Return to self-nomination Forum - Message Thread - FAQ

Username: dblake
Date/Time: Wed, May 31, 2000 at 6:42 AM GMT
Browser: Microsoft Internet Explorer V5.0 using Windows 98
Score: 5
Subject: Egregious flaws in Proposed Rules for Self-Nomination

Message:
 

 
        There are fundamental flaws with the “Proposed Rules for Self-Nomination”. The list below addresses the most egregious, and owes something to a number of other comments in this forum and others.

ISSUES:

1) The time table for nominations, campaigning and election is exceptionally compressed.

2) The restriction on supporting only one nomination (Rule 6) is patently ridiculous and totally undemocratic.

3) There is a distinct “incumbent” advantage built into the rules for NOMCOM candidates (a “sun-rise” period, as it were…).

4) The 10% rule is vague (10% as of which date?) and, as it is based on total *eligible* voters, could potentially be a bar to any and all candidates in a low turn out region. This is particularly problematic in combination with the restriction on nominations mentioned in 2) above.

5) The term “self nomination” itself is prejudicial.


DISCUSSION AND RECOMMENDATIONS:

1) Article C of the GAC communiqué presented at the ICANN Cairo meeting  stressed  the importance of “establishing a fair and effective process for elections”, and “urges ICANN to consider the extension of the September 30 [sic] deadline … in order to meet this important objective.” 

If the At Large members are to be viewed as credible representatives of the “At Large” internet community, then the unduly compressed time-line for nomination, campaign and election needs to be revised.

I join the GAC in urging ICANN to revisit the timing  and scheduling of this election.

2) Requiring individuals to determine who they will support in an election before the nomination list is final, and before campaigns have even been started, is among the stranger manifestations of “democracy” ever offered. There are immense problems with this proposal. Will members be allowed to “revoke” their endorsements? If so, then a campaign for nomination will live in constant fear of having all of it’s votes evaporate at the last minute. If not, then many members will not willingly give their support until the last minute, as they assess which of several possible candidates to support for nomination, and await developments in statements and positions of other potential candidates. The entire campaign process (already compressed) will, of necessity, be shifted forward to the nominating phases. 

If enacted as written this will further erode the credibility (and thus, usefulness) of the At Large board members.

The interest of the members and ICANN will be far better served by members being able to support multiple nominations. Along with Recommendation 1), above, this would allow for a meaningful selection of candidates.

3) Candidates tapped by the NOMCOM under the current proposal would have almost twice the campaigning time as other candidates. Considering the problems noted in 1) and 2), above, this offers a very flawed process. Depending on the degree to which Recommendation 1), above, is accepted, this issue becomes less worrisome, though it still presents a challenge to the legitimacy of the finally qualified candidates, both NOMCOM and others.

One option the Board should consider: The NOMCOM selects it’s candidates, but requires them to qualify for the ballot in the same fashion as any other candidate. This would ensures that all candidates address the issues of the At Large members, and not merely the NOMCOM and Board.

4) The issue of qualifying candidates is always a contentious one, but especially so when dealing with a relatively small electorate base. The choice comes down to requiring support from either a) relatively high portions of the likely voters, or, b) relatively low numbers of actual supporters. A compromise along the lines of point 5 of the recommendation offered by the CPSR is in order.
(see link)

5) The comments here in this forum and elsewhere display two main responses to the prejudicial nature of the “self nominated” designation. The first: replace it with a more neutral term, such as “Member Nominated”. The second: remove the distinction entirely by concealing the nature of NONCOM tapped candidates.

In the main, the members and ICANN will be best served by member’s retaining the knowledge of  who has been tapped by NOMCOM, but treating them in all other ways identically with “Member Nominated” (or other appropriate designation) candidates. This will significant aid the credibility of the eventual winners of the election, regardless of Nomination process.

And finally, it is worth invoking some of the documents that have provided the basis for ICANN’s formation and structure:

Article 2 of the White Paper states that “Nominations to the Board of Directors should preserve, as much as possible, the tradition of bottom-up governance of the Internet”.

Article 8 of the MOU specifies that the ICANN “membership mechanisms”  should “foster accountability to and representation of the global and functional diversity of the Internet and its users.”

In their present form, the Proposed Rules for Self-Nomination present many challenges to these specifications and goals. It is apparent that many of the problematic sections mentioned in 1) through 5), above,  were designed to ensure that only “competent” and “non-disruptive” persons are presented as viable candidates, at the expense of these goals and specifications.

If there are such deeply held suspicions concerning the ability of the At Large members to select qualified candidates, then the purpose, role  (and existence) of the At Large members should be re-evaluated.

Considering that the At Large membership will eventually elect almost 1/2 of the seats in the controlling body of one of  one of the worlds most important international resources (there is more truth to that than any of us can yet know), this process requires a demonstrably fair election.

Unless the Recommendations above (or others that address many of the same issues) are accepted, this will not happen.
     

 

Link: CPSR COMMENT


Message Thread:


Privacy Policy | Terms of Service | Cookies Policy