HIP: Document and Track maintainer groups #394
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Improves upon #156
closes #156
CC @helm/helm-org-maintainers
Reasoning
Something about this question Matt asked 4 years ago struck me finally:
The spirit of Matt's HIP—publicly documenting all Helm maintainers, their roles and ownership of different parts of the Helm project—is important. In order to do that fully I don't think "subprojects" is an adequate term to replace "teams". As Matt's question says, it leaves out Org maintainers. And also the Security team. Both of which the former PR removes from the existing
TEAMS.md
. I didn't think we should remove that file unless we properly replaced what it currently defines. This updated HIP does.The proposed YAML file in Matt's PR is already a list of the different groups of maintainers, and the things that group owns nested below each group. To be fully inclusive of all the groups, this PR suggests we change "subprojects" to "maintainer groups", and fleshes it all out in
maintainer-groups.yaml
.Are Org maintainers and Project maintainers all "maintainer groups"? I would say yes. So is the Security Team. As are project maintainers. They are all groups of maintainers with different roles and responsibilities that oversee certain things we should define publicly. I drew this term from Helm's GOVERNANCE.md, where "maintainer groups" or "groups of maintainers" is used several times. For example:
Would be happy to use a different term if someone has a better idea, but I think "maintainer groups" is captures it.
Additional notes
I squashed Matt's commits to keep commit history in order to allow rebasing against main (it was too old to do that easily). And then added commits on top of his.