--On Wednesday, January 30, 2013 09:15 +0000 Adrian Farrel
<adrian(_at_)olddog(_dot_)co(_dot_)uk> wrote:
...
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
For whatever it is worth, I agree with this summary and
especially with the third point (which is where I think this
effort may have gotten into trouble). I also agree with Dave's
observation about getting a "committed core" together. I also
think it is useful to differentiate between the elements of the
experiment that constitutes a process variation and hence makes
community approval desirable and possibly necessary and the
elements that can be tested within the discretion of ADs, WG
Chairs, etc., and make that differentiation clear. In some
cases, one of those categories will be unpopulated but I note
that one of the things that complicated the recent discussion
was a lot of "nothing is new here, why not just do it on a
selective basis and report back" comments.
All of this could be summarized as "it is better to have one's
ducks lined up before starting a community-wide discussion".
Re Spencer's analysis...
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.
Yes. And I (and I think Spencer) hoped that the IESG would use
this mechanism in preference to simply ignoring a BCP process
provision that had become outdated. To be a bit more explicit
about the language in 3933 on that subject, I (at least) felt
that there was always going to be a need for IESG judgment on
when statements were appropriate and when 3933 was needed.
Trying to write rules to establish a precise boundary seemed
impossible and likely to lead to more trouble. What 3933
doesn't say explicitly, but could have, is that, if the
community disagrees with the pattern of the IESG's judgments of
such things, that ought to be a matter for discussion with the
Nomcom (or, at least in theory, appeals or recalls for specific
egregious cases).
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.
I assumed that too. See comment above about differentiating a
3933 experiment (or 3933 part of a larger experiment) from a
discretionary one. Interestingly, one of the things that has
changed since we wrote what because 3933 is that, at the time,
the IESG typically issued statements without prior community
discussion. In more recent years, and for matters where a
statement has been more than the IESG telling the community how
it is doing things, such statements have more often been exposed
to community comment before taking effect. So, where we had
three possibilities when 3933 was adopted, more or less:
* IESG Prouncement
* 3933 Experiment
* BCP
We now have "IESG Statement after soliciting and considering
community opinions" as another possibility for which there are
worked examples. That may reasonably narrow the number of cases
in which 3933 is necessary.
best,
john