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 (0)