It's not about what's being presumed, but what the effects are, out there in the real world. The CoC's that people are finding highly problematic in practice (such as the so-called "Contributor's Covenant", a misnomer if there ever was one) are not being advocated as generic statements that "everyone [should] feel safe and welcome"; they're supposed to act as bright-line rulesets that everyone, both contributors and maintainers, should ultimately be bound by and actively enforce. For such a ruleset to be so transparently vulnerable to abuse as a "tool to censor and expell people" is a critical weakness, no matter if that abuse was originally predicted or not; no matter if it was intended or not.
Having NO "bright-line" CoC whatsoever is preferable by far to having one which makes a project utterly unmanageable in the face of bad actors. This is not rocket surgery; it's simply astounding to me that some people can simply fail to see these problems when they are so clearly apparent to everyone else.
> Having NO "bright-line" CoC whatsoever is preferable by far to having one which makes a project utterly unmanageable in the face of bad actors.
The only bad actors here are people spouting nonsense like this. It doesn't happen. Show me the open source project that because unmanageable because they enforced their CoC.
Exactly. You state that reporting a bug/potential feature, or issuing a pull request, are inherently "confrontational" processes, but this is far from the truth in well-managed projects. And to the extent that it has become so, it's precisely because of procedural roadblocks like CoC's. CoC's make it so project maintainers can no longer use effective moral suasion to require of all contributors to be less confrontational and keep professionalism and the goodness of the project as their shared, common goals.
Their hands are tied; they are now only allowed to act as enforcers of a legalistic "code" that focuses on punishing perceived discrimination against a laundry list of overtly-acknowledged ("protected") groups - even the perception of such outside project spaces! - but leaves literally everything else as a toxic free-for-all where the loudest and most obnoxious trolls win, and the maintainer's hard-won wisdom and judgment ultimately counts for nothing. And that's only the slightest of problems with the most common CoC's; other issues are far more serious.
>
Exactly. You state that reporting a bug/potential feature, or issuing a pull request, are inherently "confrontational" processes
Well, don't stop there, the exact quote is
> all these bug trackers, issue queues, mailing lists are inherently confrontational spaces. Someone consideres contributing, OK? They write a patch, and what happens? They need to compete at least for the attention of others .
> in well-managed projects.
Show me the well managed projects which are not short on reviewers.
You think projects like Linux are short on maintainers and reviewers? They even have multiple maintainers for the same pieces of code, each keeping their own, preferred version of the kernel "tree". And this is an inherently-scalable process, that only needs new, prospective sub-maintainers to demonstrate good judgment in "signing off" incoming patches. Many eyes making all bugs shallow, to user a rather well-known (and relevant!) turn of phrase.
If this thread didn't already include https://lwn.net/ml/linux-fsdevel/20200217001153.GE10776@drea... titled "FS Maintainers Don't Scale" ... from someone much, much more qualified to judge that topic than either of us unless of course you are also a kernel maintainer because the author of that email sure is.
http://sei.pku.edu.cn/~zhmh/linux.pdf is a scientific paper stating, among other things, "In summary, adding more maintainers to a file yields only a power of 1/2 increase in productivity, thus, four parallel maintainers are needed to double the overall output. This suggests limits to the
scalability that can be achieved by adding multiple maintainers to the same files."
Um, that article includes quotes stating that cautiously expanding commit rights to the submaintainer's tree can help solve this scalability problem? And the more recent email you quote says this about the underlying reason this sometimes fails (and the lead developer can't cope with incoming patch volume, thus tending to burn out in the process - this is the "can't scale" they're talking about):
"...they [others] don't want to do it because they are scared of making a mistake and being yelled at by Our Mighty Leaders. That is a result of the fact that a Linux Maintainer is seen as a _powerful position_ because of the _control and influence_ it gives that person. It's also treated like an exclusive club (e.g. invite-only conferences for Maintainers) ... How many people do you know who have voluntarily given up a Maintainer position because they really didn't want to do it or they thought someone else could do a better job?"
So I fail to see how contentiousness and being more confrontational than not is helping there. The linux-kernel developers are in fact doing a pretty good job of not yelling at the real newcomers (which is what most people calling for CoC's usually focus on) yet the newcomers' patches still go unreviewed. And fiddling with rules of conduct is supposed to change this for the better, how? The more you do that, the less maintainers will be inclined to renounce their formally-acknowledged influence over the project.
You are constantly moving the goalposts. I have tried to challenge your position of the Linux kernel not having enough maintainers stating the maintainer system is not as scalable as you say. I even found a scientific paper studying this.
You acknowledged nothing of this, rather singled out one email and spout nonsense:
>
So I fail to see how contentiousness and being more confrontational than not is helping there.
What the hell, everything I talked about up to now is being LESS confrontational.
This was my last reply, don't bother replying to me, I am not engaging further. This was a waste of my time.
Having NO "bright-line" CoC whatsoever is preferable by far to having one which makes a project utterly unmanageable in the face of bad actors. This is not rocket surgery; it's simply astounding to me that some people can simply fail to see these problems when they are so clearly apparent to everyone else.