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
2 Likes
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 https://discourse.mozilla-community.org/t/protocol-for-recruit-new-mozillians/5528/4 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.
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.
Pike,
Functional teams = Module
Two coordinators = Owners
Others in the team = Peers
?
@emma_irwin @lshapiro Maybe you can provide some feedback about recognition and diversity to include 
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, mozilla.org 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.
1 Like
This is fantastic, great to see it live.
One things that is missing for me is the topic of communication. Not sure if it was out of scope?
Good flag. Maybe we should have this under “Organization and governance”?
Sure it could live there, or on it’s own. The important thing is the content. I am not sure what we can prescribe, but we can list the channels we use, give tips on usages, and give some case studies of what works with other communities.