ietf
[Top] [All Lists]

Re: Uneccesary slowness.

2005-05-19 04:42:11
Bill,

Bill Sommerfeld wrote:
On Wed, 2005-05-18 at 04:50, Brian E Carpenter wrote:


Would it be better if the process required an explicit request for
more time?


In the face of variable workload it makes no sense to expect
constant-time response from the IESG.

My understanding is that there is no load-levelling on the IESG agenda
-- documents ready for review go on the next agenda regardless of how
full it is.

A review body I'm involved with at Sun has a somewhat different approach
to reviewer time management.

Oversimplifying wildly:  proposals are split into "fast-track" and
"full" review.

Fast-tracks are reviewed by email with a confirming step in our
meetings.

If the email discussion converges we typically spend about 15-30 seconds
of meeting time per fast-track.  if the discusion doesn't converge, it
may get turned into a full review.

I've been involved in similar mechanisms.

To get some facts on the table, in the last IESG telechat,
14 documents were on the agenda. Here's how the time was spent:

1 minute each: 5 documents
2 min. : 3 documents
3 min. : 2 documents
4 min. : 1 documuent
5 min. : 2 documents
7 min. : 1 document.

for a total of 38 minutes. The IESG typically spends a lot more time
on chartering discussions and complicated management issues than
on document review. Our practice is to delegate the resolution
of discusses to the document shepherd.

We sharply limit the amount of meeting time we spend discussing
fast-tracks, and also limit the number of full reviews per meeting.

That is a serialization bottleneck right there.


Because the full reviews are scheduled at least a meeting or more in
advance into a specific time slot within the meeting, the folks making
the proposals can attend the review meeting/concall and can often
quickly resolve issues which in IESG terms might wind up as a DISCUSS.

Only if the protagonists happen to be available, which is low probability
in the IETF case. And it only works if the DISCUSS is really a request
for clarification; those very often get resolved before the telechat.
If it is something that requires a WG consensus, there is no way it can
be done during the telechat.

Bottom line, I dodn't think the solution lies here.

   Brian


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



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