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.

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
from

Conversation

Projects
None yet
6 participants
@ljharb
Member

ljharb commented Jan 16, 2018

Fixes #17. Preview at http://ljharb.github.io/process-document/

I'm thinking that if we get this text right, we can be sure that a) nothing gets in without at least 1 unflagged browser, and b) anything with web compat risk can't get in without 2 unflagged browsers, and c) anything else is more of a gray area.

#17 is a bit vague; but what I recall from in-meeting discussion was a desire to find a way to more tightly specify the "Significant in-the-field experience" requirement so as to minimize debates about it, while simultaneously being sure that proposals that definitely needed 2 unflagged web browsers got them, and that proposals that didn't need unflagged browsers at all could make it to stage 4 with only a flagged/canary/nightly implementation.

I intentionally tried to pick language that allows us to always use our judgement, so we can continue to debate just as before if needed.

Thoughts?

@ljharb ljharb requested review from wycats, bterlson, littledan, zbraniecki, domenic and tc39/delegates Jan 16, 2018

@mathiasbynens

This comment has been minimized.

Member

mathiasbynens commented Jan 16, 2018

Do we want to discuss this at the upcoming meeting, as a follow-up to the earlier discussion? If so, we should schedule it on day 1.

@ljharb

This comment has been minimized.

Member

ljharb commented Jan 16, 2018

That's probably a really good idea, but I'd still prefer to show up with most of the issues worked out in advance :-)

@littledan

This comment has been minimized.

Member

littledan commented Jan 16, 2018

When we discussed this section at the last meeting, it seemed to me like the committee feeling was to not add any more specific requirements, but instead have more of a conversation about what makes sense on a case-by-case basis. This text could be interpreted to be adding more requirements, such as the expectation that it will be implemented by all engines, or that an unflagged browser implementation is encouraged. It's also linked specifically to the implementation part, whereas requirements which are case-by-case might actually be unrelated to implementations. It might be better to have more general wording.

<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?

This comment has been minimized.

@kentcdodds

kentcdodds Jan 16, 2018

Member

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

@ljharb

This comment has been minimized.

Member

ljharb commented Jan 16, 2018

@littledan The only requirement this adds (as written) is that to enter stage 2, it has to be explicitly called out what the risk areas are likely to be (which is something that's generally known at that time anyways, just not explicitly called out). Beyond that, all it's doing is refining the stage 4 requirement (based on that stage 2 information).

index.html Outdated
@@ -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">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. 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>

This comment has been minimized.

@zbraniecki

zbraniecki Jan 18, 2018

The language of this paragraph seems to be slightly different from what I remember we agreed upon at the last meeting in the area of responsibility.
At the meeting, the language we used is that the champion is responsible for identifying the risk areas and presenting them to the committee which may indicate additional risk areas to be included.

The wording of this paragraph feels a bit like its the committee that identifies the risk areas so that the champion can address them.

I'd also like to suggest to add the risk area verification to the reviewers tasks.

This comment has been minimized.

@ljharb

ljharb Jan 18, 2018

Member

Ah, I borrowed the phrasing from "The committee may elide the process based on the scope of a change under consideration as it sees fit." below.

Since this PR makes "identifying risk areas" a stage 2 requirement, it's automatically on the champion to do so - and the committee has to accept them.

We'll discuss this next week and narrow down the consensus :-)

@zbraniecki

This looks great! I like the tone of the message and recognition of differentiation between risk areas of different proposals.

I'd like to see a bit more on the exact responsibility split between committee, champion and reviewers over stages here, but those can be added later.

@ajklein

This comment has been minimized.

ajklein commented Jan 25, 2018

The "committee feedback" commit addresses some of the feedback brought up in committee, but I'll restate here that I don't think any of this should go into the process doc. Since it adds "optional" requirements, I fear it wouldn't make the Stage 4 decision any clearer, but would just provide another axes to argue over (getting the committee to agree, or not, on which risks apply).

I do think it would be useful in some separate, informative, "tips on championing a proposal" guide.

@ljharb

This comment has been minimized.

Member

ljharb commented Jan 25, 2018

My hope remains that agreeing on the risks is a much easier task than agreeing on what “significant” means. I’ll keep this open and continue iterating on it over time.

@ajklein

This comment has been minimized.

ajklein commented Jan 25, 2018

@ljharb My point is that the reality is that we'd just argue about both "significant" and "risks", due to the escape hatch that you're putting in place (and I don't think it's a good idea to remove that escape hatch, as it means that things could go to Stage 4 despite there being real problems that happened to be identified sometime after Stage 2).

@ljharb

This comment has been minimized.

Member

ljharb commented Jan 25, 2018

The escape hatch is that "committee consensus can override the requirement", which is what we have now - I'm not suggesting changing that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment