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