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

Bugs:Triage guide

Revision as of 12:24, 17 February 2010

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. Add yourself to the CC list of the reports you triage so you will receive updates and notifications on changes.
5. 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

Please take a look at some ideas here.

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 there already something like "int-123456" in the Alias field?

If so, the report already has been triaged and imported into Nokia's internal bug tracking system. Nothing to do here anymore... (Note that many reporters set an Alias like "mybug" as they think that it is required when writing a report. The planned update of Bugzilla to a newer version will fix this behaviour.)

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 is a software platform, hence bug reports about hardware bugs are invalid in bugs.maemo.org. Please ask the reporter to either contact Nokia Care services via www.nokia.com or to contact the company who sold the product to them. If the report is about an enhancement idea for the hardware, please close the report as invalid and kindly ask the reporter to file a ticket in the Maemo Brainstorm at http://maemo.org/community/brainstorm/ instead as hardware is out of scope for maemo.org Bugzilla.

Is it a valid, but wide and non-specific feature request?

Some reporters have great ideas and visions. They want to improve the User Experience in general or change behaviour of several applications at once. These ideas are very hard to handle in Bugzilla as they require extensive brainstorming, discussing and involvement of several people/teams. Such reports should be closed as INVALID and reporters should be kindly asked to file a report in maemo.org Brainstorm instead.

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 the #maemo channel on Freenode IRC (especially the bugmaster andre is good contact), or send an email to bugzilla@maemo.org.

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.

Specific areas

Documentation bugs

Specific API documentation bugs must be filed against the corresponding product. Also please add the "docs" keyword.

Generic documentation bugs and HIG issues must be filed against the "Documentation" component in the "Development Platform" product. This does not require the docs keyword.

Acknowledgment

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