2025 proposal selection process

[nairnandu]

Based on the retrospective and feedback from proposal authors, this is a draft of the 2025 proposal review process to be reviewed by the team

[dandclark]

Is there a "neutral" vote option implied here as well, or is that effectively what the "Low priority" vote means?

For example, if an organization chooses not to place a vote on a given proposal, is that interpreted as if they'd voted "Low priority"? Or is there a difference in how these are recorded such that voting "Low priority" is a slightly more positive signal than "abstain"?

[nairnandu]

It's the latter. "Low priority" is meant to be a slightly more positive signal (an openness for further discussion or to review additional data points).

[dandclark]

This voting process looks like it's effectively another iteration of the Phase 2 process, but without using the "High/Low priority" terminology.

Are there any actual procedural differences? If not perhaps the same terminology should be reused to prevent confusion.

[nairnandu]

Makes sense to clarify. In a procedural sense, the High/Low signals from round 2 will carry forward into round 3. Organizations will have the option to change that signal in round 3.

[dandclark]

This should be clearer about how carryover evaluation works. If there is no consensus on whether or not to carryover a given proposal, is it default-carryover or default-discard?

[jgraham]

Based on the feedback from last year, going forward I think we'll have more success if we're more successful at developing a shared understanding of value proposition of different proposals, and where we have room for discussion. Of course that won't always work, but I'd like the process to focus on finding those points of agreement and ensuring that as far as possible we end up with a shared consensus.

With that in mind, here's a different take on what the process could be:

1. After the proposal deadline each participating org shares a list of focus areas they'd like to champion. Those can correspond to one or more proposals. Where different orgs have similar focus area proposals they can work together out of band to develop one proposal, but in each case there should be one primary champion for later rounds. It's also OK to drop proposals at any stage if no one wants to champion it further.
2. Champions work on their focus areas, gathering evidence that the focus area represents an Interop priority (e.g. bug reports, developer feedback, positive platform impact on areas like a11y; we can discuss what people would like to see in advance). They are also responsible for ensuring the focus area has an identified set of tests. We do this in a shared space so that non-champions can provide feedback if desired (e.g. point to relevant standards-positions).
3. We have a fixed amount of f2f time (e.g. 15 minutes per participant over two meetings) to formally present the focus area proposals and explain why they're considered a priority for Interop.
4. We have some time for further async adjustments e.g. if there's feedback like "we like X, but can't support it with subfeature Y, please remove that".
5. Each participant now buckets the final proposals as P1, P2, P3 or "veto".
6. A successful outcome at this point looks like lots of proposals where orgs have given similar rankings, and few vetos. We sort by the buckets and pick focus area proposals with lots of P1/P2 rankings.

Some notes:

1. There is no formal elimination stage. It's up to participants to not champion proposals that don't meet the requirements to be accepted.
2. There's no limit on the number of proposals you can champion. It's up to individual orgs whether they'd prefer to put more time into fewer proposals or less time into more proposals. But at the presentation stage you get a fixed time to explain to others why you consider each proposal an Interop priority. This reflects the fact that time is the actual limited resource (both for decision making and implementation).