tc39/proposals: stage 3 is not a schedule, and the test262 column is where the truth is

The active list is stage 2 and above, and stage 2 is defined as expectation

The Active proposals section states its own filter before it states anything else. This list contains only stage 2 proposals and higher that have not yet been withdrawn or rejected, or become finished. Stage 2 is then given a definition in one sentence: it indicates that the committee expects these features to be developed and eventually included in the standard.

Expects is doing the work in that sentence. It is not a commitment, not a date, and not a compatibility promise, and the repository offers nothing that would turn it into one. There are no releases in this repository, and the last push was 2026-10-14, so what you get is a snapshot of a moving board.

The exclusion is the other half of the rule. Anything withdrawn, rejected, or finished is out of this list, and it has not been deleted: it has been moved. That is why the repository has separate files for stage 0, stage 1, finished and inactive proposals, rather than one list with strikethroughs.

The test262 column has four different states, and one row says no tests exist

The stage 3 table has five columns: Proposal, Author, Champion, a Test262 Feature Flag column, and Meeting Notes. The test262 column is the one that reports reality rather than process, and it is not uniform.

Some rows have a feature flag, which means a named flag exists in the conformance test suite: legacy-regexp for Legacy RegExp features in JavaScript, source-phase-imports for Source Phase Imports, import-text for Import Text, nonextensible-applies-to-private for Non-extensible Applies to Private, and import-defer for Deferring Module Evaluation, which also links a testing plan. Other rows have no flag at all but a linked test work item: Dynamic Code Brand Checks says No test262 tests, and Error Stack Accessor and RegExp Buffer Boundaries point at a tests PR.

That is four distinct states, and the difference matters. A feature flag is the strongest signal in the table, a testing plan is a plan, a test pull request is work in flight, and No test262 tests is an absence. Dynamic Code Brand Checks has meeting notes going back to 2019-07 and still has no flag, which is exactly the kind of gap the stage number alone would hide from you.

Meeting notes count is an age proxy, and the oldest row spans ten years

Every row links the meetings where the proposal was discussed, and the count and the dates differ enormously.

Legacy RegExp features in JavaScript has seven meeting notes, running from 2016-09 through 2017-03, 2017-05, 2023-07, 2024-06 and most recently 2026-01. Source Phase Imports has nine, from 2023-03 to 2026-05. Deferring Module Evaluation has eleven, from 2021-01 to 2026-07. RegExp Buffer Boundaries has six, from 2021-10 to 2026-05. Error Stack Accessor has four, from 2025-02 to 2026-05.

At the other end, Import Text has two notes, 2025-11 and 2026-03, and Non-extensible Applies to Private has three, 2025-04 through 2025-09. So the direction of travel is the opposite of what the note count suggests: few notes means recent, many notes spread over years means long. And the notes are the only public record of the deliberation, since the repository has no discussion archive of its own beyond the links in this table.

Author and champion are separate columns, and they differ on most rows

Two columns carry names, and they are not the same job. The Author column credits the people who wrote the proposal. The Champion column names the people answerable for moving it through the process.

Looking across the rows, the split is informative. Import Text lists Eemeli Aro as author and as the sole champion. Legacy RegExp features in JavaScript has Claude Pache as author, with Mark Miller and Claude Pache as champions. Deferring Module Evaluation has Yulia Startsev and Guy Bedford as authors, with Nicolò Ribaudo as the sole champion, so the proposal is championed by someone outside its author list. Error Stack Accessor has Jordan Harband as author with Jordan Harband and Mark Miller as champions. Await Dictionary lists Alexander J. Vincent as author.

Non-extensible Applies to Private is the widest row, with Mark Miller, Shu-yu Guo, Chip Morningstar and Erik Marks in both columns. So when you want to know who to follow for a proposal, the champion column is the answer, not the author column.

Four stage files and an inactive file mean nothing is deleted

The links at the top of the README are the repository's entire structure: Stage 0 Proposals, Stage 1 Proposals, Finished Proposals and Inactive Proposals, each in its own markdown file, plus the proposals for the ECMAScript Internationalization API Specification under an ecma402/ directory.

The top level confirms it. Apart from .github/, CODE_OF_CONDUCT.md, CONTRIBUTING.md and the README itself, everything is those four markdown files and the ecma402 directory. There is no code, no build, and no release.

Keeping inactive proposals is the decision that makes this repository useful as history rather than only as a queue. A feature that was worked on and then dropped is still readable, in the same format as one that shipped, so the record of what the committee tried is as accessible as the record of what it accepted. For anyone deciding whether a proposal has been attempted before, the inactive file is as important as the active list.

The process rules are linked from two domains and live outside the repository

The README says proposals follow the process document and links it. The repository metadata points its homepage at tc39.github.io/process-document/, while the README text links to tc39.es/process-document/. Two domains for the same rules.

That detail matters more than it looks. The document that defines what each stage means, what the committee expects, and what a champion owes is not vendored into this repository, so it can change without a commit here. Nothing in the five markdown files is authoritative about the process; they are authoritative about what the committee did, and they defer on the rules.

The README is not self sufficient by design. It names the specification repository, tc39/ecma262, as the place the normative text lives, and this repository as the place proposals are tracked. A reader who wants to know whether a feature exists today, as opposed to whether it is being worked on, has to follow the first link, not stay in the second.

No releases, no recorded license, and the newest stage 3 rows are the small ones

There is no version to track here. The repository has no GitHub releases, its top level contains no licence file, and no licence is recorded for it, which is consistent with a repository whose contents are meeting links, spec references and lists rather than code you would depend on.

The maintenance signal is the commit date, and the last push was 2026-10-14, so the board is current. What that date does not tell you is which row is moving. Reading the table for activity rather than for stage gives a different answer from reading it for stage: the row with the most recent notes is Deferring Module Evaluation at 2026-07, followed by Source Phase Imports at 2026-05, Dynamic Code Brand Checks at 2026-05, RegExp Buffer Boundaries at 2026-05 and Error Stack Accessor at 2026-05, while Non-extensible Applies to Private stops at 2025-09 and Legacy RegExp at 2026-01.

So a stage 3 proposal can be dormant. The stage says the committee expects it to be developed; the note list says whether anyone is.

Editorial conclusion

Use tc39/proposals if you need to know whether a JavaScript feature is real, how far along it is, and who is accountable for it, because the stage table carries authors, champions, a test262 status and a link to every meeting where it was discussed. Do not read a stage number as a delivery date, since stage 2 is defined in the README as the committee expecting a feature to be developed and eventually included, which is a statement of intent rather than a commitment. Check four things before you plan around a feature: the test262 column, because a feature flag, a test pull request, a testing plan and an explicit absence of tests are four different states and the row will tell you which one you have; the meeting notes, since the oldest entry in the table has been revisited across ten years of meetings while the newest has two notes; the champion column rather than the author column, since those two columns differ on most rows; and the process document itself, because it is linked from the README and hosted outside this repository, which has no releases, no recorded license and a top level made of markdown files.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. tc39/proposals on GitHub