Tony Hain <alh-ietf(_at_)tndh(_dot_)net> wrote:
If people disagree about the requirements to start with, it is very
hard to get consensus about any proposed solution.
Let me get back to that...
It becomes a zero-sum when it is a beauty contest or competing
implementation biased "one size fits all" outcome.
Almost inevitably, by the time we have enough folks to form a WG,
there is a potential "solution" nearing completion. In fact, more often
than not we don't form the WG before it's complete. Many folks say that
our "successful" WGs are those where the solution exists before we
start...
Remove the "one-size-fits-all", or otherwise constrain the requirements
to a set with consensus (yes that means more requirements documents),
and you reduce the chance of a zero-sum outcome.
Constraining the requirements is likely the secret.
But human nature goes the other way.
Folks with a "solution" honestly believe everything it does belongs
in "requirements". Folks without a solution (yet) propose "wish-list"
requirements. It's _so_ easy to just throw them all into the document.
But _this_ is the time when it's easiest to put areas of contention
out-of-scope.
So I must disagree with Tony: if people disagree about requirements
early on, it's the perfect time to work out how to constrain them.
Insist on "one-size-fits-all", or skip the requirements document, and
you almost ensure a zero-sum fight.
There are _many_ cases (in our history) without a requirements
document; yet we managed quite nicely to constrain the requirements,
simply by agreeing that once we had something "good enough for a start,"
we should publish it and move on.
So I don't worry about "skipping the requirements document" -- I
worry about putting too much in it.
--
John Leslie <john(_at_)jlc(_dot_)net>