From MozillaWiki
Jump to: navigation, search

Our community building efforts have been informed by a number of pilot projects that were put in place to test ideas about how to increase participation. This page documents some of those pilot projects and discusses what was learned from those efforts.

Community Builders

Hypothesis: Teams need Community Builders to drive their participation efforts. Without someone focused on participation, communities either don't form or they don't scale.

  • Pilot: Dedicating someone to create a new community
    • Summary: Dia Bondi became a Steward for the People team and was supported in her efforts to understand how to design projects for participation and was mentored on how to work effectively with volunteers.
    • Outcome: The People team hasn't had a history of participation, but after becoming a Steward Dia brought on two volunteers to the team and has plans for working with a Human Resources department at a local university to connect with additional contributors.

Finding: Having someone drive participation matters and we are able to intentionally deepen existing communities as well as broaden participation opportunities to new areas.

Next steps: David is working with key teams that have low leverage, such as Firefox OS engineering, to identify and support people who want to drive community building plans.

Contribution Pathways

Hypothesis: At the scale of Mozilla today, it is no longer feasible to expect volunteers to be able to connect with appropriate contribution opportunities without guidance.

  • Pilot: Localizing the Get Involved page in Spanish
    • Summary: Mozilla Hispano was interested in being the first local community to connect to a localized version of the Get Involved page (which had always been English only) to figure out how we can better connect non-English speakers to opportunities.
    • Outcome: The Mozilla Hispano community evolved their workflow (post one and post two) and are seeing early successes with finding new contributors (although they are also running into scaling problems with their mentorship program handling an increase in volume).
  • Pilot: Creating a contribution path for Webdev
    • Summary: The Webdev Stewards created a clear series of steps that contributors could follow to understand how to successfully contribute to a Mozilla web site.
    • Outcome: Creating a pathway provided clarity to new contributors as well as to people internally who wanted to understand where there were roadblocks to new contributors. Having a documented pathway also allowed us to create a set of badges that could be automatically issued as people progressed through the pathway (see below for more).
  • Pilot: Running a campaign to get people onto contribution pathways

Finding: Having clear contribution pathways and visibility into the health of those pathways matters and this becomes more important as we grow bigger.

Next steps: We are working with Community Builders to create more pathways and are putting plans together to get data about contribution pathways so that we can analyze what's working and where the roadblocks are (see below for more information about data plans).

Systems and Data

Hypothesis: Systems and data are needed to handle the volume of contributors wanting to participate and to scale up participation processes and best practices to the entire organization.

  • Pilot: Automating the delivery of badges to Webdev contributors
  • Pilot: Building coding contribution dashboards
    • Summary: Josh Matthews and Seif Lofty created some prototypes of dashboards that show activity of contributors involved with coding projects.
    • Outcome: This data allows the Coding Stewards to do things they hadn't been able to do before, such as put together a survey that could be sent to people who had started to contribute but didn't end up being successful.
  • Pilot: Gathering contribution data
    • Summary: Josh, Pierros, Liz and Ricky are working on a prototype to gather contribution data from different systems into one place so that information can be easily accessed and analyzed.
    • Outcome: The initial work is showing that we'll be able to build contribution dashboards more quickly than before and it will give us a more holistic look at contributions than the current limited set of function-specific dashboards.

Finding: Community Builders need the appropriate tools and data to be effective and we simply can not scale without them.

Next steps: The Systems and Data Working Group is putting together a proposal by the end of Q3 for how to move forward with the top priority community building functionality needs.


Hypothesis: We can no longer assume all Mozillians have knowledge about community building and we need to capture and spread information about how volunteering works.

  • Pilot: Teaching People team about how to use open channels
    • Summary: The People team hadn't historically known about or made use of the open channels in the community. Dia and David put together material about how to be effective in an open community and delivered that at a team offsite.
    • Outcome: The members of the People team are now actively involved with using IRC and the #peoplepeople channel has become an effective way to collaborate with Mozillians across the project.
  • Pilot: Running a community building video sprint
    • Summary: As part of the community builders meetup in Toronto people were asked to take some time to capture themselves on video to share a tip or best practice for other people interested in working with contributors.
    • Outcome: The sprint generated three videos that can now be shared easily with anyone looking to learn more about how other teams are effective at community building.
  • Pilot: Having Mozilla Reps deliver community building workshop content
    • Summary: Mozilla is so decentralized that we need to find ways to get training content out to all of the different teams and communities. The Mozilla Reps are a global network of core contributors with expertise on volunteering and they have expressed interest in taking the community building workshop material and delivering it to other Mozillians near them.
    • Outcome: This is currently in process and we don't know the outcome yet.

Finding: There is definitely a demand for learning more about community building and we have been able to create material that has been helpful and to identify ways to deliver this in a scalable way.

Next steps: We are creating a second version of the community building workshops that will be easier for people to interact with and will be easier for people to deliver to their own teams and communities.


Hypothesis: Recognizing volunteers for their contributions will deepen and extend relationships and will help us develop casual contributors into core contributors.

  • Pilot: Thanking contributors with each Firefox release
    • Summary: With the creation of some initial coding contribution dashboards (see above) the Coding Stewards have been able to set up a regular recognition schedule and they are thanking new coding contributors each time there is a Firefox release.
    • Outcome: This recognition is being appreciated by contributors (for example, one contributor thanked for Firefox 19 writes in the post "Hey, Thanks for the blog! Feels good :-)". The next step here is to get data to see how recognition helps people move along pathways and to start testing the effectiveness of recognition options (badges, swag, thank you posts, etc).
  • Pilot: Creating a template contribution agreement for universities
    • Summary: One of the contributors to the People team asked if we could sign a letter that would allow her to receive credit at her school for the contributions she had made to Mozilla. Dia worked with both the school's administration and our Legal team to craft a letter that was acceptable to both groups. She then created a generic template of the letter and shared it with the community building group.
    • Outcome: Within a day of having shared this template out to the community building group, she had received thanks from several other people (both paid staff and volunteers) who said they had been looking for something like this to establish more formal relationships with universities in their area to help them better recognize student contributors.

Finding: Recognition efforts have been happening in an ad hoc way and we have been able to identify ways to make recognition efforts easier to implement and easier to scale.

Next steps: We are pulling together documentation about best practices into a Recognition Guide that can be easily shared with teams.