Identify unowned parts of the repo

[elharo]

Description

Be explicit about submodules that have no owners

Motivation and Context

Over 80 submodules do not have current owners other than the global committers. This suggests the existing code ownership model is likely too heavyweight for the team size and should be reconsidered. We have fewer active contributors than submodules, and about half of the ones we do have are working only on presto-native.

Impact

none

Test Plan

CI

Contributor checklist

• Please make sure your submission complies with our development, formatting, commit message, and attribution guidelines.
• PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
• Documented new properties (with its default value), SQL syntax, functions, or other functionality.
• If release notes are required, they follow the release notes guidelines.
• Adequate tests were added if applicable.
• CI passed.

Release Notes

== NO RELEASE NOTE ==

[tdcmeehan]

I'm not sure if it's correct to call it unowned. Actually, committers own it. Whether we do a good job of owning is another matter.

I think the goal is to encourage people to pick up these connectors and support them. I wonder if we can add a helpful comment encouraging this. And I wonder if we can add documentation on our contributing guide nudging people in this direction.

[elharo]

Expect a batch of nominations soon, and I think we need to default to more owners rather than gatekeeping. That is, an inexperienced but willing and active approver is preferable to no owner or a backlogged one. Paraphrasing Rumsfeld, you go to code review with the army you have, not the army you want to have.

[elharo]

I believe we should also rethink module level ownership. It means too many active reviewers aren't able to approve outside a very narrow area. It might work if we had a lot more owners than we do, but we don't. I vote for simply promoting everyone to global ownership status to speed up code reviews and approvals.

[steveburnett]

Followup on @tdcmeehan's comment, maybe something like:

• change lines 6 and 68 to "Fallback to committers group for areas that do not have active code owners"

• as part of Improve CONTRIBUTING.md with a table of ways to contribute #22724, add to the Getting Started "See Fallback [Ed.: or whatever line 68 becomes as a header title, and make the word(s) here a link] in CODEOWNERS for modules, connectors, and libraries that lack active codeownership. If you have interest in contributing to one of these, work toward becoming a codeowner for that area. See Committers."

[elharo]

Followup on @tdcmeehan's comment, maybe something like:

* change lines 6 and 68 to "Fallback to committers group for areas that do not have active code owners"

done

[tdcmeehan]

Expect a batch of nominations soon, and I think we need to default to more owners rather than gatekeeping. That is, an inexperienced but willing and active approver is preferable to no owner or a backlogged one. Paraphrasing Rumsfeld, you go to code review with the army you have, not the army you want to have.

@elharo I don't think we'll be able to come to alignment on a PR, and suggest we discuss at a TSC meeting or architecture working group meeting. That being said, while I agree with the principle, I think from this comment it sounds like we have some sort of existing large pool of people who are being gated from joining but who are otherwise reviewing PRs and participating in the project frequently--I don't see that at all. To try to quantify this somehow, I took a look at the top 12 folks in our leaderboard looking back 6 months. 3/4 of them are already committers. The remaining are people who I would say are close to some degree or another, or which we're already working on making them committers. I would expect a lower proportion of committers in this list if we had the problem you mention.

Over 50% of the following 12 people are already committers, and we again see potential for more people from this list to also make it. In total, 16/24 people have a commit bit already, if there were gatekeeping I'd expect more people without the commit bit.

So, reframing this a bit, I think we agree that we work with what we're given, but the bare minimum is people need to show up, so we need to think about how to encourage people to do what is required to help maintain the community. To me, what we need to do is how to best communicate what behaviors are needed. Happy to brainstorm on this with you, but I think it's basically a doc that needs to exist, and people who are motivated just need to follow the doc and get that clear guidance. (We do have a doc already, but I feel like we need something more direct and effective.)

[tdcmeehan]

I believe we should also rethink module level ownership. It means too many active reviewers aren't able to approve outside a very narrow area. It might work if we had a lot more owners than we do, but we don't. I vote for simply promoting everyone to global ownership status to speed up code reviews and approvals.

It used to be global, and I think we can promote more people to global committership and think of a process around that (we talked about this at the TSC last year and I proposed #19803, please feel free to have a look at that). What we found in the past is people would be very hesitant to grant committership when it was global because the people who voted on granting committership would nitpick that candidates didn't have sufficient experience, or they focused on just one area. Code owners were designed to make it so you didn't have that problem--you could demonstrate mastery in just one area and get the commit bit quickly.

I think we can think of a process that people follow to further get global committership, but I worry getting rid of code owners will have the opposite effect you think it has.

Once again though, happy to brainstorm with you, but I think this requires a dedicated hash out. :) Just sharing prior thinking around this.