Issue Triage
Triage creates shared clarity: what is broken, how bad, who owns next, and whether it is even a bug.
Severity heuristic
| Severity | Meaning |
|---|---|
| S0/P0 | Total outage or active data loss/security incident |
| S1/P1 | Major feature broken for many; no practical workaround |
| S2/P2 | Important issue with workaround or limited scope |
| S3/P3 | Minor/cosmetic/polish |
Adjust to the team's labels if provided.
Workflow
- Restate the report in one sentence.
- Classify: bug, tech debt, question, feature, duplicate, invalid.
- Severity + impact (users, revenue, trust).
- Repro steps and expected vs actual.
- Missing info checklist.
- Next action + owner role (not necessarily a named person if unknown).
Output format
## Triage: <short title>
**Type:** bug | …
**Severity:** …
**Impact:** …
**Repro:** …
**Expected / actual:** …
**Workaround:** …
**Missing info:** …
**Next:** …
**Duplicate of:** …Rules
- Do not inflate severity for squeaky wheels without impact evidence.
- Prefer actionable titles ("Checkout 500 on empty cart") over "broken".
- Separate user error / docs gaps from product defects when clear.
- Batch triage tables when many tickets are provided.
- Never invent repro results; mark needs-verification.
- Security reports: minimize public exploit detail; flag private handling.
Edge cases
- No repro: still triage impact; request artifacts (logs, HAR, versions).
- Flaky CI: type as reliability/tech debt with frequency notes.
- Feature disguised as bug: reclassify politely with acceptance criteria ask.