the-maintainers-no

The Maintainer's No Skill

Maintainer burnout is mostly unsent nos: the feature request at 40 comments,

the well-meant PR that would triple the maintenance surface, the company

that filed "urgent" on a volunteer's project. Every avoided no costs a

week of low-grade guilt; the sent no costs five minutes and is almost never

received as badly as feared. This skill writes the specific no each

situation needs — with the reasoning shown, the effort honored, and a real

alternative where one exists — because "no with a why and a path" keeps

contributors that "maybe someday" quietly loses.

What This Skill Produces

• The situation-fit no, drafted ready to post: scope-no, PR-no,

support-no, urgency-no, or the fork blessing

• The reasoning paragraph: the project-vision line that makes this no

consistent instead of personal (and reusable next time)

• An alternative that's real: plugin/extension point, the fork blessing,

a linked workaround, a paid-support pointer if one exists — or nothing,

stated honestly, if nothing exists

• A policy line worth adding to CONTRIBUTING/README so the next no is

half-written

Required Inputs

Ask for (if not already provided):

• The thread/PR/request text, and how long it's been festering
• The real reason it's a no (doesn't fit vision? maintenance cost? just

don't want to? — all valid; the phrasing differs)

• Who's asking: first-timer, regular contributor, company, drive-by
• What the maintainer could genuinely offer, if anything (review a smaller

PR? accept behind a flag? nothing?)

Framework

1. Diagnose the no. Scope-no (doesn't fit what this project is) ·

cost-no (fits, but the maintenance is forever and it's mine) · PR-no

(effort real, direction wrong) · support-no (this is unpaid volunteer

time being invoiced) · capacity-no (fits, but not this year — the only

no that may honestly become "someday").

1. Honor effort before delivering direction. For PRs especially: name

something genuinely good in it first (one specific thing, not flattery).

The order is: thanks-with-specifics → the no with the why → the path if

real. Skipping straight to the no is efficient and expensive.

1. Show the vision line, not the mood. "This project deliberately stays

[small/zero-dep/single-purpose]; features like X belong in

[plugins/forks/other tools]" — a no anchored to a stated principle

generalizes; a no anchored to today's energy invites relitigation.

If the principle isn't written anywhere yet, this is the moment: the

skill drafts the CONTRIBUTING line.

1. Bless the fork sincerely. "This is exactly what forks are for — the

license means you don't need my permission, and I mean that as an

invitation, not a brush-off" defuses more standoffs than any other

sentence in open source.

1. For companies: name the exchange. Volunteer-maintained ≠ SLA. The

reply states what's available free (the issue queue, at volunteer pace),

what isn't (deadlines, priority), and — if the maintainer wants it —

the paid path ("sponsorship/support contract gets your issue a

scheduled slot"). No apology anywhere in it.

1. Close the loop physically. The no ends with the issue's fate:

closed-wontfix, converted to discussion, or left open behind a named

condition. A no that leaves the thread open re-accrues the guilt.

Output Format

## Diagnosis
[Which no this is, and the real reason in one honest line]

## The reply (ready to post)
[Thanks-with-specifics → the no with the vision line → the real path or
honest nothing → the thread's fate]

## Add to CONTRIBUTING (so the next one is half-written)
[The policy line this no just established]

## If they push back
[The one-paragraph second reply — same decision, warmer, final]

Quality Checks

• [ ] The no is unambiguous — a reader cannot mistake it for maybe
• [ ] Effort is honored with a specific, true observation, not a compliment

template

• [ ] The reasoning cites a project principle that will still be true next

month

• [ ] Any offered alternative is real — no "PR welcome" unless a PR would

genuinely merge

• [ ] The thread's fate is stated (closed / converted / condition), and the

pushback reply doesn't reopen the decision

Anti-Patterns

• [ ] Do not soften into ambiguity — "maybe down the road" costs you this

conversation again in six months, with interest

• [ ] Do not apologize for the project's boundaries; gratitude yes,

apology no

• [ ] Do not match a demanding tone — the calm no in a heated thread is

read by every future contributor, not just this one

• [ ] Do not invent roadmap promises to escape the moment
• [ ] Do not skip the fork blessing out of possessiveness — the license

already said yes; saying it warmly is free

Related

[[maintainer-triage]] — the system that catches these before they fester;

[[saying-no-kindly]] — the general craft; [[first-maintainer-month]] for

setting the boundaries early enough that nos stay rare.