ISSUE: Goal of problem-statement document

[Bound, Jim]

I agree with you Spencer.  If we have to have total consensus on root
cause it is death. I think when you see 5 or 6 bright people from
multiple vantage points say something is at the root it warrants at
least being on the list for now.

/jim

> -----Original Message-----
> From: Spencer Dawkins [mailto:spencer at mcsr-labs.org] 
> Sent: Sunday, June 08, 2003 12:45 AM
> To: problem-statement at alvestrand.no
> Subject: Re: ISSUE: Goal of problem-statement document
> 
> 
> Dear Randy,
> 
> I'm reading your note as carefully as I can, and see you are 
> asking that we understand needs and requirements well. I 
> agree, and want to focus on the definition of "well enough".
> 
> Speaking only for myself, I agreed with our text (and may
> have suggested it) because I strongly suspected that the 
> engineering alternative was discussing each problem, 
> determining its root cause, and agreeing on a prioritized 
> list of root causes before we did anything.
> 
> I would love to be wrong.
> 
> I can't speak for others, but my goal here was to avoid
> having to figure out what the IETF consensus was on a 
> prioritized root cause list before moving on any root cause. 
> This looked like death to me. I don't believe there are ANY 
> scope limits on discussions about the relative priority of 
> root IETF problems, unlike our normal engineering work.
> 
> So I thought developing a root cause list (which we have
> done, at least at some level) was sufficient, without 
> spending time trying to determine priorities. I thought this 
> was "good enough".
> 
> I would love to hear other opinions.
> 
> Spencer Dawkins
> 
> ----- Original Message ----- 
> From: "Randy Bush" <randy at psg.com>
> To: "Harald Tveit Alvestrand" <harald at alvestrand.no>
> Cc: <problem-statement at alvestrand.no>
> Sent: Saturday, June 07, 2003 4:21 PM
> Subject: Re: ISSUE: Goal of problem-statement document
> 
> 
> > >    We, in line with many contributors to the mailing list, do not
> > >    believe that the process of problem resolution will be helped
> > >    by continued rework of the root issues in what would probably
> > >    be a vain attempt to achieve any sort of consensus.  Instead,
> > >    the general tenor and scope of the problems identified will
> > >    provide a guide in setting up the processes needed to resolve
> > >    the problems and provide input to the resolvers.
> > 
> > i always found this part particularly amusing considering 
> it is being 
> > pushed by the same folk who so strongly push for a classic software 
> > engineering management view of the wg product process. how can we 
> > think we will produce a good result if we do not first define the 
> > needs and requirements well?
> > 
> > randy
> > 
>