I believe that Adrian did right in this case. This was IMO one of the
situations which in Spencer's language was 'middle path between lightweight
IESG decisions and full process BCP revisions' and a 3933 experiment could have
proved it right or wrong, useful or not. The community could not reach
consensus to run the experiment and this is one possible outcomes when such
questions are asked.
Same as Adrian I do not believe that this lack of consensus invalidates process
experiments. What I feel is that the key condition in the list drawn by Adrian
is the second:
- Very clear expression of the purpose of the experiment and how it will be
evaluated
Almost in all cases when this condition was not met I noticed the discussions
ran wild and became unfocussed, discussing not about the proposal to run the
experiment, but about that subject of the experiment and its presumed results
before it had even been started.
Dan
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Adrian Farrel
Sent: Wednesday, January 30, 2013 11:15 AM
To: 'Spencer Dawkins'; 'John C Klensin'
Cc: ietf(_at_)ietf(_dot_)org
Subject: When is a 3933 experiment necessary? [Was: Last Call: <draft-
farrell-ft-03.txt> (A Fast-Track way to RFC with Running Code) to
Experimental RFC]
Well, is that a meta-judgment call?
I took the view that the full process expressed in draft-farrell-ft
could not be done by the IESG at their discretion. That is, that some of
the steps proposed constituted a significant variation from documented
processes or well-established behavior. Thus, it was my opinion that if
such changes were to be made they would either need to be documented
direct in a BCP or run as a 3933 experiment. It was also my opinion that
consensus for a BCP would be improbable (looks like discussion on this
list has upheld that view), and so *if* this was to go ahead it would
need to be as a 3933 experiment.
Turns out, however, that the community is not willing to try this
experiment as currently documented. That's OK.
I do not take quite the same negative view as Stephen, but I do agree
with Spencer that getting consensus for a process change always looks
like a formidable task. Small changes never address enough of the
problem or the right piece of the problem. Large changes are too much in
one go. :-) So, it seems to be increasingly hard to make changes to our
process.
While IESG statements remain an option, I would not like to see them
regularly used for things that are definitively a change to consensus-
based process and especially for things that change the way the
community is supposed to behave.
On the other hand, IESG statements are fine for declaring how the IESG
will behave, for advising on action within existing parameters, and for
emergency action.
So, my conclusion: it would be good to have more process experiments if
people feel the process needs to change. However, it would appear that
such experiments
need:
- Thorough debate on an appropriate mailing list first
Do we need a "process experiments" mailing list?
- Very clear expression of the purpose of the experiment
and how it will be evaluated
- Very tight scoping to a portion of the IETF or of the IETF's
work so that the risk of the experiment simply changing
the IETF's process by default is removed
Cheers,
Adrian
-----Original Message-----
From: Spencer Dawkins [mailto:spencer(_at_)wonderhamster(_dot_)org]
Sent: 29 January 2013 21:35
To: John C Klensin
Cc: Thomas Narten; adrian(_at_)olddog(_dot_)co(_dot_)uk;
ietf(_at_)ietf(_dot_)org
Subject: Re: FW: Last Call: <draft-farrell-ft-03.txt> (A Fast-Track
way to RFC
with
Running Code) to Experimental RFC
Just as a follow-up here ...
I was John's co-author on RFC 3933
(http://tools.ietf.org/html/rfc3933).
When we were working on the draft, the problem I thought we were
solving, was that the IESG needs to update the IETF's BCP processes
from time to time, but (1) it was like 32 simultaneous root canals to
actually get community consensus to modify the IETF's process BCPs
including untried changes that might be improvements, so (2) the IESG
was using informal IESG statements developed with much less community
involvement than was expected for process BCP changes, in order to get
anything done at all.
I (and, I think, John as well) saw RFC 3933 process experiments as a
middle path between lightweight IESG decisions and full process BCP
revisions. That's what I thought Section 2 of RFC 3933 was trying to
say.
I had assumed that if the IESG clearly had discretion to do something
under the current process BCPs, and thought it was the right thing to
do, they would just do it, rather than set up a process experiment.
For what that's worth.
Spencer
On 1/24/2013 12:34 PM, John C Klensin wrote:
--On Tuesday, January 22, 2013 16:31 -0500 Thomas Narten
<narten(_at_)us(_dot_)ibm(_dot_)com> wrote:
This document seems to have a bit of missing the forest for the
trees. In the overall scheme of things, I don't believe the draft
will materially help, and is at best a distraction from dealing
with meaningful problems.
The crux of the issue is that any attempt at "fast tracking" is
fundamentally about short-circuiting some aspect of our review
processes. We should only do that very carefully. In almost all
cases, individual judgement is needed as to when it is appropriate
to do that. ADs/WG chairs already have some flexibility here. e.g.,
a WG can skip WG LC if they think its ...
Hi.
First of all, I am completely in agreement with Thomas and his
analysis. Anything that can reasonably and appropriately be done
by this sort of effort can be done by discretion without adoption of
a formal procedure and adoption of a formal procedure creates
additional and unnecessary risks.
As co-author of the process experiment model, I also object to its
use when it is not demonstrably necessary, for example to give extra
status and force IETF-wide use where the actions suggested can be
carried out as a matter of normal discretion (see Section 5 of the
document).