From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-project+bounces-8929-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by finch.gentoo.org (Postfix) with ESMTPS id 93E22138334
	for <garchives@archives.gentoo.org>; Fri, 28 Jun 2019 10:32:59 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 810C6E0877;
	Fri, 28 Jun 2019 10:32:58 +0000 (UTC)
Received: from mail-pl1-f193.google.com (mail-pl1-f193.google.com [209.85.214.193])
	(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id 4AF60E086E
	for <gentoo-project@lists.gentoo.org>; Fri, 28 Jun 2019 10:32:58 +0000 (UTC)
Received: by mail-pl1-f193.google.com with SMTP id bh12so3011336plb.4
        for <gentoo-project@lists.gentoo.org>; Fri, 28 Jun 2019 03:32:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:mime-version:references:in-reply-to:from:date
         :message-id:subject:to:cc;
        bh=6qrAboIOzoHqsl2QNnjzMee0Vqad3YUn0koWqtJzev8=;
        b=oP9QAL+6sml7fK9z2zuwdpNz0U+T+QVMaX/xP+de584pqsIFsNrgMq8f3R3sTF6lzk
         olzxRFuCtJbN6n+vFD7RkODkRlhIR7VnOniVyLXz6aKXvvmGy4HKGyuf338HUXbKu6SN
         k57fNFQQJL5cOQ9ga5UhdpZIMyLdQoZs7FRapnJ0H2Dx/QoFdsl4AnFsRQEF+LtOK0le
         Jl/65xxcEhLPlA+ZhdJXwKcFjOIW4NmHzGXhHnrUACsMnfDZrrIAEXdgtVfnB5nWtMZB
         aDpbADwpgHY6qJOVETvjf/oplPZrtsE31kNlWgvniCNmpTHTTsUInO+I6DfrxRCoDOm5
         SufA==
X-Gm-Message-State: APjAAAXzko48DnTM4L1nwc0s46slndKp90AS7vY/YCmn6J8a37RiQoz/
	IbS5z9qgKttVhEct9fI1O6HFdc5BO6amHKFHKpI=
X-Google-Smtp-Source: APXvYqzdslDHA3uwwyJdfgeGo2dA3gNwC7sZRkrKKqHiHX2maWsWJ/PQQtOhSTPD48MYO7x+nZG36Mqh8YGQuQoCHrA=
X-Received: by 2002:a17:902:70c3:: with SMTP id l3mr10710618plt.248.1561717976687;
 Fri, 28 Jun 2019 03:32:56 -0700 (PDT)
Precedence: bulk
List-Post: <mailto:gentoo-project@lists.gentoo.org>
List-Help: <mailto:gentoo-project+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-project+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-project+subscribe@lists.gentoo.org>
List-Id: Gentoo Project discussion list <gentoo-project.gentoo.org>
X-BeenThere: gentoo-project@lists.gentoo.org
Reply-To: gentoo-project@lists.gentoo.org
X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply
MIME-Version: 1.0
References: <ed341dc6c91af33edf7b660fb708a450232e373f.camel@gentoo.org>
 <5e45376a-8253-a8f3-6c24-92fa5af900d4@gentoo.org> <7f50285dd6e9dd3175e552ed21dcb7ad40a14719.camel@gentoo.org>
 <b63c58db-e675-7414-07c1-d7d3334659d9@gentoo.org> <CAGfcS_=_y87YLgtAbK_dkq8Sdka2Tgd9m1_z78eXzVyrP0pW4w@mail.gmail.com>
 <71de4d68-e14f-333f-e46d-82dee0e6b2ac@gentoo.org> <CAGfcS_=yAm+D_HUkvk2m+G=Z1DkT+cDOOS_CxH5Te3QsFWts4w@mail.gmail.com>
 <4a8db128-d62b-a2b6-ee2c-03d2fbe0feb6@gentoo.org> <CAGfcS_=_yozc4iVZsJwzuXDMhU0epmDjaSc1Gsj0J8xP=-wRgg@mail.gmail.com>
 <120ec264-07e4-0d3a-b711-b2f2b7a00cb2@gentoo.org> <CAGfcS_ntc4nHb=i5Qw9AUkC5xdXYROmu0nZ3Nj3_awZh1kRACA@mail.gmail.com>
 <a507d199-230a-9ee2-43c4-2d2f0dba4960@gentoo.org>
In-Reply-To: <a507d199-230a-9ee2-43c4-2d2f0dba4960@gentoo.org>
From: Rich Freeman <rich0@gentoo.org>
Date: Fri, 28 Jun 2019 06:32:45 -0400
Message-ID: <CAGfcS_n1gdZdO23nBJSV6w4irB+aGvcGXpfMF01C_6D_FB98EQ@mail.gmail.com>
Subject: Re: [gentoo-project] Why should you *not* vote on existing Council members
To: desultory <desultory@gentoo.org>
Cc: gentoo-project <gentoo-project@lists.gentoo.org>, proctors@gentoo.org
Content-Type: text/plain; charset="UTF-8"
X-Archives-Salt: 3a526938-7d9d-46b1-ba8d-525c88d2d743
X-Archives-Hash: f8dceae21c50d2b6c0b0d38c2014b1bc

On Fri, Jun 28, 2019 at 1:39 AM desultory <desultory@gentoo.org> wrote:
>
> On 06/27/19 10:15, Rich Freeman wrote:
> >
> > No matter what the policy is set to, somebody will be upset.  However,
> > we should still have a published policy.
> >
> Saying something as a member of the council does not mean implementing
> something as a member of the council, though only little effort
> separates them. Blaming ComRel for what others did not do and for not
> setting policy for the council, from which it draws its mandate and to
> which it reports (not dictates), are both absurd.

Nobody is blaming anybody for this.  I simply said that we ought to
have a published policy.

Heck, I'll blame myself: I could have filed a bug or brought the issue
up in an agenda call.  I'll file a bug now and Comrel/Council can
figure out what they want to do.

> Thus by the implication of proctors own published policy the publication
> of all proctors data is less important than contacting the subject of a
> complaint to resolve the matter before disciplinary action is taken,
> curiously there is no indication that this was carried through in the
> instance which spawned this discussion.

No disciplinary action was taken in this case (you'll note that the
section you quoted said nothing of warnings - a warning is a decision
to not take action over a violation).  However, I'll agree that the
page could probably be cleaner.  It was written in stages, with
general content not actually being written by the Proctors themselves,
and then it was implemented in actual procedure further down.  The end
result is that you get stuff that is more general at the top and stuff
that is more procedural at the bottom.

> If proctors do not add value in areas in which ComRel operates and
> ComRel operates everywhere that proctors do, how is the existence of
> proctors justified?

Comrel and Proctors are two different approaches to a somewhat similar problem.

Proctors are intended to take action quickly, but on a small scale.
We issue warnings, or short-term bans.  The goal is to try to moderate
our communications and improve the general atmosphere.  We don't deal
with serious issues.

Comrel is much more deliberative and take a much longer time to make
decisions (at least from what I've seen).  They tend to deal with more
serious issues, and sometimes ones where the only solution is to expel
somebody from the community.

Proctors operates fairly publicly - all our decisions are public, and
we only deal with things that happen in public.  This allows a lot
more transparency.  Comrel tends to operate more in private, dealing
sometimes with interpersonal issues that are not public, which hinders
transparency.

I can't speak for everybody on Council who approved resurrecting
Proctors, but in general I would say that one of the goals was that
Proctors would triage a lot of smaller issues so that they don't bog
down in Comrel, and that faster responses might help to provide
feedback to our lists/channels/etc so that the overall tenor of
conversation improves.

Put more simply: Proctors is a flyswatter, and Comrel is more of a
sledgehammer; when you're dealing with insects, the flyswatter is more
agile and tends to leave fewer holes in the wall.

> > All Proctors actions and bugs (whether action is taken or not) are
> > public.  Anybody can review what we're doing and raise whatever
> > concerns they wish, as you have done.
> >
> By the proctors own published policy, cited above, that claim is false.
> Yes, the bugs are, by policy public, but all actions taken and not
> cannot possibly be documented, please do not overgeneralize.

Read our resolution process (which granted is only a few months old,
so it wasn't followed exactly the first few months after we were
reconstituted).  The first thing we do when cases are opened is open a
public bug.  All actions will be documented in these bugs.

In any case, the process speaks for itself and is on our webpage.
Anybody can read exactly what is done and search bugzilla for our
alias.  Arguing over what is or isn't an "action" is silly - the
process is there to read.

> > Of course.  And that is why we have the opportunity for feedback.  All
> > policies need refinement over time, and Council is the appropriate
> > place to bring concerns about the meaning of the CoC.
> >
> And enforcing bodies are, or at least should be, suitable points of
> contact for concerns regarding their handling of the CoC.

Sure, and I've explained my reasoning in applying the CoC.  If you're
unsatisfied with my reading of the CoC, the Council has ultimate
responsibility, and we respect their decisions.

Ultimately though no policy around human interaction will ever be
completely precise in its formulation.  At best you end up with
principles and guidances that evolve over time.

And that is why Proctors is designed to be more like a flyswatter than
a sledgehammer.  It WON'T be perfect.  However, it also won't leave
holes in the wall.  A few seem to be expressing great concern over a
warning, and even if a ban had been issued it would be over already.
I get that it is a somewhat new operation, but it isn't intended that
anybody who receives a Proctors warning will fall on their sword in
disgrace.  If anybody has suggestions for how warnings can be worded
so that people take them seriously and improve how they communicate,
but don't feel like they're being driven out of Gentoo, I'm certainly
interested.

> Your argument appears to be essentially that you were bound to act
> because a bug was filed, while proctors policy explicitly states that it
> has the option to not enforce it own policies even when it considers a
> violation to have occurred:
> "The following disciplinary actions may or may not be enforced when the
> Proctors become aware of a direct CoC violation."
> Please explain.

Sure.  None of those disciplinary actions were enforced in this case.

-- 
Rich