Re: [Cfrg] [Eligibility-discuss] "Additional Criteria"

denis bider <denisbider.ietf@gmail.com> Sat, 01 August 2020 21:40 UTC

Return-Path: <denisbider.ietf@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C4D3A0F48 for <cfrg@ietfa.amsl.com>; Sat, 1 Aug 2020 14:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 WnU4zvRjdNVr for <cfrg@ietfa.amsl.com>; Sat, 1 Aug 2020 14:40:40 -0700 (PDT)
Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 E3FA23A0F4A for <cfrg@irtf.org>; Sat, 1 Aug 2020 14:40:39 -0700 (PDT)
Received: by mail-oi1-x235.google.com with SMTP id k4so30014774oik.2 for <cfrg@irtf.org>; Sat, 01 Aug 2020 14:40:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o/qAAGzP7e/lcjiYVY1pc/SF9DDk2sSHgCb+RG4GClA=; b=RUAFrDDSYtzICBikK6buFJIUhZZjYI6th4vgq/1Huk1JTaBe8chWjwKdJvKvKSsF+9 75nm4YDt4vopZN50FjoW7aMIymSl92eZn+9d5PWzj+R0EZ6cC3t/lm4TH/MvLBZtAXqM 7DcWHHMVhN4Lag1dVt7NMAo57TQ5ddB2pIx56IO43Pcj7/f45uC+vpZSPIu9rY74m00v dYToiaYxk/Qrgk7Bl9A8sAEo8xDyT5LgE/cNsf1F6c4e77OhUwCJa+WL5gWRhhrApvS5 1mLOY8jGLzVimxm+6FhmM/SoqYZ089BHOFyev3HxKm2OLyiWCQ3hfB3YTMDq3aVBwOtw B7pA==
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=o/qAAGzP7e/lcjiYVY1pc/SF9DDk2sSHgCb+RG4GClA=; b=C8Rr8g/gx3V0tgOd2EK3hIkEMpOnYc636b5ipBFa0ZiStESVLlamEETJxEC6nSWSJZ qhdMMAbjs2o5J08gRlOEjbxpZESNGml+dnMPdbrNhFZpD+1P7kszq0Kh/Rv7VaRR0Dkd qdMmPrIootPOJf+BsjB2Nsm6r5jCshHk+5JeYKVLdmQubesaHrdUc/BpZk0/CSVsHOmc SmvW5lWORVnFqprwYcHX3rm+c8vkTdyBRVbJzb/QtVA4B1t96zbOqfwK/3upt53vtCma wN5gOv2zM6axtidGhea8BVOhi/B/7M4JmIC65dQ4OpBVv9xJTJxBMbALidbIacHgPTd5 Pojg==
X-Gm-Message-State: AOAM532mnr0DVyL7GE51pNQx6c+A1j1jhEk3ewY2mh3JEQPH4MyPgwIN rJREQbAMnkcBR0uiME1RQww9dPO2kynTM9R0Fso=
X-Google-Smtp-Source: ABdhPJwalwi7SJd4nFh/NFmXGveeCAVkqhLfFmWSXMc2XImYiGrkYltM1wBn9g8z/OodJDRsoCOulVDSxm5rNxhWCR0=
X-Received: by 2002:aca:5942:: with SMTP id n63mr7446966oib.141.1596318039123; Sat, 01 Aug 2020 14:40:39 -0700 (PDT)
MIME-Version: 1.0
References: <CA+9kkMB_5ARO4fg9XAXVc5Ytz3TDsrQX5MPWPtmbALZBBtO-Sw@mail.gmail.com> <8067B111-FA6F-4DA4-9AF1-29A0765905A9@fugue.com> <CA+9kkMA3Bwdy2Oo+KghbCk9Tj6e3qGd25JRHLd8RUXNCD6urMA@mail.gmail.com> <2A09808B-DD11-4ECA-B7C6-9799CEB2C74A@fugue.com> <6E8EF3028098A52B4708627C@PSB> <4a038880-86de-e5c7-d1bc-d6f8c26b6400@joelhalpern.com> <5B866B33-8934-42F6-92D4-D05C06FE073D@fugue.com> <50D70AEC-3697-44B7-B249-04E378E2B8E9@fugue.com> <20aa7fba-d9ef-95ed-c949-992267b93da8@joelhalpern.com> <70C0ABD4-7B10-45E1-895B-27701FEFA55C@fugue.com> <19ac3b73-56a5-7f46-00be-60cf62dd7afc@nthpermutation.com> <9AB6703B-BF79-4837-B833-E83429621E7F@fugue.com> <44b53b90-2ed0-b920-4df6-7ae0c3be1f19@nthpermutation.com> <FBD86BBF-75CE-4807-9A7D-42F56BD145D3@fugue.com>
In-Reply-To: <FBD86BBF-75CE-4807-9A7D-42F56BD145D3@fugue.com>
From: denis bider <denisbider.ietf@gmail.com>
Date: Sat, 01 Aug 2020 16:40:27 -0500
Message-ID: <CADPMZDBkSUpuYR==98sFgru27HHX-jQ1zdgo4ai9BD-MCoP2Sw@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
Cc: Michael StJohns <msj@nthpermutation.com>, "cfrg@irtf.org" <cfrg@irtf.org>, eligibility-discuss@ietf.org
Content-Type: multipart/alternative; boundary="000000000000abab6605abd7c141"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/siLVNXuZDn441sQ_bbIAg-iCnZg>
Subject: Re: [Cfrg] [Eligibility-discuss] "Additional Criteria"
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Aug 2020 21:40:42 -0000

