Subject: Moderation experiment at IETF83 [Was: Re: Getting Taipei remote participants' input]

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 28 Feb 2012 14:40:06 +0100

Dear all,

I'm resuming this old thread since I would like to announce a new 
project/experiment we are going to propose at the upcoming IETF in Paris.
I put some documentation on-line, in order to clearly explain what we 
are talking about. You can access it at the following URL:

http://ietf83.conf.meetecho.com/index.php/UMPIRE_Project

I am putting the vmeet mailing list in CC:, because I think the subject 
is of interest to them.

Cheers,

Simon

Il 25/11/2011 21:08, Dave CROCKER ha scritto:
>
>
> On 11/23/2011 11:16 AM, Simon Pietro Romano wrote:
>> Hi Dave,
>>
>>> If you mean aggregating the set of folk at all the mics and taking 
>>> them in the
>>> strict order of their coming to the (single) queue, that doesn't 
>>> work on
>>> average, unless the queue is tiny. The chair can't keep track of who 
>>> arrived
>>> to the queue and when.
>>
>> I personally like Brian's idea, and think the all thing might work 
>> smoothly if
>> you make use of a tool capable to automatically collect and moderate 
>> floor
>> requests, to be put in a (virtual) single queue. What I'm thinking of 
>> is RFIDs
>> triggering BFCP (Binary Floor Control Protocol) requests,
>
>
> An interesting challenge, for Paul's current contract, is to find a 
> way to navigate between what the community wants, versus what is 
> practical.  The fact that we are a group of engineers means that we 
> tend to try to solve the problem, before agreeing on what problem we 
> want to solve...
>
> Suggestions like the above sound appealing.  Unfortunately, they are 
> far beyond current products and making them useful is considerably 
> more difficult than the suggestions imply.  That doesn't mean they 
> should be ignored, but we need to be careful about slipping into the 
> assumption that merely citing a bit of technology means that an issue 
> is resolved.
>
> We had an experiment with RFIDs.  It was awkward, at best.  In 
> addition, it was extremely limited.  Only the person standing right 
> next to the microphone could be identified.  For example, this means 
> that it would not have been useful for identifying when someone 
> /enters/ the queue.  Too far away.
>
> So if folks are going to attempt to define the technical solution, at 
> least please try to indicate how it would work throughout the 
> requirement.
>
> In the case of queue management, we have at least entering the queue, 
> position in the queue, and the chair's control of the queue.  No 
> doubt, there's even more complexity than that.  For example, there's 
> "noise" such as someone walking by the queue but not entering it...
>
> d/

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/