>>>>> "Paul" == Paul Hoffman <[email protected]> writes:
>> Those are good anecdotes: it would be useful to understand which
>> ones have technological solutions, and which ones have
>> proceedural solutions, and only appear to be technological
>> problems, because the technology makes it more obvious that there
>> is a problem.
Paul> Everything has a technological solution, and most things have
Paul> a procedural solution. :-) If people agree that the
Paul> requirement is that humans doing IM-to-mic translation be
Paul> exchanged for remote participants being able to speak
Paul> themselves, most of these fall away. Such a requirement is
Paul> both technological (there needs to be a way to get the remote
Paul> voice in the room and also on the audio stream going out to
Paul> the other participants), but it also involves procedures such
Paul> as floor control.
o Sam is speaking for Robert, and Rachel wants to comment on what
Robert said. Unless Sam reads the message as he is walking back
to his seat, Rachel doesn't get to speak.
What I see is that if we could better formalize the jabber-to-mic
process, such as by giving that person a *MIC*, and/or seating them at
the front, or making it a function of one of the co-chairs, then it
seems that a lot of the issues go away. Also most of the issues where
the presenter and/or conversation has gone forward.
Part of the problem is that we waste huge amounts of our in-person time
on presentations rather than conversations. That's why we have
situations like:
o Pete starts his presentation by asking for questions to be held
until the end. Robert has a question about slide 5, and is
waiting until the end of the presentation to post the question in
the Jabber room. After slide 7, Len jumps to the mic and
=== where was the chair here?
o Chris asks "are there any more questions" while Rachel is typing
furiously, but she doesn't finish before Chris says "I don't see
anyone, thanks Pete, the next speaker is...".
=== again, failure of the chair here.
o This is the first time Pete is presenting at an IETF meeting, and
Robert has the first question, which is relayed through Sam. Pete
stays silent, not responding the question. Robert can't see
=== here, I don't know why Pete is silent. What's the root cause here?
o Pete says something that the AD sitting at the front of the room
(not near a mic) doesn't like, and the AD says a few sentences but
doesn't go to the mic. The chairs try to repeat what the AD says,
get it only approximately right, but the remote attendees do not
hear what really was said and therefore cannot comment
effectively.
=== this seems to be a problem which has NOTHING to do with remote
participation, as the people in the back of the room didn't get it
either. It's just that the remote participation are AWARE that
they missed something, while the people in the back of the room
are just lost, because they couldn't even hear the mumbling of the AD.
> o Sam only volunteered to be scribe because no one else would do it,
> and isn't sitting close to the mic, and gets tired of getting up
> and down all the time, and doesn't really agree with Robert on a
> particular issue, so Sam doesn't relay a request from Robert.
multiple failures. Getting the voice into the room (so people can
better shout at each other) is a technological solution to a proceedural
problem here.
A lot of focus in the document here seems to be about getting the voice
into the room. As a remote participant who has participated at IETF and
other meetings, I much prefer the IETF method.
(Particularly that even with the who-is-talking-now bit, unless we can
enforce push-to-talk {how do we do that on a straight PSTN voice
connection?} we will always have the background
noise/people-eating/etc. problem.)
a) At 2am, it's much better to type at my house than to talk.
b) If I type my question, it's in the jabber log.
c) There is a good chance that someone else might answer me, and my
question does not need to interrupt.
d) If the chair/presenter could read the questions directly, when it is
a presentation rather than a discussion, then maybe we do not need
a MIC and MIC-line, as everyone could use that!
Back in 1996, when I started at the IETF, we had few computer
projectors, but did have transparencies. A feature of them is that they
are expensive, hard(er than PPT) to produce, and so there was much more
conversation.
I come back to this, because central to vmeet requirements is what kind
of meetings are we trying to support?
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] [email protected] http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html.
https://www.ietf.org/mailman/listinfo/vmeet
