Compatibility/Meetings/2017-12-15

• Web Compatibility Meeting - 2017-12-15
• Minutes: Previous 2017-12-13

Minutes

Scribed by Mike, Eric, Dennis, Adam

Triage discussion (mike)

• mike: Adam, Eric, Karl and Mike do the triage, Serigu and Oana do some too.
• mike: change karl's role to diagnosis, up sergiu and oana for more triage in Q1 18.
• mike: yesterday with open innovation team, there will be more people contribute for triage jobs, but still under-define in Q1 18.
• mike: also remind for winter break https://wiki.mozilla.org/Compatibility/WinterBreak_2017_Triage Oana will do triage for 12/22, Karl for 1/2
• mike: is there anything more we need to cover in terms of triage?
• karl: in terms of process, i don't think so. one thing i've noticed is increased "scam" sites. I wonder if it's related to UI changes.
• mike: do we know who controls "Report Deceptive website"?
• karl: we can find out.
• ACTION: karl to find out who is in charge of Report Deceptive Site menu in firefox chrome. 2018-01-10
• serigu: how many sites we need for locale in the future?
• mike: 50% less of daily effort to reduce backlog, enterprise, hook to site's change.

ContactReady to SiteWait (karl)

• karl: the topic is the contact we make with people. it happened in the past, when adam started (before he left). when he departed, i asked him if he had a list of the people he contacted.
• karl: it was a bit like, here are all my secrets. i was wondering if there was a more sustainable way of sharing contacts.
• karl: one way to do is have an archive (secret) mailing list. you put it in bcc when you contact someone. there's a trace of contacts if someone leaves, or someone needs to take over in the future. it's not to track activity.
• karl: the issue with bcc stuff, it's good for all the mails you send. but you never have all the answers, unless you take the effort to redirect.
• adam: i find that emailing is maybe 1/3 the contacting i do these days. i use twitter or linkedin. but i could send a message?
• karl: for now, i think there are more cons than pros, but i wanted to start a conversation.
• adam: i think it's good to document these things. esp if i go on holidays.
• eric: and we can know if someone channels are working better than others.
• tom: we could make an addon that annotates webcompat.com with a contact.
• mike: that kind of things would require LDAP for me to be comfortable with that.
• dennis: why not just a google doc? it requires less engineering efforts.
• mike: have we done something like that before? i know we have for test accounts, but not contacts.
• oana: would it be useful for us to record contact info as we're working on sites?
• karl: basically, when you do outreach/contact theres' no magic method. each site is different. to create a record of that, it's a lot of effort. almost like writing a blog.
• adam: it's hard also because responses can be vague.
• karl: what about a private github repo, each issue is a website.
• adam: i'm good with it (also for another topic i want to raise).
• karl: the problem problem params are: recording info (changelog, who we contact), and restricting access.
• dennis: take notes per domain, not per bug. seems easier.
• mike: email list, or github account.
• karl: whichever we choose, adam has to be comfortable.
• adam: they're both good solutions. but, let's do the private repo?
• karl: it's also easy to manage via email, with github notifications.
• adam: we'll have to define a process so it can be searchable and automated.
• eric: maybe we can add webcompat-internal subscribe to notifications for that repo as a backup.
• ACTION: mike to create a private github repo, give it a name, create a team that has access to it (karl, adam, eric -- to add more as they need it). 2018-01-10

Diagnosis process & backlog (mike)

