maintainer-reply

Maintainer Reply

Draft before posting. Read the relevant issue or PR conversation, repository guidance, and the user's stated goal before writing. A technically correct reply can still be wrong if it ignores what the recipient already knows or reveals private context.

Identify the reply

Before drafting, establish:

• recipient and relationship;
• issue, PR, review, or thread;
• purpose: answer, clarify, thank, apologize, request information, request changes, close, or explain a decision;
• what has already been said;
• what the recipient already knows;
• the state and time slice the reply must reflect, especially when testing or reconstructing an earlier point in a conversation;
• whether this is a draft or an approved post.

Keep these separate:

private reasoning → review findings, frustration, speculation, roadmap, internal comparisons
public reply      → relevant facts, concrete request, brief rationale, appropriate next step

Do not leak private reasoning merely because it informed the decision.

Style

Write in the maintainer's natural voice:

• concise and humane;
• specific to this conversation;
• proportionate to the issue and contributor;
• direct without sounding automated or corporate.

Avoid generic filler, obvious restatements, excessive headings, long technical explanations, forced gratitude, unexplained jargon, and LLM-shaped phrases such as “I’ve provided detailed feedback below” when the context already makes that clear. Avoid intensifiers and stock support language such as “sincerely,” “we appreciate your effort,” and “thanks for your understanding” unless they fit the maintainer's established voice and this specific exchange. Do not mention bots, internal agents, or project politics unless the user explicitly wants that included.

Appreciate useful contributions sincerely. Do not treat a good-faith contributor like a low-effort or automated submission without clear evidence. If apologizing, name the concrete mistake and the correction; do not over-explain.