Compatibility/Mobile/2014-02-work-week

From MozillaWiki
Jump to: navigation, search


The Web Compatibility Team is meeting during the week in Mountain View, California, USA. The February 3 last week summary has been published.

Attendees

  • Karl Dubost
  • Brad Lassey
  • Lawrence Mandel
  • Hallvord Steen
  • Adam Stevenson
  • Mike Taylor

Schedule

February 3, 2014 (Monday)

09:00-10:45 - 2013 review & 2014 strategy and goals

Looking at 2013 and what we've accomplished. Lawrence is giving a summary of what people achieved in the Web Compat activity. In 2014 we should finish up some of the projects we started in 2013 (tshirt design, badges, etc.), and decide what are the priorities for the year.

  • karl: I would like to fully understand what everyone is working on and how we distribute the work. I also want us to be community-driven, not lose focus on that. There are a few issues to tackle, in terms of documentation, e.g., how to get involved. Right now it's rough and hard to grasp. We should try to have bite-sized bits of work, to take 30 seconds, etc.
  • miketaylr: I was trying to get involve into fixing bugs for Firefox on bugzilla and the documentation is not necessary user-friendly, but the way it was done to make it easier for new participants. I agree that we should have smaller things that people can tackle.
  • miketaylr: I would be interested to understand what people think their jobs are.
  • lmandel: That's one of my goals this morning. When we hired, we wanted to fix some Web sites. But we don't scale, we need to involve people into this. So we need more people. Number 1 would be to get more people, Number 2 would be to fix sites ourselves.
  • miketaylr: It's clear that Web Compatibility work doesn't work. We are 6 and we would need 1000 people. I would love more people in Mozilla getting involved too. Within Mozilla and 10x people outside of Mozilla could participate.
  • lmandel: Some of the projects are not that clear for people inside Mozilla.
  • miketaylr: We need to simplify the UI and process.
  • lmandel: Aurora was made for Web developers, but we can customize it for people who are working on Web Compatibility.
  • miketaylr: (demo on his phone what he would love to have). In summary, simplifying the contributing tools and interactions.
  • lmandel: When we started this team there was a problem with the mobile web, that was our focus. But there's been other issues related to Desktop (Java/banks, etc). And nobody is working on Desktop. A lot of the things we're doing are related to desktop. Is this something we want to tackle?
  • karl: I think it's at least a 3 steps process. 1) clean up current database of bugs in Tech Evangelism component. 2) Figure out what to do with the language assignees. But we have to be careful and understand what that might affect. 3) I think it's important to stay on top of Desktop, especially with the growth of other browsers.
  • miketaylr: Sometimes I tackle the old bugs. It's kind of weird to close old bugs from 2003. Someone should be paying attention to. Some of my friends are reporting bugs on desktop which are Web compat issues. And it will have impact on the mobile.
  • lmandel: Do we want to do it? Some people seem to think we are the natural way for these desktop bugs.
  • miketaylr: some persons seem to be knowledgeable about any bugs. We could be allies with them and help each other.
  • lmandel: We can track it and understand what is there, and have a good grasp of the scope. And from there, we can figure out to expand on it.
  • hallvord: It is interesting work. I think there are more issues than I was expecting. I would love to do some of it. It's a matter of volumes. The problem is bigger on Mobile.
  • lmandel: Over the past few years the focus has shifted to mobile, "mobile first", "mobile is the future", etc. But Desktop continues to be important to us.
  • karl: This makes me thinks about how we can improve the devtools experience for working with mobile. We really need to improve.
  • lmandel: We need to tell the team about our usecases and feedback, and how it affects developeres.

(Discussion about the status of old bugs: Should we close, should we keep open, what are the benefits? What is worth our time?)

  • lmandel: But looking back to 2013 related to meetings and communication, how are we doing? How can we get better?
  • karlcow: More people should contribute to scribe meetings. We could perhaps rotate scribes and chairs. Instead of saying how can we fix it, let me tell you my frustrations when I'm chairing. Usually I go through the list and look at topics we've discussed to come up with agenda items. But it's only my perception. It seems like people aren't coming up with topics. It would be a lot better during the week, "we need to discuss this, I'll put it on the agenda".
  • lmandel: Another thought, we've had this every other week in the past. We can continue every week, or we can move to a bi-weekly. We shouldn't meet just because it's on the calendar. If there's nothing on the agenda, or just a simple item we can address via email let's cancel for that week.
  • miketaylr: let me think.
  • hallvord: Bi-weekly meetings might be nice.
  • adam: am I breaking this? (yes)
  • miketaylr: we can add IRC-to-email feature (daily IRC-log mailout to subscribers)
  • mikeataylr: Another issue I'd like to improve is communication with other departments, knowing who the right people are to help us get our work done, etc.

10:45-11:00 - Break

Dry Squid eating. Omiyage from Japan by Hallvord.

11:00-12:00 - Mozilla Project and Corp meetings (team introduction)

See the team on Project meeting video

12:00-13:00 - Lunch - Burritos

13:00-14:45 - Working with volunteers

Discussion with Mike Hoye.

  • mikehoye: We are developing tools that will make it a lot easier for other people to contribute in bite-sized ways.

(team introductions)

  • How do we find volunteers?
  • How do we make it a good place to work?
  • What can I do for Mozilla?
  • Job description for volunteers?
  • Guide easier for people?
  • Growing and scaling with everyone contributing
  • Geo maps of volunteers
  • Badges (including the design)

We talked about our 2014 goals earlier this morning. One of our biggest goals for this year is to find more volunteers. To increase the effort. We need more help to solve the problem.

  • mikehoye: What is a minimum viable contribution? What's the smallest thing that a volunteer can do for you to make your life better?
  • hallvord: figure out how to contact a website and send an e-mail or tweet about the problem
  • mikehoye: what about having people verify issues? How can we break contributions into smaller time commitments? I have 5 minutes, 10 minutes, etc. We have 1000 potential student representative volunteers who could potentially jump in. Would you be able to handle that level of contribution?
  • karl: It depends on the quality of the report. (discussion on having people just find a contact email, rather than doing the outreach)
  • mikehoye: It sounds like you're already describing something like a roadmap. From there you can start to define goals like, you've verified 100 sites or found 5 contacts, etc. and develop badges from that.
  • karl: What is the interest for people to get badges?
  • mikehoye: Some people don't care. But there are a lot of people who find them entertaining, fun, surprising. It's a way for many people to show the amount of work that they've contributed to a project. It lets people self-organize in ways that are interesting and unpredictable.
  • karl: Do you recommend to have different badges for different tasks?
  • mikehoye: I think as much as possible you want them to be unique. It helps if there's a lot of different variety, some people use them as a point of pride. The ability to give a way for people to be distinct is very valuable. Even a badge that can only be given away once, e.g., first person to solve a compat issue in [country x]. People will compete to get these. At some point, you want to award quality or quantity (if people recongize that they've spent X hours doing something, they might feel overwhelmed and quit).
  • lawrence: the module system might be interesting to consider as well, with the notion of module owner & module peer.
  • lawrence: I'd like to identify what badges we could create.
  • mikehoye: Can we clearly define what contributions are? And how are we going to find out about it. What are the smallest things people can do and build badges on top of that.
  • [https: //docs.google.com/spreadsheet/ccc?key=0AomP9VFrH9P5dFQ5T1Ffdk9fZ2dWQkQ1aTY4MzJJb2c&usp=sharing#gid=0 breakdown of taslks]

Now

  • You can report a website - [1, 10, 25, 100]
  • Analyze a bug, if you're more skilled[1, 10, 25]
  • You have contacted a site, and a bug got fixed as a result [1, 10, 25]
  • Close the bug as resolved. [1, 10, 25] (merge into previous)
  • Tech badge
    • Building and submitting patches for tools [1, 10, 25]
    • Create new tool  ? [1]
    • patch/fix for open source framework [1]
  • writing automated compat test cases for compatepede
  • sitedata.js

Soon

  • Documentation ?
    • check if MDN team has existing badges
  • Give a talk about compatibility
  • Social media work for compatibility - make people aware

Later

  • Search for a contact (twitter, email, contact form, etc.)
    • possibly not a good one, might encourage spammy behaviour.
  • Verify a bug. [10, 25, 100] - kind of tricky
  • Test a site and verify that there are no problems. [1, 10, 25, 100] - also tricky
  • Regression ranges [1, 10, 25]
  • Finding new contributor
    • someone in a locale has a better chance of finding a new contributor
  • Mentoring new person
    • measure?
  • Install help firefox add-on on someone else's phone
  • mikehoye: Once we've got a list of badges, how can we make it easy for people to help?

14:45-15:00 - Break

15:00-16:50 - Working with volunteers

 Pull request https://github.com/jdm/asknot/pull/104
  • OpenWeb volunteers job description.
  • Slideset for openweb work (positive)
  • How to organize an event (less positive) It has not been successful in the past.
  • Not duplicating efforts for evangelization (tomorrow discussion)
  • interacting with web compat
    • bugzilla is not nice - many volunteers do not want to file bugs
    • webcompat.com should help
    • really need to keep things simple
    • can capture screenshot/video and url automatically and prepopulate submission (brad has fennec add-on for this)
    • we need to review the onboarding process flow to ensure that the entire flow is simple
  • also need to think about people who fix sites
    • web developer friendly view of the bug, only show comments that are tagged
  • first question should be what is the UA

16:50-17:00 - Wrap up the day and modifications to tomorrow's agenda

  • karl: morning was good, afternoon could have had more concrete outcomes. let's have concrete actions from discussion.
  • mike:
  • adam: kind of what I expected from a first day of a work week, good to have action at the end of the day
  • hallvord: nice to be at project meeting, say hello to people
  • lawrence: we got through some good stuff yesterday. it seemed like a different way to work might be to hack on things we talked about yesterday. one day talk, one day work.

Work list:

  • job description written and posted
  • creation of badges
  • simplified site problem page (or whatever)
  • simplified Bugzilla problem reporting view - perhaps it doesn't need to be visibly Bugzilla at all
    • tweak brad's mobile compatibility add-on
  • minimum viable contribution for 1, 5, 10 mins availability
  • desktop bug review - cleanup bugzilla
    • cleanup bugzilla lang components (KD=fr, )
  • world map with contributor locations (KD)

Languages we care about

  • Spanish
  • Polish
  • Portugese
  • Hungarian
  • Serbian
  • Czech
  • Italian
  • Montenegrin
  • Hindi
    • other Indian languages?
  • Swedish

February 4, 2014 (Tuesday)

Template for bugs explanation

Adam is introducing a mockup for explaining the issues and possible fix.

  • miketaylr: It's good at a first contact.
  • lmandel: If we have a generic tag that will include an automatic presentation of the problem description and its fix.

TODO:

  • all: tag "suggestedfix" on the comment.
  • adam: db on what is the issue and how to fix it.
  • mike: creates repo & dummy html structure: ♡♡DONE♡♡
  • karl: layout ♡♡DONE FIRST DRAFT♡♡
  • mike: prototype template junk in JS
  • adam + karl: copy = content
  • karl + hallvord: backend/script to generate static pages.


Repo: https://github.com/webcompat/simplebug

AreWeCompatibleYet.com

  • hallvord: cron job is running and the site is updated every 2 hours. The plan is to have separate pages for lists for different countries or specific domains. The data will be eventually information from compatipede.
  • lmandel: how do you use it?
  • adam: I used it to search a bug.
  • karl: rarely
  • miketaylr: I don't.
  • hallvord: I use it because it is fastest than bugzilla.
  • karl: I use a combination of the wiki and the bugzilla saved searches.
  • hallvord: I'm not sure how complete that it should be.
    • quick list for open bugs for a specific domain
    • dashboard per country (bug statistics, timeline)
    • Todo list for volunteers on the view per list


TODO

  • Call for automated testing
  • "pass" maybe change to "Check it"
  • Redesign with a simplified home page and then secondary list pages. Give HTML templates to Hallvord.

Automation of Tasks

Karl: http queries for testing server sniffing, report to copy/paste into bugzilla. Different ua's and follow redirects.

February 5, 2014 (Wednesday)

  • 08:00-09:00 - Partner meetup Karl & Lawrence
  • 09:00-10:00 - Open time
  • 10:00-11:00 - Web compat video
  • 11:00-12:00 - webcompat.com planning
  • 12:00-13:00 - Lunch - Burritos x 3 (really?)
  • 13:00-15:30 - Hack on work from day 1-3
  • 15:30-16:00 - Web compat, QA, and automated testing
  • 16:00-16:50 - Hack on work from day 1-3
  • 16:50-17:00 - Wrap up the day and modifications to tomorrow's agenda

February 6, 2014 (Thursday)

  • 09:00-12:00 - Hack on work from day 1-3
  • 12:00-13:00 - Lunch (Lawrence and Adam depart) - Burritos x 4 (no more :\)
  • 13:00-17:00 - Hack on work from day 1-3

February 7, 2014 (Friday)

  • 09:00-12:00 - Hack on work from day 1-3
  • 12:00-13:00 - Lunch - Burritos x 5 (but none for Lawrence and Adam :( )
  • 13:00-17:00 - Hack on work from day 1-3

Parked items

  • Working with other Mozilla teams
  • UA detection use cases
  • Project definitions
  • Bug process and Buzilla improvements

Agenda Item Details

2013 review & 2014 strategy and goals

  • What did we accomplish in 2013?
  • What has been working? What do we need to tweak/change?
    • Weekly Meetings - Satisfied? Things to improve? Rotating Scribe? Chairing?
    • Bugzilla
  • What is our focus for 2014? (Solving compat problems, recruiting and onboarding volunteers, etc.)
  • How will we measure our success?

Mozilla Project and Corp meetings (team introduction)

  • team introduction
  • Adam's summary of getting started with Web compat issues

Working with volunteers

  • Finding volunteers - it is really hard to engage with volunteers
    • WhatCanIDoForMozilla
      • Status and how we can make progress
      • Time to create flows to Web compat effort
    • Meeting with (future) volunteers
      • Create a 101 on setting up events - Mozilla space specific?
      • General guidelines on event participation - in what type of events should we participate in order not to duplicate effort of other Mozilla teams?
  • How do we make Web Compatibility a nicer place to work altogether?
  • Job description
    • Pair task to write job description for post on blogs, webcompat.com, other places?
  • Mentoring
    • Mentoring in the sense that we can help them to contact or they can help us for example with language skills. It gives more a sense of working together. Experience maybe with Spain and Adam.
    • What is required from mentoring for Web compat participants?
    • from [contactready] to ASSIGNED and [sitewait], how do we distribute the work, how do we make sure we moved on and still move the community forward.
    • New contributor's guide
      • little handbook for testing, contacting, etc for Web compatibility issues.
  • Recognition / keeping people engaged
    • make a twitter list of volunteers who are actively participating on @MozWebCompat
    • make a geo map of volunteers and build recognitions for the work they are doing
      • can we build this today?
    • Open Badges
      • Outline the badges that we want to create an assign someone to create them
    • Tee-Shirt (bug 927478)
    • Stickers (bug 927478)
      • small, in series, usable on laptop, and or even on paper notebooks (aka embodiement of achievements).

Project definitions

  • Team project backlog
  • Each project should have an clear mandate and expected duration (how much time are we willing to spend on the project?)

AreWeCompatibleYet.com

  • What's to be done?
  • Create issues on github?
  • Schedule for releases

UA detection use cases

Web compat, QA, and automated testing

  • how the web compat and QA teams should interact
  • Automated testing
    • Ensure everyone knows how to use the framework - read and write tests
    • Feedback for Hallvord and Seif
    • Improvements
      • Finalize procedures for generating bug reports
      • reporting bugs and let the automated tools analyze and annotate them
      • Countries coverage for testing survey
        • New countries to add
        • Old countries to improve

Bug process and Buzilla improvements

  • Do we need to capture more information on the bug?
  • Should we try to create standards to allow for reporting? (eg. best method of 1st contact by region)
  • User Agent used for the tests. We see sometimes bugs which are landing in Tech Evangelism. Some of these sites have been tested with UA which are not production ones, and some sites will then fail. Should we recommend them to test with production ready UA?
  • Adam has some suggestions for ways in which we may be able to improve Bugzilla for the web compat community

Working with other Mozilla teams

  • Collaboration with other departments
  • Slidesets for devrel group about WebCompat
  • How should we work with developer advocates and the dev engagement team?

webcompat.com planning

  • high-level architectural decisions (i.e., sitemap, content-type)
  • determine what can be accomplished this week

Hack project board

(in no specific order)

  • webcompat.com
  • awcy.com
  • new contributor guide
  • UA use cases report
  • Web compat job description
  • WhatCanIDoForMozilla Web compat flow creation and submission
  • Bugzilla interface improvements (form, separate entry point)
  • contributor geo map
  • Bugzilla process description
  • event guide
  • Twitter volunteer list
  • open badge creation
  • automated test framework improvements
Retrieved from "https://wiki.mozilla.org/index.php?title=Compatibility/Mobile/2014-02-work-week&oldid=917620"