Bugzilla/Fields
< Bugzilla
(Redirected from Bug management/Bugzilla usage) | Due to Wikimedia's move to Phabricator this page is outdated and only kept for historical reasons. A comparison between fields in Phabricator and Bugzilla is available, also a definition of the Priority values in Phabricator. |
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
Priority
| This page is outdated (see banner above). See the definition of the Priority values in Phabricator. |
Priority should normally be set by the managers, maintainers or developers who plan to work on the bug (or by the bugwrangler), not by the one filing the bug or by outside observers.
| Priority | Meaning |
|---|---|
| immediate | Must be fixed immediately (means: "Drop any other work"). Reports must have an assignee set in the "Assigned to" field, and both assignees and further affected parties (e.g. product managers) should also be informed by private email, to be on the safe side. |
| highest | Should be fixed as next task by maintainers and certainly before the next release. Reports should have an assignee set in the "Assigned to" field. At most a handful issues (preferably one) should have highest priority at the same time on any given component.
Wikimedia-specific notes:
|
| high | Not the next task, but should be fixed soon. Depending on teams & manpower this can take between one and six months. |
| normal | Medium priority; would be good to get fixed somewhere in the future. Contributed patches might speed fixing up. |
| low | This can be fixed, but we're not going to worry about it. Patches very welcome and required for progress. |
| lowest | This can be fixed, but we're not going to worry about it. Patches very welcome and required for progress. |
- 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
| Severity | Meaning |
|---|---|
| Blocker | Blocks further development and/or testing work. |
| Critical | Crashes, loss of data (internally, not your edit preview!) in a widely used and important component. |
| Major | Major loss of function in an important area. |
| Normal | Default/average. |
| Minor | Minor loss of function, or other problem that does not affect many people or where an easy workaround is present. |
| Trivial | Cosmetic problem like misspelled words or misaligned text which does not really cause problems. |
| Enhancement | Request for a new feature or change in functionality for an existing feature. |
See also: http://www.eclipse.org/tptp/home/documents/process/development/bugzilla.html
Target Milestone
- Used by managers, maintainers and developers for release planning.
| This page is outdated (see banner above). See the assignment in Phabricator. |
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.
Tags
- Unlike Keywords which are global and visible by all users, Tags are personal and can only be viewed and edited by their author. Editing them will not send any mail notification to other users. You can use them for keeping track of bug reports which interest you. You can search for tickets with a specific tag by using the "Custom Search" in Bugzilla's Advanced Search.
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.
See Also
- See also is a link to the same bug report in other issue trackers (e.g. if the bug is in upstream code); or a link to a local report one may be looking for when reading the current bug, in particular a report about a similar (or identical) issue in another component (or the same), to aid discoverability.
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.
Alias
- A short, unique name assigned to the bug report in order to assist with looking it up and referring to it in other places in Bugzilla (for example by entering the alias of a tracking bug in the "blocks" or "depends" field instead of the harder-to-remember bug number).