There are certain levels of access, communication standards, and escalation procedures that must be followed to ensure healthy and productive collaboration all around.

NDA information for contributors

Access to certain internal resources and content within the Mozilla project may vary depending on a contributor’s Non-Disclosure Agreement (NDA) status. Understanding the difference between NDA and non-NDA access can help contributors navigate roles, expectations, and contribution opportunities more effectively.

• Non-NDA Contributors

Contributors without NDA status may have access to public content, repositories, and discussion spaces. They can participate in open reviews, content feedback, and non-sensitive projects.

• NDA-Bound Contributors

Contributors with NDA status may have access to draft materials, private repositories, internal tools, and discussions. This access is granted only after signing a Mozilla NDA and completing the required onboarding.

NDA access is valid for one year and will be subject to renewal annually. Contributors are expected to handle sensitive information responsibly, even within the community settings. Misuse of access or sharing internal materials outside of approved channels may result in suspension or removal of contributor privileges.

If you’re an NDA contributor, you can also request access to Mozilla’s Slack. You can learn more about the procedure here.

Effective communication

Mozilla values transparent, respectful, and timely communication. To help everyone stay aligned:

• Use the appropriate channels based on the team(s) you’re trying to reach for questions or feedback.
• Keep discussions and feedback focused on the work; avoid personal or unrelated topics.
• When providing feedback, be constructive; cite specific examples and suggest alternatives where possible.
• If you’re unsure where to post or whom to contact, reach out to our Community team before escalating further.

Our shared goal is to create and maintain an environment where every contributor and Mozilla staff member can collaborate effectively and safely.

Escalation channels

• Matrix

Contributors may escalate issues within our Matrix room. The SUMO Matrix channel is monitored by the Community team.

• Contributor forums

Contributors may escalate issues within our Contributor forums. This space is monitored by the Community team.

• SUMO KB Discussions

Contributors may not escalate issues within the KB Discussion section of our editing tools. Contributors can create new threads or comment within existing threads in the list to discuss SUMO article content or edits. But please be aware that this space is not actively monitored by either the Community or Content team at SUMO.

• Bugzilla

Contributors may escalate issues with Kitsune bugs or SUMO content requests within the existing Bugzilla tickets. This may include leaving a comment with the relevant information and/or tagging other contributors or Mozilla staff, if applicable. But remember, Bugzilla isn’t a chat space. Please make sure to follow Bugzilla Etiquette to maintain productive and respectful interactions. Bugzilla tickets may be monitored by different people depending on the topic. To understand who’s following a ticket, you can check the assignee or review the CC list.

• Slack

Contributors with Slack access may escalate issues through their approved account in the Mozilla workspace of Slack. The #sumo-team channel on Mozilla’s Slack is actively monitored by the Customer Experience team.

Contacting KB reviewers

If your revision has not been reviewed within the standard turnaround time and requires follow-up, you may contract the KB reviewers by sending an email to kb-reviewers@mozilla.com.

Non-permitted acts of escalation

To preserve mutual respect and community health, the following are not acceptable escalation behaviors:

• Re-opening closed Bugzilla tickets without new or relevant information to the original request, or in an attempt to influence or accelerate revision reviews
• Posting repeated or duplicate issues to pressure a decision
• Tagging or messaging multiple team members about the same concern when the contributor has been informed it is in the process of being addressed
• Sending harassing, inflammatory, or inappropriate messages to other contributors or Mozilla staff (publicly or privately)
• Circumventing established review or moderation processes

Violating these standards may result in restricted access, moderation, or removal from contributor access per Mozilla’s Community Participation Guidelines.