How to Give Feedback on an RFC in English

An RFC comment that just says “have you considered X?” leaves the author guessing whether that’s a genuine blocker or idle curiosity — precise feedback marks its own severity, so the author knows exactly what needs to be resolved before moving forward. This guide covers how to do that in English.

Key Vocabulary

Blocking concern — feedback that must be resolved before the RFC can be approved, as opposed to a suggestion the author is free to take or leave. “This is a blocking concern for me: the proposal doesn’t address what happens on partial failure, and I don’t think we can approve this without that answered.”

Non-blocking suggestion — feedback offered as an idea worth considering but not required for approval, explicitly marked so the author doesn’t have to resolve it before moving forward. “Non-blocking suggestion: you might consider naming this differently for consistency with the other services, but it’s not something I’d hold up the RFC for.”

Clarifying question — a question asked to understand the proposal correctly before forming an opinion on it, distinct from an objection, and worth marking as such so the author doesn’t read it as pushback. “Clarifying question, not an objection: when you say ‘the migration runs asynchronously,’ do you mean it’s fire-and-forget, or do we wait for confirmation before considering the migration complete?”

Sign-off — an explicit statement of approval on an RFC, ideally naming what specifically is being approved, since a vague “LGTM” doesn’t clarify whether every detail was reviewed or just the general direction. “Signing off on the overall approach and the API shape — I haven’t reviewed the rollout plan in section 5 closely, so if that changes significantly, I’d want another pass.”

Common Phrases

• “This is a blocking concern — I don’t think we can move forward until this is addressed.”
• “Non-blocking suggestion, take it or leave it: …”
• “Clarifying question before I form an opinion: …”
• “I’m signing off on the general approach, but flagging one open question in section 3.”
• “Can you walk through what happens in the failure case here? That’s the part I’m least clear on.”

Example Sentences

Marking a genuine blocker clearly: “Blocking concern: the proposal doesn’t specify a rollback plan if the migration fails partway through. I think we need that written down before this gets approved, given how much data this touches.”

Offering feedback without implying it’s required: “Non-blocking suggestion — I’d lean towards splitting this into two smaller services rather than one, but I recognize that’s a judgment call and I won’t block the RFC over it. Your call.”

Signing off with scope stated explicitly: “I’m approving this RFC as it stands. To be specific: I reviewed the API design and data model closely and I’m comfortable with both. I skimmed the operational rollout section and would defer to the SRE team on that part.”

Professional Tips

• Label every comment as a blocking concern or a non-blocking suggestion explicitly — this single habit is the biggest lever for making RFC review threads converge instead of drift indefinitely.
• Mark clarifying questions as such before asking them — without the label, authors often read a question as disguised pushback and respond defensively instead of just answering.
• State the scope of a sign-off precisely — “approving the API shape, deferring on the rollout plan” is far more useful than a bare “LGTM” that leaves ambiguous what was actually reviewed.
• When raising a blocking concern, propose what would resolve it, not just the problem — “I’d approve this if section 4 addressed the partial-failure case” gives the author a concrete path forward.

Practice Exercise

1. Write a blocking-concern comment on a hypothetical RFC, naming what needs to be resolved.
2. Write a non-blocking suggestion, clearly marked as optional.
3. Write a sign-off statement that specifies exactly what you did and didn’t review.