Tag: code of conduct

The complex reality of adopting a meaningful code of conduct

A number of prominent, globally distributed open source projects are debating the adoption of a Code of Conduct: Ruby, PHP (rfc, discussion), WordPress. There are probably others. Additionally, thousands of smaller projects have adopted codes of conduct as have many conferences.

Why are some communities able to quickly and effortlessly adopt a code of conduct while others become mired in conflict and division whenever the topic arises?

In this post I explore what I see as the main reasons we experience conflict when talking about adopting codes of conduct in our communities:

  1. misalignment of perceived shared values
  2. the relative difficulty of facilitating organizational change
  3. lack of governance infrastructure and non-technical leadership

What I hope people take away from this post is a greater appreciation for the potential complexities of FOSS communities meaningfully adopting a code of conduct and some ideas for confronting these challenges constructively, including:

  1. closing the non-technical leadership gap in our communities
  2. embracing multiple viewpoints and integrating conflict productively
  3. employing compassion and unconditional positive regard whenever possible

Some Background

Why the current momentum around adopting CoCs?

Many FLOSS communities have been around for years, yet the push for codes of conduct is relatively recent, picking up steam about 5 years ago.

What is the reason for this momentum?

First, let’s examine what a code of conduct is for. The purpose of a code of conduct is to make explicit the agreed upon social norms of group interaction within the community. There are many ways to accomplish this, but generally a code of conduct should document:

  1. expected behavior;
  2. unacceptable (transgressive) behavior,
  3. a mechanism for reporting problematic conduct and grievances, and
  4. consequences for unacceptable behavior.

All communities already have an implicit set of social norms. This is important, so I’m going to repeat: All communities already have a set of norms that govern group interactions, whether they are written or not. What a code of conduct does is make a subset of those norms explicit by putting them in writing where everyone can see them.

Over the last few years there has been a significant push for tech communities to adopt codes of conduct that make explicit a specific set of norms that strive to make these communities more equitable, welcoming, and safer for individuals from groups generally underrepresented in tech. This includes explicitly defining the destructive behavior that those from underrepresented groups are disproportionately subjected to and specifically labeling that behavior as unacceptable. The reason this is important is that the opposite standard of behavior generally remains the status quo across our communities. We may want to believe that harassment and other problematic behavior rooted in racism, classism, homophobia, sexism, transphobia, misogyny, ableism, etc., does not happen in our communities because we have never personally witnessed or been subject to it, but it happens nevertheless.

Making explicit a set of social norms that so clearly strives to re-balance power dynamics is one reason why some have such a vehement reaction against adopting a code of conduct. Those previously in the dominant social group will, on average, have to give up some of their power. Everyone will have to learn new ways of interacting. Change is scary.

Let’s not forget intersectionality

Before I continue, I want to make the intersectionality of my approach clear. Those who generally belong to the group with the dominant social power can suffer abuse and injustice too. Everyone in a community needs to abide by the community norms. Everyone is deserving of compassion and unconditional positive regard. And, many who, because of their relative privilege, are not accustomed to doing so will have to yield power, tolerate some loss, and stretch their emotional muscles further than they have generally been required to do. Some will have to do this while learning how to heal from their own experiences of abuse and injustice.

Two Personal Examples

Case Study 1: Citizen Code of Conduct

We wrote the Citizen Code of Conduct for use at Open Source Bridge in early 2011. We’ve modified it a few times since then and now use it for all Stumptown Syndicate events. Starting with text from a sample conference anti-harassment policy written by members of the Geek Feminism community, we modified and added text as needed to represent and embody the values of our community.  For example, for us, it was important to include not just a list of prohibitions, but also to set positive expectations for community interaction.

We’ve fielded a handful of reports or otherwise acted on our our code of conduct since we adopted it in 2011. None of them matched what I had imagined. Often they were more mundane yet more complicated to respond to than I had anticipated. Adopting our code of conduct did not stir up controversy, though at least one of our responses did. Generally the feedback we’ve received is that our code of conduct makes the conference more welcoming to underrepresented groups and this has been reflected in our changing demographics (more women, more PoC, more queer folks). A small number of people have expressed their discomfort or have stayed away entirely.

