Compatibility/Meetings/2020-01-work-week

From MozillaWiki
Jump to: navigation, search

This is the agenda and logistics page for Web Compatibility Team Work Week meeting in Berlin (Germany) from January 27 to January 31, 2020.

Logistics

  • Location: Berlin, Germany
  • Hotel:  ???

Attendees

Hotel Attendee Arrival Departure
hotel_name Adam Stevenson Monday Saturday
InterContinental Dennis Schubert (before Monday) (after Saturday)
InterContinental Karl Dubost Monday, 17:50 Saturday, 10:50
Hotel Berlin Kate Manning Monday, 18:00 Saturday, 10:00
hotel_name Ksenia Berezina Monday, Saturday,
Intercontinental Mike Taylor Sunday, 16:40 Saturday, 07:05
hotel_name Tom Wisniewski Monday, Saturday,
InterContinental Henrik Skupin Monday, 15:00 Saturday, 10:00
  • InterContinental Berlin, Budapester Strasse 2, 10787, Berlin, Germany

Regrets

none.

Minutes

Minutes

Scribed by Mike

Agenda ( 👹 )

Agenda for team discussions and other important things: https://wiki.mozilla.org/Compatibility/Meetings/2020-01-work-week (Anyone feel **free** to scribe.)

Quick intro ( 👹 )

(James Graham joined the team)

  • Ksenia: Currently working on interventions and overrides. On rotation for that this month. And do webcompat diagnosis.
  • James: Working with web compatibility stuff, but never in the webcompat team. Was doing webplatform tests, studying issues with interoperability in between browsers. Working on figuring out how to run less tests, to save some money. Working on a process for prioritizing WPT test fixes, with an automated bug filing process (for bugs that fail only in Firefox). Related dashboard work. Some Keep on the lights work for WPT core team.
  • Dennis: I've been working on maintaining our interventions system addon. And I've been doing diagnosis. The next couple of quarters is porting our report site issue extension (which we have in Fennec and Desktop) to Android Components, so Fenix can have that. I'm also mentoring an Outreachy intern, who is porting a site reporter inside a web extension.
  • Karl: I've been doing web compatibility for life. Right now I'm doing diagnosis for the bugs, and developing webcompat.com in Python. I love tweeting on… webcompat and mozwebcompat.
  • Mike: Manager stuff. Sometimes contributes to webcompat.com, working trying to figure out metrics, the top-site-compatibility-index (TSCI) for example. I'll give a talk about that in two days. Figuring out what we should be doing.
  • Kate: Awesome contributor. Maintaining the webcompat metrics dashboard, both the server and the frontend, together with Guillaume. Lives in Italy.
  • Tom: (on leave for the GeckoView team right now).

Discussion ( 👹 )

  • Kate: How does wpt work?
  • James: When gecko is being changed the wpt are run. So we can know if it's breaking certain tests.
  • Mike: Every browsers are running those?
  • James: yes. Apple is less involved.

Agenda items ( 👹 )

https://wiki.mozilla.org/Compatibility/Meetings/2020-01-work-week (Introduction around the agenda items.)

