For the Kubernetes org we are using peribolos to automate GitHub org and team membership. This includes inviting users to the Kubernetes org as well as creating/deleting teams and adding/removing team members to teams.
I think this is definitely useful for an open source project as Helm as well. This way all changes are going through pull requests, in which things may be discussed as well, e.g. Let's get person A invited because he already has done some amazing work for Charts. Right now it seems a bit vague how new contributors are invited to the Helm org / specific repo (e.g. helm/charts#16168 (comment)).
Next to that with peribolos it is possible to automate GitHub team creation and delegate ownership for those teams as well, e.g. the leads for Charts may be granting access to new contributors for Charts related teams whereas the leads of Web and Docs may be approving pull requests for Docs related teams. This will be done through pull requests as well so history is always kept.
What does everyone think of this?
I'd be happy to help out with the setup for this (best repo name would probably be helm/org). After having a working setup it is probably a good idea to document it as well in this community repo, e.g.: https://github.com/kubernetes/community/blob/master/github-management/org-owners-guide.md#team-guidance
/cc @jdolitsky
For the Kubernetes org we are using peribolos to automate GitHub org and team membership. This includes inviting users to the Kubernetes org as well as creating/deleting teams and adding/removing team members to teams.
I think this is definitely useful for an open source project as Helm as well. This way all changes are going through pull requests, in which things may be discussed as well, e.g.
Let's get person A invited because he already has done some amazing work for Charts. Right now it seems a bit vague how new contributors are invited to the Helm org / specific repo (e.g. helm/charts#16168 (comment)).Next to that with peribolos it is possible to automate GitHub team creation and delegate ownership for those teams as well, e.g. the leads for Charts may be granting access to new contributors for Charts related teams whereas the leads of Web and Docs may be approving pull requests for Docs related teams. This will be done through pull requests as well so history is always kept.
What does everyone think of this?
I'd be happy to help out with the setup for this (best repo name would probably be
helm/org). After having a working setup it is probably a good idea to document it as well in this community repo, e.g.: https://github.com/kubernetes/community/blob/master/github-management/org-owners-guide.md#team-guidance/cc @jdolitsky