Subject: Cutting through the accumulating sludge (was: Re: Doing the Right Things? and/or WG Quality Processes WG)

From: John C Klensin <[email-masked]>
Date: Mon, 02 Jun 2003 15:15:51 -0400

For those who don't like reading my long notes -- at least 
before they know what they have to say -- this note suggests 
that we bypass WGs and even BOFs for most of this work and adopt 
a model that uses

	* proposal-> affirmative decision -> implementation ->
	subsequent review and write up -> Last Call and BCP if needed

and

	* proposal -> negative decision -> discussion/ debate/
	serious write up -> Last Call

instead of pretending the tuning suggestions about WG process 
are technical standards.  It explains why I think that is 
appropriate, probably necessary, and The Right Thing to Do.

A more general way to categorize the things WGs do, and the ways 
in which they should do it, might be an output from this 
process, or a separate, longer-term, thread, but shouldn't be 
turned into a blocking prerequisite.

--------------

--On Monday, 02 June, 2003 15:11 +0200 Harald Tveit Alvestrand 
<[email-masked]> wrote:

>> I'm concerned that we may be wandering a bit far into
>> solutions.  Part of the problem reflects a broader IETF
>> problem with getting things done in a timely way; that
>> spinning off a new effort to identify short-term changes may
>> simply take too long.  It may be worth talking specifically
>>...
> I think that for each solution path to be pursued, a core team
> with competence and energy to drive the process is needed, no
> matter what - and that once we have that, it almost doesn't
> matter how long the formal process to start the thing is; they
> can go to work right away, and do course corrections as part
> of the chartering process, rather than waiting for the
> "formalities" to complete before starting work.
>...

Harald,

I'm concerned about one aspect of this, and, ultimately, about 
the other subthreads of the discussion recently.  We seem to be 
spending more and more time talking about process, planning 
process, planning processes for developing process, discussing 
ways to plan, planning for managing the development of 
plans,..., etc.    As this goes on, we see more and more 
postings from the same people and less participation from the 
broader IETF community.  We don't know if those who have stopped 
posting (or never have posted) have dropped off, or returned to 
lurking and trying to follow parts of the discussion, or have 
other priorities, or are simply disgusted.  I do know that the 
volume of traffic has been too much for me to follow carefully 
-- perhaps lots of the community has more spare time on their 
hands than I do, or read faster.  But I think I have also 
noticed an increase in the number of messages that claim insight 
into what those who are silent are thinking and feeling and I 
find that a disturbing sign.

It is clear that all of this process and metaprocess isn't 
getting us to changes --or conclusions that changes are not 
needed -- very quickly.

So I want to suggest a radical extension of your comment above 
(I agree with the suggestion, I just don't think it goes far 
enough under the circumstances)...   In the perspective of our 
traditional adage, let's focus on seeing what code can be built 
and whether it runs, rather than on processes for figuring out 
which code to write or not write.   I note that, unless proposed 
changes are, really, really, radical -- and I don't think I've 
seen any concrete suggestions that would fall into that 
category, or "problem statement" items that would require them-- 
we can implement first and write down the formal mechanisms 
later.   We've got a long history of that approach (which 
parallels, for better or worse, commercial implementation of 
ideas while they are still I-Ds).

To take a specific example (sorry, Margaret, but the thread was 
topmost in my mailbox), the notion of spinning up a WG, or even 
holding a BOF, to discuss topics like "require that state 
changes in the tracker be automatically posted to the WG" seems 
to me to be a huge waste of time and resources.  If that looks 
to the IESG like a good idea, let's just do it and agree to come 
back after a while and evaluate whether it is worth the effort 
to continue.  If the IESG doesn't believe it is a good idea -- 
based on their overview/ understanding of the process -- then 
they should say so and, if others don't agree with the IESG 
perspective, we should start a discussion from that point, not 
by trying to micro-tune what gets posted and to whom.

Specifically, we've got about five weeks before Vienna.  If I 
look back on the discussions of this WG since San Francisco, it 
seems clear that we could use up all of that time debating 
charters for new WGs, etc.  Even if we do that, the more WGs we 
spin up with "process" responsibilities, the more coordination 
that is going to take, and coordination takes time and energy. 
And, unless each and every one of those (including any BOFs 
scheduled as part of that process) is scheduled in clear, 
no-conflicts, time, it will draw an unrepresentative sample of 
the community, consisting of the union of those who care more 
about process than about technology standards development, those 
with free time on their hands who wouldn't rather spend it in 
some Vienna cafe or museum, and those who feel reluctantly 
required to attend to protect against the excesses of the other 
groups.   _That_ is scary.  It is also, fwiw, the reason we 
stopped holding face to face Poisson meetings.

