PROPOSAL - review & clean up OWNERS

[thesuperzapper]

Overview:

Many OWNERS files across repos in the Kubeflow org display common red-flags, therefore it is critical for the health of the project that we make a concerted effort to improve them.

In this proposal, I aim to lay out the problem and propose how we can begin to review and clean up our OWNERS files in line with the community agreed method of maintaining OWNERS files on kubeflow.org.

Full OWNERS text from the Contributing guide:

## Maintaining OWNERS files

OWNERS files should be regularly maintained.

We encourage people to self-nominate or self-remove from OWNERS files via PR's. 
Ideally in the future, we could use metrics-driven automation to assist in this process.

We should strive to:

- grow the number of OWNERS files
- add new people to OWNERS files
- ensure OWNERS files only contain org members and repo collaborators
- ensure OWNERS files only contain people are actively contributing to or reviewing the code they own
- remove inactive people from OWNERS files

Bad examples of OWNERS usage:

- directories that lack OWNERS files, resulting in too many hitting root OWNERS
- OWNERS files that have a single person as both approver and reviewer
- OWNERS files that haven't been touched in over 6 months
- OWNERS files that have non-collaborators present

Good examples of OWNERS usage:

- there are more `reviewers` than `approvers`
- the `approvers` are not in the `reviewers` section
- OWNERS files that are regularly updated (at least once per release)

Problem:

Sadly, many of our OWNERS files are failing at almost every one of the above checks, but the following are most common:

• Issue 1: OWNERS contain people who are not actively contributing/reviewing the code they cover
• Issue 2: OWNERS have the same approvers and reviewers (in many cases, the lists are identical!)
• Issue 3: OWNERS have more approvers than reviewers (in some cases, there are 0 reviewers!)
• Issue 4: OWNERS have not had people added in over 6 months (gives the perception that people can't join our community!)

Examples of Issues:

kubeflow/kubeflow

• ./components/notebook-controller/OWNERS (ISSUES: 1, 3, 4)
• ./components/centraldashboard/OWNERS (ISSUES: 1, 3, 4)
• ./components/crud-web-apps/OWNERS (ISSUES: 1, 3, 4)
• ./components/profile-controller/OWNERS (ISSUES: 1, 3, 4)

kubeflow/pipelines

• ./backend/OWNERS (ISSUES: 2, 3)
• ./frontend/OWNERS (ISSUES: 2, 4)
• ./sdk/OWNERS (ISSUES: 2)

kubeflow/community

• ./OWNERS. (ISSUES: 2, 4)

kubeflow/manifests

• ./OWNERS (ISSUES: 1, 2, 3, 4)

kubeflow/website

• ./OWNERS (ISSUES: 1)
• ./content/en/docs/about/OWNERS (ISSUES: 1, 3, 4)
• ./content/en/docs/started/OWNERS (ISSUES: 1)
• ./content/en/docs/components/notebooks/OWNERS (ISSUES: 1, 3)

kubeflow/training-operator

• ./OWNERS (ISSUES: 3)

kubeflow/katib

• ./OWNERS (ISSUES: 3, 4)

kubeflow/kfp-tekton

• ./OWNERS (ISSUES: 1, 2)

Solution

I propose we start a review process of every OWNERS file, and take the following actions to correct each issue.

Solution for Issue 1 -- inactive OWNERS

1. Review the recent commits to the code under the OWNERS
2. Remove anyone who has not contributed/reviewed to these commits within the last 12 months
   • For OWNERS who are domain experts, but have stepped away from the project, consider making them emeritus_approvers. They are unable to /approve but may help people future contributors get an informed second opinion.
3. If there have been no commits within the last 12 months: a. The code is likely abandoned, and should be considered for archive b. If the code is critical (can't be archived), raise a public request for new OWNERS on the community forums c. The @kubeflow/project-steering-group assigns new OWNERS

Solution for Issue 2 -- same reviewers as approvers

1. Review the recent commits & issues for the code under the OWNERS
2. Active participants should be added as reviewers
   • This is NOT a security risk, as reviewers have no extra permissions, they only get automatically assigned as reviewers to new PRs on that code
3. Remove any reviewers who are also approvers
   • We can ask current approvers if they would prefer to be reviewers and have less responsibility.

Solution for Issue 3 -- more approvers than reviwers

1. It is likely that solving "Issue 1" and "Issue 2" will cause there to be more reviewers than approvers

Solution for Issue 4 -- no new approvers or reviwers in 6+ months

1. It is likely that solving "Issue 2" will create a pipeline for new reviewers that will eventually become approvers

[thesuperzapper]

cc @kubeflow/project-steering-group

[thesuperzapper]

cc @kubeflow/wg-automl-leads @kubeflow/wg-deployment-leads @kubeflow/wg-manifests-leads @kubeflow/wg-notebooks-leads @kubeflow/wg-pipeline-leads @kubeflow/wg-training-leads

[gaocegege]

BTW, how about other projects like https://github.com/kubeflow/arena and https://github.com/kubeflow/kfp-tekton

[thesuperzapper]

BTW, how about other projects like https://github.com/kubeflow/arena and https://github.com/kubeflow/kfp-tekton

@gaocegege In my (very quick) glance:

• kubeflow/arena - ./OWNERS
  • looks OK
• kubeflow/kfp-tekton - ./OWNERS
  • seems to suffer from "Issue 1" and "Issue 2" (so I have added it to the list above)

[theadactyl]

This sounds like a great thing to take on after the winter holidays. Let's hold on it in the meantime so we have time to review the proposal and collect feedback.

On Wed, Dec 15, 2021 at 6:45 PM Mathew Wicks @.***> wrote:

BTW, how about other projects like https://github.com/kubeflow/arena and https://github.com/kubeflow/kfp-tekton

@gaocegege https://github.com/gaocegege In my (very quick) glance:

• kubeflow/arena - ./OWNERS https://github.com/kubeflow/arena/blob/master/OWNERS
  • looks OK
• kubeflow/kfp-tekton - ./OWNERS https://github.com/kubeflow/kfp-tekton/blob/master/OWNERS
  • seems to suffer from "Issue 1 and "Issue 2" (so I have added it to the list above)

— You are receiving this because you are on a team that was mentioned. Reply to this email directly, view it on GitHub https://github.com/kubeflow/community/issues/546#issuecomment-995388944, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABREJVKCOJVVJGP7CBPWLGDURFHDXANCNFSM5KFE2DQQ .

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[thesuperzapper]

/reopen

[google-oss-prow[bot]]

@thesuperzapper: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[thesuperzapper]

Once we have cleaned up the Working Groups (see https://github.com/kubeflow/community/issues/563), we can organize an OWNERS review for each repo under the kubeflow org with its owning Working Group.

The main complexity I see is the kubeflow/kubeflow repo, which contains code from the Notebook WG but is not "owned" at a root level by Notebooks WG.

[jbottum]

/priority P1 /area community