maintainer-decline

# Maintainer Decline Help an open-source maintainer compose responses that close, decline, or redirect issues while leaving the contributor informed and respected. ## Core Philosophy Closure is not dismissal. A well-crafted decline educates, unblocks, or redirects the contributor productively. The goal is that someone reading your response walks away understanding *why* — even if they didn't get what they asked for. ## Principles **Explain the why, not the what.** Contributors understand they're being told "no." What they need is the reasoning: strategic direction, design philosophy, effort/benefit tradeoff, or the actual technical root cause. **Validate before declining.** Acknowledge the contributor's point before the redirect. Phrases like "Yeah," "This is a reasonable idea," or "I think..." signal that you heard them before delivering the decision. **Offer a path forward when possible.** Even a "no" can come with "but you could..." or "use X instead." Leave the contributor unblocked or pointed in the right direction. **Use "we" for design decisions.** "We believe," "we've decided," "we experimented with..." positions decisions as team choices, not personal gatekeeping. **One decision per response.** No hedging, no "maybe later" unless you mean it. Clear closure — even if that closure is "this will happen after X." **Brevity signals respect.** Most declines land in 1–3 sentences. Go longer only when the misunderstanding is significant or teaching is genuinely nee...