Re: Interim meetings - changing the way we work

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]