[governance] remote participation via standardized protocols (was Re: Open consultations)

[Roland Perry]

In message <20110519161725.4342615C0DF at quill.bollow.ch>, at 18:17:25 on 
Thu, 19 May 2011, Norbert Bollow <nb at bollow.ch> writes
>Roland Perry <roland at internetpolicyagency.com> wrote:
>
>> >In my understanding, that was an assertion that it "works" under
>> >"Windows", "Apple" and "Linux",
>>
>> Versions are available for all three.
>
>Well the "Linux" version didn't work for me.

Then there's something about your installation which is causing that. 
Unfortunately, as a Linux installation is almost certain to be 
less-standard than a Windows or Apple one, faultfinding can be quite 
tedious.

Have you tried something like Win4Lin, and then running the Windows 
version of Adobe on top of that?

>> >which is at odds with my experience with a very typical set-up of the
>> >latter.
>>
>> One of the problems with *nix is that its advantages are traded off
>> against what seems to me to be a much restricted degree of "plug and
>> play". Not surprising given the almost infinite combinations available.
>
>The path to solve this kind of problems is standardization.
>
>Why do you oppose that?

I don't. If everyone used the same "standard" version of Windows, and 
Apple and Linux were banned, everything would have a much better chance 
of installing immediately. That's the theory behind those application 
developers who say "I know for sure that this works in Internet 
Explorer, use it on other browsers at your peril".

On the other hand, I also realise that diversity is good, and the 
Internet is better suited than many other technologies at allowing 
people to carve their own applications and platforms. But if you go down 
that route, you have to accept that there will be teething problems.

I speak as someone who, having surveyed the early browser market and 
found issues with the only two candidates at the time (Netscape and 
Microsoft) commissioned some people to write a new browser - which we 
shipped for free with subscriptions to the ISP I was managing.

Another bunch of people came to the same decision over email clients, 
and I'm still using the one they wrote, 16 years later. Unfortunately, 
standards even for things like email keep changing, and the client is 
showing its age.

>> >Maybe I should also mention that assertions that the "solution" "works
>> >now" and "we should embrace it" are rather unfriendly things to say to
>> >someone who was just locked out from being able to participate because
>> >what "works now" doesn't for everyone and even the fall-back option of
>> >live transcripts + email isn't made avalable, presumably as a result
>> >of a mistaken belief that the Abobe "solution" works for everyone?
>>
>> Email was available
>
>I find your repeated assertions to the contrary of my experience very
>frustrating.

Your experience was that the email was ignored. I don't think there was 
a *technical* issue with it being delivered (unless you have not told us 
that it bounced back).

>> (although I didn't see any evidence that it was used
>> by anyone)
>
>As I wrote, my timely and appropriate attempt to communicate by email
>was ignored.

That's not the fault of the email protocol. There was an ICANN meeting 
quite a few years ago, when their remote participation was in its 
infancy, and the only way I could communicate with the room was by 
emailing one of the board members sitting on the platform!

During this week's meetings in Geneva, due to problems with the 
connectivity and the reluctance of the ITU's remote moderator to 
interrupt the meeting as often as the Adobe remote participants might 
have wished, the best way to participate was by Skype to people in the 
room. I know that the Caucus has used Skype in this way in the past - 
it's up to the co-ordinators in the room to set this up.

>> >(Yesterday the "live transcript" was working but a timely intervention
>> >that I submitted by email got ignored, probably because nobody was
>> >watching the email address that had been provided, and today the "live
>> >transcript" links just give the message "Event is not active".)
>>
>> There's a new link for each session, and I did notice that this
>> afternoon's link was erroneously pointing at the morning session.
>>
>> eg: http://www.streamtext.net/text.aspx?event=MAGam&chat=no
>> vs: http://www.streamtext.net/text.aspx?event=MAGpm&chat=no
>
>During the morning session, the morning session link also didn't
>work.

I didn't make a note of the link I used in the morning.

>> That's a webmastering/editing issue
>
>and a "lack of testing / double-checking" issue.

Yes, that's a problem that any organisation faces when setting up remote 
participation. It's very difficult to get everything right at the first 
attempt. The reason why ICANN and RIR remote participation works fairly 
smoothly is because they've had lots of practice, and why the RIR I used 
to work with, offered assistance for Vilnius.

But even then you still get sessions where one problem or another means 
remote participants don't get the feed properly (missing sound is one of 
the most common, as I hinted yesterday).

>> not a technology one!
>
>Agreed. But why didn't anyone (with the power to get issues fixed)
>check that the links work?

Experience, lack of time, any number of reasons why it's hard to make 
things run exactly to plan. They did a comprehensive sound check at the 
beginning of day 1, which was good. But things still went wrong later in 
the meeting.

>Wouldn't chances be that it'd be checked have been better if there had
>been awareness that the Adobe "solution" doesn't work for everyone?

Not at all, the presence of the chat window alongside the webcast made 
it very easy for participants to exchange notes between themselves and 
the ITU technician, regarding issues such as the sound quality.

>>> Isn't the kind of violence which is present here precisely the
>>> refusal of fairness with regard to openness of interfaces?
>>
>> The fairest thing to do is deploy a solution that's instantly available
>> to the largest number of users. It would be even more unfair to deny
>> that to them. Fairness is not ensuring that everyone is equally poorly
>> serviced.
>
>I'm not asking for downgrading of service for anyone.

Banning Adobe, for the reasons you given, would downgrade the service 
that I get. Unless you are aware of a substitute which is "better", and 
conforms to your requirements for "open-ness". I'm not aware of any such 
application (see also my replies to Avri).

>But I'm asking you to stop pretending that the problems which I'm
>pointing out don't exits

Of course there are problems, all remote participation solutions have 
problems. What we need to understand is whether the currently deployed 
technology is less likely to demonstrate problems overall, than other 
ways of doing it.

>or are irrelevant to internet governance.

They are relevant to the governance of meetings which happen to be about 
Internet Governance. But that's a different thing. Imagine the meetings 
were discussing planes and airports instead. Would Adobe connect then 
become an "air traffic control" issue?
-- 
Roland Perry
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, visit:
     http://www.igcaucus.org/unsubscribing

For all other list information and functions, see:
     http://lists.cpsr.org/lists/info/governance
To edit your profile and to find the IGC's charter, see:
     http://www.igcaucus.org/

Translate this email: http://translate.google.com/translate_t