I think in new projects from now on I'll start running
echo "Don't be a dickhead, or I'll block you from the repo until you stop." > CODE_OF_CONDUCT.md
Not needlessly aggressive, gets the point across, short, covers everything someone could do wrong, provides consequences and a pathway to reconciliation.
It doesn't communicate what you consider to be dickhead behavior, so it invites fear, uncertainty and doubt both in whether my behavior is okay, and in what behavior of other participants I can expect to be "protected" from.
Codifying all expected social norms among an arbitrarily diverse group of people in a concise but fully understandable form is impossible. Attempts to do so just leave loopholes, edge cases and personal interpretations the size of jumbo jets which will be abused. This doesn't try to do so and leaves it up to you to observe the social norms of the group. Like has been done by humans since the dawn of our species.
edit: A false sense of security if not actually security as the author of this article found out.
You don't need to codify all expected social norms because the CoC is applied by and for people, who can extrapolate to fill the gaps. You do need to give them a starting point, and since there is no obvious universal definition of "don't be a dickhead", you probably want to list some concrete examples.
If people are idiots about enforcing the CoC, I'm willing to bet they'd have been idiots about enforcing the "don't be a dickhead" rule too.
I'd prefer to make the implicitness explicit, in that case: "if the project owners consider your behavior overly assholish, you may be blocked from contributing, and the owners will add a notice to a page documenting the sanction and rationale". This makes it clear upfront that it's inherently and deliberately subjective.
Then people understand what the CoC is: the project owners just moderating the project as they see fit. This is basically what all open source projects have done since forever. If others read the public list of moderation actions and disagree with the project owners' enforcement behavior (it being too lax or too strict or otherwise unfair or wrong), they can choose not to participate.
Trying to codify every possible violation into a set of explicit rules, or, worse, trying to codify good behavior, just leads to this sort of "you technically violated this part here" bludgeoning.
> and the owners will add a notice to a page documenting the sanction and rationale
I mean, that's basically a CoC-by-example. I don't really disagree with that modulo some surmountable reservations about giving too much attention to either bad actors or victims. Where I think this falls short is that, when spinning up a new project, you'd start with a blank page, so people _don't_ have the opportunity to determine whether they disagree with your moderation style until enough bad things have actually happened. Why not carry over your learnings from previous projects?
>Where I think this falls short is that, when spinning up a new project, you'd start with a blank page, so people _don't_ have the opportunity to determine whether they disagree with your moderation style until enough bad things have actually happened. Why not carry over your learnings from previous projects?
If every single project on GitHub right now removed its CoC, how much would really change over the next month or two? The vast majority of people know what's generally acceptable or unacceptable, and the vast majority of open source project owners share that sensibility. There may be a rare case of a project owner who thinks saying "hi, it might be better to do [X]" is offensive, or a contributor who thinks it's okay to say "this code is fucking terrible, you're a moron", but unless you're dealing with Linus Torvalds or someone else really unusual, it's almost never a concern.
When contributing to a project with such a blank page, you run the risk of encountering that odd project owner who seems to diverge from almost everyone else in the community, but I think the risk is so low and the impact so minor that it's not worth worrying about it much. And if it's truly a concern for some reason, you can just click on the owners' other projects or Google their names/monikers to see if anything concerning comes up.
I definitely think project owners should moderate shitty behavior, and I think for other sorts of communities (like message boards) there might be stronger requirements for somewhat more explicit rules, and if a particular project for some reason has had more than one instance of behavior the owner finds unacceptable but contributors don't then it makes sense to explicitly clarify some things, but in general I don't really understand all of the bureaucracy surrounding this.
There's local consensus but it absolutely does differ between projects. I don't know what people feel particularly strongly about, or have particularly bad experiences with. I don't know how people want problems to be reported/addressed. I don't know whether to expect the community leaders' support when there are problems, or whether it'll be blamed on me for having the wrong values. All of these distract from trying to get technical work done. Writing things down is useful.
Even the "CoC experts" in the post say that trying to codify acceptable behavior is the wrong way to do it. You just end up with overly broad rules like "be nice" because there is no way to write a CoC that covers what is acceptable behavior of every person in attendance.
So like every other CoC, except with significantly less fear? (being branded a "dickhead" is something you can shrug off; being branded a bigot far less so).
I'd say it's more fear? If I don't get any hint as to what kind of behavior the individual maintainers consider dickheadish, I have to worry about that with every interaction. If you have a CoC with even very vague and subjective rules, I at least know what kind of stuff you care about and then at worst I can be extra careful around that.
(Sure, I can shrug off the judgement, but being blocked from their repo is still a hassle if it could have been avoided with better up-front communication.)
> I'd say it's more fear? If I don't get any hint as to what kind of behavior the individual maintainers consider dickheadish, I have to worry about that with every interaction. If you have a CoC with even very vague and subjective rules, I at least know what kind of stuff you care about and then at worst I can be extra careful around that.
But knowing what's in the CoC doesn't actually tell you what kind of stuff the maintainer cares about. The maintainers will still block you if they consider you dickheadish, they'll just find a reading of their CoC that lets them declare you a racist (or whatever) first.
The maintainer can write(/adopt) a CoC as a tool to make it easy for me to not be a dickhead. The effectiveness of that is gonna vary, communication is hard. Still better than nothing.
Did you think it was cool to be a dickhead when there wasn't an explicit no dickheads allowed rule?
I don't think I'd use the wtfcoc, but it's just being explicit that the owner of the repo can block you if desired, which some people need to have said.
Writing down behaviour rulebooks that resemble law, complete with tribunals or HR employee handbooks is like adopting big company policies for your small 3 person startup. It's a bad idea because it slows you down and is unnecessary because your project isn't at a size yet where normal social management techniques break down due to scale. The vast majority of projects don't need a statement-of-the-obvious CoC until it gets to a scale past dunbar's number IMO.
I don't need to see a person's behavior rulebook if I'm going to play D&D at a meetup, or jam on some music together or whatever. The vast majority of casual stuff like that doesn't need it and shouldn't need it. Neither does joe's casual github project either.