marthas rules for decision making #34
Conversation
There was a problem hiding this comment.
Thanks for adding this, it’s good to have this a bit more fleshed out here.
I think I would like to soften the language here a bit. I’m thinking maybe saying this is one of the ways we make decisions, and is for a particular kind of decision. I’ve added some more comments to the doc.
This process has some overhead, which isn’t needed for all decisions. When is this process triggered? When is a decision big enough to go through this? It’s also not clear how this process works for deciding between multiple options. This is especially important for cases where deadlock may occur.
Btw, a similar discussion is occurring for zarr at the moment for Zarr Enhancement Proposals (zarr-developers/governance#16 (review))
| Core team members may resign from the project at any time, or lose their vote if a proposal to that effect is passed as outlined in the [Descision Making Process](#decision-making-process) section of this page. | ||
| A proposal to remove someone’s vote may not contain any other business. | ||
| Each person must be the subject of a separate proposal. | ||
| The person in question has the right to vote on the proposal to remove their vote. |
There was a problem hiding this comment.
I'm wondering if we would split how people stop being on the core team to a separate PR. We've also talked about having automatic activity based triggers on membership. E.g. if you haven't made X contributions in the past year a vote is called on removal.
But also, could be separate?
| The group tries to find a resolution that has no open objections among relevant core team members. | ||
| Core members are expected to distinguish between fundamental objections to a proposal and minor perceived flaws that they can live with, and not hold up the decision-making process for the latter. | ||
| If no option can be found without objections, the decision is escalated to the SC, which will itself use consensus seeking to come to a resolution. | ||
| In the unlikely event that there is still a deadlock, the proposal will move forward if it has the support of a simple majority of the SC. |
There was a problem hiding this comment.
I would like to keep the steering council in the decision making process. Sometimes it's important to have just have a decision be made soon.
| The group tries to find a resolution that has no open objections among relevant core team members. | ||
| Core members are expected to distinguish between fundamental objections to a proposal and minor perceived flaws that they can live with, and not hold up the decision-making process for the latter. | ||
| If no option can be found without objections, the decision is escalated to the SC, which will itself use consensus seeking to come to a resolution. | ||
| In the unlikely event that there is still a deadlock, the proposal will move forward if it has the support of a simple majority of the SC. |
There was a problem hiding this comment.
I would like to keep the steering council in the decision making process. Sometimes it's important to have just have a decision be made soon.
| Decisions about the future of the project are made through discussion with members of the community. | ||
| All non-sensitive project management discussion takes place on the issue trackers of the https://github.com/scverse repositories, in public channels of our chat, or on the forums. | ||
| Occasionally, sensitive discussion may occur via a private message. | ||
|
|
||
| Decisions should be made in accordance with the mission and values of the scverse project. | ||
|
|
||
| scverse uses a “consensus seeking” process for making decisions. | ||
| The group tries to find a resolution that has no open objections among relevant core team members. | ||
| Core members are expected to distinguish between fundamental objections to a proposal and minor perceived flaws that they can live with, and not hold up the decision-making process for the latter. |
There was a problem hiding this comment.
I would like to keep this distinction.
| Decisions about the future of the project are made through discussion with members of the community. | ||
| All non-sensitive project management discussion takes place on the issue trackers of the https://github.com/scverse repositories, in public channels of our chat, or on the forums. | ||
| Occasionally, sensitive discussion may occur via a private message. | ||
|
|
||
| Decisions should be made in accordance with the mission and values of the scverse project. | ||
|
|
||
| scverse uses a “consensus seeking” process for making decisions. | ||
| The group tries to find a resolution that has no open objections among relevant core team members. | ||
| Core members are expected to distinguish between fundamental objections to a proposal and minor perceived flaws that they can live with, and not hold up the decision-making process for the latter. |
There was a problem hiding this comment.
I would like to keep this distinction.
| * pros and cons | ||
| * possible alternatives | ||
|
|
||
| A quorum is established in a meeting if half or more of voting members are present. |
There was a problem hiding this comment.
How do we handle cases where people who would like to vote on a proposal, but can't make it to a particular meeting? Do we reschedule?
| * pros and cons | ||
| * possible alternatives | ||
|
|
||
| A quorum is established in a meeting if half or more of voting members are present. |
There was a problem hiding this comment.
How do we handle cases where people who would like to vote on a proposal, but can't make it to a particular meeting? Do we reschedule?
|
I totally understand the reasoning behind this proposal, but can guarantee you now already that this would generate significant overhead. I myself and certainly others here are strongly overburdened PhD students with ~10 parallel projects. Writing up proposals for small discussion points every week that I want to bring up is not feasible. So far we have been doing this for major points and we can formalize it for such. |
|
I agree, it is not always needed. There are mainly two points that I would like to avoid by formalizing decisions:
Essentially, we need this when no consensus is reached on Zulip? An example where proposal would make sense is the How about: flowchart TD
A{Consensus reached?}
A -- Yes --> B[Accept proposal]
A -- No --> C{Time pressure?}
C -- Yes --> D[Steering council decides with simple majority]
C --> No --> E[Martha's rules for governance meeting]
(First time I try this, mermaid is awesome 🤩) |
I'm thinking this could also come up for individual PRs. Maybe the criteria for this system being used is essentially "someone asked for us to use it"? |
|
@grst yeah, nice that one can easily generate these diagrams on Github. This sounds fine to me. |
Probably yes... My only concern here would be that there might be no time for someone to ask, if a decision is made too quickly. |
|
I've seen other projects put a time requirement before things get merged/ released. Could do something like that? |
|
What should we do with this PR? I don't mind formalizing the decisions but honestly had the impression that decision making has been done quite well in the last couple of months? |
|
Yeah, I don't think there were any issues. This might become more relevant when the core team grows? Maybe we just leave it around until then? |
|
I'd be up for merging this, but would want to, y'know, go through the process for accepting it. |
As discussed in the last governance meeting, I propose to add Martha's rules as decision making process to the roles document.
It is mostly copied over from the template in this blog post.