We’re a relatively small, contained community. In a given year, about 500-800 people are involved in Syndicate events and we operate almost exclusively in Portland. This has made adopting a code of conduct and responding to it a relatively manageable thing.

But we still have missing stairs. We have a mechanism in place for responding to code of conduct reports, but it’s almost entirely implicit. That works in the short-term, but it’s not scaleable and doesn’t ensure stability and adaptability over time. Communities need ways to transfer critical institutional operating knowledge as new leaders come aboard. Stumptown Syndicate just elected six new board members and Open Source Bridge is looking for new co-chairs, so we’re figuring out how to do this right now.

Another thing that made adopting and responsibly using a code of conduct possible was the reason Stumptown Syndicate was founded in the first place. We created Stumptown to be a trusted holding institution for the open source projects we cared most about. From the beginning we were about providing important governance and other structures that help ensure the long-term health of open source communities.

Case Study 2: Mozilla Participation Guidelines

In late 2012, Mozilla adopted their Participation Guidelines after a months-long and highly contentious process that was kicked off by the Planet Mozilla controversy. I was heavily invested in seeing Mozilla adopt a code of conduct. This cost me a lot emotionally — I got a threat from a co-worker (still employed by Mozilla and now a manager) as well as an anonymous death threat. Looking back it almost certainly burned a good deal of my social capital, too.

I suppose all that would have been worth it if I could say now with confidence that the Participation Guidelines have been useful for improving community interactions and improving diversity and inclusion.

But I can’t. (I would love to hear from you if they’ve been useful to you.)

For the most part, the weird, uncomfortable, blocking, and transgressive behavior I encountered while involved with Mozilla wasn’t (and still isn’t) addressed clearly by the Participation Guidelines. And in the few cases where you’d think the Participation Guidelines would be helpful, they weren’t. One involved a co-worker and was addressed via our employee anti-harassment/discrimination policy through HR channels (to a less than satisfactory end, but that’s another story). The others were from anonymous sources and thus weren’t easily actionable.

What are actionable events according to Mozilla’s participation guidelines are by no means clear to me. What are “exclusionary practices” in this context? The guidelines say

“Intentional efforts to exclude people from Mozilla activities are not acceptable and will be dealt with appropriately.”

But “intentional efforts” aren’t defined or exemplified.

And then the guidelines includes this bit, which to me signals a fundamental misunderstanding of how institutional oppression manifests in individual behavior:

“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.”

It’s not hard for some of us to imagine how others can unintentionally make spaces unwelcoming because it happens all the time.

Most people who engage in behavior that makes others uncomfortable or otherwise transgresses a social norm do not do so intentionally. And these are the people who benefit most from explicit norm setting and compassionate intervention. The group that engages in transgressive behavior intentionally is much smaller and does so for a varied, complex set of reasons, some of which is more easily addressed by community governance than others.

If the participation guidelines are getting invoked more than I realize, I wonder, by what mechanism are issues being resolved?

Early on the guidelines mention “groups for escalation and dispute resolution” but what are these groups? Later on, the guidelines instruct you to do the following if you experience conflict, you’re to engage with:

  1. the person with whom you have conflict,
  2. other “trusted Mozillians,” or
  3. Conductors.

To my knowledge, Conductors is completely self-selected (no training,  qualifications,  vetting, or standard of conduct) and…mostly defunct. Defunct as in many of the people listed are no longer employees and may or may not even still be involved in Mozilla projects.

Furthermore, the values indicated by the Participation Guidelines conflict with my direct experience of the community and its capacities.

This line would seem to indicate Mozilla values differing perspectives and spending energy to surface and integrate these different perspectives:

“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.”

However, Mozilla seems to have no functional, consistent mechanism for doing this. Many times during my four years with Mozilla I saw people who voiced differing perspectives ignored or outright silenced. (Example: Those of us who calmly, clearly, and respectfully voiced concerns about migrating to Gmail were invisibly silenced — our managers were instructed privately to make us stop.)

This line would seem to indicate we value working through conflict respectfully:

“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.”

But we have no effective channels for resolving conflict so we vent publicly and in back-channels, or simply stew in silence.

And how does the value of “respect” as alluded to in Mozilla’s Participation Guidelines apply to the co-worker who proselytizes to people in project spaces without their consent? Or the contributors of religious faith who worry that private demonstrations of their faith could be used to expel them from the project? Or the queer employees who wonder why their company remains silent while nearly every other tech company celebrates the SCOTUS ruling on gay marriage?

Who is getting use from this document? Did the protracted and divisive process the Mozilla community endured to get this document create any lasting, useful change? I don’t know what percentage of the community buys-in to the Participation Guidelines or even knows about them. Does the mere existence of the document make some more comfortable knowing they are there even if they’ve never invoked it?

A comparison to frame the issue

Is adopting a code of conduct like adopting a FOSS license?

Reinventing the wheel bugs me a lot. In tech, I think we waste a lot of resources and make a lot of unnecessary blunders not building upon and learning from what has come before. It’s why we’ve put effort into the Citizen Code of Conduct and making it easy for other communities to adapt and use. It’s why I’m glad others have engaged in similar work, like the Contributor Covenant, the Geek Feminism Wiki sample policy, and others.

Let’s look at a similar activity that should be familiar to a lot of FOSS contributors: licensing.

In the same way that adding a license to your project is “easy” — especially now that Github includes a drop-down selection of them during repository creation — it’s also easy to add a code of conduct.

But how many project owners who have added the GPL, or MIT, or any other open source license actually qualified, capable, and willing to enforce these licenses? And how do they determine, if they’re not well-versed in IP law, which license is really best for their project? Or what the long-term ramifications will be of their selection? Project leads already give a lot of their free time to open source development and community organizing; Do they really have more time to learn the skills required and then respond to licensing questions and concerns? Is that a fair request to make of our technical leaders?

Let’s say a project is five, ten, or fifteen years old by the time someone suggests adopting a license. How is consensus achieved across long-term contributors when some of them are very MIT-leaning and others are very-GPL leaning? Not just that, but when some folks already assumed everyone in the project was pro-GPL and are astounded the topic is even up for discussion.

This analogy has its limits, so I ask you not to over analyze it or take it too far. I don’t think it makes sense to have a third-party body doing code of conduct enforcement, for example. I think enforcement needs to stay within communities. Though I do think we need third-party experts providing training — and there’s a handful of us working on that now.

(Though if you do want to explore the idea of copyleft licensing and codes of conduct further, I suggest reading Sumana Harihareswara‘s excellent essay Codes of conduct and the trade-offs of copyleft.)

The licensing analogy demonstrates two main issues related to meaningful code of conduct adoption:

  1. The complexity of selecting and adopting a code of conduct especially in larger, already established and highly distributed projects/communities.
  2. That code of conduct response requires skills and resources many project leaders don’t already have.

Misalignment of shared values and the painful process of re-alignment

The role of shared values in conflict resolution.

Ultimately, a code of conduct is one part of a community’s conflict resolution strategy.

Making a plan for how to resolve conflict is one of the first things any community needs to do, long before any conflict arises. And it starts with reaching agreement and making explicit what your shared values are. Why? Because the values you agree as a community to prioritize in your work together need to drive decision-making about that work. Do we value unconstrained free expression of speech, or do we value inclusion of underrepresented groups? Do we value “free as in beer” or “free as in freedom”? Do we value shared public resources or do we value private ownership? Do we value adherence to using open source software, or do we value promoting the open web? In cases where are shared values fall somewhere in the middle of two extremes, where do we draw the line and which side is most important?

When communities are young, values alignment is usually implicit. This makes sense. A small number of folks get together to work on a project or advance a particular mission. Often times these folks already know each other. They may know intuitively and from past experience what their shared values are and so they don’t think about spending energy to make them explicit.

If the shared values that were implicit when a community forms are not made explicit as the community grows, you end up with divergent thinking about what the shared community values are. People who where there at the beginning have one thing in mind. People who joined at different points in time think another thing, based on what attracted them to the project and their own experience of interacting with the project/community. It’s really easy to assume the shared values of our FLOSS communities are what we want them to be. Because why else would we be there?

Misalignment of perceived shared values is at the heart of conflict

I see this misalignment of perceived shared values to be at the heart of numerous conflicts in open source communities. I see it pop up in every discussion about whether and which code of conduct to adopt. I saw it over and over again at Mozilla (migrating to Gmail, supporting EME, integrating Pocket, appointing Brendan as CEO, how community is included, etc.). I noticed it each time we struggled with a decision around Open Source Bridge / Stumptown Syndicate, which is why we spent a whole weekend last year debating what our shared principles are and then made them explicit and public.

Adding a code of conduct often requires the painful process of values re-alignment

So, one reason it is so much more complex to add a code of conduct to long-standing projects is because a code of conduct is an operating document born from a community’s shared values and in many of our large open source communities we do not have an agreed upon set of shared values. Adopting a code of conduct is a forcing function that brings that values misalignment out in to the open.

Values re-alignment requires organizational change capacity beyond what we have

To realign on values, a community needs to go through the process of agreeing what its shared values should be (not are — because people have been operating under mixed assumptions) and then put them in writing and make them public. This will inevitably require some change in the community. It’s likely that everyone will have to shift their position at least a bit. If not, some will need to leave the community. The larger and more complex the community, the longer this change process will take and the more facilitation it will require.

Organizational change is extremely difficult and most FOSS communities do not have the capacity and experience to manage the change. For the change to be navigated successfully, great care needs to be applied and community leaders, as well as everyone participating in the discussion really need to step up their game. There needs to be room for anger, for disagreement, for being weary of change, for being ravenously hungry for change. People have to be willing to change their minds. There need to be mechanisms for dealing with the inevitable flood of disruptive outsiders and blocking/sabotaging insiders. Leaders need to be able to hold the environment well enough to drive change but not let their communities implode. Everyone needs to understand and be patient with the reality that the process will take time. Months, not days or weeks.

Adopting a code of conduct in larger communities is not a technical problem with clear, templated solutions. Rather, it is an adaptive one that requires the community learn how to change itself.

The role of governance

Having a code of conduct is part of having a conflict resolution strategy, which is, in turn, essential to good governance.

What do I mean by governance? Governance includes everything about how a project carries out its work and engages with its community.

Key governance questions are:

  • how are decisions made and communicated?
  • how is conflict resolved?
  • how are conflicts of interest handled?
  • who are our leaders, and how are they selected, evaluated, and held accountable?
  • how is community membership decided?
  • how are tasks tracked and delegated?
  • what is our mission, vision and how are we planning to achieve that?
  • what are our values and are we living up to them?
  • what is our reputation within our own community and outside of it?
  • do ensure we have the resources we need to carry out our mission both in the short-term and the long-term?
  • how are we developing our community members and leaders?
  • are we serving our mission or just ourselves?
  • are we in compliance with with local laws? are we up to date on our taxes?
  • are we doing what our community needs us to do?
  • are we hearing all the feedback we need to be? from whom we need to hear it?

Having mechanisms that answer these questions in an explicit, transparent way is key for long-term sustainability and success.

In the same way that shared values are implicit when communities first form, so are the ways in which community members work together. And so must they be made explicit as a community grows. Many communities have not made these governance structures explicit. Or if they have, they are incomplete, out of date or simply don’t match how the community actually operates.

In some situations, generally when communities are small and relatively contained (e.g. to a geographic locality like a conference), it works to start with a code of conduct and make explicit the other governance structures as you go. But that becomes much more difficult the larger and more complex a community becomes.

In the same way that a large community will have misalignment in their perceived shared values, they will also have misalignment about how they think the community works together. Re-aligning is a process that takes time and care.

Does a community need to have all the above questions answered and documented before adopting a code of conduct?

No. But any community, especially large and highly distributed ones need to answer these governance-related questions when figuring out how to meaningfully adopt a code of conduct:

  • Who’s going to be responsible for holding the community accountable to the standards documented in the code of conduct?
  • How will those people be chosen, what training & resources will they need, and by what mechanism will they be held accountable?
  • How will code of conduct reports be collected? Will their resolution be communicated to the larger community? How?
  • What are the legal/privacy/etc. implications of our chosen method of reporting?
  • Have we selected a code of conduct that accurately reflects our community’s shared values, as they are actually practiced?
  • Have we selected a code of conduct we are actually willing and able to enforce?

