From mboxrd@z Thu Jan 1 00:00:00 1970 From: HiPhish Subject: Re: Promoting the GNU Kind Communication Guidelines? Date: Wed, 31 Oct 2018 15:55:18 +0100 Message-ID: <1947347.4XlFHsYOC1@aleksandar-ixtreme-m5740> References: <11169507.O9o76ZdvQC@aleksandar-ixtreme-m5740> <1605080.KxgDGXkh13@aleksandar-ixtreme-m5740> <87wopyi5wd.fsf@fsfe.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:45361) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHru8-0004xf-La for guix-devel@gnu.org; Wed, 31 Oct 2018 10:55:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHru4-0008Lr-Pv for guix-devel@gnu.org; Wed, 31 Oct 2018 10:55:30 -0400 Received: from mout01.posteo.de ([185.67.36.65]:40430) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gHru2-00086z-0p for guix-devel@gnu.org; Wed, 31 Oct 2018 10:55:26 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id CA2AB214B3 for ; Wed, 31 Oct 2018 15:55:22 +0100 (CET) In-Reply-To: <87wopyi5wd.fsf@fsfe.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Jelle Licht Cc: guix-devel@gnu.org On Wednesday, 31 October 2018 14:48:18 CET you wrote: > Without attributing malice to your statement here, I think it is > disingenuous to talk about "the other side". We are all part of > communities we interact with, there is no need for any additional > "othering" here :). Sure, but communities can still be split on issues, like which CoC to adopt :) > Again, while some people might be calling out for these cases to happen, > this is not what the discussion is about; _any_ document that describes > our norms and policies is intended to create a welcoming environment, > where anyone can decide to become an active member of the community. > > That the means through which this can happen, at its most extreme, > involves actively removing potentially harmful elements from the > community is in that sense a means to achieve these goals. This is fine by me, and I don't think anyone here agrees that we would need someone around who just sits in the mailing list and throws around insults. But where do you draw the line? The CC, which is the issue at hand, allows for abuse by 1) being vary vague on what constitutes a break of rules, and 2) requiring punishment without offering any chance of clearing things up. If the maintainers fail to punish they themselves are open for punishment. This is why I made that example of Alice and Bob where one party wants the other to be removed. > You are correct in the sense that what you state is not really false, > but at the same time also far removed from the actuality of any > realistic social setting. > > To me it seems that you only consider what one might call the > "worst-case", and I'd rather state that any community pledge/policy > document is first of all intended to prevent these situations from > arising in the first place, and give the often-powerless some semblance > of equal opportunity to become active participants, while still offering > a safety net if push comes to shove. And in my opinion the GKCG is perfectly adequate for this purpose without any of the potential of abuse. The GNU project was started in 1984, it's over 30 years old, and it has produced fantastic results without the need for overbearing policing. The communities have been fairly good at keeping everyone on track, even if someone might slip from time to time. There was no need for the type of harsh policing that the CC mandates. Note that the CC mandates the formation of an judicative-executive branch which will both judge and carry out punishments. If the maintainers are unwilling to do the work (which would not be surprising if they are busy maintaining the project) they will have to appoint people for this role. And my fear is that the people they put into position will be of the worst kind. > Again, if part of this "proven track-record" includes something that > could reasonably be seen as being in direct opposition of our norms as a > community, it would make sense to have an honest and direct dialogue in > order to resolve this situation. In extreme cases, it might still make > sense to exclude harmful elements of the community, even if they are > otherwise considered productive/effective/efficient. Nobody is above the > rules we set ourselves as a community. The CC does not provide room for honest and direct dialogue. > If we are going to play an open hand here, number 3 is literally the > goal of having this discussion in the first place: We want *anyone* to > feel like they could fill a perceived void in our community, if they so > choose. Let's say I promise you that I have fifty patches in the pipeline, but person X makes me feel uncomfortable. So you kick out person X and I submit 50 individual typo fixes in the manual and then never come back. Don't you think that is a net loss for the project? See, this is the issue I am afraid of can happen. I mean, if Bob starts calling Alice a "dumb bitch" over the mailing list, yeah that is another issue, but Alice wanting Bob removed from the project because he re-tweeted pictures of bikini modesl should be a no-go, even if the CC allows for it. Can we agree on this one? > Number 4 seems a very weird point to make. We all have emotions, and > some of us are more in touch with them then others, but somehow > insinuating that having emotions influence you is a bad thing is > confusing me. For me, most of the projects I undertake are labours of > love. Of course we have emotions, but we also need to learn to control them. Example: you are with a client and the client starts making unreasonable demands, you cannot just tell the client "if you know so much, then do your shit yourself", you have to maintain composure and explain why that demand is unreasonable within the technical of financial framework. Because if you have an outburst you will drag down the entire project. The same goes for contributors in a FLOSS project, you cannot just demand that everyone drops everything because someone upset you outside the project. > The rudest point I will make; number 5 comes across to me as an almost > hostile way of viewing any critique. If "wanting people removed from the > project" is done for legitimate reasons (after careful consideration), > this is IMHO a good thing. If this does not apply, the people should not > be removed in the first place, so I do not feel the problem for opening > each of our own behaviour up to criticism. The issue of the CC is that it does not define clearly what a good reason is, it does not require the issue to be disclosed (because that might compromise the anonymity clause) and if the maintainers fail to remove the accused they themselves can be removed. > I appreciate you writing up your thoughts in a concise and clear > manner. I would advise you to consider less of this a cold and reasoned > logic, and look more into the community building aspects. > > > * Collaboration is about community. > > * Communities are about people, so telling them to leave their "personal > grudges" at the door is wholly unreasonable. > > * Fostering welcoming, productive and even fun environments to do work > in is an active and on-going task. Just look at most of human history > to see what happens if this is not an actively sough-after goal. We might have different priorities. To me GNU is about creating a Free operating system, the community aspect is something that exists only because you need somehow to coordinate the work, manage issues and so on. GNU is not a reason for socialising for me, so the community is just something that's along for a ride. If all the work could be done by moneys on a typewriter I couldn't care less. For this reason the survival of the project is the most important to me. If we can have a good time along the way that's just an added bonus. The computer does not care about the community, so neither does the end user of our software. I view the CC as harmful to the project, which is why I support switching to the GKCG. Now don't understand me wrong, having a community that goes along is great, but if I was given a choice between sacrificing the Guix community or the Guix project, I would pick the community. Maybe this is because I came here primarily because of Guix and not because I wanted to make friends, so my views might be different from someone who came here because of the people and found Guix to be nice as well.