-
Notifications
You must be signed in to change notification settings - Fork 18
Expand file tree
/
Copy pathindex.html
More file actions
224 lines (171 loc) · 15.3 KB
/
index.html
File metadata and controls
224 lines (171 loc) · 15.3 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
<!DOCTYPE html>
<meta charset="utf-8">
<style>
html {
font-family: sans-serif;
}
th, td {
vertical-align: top;
border: 1px solid black;
padding: 0.4em;
}
table {
border-collapse: collapse;
}
ul {
padding: 0 1.5em;
margin: 0;
}
</style>
<title>The TC39 Process</title>
<h1>The TC39 Process</h1>
<p>The Ecma <a href="https://www.ecma-international.org/memento/tc39.htm">TC39</a> committee is responsible for evolving the ECMAScript programming language and authoring the specification. The committee operates by consensus and has discretion to alter the specification as it sees fit. However, the general process for making changes to the specification is as follows.
<h2>Stages</h2>
<p>Changes to the language are developed by way of a process which provides guidelines for evolving an addition from an idea to a fully specified feature, complete with acceptance tests and multiple implementations. There are five stages: a strawperson stage, and 4 “maturity” stages. The TC39 committee must approve acceptance for each stage.
<p>Proposals at stage 1 and beyond should be owned by the TC39 committee. Upon proposal acceptance, any externally-owned repositories should be transferred by following the <a href="https://github.com/tc39/proposals#onboarding-existing-proposals">onboarding instructions</a>.
<table>
<caption>ECMAScript Proposal Stages</caption>
<thead>
<tr>
<th>Stage
<th>Purpose
<th>Entrance Criteria
<th>Acceptance Signifies
<th>Spec Quality
<th>Post-Acceptance Changes Expected
<th>Implementation Types Expected*
</tr>
</thead>
<tr>
<td>0
<td>Allow input into the specification
<td>None
<td>N/A
<td>N/A
<td>N/A
<td>N/A
</tr>
<tr>
<td>1
<td>
<ul>
<li>Make the case for the addition
<li>Describe the shape of a solution
<li>Identify potential challenges
</ul>
</td>
<td>
<ul>
<li>Identified “champion” who will advance the addition
<li>Prose outlining the problem or need and the general shape of a solution
<li>Illustrative examples of usage
<li>High-level API
<li>Discussion of key algorithms, abstractions and semantics
<li>Identification of potential “cross-cutting” concerns and implementation challenges/complexity
<li>A publicly available repository for the proposal that captures the above requirements
</ul>
</td>
<td>The committee expects to devote time to examining the problem space, solutions and cross-cutting concerns
</td>
<td>None
<td>Major
<td>Polyfills / demos
</tr>
<tr>
<td>2
<td>Precisely describe the syntax and semantics using formal spec language
<td>
<ul>
<li>Above
<li>Initial spec text
</ul>
</td>
<td>The committee expects the feature to be developed and eventually included in the standard
<td>Draft: all <em>major</em> semantics, syntax and API are covered, but TODOs, placeholders and editorial issues are expected
<td>Incremental
<td>Experimental
</tr>
<tr>
<td>3
<td>Indicate that further refinement will require feedback from implementations and users
<td>
<ul>
<li>Above
<li>Complete spec text
<li>Designated reviewers have signed off on the current spec text
<li>All ECMAScript editors have signed off on the current spec text
</ul>
</td>
<td>The solution is complete and no further work is possible without implementation experience, significant usage and external feedback.
<td>Complete: all semantics, syntax and API are completed described
<td>Limited: only those deemed critical based on implementation experience; must receive committee consensus
<td>Spec compliant
</tr>
<tr>
<td>4
<td>Indicate that the addition is ready for inclusion in the formal ECMAScript standard
<td>
<ul>
<li>Above
<li><a href="https://github.com/tc39/test262">Test262</a> acceptance tests have been written for mainline usage scenarios, and merged
<li>Two compatible implementations which pass the acceptance tests
<li>Significant in-the-field experience with shipping implementations, such as that provided by two independent VMs
<li>A pull request has been sent to <a href="https://github.com/tc39/ecma262">tc39/ecma262</a> with the integrated spec text
<li>All ECMAScript editors have signed off on the pull request
</ul>
</td>
<td>The addition will be included in the soonest practical standard revision
<td>Final: All changes as a result of implementation experience are integrated
<td>None
<td>Shipping
</tr>
</table>
<p>* This column does not indicate a requirement for advancement, but simply a general expectation.
<h2>Input into the process</h2>
<p>Ideas for evolving the ECMAScript language are accepted in any form. Any discussion, idea, or proposal for a change or addition which has not been submitted as a formal proposal is considered to be a “strawperson” (stage 0) and has no acceptance requirements. Such submissions must either come from TC39 delegates or from non-delegates who have <a href="https://tc39.github.io/agreements/contributor">registered</a> via Ecma International.
<h2>Spec revisions and scheduling</h2>
<p>TC39 intends to submit a specification to the ECMA General Assembly for ratification in July of each year. The following is an approximate timeline for producing a new spec revision:</p>
<ul>
<li>February 1: Candidate Draft is produced.</li>
<li>February - March: 60 day royalty-free opt-out period.</li>
<li>March TC39 Meeting: stage 4 proposals are incorporated, final semantics are approved, and the new spec version is branched from master. Only editorial changes are accepted from this point forward.</li>
<li>April-June: ECMA CC and ECMA GA review period.</li>
<li>July: Approval of new standard by the ECMA General Assembly</li>
</ul>
<h2>Status of in-process additions</h2>
<p>TC39 will maintain a list of in-process additions, along with the current maturity stage of each, <a href="https://github.com/tc39/ecma262">on its GitHub</a>.
<h2>Spec text</h2>
<p>At stages “draft” (stage 2) and later, the semantics, API and syntax of an addition must be described as edits to the latest published ECMAScript standard, using the same language and conventions. The quality of the spec text expected at each stage is described above.
<h2>Reviewers</h2>
<p>Anyone can be a reviewer and submit feedback on an in-process addition. The committee should identify designated reviewers for acceptance during the “draft” (stage 2) maturity stage. These reviewers must give their sign-off before a proposal enters the “candidate” (stage 3) maturity stage. Designated reviewers should not be authors of the spec text for the addition and should have expertise applicable to the subject matter. Designated reviewers must be chosen by the committee, not by the proposal's champion.
<p>When reviewers are designated, a target meeting for Stage 3 should be identified. Initial reviewer feedback should be given to the champions two weeks before that meeting to allow for a back-and-forth ahead of the meeting. The target Stage 3 meeting may be delayed by a champion outside of the meeting at a later time if it is not ready.
<h2>Calls for implementation and feedback</h2>
<p>When an addition is accepted at the “candidate” (stage 3) maturity level, the committee is signifying that it believes design work is complete and further refinement will require implementation experience, significant usage and external feedback. Normative changes may only be made with the approval of the committee.
<h2>Tips for achieving consensus</h2>
<p>During the discussion of a proposal any aspect may be discussed. Consensus is given as an indicator of the current stage. Delegates should openly give feedback on proposals, and especially for a proposal for stage advancement where the concern is relevant to the stage. Delegates should raise their concerns early and asynchronously, in order to help the champion resolve any issues.
<p>A delegate may pose a constraint as necessary for advancement. A constraint refers to an desired property of the proposal, accompanied by a rationale. We encourage this to also be done asynchronously in issues, and in incubator calls, as well as in plenary. In this situation, the delegate should expect to work with the champion and other delegates during earlier stages to incorporate their constraint into the solution, and to consider different possible tradeoffs. In general, the earlier a constraint is raised, the better.
<p>Frequently, many different conflicting constraints are posited about proposals, and the committee collectively may make tradeoffs selecting a particular design even though it compromises one or more constraints.
<p>Given that consensus on Stage 3 means "the solution is complete" (i.e., all open design issues have been resolved including anticipated implementation and ecosystem compatibility issues), all TC39 participants should validate the design of proposals they care about before granting Stage 3 consensus. Stage 3 proposals which have fulfilled the acceptance criteria for Stage 4 may not be withheld from advancement unless the issue raised is related to implementation experience or identifies a problem or information which has not previously been discussed by the committee. The intention is to allow implementers to invest in implementations, and maintain the significance of stage 3 in the process.
<h2>In cases where the committee does not come to consensus</h2>
<p>The committee may come to a point where consensus is not reached in committee regarding the feature. In this case, the committee must record a good description of why a proposal did not advance. This should be done both in the meeting notes and within an issue in the proposal's tracker, but not limited to those. This allows us to understand issues in the proposal and similar proposals in a coherent way.
<p>There are two forms that this sometimes takes, the first is the violation of a constraint and the other is colloquially known as a block. Other forms exist but are not discussed directly here.
<p>In the first case, delegates may consider that the violation of a constraint is sufficiently serious reason to withhold their consensus for stage advancement. The dissenting delegate(s) and the champion(s) should work together accordingly to resolve the issue.
<p>Not all issues with proposals are easily solvable. Some issues are too fundamental and serious, requiring a significant rework of the proposal, or may be unsolvable. In these situations, if consensus is withheld, it might be referred to colloquially as a "block". The proposal will require substantial work to address the concern, may need to be rethought all together, or may not have enough justification to pursue at this time.
<p>When possible, it is preferable to raise an actionable constraint. The committee does not have an established concept of a rejected proposal--it is always possible for the champion to make changes and come back to ask for consensus.
<h2>Conditional Advancement</h2>
<p>A delegate may also request additional time to consider the proposal, if a topic they had not considered comes up during discussion. In this case, the delegate should give the champion some actionable request for how to facilitate the analysis (e.g., the champion could walk through the proposal with the delegate offline). In practice, this work should be done during the plenary, or before the next meeting. A delegate may also request additional time to consider the proposal, if it was added to the agenda after the deadline for proposal advancement.
<p>The committee may resolve to <em>conditionally advance</em> a proposal to address a particular well-understood condition offline, e.g., making a particular small specification change concrete, among a group of interested people who have an idea of the solution. Conditional advancement is time-limited, giving the person raising the concern time to discuss with the champions and authors about their concerns. If a proposal has a conditional advancement, an issue must be opened on the proposal’s repository. If the issue is resolved, the proposal automatically reaches the next stage without further discussion by the committee. If the issue cannot be resolved, the proposal does not advance.
<h2>Withdrawing Proposals, Reverting to Earlier Stages, and Adopting Proposals</h2>
<p>At any point in the process, a proposal champion may propose that a proposal be downgraded to an earlier stage or withdrawn. Consensus of the committee is necessary for these transitions. The proposal to make this change must be accompanied by a reason why it is appropriate, e.g., a significant issue that may have not been considered, or identified, before.
<p>If the proposal champion is not available or no longer interested in a proposal, then another committee delegate may volunteer to champion the proposal. From that point on, this other delegate takes over champion duties, and can propose to advance, downgrade, or withdraw the proposal.
<h2>Scope of Responsibility for Champions</h2>
<p>Champions (or, frequently "champion groups" of several members) are authors and editors of proposals. The champion is responsible for the evolution of the proposal from Stage 0 through Stage 4, at which point maintenance transfers to the editor group. Champions have admin permissions in the proposal repository and can freely make changes within this repository. Periodically, champions may bring their proposal to TC39 to ask for consensus on stage advancement.
<p>When asking for advancement, the champion is expected to make the whole proposal accessible for review by the committee, by explaining its contents, providing supporting documentation, etc. Material changes should be presented explicitly.
<p>Although there is no requirement to do so, it is often beneficial for champions to keep the committee updated with periodic status updates explaining major changes. These status updates do not require consensus; consensus is only required for stage advancement. A significant design change may require that the committee has a chance to re-evaluate if the proposal is in the appropriate stage.
</div>
<h2>Test262 tests</h2>
<p>During stage 3, <a href="https://github.com/tc39/test262">test262</a> tests should be authored and submitted via pull request. Once it has been appropriately reviewed, it should be merged to aid implementors in providing the feedback expected during this stage.
<h2>Eliding the process</h2>
<p>The committee may elide the process based on the scope of a change under consideration as it sees fit.
<h2>Role of the editors</h2>
<p>In-process additions will likely have spec text which is authored by a champion or a committee member other than the editors although in some cases one or more of the editors may also be a champion with responsibility for specific features. The editors are responsible for the overall structure and coherence of the ECMAScript specification. It is also the role of the editors to provide guidance and feedback to spec text authors so that as an addition matures, the quality and completeness of its specification improves. It is also the role of the editors to integrate additions which have been accepted as “finished” (stage 4) into a new revision of the specification.