Subject: Straw process outline for dealing with structural and practices p roblems

From: "Elwyn Davies" <[email-masked]>
Date: Thu, 17 Jul 2003 22:02:59 +0100

A number of people involved in the problem WG have been thinking about an
alternative to using a WG to work through the structural and practices
problems that we believe we have identified with the IETF, and come up with
a proposal for revisions (if any) to the way the IETF operates.

This proposal is offered as an alternative to the proposals discussed at
tonight's plenary...

In outline the plan requires:

    o  Selection of a 'Synthesis and Answer Panel' (SAP) which will
       moderate the process and own the final proposal for change under
       the general oversight of the IESG.

    o  Generation of a list of issues that appear to require attention,
       initially in this document, but subject to additions by agreement
       of the SAP.

    o  Solicitation of contributions from individuals or groups of IETF
       stakeholders which will address solutions to any part of the
       problem space.

    o  Synthesis and moderation of interactions between the various 
       contributions by the SAP in order to create a proposal which 
       appears to result in an organization which will, so far as is 
       possible, no longer suffer from the issues identified, and a 
       minimally disruptive changeover process.

    o  Acceptance of the proposal initially by as large a part of the
       IETF community as possible through open discussion by email and at
       plenary session(s), and finally by the existing IESG at the time
       of completion.

    The plan will be subject to a tight timetable, enforced by the SAP
    with the backing of the I* and intended to deliver an accepted
    proposal at the second IETF meeting after the inception of the SAP.

Constitution and Selection of the SAP

    The SAP will comprise a number of members that is sufficiently low so
    that the group is able to take decisions rapidly and effectively. The
    members of the SAP (SAPs) will be selected to represent the interests
    of as wide a range of the stakeholders in the IETF as is possible.
    To this end one group of the SAPs will be nominated by the existing
    management structures of the IETF (IESG, IAB and ISOC) whilst the
    remainder will be selected through an extension of the standard
    nomcom process.

    There will be eleven members of the SAP as follows:

    o  Two members of the current IESG nominated by the IESG.

    o  Two members of the current IAB nominated by the IAB.

    o  One member of the current ISOC Board nominated by the ISOC Board.

    o  Six members selected by the same process as is used by the
       to select the Nomcom with the variation that the qualification 
       would be attendance at least 5 IETFs with the first attendance 
       must be during 2000 or before.

    The SAP would elect its chair from amongst its members (as with the
    IAB).

    Decisions would be by a voting process determined by the SAP as per 
    nomcom.

    The SAP would also be able to encourage members of the community to 
    address problem areas that appeared to be underrepresented in the 
    solutions presented.

    The whole process should run to a tight timetable - 2 IETFs from 
    initiation to submission of completed proposal might be good!

Regards,
Elwyn Davies

on behalf of Jeanette Hofmann and myself who fleshed out this proposal 
from ideas by various members of the Problem WG editorial team.

---

From: "Christopher Allen" <[email-masked]>
Date: Thu, 17 Jul 2003 16:31:02 -0700

Straw process outline for dealing with structural and practices problemsFrom:
> There will be eleven members of the SAP as follows:

I've been involved in the meeting facilation consulting industry peripherally
for over a decade, and there are some studies that say that this is not a very
efficient number of people, unless you expect 3 or 4 no-shows regularly.

The optimum size for a committee has been show by numerous studies to be more
ideally somewhere around 7. There are a variety of reasons hypothesized for
this, but I've found it to be true from experience. One hypothesis is that this
allows sufficient time for everyone to be able to have their input into the
conversation without becoming distracted or bored waiting for others to finish.

My personal experience with groups of 9-15 is that someone always feels left
out, that their opinion was not properly considered, or that the meeting is
rigged against them by either personality, charisma, or process. Just a slightly
bit fewer people and somehow this doesn't happen.

I've tried to solve this in the past by breaking up groups of 9-15 into smaller
task meetings or sub-groups, but that doesn't really work very well either.

Oddly, when you grow the group to 25 or so there are iterative group processes
that you can use that are different then what is used in a committee that work
very well. The 'dead spot' is 10-20 -- small group processes don't work
effectively and medium group processed don't work either. (Just FYI, the
iterative group processes that work for 25+ people begin to fail at 70 people or
so.)

My suggestion is that you either consider making the SAP group a tad smaller,
say 8 or 9, or increase the size to 25 or so and use an iterative group process
and a facilitator when they meet.

