Compatibility/Meetings/2022-06-28

From MozillaWiki
Jump to: navigation, search

Minutes

Scribed by Thomas

Knowledge Base: Steps to Reproduce in YAML, or not? (dennis)

  • Dennis: For context, see the discussion in https://github.com/webcompat/knowledge-base/pull/13
  • Dennis: Both opinions are reasonable, so we need to make a call here.
  • Dennis: two topics: console messages (non-controversial?), and storing steps to reproduce in YAML (is the approach in the PR going to dupe too much info? Is there a better way to do it?)
  • Honza: I do like the view of the KB being an index collating resources, and being easy to search (with links to bugzilla/etc for STR to reduce duplication).
  • Dennis: we might not even need a second link to STR, but could rely on the primary link as also being the one to the STR (by linking to a specific bz comment, for instance).
  • Honza: SGTM
  • Dennis: ok, I'll drop that comment entirely and keep that section in the format as just a list of URLs.
  • Ksenia: I wonder if we should have a section just for STRs, with the links etc, so they are separate from issues.
  • Dennis: the key is already called "breakage", secondary key being "platform_issues"

Knowledge Base: Common definition of severities (dennis)

  • Dennis: We should agree on a definition for the knowledgebase. Suggestion:
    • critical: Site is breaking in a way that would force users to use another browser.
    • high: The issue can be worked around, but it's annoying enough tht a user might feel compelled to use another browser.
    • normal: The issue is annoying, but can be worked around by the user inside Firefox.
    • low: Minor visual issues that does not affect the user's tasks.
  • Tom: does low include minor UX issues (having to click a little more, etc), or is that "annoying" enough to be normal?
  • James: is the sites' popularity something that should be a factor? (a multiplying factor in a separate field, perhaps?)
  • James: maybe two fields, severity and user impact?
  • Dennis: what would the difference be?
  • James: number of users impacted for instance, how likely you are to run into the issue, vs how bad the breakage is
  • Joe: site rank can change over time, so maybe focusing on the one user (reporter) might be ok. We can aggregate broader data from multiple issues.
  • James: we may not have high enough quality data to do that aggregation?
  • Tom: might be worth capturing separately, as we rely on site rank to decide on severity now, and this would let us automate and document the site rank and show why we decided on a given severity more clearly
  • James: there are other considerations too, like maybe we happen to know that a given library is being changed on Facebook et al.
  • Tom: maybe that's detail better left to comments?
  • Joe: so maybe we should add a second field to ensure we catch the severity of *each* issue, not the broader underlying cause?
  • Dennis: I'm not sure if there's value to tracking individual issues like this compared to the broader underlying cause
  • James: the breakage caused by one issue can vary drastically between sites/issues, though (a pixel off here, total breakage there).
  • Dennis: sounds like our decision here today is to track both potential number of users affected, and what we're currently calling severity (although using numbers might be overkill).
  • Ksenia: this might be a lot more work than just automatically getting site rank and deciding on a coarser-grained value for "number of users affected"?
  • Joe: bear in mind that by November, we'd like to have a justifiable ranking of issues.
  • Dennis: we'd like to prioritize critical breakage affecting a lot of users, so we probably need both signals.
  • Ksenia: I agree with James that making an intuitive judgement call for "number of users affected" might work?
  • Joe: I think "is this info useful for making a judgement call" is the interesting question here?
  • Joe: maybe the default should be to record it, as it's easier in hindsight to stop doing it than to find out we need it later?
  • Dennis: so let's keep the existing severity field as-is, and add a new one to track this new field. (I'll figure something out)
  • [TODO] Dennis to add a sec before ond field.

Knowledge Base: License? (dennis)

  • Dennis: There's a PR for adding a license. Does that sound good?
  • Dennis: picking a classic code license is tricky, as it's mostly data, not code. CC0 is my first choice right now as a result, especially since MDN is also using it for webcompat data.
  • Joe: I think that sounds fine. We have a document we should check before choosing a license, have we checked that?
  • Dennis: yes, I think based on the wording in that document CC0 is still fine.
  • James: a lot of the data is just a collation of data, so I think it depends on jurisdiction maybe, but CC0 sounds reasonable.

DevTools for diagnosing web compat issues (Honza)

  • Honza: I've surveyed past documents and projects (team meeting notes/proposals/etc) and created the above document.
  • Honza: proposals don't have to be new things, could be a tweak to existing workflows.
  • Honza: rather than just focusing on webcompat, we'd like to also focus on developers (issue reporting, etc) with a focus on off-loading more work to the devs instead of the team.
  • Honza: for instance, having something which lets us not have to use Charles proxy for diagnosis, which devs would also benefit from (live-editing JS?)
  • Honza: once the table at the bottom of the new document has proposals, we could schedule a meeting to discuss them with the devtools team more directly (sometime during H2).
  • Joe: as long as we retain the distinction that the devtools team is meant to prevent/solve future webcompat issues, as compared to webcompat team being about today's issues.
  • Dennis: we have had a session where we discussed issues and did some diagnosis while the devtools team observed us. Such "pair diagnosis" so the devtools folks can watch us and see what we're doing might benefit us a lot? Joe et al: brilliant!!
  • James: what about the compatibility panel in the devtools? Is it useful, according to telemetry?
  • Honza: I'll take a look. It's quite hidden (side panel, not visible by default, etc). It's unclear if it's useful. We should try to improve it.
  • [TODO] Honza to schedule a meeting with the devtools team after we have some data/ before proposals.
Retrieved from "https://wiki.mozilla.org/index.php?title=Compatibility/Meetings/2022-06-28&oldid=1243191"