Interop 2023

[foolip]

We don't have a repository for Interop 2023 yet and haven't decided on a process/timeline, but here's an issue to subscribe to. I'll comment on this issue when Interop 2023 starts happening.

[foolip]

Here's a first cut at a timeline, to raise for discussion in #87 today:

• Now until July 15: define the process itself, in particular where / from whom we will solicit proposals, and how the positions process will work. See Retrospective on process and launch #68 (comment) for concrete issues to work through.
• September 15 to October 30: Proposals period. We should also ask for clarification during this period, so that we have fairly clear proposals going into the next step.
• November: Focus area selection, following a "positions" process similar to last time
• December 1-14: Possibly a 2nd round of area grouping and positions (if we've defined it in the process, and think it's necessary due to too many areas or some areas that didn't turn out as hoped)
• December 15: focus areas, tests, dashboard finalized and ready for a go-live date not decided. Before or after holidays?

[gsnedders]

By comparison, last year's actual timeline was:

• 7 Oct – 29 Oct: define process (sorta, we didn't really stick to it),
• 29 Oct – 18 Nov: proposals period,
• 18 Nov – 16 Dec: focus area selection,
• 16 Dec – 22 Feb: test review, metric computation, dashboard design,
• 22 Feb – 3 Mar: PR/marketing delay

[foolip]

Thanks @gsnedders! I didn't look at that first, great idea to compare. The proposals period was shorter than I'm suggesting (3 weeks vs. 6) and the test review period was much longer (2+ months vs. unclear).

So it would probably be useful to look at the "test review, metric computation, dashboard design" bit and see what we expect to still take a long time next time (test review, probably) and make sure there's enough time for it.

[foolip]

In #87 @jensimmons proposed that we have a deadline for new proposals earlier than the end of the proposals discussion period, perhaps Oct 15.

[gsnedders]

My understanding from the meeting is the slightly more concrete proposal is:

• Now until July 15: define the process itself.
• September 15 to October 15: Proposals period.
• October 16 to October 30: Proposal discussion/refinement.
• November 1 to November 31: Proposal selection.
• December 1 to December 16 (or the week after?): Test review.
• January 9 to January 20: Announcement discussion/planning (PR, marketing, etc.).
• January 23 to January 27: Launch.

To me, this feels like we have much too little time for test review versus where we spent time last year. We also likely spend a fair bit of the proposal selection last year discussing and refining the proposals, so with a clear, earlier end date for proposals do we still need a whole month to select proposals? Are we expecting the proposals to be entirely fixed by October 30? (This implies voting "investigate" like people did last year shouldn't be possible, as it's really a wholly new proposal.)

[robnyman]

@gsnedders One minor change I'd suggest there is starting December 1 to write out rough announcement drafts, to make sure PR teams and others have good time to look at them.

[jgraham]

To me, this feels like we have much too little time for test review versus where we spent time last year.

Test review can happen until shortly before launch, right? There needs to be about a week in which the scores are stable (although we can't guarantee that ofc), but I think we can expect initial test review to continue until about 20th Jan. (although in practice it's also ongoing).

This implies voting "investigate" like people did last year shouldn't be possible, as it's really a wholly new proposal.

I guess we'll see how "investigate" ends up working out this year, but dropping that so that we are only able to work on things where the interop challenges are well understood (typically: the feature just hasn't shipped everywhere yet) seems like it would represent a significant reduction in the overall ambition and potential impact of the project.

[gsnedders]

This implies voting "investigate" like people did last year shouldn't be possible, as it's really a wholly new proposal.

I guess we'll see how "investigate" ends up working out this year, but dropping that so that we are only able to work on things where the interop challenges are well understood (typically: the feature just hasn't shipped everywhere yet) seems like it would represent a significant reduction in the overall ambition and potential impact of the project.

To be clear, I was imagining being able to propose (as a counter-proposal) "investigate [X]" if someone is proposing [X], preferably with a clearer idea about the investigation would suffice than we had at that point last year.

[SachaG]

Just wanted to say that I'm happy to try and fit the 2022 edition of the State of CSS survey into your schedule as best as I can.

[jensimmons]

Working timeline created & updated in our 23 June 2022 meeting, to match the discussion as it happened.

• Now until July 15: define the process itself.
• SEPTEMBER 15: Start accepting proposals.
• September 15 to October 15: Proposals period.
• OCTOBER 15: Final deadline for proposals.
• October 16 to October 30: Proposal discussion/refinement.
• November 1 to November 30: Proposal selection.
• NOVEMBER 30: Final deadline for selection.
• December 1 to December 16: Start review of tests. Write needed tests.
• December 1 to December 16: Start involving PR teams. Write rough drafts of announcements. Begin creating dashboard.
• January 9 to January 20: Complete announcement plans. Prepare dashboard for launch.
• January 9 to January 20: Finalize test selection.
• January 23 to January 27: Launch.

[jensimmons]

Now until July 15: define the process itself.

Why a July 15 deadline for preparing for 2023? Why not give ourselves until August 15 to define the process? Or Sept 1?

[foolip]

@jensimmons for "define the process itself" I meant sending out an RFC with a timeline like the one in #78 (comment) and the decision making process the group will use later in the process. It wouldn't involve any of the focus area proposals. Does that make sense?

[mtom55]

Interop was originally created to "address key developer pain points", so in that context I think it's important to potentially include both existing specifications that have bugs/differences and to consider new areas that need addressing. If we automatically excluding anything that's not covered by existing specs than that limits the changes this effort can make.

It would be nice for the developer community to be able to provide concrete input as to what are the major capability gaps in browsers today. As an example we'd like to push for an effort for a consensus on the installation paths for Web Apps across all platforms/browsers in order to make Web Apps a viable competitor to native apps. We'd be able to campaign and demonstrate support for this, but only if there is a pathway for us to do so.

[karlcow]

• Working Groups provide feedback mechanisms and issues tracker to address the needs of technologies (future and past). This is where new ideas are being discussed and proposed. There are already plenty of mechanisms to do that, including WICG and reports to Groups. This is the place for new areas of work.
• https://webcompat.com/ addresses the issues with the current Web as implemented and helps understands the pattern we see on real websites. This leads to outreach to the websites and/or new issues for specifications or work on the compat spec AND coding work to level the differences in between the browsers.
• Interop 20* is here to help make a concerted effort in between browsers to level the field on current interoperability areas that Web developers have been reporting. Usually the type of stuff where people are saying I can't use this because it's not available in browser X, or I use this on my app/website and forbids users to use this browser Y and Z.

[mtom55]

Thanks for the reply. Would those points also cover Interop investigations or could we potentially ask for an investigation into the capability gaps in Web Applications?

Interop is one of the most positive movements on the web in recent history and provides huge benefits to ordinary developers, so we in no way want to derail/spam any good work and instead are just trying to find a path to ensure that basic critical functionality gaps (the ability to install and open apps on iOS and Android) are prioritized and addressed. Would WebApps WG be a more appropriate forum?

[marcoscaceres]

Would WebApps WG be a more appropriate forum?

Heya @mtom55! Replying as WebApps WG Chair (also super mindful that we don't derail this issue!). So, short answer is "no", WebApps WG is not the right forum to do the research, as the WG is primarily chartered to do spec work. This is the right forum - but not the right issue for us to have this discussion.

Folks here can correct me, but the 202* Interop priorities are set by various developer surveys (e.g., the "State of CSS" survey as mentioned in #78 (comment), previous MDN surveys, et.c. Thus, the world wide "developer community" is, as best possible, the one represented in the data of the ongoing surveys/data sources listed at https://web.dev/interop-2022/.

So although it seems justified to ask "what about installable web applications"? The W3C community/WebApps WG don't consider those any different from any other kind of web development: That distinction is fiction and/or marketing, specially because any web application can be "installed" by an end-user (Web Manifest present or not!). The W3C promotes "One Web", which doesn't differentiate between installed or uninstalled, and is device independent. Having said that, if a large scale developer survey revealed interoperability issues around, say, Web Manifest, then that is something all stakeholders could act on.

My understanding is that these are not issues that are significant in the data (to date). That's not to say they aren not important to developers (or that there are no issues). Is that the survey data, which this effort takes largely as representative of world wide developer needs, doesn't seem to indicate that "installable web apps" are as high priority as other things (e.g., grid interop, parent selectors, container queries, etc.). That might be for a number of reasons, like, maybe the right questions were not asked by surveys? or the surveys are skewed towards a set of standards (indicative in "the state of CSS"). But it could also be that they are, at this point in time, not as high priority as other things with the platform.

I personally don't know, but I trust that the folks here do - and that they are representing world-wide developer needs through this effort.

(🚨 To continue this discussion, maybe spin up a separate issue, so we don't continue to derail this one)

[robnyman]

Hi @mtom55, and thanks @karlcow and @marcoscaceres for thoughtful replies.
I just wanted to add that there is a forum where we've started exploring how to continue efforts around understanding web developer needs: web-platform-dx.

So while it's early days for that and we are still talking through areas, it might be a good place to also keep track of and possibly get involved over time.

[mtom55]

@marcoscaceres thanks for the reply and the suggestion

As suggested I've moved this into a separate ticket #91

@robnyman Thank-you, would love to contribute, the important part for us would be to understand the process and likelihood that it would end with real world changes.

[robnyman]

@mtom55 In terms of process, I would say it's generally looking at the existing issues and see if you have ideas or thoughts on them, or filing issues that feel relevant.

As for likelihood, if I knew the answer to that, I would be a very happy person. :-)
We are working together, though, and try to make sure we help the web platform progress, collaboratively. :-)

[foolip]

I've put up the RFC for this now: web-platform-tests/rfcs#116

[foolip]

@mtom55 responding to your earlier comments/questions, I'll reply on #91.

[foolip]

The Interop 2023 RFC was accepted and merged:
https://github.com/web-platform-tests/rfcs/blob/master/rfcs/interop_2023.md

The README of this repo will be updated to document the timeline and process.