Skip to content

Latest commit

 

History

History
67 lines (59 loc) · 4.09 KB

SEP_005.md

File metadata and controls

67 lines (59 loc) · 4.09 KB
Raw

SEP 005 -- SBOL Voting Procedure

SEP 005
Title SBOL voting procedure
Authors Raik Gruenberg
Editor Raik Gruenberg
Type Process
Status Final
Created 24-Jan-2016
Last modified 02-Feb-2016

Abstract

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).

2. Specification

2.1 Changes to SBOL governance document

This SEP replaces two sections within the governance document (http://sbolstandard.org/development/gov/): "Voting process" and "Voting form". Note: Election rules remain unchanged.

2.2 Voting Process

  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.

Copyright

CC0
To the extent possible under law, SBOL developers has waived all copyright and related or neighboring rights to SEP 005. This work is published from: United States.