1# Mac Team Triage Process 2 3This document outlines how the Mac team triages bugs. Triage is the process of 4converting raw bug reports filed by developers or users into actionable, 5prioritized tasks assigned to engineers. 6 7The Mac bug triage process is split into two phases. First-phase triage is done 8daily in week-long shifts by a single person. Second-phase triage is done in a 9standing meeting at the end of the work week by three people. Each week, these 10three people are: 11 12* The primary oncall, who does both phases 13* The secondary oncall, who will become primary in the following week, and who 14 is in the triage meeting so they'll be aware of ongoing themes 15* The TL, who is currently ellyjones@ 16 17A key tool of the triage process is the "Mac" label (*not* the same as the Mac 18OS tag), which makes bugs visible to the triaging step of the process. This 19process deliberately doesn't look at bugs with OS=Mac status:Untriaged, because 20maintaining the list of components that can be ignored during that triage step 21is untenable. 22 23## Quick Reference 24 251. During the week, turn [OS=Mac status:Unconfirmed][unconfirmed] bugs into 26 [label:Mac status:Untriaged][untriaged-m] bugs. 272. During the triage meeting, turn [label:Mac status:Untriaged][untriaged-m] 28 and [unlabelled Mac bugs][untriaged-c] into any of: 29 * [label:Mac status:Available][available] 30 * [label:Mac status:Assigned][assigned] 31 * Untriaged in any component that does triage, without the Mac label 32 * Assigned 33 34## First-phase triage 35 36First-phase triage is the step which ensures the symptoms and reproduction steps 37of a bug are well-understood. This phase operates on [OS=Mac 38status:Unconfirmed][unconfirmed] bugs, and moves these bugs to: 39 40* Needs-Feedback, if awaiting a response from the user 41* Untriaged bugs with the Mac label, if they are valid bug reports with working 42 repro steps or a crash stack 43* WontFix, if they are invalid bug reports or working as intended 44* Duplicate, if they are identical to an existing bug 45 46The main work of this phase is iterating with the bug reporter to get crash IDs, 47repro steps, traces, and other data we might need to nail down the bug. If the 48bugs is obviously very domain-specific (eg: "this advanced CSS feature is 49behaving strangely", or "my printer is printing everything upside down"), feel 50free to skip this iteration step and send the bug straight to the involved team 51or people. Useful tags at this step are: 52 53* Needs-Feedback, which marks the bug as waiting for a response from the 54 reporter 55* Needs-TestConfirmation, which requests that Test Engineering attempt the bug's 56 repro steps 57* Needs-Bisect, which requests that Test Engineering bisect the bug down to a 58 first bad release 59 60The latter two tags work much better when there are reliable repro steps for a 61bug, so endeavour to get those first - TE time is precious and we should make 62good use of it. 63 64We wait **30 days** for user feedback on Needs-Feedback bugs; after 30 days 65without a response to a question we move bugs to WontFix. 66 67Some useful debugging questions here: 68 69* What are your exact OS version and Chrome version? 70* Does it happen all the time? 71* Does it happen in Incognito? (this checks for bad cached data, cookies, etc) 72* Does it happen with extensions disabled? 73* Does it happen in a new profile? 74* Does it happen in a new user-data-dir? 75* If it's a web bug, is there a reduced test case? We generally can't act on "my 76 website is broken" type issues 77* Can you attach a screenshot/screen recording of what you mean? 78* Can you paste the crash IDs from chrome://crashes? 79* Can you get a sample of the misbehaving process with Activity Monitor? 80* Can you upload a trace from chrome://tracing? 81* Can you paste the contents of chrome://gpu? 82* Can you paste the contents of chrome://version? 83 84## Second-phase triage 85 86Second-phase triage is the step which either moves a bug to another team's 87triage queue, or assigns a priority, component, and (possibly) owner to a bug. 88This phase operates on [label:Mac status:Untriaged][untriaged-m] and [untagged 89status:Untriaged][untriaged-c] bugs. The first part of this phase is deciding 90whether a bug should be worked on by the Mac team. If so, the bug moves to one 91of: 92 93* Pri=2,3 in label:Mac, Assigned with an owner if one is obvious, Available 94 otherwise 95* Pri=0,1 in label:Mac, Assigned with an owner 96 97Otherwise, the bug loses label:Mac and moves to one of: 98 99* Untriaged in a different component 100* Assigned with an owner 101* WontFix 102* Duplicate 103 104Here are some rules of thumb for how to move bugs from label:Mac 105status:Untriaged to another component: 106 107* Is the bug Mac-only, or does it affect other platforms? If it affects other 108 platforms as well, it's probably out of scope for us and should go into 109 another component. 110* Is the bug probably in Blink? If so, it should be handled by the Blink 111 team's Mac folks; move to component `Blink`. 112* Is the bug localized to a specific feature, like the omnibox or the autofill 113 system? If so, it should be handled by that team; tag it with their component 114 for triage. 115* Is the bug a Views bug, even if it's Mac-specific? If so, it should be handled 116 by the Views team; mark it as `Internals>Views`. 117 118If the bug is Mac-specific and in scope for the Mac team, try to: 119 120* Assign it to a sublabel of `Mac` 121* Assign it a priority: 122 * Pri=0 means "this is an emergency, work on it immediately" 123 * Pri=1 means "we should not ship a stable release with this bug if we can 124 help it" 125 * Pri=2 means "we should probably fix this" - this is the default bug 126 priority 127 * Pri=3 means "it would be nice if we fixed this some day" 128* Maybe assign it an owner if needed - Pri=0 or 1 need one, Pri=2 or 3 can have 129 one if the owner is obvious but don't need one: 130 * `Mac-Accessibility`: ellyjones@ or lgrey@ 131 * `Mac-Enterprise`: avi@ 132 * `Mac-Graphics`: ccameron@ 133 * `Mac-Infra`: ellyjones@ 134 * `Mac-Performance`: lgrey@ 135 * `Mac-PlatformIntegration`: ellyjones@ 136 * `Mac-Polish`: ellyjones@ 137 * `Mac-TechDebt`: ellyjones@ 138 * `Mac-UI`: anyone 139 140**Caveat lector**: If you are outside the Mac team please do not use this 141assignment map - just mark bugs as Untriaged with label `Mac` and allow the Mac 142triage rotation to assign them. People go on vacation and such :) 143 144These are the other components we put bugs into that we assume have their own 145triage processes: 146* Admin 147* Blink 148* Infra 149* Internals>Headless, Network, Plugins, Printing, Skia, Views 150* IO>Bluetooth, USB 151* Platform 152* Services>Chromoting 153* Test>Telemetry 154* UI>Browser>WebUI 155 156[unconfirmed]: https://bugs.chromium.org/p/chromium/issues/list?q=OS%3DMac%20status%3AUnconfirmed%20-component%3ABlink%2CEnterprise%2CInternals%3ENetwork%2CPlatform%3EDevtools%2CServices%3ESyncs%2CUI%3EBrowser%3EPasswords&can=2 157[untriaged-m]: https://bugs.chromium.org/p/chromium/issues/list?q=has%3AMac%20status%3AUntriaged&can=2 158[untriaged-c]: https://bugs.chromium.org/p/chromium/issues/list?q=OS%3DMac%20-OS%3DWindows%2CLinux%2CChrome%2CAndroid%2CiOS%20status%3AUntriaged%20-component%3AAdmin%2CBlink%2CInfra%2CInternals%3EHeadless%2CInternals%3ENetwork%2CInternals%3EPlugins%3EPDF%2CInternals%3EPrinting%2CInternals%3ESkia%2CInternals%3EUpdater%2CInternals%3EViews%2CIO%3EBluetooth%2CIO%3EUSB%2CPlatform%2CServices%3EChromoting%2CTest%3ETelemetry%2CUI%3EBrowser%3EWebUI&can=2 159[available]: https://bugs.chromium.org/p/chromium/issues/list?q=has%3AMac%20status%3AAvailable&can=2 160[assigned]: https://bugs.chromium.org/p/chromium/issues/list?q=has%3AMac%20status%3AAssigned&can=2 161