Participation/Community Playbook

Introduction: Motivation and scope

This document aims to provide some concrete recommendations about how a healthy Mozilla community should look.

The content is a result of various investigations and learnings from past experiences inside various Mozilla communities as well as other open source projects.

The topics covered by this document are:

• Organization and governance: Roles, rules, and code of conduct.
• Onboarding, engagement, pathways, and retention.
• Contributor development: Empowering and learning.

Organization and governance

The first step for all communities is to have a solid base, and this is a good and documented organization and governance model.

Roles

In order to understand how many people we have available in the community, and which areas of interest we can cover, it is necessary to have a census.

Functional teams

Once you have this information you can group people by area of interest and let them decide at least two people to coordinate efforts - in order to prevent bottlenecks, it is important to have more than one person coordinating.

People coordinating projects should be in touch with functional teams at Mozilla to establish a feedback circle about goals and activities - at least one should be an English-speaker.

Core team

From all the people in the community, create a core team to work specifically on community building and decision making. This should be an open call to anyone who can commit to:

• Work actively on community building and discussions.
• Have a response time of at least 72h.
• Meet online at least once a month.

This team would be the group to take final decisions on community matters and it should be open to anyone that have worked actively at least three months in the community.

Decision making

Discussions and decisions should be transparent to all community, even if just the core team or the functional coordinator have the final word, every community contributor should have a voice during discussions. Have a single/public channel to talk about the community, if your community is medium/large split functional/project discussions to separate channels.

For core team, a simple majority voting should be enough to approve decisions that don’t have a clear consensus during discussions. A supermajority (2/3) should be required to big changes like changing the community rules. Core team should be able to vote during their 72h response time.

Leadership rotation

Being a functional coordinator or a core team members shouldn’t be a life time position. These roles should be renewed each 6 months.

• Functional: Current coordinators should present a six month report about the work during the preceding months. Also anyone should be free to present themselves to run a functional team, if more than two people run for coordination, they all should present their plan for the next six-months and the core team should vote to have at least two coordinators.
• Core team: All members should actively show their intention to continue in this position and present their personal plan and goals for the next six months.

Community rules

The way the community is structured and decisions are made should be clearly documented on the community portal, this should be a reference for everyone from old to new members.

Anyone in the community should feel free to propose changes to the community, the process could look like this:

• A proposal is opened on the community forum for discussion by a contributor (champion) answering what and why. Minimum six days period discussion.
• Once there is a clear proposal the "champion" will seek at least five other contributors to support this proposal (core team members will be exempt from this requirement )
• Proposal is formally sent to core team, who will discuss, modify (if needed) and vote.

The Mozilla Reps program has a proposals SOP based on the previous example.

Code of conduct

All Mozilla communities should follow the global Mozilla Community Participation Guidelines - it should be localized to your language and linked from your community rules.

Onboarding and engagement

Having a great experience as a newcomer is the key for success and growth. Having a clear documentation linked from your homepage should be the first step.

Documenting

What the main documentation page should include:

• Who we are? What’s Mozilla?
• Where is the community, where to go to talk? (IRC, forums, mailing list, github, task manager, social media…). List all the resources a contributor should know about.
• Community rules and structure link.
• What are the main areas and projects the community is working on? List of areas and projects.
• Contributor directory
  • Who’s currently involved in the community?
  • In which areas?
  • Who is the core team and what’s its role?

Mentors

It’s interesting to form a mentors group to help newcomers to find their way into the community. A good recommendation is to provide a "Present yourself" forum where new people can post and ask for help or how to get involved with project X.

"Crowd-mentoring" is encouraged in medium-large size communities to avoid bottlenecks. Anyone from the community should be able to help newcomers, but the mentors group should be able to devote more time to it.

Projects and pathways

Each project should have its own page describing all the relevant information about it.

• Who is coordinating, how to contact them?
  • A public forum or list to ask questions is encouraged, instead of personal emails that could generate bottlenecks.
• What this project is about? Is there a skillset needed?
• How much time (h/week) do I need to help?
• How can I start contributing now?
  • List of easy tasks.
  • A pathway from easy to medium and large task currently opened.
• Reference material
  • What learning materials should I check to improve my skills to help this project?

Everyone in a project should be tracking newcomers questions, projects coordinators shouldn’t be the only ones onboarding new people.

Retention

Why do people stay in a community? What makes you stay? What are your motivations?

Each person has different motivations to contribute to mozilla, try to understand the motivations for the people in your community.

Some tips:

• Be always public about the importance of everyone’s voice in all discussions. People should feel part of the group, like a family, they should know their opinions and ideas are valuable.
• Promote and establish an open and honest feedback and listening culture.
• Try to include at least 30% of new voices in discussions. Don’t underestimate the value of shoulder-tapping new people and asking them to share their opinion and letting them know how important it is.
• We are humans! Try to have monthly community meetings via videochat or at least audio. This is a closer way to collaborate - email or text-messages are sometimes tricky to interpret.
• Write good documentation, check with people who are not involved with mozilla (maybe your friends or family) to check if it’s clear enough to start contributing without help.

Contributor development

Being part of Mozilla is not about "giving" but also getting value back to people.

Try to understand:

• Why people in your community contribute to mozilla.
• What they would like to learn.
• What are their skills, especially skills they have never used at mozilla, including personal skills.
• What they would like to teach.
• What are their goals for the next months.
• How they would like to be recognized.

Empowerment

Mentors should be the group focused on empowering people, being in touch regularly with contributors and getting the previous information from them.

Encourage people to work on impactful projects but also projects they are more excited about. Running a local sessions of "Planning for Impact" is a good way for people to understand how to balance impact as mozillians and personal empowerment.

Recognition

Have in mind what you’ve learned about how people in your community would like to be recognized.

Some ideas:

• Use your regular meetings to do shout-outs and celebrate people and project accomplishments, even the smaller ones.
• Promote an appreciation culture where people naturally say thank you, especially powerful in a public space (social media) where others can also see this recognition.
• Establish a "contributor of the month" article on your blog.
• Publish interviews to individuals on your blog to publicly promote their work.
• Create fun badges to give to people. Per-project badges too.