• mike: The preface: we're doing better at triage. We're getting good at moving things onto the diagnosis pile. Currently, we have 900+ issues that needs diagnosis, with the most recent being some hours ago, the oldest is from Sep 2016. We're slightly backlogged. The amount of work to do has me concerned.
• serigu: what do we do if these numbers keep climbing?
• mike: well. we'll freak out. we need to get the numbers down. we currently have two people whose job description includes diagnosis. maybe, some of the issues are laying around are not important, but maybe, there are some high-profile issues hidden in there.
• mike: tom, dennis: how much time do you currently spend, on average, on diagnosis.
• tom: a third/half of the time I spent working. So 2 to 4 hours per day.
• dennis: it's ore like a fifth of my week.
• oana: do we have contributors helping out with that?
• mike: not really. we sometimes have some mozilla employees, but nothing we can rely on.
• mike: dennis, tom: what is the other time spent with
• dennis: gofaster, quantum flow profiling, ...
• tom: my addons (tripwire, diagnosis helper, ua changer), WPT, Gecko patch
• mike: karl has expressed interest in contributing more to diagnosis next year. we have to find the right balance.
• tom: one of the reason I work on the addons is to make diagnosis easier.
• mike: so, we're going to add another diagnoser to the mix. one of the questions that I have: are there things we can do make diagnosis
• karl: with focus on CSS
• dennis: if I have a lot of time I start with the oldest, if time is limited I start with CSS because they are easier to get through. We also have the priority tag now which we can use to pick. You can't really stop with diagnosis and pick it up later, since you lose the context when digging deep through code. If there is a site with high priority, I'll look at it first
• mike: I will ping people about high priority bugs often
• mike: how about tom?
• tom: needsinfo, priority, oldest, how long to take on issue, impact (severity). normally neutral for every issue.
• mike: checking the issue is still available could off load to other people.
• mike: one idea is to categorize issues when triaging into general categories (like "video issue", "css issue") and define "roles". it's probably a good idea to try this.
• ACTION: mike to create a legend for our type-labels. come up with a proposal for new ones, add those to the legend. make sure it's documented and people doing triage know about that. Oana/Sergiu will review. 2018-01-10
• mike: for q1, I'd like us to really push on needsdiagnosis. We need to prioritize some of the stuff we're doing and we need to come up with a goal.
• adam: we all feel uncomfortable with a pile that large. but maybe that's our reality. maybe we should be comfortable with "we'll never be able to look at everything".
• mike: I agree, there always be more work than hours to work. my concern is that, right now, there are new regressions and high-profile bugs laying around.
• mike: when triaging, we need to be better at checking regressions. i want to highlight regression checking and make it part of the progress.
• adam: it would be cool to be able to get a bigger picture of the type of the issue. I often get asked about "the biggest webcompat issues", and we don't really have an easy answer to that.
• eric: my work is related to that, will present later.
• dennis: Maybe we need a 2 stage diagnosis process. 1 for regression or Gecko bug or website bug. 2nd one for what the issue is. That would probably solve the issue of finding important issues, but allow us to ignore low priority issues.
• karl: I have the feeling that it does happen already. Each time there's a gecko bug, we dupe it. We don't do regression testing all the time. Once we know the category of the bug, we duplicate it.
• dennis: Sometimes that happens, but not always.
• karl: Most of the time it does.
• adam: We have prioritization of issues... should we lower or higher priority at triage time?
• oana: We do this sometimes. If we felt it's a bigger problem, we've increased the priority.
• dennis: I'm not sure if the domain thing by itself makes sense. We should have a human to make sure it's right.
• ACTION: mike to Update triage guidelines to include priority-label modifications if necessary. 2018-01-20

Visual - WebCompat (mike)

• mike: The purpose of this discussion: I want to talk about the Google Tier 1 issues, and I want to get feedback from other parts of the company. The other purpose is a discussion on how the WebCompat team can be more useful to mozilla. We're trying to figure out how to be more efficient, finding the right bugs, the right regressions, working with standards people, ...
• mike: In Firefox for Android today, we get a simplified template. It's not as terrible as what Opera Mini gets, but it's not the full experience.
• mike: However, if you pretend to be a Nexus 5, you'll get a richer experience, which cards, previews, and instant results. This is what we call the "Tier 1 search experience".
• mike: For a number of reasons, Google serves us a different experience, and we don't like that. Google is obviously a popular website, and our goal is for people to receive the same experience.
• mike: We started an experiment with the Blink team, including Rick Bayers from the Plattform Predictability Team, about trying to understand where the problems are. Our team spoofed as Chrome for Android using Fennec and was testing stuff. The theory was: if everything works, we could get the Tier 1 experience in Fennec. We found some issues, collected in this Google Doc
• mike: https://docs.google.com/spreadsheets/d/1xZ0C26HKGPnUuDYWt36utrnfGGGbCOsg6youHJC0Rb0/edit#gid=0
• mike: Some of them are fixed, some are being worked on, some are undefined david burns: is there a tl;dr of those issues?
• tom: not really. some issues are stuff we need to add to Gecko, like the WebSpeech APIs for example. Some issues are caused by webkit prefixed CSS attributes, sometimes it's issues caused by them designing the code for blink, including spec edge cases like font rendering. There are also some Blink bugs they designed around and needs to be fixed on two sides.
• mike: we're also interested in doing a SHIELD study, where we push an addon that spoofs as Chrome for a set of pre-release users and get some data on that. david burns: Chrome has this big push on WPT, do we have a way write failing tests, having them going into their trees and make them start fixing? Wondering if there are some spec issues that do not have enough coverage.
• tom: Some of them might. david baron: I think contributing to the tests is a good idea in general, but I don't think it could push them. david burns: It could get a conversation started
• james_graham: do we have the opposite answer: are there cases where we fixed a compat issue and made a WPT pass? Are there a lot of these cases? If so, we may need to focus on WPT fixing more. If not, we may find areas that need more coverage.
• james: how much of these issues are actually Chrome-specific features?
• tom: most of the issues are visual issues, so that's good. Some of the issues are Chrome-only features that have become part of the standard now, like WebSpeech.
• mike: Will have a report next week and will send it out to the compat mailing list https://lists.mozilla.org/listinfo/compatibility
• karl: some of the bugs have been fixed already
• mike: This is one of the most commonly filed reports we get
• mike: What are the biggest webcompat issues currently?
• karl: webkit-appearance (alias) and work is being done currently. Mats is trying to implement the values of webkit-appearance.
• karl: blink has support for virtual viewports, which we don't. when a page has a size that is bigger as the current viewport, we don't resize the viewport (aka zooms out), while we do not. when people add overflow:hidden, in Chrome, they'll see everything, but will not be ale to scroll in Firefox. This is not fixed at all, we're trying to understand what browsers are doing, documenting that and working towards a stable implementation everywhere.
• karl: another issue-category are font-related. Chrome for Android defaults to a different font than Firefox for Android. The fonts have slightly different baselines, and it breaks layouts. also, blink is, against the spec, accepting postscript font names (like "Roboto-Medium"). The blink team is thinking about changing that, but I don't think they will be able to, as they might break sites. They'll land some use counters, and see how widespread this issue is. david baron: is there a crbug tracking that?
• mike: it's linked in the Google doc david baron: I want to have one issue to follow the discussion, and use that bug to bring up in the CSSWG. If we end up not changing the behaviour in Chrome, it's easier to get the spec changed if we have something that the WG can read.
• ACTION: karl to find the bug in Chromium for font name matching (POSTSCRIPT name) and send to david baron 2017-12-16. david baron: That's also more of a general thing, not specific to this issue. If it's going to need a spec change, it's better to track that in one place as that is easier than going back and collecting the information. Sometimes, it's hard to understand the actual issue if it's not collected at one place, something, that's easy to read in a reasonable amount of time and that reflects the issue, and the reason why we can't change that inside the browser.
• karl: we also have performance issues with animations, but that's being worked on.
• mike: so, that's what I wanted to talk about in regards to Google. From the people outside the WebCompat team, are there areas where we can be helpful? David Baron, are there things we can help in regards to interop? david baron: Can't think about something right now.
• james: Sometiems, there are parts of the spec where there is room for implementers to choose from, we should fix that. david baron: those cases are very rare and very special cases. but those are things were spec issues should be created if it creates interop issues. david burns: I do like the idea of checking if we have WPT coverage when we fix an interop issue, and if we do but the test is disabled, maybe reenable that.
• james: not only that, but also checking if we have a number of tests go from red to green, and if they do, find more WPT to work on specificly, and if not, change coverage.
• karl: right now, we have more than 120 bugs in bugzilla that have the webcompat flag.
• mike: yeah, those are useful. that's probably on our part to prioritize them and present them in the future.

