@Stan_Development_Team and Stan community,
On behalf of the Stan Governing Body (@SGB) I’d like to share this revised proposal for a voting process on technical issues. We have a separate proposal coming soon that seeks to add more clarity on what Stan development is and who developers are, but the goal of this proposal is to outline a plan for how to settle potential disagreements on the technical direction of the project.
Feedback from current Stan contributors, potential Stan contributors, and anyone interested in the future of Stan development is greatly appreciated!
As it stands right now, Stan does not have a formal process for managing disagreement on technical issues. Although the project has been successful to date, there is a benefit to having an agreed-upon procedure in place to manage serious disagreement on technical issues. To this end, the SGB is aiming for a lightweight solution that is not burdensome for developers, but that will provide a mechanism for reaching a decision when informal consensus appears unlikely. Visibility into how technical decisions are made also helps onboard new developers to the project.
Below is a proposal for a voting system for making technical decisions in case of disagreement among developers.
When should you call a vote?
A vote is only necessary if there is still disagreement on a major issue after ample discussion. For the most important decisions, a vote should be called even if there is no disagreement in order to create a record of the consensus.
We realize there is ambiguity on what constitutes a “major” issue or “ample” discussion. Some judgement is required on the part of the initial developer. A working definition is that an issue is “major” if it may create a substantial maintenance burden on other developers or introduces any user-facing changes that may be controversial (of course there is ambiguity about these definitions too). “Ample” discussion means that the issue has been raised, and other developers have had an opportunity to read, process, and chime in. If other developers think the vote was called too soon then they can vote “No”. A proposal voted down can be brought up for a vote again after subsequent discussion.
If you’re not sure if a vote is required, err on the side of collaborative decision making by calling a vote. However, keep in mind that voting is intended as a fallback and you should first make an attempt to understand and address the technical concerns through polite discussion.
Who can vote?
Votes are open to developers contributing to the relevant module (see bullet point below) but any developer outside the module can force it to a developer-wide vote by objecting. Developers calling for a vote also have the ability to nominate multiple relevant repos initially.
A module is a repository on stan-dev. (This is a starting point. Depending on how this goes and how often modules need to be grouped together this can be revisited.)
The exception to this is for major changes to the Stan language, in which case:
- The proposed change should be posted on Discourse to allow the entire community to comment
- The voting will be open to all modules.
- Note: this is for major user-facing language changes and does not pertain to implementation issues, which are the purview of the language module developers. An example of a major user-facing change is a totally new syntax for declaring arrays (New array declaration syntax). An example of a minor user-facing change/addition is vectorizing binary functions (https://github.com/stan-dev/stanc3/issues/643).
If you are eligible to vote it is up to you whether or not to vote, but please only vote if you think you are sufficiently informed about the relevant issues.
How does voting work?
Platform for voting: This is TBD, but for the initial trial period we will try out the “poll” feature on Discourse (https://meta.discourse.org/t/how-to-create-polls/77548). Other suggestions are welcome.
The following procedure will be used:
- Someone proposes a vote and contacts SGB
- The SGB appoints someone to run the vote or recommend to the SGB that the vote not happen
- That person sets up the post with the poll, notifies voters, and reports the results after the vote
A poll is open for 2 weeks in order to give everyone enough time. If a lazy vote fails and a majority approval is required, please create a new poll and note that it is requesting majority approval.
Three vote options are available:
- +1: Agree
- 0: Abstain (the default)
- -1: Disagree (you must list your reasons for disagreement in a comment)
(We may need to adjust this if a particular topic in question can’t be expressed as a yes/no vote and requires more options.)
Proposal phrasing: Please include a statement that makes it clear what it means to “agree” or “disagree.”
Lazy vote: A binding agreement is reached when there is a minimum of one +1 and no -1s. In other words, if anyone is in favor and no one is against then the vote passes.
Majority approval: If a vote does not pass after a lazy vote, then the issue will require majority approval, where a binding agreement is reached when there are at least two +1s and more +1s than -1s. However, majority approval should be considered a last resort. The aim should be to reach rough consensus through discussion. To facilitate reaching rough consensus, voters are allowed to change their vote during the voting window if they change their minds.
Every voter’s vote has equal weight and each person can only cast one vote on a given call. (The developer bringing up a topic for a vote can also cast their vote.)
The voting procedure is intended to help resolve developer disagreement but it is possible for disagreement to happen about the process itself. In this case there is the option for arbitration, which works as follows.
If at least 3 developers consider any part of the process leading to a particular vote problematic, they may ask the SGB to arbitrate. An arbitration request stops the voting period if it already started.
The SGB may designate a community member to serve as an arbiter either for a specific case or to generally handle all arbitration requests for a module. The arbiter will act on behalf of the SGB and notify the SGB of the resolution of any arbitration.
The arbiter/SGB will consult all parties involved and then make a final decision on how the vote should proceed. That is, the arbiter/SGB will not decide the technical issue itself, but rather resolve issues related to the process, e.g., when a vote is called, the order of voting on multiple proposals, the final wording of the proposal, etc.