This document outlines how the Mac team triages bugs. Triage is the process of converting raw bug reports filed by developers or users into actionable, prioritized tasks assigned to engineers.
The Mac bug triage process is split into two phases. First-phase triage is done daily in week-long shifts by a single person. Second-phase triage is done in a standing meeting at the end of the work week by three people. Each week, these three people are:
A key tool of the triage process is the «Mac» label (not the same as the Mac OS tag), which makes bugs visible to the triaging step of the process. This process deliberately doesn’t look at bugs with OS=Mac status:Untriaged, because maintaining the list of components that can be ignored during that triage step is untenable.
First-phase triage is the step which ensures the symptoms and reproduction steps of a bug are well-understood. This phase operates on OS=Mac status:Unconfirmed bugs, and moves these bugs to:
The main work of this phase is iterating with the bug reporter to get crash IDs, repro steps, traces, and other data we might need to nail down the bug. If the bugs is obviously very domain-specific (eg: «this advanced CSS feature is behaving strangely», or «my printer is printing everything upside down»), feel free to skip this iteration step and send the bug straight to the involved team or people. Useful tags at this step are:
The latter two tags work much better when there are reliable repro steps for a bug, so endeavour to get those first - TE time is precious and we should make good use of it.
We wait 30 days for user feedback on Needs-Feedback bugs; after 30 days without a response to a question we move bugs to WontFix.
Some useful debugging questions here:
Second-phase triage is the step which either moves a bug to another team’s triage queue, or assigns a priority, component, and (possibly) owner to a bug. This phase operates on label:Mac status:Untriaged and untagged status:Untriaged bugs. The first part of this phase is deciding whether a bug should be worked on by the Mac team. If so, the bug moves to one of:
Otherwise, the bug loses label:Mac and moves to one of:
Since our component filter is not comprehensive, sometimes an Untriaged bug
that is being investigated by the appropriate team remains in the Mac queue.
In those cases, labeling the bug Hotlist-MacTriageBypass
will remove it from
the queue.
Here are some rules of thumb for how to move bugs from label:Mac status:Untriaged to another component:
Blink
.Internals>Views
.If the bug is Mac-specific and in scope for the Mac team, try to:
Mac
Mac-Accessibility
: ellyjones@ or lgrey@Mac-Enterprise
: avi@Mac-Graphics
: ccameron@Mac-Infra
: ellyjones@Mac-Performance
: lgrey@Mac-PlatformIntegration
: ellyjones@Mac-Polish
: ellyjones@Mac-TechDebt
: ellyjones@Mac-UI
: anyoneCaveat lector: If you are outside the Mac team please do not use this
assignment map - just mark bugs as Untriaged with label Mac
and allow the Mac
triage rotation to assign them. People go on vacation and such :)
These are the other components we put bugs into that we assume have their own triage processes: