Add language to identify risk areas for a proposal #18
Conversation
ljharb
requested review from
wycats,
bterlson,
littledan,
zbraniecki,
domenic and
a team
|
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. |
|
That's probably a really good idea, but I'd still prefer to show up with most of the issues worked out in advance :-) |
|
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? |
There was a problem hiding this comment.
Glad to see this. I was concerned about "Teachability" which I suppose is covered under "intuitive" 👍
|
@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> | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 :-)
There was a problem hiding this comment.
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.
|
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. |
|
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. |
|
@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). |
|
The escape hatch is that "committee consensus can override the requirement", which is what we have now - I'm not suggesting changing that. |
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?