Bug management/How to triage

When we triage bugs, we review each bug's initial report, comments, reproducibility, and any attached patches. We discuss its priority and status and decide whether to change them, and sometimes recruit developers to fix the bug or implement the enhancement.

During triage, a Priority is assigned to a bug. Project managers can use this field, in cooperation with the Bugmeister, in order to drive development of fixes or features to address the bug.

Setting priority
In order for these fields to retain meaning and effectiveness, Communication is essential. For example, the priority Highest has no meaning if no one has agreed to get it resolved quickly.

With that in mind, here are some guidelines for basic communication that should take place:

Highest
This priority should be reserved for bugs that affect Wikimedia's servers in production. In other words, the effect of this bug can be seen by an end user of Wikipedia or its sister sites. Usually, this is a problem that affects a number of users and impedes their use of the site. For anything that isn't marked with a severity of enhancement, these are regressions in site behavior — in other words, some functionality that worked before is not currently working.

Bugs with this priority should have someone assigned to them so that they can be addressed as soon as possible. If you think a bug deserves this priority, but do not know the developer who should work on it, then assign it to the manager for the affected product (i.e. Visual editor, Mobile, Page Triage, etc.). If you don't have any idea who to assign the bug to and you are still sure that the bug deserves this priority, then ask in IRC for some help before giving it that priority.

Immediately after marking a bug up to Highest priority, notify the following people in IRC or via email: the director of platform engineering, the management of 20% time, the management of QA. This way problems can be addressed quickly.

High
A list of bugs marked High should be collated on a regular basis and distributed to wikitech-l. This will encourage discussion of the problems and remind people of their existance. The discussion may also help you understand why a bug does not deserve this priority and improve your triageing abilities.

Non-enhancement bugs marked with a High priority should be addressed after Highest priority bugs. These should be good targets for WMF developers 20% time, so it is good to make sure the manager of 20% time is aware of the bugs.

Normal
Any bugs that have a severity of major, critical, or blocker that is not marked with Highest or High should probably be marked with Normal priority.

Low
All other bugs that merit any attention should be marked Low priority.

Lowest
Bug that are genuine issues with the software (i.e. the software is doing something it shouldn't) but that do not affect many people and do not cause a loss of data should be marked Lowest priority.

Other things to consider
Of course, there is more than just priority, and much has been written about that by other Bugzilla users.


 * “What to do and what not to do in Bugzilla” from Mozilla.
 * “Guide to Bug Triaging” from KDE BugSquad.
 * “Confirming unconfirmed bugs” from Mozilla.
 * “Eight Quick Steps to Triage Nirvana” from Gnome.
 * http://www.gentoo.org/proj/en/qa/bug-wranglers/index.xml
 * http://osdir.com/ml/sage-devel/2010-10/msg00428.html
 * http://solutionsfit.com/blog/2012/07/22/consolidate-your-technical-debt/