Compatibility/Meetings/2022-11-22
From MozillaWiki
< Compatibility | Meetings
- Web Compatibility Meeting Meeting - 2022-11-22
- Minutes: Previous 2022-11-08
Contents
Minutes
Scribed by Ksenia
Workweek in Berlin (Honza)
Detailed agenda of the week
- honza: Simon will join us in Berlin as well. There will be 11 of us. We have the whole 3d floor, at least 2 meeting rooms. I'll be cancelling all meetings for next week, including this one.
- simon: bgrins was planning on doing http archive presentation for the whole team and I would like to help
Reporting web compat issues in our org (Honza)
- Providing simple instructions and process for greater org to report web compat issues
- Should be easy track it
- honza: what is the right way of reporting compat issues from inside the org? are there simple instructions on what one should do?
- tom: if they're not sure whether it's webcompat issue, they can just ping us on slack or report on webcompat.com. if they know that it is a webcompat issue, they could try to investigate it themselves (using testcase reducer, for example)
- dennis: better to not report on bugzilla, always on webcompat.com
- james: for a gecko engineer, probably better on #webcompat channel. if not, "report site issue" probably is best
- honza: probably people can use webcompat ? flag on bugzilla
- james: yeah, it makes sense. the usecase for it, "I have a core issue and I want to make it a higher priority"
- tom: would be helpful if people use their github account as anonymous issue have higher chance of being closed
Get compat reports from all channels (Honza)
- Blipz Experiment
- What went well and what not
- Can we get some inspriation and try again?
- honza: should we start getting webcompat reports from release channel?
- tom: we haven't too much value from them. but if we just want to capture them to look at trends, I'm not against trying it again. But we need to be prepared for it.
- dennis: the data we recieved was absolute garbage, people just reported everything. it might be worth reconsidering if we do it right.
- tom: we should make it org wide effort, not just webcompat. this might be a good opportunity to start talking to other teams about general error reporter
- james: we need to know the metric on how many sites are broken, how bad is compatibility problem. it would be nice to have release reports as long as they don't have too much noise
- tom: as long as we have enough headcount / other teams it worth trying
- james: perf looks like a good example and we got lots of reports. I don't think the usecase is getting high quality reports and such, but more for statistics and not for diagnosis. I would be nice to analyse reports not just from North America
- tom: tracking protection team might be interested, but we have to be careful so we not end up looking at the issues only by ourselves. maybe data science team could help.
- dennis: we would need some better infrastructure for better handling of data
- james: it will have to be a completely different backend
- simon: there is a bias for reports in English, so we would need localisation. There is a document https://docs.google.com/document/d/1s07ZVHF0ZswrCuSoP9W2cmDritLXsqOuGlZwhYQy02A/edit#heading=h.uugefq19ogtp about capturing signals from developers regarding webcompat data
- honza: I could start talking to the perf team to see how this could be useful for them
Needs triage issues on the week of Nov 28th - Dec 2nd (Paul)
- We will probably not be able to triage everything incoming in the week due to 2 days of National holidays
- Also, Raul will be on PTO the entire week, so only Calin will be triaging issues.
- We'll return to 0 in the following week when Raul returns. Any concerns regarding this?
Work week meeting recorded? (Paul)
- Due to the same reasons, Calin might not be able to join the meeting as he will be quite busy with triage.
- Will the meeting be recorded? We would like to watch it when we'll have the time.
- honza: we can record some important meetings. somebody should keep it in mind :)
"Cookie Banner Reduction" option - Android (SV)
- We have seen an interesting report about this option: [issue #114364](https://github.com/webcompat/web-bugs/issues/114364). How should we act upon such issues? The cookie banner is still showed, and the option is turned on by default in the browser. Is there a certain behaviour that we should look for when the option is enabled?
- james: this is probably not webcompat issues? they should be labeled
- tom: possibly we want to label and close them, but keep track of the list
- dennis: yeah I agree that we should close them
- tom: there is an extension to move issues from webcompat to bugzilla
- paul: just the list of such issues would help
- raul: can we close existing ones as non compat?
- paul: let's sync with the other QA team, but yes closing and keeping track of the issue should do it as they just need to know the domain