Document the Interop 2023 proposals process for the public #115
Conversation
Co-authored-by: Rachel Andrew <[email protected]>
|
Thanks for the edits @rachelandrew, much nicer now :) |
| @@ -0,0 +1,31 @@ | |||
| name: Proposal | |||
| description: Proposal for feature to include in Interop 2023 | |||
There was a problem hiding this comment.
I wonder if it makes sense to have a separate issue template for investigation proposals, asking for more things like "what is the proposed outcome of this investigation effort, what is being investigated, etc"
| @@ -0,0 +1,40 @@ | |||
| name: Proposal | |||
| description: Proposal for feature to include in Interop 2023 | |||
There was a problem hiding this comment.
We usually use the term "focus area" rather than "feature". I notice that you're using "feature" all the way through here, and I guess a 1:1 mapping is the commonest case, but it's not the general case e.g. webcompat isn't a single feature, and the "Typography and Encodings" focus area from last year wasn't a single feature (although that was a later merge of several proposals).
There was a problem hiding this comment.
I didn't make a conscious decision on this, but overall tried to use wording that'd be easier to parse for web developers, written more from the outside than the inside perspective.
I don't have a strong opinion on this one, but do you think it'd be fine to talk about feature (singular) and just let people propose things that aren't strictly a single feature anyway? Or maybe we talk about "feature or group of features"? I think "focus area" might require explanation to be understood.
|
|
||
| - Only features which have high quality specifications and tests are in scope. Interop 2023 is not a venue for specifying new features, that work happens in working groups within organizations such as W3C and WHATWG. | ||
| - Interop 2023 is not a process for making browser vendors work on things they're opposed to. Decisions are made by consensus, so highly contentious features are unlikely to be accepted. | ||
| - Even great proposals may ultimately not be accepted, since we have to prioritize. |
There was a problem hiding this comment.
I'm not sure this bullet is adding much value, but it does feel like it's adding a lot of stop energy. Maybe it would sound less negative to fold it into the previous bullet point and added some positive advice: ", so highly contentious features are unlikely to be accepted, and vendors will also consider the priority of proposals against other possible work. Proposals accompanied by strong rationale (e.g. evidence of problems affecting real sites, or significant developer interest) are more likely to succeed."
There was a problem hiding this comment.
I'm fine with whatever wording others are happy with here. The purpose of this was to avoid disappointment if we end up not accepting some good proposals from "external" contributors who put in a lot of work.
.github/ISSUE_TEMPLATE/proposal.yml
Outdated
| - [W3C](https://www.w3.org/) (Recommendation Track) | ||
| - [WHATWG](https://whatwg.org/) | ||
|
|
||
| Other specifications will be considered on a case-by-case basis. |
There was a problem hiding this comment.
Per meeting discussions, remove this since anyone who might have a proposal that requires the exception, and which has a reasonable chance of being accpeted, is probably close enough to the project that they know why the other rules don't apply in this specific case.
Co-authored-by: Simon Pieters <[email protected]>
Co-authored-by: Simon Pieters <[email protected]>
|
Based on the "Could we land this PR with a note to say it's not totally finalised?" comment in #128 (comment) I'm going to add this disclaimer to README and issue template:
|
No description provided.