Reporting bugs for MediaWiki (the software that runs Wikipedia) is a process that occurs mostly in Bugzilla. Posting bugs and problems on the wiki is unlikely to receive developer attention, so it is worth learning how to use Bugzilla to submit and comment on bugs.

• Bugzilla Etiquette at Mozilla
• Bug Writing Guidelines at Mozilla
• Bugzilla's home page
• A Bug's Life Cycle

Bugzilla is a place to notify developers of bugs and contribute information that would be useful in the fixing of the bugs. It is not a place for advocacy viz. "I REALLY WANT THIS BUG FIXED!" With that in mind, please keep the following rules in mind when using Bugzilla (partially borrowed from Mozilla's Bugzilla Etiquette):

• Contribute useful comments; useless comments (i.e. advocacy) increase the signal to noise ratio
• The developers are under no obligation to fix your bug or add a feature you want.
• No personal abuse: do not make threats like "I will not edit Wikipedia until this bug is fixed"
• Don't mess around with fields unless you are the bug's assignee or you know what you are doing, instead, comment on the suggested change
• Don't whine about WONTFIX decisions
• Applicability varies, but when in doubt, follow the rules

If you see someone not following these rules, politely mention it to them via private email: do not bugspam some more by chastising the user for their conduct publicly.

You've got a bug, you're itching to report it, first thing you should do is search for an existing bug. More likely than not, someone has already reported the bug before you: searching like this helps prevents duplicates.

So... you've tried your search, trying multiple synonyms and rephrasings of what the bug could have been. Now... it's time to create an account, as accounts on Wikipedia do not carry over into Bugzilla. Now, it's time to enter your bug. Select the product (usually MediaWiki), and you're ready to go.

Here are what the fields mean (for MediaWiki):

• Version - for bugs that are happening on Wikipedia, the selection 1.6-cvs is usually correct, as Wikipedia runs code straight from the CVS repository.
• Platform and OS - these usually have no bearing on the actual bug, but it doesn't hurt to leave them specified (they are autodetected)
• Component - try to figure out what part of MediaWiki the bug is part of.
• Severity - how severe the bug is. This should not be an opinion on your part, rather, based on these tags:
  • Blocker - blocks development and/or testing work (you probably wouldn't know)
  • Critical - crashes, loss of data (internally, not, say, your edit preview)
  • Major - major loss of function
  • Minor - minor loss of function, or other problem where easy workaround is present
  • Trivial - cosmetic problem like misspelled words or misaligned text
  • Enhancement - request for enhancement (feature requests)
• Assign To - the field will automatically get filled, don't touch it
• CC - this field will add people to a mailing list which notifies users when a bug has been changed. It's generally not a good idea to randomly add people to the CC list (let them do it)
• URL - a specific URL for the bug, if any
• Summary - describe the bug in 60 characters or less. Be pithy, be precise, be concise, be concise. A developer should be able to read the summary and say, "Oh, that's what the bug is about." A bad summary is "Wikipedia isn't working!" Remember, people searching for bugs will often search the summary. Make a good impression: the summary should tell the developer whether or not to look into the bug.

Description

In a description, you should describe anything and everything about the bug. A general template to go about doing this is:

1. An overall description of the bug
2. Steps to reproduce
3. Expected result
4. Actual result
5. Additional information

Keep things to one bug to a report, and if necessary, file multiple bug reports. A good bug report is:

1. Reproducible - if the developer can't reproduce the bug, it'll get marked WORKSFORME or INVALID
2. Specific - make isolating the bug to an area quicker for the developer

Voting is a mechanism that allows you to show which bugs you care about. Bugs you vote for automatically send you email when they're status change. You can vote for a bug by clicking "Vote for this Bug" but remember, just because a bug has 92 votes doesn't mean that the developers are obligated to fix it (or that a fix will happen anytime soon).

You can link to bugs from the wiki using the Bugzilla: e.g. [[bugzilla:1000]] for bugzilla:1000.

The MediaZilla: prefix acts a little differently, and can be used for linking to any static page in MediaZilla, i.e. mediazilla:index.cgi. You can link to bugs, as Bugzilla transparently redirects you to the appropriate page, but preferred usage is for things like: mediazilla:report.cgi and mediazilla:query.cgi. Query parameters, however, do not work (making this linking scheme of minimal usefulness).

Also, note that [[bug:1000]] does not work.

• Search for all enhancement requests
• Reports by number of votes