-- Christopher Allen

----------------------------------------------------------------------
.. Christopher Allen                            Alacrity Management ..
.. <ChristopherA at AlacrityManagement.com>   1563 Solano Ave. #353 ..
.. o510/649-4030  f510/649-4034                  Berkeley, CA 94707 ..

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Jul 2003 10:09:22 +0200

Certainly don't grow it. I actually believe that a group of 11 can
be cohesive and effective, although it's easier with 7 or 9.

Most important is that the 7, 9 or 11 individuals are truly committed
to participate and to reach agreement.

    Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Jul 2003 10:15:23 +0200

I think this is a possible approach, but given the lack of convergence
last night on a model, I don't think the subset of us in this WG have
any particular authority to decide. I suggest forwarding this sketch of
a solution to the IESG, in the hope and expectation that they will
rapidly steer in this (or some other) direction. 

What we must avoid is a period of indecision about starting the
process. If we are going the way you suggest, we need the Nomcom working
on it by the end of next week.

   Brian

> Elwyn Davies wrote:
> 
> A number of people involved in the problem WG have been thinking about an alternative to using a WG to work through the
> structural and practices problems that we believe we have identified with the IETF, and come up with a proposal for revisions
> (if any) to the way the IETF operates.
> 
> This proposal is offered as an alternative to the proposals discussed at tonight's plenary...
>

---

From: James Seng <[email-masked]>
Date: Fri, 18 Jul 2003 16:50:44 +0800

