ietf
[Top] [All Lists]

Re: Reasons for delay

2005-06-16 05:57:54
Spencer Dawkins wrote:

(3) Exhaustion: Far too many drafts linger years in 90%-completed state, while the authors or the WG has moved on to other things. It would be interesting to take a look at long-delayed drafts and see how much they have really changed as a function of time. My guess is that the change rate goes towards one-sentence-per-month or less.


Yes, and this interacts badly with document quality as community "best practices" change over time - what was recommended two years ago may now be deprecated, but most people don't notice the conflicts.

Plus, it becomes very difficult for authors and the WG to do context switches. Personally, I find it very difficult to work on a draft that I haven't looked at in a year - it takes a while to re-familiarize oneself with the issue, dig up old emails and not introduce new mistakes. This is exactly the same problem that some of us know from trying to debug our own code after a long absence.

This effect tends to be self-reinforcing: Knowing that it will be painful means that I'll be less likely to work on the draft.

One of Keith's better suggestions was showing "external review" as a WG deliverable. I don't know that this is required in all cases, but if an AD says "and you need external review for this document", I would believe that.

And this information should be captured somewhere.


This interacts badly with (4). A number of IETF plenary presentations have shown statistics like "half of the I-Ds were submitted within two weeks of the I-D cutoff(s)". The resulting blizzard of text makes it even less likely that any specific I-D will receive careful scrutiny outside the WG (and, maybe, outside the list of authors).

On the other hand, I've heard from a WG chair that he doesn't schedule WGLCs except during that pre-cutoff time, as that's the only time people seem to be willing to read drafts and submit comments.




One possible fix, easy to try - WGs seem to set their milestones based on IETF meeting dates ("we'll do WGLC before Paris"). If WGs moved their milestones a month earlier, WG chairs and ADs would have more opportunities to notice problems and resolve them, and (one hopes) milestone I-Ds would not get lost in the general onslaught at I-D cutoff time.

The pre-scheduled WGLCs I suggested may help as well.


(b) It's likely that at least some of the document authors stop caring about their documents in any meaningful way, five years later, so this can lead to further delays and AUTH48 confusion (I participated in an AUTH48 process for a five-year-old Internet-Draft that generated 16 "final versions" and 142 e-mails between authors and the RFC-Editor).

Right - this then leads to tremendous pressure to "clean up" the draft in AUTH48, with very unsatisfying results for all parties.

In many cases, authors have changed companies and work fields in the 3-5 year period. It's hard to get cycles out of an author that no longer works for a company that has any interest in the document topic.

(a) As Lars-Erik points out - almost every one does WGLCs, but WGLCs are not a mandatory part of the standards-track process. Do we actually need to give WGs this freedom, especially for specifications that are (theoretically) coming out of the WG?

I have yet to see a WG draft that did not receive a WGLC (or two...). I don't see the value of worrying too much about these oddities, or is there some philosophical objection to WGLC in some WGs?



(b) In the SIP community, the WG chairs are rate-limiting the number of active WGLCs at any given time, so something like Henning's suggestion is already happening in some parts of the IETF.

Let's just say that bursts of enthusiasm and scheduling are followed by years of no pre-scheduled WGLCs. In general, I've found that the biggest problem of trying project management tools in the IETF is the predictable cycle:

(1) WG looks at charter - "Ohmygod - we're three years behind schedule".

(2) A burst of energy erupts, with a couple of WGLCs scheduled.

(3) We pat ourselves on the back.

(4) We go back to the familiar ways since the mechanisms, culture, supervision and tools don't exist to make this part of the standard operating procedure.

Henning






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



<Prev in Thread] Current Thread [Next in Thread>