WebCompat Form UX/Design Work Week / April 24-28, 2017 / Berlin, Germany

This page is dedicated to the agenda (then summary) of the work week dedicated to Webcompat UX/(re)design/implementation of our bug reporting form. We probably needs to address the long term goals of the project too.

Try as much as possible to prepare the discussions before the work week meeting when you own an agenda item. We want to be as productive as possible.

Work Week - Berlin 24 April 2017

Project Direction

(ownership, technical leadership, boundaries, constraints/project dev priorities)

• mike: (history context). We started 3 years ago. Mike did the first prototype.
• adam: Bugzilla was not very friendly for many people. We had created simple bugs which was a view on top of bugzilla. https://webcompat.com/simplebug
• mike: I made some technical choices. Flask + Backbone. The majority of the site I have written. My job changed since the first days and I do not have much bandwidth for being the lead dev of webcompat.com. Our team grew. In my mind, the person who is leading the project webcompat.com is Ola.
• mike: But that leaves out Karl. Karl, how do you see yourself write to webcompat.com development?
• karl: Good question. I like to think I'm the unspoken moderator to push back. The white beard. To be sure that what we decide is well thought out. To make sure we're not hurrying. Another history, when we worked at Opera we were frustrated by not being able to work in the open. Their bug tracker was closed. This was solved when we came to Mozilla, but it was not cross-browser. We originally wanted webcompat.com to be this, but it didn't work out that way. There was some participation from Microsoft at the beginning, but they've gone their own way. Sometimes I struggle with that, should we keep the door open, or make it Mozilla only. The conscience of webcompat.com. In terms of development, I love to work on it. But I struggle to know if I should be spending time on. There's things I dislike technically, but I recognize that it's a community. I prefer when people are collectively working on something to having a typical "leader".
• mike: how do you see yourself and the project?
• Ola: I love the project, a lead in my opinion can be very different. Helping enable others to join and participate in the project. This is what I have done in the past and really enjoy. I see that the need for webcompat.com has changed a little bit over time and have some suggestions to make it go further.
• mike: Adam?
• adam: I think we need to figure out strategy, that's never easy. There's going to be some tradeoffs, we'll need to prioritize things, etc. But this is a good use of our time. There's value in what we're doing.
• karl: do we still need webcompat.com?
• mike: yes I had similar questions. Bugzilla has amazing features but also difficult sometimes. Webcompat.com is independant has values. We have control on the features. It's built on top of Github. For the outreach aspects, there is a lot of values.
• karl: The value of outreach is worth the cost of being dependent on GitHub.
• mike: yes, we need webcompat.com.
• ola: it's a good tool for those who maybe aren't as technical, it's a good entry point for others to understand the project. The site and the bug tracker are one.
• karl: I still do not like the asymmetry of github / webcompat.com, it's a hack, the emails are coming from GH for notifications.
• mike: the sidebar UI update is so much nicer, the bug page is looking better and easier to use. We still have this other collection of bugs.
• adam: it's just a mean of doing something. Getting reports for bugs. As a tool it could be useful with the community.
• karl: I agree it's a tool for both the community, but also for us for working.
• adam: Our goal is to improve the Web compatibility, but if we are in the business of mimicking what Github does we are losing our times. Creating a community is important, but the most important is to get the Web compatible.
• ola: When we educate people, it would be better for the Web.
• mike: what are the audiences? bug reporter, community/contributor (triage/diagnosis), end user (recipient through outreach)
• karl: At Mozilla we have a team for dev rel/mdn, although it's nice for us to do, it's not entirely our role
• ola: Having resources on the website, people don't always understand what webcompat is. Having relevant information to keep developers updated on compat topics.
• karl: I am all for educating people. Dev's are not a great audience for webcompat, as they are not always the one in charge, it becomes many times a business decision.

Deployment

• mike: The way I deploy the site is through fabric. The script is called the fabfile. http://www.fabfile.org/ Let's do a fake deploy. 0. merge the pull requests into master. 1. add-to-changelog on github gives me the list of things to change and to deploy. (manual) there's no schedule for now. We could have more structure if we care. 2. Checking each of the changelog. 3. git checkout master. At the top of the changelog file, there's the number version. https://github.com/webcompat/webcompat.com/blob/master/CHANGELOG.md and its scheme. Define the version number and edit the changelog. We could automate it here, if we feel it's important. example: 4.0.1 5. git commit the change. 6. git tag -a v4.0.1 7. git push 8. git push --tags 9. Check https://travis-ci.org/webcompat/webcompat.com, if build is not broken (looking at the fabfile) 10. Fabfile runs Grunt.deploy tasks + linting tasks 11. .csvignore needs to be locally saved 12. script restarts service after uploading 13. fab deploy:dev # to deploy on staging to test things. We don't kill current connections. uswgi is safe.
• FYI: It doesn't update PIP modules automatically. You have to install them manually on the server first.

Webcompat.com Refactoring

https://docs.google.com/a/mozilla.com/document/d/1c8Y0opEKkHjVdTUV3MGraH1B4ZUx-BPhOLgZ-MxNhQk/edit?usp=sharing

• ola: the main idea is a good tool serving its purpose well. The community aspect of it could be useful. People are currently not really sure about the issues they can claim. It's difficult to assess the skills that one needs to participate on webcompat.com.
• mike: I received a lot of emails from India lately with people wanting to participate but knowing what to do.
• Ola: we are missing entry points. We do not have water cooler chat. Making people visible through their contributions. We need more content. (enumerating content). We need clean up design. Refactor some features.

Customers

We define 3 type of customers:

• People reporting bugs.
• People using webcompat.com for triaging and diagnose.
• People who are being outreached/notified about an issue.

Work Week - Berlin 25 April 2017

Discuss vs todo issues

• Ola: I would like to discuss about our process for issues where we discuss and how we move to a new issue for implementing.
• Mike: I agree and have no preference.
• Karl: Sometimes when we have big meta issues, it makes sense. But sometimes you need more context and it makes more work to create a very detailed todo issue.
• Ola: There are people who are just drive-by and some who want to be involved on a longterm.
• Karl: What do you thing about editing the first comment in an issue?
• Ola: I like the idea, but am not sure because it might invade the personal space of someone.
• Ola: I would like also to propose that people who needs feedback on their code before it's finished to create a Pull Request. karl, mike: ok.
• ToDo: Ola to add documentation in CONTRIBUTING.md on creating secondary issue after discussion for implementing - 2017-04-28
• ToDo: Ola to add documentation in CONTRIBUTING.md on documentating the pull request for early feedback - 2017-04-28

Project Direction

• mike: What should we focus on? Making it work? Growing contributions? etc. We should take the time to enable people to contribute in an easier way. We want to add content to support contributions. We need to add features, but we do not have to solve that today.
• adam: We have a lot of open issues where we didn't really discuss what the features we should do.

GitHub issues webcompat-dev

We are reshuffling the issues.

Team Strategy

(Discussion about Web Compatibility at Mozilla. Our strategy to get things fixed for the Web.)

Work Week - Berlin 26 April 2017

Form Design

We agreed that we need to improve the form. That probably means a simplification of the choices. Probably removing some of the options such as text visibility. The form was designed with a very strong mobile bias because it's where the majority of the issues is. We have also a thought about multi-screen process for filing the issues to make it less intimidating. The labels and instructions are probably too geeky and requires to be refined/simplified, for example "layout" is difficult to understand. Problem Types: Desktop site instead of mobile site The Site is not usable The Design is broken Video or audio doesn't play

Something else

------------------------------------------ 
| 1 url 
| 2 problem type 
| 3 how did you get there? (str) 
| 4 describe what was wrong 
| 5 browser version (is this correct) 
| 6 did you check in another browser? 
| 7 screenshot 
----------------------------------------- 

multicol view

1 5 
2 6 
3 7 
4 

Project Governance

• mike: we had some difficulties in the project. It's partly how do we make decision as a group about the project? Do we need a clear process or model? Or do we just need communicate?
• Ola: Everytime a team grows, issues are appearing. Maybe we need reference people.
• mike: we didn't have any issues with the community. Summary of some points: * Visibility of profiles of people part of the project. Mozilla employees + Contributors * Description

WebRender

• Adam: we had an issue about webrender busting out a Web site once activated. Do we need to care? mike, karl: yes we do.
• mike: we need to upstream those because it's ensuring webcompatibility issues for them. We need to contact Milan. We can open a bug in bugzilla.

Work Week - Berlin 27 April 2017

bots

• mike: Eric is working on an Alexa bot. He will file an issue for it.

Team Strategy

Discussions around the scope of what we are doing? The tasks, the projects, the management aspect, and the possibility for people to grow with better skills and responsibilities. Nothing defined absolutely. More of a panorama discussion to be able to explore a bit more. Probably in San Francisco.

Form Design

Working on some steps and mockups for the Bug Report form on how we can improve it so it's more accessible and trying to make it more valuable.

Logistics for the week

Agenda Bank

Use the following format:

 * Discussion Title (topic owner): quick summary giving context

• Softvision issues (mike): Summary and how do we evaluate the work?
• Form Flaws (karl): What seems to not work. Suggestion for improvements.
• WebVR compat (miket): How can we support this?
• Project governance (mike): I would like to formalize this, especially as we grow. How do we make decisions? What is the model for ownership, etc.\
• Technical leadership for webcompat.com (mike): As Mike drifts more and more into manager-land, I'd like us to discuss growing individuals to take ownership over technical direction and devops aspects of the site. Related to previous topic, a bit.
• Dev Documentation (karl): The dev documentation has grown quite a bit and distance to the first step to commit is a bit high. We might want to improve this.
• Webcompat-dev/webcompat.com balance (karl): We have to strike a balance in between the webcompat-dev and webcompat.com. Our "core business" is webcompat.com as in dealing with web compatibility issues. It's cool that we are developing the community on the webcompat-dev side, but it is probably more important to develop a sustainable webcompat.com community. The tool for a mean. It's easier to do dev, more palpable, but we have to be careful that it doesn't swallow us (even if it's more personally more fulfilling in many ways).
• webcompat-dev Issues Review (ola): Go through Github issues from 2014-2015. Sort, delete and close with history context.

Attendees

Arrival in Berlin (TXL), Friday April 23.

• Adam: 8:55 (from Munich, LH 174)
• Karl: 7:00 (from Abu Dhabi, EY1401)
• Mike: 7:00 (from JFK, AB 7249)
• Ola (local)

Departure from Berlin (TXL), Friday April 28

• Mike: 13:35
• Karl: 11:30
• Adam: 11:45

Logistics

• [DONE] Booking Berlin office space
• [DONE] Booking Flights.
• [DONE] Booking AirBnB
• Sunday Activity