Community: Updating OWNERS files

[dims]

It's been an year since the first population of the OWNERS files in https://github.com/kubernetes/contrib/issues/1389.

• Some folks have moved on and no longer reviewing or approving changes that they are responsible for
• New folks have adding code who may make good reviewers if not approvers
• Can we get some data on which reviewers / approvers are not really doing what they are supposed to do? (so we can request if we can drop them from the file(s))?
• There is a concept of a SIG in https://github.com/kubernetes/kubernetes/blob/master/OWNERS_ALIASES, but very few OWNERS files use these groups from OWNERS_ALIASES. Do we want to move to a model where we favor the sig groupings over individuals? Is that upto sig(s)? Do we want to tell them that they should review code under their purview and make the change?

It's probably time to update reviewers and approvers again...

[cblecker]

/sig contributor-experience

[bgrant0607]

Related: #1721, #1913, #1673

We have more than 4000 OWNERS files, which is clearly unmaintainable. We should update guidance on how OWNERS files should be used. How many nested OWNERS files should subprojects have probably depends on the subproject, but we should at least ensure that each directory tree has an OWNERS file.

Also, we have the general contributor ladder:
https://github.com/kubernetes/community/blob/master/community-membership.md

But that needs to be reconciled with the new SIG charter template and guidance. SIG and subproject-specific roles should be defined in SIG charters, though we do need centralized documentation about how the reviewer/approver mechanism works and is intended to be used.

We also need to update the OWNERS file documentation to reflect the concept of subprojects:

https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md

We need to add info about:

• subprojects
• subproject owners
• other roles

I'd also like to mention that we list top-level subproject OWNERS files in sigs.yaml, and briefly discuss what belongs in OWNERS vs. in sigs.yaml. For instance, SIG-level roles (chair, TL, etc.) should be in sigs.yaml. Subproject-level roles (owners, approvers, reviewers, etc.) belong in top-level subproject OWNERS file(s).

The current guidance suggests SIG aliases. We need to change those to subproject role aliases:
sig-sigfoo-subprojectbar-approvers:

• alice
• bob

Where should those aliases be defined?

Subproject working doc:
https://docs.google.com/document/d/1FHauGII5LNVM-dZcNfzYZ-6WRs9RoPctQ4bw5dczrkk/edit#bookmark=id.3xu7cakgzomb

Other docs discussing subprojects and owners:
https://github.com/kubernetes/community/blob/master/community-membership.md#subproject-owner
https://github.com/kubernetes/community/blob/master/governance.md#subprojects
https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md

cc @kubernetes/steering-committee @spiffxp @jdumars @kubernetes/sig-contributor-experience-feature-requests

[fejta-bot]

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

[idvoretskyi]

/remove-lifecycle stale

[tpepper]

An additional aspect of this is adding "labels:" to OWNERS files, eg:
https://github.com/kubernetes/community/blob/master/github-management/OWNERS

That addition of sig or area labels to OWNERS files could be a good-first-issue, for somebody looking to do a little dive into how the codebase is laid out relative to sigs.

[bgrant0607]

My current thinking is just top-level subproject OWNERS only. For subprojects with multiple directory roots, we could use subproject aliases. Not sure how we'd handle multi-repo subprojects.

cc @grodrigues3

[bgrant0607]

See also #1673 and #1913

[bgrant0607]

SIG is not the right granularity, btw. It should be subproject.

[wadadli]

@tpepper I'd be happy to do that deep dive. Is sigs.yaml the correct file to reference?

[nikhita]

Related https://github.com/kubernetes/community/issues/2878 and https://github.com/kubernetes/community/issues/2873

[bgrant0607]

It sounded like @guineveresaenger and @chris-short had concerns and/or suggestions regarding OWNERS files.

cc @parispittman also

[bgrant0607]

Another OWNERS issue: https://github.com/kubernetes/kubernetes/issues/50048

[dims]

related to https://github.com/kubernetes/community/issues/3700

[spiffxp]

/priority important-longterm
/assign
not to say that I'm committed to this, but I would like to make this easier to find for me

Going to use this as umbrella issue for all things related to OWNERS files

[spiffxp]

notes and awful hackery I have tried to measure people's actions against PRs: https://gist.github.com/spiffxp/97ee57e348d27c59e029ce55d11a50a6

tl;dr

• I think it's important to look at more actions than authorship, such as review, approval, triage, etc.
• I haven't found anything off-the-shelf that lets us:
  
  
  
  • filter by files touched
  
  
  • considers reviews that are done via GitHub's UI (PullRequestReview events aren't exposed via GitHub's API, so gharchive doesn't see them, and thus neither does devstats)
  
  
• it seems likely we would want something like ghcrawler that scrapes GitHub and gives us a database to query

[spiffxp]

(ref: https://github.com/kubernetes/test-infra/issues/10065) I think it would be preferable for us to use GitHub teams as a more discoverable / centralized way of having the same group of people referenced across repos rather than syncing OWNERS_ALIASES around. That said, we should be mindful of how to ensure visibility of how teams are managed

[mrbobbytables]

/assign @mrbobbytables