Re: [vmeet] Supporting interim meetings

[John Leslie <[e-mail]>]

Dave CROCKER <[e-mail]> wrote:
> John Leslie wrote:
> 
>> 1) Right now, a phone bridge is essentially state-of-the-art for
>> audio. Most everything else flunks Brian's 150 msec test.
> 
> This raises two different questions:
> 
> 1.  Is passing that test really mandatory?

   For Brian, perhaps... Probably not for the rest of us. But I have
experienced too many cases where VoIP flunks it by an order of magnitude
or more. I argue that if we push it by more than a factor of three, we
will be sorry.

> 2.  Is it true that no VOIP capabilities pass it today?

   I don't know, but I suspect that most VoIP capabilities let the
delay exceed one second while chasing other "quality" issues.

   (I don't believe there's any need to let it get that high, BTW.)

>> 2) Advance availability of charts is egregiously poorly enforced.
>>...
>> 3) Best Practices simply don't get followed, unless somebody is
>> constantly nagging.
> 
> On both of these point, we should note that the community does, in fact, 
> follow certain rigid requirements.  I-D submissions deadlines, meeting 
> registration deadlines, etc.

   These are enforced by programmed tools.

> When a requirement is enforced, we conform.

   The kind of requirements some are recommending depend upon enforcement
by (already overworked) individuals. And many of these individuals report
that their attempts to enforce, e.g. slide deadlines, fail miserably.

>>>> 1.  Meeting management -
>>>> a)  Ability to queue up participants, as if at a microphone
>>>> For meetings of a group that can easily be 20-40 people,
>>>> with relatively little history of group collaboration, the job of
>>>> meeting management is vastly easier when there is some functional
>>>> help for coordinating who wants to speak next.
>>>...
>> I regard this as very important; but I'm not happy with any
>> automated functions I've seen in a telepresence package. A simple
>> plaintext list of folks who have asked to speak (and not given up
>> their place or spoken) is what all participants should have.
> 
> I don't understand what you are specifying.  How would it work and how 
> would that be easy to use?

   I'm not particular how it works. An example would be a separate
Jabber window (and there's no reason an IRC bot couldn't maintain it).

>> I consider this important enough that someone should have the role
>> of maintaining it if we can't get it automated.
> 
> Again, in terms of broad-based, on-going use I believe we cannot settle
> for hack solutions. Let's be careful that we do not do the online
> equivalent of requiring each speaker bring their own public address
> megaphone.

   Our timeframe is too short to rule out "hacks" for Stockholm. For
the IETF after that, we should be able to automate things.

> The more manual the mechanism, the more hassle will be its use. To get
> work done on the scale we are seeking, we cannot have the tools impose
> hassle, IMO.

   Alas, _any_ new tool will "hassle" somebody.

> And just because one or another of us is willing to put up with that 
> hassle does not make it reasonable to impose on everyone else.

   Nor, of course, _will_ everyone else put up with it...

>>   My own concerns:
>>
>> 1) Participants need to figure out who's speaking. There are many ways
>> to help them, but it deserves to be high among our concerns.
> 
> Good point.  Yes.

   Thanks! (Be sure we don't forget this one.)

>> 2) Snapshots of slides and/or whiteboards can help keep folks on the
>> same page. Things change during meetings, and it's very easy for
>> human memories to diverge.
> 
> I'm not clear what capability you are suggesting, beyond what's already 
> been listed.

   I'm probably over-sensitive on this one, but the principle is real.
The case which sensitizes me is on IESG telechats, the DISCUSS comments
are changing in real-time, and it's hard to exactly match them to what
is said during the telechat. Issues disappear from the Balloting link
and sometimes get lost -- this leads to unnecessary friction where ADs
could become less willing to let go of a DISCUSS.

   What I would _really_ like to see is an ability to "snapshot" a
working document -- whether a whiteboard, a PowerPoint, or whatever --
to preserve its state at the point an action was agreed.

>> 3) There really should be a "record" of a meeting. This is, admittedly,
>> an art form; but folks don't want to listen to an audio recording
>> or even read a transcript of every word spoken. It very likely would
>> be helpful if such a record could be visible in real-time to some
>> participants. (I don't claim to be particularly good at doing this,
>> but there _are_ folks who are good at it.)
> 
> We currently have a jabber transcript, with a scribe, and a separate note 
> taker. Are you suggesting something beyond these?

   Yes: almost anything beyond those would help. The Jabber transcript
contains a lot of irrelevant, transitory information; and often misses
the points which deserve to be preserved. The separate Note Taker at
least has a responsibility to record the things which deserve to be
preserved, but these notes seldom appear quickly and too often get lost
entirely.

   If there _were_ a Real-Time-Text "record" -- separate from the rest
of a jabber session, it wouldn't get lost and folks could comment on
perceived errors and omissions in time to fix them.

   (I realize there are a few Jabber Scribes that do this (except for
the separate window), but we never know whether we'll get one of those
until it's too late to fix the absence.)

>> 4) Every meeting should create "action items" that someone is responsible
>> for following-up on. (Some are group items; some private.) These
>> deserve far more visibility than they usually get.
> 
> What sort of tool is involved in this, different from what is already in 
> use?

   Separate Window (or combined with my "record" window. (The amount of
typing is small enough that we could almost make this a Chair duty;
but of course it would be better as a WG-Secretary duty.)

>> 5) Separate applications is very likely better than one integrated
>> application. Webex drives me crazy by taking over organization of
>> the screen. I don't want anything else interacting with my Jabber
>> application.
> 
> Interesting point.  The tradeoff is that tools that aren't integrated each 
> require separate registration and management.

   I've been running multiple applications on my laptop for years:
what's the problem?

>> 6) VoIP-as-we-know-it doesn't meld well with POTS conferencing. Until
>> VoIP can have consistent delay -- ideally Brian's 150 msec, but
>> definitely under 500 msec -- we'll probably have to do without it.
> 
> The lengthy discussion about these details was facinating, but too many 
> people have had entirely too many, acceptable experiences with group 
> conversations that were a mix of telephone and voip.

   Someone who is "only" listening can tolerate 5-second delays. But
to "participate" requires listening _and_ speaking. 150 msec is about
the upper limit on "echo-free" listening. Get it above one second, and
few of us can both listen and speak freely.

   I experienced 5-second delays between POTS and VoIP connections to
webex. The 5-second is way past acceptable for actual participation.

   I do not believe it has to be that bad, but I've had that-bad
experiences with every packaged tool I've tried so far.

   No number of people who haven't experienced multi-second delays can
cancel the confusion this causes. At the very least, we need a warning
label if we try to combine VoIP and POTS in a single group.

   (It might be possible to have folks switch between VoIP for listen
mode and POTS for participate mode, but they'd need to know how and
allow time for switching...)

>> 7) Learning curve is way too high for most telepresence packages.
>> Folks simply _won't_ learn how to use them effectively. 
> 
> Concern about the learning curve is certainly warranted.  However we
> need to be careful about firm, pre-hoc assertions of what is and is
> not acceptable in terms of what the human factors folk call usability.

   I don't expect folks to agree with Brian about 150 msec. (But he's
right.) It's the other end of the spectrum which worries me: folks
who think that everyone can "just adjust" to ten-second delays will
make it nearly impossible for newcomers if we set the bar at ten
seconds.

--
John Leslie <[e-mail]>