Re: [Eligibility-discuss] Fwd: I-D Action: draft-carpenter-eligibility-expand-05.txt

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 09 September 2020 22:23 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: eligibility-discuss@ietfa.amsl.com
Delivered-To: eligibility-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36C23A0F9A for <eligibility-discuss@ietfa.amsl.com>; Wed, 9 Sep 2020 15:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 0q6RCQzBSMZX for <eligibility-discuss@ietfa.amsl.com>; Wed, 9 Sep 2020 15:23:37 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53EB3A0F69 for <eligibility-discuss@ietf.org>; Wed, 9 Sep 2020 15:23:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 529A0389CD for <eligibility-discuss@ietf.org>; Wed, 9 Sep 2020 18:02:25 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MzhxRqwkGxT1 for <eligibility-discuss@ietf.org>; Wed, 9 Sep 2020 18:02:23 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 539AF389BC for <eligibility-discuss@ietf.org>; Wed, 9 Sep 2020 18:02:23 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 35FC0797 for <eligibility-discuss@ietf.org>; Wed, 9 Sep 2020 18:23:34 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: eligibility-discuss@ietf.org
In-Reply-To: <05d5088f-3b2c-8162-06c6-96583fe3d700@gmail.com>
References: <159962318959.19375.6649774205472330786@ietfa.amsl.com> <943d5d03-9605-35c7-2a3b-3cc9a48ff0e1@gmail.com> <e2afeee6-f5db-4cd1-8371-b163e01a6931@dogfood.fastmail.com> <29455.1599663931@localhost> <05d5088f-3b2c-8162-06c6-96583fe3d700@gmail.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 09 Sep 2020 18:23:34 -0400
Message-ID: <4136.1599690214@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/eligibility-discuss/Bcj76XRED_kaJZAzplASl3YVGfQ>
Subject: Re: [Eligibility-discuss] Fwd: I-D Action: draft-carpenter-eligibility-expand-05.txt
X-BeenThere: eligibility-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <eligibility-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eligibility-discuss>, <mailto:eligibility-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eligibility-discuss/>
List-Post: <mailto:eligibility-discuss@ietf.org>
List-Help: <mailto:eligibility-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eligibility-discuss>, <mailto:eligibility-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2020 22:23:40 -0000

Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    >> > 2) we should include remote participants for IETF110 (and any future
    >> > IETFs if this document is renewed) regardless of whether there is a
    >> > face-to-face component.
    >>
    >> I can live with this, but I believe that this is what the other paths are for.
    >> to be clear: I don't think that we should count remote attendees when there
    >> is a face-to-face meeting.

    > So they are second-class participants?

Yes, they are.  Given that they aren't WG chairs, and haven't published an
RFC, then they might not really have good enough insights into the culture
and operation of the IETF.
That's also part of my reasoning for "becoming eligible" vs "remaining eligible",
but I acknowledge that is too big a step for this effort.

    >> I also don't think that we should count virtual meetings beyond IETF110, so I
    >> disagree with your rewording of path 1, btw.

    > Huh?

The rewording means that virtual meetings beyond 110 would not automatically count.

    > Firstly, what happens in 2022 depends on the evaluation of the experiment
    > in 2021 (see "2.  Term and Evaluation of the Experiment"), so nothing is
    > fixed beyond IETF110.

    > Second, what if the IETF decides to reduce its f2f meeting frequency
    > permanently? Surely we'll count remote attendance then?

Maybe.  That's why I'd like to outline what comes next.

    >> I think that it is better to deal with the other paths properly, rather than
    >> mutate the 3-of-5 rule to include remote participation.

    > If you look at the data snapshot, 375 people out of 1538 are eligible
    > only because of attendance. What you say would exclude those 375. Maybe
    > that's what we want, but it's a long term issue, out of scope for the
    > proposed experiment.

Yes, but how many volunteered?  That's the number that we would be excluding.

    >> > 3) we MUST have some remote participation controls, most likely with a
    >> > fee waiver program that requires a degree of assertion that you're not
    >> > a sock puppet.  With this in place, remote attendance is a reasonable
    >> > path.
    >>
    >> The simplest non-sock puppet check I can see would involve:
    >> 1) having a DT account.
    >>
    >> The next hurdle I might include would be:
    >> 2) is on at least one @ietf.org list.
    >>
    >> Finally, we could do:
    >> 3) has posted an ID of any kind. (even trivial)
    >> {Maybe we should have a badge system... like stackexchange...}
    >>
    >> (I note that the DT has all this information already)

    > Interesting but I don't see how it would change the draft which
    > is for a 1 or 2 year experiment.

Well, this is in response to having "remote participation controls".
I'm suggesting some that I would find acceptable.

    >> > I would change the wording of 4, path 1 to be:
    >>
    >> I would suggest we change the "names" of the paths to not be numbers.
    >> I can't remember which is which, and now we've renumbered them.

    > How about Path A for attendance (replacing Path 1), Path W
    > for WG Chair or Secretary (replacing Path 2), and Path R
    > for RFC author (replacing Path 3)?

I'm okay with this.

    mcr> Now, I have long advocated having a reasonably high barrier to becoming
    mcr> nomcom eligible (and I'm okay-ish with just path 1, btw), but having a
    mcr> *different* (lower) barrier to maintaining nomcom eligibility.
    mcr> The response to this suggestion has been lukewarm, but that was in the
    mcr> pre-pandemic days, and I found it hard to understand motivation for
    mcr> disagreement.  (I could jump to conclusions if you unicast me)

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide