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