WebCompat issues / locales (karl)

(Thinking loud out). Just taking notes for remembering. Marquee on Indian sites is a good example of how a feature is almost not used in most countries but has impact in some specific geographical area. Globally it might not be worth fixing but it might be important once you considered a specific country and area. An example in the past was -webkit- stuff for mobile in China/Japan.

Bug Dependency Graph (eric)

• eric: In the beginning of this year, we wanted to know which issues in Bugzilla are most important by looking setting see also. I tried to do some work on understanding the dependencies between webcompat and bugzilla. https://mdtsai.github.io/wc-bz.html (slow, don't open it)
• eric: I parse GitHub issues to look at comments about duplicates or dependencies. I made this second version which is improved.
• https://webcompat.herokuapp.com/wc-bz.html

     dest      | dest_count 
---------------+------------
 Issue 5637    |         93
 Bug 752790    |         92  
 Bug 1352238   |         73  
 Bug 941351    |         70 
 Issue 5163    |         70 
 Issue 4591    |         62

• oana: Is there a way we can be notified when a bugzilla bug is fixed, so we can verify the webcompat issues?
• mike: Not right now. But maybe we write some software to send notifications when something with the [webcompat] whiteboard item is closed.
• sergiu: We could search for [webcompat] whiteboard items and go back to the FIXED issues and verify them. And subscribe to the not yet fixed ones. ACTION ITEM: sergiu and oana to verify webcompat.com issues from fixed Gecko/Bugzilla bugs.
• mike: Is there a way to see the top items or bugs?
• eric: It's on my TODO list. Please file issues for feature requests to here https://github.com/MDTsai/wc_issue_dashboard

Working in Public (karl)

• karl: We've talked about this in SF. We are working for an open source project. Most of our discussion and reports are of public nature. The things that are not public are partner relations, interactions with private companies, business deals, HR things, private info, etc.
• karl: All the rest can be public. Even things like Google telling us an internal bug number can be commented publicly. Anything you start as a discussion, code project, docs, draft of thoughts: start them public. Share them early.
• karl: If you're afraid of sharing due to too much out of scope discussion, just specify. When you share: this is an early draft, it's not mature. Please be mindful that it's not complete. The more you wait, the harder it will be. It becomes a lot harder when the project is completed for others to participate, either from within the team or outside of the team.
• dennis: I completely agree.
• mike: me too.
• tom: I tend to not do it, because it slips my mind. Maybe perfectionism.
• karl: If it can help people in the team, think about that the way we do things in Mozilla is to work in public. Or, it's the way we do things on the webcompat team. It's our way we work together.
• ola: In general I agree working in the open is a good thing. From my experience it can be tricky. Sometimes when you work in the open, when you're just sharing ideas, people might block it or maybe not give constructive feedback or criticisms.
• ola: I think this is something we should think about when we discuss this topic.
• mike: yeah, this is a two-way thing. we work in the open, but we also have to make sure we don't block each other with feedback. sometimes, you might feel like someone is doing the wrong thing, or that you might it do otherwise, and this may feel like a personal attack.
• karl: If you're afraid of the feedback, as soon as you propose the idea (which doesn't always work), you can frame a project to request only positive feedback. Or ask that people hold onto comments for a certain time. There are ways that we propose a topic and people won't agree. But this is also part of the reason we share.
• ola: What about push-back feedback, basically telling you to turn around. It happens that people are cutting off the things you're proposing, maybe because there's some context missing. What about that?
• ola: Sometimes discussions go nowhere. We have discussions around feature requests and they stop at some point. The discussions go nowhere.
• karl: For me, it doesn't mean it's useless or has to be solved. For me, an issue can stay open or be put on the backlog. Maybe not mature, or maybe not enough energy to solve it. But it's part of the discussion, and documented.
• karl: For example, I've been working on this feature for the feed. I realized that without a database, it's not worth doing even as a prototype. It doesn't mean we have to close the issue, it just means there's not enough features around it to finish right now.
• ola: What I hear is 2 different approaches: on the one hand, being open and transparent and waiting for feedback before going on. Or trying things out and making decisions on your own. Is that right?
• karl: The discussion has changed a little.
• ola: It's just an example to be more concrete.
• karl: I'm trying to say after you've worked on something for a few months in private, once you open it up, you might get a lot more pushback if there are disagreements. Rather than at the beginning.
• ola: OK, another example. We had this discussion about transparency in another project. We had a basic direction that was decided in private, going from there, everything was made public. The core direction was decided by the core team. I'm not sure if this is 100% of what you're talking about. In Germany we say "Too many cooks mess up the meal". Sometimes you might have too many opinions to prevent you from making progress for a number of reasons.
• mike: I think there are parallels with what you are describing to Firefox. The Gecko rendering engine is developed 100% in public, but we decide in private what to work on. Once those decisions are made, you have public issues, public intents to ship, and public discussions about how to best implement things. I think it's possible to have a small group decide what things needs to be developed, and then have a public discussion about the hows.
• mike: just for me personally: i think it's good to do stuff in public and the effort usually is worth it. ola, you was hinting at a policy?
• ola: more like a process of how to make things public.
• mike: we probably can be better at setting up rules. like: if you create a new project in your paid time, create a repo and send an email to the the list.
• ola: so, the action item should be to define those processes?
• ACTION: ola to define processes on how to work in public, karl to review.

