RFC: A Structured RFC Process

Need

A healthy engineering organization demands a culture of asking for and welcoming feedback on our work. In smaller organizations, sharing plans, designs, and decisions is much easier. As we grow, it has become clear that this organic process won't suffice.

Currently, various teams already write down their plans and designs in documents that could be usually called an RFCs (Request for Comments). Without shared and clear guidance or process, these vary drastically in format, contents, and objectives. There is also a lot of variance on how these are advertised to other engineers who would be good candidates for feedback givers.

At the moment, there is no easy way for an engineer to know what topics are being discussed at a given time, or how could they give input on such decisions.

There is also no clarity on collaboration versus decision-making. An RFC process, by definition, is meant to collect feedback on a proposal. There will always be different opinions, and we must encourage people to expose their ideas and have them debated. Nevertheless, we operate in a very competitive landscape and we have no time to waste in analysis paralysis.

We believe that speed of iteration beats quality of iteration, and to iterate quickly we should have absolute clarity about who has the decision-making responsibility on a proposal.

Moreover, existing RFCs and similar documents often get into too much detail about the "how" and not enough on the "what" of the proposal. There are many different ways to materialize an idea, and implementation details are better left to be decided by those who are actually doing the work. 

In summary, we need a clear and simple process that allows people to share their ideas, receive feedback on them, and define how the decision-making process works.

Approach

The recommended approach to fulfill the needs presented in the previous section is a structured RFC process. In this document, a person or group of people will author a document describing a proposal and asking for feedback on it from the rest of the organization.

Feedback vs. Approval

The RFC process is a tool that can be used during the decision-making process, and everyone is encouraged to share rough and early ideas and proposals as RFCs. Even if the proposed change on the RFC is extremely well-received, it doesn't mean that it is approved to be worked on or that it will be prioritized. Authors of the RFC must make sure that they have whatever approval or sponsorship they need from management, leadership, stakeholders, collaborators, and their own team before any actual work is done.

RFCs are expected for any change that extends beyond a team or department, as it gives the people who would be affected an opportunity to learn more about the change and give feedback.

Authorship, Accountability, and Responsibility

The authors of an RFC can be an individual, team, or any other group of people. Being an author means that a person or team sponsors the initiative and are accountable for it.

While non-authors may be responsible for implementing the results of an RFC, its authors are accountable for it, as per the definitions below:

The main difference between responsibility and accountability is that responsibility can be shared while accountability cannot. Being accountable not only means being responsible for something but also ultimately being answerable for your actions. Also, accountability is something you hold a person to only after a task is done or not done. Responsibility can be before and/or after a task.

Collaboration

RFCs must be sent to a mailing list called rfcs@example.org. All engineers are automatically part of this list, and people from other groups are welcome to join and participate.

Comments and feedback should focus on the technical content. As long as they don't impact the content, collaborators should avoid commenting on formatting, writing style and other maybe relevant, but not critical aspects. Such comments can be sent directly to the author to avoid polluting the comment and storming people with notifications.

Authors must address all comments written by the deadline. This doesn't mean every comment and suggestion must be accepted and incorporated, but they must be carefully read and responded to. Comments written after the deadline may be addressed by the author, but they should be considered as a lower priority.

Every RFC has a lifecycle. The lifecycle has the following phases:

1. Draft: The authors are working on the RFC before asking for wider feedback
2. Feedback Requested: The RFC has been sent to the mailing list; authors are waiting for feedback from stakeholders
3. Active: The deadline for comments on this RFC has passed and the authors have decided to go ahead with it
4. Abandoned: The authors have decided not to move forward with the changes proposed in this RFC
5. Retired: The changes proposed on this RFC aren't in effect anymore, the document is kept for historical purposes

Each RFC has a revisit date, by when the authors will update the mailing list on what they have learned since the feedback phase. This is a natural point for an RFC to be retired and a new approach proposed. 

Format

The RFC document itself is where comments and decisions are recorded. It should be a Google Doc, and everyone should have access rights to comment on it.

A good RFC will describe the scope and the approach. It should not contain a list of specific tasks or project plan.

