Triage Guide

Contents

Triage Guide

The main job of the bugsquad is to triage bugs in bugzilla. Triaging a bug involves:

Making sure the bug has not already been reported before
Making sure the bug has enough information for the developers and makes sense
Making sure the bug is filed in the correct place
Making sure the bug has sensible "Severity" and "Priority" fields
Making sure the bug is versioned correctly

This really just involves using common sense.

Triage Resources

Subpages with common bug triage resources:

Getting Started

The steps below should get you started triaging.

Eight steps to triage nirvana...

Create a Bugzilla account.
Join the mailing list.
It is a good idea to join the gnome-bugsquad mailing list; it is low traffic and you can subscribe at lists.gnome.org. If you ever have questions and no one is active in IRC, feel free to email the list.
Read the /StockResponses. These stock responses are general examples of the kinds of comments that triagers should add to bug reports. There are even a surprising number of bug reports for which you can simply use these responses. As of Bugzilla 2.20 we now have the opportunity to have the stock responses pasted at once into the comment text field. If you have bugedit permissions you should see the paste buttons immediately beneath the text input box in any bug report. In any case, please always add a comment when changing the bug status to NEEDINFO or RESOLVED, so the user can comprehend your decision.
Please also learn about the differences between using the stock responses duplicate (the original bug is in NEW or UNCONFIRMED state), dup+fixed (the original bug is in RESOLVED FIXED state) and dup+needinfo (the original bug is either in NEEDINFO state, or in RESOLVED INCOMPLETE state and therefore needs to be reset to NEEDINFO state again).
Pick a bug to triage.
Any bug report will do. There are some tips on finding bugs to triage. Once you have picked a bug report, read it carefully.
Find what should be changed.
Read the Steps of Triaging to determine what should be changed (if anything) and how.
Ask someone to verify your changes.
In #bugs on irc.gnome.org (or on the email list if no one is active) mention the bug number you are looking at and the changes that you think should be made. (If no one is around, it is perfectly okay to leave a comment in the relevant bug with information that could be useful to others, e.g. "I think this bug report is a duplicate of bug 86108").
Make the changes.
After someone verifies your changes (and likely refines them and/or points out other changes), either make those changes yourself or make sure that the reviewer makes them.
Repeat steps 3-6.
See if you can get on the list of people who have closed the most bugs in the weekly bug summary.

Once you feel comfortable with the bug triaging process, you may ask for extra bugzilla permissions so that you can make changes to bugzilla yourself. Details about this are in the /FrequentlyAskedQuestions.

Is that all? Don't you have any other guidance for a newbie like me?

Sure. If you would like to read more before you get started, you can read through the /FrequentlyAskedQuestions.

Steps of Triaging

Take a look at the diagram:

Some comments about status changes:

NEW: Reports should be set to the this state when the bug has a reasonable good description and the correct product and component as well as version number set. In case of crashers with a stack trace, the trace must not have missing frames (i.e. double question marks "??") in one of the 10 lines following the <signal handler>. For more information about stack traces, see Bugsquad/TriageGuide/FindingDuplicates.
RESOLVED INCOMPLETE: We should wait at least 6 weeks before closing a report RESOLVED INCOMPLETE that has unanswered questions or missing stack traces. Note: If the report has many duplicates (say >15), give it even more time. The more duplicates a report has, the longer we should wait, because the problem affects more people. Also note that some project maintainers do not appreciate closing tickets within six weeks - see Bugsquad/TriageGuide/ProductSpecificGuidelines.

This guide should make triaging a bug as easy and simple as possible. Remember, if in doubt, ask! Also, remember that you may not be able to find anything to change for some bugs since not all bugs are filed incorrectly or incompletely.

Is it part of GNOME Bugzilla?

Some pieces of software that users think of as part of GNOME have their bug tracking systems elsewhere. See /NonGnome for a list of software tracked elsewhere for common non-GNOME products that we get reports for. If the bug relates to one of these components, please close the bug as NOTGNOME and ask the reporter to report it to the correct tracking system. Note that there is a stock response for this situation.

Does it make sense?

Does it have enough information? Common sense rules here - "this sucks" or "this crashed" should be moved to NEEDINFO with a polite message, as should other things that are too ambiguous to be useful. A stock response can be found here.

It is not appropriate for bug volunteers to close a report as RESOLVED WONTFIX - that is up to the maintainers.

The exception is crasher bugs that have a stack trace. See below for details; in general you should not mark a bug NEEDINFO if it's got a good stack trace.

If you mark a bug NEEDINFO, RESOLVED INCOMPLETE, or RESOLVED INVALID, it is useful to add yourself to the Cc field; if the reporter adds more information, you can then reopen the bug and retriage it.

If a bug report has been set to NEEDINFO state and if there has been no response for 3 months, feel free to close the report as RESOLVED INCOMPLETE by using the "incomplete" stock response.

Is the bug a duplicate?

Many bugs in bugzilla have been reported before. Finding them is more of an art than a science There is a duplicate finding guide to help you find bugs that have been filed before (if you plan to search for duplicates of crasher reports, definitely take a look at that guide, as it will save you a lot of time!). This is an important step, but don't spend too long over it; if a bug is filed twice, someone else will mark the duplicate later.

If the bug is a duplicate, mark it as a duplicate in the resolution box at the bottom of bugzilla and use the "duplicate" stock response for this situation. If the original report (i.e. not the one that you currently triage) is in NEEDINFO state, please use the "dupe+needinfo" stock response instead of the "duplicate" stock response, so the reporter will be asked to answer the questions in the original, NEEDINFO bug report.

You don't need to carry on triaging it if it's a duplicate; press the Save Changes button and go onto your next bug!

What version of GNOME?

If the bug report has been filed only recently bug is about a GNOME version prior to 3.10, ask the reporter to upgrade and close it as OBSOLETE. There is a stock response for this situation. Otherwise, select the appropriate version that the bug appears in for the GNOME Version field. For example, a bug against nautilus 3.14.1 would be marked with the GNOME Version of 3.13/3.14.
There are two exceptions. If fixing the bug requires breaking string or UI freeze, you can mark the bug with the version beyond the one that will be released next. If the bug is a feature request, you can mark it as an Unversioned Enhancement.
Set the "Version" Bugzilla field as best as you can.

Has it been touched within the last year?

If the bug is not an enhancement bug and hasn't seen any updates for a long time and is still UNCONFIRMED, it is likely that the version, the bug is filed against, will not see any updates. Set the bug to NEEDINFO and kindly ask the reporter with that stock response to reproduce with a more recent version. After 6 weeks, close the bug as RESOLVED OBSOLETE.

Is it in the right place?

If you think the bug was filed against the wrong product, look for a better alternative in the drop-down list box. Make sure to mark the "Reassign to owner of selected component" radio button in the "Change State or Resolution" box as well (forgetting to do this is a common mistake that results in the new owner not getting email about the bug).

Some areas where you are likely to find misfiled bugs: GNOME2.x bugs should never be filed in gnome-core, acme tends to get lots of reports from people who don't want to take the time to find the right product in the list, gnome-desktop tends to get bugs that belong in nautilus, and general tends to get reports from people who do not know what the correct product is (and general is usually not the place for them).

Note that when you reassign bugs, bugzilla will ask you a few extra questions. More information about this can be found in the Bugsquad/BugzillaTipsAndTricks bugzilla tips and tricks .

What severity/priority should be set?

Finding the correct severity and priority takes experience, and you will get a feel for it after triaging several bugs. Here are some guidelines for the most commonly reported bugs. You should read the severity and priority guidelines at least once.

Please note that only changing severity and/or priority slightly may do more fuss than good. It causes an extra email to the maintainers and consumes their precious time and attention. If other changes are done as well then there is only little additional impact when changing severity and/or priority.

Crasher bugs
- Should have Severity=Critical, Priority=High
- Mark them NEEDINFO if they don't have a stack trace, and ask the reporter to get a stack trace (refer them to http://live.gnome.org/GettingTraces for more information). Otherwise, do not mark them NEEDINFO since that is the first step to them being closed as INCOMPLETE and the stack trace often has enough information for a developer to fix the bug. However, if there is no information about how it is triggered you should ask the original reporter how to reproduce the bug.
- The exception to the NEEDINFO rule is if the reporter is using LFS, Gentoo, or another source distribution. In this case, you can mark it NEEDINFO and ask them what compiler options they are using; if they are using anything above -O2 the bug should be RESOLVED INVALID (since it could be introduced by the compiler).
Something not working as expected
- Severity=Minor/Normal/Major depending on how much it breaks the application (see the guidelines). If GNOME would suck badly if we shipped another version with this bug, set Priority=High; otherwise Priority=Normal.
Usability issues
- Severity=Minor, Priority=Normal.
- Add the usability keyword.
- If it could be controversial, add usability-maint@gnome.bugs to the Cc field and ask them (in the bug) for their thoughts.
Accessibility issues
- Severity=Minor or Normal depending on the extent of the bug. Priority=Normal.
- Add the accessibility keyword, and possibly the keynav keyword if it's a keyboard navigation bug.
- These really require expert assessment to determine their severity, so the accessibility keyword is the most important part of our triage.
Incorrect strings, typos, etc.
- Severity=Trivial, Priority=Normal or High depending on how user-visible it is.
- Set the string keyword.
Feature requests
- If it really is a new feature, and not an improvement to something already in the product, set Severity=Enhancement, Priority=Normal.

If you're unsure about your Severity/Priority triage, add a comment in the bug explaining why you triaged it as you did. You can also add yourself to the Cc field, so if someone retriages it differently you can find out why.

Check the product-specific guidelines.

The product-specific triaging guidelines provide extra things that you can do for individual products.

Add yourself to the cc list.

By adding yourself to the cc list of bugs you change, you will receive emails with comments and changes others do to the individual report. You learn what further investigations others make and learn more rapidly about triaging bugs in bugzilla.

As of Bugzilla 2.20 there is a checkbox just below the comments input field where you can CC yourself to the report.

Encouragement from the Bugmaster

Remember that this is only the first step. At least a couple other people will read and have the opportunity to correct your mistakes. That isn't to say "make lots of mistakes" but it is to say "don't be afraid to make them." Especially once you get used to it, your work will make the lives of the GNOME developers- and as a result GNOME itself- a heck of a lot better. -- LuisVilla4

Credits

Many thanks to all contributors:

For this wiki: