This week, I was looking into a few code of conduct document to see how open source project teams try to regulate themselves. A code of conduct document ultimately provides a way to codify procedures and rules of being a contributor for a certain open source project (or even closed source projects, though this would most be shown in a different type of document or way). It ultimately prevents higher-level people from abusing their powers by giving them a framework in which they should moderate activity on their open source project, and gives everyone else clear guardrails in what is and is not appropriate activity to do online.

Some projects want to try and create a productive and nonproblematic project culture by creating a set of values that are less hard rules and more of proper etiquette when interacting with each other. For example, the Go language project has a code of conduct that explicitly starts with “Gopher Values” to provide some etiquette pointers to contributors of the Go project. These rules were seemingly made in reflection of past experiences for Googlers contributing and primarily maintaining the project (as this is a Google project after all and Google actually became a lot worldwide as they grew), as well as the fact that people don’t act the same when they do not see a physical representation of a person. In particular, the values include a point to be patient, acknowledging that people might come from different places around the world and different environments growing up, and as such, people may had developed a vernacular that might be understood in their local population, but not in the greater global community. This is something that gets pointed to a lot in How to Drive Consensus and Transparency Within Open Source Communities, as the speakers talk about how something that might be an expression for “let’s release this” or “let’s implement this” in American English might sound kind of violent.

One thing that is kind of interesting is that the Go language project code of conduct is actually based off of the Contributor Covenant v1.4. In my opinion, this code of conduct is a good starting off point for a new open source project, where the owner or leadership of the project might want some sort of ruling framework to go off of, but the enforcement component doesn’t really scale up well with a large project like the Go language. For one, it doesn’t really account for the overall culture an open source project (but then this is only because the Contributor Covenant is only meant as a good starting off point for a project to adapt the langrage of the Contributor Covenant). For one, the Contributor Covenant’s code of conduct suggests reporting unacceptable behavior an email for appropriate response and action. However, given the size of the Go language project, reusing this language shown in the Contributor Covenant would result in way too many issues that could otherwise be resolved by “address[ing] the behavior directly with those involved” (as the Go language code of conduct suggests). It also helps that the Go language is trying to cultivate a positive developer culture, so developers would more likely be able to detect negative behavior and be more incentivized to resolve the issue without getting higher management involved.

I also find it interesting that the Go code of conducts gives people who want to report an issue two different avenues to go off of in terms of reporting problematic behavior (one with the Go project stewards and one with Google, the primary company running the Go project), which might seem like a legal copy, but can also be useful in the event of a very abusive leadership team. I also find the fact that reports are not granted a response or an action (inclusive or) kind of interesting, as I am sure that troll reports and/or reports fueled by vendetta do happen, and the fact that ultimately, this code of conduct is more to build a positive work culture, and not just punish people (as shown by the mention that the people responsible for moderation will contact the accused to hear their side of the story before they take any action).

Another project that uses a good amount of language from the Contributor Covenant is the Eclipse Code of Conduct. However, it seems like it does take on some of the expanded language shown in the Go language code of conduct, including being specific actions that might be taken in response to a report. However, the Eclipse Code of Conduct goes as far as to say that nobody is safe from getting reported and that appropriate action will be taken to anyone (even leadership people). I wouldn’t be surprised if there was a relatively high profile incident that resulted in this clause getting included (as most rules I’ve seen have been implemented because some major incident occurred). This is kind of vindicated by the fact that there are specific Actions and No Retaliation sections, to address the fact that people who break rules will be punished accordingly (although all actions are not spelled out) and the fact that retaliations are not allowed (as well as laying out the expectation that if you were reported for something by someone, you should not hold further grudge against the person, or else you’ll risk getting reported again) respectively. The Our Standards section is also elaborated to also discuss about actively listening to each other and letting others contribute (which seems like they were adapted from the Go language code of conduct because these points do contribute to a more diverse set of ideas to implement, but written as rules), as well as more specific rules on what not to do (which seems to also be about distrust and accounting for the fact that this is the internet, after all (although some of these things that people shouldn’t do probably did happen before)).

I also took a look at the Sugar Labs’ code of conduct, and it felt kind of interesting in how it is adapted from a different code of conduct (namely, the Ubuntu Code of Conduct). This is probably because Sugar Labs’ primary open source project, Sugar (the desktop environment), is basically part of an OS (as Sugar would be run on top of an existing OS like Ubuntu). Although the main concepts between this code of conduct and the previously discussed code of conducts are similar, the Sugar Labs code of conduct deemphasizes mechanisms to resolve conflicts (as I would not be surprised if there are less people contributing to Sugar Labs’ projects) and emphasizes just forking their code, implementing features that others may disagree on implementing, getting others to test it, and potentially merging it back into main. I also do find the addition of two sections interesting: the When you are unsure, ask for help section and the Step considerately section. The only reason why I think these two sections would be added on top of the Ubuntu base code of conduct (and is missing from the other code of conducts we looked at) is because of how theres less people working on Sugar Labs’ projects, and as such, there might be both less eyeballs looking at a potential pull request draft (meaning that it’s less obvious when someone is struggling on a potential fix or new feature), and the fact that there’s probably less manhours available to figure out what code you’re trying to implement and how to follow through on your logic.

Another code of conduct I took a look at was the Microsoft Open Source Code of Conduct, which is used on most Microsoft projects (as it seems like there may had been other Microsoft open source projects that used a different code of conduct, before Microsoft realized how important open source was to their success and had to embrace it). This code of conduct says that they’ve used version 2 of the Contributor Covenant, however, the main code of conduct page is structured like the v1.4 version, mostly out of simplicity, and because the most important thing to get out of the code of conduct is to not be rude to each other, and how enforcement will be structured, similar to the other code of conducts that are based off of the Contributor Covenant v1.4. There is no such emphasis on culturally being a good member of a specific project like the Go project with how one should be a good Gopher, but this is because of how this code of conduct is being reused across many projects, so it doesn’t really make sense to develop a culture for a project if it has to be forced into so many other projects. I also find it interesting that Microsoft will discuss about the process that happens to resolve an issue in slightly more detail and clarity on their code of conduct FAQ page, which is a good move to just standardize the procedures to resolving an issue across many Microsoft projects (issues that would not happen if a code of conduct was written for only one project). However, because of this same issue, the version 2 additions of the Contributor Covenant are seemingly missing, including the degrees of which moderators and community managers will deal with issues and when each punishment method is used.

Ultimately, I really like the idea of a code of conduct, but it is not an end all, be all for resolving issues or maintaining a good community. It is a good starting point to make sure people are not misbehaving or recklessly moderating and to maintain a good contributor culture, but it does not 100% account for the disorganizedness of open source projects, nor does it fully account for the fact that some conflict is good and productive. The How to Drive Consensus and Transparency Within Open Source Communities video does function as a good resource to fill some of these holes, as the presenters suggest some potential project frameworks to prevent people from overstepping on each other’s lanes and accidentally causing conflicts, as well as good methods to make a project more diverse and friendly to everyone (such as cycling between convenient project meeting times for major contributors as needed).