• Intro
• Downloads
• Community
• Development
• News
• TALK

Bugs:Triage guide

Revision as of 08:35, 4 May 2009

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").

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.

Potential tasks

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.

Or you could take a look at old bug reports and try to reproduce them with the latest software release (currently Diablo version 4.2008.30-2) to find out whether the reports are still valid.

Another option is to clean up bugs with moreinfo keyword that have not been changed for 6 months. This means that more information had been requested from the reporter but has not been provided. These bugs should be closed as WORKSFORME if you are not able to reproduce. If there is simply not enough information to be a useful report, then close the bug as INVALID (You need editbugs permissions for such changes). Please always explain your decision by adding a nice comment and in the latter case, ask the reporter to provide the information asked for, if he can, and reopen the bug.

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 (You need canconfirm permissions for this).

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.

• Crasher bugs

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.

• Something not working as expected

Severity=Low or Medium depending on how much it breaks the application.

• Incorrect strings, typos, etc.

Severity=Low, Priority=Normal or High depending on how user-visible it is.

• Feature requests

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.

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.