Frameworks for Governance, Incentive and Consequence in FOSS
This is the fourth in a series of posts reporting findings from research into the state of D&I in Mozilla’s communities. The current state of our communities is a mix, when it comes to inclusivity: we can do better, and as with the others, this blog post is an effort to be transparent about what we’ve learned in working toward that goal.
Mobilizing the Community Participation Guidelines
In May 2017 after extensive community feedback we revised our guidelines to be much more specific, comprehensible, and actionable.
In community D&I research interviews, we asked people what they knew about Mozilla’s Community Participation Guidelines. A majority were not aware of the CPG or, we suspect, shared guesses based on what they knew about Code of Conducts generally. And while awareness is growing thanks to circulated feedback and learning opportunities, there remain many ‘myths to bust’ around our guidelines, who they apply to and why they are as much a toolkit for community health and empowerment as they are for consequence.
…this moment in time is a pivotal one for all open projects who have adopted a Code of Conduct: We’re at a critical stage in making inclusive open project governance effective, and understood — real.
And this is not only true for Mozilla. In recent conversations with other open project leaders, I’ve started to see that this moment in time is a pivotal one for all open projects that have adopted a Code of Conduct: We’re at a critical stage in making inclusive open project governance effective, and understood — real. While effectively enforcing our guidelines will at times feel uncomfortable, and even met with resistance, there are far more for whom empowerment, safety and inclusion will be celebrated and embraced.
Photo credit: florianric via Visual HuntI tried to imagine the necessary components in developing a framework for embedding our CPG in our community workflows and culture. (And as much as possible we need to collaborate with other open source communities, building-on and extending each other’s work.)
Education — Curated learning resources, online and in-person that deliver meaningful and personalized opportunities to interact with the guidelines, and ways to measure educational approaches to inclusion across differences including cultural and regional ones.
Culture & Advocacy — Often the first time people interact with a Code of Conduct it’s in response to something negative — the CPG needs champions and experiments in building trust, self-reflection, empowerment, psychological safety, and opportunity.
Designed Reporting & Resolution Processes — Well-designed resolution processes mean getting serious about building templates, resources, investigative methods, and decision making workflows. We’re starting to do just this testing with regional community conflicts. It also means building on the work of our peers in other open communities; and we’re starting to do that too.
Consultation and Consensus — As part of resolution process — understanding and engaging key stakeholders, and important perspectives will drive effective resolutions, and key health initiatives. Right now this is showing up in formation of conflict-specific working groups, but it should also leverage what we’ve learned from the past.
Development — Strengthening our guidelines by treating them as a living document, improving as we learn.
Standardizing Incentive
Mozilla communities are filled with opportunity — opportunity to learn, grow, innovate, build, collaborate and be the change the world needs. And this enthusiasm overflowed in interviews — even when gatekeeping, and other negative attributes of community health were present.
While feeling valued was important, our interviews highlighted the need for contributors to surface and curate their accomplishments in formats that can be validated by external sources as having real-world-value.
Despite positive sentiment, and optimism we heard a great deal of frustration (and some delivered tears) when people were asked to discuss elements of participatory design that made contributing feel valuable to them. Opportunity, recognition and resources were perceived to be largely dependent on staff and core contributors. Additionally, recognition itself varies wildly across the project to the omission or inflation of achievement and impact on the project. We heard that those best at being seen, are also the loudest and most consistent at seeking recognition — further proof that meritocracy doesn’t exist.
While feeling valued was important, our interviews highlighted the need for contributors to surface and curate their accomplishments in formats that can be validated by external sources as having real-world-value.
“Social connections are the only way volunteers progress: You are limited by what you know, and who you know, not by what you do” (community interview)
Emerging from this research was a sense that standards for recognition across the project would be incredibly valuable in combating variability, creating visions for success and surfacing the achievements. Minimally standards help people understand where they are going, and the potential of their success; most optimistically standards make contributing a portal for learning and achievement to rival formal education and mentorship programs. Success of diverse groups is almost certainly dependent on getting recognition right.
If you are involved in open source project governance, please reach out ! I would love to talk to you — to build a bridge between our work and yours ❤
Our next post in this series ‘Designing Inclusive Events’, will be published in the second week of August.
