Engagement/MDN Durable Team/Processes/Content issue triage process

MDN Content issue triage process

This page describes the process of triaging issues related to MDN content. Currently, these are submitted in Bugzilla (and are therefore referred to as "bugs" regardless of the type of issue). Work is under way to migrate the issue-handling process for MDN content issues to GitHub, where such issues will be submitted in the mdn/sprints repository, which is where the MDN staff team manages its work.

Definitions of bug priority levels

• P0 — So urgent that it needs fixing right now, ahead of anything else (e.g., security-critical bug, or offensive content to be taken down), or so trivial that we should just get it out of the way (e.g., the entire fix is a typo or fixing a broken link). We don’t set these priorities; we just do them.
• P1 — Being worked on in the current sprint, or will be started in the next sprint. Bugs triaged during a given sprint will be worked on in the following sprint. (If a bug must be worked on in the sprint during which it comes in, it is a P0.)
• P2 — Candidates for being moved to P1. Urgent enough to fix in the next few months. Re-evaluate frequently, to keep the P1 stream from running dry.
• P3 — Staff will work on this at some point, but it is not currently seen as urgent.
• P4 — Not used.
• P5 — A valid, but low-priority issue. We'll accept community edits, but the staff team will not fix this.

Process for triage meetings

1. Go through the new content bugs submitted each week.
   • In GitHub, new issues appear in the “New” column of the ZenHub board. It may be necessary to separate content issues from development issues; however, the dev issue process remains in Bugzilla, so dev issues will be minimal and will be submitted only by staff.
2. Give each one a priority level, according to the definitions above.
   • In GitHub, use labels to indicate the priority.
3. Give each bug triaged a points estimate, in the same way as other sprint tasks, to make it easier to fit the bug into a sprint later on.

Additional process for the final triage meeting of each sprint

During week that a sprint ends, and planning occurs for the next sprint:

1. Look through the P2 bugs list, starting with the oldest ones first, and promote a maximum of 12 to P1.
   • While P2 bugs still exist in Bugzilla, review those first, and migrate to GitHub when they are promoted to P1.
2. Close any P2 bugs that are no longer relevant.
3. Put P1 bugs (existing or promoted) into the next sprint as user stories, 2 per writer (and 2 for Chris). Create an Epic to link all of those issues together (e.g. “Q3S1 content bugs”).
4. If you ever run out of P2s, go onto P3s, etc., being sure to review both Bugzilla and GitHub for potential issues to promote.

Maximum number of P1s allowed: 20.