Stage 2: Userland Early Adoption— Dave Herman (@littlecalculist) July 31, 2015
Official Description: "Draft"
In my experience, this is where the real action for a feature lives. This is the point where a champion for a feature gains consensus that the feature will make it into the spec in something similar to its current form.
That doesn't mean that Stage 2 proposals always make it into the spec in practice, but it is a strong commitment on the part of the committee to continue working on the proposal, absent a significant context shift.
An example of a feature that made it to Stage 2 but never made it into the final spec is
Formally, a Stage 2 proposal is an initial draft of reasonably complete spec text ("all major semantics, syntax and API are covered, but TODOs, placeholders and editorial issues are expected").
It's also the point where it's reasonable to consider using implementations (either transpiled/polyfilled implementations or implementations in engines) in real applications.
Using a Stage 2 implementation means you're still helping to test out the feature, but with reasonable confidence that the core functionality will eventually make it into the spec.
It's still not risk-free, and will likely change in some form as the process continues. That said, updating your use of the mainstream scenarios in a feature after this point should usually be incremental.
As an example, the decorators proposal changed significantly between Stage 1 and Stage 2 in response to feedback from early adopters, but we do not expect very significant changes to the shape of the feature as it continues.
At a high level, Stage 0 is about notifying the committee that you plan to work on a feature, and Stage 1 is about fleshing out the feature enough for champions to start doing implementation work.
In contrast, Stage 2 is a stronger commitment by the committee to working on feature and the approximate shape of the feature.
Next up, Stage 3!