Bugzilla/Fields

Here are some details about what the various Bugzilla fields are for. Some of the fields only apply to the MediaWiki software itself - others are more general. Not all of these fields have to be filled out always - in case that you don't know, simply ignore the field. Also note that some of these fields are not shown initially when you file a new bug report.

Status and Resolution

 * Please see the bug life cycle for information on the status and resolution fields.$$$$

Product

 * What general "area" the bug belongs to. For example, bugs to do with the MediaWiki software itself go in the "MediaWiki" product. See https://bugzilla.wikimedia.org/describecomponents.cgi for a list of products and their descriptions.

Component

 * Each product is divided into different components. See https://bugzilla.wikimedia.org/describecomponents.cgi for lists.

Version

 * The latest version of MediaWiki, that the bug is known to affect. Check Special:Version on the wiki where you noticed the problem to find out the version it is.
 * For extensions, use the version of MediaWiki that the extension was running on, or leave as 'unspecified' if not relevant.
 * For most other products this field is not used, and should be left as 'unspecified'. However providing information in the bug report description about the version of an extension is often welcome.

Hardware / OS / Platform

 * Only use if the bug is specific to your hardware or your desktop operating system. If you are not sure, it does not hurt to fill it in anyway.

Importance
The importance of a bug is a combination of its priority and s

everity, as described below.

Priority
Priority should normally be set by the developers who plan to work on the bug (or by the bugwrangler), not by the one filing the bug or by outside observers.
 * In addition, “Unprioritized” was added as the default priority level in April 2011. If this is the priority level on a bug, then the bugwrangler is either not concerned with it (e.g. Semantic MediaWiki items are tracked in Bugzilla, but the bugwrangler does not set priority on those items) or hasn't seen it.

Severity
See also: http://www.eclipse.org/tptp/home/documents/process/development/bugzilla.html

Target Milestone

 * Used by maintainers and developers for release planning.

Assigned To / Assignee

 * The field will automatically get filled, don't touch it unless you are also planning a fix (in which case assign it to yourself) or you know the development team well enough to know who should be responsible.

URL

 * A specific URL for the bug, if relevant. This may be a URL where you can see the bug in action, or a link to further information (but not generally to screenshots giving an example - these should be uploaded as attachments).

Summary

 * Describe the bug in 60 characters or less. This will show up in searches, etc. Try to use relevant keywords so the report is easy to find.

Whiteboard

 * A freetext field used by developers to add certain categories of personal tags to reports.

Keywords

 * There is a set of fixed keywords used across all products and components. See https://bugzilla.wikimedia.org/describekeywords.cgi for the list.

CC / CC List

 * 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 add people other than yourself to the CC list unless you know that they welcome such notifications.

Web Browser

 * Only use if the bug happens with a specific browser. If you are not sure, it does not hurt to fill it in anyway.

Mobile Platform

 * Only use if the bug happens with mobile devices.

Reporter

 * The account of the user who created the bug report.

Depends on

 * Lists other bug reports which first need to be resolved before this bug report can be resolved.

Blocks

 * Lists other bug reports which cannot be resolved before this bug report has been resolved.