SEP 005 -- SBOL Voting Procedure

[graik]

SEP 005 -- SBOL Voting Procedure

SEP	005
Title	SBOL voting procedure
Authors	Raik Gruenberg
Editor	Raik Gruenberg
Type	Process
Status	Draft
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

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.

[jakebeal]

Two notes:

1. I do not believe we want to modify SEP SEP 003 -- SBOL Governance Update #3 , which is an adopted proposal to modify governance. Instead, we want to modify the governance (just as SEP SEP 003 -- SBOL Governance Update #3 did).
2. I would suggest modifying the first bullet to make it clear what "submit" means:

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

This makes it clear that "submit" doesn't mean "obtain permissions to post an issue in this repository"

[graik]

I have adopted the "submit" statement as you suggested. Thanks!

Regarding changing SEP 3, I agree that this is not optimal though all the alternatives may be worse.

(1) Alternative one (easiest): We replace SEP 3 by a new SEP 6.
(2) Alternative two: We create an external governance document (e.g. in the git repo) which is then updated as SEPs are adopted. This may complicate the SEP idea. I.e. the process SEPs are then existing in parallel to a "code of law". The Python community gets away without that by just having process SEPs and replacing them as needed.

What we, I think, we cannot do is simply adopt SEP 1,2 and 5 without doing anything on SEP 3. Because in that case we would have at least two active "process" a.ka. governance SEPs that are in direct conflict which each other.

[graik]

Actually, the way "government" aka Process Python Enhancement Proposals seem to work is that they can be modified in place by a vote. That's why they are given status "Active" rather than "Final". The difference is that their PEPs are are under version control so that it is easy to back trace changes.

So what we could do is, instead of using another SEP to describe how to change SEP 3, we simply put the updated SEP 3 to a vote together with 1, 2, and 5.

[jakebeal]

As discussed by chat: we already have an external governance document, sbolstandard.org/developers/gov, which is what SEP #3 targeted, and will be doing that.

[graik]

As discussed during the last editors call: Clarified that this SEP changes the sbol governance document online (rather than SEP #3).

[jyquinn]

Sorry that these are coming in late, but a few notes:

• Why is the follow up vote less stringent than the original?
• Might be good to explicitly state how signal from "reject" vs. "defer/table" votes is used, otherwise there's not much point in including the deferral option. e.g. is there a threshold for "reject" votes that would cause the SEP to be thrown out immediately?
• Might also be worthwhile to add explicit information here regarding how voting results are reported to the developer group (on the SEP? In the body or in a comment? Posted to the sbol-dev list?)

[jakebeal]

Hi, Jackie:

• The followup being less stringent than the original is not a change: it has been that way in the governance previously as well.
• My understanding is that the distinction between "reject" and "defer/table" is to make sure there's a clear understanding of the feelings of the community. I don't believe that we need to specify a specific action to be taken. The default threshold, however, would be as specified: 67% majority, indicating rough consensus; in practice, however, if anything is ever put to a vote that gets a large "reject," then there is likely a larger problem in the community to be dealt with.
• I'm not sure there's a need to say how votes are reported: that feels like it might be adding a level of detail to the process that we are likely to later need to amend.

[graik]

Hi Jackie,

your point 2: I agree that the defer option could be better explained. The
effect of defer is that the proposal remains in a "draft-like" state
(rather than being officially "rejected"). It remains on everyone's radar
screen and can easily be put to a vote again. Most likely after further
discussion and amendment and at the discretion of the editors (or any two
other members of the list). That's quite different from reject = "not a
good idea" or abstain = "I don't care either way".

point 3: We don't have any concrete rules about that, have we. Announcement
to the mailing list still seems the most sensible and obvious thing to do.
Though it could be good to also add a comment or section to the SEP for the
purpose of documentation. Any preference?

On Wed, Mar 2, 2016 at 5:09 PM, Jacob Beal [email protected] wrote:

Hi, Jackie:

• The followup being less stringent than the original is not a change:
  it has been that way in the governance previously as well.
• My understanding is that the distinction between "reject" and
  "defer/table" is to make sure there's a clear understanding of the feelings
  of the community. I don't believe that we need to specify a specific action
  to be taken. The default threshold, however, would be as specified: 67%
  majority, indicating rough consensus; in practice, however, if anything is
  ever put to a vote that gets a large "reject," then there is likely a
  larger problem in the community to be dealt with.
• I'm not sure there's a need to say how votes are reported: that
  feels like it might be adding a level of detail to the process that we are
  likely to later need to amend.

—
Reply to this email directly or view it on GitHub
#5 (comment).

---

Raik Grünberg
http://www.raiks.de/contact.html

---

[jyquinn]

That all sounds reasonable. I think it's worth explaining the purpose of the defer option - both what selecting that options means and how it is acknowledged in vote counting (e.g. If it doesn't pass and there are enough votes for defer, it's tabled/reconsidered/prepped for second voting). Doesn't need to be set in stone here necessarily, but I think it's worthwhile explaining the purpose of including it.

With point 3, I don't see the harm in saying in the SEP that results will be reported to the mailing list and recorded in the SEP (with counts for each voting option).

[graik]

Voting closed on March 10th 2016. This SEP was accepted.
Votes: 25
Accept: 24
Abstain: 1