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

John C Klensin john-ietf at jck.com
Mon Jun 2 16:15:51 CEST 2003


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 
<harald at alvestrand.no> 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



More information about the Problem-statement mailing list