This document explains the concept of Webizen Advisory Committee (AC) representation and enumerates various proposals for how Webizens would vote for their AC representatives.
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
firstname.lastname@example.org (archive) with a Subject: prefix of
[Voting]. We are also interested in input from non-Members i.e. The Public.
Webizen Advisory Committee Representation
The basic idea is to choose a number of AC reps which gives Webizens a real voice in the AC. On the other hand, given that the reps don't have an ongoing business relationship with their electorate (unlike AC reps for Member companies), and may not be able to represent whether there is commitment to implementations (unlike AC reps for Members) we will limit the number of reps - at least initially. We reserve the right to expand the limit over time.
The Webizen AC reps would have some, but not all, rights of an AC Member. They may review Charters and REC track deliverables, participate in ac-forum discussions, may attend AC meetings, may nominate for the TAG and AB, and vote in TAG and AB elections. They may accept Member-confidential information, but may not distribute Member-confidential information within their companies (since their companies are not Members) or among Webizens (because re-distribution to all Webizens means it is no longer in Member space). They cannot nominate themselves or anyone else to participate in Working Groups.
The Webizen AC reps would also have write-access to the official W3C blog.
The number of reps for the Webizen community is N/200 with a cap of 25, where N is the number of Webizens that have signed up. If the number is smaller than 10, they would be elected on an at-large basis. If larger than 10, we might devise a regional representation scheme.
No single company may have more than 1 AC representative. Thus, employees of Member companies cannot be Webizen reps, and if more than one rep is elected from a company, the one with fewer votes would need to step down.
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