How We’re Making Code of Conduct Enforcement Real — and Scaling it.
Interested in learning from other individuals, projects and organizations investing in diversity and inclusion in open source? Join our Mailing List.
In 2017 the Open Innovation team set goals envisioning Mozilla’s Community Participation Guidelines as a tool not only for consequence, but as a measure and strong influence of community health overall.
Through the lens of hundreds of contributors, to over two-hundred open projects represented in our D&I for Open Source survey, we further recognize the work of 2018 in FOSS is to make inclusive open governance effective, understood —and real.
If your project has a Code of Conduct/CPG, is it effectively enforced?
In this post I’ll share our current work (including links to resources) building a framework of processes, standards and best practices for response to Code of Conduct incident reports.
This post will not outline how to write a good Code of Conduct, there are plenty of resources for that. I am also not suggesting that process can trump culture issues.
“Our community has a watered down CoC, it’s not really enforced but everyone likes to say it is” — Anonymous response from FOSS contributor to D&I for Open Source Survey
I am suggesting that by getting response right culture will benfit — we can generate beacon signaling — inclusion matters here, you matter here.
“The Heart of Mozilla is People”
This is the first line of our Community Participation Guidelines — and an nudge to keep empathy at center when designing response processes. Who are you designing for? Who is impacted? What are their needs, expectations, dependencies, potential bias and limitations?
With these questions, and others in mind, we generated the following workflow with process milestones:
Note: If this is something you are interested in doing for your project — please reach out and I’ll share our Design Thinking for CoC Incident Response Workshop (which is currently in draft).
Discovery
Many contributors seek validation from community leaders they know and trust before considering an official process. — Mozilla D&I for Communities & Contributors Research 2017
If people don’t understand and trust the process, it’s very unlikely they will report at all. The Discovery Milestone is about invitation, it’s about ensuring communities can find information about where to report, who has access to that their information, expected timelines and communication.
Reporting & Triage
The Reporting, Triage Milestones might seem obvious, but within it, are important criteria for moving to investigation and acting on urgency where required. Our reporting form was designed to help us isolate and understand reports in short periods of time.
We‘ve designed an issue triage system, using a series of questions and tags to trigger actions. I also use a template to isolate each identified violation which I’ve found super helpful. I’m also working to create templates of communication — like this one .
Investigation
The Investigation Milestone varies with every report. Early on we recognized that if we were to generate actionable recommendations we needed to to first understand who was accountable for making that decision, who was impacted, and what consultation was needed to sign-off. We use this template to build RASCIs for decision making, and this has been one of the most successful pieces of our process so far.
Often, a working group generates a preliminary set of recommendations. The size of that group is purposely kept small — and only of key stakeholders; with consultation expanding and contracting as needed. Where cases are simpler a working group is replaced with a coordinator. In both cases to ensure quality outcomes, we’ve set the coordinators role as a facilitator of decision, and not a decision maker — which better empowers the process.
Recommendations
The Recommendations Milestone, in non-urgent cases is one of iteration and decision making. We’ve been using this Consequence Ladder, that describes both escalation of response and severity of violation. We’re constantly improving this.
Notify & Follow-Up
We’re building communication templates for each level of the consequence ladder to satisfy important goals in the Notify & Follow-up Milestones, for both reporter, and reported. Something we’re working on is timelines for response dependent on the type of report. This will be embedded in the triage process as well.
Additionally, these milestones include recognition that actionable safety plans exist for people in situations of risk are crucial. This is very case-dependent but we are working on standardizing some of those best practices to share soon.
Resolution
The final milestone ‘Resolution’ signals appropriately, that resolutions are only achieved when all actions of approved recommendations have been completed. That includes, in the case of bans — what we call a CPG Onboarding which is a requirement for reinstatement.
Some Things I’ve Learned
Aside from learning how to build effective processes, recognizing ongoing needs to improve from perspective of non-English speakers and investigative practice I’ve learned a few things. And these are only a few…
People prefer to report anonymously Our reporting form is setup to accommodate this. Maybe this will change as trust grows in the ecosystem, but it’s also a signal that we need to consider anonymous reporting in our workflows. It’s also led me to consider solutions like Callisto which looks for actionable trends in the names of those reported.
We Need to Make Room for Teaching & Learning — Intention vs. Impact is a common theme in conversations. Resolutions are not only about consequence, but helping people consider their impact on others.
Onboarding is Critical The onboarding process to reinstatement after a ban has been super important to review the the why of that decision, and to setup contributors for success in future.
Self-Care is Important There is so much good happening in communities, but often as someone on the front-lines of community health, it’s important to go for a walk, or whatever a mental-reboot might look like.
Building Standards & Best Practices Help us Scale — Each case is different, people are different, regions, history, seriousness — impact are different and to move faster, with greater confidence and ability. I hope sharing our templates, and processes (so far) are helpful to that end.
For more results of our Diversity in Open Source Survey, join our first D&I in Open Source Community Call on February 28th, 2018.
You can follow, and contribute to this work in our Diversity repo.
