--On Wednesday, January 30, 2013 09:15 +0000 Adrian Farrel <adrian@xxxxxxxxxxxx> 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