Towards a "Voting Protocol" SOP

[nataled]

It has been noted that we lack a clear SOP to guide the parameters for voting in the OBO Foundry. Below, I've gathered what I could find on discussions regarding this topic.

NOTE 1: Below are just snippets of (mostly) suggestions. So far as I could tell, the discussions given below did not impact other discussions (which is to say that some of these were specific to the issue at hand and not necessarily meant for an SOP on Voting Protocol itself).

NOTE 2: I did not include the many times our minutes said something like "X will create a ticket and we'll vote next meeting". I do think the implication is that we generally do restrict our votes to meetings. By the way, we do routinely vote on matters of the web site.

NOTE 3: I restricted these notes to only our 'rolling' agendas, which began at the tail end of 2019).

Suggested in the context of various voting discussions

1. Only active members can vote (Note: It was suggested that attending meetings is not sufficient to determine 'active')
2. Guests would not be able to vote on decisions.

In the context of admitting new ontologies, this discussion

SOP question: should we admit based on consensus or majority vote?
Darren: we don’t usually come across this case with disagreement
The opinions of the people that reviewed should be weighed higher than the other opinions (falls on consensus side)
Nico to follow up next time with a vote about whether to admit and to follow with ontology developers.
Do we only vote with those who are present? (Nico says yes)
Alex D.: Require a ⅔ vote.
Bill D.: If only voting with those present, how many members must be present?
Chris S.: Prefers public, transparent vote on github

In the context of new members for the Ops Committee:

DRAFT: If someone is interested in becoming a member of the operations group, they should contact an existing group member, who explains to them that being a member will require committing to do some work. They agree (or are not considered). The current members are then asked via an email on obo-operations if anyone objects to adding the candidate member.

• If conflicts arise, we move to the decision process described elsewhere (first trying to find consensus, if not possible, ask for a formal vote with the majority of active members)

In the context of OMO (unclear the precise issue)
We call a vote with a timeline (2 weeks)
At least 5 supporters per vote

[nataled]

Please weigh in with your thoughts, especially on the topics of:

• Unless otherwise arranged, should voting be restricted to those on the relevant Operations call?
• If so, what should be the minimum number of votes?
• Regardless of mechanism, should we have a minimum number of votes and, if so, what should that minimum be?
• Should voting be restricted--unless otherwise arranged--to active members of Operations (whether or not on the call)?
• Are there any topics for which voting should NOT take place during a call, but instead by arbitrated via GitHub issue?
• If any vote is done via GitHub, what should be the default minimum and maximum time frames (unless otherwise arranged)
• Do you agree that 'unless otherwise arranged' voting requires that such arrangements are made by vote taken during a meeting (and restricted to attendees)?
• For votes seeking input outside of Operations meetings, how should these be advertised?

Please add any other considerations we should contemplate.

[cmungall]

Even though I am on the OC, I will only vote when the vote is public and transparent, such as via GitHub, and over some reasonable time frame (i.e does not require attending a call in a slot where I have multiple competing commitments) -- unless there are sensitivity issues, in which case closed-door votes are fine.

I accept that there are some issues for which only OC votes should count, but I think every measure should be taken to gauge community input before OC voting. One way in which this might be manifested is an open vote (e.g. on GitHub) but with the community votes being informative and the OC members votes being normative.

[addiehl]

We can't possibly request community votes on all the items that the OBO Operations committee decides on. Furthermore, definition of what constitutes the "community" is also unclear. Thus, within the deliberations of the OBO Operations committee, we need to have an established rule about when an issue requires an outside vote. And if we are asking for community voting or input, we need to ensure that we can get a representative sample of the community without excessive bias towards one part of it.