Compatibility/Meetings/2022-09-13

From MozillaWiki
Jump to: navigation, search

Minutes

Scribed by Honza

WebCompat Beta Report (Honza)

  • Create a beta report by the end of September to enable wider feedback
  • Original deadline: end of September (should we push it back due to PTOs in August and September?)

Thomas: we can use the AllHands time and talk about the possible improvements (we'll also have more time to focus on it). Let's see what we have. We might not reach the deadline, but. We should try to do our best to reach the deadline and not to worries to much. Even if there are other tings going on (TPAC, AllHands)

  • For top 10: perhaps we can focus on issues that can be fixed by Mozilla at this point
  • Focus on putting together useful information in the report
  • Decision: let's try to reach the current deadline.
  • Next steps
    • Top 10: Look where we are in terms on KB entries
      • Make sure that existing entries are complete (they should be done)
      • Resolve the list of suggestions for new entries
      • Risks: analyse the spreadsheet, data sources

honza: do we need to improve scoring algorithm?

james: probably no, but I think one thing we didn't figure out is duplicates. we can make manual adjustments for that

honza: If there is a core bug, we collect duplicates in "see also"

tom: in theory yes, but we also close them as duplicates of other github issue. the question is how much we care about duplicate as this data might not be correct since we don't do full diagnosis (i.e duplicate of the symptoms).

james: (1) have many dup reports for one specific reports (2) have many dup reports for many sites

Tom: it would be great to have the data, but we don't have to necessarily include it in the scoring logic. Should we use a label/mark to get the dups?

James: Yes, this is the quesion we should answer. It's not clear how to include this in the scoring, let's keep it separate. It makes sense to have a taks updating the KB regularly. We could use existing GH API, labels could be difficult.

Tom: we could use the "Closing" comments and spot dup. This comment might (in many cases) contain a link to the dupped issue. But, this doesn't have to be high quality data (rather a signal). We could have "standard phrase" rule when closing issue as dup (from now on).

Ksenia: We could look at issue state. It should contain references. We could use those refs ("cross-referenced" field, for example this issue https://api.github.com/repos/webcompat/web-bugs/issues/110562/timeline)

Tom: First deliverable: can we get good data? What is the value of dups? Perhaps they are not providing meaningful data.

James: I do think it's worth doing.

Tom: let's not prioritize this for the beta report. Let's focus on the KB entries and consequently see whether and how we could use dups.

James: the top 10 list can be used as an input for Interop 2023 suggestions list

Retrieved from "https://wiki.mozilla.org/index.php?title=Compatibility/Meetings/2022-09-13&oldid=1243904"