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

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

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"