[openstack-dev] How to guarantee success of the I Design Summit in HK

Emmet Hikory persia at shipstone.jp
Thu May 16 06:14:44 UTC 2013


Bhandaru, Malini K wrote:
> May be we could have a chat room line open to take questions from 
> remote attendees during design sessions. Recently some Rackspace 
> colleagues introduced me to TeamSpeak, the client is available for 
> pcs, android etc. That would be used for 2-way communication in 
> addition to an etherpad/slide deck online. A connection per parallel 
> session?

    The latency is likely to be too high for nearly any sort of 
multi-party voice input system.  While this class of communication can 
be done for one or two remote discussion participants, with more the 
audio system for the individual session room tends to become unusable.  
Even with one remote voice participant, the extra 500-1000ms compared to 
in-room participants requires great care on the part of other 
participants to be inclusive (and this lag isn't unreasonable for even 
64K circuit-switched audio NYC<->HK including typical human audio 
response times, never mind more complicated compression/routing). With 
multiple participants, one needs significantly better audio reproduction 
solutions to allow differentiation of voices, there are greater issues 
with input gain adjustments leading to the heavy breathing problem, many 
solutions end up muting room broadcasting on output, etc.

    There do exist some potential solutions in this space, but I'm 
inclined to agree with Stefano that deep discussion of potential 
technical models is premature: there are a number of less technical 
solutions to the issue, and until the totality of participation 
viability is understood, the set of sessions that might be compromised 
is unknown: active online discussion in existing fora combined with 
videography can do a lot to emulate the back-of-the-room experience.  
Part of this might just be ensuring that those who cannot be physically 
present can be granted the time to be time-shifted to UTC+8 to follow 
sessions in realtime, rather than attempting to perform normal work 
during remote conference attendance.

    As a non-technical solution for those who have some specific 
position they intend to express at a session, but who are unable to be 
physically present, I have had prior success for several different 
participatory design conferences by documenting the position prior to 
the session, and asking a proxy to represent that position in-session. 
In the rare cases where this isn't sufficient, post-session discussion 
via online fora is likely to be able to adjust the decisions to be 
acceptable: the chance of this is significantly increased if the 
represented position includes the proxy volunteering the principal to 
perform some subset of the effort for the session.  For the very busy, 
this technique also works well if the session schedule hands you a 
conflict, although you may have less time to prepare.

    For those with a deep desire to preevaluate technical possibilities
for a potential later discussion, I encourage consideration of the
differences between succesful remote presence technologies and audio
conferencing technologies: when a majority of participants in a
conversation have immediate physicial presence, the tolerance for many
delays, compression artifacts, etc. is very different than the tolerance
when all are using broadly similar remote connection terminals (some
combination of personal speakers and microphones).

-- 
Emmet HIKORY



More information about the OpenStack-dev mailing list