OBOFoundry.github.io Towards a "Voting Protocol" SOP

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

Only active members can vote (Note: It was suggested that attending meetings is not sufficient to determine 'active')
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

Feb 05 '25 19:02 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.

Feb 05 '25 19:02 nataled

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.

Feb 05 '25 20:02 cmungall

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.

Feb 05 '25 21:02 addiehl

On the assumption that the scope of a vote will have to be decided on a case by case basis, one basic question is whether or not we allow the attendees of an Ops meeting to decide that scope. In other words, if--during a given meeting--we decide a vote is needed, do we abide by the decision made by the attendees of that meeting as to how widely that vote needs to be?

Feb 18 '25 17:02 nataled

Voting SOP #2680 (Darren) To define what we vote on? Website? Policy? Asking Operations for their input: What is the purview of the OBO Ops to make decisions? Review of ontologies to join OBO Foundry On the Ops call: Decision making Ops: How a Principle is worded Accepting/not accepting an ontology Vote during call Looking for consensus Suggestion to then post these votes (in these minutes/GitHub) In two weeks the vote is finalized (thus giving time for community feedback) What needs to be addressed at the community level vote? On an Ops call - discuss - does this need Community input?

Email from Bjoern in 2014, the origin of OBO operations, and initial ‘vote’ process: “During ICBO we had several discussions on how to fix the decision making process in the OBO foundry. A fix is needed because, despite all the progress by the various working groups, some important decisions are not being made. This became clear in the OBO Foundry workshop where questions relating to establishing standard practices could not be answered.

Right now it is not completely clear for which decision the coordinating editors should be consulted and how people who are doing more hands-on work should enforce decisions. This situation is very similar to the one the OBI project was in several years ago, in which a 'coordinating committee' made up of community representatives was making higher level decisions, while the 'developers committee' consisted of people actively contributing to the ontology. Ultimately, the problems thereby caused were resolved by merging the coordinating committee with the developers committee, which led to a much less complicated politics and faster decision times.

We propose to do the same for the OBO foundry: Let's create a single board of members of the current Coordinating board the Operating Committee and various sub-committees (Technical, Outreach and Editorial). The new board would have regular phone calls and make decisions on policy. Our proposal is that normally decisions should be made by consensus. If that cannot be reached, a formal vote can be asked for, which is carried out on a wiki (or some other electronic solution) where all active members can participate and decisions are made by majority. Membership in one or more of the committees and the board would rest on active contribution to the foundry work, participating in phone calls or meetings, etc. Many of these ideas have been discussed already at operations committee meetings, and those of us here at ICBO would like to see the foundry move forward on them”.

For a decision, let’s make a decision on how widely the vote needs to be.

Q: Broadly, what should be eligible for an Ops decision? A: Any change--website, policy, principles, new ontologies, etc.

Q: Specifically, what should be voted on? A: Anything that attendees of a given call request. Only a single(?) person needs to make such a request. If no one thinks a vote is necessary, then no vote is needed.

Q: Should the scope of the vote (within Ops call, within Ops by GitHub, full community) be decidable by attendees of a meeting? A: Yes.

On the Ops call, decisions can be made as follows: 1st: go for consensus, and if all agree with an action and no one thinks that broader input is needed, we just do it. In this, people on the call should consider who is not on the call, and what their objections might be. Especially if attendance is low. If an objection could reasonably be expected, the issue / action should be described in the minutes / on a ticket, and input gathered for decision after a waiting period of at least 2 weeks. The goal is again to reach 100% consensus
Voting: If no consensus can be reached, a vote is scheduled over a 4 week period, which will be decided by majority of active OBO operations members Community Vote Licences Non-trivial website updates Outward facing website, ontology representations COB integration

Asking the OBO Ops call: – Is there a specified Quorum? – Possible guidance on quorum found in SOP: “Wait until approximately 8-10 people have joined. Begin no more than 4 minutes after the hour regardless of how many people are present.”

Open Questions: What can we decide based on consensus during an Ops call. What goes to a community vote? Include in minutes for each call: What was approved, and ready for 2 week review What is open for community input.

NOTE: this will be summarized below

Feb 18 '25 17:02 nataled

