Code of Conduct documents, such as this one for the Go Project, set standards for social interactions, accountability, and community-building that otherwise would not be well-defined. Given that such members of such an online community, as well as other projects’ communities, will inevitable come from different, varied cultures with different social norms, it’s beneficial to have clear definitions of what is okay and how to resolve conflict, even if these things might seem like common sense, given that this ‘common sense’ would depend on each community member’s respective upbringing. Additionally, not only does this help maintain a healthy and productive community for pre-existing members, but this also helps invite new contributors to the community by establishing a welcoming, professional, and respectful reputation regardless of your background.

The Go Project adapted the Contributor Covenant Code of Conduct, version 1.4, to make theirs. One major difference is that the Enforcement section in the Contributor Covenant’s document is replaced with a Conflict Resolution section in the Go Project’s. This conflict resolution section similarly provides a contact email to report bad behavior, but it does not explicitly state what action would be taken against a perpetrator, while the Contributor Covenant states that bad actors “may face temporary or permanent repercussions as determined by other members of the project’s leadership.” Additionally, the Go Project encourages direct communication between two parties in conflict to resolve issues. I’m not entirely sure why they wouldn’t state exactly what action they might take other than the fact that it might be decided on a case-by-case basis. I still think the possibilities should probably be stated, especially considering the large scale of the Go Project’s community. There must be overlap in how action is taken against different violations. Moreover, the second difference, that being the encouragement of direct, one-on-one conflict resolution, seems to be a reaction to the scale of the project as well; if every little conflict was reported, that contact email would probably be flooded with requests.

The Eclipse Foundation’s Code of Conduct document is also adapted from the same document as the Go Project’s. However, it is structured differently. In addition to keeping the Enforcement section instead of replacing it with a Conflict Resolution section, there are added sections titled “Responsibility”, “Investigation of Potential Code Violations”, “Actions”, “No Retaliation”, and “Amendments”. It can also be noted that the Go Project’s document has a summary at the end, while the Eclipse Foundation does not provide that. This difference in structure seemingly comes from the Eclipse Foundation stating how action against bad actors is enforced instead of just how to report it, who enforces the Code, how retaliating against raising behavioral concerns is also a violation of the Code, and, directly, that “The Eclipse Foundation Board of Directors may amend this Code from time to time and may vary the procedures it sets out where appropriate in a particular case.”

Sugar Labs’s Code of Conduct document is based on the Ubuntu Code of Conduct. Because of this, there are various differences between it and the Go Project’s Code. At a high level, Sugar Labs’s Code focuses less on specific behaviors to strive for and avoid, and instead it chooses to opt for broader behavioral goals stated in different section’s titles (e.g. “Be considerate”, “Be respectful”, “Be collaborative”), with the text in each section offering more rationale for the rule as opposed to exact guidance. Notably, there is no stated method for reporting violations of the Code.

The Arduino StackExchange’s Code of Conduct document is divided into six subsections: “Our expectations for users”, “Unacceptable Behavior”, “Reporting”, “Site Policies”, and “Usernames and profiles”, listed in order of appearance. Well, seven sections if you also count the introduction before the first subsection. There is no mention of it being adapted from another Code of Conduct document. This Code seems to mainly apply to StackExchange, particularly “Usernames and profiles”, but “Site Policies” states that it works “alongside individual site policies”, meaning that it applies to other Arduino online community spaces as well. It is more similar to the Contributor Covenant Code than the Ubuntu Code in that it very explicitly defines what behavior to strive for, what behavior to avoid, and how to go about reporting malicious behavior.

This presentation given by Jill Lovato and Trishan de Lanerolle also presents good points about how to behave in Open Source communities such as the ones discussed. One slide I found insightful was the one about lazy consensus/rough consensus. Finding perfect, exact consensus is not realistic a large amount of the time, and I think the model of lazy consensus, which is essentially just agreeing on a decision as long as nobody raises objections to it within a certain amount of time, is quite smart, because it avoids having to go one-by-one and approve something when approval can be assumed to save time. I also think it is smart to document decision-making processes during meetings and such so that the alternative options and the rationale behind each decision can be remembered and discussed as needed in the future.