GoFaster addon and non-temporary overrides ( 👹 )

  • dennis: Just to clarify, I'm not complaining. Previously our plan was to only use the system addon to only ship temporary things. And establish a process to eventually remove things. However, for Picture in Picture, I think that's going to change. I don't see how they will ever be deprecated. Mike Conley has no plan to work out a more clever API to tweak changes. As of right now, I consider these overrides to be very permanent. I'm not sure if we should split it out? Or keep using the current mechanism. The more logic we have in our hotfixing stuff, the more things could break. That's one area where I'm concerned.
  • karl: Do we allow ourselves to fix APIs which are not complete? Basically we are extending a spec. If it's temporary, because we know teams will change in the future, it makes sense.
  • mike:
  • james: The standard is an opt-in thing, and Mozilla has decided we want it to work for any videos on the web.
  • mike: How many exist?
  • dennis: Early today I approved 3 more, twitch, udemy, and some other site I forget. So, right now it's 3 instances.
  • karl: Do we know why he will not be extending the current feature?
  • dennis: It's more a question of deciding how and where to place the button?
  • karl: Do we know why the feature request is not a priority?
  • mike:
  • james: If we think the overrides have to exist for the long term, if they live inside Gecko, they only get updated at the speed of Gecko. From a high level there's good reason for this kind of thing you can push updates to.
  • dennis: Right, but maybe the system addon is not the right place for that.
  • mike: We should probably talk to Adam and Mike Conley. A few overrides seems OK, but a lot, no. If other products feel the need to tweak things like this, maybe that means we need another similar mechanism.
  • dennis: In the case of twitch, our position actually broke twitch.
  • karl: In the extreme case scenario, twitch decides to block Firefox. What would we do?
  • [TODO] Someone talk to Adam this week, if before possible.
  • karl: How long does it take to maintain this code? Is it a big burden?
  • dennis: It depends on how well we communicate. In the PiP case, it was close to being bad. The initial patch broke Fenix, I only discovered on accident via Phabricator. Because I discovered that, it wasn't a big problem.
  • karl: But for a new site with a request, how long to code and release?
  • dennis: A few hours over a few days.
  • james: Where does this code live? In m-c?
  • dennis: GitHub *and* Mozilla-Central.
  • james: You know you can watch directories in Phabricator, right? You can set yourself as blocking reviewers.
  • [TODO] miket to Make sure module peers/owner are set as blocking reviewers in phabricator. - before 2020-01-18
  • james: You can also set up an alias in Phabricator, I don't know if you can set it as a blocking reviewer. To set one of these aliases up, you have to file a bug or something. But you can do that.
  • james: Actually, you can have an alias be a blocking reviewer for a directory.
  • [TODO] Dennis to sort out the phabricator blocking alias biz. - before 2020-01-18

Where to host the graphs for our Interventions? ( 👹 )

Karld and Dennis agreed on hosting it inside the WebCompat Metric infrastructure, with a label that clearly indicates that this is a Firefox-only metric.

Multi-step form pre-discussion ( 👹 )

  • karl: the form is not very practical when you're an expert and want to file a bug quickly. it's frustrating to have to jump around.
  • karl: doing the mgame, i wonder, do we even use these categories? do they help us?
  • tom: i have a question, was it designed well?
  • mike: it's kind of a mess.
  • dennis: do we have data on how effective it is?
  • mike: yes, we do. sort of.
  • dennis: if the numbers aren’t good, it’s not worth fixing.
  • karl: I think we should stop everything. We could try to re-explore that, but maybe in a different way.
  • karl: <explains some ideas of new UX, even though we said we wouldn’t do that>
  • Mike: I don’t know if re-doing everything is going to be worth it. They have good stuff.
  • Karl: they have good ideas that we should keep. String length of descriptions, etc.
  • karl: the changes are so dramatically different, it's not really A/B testing.
  • mike: if we throw the code away, we probably won't have the time or resources to improve in the near future.
  • mike: one option is to keep it, and to improve on that work. I can see justifying effort to improve the current new form, but not running another new form.
  • karl: I'm not talking about running an entirely new form. Just about improving our old form with ideas from the new one.
  • karl: If we keep the new form, we first have to remove the old form, remove the A/B integration, and do a lot of cleaup. So either way, we have to do a lot of work.
  • mike: We knew that from the beginning, that's part of the exchange we made with OI. That was a good tradeoff for having all the work done for us.
  • mike: One thing to remember that even if the form has problem, it works. There's things to be fixed, there's tests to be written, but we still receive reports. But that only makes sense if numbers work out.
  • mike: Another thing to consider is that our original goal was to reduce the number of invalid bugs, so we may be able to rollout the form to the release population. But at the same time, we also have the machine learning-based triage process now, which also helps in scaling up handling of more reports.
  • everyone: some discussion about various things
  • karl: do we keep the A/B test infrastructure?
  • mike: It could be useful for further tests. The question is if we think it's useful for future experients.
  • mike: So, our options are: 1) remove the new form 2) keep the new form and roll it out to 100%, improve the new form as far as possible in a limited time
  • karl: Is there data available that could help us make a better decision?
  • mike: That's another plan: write some tests, turn it on 100% for 4 or 6 weeks, and compare the numbers, to see if we lost a lot, of we gained something, or if we gather more data?
  • karl: I'm concerned that there is a lot of work to do to clean things up.
  • mike: True, but that's also true for implementing other possible improvements.
  • tom: Do we have a list of things we want to get done before we feel comfortable with it? mike and karl: Mostly adding tests. And some minor bugs, that could be complicated to work out.
  • mike: we'll have a discussion at 16:00 with OI, everyone is welcome to join.
  • mike: I think it really comes down to prioritization in the end.

