ietf
[Top] [All Lists]

Re: Remote participation

2015-11-02 06:08:14
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(_at_)unina(_dot_)it> 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.




<Prev in Thread] Current Thread [Next in Thread>