Add Shahar as a CODEOWNER for Google provider

[shahar1]

Google is one of the most popular providers in the in Apache Airflow, and since I started my activity in project, I've always been quite close to this area - both as a contributor and as a maintainer.*
As this provider often requires close attention due to the big codebase and PRs' throughput, and currently there is no other committer occupying this position (from Google or elsewhere) - I thought that it would be appropriate to propose myself as a more "official" CODEOWNER, improving the existing collaboration with Google's open-source team.

CC: @VladaZakharova @potiuk - what do you think?

* Disclaimer: I'm also a day-to-day user of Google provider in my current job, which is neither Google or GCP.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[github-actions]

Backport successfully created: v3-1-test

Status	Branch	Result
✅	v3-1-test

[jscheffl]

Cool!

[VladaZakharova]

Hi
Thank you for your commitment, i understand your proposal. But from my perspective it should be discussed inside the google team if we want someone to be a codeowner of Google provider, other than someone who is actually working actively for Google. For now i would kindly ask to revert this change before i can discuss this inside the team.

[eladkal]

But from my perspective it should be discussed inside the google team if we want someone to be a codeowner of Google provider, other than someone who is actually working actively for Google.

Only maintainers can be set as Codeowners.
From the Airflow perspective this is just about who is more likely to review and approve PRs in that domain.. it doesn't take away the Google team involvement. However since we have no way to notify you about new PRs you must review periodically all open PRs and issues with the google label (as I believe you already do)

[potiuk]

Thank you for your commitment, i understand your proposal. But from my perspective it should be discussed inside the google team if we want someone to be a codeowner of Google provider, other than someone who is actually working actively for Google. For now i would kindly ask to revert this change before i can discuss this inside the team.

Yes @eladkal is right - CODEOWNER is nothing more than being notified when there is a change and setting that person as reviewer - the name of this feature is wrong (naming is hard). Because this is not about ownership - ASF is the owner of such code at the moment it is merged - and no-one else is, neither maintainers nor google code.

And any of the maintainers can add themselves to be notified when there are changes to the code - there is nothing wrong with it.

We are also addressing it better in the future when it comes to notifying Google team and other stakeholders via https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-95+Provider+lifecycle+update+proposal - there will be dashboards implemented over time and notification mechanisms that will work beyond just maintainers. And we are introducing stewardship concept - but even that stewardship does not mean that any maintainer can anyhow approve and merge a code in any part of the code. Only maintainers (committers) can give binding +1 to any of the code to merge it - this is governed by the ASF voting on code modification https://www.apache.org/foundation/voting.html#votes-on-code-modification - where only commiters / maintainers have a binding +1 (and also -1 being veto) - others, who are not committers can have advisory votes and with our stewardship proposal we have soft internal agreement on steward being involved and generally necessary (except some common global refactors and such) to have a say. But still any of the maintainers can choose to be added to CODEOWNERS to be notified if they want to. AIP-95 does not change it.

[potiuk]

So this is more of a help for you than problem @VladaZakharova - you will also have committer and maintainer who you will be able to ping in case you need to have something approved - also being a daily user - who can make better decisions helps :)

[potiuk]

And we usually don't discuss any other parts of that - if any of the maintainers wants to be a CODEOWNER of any part of airflow - they just ... add themselves :D

[VladaZakharova]

yes, maybe you are right :)
Maybe it will be faster this way
@shahar1 can you please include me and @MaksYermak to the PRs if you see them?

[shahar1]

yes, maybe you are right :)
Maybe it will be faster this way
@shahar1 can you please include me and @MaksYermak to the PRs if you see them?

Of course! That's part of improving the cooperation :)

[jscheffl]

Can we mabe add committers in comments like we do for translations that other contributors can see who is "engaged reviewer"?

Not sure if we considered a mechanism if we get into new governance structure for providers... technically maybe leveraging CODEOWNER might be good to have it in one place... maybe adding a bot to automatically "mention" in a comment engaged persons for review if not possible as "official reviewer" in GH?

[eladkal]

Can we mabe add committers in comments like we do for translations that other contributors can see who is "engaged reviewer"?

I don't understand the value of this even for the translations but in any case this is probably not something to discuss over this PR

maybe adding a bot to automatically "mention" in a comment engaged persons for review if not possible as "official reviewer" in GH?

I am really against that but if a proposal will come to mailing list I will comment there.. not something to be decided here.