Community Playbook


@deimidis and I plan to work on a “Community Playbook” where we want to detail some tips and tricks about how to create, organize, grow and sustain a healthy Mozilla Local/regional community so it can have a place to be inspired for improvement.

Since we know a lot of people have worked in this in the past and we would like to gather here other documents we can incorporate in this playbook.

Please, share here any other previous work about this topic.



There’s a lot of links at the end of this minutes of community building session from mozlandia. I think they’re all very very cool tips and tricks about increasing code contributors.

Pinging @buluma_michael, @ashickur_noor, and @Swarnava about this - gentlemen, you may have experience and knowledge to share or know others who could contribute.


Here is a conversation from earlier in the year, in which there is a link to a document George made outlining some principles of a healthy community.

Can I join you two @r_oVhPfcJCUUC5wbm6i4_C2Q and @deimidis? I’m pretty much interested in building something this.

Apart from the previous link, I (along with @Tripad) was also thinking of a mantra like ABCs for a member


Yes, we are currently defining next steps, which are going to be basically gather docs form other communities with a clear doc about how the community runs.

Hera Hussain has written this about Chayn: Running a fluid and democratic volunteer-run organisation

I want help in that playbook, I have started a discussion with some useful points for that.

I want to take part in this awesome project as well as I have been involved into designing such tool for my local community as well .

So here you have an early draft of the document

Please chime in and add comments, we would be reviewing all of them by next Monday November 30.

Thanks @Spike1 for all the proofreading :slight_smile:

The doc is a bit long for me to digest in one, so I’ll comment on the first part first.

I don’t find a lot of overlap on the general governance you propose for communities, and general mozilla project governance. For the latter, we have modules, owners, and peers. You’re describing details of how to run a democracy?

I don’t get your point, why do you think communities having an internal governance is overlapping with Mozilla module system?

BTW, the model described as suggestion in the doc is not a democracy, since anyone can join the core team due their own merits.

Functional teams = Module
Two coordinators = Owners
Others in the team = Peers

Not really, has more.

@emma_irwin @lshapiro Maybe you can provide some feedback about recognition and diversity to include :smiley:

I need to catch up on this - am totally behind on the overall goals of the playbook - but I’ll do my best to add valuable commentary on diversity stuff.

I remember having similar discussions when the Reps program started, and the program collided with preexisting communities: having one local/regional community is great (and ideal), having multiple local communities that specialize in specific functional areas is not bad, as long as they’re healthy and able to work together (or at least coexist in a civilized way).

And while I see benefits in leadership rotation, I don’t think that’s a good idea for every functional area. The reason is the same for not changing module owners and peers every 6 months.
When I look at our volunteers doing l10n, I don’t see functional coordinators, I see module owners (localization X, l10n, SUMO l10n, MDN l10n, etc.).

I’m also scared by bureaucracy, having seen very healthy and wide communities failing under the weight of it.

1 Like

The document doesn’t describe a mandatory rotation, it describes a way to be able to continue and renew leading a functional area, but under the accountability of the rest of the core community looking for the health of it. So in this analogy the module owner is accountable to the rest of the community each 6 months.

Hi all,

This is now moved to the wiki

1 Like