Compatibility/Meetings/2018-04-10

• Web Compatibility Meeting - 2018-04-10
• Minutes: Previous 2018-03-27

Minutes

Scribed by Thomas

Introducing Q2 OKRs (miketaylr)

Management-approved™ OKRs here: https://github.com/mozilla/webcompat-team-okrs/projects/1 Let's review and assign owners.

• Mike: If you received one, please accept the invite for the Mozilla GitHub. You will likely need two-factor authentication on your GitHub account.
• Mike: As for Q2 OKRs, we have two main objectives, but they are not the only things we're allowed to work on (we need wiggle-room to be able to take on extra things). Broadly speaking, we need to become more efficient at dealing with and understanding bugs (especially with the info that's there by the time diagnosis begins). Looking over the OKRs on GitHub, if you're the assignee, you're not responsible for the whole thing, just keeping the status/metadata up to date.
• Mike: Adam is interested in doing 1.2 (needscontact dashboard), so I'll assign him to be the owner.
• Mike: As for 1.3, for it to not be too intimidating, we want to have all non-anonymous diagnoses diagnosed. We should still keep an eye on anon ones, of course, to prevent big issues from slipping us by. Karl, I'll assign you to this one for now.
• Mike: 1.4 is related to a proposal from Sergiu and Oana. We'll be prioritizing non-anonymous issues, but I still think this OKR might not be ambitious enough. Still, Sergiu and Oana will be co-owners for this one.
• Mike: 1.5 is about making bug metadata richer. For example, easily knowing when it's a tracking protection bug, including navigator.buildId in reports, and trying to dump the console errors into the report upon submission.
• Sergiu: what about mobile device model?
• Mike: I don't think we have that info right now, but in the future it might be a good thing to add. Tom, I'll randomly assign you to 1.5
• Mike: 1.6 is something we're doing with the open innovation team (Biraj and Abdul). I'd like to assign it to Sergiu and Oana (maybe one of you could take this and the other could take 1.4?). We won't be sure if this OKR ends up being useful until the end of the quarter.
• Sergiu: could we maybe do several experiments?
• Mike: that's definitely alright with me, as iterating on what we've learned is important. I have a couple of docs to link for those who want to learn more about this.
• Mike: 1.7 is a last-minute addition that I think we're going to need. This could be something we do as we triage or diagnose issues. I think Karl or Ola might find this one interesting to work on, but I'll make myself the owner for now.
• Mike: I think everything in objective one is immediately familiar, but objective two is about finding ways to make us more efficient in our job, and making more of a difference with GoFaster and the like.
• Mike: 2.1 is about the next iteration of the GoFaster addon. We have some ambitious ideas here, so this version is important to get us there. With Dennis' hard work this may still be possible to land by 61, but it might slip to 62. I'd like us to ship 10 site patches before we start adding more features. We should link specific bugs to this OKR as we do so. We also want to land this addon in Fennec nightly, and let it ride the trains as it does. I'll assign ownership of this one to Dennis, but I think it would be good for others to also gain experience on how to ship site patches with GoFaster.
• Mike: in 2.2 we'll spend time prototyping an addon for helping with diagnosis. For this quarter, we are the target audience. Other deliverables are a document showing how devtools fail us (what use-cases we could improve for our needs), a blog post and All-Hands lightning talk. I'll assign this one to Tom.
• Mike: as for 2.3, we'll have an insights workshop with the open innovation team. We have telemetry, maybe use-counters, and other such data, and want to know how to use it to inform management to help do a better job directing product development (for instance, the upcoming GeckoView-based Android Firefox). This includes our metrics repo, but there's a lot more to get involved in. We basically want to start getting our personal knowledge out of our brains so others can make use of it. I'll assign this one to Rosana.
• Mike: Product wants a longitudinal experimental addon (tentatively named Blips) that Mozillians can opt into which lets them periodically thumbs up/down if things are going well on a given site, to help us figure out when sentiments improve or worsen ("people aren't happy with YouTube this week/release"). It's a bit of a wishy-washy OKR, but Tim Smith from the product team will be meeting with me to help figure this one out. I'd like to assign Rosana to Blips, but we'll need some help writing the addons and backend components. We're scoping things out right now, but hope to have things figured out for our next meeting/check-in.
• Mike: of course, in addition to these OKRs, we have our "day job" roles, and we'll do one-on-ones by our first check-in to make sure things are progressing. If you'd like to be a part of one of these, let me know.
• Dennis: could you ensure that we have permissions to add links/comments on the GitHub OKR page?
• Mike: yes, I'll add you as co-owners ASAP.
• [TODO] Mike to add everyone in the team as co-owners for the OKR on github. before 2018-04-11

