Wikipedia talk:Bug report

From Wikipedia, the free encyclopedia

You have new messages (last change).
This page is deprecated - please do not post issues on this page.
All bugs should be reported on the bug tracker.

Archives:

Contents

[edit] Refactoring

I have tried to refactor the page, so that it may become actually useful. I removed all 'bugs' that were dealt with, that weren't bugs or weren't wikipedia-bugs. I also removed many 'bugs' that were reported just once, which may have been resolved.

It is my hope that now this page is a little cleaner, some of the admins/developers might actually find useful feedback here. -- Ec5618 19:14, 28 January 2006 (UTC)

There is a reason why Bugzilla was developed, and that is why the developers want you to use Bugzilla instead of this page. Bugzilla hooks up to the developer's IRC channel, it provides numerous facilities for marking bugs certain status, priority levels, and types, it has a much better search facility, and plus, each bug gets its own page. I think it's high time this page gets deprecated, deleted, and replaced with content that explains to users how to use Bugzilla, as well as giving short descriptions of fairly old bugs and links to appropriate Bugzilla entries. — Ambush Commander(Talk) 22:57, 4 February 2006 (UTC)
Good points, and at least now the confusion will end. I'm not very familiar with Bugzilla though, so perhaps someone else should write a brief introduction. At best, I may be able to set up a useable skeleton. -- Ec5618 00:32, 5 February 2006 (UTC)
It looks like Radiant went ahead and deleted it. I was hoping to delete after a suitable content substitute could have been developed... ah well. — Ambush Commander(Talk) 03:18, 5 February 2006 (UTC)
I've archived talk page content and also replaced main page with a how to use Bugzilla document. — Ambush Commander(Talk) 20:05, 5 February 2006 (UTC)

[edit] Are the page move watchlist bugs fixed?

The following section was deleted/blanked without any comment during the semi-recent refactoring of the main page, why? see here and I've included it below. Perhaps the main page should be archived properly so there is a record of when bugs are fixed? zen master T 02:13, 5 February 2006 (UTC)

I had Hubbert peak on my watchlist, when it was renamed to Hubbert peak theory the new article title was added to my watchlist but not the new title's talk page. So currently I receive the "unwatch" tab at the top for the article, but get the "watch" tab for the talk page, doesn't make sense. Perhaps this obfuscation was by design? zen master T 20:19, 27 August 2005 (UTC)

No status or fix for this? In case you care and this "bug" wasn't by design there are actually two separate bugs here: first, when an article is retitled/moved it completely disappears from your watchlist until someone edits it at its new location. Second, the new title's talk page is not automatically watched (but the new article itself is) so any future discussion after an article is renamed/moved will be missed (very convenient). zen master T 18:18, 23 November 2005 (UTC)
It seems that this page is dead. We might as well learn to live with all the fricking bugs that are all over the place, since no one apparently cares. I guess this was just the designated place for the people to vent or something.Tommstein 16:25, 24 November 2005 (UTC)

Restored above section from premature archivage. zen master T 20:49, 5 February 2006 (UTC)

