On 2/26/2015 6:53 AM, Ted Lemon wrote:
Actually, my experience is the opposite: mailing lists are
incredibly time consuming, because there are a few participants who
feel the need to repeat themselves over and over again in any given
discussion, and people aren't concise in their responses, nor
considerate of the burden their responses will impose on readers, so
there is a lot of reading, much of which is completely redundant.
On 2/26/2015 7:15 AM, Ted Lemon wrote:
If you "try to monitor" these working groups, it sounds like you
aren't an active participant. The meetings are supposed to be
minuted, so you ought to be able to monitor them by reading the
minutes.
Do you think we should optimize working groups for getting work done,
or for being monitored?
Folks,
The above two comments capture essential views shared by many, namely
that mailing lists are too inefficient and noisy for doing serious work
and that less-active participants aren't useful or that they are even
generally problematic.
Certainly the gist of both comments have been uttered many times over
the years, by many people.
And indeed there is an understandable basis for both points, and of
course, some legitimacy.
Mailing lists are unparalleled in their ability to support open
participation:
* Anyone with an email account can participate, and at their own
schedule.
* The asynchrony also can permit thoughtful consideration of ideas
that real-time simply cannot.
* Email is good for posting proposals, because of the thoughtful,
focused review it permits.
But they also suck for /discussion/ of deep issues. The inherently slow
(and even cumbersome) interactions get in the way of constructively
conducting protracted and/or complicated discussion. Real-time
voice/video (f2f or teleconferenced) is vastly better for anything that
looks like a protracted 'negotiation' or exploration of a difficult
topic -- that is, for problem-solving.[1]
And there often are mailing list participants who are especially noisy.
In general, they are more subject to moderation during a real-time session.
However there are two essential flaws with the resulting bias towards
real-time -- and especially f2f.
* Real-time -- and especially f2f -- is exclusionary. It
significantly restricts who can participate.
* Less-active participants occasionally offer insight and
suggestions that the more-active participants have missed. They
also provide a wider base of support for post-approval deployment
and use.
The formal means of resolving these tradeoffs is /supposed/ to be that
we always MUST rely on the mailing list for documenting proposed choices
and documenting rough consensus. This permits /everyone/ to comment.
* The formal IETF model says that real-time is essentially an
efficiency hack for getting foundational convergence on
understanding and choice, BUT NOT FOR FORMAL DECISION-MAKING.
Design teams were an explicit construct introduced in the IETF about 20
years ago, to note the benefits of small-group efficiencies that can
complement the full-group formalities.[2]
Unfortunately, IETF culture has shifted towards dismissing folk who are
less active, increasing the bias towards more narrow and/or complex
design thinking. And decreasing the breadth of community understanding
and support.
The enthusiasm of an active core is essential. But so it the
contribution and support of a much broader community.
This is the essential distinguishing factor, between the original
development culture in the IETF, versus other, classic standards bodies.
d/
[1] http://www.ietf.org/wg/agenda-minutes-procedures.html
and
Chapanis, A.,"Interactive Human Communication," Scientific American,
vol. 232, pp. 36-49, March 1975.
The Chapanis study observed that a real-time voice channel was the
most important for problem-solving.
[2] I think that RFC 1603 was the first documentation of IETF design
teams, capturing a practice of self-organizing core teams, that had
emerged in the IETF; as I recall that bit of the document produced some
controversy, specifically because they DTs are exclusionary.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net