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."