Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add language to identify risk areas for a proposal #18

Open
wants to merge 2 commits into
base: gh-pages
Choose a base branch
from
Open

Add language to identify risk areas for a proposal #18

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6e4c7ab
Add language to identify risk areas for a proposal
ljharb Jan 16, 2018
da4551f
Committee feedback
ljharb Jan 25, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 15 additions & 1 deletion index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,6 +90,7 @@ <h2>Development</h2>
<ul>
<li>Above
<li>Initial spec text
<li><a href="#risks">Implementation risk areas</a> identified
</ul>
</td>
<td>The committee expects the feature to be developed and eventually included in the standard
Expand Down Expand Up @@ -123,7 +124,7 @@ <h2>Development</h2>
<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>Significant in-the-field experience with shipping implementations, such as that provided by two independent VMs, intended to address identified <a href="#risks">risk areas</a>
<li>A pull request has been sent to <a href="https://github.com/tc39/ecma262">tc39/ecma262</a> with the integrated spec text
<li>The ECMAScript editor has signed off on the pull request
</ul>
Expand Down Expand Up @@ -170,6 +171,19 @@ <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.

<h2 id="risks">Implementation risk areas</h2>

<p>There are many potential risk areas for a proposal. Some examples follow, but the committee may specify additional or modified risk areas, or none, as it sees fit. Implementation risk areas should be identified as part of entrance into stage 2, so that champions can be sure to address these as efficiently as possible.</p>

<ul>
<li>Implementation buy-in: do sufficient engines (including, but not limited to, web browsers) have interest in implementing the proposal? If added to the specification, will all engines implement it?
<li>Web compatibility: this applies in particular for API additions. Does the proposal create a new global identifier? Does it add a string property to a built-in object or prototype that might conflict with user code on the web?
<li>Implementability: can this proposal be effectively implemented and optimized by engines? Does the proposal place significant burden on implementations?
<li>Usability: will the community find the proposal ergonomic/intuitive/useful?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Glad to see this. I was concerned about "Teachability" which I suppose is covered under "intuitive" 👍

</ul>

<p>Note that a specific implementation risk area may impose different criteria on a proposal reaching stage 4. For example, if "web compatibility" is an implementation risk area, then it will likely be deemed necessary for a proposal to be shipping in two (stable, unflagged, non-nightly) web browsers prior to reaching stage 4 - whereas if it is not an implementation risk area, other implementations (nightly/dev/canary web browsers, polyfills, transpilers, non-browser engines, etc) may be enough to satisfy the "Significant in-the-field experience" requirement. To satisfy the "implementation buy-in" risk area, for example, at least one unflagged web browser implementation will likely be deemed necessary for any proposal to reach stage 4.

<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.
Expand Down