The ‘Request For Comment’ (RFC) process is often used in large open source projects to coordinate discussion, record requirements and  document design decisions. It is a process by which all contributors record suggestions, comments and discussions focussed around a technical proposal. The merit of the original proposal is debated, alternatives considered and accepted or rejected as necessary. After discussion, consultation, amendments and careful consideration – the RFC document is approved and published as the definitive collective decision on a particular technical issue.

The utility of RFCs is not limited to open source projects. They are also useful for corporate software development teams – and are especially valuable for fast growing companies with distributed remote teams – like Ebury. 

Currently, RFCs are written in markdown, live in their own repo and are managed in the main distributed version control system. Markdown provides a source than enables automated translation into other formats – like the ‘blueprints’ section which presents RFC’s on the Tech Intranet.

Scalable Asynchronous Communication

With many geographically dispersed tech teams working in different time zones and with different language capabilities, using RFCs has many benefits over in person video meetings, 

Contributors have time to fully understand complex issues and are not timeboxed into fixed meeting slots.  Participants can fit the work into their own schedules and contribute at their own pace. Video meetings favour the more vocal participants — whilst RFCs provide a quiet space for all to contribute equally.  Self timed asynchronous interaction enables the process to scale – like in any good architecture!

Within Ebury members of remote teams have team video calls at least daily – usually more often. Intra-team communication is excellent and supported by an Agile development process. Teams also tend to be aware of the work being performed by other teams working in their technical area. However, as the organisation is growing rapidly and more and more teams are created – it would be challenging to keep track. 

The single biggest benefit of RFCs is providing communication between teams and fostering a common technical development culture. 

Democratic Participation

The RFC documents are public and everybody can contribute to the discussion. This tends to be self-selecting participants who have the most experience in the area – and consequently the most to contribute. 

The RFCs are public and visible to all members of all teams. Everybody in Tech is informed whenever a new RFC is created and all versions of all RFCs, whether approved or not, are publicly available. This transparency ensures that no-one is left out and everyone has a chance to participate and keep up to date. 

Encourage Best Practices

There is a standard template for new RFCs which acts as a checklist of important points to consider. This helps in ensuring a standardised and thorough approach to development. For example, alternatives must be considered and the reasons for not choosing them documented. 

Security implications must also be addressed, dependencies must be documented, implications on data governance considered, effect on development detailed, performance impact analysed, etc. The structure of the template evolves over time as the concerns and priorities of  Tech changes over time. 

When to Create an RFC?

This is the question that causes the most debate! A team should ideally raise an RFC when:

• Other teams would benefit from the proposal
• The proposal would benefit from scrutiny by other teams

Since the prime purpose of the RFC is communication between teams, this is a good guide as to when an RFC is beneficial.  Low level design proposals local to a team that are non-controversial are best kept locally within the team. 

For example, new components, architectural patterns and best practices are good candidates for RFCs

The Approval Process

Whilst anyone can contribute to the discussion, there are well defined rules that define who are the final approvers of the RFC. These rules are themselves recorded in an RFC (of course!)  and evolve over time to suit the organisation. 

For example, significant changes like new architectural patterns require the approval of the head of architecture and the CTO, whilst smaller changes, like modifications to existing component RFCs only require approval from a code owner and a member of the architecture team. 

Agile Friendly

RFCs are a focal point for discussion – and as such should be published early and iterated often in response to feedback. A rough initial draft that is iterated into a final form through consensus is much preferable to a ‘perfect’ magnum opus that misses the mark completely. 

The process is relatively lightweight and agile. There is an expectation that relatively straightforward RFCs can be created, iterated and approved in a matter of days rather than weeks. This fits in perfectly with agile development processes where iterations are measured in weeks. 

Challenges

Whilst the process is overwhelmingly useful, there are some issues that people need to be aware of. For example, ‘RFC’ often seems like a Request For Criticism. Authors of a proposal put their head above the parapet and it can feel like they are being criticised for it.  Whilst video meetings favour the more vocal, the RFC process can favour the more confident authors.  To mitigate this, all members of a team should be encouraged to publish RFCs and commentators should be respectful and constructive in their observations. 

Also, it is an imperfect world and some proposals may not receive enough attention or get approved in a timely manner. The author of a proposal should be encouraged to proactively request comments and obtain approvals by connecting directly with key individuals. This works well – and is especially useful when the proposal is time sensitive. 

Summary

The top benefits of adopting an RFC process are:

• Scalable communication between teams in a distributed and fully remote environment
• An open, transparent and inclusive process of evolving technical proposals
• A central definitive record of patterns, designs decisions, practises and processes encoding the corporate culture
• Harnessing the collective intelligence of all members of the tech department to make better decisions and produce better solutions.