The following addresses various issues surrounding the decision-making process within the OBO Foundry, presented in Q&A format. What are presented are not necessarily firm decisions, nor are they in any 'final wording' form; at this point they are proposals meant to spur discussion. Once discussed and decided, the answers will be edited as necessary and the relevant boxes will be checked off to keep track. Note: all references to 'Operations members' are to be understood as 'active Operations members' (defined elsewhere).

[ ] Q: Broadly speaking, what should be eligible for a decision/vote? A: Any change to the status quo. Examples include website or policy changes, new or changed principles, and new ontologies. This list is not intended to be exhaustive, but rather illustrative of the types of things we've voted on before.
[ ] Q: Given that a change could range from the trivial to the highly important, how do we decide what gets voted on? That is, how do we decide which specific issues require a vote? A: This is decided by the attendees of a given call in which the change is raised/discussed. Only a single(?) person needs to motion for a vote (unless we wish that each motion gets seconded). If no one on the call thinks a vote is necessary, then no vote is needed. In deciding this, people on the call should consider those who are not on the call, and whether or not additional input/objections could possibly be forthcoming. This is especially important if attendance is relatively low (OPEN QUESTION: should a number be here?).
[ ] Q: For a given issue, how do we decide who gets to cast a vote? A: Voting eligibility is decided by a simple majority of the Operations members attending the call during which a vote was requested. Possible answers (list might not be exhaustive) are: (1) 'during the call' - vote is restricted to only the members attending the call, with the decision made during the call; (2) 'extended Operations members' - vote is restricted to any Operations member (on the call or not), within a specified time frame, with the decision made via GitHub voting; (3) 'full user community' - vote is open to all, within a specified time frame, with the decision made via GitHub voting. By default, voting eligibility is limited to Operations members that are present on the call. However, if an objection could reasonably be expected, or if additional input is likely forthcoming, the vote should go, minimally, to extended Operations members. Note: It is recognized that any vote obtained via GitHub cannot reasonably be restricted to Operations members. The best we can do is advertise the vote to only the operations mailing list instead of more widely, and accept votes by anyone invested enough in the OBO Foundry that they follow our issues.
[ ] Q: For all votes--including the one to determine the scope of the vote--should there be a minimum number of votes needed? If so, what is that minimum? A: Based on the minimum number of members needed to start a meeting, this number would be 8 participants.
[ ] Q: Should we allow 'no comment' or 'abstain' as valid responses for the sake of reaching the 8 participants? A: Yes.
[ ] Q: Should we require a minimum number of votes one way or the other to ratify the vote? In other words, do we require some specific number of votes cast for the winning option? A: Yes, this number would be five. This corresponds to the minimum number of votes that would be obtained for a binary vote with 8 participants and no abstentions.
[ ] Q: Unless otherwise arranged, what should be the default minimum and maximum time frames for final tally of votes? A: Minimum: 2 weeks; Maximum: 4 weeks.
[ ] Q: For votes with participant eligibility outside of an Operations meeting, how should these be advertised? A: For Operations members only: email to [email protected] and post on #obo-operations Slack channel; for full community, email [email protected] and post on #obo-community Slack channel (though, given the rarity of postings there, we might want to also include #general, at least at first (always directing to #obo-community).
[ ] Q: Once it is decided that an issue needs a decision and what the eligibility should be, what steps should be taken? A: Under all circumstances the meeting minutes must contain what is being voted on and any decisions surrounding that vote (or consensus, as the case may be). Any approvals should be granted a two week review period. (1) For 'during the meeting' decisions: First, look for 100% consensus among those attending the meeting. If all agree with an action and no one thinks that broader input is needed, we just do it. If there is not 100% consensus or an objection could reasonably be expected, follow steps for 'extended Operations decisions'; (2) For 'extended Operations decisions' (which includes those not on the call and anyone that follows the Foundry GitHub tracker): Create an issue on the GitHub tracker with the appropriate advertisement and allow at least two weeks for input to be gathered. If there is 100% consensus, follow the decision made by consensus. If consensus has not been reached, a majority vote is scheduled, which will take place over a 4 week period; (3) For 'full user community' votes: Same as for (2) above, but with wider advertisement.
[ ] Q: How do we post the results of a consensus decision or vote? A: For Operations votes, results are posted in the meeting minutes and within any associated GitHub issue. For community votes, results are posted via the same mechanisms used to advertise the vote (obo-discuss, Slack) as well as the GitHub issue.