-
Notifications
You must be signed in to change notification settings - Fork 24
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
Propose documentation of maintainers and lightweight governance process #71
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: John Kjell <[email protected]>
Co-authored-by: Tom Meadows <[email protected]>
just followed up and read the rest - seems reasonable enough 😄 |
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.
Should we add a section that describes non-project-specific maintainers?
To a newcomer, it may seem a bit confusing that there are multiple maintainers affiliated with a project.
Also, how important would it be to maintain an academic/researchy core?
their prior service to the project, but no longer have code review, voting, or other | ||
maintainer privileges for the project. | ||
|
||
## Project-specific dedicated maintainer roles |
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.
Should we add a way to govern this? Similar to changes if governance by having 72 hour public comment period + the need of a 2/3 majority.
## Changes in governance | ||
|
||
The maintainers supervise changes in governance. Changes are approved by a 2/3 | ||
majority of voting maintainers with a 72 hour public voting / discussion period. |
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.
majority of voting maintainers with a 72 hour public voting / discussion period. | |
majority of voting maintainers with a 72 hour public comment period. |
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.
This looks great but I have some questions / suggestions about the processes described here. Thanks for working on this!
[go-securesystemslib](https://github.com/secure-systems-lab/go-securesystemslib) | ||
and related documentation. This governance does **NOT** apply to any other | ||
projects under the [secure-systems-lab](https://github.com/secure-systems-lab) | ||
Github organization. |
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.
Github organization. | |
GitHub organization. |
The goal of the go-securesystemslib project is to be a common foundational | ||
library for cryptographic signing and verifying. We strongly believe a common, | ||
widely reviewed library, will result in a higher quality and more secure | ||
implementaiton. The project, while not limited to, is specifically interested in |
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.
implementaiton. The project, while not limited to, is specifically interested in | |
implementation. The project, while not limited to, is specifically interested in |
widely reviewed library, will result in a higher quality and more secure | ||
implementaiton. The project, while not limited to, is specifically interested in | ||
the signing and verification of metadata and signing envelopes. Several major | ||
foundation-based open source projects would like to contribute to and consume |
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.
With foundation-based, do we just mean CNCF / OpenSSF etc?
|
||
## Code of Conduct | ||
|
||
The go-securesystemslib project abides by the Cloud Native Computing Foundation's |
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.
We should clarify that CoC violations are not actually handled by the CNCF.
## Changes in maintainership | ||
|
||
Active contributors may be offered or request to be granted maintainer status. | ||
This requires approval from a 2/3 majority of currently voting maintainers with at |
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.
What distinguishes a voting maintainer from a non voting maintainer?
open issues. A maintainer has the authority to approve or reject pull requests | ||
submitted by contributors. | ||
|
||
## Changes in maintainership |
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.
## Changes in maintainership | |
### Changes in maintainership |
their prior service to the project, but no longer have code review, voting, or other | ||
maintainer privileges for the project. | ||
|
||
## Project-specific dedicated maintainer roles |
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.
## Project-specific dedicated maintainer roles | |
### Project-specific dedicated maintainer roles |
|
||
| Project | Maintainer | | ||
| -------------------------------------------- | ---------- | | ||
| [In-toto](https://github.com/in-toto) | TBD | |
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-toto](https://github.com/in-toto) | TBD | | |
| [in-toto](https://github.com/in-toto) | TBD | |
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.
I think the table shouldn't list the maintainer, so that we don't touch GOVERNANCE.md for personnel changes.
| [In-toto](https://github.com/in-toto) | TBD | | ||
| [TUF](https://github.com/theupdateframework) | TBD | | ||
|
||
**Note: Dedicated Maintainer roles are still subject to general maintainer rules* |
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.
**Note: Dedicated Maintainer roles are still subject to general maintainer rules* | |
**Note: Dedicated Maintainer roles are still subject to general maintainer rules. |
|
||
## Project-specific dedicated maintainer roles | ||
|
||
Any project that demonstrates a commitment to consuming this library as a |
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.
Do we need direct maintainers and project specific maintainers? I think in this case, we could get away with just having the latter, given the nature of the library?
| Project | Maintainer | | ||
| -------------------------------------------- | ---------- | | ||
| [In-toto](https://github.com/in-toto) | TBD | | ||
| [TUF](https://github.com/theupdateframework) | TBD | |
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.
Should this be specifically go-tuf?
This PR is a result of conversations from the in-toto-go-consolidation efforts (see CNCF Slack for additional context on that work).
This is a first draft expressing loose opinions on an initial governance process for
go-securesystemslib
. The intent is to allow foundation-based projects under community governance, such asin-toto
andTUF
, to adoptgo-securesystemslib
without fear of suffering consequences from unilateral decisions or changes.I'm open to any and all suggestions to what will make this proposal acceptable to
secure-systems-lab
and interested consuming projects.