Hi. Without knowing what happened today, but having done remote
presentations a few comments:
--On Monday, November 02, 2015 08:58 +0100 Simon Pietro Romano
<spromano@xxxxxxxx> wrote:
>...
> let me chime in on this. I'm copy-pasting below the
> "standard" message we send to each potential remote
> presenter:
That setup, and the test tools, have gotten much better since I
started using Meetecho. While there is always room for
improvement, I think they are more than adequate by now.
>...
> As you can see, we provide prospective presenters with a
> self-test facility which should allow them to properly check
> whether or not they are in the right condition to make a
> remote presentation. This almost always works, as witnessed by
> the 5 presentations (plus 4 "injections" from the virtual
> queue) we had so far and which worked like a charm. If you are
> referring, as I can figure out, to today's CCAMP session,
> this was an unlucky case. The remote presenter had made the
> test and he had indeed reported that he could not make any
> video (from his work location), whereas he could do "good
> enough" audio, due to a slow (and firewalled) network
> connection. My personal feeling is that we should avoid this
> kind of situations and perhaps ask the presenters to either
> find a better connection or delegate some of the local
> participants, or simply throw in the towel.
With two exceptions, I think that is just right. If the
presenter does not get good test results, he or she should
either find a location from which good test results are
possible, get their "normal" location fixed (it is sometimes
possible to open corporate firewalls for a single desktop or
address if the company feels cooperative), or make a plan that
doesn't involve remote presentations. However, two suggestions
(neither specific to Meetecho)
(i) No WG should ever allow a presentation that depends on
remote access unless there is a clear fallback plan, presumably
in the form of either prerecorded video or audio that is
available on-site (and a setup for running it) or someone in the
room who is prepared to talk through the slides or presentation
materials. Stuff happens and, although it has been a long time
since an IETF network suffered an extended LAN or WAN outage, we
can't say "impossible".
(ii) Pre-meeting testing for intended remote presenters should
be mandatory, not discretionary with the would-be presenter, and
results reported to WG chairs, not just that presenter. The
decision to put a presentation on the agenda belongs to the
chair(s) (subject to appeal, etc.) and they are at least
partially accountable if such a presentation doesn't come off,
so they are entitled to full information. And, if a presenter's
setup doesn't test well, the chair(s) should be at least as
responsible for being sure other arrangements are in place (if
necessary taking the presentation off the agenda) as the
presenter.
In case it isn't clear, if I've correctly understood this
particular situation from the collection of messages, blaming
the Meetecho folks is neither appropriate nor useful: if there
is blame to be cast, this was fairly clearly a presenter and/or
chair problem. Almost exactly the same comment would apply to
Meetecho responsibility for a network outage or degraded
performance at the IETF end. I hope that, rather than casting
blame, we can learn to remember that infallible technology is
rare, that ours is no exception, and that having fallback plans
in place is a necessity.
john
p.s. It seems that one of the presumably unanticipated
side-effects of the new ART (ex-Apps) schedule is that Simon and
his colleagues don't get to hear my complaining in the first
Monday session :-)
Though, I don't
> think we (i.e., the Meetecho team) can take on the
> responsibility for this choice. That's why we always keep
> WG chairs in the loop for all our e-mail exchanges with
> prospective remotees. If you believe we should adopt a
> different policy, just let us know. We're obviously open to
> discussion and ready to take your savvy advice.