Why the bug triage process is a decision forum, not a queue
Most teams treat triage as a queue-grooming chore to minimize. It is really the room where a team decides what 'broken' means for this product. Here is why the discussion is the work, on Mozilla's real severity and priority scales.
The status meeting where the bug triage process quietly decides your product#
Open any guide to the bug triage process and the framing is the same. First it calls triage a queue you groom. Then it tells you to keep the meeting short and move on. However, that framing misses what is actually happening in the room. Because every disposition sets what ships and what waits, the meeting is deciding the product itself.
Consider what a team really does there. It looks at a raw defect and argues about how bad it is. Then it argues about whether that badness is worth acting on now. Meanwhile it decides, out loud, which bugs it will deliberately never fix. Therefore the output is not a tidier list. Instead it is a shared judgment about what "broken" means here.
This is the same kind of judgment call teams defer until it costs them, exactly like the same kind of judgment call teams defer until it's too late in a data model. In practice the queue framing hides the judgment and the queue framing hides the value. So this post refuses it. Instead of grooming the queue faster, we are going to treat the room as the deliverable.
Severity is not priority, and conflating them wrecks your backlog#
Every competent article defines both terms. Few prove they are independent. That proof is the spine of a working bug triage process, so we start there. Because severity and priority answer different questions, one can be high while the other is low. When a backlog collapses the two into one number, it ships the wrong fixes first.
Severity: how badly is it broken#
Severity measures the damage a defect does when it fires. It is a property of the bug, not of your schedule. Mozilla publishes a concrete four-band scale for exactly this. At the top, S1 Catastrophic covers a defect that "causes data loss" and "may impact more than 25% of users." At the bottom, S4 covers "cosmetic issues, low or no impact to users."
Notice what severity does not tell you. It does not say how many people hit the bug this week. It does not say whether the broken screen sits on a path anyone uses. Because severity is about damage-on-contact, you still need a second axis for contact itself. The published definitions live in the Mozilla bug severity guide and the Bugzilla bug-fields reference.
Priority: when do we decide to act#
Priority answers a different question. It asks when, if ever, the team acts on the bug. Mozilla scores this on an ordinal P1 to P5 scale. P1 means "fix in the current release cycle." P3 means "Backlog." Because priority is a scheduling decision, it depends on reach, business surface, and cost, not on severity alone.
Here is the trap. A tidy backlog wants to auto-map severity to priority, so an S1 becomes a P1 by default. However, that mapping assumes the two axes always agree. In practice they routinely diverge. The published priority bands live in the Mozilla bug priority guide, and they are deliberately separate from severity.
The two axes, worked on two real bugs#
Abstract axes convince nobody, so score two concrete bugs. Bug A is a crash that loses unsaved data in the CSV-export path. Bug B is a six-pixel misalignment on the primary signup button. Read the matrix, then watch the two priority columns disagree.
| Dimension | Bug A: CSV-export crash | Bug B: signup-button shift |
|---|---|---|
| Mozilla severity | S1 Catastrophic (causes data loss) | S4 Small / Trivial (cosmetic) |
| User reach | 0.4% of monthly actives, deprecated flow | 100% of new users, on the signup path |
| Workaround | A one-click workaround exists | None; it is the primary button |
| Business surface | An export almost nobody depends on | A measured ~1.8-point conversion drop |
| Formula priority (auto-map) | P1: fix in the current release cycle | P4: buried near the bottom |
| Forum priority (drivers weighed) | P3: Backlog, despite S1 | P1: fix now, despite S4 |
Read the last two rows as the whole argument. A formula sends the S1 crash to P1, so the team ships a fix that helps 0.4% of users first. Meanwhile it buries the S4 shift at P4, so the revenue-path defect rots. In contrast, the forum breaks the mapping. It lands Bug A at P3 and Bug B at P1, because reach and business surface, not severity, decide when you act.
The quadrant, and the two cases where the formula fails#
Those two bugs are not exceptions. They are the two counterintuitive quadrants where any severity-equals-priority formula breaks. So run them yourself. Pick a sample bug, set its severity, and adjust the drivers a real room weighs. Then watch the formula disposition and the forum disposition diverge.
A crash that loses unsaved data in the CSV-export path. S1 by the definition, but the path is touched by well under one percent of monthly actives, on a deprecated flow, with a one-click workaround.
Formula: auto-map severity to priority
P1 Fix now
P1, fix in the current release cycle.
Forum: weigh the drivers
P3 Backlog
P3, a real bug that waits.
The room earns its keepThe formula would rank this higher on severity alone. The forum lowers it because reach is 0%, well under the 5% mark, it is not on a revenue path and a workaround exists. This is the case where auto-mapping spends a sprint on a bug few people hit.
| Path | Priority | Disposition |
|---|---|---|
| Formula (severity to priority) | P1 | Fix now |
| Forum (drivers weighed) | P3 | Backlog |
The severity and priority scales are Mozilla's real published S1 to S4 and P1 to P5 bands. The driver weights are an illustrative teaching model, not a benchmark. Your own thresholds belong to your product, so use the two columns to see when a formula and a forum disagree, then let the room decide.
Steer it to the two failure cases on purpose. First set an S1 with tiny reach and a workaround, and the formula still screams P1 while the forum lowers it. Then set an S4 on a revenue path with full reach, and the formula buries it while the forum lifts it to P1. Because the drivers move the answer, the room, not the number, produces the decision.
The six decisions the room actually makes#
A working bug triage process does not sort bugs into "do" and "do not." It routes each one to a disposition. There are six, and only two of them mean "act soon." The other four are where the room does its most underrated work. The tree below traces every path a triaged bug can take.
Notice that four of the six are not "fix it now." Needs-more-info and duplicate keep the queue honest. Backlog and won't-fix decide what waits and what never ships. Because the interesting judgment lives in those four, a room that only argues about the fix-now bugs is skipping most of its job.
'Won't-fix' is a product decision, not a way to close noise#
Most guides treat won't-fix as a polite way to close a ticket nobody likes. That framing wastes the disposition. Deciding what NOT to fix is a positive competence, because it defines the product's quality bar as much as any feature. When a team declines a bug on purpose, it is stating what this product chooses not to be.
'Needs-more-info' is a real disposition, not a dodge#
Needs-more-info gets abused too. Teams reach for it to make a ticket someone else's problem. However, a real needs-more-info is a deliberate act with an owner and an exit. It names who chases the missing evidence. It states what evidence closes the question.
Because the disposition carries an owner and exit criteria, it does not become a graveyard. Instead it becomes a short, bounded investigation. In contrast, an unowned needs-more-info is just a slower way to ignore a bug. So the rule is simple. Assign it, or do not use it.
What a flat queue hides and a forum reveals#
Here is the value a ticket list structurally cannot deliver. A queue shows bugs as independent rows. A forum lets humans reason across them. Because people compare tickets in the room, they see the shape a queue flattens away. That shape is usually one shared root cause wearing five different symptoms.
The same effect surfaces recurring regressions and coverage gaps. When the room notices the third crash in the same module this quarter, it stops fixing symptoms. Instead it asks why the module keeps breaking. This is the same instinct behind how manual testing surfaces the context automation misses. A queue never prompts that question, because a queue never puts the tickets next to each other.
Who's in the room, and what each seat uniquely sees#
Most roles tables stop at QA, developer, and product. That list is missing the seat that grounds severity in real pain. So this one adds the support and customer-success voice as a first-class row. Each seat answers a question no other seat can.
| Seat | What it uniquely sees | The question it answers |
|---|---|---|
| QA | Reproduction steps, edge cases, the blast radius | How broken is it, exactly? |
| Developer | Root cause, coupling, the real cost to fix | What will fixing it actually take? |
| Product | The roadmap, the quality bar, what ships next | Does this clear the bar to act now? |
| Support / CS | How often users report it, how much it hurts | How bad is this really, to a real person? |
| Software Engineering lead | Capacity, sequencing, and technical risk | When can we act without breaking flow? |
Read the support row as the missing axis. QA can tell you a bug is reproducible. Support can tell you a bug is making people abandon the product. Because the voice of the user grounds "how bad is this really," it stops the room from ranking bugs on severity in a vacuum. Without that seat, the loudest internal voice decides pain by proxy.
The cost of no triage, with the arithmetic#
The cost of skipping triage is usually stated as a vibe. So make it concrete. Without a forum, the loudest voice sets the sprint. In our two-bug example, that means the demo crash and a stack of cosmetic tickets get software engineer-days, while the revenue-path defect gets none.
Show data table
| Item | Days spent |
|---|---|
| Cosmetic tickets (loudest voices) | 6 software engineer-days |
| The demo crash (0.4% of users) | 4 software engineer-days |
| Revenue-path defect | 0 software engineer-days |
The revenue-path defect that A/B data tied to a conversion drop got zero software engineer-days, while ten went to bugs almost no user hits. That gap is the cost of skipping triage. These are illustrative, order-of-magnitude figures, not a benchmark.
Now do the arithmetic the room skipped. Bug B sits on the signup path with a measured 1.8-point conversion drop. Suppose a few thousand people try to sign up each week. Therefore that defect quietly loses dozens of new users weekly, and it compounds for as long as it waits. Because nobody weighed reach against severity, the sprint bought polish and paid in signups.
Bad triage versus good triage, annotated#
Rules on a page convince less than a room you can watch. So here are two rooms handling the same two bugs. Toggle between the bad exchange and the good one. Read each line beside a note naming the move, and the difference between grooming a queue and running a forum becomes obvious.
Bad triage#
The loudest voice sets priority, severity gets auto-mapped, and nobody speaks for the user.
-
PM Product manager
The CEO hit the CSV-export crash on his demo. That is a Sev-1. Put it at the top of the sprint.
What just happened
Loudest voice wins. The priority came from who reported the bug, not from how many users hit it.
-
Dev Developer
Understood, I will take the crash first thing.
What just happened
Severity was auto-mapped to priority. An S1 went straight to "fix now" with no reach check at all.
-
QA QA
There is also a signup button that looks shifted by a few pixels. Cosmetic, so Sev-4.
What just happened
A cosmetic label closed the discussion early. Nobody asked where that button lives or who sees it.
-
PM Product manager
Sev-4, backlog it. Moving on.
What just happened
The revenue-path defect was filed and forgotten. The room optimized for the severity number, not the product.
-
Empty seat Nobody
No support or customer-facing voice was in the room.
What just happened
With no voice of the user, the room could not say how bad either bug actually felt to a real person.
Good triage#
Severity and priority stay separate, the user has a seat, and the room decides what NOT to fix on purpose.
-
PM Product manager
CSV export crashes and loses data. That is S1 by the definition. Before we rank it, what is the reach?
What just happened
Severity is stated, then held apart from priority. The room refuses to auto-map one axis onto the other.
-
Support Support lead
CSV export is under one percent of monthly actives, on the old flow, and there is a one-click workaround.
What just happened
The voice-of-the-user seat grounds severity in real pain. This is the seat most roles tables leave out.
-
PM Product manager
So S1 severity, but priority P3. It stays a real bug. It does not lead the sprint.
What just happened
Severity and priority resolved independently. Choosing NOT to fix it now is itself the decision.
-
QA QA
The signup button is a six-pixel shift, cosmetic, so S4. But it is on the signup path every new user sees, and A/B ties a conversion drop to it.
What just happened
A low-severity bug earns a high priority. The forum surfaces the business surface, not just the defect.
-
PM Product manager
S4 severity, priority P1. We fix the cheap-looking bug first, because it is the expensive one.
What just happened
The counterintuitive call a formula could never make. The discussion, not the ticket, produced the decision.
Notice what separates the two rooms. The bad room maps severity to priority and lets the loudest voice set the agenda. The good room holds the two axes apart, gives the user a seat, and decides what NOT to fix on purpose. Because the good room argues about the decision, it reaches a call the formula could never make.
How to run a bug triage process that respects everyone's time#
None of this argues for a longer meeting. A good bug triage process is fast where it can be and slow only where it must be. The trick is to timebox the calendar time without timeboxing the decision. So prepare hard, then protect the one argument that actually needs the room.
Prepare so the room argues about decisions, not data#
Most triage time is wasted gathering facts that should have arrived with the ticket. So move that work upstream. Pre-assign severity from the definition. Confirm the bug reproduces before the meeting. Attach the usage and support data that grounds reach.
Then merge the obvious duplicates in advance. Because the facts are already on the table, the room spends its minutes on judgment instead of data entry. In practice this is the single biggest lever on triage speed. A prepared queue turns a two-hour meeting into a twenty-minute one.
Timebox the meeting, never the decision#
The SERP advice to "minimize triage" is half right. Cap the calendar time, yes. However, a genuinely contested severity-versus-priority call is the reason the room exists. So when two seats disagree about Bug B, do not gavel it shut to protect the schedule.
When a heavyweight triage forum is the wrong tool#
There is one more honest caveat. A forum decides what to fix and when. It cannot manufacture the capacity to fix it. If every sprint is already underwater, better triage will surface the problem faster, yet the real fix is scope or staffing. The room sharpens the decision. It does not do the work the decision commits you to.
Run well, a bug triage process compounds. It builds a shared model of what "broken" means, and that model outlasts any single bug. The instinct generalizes past bugs, too. It is the same discipline as treating editorial review as a discussion, not a checklist. Treat the discussion as the deliverable, and the queue takes care of itself.