Re: Updating BCP 10 -- NomCom ELEGIBILITY

Mary Barnes <mary.h.barnes@gmail.com> Wed, 11 February 2015 17:18 UTC

Return-Path: <mary.h.barnes@gmail.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 EDDD31A1A5E for <ietf@ietfa.amsl.com>; Wed, 11 Feb 2015 09:18:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 amv3wl0sxBCg for <ietf@ietfa.amsl.com>; Wed, 11 Feb 2015 09:18:32 -0800 (PST)
Received: from mail-la0-f48.google.com (mail-la0-f48.google.com [209.85.215.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF581A079A for <ietf@ietf.org>; Wed, 11 Feb 2015 09:18:32 -0800 (PST)
Received: by labpv20 with SMTP id pv20so4770658lab.8 for <ietf@ietf.org>; Wed, 11 Feb 2015 09:18:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iEN5RxykoPu4M+fi0mTkxrT3+kQxjQtWlwXG4VUt3Z8=; b=U5kdkbDg66sPyo2eFpL2PXz9K2gKjlbymZeHo79gLH2wO1qXIMBtQtniw5AqaxBmqC KmDBYJlWYYllFs9kkRrcWJ41KELozlTuhpscyeCoeI9+o2W/1ZbIFey19Hclz0qSlSkB DjBxKcujXYGMJy6IjV88m6/Y7LFCstzDkF+aWKNJR9gesEOcT0xK+253IZxJf4ySiw0P yT7YHnzvc8szOc2TBivfBSJv/5Nz2350GjKNxJaN/vqKI7KyxgkAh6cf+avjjtozt0Ek ktM7FEIsNMMv4R3/FT3HRQ0JL2XFskm87f1t9UX41CA0KX3qvj58K4/gE0IuNvhh1fEk QYVg==
MIME-Version: 1.0
X-Received: by 10.152.37.194 with SMTP id a2mr28957518lak.105.1423675110762; Wed, 11 Feb 2015 09:18:30 -0800 (PST)
Received: by 10.25.40.133 with HTTP; Wed, 11 Feb 2015 09:18:30 -0800 (PST)
In-Reply-To: <13061.1423674140@sandelman.ca>
References: <CAL0qLwZk=k-CWLte_ChK9f1kzLwMOTRyi7AwFa8fLjBsextBcA@mail.gmail.com> <9772.1420830216@sandelman.ca> <CAL0qLwZatYW2e4Wk6GXB2U26fsCn8BV2qt-07kHBugiq34zrcQ@mail.gmail.com> <04AED0595DF62A6F1013479D@JcK-HP8200.jck.com> <54DB5CBE.3070502@dcrocker.net> <54DB66A0.1050006@pi.nu> <BE226640-1857-4232-9D4F-78445D82776A@nominum.com> <13061.1423674140@sandelman.ca>
Date: Wed, 11 Feb 2015 11:18:30 -0600
Message-ID: <CABmDk8mMPa4RVfiJa8BrY5A0_F+oWXgetMp_Rq9qS-K=2Y8Xow@mail.gmail.com>
Subject: Re: Updating BCP 10 -- NomCom ELEGIBILITY
From: Mary Barnes <mary.h.barnes@gmail.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary="089e013d165640b09a050ed3315c"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/1YeHt3L1KndUJn-sDOftZAb2bCQ>
Cc: ietf <ietf@ietf.org>
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: Wed, 11 Feb 2015 17:18:35 -0000

On Wed, Feb 11, 2015 at 11:02 AM, Michael Richardson <mcr+ietf@sandelman.ca>
wrote:

>
> Ted Lemon <Ted.Lemon@nominum.com> wrote:
>     > The operation of each nomcom are pretty opaque to those who are not
> on
>     > it.   For those who have interacted with a nomcom as candidates, such
>     > an impression might exist.   It's possible that nomcom liaisons or
>     > chairs could speak to this.   However, since nomcom proceedings are
>     > supposed to be confidential, I don't know how much they could really
>     > say.   Because these properties of the nomcom are intentional and
>     > useful, it does make sense to be particularly careful about how
> nomcom
>     > eligibility is determined and not just trust to peoples' good
> natures.
>
> The 2013/2014 had someone who had to be removed because they could not
> attend
> any meetings, and were never able to organize themselves to attend calls.
> I think that they weren't Elmer; my poor recollection is that a family
> member
> got ill, and they simply couldn't do much other than their 9-5.  I never
> met
> this person, didn't know who they were.
>
> The take home if that if one does select Elmer, and s/he sits on the beach
> rather than coming to the nomcom meetings, the nomcom can boot them out. If
> it happens early enough, the nomcom chair can replace them, or the nomcom
> can
> operate with 9 rather than 10.
>
> Allison has suggesting selecting 11 people, with the 11th being a
> participating, but non-voting spare.  I'm undecided if this would be a good
> thing.  In 2014/2015 I did select an 11th from the pool, and confirmed that
> selection with others in case we needed someone else.
>
[MB] I actually really like this idea as it seems to be more the rule than
the exception that one person has to leave the nomcom or just isn't engaged
(I had the latter on the Nomcom I chaired and the former on the one for
which I was past-chair advisor).  So, I think having a backup is a really
good idea.  I would suggest if that happens that each Nomcom should agree
at the start the criteria under which they would add the 11th as a 10th
voting member.   I had a voting member that just wasn't participating at
all for an extended period of time.  I was almost at the point of going
through the process of having them removed as a voting member, but finally
I was able to get some response. But, this situation wasted a lot of time
and does a disservice to the process.
[/MB]

>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>