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 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/ --
Attachment:
pgplWDjGBXQMm.pgp
Description: PGP signature