Hi, +1 On Fri, Aug 16, 2013 at 1:59 AM, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> wrote: > Maybe I am missing something. > The reason we have face-to-face meetings is because there is value in such > meetings that can not reasonably be achieved in other ways. > I would like remote participation to be as good as possible. But if would > could achieve "the same as being there" then we should seriously consider > not meeting face-to-face. Being at the IETF for a week is never going to be the same experience as participating remotely at a computer for a couple 2 hour meetings. A lot of work gets done outside the official WG meetings because the right people can all be in the same room at the same time. IMO we should be using more virtual interim meetings, not trying to turn our f2f meetings into remote meetings. WGs should meet virtually at least once a month for 2 - 4 hours to make progress on issues same as via the WG mailing list. Everybody is a remote participant in a virtual interim so the problems with interfacing to a live meeting go away. > Conversely, until the technology gets that good, we must not penalize the > face-to-face meeting for failures of the technology. > > Yours, > Joel Andy > > On 8/15/13 9:48 PM, Mark Nottingham wrote: >> >> >> On 13/08/2013, at 11:00 AM, Douglas Otis <doug.mtview@xxxxxxxxx> wrote: >>> >>> >>> 1) Ensure exact digital interfaces driving projectors are fully available >>> remotely. >> >> >> That would be fantastic, if feasible. Much simpler than sharing through >> software. >> >> >>> 2) Ensure Audio access requires an identified request via XMPP prior to >>> enabling either a remote or local audio feed. >> >> >> Hm. >> >>> >>> 3) RFI tags could facilitate enabling local audio feed instead of an >>> identified request via XMPP. >> >> >> Could be quite interesting; many conferences now provide attendees with >> RFID tags... >> >>> >>> 4) In the event of the local venue loosing Internet access, the device >>> regulating A/V presentations must be able to operate in a virtual mode where >>> only remote participants are permitted to continue the meeting proceedings. >> >> >> That seems… extreme. >> >>> 5) Important participants should plan for alternative modes of Internet >>> access to remain part of the proceedings. >> >> >> Not exactly practical. >> >>> >>> 6) Develop a simple syntax used on XMPP sessions to: >>> 1) signify a request to speak on X >>> 2) withdraw a request to speak on X >>> 3) signify support of Y >>> 4) signify non-support of Y >>> 5) signal when a request has been granted or revoked. For local >>> participants this could be in the form of a red or green light at their >>> microphone. >> >> >> The W3C does much of this already with IRC bots, e.g.: >> http://www.w3.org/2001/12/zakim-irc-bot.html >> >> (also can pick a scribe, track an agenda, etc.) >> >> >>> 7) Develop a control panel managed by chairs or their proxies that >>> consolidate and sequence requests and log support and nonsupport indications >>> and the granting of requests. >> >> >> See above (I think). >> >>> >>> 8) Chairs should be able to act as proxies for local participants lacking >>> access to XMPP. >> >> >> Not practical, unless they delegate. >> >>> >>> 9) Chairs should have alternative Internet access independent of that of >>> the venue's. >> >> >> Seems extreme. >> >>> >>> 10) Establish a reasonable fee to facilitate remote participants who >>> receive credit for their participation equal to that of being local. >>> >>> 11) The device regulating A/V presentations must drive both the video and >>> audio portions of the presentations. A web camera in a room is a very poor >>> replacement. >>> >>> 12) All video information in the form of slides and text must be >>> available from the Internet prior to the beginning of the meeting. >> >> >> Cheers, >> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> >