Jump to content

User:Gryllida/Bugzilla

From mediawiki.org


This page explain how to use Wikimedia's bugtracker (see Bugzilla 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 new guided form to file bugs!

A screencast is available to find out more about how the new guided form works.

Bug reports need to be made in English. If you can't write in English, try using a machine translation tool like Google Translate, or ask at your local wiki talk page for help.

I found a bug. Help, what do I do?

[edit]

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.

Can you reproduce the bug?

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.

Has someone else already reported 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 search page.

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

How do I report the bug?

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.

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 "Why must I register? "). Select the product in which you've found the bug (This could be for example MediaWiki for the wiki software itself, or Wikimedia 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.
  • 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 General/Unknown.
  • Severity: If you request a new feature, please set the severity to enhancement.
  • Summary: A short one-sentence summary that explains the problem (not your suggested solution).
    • Good: "Selecting Gender is not functional."
    • Bad: "Software crashes."
  • 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:

  1. Go to https://en.wikipedia.org with Internet Explorer version 10.0;
  2. Make sure you are logged in;
  3. Select "My Preferences" menu;
  4. Go to "Gender" and select female gender from box list;
  5. Click 'Save' button.
  • Actual Results: What the application did after performing the above steps.

Example:

"There is no female gender in front of my user name."
  • Expected Results: What the application should have done, if there was no bug.

Example:

"My gender is shown in front of my user name."

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 screenshot (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?

[edit]

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!

[edit]

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?

[edit]

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.
    • Be informative — Tell what they are doing what they should not do. If pertinent, make them aware of this document.
    • Be catalytic — Tell what they should do instead. Occasionally this may be encouraging and motivating, better than a dense list of "rules".
  2. 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.

See also

[edit]