This document enumerates proposals for voting benefits of the proposed Webizen program.
For more information on the proposed Webizen program see the [ Webizen wiki].
This document is a WorkInProgress (WIP). Feedback is welcome, preferably by directly editing this document or by sending email to
email@example.com (archive) with a Subject: prefix of
[Voting]. We are also interested in input from non-Members i.e. The Public.
There are many different mechanisms for voting and it will no doubt be controversial regarding what voting technique should be used by Webizens to select AC reps.
In W3C TAG and Advisory Board elections each voter can vote n times if there are n different seats. This has the desirable effect that the n "best" candidates need not compete with each other - they can all be named on every ballot. It has the undesirable effect that if a significant minority of voters prefer one slate of candidates and a majority prefer a different slate, that the minority gets no voice while the majority can take all of the slots.
For the Webizen vote, this undesirable effect is a significant issue. Voters could be distributed around the world and may not know people in other regions of the world. The W3C approach to voting could disenfranchise significant numbers of Webizens in the election.
This is not to say that geographical representation should be the major issue for Webizen voting. But it is at least one consideration where AC style voting is likely to lead to frustrated groups.
There are several approaches to addressing this.
A popular approach is Single Transferable Vote (STV) . This removes the problem of shutting out the minority. But it introduces other problems. If balloting is for 25 candidates, it might be hard for voters to list all of their preferences - but there is no requirement to do so. And in general, STV is harder to count - but far from impossible.
Other organizations (e.g. IEEE ) have a regional component to their voting. Over a longer period of time, we need to explore the best voting mechanism for Webizens which may have a regional component.
Initially, there would be value to keep the voting mechanism simple and we should avoid the possibility that a "majority" region gets all of the seats.
In this space, we accumulate various proposals to voting mechanism. In the early years, we anticipate that the voting mechanism will be modified regularly (every year or two), until Webizens are comfortable with the mechanism.
- Any Webizen can run for an AC position
- Every Webizen gets one vote
- If there are n seats available, they go to the top n vote-getters.
(In the view of this proposal writer, until n>9, we do not make the vote more complicated).
Under this proposal, if multiple candidates run in a certain region of the world or to represent an identifiable community, they will compete and result in fewer or no representatives from that part of the world than the voters from that region or community.
- Any webizen can run for AC.
- Any webizen votes for as many candidates as they want, ranking them in preference order.
The winners are determined by "Schulze STV" voting.
To count the votes we could use the Open Source code available.
We could also run the entire election through the online implementation. it takes minutes to set up.
- Proposals for voting mechanisms are due by January 1, 2015
- Webizens will select their preferred voting mechanisms for the first year by April 1, 2015
- Nominations for 2016 are due on July 1, 2015.
- Nominee statements are due on August 1, 2015.
- Election period is September 1 - October 1, 2015.
- Position is help for one year, from 1/1/16 until 1/1/17