RE: [ga] RE: Selecting Comments to Read Aloud

["Ben Edelman" <edelman@law.harvard.edu>]

Joanna Lane wrote:

> ... the underlying message the Berkman
> Centre is sending to this list in all its posts is how to justify
> dismissal
> of the fundamental principle that remote participants and attendees should
> have equal rights to participate in all procedures of the public meeting.
> This is wholly unacceptable.

I don't think this is the message we're sending.  Certainly it's not the
message I *intend* to be sending.  And I think the facts will back me up on
this.

> ...
> having rejected numerous sponsorship offers to assist with
> implementing new
> technology that could resolve some, if not all of these issues.

To the best of my knowledge, one suggestion (of a specific technical
mechanism) has been made recently in this forum: firetalk.  Now, that's not
a program I personally happen to be familiar with, and I'm honestly not
prepared to experiment with something new on two weeks notice -- in an
unfamiliar location,  11000 miles and eight time zones away from "home
base," at that.  To do so would in some respects put at risk the entire
webcast effort -- and whatever you think of it, I hope you'll agree that
it's definitely better than nothing.  I'd like to think I make this critique
in a relatively objective sense -- for I'd equally criticize such a change
at this time if it came from a member my team, and I'd expect them to
criticize such a suggestion coming from me if I were to advance such a
proposal this late in the planning process.  (Note also that we've never
first used any major technology at an ICANN meeting; rather, we test our
infrastructure at smaller Berkman Center events in advance of ICANN
meetings -- a procedure which, whatever one might say about its necessity,
has served us well in terms of learning about problems in advance, achieving
what we consider remarkable stability, etc.  This too would be impossible
given the timetable.)

Incidentally, I don't know that sponsorship of the webcast has been
especially forthcoming for the Melbourne meetings.
<http://www.icann.org/melbourne/index.html#sponsors> reflects that ICANN
continues to recruit webcast sponsors, but to the best of my knowledge has
not received any as yet, and their web site reflects no webcast sponsors as
yet, whereas in prior instances I believe they've been prompt in posting
sponsor lists as available.  I also see from the Names Council's web archive
(<http://www.dnso.org/clubpublic/council/Arc04/maillist.html>) that they
haven't been discussing webcast expenses (recall that the NC generally
recruits a sponsor to make a contribution towards the DNSO's share of
webcast expenses), and
<http://www.dnso.org/clubpublic/council/Arc04/msg00721.html> in fact
explicitly budgets $0 for webcasts.  I don't intend to raise any of this as
"excuses" for failing to consider alternatives, if in fact I improperly
failed to do so (which I think I didn't), but rather just to rebut your
claim of "numerous sponsorship offers."  In short, I want to be clear here:
Whatever offers have been forthcoming recently, to the best of my knowledge
they have not included cash sponsorship.  And the only offer of special
technical infrastructure has been of firetalk, which I discussed above and
will critique more below.

> There have
> been only negative responses, or none at all, to practical
> suggestions that
> have been put forward, such as Sotiris's proposal to consider Firetalk to
> overcome the Real Player lag, and Kendall's proposal to incorporate voting
> on selected comments to overcome duplicated questions, not to mention my
> own; all these recommendations would appear blocked for an overriding
> consideration to maintain use of the current system which
> incorporates your
> code.

First, I sense that you'd appreciate a response to the substance of the
suggestion of using firetalk.  Putting aside my serious doubts re the overly
ambitious timetable for implementing it, I've got a few other concerns:

* <http://www.firetalk.com/for_business/features/index.html> reflects a
100-user limit in a firetalk "conference."  We've had more simultaneous
folks than that during periods of peak usage of both of the last two ICANN
meetings.  (See the respective archives for more information about webcast
usage rates.)  Obviously, we wouldn't want to adopt a system with binding
capacity constraints.

* Windows-centric client.
<http://www.firetalk.com/for_business/ft_free.html> reflects that the client
program seems to require Microsoft Windows, while we've previously used
streaming technologies that support most generally-used platforms (Windows,
Mac, and Unix).  Could implement it in parallel with another system, but I'm
not thrilled by the prospect of offering superior services to users who
happen to use one kind of OS rather than another, especially not on just a
couple weeks of notice.  Keep in mind that folks in many time zones may be
severely limited in what machines they (conveniently/easily) have access to,
given the time difference.

* Customizability to fit the existing remote participation system?  It's not
obvious from firetalk's site that this is possible, though I'll admit that
I've only briefly reviewed their site, and certainly it should be possible
in principle.  But recall the need for integration with existing
infrastructure, i.e. scribing (and the scribe-to-web gateway), etc., and
also the timetable.  Potentially of serious concern

* Low market share.  It seems that the player would be a special download
for almost everyone, few folks having used it previously.  In prior
discussions, we've resolved only to use "market-leading" streaming
technology, due to the concern that many users (especially users in shared
computing environments -- schools, libraries, many businesses) may be unable
to install arbitrary third-party software.  Again, especially given the
short notice, we wouldn't want to give an arbitrary advantage to those who
owned or fully controlled their own computing hardware.

Ultimately these are reasons that could in principle be resolved with time.
But I'm explicitly not promising to follow up with Firetalk -- it seems to
me a reasonable product, however not exactly what I understand ICANN to need
here, and on balance not desirable especially for its requirement of a
special download & installation, which experience (and various articles)
suggest to be difficult for most novices.


Now, to what I take to be the main substance of your comment above: That you
perceive only negative responses from me to suggestions for remote
participation improvements.  On balance, I certainly agree that I've been
critical of most suggestions, but in the most important respects I think
your characterization is not true.  Prof Froomkin suggested a need for
increased parity between remote participants and in-person attendees, a
principle we've long articulated and attempted to follow in design decisions
over the past 2.5 years.  Accordingly, I heartily agreed with this principle
when Froomkin so explicitly mentioned it, and thinking along those lines, on
2/19 I suggested an alternative means of selecting comments to be read.
Froomkin had two interesting critiques (in short: ratio of online versus
in-person comments, and a remote participation queue clogged with "stale"
messages) which I'll respond to later this evening.  I've seen only that and
Harald's "form follows function" notes in response to the substance of my
2/19 post.

Finally, and I think most importantly: While you characterize my messages as
dismissing "the fundamental principle that remote participants and attendees
should have equal rights to participate ... in the public meeting," I
definitely don't think that's the case.  First, as I said in my note earlier
today, "that [online participants being able to vote when an in-person show
of hands is requested] is something the remote participation team continues
to find intriguing -- and something in principle we'd like to implement if
consistent with our resources and expertise, which we think it fundamentally
is."  Certainly I don't think this is dismissing the underlying principle
you (and Froomkin and I) all so clearly agree with; my message seems
decidedly consistent with it!  Rereading that note, you'll see my
explanation of why we haven't moved forward with this -- and I hope you'll
come to the conclusion that I genuinely think is accurate in this case, that
the Berkman Center would be pleased to provide such infrastructure when it
can be done consistent with the kinds of concerns with firetalk (and other
"real-time-webcast" products) that I described above.


Returning to the general principle of equality between remote and in-person
participants, I'm curious to learn how you think "vote re which remote
participants' comments will be selected" and "project the live online 'chat'
discussion on a large screen at all time" rate under such a principle.  My
own sense is that both in fact stack up relatively poorly on that front
(whatever their other merits, of course): The method of selecting in-person
comments is first-come-first-served, not voting, so a voting-based systems
fails to achieve equality between the two means of participation.  And
comments made while another person is talking are de facto forbidden (by
social norm) during the in-person meeting, while a projected chat would
bring about precisely these sorts of interruptions; even if we don't think
of displayed chat comments as "interruptions," they still clearly fail to
map to any established in-person phenomenon, and thus fail the "equality"
criterion.

So, if the only axis of evaluation were "equality between in-person and
remote participants," I find it reasonably clear that these two
modifications would rate poorly.  Now, in fact that's obviously not the only
criterion -- at least most of us seem to want to take advantage of the
unique advantages of each medium of participation.  But I ultimately fail to
understand a critique of my suggestion that's grounded in the "equality"
principle; it seems like equality cuts in favor of an online
first-come-first-served system, and against the select-comments-by-voting
and projected-chat-room suggestions.


Again, I continue to think that first-come-first-served remote comment
selection (with some minor modifications, as previously articulated and as
further discussed in a forthcoming message later this evening) is the best
way to proceed in general.  So, I look forward especially to further
comments from this list (like those already made by Harald and Michael) re
that proposal.


Ben Edelman

--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html