I can’t stress the importance of the last two enough. No community should adopt a code of a conduct they think people want to see if it’s not a true representation of their community’s values and one they are willing and have the capacity to enforce. It’s immensely damaging for a community to have explicit policies that it doesn’t, for whatever reason, live out in practice. Integrity is essential for healthy community.

There’s also a danger is trying to make the perfect plan before acting. This is impossible. Sketch out a reasonable starting policy, practice it for a while and work with your community to adapt as needed over time.

If you’re trying to adopt a code of conduct and members of your community seem overly focused on legalistic analysis or want to negotiate every conceivable yet hypothetical situation before moving forward, it’s a sign that trust in governance and leadership is low.

The role of non-technical leadership

Community leaders, both those with formal authority and those without it, are critical to a community’s ability to successfully navigate change. Those with power in a community need to be on board with the change required be willing to do the work otherwise meaningful change is very unlikely to happen.

It’s entirely possible some of the FOSS communities that we have so much invested in aren’t willing or able to go through the change we need of them in this moment. For our  well-being and to avoid burn out, it’s important we develop the wisdom to be able to identify when that’s the case so we use our energy to build alternative communities.

(I do think there are strategies for bringing leaders on-board when change is needed and they are reticent to productively engage. But discussion of them is out of scope for this post.)

Some strategies for making things better

Close the leadership gap in our FLOSS communities

By now it should be clear that we have a non-technical leadership gap in our FLOSS communities and it’s harming our ability to navigate change and thrive.

To close this gap we need to develop, recognize, support, and elevate non-technical leaders. Non-technical leaders need to be recognized as valuable experts in the same way we recognize technical leaders for their expertise.

Embrace multiple viewpoints and integrate conflict productively

We need to avoid denigrating and silencing those who are reticent of change or raise concerns over adopting a code of conduct. I’m not talking about folks who show up for the sole purpose of trolling, derailing, and abusing. Let’s not increase the damage those people inflict by casting everyone who’s not automatically on board as one of them.

Conflicting points of view are crucial tool for learning. Ronald A. Heifetz in Leadership Without Easy Answers says:

“the mix of values in a society provides multiple vantage points from which to view reality. Conflict and heterogeneity are resources for social learning. Although people may not come to share one another’s values, they may learn vital information that would ordinarily be lost to view without engaging the perspectives of those who challenge them”

Respond compassionately to people’s sense of loss brought about by change

Some may respond with concern or be against a code of conduct because of the loss of power and privilege it represents to them (whether they are conscious of this or not). While we may feel that these folks have long enjoyed what they did not rightfully earn and that a redistribution of power as might occur with a code of conduct is fair, just, and necessary, we still need to respond to their sense of loss with compassion, not derision. Some will never adjust to the changing world in which they live, but many are capable of doing so and will, but they need help doing so.

Good governance and leadership prevent abuses of power

There are a handful of folks (example) who keep playing the dog whistle of impending fascism in response to their community’s proposal of adopting a code of conduct. This assertion simply has no merit and serves mostly to distract and derail. It also serves as a rallying call to those who feel disenfranchised by the changing social, political and economic environment.

Fascism and other abuses of power can happen with or without a code of conduct. Good governance, of which an explicit, written code of conduct is a part, is the antidote to abuses of power. In fact, I believe that keeping the ways your community works implicit and unwritten is more fertile ground for abuses of power than having written, communally available policies you actually follow.

Well-written codes of conduct are enforceable yet flexible enough to adapt to a community’s changing needs and circumstances over time. They are one mechanism by which conflicts can be resolved judiciously (as in, with good judgement, not related to a court of law) and consistently. Without a code of conduct or similar operating procedure, conflicts still arise but a community has no way to consistently approach or resolve them.

Some words of caution: A code of conduct won’t enable abuse of power where previously none was possible, but it might shift the the targets of that abuse or create unintended ones. It may also provide a false sense of security if there are not robust mechanisms in place to receive and respond fairly to reports. This is why a code of conduct needs to be backed up by skilled, ethical leadership and good governance infrastructure.

One last thought about compassion, unconditional positive regard, and emotional labor

Several times in this post I’ve stated we should show everyone compassion and unconditional positive regard.

When I say that, I’m not asking every individual and every given time to show compassion and unconditional positive regard for everyone else, including those who are or have engaged in abusive behavior or are members of social groups that have relatively greater power and privilege. Instead, what I ask is that people cultivate compassion and practice unconditional positive regard as they are able and willing.

Community is a shared burden, as a well as a shared resource. At any given time, some of us will be more capable of and willing to do certain things than others. Sometimes we need to concentrate on our own needs and healing.

Cultivating compassion, understanding, and unconditional positive regard is a communal activity, a communal responsibility. It’s how we’re going to move forward together towards a brighter future.

Death Threats in Open Source Are not Occurring in a Vacuum

Individuals who make death threats start with less egregious behavior and systematically test the boundaries of the communities in which they exist. When they get away with small violations, they often move on to larger ones. They watch what others are able to get away with, too. The pattern of behavior is common among abusers. If you’re an abuse survivor, you know this implicitly.

The open source community consistently condones the type of behavior that can escalate to death threats. The “free as in freedom” philosophy has created a haven for privileged individuals to act without accountability. Harassment, discrimination and exclusion of women, queer and trans people, racial minorities and other individuals from marginalized groups are commonplace. This is not okay. Not only is it morally wrong to exclude people in this manner, but communities thrive on diversity and stagnate without it. Open source is no different, and we have largely been failing to address this issue.

If you’re not actively working to make your community welcoming to a diverse set of individuals, you are part of the problem. If you are a white, straight cis man and you look around at your community and the majority of what you see are straight, white, cis men, then you are part of the problem. If your project or community does not have a code of conduct and you are not actively providing meaningful enforcement of those standards, then you are part of the problem. If you are not holding your technical leaders accountable for their behavior that is harming the community, then you are part of the problem.

We can no longer operate under the fantasy that maintaining healthy open source communities is solely a matter of technical skill or competence. As Matthew Garrett recently stated:

No matter how technically competent a community leader is, no matter how much code review they perform or how much mentorship they provide, if they’re expressing unacceptable social opinions then they’re diminishing the community. People I know and respect have left technical communities simply because people in positions of responsibility have engaged in this kind of behaviour without it causing them any problems.

Want to lessen the number of death threats that women (and others) in open source receive? Adopt a strong code of conduct and enforce it. Do not allow misogynist, sexist, racist, homophobic, etc. comments or behavior, no matter how trivial they feel to you. Don’t ask people like me to explain to you ad nauseam why a fellow community member saying “we don’t want you around” is a threat. Don’t argue when we say that a co-worker  who advocates against universal marriage is advocating legislative violence. Instead, hold those who make these statements accountable.

In other words, reducing and eliminating death threats in the open source community starts with being intolerant of microagressions.

Mozilla Now Has Guidelines for Community Participation

Mitchell Baker announced today on mozilla.governance that Community Participation Guidelines have been posted.

While I remain critical of the version that has been put forth (for reasons I don’t have time to articulate now, but will try to later), I recognize adoption of any standard for participation as a step in the right direction.

Thank you to all those involved in moving this forward and getting it published.

Note: If you haven’t been following this issue, read my previous posts on the subject here and here.

To the Anonymous Mozilla Member Making Threats on My Blog

I’m not going to publish any of your comments, so you might as well stop leaving them. Also, you’ve been reported to Mozilla leadership.

I will, however, share this bit with everyone here so they understand what kind of crap I and others receive simply for speaking out about the issues that are important to us.

mozilla@member.com writes (emphasis mine):

Or, to put it another way, we don’t want you two around, really. You’ve spent months creating drama and attacking anyone who disagrees with you in the most passive-aggressive “I’m a poor victim” fashion.

Feel free to find the door to more perfect folks who agree with your politics and allowed means of expression.

Still No Code of Conduct at Mozilla

It’s been nearly four months since events at Mozilla lead several of us to call for adoption of a code of conduct. And yet we do not have one.

I can’t tell if progress is stalled, or if we’re just not hearing of updates. The last post to mozilla.governance on the topic occurred in early May. What’s going on? Why does this appear to be a non-priority for our leadership?

Regardless of the reasons, four months is a long time to wait for something that was long overdue to begin with. It’s a long time to wait to have reassurance from my community that I, and others like me, are welcome, and that discriminatory behavior against us will not be tolerated.