Process experiements (was Adjustments to our work mode - please read)

Ted Hardie <> Tue, 06 October 2015 16:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E22ED1ACE44 for <>; Tue, 6 Oct 2015 09:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gaamOqFFef8k for <>; Tue, 6 Oct 2015 09:44:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 414C81ACE0F for <>; Tue, 6 Oct 2015 09:44:51 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZjVJO-0002Go-82 for; Tue, 06 Oct 2015 16:41:58 +0000
Resent-Date: Tue, 06 Oct 2015 16:41:58 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZjVJL-0002G2-C0 for; Tue, 06 Oct 2015 16:41:55 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZjVJK-0001Hq-20 for; Tue, 06 Oct 2015 16:41:54 +0000
Received: by qgez77 with SMTP id z77so179954188qge.1 for <>; Tue, 06 Oct 2015 09:41:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=fwZsQI3WXQSJ0n6o5KgW+hv3npYrvOIJtbIuaBhB04E=; b=qcB7GJmO75wtG4aaf4eyN56U12t3ZjxJvA3KcbeF3/sPgXIRCMThFmRHBi0XcML3R/ 9JKuZ31s3DX8jOFGQoSwprMG7K6FCuf7IePCZkL5A77DBADJIUF6y1qSPNi7pNDJ72QF wUOpBiDVvbrDBaRfBvaBKdBZ/tRoT89jKWqSZzQGQFwJex9hMKVmE2v4RN4iF9zknQtv 8dzq19RFVyVszZ9iKsG6pUJCG4K9IXpYlHgAOvnUaDJ0YnY/T6atN4TCETq71ty1xrDF 9uQNHNV+Duen4miVJFLyRlov/nZyNutlpZTdTrEQuaYAnUNkulEX6JMfgGVE9tO750l6 hdMQ==
MIME-Version: 1.0
X-Received: by with SMTP id f63mr50770893qhe.66.1444149687966; Tue, 06 Oct 2015 09:41:27 -0700 (PDT)
Received: by with HTTP; Tue, 6 Oct 2015 09:41:27 -0700 (PDT)
Date: Tue, 06 Oct 2015 09:41:27 -0700
Message-ID: <>
From: Ted Hardie <>
To: Mark Nottingham <>
Cc: "Eliot Lear (elear)" <>, HTTP Working Group <>, Barry Leiba <>
Content-Type: multipart/alternative; boundary="001a114235fc2766a40521724d89"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.5
X-W3C-Hub-Spam-Report: AWL=1.221, 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, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1ZjVJK-0001Hq-20 f1df1f2b877d8569f8e9fcc3d7137362
Subject: Process experiements (was Adjustments to our work mode - please read)
Archived-At: <>
X-Mailing-List: <> archive/latest/30334
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I'd like to remind folks involved in this discussion that the IETF actually
already has a documented process for how to run process experiments, set
out in RFC 3933.  I think the difference of opinion here is partly on
whether or not the changes being proposed here do or do not rise to the
level of "process experiment".  Reading through Mark's email again, I can
actually see it either way, depending on what is meant here:

"To that end, we're going to try allowing discussion and resolution of
issues in the issue tracker itself, rather than requiring discussion there
to be moved here -- thereby allowing people to participate without
subscribing to the mailing list, if they don't want to."

If the model here is that discussion in the issue tracker is like
discussion in a meeting, useful for moving things forward but always
subsidiary to the decision of the working group embodied in the mailing
list, then I agree that this is a modest enough experiment that it may not
require the whole IETF last call in advance required by RFC 3933.  In this
case the actual consensus calls might be made as decisions by working group
review of checkpoints of the draft, for example.

If, on the other hand, the intent is that the working group's consensus is
derived from looking at both the discussion on the issue and the discussion
in the mailing list, I agree that a document on approximate mechanics would
be useful.  It would be particularly useful to do so in advance of the
first decision reached in that manner, if that is the intent.  Mark's email
is a good start, but there are some points which may not be clear to all
parties (whether issue re-opening is automatic, for example, and the
determination that no new substantive changes are present done after the
re-open, or whether there is a gate to re-opening an issue and what the
shape of that gate is, if so).

As a data point on other users of github in the IETF, the RTCWEB working
group uses the issue tracker in our github repo extensively, and there is
often discussion there.  Each issue resolution, though, is brought to the
working group (in meeting or mailing list) with a specific proposal, and
the chairs judge the consensus on the proposed resolution in the usual IETF
way from that.  That means that we do not allow issue resolution, other
than on purely editorial changes, from the tracker alone.  As a chair, I
will be very interested to watch the results of this experiment, and in
particular its impact on speed.  I think others would also benefit from a
thorough description of the experiment and its results, whenever that is