Compatibility/Meetings/2017-05-09

From MozillaWiki
Jump to: navigation, search

Minutes

Site issues already logged in Bugzilla (Sergiu & Oana)

We saw that several issues were closed as duplicate due to existence of a correspondent in Bugzilla. We could stop logging this type of issues or log them along with a comment that contains the Bugzilla bug number. We already gathered a list of issues that we encountered along the way: Abnormal Radio Buttons: https://bugzilla.mozilla.org/show_bug.cgi?id=1352238 Abnormal Check-Marks: https://bugzilla.mozilla.org/show_bug.cgi?id=1352238 Small allocated space for Username/Psw/Search fields: https://bugzilla.mozilla.org/show_bug.cgi?id=752790 Check-Marks not working: https://bugzilla.mozilla.org/show_bug.cgi?id=1357169 Arrow position not centered: https://bugzilla.mozilla.org/show_bug.cgi?id=1362898 Selected option is not centered in drop-down menu: https://bugzilla.mozilla.org/show_bug.cgi?id=1362907 Text truncated if displayed on multiple rows: https://bugzilla.mozilla.org/show_bug.cgi?id=866102

  • Oana: It's about issues already reported to Bugzilla. We need to know if we should file the bugs if there is already an issue on Bugzilla.
  • Mike: I think it's worthwhile to file bugs, even if we close it as dupe. We're supposed to mark them as "see also" in Bugzilla, so you get some kind of measurement that a bug is more important. So I think it's more important.
  • Sergiu: That's why we suggested adding the bugzilla ID to the webcompat.com issue so the person doing triage does not need to search for it.
  • Mike: Yeah, that's a good idea. Just add a comment "Maybe a dupe of Bug xxx"
  • Sergiu: If it turns out not to be a dupe, we still have the reference there.
  • Karl: It's still good to log them, the more dupes we have, the more it shows there is something to fix. The popularity of a bug is helping a lot.
  • Tom: You can add more than one "see also", so it still might be worth adding them.
  • Mike: But you can only set it once you have to file a bug.
  • Tom: True, you could just add a comment with more information.
  • Sergiu: If we have nothing on webcompat.com, we have nothing to link to, yeah.

Meeting with Google Platform Integrity (miketaylr)

Mike met with Rick Byers and foolip. What does it mean for us?

  • karl: "for us". webcompat.com? or mozilla?
  • mike: When we were in Berlin, I got an email from Rick Byers. I set up a call that was in Friday. Phillip J was also on the call.
  • Mike: The gist was: They're interested in working with us in more ways that we're currently working together. The team is working on interop between multiple engines. They are not "Google" people, they are WebKit people, so their reach may be limited. However, they want to set up a regular meeting to talk about the top web compat issues. They'll send an invite, everyone is welcome to join.
  • Mike: They are ways they are able to move some things, even if it is stuff like writing specs to move Chrome.
  • Karl: You mentioned they are interested in the "Top 3 issues", but the top three issues we have are they talking about different implementations for specifications or about website issues.
  • Mike: They are more interested about spec issues. For example, they fixed a Google property because of some border-image spec issues. They are interested in unifying the web, even if this sometimes means specifying the Chrome behaviour and getting Gecko to move.

webcompat Priority triage (miketaylr)

How and when should we be deciding "diagnose-next" and "diagnose-later" (or whatever our categories are)? How might Alexa ranking help with this?

  • karl: This one is probably both for Tech Evangelism component on Mozilla Bugzilla and webcompat.com (firefox). We do not know yet what we consider relevant for domain names/alexa ranking. We have a sense for certain domain names, but it's probably not obvious to jump from Alexa ranking without looking at the data first.
  • mike: agreed, Alexa is a good signal, but it could be a very popular site, but the bug is minor.
  • eric: besides ranking, the impact to user experience and if it's already fixed in Firefox is also important to me.
  • dennis: we should probably decide on the priority while triaging, since we have a look at all issues that way anyway. having a second round feels redundant.
  • Mike: Dennis' suggestion is interesting, since Tom suggested a second round of triage, so we can have the people doing the diagnosis work to add the priority.
  • Dennis: i'm just concerned about spending too much time on triaging
  • Tom: I'm wondering if we have some guidelines what we consider "minor"
  • Mike: Karl and Adam, since you do 99% of the triage, do you think it would be useful to add a severity at the time of adding the needsdiagnosis label?
  • Karl: Probably depends on the type of issue. If it's a layout issue, we all understand that these are important, but if it's only a minor issue where something is "not perfect" but the site is perfectly usable, that's probably a minor issue for us to look at. It's still good to file them and to have a look at them, but it's not a major user experience failure.
  • Karl: However, if something like a button does not work, or of text is not readable, these issues are important.
  • Mike: Sounds reasonable. When you look at the issues at triage, do you want to assign the diagnosis priority based on that judgment?
  • Karl: It's a mix of different things. We can't just judge by the "type of issue". Even if it's a minor visual issue, if it is a high-traffic site, we still annoy a lot of users, so that's something to consider as well. If diagnose people trust us with assigning the priority, we can do that.
  • Tom: It's not really a matter of trust, more a matter of time. We don't want to spent too much time with triage, so that's good.
  • Mike: That's an interesting suggestion, but we still want to be able to flag bugs for someone to work on next.
  • Karl: So that's something different then. You're suggesting a ranked "ToDo" list.
  • Mike: Possibly! If we have two labels "diagnose-later" and "diagnose-next", we direct the work to those issues.
  • Karl: But then you could only have one issue "diagnose-next" to make it sense.
  • Mike: If you take the wording seriously, you're right, but that's just a word. We could rename that to "diagnose-important".
  • Tom: If something is really important, we can assign someone if it is really important.
  • Mike: I feel like there is a misunderstanding. I'm not talking about planning people's days, just about marking issues as more important to diagnose. I'm talking more generally. If you have 1000 issues that needs diagnosis, but how do you know where to start working on. If it is some minor visual issue, we can wait in this issue, but if there are super important issues, we need a way to mark them as something we really should be working on.
  • Karl: Why do you think we need two labels instead of just one that marks "this is super important".
  • Mike: I do not care, that's basically the same thing. We just need a thing to mark issues as important somehow. That's also the reason Eric is working on a bot that adds importance information to the issue. We're not able to diagnose everything in a sensible timeframe
  • Adam: Perfectly would be something at 1 day from start to finish, but that's far off.
  • Mike: We have a limited number of people to work on that, so that's probably impossible. And our ability to diagnose every single bug will get even worse in the future if we add the reporter to DevEdition.
  • Karl: The priorization also depends on the complexity of the issue maybe, there are issues that are pretty easy to judge, but there always will be more complex ones that we can't really judge if an issue is important or not.
  • Mike: I asked some people about when we want to do this priority assignment: At triage time, in a seperate round for assigning that by the people doing diagnose, or mixing both in cases where it's not really clear and the person doing the assignment feels like someone else should check it.
  • Karl: I feel like we should do this at triage time.
  • Eric: I agree with Karl.
  • Adam: I am on the same page. We're still looking at the site anyway and it should be possible to judge the impact of the issue. It adds a lot of value just for us to make a suggestion, and people can always reassign labels if they feel like it.
  • Mike: Makes sense. None of us have perfect information, and we can disagree with each other if in doubt. It's also okay to just ping something if it's totally unclear, so people can assign priorities. (Tom agrees, Dennis agreed earlier)
  • Dennis: I already suggested the same thing, at triage time.
  • Mike: we still need a bit more information. Do you think we should add the labels today, or should we wait until we have stuff like the alexa bot? (Team agrees that we can start now)
  • Sergiu: I have a question: How does the Alexa thing work? Sites may be on a low position on a global scale, but very high in a country list.
  • Mike: I think it's unknown. We have a specific GitHub issue (https://github.com/webcompat/webcompat.com/issues/1533), can you raise that question in the issue?
  • Seriu: Sure.
  • Mike: Dennis and Tom, do you want to agree on a label.
  • Dennis: I don't want to bikeshed a name, suggesting "diagnose-important"

webcompat tracking triage (miketaylr)

As of May 8, 2017, we have 12 bugs with the webcompat flag. See https://mzl.la/2pUnwmP

  • Mike: (quickly explains the label again, as discussed in earlier meetings, for the people who missed that) https://bugzilla.mozilla.org/show_bug.cgi?id=218415 - "Request for window.event object added to DOM to ease cross browser scripting"
  • Mike: I've been going to older issues and fine more examples. It's clear that this is an issue, so let's + this. https://bugzilla.mozilla.org/show_bug.cgi?id=737658 - "Fennec should raise the same key down/press/up event sequence for input forms, regardless of device type or OS version"
  • Mike: Sounds kinda nasty.
  • Tom: This is a compat issue for sure that needs some fixing.
  • Karl: We have some webcompat.com issues for that.
  • Mike: I feel like this is one of the polish issues that we just should to fix.
  • Tom: This is really something that needs adressing, it's a blocker if you're trying to do a cross-browser editor.
  • Mike: Let's + this and ni? Harald. https://bugzilla.mozilla.org/show_bug.cgi?id=752790 - "Input padding covers text when the padding is greater than (TextHeight - InputHeight)/2"
  • Karl: It sometimes covers the text inside issues.
  • Mike: This is a +, this is bad. https://bugzilla.mozilla.org/show_bug.cgi?id=866102 - "ellipsis multiple lines text doesn't work (i.e. add support for -webkit-line-clamp)"
  • Tom: does need spec work.
  • Mike: There is no spec, and there are no spec issues that covers this. Might be something to bring up with the Blink people. When we first learned about it, nobody used it, but people start using it, so this is important. https://bugzilla.mozilla.org/show_bug.cgi?id=876985 - "flex items with flex-basis:auto and width:auto should get sized as max-content"
  • Mike: it looks like we're doing the wrong thing here. Dennis, if you could add the links to the issues?
  • Dennis: will do. https://bugzilla.mozilla.org/show_bug.cgi?id=1246727 - '"-moz-appearance: button" doesn't hide a <select>'s downarrow button, on Android'
  • Karl: this is something important we should look at this.
  • Mike: will do that after the meeting.

Broken Voices of the Web


Web Compatibility Progress

FIXED (no DUPLICATE)

NEW

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