Bulk bug reprioritization and SLOs
Rick Byers
Tl;dr: P1 bugs created prior to 2026 will be bulk moved to P2 to better align with our stated priority definitions and SLOs.
Hi,
As Chrome, and some other Chromium embedders, prepare to double our release cadence, the Chrome technical leadership team (ATLs) believe we need to be increasing our rigor around bug handling. We have now published Chrome's longstanding internal definitions for P0 and P1 bugs and our goals (SLOs) for how they are handled. In particular:
P0: emergency, expected to be assigned within a day, updated every day and fixed within a week
P1: urgent, expected to be assigned within a week, updated weekly and closed within four weeks.
P2: active but non-urgent work. No SLO
P3: currently inactive, want to do later
P4: currently inactive, no plans to do
While Chromium contributors are generally good at treating urgent issues with the priority they deserve (thank you!), we do face a challenge with the signal of what's important drowning in the noise of old bugs marked urgent (P0 and P1), which are not, in fact, currently urgent. If you have an important bug that does not need to be updated weekly and fixed within four weeks, by definition it is not P1 but probably P2. Note that this applies only to bugs (including vulnerabilities). Features and tasks are not tracked / monitored in this way.
To help make our bug database better reflect our priority definitions we are taking the following steps:
Manually reviewing all P0 issues and reprioritizing or escalating. Please review P0s assigned to you or in components you manage.
Bulk moving all P1 bugs created prior to 2026 to P2. In doing this we will apply the Chrome-Debt-Management-Transfer hotlist so that you can review (and potentially undo) changes we made after the fact.
Rolling out a set of tools and processes to help flag out-of-SLO bugs for escalation. Unfortunately, due to technical limitations, the tools we have now are Google internal. If you are responsible for triaging a component and are not a Google employee but would value access to some tooling for this, please email me privately to discuss options.
Thanks,
Rick - on behalf of Chrome ATLs
FAQ:
Q) Why not just declare "bug bankruptcy" and mark old bugs as WontFix
A) Because we don't want to lose the information that separates "not currently a priority for owners" from "not something we'd want". Especially with programs like the SOCBB bug bounty, we want to be clear on what are known defects we'd welcome fixes for vs. things which the project does not think should be changed.
Q) But I have too many P1s bugs to be writing weekly status updates on them all!
A) The topic of how to prioritize and load-balance urgent work is complex. But in general all we're asking for here is to be honest in how bugs assigned to you (or in components you triage) are labeled. If you're not likely to actually be able to give weekly status updates or fix an issue in four weeks, we're just asking that you not lie to others by marking them P1. Instead call them P2 to set accurate expectations.
Q) Doesn't this mean we'll ship more regressions to stable?
A) No. In general regressions that have not yet reached stable should be marked P1 AND ReleaseBlock. The default handling for such issues is to bisect their cause and revert the offending CL. None of what we're doing here will impact ReleaseBlock labels and we have tooling to help us review all bugs where ReleaseBlock is added but later removed.
Q) What bugs does this apply to?
A) For now we're focusing on all bugs (type:(bug | customer_issue | vulnerability | privacy_issue)) in the public chromium tracker (issue.chromium.org). Bulk updates will apply only to 'bug' and 'customer_issue', not 'vulnerability' and 'privacy_issue' (which have their own tracking). We encourage Chromium-associated projects with bug trackers elsewhere to follow a similar model, but are not actively coordinating such efforts at the moment.
Q) But I have P0 features that will take months to deliver!
A) Yes type:feature has different prioritization conventions that's independent from our focus on product quality here. New (not-yet-shipped) P0 features should generally not be blocked on P0/P1 bugs but can be blocked on P0/P1 features, tasks, projects, and on P2+ bugs.
Q) What will happen to me if I don't adhere to SLOs for bugs assigned to me?
A) You might get one of the Chrome leads asking what's wrong. We expect that some bugs will still fall out of SLO, but that reviewing that set will generally be useful for leads to get a sense of where we're falling behind in important areas.
Q) Are more bulk transfers planned?
A) Not immediately but we may continue to iterate on the details (eg. exactly which stale P1s we move to P2). We'll follow the same pattern of applying a hotlist so that such moved bugs are easily findable and follow up here with any important changes in details.
Q) What about all the other ways our bugs don't match the priority definition? Eg. many P2s are actually inactive.
A) Yes we're aware. In general we've probably overused P2 and under-used P3/P4 labels relative to our stated definitions. This misalignment is something we'd like to address eventually, but we're currently leaving this to component owners to decide if and how to handle.