Re: NomCom procedures revision

Tony Hansen <tony@att.com> Fri, 28 August 2015 15:13 UTC

Return-Path: <tony@att.com>
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 243C61A00B0 for <ietf@ietfa.amsl.com>; Fri, 28 Aug 2015 08:13:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.245
X-Spam-Level:
X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
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 f1l62coB3r1H for <ietf@ietfa.amsl.com>; Fri, 28 Aug 2015 08:13:40 -0700 (PDT)
Received: from mx0b-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFEF71A1A14 for <ietf@ietf.org>; Fri, 28 Aug 2015 08:13:39 -0700 (PDT)
Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.15.0.59/8.15.0.59) with SMTP id t7SF8lqD028528 for <ietf@ietf.org>; Fri, 28 Aug 2015 11:13:39 -0400
Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 1wg694m8yj-1 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <ietf@ietf.org>; Fri, 28 Aug 2015 11:13:39 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7SFDcL0013253 for <ietf@ietf.org>; Fri, 28 Aug 2015 11:13:38 -0400
Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7SFDYN5013234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <ietf@ietf.org>; Fri, 28 Aug 2015 11:13:35 -0400
Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for <ietf@ietf.org>; Fri, 28 Aug 2015 15:13:31 GMT
Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7SFDVc5007785 for <ietf@ietf.org>; Fri, 28 Aug 2015 11:13:31 -0400
Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t7SFDRfb007553 for <ietf@ietf.org>; Fri, 28 Aug 2015 11:13:28 -0400
Received: from tonys-macbook-pro.local (unknown[135.110.240.195](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150828151327gw1000ce6je>; Fri, 28 Aug 2015 15:13:27 +0000
X-Originating-IP: [135.110.240.195]
Subject: Re: NomCom procedures revision
References: <CAL0qLwYJzFZT=OgWqiiTw-n6mvb3PPusRtArmPs_d4_qpLfmpg@mail.gmail.com> <CADnDZ8_KsNP=_nwp2wrckXtHF8ZSxrQTvf9UKbAMpt68BiiCFA@mail.gmail.com> <CAL0qLwbhhqG1qoHbBrymPQrU31qjswPAhdeJBqVdRj2L4AR80A@mail.gmail.com> <55E0426A.3000800@alvestrand.no>
Cc: ietf <ietf@ietf.org>
From: Tony Hansen <tony@att.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <55E07A96.1070002@att.com>
Date: Fri, 28 Aug 2015 11:13:26 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <55E0426A.3000800@alvestrand.no>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-08-28_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1507310000 definitions=main-1508280243
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/b1Cld0bgCDQ_wDoEBTIOpZRXGnw>
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 28 Aug 2015 15:13:46 -0000

On 8/28/15 7:13 AM, Harald Alvestrand wrote:
> Den 27. aug. 2015 19:54, skrev Murray S. Kucherawy:
>> Have a look at Appendix F. I plan to fill out Section 10 once we know
>> for sure which changes have consensus rather than a few points that
>> might still be fluid.
> Some notes (this is NOT a detailed review):
>
> Having just gone through the exercise of establishing a voting mechanism
> for my nomcom, I think the following needs to go:
>
> 5.5.  Voting Mechanism
>
>    The Chair must establish a voting mechanism.  The mechanism by which
>    this is accomplished is left to the discretion of the Chair, but must
>    be accepted by at least 75% of the selecting volunteers before the
>    work of the committee can begin.  Once established, this procedure
>    cannot be altered until the current nominating committee is
>    dissolved.
>
> A) It turns out that voting mechanisms are *tricky* beasts. The idea
> that a nomcom will make them 100% right on the first try is a Bad Idea.
>
>
> I suggest changing this to "Once established, the minimum threshold for
> changing the procedure is 75% of the selecting volunteers".

I agree completely that the decision on voting mechanism needs to be a
bit more flexible than "once and done". For example, there are some
voting mechanisms that can yield effective ties. If you don't decide on
how to deal with that up front, are you prevented from adding in a tie
breaker? Another example: it might be that you decide initially on an
overly complicated weighting algorithm, then figure out after using it
that a much simpler weighting algorithm would work just as well. Or you
discover some other facet that "just does not work", because when you
first chose the mechanism to begin with, you didn't have enough
experience to understand how the voting mechanism would be used.

> Note: The 75% acceptance criterion is new. 75% of the selecting
> volunteers is 8 people. That means that 3 people can a) block the
> acceptance of any procedure and b) (with my suggested change) prevent
> any change to the procedure. We should make sure that's what we want.

Do we need to be precisely 3/4? I'm pretty sure that a nomcom I was on a
few years ago used 2/3 majority of all voting members as the criteria.

>
> B) A strict interpretation of "before the work can begin" would have the
> members accept the voting mechanism before they start discussing the
> voting mechanism. I don't think that is a good idea.)
>
> I suggest "before the first vote on candidates is taken" (which is very
> late, but at least it's an explicit point in time).

ack. There's lots more work that the nomcom must do instead of just
"voting on candidates". In particular, the voting mechanism seems like
it definitely does NOT need to be a first-order-of-business topic.

>
> Also, is it an obvious consensus that the chair and the liaisons should
> have no input into the decision to accept the voting mechanism?

I would certainly expect that the chair and liaisons are there to
provide guidance on what they've seen has worked well and not well in
the past for many topics, including the voting mechanism.

>
>
> 5.6.  Voting Quorum
>
>    At least a quorum of committee members must participate in a vote.
>
>    Only selecting volunteers vote on a candidate selection.  For a
>    candidate selection vote, a quorum is comprised of at least two
>    thirds of the selecting volunteers.
>
>    At all other times, a quorum is present if at least 75% of the
>    nominating committee members are participating.
>
> It is not at all clear what a "quorum" does. In our procedures work, we
> found that separating out the idea of "meeting quorum" from "voting
> quorum" made a lot of sense, espcially since we chose to do secret
> ballots only - which means we can't do it in a meeting anyway, and there
> was actually no requirement for the members of the quorum to be present
> at the same time.
>
> It also seemed unusual to have a meeting quorum without either the chair
> or the prior year's chair; we put that into the procedures too.
>
> Note that 4.15, 5.7 and 7.1 still uses "voting member" where it should
> have "selecting member".

There is also a need to be specific about "voting" vs "selecting a
candidate". There are many decisions that the nomcom might vote on
during the course of their business -- the same rules need not apply to
all cases.

With eballots, you can actually require a higher percentage to vote on a
candidate, not tied to any meeting.

I agree that a chair must be present to hold a meeting.



A general comment: I have a problem with all of these numbers being cast
in stone. I can see recommendations being put in with specific numbers,
but not fixing them. Also, I think 2/3 is a more realistic number than
3/4 for most of these values.

    Tony Hansen

>
> Apologies if this reiterates previous discussions; I must admit that I
> seem to have skipped those debates when they happened.
>
> Harald
>
>