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
