Compatibility/Meetings/2022-09-06

From MozillaWiki
Jump to: navigation, search

Minutes

Scribed by Tom

SameSite=laxByDefault RFC (dennis)

  • Dennis: (see document that will be shared in private. Probably skip scribing for that topic.)

Getting to State of WebCompat Beta Report (Honza)

Summary of our goals:

  • Recommendations, the web platform should follow
  • Help people to understand what the problems are
  • The report should answer the question: What’s the state of webcompat?


Suggestions for improvements in individual sections in the report:

Top 20

  • More information/context about individual issues. It should be simple to understand each issue, see what’s wrong and where to look for more details.
  • Sync with the platform and get an effort estimate for each issue. One of the first questions we’ll likely be about complexity (how hard is it to fix it).
  • Coming up with a way to get platform effort for fixing those top issues (needs syncing with relevant platform teams)
  • Avoid situations where we spend a significant amount of time on an issue that can be quickly fixed (or is fixed in the meantime).
  • 20 entries in KB atm (+19 “Add entry for…” reported issues)
  • Polish scoring algorithm? Do we have all the data we need for scoring in the DB?
  • Owners: Dennis, James?

James: We may already have done much of this. Telling folks about the issue is not all we'll do; we will help pre-prioritize too. We already will have some idea of that before we talk to people, so we might not have to talk to teams to get their input on that. I also think we'll want to know a "top 5 per team" for them. Honza: the teams may already know what will be in the report by the time we present it to them.

Risks

Honza: bgrins' spreadsheet does a good job identifying data sources and fetching the data, but not so much analyzing it. One approach would be to improve it, and parse it into usefully-structured data. He doesn't mind us evolving it into something better, if we wish. I'm not sure how feasible that is, or how useful the data really is, however. James: the data we had for the previous version of the report was based on interop2022, and what vendors implied they were doing. so as i look at the spreadsheet I'm looking at it for things other vendors are already planning. if we have clear signals like that, it makes it a higher risk. the granularity of the data is fine, canIUse is coarse-grained ("SVG" like entries, not sub-features). so it could be a useful data source for others, not just us. so as long as we keep us with vendor meetings and intent emails, we can keep the spreadsheet up to date and use this to identify clues like standards positions or intent-to-implement to find risks. teams might be already of these things, but it would be good for us to be as well. Honza: given that all vendors now have their own standards positions docs, how do we efficiently do this? James: other than looking at the data and figuring it out, we might just have to iterate on this over time.

Trends/General Directions

  • Share anything we think is important in this section. High level picture.
  • What are the other interesting things we noticed that are not fitting the other sections, but others should know about it.
  • It isn’t a table, but rather free form text.
  • Continue observing trends when doing QA triage/analysis
  • Owners: Oana, Raul?

Honza: Oana/Raul's weekly notes are a data source here to help us put this together. Tom: there are also diagnoses trends (e.g. sync XHR) James: we should count duplicates of reported issues (important for final scoring), Trends don't have to be related to specific KB entry. It might happen that the section is empty, meaning "we didn't spot any" Telemetry could also help us (to confirm) identifying trends (assumptions) Tom: we could use platform counters/etc along with our own diagnoses to spot actual risks/trends, though James is right that this is muddy water. Honza: for next steps, let's have the owners of each section focus on their section and help sort out the things we've discussed.

Hawaii AllHands Planning (Honza)

DevTools: Nicolas, Bomsy, Honza WebCompat: Tom, Ksenia, James

  • DevTools + WebCompat team meeting (tooling for diagnoses). Talk also to GregT about his z-index-devtool extension. Use notes from peers session diagnoses.
  • Meeting with the Spidermonkey team (Syncing on upcoming features and how to keep DevTools up to date). Nicolas is already attending SM meetings.
  • Meeting with platform teams (Layout, DOM, …) and talk about WebCompat Report (contributions, process)
  • Meeting with Necko team (platform API for BiDi and DevTools)
  • BiDi Meeting
  • DevTools + WebCompat team dinner Wednesday?

Interop 2023 (James)

We should try to put together a proposal for a webcompat focus area. Obvious candidates are bugs we see causing site compat issues, and bugs we know libraries are working around.

James: the time window here is roughly between 15 September and 15 October.

Retrieved from "https://wiki.mozilla.org/index.php?title=Compatibility/Meetings/2022-09-06&oldid=1243900"