Have you look at draft-hardie-alt-consensus-00.txt. I think some of part 
of the SAP idea is already captured there, altho you bring more 
formalization on how SAP (review team in ted's draft) comes about.

It is worthwhile to your idea and how Ted's draft combine...

ps: Not sure where we could have the discussion tho...

-James Seng

Elwyn Davies wrote:

> A number of people involved in the problem WG have been thinking about 
> an alternative to using a WG to work through the structural and 
> practices problems that we believe we have identified with the IETF, and 
> come up with a proposal for revisions (if any) to the way the IETF operates.
>

---

From: avri <[email-masked]>
Date: Fri, 18 Jul 2003 11:05:29 +0200

I think it would need a consensus process for this group to pass
this on to the IESG, though of course Elwyn could so, or the IESG
which I believe is well represented on this list, could just pick it up
and combine it with whatever other processes ideas they were
looking at.

In the meantime I think it a good idea for this group to keep talking
about this and any other process suggestions and see if we can come
up with something we can reach consensus on.  If the IESG reaches a
decision point before we are done, so be it,  but we should not
presuppose that they will and should keep working on in WG fashion.

a.

On fredag, jul 18, 2003, at 10:15 Europe/Vienna, Brian E Carpenter 
wrote:

>> A number of people involved in the problem WG have been thinking 
>> about an alternative to using a WG to work through the
>> structural and practices problems that we believe we have identified 
>> with the IETF, and come up with a proposal for revisions

---

From: John C Klensin <[email-masked]>
Date: Fri, 18 Jul 2003 09:17:54 -0400

Avri, Elwyn, Brian, and WG participants,

I want to repeat and expand on what I said Thursday evening,
in the context of this proposal and a few other things.

Before I go on, I want to stress that I think the "problem
statement" effort has been very useful.  And I would like to
personally thank the people who have spent large amounts of
effort drawing it together.  The question in my mind is how,
and when, we translate study, design, and proposals into
action.

Sooner or later, as the saying goes, push has to come to shove.
One of the things I took away from Thursday evening was a lack
of community enthusiasm for more WG efforts, special design
teams, etc.  My personal take on that at this point is that:

	(i) Elwyn's proposal is an interesting mix of design team
	and directorate ideas.  But the thing those ideas have in
	common is that they are subject to IESG (or WG Chair)
	management.  Elwyn's proposal, as I read it, is for a group
	that is really independent of either.  That makes it just
	the right thing if we are really in a meltdown state.  But
	if the percentages Thursday night are representative of the
	community, then we really aren't: the support for the "we
	are in serious and urgent need of fundamental structural
	change" (my paraphrase) questions was definitely
	underwhelming.

	(ii) Support for "more WGs", "more design teams", and
	"appoint someone to decide" was also fairly low.  I don't
	think that makes a strong case for variations on those
	themes, although I could be wrong.

	(iii) While the question wasn't asked explicitly, I am
	convinced from what was, and was not, said on Thursday
	that, had Harald asked whether the community wanted the
	entire IESG to resign, effective as soon as replacements be
	found, that proposition would also have received little
	support.  Add to that the lukewarm (at best) support for
	the proposition that we need major structural change to
	survive in the fairly short term, and I don't think 
   we are in the middle of a
	meltdown.  We can cast this situation in terms of "trust",
	or other language, but the bottom line seems, to me, to be
	that we are still willing --perhaps anxious-- for the IESG
	to manage the IETF process and to exercise some leadership
	about it.

So, assuming we consider all of this important, sooner or later
a proposal has to be turned over to the IESG, and the IESG
needs to take action on it (or not).  And these efforts are
either are important or they aren't.  If they are not important
enough to accept some delays in the IETF's technical output,
then no proposal, including Elwyn's, is going to work (or be
worth the cost... if it involves a fairly large number of
people (and even a dozen is fairly large) who could otherwise
be doing technical work, reviewing documents, etc., then the
decision to do it is a decision to slow our technical output
down.  If it involves predominantly people who would rather be
working on procedures than doing technical work, or even are
more qualified to work on procedures than on engineering, it is
a recipe for disaster.  No free lunches here.

And that brings me back to my Thursday evening comment.  I
think it is time to _do_ something, not design structures for
talking about what to do.    I think we should go through the
issues in the problem statement document, one at a time, and
quickly generate and document some possible approaches for
each.  I don't care if we reach a clear consensus about any
given approach, indeed, I think that trying to do that might be
harmful.  We should then pass the package -- issue and possible
approaches together-- off to the IESG with

	* A statement that the community, or at least some
	significant fraction of this WG, considers the issue
	important.

	* A request that they pick whichever one of the approaches,
	or one of their own, makes sense given their perspective on
	this issues.

	* The clear expectation that they will consider the above
	and expeditiously make that decision and implement it, even
	if it delays other work, _or_ that they explain why it
	really isn't an issue or that they couldn't find an
	acceptable solution.

	* We make it clear that IESG members who are uninterested
	or unwilling to engage on those issues are expected to
	resign, that the Nomcom is expected to replace, as a
	priority, any who don't resign, and that any who are
	problematic who are not up for review this year (or who are
	especially problematic) will be recalled.

The bottom line is that we are either serious about this or we
aren't.  And "serious", at this stage, implies that we are
willing to have other things delayed in order to move forward
and that we are willing to fire IESG members who don't want to
play.  The good news, from my standpoint, is that I know the
majority of the IESG fairly well, and they really want to do
the right thing, including working to the community's
priorities
if those are clear and realistic (e.g., "add these additional
things to your workload while speeding up the rate at which you
do other things" is not plausible).  I strongly suspect all of
them do.

All a more complicated process will accomplish, IMO, is delay
and wasted cycles.  Regardless of how a proposal originates
and how specific it is, the IESG is still obligated to figure
out
what makes sense and what doesn't and what can be practically
implemented and what isn't, regardless of the level of
consensus from some group that is, inevitably, not
representative of the community.  So why spend more time
developing procedures to develop procedures, taking people away
from technical work or driving everyone who isn't focused on
process details as-an-end away, producing a less and less
representative "consensus".

       john

p.s. To save generating another note, there will come a time at
which the procedures and models we have discussed about WG
management should be applied to this WG.  Have we reached the
point of diminishing returns and how do we figure that out?
For
obvious reasons, if more energy isn't going to produce enough
more in the way of results to justify the investment, it would
be better if the WG "voted" itself out of existence than to
force Harald to unilateral action.  But, while I can't speak
for others, I expect him to do his job as AD.  And that
implies that, if he concludes that the WG has produced about
all it is likely to produce relative to the cost of having it,
he should shut it down.

regards,
     john

--On Friday, 18 July, 2003 11:05 +0200 avri
<[email-masked]> wrote:

> I think it would need a consensus process for this group to
> pass this on to the IESG, though of course Elwyn could so,
> or the IESG which I believe is well represented on this
> list, could just pick it up and combine it with whatever
> other processes ideas they were looking at.
> 
> In the meantime I think it a good idea for this group to
> keep talking about this and any other process suggestions
> and see if we can come up with something we can reach
> consensus on.  If the IESG reaches a decision point before
> ...

---

From: Dave Crocker <[email-masked]>
Date: Sun, 27 Jul 2003 10:11:48 -0700

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:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>