Hi Amogh and Ilya (and others), I mostly align with your thinking. I lean toward reserving CODEOWNERS for Level 4 (hard commitment/gating), as the "shield" signal Ilya mentioned is strong despite my preference for the term "CODESTEWARDS."
Adopting an explicit CODENOTIFY for Level 3 would provide the flexibility to include non-maintainer provider stewards. We could potentially use protected branches to require a +1 from a CODEOWNER and implement checks to ensure sufficient coverage among active maintainers. Regarding the naming, we could explore placing a CODESTEWARDS file in the repo and symlinking CODEOWNERS to it, if GitHub supports it. I agree that Levels 1 and 2 should be handled individually. With GitHub's UI improvements and the rise of agentic workflows like Claude or Codex, contributors can now easily customize how they filter and review PRs based on their own criteria. Best, Jarek On Mon, Apr 27, 2026 at 9:29 AM Dev-iL <[email protected]> wrote: > From a purely github-ui perspective: > - code owner reviewers are shown with a "shield", which I think universally > corresponds to the "gating" (4th) level, as they're seen to "protect" the > repo. Furthermore, the 🛡️ carries the extra meaning of "this person is a > maintainer+". > - "Invited" reviewers, otoh, have no special symbology, which seems more > like level 3 (sans the consent). > > So my suggestion (incorporating the previous replies) is: > 1. CODEOWNERS -> level 4 > 2. CODENOTIFY (name ™; same structure as CODEOWNERS or perhaps tag-based) > -> level 3. Reviewers will be auto assigned but will not have a shield. > Could include all community members. > 3. Level 2 is mostly achieved by watching the repo > 4. Level 1 can be achieved via manual issue/pr search filters > > I believe this will align naturally with contributor expectations. > > On Sun, 26 Apr 2026, 16:33 Jarek Potiuk, <[email protected]> wrote: > > > 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 > > > > > >
