Eric Weisberg wrote:
> A system can be designed to accomplish a purpose or to fail. ICANN
> must decide whether its purpose is to afford maximum diversity of
> representation or to develop a fool proof system for conducting
> meaningless elections (in the sense of its expressed representational
> aspiration).
I am saying that the MAC made a recommendation that it preferred a more
fool-proof system with a somewhat less diverse but hardly meaningless
representation. Head-to-head elections are not meaningless, they are
simply not as nuanced. You argue that one particular value should
override all others. It is a one that the committee also cherishes; but
there are competing concerns and the committee tried to balance them.
ICANN may or may not adopt all of those recommendations.
> (....) Lets talk this through.
>
> The MAC recommends that ICANN elect all of its proposed "at-large"
> directors using a form of preferential voting, but makes no suggestion
> on how that may be accomplished. Instead, it proposes a system in
> which it can not be done. It finds that representation of diverse
> stakeholder interests/avoidance of capture is the top level concern,
> but concludes that we should not even try to accomplish that purpose
> for technical reasons!
The ICANN personnel designated to follow up on this recommendation will
be responsible for making such suggestions.
Preferential voting for two candidates is still preferential voting.
The main purpose for staggered voting is to iron out issues of
authentication. If those issues can be dealt with prior to the actual
election, then perhaps a largest field can be seated in one election.
(There were also some who felt that stability and efficiency were better
served if an entirely new Board didn't have to learn everything from
scratch, but we didn't take a vote on that). There is still the issue
of whether electronic proxy voting will be permitted under California
law. It would be helpful if you could address those issues.
> What options might ICANN consider if it wants to work out the
> technical bugs before going live with "at-large" elections? Here are
> some suggestions off the top of my head. I suspect that members of
> this list can suggest other mechanisms.
>
> 1. ICANN can employ a professional election service to perform this
> function;
Vendor election services are being reviewed, although I haven't yet seen
one service that offers all the functions that ICANN needs. The problem
is cost and it would still require testing. The problem isn't "who" can
do it, the problem is "how" can it be done and at what price.
> 2. it can experiment on something besides the real thing--hold some
> "dress rehearsals" before opening night (like a "straw" vote on which
> new gTLDs to add); or
Yes, we've talked about this. IMHO it's an excellent proposal, and I
expect they'll do a trial run before the first election anyway. Again,
though, I think you are confusing issues that relate to authentication
of the membership with issues relating to authentication of the
ballots. Solutions for one are not necessarily solutions for the other.
> 3. it might hold a single seat election, first, and the rest of the
> "at large" elections three months later.
Yup. That's a possible, too. The exact number of seats during trials
wasn't written in stone.
Diane Cabell
http://www.mama-tech.com
Fausett, Gaeta & Lund, LLP
Boston, MA
