Difference between revisions of "Talk:BugSquad/Bug Triage"

From Sugar Labs
Jump to navigation Jump to search
(New page: Certainly areas of potential improvement is in regard to defining appropriate tags for Milestones and Components, and coming up with a list of keywords that we can agree to the meaning of....)
 
Line 2: Line 2:
  
 
==Questions==
 
==Questions==
 +
 +
===Milestones/Versions===
 
Would it make sense to have a Sugar '''milestone''' (e.g., Sugar 0.82) that is distinct from the OLPC milestones? Or would it make more sense to have a Sugar '''version''' that maps to an OLPC milestone?
 
Would it make sense to have a Sugar '''milestone''' (e.g., Sugar 0.82) that is distinct from the OLPC milestones? Or would it make more sense to have a Sugar '''version''' that maps to an OLPC milestone?
  
 +
===Keywords/Components===
 
Would it make sense to consistently add '''keywords''' that map to the Sugar modules or should these be '''components'''?
 
Would it make sense to consistently add '''keywords''' that map to the Sugar modules or should these be '''components'''?
 
* sugar
 
* sugar
Line 16: Line 19:
 
** ''et alia''
 
** ''et alia''
  
 +
===Priorities===
 
The assignment of '''priorities''' is the difficult one. We need to come up with definitions and a process. A first pass:
 
The assignment of '''priorities''' is the difficult one. We need to come up with definitions and a process. A first pass:
  
Line 26: Line 30:
 
:Low: odds and ends
 
:Low: odds and ends
  
 +
===Verify===
 
Would it be possible to assign teams to each ticket, where we identify up front someone who agrees to '''verify''' a ticket, and someone who agrees to test a fix? Maybe we can accumulate a list of volunteers who'd be willing to be assigned in a work-wheel-like system?
 
Would it be possible to assign teams to each ticket, where we identify up front someone who agrees to '''verify''' a ticket, and someone who agrees to test a fix? Maybe we can accumulate a list of volunteers who'd be willing to be assigned in a work-wheel-like system?

Revision as of 18:00, 13 May 2008

Certainly areas of potential improvement is in regard to defining appropriate tags for Milestones and Components, and coming up with a list of keywords that we can agree to the meaning of.

Questions

Milestones/Versions

Would it make sense to have a Sugar milestone (e.g., Sugar 0.82) that is distinct from the OLPC milestones? Or would it make more sense to have a Sugar version that maps to an OLPC milestone?

Keywords/Components

Would it make sense to consistently add keywords that map to the Sugar modules or should these be components?

  • sugar
  • sugar-base
  • sugar-datastore
  • sugar-presence-service
  • sugar-toolkit
  • sugar-artwork
  • sugar-activity
    • journal-activity
    • chat-activity
    • et alia

Priorities

The assignment of priorities is the difficult one. We need to come up with definitions and a process. A first pass:

Blocker: catastrophic failure—Sugar will not run or user experience severely impaired (new features would rarely, if ever, fall into this category)
High: important to Sugar user experience—either in terms of performance or usability (these would typically be coupled with the "task" ticket type)
Med: enhancements to non-core features (or enhancements that impact individual activities)
Low: odds and ends

Verify

Would it be possible to assign teams to each ticket, where we identify up front someone who agrees to verify a ticket, and someone who agrees to test a fix? Maybe we can accumulate a list of volunteers who'd be willing to be assigned in a work-wheel-like system?