Online communities often rely on an explicit set of rules, a.k.a. code of conduct, to regulate the behavior of the communitiy members. Open source software development community is of no exception. While intending to giving the community members a warm feeling, a code of conduct also acts as an enforcement that deal with any community member who does not obey it.

Code of conduct activity

Constitution and functionalities of the code of conduct

Integrating a code of conduct into an online project brings about various benefits. Firstly, a code of conduct helps regulates the behavior of the community members. Without such regulation, the community can be plunged into chaos in the long term and will not be productive any more. Secondly, a properly-written code of conduct can add to the affinity of the community. It would maintain a warm environment that prevents its members from leaving, and it is more likely to attract new members to the community with a guarantee of a friendly and welcoming environment. Based on the previous arguments, I believe that it would be beneficial for any open source project to have a code of conduct document.

Now let’s compare the code of conduct document for the Go project with the Contributor Covenant website from which it is adapted. There are two main differences between the two code of conduct documents. Firstly, the specified scope of the documents are different. The latter applies “within all project spaces” when an individual is “representing the project or its community in public spaces.” However, the former applies 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.” This difference is probably due to real cases where individual behaviors negatively impacted the Go project or community, and the change is to make up for that loophole. Secondly, the enforcement (or conflict resolution) sections are different. The latter guarantees that “all complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances,” but the former doesn’t. Instead, one “may not receive a direct response,” and the accused of the report will “be notified and provided with an opportunity to discuss it before any action is taken.” This change is less hard-line and more of human nature.

If we look at Eclipse, which is another open source project whose code of conduct here is inspired by the Contributor Covenant, we can see that it has some additional sections including Investigation of Potential Code Violations, Actions, No Retaliation, and Amendments. Moreover, it has specified much more standards for positive behaviors and unacceptable behaviors than the Go Project and the Contributor Covenant. This is probably because Eclipse is a much larger project and has a much more developed management team and community. Therefore, it needs more standards to organize the more complex community, and is able to provide more details on code violation due to a possibly larger numbers of real cases.

Another kind of constitution of the code of conduct

The code of conduct document for the Sugar Labs project is quite different from that of the Go project. Rather than listing which behaviors are unacceptable and talking about resolution to conflicts and mishehaviors, the code of conduct for the Sugar Labs project focuses elaborates on the positive aspects, guiding newcomers to attain the recommended attitude and behaviors, how to resolve confusion, and how to get started. This huge difference is because they are based on different code of conducts. The reference of the code of conduct document for the Sugar Labs is the Ubuntu Code of Conduct.

The code of conduct of my interested project

An open source project that I’m interested in is the Linux kernel project, with its code of conduct being adapted from the Contributor Covenant, the same code of conduct document that the Go project referred to. The Linux kernel project did not make any further modification from the Contributor Covenant.

My first experience working on an add-on project

I have to confess that I have never worked on an add-on project before, nor had I ever used Javascript :/ so the add-on project in this course is my first experience working on an add-on project and programming in Javascript. Following the instructions of the Mozilla Extensions tutorial is rather simple: I only need to copy the code and follow the instructions, and the examples are the most simple ones for writing an add-on for the browser. When it comes to creating an add-on with my group, difficulties came. First, it is hard to determine what kind of add-on we would like to do. Not knowing what I can modify on the brower and not knowing Javascript functionalities add to this difficulty. For instance, I initially thought of adding a dark theme for the Overleaf online LaTeX editor since I’ve being looking for such an extension for long but haven’t found any usable one, but not long after that did I find it too difficult to realize since it has something to do with LaTeX compilation. Up till now I haven’t decided what to do, but I will keep working on it and update my progress with the group in my next blog.

Summary

I have compared and analyzed various code of conduct documents of open source projects and explained its necessity and advantages. I have also briefly updated my progress of the add-on project of the course. Finally, thank you very much for your meticulous reading and hope you enjoy it.