add SIP for governance.md #2593
Conversation
There was a problem hiding this comment.
Content looks great, thank you!
Do you intend that the markdown block from the SIP be used historically to describe the initial intention of the SIP?
(trying to understand if it would make more sense to have the separate governance.md file as part of this PR instead — not blocking, though).
LGTM
There was a problem hiding this comment.
This is a great start! Thanks so much for working on this.
I have one larger meta-comment: We are using the SIP process to propose and come to agreement on a new governance structure. The document defining this governance structure however makes no mention of the SIP process. I imagine that we're not trying to abolish the SIP process with this change, and so the intent is to keep the SIP process around.
I believe we should be explicit about what role the SIP process plays in governance particularly around decision making. The reason I feel this way is that SIPs ensure some sort of public accountability, and the process as currently written could potentially lead to decision-making happening behind closed doors. If instead we require major decisions to go through SIPs, we're ensuring decision making happens in the open where public feedback can be taken into account.
docs/content/sips/019-governance.md
Outdated
| The process for changes to the Governance.md file is as follows: | ||
|
|
||
| 1) Open an issue | ||
| 2) Open a pull request to this SIP describing changes and the Governance.md file with proposed changes. |
There was a problem hiding this comment.
It feels strange that future changes would not require a SIP. I could understand small clarifications that don't obviously materially change the intent of the governance.md doc being done through PR, but IMO any changes of substance should go through the SIP process.
There was a problem hiding this comment.
I agree that substantial changes should require new SIPs, yes. I sketched out a process for what that could look like:
- Decide whether the change is substantial in nature. A substantial change is one that changes the project governance itself, instead of editorial changes providing clarifications, small bugfixes, etc
- Then,
- for substantial changes
- Open a new SIP for the changes
- Follow the normal SIP process, requiring a supermajority for acceptance
- for editorial changes
- Open a PR with the changes to
governance.md - Land the PR after getting at least two positive reviews, and waiting for at least 3 workdays across all time zones
- Open a PR with the changes to
PRs landed without SIPs can be challenged as substantial for up to 2 weeks afterwards, at which point they have to be backed out, and the proposed changes have to go through the SIP process instead.
There was a problem hiding this comment.
That makes sense to me. Thanks @tschneidereit. Updated with this process.
docs/content/sips/019-governance.md
Outdated
| The process for changes to the Governance.md file is as follows: | ||
|
|
||
| 1) Open an issue | ||
| 2) Open a pull request to this SIP describing changes and the Governance.md file with proposed changes. |
There was a problem hiding this comment.
I agree that substantial changes should require new SIPs, yes. I sketched out a process for what that could look like:
- Decide whether the change is substantial in nature. A substantial change is one that changes the project governance itself, instead of editorial changes providing clarifications, small bugfixes, etc
- Then,
- for substantial changes
- Open a new SIP for the changes
- Follow the normal SIP process, requiring a supermajority for acceptance
- for editorial changes
- Open a PR with the changes to
governance.md - Land the PR after getting at least two positive reviews, and waiting for at least 3 workdays across all time zones
- Open a PR with the changes to
PRs landed without SIPs can be challenged as substantial for up to 2 weeks afterwards, at which point they have to be backed out, and the proposed changes have to go through the SIP process instead.
There was a problem hiding this comment.
I'm pretty happy with how this is turning out - thanks for your great work! The last thing I'd need before giving my personal ✅ is some resolution to the voting vs consensus question. I would personally like to always see consensus as the preferred method for any and all decisions, and voting only used in truly exceptional circumstances where consensus cannot be reached.
michelleN
force-pushed
the
governance
branch
10 times, most recently
from
b209d3f
to
2c4d120
Compare
|
@radu-matei @rylev I've updated the PR to include the GOVERNANCE.md file. I've also updated the SIP so it no longer contains the the governance document rather describes some of the important aspects we've discussed around governance that are reflected in the document. @rylev I've removed most references to voting and opted for consensus across the board. |
There was a problem hiding this comment.
@michelleN I'm a bit confused - I was assuming that the SIP would simply reference GOVERNANCE.md for much of the content. In other words, I had assumed the SIP would say more or less "see this commit of the GOVERNANCE.md file for how the SIP is proposing governance will work", and the SIP only would only provide additional information/context that isn't appropriate for the GOVERNANCE.md file.
However, it seems that the content of GOVERNANCE.md is duplicated across the SIP and GOVERNANCE.md. Unfortunately, it's not a 1 to 1 copy and there appears to be contradictions between the two documents. For example, on decision making, the GOVERNANCE.md file provides an exception to when objection free consensus is used (for changes to governance), while the SIP does not.
Let me know if I'm missing something here, but as it stands, it makes reviewing difficult as the proposal is split, copied, and slightly modified between two places.
|
@rylev I can see how that might be confusing. I've updated the SIP so that it no longer contains the additional sections. Let me know if you have other suggestions. |
michelleN
force-pushed
the
governance
branch
2 times, most recently
from
5fc87a2
to
f84ae91
Compare
docs/content/sips/019-governance.md
Outdated
|
|
||
| ## Proposal | ||
|
|
||
| This SIP is a proposal to add a GOVERNANCE.md file to the root of the Spin repository. The governance structure described in the corresponding GOVERNANCE.md file aims to describe transparently a process close to how we've been doing things so far in the project and how to make changes. It formally opens up the project for maintainers from multiple organizations, defines maintainership roles, describes decision making processes and more. |
There was a problem hiding this comment.
We should try to remember to link to the current version of GOVERNANCE.md so that it's easy in the future to see the exact version of the governance.md that was agreed to by this SIP (without having to crawl GitHub). Of course, we can't link to the exact version until we're sure it's final.
GOVERNANCE.md
Outdated
|
|
||
| ### Decision Making | ||
|
|
||
| The default decision making process is objection-free consensus except for changes to the Governance of the project which requires a supermajority agreement of the committee. The process for making governance related changes is described below. |
There was a problem hiding this comment.
Still not sure why changes to the Governance of the project use a vote instead of the normal decision making process. If there's a good reason for this can we document it here?
There was a problem hiding this comment.
I kept this in here because I would want to ensure a supermajority of the governance committee has explicitly reviewed and thought through any changes to the governance document. I'm open to changing it but I'd like to hear some more thoughts on the matter.
There was a problem hiding this comment.
This concern makes a lot sense since the current objection free consensus process doesn't explicitly state requirements for quorum. I would personally prefer we address the concern by establishing quorum rules rather than jumping straight to a vote.
My straw-man proposal would be for non-governance decisions to require a simple majority quorum and for governance decisions to require super-majority quorum. I think this would address the concern while still favoring consensus over "winner takes all" voting.
There was a problem hiding this comment.
My straw-man proposal would be for non-governance decisions to require a simple majority quorum and for governance decisions to require super-majority quorum. I think this would address the concern while still favoring consensus over "winner takes all" voting.
That seems like a reasonable proposal actually - I really dislike unqualified objection-free consensus for a whole bunch of reasons, so even if it's the goal, big +1 to defining requirements that give a clear path to forward progress.
There was a problem hiding this comment.
My straw-man proposal would be for non-governance decisions to require a simple majority quorum and for governance decisions to require super-majority quorum. I think this would address the concern while still favoring consensus over "winner takes all" voting.
@rylev could you describe the process around requiring quorum to make changes to governance? Maybe compare that with how we've currently outlined the process for the changes to governance currently?
There was a problem hiding this comment.
The top-level concern I have is the use of a "winner takes all" voting process for governance changes as opposed to the consensus seeking process used for all other decisions. The concern you had was around ensuring that a sufficient number of voices take place in the decision making process, since a strict reading of the consensus process could lead to situations where, for example, only 2 people out of N number of members of the Spin Governance Committee actually give input and work towards consensus (since silence == consensus). This is a very legitimate concern. We want to ensure that decisions not only represent some sort of consensus but that consensus is actively shared among a large enough percentage of the Spin Governance Committee. In other words, it's not enough that Bob and Alice agree while everyone else was on vacation - if not enough people participate in building consensus, then we should not consider that actual consensus.
This is where the idea of quorum comes in. We no longer say that consensus among any subset of the Spin Governance Committee is sufficient but rather that consensus must actively be reached by a certain percentage of the Spin Governance Committee.
The specific change here is to no longer strictly say silence == consensus. In order for decision to be made, some % of Spin Governance Committee members must actively give their consensus by stating they have no blocking objections.
How does this differ from voting? Quorum is about participation percentage where as voting is about a decision making threshold. In other words, for a decision to be made by consensus with 50% quorum requirement, 50% of potential decision makers need to actively take place in the process, but 100% of those who participate need to have no objections. This differs from a simple majority vote where as long as 50% of those who participate agree, it doesn't matter if other participants vehemently object, the vote still passes. Consensus seeks to address concerns and ensure that at the very least everyone can live with the decision.
I'd like to also make clear one other distinction between voting and consensus that isn't explicit in the explanation above. Consensus asks "can you live with this decision?" while voting asks "do you actively support this decision?". In voting a decision is made by those who actively agree with a decision while in consensus a decision is made by everyone at the very least not blocking a decision. Consensus ensures everyone's opinions are heard whereas in voting once it's clear enough people agree, there is zero incentive to listen to those who don't actively agree.
So, the original comment I left is all about consistency around the decision making process. I propose we use the same decision making process for all decisions in the project including changes to governance: consensus. The only difference between governance related decisions and other decisions is the quorum requirement: i.e., how many people must actively state they have no objections. In my straw-man proposal the quorum figure is 50% for regular decisions and 66.66% for governance decisions. Again, 100% of those who participate though must have no objections.
Sorry for the longwinded answer. I hope this clarifies things, but let me know if things are still not clear.
There was a problem hiding this comment.
Thanks thats a really helpful answer.
Signed-off-by: Michelle Dhanani <[email protected]>
I was not overlooking a concern. I had taken your suggestion but I think I must have fumbled a rebase. Updated the text. I appreciate your input. |
Signed-off-by: Michelle Dhanani <[email protected]>
|
I've updated this doc most recently to include:
|
GOVERNANCE.md
Outdated
|
|
||
| ### Decision Making | ||
|
|
||
| The default decision making process is objection-free consensus. All governance related decisions require supermajority quorum. All substantial changes require a SIP. A substantial change is one that changes the project governance itself, instead of editorial changes providing clarifications, small bugfixes, etc. |
There was a problem hiding this comment.
All substantial changes require a SIP. A substantial change is one that changes the project governance itself, instead of editorial changes providing clarifications, small bugfixes, etc.
This doesn't read quite right to me. As it stands now, it's not clear to me whether "All substantial changes require a SIP." is saying all substantial changes to governance require SIP or all substantial changes to anything in the Project require a SIP.
I can see this stating either one (or both). Whatever one we mean, can we rephrase this to be less ambiguous?
GOVERNANCE.md
Outdated
| - A maintainer may be removed for a [code of conduct](CODE_OF_CONDUCT.md) violation by the Spin Governance Committee. Code of conduct violations may be submitted to any member(s) on the Spin Governance Committee by email. See email information on MAINTAINERS.md. | ||
| - When a project has no active maintainers, the maintainers of the [fermyon/spin Github repo](https://github.com/fermyon/spin) become responsible for it, and may archive the project, or find new maintainers | ||
|
|
||
| ### Decision Making |
There was a problem hiding this comment.
I probably sound like a broken record so apologies, but it seems the decision making process for the Project maintainers differs from the decision making process of the Spin governance committee in the following ways:
- Silence in Project maintainers decision making is equivalent to silence whereas for Spin governance committee it's not stated what silence means.
- When decisions require a SIP is not specified for Project maintainers but it is for the Spin governance committee
- quorum rules are set for some decisions for the Spin governance committee but not for Project maintainers.
It's not clear to me why these differences in decision making process exist. Perhaps we can only have one section on decision making in the document, and if there is an explicit difference between Spin governance committee and Project maintainers we just call it out there? Having two difference sections on decision making makes it very hard to understand which differences are intentional and which is just due to the sections being worded slightly differently.
There was a problem hiding this comment.
Does this read better to you (collapsed decision making section)?
Decision Making
The default decision making process is objection-free consensus. In other words, a decision is made when all decision makers have had time to consider the decision and do not raise any objections. Silence on any consensus decision is equivalent to non-objection. Explicit agreement may be stated at will.
Decision making scenarios should be promoted appropriately by the maintainer or committee member overseeing the issue. All substantial changes in any part of the Spin project including for governance related changes require a SIP.
All substantial changes to governance require a supermajority quorum on the governance committee.
In the extreme case that objection-free consensus cannot be reached after a reasonable amount of time and effort between project maintainers on a project level decision, a project maintainer can call for a supermajority vote from the project maintainers for a repo on a decision. If quorum cannot be met for a decision, all members of the Spin Governance Committee are added to the relevant vote.
If a decision impacts multiple repositories or requires a coordinated effort across multiple repositories and project maintainers are unable to reach a decision on their own for the relevant projects, a maintainer can call for a decision from the Spin Governance Committee.
In the extreme case that objection-free consensus cannot be reached after a reasonable amount of time and effort on the governance committee, a committee member can call for a supermajority vote form the committee. If another member seconds the vote, the vote must take place.
There was a problem hiding this comment.
Looks really good! I just have one nit (chaning a "should" to a "must"):
Decision making scenarios must be promoted appropriately by the maintainer[...]
There was a problem hiding this comment.
Chiming in with a that change LGTM too
Signed-off-by: Michelle Dhanani <[email protected]>
Signed-off-by: Michelle Dhanani <[email protected]>
|
|
||
| - A project maintainer may step down by emailing the mailing list. When a project maintainer steps down, they become an emeritus maintainer. | ||
| - Project maintainers MUST remain active on the project. If they are unresponsive for > 3 months, they will lose project maintainer-ship, unless the remaining project maintainers of the given project and the Spin Governance Committee agree to extend the period to be greater than 3 months. | ||
| - New maintainers MUST be nominated by existing maintainers. Maintainers are to discuss and agree in a private setting adding a new maintainer. Once a descision has been made, a maintainer may be added to the project via a pull request to the relevant MAINTAINERS.md file. |
| - Project maintainers MUST remain active on the project. If they are unresponsive for > 3 months, they will lose project maintainer-ship, unless the remaining project maintainers of the given project and the Spin Governance Committee agree to extend the period to be greater than 3 months. | ||
| - New maintainers MUST be nominated by existing maintainers. Maintainers are to discuss and agree in a private setting adding a new maintainer. Once a descision has been made, a maintainer may be added to the project via a pull request to the relevant MAINTAINERS.md file. | ||
| - A maintainer may be removed for a [code of conduct](CODE_OF_CONDUCT.md) violation by the Spin Governance Committee. Code of conduct violations may be submitted to any member(s) on the Spin Governance Committee by email. See email information on MAINTAINERS.md. | ||
| - When a project has no active maintainers, the maintainers of the [fermyon/spin Github repo](https://github.com/fermyon/spin) become responsible for it, and may archive the project, or find new maintainers |
This SIP includes a proposal for a
Governance.mddocument which describes governance for the Spin project. This goal of this initial version of governance is to most closely mirror what we currently do, formally define and open maintainer-ship, and provide a process for iterating on governance further. It is not the goal of this proposal to fully resolve all governance matters but it does kick off the process.related to #2449