From MozillaWiki
Jump to: navigation, search


  • Scribe: Tom
  • Chair: Dennis

WebCompat KB NG (Honza)

  • Any concerns about the new proposal?
  • Any questions for Bobby? Or is all clear?
  • We need effort estimate (engineering months)
  • Dennis: overall I think everything is clear, as we discussed last week. Still a big question mark around actually making th reporter happen, and providing a time estimate, due to other teams being involved. We are only responsible for doing so much of it ourselves.
  • Honza: we don't have to provide the full estimate, just for the parts we're doing. Bobby has also promised help in connecting and syncing with the other teams.
  • Dennis: I'd be surprised if this requires more than a person-month of engineering, though it will of course take longer than a real month. I haven't heard back about the status of the Google Cloud deployment, so there is also risk of the timeline dragging on if teams are too busy for something. But if we have an organizational chain to help us keep other teams active, that might be enough.
  • jgraham: we should write a requirements doc with a proposal of what's required from other teams, linking to Bobby's document. and we can sent our proposal and send it back to Bobby for approval
  • honza: so will it be 2 docs
  • james: one document for frontend (the db + ux) and then the backend (telemetry). we have questions, how much can we link these reports agains the telemetry. we can specify the requirements for each part of the system
  • dennis: do we have resources to start on the frontend requirements document? we might not have time to do it right away.
  • james: we need to get the document done first before other work can begin, so it's important to get it done sooner (this week if possible)

State of Webcompat Report? (jgraham)

  • james: are we planning to do a reduced SoWC report for Q1? if so, we should get to work on that right away. (we had discussed doing one with trends, risks, and maybe stuff from the Safari release).
  • honza: we're not pressed to have one in the next two weeks or even this quarter. other teams already have enough work from the old reports to carry on. we don't have a milestone to go by yet anyway. in the meantime it's up to us what we want to do or share with the org. for instance, the Bocoup analysis could have things we want to share, and trends we're seeing like with unsupported-labelled issues (I'll meet with bgrins to discuss this today) and yes, checking the Safari release notes for important platform gaps and other notes. I'm not sure what to call these interim reports (mini SoWC report? of specific to what they're about, like "Safari anaylsis")?
  • james: if the goal is a unified summary we should probably start a summary/highlights doc now that we can fill out over time, and link it to the bigger doc. But then there may be no point if higher-ups will look at all individual docs in detail?
  • dennis: we don't have time to do a full report, and it will only be duplicate data from the last one. I think we mostly need to inform others about sites intentionally blocking Firefox (unsupported) but it sounds like we're already beginning to do that.
  • honza: then I can imagine individual docs about Safari, unsupported, etc being the way to go.

Question from Jon about Connect (Dennis)

  • dennis: community manager (Jon) pinged us about seeing people report webcompat issues on Mozilla community site, Connect. right now Jon sends me a link, and then I send a link to the rest of the team for visibility. this isn't scaling, as sometimes we miss them. is there something better we can do? one first idea is to just have them redirect the questions right into, for instance. Or they could use SuMO, but there isn't a clear methodology right now.
  • james: should we feed them into the new reporter as we develop it?
  • dennis: people on Connect generally expect answers right away, because it's about moderating ideas. I don't think we can just dump them into a database without doing anything, but I think Jon would be fine with some sort of automated comment at least. On the other hand, the reports aren't usually very actionable or have good STR, and can be rather irate. Maybe "forcing" them to re-file reports on will at least give them a chance to file a good report more often.
  • honza: agreed. Jon also pings me about these and I've requested to just re-file on Jon is ok with that.
  • dennis: okay, then for now I'll ask Jon to re-direct those folks to, and later when we have the new reporter we'll revisit this to do so automatically. Jon's team is happy to direct folks for us.
  • james: a problem to think about is if we start collecting these webcompat reports, can we link back to inform them once a fix is done? i can imagine it being challenging, but maybe it's feasible and worth discussing? (to contribute to a feeling that Firefox is improving)
  • honza: once in a while Jon pings me about a bug getting fixed, and asking to update the thead on Connect, so this sounds like a good idea.
  • james: right, just clarifying in the original report (wherever it was) when a fix will be available, which Firefox version, should help with that.
  • dennis: even if we only do so in one spot, and users know where their bugs were moved to, is better than nothing.