Decision making guide #87
Conversation
afshin
force-pushed
the
decision-making-guide
branch
from
76265f5
to
c3ef275
Compare
|
This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there: https://discourse.jupyter.org/t/governance-office-hours-meeting-minutes/1480/118 |
decision_making.md
Outdated
| - We encourage teams to always seek to balance the core guiding principles of this process as stated above: balancing agile decision making with an open and collaborative culture of participation from all relevant stakeholders. | ||
| - During the consensus seeking phase, don’t interpret a lack of participation, discussion, or feedback as consensus or the lack thereof. 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/stakeholders/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. | ||
| - We recognize that a no quorum voting scheme could be mistaken for a low participation voting scheme – that is not our goal. To guard against this, teams should always strive for broad participation. |
There was a problem hiding this comment.
Let's strike this entirely. No quorum provides no incentive to strive for broad participation.
decision_making.md
Outdated
| - 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 pull request, link to the relevant “Vote” issue. | ||
| - This decision making process is incompatible with individuals merging their own PRs in most situations. |
There was a problem hiding this comment.
We can distinguish here between individuals reviewing their own PRs and merging their own PRs. In some systems, once other people have signed off on a PR, the original author or anyone else can merge it (for example, it might be signed off conditional on tests passing, and the original author might merge once tests have passed).
There was a problem hiding this comment.
Also this doesn't account for the somewhat common (at least not uncommon) occurrence of two people working on a PR, each reviewing the other's work, and then one of them merging it.
There was a problem hiding this comment.
We should remove this statement because each repository's contributors already have a strong culture of what is acceptable when it comes to merging pull requests.
|
We've made a number of updates to the language, so hopefully the document is clearer when read in isolation (i.e. outside the context of this PR conversation). But to try to also answer directly some of the feedback @willingc @jasongrout brought up (thx a lot btw!!):
(BTW the 'we' above was @afshin @ellisonbg and me during the last meeting :) |
|
Thinking out loud about quorum, speed, minimum vote periods:
This made me wonder if having a fixed cadence for votes would help people to schedule time ("every 3rd Thursday of the month is voting deadline, let me put that in my agenda") and as a result increase the participation? It gives people who are waiting a clear time frame and "plannability" ("We need the board to vote on this so we need to get it to them by X as the next scheduled vote will be too late"). It also signals to would-be decision making body members that if they want to take on this position there is an expectation that they have time to cast a ballot once a month (monthly is just a random cadence I picked for the sake of concreteness). |
This is a really interesting idea. Not sure how that will work in different contexts such as the different decision levels this document is a guide for, but I would bet that could help overall.
I think the updates make the guide better than the previous iteration, still, I am not totally convinced about not requiring some sort of quorum across the whole project (even if the details for that quorum is different for a different part of the ecosystem at least there is an idea or quorum protecting the decision making process)... |
This is an interesting idea, I think if a specific team or decision-making group wanted to go with this cadence they could. We purposely were trying not to be prescriptive behind the 'how' these guidelines are enacted so each team can create a culture that works for them. Sometimes lack of participation is because there's a lack of caring, an example being if one or two UX minded people are making color decisions, others may not be as interested. We wanted to give people permission to not care about every decision without stopping progress. Sometimes a lack of participation is due to a lack of time, even on decisions that are important. We wanted to give solid minimums for people to have a chance to engage, we also expect there to be differences in how 1-way vs 2-way doors are treated. ie: if the decision is to change a long-held upon protocol, that would be a longer discussion, consensus would be sought, hopefully, achieved, and then the decision would be enacted. But if there is a clear disagreement and consensus is not reached, we ought to be able to vote on a direction and try it. In short, I think having some sort of a cadence is a great idea, but I don't think we should force that cadence on every project. |
|
This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there: https://discourse.jupyter.org/t/governance-office-hours-meeting-minutes/1480/119 |
decision_making.md
Outdated
|
|
||
| This document describes how Jupyter’s governing bodies (Board of Directors, Software Steering Council, Software Projects, non-software Working Groups) make decisions. Because individuals often work across multiple decision making groups, all Jupyter governing bodies are expected to follow this approach. | ||
|
|
||
| This document provides guidelines but is not meant to be a comprehensive procedure manual. We seek to honor the principles of collaboration, inclusive participation, and responsive decision making. If a situation arises that is not explicitly covered by the guidelines in this document, we encourage all teams to find a path forward with decisions, filling in the gaps in formal decision making procedure with adherence to these principles. |
There was a problem hiding this comment.
I find this sentence a bit confusing. When I first read it, I interpreted the rest of the page's content as "these are suggestions but not rules". But then in the next section it says things like "Formally, these decision making bodies make decisions using consensus seeking with an option to call a vote to move the decision forward." which seems like something closer to a mandate. Which interpretation is correct?
decision_making.md
Outdated
|
|
||
| Depending on the governing body, decisions may be proposed by members of the decision making body, or by a broader group of stakeholders/contributors. | ||
|
|
||
| Decision making, even when it begins with simple informal discussion, starts with consensus seeking. The goal of this discussion 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 voice heard; teams must be proactive in providing opportunity 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. |
There was a problem hiding this comment.
Just a quick note that for these kinds of sections that lay out different steps of a procedure, I think it is helpful to begin each paragraph with highlighted text or a sub-header that denotes that step's name, so that readers are able to orient themselves to the text more easily
decision_making.md
Outdated
|
|
||
| Decision making, even when it begins with simple informal discussion, starts with consensus seeking. The goal of this discussion 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 voice heard; teams must be proactive in providing opportunity 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. | ||
|
|
||
| At any time 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 and notify the entire decision making body. After the proposal is seconded by another member of the decision making body, members have 7 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 result will be determined with no quorum by a simple majority for binary decisions and ranked choice for multiclass decisions (one among many, or many among many). The sponsor may update the proposal at any point during the voting period, in which case, the voting period will be reset. |
There was a problem hiding this comment.
I feel like there are certain kinds of decisions where you really do want quorum (e.g. a board of directors, a project-wide decision on a JEP, etc) and others where you probably don't need it. Enforcing quorum/no-quorum across all decisions will likely feel inadequate for one or the other type of decision unless we differentiate the two somehow.
Perhaps we can identify an explicit subset of decision-making bodies (e.g. board of directors), or types of decisions (e.g. project-wide JEPs) that require quorum, and for others it is left to the project to decide?
There was a problem hiding this comment.
Governance decisions (BoD and JEPs) benefit from having a quorum. Without quorum and minutes, there is no way to measure the effectiveness of transparency or adequately make sure that folks are aware of a vote.
Decisions that do not need quorum are those that are more along the lines of day-to-day operations of the project.
There was a problem hiding this comment.
I like this idea of quorum/no-quorum for well-defined subsets.
There was a problem hiding this comment.
Can we be explicit that BoD and SSC votes should have a quorum? Day-to-day operations in the subproject could be exempt from that. Lack of quorum in BoD and SSC votes leaves me concerned about the governance.
|
I made a few comments in the PR - also a quick thought on @betatim's point - it occurs to me that his proposal of a regular cadence for decision-making feels natural with what the JupyterHub project already does. I feel that for most decisions, they are made on-the-fly because a consensus is quickly reached. However for more complex, controversial, etc decisions, we often say "let's discuss at the team meeting". I think it is reasonable that most people who are on the "decision-making body" of a project should also be committed-enough to attend team meetings and such (or cast and absentee vote). So I think this feels reasonable to me. Thinking out loud here: Perhaps another safety valve on the question of quorum and participation is: if quorum is not reached, you need a supermajority to pass, and if it is reached, then you only need a simple majority? Though I must admit that in general my inclination is that putting yourself in a leadership / decision-making role within a project is something you should only do if you have the bandwidth and interest to participate in governance. I think we should avoid designing governance with the assumption that people will be checked-out. |
|
This pull request has been mentioned on Jupyter Community Forum. There might be relevant details there: https://discourse.jupyter.org/t/governance-office-hours-meeting-minutes/1480/136 |
Co-authored-by: Carol Willing <carolcode@willingconsulting.com>
|
The content of this PR has been moved into: #98 |
Background or context to help others understand the change.
The incoming governing body pull requests will refer to a common set of decision making strategies, so this pull request represents the decision making guide that all governing bodies within the new model will adopt.
Please consider the draft and offer suggestions.
A brief summary of the change.
This adds a decision making guide document.
What is the reason for this change?
To create a common "algorithm" for Jupyter sub-projects to use in their decision-making.
The process ❗
The discussion phase is meant to gather input and multiple perspectives from the community.
Make sure that the community has had an opportunity to weigh in on
the change before calling a vote.
cc: @fperez @ellisonbg @tgeorgeux, we decided during the most recent governance call to open this draft PR.