Compatibility/Meetings/2019-02-12

• Web Compatibility Meeting Meeting - 2019-02-12
• Minutes: 2019-01-29

Minutes

Scribed by karl

OKR Check-in (miketaylr)

https://github.com/mozilla/webcompat-team-okrs/projects/4 See the comments in each issues for the progress on each of the tasks.

Tracking diagnosis work redux (miketaylr)

Let's talk over any concerns with the self-assigning and type-foo labeling.

• mike: Marco is based in Toronto. He will help understand our needsdiagnosis workflow. Let's try to be discipline with the labels. Let's create new ones if they don't exist. This doesn't seem controversial.
• karl: From the webcompat side, we can't apply all the labels. There's no issue on the GitHub side. (link issue here)
• denschub: I have hard time figuring out what kind of labels. If I should create a new one or not.
• karl: If you think a more precise label is useful, do it. We can clean up later on. It's easier to group things in the future than to break down a big bag.
• mike: let's keep experimenting this.
• tom: Do we have goals? Or are we just experimenting?
• mike: Periodically, people are asking us what kind of bugs, which areas are impacted by webcompat. Labels will probably help us understand the type of bugs we have.
• tom: Do we have some team asking for specific things? I'm afraid that the value is not obvious for now. But we could just try for the quarter. It's more work.
• mike: It's something I want for a long time.
• mike: Let's jump to assigning. Marco could you explain what you are working on?
• marco: I have mostly worked with devtools teams on their projects. Usually I try to help them understand how much work they can accomplish in a defined range of time. Which is a bit different that what webcompat does. (karl let mike scribe so you can participate :P)
• marco: So far this has been successful, teams have been able to hit their goals.
• mike: So for the webcompat team, can you explain how it would work?
• marco: Typically, I need a start and enddate for the work. We'll use the first 6 weeks to gather performance data. Take all the work, look at start and end date, run it through a simulation and get the 85% fit for completion. This can work for webcompat, at least for the diagnosis phase (once it moves to some other milestone). Once the data is available, it's up to the team to decide. You can then set release goals, how much work we expect to complete over the next 6 weeks. We will resolve 100 issues over the next 6 weeks. The second level, you give stakeholders a number, but then you actually say, given the backlog as it is now, we're going to fix 100. If more important work comes in, we swap it out. So you can tell stakeholders the number of items you'll do, and the specific items. But it does require the basic data -- the start and end date. The caveats are, you can't be reserving work (assign yourself now, and work on it in a week). If you were to assign yourself after the fact, it also doesn't work. I collect the data over a week (given the volume of work for this team, weekly makes more sense than bi-weekly), then update the performance dashboard based on that.
• karl: When you say start date, when the bug is assigned. And end-date...?
• marco: When you assign yourself a needsdiagnosis milestone, and the end-date is the date when it's moved out of the milestone. Those together are lumped together as "done" (for the purpose of this exercise).
• karl: A couple of daily examples. Very often when a bug is triaged and ends up in needsdiagnosis. There are some bugs, just by looking at it, you can understand if it's invalid (or diagnosed?). It's closed in 2 minutes. This happened for me twice today. The second case, I will start a diagnosis and will get stuck, or need to pass off to Dennis or Tom. It might take 20 minutes or one hour, and I hit a wall. So I release myself, the bug is left in needsdiagnosis, and someone else will work on it. How do we handle cases like this?
• marco: For the second point, that's fine. If work is transferred from one person to the next, it resets the clock. For the bug, we measure how long does it take to complete it, but also data on how long does the bug sit in the milestone. That happens in other projects as well -- someone left a team, hit a wall, etc, it goes to another developer.
• marco: In terms of the quick turnaround, the modeling will factor that out, essentially it will be given a value zero.
• karl: Do you need assignment in that case?
• marco: If it's seconds, and you forgot, I would just use the close date as the start date. But that's just me guessing and interpreting. I'd rather not have to guess.
• marco: For the projects I work on, the teams decide what to work on, from their backlog. The developers are guiding the direction. There isn't a project that doesnt' go by where the list of bugs will later be found to have dupes, invalid, wfm, etc. They get discarded from the project -- they get removed from the backlog. The backlog is groomed by the developers all the time. When we remove bugs from the backlog, it frees up space to work on new bugs. The way this works, it's tailored 100% to Mozilla. The dev team is fully in charge. The team is developing the backlog and self-assigning.
• karl: Did you start tracking right now?
• marco: Not yet.
• karl: I would like to propose that when you start tracking the data, can we know after one week if it's meaningful. So we know early if we need to change something in the way we do things.
• marco: To do the initial forecast, I need 4 to 6 weeks of data.
• karl: I mean the data, not the forecast.
• marco: Ah you mean the mechanics. No problem.

Increased number of duplicates (SV team)

We saw a large number of duplicates being reported lately. We were thinking of some ways to limit this: - introduce a Captcha field (https://github.com/webcompat/webcompat.com/issues/2797) - limit the number of reports filed by the same IP for the same domain (eg. 1 every 15 minutes) - add a new radio button option (unsolicited/negative/disturbing content) https://github.com/webcompat/webcompat.com/issues/2214

• mike: Let's follow up in the bugs.
• karl:
• tom: Do these look like the same user hitting submit twice?
• oana: We don't know.
• tom: If we think that someone is hitting submit twice, then we modify our form to prevent that.
• sergiu: We produced some stats for bug 2214.

Renaming Tech Evangelism ( 👹 )

https://bugzilla.mozilla.org/show_bug.cgi?id=1527140

FYI Removing Adam from the scribe list ( 👹 )

https://wiki.mozilla.org/Compatibility/Meetings/Scribes

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.

• Abdul: Future of Work Conference (https://events.yourstory.com/future-of-work-2019)
• Adam:
• Cipri: Triage issues. Tier1 Card Report testing.
• Dennis: Diagnosis, GoFaster, `::-webkit-scrolblar` shimming.
• Guillaume:
• Karl: needsdiagnosis. Conversion to python 3 for webcompat.com (ongoing. still some tests issues with str, bytes, unicode). Code review for Kate on webcompat dashboards. Helping/Reviewing Mariana stuff. Check a bit the status of bugzilla/webcompat bugs.
• Kate: Script for weekly issues, database model draft, grokking changes to front end.
• Mariana: Implemented push using python firehose & finished implementing python rendering. Started learning about web security with my new professional mentor 🌟.
• Mike: SOMETHING ELSE>
• Oana: Triage issues. Tier1 Card Report testing.
• Sergiu: Triage issues. Tier1 Card Report testing.
• Thomas: Mucho diagnostico, about:compat review work, fixed compat bug 1524897

PTO / Travel ( 👹 )

• Karl: 2019-02-28 to 2019-03-08. French TZ. Reachable.