Re: Front-end delays

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Lucy E. Lynch wrote:
Excuse top posting, please.

Many of the issues related to WG progress can be managed using the
excellent web tools provided at tools.ietf.org - see for example:
http://tools.ietf.org/wg/ccamp/

This site makes review quick and easy. Clicking on a draft title
gets you not just txt but a nits check and diffs from any previous
versions. See:  draft-ietf-ccamp-gmpls-ason-lexicography-02.txt

The top menu includes links to email the WG Chair(s) and:
Drafts | Agendas | Minutes |  Charter | List Archive
making it easy to review the Charter, check the list archive for
comments on a given draft, and review minutes etc.

These tools are useful, but don't track (for example) working group last calls. They don't even track interim meetings, at least based on my limited checks.

Finding list comments by draft in a mailing list works fine when a working group focuses on one main spec, but there are many working groups that progress literally dozens of specs at the same time. Just take a look at the active I-D list for SIPPING and AVT, to cite two groups I'm familiar with. In some cases, subject headers contain the draft title - in most cases, they don't and they may use such helpful subject headings like "Last call comments" or "IETF 62 discussion".

(Besides the problem that a search facility for the mailing list archives is non-existent. Not a problem for a small mailing list, but try flipping through the WG list which generates hundreds of messages a month and has been active for five years plus...)



There is also a link to a Draft dependency graph at the top of the drafts
page. The graph shows you where cross area review might help a draft
progress, as well as highlighting blocking drafts, expired work, etc.

If every WG had and used such a page to triage work based on blocks and
cross-area dependencies things might move faster. Authors (and WG
reviewers) can also use the nits/diffs/and list archives to make sure that
individual documents are in shape to move forward.

I'm sorry to say that for the drafts that took years to progress, 'nits' problems were not exactly the reason. I wish it was that easy to fix.



Getting people to use the tools is a seperate issue. Just another mash
note from a tools.ietf.org fan...

These are all useful tools and I commend whoever is working on them. They are just not quite up to the task to address the problems I mentioned, in my opinion.



Lucy E. Lynch 				Academic User Services
Computing Center			University of Oregon
llynch  @darkwing.uoregon.edu		(541) 346-1774

On Tue, 14 Jun 2005, Henning Schulzrinne wrote:


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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]