Hey all, Thanks for the proposal, Jarek! The idea is great! Sorry for the delayed jump-in! As everyone also pointed out, I see many benefits too. It would balance maintainers' responsibilities and prevent a single person from having many PRs in their TODO, eventually unblocking many PRs.
On Thu, Feb 13, 2025 at 9:50 AM Mehta, Shubham <shu...@amazon.com.invalid> wrote: > 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 > -- Bugra Ozturk