I think the hint was to go to Bugzilla and see if there was already a bug, and if not, file a bug for it. — Ambush Commander(Talk) 20:51, 5 February 2006 (UTC)
I got that hint but listed reasons why a status of bugs should be kept within Wikipedia. Perhaps you missed that when you completely refactored the page which blanked active discussions that you were involved in, see here. FYI: In case you didn't notice I've also moved your refactoring to Wikipedia:How to report a bug and restored the previous archive/bug status page. zen master T 21:01, 5 February 2006 (UTC)
That was the hint. ;-) Ah well, I shall be more explicit in the future. I am not questioning the validity of the bug or any of that, but this simply is the wrong place to report it.
Most policy pages, when they go out of use, are not deleted, they simply are slapped with an inactive tag, warning people not to edit the time. Most of the time, these tags are effective. However, this has not been the case for this page.
After the tag was first added (by Brion Vibber, our lead developer), there have been no less than 20 edits to the page, five of which involved the submission of a new bug. People just don't like to read, huh?
I believe that this page would serve us best as information on how to report bugs, and in order to prevent misunderstandings, the previous bugs on the page should be permanently archived in the history, or, alternatively, a subpage. Leaving the page as a bug status page is not helpful, because it requires developers to come to this page and say, "Hey, this bug is fixed!" instead of simply closing a bug on Bugzilla after marking it FIXED.
In the mean time, you should fix the {{Shortcut}} tag and link to the how to report a bug page on this page, but I still believe that this page should have the bug reporting information. — Ambush Commander(Talk) 21:16, 5 February 2006 (UTC)
You haven't actually responded to my list of reasons why bugs should be kept self containted within Wikipedia proper? If Mediawiki software can handle an encyclopedia it is more than capable of functioning as a bug system. There are countless pages within Wikipedia that have custom access controls and various systems and people watching them to prevent vandalism, a bug system is no different. All aspects of Wikipedia should be reported and handled internally to ensure integrity, to do otherwise violates the entire concept of Wiki and collaborative development. Bug reports into bugzilla can and should be gleaned from user comments if MediaWIKI developers really and truly want to continue using bugzilla (a non wiki system). Wikipedia is by far the most heavily used Mediawiki site, it stands to reason that Mediawiki developers keep close tabs with what goes on here and are not solely focused on bugs reported into bugzilla as you and others excessively imply/claim. Are you a developer or do you make a habit of speaking for them? Forcing wikipedia users to go to bugzilla only decreases the awareness of bug information. Disparate information locations and instituationalized redundancy are not a benefit to wikipedia and collaborative development. At the very least Wikipedia should have a Wikipedia:Bug status page that succinctly lists all currently active bugs (and recently closed bugs and common pitfalls/FAQ), but if certain people are uninterested in fixing bugs such as the page move watchlist bugs (intentional obfuscation?) then it probably won't matter. zen master T 23:58, 5 February 2006 (UTC)
I actually agree with what was the basic premise of this page. I recently decided to refractor this page, and had hoped that the page could find volunteers to actually provide feedback on ongoing issues.
Perhaps we shouldn't have so easily given up on this page. -- Ec5618 00:12, 6 February 2006 (UTC)
I agree, would you be interested in trying to resurrect this page? I still think there should be a place within Wikipedia for users to report issues, this info can then be used to generate bugzilla bug reports, and/or add to the FAQ of common pitfalls and would be any easily searchable historic guide of the sorts of problems users run into. zen master T 05:53, 6 February 2006 (UTC)
I can understand your viewpoint, and this is probably the most obvious solution. Indeed: this has popped up in multiple places (i.e. meta:MediaWiki extensions and meta:MediaWiki feature request and bug report discussion). Both, if you notice, have notices warning users to use Bugzilla.
So... with your issues. If Mediawiki software can handle an encyclopedia it is more than capable of functioning as a bug system. You're right: it is capable of functioning as a bug system. But is it the best choice? (of course, that rhetorical question is up for debate, what I'm really trying to say is "Just because you can use the wiki, you shouldn't, if there is a better tool out there") (but is Bugzilla a better tool?) (and can both work in tandem?)
There are countless pages within Wikipedia that have custom access controls and various systems and people watching them to prevent vandalism, a bug system is no different. I believe what you are trying to say is that the concept of wiki has been stretched to accomodate other things like discussion, dictionaries, news reporting, source text repositories, common image file repositories, etc. But if you think about this, and then think about how these project's configuration for the software is different (how many times has an actual "forum" system for discussion has been proposed, what are some inefficiencies in Commons that could have been corrected by more specific software?) They do work, but many times it's not to full potential. A lot of the time, this is because there is no alternative. But there is a better way (reference to the 2005 Democratic Response)
All aspects of Wikipedia should be reported and handled internally to ensure integrity, to do otherwise violates the entire concept of Wiki and collaborative development. Bug reports into bugzilla can and should be gleaned from user comments if MediaWIKI developers really and truly want to continue using bugzilla (a non wiki system) - Then why do we have a MetaWiki? :-) And as regards to the fact that Bugzilla is a non-wiki system, well, the development process for the software also is un-wiki. The developers are under no obligation fulfill your freature requests. But we've got the next best thing: open-source software.
I think you are somewhat confusing Bugs and Feature Requests/Implementation Details (which do get lumped together all the time). Say, for instance, clicking my contributions doesn't bold the link up top. That's a bug. The real behavior seems simple: make sure it gets bolded when it happens. It actually is a bit of a problem to fix. Would it belong on this page? Of course not!
But take the single login bug. The actual implementation of the solution is complicated, and there is great variance in opinions on how exactly to fix it. Thus, meta:Single login has risen up for the transparent communication process through wiki. But notice how it is on meta, not on Wikipedia. Why?
Wikipedia is by far the most heavily used Mediawiki site, it stands to reason that Mediawiki developers keep close tabs with what goes on here and are not solely focused on bugs reported into bugzilla as you and others excessively imply/claim. As in Wikipedia you mean multilingual Wikipedias, right? French Wikipedia, German Wikipedia, they all also have their say on software issues, no? After all, they all use MediaWiki. But, of course, we should put this stuff on English Wikipedia! Because English Wikipedia is special! En.Wikipedia simply is the wrong place for the "end-all-be-all-bug-reporting-place" (it can have it's own bug facilities), but this really belongs to meta. Or Bugzilla.
As to whether or not the MediaWiki developers keep close tabs here, they do! Check out Wikipedia:Village pump (technical), or alternatively, Special:Contributions/Brion_VIBBER.
Are you a developer or do you make a habit of speaking for them? Aww... you're being unfair! :-) It's not a binomial categorization, but yes, I try to speak for the developer's so that they can do the coding. Besides, every action the developers have made (such as the original deprecation notice on this page, by Brion Vibber, and the comments by Rob Church) say "USE BUGZILLA!"
Being a developer myself (just not on MediaWiki (and even then, sort of, I've submitted a few patches and written a bit of documentation)), I have a bit of insight into the development process. I also have been reporting bugs for Mozilla Firefox, and I see a lot of bugspam happen over at that Bugzilla. It drives the developers nuts. (this argument is a bit sparse, so feel free to ask for elaboration)
Forcing wikipedia users to go to bugzilla only decreases the awareness of bug information. Disparate information locations and instituationalized redundancy are not a benefit to wikipedia and collaborative development. These are two very different concerns, both valid. True, forcing users to go to Bugzilla does decrease awareness. If it prevents bugspam, it's a good thing :o) But when there is a bug, it doesn't take very much for a user to ask around and get pointed to the best place. Remember, they still have to find this page.
Regarding the second concern, you might think that it was an argument against this page. If you think about it, Bugzilla has been around a lot longer, and it could be this page that is the disparate information location and redundancy that is not a benefit. (there are other arguments, but I think this suffices)
At the very least Wikipedia should have a Wikipedia:Bug status page that succinctly lists all currently active bugs (and recently closed bugs and common pitfalls/FAQ) There are 1000+ open bugs on Bugzilla, and 4887 total bugs ever filed. Redundancy is bad. A common pitfalls/biggest bugs FAQ would be a good idea though.
if certain people are uninterested in fixing bugs such as the page move watchlist bugs (intentional obfuscation?) then it probably won't matter. Trust me, the developers do care. But they care about a lot of things, and if you can make their life easier by using Bugzilla and reducing the number of places they have to watch, please do that. Is bugzilla:2580 relevant?
This comment is way too long, and if you read it all, I thank you. This I believe. — Ambush Commander(Talk) 02:03, 6 February 2006 (UTC)

I agree the word "bug" may be an insuffient word to describe issues listed on this page. For repeated example after the software "upgrade" last summer the watchlist was changed to where very important information, such as the renaming of an article, no longer shows up on the page designed to "watch" for changes which makes one wonder if that change was intentional for the purpose of obfuscation (not a "bug" in that case). I agree the Mediawiki developers should perhaps primarily monitor bugzilla, however, all Wikipedia users should have one central place to report and monitor bugs self contained within that site. Surely Wikipedia has their own staff of developers and admins separate from the Mediawiki software developers? I've commented elsewhere previously on the need to have one unified namespace, having disparate meta, dictionary, quote, news and encyclopedia sites makes potential obfuscation easier. Bug spam is the exact same spam problem that is already dealt with on Wikipedia on a massive scale. I did not mean other language Wikipedias above, I meant the Mediawiki software does not exist in a vacuum, developers of the software are highly likely to be keeping close tabs on the most popular site that uses that software (Wikipedia). Though, since you mentioned it does wikipedia's instance of bugzilla or the Mediawiki developers even support or speak other languages such as French and German, that point seems to be against your position, the language issue is actually a reason for each Wikipedia site to have their own list bugs and issues their users have encountered. Also, many Mediawiki sites install their own custom extensions and "hacks" which are obviously specific to that site, forcing everyone to one central bug reporting location in that likely case is unwise. Following the principle of full disclosure and ease of accessibility for as many users as possible all information that is relevant or potentially relevant to the use of Wikipedia should be listed somewhere on Wikipedia. zen master T 05:53, 6 February 2006 (UTC)

When it comes to software issues, the hierarchy is actually quite simple. You have the core MediaWiki installation, and then extensions in the form of extra wiki markup and special pages. The Bugzilla is set up to make this very explicit, if you notice, there is a product description page for MediaWiki, and then MediaWiki extensions (like Cite). Wiktionary and Wikisource could be using the same extension: Bugzilla makes this explicit, splitting up the issues into each project doesn't.
Bugspam is not the same as Wikipedia vandalism. Bug spam is users harassing developers trying to get a feature implemented or a bug fixed. I was trying to pre-empt a flood of clueless users submitting "bad bugs" as the visibility of Bugzilla increased, forgive me if I was ambiguous.
My point is this: there is no reason for a central bug reporting place on English Wikipedia. Yes, there is a place for a central feature request place (but that probably belongs on Meta), yes, there is a place for a FAQ of longstanded bugs (but that is not what this page was previously, and it also may be more appropriate on Meta). The How to Use Bugzilla seeks to provide full disclosure, by telling users upfront how to find and report bugs. It should be, I argue, supplemented with a FAQ listing the most frequently reported bugs. — Ambush Commander(Talk) 19:56, 6 February 2006 (UTC)
You misinterpret my point, the bug reporting place on English Wikipedia should only include issues as reported by users of English Wikipedia -- French, German and other non-English sites would have their own bug report or bug status areas. How to use an external bug system is not an explanation for why that information can't (also) be kept on the site where the bug or issue occurs. The most commonly reported bugs aren't necessarily the most important, the watchlist feature not working as it did previously is a very serious issue and as many users of Wikipedia as possible should be made aware of it. zen master T 20:52, 6 February 2006 (UTC)
Okay, I've misinterpreted your point. I still think the new interpretation is a bad idea, unfortunantely. ^_^" I am going to ask for a few more clarifications, if you don't mind. What exactly is the "information" that "can't (also) be kept on the site)? Also, I tested your bug, and it does seem to exist. I don't know why you won't file it yourself, so I'm going to go out and do it for you.
If the bug causes the software to not work as expected, and could cause problems for users but would remain mostly latent so they would not notice until it's too late, then why would they find this page before they notice the bug? So then, they ask around, and then a knowing user either points them to Bugzilla, or they point them to this page. Then they mill around, say "We really need to fix this bug," vent their frustrations on the talk page, and the developers still never find out. They go to Bugzilla, they file a duplicate bug, and the developer goes, "Hmmm.. haven't ten other users already reported that? DUPLICATE!"
Or, we could have a nice, user friendly page, telling them how to search Bugzilla before filing bugs, some short synposes of the major bugs, and no indication that they should ever place their frustrations on this page.
Better yet, we could edit MediaWiki:Watchdetails to notify people of the caveat on the watchlist. There are many other possibilities. What are the other bugs? — Ambush Commander(Talk) 21:49, 6 February 2006 (UTC)
The information is the bug information, all issues a website is experiencing should be listed somewhere on that site, especially for a wiki open collaborative site. I did report it here on Wikipedia, I didn't report it to the developers because it probably wouldn't matter since I considered the "bug" was most likely intentional given all the page renaming/title controversies around that time (also all the other reasons listed above).
The most likely first thing a wikipedia user is going to do if they encounter a bug is search wikipedia for info on, or other examples of and workarounds for, that bug. Venting about the bug on a random wikipedia discussion page is better than discouraging any mention of the bug or issue within wikipedia. I've worked with bugzilla a lot and the wiki concept is a better system for managing bugs especially because of the fact that it keeps bug information about a site specific to that site (if the site is a wiki). Listing bug information within one site in no way diminishes the ability to file a bug in an external bug system, I would argue that actually spreads bug information more effectively (eventually). The fact that so many duplicate bugs are filed into bugzilla should be taken as an impetus to have an easily accessible bug status page in many locations that concisely summarizes all currently know issues. zen master T 22:33, 6 February 2006 (UTC)
A related bug is the fact that discussion page vs article page watching (watchlist) can get out of sync. In some cases, if the article is renamed after maybe you clicked watch for the discussion page rather than the article, you could be watching the article but not the discussion page (or vice versa). I've loaded to the discussion page of an article and gotten the "watch" tab but received the "unwatch" tab for the article, very confusing. Maybe this one has been fixed, haven't confirmed it recently. zen master T 22:33, 6 February 2006 (UTC)

Something real silly (read confusing) is happening. Is it just me, or did Zen-master just get banned? — Ambush Commander(Talk) 01:51, 7 February 2006 (UTC)

[edit] Shoot me, but...

I still think that the page should mostly be how to use Bugzilla, and then with a list of bugs supplementing it. With Zen-master banned (for one year, mind you), and without any major opposition, I have reverted it back to the other version. — Ambush Commander(Talk) 01:56, 7 February 2006 (UTC)

Is there any reason you're so cheerful about it? As it happens, I oppose your change. The Wikipedia:How to report a bug page was a great compromise, which allowed this page to continue to showcase known issues. For one, this might allow Bugzilla to run more efficiently. For another, it might help users with problems at their end, in a respectful tone (as you may be aware, bugzilla responses are not the most friendly). You have said a lot above, but nothing to explain removing these bug reports. I'll not revert. Please do it yourself, or make a really good case. -- Ec5618 02:08, 7 February 2006 (UTC)
"BugZilla responses are not the most friendly"
Well, if you ask a stupid question... Rob Church (talk) 17:50, 10 February 2006 (UTC)
Well, it doesn't look like I'm going to get away with this, but here's what. I wouldn't mind if this page was a list of major bugs and a place for users to vent frustrations. However, we don't have an exact implementation of that idea, and I'm fairly certain that I was able to convince Zen-master that the page, as it currently stood, was not good. The How To page is a better solution, and the showcasing of known issues may have been the best solution. However, I reiterate, we don't have a page showcasing known issues. There are 1000+ open bugs on Bugzilla, and each them may be valid. I've archived the old reports, but they need to be rewritten in a more objective fashion.
I'm sorry. I didn't mean to come off as cheerful or declaring victory because zen-master got blocked. — Ambush Commander(Talk) 02:34, 7 February 2006 (UTC)

[edit] Ultimatum

OK, excuse the tone here but these little arguments have gone on long enough. I shall now address:

  1. The reason we don't use the wiki to track bugs
  2. Where we do track bugs
  3. What to do when one finds a bug
  4. Recommended course of action
The reason we don't use the wiki to track bugs

MediaWiki is a wiki engine and is designed for collaborative editing of freeform documents. Wikimedia uses it to organise encyclopaedias; dictionaries, and other free information resources.

MediaWiki is not designed to track bugs. It is not an effective tool for doing so. It doesn't have the elements we need to track bugs, dependencies, keep tabs on duplicates, states and statuses, assignees, etc. In short, it's not up to the job of helping us work.

It's not designed to be. We use BugZilla because that is designed to track bugs.

Where we do track bugs

All bugs, feature requests, and requests for changes to the site configuration need to be posted on our BugZilla at http://bugzilla.wikimedia.org. Core developers subscribe to a mailing list for, and receive updates and status reports on, bugs and so forth. It's all in one neat place. We can organise things, mark priorities, and generally co-ordinate the coding, running and tweaking of the site.

What to do when one finds a bug
  1. Be sure it's a bug
  2. Post it on the bug tracker at http://bugzilla.wikimedia.org
Recommended course of action

Each of these little "bug reporting" pages needs to be tagged as deprecated. Redirect them all to one single page, containing a brief (or this) explanation of the reasons we use the tracker. Or redirect to instructions on how to use it. It doesn't matter.

Please bear in mind

With one exception, none of the developers are paid for their work. We have people from a range of ages, skills, backgrounds and geographical locations. Brion's a professional software developer from California. Tim's a Ph.D. student from Australia. I'm a pre-degree student from the UK. There are lots of us, but we all

  • Have lives
  • Have other priorities, at times
  • Do this through some altruistic channel

We cannot and will not be expected to watch six thousand little pages. We already deal with thousands of requests, bug reports, etc. each and every day. I doubt we particularly mind (else we wouldn't do it) but we have set out the ground rules. This is how it has to be. We can't keep Wikipedia and the like as an Alexa top 15 (or is it higher now?) web site, and keep track of things, and organise ourselves, without a little co-operation.

All we've asked for is for people to use a bug tracker. Is it so hard?

Thank you. Rob Church (talk) 01:22, 10 February 2006 (UTC)

Nobody knows what "deprecated" means in this context. Usually it means "to put down," or "to insult." 131.123.231.143 04:34, 10 February 2006 (UTC)
Phased out. Obsolete. Rob Church (talk) 13:48, 10 February 2006 (UTC)
I understand that at some point, this page was where users came to make sure they had found a bug, in part to prevent users from complaining about problems at their end. -- Ec5618 13:56, 10 February 2006 (UTC)
This page is now obsolete and should not be used to report bugs or request features. We are not guaranteed to see them, and we are not obliged to even think about responding to them. Rob Church (talk) 17:49, 10 February 2006 (UTC)

[edit] Stopping spammers from finding my e-mail address at Bugzilla

Is there a way to prevent Bugzilla: from reporting my e-mail address for everyone to see? I figure spammers will find it fast. Will (Talk - contribs) 05:11, 14 December 2006 (UTC)

There's lots of services out there that offer throw-away email addresses. — Edward Z. Yang(Talk) 05:58, 15 December 2006 (UTC)

[edit] Moving to meta

Any reason the bulk of this documentation shouldn't be moved to meta? the wub "?!" 16:55, 10 January 2007 (UTC)

If you checked the page history, you'll notice that a long time ago, this page was used as a dumping ground for random bug reports and feature requests from English Wikipedia, much to many developer's dismay. Anyway, there was substantial opposition to nuking the page, so I rewrote it pointing users to the right place.
In short: probably not. — Edward Z. Yang(Talk) 21:18, 10 January 2007 (UTC)
Pah, I don't need to check the page history - I remember those days. It certainly doesn't seem that long ago... am I turning into an "oldtimer"? Anyway great job on the rewrite, I just think it should be on meta to avoid duplication. the wub "?!" 00:24, 11 January 2007 (UTC)

[edit] cookies logging in

i know this isnt where im supposed to be with this, but i dont know where i am supposed to be, and bugzilla isnt opening. but i cant log in to wikipedia cause it says i have cookies disabled, which i have not, this problem keeps coming back from time to time. what could i do? lygophile 15:58, 16 March 2007 (UTC)

The appropriate place to ask a question like this is not this place or Bugzilla but Wikipedia:Village pump (technical). I'm sure some folks over there will be able to help you. Be sure to also say what your browser is. — Edward Z. Yang(Talk) 17:11, 16 March 2007 (UTC)
Retrieved from "http://en.wikipedia.org../../../b/u/g/Wikipedia_talk%7EBug_report_d265.html"