From MozillaWiki
Jump to: navigation, search

This is the agenda and logistics page for Web Compatibility Team Work Week meeting in Whistler (Canada) from June 17 to June 22, 2018.



  • Location: Whistler, Canada
  • Hotel: Multiple


Hotel Attendee Arrival Departure
Aava Whistler Abdul Rauf Monday, 14:25 Saturday, 8:00
hotel_name Adam Stevenson Monday Saturday
Fairmont Chateau Whistler Dennis Schubert Monday, 15:55 Saturday, 17:45
Aava Whistler Guillaume Démesy Monday, 14:00 Saturday, 14:10
Fairmont Chateau Whistler Karl Dubost Monday, 14:50 Tuesday 25, 16:25
Aava Whistler Kate Manning Monday, 18:55 Saturday, 20:55
Westin Whistler Ksenia Berezina Monday, 12:59 Saturday, 16:45
Fairmont Chateau Whistler Mike Taylor Saturday, 21:26 Saturday 06:15
Fairmont Chateau Whistler Tom Wisniewski Monday, 16:42 Saturday, 00:05




Scribed by Everyone reporting prototype improvements ( 👹 )

  • mike: it's a thing that's happening. There is a meeting on Thursday morning (beforer Lunch) for those who are interested in seeing what the Open Innovation team came up with. There were a couple of interesting findings, frequent points of confusion, and other things to work on. Actual location and time TBD. roadmap discussion ( 👹 )

  • mike: is done? Is it feature complete?
  • Karl: I would love we'd finish the milestones (the Paris project: which are already there. And maybe we could continue adding new issues to milestones every six months or so. There are always things to improve, things we can add, ...
  • guillaume: is the website useful? two years ago, we had a meeting and we talked about as a tool for the teem. Right now, I have the feeling is mostly used by reporters, but as a team, we mostly use GitHub.
  • karl: 99% of the reporting is done via For finding bugs to work on, it's not feature complete: missing filters, missing GitHub search queries, ... so I'm forced to use GitHub. What I do often is to go back to via Eric's extension. I'm doing that because it's easier to upload images and change the status there.
  • guillaume: so, is it useful to spend time on implementing those features, or should be maybe stop doing that, and focus on the reporting side of
  • karl: For me, is not replicating GitHub's features, it's adding features that help me work. For example, before Mike added the engine-gecko label, I had to use a long search query on GitHub. Another reason why I use is Eric's extension to file a bugzilla bug.
  • tom: $0.02, if there are low-hanging fruit for things to implement, that may be worth it.
  • karl: There are lots of issues on, for example the search translation is broken, but fixing that would taking a lot of time. karl and mike: we did a lot of user-centered research for the reporting formr, but we never researched the needs of people working on bugs. maybe that's a way to discover new things and new ideas. the idea behind should be to help people to work better, not to replace GitHub.

webcompat A/B testing ( 👹 )

A discussion has happened in between Rosana and Mike mainly on how to operate the A/B testing. John Giannelos will propose a new pull request which takes into account our own setup. Some meetings will be scheduled in between mike and Rosana at regular pace. We also ask to be reach out in advance for any proposals. - Community - Recognition, Stories, Outreach, Mentorship ( 👹 )

  • abdul: How high is the priority for community engagement in the webcompat project?
  • mike: If the community surfaces, we are committed to support it. If they are other people who are showing up, great. But we do not want necessary to build tools to create the community.
  • abdul: where do we need community?
  • karl: outreach is one thing. triage is a huge part, but you need a special set of skills. we need a lot of time to teach people the required skills, and our community members leave frequently, so that's lost effort. one thing that softvision is doing, which could be a community effort, is looking back at sitewait issues and verifying those.
  • abdul: there are two types of contributers: general users, and very mozilla-active people. getting the general users to contribute to is hard, but talking to the technically versed people is much simpler. I need help to create stories for helping simple users to start off with It's very difficult to start diagnosis.
  • karl: diagnosis looks like a giant task where you need to know everything. But that's not actually true. It's perfectly fine to look at an issue, decide you don't have the required skills, and just move onto other bugs. You don't have to be an expert in everything. We failed to explain that to the community.
  • abdul: Maybe a good-first-bug label for diagnosis could be a good idea?
  • karl: In theory, yes. The issue with that is if we identify a good first bug, we already have understood the bug, and basically have already understood it.
  • karl: If you have people who are active, get them to just try diagnosis and ask questions. It's perfectly fine to ask questions like "how can I make progress on this issue?"
  • tom: it might be a good idea to just throw out a bunch of information about how we would do triage, diagnosis, etc, so people can get inspired.
  • abdul: from my experience, people like students are mostly interesting in diagnsis and the coding part.
  • tom: those kind of people could just look at a bug they find interesting, and ask questions if they have any, if they want to know how to progress, and if they find the solution to a low hanging fruit we didn't get to yet, that's awesome.
  • karl: a very important point is: you do not need to finish things. it's fine to start on a diagnosis issue and stop. any progress is good progress, there is no need to finish everything.
  • mike: i have some feedback from the UX people about the documentation, we could look into those.
  • tom: the diagnosis base is also related, and can be improved if it can be more useful to contributors.
  • [TODO] Abdul to file an issue on for Contributi before on Stories

webcompat bug Outreach ( 👹 )

  • mike: is anyone familiar with webcompat dashboards?
  • mike: before we had two persons into outreach partly, and now we have none.
  • abdul: I had discussions with Adam and Karl this morning. when contacting with your own personal email address is not very efffective in terms of recognition. Mozilla has also already privileged communications.
  • karl: the NDA abdul has signed is with Mozilla. I'm not sure the companies have agreed to have non-Mozilla employee having access to their information.
  • karl: we opened an issue on, to use webcompat-bot to flag domains where we know we have a contact avenue. There will be a label. No need to find contacts.
  • mike: for the partner is kind of working ok. for contributors we could create something probably, a domain name, reuse
  • mike: OK, what about the diagnosers?
  • karl: In the past, we understood if a bug was triaged adn diagnosed quickly, outreach was more successful. If we waited for a long time, the issue could disappear because the site changed. If the diagnosis is done, being able to do outreach is very cool.
  • mike: What are the obstacles?
  • karl: It is hard, because people will not reply or fix things. It's a lot of manual work. You can't complain. You need to be polite, tactful. If people are rude, you still need to be professional.
  • karl: If we think we can't do it for lack of resources, what's the point?
  • mike: do you have objections contacting people?
  • dennis: The actual hard part isn't sending the email, but finding the contact. And even harder to re-ping after a given time.
  • ksenia: I had good success on LinkedIn. Can we have have a shared account?
  • tom: can we just ask for the money?
  • mike: Agree, I don't think it's that much. Or, worthwhile.
  • tom: I would need a little bit of training, and maybe some prodding.
  • karl: I do have a fake linkedin
  • mike: another solution is to have softvision helping. I don't think we can hire new people, but maybe they can help. they also go back to sitewait bugs and verify them, that could help with repinging.
  • karl: right now, we're trying to find ways on how to do outreach. will there be a goal or a number and a way to track that?
  • karl: If we have a practice, the place bugs should be is sitewait, not needscontact / contactready.
  • mike: is the distinction actually useful?
  • dennis: The tricky part of outreach is finding the contact. Composing the email doesn't take too long. But I have used contactready for a few instances.
  • RESOLUTIONS: * Everyone participate to outreach * We set goals for 2019Q3 on how to reduce the bulk of issues in needscontact/contactready * Decide on the state of "small" issues?

TSCI discussion (20 mins) ⭐)

A discussion has happened during mike's talk about the index. A desire for a better coordination with web Platform tests was voiced. Probably a way to broadcats that a specific issue requires a WPT. It would also be good to have a better understanding of the current data and their variability.

