[Fedora-ambassadors-list] FAMSCo election?
Patrick W. Barnes
nman64 at n-man.com
Tue May 23 03:26:41 UTC 2006
After reviewing the other posts in this thread so far, here's my basic view of
what has been said so far:
1. The Voting System
Our solution for this will follow the plans for other committees. Anyone who
is registered in the Fedora Account System and is a member of the
'ambassadors' group will have the opportunity to vote. The system for this
has yet to be created, but each voter will need to log in using their
registered account. They will then be able to place their vote. Their vote
will be added to a statistical pool and will not be connected to their
account. The account will be marked as having entered a vote in that
election, preventing multiple votes. The number of votes permitted for each
election could be adjusted, but that will be dependent upon the rules decided
for each election.
2. Election Committees
There will be no need to create specialized committees to manage elections.
The community as a whole (the Ambassadors, in this case) will be able to
agree upon appropriate guidelines for elections. Once those rules are
established, the infrastructure will handle almost all other concerns. If
issues arise, the community will always have the power to revisit decisions
and refine the process. The Infrastructure team will be responsible for
maintaining the voting infrastructure and handling accountability concerns.
3. Remaining Questions
The questions that remain to be answered are merely guideline concerns.
Decisions have to be made regarding the frequency of elections, total number
of seats, number of seats to be opened for each election, nomination process,
nominee eligibility, voter scope, number of votes for each voter in each
election, whether or not multiple votes can be entered by one voter for one
nominee and number of terms each committee member can serve. Other concerns
may also arise, but these are the basics we need to figure out.
a. Frequency of Elections
Common ideas elsewhere in the Fedora Project have been for 6-month or 1-year
regularity. I personally feel like 6 months is reasonable.
b. Total Number of Seats
The current steering committee has grown since its inception. We should try
to decide if the current number of seats is reasonable, or if the number
should be adjusted.
c. Number of Seats Opened for Each Election
Instead of replacing the entire steering committee in each election, or even
taking the risk of doing so, we can create multiple sets of seats and open up
only one set in each election. For example, we could use a 6-month election
frequency and give all steering committee members a 1-year term. We could
then put up only half of the seats in each election. This would keep the
committee from becoming fractured or introducing confusion by making radical
changes to the members.
d. Nomination Process
We need to decide how new nominees will be selected. We could easily follow
the FESCo model for this.
e. Nominee Eligibility
What requirements do we want to introduce for steering committee members? For
example, do we want to require potential nominees to be part of the group for
at least x months before they are eligible?
f. Voter Scope
Who can vote? I think that requiring membership in the 'ambassadors' group of
the Fedora Account System is sufficient, but others might feel differently.
At the very least, that membership will be required, but we could add more
requirements.
g. Number of Votes for Each Voter in Each Election
The simplest model would be to allow one vote to each voter in each election,
but we could also allow multiple votes. This would allow voters to cast
votes for multiple nominees. Since we are electing a committee of many
members, allowing multiple votes may make sense, but we should not allow more
votes than the number of open seats.
h. Whether or Not Multiple Votes Can Be Entered by One Voter for One Nominee
If we do allow multiple votes, we should decide whether or not a single voter
can vote for a single nominee more than once. Allowing this would give one
voter the ability to give all of their votes to a single nominee. This could
have a significant impact on how votes can be allocated.
i. Number of Terms
We must decide if we want a limit on the number of terms any member may serve.
In a community of this sort, I don't believe it makes much sense to place
such a limit, but it is an option to be considered.
4. A Few Things to Remember
As we move forward in establishing these guidelines and carrying out our
elections, there are a few things to keep in mind:
a. We are a meritocracy, not a democracy.
In this community, voting is a privilege, not a right. There may be concerns
above the Ambassadors program that may require intervention and may work
against the wishes of the general community. Obviously, it is in the best
interest of the Fedora Project to keep contributors happy and comfortable,
but some understanding may be necessary.
b. We are not alone.
The Fedora Ambassadors Project has the Fedora Project Board above it and many
other projects as its siblings. This means that we must cooperate with them
and that we can refer to the practices of the other projects for guidance.
We cannot conflict with the other projects and cannot disregard them in
establishing our governing processes.
c. Leading community members are here for a reason.
As the Fedora Project is a meritocracy, the current leaders have their
positions because they have established their participation and have shown an
interest in the project. Anyone who will become a Fedora Project leader must
demonstrate leadership abilities and a devotion to the Fedora Project. This
is not something to be taken casually. Established community leaders also
deserve a degree of recognition for their accomplishments, but they must
continue to demonstrate those characteristics in order to remain in
leadership positions.
Now, who has something to add? :-)
--
Patrick "The N-Man" Barnes
nman64 at n-man.com
http://www.n-man.com/
LinkedIn:
http://www.linkedin.com/in/nman64
Have I been helpful? Rate my assistance!
http://rate.affero.net/nman64/
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-ambassadors-list/attachments/20060522/8d67bb6a/attachment.sig>
More information about the Fedora-ambassadors-list
mailing list