A weekly triage meeting that runs longer and decides less is doing work that belongs before it. Reproducing a ticket, arguing whether it is a bug, and hunting for the browser it happened in are all preparation, and a room full of engineers is the most expensive place to do any of them. Triage is one decision per ticket.
What the room spends its hour on
Sit in the meeting with a stopwatch and sort what happens by kind. Most of it is one of five activities, and only two of them need the room.
| What happens in the room | What it is | Where it belongs |
|---|---|---|
| “Can anyone reproduce this?” followed by somebody trying, live | Reproduction | Before the meeting, by whoever queues the ticket, from the evidence on it |
| “Is this even a bug, or is that how it works?” | Classification | Product, in writing, before the ticket is queued |
| “How bad is it?” argued from memory of the report | Severity | A written scale applied by whoever queues the ticket |
| “Who takes it?” | Assignment | The room |
| “This sprint or next?” | Priority | The room |
The first three rows are where the hour goes, and none of them is a decision the room is uniquely able to make. Reproduction needs a browser and the conditions the bug happened in, which a group discussion supplies worse than a ticket does. Classification needs somebody who owns the product’s intended behaviour, who may or may not be in the room and in any case should not be deciding under time pressure with six engineers watching. Severity needs a scale and the evidence, and a scale applied in the room is a scale re-argued every week.
The last two rows are the meeting. Assignment and priority need the people who will do the work and the person who owns the sprint, at the same time, looking at the same list. That is a short meeting when it is only that.
Every ticket leaves with exactly one of three outcomes
Bug triage is a sorting decision, and a sorting decision has a fixed set of bins. Three are enough, and the discipline is that every ticket goes into one of them before the next ticket is opened.
Accepted: the ticket is a reproducible defect with a severity already set, and the room gives it a priority and an owner. It moves into the working life cycle and nobody discusses it again until it comes back for verification.
Rejected: the ticket is a duplicate, a request rather than a defect, or a behaviour product has confirmed as intended. The reason is written on the ticket in a sentence a reporter could read, because “closed” with no reason is how the same report gets filed again next month.
Sent back: the ticket lacks something the decision needs, and the ticket names what. Never “needs more info”, which is a rejection wearing a softer label, but “which browser, and what did the screen show after the click”. The ticket returns to the reporter, or to whoever queued it, and it does not come back to the room until the gap is filled.
The third bin is the one teams skip, and its absence is why the meeting reproduces bugs live. A ticket with no send-back option has to be either accepted on faith or rejected on suspicion, so the room does the reporter’s work instead, on the clock, with everybody watching.
A ticket arrives ready or it does not arrive
If sending back is allowed, the next question is what “ready” means, and it needs to be written where the reporter can see it before they file. The minimum is short: what was expected, what happened, the steps taken, and the conditions, meaning the browser and its version, the viewport, the route, and what the console and the network were doing in the seconds before.
The conditions are the half the reporter cannot supply. A tester on the team can be trained to include them; a client or a support colleague forwarding a customer’s complaint cannot, and a readiness rule they cannot meet will be waived on the first busy week. The way past that is to have the page under test supply the conditions itself. With evidence capture a report filed from the page carries the browser and viewport, the page path, and the console and network activity from before the click, so the readiness rule is met by the page rather than waived for the reporter, and the room is left with nothing to reproduce live.
Severity belongs in the same pre-meeting step. A written scale of severity levels, applied by whoever queues the ticket, means the room inherits a severity and argues only if it disagrees. Disagreement is rare when the scale is specific, and when it is common the fix is to rewrite the scale, once, rather than to relitigate it weekly.
The meeting that is left
Strip out reproduction, classification and severity and what remains is a list of tickets with evidence and a severity, each needing an owner and a slot. That is a meeting that can be run standing up, and often the point of describing it is to notice that it need not be a meeting at all: the lead can assign and prioritise asynchronously, on the board, and gather people only for the tickets where the slot is contested.
What has to stay synchronous is the contested slot. Two engineers who both want the same bug, or neither of whom wants it, and a sprint that cannot hold both of the bugs two customers have been promised: those are conversations, and they are short when they are the only thing on the agenda. The queue itself lives on the board, in the column reports arrive in, and a triage decision is a move out of that column carrying the severity and the priority the room settled.
A ticket with evidence but no reproduction is accepted
One class of ticket breaks the three bins, and the process has to say what happens to it rather than letting it circle. An intermittent defect, of which the heisenbug that vanishes under a debugger is the extreme case, carries evidence, a console error, a failed request, a replay showing the click, and still cannot be reproduced on demand by anybody. Sending it back asks the reporter for something they already gave. Rejecting it discards evidence of a real failure. Accepting it hands an engineer a ticket with no known starting point.
Some fraction of real defects will only ever be seen in the evidence and never on an engineer’s machine, no tool changes that, and the send-back loop has to have an exit for them. The workable rule is that a ticket with evidence but no reproduction is accepted at the severity the evidence shows, with a bounded investigation attached: an engineer reads the evidence, forms a hypothesis, adds a guard or a log, and the ticket waits for the next occurrence rather than for a reproduction. That is a decision, made once, with an owner, which is what triage was always supposed to be.