Direction of webcompat.com (Ola)

We keep having great ideas for features and improvements for the site, but often we don't decide on anything as we are not sure about the direction. So, let's talk about it! What is the purpose of webcompat.com? Which purpose should it maybe serve in addition? Please check out the https://github.com/webcompat/webcompat.com/tree/refactor branch and take a look at the new design / content to see which direction we are moving to right now.

Direction of webcompat.com itself (Ola)

1. Who is the target group for the site? 2. Is anything missing, you'd really love to see there? (Prio: important)

• ola: The main purpose used to be reporting bugs and working with bugs. But also, we want to get people involved and educated about web compatibility. With the refactor, we want to make it more accessible for contributions. What do you feel the direction the site should be like in 1 year. Or 2. What do you think?
• adam: In general, my opinion is that webcompat.com is a tool for us to provide access for any user to report a bug anonymously, quickly. I never get too fixated on the tools of webcompat.com, unless we make tools that exceed on some larger level than what GitHub can do. I think for the next year, it depends on what we think are our greatest needs. We should focus on that part of the site. If that's not our focus, it's maybe making it easier for contributors or our users.
• tom: I think it's going to be all about crowd-sourcing. But to get what we need to get done we need as much help as we can get. Whatever is involved.
• dennis: I think our main focus is still on getting non-technical users to report bugs on the sites they use daily. We're making good progress on this I think. We should improve this, and make it easier for the team to do its work. And for the community to get involved. I don't have any revolutionary ideas.
• sergiu: I feel like we should get ready for more and more users reporting issues. Since we joined this project, the number of daily issues increased a lot. This year we had more visibility for users. I think we should also come up with a way to contact reporters, anonymous ones.
• karl: 2 target customers: 1st, the reporters. People reporting bugs. 2nd, the people using the tool to process the issues to the end of the issue. Everything from triage to contact. The goal of webcompat.com is a tool for us to detect (not only Mozilla) bugs in browsers, or in websites. *cough* *cough* (actual coughing). We have to solve this issue with non-GitHub users. Maybe they want to leave contact info. It's happened often that people will comment anonymous, and then comment later on that they were the person reporting the bug. They self-identified.
• oana: We should educate the users, reporters, anyone by creating demos. Nobody likes to read blogs or long docs. But some demos related to reporting issues or triage that would be helpful. Me and Sergiu can help with this. Education materials for people using the tool, but also collaborators. Triage, diagnosis. Better guidelines on how to do it, and how to do it well.
• ola: I have a question, I couldn't hear. Just restrained to the workflow, or also including educating people on web compatibility itself. How to write cleaner code, etc.
• dennis: I think our team should do some work on teaching how to do things the right way. But I think maybe MDN dev docs is a better place, cross-linking. That seems to be a good place to teach about compat issues.
• ola: You mean a short resources page with links?
• dennis: Yeah, I think so. But MDN would be the place to write articles.
• karl: I don't think we should do it at all. Moz already has a DevRel team. We might be resources to write articles or blog posts on hacks, or MDN. But I don't think we have time to do it.
• ola: And a collection of links?
• karl: Nice to have, but a pain to manage. These kinds of projects are usually out of date. So you have to manage them on the long-term, it requires a commitment.
• ola: What about tools everyone is using to diagnose issues?
• karl: Yes, I think so.
• mike: I agree with Dennis, I think.
• oana: Are there people who have asked, how do I learn more about this topic?
• dennis: There have been people who have approached me.
• ola: I had an interesting discussion, people want to get involved but don't know where or how with their skills. The solution could be to define roles and list the skills. And other stuff. (back to original question)
• eric: For webcompat, a place for collecting problems. If we can try to make users use their Facebook or Google users to log in to report issues to help them report and get back to them, but they are still anonymous on there.
• adam: To add to that, we asked Vlad about using Firefox accounts as well. It's a possibility.
• tom: There's also the possibility would be p2p like service workers.
• dennis: I created a POC using push notifications.
• eric: If we can do things to make it possible for more people to interact, the better.
• sergiu: Won't the user feel stalked if we send notifications?
• tom: Yeah, but it should be opt-in.
• mike: the real value is collecting bugs, no matter where they do on github or webcompat, just make the web better.
• mike: the most important thing is the bug form, etc. Add more information to make sure the issue clear, make it become more powerful.
• mike: value is to get feedback from user easily, much easier than bugzilla.
• mike: help people to contribute, triage/diagnosis/outreach. Always have way to improve that.
• ola: Thank you. It's interesting to see that all of you have a common sense of the direction. What I heard was: target groups, people who report bugs. Especially non-technical people. The 2nd is people who work with bugs (the team, community, people who want to get involved, triage, diangosis, outreach, or people who want to develop tools). 3rd - crowdsourcing?
• ola: Contact anonymous reporter seems important. And form improvements.
• dennis: I would like to know your opinion. You skipped the line.
• ola: I agree with all of you. For me, educating is super important. How to diagnose, triage, contributions. Educating people on how to produce clean code. People have told me, I would love to help, but I don't know how. I don't know how to produce clean code.
• adam: The more organized we are about what we want to do, the easier it will be for contributors to help out. Someone might pitch in with a contribution.

