Love this idea! Yeah, I felt that CODEOWNERS file was a little bit outdated in the context of Airflow 3 and the rest of the active development happening.
Personally, it's hard for me to catch up with the reviews when I am not notified about it. (Although, I keep checking for different PRs on Github once in a while, while this is OK, it is often easy to miss track of PRs that actually require my attention or review). I would be for the idea definitely here and defining a reasonable ETA for this is something I would be interested in too. And of course, to avoid burnouts when it comes to reviews, I'd suggest we propose at least 3-4 code owners per area based on active development happening (needs revisiting every now and then) Thanks & Regards, Amogh Desai On Sat, Feb 8, 2025 at 11:06 PM Jens Scheffler <[email protected]> wrote: > Hi all, Jarek, > > Thanks for the proposal. > > I would favor the idea - I was opting in in the past for areas where I > assume I have a certain level of expertise and will take care for PRs. > But I also saw a couple of "feeling like orphaned" entries. > > I would even propose to see it stricter: I would expect that persons > signing-in for CODEOWNER should take care that PRs are not stalled. > Maybe an ETA of response of 1 week should be the target (with exceptions > of vacation/sick-leave) > > Jens > > On 08.02.25 18:26, Jarek Potiuk wrote: > > Hello here, > > > > For quite some time I thought that we should make a slightly better > > use of our CODEOWNERS file and feature and agree on some kind of > > "social contract" we have around it. > > > > With providers (almost) moved, we have simplified a lot the CODEOWNERS > > file recently and now it's going to be far simpler to set some of the > > rules up - especially for providers. We are also approaching some > > further package splits so our monorepo will become far better > > modularised, also a number of refactorings - for example dag processor > > ones done by Jed and Daniel recently - made the code related to single > > feature to "live" closer together. And possibly we will do more of > > that. > > > > So far our "social contract" on what it means to be in CODEOWNERS was > > not really clear. But maybe - with airflow 3 and all the refactorings, > > it will be much easier and cleaner to actually draw a bit easier and > > better boundaries between different areas of Airflow - we will have > > better "internal" splits - for example 'task_sdk" , "apis" etc. and we > > have quite significant number of maintainers (only maintainers can be > > added as CODEOWNERS) to cover quite a lot of our code with "experts" > > kind of notion for each area (including some bigger and smaller > > providers). > > > > CODEOWNERS is a bad name though - because CODEOWNERS does not reflect > > the basic assumption that ASF has - that all committers and PMC > > members are stewards (not owners) of all the code that belongs to the > > PMC, but in essence CODEOWNER means two things: > > > > * you will get notified when someone opens a PR that touches area you > > are a CODEOWNER of > > * people opening the PR will see that you are assigned as reviewer in > such case > > > > Which might actually correlate well with being an "expert" in this > > area and someone who should "likely" review PRs there. > > > > Proposal: > > > > So I think maybe this is a chance to make a bit of order in CODEOWNERS > > (currently it's a bit of a mess and random entries). With the notion > > that; > > > > 1) any of the maintainers can sign-up to be CODEOWNER of certain area > > when they think they are expert there > > > > but: > > > > 2) this also means that there is an expectations that they will be > > reviewing code in this area when they are defined as CODEOWNER (of > > course taking into account all volunteer limitations, no expectations > > on specific timelines, and taking into account all vacations and such. > > > > 3) we communicate that in our README and contributor's guide so that > > contributors who contribute a PR understand that and eventually might > > also (after some time) ping the right people - also other maintainers > > will have a clear information who of the maintainers thinks of > > themselves as "expert" in the area - which might make it easier to > > know whom to reach out when there are doubts/questions. > > > > > > Ideally we should have 2/3 people at least in all important areas and > > possibly in big/important providers - to avoid SPOF. > > > > Also we could see where we are lacking "expertise" and that might > > guide other maintainers who would like to learn a certain area - > > signing up as CODEOWNER there might also be a good way to learn by > > more frequent reviews of the area you are signed up to. > > > > And of course at any time any of the maintainers can sign-out by a PR > > and/or we can make some periodic reviews of the areas and see if we > > need some more "bringing an expert" in certain areas. > > > > I wonder what your thoughts are about it. There are certain things > > here that might be problematic - when we do it this way and agree to > > this "social contract" it is some kind of "commitment" - yeah I am > > going to look at those PRs coming in a reasonable time, and people who > > are volunteers might not want it, but - then they might simply > > sign-out to signal they have no time/focus/free cycles to be looking > > at those, so this is something that any maintainer can manage and > > signal their "readiness" to help in different areas. > > > > BTW. You might not know that the word "committer" that we use in ASF > > comes from "commitment" not from "commit permission". So "committing" > > to certain areas, sounds pretty appropriate :) > > > > Looking forward to feedback on that. > > > > J. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
