Compatibility/Meetings/2022-07-12

From MozillaWiki
Jump to: navigation, search

Minutes

Scribed by James

H2 2022 Planning (Honza)

  • Honza: What do we need to do to reach the milestones? Current document suggests some targets and milestones. Not clear how many knowledge base entries we can expect. Want to focus on quality of data. As we use the database some improvements to the design will be required. Fast response triage and priority bugs will provide inputs, so will bugzilla entries e.g. web-compat priority P1 and P2. Also Web Compat. components e.g. S1 and S2. Could also use wpt failures, although that might not be easy. Work might help us understand the landscape. That's the goal. Risks with the database: it can be too big and we don't have a good search UI. For a small number of items we can just remember the entries, but that doesn't scale. Also no cleanups. We don't want to keep obsolete data. Other rows in the table are directly about milestones. We want to do this in steps, e.g. to learn the structure of the report. Suggesting that by the end of July we have 30 entries. Might be able to pick a top 5 from those 30 and put together a prototype of the report using those entries. Might want to try using the "Japan" trend as an example of identifying a pattern. At this point we will know more about how to put together the report, and what constitutes a trend. Examples of trends: * Site owners decide to not support Firefox. * Other vendors are going to implement an API that isn't on our roadmap; likely to be an upcoming webcompat issue. * Something that works in other browsers but not Firefox. As we go toward the end of next half we might learn more about how to present the trends. Other milestones aren't that different. Next is 0 entries which is 3/week. Not sure if this is the right speed. Might then identify top 10 issues. If we decide to use Telemetry we need to land it soon enough to collect the data. Would need to land by this milestone to have data by November. Might also have other sources like HTTP archive. Final report: 90 entries target. Looking for top 20. Should be able to finalise report. Incorporate feedback collected from reports at previous milestones. Should have a good overview of the landscape that we can use to answer high level questions, and help platform teams set priorities. List of actionable tasks to meet OKRs.
  • denschub: Sounds like a solid plan. Can't predict the future e.g. we might dig through all existing issues and not reach 90 entries if there's a lot of dupes. Hard to know how many kinds of breakage there are until we do the work.
  • Tom: Risks are not about stuff that will impact us directly, but the OKRs could be too specific to meet, even if we get good data.
  • Honza: What do you think about triaging P1/P2 in bugzilla? New meeting? Background activity.
  • Ksenia: Core bugs triage is more important. We don't usually adjust P/S flags in Web Compatibility component. webcompat-priority field is more polished because we're actively triaging that. If we run out of issues we can look at Compatibility component.
  • Ksenia: 33 P1/P2 issues in Web Compatibility component, so we could just divide them up and add them to the knowledge base. It's hard to find entries that are worth adding. Looked at P1s we were going through. There was one for Google Sheets which wasn't that important, don't know whether to add it.
  • Dennis: We should default to creating entries when we see an issue; it shouldn't take too long. Unless it's something that requires an hour to dig into just add it. We don't have too much knowledge. One thing that I'm confused about is the distinction between a Firefox bug and a Web Compat issue. e.g. Slack issue which is some kind of Firefox bug but it seems to only affect Slack. If we create a kb entry for every Firefox bug that breaks a site we'll have a lot of entries very quickly.
  • Tom: Worth creating kb entry if there's detail, but if we don't have details have a general issue that links to all the issues which seem to be the same kind of breakage.
  • Dennis: So we should probably just create an entry for any kind of site breakage?
  • Tom: That will help us later on if we start to see more issues of a similar kind and identify trends. For webdevs it might be helpful to be able to look up "all the compat issues with service workers"
  • Joe: Are we just duplicating bugzilla?
  • Tom: Gives us one place to look up all the issues that are related.
  • Joe: Almost all bugs in gecko could be webcompat bugs.
  • Dennis: Yes. Maybe slack example wasn't a great example https://bugzilla.mozilla.org/show_bug.cgi?id=1778322 is technically a webcompat bug because it affects GitLab and some other sites. It's a browser difference between Firefox and Chrome. Should I create a kb entry for this? It would be the same information as we already have in bugzilla. Maybe in this case the answer is "yes" because it affects a lot of people. But there are lots of bugs and they could all be webcompat issues. Don't want to duplicate bugzilla.
  • Joe: Purpose of the kb is to help answer the question "what's the state of webcompat in Firefox". For the purposes of that question, a simple bug isn't a webcompat issue. If there's a bug but we're doing "the right thing", that becomes a webcompat issue.
  • Tom: Sounds like webcompat vs interop. Sounds like something
  • James: Sometimes bugs are important WebCompat issues. Even if the platform team wants to fix it and it's clearly a bug, it's still a WebCompat issue. The Slack-example is clearly a bug, but if we know there are a bunch of Service Worker issues, this is a pattern worth paying attention to. What Tom suggested, like adding a "Unspecific Serivce Worker issue" to the Knowledge Base, is helpful and can help the platform team prioritizing investigating and fixing Service Workers.
  • Tom: We could also create a metabug and link the metabug.
  • James: If you create a metabag for every KB entry, then what is the KB even useful for, it could just be a bunch of bugzilla labels.
  • Dennis: Having a kb entry for generic service worker entries seems like a good idea. Then we don't have the problem of creating one issue per observed bug.
  • Tom: Other browser vendors might want to add their own entries, so maybe don't want to tie it too closely to bugzilla.
  • Dennis: I think we should accept pull requests if other vendors want to be involved. In the short term we should focus on the requirements of our Web Compat team rather than other teams.
  • Tom: Maybe that makes it worthwhile to have a metabug issue.
  • Dennis: I'm fine with that. Also, expected behaviour in Firefox that breaks sites is a webcompat issue e.g. download issue. That should get an entry.
  • Tom: This will organically grow, so go with our own flow.
  • Honza: Could we have a concept of grouping? If we have a lot of entries that are all related to service workers could we have a generic entry that contains the others?
  • Tom: That's what I was thinking about the metabug.
  • Dennis: We have tags, so can group that way. Or subdirectories, but tags are easier.
  • James: On grouping and searching: A thing that's not on the roadmap but probably should be: Progressing the tooling. There are a lot of things we can do, like letting us know if a bugzilla bug is closed, a bit of searching (like searching for tags), ... there probably are a lot of areas we'll realize we want more tooling for.
  • Honza: Some maintainance will be needed to ensure data quality.
Retrieved from "https://wiki.mozilla.org/index.php?title=Compatibility/Meetings/2022-07-12&oldid=1243401"