# Defect Triage & Prioritisation Turns a pile of reported defects into an ordered list with the reasoning attached — and sends back the reports that cannot be triaged with the exact question that unblocks each one. ## Deliverable One Markdown document, `triage-report.md`, in the structure set out under **Output** below. It is read alongside the **Regression Suite Audit**, which uses the defects that escaped to judge the suite. ## Required inputs - **The defect reports to triage** — in whatever form they arrive: tickets, an export, a list, messages. - **Who decides business consequence** — the person whose call sets priority when impact and urgency disagree. Without both, stop. A triage with nobody to settle priority orders the list by whoever complained most recently. ## Optional inputs - Per report: steps to reproduce, environment, build or version, logs, screenshots - Access to an environment where a report can be reproduced - The severity and priority scales already agreed, with their definitions - The existing defect record, for finding duplicates - Who is affected, and whether a workaround exists - The dates or commitments these defects sit against Where no scale is supplied, the report states the scale it used and asks for the agreed one. Where a defect cannot be reproduced it is recorded as not reproducible; it is never given a severity so that the list looks complete. ## Execution **1 — Normalise every report.** One entry each: what was observed, what was expected, where, on which build, who reported it, and when. Fields the report does not carry are written `unknown`. They are not inferred from the wording of the description. **2 — Reproduce, or say you could not.** Attempt each defect on the stated environment and build. Record `reproduced` with the steps that worked, `not reproducible` with what was tried, or `not attempted` with the reason. Nothing moves further through the triage without one of the three. **3 — Return the reports that cannot be triaged.** A report with no observed and expected pair, no environment, or no route to the behaviour goes back with the single question that unblocks it, addressed to the person who filed it. A general request for more detail comes back as a general answer. **4 — Merge the duplicates.** Group the reports describing the same underlying failure, name the one they merge into, and keep every reporter attached so each is told when it closes. Reports that look alike but differ in trigger stay separate, with the difference written down. **5 — Judge severity from observed impact.** What the defect does when it occurs: data lost, a wrong result recorded, a task blocked, a display wrong. Severity is assigned only to a defect that was reproduced. A defect nobody has reproduced carries a request for reproduction in place of a severity. **6 — Judge priority from business consequence.** Who is affected, how often, whether a workaround exists, and what it costs to leave the defect open. Priority is recorded as its own value and may disagree with severity. The disagreement is the useful part of the triage: write it out, never average it into one number. **7 — Order the list and show the reasoning.** State the rule the order follows before the order itself, then give each defect its position and the reason it holds it. An order with no stated rule cannot be challenged, only resented. ## Output `triage-report.md`, in this order: - **1. Input and date** — which reports were triaged, against which build, by whom, and when - **2. Triaged defects** — per defect: identifier, observed, expected, environment, build, reproduction status, severity, priority, and the reason for each judgement - **3. Not reproducible** — per defect: what was tried, on which environment and build, and the question returned to the reporter - **4. Returned for information** — per report: the single missing fact, and who was asked for it - **5. Duplicates** — per group: the reports merged, the one they merge into, and the reporters to notify - **6. Severity and priority disagreements** — per defect: what each judgement says, and who must settle the order - **7. Ordering** — the rule used, then the ordered list with the reason for each position - **8. Missing information** — what blocked the triage, and who can unblock it ## Validation The triage is ready when all of these hold: - Every input report appears exactly once, in section 2, 3, 4 or 5 - Every defect in section 2 carries a reproduction status - No severity appears against a defect that nobody reproduced - Severity and priority are recorded as separate values, and neither is derived from the other - Every entry in section 4 names one specific missing fact rather than asking for more detail - Section 7 states the ordering rule before the order Fail the run if a severity appears without a reproduction, or if a report from the input is missing from the output. ## Failure handling - **No environment to reproduce in** — mark every defect `not attempted — no environment`, leave severity `pending reproduction` throughout, order on business consequence alone, and name the access needed in section 8. - **A report with no steps** — return it in section 4 with the exact question. Never reconstruct the steps from the description; a reconstructed reproduction confirms the reader, not the defect. - **Two reports contradict each other about the same behaviour** — keep both, name both reporters, and raise the contradiction in section 6 as blocking. Do not merge them into one report to make the conflict go away. - **Nobody will decide business consequence** — publish severity, leave every priority `undecided`, and name who must decide. A priority invented here is an opinion with a rank on it. - **Partial material** — triage what the material supports, mark the rest `INCOMPLETE — pending `, and deliver. A short triage that states what it could not judge is usable; a complete-looking one that guessed is not.