(Initial version) |
(fix link after redirect) |
||
| Line 11: | Line 11: | ||
|} | |} | ||
| - | Also see [http://wiki.meego.com/ | + | Also see [http://wiki.meego.com/Quality/How_To_Report_Bugs How To Report Bugs]. |
== How can I help? == | == How can I help? == | ||
| Note: This is a first and very rough draft. If you can add information please go ahead. -- User:Andre |
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.
| TO DO: Sync prefixes (move from "Bugzilla" to "Quality" and update link -- User:Andre |
Also see How To Report Bugs.
Contents |
| TO DO: Introduce Stock answers if wanted and agreed on -- User:Andre |
| TO DO: editbugs permissions: Does this make any sense in the bugs.meego.com setup? -- User:Andre |
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.
| TO DO: Create "Tasks" wikipage -- User:Andre |
Please take a look at some ideas here.
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.
Some pieces of software that users think of as part of MeeGo might be 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 corresponding tracking system.
MeeGo is a software platform, hence bug reports about hardware bugs are invalid in bugs.meego.com. Please ask the reporter to either contact the hardware manufactorer (in case of Nokia this would be www.nokia.com) or to contact the company who sold the product to them. In case of enhancement ideas for Nokia hardware there is http://conversations.nokia.com/design-by-community/.
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 are better to be discussed on one of the MeeGo mailing list first .
Does it have enough information? Common sense rules here - "this sucks" or "this crashed" should be moved to NEEDINFO state 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, just comment describing what changes you want made, or ask for help from the #meego-bugs channel on Freenode IRC, or send an email to meego-qa@lists.meego.com.
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 "Commit" button and go onto your next bug!
If you can, please try to reproduce the problem. If you think the problem is not reproducable, write a comment indicating the exact software version you tested, the hardware that you used, the steps you took, the results you got, and why you think the bug WORKSFORME.
In general we always ask people to run the latest available software release, because nobody works on fixing ancient and obsolete releases anymore.
If you think the bug was filed against the wrong product, look for a better alternative in the drop-down list box (general information about the MeeGo architecture can be found here).
| TO DO: Document restrictions and permissions -- User:Andre |
The priority field is restricted to group_of_some_people so it cannot be set by reporters or changed by average users.
Finding the correct severity 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.
| TO DO: Introduce Stock answers if wanted and agreed on -- User:Andre |
Set the status to NEEDINFO if they don't have a stack trace, and ask the reporter to get a decent stack trace (see 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. If you're unsure about your Severity 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.
| TO DO: Anything needed here? |
Kudos to timeless, the Mozilla Triage Team and the GNOME Bugsquad. This guide is based on the maemo.org guide.