Platform UI/Bug Triage
- bug overview (all bugs in Platform UI and IDE, by owners and severities)
- Greasemonkey script
- Component Areas
- Why we changed our bug triage process
The New Bug Triage Process in Detail
This is how our bug triage process looks like:
Incoming bugs are triaged by a full-time committer on a rotating basis. The goal is to have an empty inbox, no bug should stay in the inbox for longer than a few days.
Incoming bugs: To do triage, we use the Greasemonkey script (with buttons for all component areas). Clicking on a button will
- Prefix the bug description with [ComponentArea].
- Set the "QA contact" field to the person responsible for watching bugs in the identified component.
- Assign the bug to email@example.com (separate account from platform-ui-inbox).
As part of the triage, we need to make sure that the bug contains enough information, and that the "severity" is set to a value that makes sense. Enhancement request need to be marked as such, and the same is true for blocker/critical bugs.
When a person is assigned as the QA contact for a bug:
- Double-check that there is enough information in the bug, and that the severity is accurate.
- If it is a blocker or critical bug (e.g. loss of data, crash), it needs to be fixed as soon as possible. If you are not able to fix the bug yourself, assign it to someone else who is.
- If it is a regression, it needs to be fixed during the current development cycle, or potentially in a maintenance stream as well. Schedule the bug accordingly, or assign it to someone else who has time to work on it.
- For all other bugs, try to stay "on top" of the bugs you are watching in the sense that you can produce a rough prioritization of the bugs in a component area. Something like: "if we had the time to fix these ten bugs, our code would be in much better shape".
When a new comment is made on a bug you are watching:
- Respond on the bug if necessary.
- Adjust prioritization if necessary.