Bug triage

At a glance

Why it matters

An untriaged backlog is a list nobody can trust: real bugs sit beside duplicates and questions, and the loudest report wins. Mozilla's policy does not count a defect as triaged until it carries a severity, and it expects every new bug to be assessed daily and fully triaged within a week (Mozilla). Chromium adds a reason to keep the meeting regular: issues have a half-life, so most triage time belongs on reports opened in the last year, and people re-file the ones that still matter (Chromium).

How do you triage bugs?

• 1. Start with the new reports. Kubernetes labels every new issue needs-triage and reviews those first; Mozilla asks for a daily pass so security bugs are not waiting on the weekly meeting.
• 2. Confirm it is a bug. Reproduce it from the steps. A question, a duplicate or a bug nobody can reproduce is closed with a reason, not parked (Kubernetes).
• 3. Set the severity. Judge impact from the report; Mozilla asks for a comment whenever a severity changes. See severity vs. priority.
• 4. Set the priority. Chromium's test for P1 is whether someone would notice, in a bad way, if the fix missed the current milestone.
• 5. Assign an owner. Chromium's third question is who owns the work; Kubernetes routes each issue to the group that owns the area.
• 6. Ask for what is missing, with a clock. Kubernetes marks the report needs-information and closes it after 20 days without a reply.
• 7. Revisit. Kubernetes follows up at 30 days with no fix in flight and lets a bot mark issues stale at 90; Chromium expects old issues to decay unless someone re-files them.

Triage outcomes

Common mistakes

• Nobody owns it. Mozilla names a triage owner per component. A meeting with no owner skips a week, then a month.
• Priority copied from severity. A severe bug in a screen nobody opens can wait; Chromium ranks P1 by whether someone would notice the miss.
• Needs-information that never closes. A report waiting on the reporter is open work to everyone reading the list. Kubernetes closes it after 20 days.
• Changing severity silently. Mozilla requires a comment explaining the change, so the next triager knows why.
• Treating triage as a one-time cleanup. Chromium calls it a regular process because issues keep arriving and old ones decay.

Frequently asked questions

Who should run bug triage?

A named owner per area. Mozilla's policy gives every component a triage owner who is responsible for triage happening on time, without being the only person who does it; anyone senior enough can triage as bugs arrive, leaving the ones that need discussion for a weekly meeting.

How often should bug triage happen?

Daily for a quick pass and weekly for the full one. Mozilla expects every new bug to be assessed each day so security bugs can be acted on, and fully triaged or under active investigation within one week of being filed.

What is the difference between bug triage and prioritization?

Prioritization is one of the three triage decisions. Chromium frames triage as deciding whether the work is wanted, how important it is and when, and who owns it. A report can be prioritized only after triage has confirmed it is a real bug.

What happens to a bug that cannot be reproduced?

Ask the reporter for what is missing and put a clock on the answer. Kubernetes marks the issue needs-information and closes it after 20 days without a reply; it is reopened the moment someone adds the steps that reach the bug.

Should old bugs be closed during triage?

Often, yes. Chromium observes that issues have a half-life, so most triage time belongs on reports from the last year, and anyone still affected re-files. Kubernetes follows up at 30 days with no fix in flight and marks issues stale at 90.