We endorse the
These guidelines describe the type of community we are building. They work in conjunction with the Anti-Harassment/Discrimination Policy [1] 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 behavior 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 called “Interaction Style” about how we treat each other. Each is an important part of the community we’re building.
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 (which extends to Mozilla-hosted events, even if not in our spaces). (c) if (a) and (b) are met, other Mozillians should treat this as a private matter, not a Mozilla issue.
If you believe you’re experiencing practices which don’t meet the terms outlined above, please contact [email protected] which reaches our VP of People, D&I Program Manager, and Employee Relations Specialist. They 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. We 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.
This is a more general section about how we treat each other. Each aspect is an important part of the community we’re building.
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 to speak. Strive for excellence. For our products to be great 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.
Inevitably, conflicts will arise. Sometimes we’ll differ about style or about what’s respectful. Sometimes attempts at humor will backfire. 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. If you need help with discussion, again, please contact [email protected].
Furthermore, regarding interaction between volunteer localizers, we adopt the following code:
Mozilla Italia is a community made by Mozilla’s volunteers. As such, we don’t ask you a professional commitment in our projects. Still, if you wish to join, we expect you to uphold a certain conduct while interacting with other people and with the project itself.
When you start contributing in a project, remember that, just like software, web pages and contents are a work in progress: they are often updated and their translation must also be maintained up to date. The big part of the work is to translate the project the first time, but the important part is to follow future updates of the project. Updates are usually small, but they require weekly checks for new or edited content. When a content lacks its translation, it is shown in English instead, thus compromising accessibility for non-English users. For this reason, it is very important that you keep following the updates of a project after the initial translation.
It is important to be coherent with the language used in previous localization of the same project (or of similar project) and there are different styles used, for example a formal registry in guides or documentation, a more friendly language in web pages.
When you translate new stuff, you must always check previous translations and make use of the same terminology and style.
The terminology used in other product must be respected.
For example, if you are translating a guide on how to use the Private browsing in Firefox, you have to use the standard term Navigazione anonima even if other translation choices are possible.
The use of a coherent terminology across projects is very important to achieve a solid experience for users of other languages. The job of reviewers is to give translators the list of tools and terminology resources, the job of translators is to read and make use of it during the translation process.
When participating to a collaborative project, you interact with other volunteers such as yourself. Be respectful of their time and don’t use inappropriate language or trash talking in messages. Proper language is important, we don’t demand that you write like Alessandro Manzoni in messages, but, please, try avoiding “SMS language” or abusing acronyms. Also, please don’t replace ch with k or similar abbreviations in Italian, it is an aberrant behaviour and makes messages difficult and annoying to read.
If reviewers share tips or suggest to change translation, try to follow advices. If you don’t agree, try to be propositive and offer alternative changes in a respectful discussion. Sometime suggestions are made according to previous translations and maintaining a coherent terminology across projects is very important. We realize reading pages over pages of documentation can be time consuming. However if a reviewer encourages you to read guidelines or instructions, please make the effort and go through it carefully before asking for help. Not wasting other people’s time over questions that have already been answered is a sign of consideration toward your fellow community members.
When you are engaged in a translation project, it is very important to provide a means of contact (email, forum account etc.) for us to get in touch with you. We realize that community members have sometimes very little time to spare for volunteer activities. It is important for our organization to know general availability of our team. Because of that we ask you to communicate if you’re going to be busy for an extended period and don’t wish to be contacted during that time. We don’t demand you to be always reachable, but we wish to know if we can count on you for a project in a specific range of time. Pages on Mozilla sites are assigned certain deadlines, and in order to meet them it is important to divide work among available members.
We think these are simply and logical rules to follow when collaborating in a project and we hope you agree with them.