oss-issue-triage

Start by measuring the queue with a baseline export of open counts, age, and response times, then compute weekly triage capacity against inflow. From there, design the label taxonomy, intake forms, duty rotation, and closing policy in that order, validating each artifact with the maintainers.

Organize labels into orthogonal axes (type, state, priority, area) with at most one value per axis per item. A solo maintainer needs about four state labels, a small team adds type and a two-value priority, and only multi-owner projects need the six-family Kubernetes-style taxonomy.

Only auto-close items waiting on a reporter who stopped replying, never items waiting on maintainers such as confirmed bugs. Restrict the sweep to the waiting-on-reporter state, exempt confirmed and blocked items, warn before closing, and run the first pass in dry-run mode.

Gate on reputation and submission volume rather than trying to detect machine-generated content, since no reliable detector exists. Set a written volume-gating trigger in advance, and consider changing submission incentives such as monetary bounties that attract low-quality volume.

Derive the target from measured capacity: triagers times sessions per week times minutes per session, divided by minutes per item, compared against inflow. Publish a number the team can hold in a bad month, defined as a human reply rather than a bot greeting or a fix.

Always. Security reports need a private intake channel, a named size-capped response team, and an embargo mechanism for coordinated disclosure, separate from general triage. With no security list, use the code host's private vulnerability reporting as the default.