The most important thing: please use common sense. The guidelines below are likely not exhaustive and do not cover every case.
All Untriaged
DevTools issues, as well as any Unconfirmed
issues that also have the TE-NeedsTriageHelp
label need to be triaged.
Right now there is a Google-internal rotation set-up, with people that do weekly shifts. As Microsoft is in an opposite timezone they have a similar rotation on the same triage queue, but during a different time.
- Google rotation: GMT+1
- MS rotation: GMT-9
Issues in the untriaged queue should receive a meaningful response within a business week. This means that the goal is to make the query mentioned above return zero issues.
- P0: This needs to be urgently done, fire drill alert!
- Most of the time, this seldom needs to be used.
- Critical security exploits that affect stable are a good example for a P0
- DevTools crashing on startup is a good example
- P1: This is important. Let’s aim to get this done next
- Non-critical security fixes will likely be in this category
- Regression bugs will be likely in this category
- Important features that partners are waiting for might be in this category
- P2: We want to do that. The exact time of delivery is not that important though.
- General feature work will likely be in this category
- Non-severe bugs
- P3: This is nice, but not important. We unlikely will do work here.
- Edge-case bugs might fit this category
- Non-important feature requests too
- Close issues as
WontFix
if they don't reproduce (in simple cases) or are requests for features we've already concluded not to pursue. - Close issues as
Archived
that are valid, but it seems unlikely that we will get there anytime soon. - Move issues out of
Platform>DevTools
if they are not DevTools issues (but just reported via the menu item in DevTools), put on theDevTools-Triaged
label and leave theUntriaged
status as is. - Assign regression bugs with bisects to individuals directly and set the status to
Assigned
. - Put proper
Platform>DevTools>XXX
component(s) on the issue and do an initial check-in regarding the priority. - Put one of the following labels on it and set the status to
Available
:Hotlist-DevTools-ProductReview
if it's controversial or clear that consensus needs to be built first.Hotlist-DevTools-BrowserAutomation-Backlog
if it's an issue related to ChromeDriver or puppeteer.Hotlist-DevTools-Debugging-Backlog
if it's a debugging issue.Hotlist-DevTools-DesignAccessibility-Backlog
if it's a design or accessibility issue.Hotlist-DevTools-Performance-Backlog
if the issue is related to our performance tooling (i.e. Performance panel, Lighthouse).Hotlist-DevTools-Backlog
if it's a general DevTools issue that is not specific to one of the core areas.
- Also remember to put the
Needs-UX
label on it, if help from a designer is likely to be required.
Set issues to Available if they don’t need immediate action and nobody right now and in the short-term future (an iteration) needs to work on it.
Issues that are handled by Microsoft have the label “Hotlist-DevTools-MS-Backlog” and “Hotlist-DevTools-MS-CurrentSprint” respectively and can be considered triaged.
If you think they are super urgent, please assign them to [email protected] and cc [email protected] and [email protected].
Don’t be afraid to close issues with WontFix if:
- Bugs that are not reproducible
- After two weeks you did not get a response back from the reporter on a question
- The requested “bug” is the intended behavior Make sure that you bundle the WontFix with a brief comment explaining it e.g. “Setting to WontFix because not reproducible.”
If you think the to-triage issue is not a DevTools issue, please simply set it to a component that you think it should belong to and potentially remove the DevTools component. Make sure that the status is set to Untriaged. Please also ensure that you add the label DevTools-Triaged to the bug to ensure that the bug does not come back to the DevTools component. Feel free to CC people that you think might help with triaging this. This essentially moves the issue out of the DevTools triage queue into another team’s queue.
If you think the to-triage issue or feature request is best handled by Microsoft then add the label "msft-consider" to the issue along with completing the other normal triage steps.
Please set the request to Available and add the label “Hotlist-DevTools-ProductReview”.
The combination of the label “M-” and “Release-Block-” signals that this very bug is blocking a release. Examples:
- M-80, Release-Block-Stable
- This blocks the release of 80 to the Stable channel
- Depends in which release channel 80 is, this might not be an urgent (but still important bug to fix)
- M-81, Release-Block-Beta
- This blocks the release of 81 to the Beta channel
- Depends in which release channel 81 is, this might not be an urgent (but still important bug to fix)
- M-81, Release-Block-Dev
- This blocks the release of 81 to the Dev channel
- This typically means that the bug is urgent and important, as Dev releases are happening every week and are ok to be a little bit buggy.
Managing the backlog is out of scope for the triage rotation. The backlog will be groomed continuously by hablich@ for now. The SLA is that there should be a maximum of 50 issues in there.
Issues in ProductReview
will continuously be handled by hablich@ to unblock items in there. SLA is max 10 issues.