Design Teams (was "v 1.2, IETF material")

[Gary Scott Malkin <[e-mail]>]

Marshall,

> Any attempt to require design teams to produce charters, minutes, etc.,
> will result in there never being any design teams.  It is hard enough
> trying to produce decent technology without having to keep a detailed
> record of why each decision was taken.

I can't agree.  If a line of logic was followed to reach a decision then
it can be written down.  If it was a leap of faith then you've got no right
to dismiss someone else's argument out of hand.  Take a look at Router
Requirements.  It has discussion sections for every controversial issue
describing the lines of reasoning.

> Further, experience shows that some people (Frank's J-Random) just don't
> read or listen.  You could drop a truck-load of work on them and it just
> wouldn't help.  On the other hand, if the design team produces a well
> thought-out and comprehensive spec, then competent people in the working
> group can make their own evaluations of the the quality of the work.

I too have run into people who don't read documents until long after
it's too late.  But that doesn't necessarily mean that their comments
aren't needed, just irritatingly belated.  The problem with design
teams is that finished documents are often presented as a fait
accompli.  Sure there is an open review, but it can be damn hard to
get changes made.  I know this to be true because I've been through it
myself, many times.

> You have a choice: you can get results, or you can play process games.
> The whole point of design teams was to foster an environment in which
> real work could get done.  Trying to turn design teams into mini-working
> groups will just add another layer of process.

It doesn't have to be that black and white; there is room for compromise.

----------------------------------------------------------------------
Gary Malkin                         Humankind asks: "Why are we here?"
[phone]                      Earth responds: "PLASTIC, morons."