Administration acls on sig sponsored sub-project repos. about org HOT 10 CLOSED

Yup, closing in favour of that issue. Thanks @nikhita!

from org.

/sig contributor-experience
/area github-management
ref: kubernetes/community#2323

from org.

For the example: today, creating a new repo is a manual process. I try to be consistent, making sure teams are setup according to our current guidance but I missed a step of adding the teams to the repo in this case. They've been added, and you should bug @detiber who's the team maintainer (since he was the person who asked for the repo when steering was in charge of this)

from org.

So the problem is as follows:

Organizational structure is hierarchical and permissions and rights show flow from this hierarchy. Gitlab has this feature (https://docs.gitlab.com/ee/user/group/subgroups/).

We now have an implicit hierarchy that is replicated in several locations and the permissions do not chain down from there. A concrete example is the following:

• sig-cluster-lifecycle
  • cluster-api
    • provider-x
    • provider-y

Within each repository there is a duplication of OWNERS which can be out of date over time. Administrative permissions (e.g. maintainers) should flow through this hierarchy and have a single canonical source of truth (e.g. sigs.yaml)

Right now I can just deal with it, but we need to fix aliases in OWNERS across orgs, and across repos so permissions are consistent.

from org.

Agree this is the direction we want to head. Our first step will be driving the github side of things from a file that lives here, via peribolos

Integration with OWNERS files and sigs.yaml are next steps that I haven't invested a lot of time in articulating. There are conflicting views between distributed OWNERS files as the source of truth vs a single location (like sigs.yaml.) I'd prefer to reconcile one from the other, instead of trying to do anything bidirectional. We may also find using GitHub teams instead of OWNERS_ALIASES would be a useful compromise.

from org.

We can start enforcing all this with automation.

from org.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

from org.

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

from org.

Trying to understand the issue better...today, we ask for who needs to be provided admin and write access to the repo in the issue template and create teams + grant access as part of the repo creation. Does that solve this issue?

We may also find using GitHub teams instead of OWNERS_ALIASES would be a useful compromise.

If the issue has boiled down to using GitHub teams in OWNERS files, maybe this should be another issue in k/test-infra?

from org.

Can we close this in favour of kubernetes/test-infra#10065?

from org.