Compatibility/Meetings/2017-06-27

From MozillaWiki
Jump to: navigation, search

Minutes

introduction (mike)

What do you want to achieve this week, who do you want to meet? What are your goals?

  • Dennis: quantum work flow.
  • adam: Want to work of webcompat philosophy. I want to find the right balance of work.
  • eric: Find/fix some issues with Alexa webhook in python. And gofaster planning.
  • guillaume: webcompat.com layout, StyleGuide.
  • karl: (wants to take notes) finish / kill webhook for type-media, deploy thing, <- please fill in karl, sorry!
  • mike: The nightly has been redesigned. so webcompat report button has to be redone. Milestones to rewrite. Finish to window.event spec work. Solve with beatriz the geckodriver bug.
  • Tom: chat with mike about window.events, dennis add on and treeherder.
  • Carol: #1547 and follow up #1552, #1574, discussion with Ola about #1551 / #1565
  • Ola: Living style guide. Architecture about webcompat.com. Talk about webcompat.com testing.
  • Beatriz: geckodriver bug out of the way.
  • Jet: I'm part of the layout team. I'm very interested by what the webcompat team is doing.

type-media (karl)

'

  • karl: gives an intro into what these type-media bugs are. we have someone who is traiging a few of them, but not many. alfredo Yang (not in sf all hands due to family issue. find Blake Wu), but he doesn't know our process. i'm working on a webhook to close them automatically (the dupes), so we don't have to do anything automatically. there's a meta discussion before we land this code, do we want to continue this on our infrastructure? or do we want to just kill it.
  • mike: we could make it in a way that the bug goes onto bugzilla instead of webcompat.com. One of the benefits of webcompat.com you can report anonymously, which you can't on bugzilla.
  • tom: maintain a separate
  • karl: If we were coming to this end, I would say, here's the code, you're free to use it.
  • adam: what is the problem they are trying to solve and do they still want to solve it?
  • mike: it doesn't cost us anything but time. It's a social cost. Work time for triage. We can ask the media team (Anthony Jones) if the current setup is useful.
  • mike: i like the idea of catching as man bugs as possible, and to have as many customers as possible.
  • karl: it is really hard to manage, it takes time and is very repetitive. makes the job of triaging even more boring than it is usually.
  • mike: your current approach is to write tools that help us to manage it, and I think this is the better approach then to try to reduce the amount of bugs, since eventually we have to deal with larger amounts anyway.
  • tom: we should probably reach out first, check if the media team is still interesting.
  • mike: yeah. if they are still interested in these issues. if they are not, let's turn it off.
  • adam: people were signing in on github, file an issue, but never got any response to it. maybe we should make that more clear, or even modify the form to not allow signing in if it is an automated type-media report.
  • ACTION: mike to meet with Anthony Jones for type-media bugs - 2017-06-30

Architecture overview. (karl)

'

  • mike: we have a flask python app serving html/css/js assets. At its core it's a bug form. We post the data to our backend. When I wrote this initially, I wanted to use github API. The python app is talking to github the API. We have a couple of automatic labels. webcompat-bot is a privileged user which can also handles anonymous report.
  • karl: the python web-app is distributing a template, but it's not serving the actual issues. the client side pulls the actual github data via javascript. the reason we did that is so that the user has a quick first-experience while loading issues, since loading data from github could take some seconds. I wanted to make a python-only version, just to see if there is an actual performance gain.
  • karl: people who contribute the first time have a very hard time figuring out where everything is, since it is quite complicated to understand how everything works and how each layers work together. we should maybe build a graph to visualize how the code base works and how individual parts work together, so it's easier to understand.
  • ola: question for context: why python? Is there any reason why Python was chosen?
  • mike: I like Python. Flask is a lightweight server-side framework. We have it because I wrote it that way, there is no huge reasons behind it.
  • mike: let's talk more about the architecture and document more at a later point.

team meetings (karl)

'

  • mike: we only have a meeting when people have items to discuss. do we have any feedback? is this good? do people like it? should we change something?
  • dennis: i like it.
  • adam: maybe there is a bit confusion about what qualifies as "important" to have the team meet about. we maybe should have guidelines what is important for a meeting.
  • karl: most of the items that could have been an email are from ioana and sergiu. we probably should encourage them to write to the list more.
  • karl: just a reminder: everyone is welcome to add agenda items. however, if you feel like we can perfectly work the issue out via email, write them to the list.
  • ola: sometimes, I would love to hear from everyone what everyone is doing. it's really interesting to know what people are doing.
  • mike: i agree. we had that in the past and we still do that sometimes if we have time.
  • karl: the team is getting larger. if we only spend 2 minutes per person, with 10 people, we still would have to spend 20 minutes, which is quite a time. we tried sending weekly updates per email in the past, but that only works if everyone is participating.
  • ola: we had this issue in my old company. we solved that by having a slack bot that pinged everyone who has not shared their update.
  • mike: we could also treat it like the webcompat.com triage: don't share weekly updates, share montly updates. but let's come back to that, for now, let's keep doing what we are doing.
  • dennis: It could be weekly, which would keep the amount of items smaller.

newsletters + screencasts (karl)

'

  • karl: there are photon and quantum newsletters, which are really interesting for people to know what other teams are doing. In the past, we did lighting talk like presentations in the weekly project meeting, we don't do that anymore, but maybe a newsletter would be a great way to share updates. https://public.etherpad-mozilla.org/p/webcompat-news
  • karl: that list is a collection of anything we did or do. if a layout issue was fixed, we should add that to the list, since it is also our teams work. if you want to add something, add it to the list.
  • ola: I would also love to add good first bugs to the newsletter, to make it easier for people to start contributing.
  • karl: basically, add everything you think is newsworthy.
  • ola: we talked about the newsletter idea in general. when we realize we have a lot of content, it gets a lot of work to write those. I know someone who does a lot of newsletter writing, she might be able to help.
  • mike: what would be the targeted audience?
  • karl: I was thinking about other Mozillians.
  • ola: It could also be a great way for new people to join.
  • karl: Would it help to have a blog? Like ehsan, he is blogging the Quantum newsletters on his blog.
  • mike: I would not volunteer doing it, but I would support anyone doing it. It would be interesting if we had a newsletter that someone goes on the weekly meeting to talk 3/4 items.
  • tom: why don't we simply use the newsletter etherpad to also share the team updates. we can decide what would be newsletter-worthy later. for example, if I have an update for the testing, I could add that to the pad, but it's probably not interesting for people outside mozilla. I could still add it to the pad, and we can pick stuff we actually want to put into the newsletter at a later point.
  • beatriz: i would be interested in reading those.
  • RESOLUTION: put your news item on the etherpad https://public.etherpad-mozilla.org/p/webcompat-news and we will figure out if we have enough materials.

addition to transparency (ola)

'

  • ola: can we share the quaterly team goals with each other?
  • mike: we should put them on the wiki.
  • ACTION: mike to put q3 team goals into the wiki. - 2017-06-30

lightning talks (mike)

'

  • mike: let's do this. friday morning. could be something you did this week, could be a tool you use, could be something you learned. BE PREPARED.

Alexa Ranking / Priority (eric)

'

  • eric: I created a hook, similar to the type-media-deduplication hook. whenever we receive a bug, I'd assign a label with priority. the top 100 get a critical priority, the top 1000 a medium and everything else would be normal.
  • eric: I did initial analysis, and about 20% of our open bugs are medium or higher. so, how should we treat them? do we only look at critical issues?
  • mike: that's something we need to work out. if we get a lot of issues, we should stay up on the critical issues. but sometimes, the "medium" issues also expose weird behaviour.
  • karl: sometimes, bugs can have a inpact not only based on the number of affected users, but on the type of issue. sometimes, a lot of users are affected by a marginal issue, but it could be far more important of "a few" users are affected by a very annoying issue.
  • mike: so, eric, is your question if the priority is actually useful?
  • eric: yeah. we already know the "critical" sites. also, sometimes we can't even fix the critical sites since people do not want to communicate with us.
  • mike: one question we have is if it is problematic to have a bot that assigns priorites and if it is less controversial to have a human assigning the priority.
  • karl: i have the same issue with the type-media-hook. for example, would it be important to automatically shift it to needsdiagnosis?
  • dennis: i don't think that's a good idea. there are a lot of issues that probably won't qualify for needsdiagnosis. manual triage is still important.
  • mike: let's think about it for the triaging side. would a priority be useful to triagers?
  • karl: yes, having the flag would be useful to focus the triaging work. it won't remove the workload, but it would make it easier to focus on the stuff we actually care about.
  • mike: so, my impression is: let's try it. if we figure out it's not that useful, we can remove it, but it's probably best to try that.
  • adam: in the future, it may be useful to flag bugs that do not contain a lot of useful information, so we don't even look at it.
  • ACTION: eric coordinates with Karl on getting alexa webhook implemented and deploy it. we can remove it if we feel like it. 2017-06-30

labels (ola)

'

  • ola: we have a lot of labels assigned and sometimes, it can be quite complicated to understand them. some labels are categorized, like "progress" types (needstriage, needsdiagnosis, needscontacts) and I want to know if we can agree on continue doing that.
  • ola: [shows mockups for the new filtering UI] (everyone agrees)

Unit Tests failing for Beatriz (karl)

Karl and Beatriz solved her issues with unit tests failing. Oauth with wrong token. Which basically is bad because it means that our unittests are depending on the network being up. We need to solve this. https://github.com/webcompat/webcompat.com/issues/1618

  • ACTION: karl to solve the issue about having tests dependent on the network. See issue 1618 - 2017-07-07

Needstriage (Adam, Eric, Karl)

'

  • karl: summarizing the issue and wondering if we need consistency
  • adam: In Taipei we put together https://wiki.mozilla.org/Compatibility/Guide/Triage
  • karl: When there's a bug which requires more info from reporter. When do we use this? I use the @ handle if the reporter is logged into GH. If no reporter close as incomplete.
  • adam: I use the needsinfo to get it out of triage until we have a response, to exclude from triage list
  • adam: I will only go back to needinfo if there's a response by email. Currently we have 131 needinfo issues.
  • karl: there is the risk to become a graveyard. I'm usually closing them as incomplete.
  • RESOLUTION: let's close the one month old needinfo with no answer as incomplete.
  • karl: we should always ping in GH using their @username to ensure they are informed
  • eric: Sometimes it's harder for me to decide which way is better. close or reproduce.
  • karl: for netflix, can ping miket or adam_s, for amazon prime, ping adam_s; some site need VPN, ping adam_s
  • RESOLUTION: When you need more test ping an individual or close it.
  • eric: sergiu and oana provide pre-diagnosis result, should we move to needsdiagnosis directly?
  • karl: if we trust them, they could move to needsdiagnosis or close (for duplicate case, how do they do?)
  • ACTION: karl to ask oana, sergiu on how they find out it is a duplicate of bugzilla bug. 2017-06-30
  • eric: if the bug is not a duplicate, should oana and sergiu move it to needs-diagnosis directly.
  • karl: I guess we should encourage them to move directly to needsdiagnosis. They can still ping us if they have doubts.
  • karl: sometimes when I do needstriage and if I feel it's a CSS issue I try to do the needsdiagnosis to offload the work of tom and dennis.
  • karl: for issues happen on other browser, for IE/Edge, I ping Microsoft(?)'s team to handle.
  • karl: for issues for Chrome or Safari let's try to find out who is handling the interop bug on their bug reporting system.
  • adam: Sometimes people report issues like a real bug with code example on jsbin.
  • karl: usually I try to reproduce and if I'm rested I open a new bug on bugzilla. I wonder why. they don't do it directly there.
  • karl: have a extension to cross-post wc.com issue to BMO, auto fill some field first.
  • karl: if we have a extension which is closing as a duplicate of bugzilla automatically and put see-also.
  • ACTION: karl to ask the rest of the team about having a Web extension for filling an issue automatically on bugzilla. 2017-06-30
  • eric: some sites have performance issues, but what criteria do we chose for closing, moving to bugzilla or analyze.
  • karl: If it's a big perf issue, it means Firefox sucks. and we should open a bug on bugzilla.
  • eric: is status-needsdiagnosis-important useful?
  • karl: Your work on alexa priority will kill it. No worries.
  • ACTION: adam to document on https://wiki.mozilla.org/Compatibility/Guide/Triage the additional information from the minutes of Work week SF all hands. 2017-07-14

GoFaster hacking time (dennis)

'

Web Regression Analysis [and other odds and ends] (thomas)

'

  • Tom: Thomas met with the add-on team to discuss the needs of his Web Regression Analysis tool, and received positive feedback about how the add-on functions. He also continued work on web extension bugs 1333050 (clearing of indexedDBs) and 1295276 (_execute_browser_action popup improvements), as well as landing fixes for a few other small bugs: - 448486: fix two Awesomebar autofill papercuts with ctrl/shift+enter - 1343236: add linkText to web extension contextMenus.OnClickData API - 1287928: add title to web extension browser.history.onVisited API

Webcompat.com refactoring (ola)

'

  • ola: Guillaume and Ola went through grid system as well as existing mockups, which can be found here: https://github.com/webcompat/design/tree/master
  • ola: We discussed naming conventions and to slip up the CSS hierarchy in global definitions (can and will be reused as much as possible as well as inherited to the modules) and scoped definitions, that will be used for unique modules. Global definitions will be added as classed to the DOM nodes to keep everything modular. Modules will be defined per ID and can go one level deep, those classes are scoped within the ID. We decided on not using style overrides to keep the code clear and straight forward as well as re-usable.
  • ola: As the first steps for the living style guide, Guillaume is working on building the grid system with flexbox. Then we'll build the bio and the text modules together to make sure, the namespacing conventions are working and we are in the same page. After finishing that, we'll move on and build the other modules. https://github.com/webcompat/design/tree/master/website_modules
  • ola: The main css file will live in the design repo for now, but we will move it to the webcompat.com repo when we start the actual refactor, so development is still straight forward as well as we have just one source to get and test the code from. Documentation will follow soon.
  • ola: Visual regression testing might be blocked by the webpack refactor as we don't deploy the minified file on the repository to feed the LSG from. With the LSG in place and after starting refactoring the old website with the new design, it would be a good time to tackle that issue.
Retrieved from "https://wiki.mozilla.org/index.php?title=Compatibility/Meetings/2017-06-27&oldid=1174660"