A Request For Comments also known as RFC, is a process that captures ideas and proposals about a specific topic to discuss and find consensus 🤝.
An RFC involves a document or a series of documents 📑, which are drafted, reviewed and eventually approved or rejected by a group of people.
What are the benefits?
Planning
Writing down your idea into a document will clarify your thoughts and will help organizing them in a structured manner.
Anticipating 🔮 the problem you aim to solve and envisioning potential solutions is key to identifying issues and edge cases.
Alignment
As a team, it's important that decisions 🎙️ are made by reaching a consensus 🤝. It's very common that as humans we have different opinions and points of view.
RFCs are an effective process to include everyone's opinions 💭 and reach a decision everyone agrees with.
Documentation
The document 📑 itself is a valuable piece of documentation as it captures the context, the problem, the solution, and the decision-making process.
It will serve as a reference for future team members and will help them understand the context and the reasoning behind the decisions made ❣️
An RFC is usually the initial step in the decision-making process before creating Architecture Decision Record which I previously wrote about ✍️
Better decision-making
One of the steps of the process is to share the RFC with the team to collect feedback and review the context and the proposed solution.
Involving multiple people 🧠 in the decision-making process is key to achieve high quality decisions, as it will bring different perspectives and solutions to the table reducing the chances of overlooking important details.
You can think of it as a code review, but for ideas and proposals.
When you should write an RFC?
It depends 🙈 but generally I would recommend writing them when dealing with high-impact decisions and major changes that require consensus and alignment such as:
- Introducing a new service in your company 🚀
- Major changes in the architecture 🏗️
- Big features that have an overarching impact 🆕
It's up to you to decide when to write them, but in my opinion you should weight ⚖️ the effort 🥵 and the impact 💥 since it's a time-consuming process that involves many people.
How to write an RFC
Define a template
When writing them, a common practice is to have a template to write ✍🏼 all the documents in the same way.
You'll find a lot of templates online, but this is the one I use 👈
❗️ Use a tool that allows collaborative features (comments, suggestions etc) to make it easier for the team to review and provide feedback such as Google Docs or Notion.
Share document for review
Once you have the document ready, share it with the team for them to review 👀 and provide feedback.
Address feedback
After the reviews come in, you should address the comments, questions and concerns and incorporate any suggestions if appropriate 🖊️.
Make a decision
Finally, after the document has been reviewed and the feedback has been addressed and collected, it's time to make a decision.
The team should either approve ✅ the RFC and move forward with the proposal or reject ❌ it.
Examples
In case you're looking for inspiration, there are many organizations and communities that use RFCs to propose and discuss new ideas, here are some examples:
Conclusion
RFCs are a powerful process to gather feedback, align the team and document decision-making. They're a great way to reach consensus as a team representing everyone's opinion.
I encourage you to give them a try and see how they can help you and your team to make better decisions! 🫰
Top comments (0)