Compatibility/Meetings/2018-01-09

• Web Compatibility Meeting - 2018-01-09
• Minutes: Previous 2017-12-19

Minutes

Scribed by Ola, Dennis

OKR Check-in (miketaylr)

Please have respective KRs filled in for Objectives you own, ready to discuss <https://docs.google.com/a/mozilla.com/document/d/1HbESnd9HyuOqwTpkqfuzB1Nhr8hmiP2ZXqWmTKEaTU0/edit?usp=sharing> (probably non-public, once everything is filled in, I can change sharing to public)

• Mike: Today is our first OKR check in as well as a sanity check. Objective 1 has key results. We have a massive backlog, so lets see how we deal with this.
• Mike: First is the and Sergiu and Oana are owning this. What is your score at the moment?
• Mike: We're gonna just comment on things we are working on it right now.
• Sergiu: We have 86 issues tested.
• Mike: Sounds like fantastic progress. I'm gonna say 0.5.
• Sergiu: Sounds great.
• Mike: Next one, diagnose 100 bugs. Karl, you left a comment on the bugs you've looked on. We'll talk about this in a moment. Just for this quarter, Karl has manually tracked the issues. I've created a label for this. Dennis, Eric, Tom have you kept track? Dennis + Eric + Tom: Yes.
• Mike: Just a reminder for everyone, who is doing diagnosis... You need to do 2 full days per week, otherwise we need to recheck our expertations. Lets create one doc.
• Karl: When I was tracking the bugs last week, its difficult to define what "needs diagnosis" means. Sometimes bugs aren't reproducible anymore and we move them to "invalid" or other. But is this diagnosis?
• Mike: Good question. What is our goal?
• Karl: My proposal is to understand what we are tracking and what part of work is really meaningful for tracking and the triage.
• Dennis: If we burn down the backlog, we will understand it anyway.
• Sergiu: You can count on us triaging the "need diagnosis" issues.
• Tom: I agree. The team is working on 2 parts. 1 triage and 1 to burn down the 100.
• Mike: So, everyone agrees? *everyone nods*
• Mike: As from today, everyone is tracking this on their own. Please link your work. I'll put 0.5.
• Mike: Dashboard, this is what depends on what we want to do. So not in progress right now. Let's recheck after 1 month, so we know which data we are tracking.
• Dennis: Obj2 - Ship Webcompat Go Faster v2. I've been on PTO and sick. There was an email about the Console API, something I need to address.
• Mike: Lets go though it step by step. 2.1 -> adding risk. Changing API.
• Dennis: Starting to work on it today.
• Mike: We have other 3 bugs, whats the progress?
• Dennis: I need to submit the code for review. It will happen this week.
• Mike: Do we feel this is a 0.5?
• Dennis: Yeah.
• Mike: 2.2 - Ship in v60
• Dennis: I need to follow up with the deadline mail for 60 (deadline tomorrow), so they don't forget the testing.
• Mike: Confidence n/a. 2.3 depends on 2.2 so also n/a.
• Mike: Obj 3 - TripWire
• Tom: Add on to diagnose regresson analysis for FF, which we need to get it running in automation. 3.1. - Get Tripwire working with automation. I'd say this is a 0.5. I have a running testcase. I'm sure, in 1-2 weeks I'll get it running.
• Mike: So you have it running locally?
• Tom: Yes. But I need to test it more and work on diagnosis more.
• Mike: Drive a browser and run a test.
• Tom: 3.2 is depending on 3.1 and 3.3 on 3.2, but there are things that I can work on.
• Mike: Let's say, we pick sites. Then we can assign a fraction.
• Tom: Great! 3.3 not sure about the confidence here as it depends on the first 2.
• Mike: Cool, let's check in in 2 weeks.
• Mike: Obj 4, Partner Relations...
• Adam: I'm gonna go through our trello board and check critical bugs. Then we'll get through bugzilla and make sure everything is labeled properly. Then we go back and populate the trello board again. Score; 0.5.
• mike: cool.
• Mike: Obj 5, Webcompat.com
• Ola: Refactoring design: On it, right now: Q1 milestone on Github that contains issues that are left open
• Ola: What we need to do: make sure we ship end of Jan/beginning of Feb, so we have enough time for Feedback and get the bugs fixed, since we also have to rewrite the tests. So the semantics shouldn't change much to not break tests.
• Mike: So confidence leel... it's in progress?
• Ola: Yeah. Score: 0.5.
• Mike: 5.1.2: Is this happening on staging?
• Ola: I guess it would be good for everyone to be able to see the site and click around, so yeah. We need some more content work, and I'd appreciate if Sergiu, Oana, and Karl could help.
• Mike: I'd help as well. It would be useful to have an issue on GitHub to be assigned to. But I agree this is easier on staging. Confidence level?
• Ola: I'd say N/A because nobody is working on it right now.
• Mike: KR "Rewrite tests", this is just fixing the tests after we changed everything. This is still N/A, because nobody is working on it.
• Mike: Broken tests are in general a concern of mine, because even on Master, all tests are broken right now because of some travis changes.
• Ola: Is there a bug tracking this?
• MIke: There are two PRs from Bea discussing about that. I'll probably work on that this or next week. I'll also file a bug and ping Ola.
• Mike: So, this KR is also N/A, snice noone is working on it
• Mike: 5.1.4: This is optional. Do you think we have time for that?
• Ola: It depends. It would be nice to auto-generate issues with comments we leave. But it depends on if we have time and if somebody wants to help. If we have someone helping, we can make it, but otherwise, probably no.
• Mike: There is no such thing as an optional key result, so I'll delete the word. If we don't make it, we just get a 0.
• Mike: 5.2: Ola and Eric are working on this?
• Eric: Yeah, we will need to discuss some open issues and details, and we need to agree on a set of features.
• Mike: So, is anyone actively working on that? Also, everyone, please have a look at this and get your comments in. On staging, you can test this feature. I tested it and couldn't get it to trigger, and an issue has been filed.
• Karl: We have some expectations on how it should work, and it does not work that way, but there is an issue filed on that for discussing around that.
• Mike: Feel free to look into the issues linked in the OKR doc, and I suggest that we made a decision on how it should work by the next checkin (Jan 23).
• Mike: I'll put down N/A, although Ola and Eric did a significant work on that, just because we can't really tarck it.
• Mike: 5.3: Karl, is this something you want to co-own with Guillaume?
• Karl: Yes, for sure. Mike, if I recall correctly, you had some comments on that, but I can't find them on GitHub
• Mike: I will file a bug.
• Karl: I'd appreciate feedback from others, since me giving feedback on a feature I developed may not be the best idea.
• Mike: I guess it would be good for Oana and Sergiu to provide feedback here, since they'll be hopefully using it. There is a link to the dashboard in the description, so if people want to use it, please do. Also, file issues.
• Mike: Obj 6 - GWS Tier 1 Experiment
• Mike: This is all about continuing the work. I'll enter OKRs by next checkup or delete it. :)

