>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 > > >
