-
Notifications
You must be signed in to change notification settings - Fork 2
Governance document #20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
+ Mostly transferred over from Spin repository. + Additional details around project proposal process + Add SpinKube to project list + Add Code of Conduct + Update CoC reference in governance document + Update README Signed-off-by: Michelle Dhanani <[email protected]> Co-authored-by: Brian Hardock <[email protected]>
vdice
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Realize this doc was ported from the Spin repo but might be nice to squash some of the typo/grammer items. Otherwise LGTM!
|
|
||
| ### Proposing New Projects | ||
|
|
||
| Existing projects may be proposed by submitting a pull request to this document adding the project and it's future location in this organization to the above list with a clear pull request description indicating who maintains the project and why it should be part of the Spin Framework GitHub organization. Once the pull request is approved, a repository transfer will be initiated. Once transfer is complete, the pull request will be merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Existing projects may be proposed by submitting a pull request to this document adding the project and it's future location in this organization to the above list with a clear pull request description indicating who maintains the project and why it should be part of the Spin Framework GitHub organization. Once the pull request is approved, a repository transfer will be initiated. Once transfer is complete, the pull request will be merged. | |
| Existing projects may be proposed by submitting a pull request to this document adding the project and its future location in this organization to the above list with a clear pull request description indicating who maintains the project and why it should be part of the Spin Framework GitHub organization. Once the pull request is approved, a repository transfer will be initiated. Once transfer is complete, the pull request will be merged. |
|
|
||
| Existing projects may be proposed by submitting a pull request to this document adding the project and it's future location in this organization to the above list with a clear pull request description indicating who maintains the project and why it should be part of the Spin Framework GitHub organization. Once the pull request is approved, a repository transfer will be initiated. Once transfer is complete, the pull request will be merged. | ||
|
|
||
| A new project it must be proposed through the [Spin Improvement Proposal](https://github.com/spinframework/spin/blob/main/docs/content/sips/index.md) process in the Spin repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| A new project it must be proposed through the [Spin Improvement Proposal](https://github.com/spinframework/spin/blob/main/docs/content/sips/index.md) process in the Spin repository. | |
| A new project must be proposed through the [Spin Improvement Proposal](https://github.com/spinframework/spin/blob/main/docs/content/sips/index.md) process in the Spin repository. |
| - 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 decision 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). See document for information on reporting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| - A maintainer may be removed for a [code of conduct](CODE_OF_CONDUCT.md). See document for information on reporting. | |
| - A maintainer may be removed for a [code of conduct](CODE_OF_CONDUCT.md) violation. See document for information on reporting. |
|
|
||
| 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 MUST 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Decision making scenarios MUST 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. | |
| Decision making scenarios MUST be promoted appropriately by the maintainer or committee member overseeing the issue. All substantial changes in any part of the Spin project including governance related changes require a SIP. |
|
|
||
| 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| 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. | |
| 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 from the committee. If another member seconds the vote, the vote MUST take place. |
Uh oh!
There was an error while loading. Please reload this page.