nairnandu: one of the pre-requisites is grouping of proposals. When would that be done?
jgraham: Idea here is that organizations can propose areas that they would like to see as a focus area. There would be time to make adjustments later on, of course.
nairnandu: Is this something the champion would own?
jgraham: the idea is for orgs to share their thinking ahead of time. The champion would be overall owner to do the work for grouping similar proposals and resolving conflicting priorities during the grouping
foolip: do we need 3 weeks for champion selection?
jgraham: proposal submission and refinement would be first 2 weeks
foolip: where would we share reasoning (async) on proposals we are championing?
jgraham: we should have a sheet to capture the initial data (proposal, signals, champion). The point of the 15 min pitch would be to share a narrative from all the signals (or the lack of it).
gsnedders: as a one-off we could potentially have a longer meeting
jgraham: preference would be for a 2 hour meeting where everyone could present in one session
foolip: +1
dandclark: +1
foolip: need more clarity on P3 priority, if we are using that as a negative signal
jgraham: it is a way to remove proposals that have no (or very low) interest from participants. P3 is for things a participant does not want to include a proposal, but stops short of a veto. The assumption is that participants would rank all proposals at this stage
dandclark: could use some more clarity on P3 vs veto
jgraham: success would be if we get to stage 3 (ranking) and there is enough awareness of where each participant stands
gsnedders: There needs to be a way to address the edge cases where a participant agrees that an area is important, but there is disagreement on the inclusion of tests that are potentially low priority.
jgraham: the idea is that the champion can take the ownership of reviewing the tests and the overall quality of the proposal using the rubrics
gsnedders: for RCS as an example, the area is weighted heavily towards currentcolor. Even if we ask engineers to review the tests, we need to have a holistic review in the Interop team.
nairnandu: how do we deal with carryovers? Do we prioritize them alongside the new proposals?
jgraham: my proposal would be to automatically re-submit (as a github issue) any Interop 2024 area that has not yet reached 100%.
foolip: for the ones with mixed rankings we could add more clarity on the process
jgraham: my pov is that we will all get feedback from internal teams, based on available signals. On top of that, the prioritization from other participants will also become an additional signal for us to go back and have that discussion internally.
foolip: there is room for subjectivity and discussion. For the ones that have mixed signals - it would be good to go through individually and call for consensus.
Next step: members will add any additional comments on the process, to the PR #657
Brainstorming session on developer, user and compatibility signals
Here is the proposed agenda for June 13th, 2024: