all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jelle Licht <jlicht@fsfe.org>
To: HiPhish <hiphish@posteo.de>
Cc: guix-devel@gnu.org
Subject: Re: Promoting the GNU Kind Communication Guidelines?
Date: Wed, 31 Oct 2018 14:48:18 +0100	[thread overview]
Message-ID: <87wopyi5wd.fsf@fsfe.org> (raw)
In-Reply-To: <1605080.KxgDGXkh13@aleksandar-ixtreme-m5740>


Hello,

HiPhish <hiphish@posteo.de> writes:

> I am really trying to understand the other side here, so please help me out on

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 :).

> this one. Let's say you have two people for the sake of simplicity, we can
> call them Alice and Bob. Alice and Bob hate each other's guts, Alice is
> unwilling to work on the team if Bob stays on the team, but Bob is willing to
> work on the team regardless of Alice. Furthermore, Bob has already worthwhile
> contributions under his belt, whereas Alice has done nothing yet, but she
> might if Bob were to be remove.
>
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.

> And your choice would be to remove Bob from the team. Am I correct so far?

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.


> What sense does it make to remove someone who 1) has already a proven track-
> record and 2) has shown that he is willing to control his emotions to
> focus on

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 task, all in the hopes that 3) the other person might perhaps fill in the
> void and 4) already has show to let emotions override work duty, and 5) has a
> track-record of wanting people remove from the project?

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.

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.

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.

>
> Please explain to me how kicking Bob out of the team is supposed to improve
> the project. I am really trying hard to wrap my head around the issue, but
> this logic is entirely alien to me. Wouldn't it make more sense to just tell
> people to keep any personal grudges out of the workplace and carry on? It is
> not that the project management is preventing Alice from joining, she refuses
> out of her own volition.

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.

Kind regards,

Jelle

  reply	other threads:[~2018-10-31 13:48 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 [this message]
2018-10-31 14:55           ` HiPhish
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wopyi5wd.fsf@fsfe.org \
    --to=jlicht@fsfe.org \
    --cc=guix-devel@gnu.org \
    --cc=hiphish@posteo.de \
    /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 external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.