18 months

[Brian E Carpenter]

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
> >
> >

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland