Re: Updating BCP 10 -- NomCom ELEGIBILITY

Dave Cridland <> Sun, 15 February 2015 19:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D84201A00E0 for <>; Sun, 15 Feb 2015 11:38:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hVHIRJnAtCUo for <>; Sun, 15 Feb 2015 11:38:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6727F1A0010 for <>; Sun, 15 Feb 2015 11:38:12 -0800 (PST)
Received: by with SMTP id va2so35950581obc.1 for <>; Sun, 15 Feb 2015 11:38:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g+n4jFVafaC1bt7E9CBiemhpvU/Kr07j0lXJZiHzdPM=; b=DmIUNQFoFvtF54r9vv89IW0I5vOIpoUxnhpE7fvbhhNXhEqCKYFpIGMMGN6lnSBDp9 GTnHlXBTyPZHc2d0YBXkRnzAOnvBt026zaaxo4iQQo8DI1V5bq1RGGh7FdP0uVNc7Dp0 U/aOj8U7xy7Yceg1LTtmHS66NSN7mnfmVx0Zw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=g+n4jFVafaC1bt7E9CBiemhpvU/Kr07j0lXJZiHzdPM=; b=gK1hsn+BnXqakfUBsCfkGf5rhQxe0GWh+/6F9hYO6YwoaAnS6G7yQjmpy/+hGpwIhw bXajZIcVb+VD8Kfp50QTglh/XWZjqM34NetuHFWARTqUam/CHZjr64l9NeDO2uksEpPE +EJZ+695iZ0h3LqCtsw3Qw7inYK1QBn/Gf8IWe759zM4tTocVA4YdRSjYQitYblVx4oJ D3zbvKfKXXH3gfLGQyChIVRq1YRAFGBXZyio8DPJ/A23yTfpk2Wn+0GgA+rfTuKsFSJK JkkWoxWxiGZly8ursg3tuF8FeVaKnmMKj0riF+qMoaFfQ0BnUW05gWbbGJO0Q+6QGDvm C5Vg==
X-Gm-Message-State: ALoCoQmILcx/m1uy5EkAowV5qGZXn1aRitpYyMqRsN+NavwHcIxQcwSsPhWkVBNNjNv8hSzHOj3b
MIME-Version: 1.0
X-Received: by with SMTP id sn10mr13245756obb.52.1424029091608; Sun, 15 Feb 2015 11:38:11 -0800 (PST)
Received: by with HTTP; Sun, 15 Feb 2015 11:38:11 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Sun, 15 Feb 2015 19:38:11 +0000
Message-ID: <>
Subject: Re: Updating BCP 10 -- NomCom ELEGIBILITY
From: Dave Cridland <>
To: Michael Richardson <>
Content-Type: multipart/alternative; boundary=089e0153694e27d08b050f259c34
Archived-At: <>
Cc: " Discussion" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 15 Feb 2015 19:38:15 -0000

On 15 Feb 2015 15:34, "Michael Richardson" <> wrote:
> Dave Cridland <> wrote:
>     > 1) AUTH48 is interesting as a metric; it's clearly an indicator of a
>     > document actually getting published, and one that doesn't get
>     > outside the author's control unlike publication. Moreover, anyone
>     > through AUTH48 has had to deal with an IESG telechat on their
>     > that's extremely useful experience in leadership selection. Possibly
>     > "last call" and "telechat" are also good enough - and interesting
in as
>     > much as a document that "fails" last call is arguably as important a
>     > contribution as one that goes on to publication.
> So, instead of AUTH48, you'd pick an earlier state like IESG Review.
>     (see, but
>     actually I think write-up and the diagram are old and missing some
> That (perhaps correctly) skips things that go through the Independent
> Submission Stream.
> I agree that including the authors into the state above solves the
problem of
> a document which is so good that it needs no review and no tickets.

That all sounds good. And yes, I think an independent stream submission is
reasonable to skip. I did consider suggesting that only IETF consensus
documents should count, but that is probably too narrow.

>     > 2) I think the document uploader concept is good, but limiting the
>     > documents to only those which get scheduled time in a WG session
>     > so good; some WGs don't meet often, or even at all, and a document
>     > that's so well crafted that it doesn't need discussion in a face to
>     > face meeting is a really good document in my opinion. Clearly we
>     > want arbitrary documents either. Any WG document would seem a "good"
>     > contribution, and I suspect any document with a shepherd assigned
>     > should be safe, too, since that effectively implies an expectation
>     > publish.
> The problem with shephard assigned is that it could be very late in the
> process, and a document which *does* get a lot of discussion and revision,
> represents a lot of contribution of effort.   It is not unreasonable to me
> that a single document occupies the entire IETF "life" of 3-4 persons.

Yes, true. As I said, I think measuring contribution is a very hard metric
to find, and there's an implicit suggestion lurking here that we're after
long-term, quality contributions - I'm not sure I disagree with that

But in general terms, any document that has any of those characteristics -
it's WG document, one that's getting WG "time" by some measurement, or one
that has a shepherd assigned - seems likely to be good for a document
uploader metric.

It might be interesting to have the tools adapted so the uploader can note
which of the authors have actively contributed this time around, too, to
avoid the situation where two co-authors have to share uploading.
Similarly, it might be useful for WG chairs to be able to tag a document as
having been discussed within their WG.

>     > 3) This works for WGs that use a ticketing system and have
>     > meetings. Not sure what percentage that actually is.
> A number of WG chairs don't like the current ticketing system, but
> I think that WGs are going to use some ticket system.

And, thinking about it further, we probably want to promote the use of a
ticket system anyway. In addition, I'm more comfortable with measurable

Again, it might be useful for the ticket system to be able to record
whether the ticket resulted in useful discussion, and note who was
involved. Again, this is at the whim of somebody, but I really don't think
excluding whims is entirely a positive thing.