RFC stages
The RFC ("request for comments") process is how Ember designs and achieves consensus on "substantial" proposed changes. The process is intended to provide a consistent and controlled path for new features and changes to enter the framework. RFCs can be created by any member of the community.
When an RFC is created and implemented it goes through six stages, proposed, exploring, accepted, ready-for-release, released and recommended. There are two statuses for when RFCs don't move forward, discontinued and closed.
For certain stage advancements, a final comment period (FCP) is required. This is a period lasting 7 days. The beginning of this period will be signaled with a comment and tag on the RFC's pull request. Furthermore, a message will be posted in #news-and-announcements on Ember Discord to attract the community's attention.
An RFC can be modified based upon feedback from the core teams and community during the final comment period. Significant modifications may trigger a new final comment period. At the end of a successful FCP, the RFC moves into the next stage. An RFC may be closed or discontinued by the core teams after public discussion has settled and comments have been made summarizing the rationale for closing. The RFC will enter a "final comment period to close" lasting 7 days. At the end of the "FCP to close" period, the PR will be closed. An RFC author may withdraw their own RFC by closing it themselves.
| Stage | Description | Requires FCP to enter? |
|---|---|---|
| 0 - Proposed | A proposal for a change to Ember or its processes that is offered for community and team evaluation. | no |
| 1 - Exploring | An RFC deemed worth pursuing but in need of refinement. | no |
| 2 - Accepted | A fully specified RFC. Waiting for or in the process of implementation. | yes |
| 3 - Ready for Release | The implementation of the RFC is complete, including learning materials. | yes |
| 4 - Released | The work is published. If it is codebase-related work, it is in a stable version of the relevant package(s). | no |
| 5 - Recommended | The feature/resource is recommended for general use. | yes |
Proposed
Proposed RFCs are opened as pull requests to the RFC repository. Anybody may create an RFC. The format should follow the templates in the RFC repository.
An RFC's number is the number of it's original proposal PR.
From "Proposed" an RFC may move to Exploring, or Closed stages. To move to Closed an FCP is required as in the existing process. A "Proposed" RFC may be moved to "Exploring" by consensus of the relevant team(s) without an FCP. See Exploring.
Exploring
An Exploring RFC is one the Ember team believes should be pursued, but the RFC may still need some more work, discussion, answers to open questions, and/or a champion before it can move to the next stage.
An RFC is moved into Exploring with consensus of the relevant teams. The relevant team expects to spend time helping to refine the proposal. The RFC remains a PR and will have an Exploring label applied.
An Exploring RFC that is successfully completed can move to Accepted with an FCP is required as in the existing process. It may also be moved to Closed with an FCP.
Accepted
An RFC that has been "accepted" has complete prose and has successfully passed through an "FCP to Accept" period in which the community has weighed in and consensus has been achieved on the direction. The relevant teams believe that the proposal is well-specified and ready for implementation. The RFC has a champion within one of the relevant teams.
If there are unanswered questions, we have outlined them and expect that they will be answered before Ready for Release.
When an RFC is merged and moved to "Accepted", a new PR will be opened to move it to Ready for Release. This PR should be used to track the implementation progress and gain consensus to move to the next stage.
Ready for Release
The implementation is complete according to plan outlined in the RFC, and is in harmony with any changes in Ember that have occurred since the RFC was first written. This includes any necessary learning materials. At this stage, features or deprecations may be available for use behind a feature flag, or with an optional package, etc. The team reviews the work to determine when it can be included in a stable release. For codebase changes, there are no open questions that are anticipated to require breaking changes; the Ember team is ready to commit to the stability of any interfaces exposed by the current implementation of the feature. Today, this would be the "go/no-go" decision by a particular team.
This stage should include a list of criteria for determining when the proposal can be considered Recommended after being Released.
A PR is opened on the repo (see Accepted) to move an accepted RFC into this stage. An FCP is required to move into this stage.
Each Ember core team will be requested as a reviewer on the PR to move into this stage. A representative of each team adds a review. If a team does not respond to the request, and after the conclusion of the FCP, it is assumed that the release may proceed.
Released
The work is published. If it is codebase-related work, it is in a stable version of the relevant package(s). If there are any critical deviations from the original RFC, they are briefly noted at the top of the RFC.
If the work for an RFC is spread across multiple releases of Ember or other packages, the RFC is considered to be in the Released stage when all features are available in stable releases and those packages and versions are noted in the RFC frontmatter.
Ember's RFC process can be used for process and work plans that are not about code. Some examples include Roadmap RFCs, changes to the RFC process itself, and changes to learning resources. When such an RFC is a candidate for Released, the work should be shipped as described, and the result should presented to the team with the intent of gathering feedback about whether anything is missing. If there is agreement that the work is complete, the RFC may be marked "Released" and a date is provided instead of a version.
An RFC is moved into "Released" when the above is verified by consensus of the relevant team(s) via a PR to update the stage.
Recommended
The "Recommended" stage is the final milestone for an RFC. It provides a signal to the wider community to indicate that a feature has been put through its ecosystem paces and is ready to use.
The "Recommended" stage is most important for suites of features that are designed as a number of separate RFCs. It allows the Ember maintainers to stabilize individual features once they are technically feature complete, an important goal for maintaining technical velocity.
To reach the "Recommended" stage, the following should be true:
- If appropriate, the feature is integrated into the tutorial and the guides prose. API documentation is polished and updates are carried through to other areas of API docs that may not directly pertain to the feature.
- If the proposal replaces an existing feature, the addon ecosystem has largely updated to work with both old and new features.
- If the proposal updates or replaces an existing feature, high-quality codemods are available
- If needed, Ember debugging tools as well as popular IDE support have been updated to support the feature.
- If the feature is part of a suite of features that were designed to work together for best ergonomics, the other features are also ready to be "Recommended".
- Any criteria for "Recommended" for this proposal that were established in the Ready For Release stage have been met.
An RFC is moved into "Recommended" via PR to update the stage. An FCP is required to enter this stage. Multiple RFCs may be moved as a batch into "Recommended" with the same PR.
Discontinued
A previously Accepted RFC may be discontinued at any point. The RFC may be superseded, out-of-date, or no longer consistent with the direction of Ember.
Closed
A Proposed or Exploring RFC may be closed after an FCP period. This is the same as the existing process. A closed RFC is discontinued.