Bugs:Triage guide

This article is for anyone who wants to help triaging the incoming and existing bug reports in Maemo Bugzilla. This article is not for bug reporters, but those people taking a look at the reports after they have been submitted.

Following the techniques listed and explained here will help important bugs get fixed, as well as optimize precious developer time.

How can I help?

 * 1) Create an account.
 * 2) Read the Stock answers. 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. Please always add a comment when changing the bug status to RESOLVED or adding the "moreinfo" keyword, so the user can comprehend your decision.
 * 3) Find what should be changed. Read the Steps of Triaging to determine what should be changed (if anything) and how.
 * 4) Ask someone to verify your changes. In #maemo on irc.freenode.net 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 1234").

There are a number of ways, but one way is to pick a couple of components that interest you, or which you know about, or are willing to learn, or happen to use and set up user watching. Once you've done that, look through the bugs in each of those components.

You could also take a look at the latest incoming reports of the last two weeks.

As time goes by and you become more familiar with Bugzilla, please ask the Bugsquad members to provide editbugs permissions to you so you have gain much more power to change things and work efficiently in the bug database.

Steps of Triaging
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 Maemo Bugzilla?
Some pieces of software that users think of as part of Maemo are 3rd party software and have their bug tracking systems elsewhere. If the bug relates to one of these components, please close the bug as INVALID and ask the reporter to report it to the correct tracking system.

Hardware problems and Hardware enhancement requests
Maemo.org is a software platform, and while its sponsor thinks about hardware, we don't. Close the bug as invalid and ask the reporter to either 1. Contact Nokia Care services 1. visit www.nokia.com 2. browse to Nokia 770 or Nokia N800 3. Support and Software 4. Under Nokia Care services, select Repair and recycling 5. Select your Nokia Care point 6. Select Repair or Warranty 2. Contact the company who sold you the product

Does it make sense?
Does it have enough information? Common sense rules here - "this sucks" or "this crashed" should get the "moreinfo" keyword with a polite message, as should other things that are too ambiguous to be useful. In many cases asking for a URL or attachment will help. If you need help making changes to bug fields ("editbugs"), just comment describing what changes you want made or ask for help from #maemo (especially the bugmasters, andre and guenther, are a good contact).

Is the bug a duplicate?
Some bugs in Bugzilla have been reported before. Finding them is more of an art than a science :-) 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. Be creative, e.g. searching for "delet" will bring up all bugs that have "delete" or "deleting" in the report. If the bug is a duplicate, mark it as a duplicate in the resolution box at the bottom of bugzilla and add a polite comment explaining that this bug/request has been filed before. 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!

Can you reproduce it?
If you can, please try to reproduce the problem. If you think the problem is not reproducable, write a comment indicating the version you tested, the steps you took, the results you got, and why you think the bug WORKSFORME. If you can reproduce the bug running the latest publically available software version and if it is well-reported, change the status from Unconfirmed to New.

Is the version set correctly?
See http://en.wikipedia.org/wiki/Internet_Tablet_OS for a mapping between the SDK version information used in Maemo Bugzilla and the name of the software images. In general we always ask people to run the latest available software release, because nobody works on fixing ancient and obsolete releases anymore.

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 bug to default assignee and QA contact of selected component" radio button (forgetting to do this is a common mistake that results in the new owner not getting email about the bug).

What severity/priority should be set?
Finding the correct severity and priority takes some 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.

Should have Severity=Critical, Priority=High. Add the "moreinfo" keyword if they don't have a stack trace, and ask the reporter to get a decent stack trace (see https://wiki.maemo.org/index.php?title=Bugs:Stock_answers for more information). If there is no information about how it is triggered you should ask the original reporter how to reproduce the bug. Severity=Low or Medium depending on how much it breaks the application. Severity=Low, Priority=Normal or High depending on how user-visible it is. If it really is a new feature, and not an improvement to something already in the product, set Severity=Enhancement, Priority=Low. 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.
 * Crasher bugs
 * Something not working as expected
 * Incorrect strings, typos, etc.
 * Feature requests

What keywords should be set?
The available few keywords are listed here. Get familiar with them. For example, if the bug is most probably trivial to fix, add the "easyfix" keyword. If a patch has been added that fixes the issue, add the "patch" keyword.

Acknowledgment
Kudos to timeless, the Mozilla Triage Team and the GNOME Bugsquad. I shamelessly copied huge parts from them.