Compatibility/Meetings/2023-09-19

• Web Compatibility Meeting Meeting - 2023-09-19
• Minutes: Previous 2023-09-12

Minutes

• Scribe: Ksenia
• Chair: James

Triage process for Bugzilla bugs (Dennis)

• Dennis: Raul and Calin already file some issues on Bugzilla. I'm looking at the emails to make sure we don't miss a P1, but besides that, we do not triage anything at the moment.
• Dennis: We should change that, either by looking at those issues during our diagnosis triage, or in a different slot.

• ksenia: we can try Monday?
• dennis: there are 262 issues that are uncorfimed, so might not be enough
• james: we can try that. one question is what the outcome of this? would it get needsdiagnosis flag or set a priority
• dennis: we can add needsdiagnosis flag, but that raises anoter question who will be doing diagnosis?
• james: and we should set Priority flag and that would be diagnosis priority
• dennis: the query is all issues in Web compatibility component (Mobile, Desktop) without priority and needsdiagnosis flag
• raul: Would it help if we announce major P1 issues on slack?
• dennis: yes, that's a good idea

What happens to webcompat.com after shipping the New Reporter? (Dennis)

• Dennis: The new reporter workflow still has the ability to file a "more detailed" report on WebCompat.com, which is in line with our plans. The link to webcompat.com can be turned off via a pref, but it's on by default.
• Dennis: I am, however, concerned that this will create a situation where Softvision needs to triage two sources of new reports, and we need to triage diagnosis priorities in two places.
• Dennis: We should come up with an approach/solution here - ideally before the reporter is shipped to Release (currently planned for Firefox 120, which hits release in December)
• Tom: I beleive we were shipping to only 10% of the users in 120, with the aim to ship to 100% in 121, so we still have some time.
• Tom: one option we might get away with is only enabling "send more info (to webcompat.com)" for nightly+beta users, but I'm not sure if that's something we actually want to do.
• Tom: one detail we need to consider is whether we want those reports sent to webcompat.com to be "tied" to a Glean ping, because right now my code is just doing what Report-Site-Issue does, and forgetting the report after sending the user to webcompat.com. But I should be able to send a Glean ping so the data also ends up in BigQuery in that case, by waiting for the report to be submitted and (hopefully) get an issue# back from webcompat.com to "tie" to the Glean ping.
• Tom: one other thing to note is that the "new"/simplified reports will have the additional browser data and prefs and such stored, which I don't believe we're storing for reports sent to webcompat.com right now. So there would be a benefit to "tying" the webcompat.com reports to Glean pings from that point of view (unless we want to just store everything "send more info" users pass along in webcompat.com, separately from Glean/BigQuery. And if we do want to save that data on webcompat.com someone -- possibly how we're storing consoleLog info? -- then we have an opportunity to improve the JSON data ping format we send to webcompat.com as additionalData)

• James: we can mention on webcompat.com that the issues will likely not be triaged, "do something else instead". And ask Karl and others if the site is providing value
• Tom: we can mention this to Karen
• Honza: I like the idea of having it only to Nightly/beta
• James: it makes sense to keep the link for a few releases and see how it affects the number of reports
• Tom: one detail we need to consider is whether we want those reports sent to webcompat.com to be "tied" to a Glean ping, because right now my code is just doing what Report-Site-Issue does, and forgetting the report after sending the user to webcompat.com. but we can tie them together
• James: If user goes organically to webcompat.com we show a message to use in product reporter, if they go through in product reporter we try and learn why there clicked on the link (i.e. they wanted to add a screenshot, and we prioritize adding that)
• Tom: The data we're getting from 2 systems might not match
• James: The hope is that the amount of data we get through detailed link is not sufficient
• Honza: it seems that we want to have less work for both triaging and maintaining 2 systems
• James: we can have 2 systems as a transitional period and then decide what happens to webcompat.com
• Ksenia: So once users click on the "add more detail" link, we're just sending them to webcompat.com, and not sending them over telemetry?
• Tom: Yes, for now those would be seperate. But if we want to in the future, we could store that in Telemetry as well. I'll push for the "more detail" link to be hidden in Release so we get less traffic.
• Ksenia: There's still the old code for saving to BigQuery and the short form code on webcompat.com, but it's currently not deployed. Should we get rid of that?
• Dennis: The new reporter will store the data in Telemetry databases, and we can't write into that table, sadly. While we spent some time implementing that, I don't think we can use that in production, as we'd have two data stores that both contain user reports.
• James: In theory, could we store the reports into a seperate table, and then create an aggregate table that contains both telemetry data and webcompat.com data, so we could triage them in a single step?
• Honza: the other advantage of github is that we can communicate with users
• Dennis: we can aggregate 2 tables and create an ETL script, but this would require additional work
• James: Let start with the simplest thing and do triage in 2 places to learn more about the reports we're getting
• Dennis: lets revert the BQ code from webcompat.com for now

WebCompat KBNG Status (Honza)

The curent status, next steps and risks.

• M1 Basic Infrastructure

   * DONE BigQuery tables (Dennis) 
   * DONE New Bugzilla Component (Dennis)
   * DONE Webcompat.com UI for simplified reports, experiment (Ksenia)
   * Import existing web-bugs to WCKB? (Dennis) - checking data types/schemas yet needed
   * ETL for syncing Bugzilla -> BQ? (Ksenia) - scheduler needs to be done

• M2 Collection of simplified reports

   * WIP Reporting Tool (Tom, planned release Fx121, Nightly Starts October 23)
   * Calculate Site Popularity (Dennis)
   * WIP Triaging Dashboard (Dennis)
   * Updating Bugzilla Statuses (Ksenia?)
   * Identify candidates for confirmation

• M3 Adaptation of the triage process

   * Transition to the new process

• Honza: there is a deadline, so we should be ready by Fx121 release
• Dennis: I'm working on the dashboard. web-bugs to WCKB is not done, but I have a script for import
• Honza: Identifying candidates for triaging looks like the most complex point in M2. Are there any other complex issues?
• Dennis: Updating Bugzilla Statuses and Identify candidates for confirmation
• Honza: what do you think the timeline is for have anything ready?
• Dennis: dashboard is hopefully deployed by october 23
• Honza: so we hope to release it then and start polishing
• Raul: And Adaptation of the triage process is about QA triage process?
• Honza: Yes, Milestone 3 is both adaptation of QA triage and diagnosis
• Dennis: Since we have a custom dashboard we could make any changes needed

Firefox for iOS User agent string (Dennis)

• Dennis: Do we have a list of known-broken sites for FxiOS, or do we just move all the reports into the FxiOS repo?
• Ksenia: We have some, but they're all quite old.
• Dennis: Would we be fine temporarily re-enabling the reporter for (maybe a subset) of FxiOS release folks if we make UA changes?

• James: it would be good to have a BQ table grouped by domains to see the breakage and if changing UA would fix those
• Dennis: there is a problem with not having enough resourses
• Tom: what is the timeline?
• Dennis: there is no timeline right now, I can ask if we can delay it to avoid overlap with the new reporter
• Tom: They could start sending data to Glean
• James: Yeah we can ask if they can do it, if not could use webcompat.com but don't triage them

ACTION: Dennis to talk to the iOS team and suggest waiting 2 months, so we can use the new WebCompat bug pipeline.

Interop / State of WebCompat (jgraham)

Need to make sure teams know what's going on.

• James: We should make sure that the core teams are aware of what is shipping in other browsers and what we're missing.
• Tom: I was going to look at release notes and platform gap this week
• James: Yeah this week is fine, we should do it before October 4
• Honza: doing it ASAP is the best and as soon as we have something I'll share it with platform manager
• James: We should include everything that was in the previous Safari release notes as well