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