Jarek I agree with the sentiment but I don't think this should be part of this proposal. You are binding the approval process with code review process and ownership/governance about the code. This proposal does not change anything about the ownership/governance model. The approval process of vote/lazy consensus was established in an era where we could not handle so many providers easily, thus we wanted to limit the number of official providers and to discuss the question "Should this be a provider owned by airflow or owned by 3rd party". That question is no longer a serious concern thus I wish to simplify the policy around it. That is it.
> If we automate checks for at least two people in CODESTEWARDS and ensure they are automatically assigned as reviewers and CC'ed on related issues, I am happy to drop the vote requirement. Given the effort required for integrations like Akeyless and Vespa, our existing quality gates should sufficiently prevent "drive-by" providers. I don't think this is a blocker to my proposal. That is something that can happen in parallel. The vote/lazy consensus part that I ask to drop does not offer any value on that front so whether we accept this proposal or not it will not change anything about the automation you are suggesting. On Tue, Apr 28, 2026 at 5:44 PM Jarek Potiuk <[email protected]> wrote: > > I do support Jarek's suggestion for automation of checks when possible, > but > it shouldn't be blocker IMO for introducing the suggested changes. > > Side comment. Those things are no longer blockers. > > To be honest, nowadays, automating a process like that (if we agree on it) > is > literally one, good prompt away. We just need to know what to prompt and be > ready > to step in while the agent implements it. > > Once we agree on the process, it will generally work by pointing the Agent > to this discussion and asking the agent: > > "Implement changes in the Airflow CI and breeze following the discussion in > <link to the discussion>." > > Iterate a little, answer a few questions and correct the agent if it goes > sideways > here and there. > > What results is a ready PR implementing the process - ready for review, > with all the docs and > explanation. We just need to agree on the process first. > > And I am not joking at all - this is what I've been literally doing for the > last two months. Most > of my PRs are now done like that. > > I will be happy to do it once the discussion concludes and show you the > results and prompts > used :) > > J. > > > > On Tue, Apr 28, 2026 at 2:56 PM Shahar Epstein <[email protected]> wrote: > > > +1 from me for this suggestion, which will help reducing beaurocracy and > > inviting more providers to get onboarded. > > > > One suggestion, though: > > To avoid ambiguity, I think that the "without formal vote" should be > > replaced with "with the support of at least one sponsored committer" - > > explicitly stating that there should be a committer "in charge" (which > > could be technically considered as a "vote", providing some level of > > formality...). > > > > I do support Jarek's suggestion for automation of checks when possible, > but > > it shouldn't be blocker IMO for introducing the suggested changes. > > > > > > Shahar > > > > > > On Tue, Apr 28, 2026, 12:42 Elad Kalif <[email protected]> wrote: > > > > > Hi, > > > > > > I'd like to propose a small but meaningful change to how we accept new > > > community providers. > > > > > > Background > > > ---------- > > > > > > When the original acceptance process was written, the bar for what > > > qualified as a > > > community provider was higher and more subjective, a formal vote made > > sense > > > as a > > > gate to ensure broad consensus before investing in a new integration. > > > AIP-95 changed that calculus. By introducing the Incubation stage with > > > clear, objective > > > health metrics and a defined graduation path, we already have a > > structured > > > safety net. > > > A provider that doesn't meet the bar will not graduate; one that does > has > > > already proven > > > its value. The vote before acceptance was largely redundant with the > > > governance framework > > > AIP-95 put in place. > > > > > > Proposed change > > > --------------- > > > > > > Drop the [VOTE] (and the [LAZY CONSENSUS] shortcut) from the acceptance > > > process. > > > A [DISCUSS] thread on the devlist open for 7 days is sufficient. If no > > > objections > > > are raised, the proposal is considered accepted and the contributor can > > > open a PR. > > > > > > The prerequisites remain unchanged: working codebase, at least two > > > stewards, a sponsoring > > > committer, and quality standards. We're also making system test > coverage > > an > > > explicit > > > consideration in the proposal, which was implicit before. > > > > > > This keeps the community informed and gives everyone a chance to raise > > > concerns, without > > > creating unnecessary bureaucratic friction for contributors. > > > > > > The corresponding docs update is here: > > > https://github.com/apache/airflow/pull/66010 > > > > > > Happy to hear thoughts. > > > Elad > > > > > >