To avoid overloading the document with implementation details, RFCs should follow the Stanford Research Institute's NABC model, making sure that they cover four points:

An NABC comprises the four fundamentals that define a project's value proposition: 

Need:

What are our client's needs? A need should relate to an important and specific client or market opportunity, with market size and end customers clearly stated. With DARPA, for example, we are required to state a critical Department of Defense (DoD) need. The market should be large enough to merit the necessary investment and development time.

Approach:

What is our compelling solution to the specific client need? Draw it, simulate it or make a mockup to help convey your vision. As the approach develops through iterations, it becomes a full proposal or business plan, which can include market positioning, cost, staffing, partnering, deliverables, a timetable and intellectual property (IP) protection.

If we are developing a product, it must also include product specifications, manufacturing, distribution and sales. DARPA usually demands paradigm-shifting approaches that address a specific DoD need (e.g., a 10-times improvement). 

Benefits:

What are the client benefits of our approach? Each approach to a client's need results in unique client benefits, such as low cost, high performance or quick response. At DARPA, the benefit might be an airplane that turns faster, goes higher, costs less or is safer. Success requires that the benefits be quantitative and substantially better - not just different. Why must we win?

Competition/alternatives:

Why are our benefits significantly better than the competition? Everyone has alternatives. We must be able to tell our client or partner why our solution represents the best value. To do this, we must clearly understand our competition and our client's alternatives. For a commercial customer, access to important IP is often a persuasive reason to work with us. At DARPA, our competition is usually other research laboratories and universities across the United States.

But, whether to a commercial or government client, we must be able to clearly state why our approach is substantially better than that of the competition. Our answer should be short and memorable.

Benefits

The first significant benefit of the approach described above is making a clearer distinction between decision-making and feedback gathering. With a clearly appointed accountable team, we can create a disagree and commit culture. We will carefully hear all positions and reckons from everyone, but ultimately a decision will be made by a specific person or team.

Once the decision is made, everybody, irrespective of any differences in opinion during the RFC process, will commit to implementing and championing the decision. If it turns out that the decision wasn't a good one, the revisit date on the RFC is there to make sure another discussion will be held in the near future.

Another important benefit of the proposed RFC process is openness. We have fantastic engineers, and we need to use our collective knowledge as leverage. None of us is as smart as all of us. To make collaboration work, we need to make it easy for all engineers to see what RFCs are being proposed and we need to make it a safe environment to collaborate, where comments focus on factual benefits and tradeoffs.

The NABC format is an industry tool used for making structured 'pitches'. Using this tool will likely lead us to discuss the what without losing ourselves in the ocean of technical detail.

Competition (or Alternatives)

Do Nothing

We should consider the option of not making any change and keeping the ad-hoc model we currently have for RFCs.

The main issues with this option were described in the Need section of this document. Unless something changes, the problems there will remain.

Adopt IEEE RFC Model as-is

Although any collaborative development process will have feedback as a core component, the name RFC was made popular by the process used by the IETF to document fundamental standards for what eventually became the Internet. We could follow the IETF RFC model, and maybe even require authors to use terms like MUST, SHOULD, and MAY as formally specified by RFC2119 to avoid ambiguity. 

The main reason to avoid this style is that IETF RFCs have evolved into "the Internet documents of record", containing "very detailed technical information" about standards that browser vendors and network middleware need to implement. These documents will impact the whole industry and hence warrant a complex publishing workflow.

The process we propose in this document, on the other hand, is about putting forward an idea as early as possible and receiving feedback on it by a wide audience. With this goal in mind, a less formal process like the one described here is preferred.

Use Architecture Decision Record

Michael Nygard published a model to document and manage change in software architecture called Architecture Decision Record (ADR). Its motivation, format, and lifecycle are very similar to what this document proposes. 

Nygard's model is specialized in software architecture work. This is reflected in its usage of engineering tools such as repositories and Markdown files, which only make sense in a software project. We want the RFC process to be a tool useful in areas other than software development, which makes harder to implement some of the more specialized areas of the process. Nevertheless, ADRs can be used together with the RFC process described here when developing software systems.