Bugmasters/Projects/Folk Knowledge/Priority Field

From MozillaWiki
< Bugmasters‎ | Projects‎ | Folk Knowledge
Revision as of 15:46, 4 April 2016 by Gfritzsche (talk | contribs) (Adding measurements client team workflow)
Jump to navigation Jump to search

Mobile team (Fennec, iOS) essentially don't use Bugzilla's priority field. Mobile team uses tracking-fennec flags to track releases; we assign individuals to track tickets; and we switch the status to ASSIGNED to mean "work is happening".

Some Firefox front-end teams use Bugzilla's "Rank" field to prioritize bugs from 1–60.

Priority-based triage

Some teams us the priority field to sort bugs.

  • P1 - Fix immediately
  • P2 - Needs to be fixed, but not urgent
  • P3 - Would like to fix, but waiting for resources (optional)
  • P4 - Not used or the same as P5.
  • P5 - A real issue, but no intent to fix. (patches usually welcome)

Bugs without the priority field set are untriaged. Bugs that are not real issues are generally closed. The Media Playback team generally closes bugs that have gone several weeks without progress toward determining an actionable cause; most teams leave bugs open if the cause has not been determined.

The following teams use this workflow:

Priority-based iterations

Used by the measurements client team:

  • P1 - fix this in the current iteration
  • P2 - would like to fix in this iteration if possible
  • P3 - work-scope for this quarter
  • P4 - longer-term work (year or so)
  • P5 - valid bug but no intent to fix, patches welcome