maintainer-triage

Maintainer Triage Skill

An untriaged backlog isn't a to-do list — it's 400 open loops charging

interest on a volunteer's conscience. The fix isn't heroic issue-closing

weekends (they don't repeat); it's a system where every issue gets a

decision in under a minute — reproduce/needs-info/accepted/wontfix/

someday — encoded in labels, communicated by saved replies that stay human,

and maintained by a 30-minute weekly routine. Honest triage closes issues

politely that will never be done, because "open forever" is the cruelest

answer of all.

What This Skill Produces

• A label taxonomy that encodes decisions, not just topics: status

(needs-repro, needs-info, accepted, help-wanted, wontfix, someday) ×

type (bug, feature, docs, question) × effort (good-first-issue,

deep-water)

• Batch triage rules: the 30-second decision tree per issue, and the

order to eat the backlog (newest-first, oldest closed honestly in bulk)

• Saved replies for the eight recurring moments — needs-repro,

duplicate, wontfix-with-respect, stale-close, "PR welcome" (said only

when meant), the excited-first-contributor welcome

• A sustainable routine: the 30-minute weekly triage block + the

stale-policy settings, with the conscience switch: bugs never auto-stale

• The backlog burn-down plan for the existing 400

Required Inputs

Ask for (if not already provided):

• The repo: what it does, issue count, open PR count, other maintainers or

solo, current label mess

• The honest capacity: hours/week the maintainer actually has (the system

is sized to this, not to the backlog)

• The sore points: what fills the backlog (support questions? feature

wishlists? real bugs?) and what the maintainer feels worst about

• Project stance: is this a hobby, a career asset, or accidentally

load-bearing infrastructure? (wontfix courage scales with clarity here)

Framework

1. Labels are decisions. Every open issue carries exactly one status

label — an issue with no status is untriaged, and the goal state is

zero untriaged. Topics are optional garnish; status is the system.

1. The 30-second tree. Bug without repro → needs-repro + saved reply +

14-day clock. Repro'd bug → accepted + severity. Feature aligned with

project vision → accepted or help-wanted; not aligned → wontfix now,

kindly — parking unaligned features in "someday" is deferral disguised

as kindness, use someday only for genuinely-yes-later. Question → answer

or convert to discussion/docs issue. Duplicate → link + close.

1. Eat the backlog newest-first. Newest issues have live reporters and

fresh context; the oldest 200 get the honest bulk pass: a pinned

announcement ("triage sweep this week — issues inactive >12 months close

with this message; comment to reopen") then the sweep. Reopens are

signal, not failure — that's the mechanism finding the living issues.

1. Saved replies stay human. Each is 2–4 sentences, warm, and ends with

a clear next step. "PR welcome" appears only where a PR would genuinely

be reviewed and merged — as a brush-off it's the most resented phrase in

open source.

1. The routine that survives. Weekly 30 minutes: new issues to zero

untriaged → needs-info clock expiries → one accepted issue advanced.

Stale-bot only on needs-info and question labels, never on accepted

bugs. The maintainer's dread is the metric: if opening the repo stops

hurting, the system is working.

Output Format

## Label taxonomy (create these)
[Status set · type set · effort set — with color/description lines]

## The 30-second tree
[Decision tree, one branch per issue shape]

## Saved replies (paste into GitHub)
[The eight, each 2-4 sentences]

## Backlog burn-down
[The pinned announcement text · sweep order · reopen handling]

## Weekly 30 minutes
[The three-step routine · stale-bot config with the bugs-never-stale rule]

Quality Checks

• [ ] Every issue shape in the tree ends in a decision + a saved reply —

no branch ends in "leave it"

• [ ] Wontfix replies give the reason and thank the reporter — respect at

scale is the whole trick

• [ ] The bulk-close announcement runs BEFORE the sweep, and reopen

instructions are in the close message

• [ ] Stale automation exempts accepted bugs explicitly
• [ ] The routine fits the stated real hours, not the aspirational ones

Anti-Patterns

• [ ] Do not build a 40-label topic museum — status labels are the system;

taxonomy sprawl is procrastination with colors

• [ ] Do not use "someday" as a polite graveyard — unaligned features get

an honest wontfix

• [ ] Do not auto-stale confirmed bugs; nothing burns trust faster
• [ ] Do not write saved replies that could double as form rejections —

each names the specific next step

• [ ] Do not size the system to the backlog instead of the maintainer's

hours

Related

[[the-maintainers-no]] for the requests that need a personal no;

[[first-maintainer-month]] for new maintainers; [[email-triage-system]] —

the same discipline pointed at an inbox.