Post 247380 by oshwm@mastodon.social
 (DIR) More posts by oshwm@mastodon.social
 (DIR) Post #247321 by bob@soc.freedombone.net
       2018-09-27T08:17:40.070836Z
       
       0 likes, 1 repeats
       
       The question of CoCs is essentially one of whether communities can consciously practice self governance. I sometimes wonder whether if CoCs were renamed to "community constitution" whether a lot of the toddler tantrums would go away.
       
 (DIR) Post #247322 by cjd@mastodon.social
       2018-09-27T08:31:48Z
       
       0 likes, 0 repeats
       
       @bob If communities using these things prove to produce better software, they will necessarily proliferate across the space, though perhaps at a slow rate.Decision-conservatism is not necessarily bad, we need some people to continue doing things the old way in case the new way suddenly blows up due to some unexpected problem.IMO name game doesn't calm anyone who thinks at all critically, what would is a study on the projects which do use these constructs.
       
 (DIR) Post #247323 by wolf480pl@a.nom.pl
       2018-09-27T09:29:31.126791Z
       
       0 likes, 0 repeats
       
       @cjd @bob I think there are two kinds of pushbacks against CoCs:1. I read that CoC and I see 50 of ways it can be abused, and its spirit doesn't really fir the telos of the community. It doesn't reflect OUR values, the values that hold us together.2. I've seen bad CoCs, therefore all CoCs are bad.Changing he name would help against the 2nd. In the case of the 1st, it might make it easier to express objections, and to push for a better code.IMO if your document is significantly different from Contributor Covenant, and you try to better represent (often implicit) values of the existing community, then you'd better come up with a different name. However, trying to push Coraline's Covenant under a different name only makes you look more dishonest.
       
 (DIR) Post #247377 by bob@soc.freedombone.net
       2018-09-27T08:41:58.262676Z
       
       0 likes, 0 repeats
       
       @cjd Codes of conduct were never about software. They're about personal conduct. Something more like esprit de corps.
       
 (DIR) Post #247378 by cathal@sunbeam.city
       2018-09-27T08:47:38Z
       
       0 likes, 0 repeats
       
       @bob@cjdI'd concur: the Old Ways implicitly included "don't be a shithead" but it was never codified because social groups were small and insular (and homogenous) enough to self-regulate. Codifying "Don't be a shithead" isn't a breakaway from the Old Ways, it's a reaffirmation.
       
 (DIR) Post #247380 by oshwm@mastodon.social
       2018-09-27T08:53:40Z
       
       1 likes, 0 repeats
       
       @cathal@bob @cjdThe best answer to don't be a shithead is people who can defend themselves and others around them - once an ego takes a big enough bruising then the shitheads go elsewhere :)From birth we need to build strong people, mentally, emotionally and physically.
       
 (DIR) Post #247404 by cathal@sunbeam.city
       2018-09-27T09:02:20Z
       
       0 likes, 0 repeats
       
       @oshwm @bob @cjd I appreciate where you're coming from, but I see this as a commonplace fallacy. People who are resilient against emotional abuse are not necessarily better engineers or project managers. I'd be surprised to see a correlation there, in fact for community or project management I'd expect an inverse correlation. And without any data that controls for survivor bias (I've seen none?) it seems an irrational position to take.
       
 (DIR) Post #247405 by cjd@mastodon.social
       2018-09-27T09:06:50Z
       
       0 likes, 0 repeats
       
       @cathal @oshwm @bob Back to the second point I've been beating the drum about :)It would be a lot easier for the "honestly concerned" people to accept a coc if there was some supporting documentation about how it has worked in other communities, what works, what doesn't. Perhaps biggest problem w/ Linux community was lack of clear presentation...  (I understand there wasn't a whole lot of presentation, just Linus: "Ok everybody, now we're going to have a CoC")
       
 (DIR) Post #247406 by cathal@sunbeam.city
       2018-09-27T09:10:54Z
       
       0 likes, 0 repeats
       
       @cjd@oshwm @bobI do agree: With Rust as a prototype for example, "serious engineers" would be able to see that a CoC did not result in a community of soft engineers who can't get stuff done. And looking at their channels ome could see how it doesn't stifle productive discussion. Of course, a bad CoC can have bad outcomes, I'm sure there are communities where authoritarians used them poorly. Perhaps even Linux will suffer that way?
       
 (DIR) Post #247407 by cjd@mastodon.social
       2018-09-27T09:18:09Z
       
       1 likes, 0 repeats
       
       @cathal @oshwm @bob I understand that the concern is it will be used for politics... Of course politicians use whatever they can get their hands on... I think one of the reasons for BDFL communities is because it's cheaper to have a dictator and hold them to the implicit threat of a fork rather than pay the massive productivity cost of doing democratic politics in addition to the project itself.
       
 (DIR) Post #247673 by cjd@mastodon.social
       2018-09-27T09:33:48Z
       
       0 likes, 0 repeats
       
       @wolf480pl @bob Back to my first point, if CoCs make communities more inclusive, which attract more good developers & users, then all the activity will happen over on the CoC side and the anti-CoC side will atrophy.Seeing "new" projects (nodejs, ruby, rust) doing well enough with CoCs indicates that this probably will happen. #TINABut clearly the opposite is also true...
       
 (DIR) Post #247674 by wolf480pl@a.nom.pl
       2018-09-27T09:43:17.139031Z
       
       0 likes, 0 repeats
       
       @cjd @bob From my POV, a dangerous failure mode of Covenant is that project using it may be forced to accept poor quality patches because making people feel part of the community is more important than producing good code.Also, many good developers have poor social skill, and the Covenant excludes them.OTOH, there are better CoCs. Eg. PostgreSQL's one: https://www.postgresql.org/about/policies/coc/IMO it's important for a CoC to preserve the goal of the group, which, in case of an open-source project, is producing good code.Here's a good write-up about it:https://lkml.org/lkml/2018/9/23/212My guess is that extreme cases of CoC and anti-CoC projects will run into trouble, while those in the middle will do fine, whether or not their handling of abusive behaviour is based on a CoC or not.