# emberjs/rfcs: the process that decides what changes in Ember

> The Ember RFCs repository is not a library and not a website, it is the governance machinery behind the framework, a set of numbered stages, a final comment period, and a directory of templates that turn a substantial change into a merged document. It is also the clearest public record of how a JavaScript framework argues with itself about its own direction.

**emberjs/rfcs** — RFCs for changes to Ember

- Repository: https://github.com/emberjs/rfcs
- Website: https://rfcs.emberjs.com/
- Stars: 801 · Forks: 410
- Language: Unknown
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/emberjs-rfcs

## The dividing line is substantial, and everything below it goes through pull requests

The RFC process is described as how Ember designs and achieves consensus on substantial proposed changes. The word substantial is doing a lot of work, and the next paragraph defines it by contrast.

Many changes, including bug fixes and documentation improvements, can be implemented and reviewed via the normal GitHub pull request workflow. Some changes though are substantial, and those are asked to go through a design process and produce consensus among the Ember core teams.

So the repository handles the minority of changes. A rename of a private method, a fix to a type annotation, a documentation rewrite, none of that needs a design document. A new public API, a change to the object model, a deprecation of a long-standing concept, those do.

The stated purpose is to provide a consistent and controlled path for new features and changes to enter the framework, and the process is open to anyone: RFCs can be created by any member of the community. That openness is bounded in practice by the champion requirement described later, but the entry point is not gated on being a core team member.

The repository itself reflects the process rather than the framework. The top level holds 0000-template.md, the RFC template, and deprecation-template.md, alongside directories for the stages, the teams and the text of the RFCs, plus images/ and a CODE_OF_CONDUCT.md. There is no source code, no build, and no releases.

## Six numbered stages, and a table that says which ones need a final comment period

The stage list is the core of the process, and it is published as a table with three columns: the stage, its description, and whether entering it requires an FCP, a Final Comment Period.

Stage 0, Proposed, is a proposal offered for community and team evaluation, and no FCP is needed to enter it. Stage 1, Exploring, is an RFC deemed worth pursuing but in need of refinement, also with no FCP requirement. Stage 2, Accepted, is a fully specified RFC waiting for or in the process of implementation, and this one does require an FCP. Stage 3, Ready for Release, means the implementation is complete, learning resources included, and requires an FCP to enter. Stage 4, Released, means the work is published and, if it is codebase work, is in a stable version of the relevant packages, and no FCP is required. Stage 5, Recommended, means the feature or resource is recommended for general use, and it does require an FCP.

The pattern is deliberate. The two stages where consensus is hardest to reach, agreeing a design is final and agreeing a feature is recommended for general use, both get a mandatory waiting period. The middle stages, which are about implementation progress rather than opinion, do not.

There are two additional statuses for RFCs that will not move forward. Discontinued applies to a previously Accepted RFC that is either in conflict with Ember's evolving programming model or superseded by another active RFC. Closed applies to Proposed RFCs that will not be moved into the next stage. The distinction matters because Discontinued implies something once agreed is being undone, and the reason given is a conflict with the programming model, which is a design argument rather than a scheduling one.

## The advancement pull requests are opened automatically, one per stage

The mechanism that keeps the process moving is a set of automatically opened pull requests, and the mechanics are laid out stage by stage.

When an RFC is accepted, a draft pull request is automatically opened to advance it to Ready for Release. That pull request has a template outlining what is necessary to merge, and it is where the community tracks implementation progress. Once the criteria are met, including commitment of the team to the feature's stability, the pull request may be merged after a Final Comment Period, and each core team needs to review and approve it before the end of that period.

When the RFC is merged as Ready for Release, another pull request is automatically opened to advance it to Released, again with a template. That one is merged when the requirements are met and the relevant team has consensus, and no FCP is required. When it is merged as Released, a third pull request is automatically opened to advance it to Recommended, and this one does require a Final Comment Period to merge.

So an accepted RFC generates a chain of tracked pull requests, and each one carries a checklist of what has to be true. The commitment to stability is the interesting requirement, because it is a promise about the future rather than a description of the present.

Merged RFCs can also move to Discontinued at any point via a pull request, which is done when the RFC is no longer relevant or the feature is no longer supported. That the repository keeps this door open is a sign of how the process handles a framework that lives for more than a decade.

## How to follow an RFC without reading the whole repository

The README's most practically useful section is a set of saved GitHub search queries, one per stage, so you can watch the process without subscribing to every pull request.

There is a listing for proposed RFCs, filtered on the S-Proposed label and sorted by most recently updated, and one for exploring RFCs on S-Exploring. Then there are three for advancing RFCs: pull requests to advance to Ready for Release, to advance to Released, and to advance to Recommended. Finally there are two time-sensitive ones, RFCs in Final Comment Period for any Stage, and RFCs in FCP to close.

