codeowners: Expand scope

[jodh-intel]

Improve the CODEOWNERS file by specifying more groups. The hope is
this will help reduce the PR backlog.

See: kata-containers/community#253

Fixes: #4533.

Signed-off-by: James O. D. Hunt [email protected]

[jodh-intel]

As shown, the CODEOWNERS file contains errors relating to non existant teams. If folk agree, I'll create those...

[wainersm]

Hi @jodh-intel !

What's your opinion about having individuals on the file? For example, assigning myself to .ci/openshift-ci instead of the broaden ci team.

Also maybe the directory kata-webhook should be owned by the integration-tests team as I is used by some of the k8s integration tests.

[jodh-intel]

@wainersm - personally, I'm not in favour of hard-coding usernames in these files since it would create a maintenance nightmare as folks come and go, files move, etc. By only specifying teams, the file will be smaller and clearer. Plus, we can manage group membership without requiring PRs to make it more agile.

[wainersm]

@wainersm - personally, I'm not in favour of hard-coding usernames in these files since it would create a maintenance nightmare as folks come and go, files move, etc. By only specifying teams, the file will be smaller and clearer. Plus, we can manage group membership without requiring PRs to make it more agile.

You got a point. And it makes sense for me. :)

[wainersm]

Is it in wip because some groups need to be created?

[jodh-intel]

@wainersm - for that reason and also that I'd like some input from the community on the content of the PR :)

[wainersm]

@wainersm - for that reason and also that I'd like some input from the community on the content of the PR :)

Got it.

/cc @kata-containers/redhat please your input is valuable...

[c3d]

@jodh-intel I like the idea, but we need to create the associated groups.

It's unclear to me why you believe that maintaining the groups is easier than maintaining the code owners file. Is it because you expect contributors to self-managed and exit the groups by themselves? Or some other reason?

[jodh-intel]

@jodh-intel I like the idea, but we need to create the associated groups.

@c3d - yep, see my comment above. I've held off creating those groups until there is general agreement to the strategy.

My thoughts on specifying groups rather than individual users:

Convenience / easier maintenance

The codeowners file lives in the repo, which means we have to raise a PR every time we adjust it.

By specifying groups rather than users we can maintain the members using GH's existing teams interface.

Clarity

If we just specify the groups, the file is clearer (simpler and shorter). But also imagine a rule like this:

*.wibble        @user1, @user2, @user3

That doesn't tell me much if I'm new to the project (wtf are wibble files and who are those users?) Conversely:

*.wibble        @kata-containers/security-team

Although I still don't know what wibble files are, I can take a guess as to what they are used for and/or their relative importance, so the end result is more (but admittedly not complete) clarity.

Ease of contact

The reason for creating this file is to simplify the task of the PR reviewers. If a reviewer wants input from a group of contributors relating to, say, a security PR, it's much easier for them to ping a single GitHub group than potentially ping a long list of users.

Privacy

There is the possibility that some users may not wish to be "known" as being involved in certain areas of the code. If we specify groups, they can maintain some level of privacy since you need a certain GitHub privilege level to be able to view group members.

Personal preference

• I don't like unnecessary hard coding.
• Lists of users:
  • Look untidy to me.
  • Are invariably incorrect / out of date.

Hence, I'd personally prefer a level of indirection to hide the clutter and make the end result neater 😄

[jodh-intel]

Closing due to lack of feedback...