Re: Myths of the IESG: Reading documents is the problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Myths of the IESG: Reading documents is the problem



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



_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf




Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.