Week 2 - Looking Over Different Code of Conduct Docs in Search of Best Community Practices

Part 1 - Go Project, The Contributor Covenant, and Eclipse

picture taken from https://dev.to/eichgi/golang-discussion-239l

The Go Project’s Code of Conduct provides a throgouh and well-polished structure for anyone who wishes to intercat with the Go community. Following a familiar format seen in many codes of conduct, the document is divided into subsections covering every aspect of communication. Most importantly, in my opinion, the code provides valuable resources (such as contact emails and links) for assistance when issues of inappropriate behavior arise.

I think it is tremendously crucial for every project, no matter how small or seemingly insignificant, to have a code of conduct (or an equivalent document) that is readily accessible. It is always a good idea to plan ahead and safe yourself time if issues within the community do occur!

Two differences between the Go Project and The Contributor Convenant code of conduct documents:

  • Under the “Enforcement” section for The Contributor Convenant, it stated that “All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances.”, while for Go Project it is stated that “We will investigate every complaint, but you may not receive a direct response. We will use our discretion in determining when and how to follow up on reported incidents, which may range from not taking action to permanent expulsion from the project and project-sponsored spaces.” I beleive such a difference in providing solutions/responses has to do with the scales of the projects: it would be physically exhausting and nearly impossible for the Go team to cover every single conflict out there due to the popularity and large usability of the Go Project.
  • Go Project provides a what seems to me one of the shortest summaries I have ever seen at the bottom of the page, while The Contributor Convenant doesn’t have one. This change was obvisouly included due to the existence of many other additions/changes that Go Project made to their own code of conduct when borrowing it from The Contributor Convenant, as can be judged by the length of the Go Project’s code of conduct.

Link to the code of conduct document for Eclipse

Eclipse’s code of conduct is different from Go’s because:

  • While both documents wish to foster respectful and inclusive communities, their different structures reflect the different organizational context and scope. For example, while both include a “Scope” section applicable to project spaces and public events (both online and offline), the Go document adds “This Code of Conduct also applies outside the project spaces when the Project Stewards have a reasonable belief that an individual’s behavior may have a negative impact on the project or its community.”, while Eclipse doesn’t provide such further details.
  • Different communities evolve their codes of conduct based on their history, the nature of their interactions, and the specific challenges they face. Notice that the Eclipse document is marked as Version 2.0 (January 1, 2023), suggesting it has been updated or expanded to meet current needs, and also has an “Amendments” section listead at the bottom, while the Go code of conduct is based on a specific version of the Contributor Covenant, which may not have undergone as extensive a revision process in the same way.

Part 2 - Go Project VS Sugar Labs

Comparing Go’s code to Sugar Labs’ code:

  • “The Sugar Labs Code of Conduct is based on the Ubuntu Code of Conduct”, while Go Project’s code is “adapted from the Contributor Covenant, version 1.4.”.
  • A Spanish version of the Sugar Labs document is available.
  • Sugar Labs share in the code that they are licensed under the Creative Commons Attribution-Share Alike 3.0 license, while The Go code of conduct’s licensing isn’t explicitly mentioned.

Part 3 - Blender’s Code of Conduct

Link to Blender’s Code of Conduct

While it doesn’t explicitely state from where the code is based on, it looks more similar to the Sugar Labs document if comparing its structure. Compared to the codes discussed in Parts 1 and 2, I was struck by the brevity of Blender’s document. I assume this might indicate fewer internal conflicts within the community (although this assumption might be very wrong).

Blender definitely likes to keep it to the point, which is not a bad approach and may encourage more people to read the entire document. I particularly appreciate this statement: “We recognize that misunderstandings and mistakes can happen. We will only take actions after repeated intentional violations.”.

My Thoughts on “How to Drive Consensus and Transparency Within Open Source Communities” video

picture taken from https://www.madeforsuccess.com/articles/business/respect-find-out-what-it-means-to-me/

I enjoyed watching this video because it provided useful insights into professional and academic communication. It seemed primarily aimed at community leaders to help them foster a friendlier environment.

Specifically what I noted (appreciated):

  • Find the North Star expression is now invited into my vocabulary, along with the Bus Factor from the book.
  • Open Source Community is a meritocracy; just liked this word.
  • Using light verion of RACis within the communities.
  • Have a set of issues in the issue tracker meant specifically for the newcomers and provide easy access to it, I found this idea to be very refreshing and kind of unusual.
  • My Favorite: leverage “lazy consensus” and “rough consensus.” I resonate strongly with lazy consensus, as I frequently encounter it in my role as the Editor-in-Chief for BRIO, NYU Literary Journal.
  • Focusing on community goals by ensuring that conversations remain inclusive and free from personal agendas.
  • Redirecting energy when discussions digress.

Finally, I do want to note that the approaches in the video are very U.S.-centric. As the video itself points out, these methods might differ in other countries. For instance, during my internship with Hi! PARIS, a data center at Institute Polytechnique de Paris, I noticed that feedback was expected less frequently — once a week rather than daily. But this only proves the importance of one being self-aware when entering any type of community and respecting their way of douing things.

On that note, I find this video, The Culture Map: The Future of Management, to be a peculiar additon to the discussion of how to foster an inclusive and respectful community in the international setting.

Written before or on February 2, 2025