Re: [sidr] Interim Meeting Dates/Locations (Proposed)

[Matt Lepinski <[e-mail]>]

On a related note:

At some point we could also try a virtual (remote-only) interim meeting. 
I realize that there is value in having a critical mass of people in one 
room interacting directly. However, in cases where there is not a 
co-located event that is likely to draw a critical mass of people, 
perhaps a virtual interim makes sense.

Note: I have been involved in other working groups that have 
successfully pulled off virtual interims (so there are worked examples 
of this happening successfully). Also, most of the problems in San Diego 
were in trying to combine a large number of physical participants with a 
large number of remote participants, so it is possible that a completely 
virtual interim would run into fewer potential stumbling blocks.

Just my 2 cents,
- Matt Lepinski


On 3/27/2012 5:52 PM, Samuel Weiler wrote:
> On Tue, 27 Mar 2012, Murphy, Sandra wrote:
>
>> Moderate badness in the Monday meeting was due to my laptop 
>> communication problems.  Suggestions welcome as how to handle such a 
>> situation better.
>
> Thank you for asking.
>
> 1) First and foremost, delegate the tech issues to two or more persons 
> who do not have responsibilities to chair, present, scribe, or jabber 
> scribe.  Ideally, find people who are unlikely to be active 
> participants in the meeting.  It's fine to bring in outside help.
>
> 2) Have spares for all key hardware.  This includes laptops, audio 
> gear, network gear, network connections, and phone connections. Cables 
> and power supplies need spares, also -- a dead power supply can mean a 
> dead laptop.  Based on experience in San Diego I suggest having at 
> least three pieces of all key gear.  Have fallbacks in case a service 
> provider fails: if you're planning to use Meetecho, ALSO have a WebEx 
> session and a PSTN bridge set up and ready to go.
>
> 3) Test both primary and spare hardware and service providers in 
> multiple combinations prior to the meeting.  The more testing you do, 
> the more you can get away with only a single spare.  Testing needs to 
> happen in the real meeting environment using the same phone lines, net 
> connections, and audio hardware that will be available during the 
> meeting.  The more removed your testing environment is from the real 
> meeting environment, the more you need that second spare.
>
> 4) When a relatively large number of participants will be in a single 
> space, provide high-quality microphones.  The average Polycom 
> microphone still sounds like a speakerphone, and listening to people 
> talking through one all day gives remote participants a clearly 
> second-class experience.  If possible, give every participant his own 
> microphone (with mute switch!).  At the very least, provide a floor or 
> wireless handheld microphone as we have at the regular IETF meetings 
> and make sure people use it.
>
>
> Yes, this is a lot to do.  Yes, I'm saying to have three net 
> connections[1].  Remember, you're not doing this yourself (at least, 
> not if you're following suggestion #1).  In fact, no one person is 
> stuck with all of this.  And "spares" don't have to be 
> sitting-in-a-box-and-hauled-around-the-world-the-to-be-a-spare: they 
> can be a meeting participant's personal power brick, so long as you're 
> sure there's going to be that spare in the room and the person is 
> willing to part with it should the need arise.
>
> -- Sam
>
>
> [1] This is based on the San Diego experience where the hotel net 
> connection was terrible and the backup net was a 4G hotspot.  While 
> both could move some packets, they were not enough to handle both 
> remote participation and the normal packet-pushing desires of those in 
> the room.  A 3G or 4G device could easily be the backup net, so long 
> as 1) there is actually service in the meeting space and 2) the device 
> gives priority to the remote participation traffic and avoids getting 
> bogged down by routine email checking and web browsing.
> _______________________________________________
> sidr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidr