Week 2 – Codes of Conduct, Consensus, and Trust in Open Source

This week’s materials reinforced the idea that open source projects are not sustained by code alone, but by shared norms and communication practices. While code enables collaboration, it is social agreements—such as Codes of Conduct and transparent decision-making processes—that determine whether a community can function and grow sustainably.

After reading the Code of Conduct for the Go Project and comparing it with shared templates such as the Contributor Covenant, I began to view Codes of Conduct less as legal documents and more as social agreements. They do not carry legal force, and violating them does not result in legal punishment. Instead, they represent a collective commitment by contributors who voluntarily follow shared expectations in order to improve the community.

The Go project’s Code of Conduct reflects the language’s broader engineering philosophy, which prioritizes clarity, professionalism, and collective responsibility over individual expression. Compared to the Contributor Covenant, Go’s document is more concise and less prescriptive. One clear difference is tone: the Contributor Covenant places stronger emphasis on inclusivity and explicit behavioral guarantees, while Go focuses more narrowly on professional conduct and respectful technical collaboration. This difference likely reflects Go’s mature governance model and long-established contributor culture, where expectations are already well understood.

Another difference lies in scope. The Contributor Covenant is designed as a general-purpose template applicable to many communities, whereas Go’s Code of Conduct is tailored to its specific ecosystem. This suggests that the Go project intentionally adapted the template to better match its scale, audience, and engineering-oriented values rather than adopting it verbatim.

Part 2: Comparing Go and Sugar Labs

I also reviewed the Sugar Labs Code of Conduct, which is located within the legal section of the project’s wiki. Compared to Go’s Code of Conduct, the Sugar Labs document places much stronger emphasis on safety, inclusivity, and mentorship. This reflects Sugar Labs’ educational mission and its focus on younger learners and community participation.

While the Go Code of Conduct assumes a high level of professional experience among contributors, the Sugar Labs document makes expectations more explicit and protective. It also appears to be more closely aligned with established templates such as the Contributor Covenant. These differences suggest that Codes of Conduct are shaped not only by abstract principles, but by the intended audience and purpose of the project itself.

Part 3: Arkworks and the Absence of a Code of Conduct

For the third part of this activity, I examined arkworks, an open source ecosystem of Rust libraries for cryptography and zero-knowledge proof systems (arkworks GitHub organization). After reviewing the project’s repositories and organizational documentation, I was unable to find a dedicated Code of Conduct or a reference to a standard template such as the Contributor Covenant.

This absence is notable but understandable. Arkworks is primarily a research-driven project, with contributors largely drawn from academic and cryptography research communities. In such environments, collaboration norms are often implicit rather than formally documented, and professional expectations are assumed rather than explicitly stated. However, as arkworks continues to grow and attract contributors beyond its original research-focused community, the lack of a clear Code of Conduct may create uncertainty for newcomers.

Compared to projects like Go or Sugar Labs, which serve broad and diverse contributor bases, arkworks operates in a more specialized domain. This likely explains why it has not adopted a formal Code of Conduct. That said, a lightweight and focused document could still be beneficial. A reasonable proposal would be for arkworks to adopt a simplified Code of Conduct inspired by the Contributor Covenant, emphasizing respectful technical discourse, clear attribution of contributions, and inclusive participation in discussions, without introducing unnecessary bureaucracy.

In this sense, the arkworks project highlights an important lesson from this week: Codes of Conduct are not primarily about enforcement, but about communication. Their role is to make implicit norms explicit, especially as communities evolve and expand.

Consensus, Transparency, and Everyday Practice

The presentation How to Drive Consensus and Transparency Within Open Source Communities connected these documents to real collaboration practices. Concepts such as active listening, documenting decisions, and seeking “rough consensus” emphasize that disagreement is a natural part of collaborative work. What matters is whether discussions remain open, respectful, and transparent.

Transparency helps prevent hidden decision-making and builds trust among contributors. In this sense, consensus-driven processes and Codes of Conduct work together: both aim to reduce power imbalances and ensure that contributors feel heard throughout the decision-making process.

Personal Reflection

This perspective made me reflect on a mistake I made in my Agile Development course. I once created a pull request and approved it myself, treating the review process as a formality rather than a meaningful checkpoint. While this did not violate any explicit rule, it went against the spirit of collaboration.

This experience showed me that collaborative norms only work when participants respect not just the written rules, but the intent behind them. Processes such as peer review exist not to slow development, but to create shared responsibility and trust within a team.

Conclusion

Overall, this week reinforced the idea that open source communities depend on more than technical skill. They are sustained by voluntary social agreements, transparent communication, and a shared commitment to respectful collaboration. Although Codes of Conduct may not be legally binding, their power lies in the fact that contributors choose to follow them in order to build communities that last. Understanding these norms early has reshaped how I approach collaboration, not only in open source projects, but in any team-based technical environment.

Written before or on February 1, 2026