Hi Elad, I support this proposal provided we implement automated criteria checks for PR merges to ensure commitment and avoid mistakes. This aligns with our discussion on CODEOWNERS [1]; I suggest a three-tier system: CODENOTIFY (notifications), CODEOWNERS (maintainer gating), and CODESTEWARDS (stewards/contributors).
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. [1] https://lists.apache.org/thread/5ssp4ksyohdzclxqvj7ngz0hz5wy9j68 Best, Jarek Potiuk On Tue, Apr 28, 2026 at 11:42 AM 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 >
