Compatibility/Meetings/2017-04-04

From MozillaWiki
Jump to: navigation, search

Minutes

Introduction for Oana (miketaylor)

  • Mike: In the first meeting of the month, we focus mainly on webcompat.com development and leave out the rest, unless there are some important topics.

Needs Decision Issues (miketaylr)

Let's review. https://github.com/webcompat/webcompat.com/labels/status%3A%20needs%20decision Issue triage. https://github.com/webcompat/webcompat.com/issues/1474

  • Mike: just a reminder: if you need some clarity or a decision to move forward with an issue, just add the "needs decision" label and we will look at that once a month in this meeting.
  • Mike: For context, Guillaume added support for prettifier, as a tool to ensure code is formatted correctly, to avoid any style issues. The question I had was: we should document the workflow, since this is a new thing and everyone should do the same.
  • Mike: I proposed: you write some code and run a command to lint it, if there are some errors coming up, one fixes that and ammends that to the comment. Is this to manual or not?
  • Karl: Question: Thinking about python, when I edit some code, my editor shows me the errors. Will this work the same way or do I have to run a command manually.
  • Mike: The PR has changed, the way it is set up now is as a extension for eslint. So if you have eslint-support set up in your editor, it will show up. It's will be a little bit awkward at first since we first have to learn the new rules, but in theory we shouldn't need to learn them since eslint will tell us. Ola, since you suggested pre-commit hooks, what do you think?
  • Ola: I like the idea about writing code without thinking about code standards, and I often forgot to lint, so it would be nice if lint runs automatically.
  • Tom: There are also client-side git hooks, so we could set it up to run on everyones repo instead of a central solution (travis, ...) for everyone. So rather than standardize on a pre-commit hook, you could do it yourself.
  • Mike: Yes. Generally, the hooks are just a shell script inside .git/hooks/, so everyone can change stuff there.
  • Mike: So it sounds like we have general consensus that we want to have an automated hook. I'm going to document that in the issue, but we should maybe also document the manual commands, in case someone needs them.

webcompat tracking flag in Bugzilla (denschub)

We now have the webcompat-flag for bugs in BugZilla. We should discuss about when and how to use it and maybe how/when/by whom triage is done. I went ahead and requested webcompat? at https://bugzilla.mozilla.org/show_bug.cgi?id=876985 for now, since I've seen some breakages due to this!

  • karl: do you mean [webcompat] in whiteboard keywords. Or something else I have missed? Ah no… understood. bugs with webcompat flag. OK happy to hear how we would use it.
  • dennis: Now we have a tracking-webcompat flag in the Core component and in the Firefox for Android component. I want ttalk about how we can use that. There's no documentation for that yet.
  • Mike: we talked about this a couple of months ago. We wanted a way to signal that issues are important to webcompat.
  • Karl: A clarification - I still don't know how/who is setting the flag.
  • Mike: The motivation was: working with Cyberdees. (shows the tracking flag on Bugzilla via screen sharing).
  • Mike: With the "platform-rel" flag, the idea is to maintain high-profile relationships with some partners, so if there is an issue that might be important to a partner, someone requests a platform-rel?. Basically, that's a signal that that sometime in a meeting, someone will look at this issue and make a decision if this is important to fix. If the meeting decides it's important, platform-rel+ is used to generate a list of issues.
  • Mike: In webcompat, we have been using the whiteboard flag to track issues that affect web compatibility. The theory is that we can advocate for these issues and make people prioritize them. For example, yesterday, Tom found a weird Fennec issue that causes the reddit web-bug. So he files a bug, and he adds a request for web-compat tracking (webcompat?). So once a week (or whenever), we can have a look in our meeting so I can bring this up in our platform manager meeting to move these issues forward.
  • Mike: We could have done that previously with a list of issues, but here we can track it on bugzilla and have multiple statuses: webcompat? - we need to make a decision on that; webcompat+ - this is important and someone should have a look at it; webcompat- - this is not important to webcompat at this time.
  • karl: would this one qualify https://bugzilla.mozilla.org/show_bug.cgi?id=1352979
  • Mike: (shares sceren with Karls issue)
  • Karl: (explains replies in bugzilla) Summary: this is a firefox issue, and we are the only one having the issue.
  • Mike: yes, I'd add "webcompat?" there so we can have further discussion in the next meeting.
  • Mike: is this related to the base-xml-email Jet Villages sent out last week?
  • Karl: Somewhat, but this email was for svg documents, but this is something different. This issue is about SVGs respecting the HTMLs base element. Per spec, we are doing the right thing, seems like Edge is doing the same thing as well. Chrome implemented it, but backed out.
  • Mike: Interesting to know. If we triage this, the flag will help us prioritize and maintain a list of issues we feel important for Gecko to implement.
  • Mike: So I think the guidance is: If you're inside one of the qualified products, and you have an issue that feels important for webcompat to you, add the flag. We'll have a discussion about these issues in an upcoming meeting.

