Facebook has decided to adopt a new Request for Comments (RFC) process to help guide the design of React and smooth the pathway from idea to implementation.
The new procedure asks that major changes to React go through a vetting process before development occurs. Examples include:
- A new feature that creates new API surface area, and would require a feature flag if introduced.
- The removal of features that already shipped as part of the release channel.
- The introduction of new idiomatic usage or conventions, even if they do not include code changes to React itself.
List taken from the RFC Process README
As part of the process, developers will need to create an RFC document, submit a pull request to the RFC repository, and incorporate feedback from the community into their proposal. Final decisions on whether or not to accept the RFC are the responsibility of the core React team.
This appears to be a formalization of a custom that the React project had informally adopted. A search of the React project on GitHub shows that there are many issues that start with RFC with varying levels of discussion.
Facebook gives credit to the Rust RFC process as inspiration for their process; the RFC home pages have much of the same content and procedures. Of course, RFCs are not new and they are the basis for much of the work done by the Internet Engineering Task Force (IETF).
One advantage of using an RFC process for open source projects is that people feel more included, says Juan Pablo Buritica:
I've found no better way to generate the sense of belonging in teams than by including people in decision making. If we're involved in important decisions, our work has the potential to be more impactful, and this gives it a sense of purpose. By giving team members the opportunity to comment on decisions proposed by others, RFCs become excellent tools for inclusion and enable participation that can result in impact at work.
The RFC process should save time for both open source maintainers and those that want to contribute. Making a large change to a code base and submitting a pull request only to have the maintainer reject it is a waste of time. Jeff Geerling says big changes with no discussion is one of the reasons he rejects pull requests:
I've had PRs where the entire project architecture or test architecture was swapped out. I will never merge something like this unless it's been thoroughly discussed (and approved) in an issue first. There's usually a reason (many reasons, in fact) why things are the way they are.
The current list of documents in the RFC so far includes a few written by React core team members.
