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

 

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
    1. Proposal
    2. Working Draft
    3. Candidate Draft
    4. 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
Made with Slides.com