Difference between revisions of "BugSquad/Triage Guide"

From Sugar Labs
Jump to navigation Jump to search
 
(31 intermediate revisions by 12 users not shown)
Line 1: Line 1:
{{TeamHeader|BugSquad}}
+
<noinclude>{{TeamHeader|BugSquad}}{{TOCright}}
 
+
[[Category:BugSquad]]
= Bugsquad Triage Guide =
+
[[Category:HowTo]]
 +
</noinclude>
  
 
== Why bug triaging is helpful? ==
 
== Why bug triaging is helpful? ==
Line 8: Line 9:
 
* Verify that the bug is filed against the correct component
 
* Verify that the bug is filed against the correct component
 
* Verify that the bug has the correct software version field
 
* Verify that the bug has the correct software version field
* Verify the priority of the bug
+
* Verify the severity of the bug
  
 
== How to get up to speed ==
 
== How to get up to speed ==
 
=== Create a trac account ===
 
=== Create a trac account ===
Create a trac account at [http://dev.laptop.org/register laptop.org].
+
* Create a trac account at [https://bugs.sugarlabs.org/register bugs.sugarlabs.org].
  
=== Join the sugar mailing list ===
+
=== Join the sugar-devel mailing list ===
To keep up to date with the recent discussion and developments we recommend joining the [http://lists.laptop.org/listinfo/sugar sugar mailing list]. We might create a separate list for the Bugsquad in the future.
+
To keep up to date with the recent discussion and developments we recommend joining the [http://lists.sugarlabs.org/listinfo/sugar-devel sugar developers mailing list]. We might create a separate list for the Bugsquad in the future.
  
 
=== Read the Stock Responses ===
 
=== Read the Stock Responses ===
The [[BugSquad/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.
+
The [[BugSquad/Triage Guide/Stock Responses]] 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.
 +
 
 +
=== Read the Status Fields ===
 +
The [[BugSquad/Status Fields]] describe the fields you can use to triage the bugs in Trac.
  
 
== Triaging ==
 
== Triaging ==
 
=== Pick a bug ===
 
=== Pick a bug ===
Use the tracker to create a query http://dev.laptop.org/query. This for example creates a query for [http://dev.laptop.org/query?status=assigned&status=new&status=reopened&component=sugar&order=priority&col=id&col=summary&col=status&col=owner&col=type&col=milestone all open sugar bugs]. Choose one you want to triage and read it carefully.  
+
Use the tracker to [https://bugs.sugarlabs.org/query create a query]. This for example creates a query for [https://bugs.sugarlabs.org/query?status=accepted&status=assigned&status=new&status=reopened&component=sugar&order=priority&col=id&col=summary&col=status&col=type&col=priority all open sugar bugs]. Choose one you want to triage and read it carefully.
  
 
=== Find what should be changed===
 
=== Find what should be changed===
Read the [[BugSquad/TriageGuide#Steps_of_Triaging]] to determine what should be changed (if anything) and how.
+
Read the [[BugSquad/Triage Guide#Steps of Triaging]] to determine what should be changed (if anything) and how.
  
 
=== Ask someone to verify your changes ===
 
=== 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 [[BugSquad/Contacts#List_of_Triagers]]. You will find them usually at #sugar on freenode.
+
For the first bugs we encourage you to make the changes in conjunction with a member of the BugSquad team [[BugSquad/Contacts#Squad Members]]. You will find them usually at #sugar on freenode.
  
 
=== Make your changes ===
 
=== Make your changes ===
Line 34: Line 38:
  
 
== Steps of Triaging ==
 
== 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 [[BugSquad/TriageGuide/StockResponses]].
+
These are some notes how to triage the bugs in detail. In all the cases you can find the matching stock response at [[BugSquad/Triage Guide/Stock Responses]].
  
 
=== Verify that the bug is not a duplicate ===
 
=== Verify that the bug is not a duplicate ===
Line 42: Line 46:
 
=== The bug report need some logs ===
 
=== 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 [[BugSquad/GetLogs]].
+
In most of the cases the developer could use some logs to better identify the problem. Instructions on how to take logs are at [[BugSquad/Get Logs]].
  
 
=== If the bug is not described well ===
 
=== 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 [[BugSquad/BugHowto]] or are just inexperienced. Best, is to use one of the stock answers and go to the next bug :)
+
The bug report isn't very useful if the bug isn't described well. Some people do not read the [[BugSquad/Bug Report]], [[olpc:Reporting bugs]], 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 ===
 
=== If the bug is in an obsolete version of the application ===
Line 54: Line 58:
 
=== If the bug is not in Sugar ===
 
=== 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.
+
The bug might not be in sugar and in one of the libraries sugar is using (e.g. 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.
 
  
 
+
=== Severity of the bug ===
[[Category:BugSquad]]
+
Verify that the severity of the bug is set correctly. What you should not try to set is the milestone and the priority of the bugs, this is the duty of the component maintainer. (Please refer to [[BugSquad/Status_Fields#Severity_.28Default.3DUnspecified.29|Severity]] for a definition of the severity fields.)

Latest revision as of 11:27, 1 April 2010

Team Home   ·   Join   ·   Contacts   ·   Resources   ·   FAQ   ·   Roadmap   ·   To Do   ·   Meetings


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 severity of the bug

How to get up to speed

Create a trac account

Join the sugar-devel mailing list

To keep up to date with the recent discussion and developments we recommend joining the sugar developers mailing list. We might create a separate list for the Bugsquad in the future.

Read the Stock Responses

The BugSquad/Triage Guide/Stock Responses 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.

Read the Status Fields

The BugSquad/Status Fields describe the fields you can use to triage the bugs in Trac.

Triaging

Pick a bug

Use the tracker to create a 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 BugSquad/Triage Guide#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 BugSquad team BugSquad/Contacts#Squad Members. 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 BugSquad/Triage Guide/Stock Responses.

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 BugSquad/Get Logs.

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 BugSquad/Bug Report, olpc:Reporting bugs, 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 (e.g. telepathy). Please try to help to get the bug report upstream. Also ensure that both bug reports contain a link to each other.

Severity of the bug

Verify that the severity of the bug is set correctly. What you should not try to set is the milestone and the priority of the bugs, this is the duty of the component maintainer. (Please refer to Severity for a definition of the severity fields.)