What do we do and why do we do it? ( 👹 )

There is a graph of all the things we do (photos of whiteboard). it will be made in a file form very soon.

Alternate Auth systems + anonymous reporting ( 👹 )

  • [TODO] karl to upload a picture of Karl's whiteboard - before 2020-02-18
  • Mike: The current workflow allows making anonymous reports that end up on GitHub, and you can also make reports via GitHub. The question is: Is there a way to build other authentication channels, like FxA?
  • Karl: How would that look like on GitHub? Would that be the WebCompat bot to post the issue?
  • Mike: That's unclear.
  • Karl: What would be the benefit of that? Kate and Mike: It would prevent abuse as it proves you're a human.
  • Karl: Instead of Firefox account, you could do twitter?
  • Dennis: If we implement FxA, we'd have the basis of OAuth anyway, so we could add other providers as well.
  • Mike: Do we think that's an important idea?
  • Dennis: We'd still need a way of receiving unauthenticated reports, or we'd limit the audience, so I'm not sure how helpful that is.
  • Mike: yeah. This would be a dicussion that we can continue if it turns out that the private moderation workflow is not working out.

TLS bugs ( 👹 )

  • [TODO] karl to upload a picture of Karl's whiteboard - before 2020-02-18
  • Karl: Is the current SSL error understandable enough for non-technical users to avoid us receiving this report?
  • Karl: There are two ways we could improve our situation: a) Improve the SSL error page, or b) remove the WebCompat reporter on SSL error pages.
  • Mike: Removing the icon is probably fine, if someone wants to do the work.

The Future of Webcompat.com Infrastructure ( 👹 )

  • [TODO] karl to upload a picture of Karl's whiteboard - before 2020-02-18
  • Mike: (Recaps what happend and the issue)
  • Mike: The question is if we need to build our own system for the future, if there is another system we could use, or if we should stick with GitHub?
  • Karl: Another option is to still use GitHub, but use our own database to store backups of the data.
  • Ksenia: Building our own system feels weird if there are so many things that already exist.
  • Karl: If we use Bugzilla as a Storage backend, what does that mean?
  • Mike: I had this conversation with Emma years ago, but only about Media bugreports. That's something to explore, and something to have conversations with relevant people to talk about potential concerns.
  • Karl: Why do we want to have a backup? For me, to have a static version of webcompat.com and to keep the history.
  • Mike: To have a database to query. To reduce external dependencies. To make the system more reliable. To own our data.
  • Mike: I think it's good for us to draft a document with the requirements.

Mission accomplished?! ( 👹 )

  • [TODO] karl to upload a picture of Karl's whiteboard - before 2020-02-18
  • Karl: Are we done?
  • Mike: No. People still experience interop issues.
  • James: And web developer's pain points are still top pain points. According to the MDN survey, 5 out of 7 issues are pain points. To retain users on the web, we also have to make sure it remains the platform of choice for developers.
  • Mike: If the question is "are things significantly better than they were in the past?", the answer probably is yes.
  • Mike: You always have to do some level of this work. The web is always evolving. There is no potential future where there are on future interop issues.
  • Mike: Will we always need a team of this size, do we need more people, do we need less? The future is unknown, we're not there yet.
  • James: You still have the big pile of incoming issues, and if we find that those are still valid issues and you're just keeping up, that's an indication that there are sitll issues.
  • Dennis: I'm concerned that this state of "there are no large fires right now", but that's only bacause Google is not yet pushing their new APIs?
  • James: The question is that if that's the case, what is WebCompat's role here? Is it deciding on which APIs to implement?
  • Tom: I think the problem won't be to figure out what to implement, it's more about finding the undocumented aspects in Chrome's implementation, and to find the differences between our and Google's implementions.
  • James: That's an interesting question. If we think we reacted to the "the world is on fire" stuff, should be be more proactive and provide more leadership in ensuring interop.
  • Mike: That's a question of research, but also about figuring out prioritizing WPTs, ...
  • James: There's a bunch of stuff where we don't even know if we have good test coverage. Lot's of open questions that we don't know how to solve.
  • Karl: Is anyone at Mozilla doing the "Read the (web) Air"?
  • Tom: Is there devrel people doing that?
  • Everyone: Probably not really, but maybe.

