Trusting the IESG to manage the reform process (was:Re:Doingthe Right Things?)

[Dave Crocker]

Randy,

>> 2) You did not explain who is left, after you dismiss the worth
>> of authors, wgs and chairs, and
RB> once again, i did not dismiss anyone's worth.  i said your proposal
RB> did.

That is what:

RB> does not scale.  this is still the mode where the authors, wgs,
RB> chairs, ... wuss out.

meant???  Wow.

A suggestion that we have community-based criteria dismisses authors wgs
and chairs?

Double wow.


>> 3) what is it, for example, about "community based criteria" that
>> will not scale.
RB> nothing.  asking the iesg to be  the only enforcer of them will not
RB> scale.

And another "oh, so *that* is what you meant". This is one of those
cases where "cryptic" translates into: It would have helped if you had
not deleted the clarity of your note, before sending it the first time.


The formal statement about the IESG quality function is that it is a
safety mechanism, to help when a working group has essentially running
rogue. It is supposed to be a backup mechanism, not a primary mechanism.

That role is very different from being "the only enforcer" and I don't
recall anyone -- certainly not me -- saying anything like "only" or
"the" or any other such label of exclusivity.


In any event, if you don't want the IESG to perform any quality
functions at all, then what do you propose? Automatically approve
anything a working group approves, rather does not raise a major ruckus
in the IETF Last Call?


RB> but as i have previously suggested, i suspect we can not scale and
RB> produce quality without saying "no" to some things,

and most folks agree with you.  so the concept is not a controversial
one.  as you note, it is the practise that is challenging.


RB> if we come to agreement that producing quality and scaling are two
RB> core problems, then i think there is some organizational and
RB> management experience from within the computer industry and outside
RB> from which we can draw some ideas on quality management etc.  but i
RB> don't think we've reached consensus that these are the issues yet.

really?

time to ask folks whether anyone needs convincing of these two points.



d/
--
 Dave Crocker <mailto:dcrocker at brandenburg.com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>