The Ecma TC39 committee is responsible for evolving the ECMAScript programming language and authoring the specification. The committee operates by consensus and has discretion to alter the specification as it sees fit. However, the general process for making changes to the specification is as follows.
Changes to the language are developed by way of a process which provides guidelines for evolving an addition from an idea to a fully specified feature, complete with acceptance tests and multiple implementations. There are five stages: a strawman stage, and 4 “maturity” stages. The TC39 committee must approve acceptance for each stage.
| Stage | Purpose | Entrance Criteria | Acceptance Signifies | Spec Quality | Post-Acceptance Changes Expected | Implementation Types Expected* | |
|---|---|---|---|---|---|---|---|
| 0 | Strawman | Allow input into the specification | None | N/A | N/A | N/A | N/A |
| 1 | Proposal |
|
|
The committee expects to devote time to examining the problem space, solutions and cross-cutting concerns | None | Major | Polyfills / demos |
| 2 | Draft | Precisely describe the syntax and semantics using formal spec language |
|
The committee expects the feature to be developed and eventually included in the standard | Draft: all major semantics, syntax and API are covered, but TODOs, placeholders and editorial issues are expected | Incremental | Experimental |
| 3 | Candidate | Indicate that further refinement will require feedback from implementations and users |
|
The solution is complete and no further work is possible without implementation experience, significant usage and external feedback. | Complete: all semantics, syntax and API are completed described | Limited: only those deemed critical based on implementation experience | Spec compliant |
| 4 | Finished | Indicate that the addition is ready for inclusion in the formal ECMAScript standard |
|
The addition will be included in the soonest practical standard revision | Final: All changes as a result of implementation experience are integrated | None | Shipping |
* This column does not indicate a requirement for advancement, but simply a general expectation.
Ideas for evolving the ECMAScript language are accepted in any form. Any discussion, idea or proposal for a change or addition which has not been submitted as a formal proposal is considered to be a “strawman” (stage 0) and has no acceptance requirements. Such submissions must either come from members of TC39 or from non-members who have registered via Ecma International.
TC39 intends to submit a specification to the ECMA General Assembly for ratification in July of each year. The following is an approximate timeline for producing a new spec revision:
TC39 will maintain a list of in-process additions, along with the current maturity stage of each, on its GitHub.
At stages “draft” (stage 2) and later, the semantics, API and syntax of an addition must be described as edits to the latest published ECMAScript standard, using the same language and conventions. The quality of the spec text expected at each stage is described above.
Anyone can be a reviewer and submit feedback on an in-process addition. The committee should identify designated reviewers for acceptance during the “draft” (stage 2) maturity stage. These reviewers must give their sign-off before a proposal enters the “candidate” (stage 3) maturity stage. Designated reviewers should not be authors of the spec text for the addition and should have expertise applicable to the subject matter. Designated reviewers must be chosen by the committee, not by the proposal's champion.
When reviewers are designated, a target meeting for Stage 3 should be identified. Initial reviewer feedback should be given to the champions two weeks before that meeting to allow for a back-and-forth ahead of the meeting. The target Stage 3 meeting may be delayed by a champion outside of the meeting at a later time if it is not ready.
When an addition is accepted at the “candidate” (stage 3) maturity level, the committee is signifying that it believes design work is complete and further refinement will require implementation experience, significant usage and external feedback.
During stage 3, test262 tests should be authored and submitted via pull request. Once it has been appropriately reviewed, it should be merged to aid implementors in providing the feedback expected during this stage.
The committee may elide the process based on the scope of a change under consideration as it sees fit.
In-process additions will likely have spec text which is authored by a champion or a committee member other than the editor although in some case the editor may also be a champion with responsibility for specific features. The editor is responsible for the overall structure and coherence of the ECMAScript specification. It is also the role of the editor to provide guidance and feedback to spec text authors so that as an addition matures, the quality and completeness of its specification improves. It is also the role of the editor to integrate additions which have been accepted as “finished” (stage 4) into a new revision of the specification.