Direction of form (Ola)

• (Prio: important) 1. Who is the target group? 2. Do we want to split inbetween power user features and casual reporter? If so, how? 3. How do we handle the add-on?
• ola: How to we improve the form? One idea is to split the form about a "simple" and "advanced" mode for the form?
• ola: Non-technical users might feel overwhelmed by some features we want and need in the form.
• mike: can you give an example for such a feature?
• ola: For example the "similar bug" feature, where you paste an URL and get a list of bugs with the same URL. It will be expanded by a search for keywords. As a non-technical user, this can be confusing and lead to situations where reporters might not report a bug because they feel like this may be a dupe, ...
• mike: I see. another good argument for splitting this up for "advanced" users is that required login for some features creates a history event.
• adam: Some of the talks this week seems like Mozilla has involved into being able to test ideas quickly, like storyboards for non-technical users, where we could simply draw something. these ideas sound awesome. we have tools to get in touch with our users now. maybe we can ask users to provide feedback after they report a web bug, check if they want to answer some question.
• mike: so you are suggesting to do user research with mockups or something similar?
• adam: yeah. we could get useful feedback without having to spend time actually building something (besides mockups). (sudden change in topic)
• ola: for the simple form, we also thought about adding multiple steps, or grouping form fields together to make it more simple.
• karl: agree with adding an "advance" mode. i think, to do that work, we need to looking into the data of the current form. like.. "how many times do users chose the wrong category/bug type", or if people actually tested in other browsers if they claim they did.
• karl: as for a multi-step wizard, it might be an option. we need to test and iterate until we find something that works for everyone. one thing I'd love to see: instead of using the bug type as a title, we use the description as a title. sergiu agrees.
• sergiu: how about we start a 1-month a/b testing.
• mike: yeah, that's probably the way to go. we have to build the functionality, however. but I think that's what we should do. also compare simple mode vs. advanced mode, and other stuff.
• ola: I really love the idea of a/b testing, but what karl said is also really important, looking at the data. i feel like this should be an action item: we have enough data to make a guess.
• mike: we are probably currently blocked in shipping the refactor.
• adam: that's why I suggested drawing stuff out first and building mockups.
• mike: i'd be willing to help out in looking into it, but I don't think it will happen in q1, maybe q2 or q3.
• ola: Q3 sounds great.
• ACTION: mike to look into old bug reports and make a guess.
• sergiu: when will the new and awesome webcompat.com be released?
• ola: q1 is the goal! there is still a lot of work to do, the more help I get the better!
• mike: as we are on topic: if I check out the refactor branch, does it work?
• ola: yeah. Most of the functionality is there. some stuff is still sitting in PRs, but most sites work just fine.
• oana/mike: are you ready for feedback on individual modules/parts of the page yet or is it too early?
• ola: it depends. we basically took the old functionality and changed the design and semantics, the functionality did not really change. you can always suggest ideas and check it out. however, I don't think the feedback will be implemented right now.
• karl: do you prefer feedback when it is on staging?
• ola: yes. sergiu is happy to test the new site. very happy.
• mike: so, to wrap up: we all agree improvements are wanted and needed, we want to analyze some reports to understand if the stuff we get currently is good and where we can approve. we want a wizard. we want it a/b tests, and we want paper-tests before.
• sergiu: i'm not sure if it's just me, but I feel like the old placeholder text was more useful?
• mike: yeah, it was probably more easier for people to understand.
• ACTION: sergiu to comment on the old bug or file a new one. https://github.com/webcompat/webcompat.com/issues/1819

Keep good code quality in webcompat.com (Ola)

• (postponed):

Similar bugs (ola)

Please check new feature Eric built and give feedback. Thanks! (Prio: we should talk about it)

• https: //github.com/webcompat/webcompat.com/tree/similarbugs
• ola: please give feedback on erics feature!

Labeling + Milestones on webcompat-dev (Ola)

Labeling makes issues easier to scan, search, and group. (Prio: we should talk about it) It also makes it easier to look for related issues. It saves more time than cross-referencing issues, but keeps the context (No argument against cross-referencing. Just pro scope labels). They show scope of a feature (e.g. https://github.com/webcompat/webcompat.com/issues?utf8=%E2%9C%93&q=is%3Aissue+label%3A%22scope%3A+dashboard%22). The issues get easier to add to a milestone + prioritize.)

    Suggestion for labels:

    - always add a type label to the issue

    - when possible, add a scope label to the issue

    - Did the lang-labels improve our work / contributions? Should we keep them? Always add them or just in specific use cases?

    - move general scope-labels to type? (security, testing) 

    - color code labels after prefix (type, scope etc...)


    Suggestion for prioritization of issues:

    - 

• ola: i sometimes have a hard time to find related issues, or get context. i can imagine how hard it is for people who are new to the project. [suggestions from above]
• mike: i think the language labels are useful. I am maybe guilty of not assigning it regularly. but I think everything you described is good and useful.
• mike: one thing that could be helpful could be a regular triage meeting, to look at the new issues since the last meeting, making sure the right labels and scopes are set.
• ola: i'd love to have a kinda-regular triage meeting. we could do it during the webcompat.com meeting?
• dennis: is that important enough? the meeting is already filled, not sure if we have time for that.
• mike: we can do it asynchronously.
• ola: the more people are involved, the more important this is. the rust and servo people are doing a great job.
• karl: are there issues with that right now? did you identify things we need to solve?
• ola: i'd clean up our labels. I would add a prefix to labels, create some, renaming some, ...
• mike: sounds great. whatever you think is right, do it. we all trust you! dennis nods.
• karl: just send an email to the mailing list afterwards, with a summary of the changes.
• ACTION: ola to clean up the labels.
• ola: I had some discussion last week about the prioritization of labels. we should assign priorities to issues. there are two ways to do it: we assign strict priorities from p1 to p5. another way, and maybe the more human way, would be to add "good first bug", "good next bug".
• karl: "good first bug" and "good next bug" are not priority-based.
• dennis: well, "good next bug" is kinda prioritizing an issue.
• ola: the rust and servo people saw increased contribution rates when adding "good first bug" and "good next bug" labels.
• ola: i also think that, in combination with other labels, people are able to judge what's important. like a "good next bug"+"type: bug" is more important than "good next bug"+"type: feature" feels more important to people.
• dennis: let's make sure not to make "fix typo" and other issues "good first bugs", because those attract a kind of contributor we actually do not want.
• ola: yeah. "good first bugs" should have some complexity, but not being to hard, and they also need good documentation.
• ola: I agree that "backlog" and "nice to have" are good labels, but how do we name the "high priority" label?
• mike: let me just recap the way firefox does it. we have the p1 to p5. p1 = somebody is working on that (someone needs to be assigned). p2 = somebody is workong in that hext. p3 = backlog. p4/p5 = patch is welcome.
• dennis: "important" might be a good label name.
• ola: sounds good. we can always rename.

webcompat-dev Feature requests (ola)

(Prio: we should talk about it) Since webcompat.com used to be a side project, we kept adding features on the fly. It was great, but we might end up to become bugzilla web compat version at some point. :D I'd like to suggest a flow for new features, without creating overhead for everyone who is working on them, but to add more structure and to keep the direction in mind / test features and see, if they are working out for us / how we can improve them.

    Rough idea:

        - Discuss feature idea in issues and/or team meeting / mailing list
        - Create an issue on webcompat.com repo with scope: feature request label
        - If scope / feature list is decided on, create a "stand alone" prototype in a separated branch the team can review / you can demo
        - 2 weeks to test / give feedback before roll out or moving to production site (clean up the prototype, add tests if not there yet etc)
        - Deploy && enjoy

• mike: i think this sounds great. an email with a proposal to the list would be cool, so we can digest that and think about it. dennis and tom agree. karl also agrees, if used for larger features and not small bugs/tasks.
• karl: we only need someone enforcing it, and someone to make sure that the process is taken into consideration when opening a new issue.
• ACTION: ola to write a summary email.

webcompat-dev Tests (ola)

- Functional vs unit tests (+ visual regression testing for Style Guide)
- Happy with intern as testing FW? Preferences for unit tests in JS? 
- Test coverage is something we discussed a few times. Anything that is speaking against it?
- How to run the test server setup is sometimes not 100% clear. Is the `npm run start:test` script enough? Shall we add the test runner to the pre-commit?
(Prio: can be to postponed)

Code reviews (ola)

- Happy with it? Anything you'd like to improve?
- Karl also started this thread: https://github.com/webcompat/webcompat.com/issues/1975#issuecomment-350342290 (Prio: possible to postpone)

Code standards + processes (ola)

- Happy with it? Anything you'd like to improve?
- Automated pre-commit linter for python
- Auto-generated change log 
- Code documentation is something we have on our OKR list, but didn't seem to have time for it. https://documentcss.com/ && https://documentjs.com Look great.
(Prio: can be to postponed)