Architecture Council/Bugzilla Best Practices

This page documents some best practices for making use of Bugzilla.

ATTENTION: This is outdated information as Bugzilla is soon not supported anymore by the Eclipse foundation.

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?
    • DAC: We do just that in XSL Tools...see my blog entry on Agile Bugzilla Bug Triaging for more info.
  • Product Backlog

• Milestone Planning
  • Look at prioritized backlog and assign target milestones
  • Items for a Particular Milestone

• Backlog Maintenance
  • At regular times (e.g. after a release), reconsider themes for moving forward, go through the backlog and re-prioritize.
  • This is actually the same as the Product Backlog, but is run again just before the start of the next milestone.
  • A helpful query is a list of Bugs Completed during a Milestone.

The queries that are executed are based on XSL Tools participation in the Web Tools Platform 3.2 release. The same queries can be used unchanged within Mylyn. These queries are actively used by XSL Tools for planning and triaging the bug backlog every milestone and during release planning. Planning varies by projects but using this method of planning just before a Milestone helps keep the team focused and allows for changing priorities.

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)

• Greasemonkey: See Platform UI/Bug Triage