The key sentence in what Sam wrote, IMHO, is
The more we do up front to
improve specs, the less time review takes.
If a document reaches the IESG in good shape, it leaves the IESG
much more quickly than one that's in poor shape. The single most
effective way to reduce IESG review time is to produce better
documents - and the criteria for "better" aren't secret, although
there is scope for a central place pointing to the various criteria.
I agree with Sam that raw reviewing time is not by any means
the main source of IESG load - although the fact that o(15) drafts
show up for review every two weeks, with the processing they require,
does add up to a large chunk of time. But certainly one of the
criteria for a proposed alternative review process is: how
much work does it actually divert, and does it add new processing
work instead?
Brian
Sam Hartman wrote:
We're' in the midst of an honest discussion about reducing IESG work
load. Personally, I think we've missed an important question
somewhere around here. What do IESG members spend their time on?
I don't currently know the answer to this question. I'm thinking of
ways to find out and hope to have suggestions in this area.
There seems to be a common perception that a major time sync for the
IESG is reviewing documents and writing up comments.
This does take time, but it is quite efficient. I do not expect to
find major time savings in increasing the efficiency of getting
information about protocol proposals to the IESG.
We tend to get very good at doing a first pass of a document and if
the document is well written building up an understanding from that
first pass. In general I and other IESG members I've discussed this
with can pick up the content of a document faster than I could by for
example reading a presentation about the document or having the
authors explain it to mee.
Writing up initial comments is also reasonably efficient.
There are approximately three levels of review. The simplest is
reviewing to find out what a document is about: the gola is to
understand the document well enough to know what technologies it
touches and briefly what it is trying to do. The second and most
common type of review is to have a fairly good understanding of the
document; understand all the conceptual bits although perhaps not all
bits on the wire. The third level of review involves going over a
document in fine detail, looking for internal inconsistencies or
missing details.
Each successive level of review requires more time. For me the
differences involve how much time I spend taking notes while reading,
how many passes over the document I need, how many times I need to
jump forward or reread a section and how many references I need to
follow. There is also some time required for thinking through
details. the IESG work load trains you to be quite efficient at each
level of review.
An interesting side effect of this is that proposals like RFC 3932
designed to encourage the IESG to review certain classes of document
in less detail may not have as much success as you would initially
think. It is more efficient in many cases to read a document for a
full review than it is to read for limited criteria. And if you read
the document in full, you're going to find all the comments you would
have found regardless of whether they were in scope for the review.
Even so, such procedures do have time savings in other parts of the
process. In particular I do support something like RFC 3932 both
because of time savings and because of other benefits.
So if reducing time spent reading documents is not likely to be a good
target for optimization, are there related activities that are
potential optimization targets? I think so. Many aspects of handling
comments could be optimized possibly for significant time savings
especially on the tail of the distribution. I also think that there
are many logistical/tools issues that could produce significant time
savings. Finally, time required to review a spec depends
significantly on the quality of specs. The more we do up front to
improve specs, the less time review takes.
--Sam
_______________________________________________
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