Preface

Recently there has been a lot of commotion around code of conducts and if a user group/open-source project should implement them or not. This is not a post about that, we shall not be discussing the ethics or possible political impact this brings with it. We will however propose a starting point on how to implement them.

Please note that I am in no way an expert in this field, this blogpost is the result of endless talks with colleagues / friends and people I bugged on Slack (extra thanks to Paul Hallett and Jack Skinner).

So without further ado, I’ve made an easy 7 step program to follow along (this is the perfect time to fetch coffee or tea):

Steps

1. What is a CoC?

This is where the bulk of the drama comes from; most people are not really informed about what a Code of Conduct really is or start to overthink the concept. In essence it’s actually really simple:

A CoC or a code of conduct boils down to a list of rules. These rules can be as verbose or short as you like, as strict or as loose as you like. It’s just an outline of how people should behave when they attend your conference or contribute to your open-source project.

Lots of places have a code of conduct, like for example a bar, think “we don’t serve people without shoes”.

2. Do I need a CoC?

You might react with: “Well we’ve never had any problems before and I don’t see the point in having one”. Sure, don’t adopt one. The world isn’t going to end if you don’t adopt one.

On the other hand a CoC can have the advantage that everyone clearly knows what’s up. So if you turn into problems later down the line, you can easily refer to the rules.

Just make up your mind. As stated before, this post is not about whether or not you should implement one.

If you don’t want to implement one, you can skip to step 7.

3. Should I write one myself?

As always there is a lot of debate around this. You could if you want, but the general opinion is the same as on encryption, “Don’t invent your own”. Writing your own is pretty catchy (believe me, I’ve tried). There are lots of things to think about and frankly you probably want a CoC that’s clear about its contents.

If you want to write a CoC that states:

  • Be: awesome.
  • Don’t be: not awesome.

That’s all good, but know that you’ll be spending more of your time arguing about what passes as “Being awesome” then doing the thing you want to do. Holding conferences or writing code.

So if you want to save yourself some trouble and or time down the line, a good idea is to implement something that’s already thought out and proven to work.

4. What’s out there?

Luckily there are some easy ways to adopt CoCs out there, for example geekfeminism has a conference blueprint that can be used to roll your own: conferences CoC, if that one doesn’t fit your bill there are others out there, for example: Conference Code of Conduct.

If you rather check out the codes of conduct of famous open-source projects/conferences and fit them to your needs, here are a few:

And there are a lot more out there. (If I forgot a major one, please contact me, or leave a comment).

5. Pick one

So now comes the difficult part, choose one. This means:

  • Read them.
  • Take one that you think fits your project/conference best.
  • Possibly adapt it to your needs. (if you adapt it, make it clear you’ve done so)

Please note that I don’t want to favor one over the other, this is your choice here.

6. Implement it

Ok, you’ve chosen your CoC. Now is the moment you want to share it with the world. Make sure you clearly show that you have a CoC and that you expect people to follow it. People can’t follow a CoC if they don’t know it exists.

7. Communicate

You’ve chosen a CoC, or not, you’ve put it out there, we are done right?

Well no. Open-source is all about community. A project is never an island. There will be reactions on your decisions (if there aren’t you should ask for them), now it’s the time to discuss it with the community. Again, how you handle them is up to you, but it could be wise to be open to them (if you think they’re good) and be willing to adjust some parts.

These things are like code, they can always be improved upon.

Addendum

As you might have noticed, this is kind of a difficult topic and I am in no way an expert on this stuff. If you found some inaccuracies or want to discuss this further (keep it civil, please) you can post in the comment section below or find me on twitter.