While chatting in IRC with Eric Holscher tonight the topic of conversation wound its way toward positivity and the need to encourage it. I pointed out that my newest project, hyper, has as part of its contributor guidelines a section about respect. I wanted to talk briefly about why I wrote this, and why I think it’s important enough to warrant an explicit mention in contributor’s guides.
Before I do, I should note that while I wrote hyper’s guide in isolation, there are some other projects that have similar provisions. Of particular note are Pylons and Ubuntu, both of which are substantially larger than hyper is and have commensurately more substantial guidelines. These are good places to get inspiration for your own projects, though I feel that hyper’s has a simplicity about it that is helpful.
My personal projects are small: I’m not the kind of developer that releases a project and gets tons of contributors. hyper’s had several hugely important contributions from kind folks, but it remains a small project. Certainly it’s not at a size where I’ve had any kind of difficulty with contributors.
So why did I write that set of guidelines if it’s not something I think I need right now? Two reasons: culture, and security.
Let’s deal with culture first. Culture is difficult to define and harder still to quantify, and establishing it early is important. In open source, establishing the culture of a project is particularly critical: it defines the project in a way that nothing else does. Projects live and die based on their culture. The culture of a project affects what its priorities are and how successful it will ultimately be.
To that end, my highest priority for hyper is for it to be a welcoming project. I want it to be a space where people feel comfortable contributing. Open source contribution is always nerve-wracking, especially if you’ve never done it before. It’s hugely important to me that hyper be seen as a place where it is safe to volunteer your efforts: where you won’t be ridiculed or treated like an idiot. To truly give this impression it needs to be a core part of the culture of hyper.
The second part is, if anything, more important. Assuming hyper becomes successful (by no means guaranteed), at some stage someone will volunteer a contribution and, in doing so, behave in a manner that shows disrespect for someone else.
When this happens, it’s hugely useful to have a policy in place to which you can point. It’s important to have this policy in place before you need it. These policies exist for exactly one reason: to make it totally clear that certain kinds of behaviour are unacceptable. In addition to providing a good reference point (letting you say that “you should have known that was unacceptable, it’s in the contributor’s guide”), it protects the maintainers by depersonalising the response. When I say “Listen, you have to apologise for that or I’m going to refuse your contributions”, it’s helpful to be able to demonstrate that this is not a personal vendetta.
Having this policy gives me comfort. I know that I’ve taken steps to protect people who volunteer their time and effort, and I know that I’ve taken steps to ensure that toxic contributors can be handled gently, without making it personal. This is a great place to be, and I believe that it will improve the chances of hyper’s success. If you’re running a project, I strongly suggest you consider a similar clause.