Compatibility/Meetings/2017-09-12

From MozillaWiki
Jump to: navigation, search

Minutes

Taipei work week summary (miketaylr)

I'll demo the work we've done around milestones during last week's work week.

  • Mike: Quick summary of the work week: Primary goal was to fix issue #886, which is about using the milestones instead of labels. The good thing about milestones is the APIs around it, it's very easy to see how many issues are in each bucket. Also, they are mutally exclusive, so when using it as a status, we cannot accidentally set two states at the same time by accident. We had a productive week, and there is only one issue left.
  • Mike: It shouldn't affect the UI/UX too much, you'll only have a second selector on webcompat.com.
  • Mike: One maybe controversial UX decision was to remove the close button. If you assign a "closed state" milestone (fixed, wontfix, ...), we will automatically close the issue.
  • Mike: We also had to clear the session database to fix a bug. It's possible that some people were not able to report bugs, but that's fixed. But that only affected logged in bugs, anonymous bugs worked fine.
  • Mike: Also, new bugs should have a priority label assigned now, since Eric landed his stuff.
  • Oana: What's the source for deciding which priority label gets assigned?
  • Mike: Currently it's the Top X list from Alexa. We might develop a smarter solution in the future, but for now, Top 100(?) websites will get assigned the critical label and so on.
  • Oana: It was a bit weird seing a "cropped text" issue with "critical" priority
  • Mike: Yes, it might be good to file an issue for that to get the discussion started.

57 Nightly bugs priority (miketaylr)

We need to be extra vigilant about possible regressions coming in the 57 nightly cycle. Let's make a plan.

  • Mike: Yesterday, in our internal meeting, people were talking about how important the release is and empathized that people doing issue triage should be sensitive about regressions in 57. Everyone should pay attention, so we can have a good release.
  • Mike: Also, he gave the WebCompat 'Report site issue' button a shout out and encouraged people to report all their issues. I'm not sure if we should change something for this cycle. Adam also had some thoughts around this.
  • Adam: There are a lot of bugs we can't reproduce, and it does not feel good to close them. Sometimes, I might ping some people in teams that may know what went wrong. Can we improve that? Can we use some better templating to ask for more information? Should we leave issues open?
  • Mike: So your concern is that we miss something important caused by not beeing able to follow up with questions?
  • Mike: Maybe we can improve our templates when closing issues. Maybe add a SuMo link. There isn't really anything we can do if we cannot reproduce, but if we are more careful when closing issues might be good.
  • Tom: Idea: When we had "Hello", a simple way to contact people. Why don't we keep an (anonymous) way to get back to users when we need. So basically a simple way to send messages to the anonymous reporters browser (if they agree on getting called back) if we have questions.
  • Mike: We also had the idea of asking people for email addresses, which won't show up in the bug. Maybe we could send a notification somehow.
  • Dennis: There is push notification API where each client is a unique, anonymous identifier. So in theory we could do that. I still have POC code laying around. I'll file a bug.
  • ACTION: Dennis will file a bug on that.

PerformanceObserver API (denschub)

Quoting Tom in https://github.com/webcompat/web-bugs/issues/9716#issuecomment-328694263: > "I have to admit that I'm worried about this API, given that they're not the first high profile site/service to mis-use it this way." I agree, so let's talk about this. (See also: https://bugzilla.mozilla.org/show_bug.cgi?id=1398477 )

  • Dennis: I've been reading in my GitHub mail and noticed a PerformanceObserver API bustage. It's not the first occurance. We should have a plan, it will land in 57 enabled and I'm not sure how it affects other sites.
  • Mike: What's the concern, if we ship in 57?
  • Tom: The problem is, the way the spec is written, if the UA doesn't support the things you're interested in is to throw. My suggestion is to turn it off for another release while it's worked out in the spec. The easiest thing to do might be to return a Promise, rather than throwing.
  • Mike: It might be good to send Overholt an Email directly. I'm happy to do that and CC the webcompat list.

Two Minutes (webcompat)

This is the summary of what you have done during the week. Feel free to add your own 2 minutes. Keep it short. Feel free to add your name if you think you need to share something.

Broken Voices of the Web

Web Compatibility Progress

FIXED (no DUPLICATE)

NEW

Retrieved from "https://wiki.mozilla.org/index.php?title=Compatibility/Meetings/2017-09-12&oldid=1180346"