On Mon, Jul 27, 2015 at 6:20 AM, Stephen Farrell <stephen.farrell@xxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxx >> >> <<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