4 ms·
I am getting really exasperated, every time this topic comes up there are always some who presumes the worst of ... I do not know who but someone who just wants
by chx 7y ago
I am getting really exasperated, every time this topic comes up there are always some who presumes the worst of ... I do not know who but someone who just wants to use the CoC as a tool to censor and expell people. It doesn't work that way. It doesn't. It never did, it's not about that. It's about making everyone feel safe and welcome. I tried to explain and I feel you didn't read and just parrot the usual bro words. Did you read my blog posts?
Really, come now, I have grown up behind the Iron Curtain, do you think I don't know what censorship is?
- zozbot234 7y agoIt'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.
- chx 7y agoDid. you. read. my. blog. post. https://medium.com/@chx/a-note-from-an-open-source-lead-developer-who-got-banned-from-his-community-due-to-code-of-conduct-22d8f066ab9e https://medium.com/@chx/a-note-from-an-open-source-lead-deve... > 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.
- zozbot234 7y ago> Did. you. read. my. blog. post. 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.
- chx 7y ago> 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.
- zozbot234 7y agoYou 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.