At Mozilla, with over 400 staff in community-facing roles, and thousands of volunteer contributors across multiple projects: we believe that everyone deserves the right to work, contribute and convene with knowledge that their safety and well-being are at the forefront of how we operate and communicate as an organization.
In my 2017 research into the state of diversity and inclusion in open source, including qualitative interviews with over 90 community members, and a survey of over 204 open source projects, we found that while a majority of projects had adopted a code of conduct, nearly half (47%) of community members did not trust (or doubted) its enforcement. That number jumped to 67% for those in underrepresented groups.
For mission driven organizations like Mozilla, and others building open source into their product development workflows, I found a lack of cross-organizational strategy for enforcement. A strategy that considers the intertwined nature of open source, where staff and contributors regularly work together as teammates and colleagues.
It was clear, that the success of enforcement was dependent on the organizational capacity to respond as a whole, and not as sole responsibility of community managers. This blog post describes our journey to get there.
Why This Matters
Photo by Debby Hudson on Unsplash
Truly ‘open’ participation requires that everyone feel safe, supported, and empowered in their roles.
From an ‘organizational health perspective this is also critical to get right as there are unique risks associated with code of conduct enforcement in open collaboration:
- Safety – Physical/Sexual/Psychological for all involved.
- Privacy – Privacy, confidentiality, security of data related to reports.
- Legal – Failure to recognize applicable law, or follow required processes, resulting in potential legal liability. This includes the geographic region where reporter & reported individuals reside.
- Brand – Mishandling (or not handling) can create mistrust in organizations, and narratives beyond their ability to manage.
Where We Started (Staff)
I want to first acknowledge that across Mozilla’s many projects and communities, maintainers, and project leads were doing an excellent job of managing low to moderate risk cases, including ‘drive by’ trolling.
That said, our processes and program were immature. Many of those same staff found themselves without expertise, tools and lacking key partnerships required to manage escalations and high risk situations. This caused stress and perhaps placed an unfair burden on those people to solve complex problems in real time. Specifically gaps were:
Investigative & HR skill set – Investigation requires both a mindset, and set of tactics to ensure that all relevant information is considered, before making a decision. This and other skills, related to supporting employees, sits in the HR department.
Legal – Legal partnership for both product and employment issues are key to high risk cases (in any of the previously mentioned categories) and those which may involve staff – either as the reporter or the reported. The when and how for consulting legal wasn’t yet fully clear.
Incident Response – Incident response requires timing and a clear set of steps that ensures complex decisions like a project ban are executed in such a way that safety and privacy of all involved are at center. This includes access to expertise and tools that help keep people safe. There was no repeatable predictable, and visible process to plug into.
Centralized Data Tracking – There was no single, cohesive way to track HR, Legal and community violations of the CPG across the project. This means theoretically, that someone banned from the community could have potentially applied for a MOSS grant, fellowship or been invited to Mozilla’s bi-annual All Hands by another team – without that being readily flagged.
Where We Started (Community)
Photo by Nicola Fioravanti on Unsplash
“Community does not pay attention to CPG , people don’t feel it will do anything.” – 2017 Research into the state of diversity & inclusion in open source.
For those in our communities, 2017 research found little- to-no knowledge about how to report violations, and what to expect if they did. In situations perceived as urgent, contributors would look for help from multiple staff members they already had a rapport with, and/or affiliated community leadership groups like Mozilla Reps council. Those community leaders were often heroic in their endeavors to help, but again just lacked the same tools, processes and visibility into how the organization was set up to support them.
In open source more broadly, we have a long timeline of unaddressed toxic behavior, especially from those in roles of influence . It seems fair to hypothesize that the human and financial cost of unaddressed behavior is not unlike concerning numbers showing up in research about toxic work environments.
Where We Are Now
Photo by Patrick Hendry on Unsplash
While this work is never done, I can say with a lot of confidence that the program we’ve built is solid, both from the perspective of systematically addressing the majority of the gaps I’ve mentioned, and set up to continually improve.
Investments required to build this program were both practical, in that we required resources, and budget, but also of the intangible – and emotional commitment to stand shoulder-to-shoulder with people in difficult circumstances, and potentially endure the response of those of those for whom equality felt uncomfortable.
Over time, and as processes became more efficient, those investments have also been gradually reduced from two people, working full time, to only 25% of a full time employee’s time. Even with recent layoffs at Mozilla, these programs are now lean enough to continue as is.
The CPG Program for Enforcement
To date, we’ve triaged 282 reports, consulted on countless issues related to enforcement, and fully rolled out 19 complex full project bans among other decisions ranked according to levels on our consequence ladder . We’ve also ensured that over 873 of Mozilla’s Github repositories use our template, which directs to our processes.
Customers/Users 
Who uses this program? It might seem a bit odd to describe those who seek support in difficult situations as customers, or users but from the perspective of service design, thinking this way ensures we are designing with empathy, compassion and providing value for the journey of open source collaboration.
“I felt very supported by Mozilla’s CPG process when I was being harassed. It was clear who was involved in evaluating my case, and the consequences ladder helped jump-start a conversation about what steps would be taken to address the harassment. It also helped that the team listened to and honor my requests during the process.” – Mozilla staff member
“I am not sure how I would have handled this on my own. I am grateful that Mozilla provided support to manage and fix a CPG issues in my community” – Mozilla community member.
Obviously I cannot be specific to protect privacy of individuals involved, but I can group ‘users’ into three groups:
People – contributors, community leaders, community-facing staff, and their managers.
Mozilla Communities & Projects – it’s hard to think of an area that has not leveraged this program in some capacity including: Firefox, Developer Tools, SUMO, MDN, Fenix, Rust, Servo, Hubs, Addons, Firefox, Mozfest, All Hands, Mozilla Reps, Tech Speakers, Dev Rel, Reps, MOSS, L10N and regional communities are top of mind.
External Communities & Projects – because we’ve shared our work openly, we’ve seen adoption more broadly in the ecosystem including the Contributor’s Covenant ‘Enforcement Guidelines’.
Policy & Standards 
Answering: “How might we scale our processes, in a way that ensures quality, safety, stability, reproducibility and ultimately builds trust across the board (staff and communities)?”.
This includes continual improvement of the CPG itself. This year, after interviewing an expert on the topic of caste discrimination, and its potentially negative impact on open communities, we added caste as a protected group. This year, we’ve also translated the policy into 7 more languages for a total of 15. Finally, we added a How to Report page, including best practices for accepting a report, and ensuring compliance based on whether staff are reporting or the reporter. All changes are tracked here.
For the enforcement policy itself we have the following standards:
- A Decision making policy governs cases where contributors are involved – ensuring the right stakeholders are consulted, scope of that consultation is limited to protect privacy of those involved.
- Consequence ladder guides decision-making, and if required, provides guidance for escalation in cases of repeat violations.
- For rare cases where a ban is temporary, we have a policy to invite members back through our CPG onboarding.
- To roll out a decision across multiple systems, we’ve developed this project-wide process including communication templates.
To ensure unified understanding and visibility, we have the following supportive processes and tools:
- A Github standard for CODE_OF_CONDUCT.md file.
- A script for scanning the Mozilla’s Github organization for out-dated, or missing CODE_OF_CONDUCT files. This same script will open an issue and associate PR with the correct file.
- A Code of Conduct evaluator tool for Mozilla’s Open Source(MOSS) grant program to better evaluate the inclusion of applicant policies.
Internal Partnerships 
Answering: “How might we unite people, and teams with critical skills needed to respond efficiently and effectively (without that requiring a lot of formality)?”.
There were three categories of formal, and informal partnerships, internally:
Product Partnerships – those with accountability, and skill sets related to product implementation of standards and policies. Primarily this is legal’s product team, and those administering the Mozilla GitHub organization.
Safety Partnerships – those with specific skill sets, required in emergency situations. At Mozilla, this is Security Assurance, HR, Legal and Workplace Resources (WPR) .
Enforcement Partnerships – Specifically this means alignment between HR and legal on which actions belong to which team. That’s not to say, we always have the need for these, many smaller reports can easily be handled by the community team alone.
An example of how a case involving an employee as reporter, or reported is managed between departments.
We also have less formalized partnerships (more of an intention to work together) across events like All Hands, and in collaboration with other enforcement leaders at Mozilla like those managing high-volume issues in places like Bugzilla.
Working Groups 
Answering: “How can we convene representatives from different areas of the org, around specific problems?”
Centralized CPG Enforcement Data – Working Group
To mitigate risk identified a working group consisting of HR (for both Mozilla Corporation, and Mozilla Foundation), legal and the community team come together periodically to triage requests for things like MOSS grants, community leadership roles, and in-person invites to events (pre-COVID-19) reduced the potential for re-emergence of those with CPG violations risk in a number of areas.
Safety – Working Group
When Mozillians feel threatened (perceived or actual), we want to make sure there is an accountable team, with access and ability to trigger broader responses across the organization, based on risk. This started first as a mailing list of accountable for Security, Community, Workplaces Resources (WPR) and HR, this group now has Security as a DRI, ensuring prompt incident response.
Each of these working groups started as an experiment, each having demonstrated value, now has an accountable DRI (HR & Security Assurance respectively).
Education 
Answering: “How can we ensure an ongoing high standard of response, through knowledge sharing and training for contributors in roles of project leadership, and staff in community-facing roles(and their managers)?”
We created two courses:
These are not intended to make people ‘enforcement experts’. Instead, curriculum covers, at a high level (think ‘first aid’ for enforcement!), those topics critical to mitigating risk, and keeping people safe.
98% of the 501 staff who have completed this course said they understood how it applied to their role, and valued the experience.
Central to content is this triage process, for quick decision making, and escalation if needed.
CPG Triage Infographic
Last (but not least), these courses encourage learners to prioritize self-care , with available resources, and clear organizational support for doing so.
Supporting Systems 
As part of our design and implementation we also found a need for systems to further our program’s effectiveness. Those are:
Reporting Tool: We needed a way to effectively and consistently accept, and document reports. We decided to use a third party system that allowed Mozilla to create records directly and allowed contributors/community members to personally submit reports in the same tool. This helped with making sure that we had one authorized system rather than a smattering of notes and documents being kept in an unstructured way. It also allows people to report in their own language.
Learning Management System (LMS): No program is effective without meaningful training. To support, we engaged with a third party tool that allowed us to create content that was easy to digest, but also provides assessment opportunities (quizzes) and ability to track course completion.
Finally…
Photo by Courtney Hedger on Unsplash
This, often invisible work of safety, is critical if open source is to reach it’s full potential. I want to thank, the many, many people who cared, advocated and contributed to this work and those that trusted us to help.
If you have any questions about this program, including how to leverage our open resources, please do reach out via our Github repository, or Discourse.
___________________________________________________
NOTE: We determined Community-facing roles as those with ‘Community Manager’ in their title and:
- Engineers, designers, and others working regularly with contributors on platforms like Mercurial, Bugzilla and Github.
- Anyone organizing, speaking or hosting events on behalf of Mozilla.
- Those with jobs requiring social media interactions with external audiences including blogpost authorship.