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 | Bug A: CSV-export crashS1 Catastrophic (causes data loss) | Bug B: signup-button shiftS4 Small / Trivial (cosmetic) |
| User reach | Bug A: CSV-export crash0.4% of monthly actives, deprecated flow | Bug B: signup-button shift100% of new users, on the signup path |
| Workaround | Bug A: CSV-export crashA one-click workaround exists | Bug B: signup-button shiftNone; it is the primary button |
| Business surface | Bug A: CSV-export crashAn export almost nobody depends on | Bug B: signup-button shiftA measured ~1.8-point conversion drop |
| Formula priority (auto-map) | Bug A: CSV-export crashP1: fix in the current release cycle | Bug B: signup-button shiftP4: buried near the bottom |
| Forum priority (drivers weighed) | Bug A: CSV-export crashP3: Backlog, despite S1 | Bug B: signup-button shiftP1: 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 fix this first on severity alone. The forum sees low reach and a workaround, so it lowers the priority. This is the case where auto-mapping wastes a sprint on a bug almost nobody hits.
| Path | Priority | Disposition |
|---|---|---|
| Formula (severity to priority) | P1 | Fix now |
| Forum (drivers weighed) | P3 | Backlog |
Bug A: CSV crash. Severity S1 Catastrophic, reach 0 percent, not on a revenue path, workaround exists. Formula disposition Fix now at P1. Forum disposition Backlog at P3. The two disagree. The formula would fix this first on severity alone. The forum sees low reach and a workaround, so it lowers the priority. This is the case where auto-mapping wastes a sprint on a bug almost nobody hits.
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 | What it uniquely seesReproduction steps, edge cases, the blast radius | The question it answersHow broken is it, exactly? |
| Developer | What it uniquely seesRoot cause, coupling, the real cost to fix | The question it answersWhat will fixing it actually take? |
| Product | What it uniquely seesThe roadmap, the quality bar, what ships next | The question it answersDoes this clear the bar to act now? |
| Support / CS | What it uniquely seesHow often users report it, how much it hurts | The question it answersHow bad is this really, to a real person? |
| Software Engineering lead | What it uniquely seesCapacity, sequencing, and technical risk | The question it answersWhen 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.
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.