PROM-95: Standardize Prometheus Github teams and repository access

[ArthurSens]

The Prometheus GitHub organization has grown organically over the years, and with the previous Governance structure stating that every team member gets full Owner permissions, we're starting to lose control of what is happening across our GitHub organizations.

Here, the Steering Committee proposes introducing GitHub teams to our org, ensuring everyone has the permissions they need to carry out their maintainership responsibilities without giving more than necessary.

in this PR proposal, we invite all Prometheus team members to provide feedback and share possible concerns.

We're aiming to finding concensus and roll out this plan within a month!

[SoloJacobs]

Since we now also want to remove org ownership as part of this proposal, we should make that clear in the proposal.

[ArthurSens]

Last commit should clarify that org Owner permissions will be revoked from everyone

[roidelapluie]

Should we have a Platform team that also has owner access ? I am involved with Ben in many repos' CI/CD processes and I believe keeping the ability to merge such PR's across all repos would be useful.

[ArthurSens]

Should we have a Platform team that also has owner access ? I am involved with Ben in many repos' CI/CD processes and I believe keeping the ability to merge such PR's across all repos would be useful.

I am very much supportive of introducing broader teams, like the one you suggested, but others like an "Exporters' Team", "SDK Team", "Security Team". I do feel like this is a next step in our org maturity and would require a follow-up proposal. I think for now we can keep your Owner permissions as a special case and have it properly documented :)

[metalmatze]

Great work!
Overall, it's looking good.

One additional thing to potentially add now - maybe it has been discussed within the Steering Committee, maybe not - is synchronizing the maintainers we are going to properly keep up to date per repository with the newly created https://github.com/prometheus/.project/blob/main/maintainers.yaml going forward.

[SoloJacobs]

@metalmatze Yes,that it is likely the right solution. For now we only planned synchronizing the MAINAINERS.md files. But i have an open action item to figure out how to reconcile things with .project. Is your suggestion to replace those .md files too? Just curious for input

[sebastiangaiser]

Thank you for writing the proposal.
I would like to raise one repository: prometheus-community/helm-charts.
Ownership in that repository is organized per chart rather than per repository. MAINTAINERS.md contains a section per chart, and .github/CODEOWNERS a corresponding /charts/<name>/ rule, covering all 44 charts with largely disjoint maintainer sets. Would it be reasonable to treat the repository in the same way as prometheus/prometheus for the time being, leaving its MAINTAINERS.md unchanged? I would be glad to help work out the details on the helm-charts side.

[ArthurSens]

Thank you for writing the proposal. I would like to raise one repository: prometheus-community/helm-charts. Ownership in that repository is organized per chart rather than per repository. MAINTAINERS.md contains a section per chart, and .github/CODEOWNERS a corresponding /charts/<name>/ rule, covering all 44 charts with largely disjoint maintainer sets. Would it be reasonable to treat the repository in the same way as prometheus/prometheus for the time being, leaving its MAINTAINERS.md unchanged? I would be glad to help work out the details on the helm-charts side.

Thank you for the heads-up! We absolutely can defer helm-charts too.

[ArthurSens]

@metalmatze Yes,that it is likely the right solution. For now we only planned synchronizing the MAINAINERS.md files. But i have an open action item to figure out how to reconcile things with .project. Is your suggestion to replace those .md files too? Just curious for input

I also think we need to understand and align with CNCF on what it means to add people to that file. CNCF mentioned that it automatically gives access to certain CNCF services. If there's no downsides to it, I guess we can just add all maintainers, if there's downsides then we need to understand them and find the right balance :)

[bwplotka]

Let's mention #95 (comment) helm-chart repo.

@sebastiangaiser - maybe we can think of some solution that would resolve fine-grained ownership per path vs terraform together here or in an additional proposal? 🤔

[bwplotka]

Ideas:

1. Rely on CODEOWNERS and give them write access. With write access those sub-path owners can create tags, push branches etc but restricted branches are safe with "Required check from Code Owners setting". Some trust involved but it's what we have now (I think).
2. Leave those as members (read/triage access only) but add to MAINTAINERS.md and setup some required status check that requires subowner to approve.

Why 1 is not a good start?

[sebastiangaiser]

Option 1 is what we have today. The chart owners sit in helm-charts-maintainers with Write, helm-charts-admins holds Admin, and the ruleset on main requires code owner review with one approval and disallows direct pushes, so a chart owner cannot approve a change to another chart.

I am less sure about option 2. GitHub appears to honor a CODEOWNERS entry only for users and teams that have write access, and the docs state that a code owner will not be assigned if the user or team has insufficient access. If that is right, moving the chart owners to read or triage would not weaken CODEOWNERS but switch it off, and the status check would have to take over the whole job rather than add to it. Is that your reading as well?

The gap I see in option 1 is that write reaches further than CODEOWNERS can scope. Tags, releases and gh-pages in helm-charts are usually written by the release workflow, so no human should need those permissions. Restricting them to CI would bring the practical reach of write close to the per-path model, without anyone noticing a difference in daily work.

[sebastiangaiser]

One idea: a team per chart below helm-charts-maintainers, generated from MAINTAINERS.md and referenced from CODEOWNERS instead of individual handles.

[bwplotka]

I am worried about the unsolved fine-grained control per path for Prometheus SDs and helm charts, but otherwise let's iterate! Let's not stall this (: