ietf
[Top] [All Lists]

Re: call for ideas: tail-heavy IETF process

2013-05-05 16:24:00


--On Friday, May 03, 2013 13:29 -0400 Thomas Narten
<narten(_at_)us(_dot_)ibm(_dot_)com> wrote:

Let me expand further on "work plan" and  "project management".
...
But it extends to the WG as a whole.  WGs have a finite number
of cycles. [...] if you spread their
resources too thinly, a WG starts having problems.

Few WGs acknowledge that and try to manage it. Managing it
means:

1) identifying core documents that are priority, and minimizing
distractions that will take cycles away from the priority
deliverables.

2) It may mean making concious decisions not to work on some
documente *yet* in order to concentrate resources where it
matters

3) it means tying the work plan directly back to the charter.
If the two aren't in sync, one or both need changing.

4) It means recognizing that there are real limits to how many
documents a WG can (credibly) work on at any one time. (Too
many WGs have lots of marginal documents that suck cycles away
from the critical ones.) How many WGs say "no" to marginal
documents?

If one replaces "WG with AD" and then "document" with "WG", one
sees another part of the problem.  It seems to me that we need
to either:

        * reduce expectations of what a given AD is supposed to
        do with WGs and documents  or
        
        * reduce the number of workload-weighted WGs that an AD
        is expected to "manage".

If we don't do one or the other, this discussion's increased
expectations for mentoring, management, and keeping track of the
big picture and long-term issues are unrealistic: neither
ongoing overload nor lurching from one near-crisis to the next
are a good basis for getting either good management or strategic
thinking done.

SIRS has been mentioned as an old idea that we haven't tried.
But, when one starts looking at AD load, there are other
proposals around too: ones to put limits on the number of WGs
and others to change the review process so that we don't expect
the same people to manage WGs, advocate for them, take the lead
in advocating their output, and then do the evaluations.  There
are reasons to believe that combination would not be ideal under
the best of circumstances but, if we are going to expect more
attention to WG oversight and mentoring, it gets worse.

Along the same lines, it seems to me that we need to be able to
trust WG Chairs to correctly understand and monitor both WG
consensus and agreements reached after Last Call.  If that isn't
realistic, we probably need better-trained WG Chairs or
replacement WG Chairs, not more work for the ADs.  In
particular, as another piece of the end game, I think AUTH48
ought to be able to be managed by WG Chairs and authors, with a
general understanding that substantive issues have to go back to
the WG and no AD involvement except in very exceptional cases.

Finally, there are a few things that we used to do, that were
helpful, and that were abandoned due to industry evolution and
changes in priorities.  The original idea of a Proposed Standard
as a fairly rough specification that would be used for study and
evaluation on the basis of implementation experience, not a spec
from which products were built, is one that has been mentioned
(although not quite in that way).   The other one that occurs to
me --done rarely but to good effect-- was to identify WGs who
are doing design work with broad implications and give them
plenary time to explain their goals, work plans, and general
functional ideas.  Done well and timed correctly, that allows
very early and very broad review by the community independent of
what is committed to writing in particular documents and alerts
to issues that had best be considered and resolved earlier
rather than later.  Perhaps we should review our priorities for
plenary time and try that again.

best,
   john