triaging-an-issuelisted

# Triaging an issue Triage is deciding what a report *is*, not fixing it. Done well it takes minutes and saves the person who picks it up an hour. Done badly it produces a backlog of things nobody can start. ## First, reproduce it Everything depends on this. - Follow the steps exactly as given, on the current default branch. - If it reproduces, write down the shortest version that still fails. That is the most valuable thing you will produce today. - If it does not, do not close it as invalid. Say precisely what you tried — version, branch, command, environment — and ask for the one piece you are missing. Most irreproducible reports are missing exactly one detail. Watch for the report that describes a solution rather than a problem ("add a retry to the uploader"). Ask what actually went wrong; the proposed fix is often for the wrong cause. ## Then work out what it is - **A bug** — behaviour contradicts what is documented or intended. - **A feature request** — it works as built; someone wants it built differently. This is the owner's call, not the team's; do not start it because it seemed small. - **A question** — answer it, and if the answer should have been obvious, the real fix is a documentation change. - **Not our problem** — a dependency, the environment, someone else's service. Say where it actually lives and what you checked to know that. ## Then judge how much it matters Two axes, and be honest about both: - **Impact**: data loss, a security hole