TestEngineering/Performance/Triage Process

From MozillaWiki
< TestEngineering‎ | Performance
Revision as of 09:14, 1 October 2019 by Davehunt (talk | contribs) (Created page with "* When triaging, review new, P1, intermittent, and mentored bugs * Set a priority as early as possible (gut feeling is okay) * Triage search is based on new bugs since last tr...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
  • When triaging, review new, P1, intermittent, and mentored bugs
  • Set a priority as early as possible (gut feeling is okay)
  • Triage search is based on new bugs since last triage, plus bugs without priority
  • Always make sure there are enough P1s to work on
  • P1 means someone should be assigned and working on the bug
  • If a P1 is blocked, make sure the blocker has an appropriate priority and assignee
  • P2 means we can pick up this work when P1 work is blocked or complete
  • P3 bugs are backlog and are good candidates for community to work on
  • We can plan P3 sprints where we take a break from higher priority work
  • Consider marking P3 bugs as mentored good first bugs
  • Do not use P4
  • P5 means we do not intend to fix but will accept a patch