minor corrections (#39)

index.html

@@ -30,7 +30,7 @@ <h1>The TC39 Process</h1>
 
 <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>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 six stages: a strawperson stage and five “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>.
 
@@ -158,7 +158,7 @@ <h2>Spec revisions and scheduling</h2>
 <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>March TC39 Meeting: stage 4 proposals are incorporated, final semantics are approved, and the new spec version is branched from <code>main</code>. 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>
@@ -169,7 +169,7 @@ <h2>Status of in-process additions</h2>
 
 <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.
+<p>At stages 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>
 
@@ -179,7 +179,7 @@ <h2>Reviewers</h2>
 
 <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.
+<p>When an addition is accepted at stage 3, the committee is signifying that it believes design work is complete and further refinement will require implementation experience, significant usage, and external feedback.
 
 <h2>Tips for achieving consensus</h2>
 
@@ -227,7 +227,7 @@ <h2>Scope of Responsibility for Champions</h2>
 
 <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.
+<p>During stage 2.7, <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>