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

[Bob Stewart <[e-mail]>]

>Bob Stewart said, in effect, that perceptions of impropriety will
>always be there, and so we should not worry about them.

I wouldn't say to ignore perceptions, just that managing them should be of
less importance than doing something real.  We need technical development
first, public relations second.  If you put public relations first, you'll end
up with leaders that do little but convince you that they're doing what you
want and need.  The U.S. Congress comes to mind.  Actually (unfortunately)
they do more than nothing, generally motivated by perceptions rather than
wisdom and quality.

My comments were intended more in the vein that some people won't be pleased
no matter what you do, so don't expect to please everyone, with quality or
perceptions, and, when in doubt, go for quality.

>Bob's
>analysis is incomplete insofar as it centers on personalities and
>motives: it perpetuates the myth that somehow anybody who criticizes
>the technical work of a design team or questions the conduct of a
>working group evaluating a team contribution is motivated only by envy
>or dislike of the design team members. 

People usually criticize because they don't understand or have different
understanding or goals.  I find it more useful to assume good, honorable
motivations.  That makes me easier to fool, but more often right about
people's intentions.

>It is true that we must work to reduce bureaucratic delays that are
>introduced by our structure, and we must streamline our procedures so
>that they, in and of themselves, are not a source of inappropriate
>delay, but attempting to reduce delay by abbreviating working group
>discussions is DEFINITELY the WRONG answer. We should be streamlining
>our formal procedures in order to allow for LONGER working group
>discussions.

Is there some limit to how long you spend letting everyone have their say?  As
we grow, we'll always be adding new people, who will bring with them the
recurring bad ideas.  Are we doomed forever to repeat the same discussions so
we won't appear to be favoring the old boys?  When I first got started in
SNMP, I thought the original authors were Internet old boys.  I was informed
otherwise.  I betcha now there are people who think I'm an Internet old boy,
or at least an SNMP old boy, dedicated to preserving the old ways.

>Our success owes most to the "community spirit" -- our faith in each other --
>of which Marshall Rose spoke so eloquently in Washington. Not to our ability
>to tell time.

That success also came from a much smaller community, with a slower influx of
new people, more homogeneous goals, and more trust among the members.  People
know each other better in a small town, and more easily adjust for one
another's foibles.  Mistrust, distance, and complex laws come with large
communities. 

>Conclusion: The notion of Design Teams is largely irrelevant and does
>not warrant pursuit as part of the poised effort. Design Teams have
>only become an "issue" because they have been coincidently associated
>with cases in which quality technical deliberation may have been
>sacrificed to haste.

I believe Chuck has an important point.  It is not as important that we
formalize the behavior of design teams as it is important that we understand
how to run fair, open, productive working groups.

>Moral: don't set artificial time limits for working group
>deliberations. If WG members are motivated to work cooperatively, and
>the WG has an able chair, any truly important schedule will probably
>be met.

And if the chair is not able, or the members are not cooperative...

>P.S. Bob Stewart was concerned about the judgement of history on the
>SNMPV2 WG. My (speculative) belief is that history may be more kind to
>the WG chair than it may to the AD (and others) who bear much of the
>responsibility for (mistakenly) imposing time limits to begin with.
>History may deal most harshly with those who either seek to impose
>time limits gratuitously or to abuse them for some advantage.

I'll accept my share of heat on the time limit.  I believe in it, and, for
that matter, the working group has confirmed it at every call for consensus.
Timing is an important component of quality.  An otherwise outstanding
product, shipped too late, can easily be far outshone by an inferior product
shipped at the right time.  I'll resist the temptation to supply examples.

	Bob