Use GoFaster as a platform to ship shims/polyfills ( 👹 )

  • tom: Gofaster allows us to do changes to a site relatively simple. But there are also cases where there is a widely used feature Firefox does not support (for example, we did not support WebP for a long time), which we could polyfill/shim. We could use well-known library via GoFasters on site's where it's neccesary.
  • karl: We are already doing that with our own scripting, like for the -webkit-scrollbar cases. As long as the polyfill is whitelisted to specific sites, that sounds fine to me.
  • mike: two concerns I have: performance is an issue for generic overrides. Also, security might be an issue.
  • dennis: and legal issues
  • tom: it's for sure something only to consider for specific cases.
  • mike: let's explore this if we have the need. We did this before for HLS, where we experimented with shipping a polyfill. However, getting security and legal review are slow processes. But might be worth it for specific sites.
  • karl: one unwanted effect of that: let's say we fix an issue on important site X. If we fix this issue via a polyfill, the amount of reports drops, and the priority of implementing the technology into Gecko might drop.
  • tom: we can also leverage telemetry to generate the same numbers.

Sharing diagnosis knowledge ( 👹 )

  • mike: we were sending on a regular basis a list of the work done in diagnosis. The intent was to share what was discovered. The idea seems useful.
  • dennis: There was too much information to process, and not that interesting. When ever we discover something which is interesting, we need to share through emails explaining the issue.
  • tom: the interesting stuff is useful. so what's interesting? new compat issues we don't know about. we don't really have a knowledge base. we just have to know it, or search online. being able to say, we now know about a new class of compat issue. having that listed on a wiki or whatnot, would be helpful.
  • dennis: basically anything is interesting if we didn't know about it yet.
  • karl: what would be the easiest way for you to share that information? do you think you can commit to it? any system we could find for this, we need to have people commited long term. i see both of you (dennis / tom) share an issue on IRC. perhaps we could create a bot that takes the comment and stick it in the knowledge base. can we hack our habits rather than create a new process?
  • dennis: i like the idea of having a chatbot. i like to share on IRC because there are people from other teams in our channel and it's useful for them to see. yes, i can commit to doing something like that.
  • karl: secondary question, how would you like to consume information for things you don't know yet?
  • ksenia: searching on github has been useful. once i spent an hour tracking down a regression and discovered karl had already figured it out for another site. for me it's probably some kind of archive for information.
  • karl: i'm using github emails to search over them. but if you're new, you don't have that archive of historical information.
  • tom: willing to commit. I think it's worth to put out the information. I don't care much about the format, but a knowledge-base kind of thing would be nice, so it's searchable by symptoms. I'm also willing to help sorting that information if other's just want to dump information.
  • mike: I'd propose we just use the GitHub wiki on the web-bugs repo. We just need to remember to do that whenever we discover something new.
  • RESOlUTION: creating knowledge base with the interesting issues of webcompat.
  • [TODO] Dennis to create a first entry for the knowledge base. before 2019-06-26

Team walk ( 👹 )

(that's not a discussion?) ⭐⭐⭐⭐⭐⭐⭐⭐⭐🐻🦂🦂🦂 (might be too complicated, but fyi:

Ask us anything for Ksenia ⭐⭐⭐⭐⭐⭐ ( 👹 )

  • ksenia: how are important the webcompat priority flags on bugzilla?
  • mike: We had success with the webcompat priority flags. There are high impact bugs.
  • ksenia: How to test in Fennec 69
  • all: There is no more Nightly 69. The best is to test in Fenix.
  • ksenia: beta uplift?
  • mike: This is when we need to move a feature faster to release without waiting the release train. (nightly ~ 6 weeks ~ beta ~ 6 weeks ~ release).

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:

  • Tuesday 16:00 - 17:00 Fetch Q&A (Tom)
  • Wednesday 10:00 - 11:00 Puppeteer Planning (for Mike)
  • Wednesday 10:00 - 12:00 Performance Workshop
  • Wednesday 11:00 - 12:00 Outreachy AMA (Mike, Karl, Kate, Others)
  • Wednesday 13:30 - 14:00 Emerging markets Exec Q&A (karl)
  • Wednesday 14:00 - 15:00 WebCompat system addons in Fenix with Sebastian and maybe other Fenix people (Tom, Ksenia, Dennis, and whoever is interested)
  • Wednesday 16:00~ Conference Center. Demos (Karl)
  • Thursday 10:00 - 11:00 Getting people to care about Web Compatibility (maybe the entire team? Karl)
  • Thursday 10:00 - 11:00 Firefox Lite Learning and roadmap (Karl)
  • Thursday 12:00 - 14:00 (CONFLICT with lightning talks) Open Innovation lunch about A/B testing
  • Thursday 13:00 - 16:00 Runtime & Visuals Lightning Talks
  • Thursday 14:00 - 16:00 Mitchell's State of the Internet discussion group (Dennis is interested, also Tom, maybe others)
  • Thursday 15:00 - 16:00 Emerging Markets user research insights sharing (karl)
  • Thursday 16:00 - 17:00 Profiling workshop
  • Friday 09:30 - 10:30 Firefox Exec Q&A (everyone?)
  • Friday 10:00 - 11:00 Remotee Meet Up (Karl)
  • Friday 10:30 - 12:00 Browser Manager Meeting (mike)
  • Friday 14:00 - 15:00 WebCompat Metrics (entire team)


Monday 17

Arrival day

  • 09:00 - 17:00 Blah

Tuesday 18

  • 09:00 - 17:00 Blah
  • 7:30 - 9:30 Breakfast plus Kick off
  • 10:30 - 11:30 Android Bootcamp for Gecko Engineers (for those working on system addons on Mobile)
  • 11:30 - 12:00 Start agenda building
  • 12:00 - 13:00 Lunch
  • 13:00 - 14:00 Agenda building
  • 14:00 - 17:00 Topics
  • 18:30 - 20:30 Team Dinner: BG Urban Grill. Reservation confirmed.

Wednesday 19

  • 08:30 - 10:00 Breakfast + Plenary + Walking back to Fairmont
  • 10:00 - 12:00 Hacking
  • 10:00 - 11:00 Puppeteer Planning (for Mike)
  • 10:00 - 12:00 Performance Workshop
  • 11:00 - 12:00 Outreachy AMA (Mike, Karl, Kate, Others)
  • 12:00 - 13:00 Lunch
  • 13:00 - 14:00 Agenda Topics
  • 14:00 - 15:00 WebCompat system addons in Fenix with Sebastian and maybe other Fenix people (Tom, Ksenia, Dennis, and whoever is interested)
  • 14:00 - 15:00 Hacking
  • 15:00 - 17:00 Agenda Topics

Dinner is self-organized tonight -- find a friend and go to dinner with them!

Thursday 20

  • 08:30 - 10:00 Breakfast + Plenary + Walking to Fairmont
  • 10:00 - 12:00 Chat about prototype form improvements with Open Innovation team (optional, for those interested)
  • 10:00 - 11:00 Getting people to care about Web Compatibility
  • 10:00 - 12:00 Hacking
  • 12:00 - 13:00 Lunch
  • 13:00 - 16:00 Runtime & Visuals Lighting Talks
  • 14:00 - 16:00 Mitchell's state of the internet
  • 16:00 - 18:00 Team walk?????????????

Dinner is self-organized, find a friend and go to dinner with them.

Friday 21

  • 09:00 - 14:00 Blah
  • 14:00 - 15:00 WebCompat Metrics (see sched)
  • 15:00 - 16:00 Blah
  • 16:00 - 19:00 Chill out time
  • 19:00 - ???? Friday Night Closing Event

Topics Bank

Use the following template in one of the section below:

 ==== Topic ====
 Description with [ links] when necessary reporting prototype improvements

The OI team is doing some cool work around improving the form, and they've even gotten it user tested. Let's discuss, for those interested.

Assigning bugs and priority conventions

Let's come up with something consistent for Bugzilla work.

TSCI discussion

Now that we have a Top Site Compatibility Index, what does it mean for how we prioritize our work? I'd like us to discuss prioritizing efforts on top sites (the whole pipeline, not just diagnosis) and critical bugs going forward. roadmap discussion

What's next?

A / B testing of bug form

(In theory we might have something useful to discuss? Will depend on Open Innovation getting the work done in time).

webcompat SAO workflow

Do we stay on GitHub? Move entirely to m-c? Let's discuss the pros and cons.

Unifying diagnosis workstream

See Mike would like to move all diagnosis work from Bugzilla to GitHub. Let's discuss the implications.


There are a lot of bugs that need outreach, and no longer dedicated headcount to do this work. How do we split up the work?

Sharing diagnosis knowledge

We've tried weekly reports. What's next? Thomas had a proposal for a summary of the interesting issue. We probably need something which is easy to carry on.

Define 2019H2 OKRs

The goal is to come up with a set of objectives that we can reasonably achieve in the next 6 months.

Define 2019Q3 OKRs

The goal is to come up with a set of objectives that we can reasonably achieve in the next 3 months. This list is more tailored, matured. (note: Q3 OKRs already exist in a draft state, so let's dig in and see if we need to adapt)

[SV] Retest Bing top sites Should we consider having a new OKR task for Bing top sites after Bugzilla issue #1555035 is fixed?

Orlando 2018 All Hands Post Mortem

Let's check the project we started in Orlando and how much did we fare and fail. What we need to pursue or abandon?

Review milestones/projects

There are a couple of unfinished tasks in current we need to review, trim, clean, close, move forward.

And let's create mini-projects that someone can take ownerships in a way which is not overwhelming.

Bug Work Process Check-in

How do we do our bug work (from new bug to closed bug)? Is it effective? Can it be improved? What are the bottlenecks?

Needsinfo co-hacking

Let's pair up and work on clearing out old and complicated needinfo requests.

Team walk

We can walk around and talk about bugs... by the trees. 🌲🌲🌳🐝🐛🐜🦟🦗🌿☘️🚶🏽‍♂️🚶🏼‍♀️🚶🏽‍♂️🚶🏽‍♂️🌳🚶🏼‍♀️🚶🏽‍♂️🚶🏼‍♀️……🌳……🏃🏽‍♂️🌳🌲🌳🌳

Tooling improvements discussion

Let's discuss how we could improve tools like Tinker Tester Developer Spy to lower the amount of time we have to do triage and diagnosis. Any specific papercuts, or things we do over and over? Perhaps we could finally make that addon to report common webcompat issues noticed on a given site? Are there additional details the reporter could grab that would help? (connection error messages, SSL info, etc)?

  • What is the status of the UI proposal made by Dennis in Florida work week (December 2018)?

Ask us anything for Ksenia

Probably Ksenia should collect all the questions she may have about the work and take the opportunity to fill up what is missing.

Use GoFaster as a platform to ship shims/polyfills?

Out of some discussions between Tom and Dennis around a WebSQL breakage, the idea of shipping polyfills via GoFaster came up. Let's have a discussion around that idea.

Reporter addon and Fennec/Fenix for mobile frameworks

How to get the new detection features in Fenix at least, and Maybe fennec (stucked on 68)?

[SV] Weekly task - Twitter issues investigation

Should we consider having a weekly task regarding investigation of issues reported by users on Twitter, which are gathered in this document and slack “Webcompat-in-the-wild” channel?

[SV] Monthly task - Verify “about:compat” bugs

Should we consider having a monthly task to verify that all the sites in “about:compat” on Desktop and Mobile still need the overrides or interventions (in Nightly)?

[SV] Webcompat new site design testing

Since the site is being redesigned should we consider having a task to test the new design?

[SV] Machine Learning for auto-triage (Nemo)

Are there any news about Nemo’s progress on this? Can we further help him in any way?

Secure Connection Bugs

There is nothing much we can do about these in needsdiagnosis. Probably they should be just be closed or sent directly to bugzilla after triage. with a link to