From: HiPhish <hiphish@posteo.de>
To: Jelle Licht <jlicht@fsfe.org>
Cc: guix-devel@gnu.org
Subject: Re: Promoting the GNU Kind Communication Guidelines?
Date: Wed, 31 Oct 2018 15:55:18 +0100 [thread overview]
Message-ID: <1947347.4XlFHsYOC1@aleksandar-ixtreme-m5740> (raw)
In-Reply-To: <87wopyi5wd.fsf@fsfe.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.
next prev parent reply other threads:[~2018-10-31 14:55 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-28 11:58 Promoting the GNU Kind Communication Guidelines? HiPhish
2018-10-28 12:33 ` Gábor Boskovits
2018-10-28 16:14 ` Alex Griffin
2018-10-28 20:55 ` Thorsten Wilms
2018-10-29 11:27 ` Alex Sassmannshausen
2018-10-29 17:00 ` Thorsten Wilms
2018-10-29 17:50 ` Ricardo Wurmus
2018-10-29 23:54 ` OF-TOPIC: " Tonton
2018-10-29 11:29 ` Alex Sassmannshausen
2018-10-29 8:23 ` Björn Höfling
2018-10-29 10:10 ` Thorsten Wilms
2018-10-29 11:13 ` Alex Sassmannshausen
2018-10-29 17:15 ` Thorsten Wilms
2018-10-29 17:43 ` Ricardo Wurmus
2018-10-29 20:44 ` Björn Höfling
2018-10-29 11:08 ` Alex Sassmannshausen
2018-10-29 18:50 ` HiPhish
2018-10-29 23:54 ` Tonton
2018-10-30 0:38 ` HiPhish
2018-10-30 5:13 ` Nils Gillmann
2018-10-31 9:27 ` Alex Sassmannshausen
2018-10-31 12:29 ` HiPhish
2018-10-31 12:46 ` Alex Sassmannshausen
2018-10-31 13:23 ` HiPhish
2018-10-31 14:14 ` Jelle Licht
2018-10-31 14:55 ` HiPhish
2018-10-31 15:41 ` Stop it. Formerly - " Pjotr Prins
2018-10-31 17:51 ` Leo Famulari
2018-11-01 14:40 ` Ludovic Courtès
2018-11-01 15:11 ` Alex Griffin
2018-11-02 2:04 ` Mark H Weaver
2018-11-04 9:15 ` Mark H Weaver
2018-11-04 14:30 ` HiPhish
2018-11-04 21:01 ` Thorsten Wilms
2018-11-06 12:55 ` Ludovic Courtès
2018-11-06 17:23 ` Marius Bakke
2018-11-06 17:41 ` HiPhish
2018-10-31 12:30 ` HiPhish
2018-10-31 13:48 ` Jelle Licht
2018-10-31 14:55 ` HiPhish [this message]
2018-10-31 17:17 ` Thorsten Wilms
2018-11-01 10:35 ` Mark H Weaver
2018-10-31 13:48 ` Thomas Danckaert
2018-10-31 14:06 ` Alex Griffin
2018-10-31 14:55 ` HiPhish
2018-10-31 16:41 ` Thorsten Wilms
2018-11-01 2:58 ` Mark H Weaver
2018-11-01 9:14 ` Mark H Weaver
2018-11-01 8:40 ` Steffen Schulz
2018-10-29 11:37 ` Promoting the GNU Kind Communication Guidelines? (-> convivenza) Nils Gillmann
2018-10-29 11:45 ` Nils Gillmann
2018-10-29 12:01 ` Alex Sassmannshausen
2018-10-29 12:48 ` Promoting the GNU Kind Communication Guidelines? Giovanni Biscuolo
[not found] ` <9066320.aHiQMI0tiE@aleksandar-ixtreme-m5740>
2018-10-29 18:49 ` HiPhish
-- strict thread matches above, loose matches on Subject: below --
2018-10-30 0:46 Alex Griffin
2018-10-30 2:09 ` Alex Griffin
2018-10-28 23:37 HiPhish
2018-10-23 11:15 Mathieu Lirzin
2018-10-23 13:38 ` Tobias Geerinckx-Rice
2018-10-23 14:39 ` Mathieu Lirzin
2018-10-24 1:06 ` Alex Griffin
2018-10-24 3:02 ` Jack Hill
2018-10-24 10:02 ` Ludovic Courtès
2018-10-24 14:21 ` Alex Griffin
2018-10-26 21:36 ` Tonton
2018-10-26 22:37 ` Alex Griffin
2018-10-28 18:42 ` Tonton
2018-10-28 19:50 ` Alex Griffin
2018-10-28 20:25 ` Alex Griffin
2018-10-28 21:12 ` Thorsten Wilms
2018-10-28 21:26 ` Alex Griffin
2018-10-29 8:59 ` Björn Höfling
2018-10-29 10:49 ` Thorsten Wilms
2018-10-29 13:43 ` Alex Griffin
2018-10-29 17:48 ` Christopher Lemmer Webber
2018-10-29 22:58 ` Tonton
2018-10-29 18:16 ` Cook, Malcolm
2018-10-24 10:23 ` Ludovic Courtès
2018-10-24 16:06 ` Mathieu Lirzin
2018-10-25 10:23 ` Ricardo Wurmus
2018-10-25 15:25 ` Mathieu Lirzin
2018-10-25 23:03 ` George Clemmer
2018-10-26 2:43 ` Gábor Boskovits
2018-10-26 21:25 ` Alex Griffin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1947347.4XlFHsYOC1@aleksandar-ixtreme-m5740 \
--to=hiphish@posteo.de \
--cc=guix-devel@gnu.org \
--cc=jlicht@fsfe.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).