Architecture Council/Bugzilla Best Practices
< Architecture Council
Revision as of 09:51, 14 May 2009 by Mober.at+eclipse.gmail.com (New page: This page documents some best practices for making use of Bugzilla. == Why are there Best Practices? == * We've seen bugzilla users make incorrect assumptions about the meaning of bug sta...)
This page documents some best practices for making use of Bugzilla.
Why are there Best Practices?
- We've seen bugzilla users make incorrect assumptions about the meaning of bug states, which led to miscommunication.
- Particularly the "assigned-to" field was found by the Platform UI team to miscommunicate a bug getting addressed
- Thus the Platform UI team started the Platform UI/Bug Triage effort
- When discussing this at the Architecture Council, we found our exchange very valuable and fruitful and created these Best Practices for anyone to consume.
- Goal: Make it easy for "outsiders" to understand what has happened to a bug.
- Plus, easy and consistent workflows for "insiders".
What is the benefit of adhering to these Practices?
- By getting more consistent use of bugzilla across Eclipse.org, it's easier for everyone to understand the status of a bug and act accordingly.
- easier for committers or contributors working on multiple projects
- easier for users to understand status of their bugs
- Consistent use is better supported by Tooling (Mylyn, Greasemonkey - see below)
What is covered by the Best Practices?
- Consistent Meaning of fields like priority and severity
- Consistent use of fields such as "QA Contact"
- Consistent workflows such as deferring to later
- Consistent queries such as a prioritized backlog
Recommended Meaning of Fields
- Severity: owned by submitter
- Priority: owned by the team
- P1 = Must fix in this release
- P2 = Really want to fix in this release (best effort)
- P3 = Everything else
- P4 = In the queue, not quite closed yet
- P5 = Never going to be fixed by us, but may accept patches
- CLOSED = closed for technical reasons, unlikely to accept patches.
- Target Milestone
- Use ---- with Priorities for deferring work in order to get a single, prioritized backlog.
- Assigning a target milestone means "will be fixed for this milestone".
- Avoid a synthetic "Future" milestone to distinguish inbox from triaged since this tends to create 2 distinct backlogs
- Assigned To
- Should mean real ownership and some chance to get fixed, since this is what end users perceive when seeing a bug assigned to somebody
- Assign to email@example.com in order to indicate that the bug got initial triage. This virtual bugzilla user has to be created by the webmaster.
- We recommend using "QA Contact" instead of Assigned-to when just assigning for further comment rather than for getting fixed
- QA Contact
- The "caretaker" for a bug who guarantees responsiveness to requestors but won't necessarily fix himself
- Separate caretaker per component scales better than single caretaker (project lead) for entire project
- ASSIGNED state
- We don't use this at Eclipse, for us NEW==ASSIGNED. Others (e.g. Mozilla) do use it.
Processes, Queries and Workflows
- Inbox Tracking
- Inbox query = all NEW bugs assigned to firstname.lastname@example.org
- Assign to "email@example.com" and dedicated caretaker as QA contact - #Tools can support this with a single button
- MO: Why don't we just set ASSIGNED to the inbox instead of the "triaged" user?
- Milestone Planning
- Look at prioritized backlog and assign target milestones
- Backlog Maintenance
- At regular times (e.g. after a release), reconsider themes for moving forward, go through the backlog and re-prioritize.
- TBD: Add here what support Mylyn provides
- Greasemonkey: See Platform UI/Bug Triage