How to implement a code of conduct

Posted Thu Jan 28 2016


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):


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.

Hey thanks for reading!

Hope you enjoyed this post. There is no comments section here, if you've ever seen the YouTube comments section you'll probably understand why. If you have any remarks or comments on this topic, you can find links below to social media discussions

Bird's eye view of a landscape

A bird's eye view on API development

Posted Sun Nov 15 2015

So you want to build a web API. You have to start somewhere, why not here

Continue reading
A chair and a washbin

The economics of clean code

Posted Thu Feb 06 2020

Clean code makes projects more comfortable to work with and improves shelf life. Its the antagonist of vile legacy codebases that are unmaintainable. Then why do we see it all the time?

Continue reading
Laptop with code

How we improved our PWA score by 53 points in 4 hours

Posted Sun Mar 12 2017

After a recent burst of inspiration at PHPUK Sam and I ran an experiment to see how much we could improve our company site in just 4 hours. Turns out it was far easier than we expected

Continue reading