> 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 > > >
