Codes of Conduct

This is a plea. It seems we are stuck with So-called “Codes of Conduct” (CoC) in many projects now. So we better handle them with care, and I need a piece of text to refer to so I can give my stance toward them.

It seems CoCs stem from ancient times where they defined rules and responsibilities for parties, groups, or organizations. Some of these, like “The code of Hammurabi” is essentially laying out law. Others, like the “Five Pillars of Islam” or the 10 commendmants of Christianity define a more religious conduct of how believers should behave to be in tune with their faith. Even medieval knight chivalry can be defined as a code of conduct. As can the hippocratic oath taken by physicians and their assistants, or the Geneva convention. CoCs is a broadly defined space.

Recently, software projects have begun to adopt CoCs in order to define how they operate. Essentially, they lay out the “Rules of engagement” to be followed when you are to contribute to a software project. Of course, this is an additional set of rules on top of existing law, which aims to create a coherent project structure.

Go read Ashe Drydens 101+FAQ on the subject, first. The best way to get a grasp on a subject is to read, and Ashe is definitely one of the most eloquent and knowledgable on the subject, when it relates to either software or tech conferences in general. Also, I suggest reading up on the history of CoCs throughout the ages. Like lots of things, it is not entirely black and white. Some codes have historically been very important, like the hippocratic oath for instance; or the work of Hammurabi. Other codes have had a more dubious usefulness—all depending on the area in which they have been invoked. I can’t speak of the rules of Fight Club.

I do have some mixed feelings in regard to CoCs in the areas of conferences and software projects. On one hand, I don’t see the harm in adding CoCs to either conferences nor software projects. Most reasonable behaviour of human beings fall well inside the boundaries of most CoCs I’ve read. I have yet to see even a single CoC for which my normal operational behaviour would break out of the framing set up by the code. And that by one who loves to challenge existing structure. Also, logically, when projects or conferences grow in size, the risk of dealing with abnormal behaviour rises by means of standard statistics. And hence a need for a CoC can become more important since it provides leverage for which to handle an eventual (invetable!) troll in the community.

On the other hand, CoCs seems like they are a redundant because normal human behaviour already covers what they set out to solve. And for many projects, it looks like overkill to adopt a CoC. The power structures codes impose are vast and they require serious attention to detail when implementing them. Hence, they are not free in the sense you can just blindly slam a code onto your conference or project and then gently shake Tinker Bell over the code to make it fly. You have to babysit the CoC in order to enforce it. If a conference adopts a CoC blindly and yet does nothing to enforce it, we are worse off than having none at all.

One CoC I like is the “FreeBSD committers guide” which lays out the general rules for FreeBSD committers. It is nice because it deals with all aspects of the project. From the administrativia to the more “soft” parts of development where you engage in friendly social conversation with other human beings.

FreeBSD employs a mentor/mentee system wherein newcomers to the project have a senior person they can ask for guidance. This is tremendously useful in large projects, where navigating or getting traction can be hard. Having a mentor who can introduce you to people or can help you learn how to navigate the project is a very clever thing.

Also, FreeBSDs “Big list of rules” can be summed up as: respect other people. And that’s it. Of course, there is more description of how to behave, but the gist of the whole message is that you have to respect the views of others. And you have to think about how the project moves ahead while wasting as little energy as possible on petty arguments and flame wars. The code acknowledges human beings can get filled with anger, be fallable, mess things up, make mistakes and switch stances. But we usually communicate well with each other, luckily.

Code of Conduct as Licenses

Open Source Software is usually guided by the licenses we use to grant others the right to use the software. While you may not like the legalese of licenses, they serve the purpose of setting up some general rules (or code) about the use of the software you write. Licenses come in different forms: MIT, Apache, BSD-2-clause, GPL 3.0, AGPL, LGPL, Creative Commons and so forth. Licenses serve a number of nice features in order to make it easy to navigate the maze:

Licenses, once known to the developer, allows for quick and easy evaluation of a piece of software. Most developers have a set of “valid” licenses they accept. These are the licenses for which they are willing to contribute. Companies also use licenses to define the projects they are willing to incorporate into their own systems.
Licenses are versioned. So as the license gets updated, we can quickly understand the major changes in the license and what that means for us as developers.

The current state of Codes of Conduct, is as follows:

We have no structure for Codes of Conduct in the sense of defining a set of base codes and their versions.

I’m not the first one to identify this flaw, as it has already been identified by Ashe Dryden, by alluding to the principle of “Don’t Repeat Yourself” (usually called the DRY principle). I hereby call for some streamlining in the area by adopting a structured way of handling Codes of Conduct:

We avoid having to read through a Code for which we already know its wording. This saves tremendous time, which can then be channeled for better purposes.
Versions means we get to know exactly how a code evolves and what is added and removed from it. It allows us to use the power of “version control” and a direct handling of the revisions of a code. It protects against sudden alteration of a code which then is ignored by the majority of participants.
As a corollary, versioning also protects against a slippery slope of alterations ad nauseum. A change needs a purpose to warrant a new version of a license so we usually govern their change by including multiple changes in one version bump. This calls for self-reflection in the form of precise and better wording of the code and clearer boundaries of what the code will contain.
Developers will learn those codes for which they agree and those for which they do not. Like all codes, there may be some you don’t necessarily agree with or ascribe to. Example: I, as an atheist, reject most codes grounded in a religious belief —though I do accept some parts of them on a moral ground of justice. Other people may differ in viewpoint.
As a consequence, it will be easy to handle codes as we do software licenses. If a person rejects a specific code, they can choose not to engage with the project.
We move discussions of codes from projects to a higher level. Since changes to codes will be versioned, changes have to be vetted and we have to hear out more people when making changes. Codes will have a slower rate of change and they will be written more carefully. In addition, we can find the points on which we have differences in stance and proceed to create individual codes for these. This is—in my view—a good thing. We don’t need rampart changes of codes in each and every project. We need this discussion at a higher moral ground with carefully laid out decisions.

The point I’m trying to make is that the adoption of a specific CoC tells a lot about your project. In a conference code of conduct, we find:

Our conference is dedicated to providing a harassment-free conference experience for everyone, regardless of gender, age, sexual orientation, disability, physical appearance, body size, race, or religion (or lack thereof).

…which will be taken differently by different readers. Some will welcome the inclusivity of such a statement and feel safer because the given conference has taken a clear stance in securing its premises. Others will look at the statement as if the conference is a day care where 6 year old children have to be told how to behave by their nanny in a condescending manner. Others again will have absolutely no feelings toward such a statement, so it is by no means a dichotomy.

We will get the equivalent of the Beerware license version 42 as a code. But we will also get a sorely needed discussion of different kinds of codes. And some of these discussions have place in a larger setting than in a Node.js advisory board discussion on top of a pull request on github. Can it get any worse?

What you write in a CoC does have an effect on who your contributors will be. And it is okay that it does not please everybody. Human beings are different in their views. It would be fatal to think software projects or conferences would be otherwise.

Finally, where do I stand in all of this? It all depends on the codes of conduct that gets implemented for projects and conferences I care about. I would not like to see a day where I would have to avoid a software project because I could not accept the code the project has on a moral ground. But I do note that I have yet to see a CoC I disagree with to the extent for this to happen.

What I am more sceptical about is the implementation of a CoC. That is, where the wording is abused in order to drive out someone from a project not for the reason of a CoC violation, but because other parties dislike the person and uses the CoC as a blunt tool. Because that would be the entirely opposite situation than the one for which the CoC was implemented in the first place.