Re: [vmeet] Supporting interim meetings

Dave CROCKER <dhc@dcrocker.net> Thu, 14 May 2009 17:41 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: vmeet@core3.amsl.com
Delivered-To: vmeet@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B37003A705A for <vmeet@core3.amsl.com>; Thu, 14 May 2009 10:41:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.188
X-Spam-Level:
X-Spam-Status: No, score=-2.188 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q1wl6Px6y1f5 for <vmeet@core3.amsl.com>; Thu, 14 May 2009 10:41:56 -0700 (PDT)
Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id BCB433A6F19 for <vmeet@ietf.org>; Thu, 14 May 2009 10:41:48 -0700 (PDT)
Received: from [127.0.0.1] (adsl-68-122-70-68.dsl.pltn13.pacbell.net [68.122.70.68]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n4EHhDjh013262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 May 2009 10:43:19 -0700
Message-ID: <4A0C5831.5060801@dcrocker.net>
Date: Thu, 14 May 2009 10:43:13 -0700
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: John Leslie <john@jlc.net>
References: <20090507175356.GG32848@verdi> <4A08BC3C.9070302@dcrocker.net> <200905121242.n4CCgnj4013481@cichlid.raleigh.ibm.com> <20090513025653.GD14375@verdi>
In-Reply-To: <20090513025653.GD14375@verdi>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Thu, 14 May 2009 10:43:19 -0700 (PDT)
Cc: dcrocker@bbiw.net, vmeet@ietf.org
Subject: Re: [vmeet] Supporting interim meetings
X-BeenThere: vmeet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF remote participation meeting services discussion <vmeet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vmeet>
List-Post: <mailto:vmeet@ietf.org>
List-Help: <mailto:vmeet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vmeet>, <mailto:vmeet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 May 2009 17:41:57 -0000

John Leslie wrote:
>    1) Right now, a phone bridge is essentially state-of-the-art for
> audio. Most everything else flunks Brian's 150 msec test.

This raises two different questions:

1.  Is passing that test really mandatory?

2.  Is it true that no VOIP capabilities pass it today?

I suspect the issue here is going to be about statistics.  How often is there a 
(serious) problem, not whether there is one.  People can be pretty adaptable, 
and cell phone have taught us all to be particularly forgiving of poor voice 
channel characteristics.  There are limits, but they are not necessarily as 
strict as the discussion on this list seems to suggest.


>    2) Advance availability of charts is egregiously poorly enforced.
> Where it is enforced it leads to charts which only exist in the
> presenter's imagination. Preparation of slides is the best exercise
> for most presenters to organize their thoughts -- and, alas, the
> last minute is when it, almost by definition, happens.

>    3) Best Practices simply don't get followed, unless somebody is
> constantly nagging.

On both of these point, we should note that the community does, in fact, follow 
certain rigid requirements.  I-D submissions deadlines, meeting registration 
deadlines, etc.  When a requirement is enforced, we conform.  We are sloppy 
about enforcement only when the requirement isn't rigid. When the consequences 
of non-conformance are clear and firm, we tend to conform quite readily.


>>> I think we could get away with a relatively modest initial
>>> requirement.  Say, 30 people?  That will limit applicability for the
>>> larger and more active working groups.
>> ... 
>>
>> Careful about predicting future participation based on the past,
>> especially if travel issues are now motivating more to stay at home.

This is certainly an important point, but it's the best we have to base our 
estimate on, now.


>    Agreed; but it's a reasonable starting point...
> 
>>> 1.  Meeting management -
>>>      a)  Ability to queue up participants, as if at a microphone
>>>          For meetings of a group that can easily be 20-40 people,
>>> with relatively little history of group collaboration, the job of
>>> meeting management is vastly easier when there is some functional
>>> help for coordinating who wants to speak next.
>> It may also be necessary for basic fairness. Folk can get mighty
>> unhappy if it seems to them that they are being treated as second
>> class citizens in the microphone queue relative to others.
> 
>    I regard this as very important; but I'm not happy with any
> automated functions I've seen in a telepresence package. A simple
> plaintext list of folks who have asked to speak (and not given up
> their place or spoken) is what all participants should have.

I don't understand what you are specifying.  How would it work and how would 
that be easy to use?


