Re: Remote participation fees

[Simon Pietro Romano <[e-mail]>]

Hello John,

If we were serious (as we are) we'd keep on doing our best to improve remote participation support. Most of the functions you cite are, in my view, if not already there ay least VERY close to what can be defined a reliable service suite for remote participation. I encourage you to look back at past meetings and compare the remote experience you had from one meeting to the other in the last three years. Please don't tell me we didn't do giant steps towards a good service. And when I say 'we', I mean the IETF leadership, the secretariat,  the NOC, some people like you who have provided invaluable feedback on end users experience...and the Meetecho team.

Cheers,

Simon

Il 15 Febbraio 2015 14:31:09 CET, John C Klensin <[e-mail]> ha scritto:
>
>
>--On Saturday, February 14, 2015 21:11 -0500 Ted Lemon
><[e-mail]> wrote:
>
>> On Feb 14, 2015, at 5:51 PM, John Leslie <[e-mail]> wrote:
>>>   Is there anybody besides the Meetecho folks whose task it
>>>   is to "make it work"? Is there anybody _including_ the
>>> Meetecho folks who has the ability to arrange similar
>>> priority at the mike to that of on-site participants?
>> 
>> A tremendous amount of work goes on behind the scenes to make
>> this work, not just the meetecho folks.   I remember reporting
>> a problem in a meeting and having Alexa show up five minutes
>> later checking to see if it was fixed, and I know that other
>> folks from AMS and from the NOC work hard on this.
>
>Ted,
>
>I agree about the efforts and have said that before.  I think we
>would be much worse off without those huge, and largely
>successful, efforts to remedy or patch things when problems are
>noticed.
>
>However, the example you note is part of my concern about
>whether the IETF is serious about remote participation.  As John
>Leslie and I have noted, "something doesn't work in some 9AM
>Monday WG session" seems so common as to be routine.  Sometimes
>those things get fixed quickly, sometimes those of us who are
>remote are basically told that a fix cannot be made without
>disrupting the meeting so things will be fixed and tested after
>11:30.  
>
>If we were serious, we'd have these things up and tested before
>the sessions start.  If we were serious, we'd promise
>availability of remote participation (or at least remote
>observation) of Sunday afternoon tutorial sessions and we would
>test things in advance for them. Most of those sessions are as
>valuable to those who are remote as to those who happen to be
>present, and, especially for newcomers, some may be more
>important for the remote people who cannot ask questions in the
>halls.    If we were serious, it wouldn't be left to remote
>participants to report that a camera was giving a lovely view of
>the carpet in the meeting room or that speakers were otherwise
>off-camera, and, when the problem was detected, fixing it would
>be a priority, not something deferred to avoid interrupting the
>speaker (or we'd be using remote-controllable cameras).   
>
>If we were serious, we would establish a system that works and
>use it and stop trying to half-support three systems (Meetecho,
>WebEx, and the streamed audio/Jabber combination in parallel).
>Of that list, Meetecho has been quote close to what we need
>although I've got scaling concerns; WebEx is notoriously
>unreliable, especially for unmoderated sessions with many
>participants and many locations; and, if only because of the
>combination of audio lag, typing lag, and microphone access lag,
>we should stop pretending the last combination is worth the
>trouble (there are good reasons for recording and probably
>streaming audio, but they aren't related to remote
>_participation_)   I don't believe that all of the items on the
>list Randy provided three years ago and quoted in a recent note
>are entirely necessary, but I'd certainly like to have them too.
>If we were serious, we would have made some progress on that
>list in three years.  As far as I can tell, we haven't.
>
>And, coming back to the topic of this thread, if charging a
>remote participation fee is a component of a serious commitment
>by the IETF (rather than the dedication of a handful of
>individuals), then let's charge a registration fee.   If it is
>better to set a schedule for quality and well-supported remote
>participation services, imposing a fee only when things are up
>and running, that is fine but let's see the schedule.  By
>contrast, if "there is no fee, remote participants get the best
>service volunteers can deliver when they have time and without
>disrupting meetings, and we have no incentive to announce a
>schedule" is the IETF's policy in practice, then let's admit
>that, acknowledge whatever it means for diversity of
>participation, and move on.
>
>     john