Update CODEOWNERS and maintainers.yaml files

[riaankleinhans]

https://github.com/confidential-containers/confidential-containers/blob/main/MAINTAINERS

[fitzthum]

I'm a little bit surprised to see a new repo created in the org without consultation with maintainers. That's not our usual process in this project. The initial state that was pushed to the repo without any review contains many errors. I think this should have been introduced via a pull request.

For example, project.yaml lists arronwy as the "project lead." This community has no such role and while Arron is a great guy, he hasn't been involved with the project for more than a year.

@riaankleinhans can we force push to an empty repository and then open a PR introducing all the relevant files including codeowners.

Nothing against the idea of .project (although we'll need to clarify a couple procedural things with our existing governance doc) and I appreciate trying to roll this out without too much burden on maintainers.

[ahmadqasembader]

@fitzthum
As you mentioned, CNCF is trying to roll out .project without placing too much burden on maintainers. .project is a CNCF initiative to centralize metadata for all CNCF projects.

The initial state of the repo was provisioned automatically by cncf/automation tooling, immediately after onboarding a new Org with the .project we create an onboarding Issue #1 that explains the context (in the recent onboardings, we improved the issue so it gives a clearer context)

The metadata is harvested from public sources (landscape, CLOMonitor, governance files across your org), so it's a best effort and will probably contain errors. It's not meant to be authoritative without the Org owners' review.

Next step would be CNCF Staff contacting the Org owners and asking them to verify the metadata that was collected by the .project tool

We onboarded a bunch of projects at the same time, and @riaankleinhans is in the process of going through each one for verifications of metadata and follow up with the Org owners.

force-push a clean repo isn't necessary imo, and it requires a few changes to the .project tooling, if there are missing/incorrect metadata, we can simply edit them via PRs.

For the issue with stale maintainers, as mentinoed above, we rely on the Org goverances file (CODEOWNERS, MAINTAINERS, etc) and the cncf/foundation CSV list.

[fitzthum]

I don't think the information should be pushed into the repo if it has not been verified. If the idea is to have organization owners review the info, this can be done via a PR. Fixing things retroactively with PRs isn't really a substitute for the standard process of reviewing code before it is merged.

I'm not sure how widely this info is propagated yet. Maybe it's not too big of a deal, but if people come to this repo today, they will find inaccurate information.

This update to the maintainers is good, but there are other errors.

[riaankleinhans]

@fitzthum I verify the maintainer information as that affect the project's access to CNCF services.
The rest of the information get check by each project, as there is a lot of variation across 230+ projects.

Updating the .project information would also help the TOC move faster through moving levels evaluation of project information.

[fitzthum]

@riaankleinhans I appreciate the update to the maintainers. This info looks correct. Do you plan on making a PR to correct the other information?

Again, my suggestion as a maintainer is to reset this repo to an appropriate first commit and add all significant changes via pull requests. I don't want to be annoying about this, but that's the process that we follow for all contributions.

[sameo]

@fitzthum As you mentioned, CNCF is trying to roll out .project without placing too much burden on maintainers. .project is a CNCF initiative to centralize metadata for all CNCF projects.

We definitely appreciate it and we realize that this is all with good intentions. But creating a repo without consulting or notifying the project maintainers may not be the best open source practice. Even more so if the repo comes loaded with content that is not reviewed neither.

My advice at that point is to reset (push force) that repo to an empty state and send a PR with its initial content. We'll review/approve it straight away. Let us know how we can help.