Re: Front-end delays

Henning,

Thank you for a series of reasonable suggestions.

My thoughts are inline.

Spencer


> 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:
Whether "the main problem with timeliness is now in the WG process 
itself" is true or not, it is worth removing systemic sources of delay 
in the WG process.
> (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.
I like this suggestion. The gotcha is that "I-D creation" is not a 
one-step process, as many WGs start out with individual drafts that 
get renamed, and even combined, as they are adopted as WG drafts.
If your suggestion is "once the I-Ds have been adopted as WG I-Ds for 
a charter milestone ...", I think this would work well - and would 
also point out the milestones with approaching dates where the WG has 
not even agreed on baseline text.
There is one missing aspect to this - WG charters aren't consistent 
between "the WG thinks we're through" (we requested publication) and 
"the IETF thinks we're through" (the document has been approved for 
publication). We give WGs and ADs a lot of flexibility in specifying 
milestones - do we need this flexibility? If charters said, "we have 
three dates for each document - WG draft adopted, publication 
requested, approved for publication", and tracked these dates, we 
would know a lot more about where the delays in the process are than 
we know today.
> (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).]
As you say, this is an obviously good thing to do, given (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.
Two points here -

The IETF face-to-face meeting is supposed to be our high-bandwidth 
exchange opportunity, so reviewing this schedule, with color coding, 
can also help us focus on what documents need our attention. This 
could also be a time for editors to say, "I need help", or even, "you 
need another editor".
A number of WGs are in constant tension between the current charter 
deliverables and adopting new work items. If a WG can say, "look, 
we're all green, except for two yellow documents that we have a plan 
to recover", that's got to help an AD agree to a new charter item.
> (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.
Back in the days of 40 or so APPS area working groups, the APPS ADs 
presented their report card for the APPS working groups at an APPS 
Open Area meeting, usually on Monday morning. I believe their 
classification was something like "on time", "late, but making 
progress", or "lost in the weeds". We probably don't need a 
quantitative scale for this - simply assigning colors would give the 
WGs a heads-up about what their ADs think, and how much "attention" 
the WG is likely to get in the next meeting cycle.
> 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.
I can't believe we don't track original planned dates plus current 
forecast dates now. We also lose all track of when milestones were 
completed, because the dates are replaced by DONE. I would like to see 
this happen.
> 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


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