Contribute/Pilots

From MozillaWiki
Jump to navigation Jump to search

The plans for community building 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 the more interesting 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 provided mentoring 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.

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: Ruben Martin was interested in working on how we could localize the Get Involved page (which had always been English only) so that it could be a useful resource for connecting non-English speakers to opportunities with local communities.
    • 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.
  • Pilot: Running a campaign to get people onto contribution pathways
    • Summary: As part of the 15 years of Mozilla campaign, we talked about how Mozilla was a place for participation and encouraged them to sign up on the Get Involved page.
    • Outcome: We saw a huge spike in the overall numbers of people wanting to contribute to Mozilla and particularly large increases in new types of contribution opportunities, like Education.

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

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
    • Summary: Many teams have been interested in awarding badges to contributors and some of those teams have people with time available to issue those badges. There is very limited bandwidth for community building within Webdev though, so this pilot effort created a way to automatically track relevant contribution opportunities and send that data directly to badges.mozilla.org.
    • Outcome: There are now badges being issued to people who contribute to Mozilla's web sites that are being issued without requiring any time from Webdev team members.
  • 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 allowed us to do things we hadn't been able to do before, such as put together a survey that we could send to people who had started to contribute but didn't end up being successful.
  • Pilot: Creating a Working Group of community builders
    • Summary: People involved with community building for their team or region want to work with other community builders in order to reduce duplication and make the best use of limited resources. In Q2 we organized a working group around the Systems and Data pillar to identify the shared needs of staff and volunteer community builders and identify the best solution for those needs.
    • Outcome: The Working Group model has been an effective way of focusing the efforts of a diverse and decentralized group and we are looking at spinning up additional groups around the other community building pillars.

Finding: Having the appropriate tools and data is essential for community builders to be effective and to make smart use of the limited time teams have to devote to community building.

Education

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.

  • reps to deliver workshop content (in process)

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.

Recognition

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

Finding: Recognition efforts have been happening in an ad hoc way and we have been able to identify ways to make this process more comprehensive and less time intensive.