BT

React Adopts RFC Process

| by David Iffland Follow 4 Followers on Dec 13, 2017. Estimated reading time: 2 minutes |

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Educational Content

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT