=============== FESCo Elections =============== The recent FESCo election was a success in the sense that we ran it without technical difficulties, mudslinging by candidates, or charges of corruption. There remains much that we could do better in the next election cycle. Let's discuss the issues now so we have time to implement them before the next election. The following are some of the recognized issues and some possible solutions. Voter Turnout ============= Not a lot of the eligible voters actually cast ballots. Is this a problem or just an indication that all the candidates were acceptable to most people? One thing to try would be to incorporate a nag message into the next election. When the election opens, all eligible voters are emailed directly that they can vote. When voting is about to close, those who haven't voted get a new message reminding them that the election is about to end. Election schedule ================= When should elections be held? Tieing it to Fedora Core releases seems to make sense. In that case, would it be better to put half the seats up every election? Or to put every seat up for election after two Core releases? The first leads to elections roughly every 6 months and assures that some old blood is around after every election. The second method depends on former FESCo members deciding to renominate in order to keep continuity but has the benefit of having less elections for us to administer and for Extras members to have to remember to go and vote for. Comments on which plan is more appealing is highly appreciated. Formulation of the Ballot ========================= Contingent Nominations ---------------------- "Contingent nominations" were confusing. Here's my proposal for next election: If there are enough candidates to fill the ballot (See next paragraph for how many this is) without the contingent nominations they will not be added. If they are needed to fill the ballot, they will all be added as regular candidates. There will be no official after-the-election turning down of positions so other people can be on FESCo (We can't stop unofficial resignations, only enforce this through tradition). If contingent nominees want to do something like that, they should have their names taken off before the election starts. Number of Candidates Required for Elections ------------------------------------------- Having choices on a ballot is essential for making it worthwhile to vote. How many people are enough to fill out a slate of candidates? Should we hold off on starting an election until we have number of seats +1 candidate? Number of seats +X? Number of open seats + 25%? I would like to see us hold the start of elections for up to one week to try to get number of seats + 25% (For a 13 member FESCo with half the seats up for election, this equates to number of seats +2). After that, we just have to live with however many people are on the ballot. Lack of Candidates ------------------ Assuming that our cycle of elections will be terms of every 2 Core releases with elections for half after every release I propose we deal with not having enough candidates to fill all the seats this way: FESCo will run with less members for that Core release. The seats will be added to the next election. The lowest vote getters in that election will get the FESCo seats until the next core release, at which time the seats will be open for election again (so we maintain elections of roughly half the seats each time.) Term Limits ----------- Should there be term limits for FESCo in general? For the chair in particular? My personal feeling is that we're enough of a meritocracy that term limits for FESCo membership don't make sense. If someone feels they can best help the project by being on FESCo and the voters agree, then they should remain on FESCo. Defining how long a FESCo member can be the chair would be advantageous for rotating the duties and responsibilities of the position. No chair need feel guilty for giving up the position if it's written into the bylaws that they have to to yield the position after a certain time limit. Is a year the appropriate time span? Resignations and Election System ================================ What happens if someone resigns? Do we automatically go to the people previously up for election? Do we hold a special election? In the interests of efficiency and avoiding voter burnout, I would like to avoid special elections between Core releases. Instead, I propose selecting the runner-up candidate from the previous election to serve out the term (no matter if the remainder of the term is one Core release or two). Regarding this, there was some discussion about the GNOME Board[1]_ recently where the bloc voting method (there are 13 open seats, vote for at most 13 people, the 13 with the most votes will get in) was shown to be unfair when dealing with resignations. Basically, bloc voting gives you 13 votes to distribute among candidates. If one of those candidates resigns, one of your votes that could have gone to someone else has become irrelevant. If we change our model, what are our criteria for a new system? My criteria are: 1) it should be to something simple and easy explain to the voters, 2) it should not require complex calculations to determine the winner, and 3) should address the issue of votes being wasted if someone resigns. Approval voting (Vote for as many candidates as you like. The 13 with the most votes will get in) and range voting (There are X candidates, assign each of them from 0 to Y points. The 13 with the most points will get in.) Would both satisfy these criteria. I favor range voting where for 13 seats you can assign from 0 to 13 points to each of the candidates as this allows you to simply tally the votes at the end to see who the winners are, express your feelings as simple approval (13 for approvals, 0 for disapprovals) or in simple ranking if you are inclined. [1]_: http://blogs.gnome.org/view/jamesh/2006/06/06/0 Voting App ========== The voting application we used for this election was simple but effective. There are a number of enhancements that would be nice in the future. It would be nice to expose the results of past elections. It would also be nice to combine ballots with the Fedora Board when their elections come up so you don't have to go to two URLs to vote. I'd like to see an introductory screen that lists which elections are currently in progress, past elections, and upcoming elections. The voter can click on the past elections to see the results. Current elections asks the voter to login. Once logged in, they are given the ballots for each election they are allowed to vote in. Should voters be able to see current positions on in progress elections? As long as the voting model is simple, it shouldn't be too hard to display the current standings. We will soon have Turbo Gears available for Fedora web apps. The voting application could use this framework if it makes it easier to enhance. Are there other people interested in working on the voting application or am I going to continue to be the primary mover of this project? Feedback ======== Let's discuss these proposals and any other problems people observed with the election process! I'll start a draft of elections policy for FESCo to review and vote on based on the discussion that takes place here. -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
