Brian E Carpenter
brian at hursley.ibm.com
Mon Jan 6 16:58:47 CET 2003
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.
Harald Tveit Alvestrand wrote:
> --On søndag, januar 05, 2003 09:45:08 -0800 Dave Crocker <dhc at dcrocker.net>
> > 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.
> 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.
> > 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
More information about the Problem-statement