Which is exactly why codes of conduct do so at length, rather than assuming everyone will agree on a "simple" definition.
> This is not a winnable battle. Some people find being told "no" to be oppressive and horrible.
They'll get over it or go somewhere else. That's not what codes of conduct are there for, and that's exactly why this issue came up in the first place: some people use a code of conduct as a weapon when they're told that their actions are not acceptable.
> Would you accept Linus Torvalds on your project? He's known for his technical ability, but also known for taking little to no crap and calling out said crap with extreme prejudice.
Sure, anyone is welcome, right up until the point where they make themselves unwelcome, at which point they don't get a free pass for it for any reason. Even the kernel community seems to be getting somewhat better in that regard, though sadly not nearly fast enough.
Note also that criticizing code is not criticizing people. See https://www.youtube.com/watch?v=_O2zgNfvsh0 for a great presentation on the various levels of awfulness that often appear in a project.
> If the answer is no: You clearly value social communication over Getting Shit Done®.
http://www.slideshare.net/dberkholz/assholes-are-killing-you...
One person can drive off many potential contributors, and a steady flow of contributors is often more critical to a project than any one person.
I could say the same thing of people who don't like the atmosphere on a given project. There are plenty of projects with plenty of different kinds of communities.
Sure, anyone is welcome, right up until the point where they make themselves unwelcome
Please answer the question as asked and in the spirit it was intended in.
One person can drive off many potential contributors
And one bad CoC that legitimizes certain kinds of bad behavior can do the same. The backlash speaks to the truth of that.
You keep linking that slideshow - not one of the claims made there are sourced or backed up. Considering one slide goes on about the importance of providing numbers, this is especially galling.
More of a general question: Is anyone aware of a FOSS project which was killed due to a lack of contributors brought on by the perceived negative atmosphere of the community?
And doing so means you're perpetuating the problem.
> There are plenty of projects with plenty of different kinds of communities.
And codes of conduct help create more projects with welcoming communities.
> Please answer the question as asked and in the spirit it was intended in.
I did. Contributions welcome; hateful behavior not. Doesn't matter who the contributor is, they'd be told their behavior was unwelcome, and removed if persistent.
> And one bad CoC that legitimizes certain kinds of bad behavior can do the same. The backlash speaks to the truth of that.
Every time I look at this supposed "backlash", I see piles of people I don't want anywhere near any project I care about. So it sounds like the CoC is doing its job.
> You keep linking that slideshow - not one of the claims made there are sourced or backed up.
There are myriad sources and firsthand accounts available if you look, and the numbers from that particular presentation are (to the best of my knowledge) based on a direct study.
> Is anyone aware of a FOSS project which was killed due to a lack of contributors brought on by the perceived negative atmosphere of the community?
Off the top of my head, glibc was forked to create eglibc largely because of the (now former) maintainer of glibc, and many distributions switched over to eglibc as their primary upstream. Shortly after that person was replaced as the maintainer of glibc, eglibc got merged back in and distros switched back to glibc as upstream. Many more cases where that came from.
What problem?
Why the double standard? Why is your CoC fine and dandy and mine is not? What of the people who don't want to waste time litigating sociology and who want to code? Why can they just "go away" as you say and people who want to muddy coding with other non-coding interests not?
My entire point was that there are plenty of communities that don't need this, and so far, you've not shown that the problem it sets out to solve actually exists outside of a few well-publicized outliers.
>I did. Contributions welcome; hateful behavior not.
So is Linus' behavior hateful or not, by your definition?
>There are myriad sources and firsthand accounts available if you look, and the numbers from that particular presentation are (to the best of my knowledge) based on a direct study.
Which study? There are many, many studies that detail the behavior in online communities (and given my recent courseload, I'm familiar with more of them than I'd like ^^). Which one were those numbers pulled from? Nobody knows, because the author didn't bother to include that data.. This is why cites are important.
Random example, if you want one likely to apply to an issue tracker: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b... Reporting a bug about fixing such an assumption will almost certainly involve some discussion about identity. And if you tell people to shut up because their concerns aren't technical, the bug won't get fixed, and the next bug like it won't even get reported because you've made it clear that you don't care.
Another example: submitting a patch to change "master/slave" terminology into "primary/replica".
Another example: submitting a patch to avoid assuming male pronouns in documentation, in an effort to not make the default assumption that the reader is male.
> So is Linus' behavior hateful or not
When he's creatively explaining how a piece of code is broken, there's nothing wrong with that. When he's telling people that they should have been "retroactively aborted", yes, that's hateful. As mentioned, I've seen a lot less of that lately.
> Which one were those numbers pulled from?
Life isn't Wikipedia; direct primary research is perfectly acceptable.
The same is thought across corporations: process (an equivalent for potential contributors) is valued over any single employee; corporations don't like to rely on a sole worker. And guess what? It doesn't work in favour of innovation or good craftsmanship.
It may be somewhat different in open source projects, as contributing is way easier and requires much less commitment than changing jobs (the nature of things can change in surprising ways as the numbers grow), but personally I doubt it.
Here's my personal litmus test: Would you accept Linus Torvalds on your project? He's known for his technical ability, but also known for taking little to no crap and calling out said crap with extreme prejudice.
If the answer is yes: You clearly value technical ability and Getting Shit Done® over all else.
If the answer is no: You clearly value social communication over Getting Shit Done®.
Neither of these options are completely right or completely wrong, but again, I lean towards the hacker mindset. Getting stuff done should be more important than not offending people, IMAO :)