How to Write an RFC Comment Thread Summary in English

A fifty-comment RFC thread is unreadable to anyone who joins the discussion late, and the author who writes a clear summary at the top — what was debated, what was decided, what changed — saves every future reader from re-deriving the whole conversation. This guide covers the English for writing one.

Key Vocabulary

Open question — a point raised in the thread that hasn’t yet been resolved, explicitly labeled so readers know not to treat the current document text as final on that point. “There’s still one open question: whether we version the API in the URL or the header — that discussion is ongoing further down the thread.”

Resolved (in favor of X) — a comment thread marker showing that a debate concluded with a specific decision, ideally with a one-line reason, so a reader doesn’t have to reconstruct the reasoning from scratch. “Resolved in favor of the header-based versioning approach — it keeps URLs stable for clients that don’t care about the version and matches our existing service conventions.”

Dissent (noted, not blocking) — an explicit acknowledgment that someone disagreed with the final decision but isn’t blocking it from proceeding, distinct from silence implying full agreement. “Noted dissent from the platform team on the migration timeline — they’d prefer an extra week, but agreed not to block the RFC on it given the broader deadline pressure.”

Superseded comment — a comment whose concern was addressed by a subsequent revision of the document, flagged so a new reader doesn’t re-raise an already-fixed issue. “That comment about missing error handling is superseded — section 4 was rewritten to cover it after this thread.”

Revision note — a short changelog entry describing what changed in the document as a direct result of thread feedback, tying discussion back to concrete edits. “Revision 3 added the rollback plan section directly in response to the concerns raised in comments 12 through 15.”

Common Phrases

• “Is this an open question still, or was it resolved somewhere in the thread?”
• “What was this resolved in favor of, and why?”
• “Is this a blocking objection, or dissent that’s been noted but not blocking?”
• “Has this comment been superseded by a later revision?”
• “What actually changed in the doc as a result of this discussion?”

Example Sentences

Opening a thread summary: “Summary as of revision 4: three open questions remain (see below), two were resolved in favor of the original proposal, and one piece of dissent was noted but isn’t blocking merge.”

Closing out a resolved debate: “Resolved: we’re going with async processing for this step. The main counterargument (added complexity) was acknowledged but outweighed by the latency requirement stated in the goals section.”

Flagging a superseded concern: “This is superseded — the concern about the missing index was valid, and revision 2 added it explicitly to the schema section.”

Professional Tips

• Post the thread summary at the top of the document or in a pinned comment, not buried at comment 40 — most readers scan from the top and never reach the bottom of a long thread.
• Mark items resolved in favor of X with a one-line reason — a bare “resolved” tells a reader what happened but not why, which matters if the decision is revisited later.
• Explicitly note dissent, even non-blocking dissent — silently proceeding without acknowledging disagreement erodes trust that concerns were actually heard.
• Tie every significant thread discussion to a revision note — a debate that changes nothing in the document should say so; a debate that changed something should say what.

Practice Exercise

1. Write a one-paragraph summary of a hypothetical RFC thread with two resolved questions and one open question.
2. Write a sentence noting non-blocking dissent professionally.
3. Write a revision note connecting a comment thread to a specific document change.