>    I consider this important enough that someone should have the role
> of maintaining it if we can't get it automated.

Again, in terms of broad-based, on-going use I believe we cannot settle for hack 
solutions.  Let's be careful that we do not do the online equivalent of 
requiring each speaker bring their own public address megaphone.

The more manual the mechanism, the more hassle will be its use. To get work done 
on the scale we are seeking, we cannot have the tools impose hassle, IMO.  And 
just because one or another of us is willing to put up with that hassle does not 
make it reasonable to impose on everyone else.


>>>      b)  Ability to shift who is presenting
>> While I agree this is necessary, I am not sure that we require tools
>> to support this. Charts in advance work pretty well in practice. But
>> not at the expense of limiting participation if the bandwidth
>> requirements are too high.
> 
>    It is a weakness of many of the available tools that they expect
> every participant to have the same available bandwidth. This simply
> isn't the world we live in. Anyone without sufficient bandwidth to
> support a real-time display should be able to turn that bandwidth
> demand off.
> 
>    As a general rule, we shouldn't be designing for the lowest
> (bandwidth) common denominator.

The lowest common denominator is 9.6kbps, or worse.  We aren't designing for that.

But a rule of egalitarian access is that is pushes for a norm that is 
considerably below what is available to some.


>>> 3.  Shared slide presentation
>>>      Shipping powerpoint files around is tolerable only for special
>>> cases, I believe.
>> I disagree. I think shipping charts around in advance has benefits
>> too.
> 
>    When they actually _get_ shipped, I agree.
> 
>> Doing everythig at the very last second (especially for a meeting
>> that is schedule far out in advance) does not necessarily result in
>> good meetings and/or good presentations. And it can actually be quite
>> useful to skim a presentation in advance before a talk begins.
> 
>    But last-minute changes, even changes _during_ the presentation
> are the nature of the beast. I agree with Dave.

There was some push-back about the suggestion for including a white-board 
function.

I have certainly been in meetings where text was created collaboratively and in 
real-time.  Charter-bashing is perhaps the most common example.

Whether that is through a "shared whiteboard" or simple broadcast powerpoint 
revisions is secondary, IMO.  But we need to be able to have materials 
changeable in realtime through collaborative efforts.


>    My own concerns:
> 
> 1) Participants need to figure out who's speaking. There are many ways
>    to help them, but it deserves to be high among our concerns.

Good point.  Yes.


> 2) Snapshots of slides and/or whiteboards can help keep folks on the
>    same page. Things change during meetings, and it's very easy for
>    human memories to diverge.

I'm not clear what capability you are suggesting, beyond what's already been listed.


> 3) There really should be a "record" of a meeting. This is, admittedly,
>    an art form; but folks don't want to listen to an audio recording
>    or even read a transcript of every word spoken. It very likely would
>    be helpful if such a record could be visible in real-time to some
>    participants. (I don't claim to be particularly good at doing this,
>    but there _are_ folks who are good at it.)

We currently have a jabber transcript, with a scribe, and a separate note taker. 
  Are you suggesting something beyond these?


> 4) Every meeting should create "action items" that someone is responsible
>    for following-up on. (Some are group items; some private.) These
>    deserve far more visibility than they usually get.

What sort of tool is involved in this, different from what is already in use?


> 5) Separate applications is very likely better than one integrated
>    application. Webex drives me crazy by taking over organization of
>    the screen. I don't want anything else interacting with my Jabber
>    application.

Interesting point.  The tradeoff is that tools that aren't integrated each 
require separate registration and management.


> 6) VoIP-as-we-know-it doesn't meld well with POTS conferencing. Until
>    VoIP can have consistent delay -- ideally Brian's 150 msec, but
>    definitely under 500 msec -- we'll probably have to do without it.

The lengthy discussion about these details was facinating, but too many people 
have had entirely too many, acceptable experiences with group conversations that 
were a mix of telephone and voip.


> 7) Learning curve is way too high for most telepresence packages.
>    Folks simply _won't_ learn how to use them effectively. Formal

Concern about the learning curve is certainly warranted.  However we need to be 
careful about firm, pre-hoc assertions of what is and is not acceptable in terms 
of what the human factors folk call usability.



-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net