ietf
[Top] [All Lists]

Re: Radical Solution for remote participants

2013-08-16 10:57:28
Hi,

+1

On Fri, Aug 16, 2013 at 1:59 AM, Joel M. Halpern 
<jmh(_at_)joelhalpern(_dot_)com> wrote:
Maybe I am missing something.
The reason we have face-to-face meetings is because there is value in such
meetings that can not reasonably be achieved in other ways.
I would like remote participation to be as good as possible.  But if would
could achieve "the same as being there" then we should seriously consider
not meeting face-to-face.

Being at the IETF for a week is never going to be the same experience
as participating remotely at a computer for a couple 2 hour meetings.
A lot of work gets done outside the official WG meetings because
the right people can all be in the same room at the same time.

IMO we should be using more virtual interim meetings,
not trying to turn our f2f meetings into remote meetings.
WGs should meet virtually at least once a month for 2 - 4 hours
to make progress on issues same as via the WG mailing list.
Everybody is a remote participant in a virtual interim so
the problems with interfacing to a live meeting go away.

Conversely, until the technology gets that good, we must not penalize the
face-to-face meeting for failures of the technology.

Yours,
Joel


Andy


On 8/15/13 9:48 PM, Mark Nottingham wrote:


On 13/08/2013, at 11:00 AM, Douglas Otis 
<doug(_dot_)mtview(_at_)gmail(_dot_)com> wrote:


1) Ensure exact digital interfaces driving projectors are fully available
remotely.


That would be fantastic, if feasible. Much simpler than sharing through
software.


2) Ensure Audio access requires an identified request via XMPP prior to
enabling either a remote or local audio feed.


Hm.


3) RFI tags could facilitate enabling local audio feed instead of an
identified request via XMPP.


Could be quite interesting; many conferences now provide attendees with
RFID tags...


4) In the event of the local venue loosing Internet access, the device
regulating A/V presentations must be able to operate in a virtual mode where
only remote participants are permitted to continue the meeting proceedings.


That seems… extreme.

5) Important participants should plan for alternative modes of Internet
access to remain part of the proceedings.


Not exactly practical.


6) Develop a simple syntax used on XMPP sessions to:
1) signify a request to speak on X
2) withdraw a request to speak on X
3) signify support of Y
4) signify non-support of Y
5) signal when a request has been granted or revoked.  For local
participants this could be in the form of a red or green light at their
microphone.


The W3C does much of this already with IRC bots, e.g.:
   http://www.w3.org/2001/12/zakim-irc-bot.html

(also can pick a scribe, track an agenda, etc.)


7) Develop a control panel managed by chairs or their proxies that
consolidate and sequence requests and log support and nonsupport indications
and the granting of requests.


See above (I think).


8) Chairs should be able to act as proxies for local participants lacking
access to XMPP.


Not practical, unless they delegate.


9) Chairs should have alternative Internet access independent of that of
the venue's.


Seems extreme.


10) Establish a reasonable fee to facilitate remote participants who
receive credit for their participation equal to that of being local.

11) The device regulating A/V presentations must drive both the video and
audio portions of the presentations.  A web camera in a room is a very poor
replacement.

12) All video information in the form of slides and text must be
available from the Internet prior to the beginning of the meeting.


Cheers,


--
Mark Nottingham   http://www.mnot.net/