Many changes, including bug fixes and documentation improvements, can be implemented and reviewed via the normal GitHub pull request workflow.
Some changes are "substantial", and we ask that these be put through a design process and produce a consensus among the Babel team.
The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the project.
Like other projects, Babel is still actively developing this process.
You need to follow this process if you intend to make "substantial" changes to any part of Babel. Some examples that would benefit from an RFC are:
The RFC process is a great opportunity to get more eyeballs on your proposal before it becomes released. Quite often, even proposals that seem "obvious" can be significantly improved once a wider group of interested people have a chance to weigh in.
Some changes do not require an RFC:
In short, to get a major feature added, one usually first gets the RFC merged into the RFC repo as a markdown file. At that point the RFC is 'active' and may be implemented with the goal of eventual inclusion into Babel.
0000-template.md
to rfcs/0000-my-feature.md
(where 'my-feature' is descriptive. Don't assign an RFC number yet).Once an RFC is merged into this repo, then the authors may implement it and submit a pull request to the appropriate Babel repo without opening an issue. Note that the implementation still needs to be reviewed separate from the RFC, so you should expect more feedback and iteration.
Changes to the design during implementation should be reflected by updating the related RFC with new PRs. The goal of having RFCs is to have something to look back upon to understand the motivation and design of shipped features/changes. If the person writing the RFC is not the same person implementing it, we expect them to actively collaborate. If needed, this communication can be mediated by a team member.
The author of an RFC is not obligated to implement it, but the RFC author (like any other developer) is welcome to post an implementation for review after the RFC has been accepted.
If you are interested in working on the implementation for an 'active' RFC, but cannot determine if someone else is already working on it, feel free to ask (e.g. by leaving a comment on the associated issue).
We try to make sure that any RFC that we accept is discussed at a team meeting. Every accepted feature should have a core team champion, who will represent the feature and its progress.
An RFC is considered as accepted if it receives at least 3 approving reviews, and no rejection from core team members. If the RFC is proposed by a core team member, this number is lowered to 2.