Issue triage
An untriaged tracker teaches everyone to ignore it. Triage is the recurring work of turning a stream of reports into a queue that reflects reality, which means closing as decisively as it means labelling.
Method
- Triage on a schedule, not on impulse. A short daily or weekly pass keeps the backlog current, while heroic quarterly sweeps mean reporters wait weeks for a first response.
- Make the first response fast and human. Acknowledging within a day, even to say this needs more information, is what keeps contributors engaged (see community-building).
- Require reproduction before diagnosis. Version, environment, and steps. A template that asks for them up front saves the round trip that most reports otherwise need (see bug-report-triage).
- Label for decisions, not for taxonomy. Labels that change what happens next, such as needs-repro, confirmed, or good-first-issue, earn their place; elaborate category schemes do not.
- Close honestly and kindly. Out of scope, will not fix, and stale are legitimate outcomes, and saying so with a reason respects the reporter more than silence does.
- Convert recurring questions into documentation. The same issue three times is a documentation defect, not three bugs (see documentation).
Boundaries
- Triage sorts and decides; it does not fix, and a well-triaged backlog still needs someone to do the work.
- Volunteer maintainers owe no response, and setting that expectation publicly is healthier than implying a service level.
- Security reports must leave the public tracker immediately and follow a private path (see vulnerability-disclosure).