I believe in submitting clean and complete pull requests (PRs). I like PRs to compile without errors or warnings, include clear descriptions, and have good test coverage. However, there is one category of PRs where these standards do not apply - RFC (Request For Comments) PRs.
What are RFC PRs?
RFC PRs are PRs whose sole purpose is to help reach alignment and unblock development work.
When to send RFC PRs?
In my experience, sending RFC PRs can be particularly helpful in these situations:
- When working in an unfamiliar codebase.
- When trying to determine the best implementation approach, especially when there are several viable choices.
- To clarify ideas that are easier to explain with code than with words
The first two scenarios are like asking: 'This is what I am thinking. Is this going in the right direction? Any reasons why it wouldn't work?'
The third one is often a result of a design discussion or a PR review. It is like saying: 'I propose we approach it this way.'
The quality of RFC PRs
RFC PRs are usually created quickly to ask questions or demonstrate a point. These PRs are not expected to be approved, merged, or thoroughly reviewed, so there is little value in doing any work that does not directly contribute to achieving the goal. Adding test coverage is unnecessary, and the code does not even need to compile. For example, it is OK not to update most call sites after adding a function parameter.
I advise against trying to merge RFC PRs. Doing this rarely ends well. First, it is hard to change the reviewers' perception after they saw the first quick and dirty iteration. Furthermore, comments from the initial attempt may mislead reviewers and cause unnecessary iterations. It is often easier to submit a new PR, even if an earlier RFC PR heavily inspires it.
Storytime
I used an RFC PR recently while researching how to integrate our services with a system owned by another team. The integration could be done in one of two ways: using a native client or an API call. The native client offered limited capabilities, but understanding the consequences of these limitations was difficult. I decided to send an RFC PR to get feedback on my approach and quickly learned that the client approach wouldn't work and the reasons why.
Top comments (2)
Cool, thanks for the article. I too have recently started writing RFCs and integrating that into the frontend team. The last rfc was not about pull requests (merge requests, I work with gitlab), but about a separate part - comments in merge requests
Pull requests are an essential tool in collaborative software development, providing a platform for peer review and code discussion. They embody the philosophy that "code wins arguments," ensuring that technical decisions are made based on concrete implementations rather than theoretical debates. Through pull requests, developers can propose changes, receive feedback, and refine their code, ultimately improving the quality and robustness of the project. This Rfc process not only fosters better code but also enhances team collaboration and knowledge sharing.