Charter: Voting

Continuing on with the project charter, today I want to outline the sections related to voting mechanics. As discussed in several previous articles, the voting is going to be split up into three main areas: general votes, design voting, and leadership voting. There's still a lot that's open to change for these, particularly the exact voting methods used in each section; But we can always amend them later once something basic is in place, and we get a better sense of the overall voting dynamics.

Before getting to the specific voting structure, I'd like to give a quick rundown of what needs to be decided for each type of vote:

• Voting Method: Yes/No, Multiple Choice, +/-1, etc.
• Deadline: We can't leave votes open forever, we need to decide how to consider them finished, whether with time limits or dependent on some external trigger.
• Multiple Share Voting: We will have to bear in mind how those with multiple shares will be able to exercise the corresponding voting power.
• Abstentions: Realistically, we're likely to have a fair number of people who don't vote at all, and we have to decide how that decision applies, whether as assent or non-assent.

With those in mind, let's look at the different forums for voting.

General Voting

The General voting section is intended as a place for large decisions relating to the project's overall direction. As such, it shouldn't really see too much use. It will be divided into two subsections: Motions and Referendums.

Motions are proposals for referendum votes. They take the form of a yes/no or multiple choice proposal to be presented to the community. The actual votes for the motion, however, will be on a +1 basis. In other words, a member who supports bringing the question to a full vote will have one vote per share to vote for the motion (abstentions having no effect), which will be given a rating based on the total number of positive votes. Motions which accumulate a certain number of positive votes will be considered "seconded" and the question they contain will become a referendum item. Motions do not expire unless the proposer withdraws them, or the proposal they contain becomes obsolete. Both proposing on and voting for motions is limited to Shareholders (as discussed in last week's article on Membership.)

Referendums are general votes, open to any Pledge Member or Shareholder; holders of multiple shares will have their vote weighted at that multiple. The individual votes can be either yes/no or multiple choice, depending on the motion proposed. The votes will be open for a set period after the motion is seconded, perhaps about one month. Referendums will pass based on the type of vote: an issue vote will pass with a simple majority, with abstentions having no effect. A motion to make changes to the project charter, on the other hand, will need to pass with three-fourths of the vote, abstentions being considered as votes for the status quo.

The underlying idea here is to keep the bar for motions becoming referendums fairly high, to make sure only really important issues make it into the Referendum forum. There are also several special votes which would be included in the general voting area: One is a vote of No Confidence in the current project board (as described below.) Another is the final vote for the game's release. The others are the votes for developer selection as described here.

Design Voting

The Design area is where members can directly influence the game design. It's open to all Pledge Members and Shareholders, although only Shareholders are allowed to propose new features. There would be two subsections of this area: the main Features area and a smaller area for Decisions.

Features are individual elements of the game, presented in a set format (as a developer might say, they are "user stories.") They will remain open indefinitely. Members will be able to express a preference for the features they believe are most important; These highly-rated features will become part of the Mandate. Moderators will have to be appointed to make sure individual proposals are appropriate in scope (i.e., one proposal = one feature, not a huge wishlist.)

The big question for features is which voting method to use. We could either go with:

• +1, Limited Votes: In this model, each member would receive a certain number of votes per share (say 15). They would be able to allocate these votes as they wished to the features they believe are most important: either spread them across 15 items, or give multiple votes to the items they feel strongly about.
• +/-1, Unlimited Votes: This would be a format similar to that used on Stack Exchange sites, in which members would have one vote per share on any item, which could be either positive or negative.

Both these methods have strengths and weaknesses; The latter is likely easier to implement, but the former requires more careful thought about how to allocate votes.

Stack Overflow and related websites use a +/-1 system to bring the most relevant content to the top.

Another part of the Design area will be the Decisions forum. This is a special area for issues on which a choice is necessary. For example, there might be two equally popular features in the Features area which are incompatible in their implementation. In this case, the moderators could create a decision vote between the two features to show which is preferred.

The Design area will also be open for the developers to propose features and decisions, as in cases where several design choices are possible and they would like direct feedback from the community.

Finally, it should be noted that the contents of the Design forums will change once the developer is selected and the game is feature-frozen for development. At that point, the Features area will be replaced by the voting area for release criteria, as described here.

Leadership Voting

The final area of voting is the Leadership area, where the project members can select the Board of Directors that will oversee the project. Both will be open only to Shareholders. Leadership voting will be spread over two forums, Nomination and Elections.

The Nominations area will be a place for individual members to put forth their name as a candidate. A nomination will have a standard format, including basic information about the candidate and statements about their qualifications, goals and vision for the project. Votes on nominations would be on a +1 basis, in the same fashion as the Motions forum. A nominee who received enough votes would be moved to the Election area as an official candidate. At this point, they would also be required to verify any information about their experience, qualifications, etc. that appeared in their nominee profile.

The Elections forum will be opened when it becomes time for a general board election. The candidate list will be made up of all the nominees from the nomination forum, as well as any incumbent directors who wish to stand again. The election itself will last for a relatively short period, perhaps two weeks. Members will receive a set number of votes per share to allocate as they see fit, either to a single candidate they prefer strongly, or to multiple candidates. Those candidates with the most votes will become the board of directors, with the highest-voted candidate serving as chairman.

If all goes well, it should only be necessary to hold elections once, as board members will serve until the game is released. Further votes would happen in only one of two cases:

• If a member of the board resigns, there will be a special election for the open seat.
• If the majority of members are unhappy with the project's direction, they can propose a vote of No Confidence in the Referendum forum. No Confidence votes would require a 2/3 majority to pass, with abstentions considered as votes for the status quo. If a No Confidence vote passed, the current board would be dissolved and a new general election would be held.

I think this setup will provide members with a comfortable degree of control, while still giving the board and the dev team some latitude to run the project day-to-day. Obviously there are still some decisions to be made, most notably the most appropriate voting method for the Features area. If you have feedback or further ideas please let me know!