+1 on that proposal, refreshing the code owners would be a great idea. That is something that could help to reduce the number of stale PRs.
On 2025/02/09 07:17:56 Amogh Desai wrote: > 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 <j_scheff...@gmx.de.invalid> > 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: dev-unsubscr...@airflow.apache.org > > > For additional commands, e-mail: dev-h...@airflow.apache.org > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org > > For additional commands, e-mail: dev-h...@airflow.apache.org > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional commands, e-mail: dev-h...@airflow.apache.org
