Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Architecture Council/Bugzilla Best Practices"

(Tools)
Line 80: Line 80:
  
 
* Greasemonkey: See [[Platform UI/Bug Triage]]
 
* Greasemonkey: See [[Platform UI/Bug Triage]]
 +
 +
[[Category:Best_Practices]]

Revision as of 11:29, 14 May 2009

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

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)

Back to the top