Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Architecture Council/Bugzilla Best Practices"
(→Tools) |
|||
Line 73: | Line 73: | ||
== Tools == | == Tools == | ||
* Mylyn | * Mylyn | ||
− | ** ''TBD'' Add here what support Mylyn provides | + | ** Supports a single backlog filtered as follows: |
+ | *** 1. '''Own bugs''' (assigned-to-me) | ||
+ | *** 2. '''Caretaker''' (where I am QA contact) | ||
+ | *** 3. '''Backlog''' prioritized list with target milestone = "---" | ||
+ | ** ''TBD'' Add more here what support Mylyn provides (buttons etc) | ||
* Greasemonkey: See [[Platform UI/Bug Triage]] | * Greasemonkey: See [[Platform UI/Bug Triage]] |
Revision as of 11:00, 14 May 2009
This page documents some best practices for making use of Bugzilla.
Contents
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
Best Practices
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 your-component-triaged@eclipse.org 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.
- Keywords
- helpwanted
Processes, Queries and Workflows
- Inbox Tracking
- Inbox query = all NEW bugs assigned to your-component.inbox@eclipse.org
- Assign to "your-component.triaged@eclipse.org" 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?
- TBD Example Query from XSL Tools:
- Milestone Planning
- Look at prioritized backlog and assign target milestones
- TBD Example Query from XSL Tools:
- Backlog Maintenance
- At regular times (e.g. after a release), reconsider themes for moving forward, go through the backlog and re-prioritize.
- TBD Example Query from XSL Tools:
Tools
- Mylyn
- Supports a single backlog filtered as follows:
- 1. Own bugs (assigned-to-me)
- 2. Caretaker (where I am QA contact)
- 3. Backlog prioritized list with target milestone = "---"
- TBD Add more here what support Mylyn provides (buttons etc)
- Supports a single backlog filtered as follows:
- Greasemonkey: See Platform UI/Bug Triage