unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: HiPhish <hiphish@posteo.de>
Cc: guix-devel@gnu.org
Subject: Re: Promoting the GNU Kind Communication Guidelines?
Date: Thu, 01 Nov 2018 06:35:47 -0400	[thread overview]
Message-ID: <87va5hnkyp.fsf@netris.org> (raw)
In-Reply-To: <1947347.4XlFHsYOC1@aleksandar-ixtreme-m5740> (HiPhish's message of "Wed, 31 Oct 2018 15:55:18 +0100")

HiPhish <hiphish@posteo.de> writes:

> 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,

The CoC is not a legal document, and is not intended to be normative.

If it were law, I would agree with you that the vagueness would be quite
worrisome.  A vague law is dangerous because laws enable authorities to
make enforcement actions that they otherwise couldn't, and a vague law
can be abused.

The CoC is fundamentally different.  The key difference is that the CoC
does not grant any powers to the maintainers that they didn't already
have.  That's worth repeating.  The CoC makes *no* change to their
powers.

The function of the CoC is to document the policies that the maintainers
have chosen to enforce, for the sake of transparency.  Roughly the same
policies were enforced before we had a CoC, but they weren't documented.

Also, it's a mistake to expect a CoC to cover every possible case and
include all relevant factors.  It would be a fools errand to try.
Ultimately, every case will depend on the specific details, and on the
maintainers' best judgement.

> and 2) 
> requiring punishment without offering any chance of clearing things up.

It would depend on the details, but I see nothing in the CoC to justify
this claim.  On the contrary, our maintainers have shown themselves to
be quite explempary in their handling of conflicts without resort to
punishment, and I see no reason why that should change.  I have
confidence that they will continue to exercise their powers judiciously,
and only as a last resort after diplomatic efforts have been exhausted.

Do you have reason to believe otherwise?

      Mark

  parent reply	other threads:[~2018-11-01 10:36 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
2018-10-31 17:17             ` Thorsten Wilms
2018-11-01 10:35             ` Mark H Weaver [this message]
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=87va5hnkyp.fsf@netris.org \
    --to=mhw@netris.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 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).