ci: add CODEOWNERS for default reviewer requests

[potiuk]

Summary

Adds .github/CODEOWNERS so that @dave2wave, @raboof and @potiuk are automatically requested as reviewers on every PR, rather than being added by hand each time. Additional reviewers (area experts or PMC members affected by a particular change) can still be added ad hoc on top of the defaults.

Test plan

• After merge, the next PR opened against main should auto-request all three as reviewers.
• Existing branch-protection rules continue to work (this PR does not change them).

[raboof]

This might give the impression that we're the ones primarily reviewing actions, and that others can just sit back and wait. I'd rather see people affected by a particular change review first, and then the committers on this repo can merge based on that.

if we do this then we should probably add @dfoulks1 as well.

[potiuk]

This might give the impression that we're the ones primarily reviewing actions, and that others can just sit back and wait. I'd rather see people affected by a particular change review first, and then the committers on this repo can merge based on that.

if we do this then we should probably add @dfoulks1 as well.

I mostly based it on actual activiity in the recent month or so. And yes - I would love more people being invoilved and do the reviews - especially that it is quite fast now. Not sure however how to make them more incentivised to have a a a look and act.

It's not entirely clearly who's eventual responsibility the repo is. And yes, I ageree that we woudl get more people in. But so far what I found out works well in airflow is:

a) have people who are there by default
b) their job is not necessarily do the job but actively pulling in people who could help and express our expectation they will be more involved.

This is for example what I did in #751 (comment) and it worked (and I have a long time experience of doing the same thing in Airflow).

For example I would love to pull in @ppkarwasz and make him also default reviewer - initially for Java actions and then later to become a more active reviewer. I think he has good ideas and if we actually state our expectations that we would love him to join the reviewer team - he would.

I found this scheme to work - especially with pulling in contributors who would not be even aware that we expect them to act.

I think in many of our endevours we think that people will "magically" show up without any work from our side. I think the most important work of "CODEOWNERS" (at this stage) is not to do reviewes themselves but actually pull in other reviewers actively. This is the only way we can actually achieve community of people collaborating here.

[dave2wave]

@potiuk please add @dfoulks1 since he as the representative of INFRA is the true "CODEOWNER".

I am active this month, but not so much. If we want to further have "CODEOWNERS" then I would prefer to limit my "ownership" to the Pelican action and am willing to continue to review work on those actions.

I am unlikely to review action updates and should not be a "code owner" for those.

[raboof]

This might give the impression that we're the ones primarily reviewing actions, and that others can just sit back and wait. I'd rather see people affected by a particular change review first, and then the committers on this repo can merge based on that.
if we do this then we should probably add @dfoulks1 as well.

I mostly based it on actual activiity in the recent month or so. And yes - I would love more people being invoilved and do the reviews - especially that it is quite fast now. Not sure however how to make them more incentivised to have a a a look and act.

That's indeed a challenge.

It's not entirely clearly who's eventual responsibility the repo is.

Given it's an infrastructure- repo I'd say Infra, but also they've explicitly said they can't do it alone and welcome help.

And yes, I ageree that we woudl get more people in. But so far what I found out works well in airflow is:

a) have people who are there by default b) their job is not necessarily do the job but actively pulling in people who could help and express our expectation they will be more involved.

This is for example what I did in #751 (comment) and it worked (and I have a long time experience of doing the same thing in Airflow).

For example I would love to pull in @ppkarwasz and make him also default reviewer - initially for Java actions and then later to become a more active reviewer. I think he has good ideas and if we actually state our expectations that we would love him to join the reviewer team - he would.

I found this scheme to work - especially with pulling in contributors who would not be even aware that we expect them to act.

I think in many of our endevours we think that people will "magically" show up without any work from our side. I think the most important work of "CODEOWNERS" (at this stage) is not to do reviewes themselves but actually pull in other reviewers actively. This is the only way we can actually achieve community of people collaborating here.

That sounds reasonable but I didn't really volunteer for that.

[potiuk]

I applied the comments @dave2wave and @raboof -> yes I was not here when you volunteered for it - and I do not think you need to do such active recruitment

[potiuk]

That sounds reasonable but I didn't really volunteer for that.

I updated the comment in CODEOWNERS to reflect that.

[potiuk]

Looking for aprovals @raboof @dfoulks1 @dave2wave :)