[vmeet] Comments on today's vMeet webex session

Dave CROCKER <dcrocker@bbiw.net> Fri, 24 April 2009 17:54 UTC

Return-Path: <dcrocker@bbiw.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 0495C3A705F for <vmeet@core3.amsl.com>; Fri, 24 Apr 2009 10:54:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 KMe2hrKaCJ8R for <vmeet@core3.amsl.com>; Fri, 24 Apr 2009 10:54:58 -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 1955E3A6B49 for <vMeet@ietf.org>; Fri, 24 Apr 2009 10:54:54 -0700 (PDT)
Received: from [127.0.0.1] (ppp-67-124-88-232.dsl.pltn13.pacbell.net [67.124.88.232]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n3OHu62J032154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <vMeet@ietf.org>; Fri, 24 Apr 2009 10:56:12 -0700
Message-ID: <49F1FD36.4010208@bbiw.net>
Date: Fri, 24 Apr 2009 10:56:06 -0700
From: Dave CROCKER <dcrocker@bbiw.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: vMeet@ietf.org
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]); Fri, 24 Apr 2009 10:56:12 -0700 (PDT)
Subject: [vmeet] Comments on today's vMeet webex session
X-BeenThere: vmeet@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Fri, 24 Apr 2009 17:54:59 -0000

These are my own comments about today's two-hour session.

A vigorous round of thanks to Eliot Lear for setting this up, as well as 
patiently demonstrating and explaining Webex features.  As he noted, he's not 
part of the Webex product team but rather is an extended user.  I think this 
made his comments less canned and more salient and maybe more candid.

And a vigorous round of thanks to the 12, or so, folk who participated.  I think 
we had enough people and enough kinds of discussion, debate, confusion, 
resolution, etc., etc., to give a reasonable taste of this using this tool real 
work.

John Buford posted a note suggesting an additional session that is primarily 
intended to give each participant a chance to be 'host', that is to control the 
room.  It does afford a different perspective than merely being a participant.

We will also try to set up sessions similar to today's, with other, similar tools.

It was noted that this was a strictly virtual meeting, with no face-to-face room 
component.  Hence, it was felt that this probably more like an online-only 
interim meeting than a face-to-face.  My own reaction about this assessment is 
mixed:  Eliot noted that the pattern of contribution actually matched some kinds 
of face-to-face working group meetings, and I agree.  While it's certainly true 
that a mixed f2f/remote meeting has its own dynamics, I think that this 
all-virtual session felt quite a bit like smaller, collaborative f2f wg meetings.

Any interesting tool in this space is going to have quirks.  Some will be 
distracting.  I think one of our challenges is to distinguish between core 
features vs. details of how they are implemented.  For example, Webex lets a 
participant raise their hand, but it doesn't indicate what order hands are 
raised in.  As the one calling on folks who raised their hand, I certainly would 
have preferred having them rank-ordered.  But while I think that hand-raising is 
an essential feature, I think the rank-ordering is more a matter of convenience 
than being essential

My point is that I hope we are all careful to distinguish between what is 
essential versus what is preferred.

Also predictably -- especially during the relatively early stages of an exercise 
like this -- is our jumping between comments about the specific tool we were 
using, versus comments about requirements for any tool.  The scenarios/goals 
list is meant to be generic:  what kinds of meeting capabilities do we want and 
how do we want to use them, versus whether a particular tool can satisfy a 
particular scenario.

The issue of meeting participation "role" has come up a number of times, such as 
between passively lurking, versus occasionally asking a question, versus giving 
a presentation, versus actively engaging in a discussion/debate.  Each implies 
some very different functional capabilities. While it's tempting to think of 
these as explicitly different memberships, chosen at the time of joining, I hope 
folks will think of how fluid real IETF meetings are, in terms of the roles 
people switch between.  Any lurker can suddenly become an active and important 
component of an intense debate.  We want to be careful we don't lose that.

Having a lot of mechanism mediating a meeting clearly requires that process and 
content be delegated to different people.  So, for example, at one point I was 
trying to conduct a discussion about scenarios and take notes of people 
comments, and I completely missed the fact that some folks were raising their 
hands.  We need the person who is facilitating the meeting process always to be 
different from any of the folk who are actively engaged in the discussion and 
different from the person(s) taking notes.

Thomas Narten is lobbying for an effort to develop a document on best practices. 
  This highlights that any tool we use still requires some care among the 
participants:  for that matter, even when there is no tool.  The usual example 
is that the way a speaker should talk (pace, language, volume) is different when 
non-native speakers are present, and even now, we attend to this too little. 
Adding heavy computer mediation increases the issues and the need for each 
participant to be careful.  A BCP on this sounds like it would be useful.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net