It’s been a year and a half since Code for DC first implemented a code of conduct, so I thought that it would make sense to revisit it and see whether it could be updated. In that time, many more examples of codes of conduct have popped up, meaning that there are a lot of great ideas to borrow.
This is an iterative process, and we hope to be constantly improving, even if there isn’t a pressing issue. As a Code for DC captain emeritus said: <blockquote class="twitter-tweet" lang="en"><p lang="en" dir="ltr">2/2I'm thinking if you haven't heard from a member about code of conduct problems, you probably just haven't been told about it #cfabrigade</p>— Leah Bannon (@leahbannon) October 11, 2014</blockquote>
The biggest decision to make was whether to propose updates to the existing document or to replace it by adopting another code of conduct. There are some great options out there, like the Contributor Covenant, 18F’s code of conduct, or one of the other codes used by large open-source communities. However, because Code for DC has aspects of a conference, an online community, and an open-source project all rolled into one, none quite fit and it seemed best to build on what we already had.
One of the biggest changes is the addition of an “Aspirations” section. In the previous version, only specific rules were set forth. However, a code of conduct is useful not just as a way to prevent bad behavior, but also as a way to encourage especially good behavior. At our meetups and on our site, we encourage people to familiarize themselves with the code of conduct, so stating these as goals helps to give newcomers an idea of the kind of environment we hope to create.
Many additional classes were added to the explicit list of protected attributes. In adding to the list, I tried to err on the side of including an attribute unless it seemed duplicative. In v1, I had been choosier due to some idea that a long list was undesirable or unenforceable. This was a silly idea. It costs Code for DC nothing to be more explicit, and it might make a big difference to somebody who is considering whether the group is welcoming. We want those people to feel welcome, and that’s what matters above all else. The 18F code was very useful as a resource for this.
The code didn’t mention online activity, which seemed like an oversight, especially considering the amount of time spent on GitHub and Slack. These venues are just as much a part of our community as the meetups, and therefore should be specifically included, as well. Additionally, the examples of what constitutes harassment were expanded. The Geek Feminism code was useful for this. I’m wary of longer lists, as they may give the idea that they are “complete” and therefore that loopholes might exist. As a result, I added language stating that we’ll give precedence to the viewpoint of the target of the behavior, if necessary.
Finally, the description of possible actions taken in response to violations was simplified. This section seemed overly legalistic, and the catch-all of “any other appropriate action” made it superfluous. In my opinion, the more important part of the code is placing the responsibility for resolving reports squarely on the organizers, and that is still clearly stated.
The pull request with all of the changes can be found on GitHub here.