Waffle time - https://waffle.io/webcompat/webcompat.com (miketaylr)

'

  • Mike: let's review what's in progress.
  • Mike: #945 - Ola sent a PR, seems to be good.
  • Mike: #1468 - This one has been merged. Moved to done.
  • Mike: #1360 - I'm interested in feedback here. The media team is interested in using webcompat.com and they want to prepopulate the form with a stacktrace and they also want to be able to add a label "type-media" so they are able to triage. I got a PR open for this (#1453). In this PR, it's easy to submit labels via a "hidden" form field. However, since we're using the webcomat bot, all unknown labels will be added automatically, so this is a way for abuse. Karl, we talked about having a configuration file with valid labels, maybe this would be an idea? Another way would be to hit the GitHub API once and generate that list. You could hit the API each time, but this does not seem like a smart way of doing that.
  • Karl: I can look at that tomorrow.
  • Mike: I'll add a comment with more context.
  • Mike: #1449 - This came up as part of our CSP integration. Our current implementation injects another script URI, which gets blocked by the CSP. We've allowed that for now, but basically that's a bad situation and we should fix our GA integration. We want to move the GA integration into a seperate file.
  • Mike: #1432 - Carol did a lot of work to integrate Browserstack into webcompat. I will take this issue over, we can leave this alone for now.
  • Mike: #1425 - Karl, Ola, can you describe what's going on?
  • Karl: There was a PR of adjusting the size of the image, since they were not quite right. If you look at the SVG, there are some issues with that: the lines do not have the same thickness, the icons are not centered, so we maybe have to do some manual work on the SVG file to make them look the same.
  • Ola: The PR we merged fixed it via CSS, but this is something to that has do be done.
  • Mike: No one is working on it, so let's move this to Ready
  • Mike: #1385 - I think jeanhl wanted to work on this, I don't know if she has made any progress
  • Karl: I think this is a bit too complicated for a good first bug. The work I have done in #1384 would be relevant to this issue.
  • Mike: Let's give Jean a bit more time.
  • Mike: Let's look at the backlog now.
  • Mike: #1475 - Thanks for reporting this!
  • Mike: we were hiding the "remove" button, and having it keyboard accessible screws up the layout. This might be interesting to Guillaume, I'll ping him.
  • Mike: #1474 - This is ready.
  • Mike: #1473 - i'm not sure about this, maybe Karl has more information?
  • Karl: It would be good to have some tools to improve the documentation. I asked if she had a particular tool or a motivation behind this issue.
  • Mike: I have more context. pep257 covers docstrings (the way you do inline documentation). She emailed me and suggested we add it, as it could be useful for newcomers to have more parts of the code documented.
  • Karl: We have a lot of uncommented code, so this is good.
  • Mike: This might be a good contribution intro for her and others. I'm moving this one into Ready, it is a good thing.
  • Mike: #1471 - The issue here is just the opacity of the dropdown. It seems like it's ready for someone to fix.
  • Mike: #1470 - This is one of the main issues the new Outreachy participant will focus on. Sometimes, this test fails. Let's say this one is ready.
  • Mike: #1469 - This is another issue where Karl could help with.
  • Mike: This came up in a discussion with one of the folks from the media team. Gijs suggested to use a different URL encoding method in Gecko, so our server side should be able to handle this. This seems fine since we don't have legacy content, but I am not sure what's the best way of implementing this.
  • Mike: I'll ping you, Karl, on the issue.
  • Mike: #1462 - This is to ensure we don't break the textarea again. This one is in progress.
  • Mike: #1454 - The idea is that we don't want to have really motivated first contributors claiming multiple issues.
  • Karl: Yes, this is to say people they don't need to claim multiple issues at once.
  • Mike: Moves to ready, let's add a note on the documentation about the maximal number of "claimed" issues. I'll comment on the issue.
  • Mike: #1452 - This is done, right?
  • Karl: Yes, I think we can close this.
  • Mike: (moves the issue to done)
  • Mike: #1442 - I agree that it's not very obvious that there is a search field.
  • Mike: There are some suggestions, seems ready to just be fixed. Maybe something for Guillaume?
  • Mike: #1436 - Adam, do you want to give a quick intro?
  • Adam: Karl did some work on a script to ensure we understand what happens in the background and we don't miss thing. The background for this issue is that someone closed an issue via webcompat.com, and if it didn't have a weird label state, we would not have found this at all.
  • Mike: So the questions Karl had were about the process. This might be a good discussion to have in Berlin.

Webcompat - Adding details for issues on multiple browsers (Oana)

We suggest adding details of issues that are reproducible on multiple browsers, for tracking purposes. We could add these details in Column G of the daily progress document.

  • karl: Who in webcompat team is using the Google document with the progress made by Sergiu and Oana? I only look at the bugs when they land on webcompat.com. Issues which are reproducible on all browsers are what we call non-compat. They are currently accumulating in a milestone and basically nobody is taking care of them. non-compat. It follows up a request on December 2016 that we should not close them as invalid (because out of scope). Honestly for me it's like a cemetery of good intents. These are indeed interesting issues, but in a boil the ocean way. For example, we could probably add most of the modern Web sites for accessibility issues probably starting with webcompat.com.

Webcompat - Localization (Oana)

What about a localized webcompat.com version? Maybe top most used locales, after EN?

  • karl: this is an often discussed topic. We recognize there is a need. We don't really have the manpower to handle it for maintaining it AND for dealing with the issues after. To better explain, imagine when issues are open in Japanese or Chinese. We can't do triage except if someone with the language skills handle them. Our webcompat triage/investigators is either too volative or too small to be handled those.

Webcompat - Allocate time on testing Webcompat.com (Oana)

Report Bugs/Enhancements, Design Test Cases, Wireframes

  • karl: If you find a bug on webcompat.com that you think need to be fixed, open a bug for it (don't forget to search the previous issues). As for allocating time to softvision for it, I think it's a question for Mike Taylor. I don't think it's the priority in the sense, we all do that already and sometimes through volunteer UX contributors. It's not like our purpose is to develop a product usable and reinstallable by others. We develop the tool so people can contribute webcompat issues and participate in analyzing. The scope is different than for example Firefox. # Non-verbal updates

Webcompat - Testing progress (Sergiu & Oana)

Testing done so far. Issues logged so far. Accounts were created for most of the sites tested.

  • karl: This looks like a status update. I wonder if these should be on the mailing-list instead of the etherpad. A regular weekly email with, for example, [Softvision webcompat testing] 2017-04-04 Status Update and most of the items below. The etherpad should be probably reserved for things which requires direct discussions.
  • Sergiu: This info is also included in the weekly status update that we send out to the mailing-list. We can keep it out of the etherpad, along with any other status updates we might have.
  • Mike: thanks for the plain text emails. :)

Webcompat - Retesting (Sergiu)

Retesting the sites which were not tested enough. Progress can be identified in the mentioned document, by the blue color.

  • karl: Is there a question or is it just a status update?
  • Sergiu: This is just a status update.

Webcompat - office.com and word documents (Sergiu)

We were unable to create Word documents on office.com. The sites requests using the App. Every other Office web-based app works fine.

  • karl: is there a followup question or is it just a status update?
  • Sergiu: This is just a status update.

Webcompat - Android Crashes - Bug 1218607 (Sergiu)

Issue 1218607 sometimes hinders testing (eg. Pinterest).

  • karl: Is there a question?
  • Sergiu: This is just a status update.

Webcompat.com - Web-bugs (adam_s non-verbal)

Issues reported for week of: March 27, 2017

  • Total: 96
  • Valid: 23
  • Needsinfo: 2
  • Incomplete: 5
  • Worksforme: 26
  • Invalid: 25
  • Duplicate: 20
  • Wontfix: 0
  • Non-compat: 12

Broken Voices of the Web


Web Compatibility Progress

FIXED (no DUPLICATE)

NEW

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