Future FESCo Elections

[Toshio Kuratomi]

===============
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20060724/abb628e6/attachment.sig>