Mozilla Community Participation Guidelines
Version 1.0. Last updated: May 5, 2015
Community Participation Guidelines
The guidelines describe the type of community we are building. They work in conjunction with
- the Anti-Harassment/Discrimination Policy which sets out protections and obligations of Mozilla employees, and is crafted with specific jurisdictional legal definitions and requirements in mind.
- Mozilla groups for escalation and dispute resolution.
The Community Participation Guidelines cover our behaviour as members of the Mozilla Community, in Mozilla-related forums, mailing lists, wikis, web sites, IRC channels, bugs, events, public meetings or person to person Mozilla-related correspondence.
The Community Participation Guidelines have two parts -- an Inclusion and Diversity section, and a general section about how we hope to treat each others. Each is an important part of the community we’re building.
Inclusion and Diversity
The Mozilla Project welcomes and encourages participation by everyone. It doesn’t matter how you identify yourself or how others perceive you: we welcome you. We welcome contributions from everyone as long as they interact constructively with our community, including, but not limited to people of varied age, culture, ethnicity, gender, gender-identity, language, race, sexual orientation, geographical location and religious views.
Mozilla-based activities should be inclusive and should support such diversity.
Some Mozillians may identify with activities or organizations that do not support the same inclusion and diversity standards as Mozilla. When this is the case:
- (a) support for exclusionary practices must not be carried into Mozilla activities.
- (b) support for exclusionary practices in non-Mozilla activities should not be expressed in Mozilla spaces.
- (c) when if (a) and (b) are met, other Mozillians should treat this as a private matter, not a Mozilla issue.
Raising Issues Related to Inclusion and Diversity
If you believe you’re experiencing practices which don’t meet the Inclusion and Diversity policy, please contact Allison Banks who leads our Inclusion and Diversity Program - firstname.lastname@example.org. Allison can provide a range of resources, from a private consultation to other community resources, and of course cover the legal aspects the Mozilla organization should address.
Intentional efforts to exclude people from Mozilla activities are not acceptable and will be dealt with appropriately. It’s hard to imagine how one might unintentionally do this, but if this happens we will figure out how to make it not happen again. I suspect there will be some questions about when and if something moves from a private to a public matter, which we’ll have to sort out.
- Be respectful. We may not always agree, but disagreement is no excuse for poor manners. We will all experience some frustration now and then, but we don’t allow that frustration to turn into a personal attack. A community where people feel uncomfortable or threatened is not a productive one.
- Try to understand different perspectives. Our goal should not be to "win" every disagreement or argument. A more productive goal is to be open to ideas that make our own ideas better. "Winning" is when different perspectives make our work richer and stronger.
- Do not threaten violence.
- Empower others.
- Strive for excellence. Our products must be great and our communities must be healthy and vigorous. Being respectful does not mean papering over disagreements or accepting less than we can do.
- Don’t expect to agree with every decision.
Raising Issues Related To Interaction Style
Inevitably conflicts will arise. Sometimes we’ll differ about style, about what’s respectful. Sometimes attempts at humor will backfire. One approach could be to try to make Mozilla as strictly business-like and sterile in an attempt to avoid all issues. This doesn’t fit with Mozilla. If we become sterile we’ll have lost part of our essence. A community is a set of relationships and encompasses more than the interactions strictly required to ship software.
We are also likely to have some discussions about if and when criticism is respectful and when it’s not. We *must* be able to speak directly when we disagree and when we think we need to improve. We cannot sugar-coat hard truths. Doing so respectfully is hard, doing so when other don’t seem to be listening is harder, and hearing such comments when one is the recipient can be even harder still. We need to be honest and direct, as well as respectful. That takes work.
Here are some ways to handle conflicts
Direct Conversation. If you are comfortable having a direct talk with the other person, this is a good way to start.
Conversation with Other Trusted Mozillians. If you’re not comfortable having a direct conversation, identify one or more people you trust. It will be helpful to identify whether the conflict is because someone is flaming, or behaving in a troll like manner or just won’t listen? Has the person been expressing some frustration and is now escalating into an increasingly strident tone?
Engaging the Conductors Group. The Conductors group was formed to deal with difficult communications; and with helping people learn how to communicate in a more productive way. The conductors are a good place to ask for advice in how to raise a topic directly, and what sorts of other interventions may be possible and appropriate. You can contact the group, or any member of it. If you don’t know anyone in the group ask people you trust for a recommendation to someone in the group. Or you can talk to the module owner Stormy Peters. Stormy is the module owner because she has a lot of experience but also because of her discretion. If you don’t know any of the conductors then ask people you do know and trust for a recommendation, or start with Stormy. If you know a lot of the conductors but have reasons that make you uncomfortable with anyone in the Conductors group, then you have an issue for the Module Ownership peers. Once again you can contact the group or any particular member of it.