Responses to some points below but I'd really like to ask people to consider a few things here: - what's proposed is an experiment, it'd likely get tried out a few times and won't consume any huge resource anywhere - its optional, WG chairs that want to try it could, those that don't can just ignore the whole thing - argument that there are other or better process issues to address is misdirected - on a meta-level, if every process proposal, even small experiments like this, generates huge concerns then we're not in a good place and it seems to me that we are in that bad place (that's not an argument to do this experiment, but just an observation) On 01/25/2013 10:54 AM, Loa Andersson wrote: > Running code is valuable, but does not normally replace review. This proposal doesn't "replace review." Its an optional way to get some of that done in parallel with a few other rule tweaks. On 01/25/2013 10:30 AM, Brian E Carpenter wrote: > Speaking as a Gen-ART reviewer, I am indeed worried by this aspect. > I feel I would have to spend much longer reviewing a draft if I > knew it had not been through WGLC. Its an experiment that would be used for a few drafts, your concern might be justified if this were proposed as a permanent change (it's not) that applied to many drafts (it won't ever IMO, but certainly not during the experiment). On 01/25/2013 10:02 AM, t.p. wrote: > This proposal asks the ADs and WG Chairs to do more work It does not. WG chairs *choose* to take this route if they want to. The timers and checking the implementation could increase the workload for the responsible AD at a time not of her choosing and its the timing that's more pertinent but not so bad since ADs are already clearly gullible enough when it comes to additional workload:-) On 01/24/2013 06:34 PM, John C Klensin wrote: > As co-author of the process experiment model, I also object to > its use when it is not demonstrably necessary, That's a really weird objection. I just re-read 3933 and it says nothing whatsoever like that, in fact it says 'This specification permits and encourages the IESG to adopt and institute "process experiments"...' and the whole tenor of the RFC is that stuff ought be tried out. John also said: > this document moves a number of informal IESG > procedures -- including the DISCUSS criteria and even the > Shepherd report requirements (now Informational in RFC 4858 plus > a number of less formal "statements" and "templates" that have > sometimes changed rapidly) -- into the status of formal > procedural requirements That's just wrong. It includes those as part of an experiment that is optional to use which I don't think qualifies as "formal process requirements" in any useful sense. And lastly... > In my experience in the IETF, we almost > never allow a individual submission document that is obviously > very controversial to turn into a extended debate on the IETF > list with the author trying to refute every comment. "Trying to refute every comment" is (IMO wildly) inaccurate. This was proposed a couple of months ago. Some people liked the idea of trying it out, others didn't. I'm following up on that as described in 3933. Every proposal to do with process seems this controversial unfortunately, even teeny little ones like this. I'd love if it were otherwise. And if Adrian or the IESG decide we should not go ahead and try this particular experiment, that's just fine and the world will not end. (And nor will it end if this experiment is run.) What's less fine, but I suspect is also the case, is that any proposal for process change would get the same kinds of negative reception from a similarly sized set of folks and with similarly good, bad and irrelevant arguments against whatever change or experiment is proposed. Regards, S.