BugSquad/Triage Guide
Bugsquad Triage Guide
Why bug triaging is helpful?
- Filter out duplications
- Verify that the information, needed by the developer to fix the bug, is present
- Verify that the bug is filed against the correct component
- Verify that the bug has the correct software version field
- Verify the priority of the bug
How to get up to speed
Create a trac account
- Create a trac account at laptop.org.
Join the sugar mailing list
To keep up to date with the recent discussion and developments we recommend joining the sugar mailing list. We might create a separate list for the Bugsquad in the future.
Read the Stock Responses
The QATeam/TriageGuide/StockResponses are general examples of the kinds of comments that triagers should add to bug reports. Please read them carefully. In most cases you can use one of them as a comment.
Triaging
Pick a bug
Use the tracker to create a query http://dev.laptop.org/query. This for example creates a query for all open sugar bugs. Choose one you want to triage and read it carefully.
Find what should be changed
Read the QATeam/TriageGuide#Steps_of_Triaging to determine what should be changed (if anything) and how.
Ask someone to verify your changes
For the first bugs we encourage you to make the changes in conjunction with a member of the bugsqad team QATeam/Contacts#List_of_Triagers. You will find them usually at #sugar on freenode.
Make your 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.
Steps of Triaging
These are some notes how to triage the bugs in detail. In all the cases you can find the matching stock response at QATeam/TriageGuide/StockResponses.
Verify that the bug is not a duplicate
Many times the particular bug has already been reported into our bug tracking system. Note to which bug this is a duplicate to and close this one with 'resolve as duplicate'. If the original bugs needs further information, please encourage the reporter to provide that information there.
The bug report need some logs
In most of the cases the developer could use some logs to better identify the problem. Instructions on how to take logs are at QATeam/GetLogs.
If the bug is not described well
The bug report isn't very useful if the bug isn't described well. Some people do not read the QATeam/BugHowto or are just inexperienced. Best, is to use one of the stock answers and go to the next bug :)
If the bug is in an obsolete version of the application
Sugar developers may not work anymore on the specified version. If you are unsure if that is the case, please ask at #sugar or in the mailing list.
If the bug is not in Sugar
The bug might not be in sugar and in one of the libraries sugar is using (i.e. telepathy). Please try to help to get the bug report upstream. Also ensure that both bug reports contain a link to each other.
Priority of the bug
Verify that the priority of the bug is set correctly. What you should not try to set is the milestone of the bugs, this is the duty of the component maintainer.