User:Gryllida/Bugzilla

This page explain how to use mediazilla>mediazilla:|Wikimedia's bugtracker (see for more information). To harness the full potential of this tool, please read below. Effective bug reports are the most likely to be fixed.

Try the mediazilla-search>mediazilla:enter_bug.cgi?format=guided|new guided form to file bugs!



I found a bug. Help, what do I do?
To fix an bug, the first step is to identify the issue. You as the reporter usually have most information about this; you are the primary important actor in bugzilla. Read below.

Try to reproduce your bug using a recent version of the software, to see whether it has already been fixed. Try another browser. If the bug is on a wiki site like Wikipedia you could try testing the latest software version on [//test2.wikipedia.org test2.wikipedia.org].
 * Can you reproduce the bug?

Use the search box on bugzilla.wikimedia.org to see if your bug has already been reported. You can also perform more advanced searches on the mediazilla-search>mediazilla:query.cgi|search page.
 * Has someone else already reported the bug?

It's easier to track down issues later this way, to find motivations and history for each change made.

If you have faced a bug in a recent version and no one else appears to have reported it, then report it. Include only one problem per report.
 * How do I report the bug?

Go to bugzilla.wikimedia.org. Choose "Enter a new bug". You will be asked to log in (or register) if you have not already done so (see ""). Select the product in which you've found the bug (This could be for example  for the wiki software itself, or  for configuration changes of the Wikimedia wiki sites.)

Fill out at least the recommended fields, mentioned below. Check if your report is complete, then press the "Submit bug" button.


 * Note: Bug status, priority, and target milestone fields summarize and reflect reality and do not cause it. Read about the meaning of the fields and, when in doubt, do not change them, but add a comment suggesting the change and convincing reasons for it.

Example:
 * Component: The part of the software the bug happens in. On the right you can see descriptions for each component. If none seems appropriate, use .
 * Severity: If you request a new feature, please set the severity to </>.
 * Summary: A short one-sentence summary that explains the problem (not your suggested solution).
 * Good:
 * Bad:
 * Description: Full details of the issue, giving as much detail as possible. This can include:
 * Steps to Reproduce: Minimized, easy-to-follow steps that will trigger the described problem. Include any special set-up steps.

Example:
 * Actual Results: What the application did after performing the above steps.

Example:
 * Expected Results: What the application should have done, if there was no bug.

Please also provide any other information that might be useful, such as: the web browsers, skins, or computer systems you've seen the bug on; links or diffs to one or more pages where you encountered the bug; or whether the problem appears every time, only occasionally, only on certain pages, or only in specific circumstances.
 * Attachment: You may attach a log file or (but make sure that no confidential data is included or shown).

Some people don't enter the bug fields, or enter them incorrectly. Once you gain orientation in the components and software structure, you can help by subscribing to a component in your preferences at Bugzilla and confirming bugs, moving them to a relevant component as appropriate, granted you're familiar with what component they belong to; if in doubt, it's usually better to leave a bug in the queue and someone else would look at it.

I would like to comment. What do I do?
The bug tracker allows commenting on bugs. Comments should be directly related to reporting, confirming, evaluating the severity, or fixing the bug. Thoughts unrelated to the topic of the report (for example, meta-level discussions on priorities in general or on whether a new extension is wanted at all) should go to the appropriate mailing lists or wiki talk pages.

Criticize ideas, not people; a healthy amount of constructive criticism and vibrant debate helps to improve our software and is encouraged.

Remember to act in public. Unless you are reporting a security issue or you were asked to email somebody with specific information, place all technical information relating to a bug report in the report itself.

Bug is not fixed. Help!
As a general rule, the fastest way to see a bug resolved is to provide a patch; +2 is one policy for approving proposed code.

Something wrong is going on here. What do I do?
If you see someone not following these guidelines or not being productive:
 * 1) The first step is to contact them. This can be done through private email in minor cases, or in public in major cases to avoid any later assumptions of tolerated behavior.
 * 2) *Be informative — Tell what they are doing what they should not do. If pertinent, make them aware of this document.
 * 3) *Be catalytic — Tell what they should do instead. Occasionally this may be encouraging and motivating, better than a dense list of "rules".
 * 4) In the case of persistent disregard of these guidelines, ping a Bugzilla administrator on Wikimedia IRC or send an email to the bugwrangler and ask him or her to look into it.