ISSUE: Goal of problem-statement document

[Spencer Dawkins]

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
>