nukeador
(Rubén Martín [❌ taking a break from Mozilla])
1
Hello,
@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.
Pinging @buluma_michael, @ashickur_noor, and @Swarnava about this - gentlemen, you may have experience and knowledge to share or know others who could contribute.
Apart from the previous link, I (along with @Tripad) was also thinking of a mantra like ABCs for a member
2 Likes
nukeador
(Rubén Martín [❌ taking a break from Mozilla])
6
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.
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?
nukeador
(Rubén Martín [❌ taking a break from Mozilla])
13
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.
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
nukeador
(Rubén Martín [❌ taking a break from Mozilla])
19
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.
nukeador
(Rubén Martín [❌ taking a break from Mozilla])
20