Ideas ( 👹 )

  • Connecting Web Platform Tests and webcompat bug references * Dashboard planning * Private reporting launch checklist

Schedule Conflicts ( 👹 )

Things we should schedule around, either for the whole team or individuals. We can have "hack time" for those not interested in attending these meetings:

  • Wednesday night DX Managers Dinner
  • Thursday night some Engineering Manager dinner?

Agenda

Monday 27

Arrival day

  • 13:00 - 21:00 Registration, Jetlag and Party

Tuesday 28

Wednesday 29

  • 09:00 - 10:00 Wednesday All Hands Plenary
  • 10:15 - 12:00 Cross-team time (meetings with other teams) or Hacking
  • 12:00 - 13:00 Lunch
  • 13:00 - 16:00 Cross-team time (meetings with other teams) or Hacking
  • 16:00 - 18:00 Demos
  • 18:00 Dinner on our own

Thursday 30

  • 09:00 - 10:00 Thursday Plenary
  • 10:00 - 10:15 Remotee Group Photo (sorry Ksenia???)
  • 10:00 - 12:00 Team time / topics
  • 12:00 - 13:00 Lunch
  • 13:00 - 15:00 Browser Engineering / Firefox Lightning Talks
  • 15:00 - 16:00 Metrics Retrospective (sched)
  • 16:00 - 17:00 Cross-team time (meetings with other teams) or Hacking
  • 18:00 Dinner on our own

Friday 31

  • 09:00 - 10:00 Friday Plenary
  • 10:00 - 12:00 Team Time + Agenda Items
  • 12:00 - 13:00 Lunch
  • 13:00 - 17:00 Team Time + Agenda Items
  • 18:00 -> ???? Closing Event

Topics Bank

Use the following template in one of the section below: 

 ==== Topic ====
 Description with [http://example.com links] when necessary

Alternate Auth systems + anonymous reporting

Could we require other types of auth (and still use the proxy reporting to GitHub) in place of anonymous reporting? This would help with potential abuse.

2020 webcompat.com Bang!

on January 2, 2020, the web-bugs repo and the webcompat-bot were both totally disabled. Leaving webcompat completely blank. It helped us identify some issues:

  • Status On the project
  • no live backup, able to show the issues data and comments. Also related to #165
  • missing some emergency landing pages easily activated on issues. Related to #2733
  • Accounts consolidation. (Who's doing what? As access to what? twitter, github management, deployment, etc.)
  • Metadata Future for webcompat
  • Project Belt On. Aka we are doing for the anonymous reporting workflow.

Team Walk

If the weather is willing, walking somewhere would be nice, as a chance to get away from All Hands madness and connect as a team.

Multi-Steps Form

The discussion is intended to define if we continue the experiment or if we stop it and focus our energies on something else.

What did we learn about reporting? What mistakes have we done? What have been the positive outcomes? What do we do for the future?

GoFaster addon and non-temporary overrides

Some people seem to be interested in shipping more permanent interventions (the PiP, for example) via our system addon. Originally, we decided the addon is only a way for temporary interventions, and those ideas are contradicting that. How do we handle those cases?

TLS bugs

Let's talk about TLS bugs, what to do about them, and how the future will look like in regards to turning off older TLS/SSL versions.

Where to host the graphs for our Interventions?

We have data for drawing a graph about the number of active interventions. Do we want to build that into the WebCompat Metrics, or as a standalone project?

Retrieved from "https://wiki.mozilla.org/index.php?title=Compatibility/Meetings/2020-01-work-week&oldid=1223125"