18 months

[Brian E Carpenter]

By the way, I should also have mentioned that I agree with Harald.
We can't argue from subjectively perceived patterns. We need
solid facts - for example, a couple of years ago Henning Schulzrinne
(I think) analyzed historical data to show that over 8 years, the
average time to progress from a -00 draft to Proposed Standard RFC
had increased from 6 to 18 months. 

One could do further analysis. For example, is there any correlation
between the number of products claiming to support a given PS and
the number of months it took to produce that PS? That would allow
us to judge whether the subjective impression of a pattern is accurate.
Merely repeating one's subjective impression doesn't make it true.

   Brian

Brian E Carpenter wrote:
> 
> Seems to me that the correct answer is not an arbitrary time limit
> (see arguments advanced by Joel and Andy for example), but strong
> follow-up of the agreed milestones. A 19 month milestone isn't a
> problem. A *missed* 19 month milestone is a problem, because it can
> have knock-on effects on other milestones in the same WG, on other WGs,
> and on implementors and users.
> 
> That being said, I do agree with Dave that long, over-ambitious WG
> milestones are undesirable, and most of them should be significantly
> shorter than 18 months.
> 
>     Brian
> 
> Harald Tveit Alvestrand wrote:
> >
> > --On søndag, januar 05, 2003 09:45:08 -0800 Dave Crocker <dhc at dcrocker.net>
> > wrote:
> >
> > > Folks,
> > >
> > > Monday, December 23, 2002, 11:42:22 AM, you wrote:
> > > Joel> The assumption that long-winded working groups inevitably
> > >
> > > It would be great if we could design a process that was infinitely
> > > flexible and could adapt to every possible working group setting.
> > > However we are unlikely to achieve that.
> > >
> > > Therefore, if we argue for or against proposals based on individual
> > > examples or exceptions, we will make no progress.
> >
> > Dave,
> >
> > your statement as written seems to be that we should accept your perception
> > of a pattern without question, and that counterexamples are uninteresting
> > because they are exceptions or individual examples.
> >
> > I would suggest that in the absence of verifiable data, detection of
> > patterns is an exercise in theology, not engineering.
> >
> > So I would suggest that when you claim a pattern, you also mention at least
> > 3 specific examples that you think fit the pattern.
> >
> > We've been talking a lot about "success" and "failure" here, but rarely
> > saying which projects we consider in each category - probably because we
> > all know that not everyone agrees on the status of each project.
> >
> > But unless we stop pussyfooting, I think we cannot engineer for reality.
> >
> >                      Harald
> >
> > > My own discussion tried to claim some *patterns*.  A pattern does not
> > > require correlation of 1.0.  It does not require that there be no
> > > exceptions.  Rather it looks for dominant behavior.  One might even call
> > > it a rough consensus pattern.
> > >
> > > My claim is that the *pattern* of IETF performance shows that excessive
> > > time highly correlates with poor productivity and utility.
> > >
> > > If we build a process that is tailored for the exception, we are likely to
> > > retain the current IETF productivity problems. However that is not the
> > > IETF folks seem to want. So the question is how to improve productivity
> > > without losing the essential core to our process.
> > >
> > > d/
> > > --
> > >  Dave <mailto:dhc at dcrocker.net>
> > >  Brandenburg InternetWorking <http://www.brandenburg.com>
> > >  t +1.408.246.8253; f +1.408.850.1850