Propose documentation of maintainers and lightweight governance process#71
Propose documentation of maintainers and lightweight governance process#71jkjell wants to merge 2 commits intosecure-systems-lab:mainfrom
Conversation
Signed-off-by: John Kjell <john@testifysec.com>
Co-authored-by: Tom Meadows <tom@tmlabs.co.uk>
|
just followed up and read the rest - seems reasonable enough 😄 |
There was a problem hiding this comment.
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.
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.
| majority of voting maintainers with a 72 hour public voting / discussion period. | |
| majority of voting maintainers with a 72 hour public comment period. |
adityasaky
left a comment
adityasaky
left a comment
There was a problem hiding this comment.
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.
| 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.
| 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.
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.
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.
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.
| ## 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.
| ## 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.
| | [In-toto](https://github.com/in-toto) | TBD | | |
| | [in-toto](https://github.com/in-toto) | TBD | |
There was a problem hiding this comment.
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.
| **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.
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.
Should this be specifically go-tuf?
5 participants
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-totoandTUF, to adoptgo-securesystemslibwithout 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-laband interested consuming projects.