Issue Triage

---
name: issue-triage
description: Process incoming issues so real problems get found fast and the queue stays honest about what will be worked on. Use when an issue tracker has grown past what anyone reads.
---

# 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

1. **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.
2. **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).
3. **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).
4. **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.
5. **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.
6. **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).