That last pair is the practical one to bookmark. An FCP is the only stage with a hard deadline, and an FCP to close is the rarer and more consequential of the two, since it means a proposal that was well developed is being shut down rather than shipped.

For reading rather than tracking, the RFC website at rfcs.emberjs.com shows the current state and text of all RFCs in Accepted or later stages. The distinction is deliberate: proposals under discussion live in pull requests, and only what has been agreed gets published as a document.

The README also links to a stages/ directory and a teams/ directory in the repository, and the table of contents lists a section on relevant teams and a reference section explaining Final Comment Periods in more detail, including how FCP to close works.

## Creating one: gather feedback first, then find a champion

The creating section is where the process puts its costs on the table, and it is worth reading the table of contents entries in order, because the sequence matters.

The first entry is when you need to follow this process, which is the natural first question. The second is gathering feedback before submitting an RFC, which tells you that the repository expects you to have already had the conversation somewhere else. The third is the process itself, and under it there are two subsections: how to create a new RFC, and finding a champion.

A champion is the person who carries the proposal through the stages, and the existence of that requirement is the real gate in this process. Anyone can open a pull request from a template, but a proposal without a champion has nobody to answer the review comments, nobody to negotiate the Final Comment Period, and nobody to notice when the implementation stalls. The repository also points at a Reference section naming the relevant teams, which tells you which group of core team members has to agree for a given kind of change.

The templates are the entry mechanism. New proposals are submitted as pull requests using one of the RFC templates, depending on what the RFC is proposing, and the top-level 0000-template.md is that starting point. The separate deprecation-template.md exists because removals are treated as their own kind of decision rather than as an ordinary change, which matches the description of Discontinued as a stage for work that was once agreed and now is not.

There is also a section on implementing an RFC and one on editing merged RFCs, which covers the case where an accepted document turns out to contain an error worth fixing after the fact.

## What the repository does not contain, and who decides what

A few things are worth stating plainly about the scope of this repository, because the name invites confusion.

It holds no framework code. There is no build script, no package manifest, and no compiled artefact, and the repository has no GitHub releases. The primary language is not even recorded, which is consistent with a repository whose contents are Markdown documents and templates.

What it holds is a procedure, expressed as a stage ladder, a set of label-filtered search queries, a table of contents that names every sub-process, and two templates. It is a governance artefact, and its value is that it is short enough to read in an hour and specific enough to copy.

The decision-making body is described as the core teams, and the process refers to the relevant core teams and to the agreement of those teams for particular advances. The reference section points to a section naming the relevant teams, and the teams/ directory in the repository presumably holds those details.

The licence is not recorded for the repository, which is unusual for a project of this size and worth checking directly in the repository before reusing any of the text. The last push was on 2026-10-19, the repository is not archived, and the site is published at rfcs.emberjs.com, so the process described here is one being followed right now rather than a historical document.

## Conclusion

Adopt this process as a reference if you maintain a framework that needs a written path for substantial changes, since the stage ladder and the final comment period are well documented and free to copy. Do not look to the repository for an Ember API, since it contains proposals and templates rather than code. Before you file a proposal, check the two stage listings in the README to see whether a similar RFC is already in Exploring, decide whether your change is substantial enough to need the process at all, and read the deprecation template before you assume a removal can happen through an ordinary pull request.

## FAQ

### What are the stages an Ember RFC goes through?

Proposed, Exploring, Accepted, Ready for Release, Released and Recommended, numbered 0 to 5. Two further statuses exist for proposals that stop: Discontinued for a previously Accepted RFC that conflicts with the evolving programming model or is superseded, and Closed for Proposed RFCs that will not advance.

### Which Ember RFC stages require a final comment period?

Entering Accepted, Ready for Release and Recommended requires an FCP. Proposed, Exploring and Released do not, since the Released stage is merged once the requirements are met and the relevant team has consensus.

### Who can submit an RFC to the Ember framework?

Any member of the community can create one, by opening a pull request from one of the RFC templates. The README also asks that feedback be gathered before submitting, and the process calls for finding a champion to carry the proposal.

### Where can I read all accepted Ember RFCs?

The RFC website at rfcs.emberjs.com shows the current state and text of all RFCs in Accepted or later stages. RFCs still under discussion stay as pull requests in the repository.

## Sources

- [emberjs/rfcs on GitHub](https://github.com/emberjs/rfcs)
- [Issues](https://github.com/emberjs/rfcs/issues)
- [Project website](https://rfcs.emberjs.com/)
- [README](https://github.com/emberjs/rfcs/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/emberjs-rfcs