My 2c: The 4-level framing is the right way to think about this. The practical implication is which of those levels should CODEOWNERS cover? And I personally think, just level 3: soft review commitment. That's the only thing GH mechanism can cleanly express without creating a mess for the future.
Level 1 and 2 do not need CODEOWNERS, GH has watch / subscription that can handle passive notifications without polluting the review queue or creating some sort of false expectations. Adding people to CODEOWNERS "just to be notified" is where the ambiguity creeps in. For level 4 about gating, I would probably handle that separately by having a small, explicitly named list in PROVIDER_GOVERNANCE.rst or a dedicated config file, with some automation that enforces the soft requirement and has a documented bypass path. Trying to signal gating through CODEOWNERS alone is too subtle, and contributors will not know the difference between "this person is here for notification" vs. "this person must review before merge." The coverage gap problem is where I would actually focus energy and try to solve it. The "compute git blame stats and invite top contributors" idea is good — but the result matters most as a public list people can opt into if they wish, not as an auto-assignment. Bottom line I guess here is to agree on a written social contract first and then try to address gaps via a voluntary opt-in process. Don't try to use CODEOWNERS to represent all four levels, we would just be copmplicating it. Thanks & Regards, Amogh Desai On Sun, Apr 26, 2026 at 7:05 PM Jens Scheffler <[email protected]> wrote: > Hi Dev-iL, > > thanks for raising the discussion and "nudging" the community on this. I > _think_ we had a discussion about this ~a year ago where we discussed > about this... but can not find it. > > The thing I remember was that the lising in CODEOWNER file should be a > signal of engegement (not status) of a contributor to "take care" about > PRs. And I think in this light most of the things are organized. > > Since we agreed on the provider governance stewardship model I think the > gaps you raise are really gaps where engagement ("who takes care") are > undefined. And my view always was that we make it (pragmatic as no > better mechanism) with providers the same we do with i18n - defining the > engagement for non-committers in comments and having the sponsors in. > > But we never adjusted the pre-existing providers ... so I agree there > might be pre-existing providers where no committer is notified. Would be > a good chance to discuss how we distribute work - or even if providers > might need somebody to be taking care of where nobody feels responsible. > > I would propose if notifications are rather "noise" then please each > contributor who is bothered un-subscribe to CODEOWNER file. > > Jens > > On 26.04.26 13:47, Dev-iL 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 > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
