Subject: Re: Uneccesary slowness.

From: Bob Braden <[email-masked]>
Date: Mon, 23 May 2005 11:06:32 -0700 (PDT)

*> time for vacations, sick leave and day job, etc.  (My intuition is that 
  *> it shouldn't take more than about 2 days to get through each part of the 
  *> process if nothing else were in the way.

Which universe are you living in?

Bob

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Steve Crocker <[email-masked]>
Date: Mon, 23 May 2005 14:39:09 -0400

Well, I'm probably living in a very old universe, which may be out of date.

What numbers are more appropriate?

Thanks,

Steve

---

From: Michael StJohns <[email-masked]>
Date: Mon, 23 May 2005 14:51:30 -0400

Bob/Steve -

I think some static got in the way.

Bob - I think what Steve meant was that for any given product absent any 
other competing demands on time, it should take "n" days for stage "x".

Project management 101.

Project management 102 is about dealing with a lot of competing demands and 
still getting work through. E.g. avoiding "thrashing".

:-)

Mike

At 02:39 PM 5/23/2005, Steve Crocker wrote:
>>   *> time for vacations, sick leave and day job, etc.  (My intuition is 
>> that   *> it shouldn't take more than about 2 days to get through each 
>> part of the   *> process if nothing else were in the way.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 May 2005 14:55:46 -0400

>>>>> "Steve" == Steve Crocker <[email-masked]> writes:

    Steve> Well, I'm probably living in a very old universe, which may
    Steve> be out of date.  What numbers are more appropriate?

I'd think two months would be doing good for IESG processing.  That
includes AD review, IETf last call, telechat delays and a bit of slop
for interaction with the authors.  However that's time to travel
through the queue, not actually time spent on that document.

Because of the delays involved with telechats and last call, getting a
WG document done in less than a month of wall time or an individual
document done in less than 1.5 months is very unlikely.

---

From: Steve Crocker <[email-masked]>
Date: Mon, 23 May 2005 14:59:13 -0400

Sam,

Thanks.  The IETF last call and scheduling of telechats are visible and 
understandable.  What's the figure for time for AD review?

Steve

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 May 2005 15:25:10 -0400

>>>>> "Steve" == Steve Crocker <[email-masked]> writes:

    Steve> Sam, Thanks.  The IETF last call and scheduling of
    Steve> telechats are visible and understandable.  What's the
    Steve> figure for time for AD review?

I'm not the best person to ask; my sample set is small.

It depends a lot on a document.  I can often do a document in in two
hours if it is reasonably short and I understand the technology and
the document quality is good.  I have one document languishing
somewhat in my queue because I need to block out an entire day for it
and finding a full day to work on one document is hard.

Keep in mind that AD review can easily have round trips with the
authors.

Also, as you are well aware, finding the time among all the other
things is difficult.

I would say that accomplishing AD reviews in a week of real time would
be doing good; two weeks would be fine.  Some documents will take
longer.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 May 2005 15:25:25 -0400

---

From: Steve Crocker <[email-masked]>
Date: Mon, 23 May 2005 15:39:10 -0400

"I have one document languishing somewhat in my queue because I need to 
block out an entire day for it and finding a full day to work on one 
document is hard."

I'm guessing that this sort of situation arises when you have less 
familiarity with the work or the document is particularly troublesome. 
I wonder if there's a way to identify this in advance and treat it 
differently.  Lumping the well prepared and easy to process documents 
into the same bin as the ill prepared or difficult to process documents 
could be hiding some important factors that might benefit from closer 
analysis.

Steve

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 May 2005 11:35:18 +0200

Steve,

No doubt, but that problem doesn't go away with increased parallel
processing. If we're talking about, say, a 100 page MIB, where the
MIB doctors do provide excellent parallel processing, there is still
going to be the problem of the chosen reviewer cutting out a full
day to grind through the document - and quite possibly needing to
read other documents as well, to understand the first one.

If the IETF wants thorough technical review by people other than
a document's protagonists, it *will* cost queuing time, whether the
people making those reviews are called "AD" or something else.

    Brian

Steve Crocker wrote:
> familiarity with the work or the document is particularly troublesome. I 
> wonder if there's a way to identify this in advance and treat it