Spencer Dawkins wrote:
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.
You can also read it as "we've tried to reform the tail end of the
process and we have either succeeded or run out of energy to do more" :-)
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.
Yes, that's what I meant. In some cases, this may also encourage early
conversion, as documents often linger in draft-somebody state long after
they have been adopted as draft-ietf (making them almost impossible to
find for outsiders).
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.
I agree that having three dates would be even more useful, particular if
they become standard "fields" in the charter "record". I'm happy to
start with one, which is a lot better than zero. Ideally, the delta-t
after the "submit to IESG" should be a lot more predictable, given the
IESG process reforms.
(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".
Side motivation: A little bit of public accountability can't hurt. If
somebody had gone out to design a design that discourages such
accountability, the current system seems to meet that objective very well.
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.
This also applies to authors. There are lots of authors that for
whatever reason (inability to estimate time available or resume padding)
volunteer for lots of drafts. Telling a prospective author/editor that
they have three red drafts and that they might not be the best person to
do this until these drafts have cleared can be helpful as well.
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.
I can well imagine a more detailed review during the area open meeting,
but I think that having a high-level review of WG status during the
plenary would be helpful. After all, this is the business of the IETF
and would, among other things, also encourage cross-area review and
maybe even yield some interesting questions from the floor, rather than
re-visiting the NAT issue for the twentieth time.
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.
This "DONE" also means that we have no easy way to look back and
systematically compare how realistic WG charter deadlines are. My
suspicion is that we meet less than 10% of our original charter
deadlines, but I have no way to prove this except trying to somehow dig
out mailing list archive messages at great tedium.
Henning
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf