Productive Welcoming vs Code of Conduct
Eventsourcing project does not have a Code of Conduct, for a reason. Not for political reasons (if you know me personally, you might be aware of my opinion on that end), but to focus on the things that I find indispensably valuable for open source projects and to try to eliminate the source of potential problems CoC is attempting to solve. Of course, no solution is perfect, but at least we get to choose the weapons!
The way I see it, many open source projects struggle to move forward efficiently because there is no simple and effective way to contribute to them. Sure, pull requests have been around for a good while now, but even though they do solve a problem of delivering your patches to the maintainers, they don’t guarantee much beyond that. Will your patch get merged? When? Will you have to go over and over to perfect it to maintainer’s liking? What release will it make into? When?
This doesn’t happen because some of the maintainers are somehow evil or forgetful. Oftentimes, it’s a lack of time, or different value judgment, or a sense of duty to only allow “good code” into the project and pure, unadulterated perfectionism.
Not knowing (or not caring about) maintainer’s part of the story forces our brains to make up micro-stories that explain the situation. Stories that are made up in a fraction of a second, subconciously. Not all of these stories are positive. Stories that lead to frustration. That’s at least one point in the timeline when emotions can burst and people will “suddenly” become impolite or hostile.
Most maintainers are, by default, dictators (a more positive term would be gatekeepers). Most of them are very well-intended. It is, however, a position of power. When power is well regulated and enforced, it is easier to form expectations and play along. When the power is unspecified and many decisions are made in private, it’s hard to know how to play the game.
There is a lot of talking about welcoming all kinds of people around Code of Conduct. In fact, some of the versions use language similar to this
…in the interest of fostering an open and welcoming community…
and then go ahead and specify the undesirable behaviours and resolution processes for handling those.
My thesis is that strong gatekeeping and unclear collaboration procedures are a big factor in the occurrence of those “unwanted” behavioural patterns. So, what if we tweak that?
In fact, we don’t even need to invent anything new. Thanks to Pieter Hintjens and the ZeroMQ community, we have some brilliant work in the form of C4 (Collective Code Construction Contract). A simple and clearly defined “protocol” for operating a programming project.
What I found particularly exciting about it is the focus on getting contributions in quickly, removing fruitless conversations, bike shedding and value judgement from the process of getting people involved. This removes a lot of potential frustration and makes people feel welcome.
This is what I personally want to focus on. Getting people in. Preventing (or delaying) high stakes conversations. Making people understand how things tick. Being open. Being productive.
