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