Post-ES6 Spec Process
Rafael Weinstein
Dmitry Lomov, Sept 2013
https://slid.es/rafaelweinstein/tc39-process
Status quo for ES additions
-
Committee is the sole steward
- Consensus-based
- Additions driven by champions
- Community is heavily involved
- Spec revisions are date-driven
- Informal development process
Most of this is good
- Language evolved as a cohesive whole
- Committee is the sole steward of ES
- Consensus-based
- Additions driven by champions
- Community is heavily involved
- Spec revisions are date-driven
- Informal development process
- Language evolved as a cohesive whole
- Committee is the sole steward of ES
- Consensus-based
- Additions driven by champions
- Community is heavily involved
- Spec revisions are date-driven
- Informal development process
Problem: Date-driven revisions
Long time between revisions
"Making" the next revision is high-stakes
Feature creep
Delays
Problem: Date-driven revisions
-
Inevitably contain additions of varying maturity.
- Mature/stable additions are delayed by large and/or later developed ones.
- Less mature/stable additions face undue pressure to finalize.
Problem: Informal process
-
Acceptance occurs before many details are sorted out
-
Implementers lack clear signals of maturity
- Increases implementers’ risks
-
Spec writing is the burden of the editor
Solution
- Decouple additions from dates (specific revisions)
- Revise spec annually
- When addition is complete, it goes into next revision
- Formalize stages of maturity
- Clear criteria at each stage
- Clear significance for acceptance
Non-goals
-
Componentize the spec or the language
-
Change the rate of evolution
Process
-
Maturity Stages
- Proposal
- Working Draft
- Candidate Draft
- Last Call Draft
- TC-39 sends a new Final Draft to ECMA every September.
- Additions which have been accepted as Last Call drafts can be included
Stage 1: Proposal
-
Making the case for addressing the problem
-
Describing the general shape of a solution
Proposal: Criteria
-
Prose outlining the problem or need and the general shape of a solution
-
Illustrative examples of usage
-
High-level API
-
Discussion of key algorithms, abstractions and semantics
-
Identification of potential “cross-cutting” concerns and implementation challenges/complexity
-
An identified “champion” who will move the proposal towards a Working Draft.
Proposal: Acceptance Signifies
-
The problem or need warrants a solution and the attention of the committee
-
The proposed solution appears workable and worth developing further
-
The committee expects to devote time to examining the problem space, solution and cross-cutting concerns
Stage 2: Working Draft
-
Detailed solution
-
Initial spec
Working Draft: Criteria
-
Draft spec text (relative to latest final draft) for all major semantics and syntax (some TODOs, placeholder prose and editorial issues are expected)
-
An identified "champion" who will move the draft towards a Candidate.
Working Draft: Acceptance Signifies
- The committee has accepted the addition as a work item with the expectation that it be fully developed into a language feature.
Stage 3: Candidate Draft
-
Needs implementations
Candidate Draft: Criteria
- Complete spec text for all semantics and syntax
Candidate Draft: Acceptance Signifies
-
The committee feels that the solution is complete and no further work is possible without implementation experience and developer feedback
-
The spec is ready for experimental implementations
Stage 4: Last Call Draft
- Finalized spec
Last Call Draft: Criteria
-
Spec text reflects all changes made in response to implementation and developer feedback
-
Suite 262 acceptance tests have been authored for mainline usage scenarios
-
Two implementations pass the acceptance tests
-
All outstanding objections have been addressed to the committee's satisfaction
Last Call Draft: Acceptance Signifies
- TC-39 recommends the feature, as specified, for inclusion in the ECMAScript standard
- Implementers expected to ship the feature as specified
- The feature will be scheduled for inclusion in the next available spec revision
Mechanics: Feature dependencies
- The committee is responsible for considering additions in light of each other and existing semantics
- The committee can require two or more additions either be joined, tracked together through the process or serialized
Tooling: Managing the spec?
- Branches or “Feature Flags”
- Hybrid?
- Develop more spec writing competency
Post -ES6 Spec Process Rafael Weinstein Dmitry Lomov, Sept 2013 https://slid.es/rafaelweinstein/tc39-process