chore: use component_owners

[toddbaert]

Adds component_owners for all components

[beeme1mr]

The challenge with using a code owners file is that everyone listed needs write access to the repo. @dyladan created a tool that works around that limitation that we may want to consider.

[toddbaert]

The challenge with using a code owners file is that everyone listed needs write access to the repo. @dyladan created a tool that works around that limitation that we may want to consider.

I've simply done this: open-feature/community#221

This extracts the contrib roles from the sdk roles. With the CODEOWNERS in place, this should cover our use cases. CODEOWNERS will be able to approve changes to their own modules and merge them, but not release or make wider changes without SDK maintainer approval. We'll need to add @Mateoc and @sago2k8 to the contribs maintainers to make this all work.

[dyladan]

The challenge with using a code owners file is that everyone listed needs write access to the repo. @dyladan created a tool that works around that limitation that we may want to consider.

I've simply done this: open-feature/community#221

This extracts the contrib roles from the sdk roles. With the CODEOWNERS in place, this should cover our use cases. CODEOWNERS will be able to approve changes to their own modules and merge them, but not release or make wider changes without SDK maintainer approval.

You're both right. The issue is that the contrib group can make changes to anything in the contrib repo or merge any PR that satisfies merge checks. If you're ok with that risk then I would recommend using the built in solution as long as it works for you. In otel we have many components with many different owners, some of whom are only occasionally present in the repo or are new to the repo so we wanted to be stricter with controlling those permissions.

[toddbaert]

The challenge with using a code owners file is that everyone listed needs write access to the repo. @dyladan created a tool that works around that limitation that we may want to consider.

I've simply done this: open-feature/community#221
This extracts the contrib roles from the sdk roles. With the CODEOWNERS in place, this should cover our use cases. CODEOWNERS will be able to approve changes to their own modules and merge them, but not release or make wider changes without SDK maintainer approval.

You're both right. The issue is that the contrib group can make changes to anything in the contrib repo or merge any PR that satisfies merge checks. If you're ok with that risk then I would recommend using the built in solution as long as it works for you. In otel we have many components with many different owners, some of whom are only occasionally present in the repo or are new to the repo so we wanted to be stricter with controlling those permissions.

I'd be open to more robust tooling if it's not a lot of overhead. This is just what we'd already talked about. I guess the risk would be a "low trust" CODEOWNER pushing/approving changes that are not carefully reviewed when a maintainer later releases them?

[toddbaert]

I'll mark as draft for now.

[dyladan]

There are several potential risks of varying severity and likelihood, but most can be mitigated. The issue is that as the repo grows you have tens or hundreds of people with write permissions. Even if you've used branch protection rules and merge checks to lock things down as much as possible you may still run into issues like code owners merging PRs for components they don't own, closing issues that aren't resolved, et cetera. The more people have write permissions, the more likely it is something like this will happen even on accident.

[toddbaert]

There are several potential risks of varying severity and likelihood, but most can be mitigated. The issue is that as the repo grows you have tens or hundreds of people with write permissions. Even if you've used branch protection rules and merge checks to lock things down as much as possible you may still run into issues like code owners merging PRs for components they don't own, closing issues that aren't resolved, et cetera. The more people have write permissions, the more likely it is something like this will happen even on accident.

Ok I'll look at the tooling you're referring to... Assuming I can find it in the otel js contribs?

[beeme1mr]

https://github.com/dyladan/component-owners

[toddbaert]

@dyladan @beeme1mr the TC has agreed to give this a go! Thanks Dan!

Please re-review.

[sago2k8]

LGTM, I'm ok being pinned for maintaining the provider.

thank you

[toddbaert]

@kinyoklion I've added the permissions as you suggested, good idea.

@dyladan I looked through the source and cross-referenced the REST calls I saw there with the GH doc, and came up with the permissions above. If this looks good to you, and it works, I can open a PR to document this in your sample workflow.

EDIT: read|write is invalid. I changed this to write, which implies read. After that this worked well.