Retrospective: Interop 2024 proposer experience

[nairnandu]

We are doing a retrospective on the Interop 2024 process on launch (#611), as input into the next year's process.

We would like to solicit the feedback from those of you who submitted and advocated for proposals, in particular proposal authors that are not employed by one of the organizations that form the Interop team.

Anything that you think worked well or not so well, and any ideas for improvement, would be welcome feedback. Please note that we cannot discuss outcomes of specific proposals in this issue. We will review all feedback in the next Interop meeting (on Feb 22nd, 2024) and we will try to summarize any actions that we arrive at, from that meeting.

If you have private feedback, feel free to reach out to anyone you know to be involved with this project in private (DMs, email, chat, etc.) and ask them to share with the rest of the Interop team. You can find some email addresses with git log in a checkout of this repo.

@ramiy, @nileshprajapati, @stof, @AshleyScirra, @Jothsa, @rctneil, @Schweinepriester, @mayank99, @rd3k, @o-t-w, @jsnkuhn, @BearCooder, @romainmenke, @johannesodland, @benjamind, @ydaniv, @scottkellum, @jaime-rivas, @brandonmcconnell, @msub2, @rejhgadellaa, @MayyaSunil, @firefoxic, @chriskirknielsen, @dginev, @theres-waldo, @myakura, @reinhart1010, @joppekroon

[msub2]

I found the submission process itself to be fairly straightforward and without issue. While I understand that my proposal was for a relatively niche topic (WebXR), I had hope that the existence of the WebXR Test API with its mocked device capabilities would be sufficient for at least promoting spec parity across engines, since it's already in use for the WebXR WPTs. I would suggest clarifying the meaning of "testing infrastructure" and what is or is not currently considered supported in the cases where a proposal affects an API that communicates with external hardware.

[mayank99]

It would help if the purpose of "investigation effort" was made more clear. I still do not understand what it's for. Everything else was generally a good experience.

[dginev]

I would welcome some guidance on how to make proposals that are distant from the usual focus areas of development more likely to be accepted in future editions of interop.

1. Should we first be proposing an "investigation effort" before outlining tests that need support?
2. Was the scope of an issue too broad or too narrow to attract effort?
3. I have seen some sentiment on social media that proposals dealing with "other specs" (e.g. SVG or MathML) do not belong in interop at all, or similarly that peripheral proposals which "distract a browser's development team" don't have a path to acceptance.
   • It would be great to know if we need to help mitigate such concerns

Also let me send my gratitutde to the entire interop team, for hosting such a transparent community effort. It has been really rewarding to see all the interoperable progress in recent years!

[theres-waldo]

For proposals that were vetoed, as a proposal author I would appreciate some guidance on what sort of updates to the proposal / additional investigation / test changes etc. (if any) might help overcome the veto in a future year.

[joppekroon]

I was invited to attend a meeting after submitting my proposal, but my proposal was not discussed at all during the meeting. What was discussed were things that I had no hope of grasping. It felt like a wasted hour.

The meetings after were at inconvenient times, so I wasn't able to attend. Unfortunately there were never any minutes published to be able to keep abreast of what was discussed.

I think at least some minutes of the meetings would be a nice improvement to give some insight into what was discussed and give a chance to try and understand it.

[zcorpan]

@joppekroon that's unfortunate. We must have missed to add your topic to the meeting's agenda, and that's at least in part my fault. Sorry.

Your proposal was accepted, and so there's still time to discuss it and make progress during this year. The relevant issue is https://github.com/web-platform-tests/interop-accessibility/issues/95 I'm personally open to have a 1:1 discussion with you to get the ball rolling.

The Accessibility investigation group do usually publish meeting minutes in a GitHub issue. I don't recall which meeting you attended in particular, though. See https://github.com/web-platform-tests/interop-accessibility/issues?q=is%3Aissue+label%3A%22Agenda%2B%22+Meeting+

[brandonmcconnell]

Honestly, I was disappointed to see my dynamic attr() interop proposal (#521) not selected again this year, despite significant community interest.

It seems to me that all necessary information for a decision on this feature is already available or could be easily obtained in a discussion in a single day. This feature has been proposed and overlooked annually, even amidst continually growing demand. I believe it’s crucial for the selection process to address lingering questions around such proposals proactively. At the very least, addressing any lingering questions this year and committing to include attr() in next year’s interop priorities, given its evident demand, would seem reasonable to me and no doubt be a positive step forward for the community and the web at large.

One other issue that I was both surprised and disappointed didn't make the cut was @scottkellum's proposal for "Unit division and multiplication for mixed units of the same type within calc()" (#513) as it's a need many of us already face. The reason for rejection was that the proposal was considered too broad. Personally, I would contest that, since the proposal targeted one specific adjustment to CSS arithmetic, which is clearly outlined in the official specification.

Both of these features are highly demanded and desired by the community, and both would revolutionize the capabilities of CSS development at large.

[scottkellum]

+1 @brandonmcconnell, I was also a bit surprised and disappointed when both proposals were not selected. Especially after all the work @brandonmcconnell did with assistance from @foolip, @nt1m, and @gsnedders on getting the tests in place to really solidify #513. With the significant community support it felt like a sure thing* and the reasons for rejection left me a little confused.

*Nothing is ever a sure thing, I get that.

[chrishtr]

For proposals that were vetoed, as a proposal author I would appreciate some guidance on what sort of updates to the proposal / additional investigation / test changes etc. (if any) might help overcome the veto in a future year.

We now have a mailing list where you can ask questions / obtain advice. Feel free to email us, and I'll try to help!

[brandonmcconnell]

@chrishtr I wouldn't mind emailing there as well, but could we stick to keeping this thread public here for visibility as we address these issues?

[chrishtr]

@chrishtr I wouldn't mind emailing there as well, but could we stick to keeping this thread public here for visibility as we address these issues?

Definitely feedback about 2024 should be here, not on the mailing list, in part so it stays visible like you said. The mailing list is more for questions like "I'd like to propose feature X next year, any suggestions on next steps?"

(I just wanted to make everyone aware that the mailing list now exists going forward. We added it today after discussing feedback here.)