TC39 accepts changes through two processes--the four-stage proposal process and pull requests. Staged proposals are governed by the process document, whereas pull requests are lighter-weight, working through informal rules and conventions, as administered by the editor. This document attempts to codify a process for pull requests, mostly through writing down current practice (to help others follow along what's happening, and to help the next editor if there is a transition), but a change from current practice is included in bold.
Algorithm for getting a PR merged:
- If the PR is purely editorial or to support layering, tag it as 'editorial' or 'layering'.
- Otherwise, tag it as 'normative', as it makes an observable semantic change.
- If the PR is about reflecting what some web browsers' behavior is, tag it as 'web reality'.
- Get consensus on the PR. If this is difficult or time-consuming, mark 'needs consensus' as it is gaining consensus.
- If the PR is tagged 'editorial' or 'layering',
- Merge the PR.
- Else,
- Write a matching PR for test262 tests for the normative web-reality change.
- If the PR is also tagged 'web reality': 1. Assert: The tests pass on at least one implementation.
- Else, 1. Tag as 'awaiting implementation'. 1. Create an implementation which passes the new tests.
- Merge the spec PR and the test PR.
- Draw attention to the change as appropriate, e.g., in a changelog and/or announcement at TC39
Achieving conseus: PRs can achieve consensus on GitHub or in TC39.
- On GitHub, for non-trivial changes, to be considered consensus, the thread should get the review of people who have worked on/provided input to that part of the specification. If the change requires action by implementations, then implementers who are active in TC39 should also have their review solicited. If it's not possible to get sufficient feedback from these people via GitHub, or agreement can't be reached, take it to TC39.
- The in-person meeting at TC39 typically has the necessary people present to reach consensus.