Sam's text and way forward on the last call of draft-farrresnickel-harassment-05.txt

Jari Arkko <jari.arkko@piuha.net> Thu, 19 March 2015 10:03 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 622C01A014E for <ietf@ietfa.amsl.com>; Thu, 19 Mar 2015 03:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cAEfdE1W7TW for <ietf@ietfa.amsl.com>; Thu, 19 Mar 2015 03:03:40 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7671A014C for <ietf@ietf.org>; Thu, 19 Mar 2015 03:03:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 329BF2CCD1 for <ietf@ietf.org>; Thu, 19 Mar 2015 12:03:39 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNuN0gUVTR4Z for <ietf@ietf.org>; Thu, 19 Mar 2015 12:03:38 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 1D9512CC4D for <ietf@ietf.org>; Thu, 19 Mar 2015 12:03:38 +0200 (EET) (envelope-from jari.arkko@piuha.net)
From: Jari Arkko <jari.arkko@piuha.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_A225F748-E10B-48DE-9FA9-456EEC16F558"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Message-Id: <B714CBFE-5D3D-4293-91C2-534A3437EB24@piuha.net>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Sam's text and way forward on the last call of draft-farrresnickel-harassment-05.txt
Date: Thu, 19 Mar 2015 10:03:37 +0000
References: <5503914A.7060209@gmail.com> <5503BF22.5020902@gmail.com> <2AE2D092-C32A-46EB-88CA-71366965F4D7@cisco.com> <5505D873.1040203@gmail.com> <CAL0qLwbQf_2WUn8PrUXCMy_3w6tt+iJw0tyF=gUojA5fwRXJNg@mail.gmail.com> <550736E0.6080101@dcrocker.net> <20150316203250.GJ2179@mx1.yitter.info> <55073F22.6000606@dcrocker.net> <20150316204616.GK2179@mx1.yitter.info> <55074AC1.9080500@dcrocker.net> <20150316214620.GO2179@mx1.yitter.info> <550751AC.7090108@dcrocker.net> <55075EBA.4000905@gmail.com> <5509BB58.4060307@qti.qualcomm.com>
To: IETF Discussion List <ietf@ietf.org>
In-Reply-To: <5509BB58.4060307@qti.qualcomm.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/rBdTZ-Odxqq17WsyCCiTNdy1Rgs>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2015 10:03:43 -0000

I wanted to recap where we are with respect to the topic
of incidents handled by the ombudsteam affecting roles
that people have in the IETF.

First off, I think we have broad agreement that we need
to deal with this better than version -06 of the document
does, and that misbehaving leadership needs to be
removed. The debate has been about the specific
mechanics of doing that, and clearly -06 was not up
to the task, as well as leaving a bad impression.
I’m sorry. We are now in the process of seeing how to
correct that.

I would like to get to the specific proposals. Sam
suggested one way of dealing with this, copied below.

I personally like this text. There are some variations of
the general approach, I think Pete argued for a similar
treatment of WG chairs and nomcom-appointed
positions. I could live with that as well.

However, there is clearly another class of approaches
to solving this. We could specify the mechanics of
ombudsteam initiating or running the recall process,
or providing the ombudsteam the authority to terminate
appointments. I think this type of an approach is also
possible, but would tie into our nomcom and recall
processes in a quite close manner. The details would
have to be specified, and of course, the resulting system
should still be workable, safe, etc. from overall IETF
perspective. Does anyone have a proposal in this
space, or believe we should take this path?

Or are there other approaches not listed in this
e-mail?

So at this point I would like to ask if people are
comfortable with Sam’s proposal or if other
proposals are forthcoming and/or people believe
that another approach is needed. Concrete
text proposals would be appreciated.

Here’s Sam’s proposal:

> I'd like to take a stab to see if I understand what we do have consensus
> on:
> 
> old:
> (The Ombudsteam can not impose that a Respondent
>      who is in a IETF management position be removed from that
>      position.  There are existing mechanisms within IETF process for
>      the removal of people from IETF management positions that may be
>      used as necessary.)
> 
> new:
> The Ombudsteam MAY ask a respondent to consider resigning from an IETF
> management position.  The Ombudsteam May remove a respondent from a
> working group  or document editor position.  While this document does
> not create additional procedures permitting a nomcom appointee be
> removed, the Ombudsteam can exclude a respondent from meetings and
> mailing lists and other activities, making it impossible for them to
> carry out their appointed tasks.
> 
> Rationale  for the above:
> 
> I think we should split handling of chairs and wg-level positions from nomcom stuff.
> The discussion to date seems to have focused on nomcom-level
> appointments, and we apparently don't have consensus to make changes to
> that in this document.
> However, I think we should carefully ask ourselves how we handle chair
> harassment.
> Recommending to the AD seems like the wrong approach.  The AD isn't
> going to be in a position  to know the facts, the AD is not going to be
> trained in harassment.  As a manager I've sometimes been told by HR that
> I had to take certain actions; sometimes I agreed, sometimes I wished I
> had other options.  However, sometimes the interest of (in that case the
> company, in this case the IETF) to avoid harassment are more important
> than an individual manager's preference.
> So, I'd like to float the idea that the Ombudsteam is in the best
> position to make harassment-related removals at that level.
> 
> I've removed the sentence saying that the Ombudsteam cannot make
> leadership removals because it's too easy to read that as an affirmative
> statement against leadership removals.  Instead, I've floated a specific
> instantiation of the idea that the Ombudsteam does have the power to
> make it impossible for a leader to do their job.  I think it's important
> to confirm we have consensus on this point.  It would be a huge mess for
> the Ombudsteam to try and do that and to discover we didn't have
> community support for that.  In effect I'm arguing that it's important
> enough to make sure we're on the same page here that we float specific
> text for this issue and confirm it doesn't attract unresolvable
> objections.  Pete has said on-list and in private discussions that he
> believes their is support for the Ombudsteam choosing remedies like
> this.
> 
> 
>