Re: [vmeet] Suggestion

Dave Crocker <dhc@dcrocker.net> Fri, 08 April 2016 17:57 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: vmeet@ietfa.amsl.com
Delivered-To: vmeet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A586312D4FE for <vmeet@ietfa.amsl.com>; Fri, 8 Apr 2016 10:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-0g8PYqpI5m for <vmeet@ietfa.amsl.com>; Fri, 8 Apr 2016 10:57:28 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 007AF12D0EA for <vmeet@ietf.org>; Fri, 8 Apr 2016 10:57:27 -0700 (PDT)
Received: from [192.168.1.168] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id u38HvN9Q029040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 8 Apr 2016 10:57:23 -0700
To: Ray Pelletier <rpelletier@isoc.org>, "Joe Hildebrand (jhildebr)" <jhildebr@cisco.com>
References: <62592448-DE03-4FAA-9974-1DF2899CA02E@cisco.com> <640096FA-BD5A-4149-85D4-361323910EF0@isoc.org>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <5707F0FF.8050806@dcrocker.net>
Date: Fri, 8 Apr 2016 10:57:19 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <640096FA-BD5A-4149-85D4-361323910EF0@isoc.org>
Content-Type: text/plain; charset=windows-1252; 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, 08 Apr 2016 10:57:23 -0700 (PDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/vmeet/Yovd9hdTjj-8NH_6JHiUiVMAVqY>
Cc: "lee.howard@twcable.com" <lee.howard@twcable.com>, Brian Trammell <ietf@trammell.ch>, team@meetecho.com, Mirja Kuehlwind <ietf@kuehlewind.net>, "vmeet@ietf.org" <vmeet@ietf.org>
Subject: Re: [vmeet] Suggestion
X-BeenThere: vmeet@ietf.org
X-Mailman-Version: 2.1.17
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/options/vmeet>, <mailto:vmeet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 08 Apr 2016 17:57:29 -0000

On 4/8/2016 10:03 AM, Ray Pelletier wrote:
> I really like the idea of the chair cockpit.  For example, we could get Meetecho to pre-load the slides that have been loaded in to the tools site (and all of the associated drafts), have their laptop connected to both projectors, and have their laptop be the place where you navigate the decks.  The meetecho team was fantastically helpful this week, springing into action whenever you said their name in the jabber channel.  That could be made more discoverable in a tweaked UI.


In practical terms, this needs one person focused on running the meeting 
and a second person, sitting next to the first, running the meeting's 
integrated tech cockpit.

More generally:

      We should formulate basic operational scenarios for each relevant 
actor (chair running the meeting, chair operating the cockpit, 
presenters in the room, presenters not in the room, audience in the 
room, audience not in the room.

      And we should formulate templates for how they interact.

I think we are remarkably close to being able to make things work quite 
well.  Maybe not reaching the magical 'seamlessly', but quite well.

 From my experience this week, the biggest deficiency is queue 
management.  The virtual queue, for remote participants, worked 
usefully, but have in-room folk be in a separate queue creates a 
juggling problem operationally.  Things will get far simpler if/when  we 
figure out a workable way to get in-room folk also be listed in the 
virtual queue.[*]

I suspect there is also an issue with the virtual queue, in terms of 
remote hubs, if they also have in-room microphones.

Anyhow, defining the scenarios we want to support and targeting them is 
what we should do.  And if we want this to be real for IETF 100, we'd 
better target a serious dress rehearsal for IETF 98.

d/

[*] I suspect we are also going to want two or more cameras in a room, 
so that folk can see chairs, in-room speaker, and audience-at-microphone 
simultaneously.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net