Engagement/MDN Durable Team/Processes/Content issue triage process
Contents
MDN Content issue triage process
This page describes the process of triaging issues related to MDN content. Prior to January 2019, content-related issues were submitted in Bugzilla, where there is still a large backlog of open bugs. (See #Helpful Links below for bug lists by priority.)
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. Issues triaged as P1 during a given sprint will be worked on in the following sprint. (If an issue 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
Content triage meetings are usually held on Wednesdays at 16:00 UTC (March-October) or 17:00 UTC (October-March), unless pre-empted and rescheduled due to a higher-priority meeting.
- Go through the new content bugs submitted each week. New issues appear in the “New Issues” column of the ZenHub board.
- You can find (most of) the user-submitted issues by filtering on the string "https://dev", which appears in the title of any issue submitted from the MDN nav bar, if the user didn’t change it.
- Add the “Content” label to help distinguish this issue from dev issues once it is triaged. Also add a label for the topic area, e.g., “Content:HTML”, “Content:CSS”.
- Give each one a priority level, according to the definitions above; use GitHub labels to indicate the priority.
- For P1, P2, or P3 issues, assign an owner. You can also assign an owner to P5 issues, which indicates that the owner is willing to mentor someone in fixing the issue.
- Come up with a size estimate of Small, Medium, or Large. Small fixes (typos or bad links) can be done on the spot; Large issues probably need to be tracked in the content roadmap; Medium-sized issues are appropriate for putting into a sprint as P1 or P2. They should be estimated more precisely before being added to a sprint.
- Move the issue into another column: “Icebox” for P3 and P5, “Not Ready” for P1 and P2.
- After handling the filtered new issues, remove the filter and scan to see if there are any remaining content issues, and triage those.
Tip for staff: If you create issues that you know you’re going to work on, self-triage them (assign, prioritize, and move to another column) so that they don’t take up the group’s time in the triage meeting.
Additional process for the final triage meeting of each sprint
During week that a sprint ends, and planning occurs for the next sprint:
- Look through the P2 bugs list, starting with the oldest ones first, and promote a maximum of 2 * (# of full-time team members) to P1.
- While P2 bugs still exist in Bugzilla, review those first, and migrate to GitHub when they are promoted to P1.
- Close any P2 bugs that are no longer relevant.
- Put P1 bugs (existing or promoted) into the next sprint as user stories. Create an Epic to link all of those issues together (e.g. “Q3S1 content bugs”).
- 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: 4 * (# of full-time team members) --- 2 per writer for the current sprint, and for the upcoming sprint.
