If you work in a team that makes architectural or process decisions, you will eventually need to read — or write — an RFC. For non-native English speakers, the challenge is double: you must understand the technical content and the specific vocabulary that experienced engineers use to discuss it. This post breaks down every key term, shows you how it appears in real conversations, and gives you a quick reference to use during your next review.

What Is an RFC and Why Does It Matter?

An RFC (Request for Comments) is a structured written proposal that describes a problem, suggests a solution, and invites the team or organisation to discuss it before a decision is made. The term comes from the early internet (the IETF published RFCs to define protocols), but today software teams use it for anything from a new API design to a change in deployment strategy.

RFCs slow down the impulse to just “start coding” — and that is a feature, not a bug. A well-written RFC surfaces concerns early, creates a paper trail, and ensures stakeholder alignment: everyone who will be affected by a decision has had a chance to comment.

“Before we start the sprint, can someone write an RFC? I want to make sure the platform team has visibility before we commit to this approach.”

“We follow an RFC process here. Even small architectural changes need a design proposal so we can keep a decision record.”

Core Terms

Problem statement — a clear, concise description of the issue that motivates the RFC. A good problem statement answers: what is wrong, for whom, and why does it matter now? Avoid jumping to solutions here.

“Your problem statement is a bit vague. Can you quantify the impact? Something like ‘our p99 latency exceeds 800 ms under load’ is much stronger than ‘the service is slow’.”

“I’d suggest separating the problem statement from the motivation section — right now they’re blended together and it’s hard to see what you’re actually trying to fix.”

Motivation — the why behind the proposal. While the problem statement describes what is broken, the motivation explains why solving it matters to the business or users. Good motivation includes data, user feedback, or cost arguments.

“The motivation section needs more context. What’s the actual business impact if we don’t address this? A concrete number would help get sign-off.”

“I love that you tied the motivation to our OKR on developer experience. That will help with stakeholder alignment when this goes to the architecture review.”

Proposed solution — the main recommendation of the RFC. This section describes what you want to do and how it works. It should be detailed enough for reviewers to assess feasibility, but not a full implementation spec.

“The proposed solution looks solid, but I’m missing detail on how you plan to handle backwards compatibility. Can you add a paragraph on the migration path?”

“Your proposed solution assumes we already have feature flags in place. Is that a safe assumption for all environments?”

Alternatives considered — a section that lists other approaches you evaluated before settling on the proposed solution. Skipping this section is a red flag; it signals that the author did not explore the problem space thoroughly.

“I see only one entry in the alternatives considered section. Did you look at using a message queue instead of a direct HTTP call? That trade-off analysis would be useful.”

“We rejected the GraphQL option — it’s in the alternatives considered section with reasoning. Short version: the team lacks experience and the timeline is tight.”

Trade-off analysis — a comparison of the pros and cons of each option, including the chosen one. Good trade-off analysis is honest: it acknowledges the downsides of the proposed solution rather than pretending it is perfect.

“I appreciate the honest trade-off analysis. Admitting that this approach increases operational complexity is the right call — we’d rather know upfront than discover it in production.”

“Can you extend the trade-off analysis to include serialise/deserialise costs? With high-frequency events, that overhead could be significant.”

Structuring the RFC Document

Success criteria — measurable conditions that define when the proposal has achieved its goal. Without success criteria, it is impossible to evaluate whether the implementation was a success.

“What are the success criteria here? I want to know what ‘done’ looks like — is it a latency target, an error rate, or something else?”

“Let’s add success criteria before the RFC is accepted. My suggestion: p95 response time below 200 ms and zero increase in error rate over a 2-week canary period.”

Open questions — a list of unresolved issues that the RFC author acknowledges but cannot answer alone. This section invites specific input and prevents the RFC from being blocked on uncertainty.

“The open questions section is helpful. I can answer question 3 — the data retention policy is 90 days, so your archival logic needs to handle that edge case.”

“Please don’t mark this RFC as ready for review until you’ve resolved or at least triaged the open questions. There are two blockers in there.”

Decision record — a persistent log of why a decision was made, including the context, the options evaluated, and the outcome. Even when an RFC is rejected, the decision record preserves the reasoning for future engineers.

“I couldn’t find the decision record for why we moved away from REST here. Does anyone know if there was an RFC? We might be about to re-litigate an old decision.”

“Always update the decision record after the RFC review meeting, even if the outcome is ‘we decided to wait’. Future you will thank present you.”

RFC Review: Language and Etiquette

An RFC review meeting is a synchronous (or async) session where stakeholders discuss the proposal and move toward a decision. Knowing the right phrases makes these meetings less stressful.

Common phrases you will hear:

“I left some comments on the doc — nothing blocking, just nits.”
“I’m +1 on the proposed solution, but I’d like to see the open questions resolved first.”
“Can we timebox the alternatives discussion? We’ve been on it for 20 minutes.”
“Let’s take the implementation details offline — this is getting too deep for an RFC review.”

Comment resolution refers to the process of addressing reviewers’ written feedback before a decision is made. Authors are expected to either fix the issue raised or explain why they disagree.

“I’ve gone through all the comments. Two are resolved, one I’ve pushed back on with a note — can you take a look and confirm you’re happy?”

“Comment resolution is blocking the merge. We can’t accept the RFC until every open thread is either addressed or marked as won’t fix with a reason.”

How to Use These in Conversation

Understanding the terms is only half the work. Here is how to deploy them naturally in daily communication.

LGTM vs NACK — two shorthand verdicts used in code and RFC reviews. LGTM (“Looks Good To Me”) signals approval. NACK (“Negative Acknowledgement”) signals a blocking objection.

“I’ve added my LGTM to the doc. One minor nit on the serialise method name, but that’s non-blocking.”

“I’m going to NACK this RFC for now. The trade-off analysis doesn’t address data sovereignty, and that’s a hard requirement for our EU customers.”

When an RFC reaches the end of its review period, the outcome is announced formally:

“The RFC is accepted. We’ll move to implementation in the next sprint.”
“The RFC is rejected. See the decision record for the reasoning and next steps.”

“The RFC is accepted with conditions — we need to resolve the open question about retry behaviour before we cut the first release.”

“After three weeks of review, the RFC is rejected. The consensus was that the cost of migration outweighs the benefit at our current scale. The decision record has been updated.”

A design proposal is sometimes used interchangeably with RFC, but in some organisations it refers to a lighter-weight document — less formal, shorter, and used for smaller decisions that do not require full stakeholder alignment.

“For a change this small, a design proposal in the wiki is probably enough. You don’t need to go through the full RFC process.”

“I started with a design proposal to get early feedback, then expanded it into a proper RFC once the approach was validated.”

Quick Reference

Term	Meaning
RFC (Request for Comments)	Structured proposal document inviting team review before a decision
Problem statement	Clear description of what is wrong and why it matters
Proposed solution	The recommended approach to solving the problem
Alternatives considered	Other options evaluated and reasons for rejecting them
Trade-off analysis	Honest comparison of pros and cons for each option
Success criteria	Measurable conditions that define a successful outcome
Open questions	Unresolved issues explicitly flagged for input
Decision record	Persistent log of why a decision was made
LGTM / NACK	Approval / blocking objection in a review
Stakeholder alignment	Ensuring all affected parties understand and accept the decision

Writing RFCs in English is a skill that improves with practise. The vocabulary in this post will help you participate confidently in reviews, give precise feedback, and write proposals that colleagues trust. Start by reading a few accepted RFCs in your organisation — notice the behaviour of each section, and pay attention to how experienced engineers structure their trade-off analysis. Then try drafting one yourself, even for a small decision. The artefact you create will outlast the meeting where it was discussed.