WebAssembly
Explicit text about proposal scope, goals as a part of phase 1?
Our current phases process doesn't require discussions or text about proposal scope. Should we explicitly call out scope, and/or goals of a proposal in the phases document, possibly as one of the exit criteria for phase 1?
For some proposals the scope is fairly straightforward (SIMD for example), others could benefit from some explicit documented scope. The advantages of doing so would be:
- For larger, ambiguous problem spaces, having explicit discussions about scope may streamline some of the design discussions
- Useful for newer folks trying to contribute that may not have all the historical context. The context in general is hard to track down as it can be spread across different meetings that are not linked to the relevant issues.
This seems very reasonable and useful to me as an exit criterion for phase 1. Would we just require that scope/goals/requirements are documented and leave it to the CG to interpret that, or would we be more specific about the kind of documentation we would like to see? I'd be fine either way.
Should be no surprise that I agree wholeheartedly. BTW, it is not obvious to me that SIMD's scope is so straightforward!
Agree, calling out goals and non-goals in the overview document will help focus the proposal. It also sounds reasonable for a Phase 1 exit. (The goals and non-goals don't have to be immutable, as proposals advance through the stages there will be more discussion generated and more people involved, and the goals/non-goals should be updated along the way.)
This seems very reasonable and useful to me as an exit criterion for phase 1. Would we just require that scope/goals/requirements are documented and leave it to the CG to interpret that, or would we be more specific about the kind of documentation we would like to see? I'd be fine either way.
I think leaving it to the CG to interpret makes sense to me as it is possible that this would vary for different proposals, just that this is something we should evaluate during phase 1.
Forgot to add cc @RossTate for suggesting this recently.