Front-end delays

There has been a fair amount of effort in accelerating the tail end  
of the document process, i.e., after IETF last call. It is unclear  
whether this has succeeded (as there don't seem to be any published  
measurements), but I believe that the main problem with timeliness is  
now in the WG process itself. Each case is unique, but there are a  
disturbing number of modest-size documents that have taken 3 to 5  
years from first individual draft to RFC. In a separate message, I'll  
have more process- and people-oriented suggestions, but here are some  
simple things that would at least allow us to measure, and thus  
manage, delays:
(1) Problem: Currently, the mapping between charter items and drafts  
is often vague and those not intimately involved with the process are  
often left to guess which draft(s) meant to address which charter item.
Proposal: Once the I-Ds have been created, the charter is updated to  
reflect I-D names. This doesn't have to be done for every single  
draft, but doing such an update once for each IETF meeting seems  
easy, as there are no substantive changes.
(2) The I-D tracker should keep track of the charter deadline for  
each document so that the author and WG chairs can trivially see  
whether a document is on track or not. [This item can obviously be  
used to automatically generate (1).]
(3) At each WG meeting, it should be expected that after the agenda  
bashing, the delivery schedule for each draft is reviewed, maybe with  
a red (already out of schedule), yellow (likely to miss schedule) and  
green (possible/likely to meet schedule) indication.
(4) Just like the RFC editor and IANA provides statistics, each area  
should provide an overview of its status at the IESG plenary,  
indicating the major work items of each WG and whether the WG is  
generally on schedule or behind. Again, one could imagine a color  
coding, e.g., if 30% or more of the charter items are "in the red",  
the WG is flagged red.
Clearly, WG chairs and ADs could "game" the system to make the WG  
look on time, by continuously adjusting schedules or by having  
deadlines a decade out. That itself, however, would provide an  
indication that a WG is not meeting deadlines or is planning to be  
really slow. If one wanted to, one could indicate both original and  
current deadline for work items.
None of these items make things faster, but they would allow the IETF  
management to apply project management tools, such as reducing scope,  
replacing authors, or working group chairs, with some efficiency.  
More on hypotheses for why things are late in another note.
Henning



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf