Yeah. Good points; it would be great to align on what CODEOWNERS mean to us.
CODEOWNERS is a poor name because nowhere in our process do we consider ourselves owners. At most, we can think of the people as "stewards"; this applies equally to core, providers, and any other part of the code. The whole PMC "owns" all the code (Actually at release time - which is the legal act of foundation where we donate the code to the ASF - I think legally it looks like that.). Also CODEOWNERS has the property that it does not allow "non-collaborators" (i.e. regular contributors) to be added to CODEOWNERS. I think indeed that there are several cases as Ilya explained, that fit nicely into the next stage after "triage". And this is my view (progressing with the commitment). 1) I do not want to be notified at all about those (and for that, the solution is, I think, easy) - just remove yourself from CODEOWNERS and do not sign up for other notifications 2) I just want to see that PRs are coming to a certain area, but I am ok if I do not review it at all 3) I want to soft-commit to reviewing PRs, and I am ok if people expect it and ping me after some time when they see a "ready for review" PR. I think it could be nicely connected with "ready for review" label from the triage process (following our gentle ping rules, also of course people are on vacation and such) 4) I want to "gate" PRs in certain areas. For example, for crucial areas of Airflow, there could be several "resident experts," and at least **one** of those people should review the code. (SHOULD -> as if, we can deliberately bypass this in cases of urgency, when no "gating steward" is available but we should have a good reason for it; other PMC members might override it. However, I think having more than one person (power and responsibility) means we commit "more" to doing the reviews. Also, there should always be a few people on this "gating stewards" team so that we are not blocked when someone is on vacation. That's how I see it at least. As I see it 1) is easy, CODEOWNERS (due to it's limitaitons) falls somewhere between 2) and 3) currently - and we could have a social agreement about that. We could also make it primarily serve option 2). For "provider" stewards we also want to include people who are non-contributors. We could add automation to ping both committers and non-committers interested in point 3. This automation could also serve point 4. Point 4 would mostly involve a social contract, but then we should record the "commitment+gating" somewhere. It's very easy now to implement such automation. With Claude/Codex, we simply express our intention, and we get the desired result.. So I would love to hear what others want and whether we can agree on a common solution. J. On Sun, Apr 26, 2026 at 1:48 PM Dev-iL <[email protected]> wrote: > Hi all, > > This came up in a Slack conversation with Jarek and Elad after I noticed > that some provider test directories have no code owners and thus no > reviewers are auto-assigned on PRs touching them. We agreed that a broader > discussion is warranted here. > > --- > > **The core problem** > > Right now, CODEOWNERS means different things to different contributors: > - For some, it's a notification mechanism for areas they care about. > - For others, it implies a review expectation or commitment. > - For others still, it's mostly noise -- especially for cross-cutting PRs > that touch many providers at once. > > This ambiguity creates confusion both for contributors ("why wasn't anyone > assigned?") and for maintainers ("why am I being pinged for this?"). > > --- > > **Proposed discussion points** > > 1. **Agree on what CODEOWNERS means in this project.** Should it signal "I > want to be notified" vs. "I commit to reviewing"? Should we support both > use cases, perhaps with different mechanisms? > > 2. **Coverage gaps.** Many provider directories -- including tests -- have > no owners at all. One idea: compute git blame/contribution stats across PMC > members, publish the results to this list, and *invite* (not assign) top > contributors to voluntarily claim uncovered areas. > > 3. **Connection to provider stewardship.** The [PROVIDER_GOVERNANCE > stewardship model]( > > https://github.com/apache/airflow/blob/main/providers/PROVIDER_GOVERNANCE.rst#stewardship-model > ) > already defines a concept of stewards. CODEOWNERS could be the natural > mechanism for stewards to receive PR notifications in their providers -- > but only if we align on its meaning first. > > --- > > **Non-goals** > > To be explicit: this is not a proposal to force anyone into CODEOWNERS or > to auto-assign review obligations. The Apache principle of volunteering and > consent is the baseline here. > > --- > > Looking forward to hearing your thoughts. I'm happy to follow up with a > concrete proposal once we've aligned on the direction. > > Best, > Dev-iL >
