Agenda for Feb 22, 2024

[nairnandu]

Here is the proposed agenda for the meeting on Feb 22nd, 2024

• Interop 2024 process retrospective
  • Interop 2024 process retrospective #611
  • Retrospective: Interop 2024 proposer experience #635
• Test change proposals

[nairnandu]

Attendees: @lolaodelola, @foolip, @nairnandu, @zcorpan, @jensimmons, @dandclark, @gsnedders, @meyerweb, @jgraham, @bkardell, @nt1m

Notes:

• Interop 2024 process retrospective

  • Interop 2024 process retrospective #611
    • [611] Automatically re-propose features, that were not accepted, for next year
      • jgraham: disagree for a few reasons - it might get done anyways, developer interest. We should make it clear to folks why Interop cannot support a proposal.
      • lolaodela: should we consider re-reviewing last year’s proposals (without re-opening them) based on the selection criteria?
      • jensimmons: there is a process question here - automatically re-opening issues. Outside of the process - there has been an assumption that if we select a proposal, the work is not added for one calendar year. Its until the work is finished.
      • jgraham: my suggestion was for rejected proposals, not for carryover.
      • Consensus: Do not automatically re-open proposals that were rejected last year
    • [611] Did having 3 rounds work well? Did the ranking in round 3 work well?
      • foolip: could have gone directly to round 3?
      • jgraham: round 1 was mechanical and did not have much impact. By the end of round 2, all feedback was in there. The ranking of proposals could have been done earlier
      • dandclark: the work for round 2 and 3 were the same for us
      • jensimmons: round 1 intention was to remove any that did not qualify as per the criteria. Dont think we did round 1 in enough detail. Liked having a round 2 and 3. However, the ‘N’ was too high and we ended up with a lot more proposals than intended in round 3. We should maybe limit the no: of proposals coming out of round 2.
      • bkardell: this is a joint prioritization exercise. Too much data coming in and not enough resources to estimate and filter out proposals. We should spend more time filtering and picking the top N earlier. Like for N to be small.
      • jgraham: hard to ignore the contradictory constraints that exist. The value of round 1 is to filter things earlier. Orgs should be able to state their priorities earlier.
      • jensimmons: In round 1 - we could also eliminate anything with a known objection. There might have been a mis-conception that we needed consensus to eliminate, as opposed to consensus to remain
      • bkardell: the process was very inefficient and more contentious than it needed to be.
      • zcorpan: the intention with the 3 rounds was to reduce the work and it did not do what it set out to do
      • jensimmons: it was indeed a lot of work. Surprised that round 1 was as much work. Would not want to go back to last year’s (Interop 2023) process. We should look at reducing the ‘N’ from round 2.
      • jgraham: agree with it being much more work this time. Not convinced that a smaller N would have the effect that we think.
      • nairnandu: we need more time to discuss. Adding this to the agenda for next week.
  • Proposal feedback and proposer experience
    • foolip: would like to discuss JPEG XL. The member-confidentiality prevented us from communicating any clarifications on the matter. The member-confidentiality did not work for us.
    • jgraham: the biggest lesson is that we need to be clear on what Interop can and cannot achieve. There is nothing stopping individual organizations from communicating their roadmaps.
    • dandclark: Need more clarity on what can be communicated. The member-confidentiality limits what we can and cannot state, in public. Constraints on sharing our own positions is stonewalling
    • bkardell: As mentioned earlier, there was an opportunity for us to provide more clarity on certain proposal responses.
    • jensimmons: what we decided against was a joint statement. Each organization has the flexibility to communicate. What’s confidential is the joint rankings or revealing what other organizations have done.
    • dandclark: As we define the process for next year, we should make it explicit as to what can be communicated. We would like to be more vocal about the positions we took
    • jgraham: What each org is shipping can be communicated and is the thing developers care about. That is more important than what got selected in Interop. We should set the expectation that a positive standards position (as an example) is required for support
    • jensimmons: you can always write something up and share it with the rest of the group as a courtesy and get a review. The spirit is that we want to make this project about collaboration.
    • jgraham: For next year - we should not publish the github reactions list as it is not an accurate representation of developer priority.

• Retrospective: Interop 2024 proposer experience #635 and test-change-proposals - not discussed

  • Ran out of time. Pushed to next week.