This commit copied SEP_005 from the comment section of the issue tracker to a real file. This will allow us to close SEP_005 out from the issue tracker while maintaining a more accessible copy of its information.

This proposal describes the voting procedure used to accept or reject changes to the SBOL data model or to SBOL community rules.

##1. Rationale

With the introduction of SEPs, SBOL voting rules need to be updated. Previously, voting could be initiated by any two members of the sbol-dev mailing list on any issue of choice. According to the new proposal, voting can be initiated only on issues that first have been documented as an SBOL Enhancement Proposals (SEPs).

1. Any member of the SBOL Developers Group can submit an SBOL Enhancement Proposal (SEP) to the editors and/or to the community at large.

2. The SBOL editors are expected to move a given SEP draft to a vote once they agree that there has been sufficient debate. However, any member of the SBOL Developers Group can initiate the vote as long as one other member of the group seconds the motion.

3. SBOL Editors post a voting form (see below), for a final discussion period of 2 working days.

4. Voting runs for 5 working days, starting at the end of the discussion period. All members of the SBOL Development Group are eligible to vote.

5. The SBOL Editors may extend the voting period by up to an additional 5 working days when they feel that an insufficient number of votes have been obtained.

6. SBOL Editors tally and call the vote. First vote will be judged by a 67% majority to indicate "rough consensus".

1. If rough consensus is not reached, discussion of 3 working days is to follow. SEP authors can modify or withdraw their proposal during that time.

2. The reasons for decisions must be recorded with the results of the vote.

3. Any second followup vote will be ruled by 50% majority and will be treated as the decision

###2.3 Voting form

The voting form must:

1. State clearly the SEP number and title being voted on and provide a link to this SEP.

2. State the eligibility criteria for voting, “All members of the SBOL Developers Group are eligible to vote.”

3. Provide the following options for the vote:

- accept -- vote to accept the SEP

- reject -- vote to reject the SEP

- abstain -- no opinion, abstain votes will not be counted when determining majorities

- defer / table for further discussion -- keep the SEP in draft stage (in contrast to "abstain" this vote will be counted when determining majorities).

4. include a field for entering the e-mail address of the voter

5. include a field for further comments.

##3. Discussion

The voting procedure is still very similar to the previous rules. New is the idea of SEPs and that it should, preferably, be the editors who move proposals for a vote. However, the proposal also still retains the previous practice -- anyone on the list can initiate the vote, as long as it is seconded by any other developer. Editors can therefore not block the vote on any issue.

Voting for election purposes remains unchanged and is described in SEP #3.