On Mon, Jul 27, 2015 at 6:20 AM, Stephen Farrell
<stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie> wrote:
I'm not in favour of a rigidly enforced single queue, virtual
or not.
+1 -- often someone walks up to the mic and makes a point. Someone
else specifically wants to respond to that point, and having them be
able to quickly queue jump to be able to agree / disagree makes the
conversation *much* more useful. In another standards group we use
Adobe Connect for (endless) conference calls with 10 - 30 people --
Adobe lets you virtually "rise your hand" and be put in a queue. This
ends poorly.
We will discuss something and someone will include a question /
suggestion, so you raise your hand with the answer. The person running
the meeting then goes through the queue and eventually, after 10 or 15
minutes of random pontificating it's your turn... at which time you
can:
A: say "Yeah, I agree with what everyone else said..." -- this is a
waste of everyone's time.
B: say "I've actually tested this and the answer is 42" -- this means
that the last 15 minutes of pontification was a waste of time.
C: say "Sorry, it's been so long I cannot remember what we were
talking about..." -- this simply reopens the entire discussion and you
realize no-one actually knows what the question was.
Conversations never terminate, but we *do* end up with very pretty bikesheds.
I do support the idea that a remote participant can get in a
queue and not be endlessly gazumped by folks who are present.
When chairing I always let the jabber scribe jump to the front of the
line - it is sufficiently hard for remote participants to interact
that this allows them to actually be able to stay engaged. It also
avoids the issue where the remote person suggests that we do $foo and
so the scribe gets in line. The first person at the mic then also
suggests $foo... the queue slowly drains and finally the scribe relays
Bob's suggestion. Everyone thinks "Gods, Bob's an idiot, we already
agreed to $foo, why is he suggesting this again, now?!" - sure they
"get" that this is a queued question, but humans have evolved with
face-to-face interactions and so there is a bit of a break...
W
With jabber and channelling that works ok today. We need to find
a way to make it work with remote audio input. (I don't think the
pacman thing is there yet but am fine with that being played with
and improved.)
What I do not want however is for chairs to lose the ability to
allow two or more folks to discuss a specific point when that's
the best way to get something resolved. Insisting that someone
has to wait until N other folks have raised different issues is
surely a way to dis-improve our face to face interactions. And I
don't think the way to handle that is via any kind of UI, fancy
or simple, but rather by allowing chairs to do the right thing,
whatever that is. (Actually I wish we were much better at getting
mic lines to discuss one topic at a time, but that's a different
discussion, so I'll not interpose it here:-)
S.
On 27/07/15 10:17, Simon Pietro Romano wrote:
100% agreed!
Simon
On 27/lug/2015, at 10:56, Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
On 7/27/2015 10:46 AM, Simon Pietro Romano wrote:
As I know you know quite well, this can be achieved in a number of ways.
We proposed RFID some time ago. We have then moved to alternatives like
barcode scanners close to the mics and/or the very simple web interface
you find in the page I mentioned.
And as I know you know... I would like us (all) to simply use the web
interface.
The other technologies are fun and clever but have significant usability
issues, operational issues, and possibly privacy issues. At a minimum,
they require specialized infrastructure. I also believe that the
distance between their current usability and their being comfortable for
production use in the IETF is quite far.
The web interface has drawbacks too, but it is likely to be trivial for
most of us, most of the time, given that we all heavily use web
interfaces and nearly all of us have easy online access in meetings.[*]
For those other times, we can provide a few different hacks, such as
asking a neighbor to enter our name, or maybe even to having a public
terminal near a microphone, for entering names.
d/
[*] Beyond the question of how a name is entered into the queue is the
question of how the queue is publicly displayed. We will probably find
that rather than showing the names of everyone in the queue, we should
show only current name, next name, and a count of the queue size.
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_\\|//_
( O-O )
~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
Simon Pietro Romano
Universita' di Napoli Federico II
Computer Engineering Department
Phone: +39 081 7683823 -- Fax: +39 081 7683816
e-mail:
spromano(_at_)unina(_dot_)it
<<Molti mi dicono che lo scoraggiamento è l'alibi degli
idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
oooO
~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
\ ( ( )
\_) ) /
(_/
----
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITÀ DI NAPOLI
Codice Fiscale: 00876220633
www.unina.it/Vademecum5permille
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf