Straw process outline for dealing with structural and practic es problems

[Elwyn Davies]

Hi.

Perhaps we should have reversed the order of the text of the proposals:
I agree that we need to start producing ideas for solutions NOW, and that
was part of the straw process although it was said late on.  The exact
mechanics of the selection/compromise/synthesis process are moot until it
has something to work on.

So let this be a call to arms!

Whether you think the problem statement, as it is, is right or not, if you
(singular or a group) have ideas for a fix or a way forwards for some part
of the problem as you perceive it, get it written down and put it in front
of the community as soon as possible.

We can work on an acceptance process in parallel.

Regards,
Elwyn

> -----Original Message-----
> From: Dave Crocker [mailto:dhc at dcrocker.net]
> Sent: 27 July 2003 18:12
> To: problem-statement at alvestrand.no
> Subject: Re: Straw process outline for dealing with structural and
> practices problems
> 
> 
> Folks,
> 
> JCK> And that brings me back to my Thursday evening comment.  I
> JCK> think it is time to _do_ something, not design structures for
> JCK> talking about what to do.    I think we should go through the
> 
> John and others have raised a number of concerns about a number of
> proposals, notably the one coming from a subset of the 
> problem-statement
> editors' team. I was/am part of that team, but did not 
> contribute to the
> proposal, except for a quick, late-stage review.
> 
> I think we need to pursue some very separate lines of discussion, to
> give this whole topic proper consideration.  What follows separates
> discussion of the timing of change, the source of proposals 
> for change,
> and the authority for making decisions about change.
> 
> 
> 1.  TIMING OF CHANGE
> 
> I keep pointing out how long it has been since Yokohama, because this
> much passage of time, with no change, suggests that the 
> actual operation
> of the IETF is proving to be more interested in discussing 
> process than
> in improving our work... by making changes that will have real and
> useful effect. (No, I don't believe anyone actually intends this to be
> true, but so far, our actions show the truth of that fact.)
> 
> I also point it out because it means that we are suffering the same
> problem with timeliness in our change effort as we do in our protocol
> development: loss of market window. In other words, loss of 
> opportunity
> and relevance.
> 
> In this case, the "market window" has to do with the attitudes of
> participants. When folks feel a deep sense of frustration and the
> frustration does not get resolved anytime soon, folks will typically
> give up. This fact plays heavily on the interpretations and 
> validity we
> can assert, about "feedback" we are getting during our continuing
> process. (For the statistically inclined, think of this as biasing the
> sample.)
> 
> So, the calls from a number of folks to start making changes, rather
> than to continue talking about the process of change, seems 
> is entirely
> appropriate. The fact that it is coming from a number of independent
> participants -- and I continue to be amused when John K. and 
> I agree on
> a topic's recommendation phase, not just its analysis phase -- should
> carry some weight.
> 
> 
> 2.  SOURCE OF CHANGE PROPOSALS
> 
> At this point, quite a few people/groups are suggesting that 
> the source
> of useful proposals for change need to come from... The IETF populace
> and not from specially "authorized" representatives.
> 
> There is an key, implicit message here, folks.  Ultimately, this is
> "our" organization and we call for the specifics of change, 
> not just the
> concept of change.  Yokohama made clear that change is needed, but it
> did not specify the details.  The details are in the specifics of
> careful proposals.  They must come from us.
> 
> The fact that this perspective seems to be coming from a 
> number of very
> independent sources suggests that it is not all that controversial. At
> the least, I haven't seen a serious alternative to it 
> proposed recently.
> 
> The bottom line from this is that we need concrete, detailed proposals
> for concrete, specific changes, backed by their rationale.  Some are
> starting to emerge.
> 
> What is essential is that anyone having an idea that is not 
> yet written
> down and available for review needs to do that work.
> 
> Anyone.
> 
> As in, not just our "leaders" and not just some designated committee.
> 
> Anyone and Everyone.
> 
> 
> 3.  AUTHORITY TO ADOPT SPECIFIC CHANGES
> 
> So, given a panoply of concrete, detailed, serious proposals, how does
> the IETF choose ones to implement?  Here lies the divergence of views.
> (And frankly, I was getting tired of agreeing with John so much.)
> 
> Some suggest the IESG.  Some suggest a blue-ribbon committee.  Some
> suggest the IETF Plenary.
> 
> I now believe all those ideas are fundamentally flawed, 
> though I remain
> somewhat biased towards the last of these, though it too is flawed.
> 
> The universal flaw is that all of them ignore the real need for real,
> broad, community support. Whatever is chosen, the community has to
> embrace it. This being a community of rather independent 
> personalities,
> embracing does not occur because someone dictates it.
> 
> The IESG has no history deciding what process changes are best for the
> IETF. Further, its members have no special expertise in such 
> design and
> selection. Choosing some decision mechanism other than the 
> IESG does not
> imply that we are in melt-down or that the IESG is incompetent. It
> suggests that that is a body with different skills and 
> perspective than
> is appropriate for this category of decision-making.
> 
> A select, "blue-ribbon" committee is always an appealing idea, and
> always suspect.  It, too, has no track record of success for the
> decision it is making.   Unfortunately, there is no existing
> IETF-related body that does have that track record or that even
> obviously has the necessary skills about organizational design and
> change.
> 
> The Elwyn-et-al proposal invokes an multi-source sampling 
> mechanism for
> populating the committee. I've come to cherish the benefit of ANY
> diverse sampling technique, for populating a decision-making 
> group that
> is intended to represent a larger community, as long as it has any
> reasonable basis. In particular, there needs to be some assurance that
> the folks being chosen are likely to be clueful. Its key strength is
> that it ensures a real diversity of views (and agendas.) 
> Hence, it works
> on independent contributions. This forces a negotiation and compromise
> process.
> 
> The problem with using an IETF Plenary session as the decision-making
> body is that it may well be too highly biased (limited) a 
> sample of the
> population.
> 
> Ultimately, however, I believe that the real decision-making 
> needs to be
> done by garnering strong support from the community. I won't go as far
> as invoking the usual "rough consensus" criterion, because we now have
> quite a bit of experience showing how difficult that can be to acquire
> or gauge, for "social" decisions.
> 
> And let's be clear that that is the realm we are in. This is human and
> group stuff, not technical. So, few if any of us have any 
> real skills in
> this. Worse, finding folks who *do* have those skills does 
> not solve the
> problem. In fact, there is no way to guarantee that any proposal will
> work as intended or even that it will work well. That is the 
> sad fact of
> life about this type of organizational change, especially for a group
> this diverse and diffuse.
> 
> To me, that means the only thing we can do is to make sure that the
> decision is as broadly-shared as we can make it. This begins by
> developing a constituency of support for a candidate proposal.
> 
> The nice things about such a direction of effort is that it 
> lessens the
> import of choosing the best group to make the "final" decision.
> 
> 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>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://eikenes.alvestrand.no/pipermail/problem-statement/attachments/20030728/2db34bed/attachment-0001.htm