Triage is deciding what happens to an issue, quickly, without doing the work. It is not prioritisation and it is not investigation. Confusing it with either is why most triage sessions overrun and most backlogs grow.
There are only four outcomes
Every incoming issue ends in one of these. Naming them makes triage faster, because the job stops being "think about this" and becomes "pick one".
- Actionable. Somebody could start this today. It goes into the queue with a priority.
- Needs an answer. Real, but not startable until a question is answered.
- Not ours. A product decision, a support request, another team's, or working as designed.
- Closed. Duplicate, obsolete, or unreadable.
The second category is where backlogs go wrong, and it is worth being strict about it: an issue that needs an answer is not in the queue. It is waiting on a person, and if nobody is chasing that person it will wait forever.
The order to check in
Cheapest checks first, so you stop early.
1. Is it readable? If you cannot tell what it means in thirty seconds, it is not going to be worked on. Ask or close. Do not investigate.
2. Is it a duplicate? Search before reading closely. Merging early is much cheaper than merging after two people have commented on both.
3. Is it actually a defect? Ask what the reporter expected. If the expectation describes behaviour the software never had, this is a product decision and belongs with whoever owns that, with the reporter's own words attached.
4. Could somebody start it today? If not, name the single thing missing and ask for it. One question, not five.
5. Only now, how urgent? Priority is the last question, not the first, because three of the four outcomes above never reach it.
The trap: triaging by writing quality
Faced with a queue containing one crisp issue and one vague one, everybody picks the crisp one. It is the right local decision and it quietly reorders your roadmap by writing quality rather than importance.
The correction is not to be more virtuous. It is to make the vague ones less vague at the moment they arrive, so that by the time anyone is choosing, the queue is comparable. Nothing you do at triage time fixes a distortion that was introduced at filing time.
The trap: investigating during triage
An issue looks interesting, somebody opens the code, and forty minutes disappear. The rest of the queue is now untriaged, and the forty minutes were spent on whichever issue happened to be intriguing rather than whichever mattered.
Triage has a hard rule: no code. If an issue cannot be classified without opening an editor, classify it as "needs investigation", timebox it, and move on.
The trap: the open issue that means nothing
Every backlog accumulates issues nobody can interpret, often written by a colleague, sometimes by you. They resist closing because they might be important.
They are not going to be worked on. Leaving them open advertises an intention that does not exist, and makes the backlog a less honest document. Close them with a comment saying they were closed for being unreadable rather than unimportant. If the problem is still real, it will be reported again by somebody who can currently see it.
Cadence
Triage decays fast. An issue triaged within a day gets a reporter who still remembers the details; one triaged after a fortnight gets silence.
Little and often beats a weekly session. Ten minutes daily on new arrivals keeps the "needs an answer" pile moving, which is the pile that determines whether reporters keep reporting.
What to measure
Two numbers tell you most of what you need, and almost nobody tracks either.
Time from filed to triaged. If this exceeds a couple of days, your clarifying questions are arriving after the reporter has moved on, and your answer rate will show it.
The share of issues that needed a clarifying round trip. This is the tax you are paying on unclear reports, and it is the number that tells you whether anything you change at the filing end is working.