tc39
Add language to identify risk areas for a proposal
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?
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.
@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).
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.