# Decision-Making Guide

This document describes how Jupyter’s governing bodies make decisions. Because individuals often work across multiple decision-making groups, all Jupyter governing bodies are expected to follow this approach.

We seek to honor the principles of collaboration, inclusive participation, and responsive decision making. Some aspects of this decision-making guide are required of all teams. Others are provided as recommendations and are optional. We have clearly noted the optional aspects of decision making below.

Finally, the Jupyter Board of Directors may either intervene, or be called upon by members of a team, in the event that issues arise in the decision making process. This includes, but is not limited to: process ambiguity, violations of the decision making process, mitigating circumstances that require process exceptions, etc.

## Required aspects of decision making

The decision-making process is intended to balance broad participation of stakeholders with agility. While the size of decision-making bodies may vary (e.g., software projects can range from a handful to dozens of decision makers), all need to find this balance.

All official Jupyter projects, working groups, governing bodies, and official initiatives must have a clearly-defined and documented decision-making body. Formally, these decision-making bodies make decisions using consensus seeking with an option to call a vote to move the decision forward.

Depending on the governing body, decisions may be proposed by members of the decision-making body or by a broader group of stakeholders/contributors.

**Informal consensus seeking.** Decision making starts with informal consensus seeking through discussion. The goal of this phase is to refine the proposal, consider alternatives, weigh trade-offs, and attempt to find informal consensus. The legitimacy of the consensus-seeking process is predicated on all stakeholders having their voices heard, so teams must be proactive in providing opportunities for all relevant stakeholders to provide input. If the decision-making body arrives at informal consensus, they may immediately move to document and enact the decision. This is the consensus-seeking phase.

**Calling a vote.** When the discussion matures during the consensus-seeking phase, any member of the decision-making body can call the matter to a vote. When that member (the sponsor) calls the vote, they shall summarize the proposal in its current form for the entire decision-making body. After the proposal is seconded by another member of the decision-making body, members have seven days to vote. The governing body may consider longer voting periods as necessary for special circumstances, or _shorter periods only if all voting members are present_. The decision will be determined by a simple majority of non-blank votes for binary decisions (i.e., approving a proposal) and ranked choice for multi-class decisions (one among many, or several among many). The sponsor may update the proposal at any point during the voting period, in which case the voting period will be reset.

**Voter participation and quorum.** The Jupyter decision making bodies often have broad scope. There are typically a subset of members who have the time, interest, and expertise to dive into the details of a limited scope issue, such as subproject specific issues. We believe that open, transparent, and time-bound voting with no quorum will enable these ad-hoc, informal subgroups to form spontaneously for these limited scope issues and work on a per-decision basis, in a manner that supports our goals of responsiveness and engagement.

All members of a decision-making body are required to participate in at least 2/3 of formal votes of that decision-making body per calendar year (teams can decide how to account for the specifics of this in low-activity projects, etc.). Members that have not met the 2/3 vote participation threshold for a year will automatically be asked to step down at the end of that year. Those individuals remain eligible to rejoin the decision-making body in the future as they become available to participate at the required level. The quorum for all formal votes will be 50% and a "blank" option will always be included, with the "blank" option counting towards the quorum but not included in totals for calculating results.

**Recording.** Once a decision has been made during the consensus-seeking phase or by a formal vote, the decision-making body will record the decision in an appropriate location that is as open as possible given the decision and the work of the particular body.

## Optional aspects of decision making

While the previous section is prescriptive for all Jupyter teams, the following are recommended guidelines rather than mandatory procedures.

- Do not call a vote to short-circuit an ongoing discussion that is still productive in terms of exploring ideas and feedback. Votes should be called only when discussion has explored the space and stakeholders have provided input.
- During the consensus-seeking phase, don’t interpret a lack of participation, discussion, or feedback as approval or disapproval. Dissent can be silent and sometimes people are supportive but busy.
- If you are interested in a decision being made, it is your responsibility to encourage voting member/stakeholder/community participation in the decision-making process. If you can’t get such participation, you may want to hold off on doing any significant work on the matter.
- Special guidelines for software projects making decisions:
- Add a link to this document in your issue and PR templates along with a link to the decision-making body membership (see recommended language below).
- Create “Consensus Seeking” and “Vote” issue tags to make it easy to find issues/PRs where a decision is being made.
- When a vote is called on GitHub, the sponsor should summarize the decision and paste a checklist of the voting members to use in voting in the top entry (description) of the issue/PR.
- When communications (in whatever number of channels) point to a discussion that requires a project-wide decision, and before major implementation work starts, a standalone issue should be opened that summarizes the issue, points to relevant prior discussions, and calls for an explicit vote/decision. This issue should be tightly scoped to the relevant decision only, and include the "Vote" tag.
- When an implementation of a decision appears in a pull request, link to the relevant “Vote” issue.
- Decision-making bodies and those proposing decisions should explicitly distinguish between decisions that are two-way doors (easy to reverse later) and one-way doors (difficult or impossible to reverse later). For one-way doors, teams should carefully weigh alternatives and tradeoffs and take extra care to ensure broad participation and stakeholder input. For two-way doors, teams should feel free to move quickly, without compromising the principles and procedures described herein.

## Language for issue/PR template

Project Jupyter makes decisions using a consensus-seeking model. You can read about this model here (link). The decision making body for this project is documented here (link).

## Transitioning to this decision making process

During 2021, Project Jupyter is transitioning to a new governance model that will introduce a new Board of Directors and Software Steering Council and dissolve the existing Jupyter Steering Council. This decision-making guide is part of that revised governance model, and will eventually be used by all decision-making bodies in the Project (Working Groups, Subprojects, the Board of Directors, and the Software Steering Council). During the transition to this new governance model, the existing decision making process of the [current Jupyter governance model](https://github.com/jupyter/governance/blob/master/governance.md#governance) will remain in full effect unless otherwise stated. For a Working Group or Subproject to adopt this new decision making process, it will first go through the decision making body bootstrapping process described in the [bootstrapping guide](bootstrapping_decision_making.md) and then add itself to the list below. The existing Jupyter Steering Council will continue to use the existing decision making process until its dissolution.

The following list of Subprojects and Working Groups that have gone through the bootstrapping decision making bodies process:

* Subproject 1
* Subproject 2
* ...