--On Saturday, February 14, 2015 21:11 -0500 Ted Lemon
<Ted(_dot_)Lemon(_at_)nominum(_dot_)com> wrote:
On Feb 14, 2015, at 5:51 PM, John Leslie <john(_at_)jlc(_dot_)net> 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