Compatibility/Meetings/2017-10-19

Meeting: webcompat.com Date: 19 October 2017 - 19:30 UTC Scribe: Mike (until he leaves...)

OKR's for Q4 (ola)

Our suggested OKR's for webcompat.com Q4 are:

https://docs.google.com/document/d/1TXQI-olA6MDMTm4rsd0OpC7_wUXdcU0vNtX3Id38R7Y/edit

- Fix bugs (clarity needed), Owners: Ola, Mike, Karl

- Implement new content + content modules modules (site refactor), Owner: Ola

- Generate a code coverage report, Owner: Ola

- Generate CSS documentation, Owner: Ola

I would like to set up a roadmap for the next quarter and see how this goes. For this it would be interesting to hear from y'all what you feel like our main pain points are with webcompat.com and talk about their prio.

ola: These are great goals, but it's a lot of work. There's a lot of steps that might depend on eachother. Thoughts on a roadmap + milestones (which would include specific bugs)?

tom: I was wondering what CSS documentation is, I might be able to help.

ola: I was thinking of using documentcss. You can create a living style guide out of the documentation, which removes pain points around updating a LSG. And milestones/roadmap? tom: It's good for people involved.

guillaume: I don't know. I like to have a clear roadmap. But it's hard for me to see what's important if I'm not working day to day. This would be a good thing and help us be more organized. I'm not sure about milestones.

mike: I'm into it. I'm not organized enough to do this, but I am supportive. Roadmaps are good, they can be collaborative. People have ideas, suggestions. Maybe you have one person in charge to create meaningful groups of work to achieve that. DevTools is doing that: https://github.com/devtools-html/debugger.html/milestones. And it would be good for people who might not be 100% involved (due to other priorities, jobs, etc.), so they could come in and see what they can work on that's important.

ola: I would also like to add prioritization to bugs/issues.

Form UX improvements (ola)

As the amount of reports is increasing, Dennis and others suggested to improve the UX of your bug report form. Let's talk about it!

mike: I just had a meeting with Konstantina. Important feature would be to identify duplicates. Feedback was that some people felt a little bummed out after they reported an issue and it was closed as a duplicate.

ola: Is anyone else interested in joining a meeting for designing this feature?

tom: I'm interested but don't know if I have the time.

guillaume: I'm interested.

ola: I pinged Eric already, and Adam is interested.

prioritization labels (ola)

I feel like we are patching issues that are the most pressuring with webcompat.com. To get more things done like e.g. feature requests more structure could be helpful as well as a prio label system, so the team can jump on issues faster, if they have time to help out. Would love to hear your thoughts on this.

E.g. I'd like to add more structure to our webcompat issues. Group re-occurring issues with labels (like we did it e.g. with the form-refactor) and give them a prio label. We could also move those to milestones?

ola: First question, what do you think about it? Second question, on which level would it be important to do groupings?

adam: It's probably difficult for others to know what it's OK to jump in on. If something is part of something larger that it's not great to work on right now.

mike: What do we mean by prioritization? P1? P2? P3?

ola: My idea was similar to web-bugs, priority-critical, priority-important, etc. We would have labels that would group a specific theme, for example, scope: tests.

Mike: I'd like the idea of having milestones and issues with prop labels. Labeling issues is always useful.

adam: It should help to break up the work as well. And useful for contributors as well.

mike: The layout team uses the following prioritization, which I think is cool: https://astleychen.github.io/triage-report/#report p1 - active p2 - next p3 - backlog p5 - patches welcome

guillaume: I think you could also prioritize these things via milestone as well. p1 milestone, etc.

ola: I think that's a good way to get an overview, but it might create some more work.

guillaume: I didn't know about milestones; I think it's a good thing.

ola: there are different approaches to how to organize it.

guillaume: It can be hard to tell if a label is for contributors more than core developers.

ola: Yes, we need to think about the approachability of this (P1 vs P5? Good first bugs? "Important" labels?)

adam: We could have an FAQ/guide for first-time contributors, so that by the time they click to see the issues, the labels make sense.

ola: agreed, that would be worth adding.

Tom: I'd suggest having a style guide for labels to make sure we are all on the same page.

ola: agree, we started that already on the wiki. I think we should start by finding out what works for us, and then we document it more formally.

ola: back to pain-points, what do you think adam?

adam: I don't have an answer yet, but the UX improvements are something I would be super-happy to see move along. I love anonymous reporting, as it's a low barrier of entry, but it does lead to times where that leads to us being swamped. That's why I think it's so important to have a simple place for first-time contributors to get quickly involved.

ola: guillaume? what would you like to see fixed next?

guillaume: I have the feeling webcompat.com is important for new reporters, but more experience devs (karl, adam) seem to prefer using Github for the conveniences it provides. I think we have more reports made on webcompat.com, but I'm not sure which end to improve I'm not sure if we should spend time improving the github end or webcompat.com end more, given that some things are much easier on github (as I fouind last week).

ola: so we should try to invest time to find where each end is better for triage.

adam: yes, I use github more as well. Canned responses, the color scheme, all sorts of little things make the difference. But it would only take one useful feature for me to switch over, so it's worth considering this. And for someone like me, I'll get my job done regardless, so the payoff for improving either end for me may not be as important as improvements for general reporters. One thing is that webcompat.com makes it easier to do experiments.

ola: true, it's easier to make small improvements on webcompat.com (dennis also suggested the same thing). it's not necessarily that content or functionality will improve a lot, but papercuts can be dealt with.

Tom: Github is easier to deal with because I use it for other things. If we just use webcompat.com as a test bed to make things better than Github for specific features, it makes sense.

Ola: It could be worthwhile making webcompat.com match github to make sure contributors aren't turned off by it

ola: it is easier to make small improvements on webcompat.com (dennis also suggested the same thing). it's not necessarily that content or functionality will improve a lot, but papercuts can be dealt with more easily.

tom: might be best for us to let the team spend some time brainstorming what we'd like to change first, and then we'll more tangible things to make goals/milestones for.

ola: agreed, that's what the aim is, to pool brainstormed ideas each month during these meetings.

progress with style guide + roadmap (ola)

http://webcompat.github.io/design/index.html

https://github.com/webcompat/design/issues?q=is%3Aopen+is%3Aissue

- What are the next steps? - Who would like to help? (How would you like to help? How much time do you'd like to commit to?)