From MozillaWiki
Jump to: navigation, search


Scribed by Dennis

WebCompat Knowledge Base “Database” Design (Honza + Joe)

  • Honza:
  • Honza: Theres this document to keep track of plans. Let's discuss the details.
  • Honza: (discussing about the document, changes and notes are inside that Google Doc)
  • James: One of the key questions is "I'm working on an issue - is this related to anything in the knowledgebase?". How do we find stuff? Just via full-text search? Via a strict hierachy? How do I find stuff without having everything in my head?
  • Tom: We have to consider the different consumers: WebCompt diagnosers, who need to find issues by symptoms. Some structure to describe a symptom and tie it to potential issues. A few days ago, I diagnosed an issue with a site not loading, and it would be nice to have some workflow "what do look for when a site is not loading". Other categories can include "some content is missing", "image aspect ratios are wrong", ...
  • James: With high-level categorization ("something with zoom", "something with flexbox"), GitHub labels allows mapping that to existing structure. For the stuff Tom is talking about, it seems like people want to be able to do some full-text search.
  • Dennis: I think for a first iteration, something that would just allow us to have a simple search like "grep'ing over a bunch of text files" would be good enough. We can paste console messages and short descriptions of issues into a text file, and try if this is useful and if we can re-discover issues again. If not, we can think about a more complex solution.
  • Joe: A question that we're asked on a regular basis is "what are the most important webcompat issues" - and we don't have an answer to that question right now. The number 1 output of this is to have an answer to this question. If we have any goal with this, it should probably be to be able to build a list of the most important issues, that allows us to inform Gecko planning.
  • Dennis: So then we'd need to group data by Web Platform feature, having an entry for each feature, with links to Bugzilla bugs, WebCompat bugs, a description how this issue manifests, and a list of concrete CSS attributes, JS methods etc to be able to search for it.
  • Jamas: I'd start with the flattest structure possible. While there aren't too many issues that affect both DOM and CSS for example, some issues might be caused by Flex and Grid, and there needs to be a way to correctly label this.
  • James: While data should be available in some machine-readable format so that we can build some tooling (like "build me a list of all labels used to filter out related/duplicates"), this should be as simple as possible.
  • Joe: Next week, how about we look at the recently reported webcompat bugs and see if there is anything urgent?
  • [TODO] Dennis to look at the document and come up with a data schema (JsonSchema or similar) to s before tore data.
  • [TODO] After that, Ksenia, Tom, and James to try to fit existing issues into that schema, and to discuss in the next meeting what we missed or wha before t we need.

Fast Response Triage meeting ( 👹 )

  • Joe:
  • Honza: Do we have enough information to schedule this? Is something missing?
  • Joe: For me, the goal is to look at the recent issues, and to find out if there is anything we need to look at closer or more urgently. The doc is a bit unfinished, but let's just try it next week.
  • James: Do we want to schedule a seperate slot of this meeting, or do we want to make this part of the team meeting? We've been using the non-team-meeting week to go through the webcompat-priority? flags on Bugzilla, and I think we're getting value out of it.
  • [TODO] Honza to change the team meeting to weekly, move the webcompat-priority?-flag meeting to another slot, and add another weekly meeting for t before he triage.
  • [TODO] Dennis to transfer ownership of the current meetings before to Honza.