Re: On cooperative work [Was: Re: newbus' ivar's limitation..]

From: Warner Losh <imp_at_bsdimp.com>
Date: Thu, 2 Aug 2012 11:40:40 -0600
On Aug 2, 2012, at 10:46 AM, Doug Barton wrote:
> Those all sound like nice steps forward, thank you for pointing them
> out. Nothing would make me happier than to be proven wrong in this area.
> What would be nice I think would be if these steps were formalized, and
> shared more openly. Having things on the wiki is nice, but reporting
> things in detail on the mailing lists puts it in the archives for future
> reference, as well as making it more broadly available to start with.

One thing to remember about the IETF.  There's many vendors that devote significant resources to the IETF.  While I was at Cisco, for example, I know that we provided audio and video bridges to IEFT meetings to facilitate remote attendance at the meetings.  Cisco dedicated several engineers to ensure that the audio and video quality remained good during the meetings and were able to use facilities cisco normally used for things like WebEx and MeetingPlace.  With a global presence and infrastructure, they were able to pull it off.  I'm not aware of similar resources within the project.

We don't have any such benefactor in the project, so we have to rely on the kindness of strangers. AsiaBSDcon live streams most of its talks, but uses a free service that changes from year to year and is quite good for talks, but can't do meetings at all.  Other meeting things do meetings OK, but the video or audio quality sucks unless you have high end gear for the source. Mapping out what hardware, software and service combinations work would be very beneficial.  I suspect this will vary based on geographic location (stuff that works good in the US won't work in EU or Asia and vice versa).  These issues are what makes it hit or miss.  While it is easy to skype one or two people into a meeting, that scales poorly to more than two. Plus if things are going poorly, the attempt to broadcast the meeting can derail or eat into the time available significantly.

I guess this is a long way to say that while one to one, and one to many problems have relatively easy solutions, many to many like we need still remains fussy and difficult.

Warner
Received on Thu Aug 02 2012 - 15:40:45 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:29 UTC