This document outlines how the Chrome 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.
*** promo If you are not on the Chrome Mac Team and want to send a bug to them for triage, please add the Mac-TriageQueue hotlist and allow the Mac triage rotation to assign them.
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 on Mondays by the Mac team as a group.
*** promo All necessary hotlists and saved searches are bundled into the Mac triage bookmark group.
During the week, the primary works from the “Mac triage candidates” saved search. The primary has two main goals:
To ensure that each bug is looked at.
To add bugs that should be seen by the whole team to the Mac-TriageQueue hotlist
As of March 2024, the candidates saved search is greatly inflated by bugs that became unassigned as a part of the Buganizer transition. Due to this, it's not expected that the primary gets through the whole search. Instead, the primary should focus on bugs filed or updated within the past one or two weeks. We expect that we will shrink the queue to a reasonable size within the next few months
During the triage meeting, the team as a whole looks at the triage queue. At the end of the triage meeting, it's expected that every bug in the queue will be in one of the following states:
First-phase triage is, first and foremost, a filter. Not every bug that is filed on a Mac, or even exclusively occurs on the Mac is best handled by the Mac team. If the bug 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‘s component. Our triage filter is coarse enough that this isn’t always sufficient to get the bug out of our queue; in these cases the bug should also be bypassed
If the primary determines that the Mac team is responsible for this bug (or it isn't immediately apparent), the next step is to ensure the symptoms and reproduction steps of the bug are well-understood.
If the bug is clearly of interest to the wider team, or seems like it could use input from domain experts, it makes sense to put it directly into the triage queue at this point.
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. Useful hotlists at this step are:
The latter two hotlists 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.
Once the bug is sufficiently understood, it should end up in one of the following states:
We wait 28 days for user feedback on Needs-Feedback bugs; after 28 days without a response to a question we move bugs to WontFix.
Some useful debugging questions here:
Second-phase triage is for “complicated” bugs that benefit from the full team's perspective. In principle, anything with clear and unambiguous next steps should not make it to the triage queue.
The primary “drives” by presenting the triage queue in Chromium's issue tracker, and the team goes through each bug one by one, taking action by consensus. If the queue is exhausted, the team proceeds to look at the triage candidate queue.
Some bugs require more feedback from either the reporter, or cc'ed members of other teams; in that case we may choose to keep it in the queue for a week or two for monitoring. Otherwise, the set of outcomes is similar to first-phase triage:
