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.