TC39: A Process Sketch, Stages 0 and 1

This week, I asked on Twitter what TC39-related topics, people wanted me to talk about on this blog. Julia Evans (@b0rk) threw a bunch of questions at me, and I'll try to answer them one at a time.

Do you have to implement the future of JavaScript before you decide on it?

This is, more or less, a question about the process of adding new features to JavaScript.

Just a few years ago, the process was big and bulky, and led to a 5-year design process for ES2015, most of which wasn't implemented at all before the spec was approved.

Since then, TC39 has adopted a staged process, allowing the interplay of spec development and implementation. Dave took a stab at explaining it once on Twitter and I'll try and flesh it out a bit. I'll also include information from the official TC39 process document.

When Rafael Weinstein presented the proposal for the new staged process, he identified two areas that could use improvement: that spec revisions were driven by dates rather than progress, and that the development process was informal. Once I get through explaining how the current process works, I'll come back to these points and explain how the current process addresses them.

Stage 0

Official description: "Straw Man: Allow input into the specification"

When a member of TC39 is interested in starting the process of adding a feature to the specification, they start by presenting to the committee with a motivation and basic straw man, usually in slideshow form.

There are no valid reasons to object to Stage 0: it simply indicates that a member of the committee has notified the committee about the basic shape of the feature.

This stage is also the best place for new contributors to the spec. If you're interested in proposing a feature, find a member of TC39 to help you put together a presentation, get them to add it to the agenda, and attend the next committee meeting as their guest. Stage 0 will be yours.

The TC39 proposals repository contains a document listing all of the active Stage 0 proposals.

If the feature is transpiled or polyfilled at this stage, it's done by the person working on the proposal itself: Stage 0 proposals aren't fleshed out enough (and do not contain enough spec text) for a third party to attempt implementation. Using a Stage 0 implementation means you are helping to develop the feature and it is virtually certain to change significantly as it makes its way through the process.

Stage 1

Official description: "Proposal"

This is the point where you'll need to make a real argument for the feature and flesh out the solution more. This stage doesn't require formal spec text (although people will often write some anyway).

To get approval for Stage 1, the feature needs an official "champion", responsible for the feature moving forward through the rest of the spec process.

The champion (or champion group) is a key part of the TC39 process (and predates the current formal process). It is a key way that TC39 mitigates the dreaded "design by committee" problem. Champions do the design work for a feature, and the committee typically defers to champion expertise for many of the fine details of the process. This works because effective champions identify members of the committee with deep interest in the proposal, and do legwork ahead of time to make sure that the concerns of interested members are identified and incorporated into the proposal.

Stage 1 is also the point where the proposal is expected to have identified cross-cutting concerns, interactions with other proposals, and implementation concerns.

The proposal itself should be relatively fleshed out: the process requires "discussion of key algorithms, abstractions and semantics," "illustrative examples of usage," and "high level API."

In practice, there are very few reasons for TC39 to reject "Stage 1" for a given feature, as long as the committee "expects to devote time to examining the problem space, solutions and cross-cutting concerns."

The committee will often advance a feature to Stage 1 while noting that there are strong objections from committee members, or identifying difficult challenges that the champion should address before coming back for Stage 2.

In practice, almost any request for Stage 1 will be approved, both because the requirements are light, and because champions ask for advancement once the feature is far enough along that it has a recognizable shape.

People often attempt to transpile or polyfill features at this stage, but the spec is usually missing enough detail that implementation attempts require close coordination with the champions, and almost always end up influencing the spec text presented for Stage 2. Using a Stage 1 implementation means you're helping to user test the feature and flesh out edge cases. It is still virtually certain to change significantly as it makes its way through the process.

Stay tuned for Stages 2, 3 and the series finale, Stage Four.