So, instead, I suggest that we encourage groups to form out of 
the problem-statement list, groups who are excited about, 
focused on, and in general agreement about, some small subset of 
the particular issues that have been identified.   Let them 
self-identify from collections of people with similar opinions. 
Encourage them to put the energy that has been going into 
multiple list postings in very short periods (in many cases, 
repeating the same themes over and over again) into quickly 
generating some specific "suggestion" documents.  I'd like to 
see those posted as I-Ds, but let's be relaxed about format 
since they are unlikely to evolve directly into RFCs. 
Encourage very short documents with very specific suggestions 
(which means I'm not doing any of the writing :-)). Set a 
deadline.

Impose a filter on the documents.  I don't think it makes a huge 
difference what it is, but I'm thinking about something along 
the lines of "if at least five people don't sign up to believing 
this is a good idea, the IESG shouldn't waste its time".  Pick a 
different number, or a different formula, if you like, but let's 
not spend weeks debating it.

With those documents in hand, let the IESG go through them and 
classify them as something like:

	* good (or at least interesting and not harmful) idea,
	will implement on a trial basis. (A schedule would be good.)
	
	* unimplementable, because...
	
	* unwise or undesirable, because...

	* doesn't appear to solve any relevant problem.
	
	* sweeping change
	
	* needs a lot more thought and consideration.

For suggestions in any of the categories other than the first, 
find out if anyone other than the proposer(s) really care(s). 
You could ask for comments on the mailing list, or for more 
endorsements.  It probably makes little difference, but, again, 
it is useful to have a filter to avoid wasting more time on 
something no one cares about or that won't do any good.  If it 
"passes", put it on the plenary agenda for Vienna.  Or, if some 
of this turns out to require a smaller, "discussion", BOF that 
won't fit in the bar, schedule a BOF.  (Assuming times can be 
found, the scheduling deadlines are all IESG rules, developed 
for IESG and Secretariat convenience.  The IESG can presumably 
waive any rule it can make, so, if it is important enough and 
space can be found, the deadline for scheduling a BOF for the 
morning of 14 July is probably the afternoon of 13 July).

I would hope that the IESG can do this quickly and with 
expedited review.  If any of these suggestions gets tied up in 
"discuss" votes, rather than having a decision made and moving 
on, would certainly be taken, by some people and with some 
justification, as evidence that the IESG is, itself, broken. 
If the IESG doesn't have time, appoint a blue-ribbon committee 
to do a preliminary review and write comments for the IESG to 
review.  You ought to be able to draft any existing WG chair in 
this area, or likely candidate to become one,  onto that 
committee -- it will take less of their time.

I note that any, or all, of the above can be done, and 
implemented, without procedure changes or more process debates. 
While I've been unhappy with some of it, the IESG has claimed 
for itself the authorization and right to do far more sweeping 
things under the "managing the process" umbrella.  And it is an 
approach that, if people really want to get something done 
--rather than engaging in interminable process debates-- could 
actually produce some agreement about changes before Vienna and 
a clear agenda for the plenary there.   It seems to me that most 
of the alternatives that have been suggested are going to leave 
us spending the rest of this month, if not the next few months, 
debating structure, charters, methods for selecting chairs, and 
other nice process-things that do not, themselves, produce 
forward progress.

Now, there are things, most of them in the "long term" category, 
that this approach won't address or fix.  I'll try putting some 
comments on one category of those things into a separate note. 
But, if there is anything of that nature that we really need to 
do, they will almost certainly require spinning up a WG, careful 
consideration of charters and leadership, etc.  I think the odds 
of something of that nature producing results that are ready for 
us to even debate intelligently in Vienna are pretty low, and 
will keep getting lower unless we can do something radical about 
the current astronomical N/S ratio.   Maybe we can at least 
start that effort in parallel with the above.  But let's not bog 
down practical issues, fine-tuning, and fixes with the same 
process needed for long-term, major, changes.

  regards,
     john

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 02 Jun 2003 15:30:34 -0400

Hi John,

I mostly agree with what you've said here (and feel free to use me
as an example, good or bad, any time! :-))...

In particular:

At 03:15 PM 6/2/2003 -0400, you wrote:
>Now, there are things, most of them in the "long term" category, that this 
>approach won't address or fix.  I'll try putting some comments on one 
>category of those things into a separate note. But, if there is anything 
>of that nature that we really need to do, they will almost certainly 
>require spinning up a WG, careful consideration of charters and 
>leadership, etc.  I think the odds of something of that nature producing 
>results that are ready for us to even debate intelligently in Vienna are 
>pretty low, and will keep getting lower unless we can do something radical 
>about the current astronomical N/S ratio.   Maybe we can at least start 
>that effort in parallel with the above.  But let's not bog down practical 
>issues, fine-tuning, and fixes with the same process needed for long-term, 
>major, changes.

This was the point of separating the "near-term" and "longer-term"
items in the process document...

We should work on fixing the near-term items now, in some loosely
coordinated way, in parallel with fixing the longer-term problems
(i.e. reorganization and updates to the standards-track).

I'm just not sure how you think that we can start the near-term
effort that you've explained...  I had suggested a WG to vet the
various ideas for improvement and prioritize which ones to implement,
and you've suggested either having the IESG do it, or having the IESG
appoint a panel to do it.

A WG provides more opportunity for visibility and community
feedback, which is why I prefer a WG to having this done in a
closed group.  I know that not everyone can attend a WG, but
it a WG is certainly more open than the IESG or a closed
committee.  I agree, though, that a WG could be too high
overhead.

So, either way is really okay with me, as long as we find a way
to start vetting the various ideas for near-term improvements and
implementing the most promising ones.

Margaret

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Jun 2003 15:56:03 -0400

--On Monday, 02 June, 2003 15:30 -0400 Margaret Wasserman 
<[email-masked]> wrote:

>>...
>> we really need to do, they will almost certainly  require
>> spinning up a WG, careful consideration of charters and
>> leadership, etc.  I think the odds of something of that
>> nature producing  results that are ready for us to even
>> debate intelligently in Vienna are  pretty low, and will keep
>> getting lower unless we can do something radical  about the
>> current astronomical N/S ratio.   Maybe we can at least start
>> that effort in parallel with the above.  But let's not bog
> This was the point of separating the "near-term" and
> "longer-term" items in the process document...

Understood.

> We should work on fixing the near-term items now, in some
> loosely coordinated way, in parallel with fixing the
> longer-term problems (i.e. reorganization and updates to the
> standards-track).
>
> effort that you've explained...

I am suggesting that, if there seems to be general sympathy on 
the list (or otherwise) for this, that the relevant AD just do 
it --or delegate it to the WG Chairs or an appointed 
coordinator-- to do it.  The authority is there; nothing in the 
current procedures requires us to find a tree and dance around 
it in a circle while chanting "rough consensus and running 
code", or to create a charter and WG, before doing anything.

>  I had suggested a WG to vet
> the various ideas for improvement and prioritize which ones to
> implement, and you've suggested either having the IESG do it,
> or having the IESG appoint a panel to do it.

If the IESG thinks that a particular idea is a good one, or 
likely to be a good one, then they should implement it, without 
more fuss.  If they think an idea is a bad one, and the 
community still thinks otherwise, _then_ we may need a more 
formal/systematic process.

> committee.  I agree, though, that a WG could be too high

Then find the middle ground by using the WG for those things 
that (a) are controversial, (b) are non-trivial, and (c) still 
have significant support.  Right now, we are headed for using 
WG-like mechanisms for suggestions that, once understood, are 
probably obvious and trivial.  We are also headed for using 
those mechanism for proposals that, were the IESG to comment, 
they would immediately point out reasons why the ideas were 
infeasible and, probably for a large subset, immediately 
convince most of the rest of us.

So, IMO, we need to move to a "four piles" plan -- clearly yes, 
clearly no (or no support beyond the author and his two 
friends), not worth further effort, and really worth serious and 
extended discussion.   For the fourth category, _if_ it actually 
turns out to be non-null, let's by all means spin up a WG, or 
attach those topics to the "long-term" WG.  But let's not go to 
that effort unless the fourth category really is non-null. 
Personally, from looking at the list over the last few months, 
I'd be a bit surprised.

> to start vetting the various ideas for near-term improvements
> and implementing the most promising ones.

Ok.  Want to wait until August to get started?  If the answer is 
"no", then let's not start planning WGs instead of generating 
specific suggestions and getting quick and efficient IESG 
evaluations of them.

    john

---

From: Randy Bush <[email-masked]>
Date: Mon, 2 Jun 2003 20:09:28 -0700

> code", or to create a charter and WG, before doing anything.

i think we really do not have a clear vision of what we should
be doing, so it is easier to talk about the processes and enemies
of doing it.  no blame.  this is extremely difficult stuff.

i keep thinking of the analog to how some engineering companies
dealt with the conflicts/tensions of staying nimble while
undergoing large growth.  

digital equipment tried to maintain a dynamic engineering culture
while growing massively.  it did not work.

hp is still trying, but has become more and more stodgy and has not
stayed lively and dynamic.

intel may be the most successful.  one key to this success is not
touching anything that does not have at least a 40% margin.  i.e.,
they say "no" to a lot of bright ideas.  i do not believe that we
have the culture to do that.

randy

---

From: Keith Moore <[email-masked]>
Date: Tue, 3 Jun 2003 12:01:52 -0400

> have the culture to do that.

of course IETF doesn't measure success in dollars, but paying explicit
attention to risk, need, and resource consumption would be a good idea.  seems
like we would do well to avoid WGs with high risk and low need, as well as
those with high resource consumption and low need.  

at least when I was an AD there seemed to be a widespread belief that IETF was
required to take on any working group for which there was a constituency. 
people need to understand that this is unreasonable.

there are always more bright ideas than can be investigated.