The Reviewer's Guide: How to Give Great RFC Feedback

Most writing about RFCs focuses on the author. How to structure a proposal, what sections to include, how to write a clear problem statement. But reviewing is half the process, and bad reviews are just as damaging as bad proposals. A brilliant RFC that receives only "LGTM" is a missed opportunity. A solid RFC that receives only vague pushback is a frustrating waste of time.

Good reviewing is a skill. Here is how to develop it.

What to Look for in an RFC Review

When you open an RFC, resist the urge to start reading line by line and leaving comments on whatever catches your eye. Instead, read the entire document once without commenting. Then go back and evaluate these four dimensions:

Clarity of the problem. Does the RFC clearly articulate what problem it is solving and why it matters? Could you explain the problem to a colleague who has not read the RFC? If the problem statement is vague ("we need better performance") or missing entirely, that is the most important feedback you can give. Everything downstream of a weak problem statement is suspect.

Completeness of alternatives. Has the author considered meaningfully different approaches? "Do nothing" should almost always be listed as an alternative -- it forces the author to justify why action is needed at all. Watch for RFCs where the alternatives are straw men set up to make the proposed solution look good. If Alternative B is "rewrite everything from scratch," it is not a serious alternative.

Feasibility. Can this actually be built as described? Are there hidden dependencies, resource constraints, or technical limitations that the author may not be aware of? This is where domain expertise from reviewers is most valuable. The author may not know that the team tried a similar approach two years ago and hit scaling limits, or that the proposed API contract conflicts with an existing integration.

Risks and unknowns. What could go wrong? Does the RFC acknowledge the risks, and is the mitigation plan credible? Pay special attention to rollback plans. If the RFC says "we can always roll back" without explaining how, that is a red flag.

How to Give Constructive Feedback

The goal of RFC feedback is to improve the proposal, not to demonstrate your own expertise. Every comment should be actionable -- the author should be able to read it and know what to do next.

Be specific. Instead of "I'm not sure about this approach," say "I'm concerned that the proposed caching layer will not handle cache invalidation for the user-profile service, because profile updates happen on a different write path than the one described in section 3."

Ask questions before making assertions. "Have you considered what happens when the upstream service is unavailable for more than 5 minutes?" is more productive than "This will break when the upstream service goes down." The question invites the author to think through a scenario. The assertion invites defensiveness.

Separate your concerns from your preferences. "This design does not handle the case where two users edit the same document simultaneously" is a concern -- it identifies a gap. "I would have used gRPC instead of REST" is a preference -- it reflects a different stylistic choice. Both are valid feedback, but they should be weighted differently. Concerns need to be addressed. Preferences can be noted and the author can decide.

Acknowledge what is good. If the problem statement is exceptionally clear, say so. If the alternatives analysis is thorough, say so. Positive feedback is not just politeness -- it tells the author what to keep doing.

Blocking vs Non-Blocking Feedback

Not all feedback carries the same weight. Making this explicit prevents bikeshedding and keeps the review focused.

Blocking feedback identifies an issue that must be resolved before the RFC can be accepted. These are fundamental problems with the approach: a missing failure mode, an incorrect assumption about system behavior, a security vulnerability, an unacceptable tradeoff. Blocking feedback should be rare. If you are leaving blocking feedback on every RFC, either the RFCs are low quality or your bar is too high.

Non-blocking feedback identifies issues that are real but can be resolved during implementation or in a follow-up. Naming suggestions, minor structural improvements, additional edge cases that do not change the core approach, stylistic preferences. These are worth noting but should not hold up the decision.

When you leave a comment, label it explicitly. "Blocking: the proposed schema does not support multi-tenancy, and we need that for the enterprise tier" is clear. "Non-blocking: consider renaming the process method to handle for consistency with the existing codebase" is also clear. Unlabeled comments force the author to guess how seriously to take each one.

Timeboxing Reviews

An RFC that sits in review for three weeks is an RFC that has failed. The author is blocked. The project timeline slips. And by the time reviewers get around to reading it, the context has faded and the review quality suffers.

Set a review deadline for every RFC -- typically three to five business days from when review is requested. If a reviewer cannot provide feedback within that window, they should say so immediately so the author can find another reviewer.

For the author, this means: do not drop an RFC on Friday afternoon and expect feedback by Monday. Give reviewers a realistic window and flag the RFC in whatever communication channel the team uses.

For reviewers, this means: RFC review is not something you do when you have spare time. It is a commitment. When you agree to review an RFC, you are agreeing to provide thoughtful feedback within the timeframe. If you cannot do that, decline the review.

Some teams designate a standing "RFC review hour" once or twice a week. Engineers block time on their calendars specifically for reading and commenting on open RFCs. This prevents the common failure mode where everyone intends to review but nobody schedules the time.

Example Review Comments: Good vs Unhelpful

Here are concrete examples to illustrate the difference.

On a problem statement:

Unhelpful: "The problem statement is weak."

Good: "The problem statement mentions latency but does not quantify it. What is the current p99 latency, and what is the target? Without these numbers, it is hard to evaluate whether the proposed solution is sufficient."

On a proposed solution:

Unhelpful: "I disagree with this approach."

Good: "The proposed approach assumes that all writes go through a single coordinator. In our current architecture, the order service writes directly to the database during checkout. How would this change affect checkout latency? Have you measured the additional hop?"

On alternatives:

Unhelpful: "You should consider other options."

Good: "The alternatives section does not include the option of extending the existing queue system with priority lanes. Given that we already operate and monitor that system, it might be lower-risk than introducing a new service. Would you add that as an alternative with a brief analysis of the tradeoffs?"

On risks:

Unhelpful: "This seems risky."

Good: "Section 5 mentions that the migration will be zero-downtime, but the proposed approach requires a schema change that adds a NOT NULL column. In PostgreSQL, adding a NOT NULL column to a table with 50M rows requires a full table rewrite unless a default value is provided. This could lock the table for several minutes. Can you update the migration plan to account for this?"

On scope:

Unhelpful: "This is too big."

Good: "This RFC covers both the new ingestion pipeline and the new query API. These could be reviewed independently -- the query API depends on the ingestion pipeline but not vice versa. Would you consider splitting this into two RFCs? That would make each one easier to review and would let the team start on the ingestion pipeline without waiting for the query API design to be finalized."

The Reviewer's Mindset

The best RFC reviewers share a few traits.

They read generously. They assume the author is competent and has thought about the problem. When something seems wrong, they ask before they assert, because the author may have context that is not in the document.

They focus on outcomes, not preferences. The question is not "would I have designed it differently?" but "will this design achieve the stated goals?"

They are honest about what they do not know. "I am not familiar with the performance characteristics of this database engine -- can someone from the platform team weigh in?" is a more valuable comment than a confident but uninformed opinion.

They finish the review. An RFC with three comments on the first section and nothing on the rest is an incomplete review. If you commit to reviewing, review the whole document.

Reviewing is a form of mentorship. When you review a junior engineer's first RFC, you are teaching them how to think about systems design. When you review a senior engineer's RFC, you are stress-testing their assumptions. Both are acts of collaboration. Treat them that way.