Agenda for Sept 25, 2025

[nairnandu]

Here is the proposed agenda for Interop team meeting on Sept 25th, 2025

• Closing the call for Interop 2026 proposals
• State of HTML 2025 results and analysis from @LeaVerou

[nairnandu]

Attendees: @chrishtr, @stubbornella, @ChrisC, @yulunwu2, @foolip, @captainbrosset, @jakearchibald, @jgraham, @meyerweb, @nt1m, @gsnedders, @LeaVerou

Notes

• Closing the call for Interop 2026 proposals
  • Merge Interop 2026 - closing of proposal submission window #1159
  • Stop auto-add of issues to Interop 2026 project
  • Officially closed for proposals
• State of HTML results
  • Lea shared the results with the team and would follow-up async on gathering feedback
• Test change proposals
  • [Anchor positioning] anchors-visible tests should probably not be in interop? #998:
    • Follow-up offline on the CSSWG issue. Since we don't expect that to be completed by EoY, the default should be to remove the tests.
• jakearchibald: demo idea for collecting developer priorities
  • jakearchibald: the overall idea is to have developers stack rank proposals
  • foolip: sounds good. How are they ordered?
  • jakearchibald: the ones in the “no opinion” buckets are sorted randomly
  • captainbrosset: creating a limit on the number of items you can rank would help with even greater prioritization
  • foolip: depends on the analysis we do. But limiting might not influence the outcome as much
  • stubbornella: we have some existing signals already. I wonder if this would give the perception that a top ranked item is a certainty. There is also the aspect of gaming this.
  • jakearchibald: github reactions seems more gameable than this approach (more effort involved in ranking as opposed to adding a +1)
  • jgraham: open to it as long as we caveat this to say that this is not the single source of truth for developer signals or that a highly ranked item is a given for inclusion in Interop. Also keeping the results for team evaluation only.
  • foolip: treating this as an experiment sounds good to me
  • stubbornella: agree with James on not publishing the results. Worry that this would dilute the other signals that we have (State of surveys). The way we did it last year by sharing the signals we each gathered as champions were super useful.
  • captainbrosset: agree that we have a lot of signals already. This, I think we would get a different perspective compared to the github reactions. It would be good if this was an “official” thing from Interop.
  • jakearchibald: we could make it an official Interop thing or I can publish it as a personal thing
  • jgraham: dont think this should be an official Interop artifact (same as the reactions dashboard). Are there any objections to doing this as an experiment?
  • stubbornella: need to get a few more opinions before we commit to this

[LeaVerou]

• jakearchibald: demo idea for collecting developer priorities

Just spotted this while cleaning up old email, hope this is the right place to post feedback!

I love the idea of crowdsourcing prioritization! In terms of UX, generally, when you want a lot of people to rank a lot of things, you usually want to expose them to ranking a very small subset at a time (often just two), then you reconcile the results. Exposing them to too much data at a time is overwhelming, and results in the biases already mentioned in the discussion.

E.g. you can turn it into a game where people are presented with two features and have to pick one of the two, then are shown how many people agreed with them. There are many established algorithms for how to reconcile this data into a single ranking. As a bonus, because this involves very little data at any point in time, it can easily be adapted to mobile.

You can even call it Webmash as a play on Facemash, Facebook's precursor that did the same thing with people 😅

In fact, I can imagine a UI that merges the two, where you go into game mode where you pick among pairs, and then it shows you the order it has figured out from your actions and you can edit it.

[jakearchibald]

you usually want to expose them to ranking a very small subset at a time (often just two)

The worry I have about this, is most people will not be familiar with most of the proposals, so there may be a lot of rounds before they get two they're familiar with, and they're likely to rage quit before that.

The UX I'm aiming for here is: Go through the list and pick some that catch your eye, then order them.

I'm sure there are better ways to achieve that though.

[LeaVerou]

you usually want to expose them to ranking a very small subset at a time (often just two)

The worry I have about this, is most people will not be familiar with most of the proposals, so there may be a lot of rounds before they get two they're familiar with, and they're likely to rage quit before that.

The UX I'm aiming for here is: Go through the list and pick some that catch your eye, then order them.

I'm sure there are better ways to achieve that though.

1. I think it's very hard to avoid overwhelming though, and effectively picking one that catches your eye is still random.
2. Even if you haven't heard about a feature, if the two cards you see have enough info, you can still often prioritize between the two. We've seen this time and time again in the State Of… surveys, where people often click "Interested" or "Not interested" in features they have never heard of, to the point we started optimizing to facilitate it (e.g. provide enough info for each feature).
3. There should still be a "No idea" button, both to catch this case, as well as to prevent garbage data by forcing people to pick when they genuinely don't have an opinion.