Samsung Internet cooperation (Oana & Sergiu)

Are there any news on this subject. We would also like to take part in it.

• Mike: I recall there was a conversation at the Devtools Workshop about this?
• Dennis: yeah, Ada and Peter (mobiles DevRel folks) were interested in looking at webcompat issues, though we don't have to be directly involved in this. They just want to make sure they aren't missing anything, and we can ping them if that happens. There isn't anything official about supporting Samsung Internet.
• Mike: do we have any labels for Samsung Internet?
• Oana: yes, we have one.
• Dennis: there is actually a Samsung Internet GitHub account, but Ada and Peter did not know if anyone is actually watching it. I'll chat with them.
• Mike: it might be good to put such contacts in our Slack channel or somewhere like that.
• Dennis: it's worth noting there are only maybe 20 issues for Samsung Internet Browser right now, but it's still good to keep an eye on it.

keypress/keydown and Closure (karl)

There are threads here and there about the issues. A lot of history and painful things. We need to understand if the fix will break more sites than just sites using the closure library. How do we do that? Is there a good way to test websites for this and spill it out in the console? Would Selenium and automated testing could make things easier to test?

• karl: https://github.com/facebook/react/search?q=keypress+firefox&type=Code
• Karl: Jet and Masayuki were hoping to find a way to know if this keypress-handling change will break any topsites, since it's hard to tell outside of Google, as Closure isn't the full story.
• Mike: I've paid some attention to this issue. There's an about:config pref you can flip to enable the standard behavior, and when I browsed for a day with that pref on, it was Google spreadsheets and docs that were broken.
• Karl: maybe a Shield study could be used? We wouldn't collect all data automatically, but maybe we could detect if the issue might be happening, and ask the user to confirm?
• Mike: this is probably related to our desires for Blips.
• Karl: if anyone has any bright ideas here, I would like to know.
• Dennis: maybe let's do a mailing list discussion?
• Karl: either way we don't really have a proposed solution now, and it's not an easy issue to reason about. As usual, even if Closure is fixed by Google (which is planned), there is no guarantee that any other sites using it will update.

A team call-to-action: counting compat regressions (Tom W)

It would be great to have some hard data on how many and what kind of webcompat *regressions* we see on webcompat.com. That is, whenever a site's layout/rendering is visibly different, because Firefox is suddenly doing something incorrectly where it was previously correct. If it seems as though an automated tool would have caught a visually-noticable compat issue had it been monitoring the site in question, please let Tom W know, as I will be keeping an eye on such regressions during this quarter.

• tom: We would like with TripWire add-on to move forward. Where can we use it? Will this tool be useful for us? While we are doing our day job, if we identify issues that could have been catched in advance by such a tool, maybe we could put in the tool. Give me the issue number and we will try to compile the issue inside the addon. Layout difference (visual differences). The two criterias: Visual changes and it's a regression (for example, the Fennec "double dropdown arrows" issue).

Two Minutes ( 🐝 )

This is the summary of what you have done during the week. Feel free to add your own 2 minutes. Keep it short. Feel free to add your name if you think you need to share something.

• Adam: needscontact and contactready burn down, some PTO
• Dennis: diagnosis, diagnosis on bugzilla, perf, ua override for gofaster
• Karl: neesdiagnosis. A bit of webcompat.com
• Guillaume: dashboards, dashboard.
• Mike: Event.srcElment Event.returnValue dom spec PR. planning, HLS verification
• Ola: PTO + catching up.
• Oana: Investigated, triaged and checked needsdiagnosis issues. Start the new round of Pre-triage experiment.
• Sergiu: Investigated, triaged and checked needsdiagnosis issues. Pre-triage experiment activities.
• Thomas: Mostly diagnosis and dusting off my diagnosis helper addon. Also sick. Also spotted a standards problem with Google Search's service worker which caused other browsers UA-spoofing as Chrome Mobile to break (and which they have already fixed, yay!).

PTO / Travel ( 🐝 )

• Ola: 19.04.2018 on PTO