[Proposal] Community management with Peribolos

[aepfli]

Proposal

Community, Membership, and Repository management is complex on its own. With a growing community, keeping an overview gets harder and harder. Instead of relying on manual actions, I recommend switching to a GitOps approach, utilizing Peribolos.

Peribolos offers a great variety of settings and can be used to manage organization management, team assignments, and repository permissions.

Peribolos is developed and used by Kubernetes and is a good fit for OpenFeature.

What do we want?

1. We want to have an easy and trackable way of assigning different permissions to members of our organization.
2. We want to have a straightforward approach with little to no duplication or too many points to edit alignment
3. We want to organize our members in teams with certain aspects.
4. We don't want to assign permissions per individual but on a team basis, so if you want specific permissions, you're part of a certain team.
5. We want to group repositories for teams, aka one team is responsible for multiple repositories - to reduce maintenance efforts
6. We also want to have overlapping teams for repositories, as there might be the need to separate some access

Permission structure

Organization Level

First, we do have roles on organizational level like:

Owners
Members

With respective permissions

Repository Level

Additionally, if you are part of the organizational level, you can also be one of those roles just for the repository or repository group:

Repo-Admin
Repo-Maintainer
Repo-Approver

Proposal

Ultimately, we can setup the repo permissions for each repository, which means a lot of duplicated configuration effort, but grouping would be easier and way better to handle. Furthermore, it would represent the community structure in a better manner.

Theoretically, we could group the repository as follow (naive proposal)

* sdk * java - https://github.com/open-feature/java-sdk - https://github.com/open-feature/java-sdk-contrib * javascript - https://github.com/open-feature/js-sdk-contrib - https://github.com/open-feature/js-sdk * .net - https://github.com/open-feature/dotnet-sdk - https://github.com/open-feature/dotnet-sdk-contrib * go - https://github.com/open-feature/go-sdk-contrib - https://github.com/open-feature/go-sdk * php - https://github.com/open-feature/php-sdk - https://github.com/open-feature/php-sdk-contrib * ruby - https://github.com/open-feature/ruby-sdk - https://github.com/open-feature/ruby-sdk-contrib * python - https://github.com/open-feature/python-sdk - https://github.com/open-feature/python-sdk-contrib * rust - https://github.com/open-feature/rust-sdk * education - https://github.com/open-feature/docs.openfeature.dev - https://github.com/open-feature/killercoda - https://github.com/open-feature/playground * org - https://github.com/open-feature/ofep - https://github.com/open-feature/community - https://github.com/open-feature/.github - https://github.com/open-feature/spec * utils - https://github.com/open-feature/test-harness * cloud native - https://github.com/open-feature/flagd - https://github.com/open-feature/watchman - https://github.com/open-feature/schemas - https://github.com/open-feature/open-feature-operator

As the configuration file for this structure would be already quite big and cover a lot of duplication

I propose consolidating this into a leaner structure with an automatic merge (like Kubernetes is doing https://github.com/kubernetes/org) tailored to our needs. We will have our Directory per organization we manage and a subdirectory per group containing the necessary information.

The org.yaml will contain basic information about the organization, such as general membership, description, etc. Also it will contain a group for Community maintainers

The group configuration will contain the following structure, eg. for java

repos: # the repositories belonging to this team
  - java-sdk
  - java-sdk-contrib

approvers: # list of users who are approvers for this group and its repos (GitHub Permission: triage)

maintainers: # list of users who are maintainers for this group and its repos (GitHub Permission: maintain)

admins: # list of users who are admsin for this group and its repos  (GitHub Permission: admin)

Our merger will then take all this information to generate the configuration and apply it via GitHub Action to the defined organizations.

References

• https://github.com/kubernetes/org

[beeme1mr]

This seems like a nice improvement that will help make the org permissions more transparent and easier to understand.

[aepfli]

i do have somewhat issues to split permissions between approvers, and triagers - as the permissions seems to be the same for me, the question is, if it is worth to differentiate between both of them, and if we should reflect this also in the structure of the groups

[AlexsJones]

Is this the project https://github.com/uwu-tools/peribolos ?

I also want to add some clarification here:

What do we want? ~We want to have a GitOps way of assigning different permissions to members of our organization.~ We want to have a straightforward approach with little to no duplication or too many points to edit alignment We want to organize our members in teams with certain aspects. We don't want to assign permissions per individual but on a team basis, so if you want specific permissions, you're part of a certain team. We want to group repositories for teams, aka one team is responsible for multiple repositories - to reduce maintenance efforts We also want to have overlapping teams for repositories, as there might be the need to separate some access

The process and technology isn't important, the outcomes are.

I am happy to bring this up at the next governance meeting though as I think it's great you're bringing this up!

[aepfli]

actually it is https://docs.prow.k8s.io/docs/components/cli-tools/peribolos/ - we extracted it into our own docker image, to be easier used with github actions

Seems to be close to the same idea as uwutools :)

[aepfli]

-We want to have a GitOps way of assigning different permissions to members of our organization.
+We want to have an easy and trackable way of assigning different permissions to members of our organization.

@AlexsJones I totally agree, i hope this change of wording helps in regards of the goals :)