Talk:BugSquad/Bug Triage

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?

http://developer.gnome.org/projects/bugsquad/ presents an interesting model.

Return to "BugSquad/Bug Triage" page.