Bugmasters/Projects/Folk Knowledge/Priority Field: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Media Playback priorities)
(Mention Rank field. Also link to dbaron's blog post about Bugzilla priorities.)
Line 1: Line 1:
Mobile team (Fennec, iOS) essentially don't use Bugzilla's priority field.  Mobile team uses <tt>tracking-fennec</tt> flags to track releases; we assign individuals to track tickets; and we switch the status to ASSIGNED to mean "work is happening".
Mobile team (Fennec, iOS) essentially don't use Bugzilla's priority field.  Mobile team uses <tt>tracking-fennec</tt> 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 ==
== Priority-based triage ==
Line 17: Line 19:
* Media Playback (Only P1, P2, and P5)
* Media Playback (Only P1, P2, and P5)
* Awesome Search Team
* Awesome Search Team
* [http://dbaron.org/log/20090120-bug-priorities dbaron's 2009 blog post about Bugzilla priorities]

Revision as of 22:23, 1 April 2016

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 or which go several weeks without progress toward determining an actionable cause are generally closed.

The following teams use this workflow: