Updating the CODEOWNERS seems like a good idea. I feel we probably need to do it occasionally once in a while (half or one year, maybe?)
Best, Wei > On Feb 10, 2025, at 10:30 PM, Vincent Beck <vincb...@apache.org> wrote: > > +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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional commands, e-mail: dev-h...@airflow.apache.org