OKR diagnosed issues (karl)

We are supposed to be entering the issues we diagnosed, but which ones, and under which form.

• karl: This will be a long in the Google Docs and probably the OKR is not completely defined. We need to refine this. As an example I tracked what I did on 2018-01-03. See https://gist.github.com/karlcow/3175743cd3c357b25bca109da51de3fa
• mike: For now, keeping track in any random text document is fine. I hope having a system with labels will allow us to track this more easily (or similar). Otherwise, we can create a master Google spreadsheet.
• Karl: We already discussed this before. Everyone tracks their progress in their own Docs and links them in the OKR doc.
• Karl: Do you want to track the progress together or in individal documents.
• Dennis: Does it even matter? It's just a list of issues, and where and how we track it, doesn't really matter.
• Tom: I don't think I have an opionion on that. As long as it's tracked, it's tracked.
• Mike: Let's just decide this now. If we have one shared doc, we don't have to send out updates. If we're doing our own thing, we probably need a weekly update to the list. Does that change anyones opinion?
• Tom: It probably would be easier to have only one doc.
• Dennis: I agree.
• Sergiu: Maybe, some time in the future, we'd like to have our progress charted. So it makes sense to collect everything in a single doc if we want to have this.
• Mike: I want to have some kind of dashboard eventually. It could be motivating to have a visual indication of how much work we already did. But either way, we can collect the data.
• Mike: Let's create one shared spreedsheet, and let's say by the end of each week, everyone dumps their issues in there.
• ACTION: Dennis to create a document to track the collective diagnosis progress.

Diagnosed label [related to objective (miketaylr)

In order to track the work, it would be good to have a label to know when an issue has been diagnosed. Maybe even good to know when diagnosis is started or in progress as well?

• karl: an issue has finished to be diagnosed once it is moved to another status. So this one is "easy" to track with a webhook probably. To verify. we can record in a diagnosis db (date, issue_number, "finish")
• karl: let's see. once the milestone "needsdiagnosis" is set there is an event. We could record the (date, issue_number, "new"), but that doesn't mean we start the diagnosis. Setting a label 'diagnose-start' (name bikeshedding season started) could be a way to record in the same file (date, issue_number, "started"). Yesterday, I discovered bugs which were left as-is and not finished (we all did, just to make sure there's no one to blame here.) This is an issue, specifically when the issue is one year old. The diagnose-start could help to send a notification "Hey… pssst… it has been 2 weeks the diagnose has been started and still nothing."
• mike: Thanks for the thoughts. I hadn't considered tracking diagnosis by having things move from milestones...labels seems like the lazy/easy solution. :)
• mike: Note: i just created status-diagnosis-started and status-diagnosis-ended to work with between now and our meeting (we can change them, or delete them or whatever).
• sergiu: should we also use these labels and leave "started" label for the issues that are still reproducible? maybe the diagnosis team could tackle these first.
• Mike: We probably don't need to do that for the reasons karl mentioned before (some issues are moved out of the diagnosis queue, although there was no diagnosis happening). Let's ignore this label for now.

Engagement survey [non-verbal update] ( 🐝 )

Please fill it out if you haven't already.

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: PTO, triage, Q1 planning
• Dennis: PTO, bit of triage, more PTO.
• Eric: Issue triage, TW issue diagnosis (https://docs.google.com/spreadsheets/d/12xXX8cRc8EhxyjFQqpNk5gHXuvpuTq3aPTx86g7q_bs/edit?usp=sharing) , survey site patch candidates
• Karl: Peace, Love and Earthquakes. Reviewing the webcompat.com code of Mike. Coding Webcompat.com. Doing needsdiagnosis and needstriage and contact.
• Guillaume:
• Mike: OKR stuff, writing some code for type-webrender and supporting multiple labels (for label and details), getting back up to speed post-break.
• Ola: OKRs, test for similarbugs, code reviews, added Q1 Milestone + processes to Contribute.md
• Oana: Investigate issues. Triage and Diagnose issues. Added info/summary related to Austin Work Week.
• Sergiu: Investigate issues. Triage and Diagnose issues.
• Thomas: OKR stuff, work on integrating Tripwire into m-c.
• Biraj: