From MozillaWiki
< QA‎ | Taskboard
Jump to: navigation, search

Session at Mozilla Festival 2012

Zac Campbell of the Mozilla QA team led a session at the Mozilla Festival 2012 in London, UK.

  • Date: Sun 11th November 2012
  • Time: 11:00 am – 2:00 pm GMT
  • Location: London, UK | Ravensbourne
  • Mozilla Reps: Carlo, Ioana, Deb, Kensie
  • Volunteers: Dave, Alex, Robert and Bebe

Session Setup

For the setup of the session Zac decided to seed the conversations in the group with 8 questions that represent some of the questions and problems that Mozilla has with itself and contributors. These were printed (PDF 94 KB) and put into envelopes. Discussion cards

Zac planned to split everybody into groups and give each group a card and 15 minutes to discuss their thoughts on the issues and write them out on paper. Then the group would explain their issue to another group before hacking on printouts of wireframes.

Discussion on Questions about Contributors

The seeded discussions went very well with groups both coming up with different thoughts on the same issues. Then each group stood up and presented their findings (PDF 2.28 MB) on each question, after which some more debate and discussion ensued.

Entry points

Q1: There are lots of different 'entry points' into Mozilla: Mozilla's Wiki, blog, IRC, in person, etc. Is a website the best option we have?

Discussion: [not discussed]

Tasks Queue

Q2: How can Mozilla staff make sure that there is a healthy set of tasks available at all times? Sometimes tasks get completed very quickly and the list needs attention and to be replenished!


  • Personal Documents / Notes
    • Github Issue
    • MozTrap => Personal workflow affected
  • Staff Notes
    • Mature contributor tagging
    • Junior Guy
  • Each project
    • Manual Tests
    • Automated Tests
    • Tests => Cyclic (Nightly test manual)
    • Needs to be tackled => Special Task => Simple Tasks / Knowledge Based
  • Parsing Emails -> Editorial Workflow
  • Priority, Severity (Importance), Skill Grade

Contributor ability

Q3: What is the difference between a task that is too hard and causes a contributor to give up and a task that is hard enough to challenge and educate. Should we set tasks beyond the ability of the contributor as motivation?


  • A task is too hard if there is no documentation. The contributor needs guidance.
  • Two Types of Tasks
    • Learning task, challenging you
    • Chore / maintenance, already have the skill set but motivated by desire to help Mozilla.
  • Tags:
    • degree of complexity
    • learning task tag, mentor tag
  • Tasks to be available always
  • A wide range of tasks, always.
  • Time:
    • Simple task but long time would be more patient
    • Difficult task and no idea/skills more likely to give up
  • Leave people to choose their own tasks, they know their own skill level better. "Contributor is always right!"

Interaction across timezones

Q4: Mozilla works all timezones but mostly Pacific time and EU timezone. How can we deal with a contributor that reaches out at an odd timezone?


  • The Taskboard has a contact person -> responsible for / assigned to task
  • Don't point to IRC -> point to contact person
  • Reps / volunteer present on IRC -> covering all timezones just to give support and answer questions (not technical ones, but the starters: How can I contribute?) -> point to taskboard, link wiki documentation. Just to get to them.

Contributor encouragement

Q5: How soon after deciding to contribute at Mozilla should a person be talking to a real Mozillian instead of a website? Would you be discouraged by taking tasks and direction from a website?


  • Two Persons
    • wants hand-holding (HH)
    • wants to explore (E)
  • Opportunity to contact someone immediately (HH)
    • Contact info for mentor in task
  • Greeting email after X days (E/HH)
    • Mentor sends personalized email to volunteer who has taken task if they didn't reach out on their own (HH)
    • Tone is just "Hi! I'm here" not "Show me your work" (E)
  • Would you be discouraged?
    • HH => Yes (Kensie, Ioana)
    • E => No (Kairo, Deb)
  • Everyone needs fallback if website isn't clear.

Contributor skills

Q6: Contributors can come to Mozilla with all sorts of skills. Some are very technical whereas others are not but are very motivated to help out. How can Mozilla QA accommodate all of them?


  • Break down every aspect of a task.
  • Encourage people to work together to cover different aspects of the task.
  • Step by step documentation on how to complete tasks.
  • Don't see hand-holding as a bad use of time!
  • Rank tasks by difficulty and skills.
  • Let volunteers have your easy tasks.
  • Make it easier for higher skilled volunteers to be assigned tasks / take tasks off old team.
  • Prioritize code reviews for new volunteers.


Q7: Mozilla QA is enormously thankful for the work contributors complete. How can the One and Done site itself reward people for completing tasks?


  • Badges!
  • Progress meter (track completed tasks by volunteer) -> details about work.
  • Dan Pink [[ RSA "What Motivates Us"] (autonomy, mastery, purpose)
  • Offer harder / higher vaue tasks after volunteer completes a task (mastery)
  • Let volunteers create tasks (autonomy)
  • Communicate the higher level goal the completed task helped team achieve (purpose)
  • Badge Rewards / Open Badges
    • Multiple levels, daily evel, weekly
    • Show off your involvement
    • Git access badge
    • Get on top of open badges accounts (-> link to Mozillians), share profiles
    • Levels
    • QA team can award badges based upon discretion.
    • Non-swag rewards like merge rights / commit access. Currently discretionary. When do.
    • Member of Moz group on Github is good for CV. Proof of OS [Open Source] contributions. Make sure contributios are in our group and recognized.
  • Swag
    • Special QA branded MozGear
    • A T-shirt, lanyard
    • Badge Level 1 - swag package
    • Level 2 - more swag
    • Swag is a chance to be recognized outside the virtual world, in the physical world.
    • Pride in open source projects and pride of contribution.
  • Contributor spotlight on One and Done, not in QMO, save duplication
  • Sending to MozCamp / Fest or contributor meetups, etc. Big incentive.
    • Good to meet Mozillians.
    • But one of team should be present to greet and mentor the contributor, bolster the relationship. (Important!!!!)
    • Important for Mozillians' presence at these events.

Mentoring contributors

Q8: A contributor will often need to talk to QA staff to find out information. How can we connect a contributor with the most suitable guide or mentor within Mozilla?


  • One point of contact for every communication channel
  • The point of contact does the channeling of questions to the proper position able to answer it.
  • Available channels:
    • IRC (Derivatives: IRC clients with Social API)
    • Mailing List
    • Task Board Forum
  • Have someone in the QA Team to reply to the questions within 2 working days or sooner.

Discussion on Wireframes

The session attendees only had about 30 minutes left to hack on the wireframes. They spent those 30 minutes scrawling all over the wireframes (PDF 3.19 MB). It was a bit unstructured and they didn't apply all of the discussion results to the wireframes but they got some good general thoughts nonetheless.

Home Page

Original Wireframe

Wireframe hacks-01.png

Edit Profile Page

Original Wireframe Wireframe hacks-02 1.png

Wireframe hacks-02 2.png

Wireframe hacks-02 3.png

View Profile Page

Original Wireframe Wireframe hacks-03 1.png

Wireframe hacks-03 2.png

Wireframe hacks-03 3.png

Task Execution Page

Original Wireframe Wireframe hacks-05.png

Task Feedback Page

Original Wireframe Wireframe hacks-07.png

Task Creation Page

Original Wireframe Wireframe hacks-08.png

Tasks List Page

Original Wireframe Wireframe hacks-09 1.png

Wireframe hacks-09 2.png