General thoughts on community self-leadership:

- How to avoid the Dunning-Kruger effect from causing the election of
someone mediocre (but representative!) is an unsolved problem.

- People are of fundamentally good intent. This can come across wildly
distorted when people are confused, hurt and unskilled.

- A social process does not need to be designed against attack by
super-intelligent aliens. The real challenges are (1) a lack of effective
organization altogether, and (2) sometimes, events caused by the confused,
hurt and unskilled.

- Inflexible and technical rules enable malicious compliance. Malicious
compliance creates a temptation for more rules. A proliferation of rules
has a strangling effect on constructive, well-meant contributions.

- The rules of a social process are interpreted by people, not algorithms.
The rules therefore do not have to be inflexible and technical, and can be
general guides.

- Universal agreement on what the rules mean and how they should be applied
is not required and should not be expected. The Supreme Court hands down
5/4 decisions regularly, that is fine as long as decisions are made and can
be overturned at a later time.

- A social process will not lead to better results than the people who
execute it. It is far more effective to secure the involvement of the best
people, than to exclude offenders by devising rules.

You build the house you want by bringing in the parts that will comprise
the house you want. You don't do it by writing rules to exclude the wrong
parts.

Not only is no one interested in bringing you the wrong parts; but writing
rules to exclude the wrong parts does not actually bring the right ones.

These are probably the only thoughts I will have on this.

Regards,

denis


On Fri, Jul 31, 2020 at 4:20 PM Ted Lemon <mellon@fugue.com> wrote:

> On Jul 31, 2020, at 5:04 PM, Michael StJohns <msj@nthpermutation.com>
> wrote:
>
> Yes, but for example rfced-future@iab.org is an IETF community working
> group mailing list, and cfrg@irtf.org is an IETF community mailing list -
> need I go on?
>
>
> Apparently, because I have no idea what your concern is. Do you mean that
> if people participate in RGs, that doesn’t qualify them for nomcom? Well
> then either we include RG mailing lists in the set, or we decide that
> indeed participating in RGs doesn’t qualify you for nomcom. This is just a
> decision to make—there’s nothing inherently difficult about it.
>
> Why is X on the list of qualified people - not why is X on the mailing
> list....    in any event, is "+1" a contribution?   Is "this idea is stupid
> for [list of reasons that have been debunked many many many times]" a
> contribution?   If so, I can automate a random +1 or -1 to be sent to the
> list every say 10 topics.
>
> Yes, you can. If people really want to kill the IETF, they can automate
> bots to kill the IETF. This is possible now—it just isn’t happening because
> nobody is motivated to do it. I agree that this is a potential attack
> surface, but there are things we can do about it: maybe we need to only
> allow addresses registered in the datatracker? Maybe only addresses
> registered in the datatracker that are for people who attended online or in
> person? If we’re so concerned that this is going to happen that we think
> it’s urgent to prevent it, that would make it a lot harder.
>
> But regardless, what you miss with your criteria are actual contributions:
> private notes to the WG chair, or back and forths with the authors on a
> document, or, for the GITHUB based WGs, you might miss pull requests or
> comments in the issues trackers.  Or the document that the contributor was
> working on is awaiting an action by the WG chair, by the AD, or by the
> RPC.  I don't find your criteria either useful or all that related to the
> concept of "contributing”.
>
>
> You know, this is starting to feel like a pissing contest. Yes, what I
> suggested doesn’t capture every contribution, but it does capture an
> important type of contribution. Yes, it can be gamed. And the gaming can be
> mitigated. My concern is that right now we are headed in the direction of
> valorizing “showed up for the meeting” above “participated on the mailing
> list” and I’d like to address that. If you think participating on the
> mailing list doesn’t matter, why are you responding here?
>
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>