I like the proposal. Can't really disagree with people voluntarily taking ownership of specific aspects of the codebase. Given the complexity of Airflow, I'm sure the users would appreciate if we have the DOCOWNERS as well for various sections of the documentation : )
Shubham On 2025-02-08, 9:27 AM, "Jarek Potiuk" <ja...@potiuk.com <mailto:ja...@potiuk.com>> wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. 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 <mailto:dev-unsubscr...@airflow.apache.org> For additional commands, e-mail: dev-h...@airflow.apache.org <mailto:dev-h...@airflow.apache.org> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@airflow.apache.org For additional commands, e-mail: dev-h...@airflow.apache.org
