From 3484c46764b546d63e6730f83addb5e39f36d232 Mon Sep 17 00:00:00 2001
From: Vikram Koka <vikram@astronomer.io>
Date: Wed, 21 Jan 2026 10:06:35 -0800
Subject: [PATCH 01/12] Updating the Provider governance docs based on AIP-95

Following up from earlier discussions, here is a PR to update the providers governance documentation.

Feedback is welcome.

Full disclosure, I used Cursor to generate the RST doc
---
 PROVIDERS.rst                              | 279 +++++++++++++++++----
 providers/MANAGING_PROVIDERS_LIFECYCLE.rst |  30 +++
 2 files changed, 257 insertions(+), 52 deletions(-)

diff --git a/PROVIDERS.rst b/PROVIDERS.rst
index 05456ebef4c69..283f1003ebf07 100644
--- a/PROVIDERS.rst
+++ b/PROVIDERS.rst
@@ -88,49 +88,233 @@ Airflow main branch to being decommissioned and removed from the main branch in
    `Managing provider's lifecycle <https://github.com/apache/airflow/blob/main/providers/MANAGING_PROVIDERS_LIFECYCLE.rst>`_
 
 
+Provider Governance Framework
+-----------------------------
+
+This section describes the governance framework for community providers, including lifecycle stages,
+stewardship model, and quantitative health metrics.
+
+Airflow's success is built on its extensive ecosystem of community-supported integrations—over 1,600
+hooks, operators, and sensors released as part of 90+ provider packages. These integrations are critical
+for "ubiquitous orchestration." This governance framework establishes a scalable method to grow the
+number of integrations while ensuring quality. All governance remains with the Airflow PMC.
+
+Provider Stewardship Model
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Each provider or integration component must have designated **stewards** responsible for ensuring
+the health criteria described below are met:
+
+* **Minimum stewards**: At least two unique individuals must serve as stewards for each provider
+* **Role definition**: Stewards are subject matter experts for the integration (service, language,
+  or skill). Stewardship is a responsibility, not an additional authority or privilege
+* **Committer sponsorship**: Each steward must be sponsored by an existing Airflow Committer who
+  ensures stewards fulfill their responsibilities. The sponsor is responsible for guiding the stewards
+  through the process of maintaining the provider, following best practices including regular dependency
+  updates, issue resolution, and ensuring the provider meets the health metrics described below. The sponsor
+  is NOT responsible for the codebase itself, which remains the responsibility of the stewards.
+* **Accountability**: Ultimate accountability remains with the Airflow PMC and Committers
+* **Transitions**: Neither sponsorship nor stewardship are roles in perpetuity—they can be
+  transitioned to others based on mutual agreement and PMC approval
+
+.. note::
+
+   The quantitative criteria described below are aspirational. The PMC will revisit these metrics
+   based on actual experience 6 months after they are established and published.
+
+Provider Lifecycle Stages
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+All providers follow a three-stage lifecycle: **Incubation**, **Production**, and **Attic/Deprecation**.
+Additionally, providers may be designated as **Mature** under specific circumstances.
+
+**Incubation Stage**
+
+All new providers or integration modules (such as Notifiers, Message components, etc.) should start
+in incubation unless specifically accelerated by the PMC. Incubation ensures that code, licenses, and
+processes align with ASF guidelines and community principles such as community, collaborative
+development, and openness.
+
+Requirements for incubation:
+
+* Working codebase to bootstrap credibility and attract contributions
+* Visibility in the provider health dashboard
+* Designated stewards with committer sponsorship
+
+Quantitative graduation criteria:
+
+.. list-table::
+   :header-rows: 1
+   :widths: 40 60
+
+   * - Metric
+     - Threshold
+   * - PRs submitted
+     - Minimum of 10 PRs in the last 6 months
+   * - PR review time
+     - PRs reviewed within 14 days
+   * - Issues reported
+     - Minimum of 15 unique issues filed in the last 6 months
+   * - Contributors
+     - At least 3 unique individuals making contributions (code or documentation) in the last 6 months
+   * - Issue resolution rate
+     - At least 50% of reported issues closed within 90 days
+   * - Security/release issues
+     - All release and security related issues closed within 60 days
+   * - Governance participation
+     - Demonstrated participation in project governance channels including quarterly updates
+   * - Quality standards
+     - Meet quality criteria for code, documentation, and tests as listed in the Contributing Guide
+
+**Production Stage**
+
+All modules in production are expected to be well managed with prompt resolution of issues and
+support for a consistent release cadence (at least monthly, but typically every 2 weeks when changes
+exist). Production providers must:
+
+* Stay consistent with the main branch
+* Pass tests for main + all supported Airflow versions
+* Follow Airflow support guidelines, staying current with main Airflow releases
+
+Exceptions can be granted based on a PMC/devlist vote (PMC members only having binding votes) for
+valid and one-off criteria.
+
+Quantitative criteria to maintain production status:
+
+.. list-table::
+   :header-rows: 1
+   :widths: 40 60
+
+   * - Metric
+     - Threshold
+   * - PRs submitted
+     - Minimum of 10 PRs in the last 6 months
+   * - PR review time
+     - PRs reviewed within 14 days
+   * - Issues reported
+     - Minimum of 20 unique issues filed in the last 6 months
+   * - Contributors
+     - At least 5 unique individuals making contributions (code or documentation) in the last 6 months
+   * - Issue resolution rate
+     - At least 60% of reported issues closed within 90 days
+   * - Security/release issues
+     - All release and security related issues closed within 30 days
+   * - Feature releases
+     - At least 1 feature release every 6 months
+   * - User engagement
+     - Maintain support activity with response to questions within 2 weeks on average
+   * - Governance participation
+     - Demonstrated participation in project governance channels including quarterly updates
+
+**Attic / Deprecation Stage**
+
+Modules should be moved into the Attic when relevance wanes, typically measured by declining
+activity. This commonly occurs when the integrated solution has faded in popularity and is replaced
+by more modern alternatives.
+
+Movement to the Attic must be communicated on the dev list and voted on by the PMC. Exceptions can
+be granted based on the vote.
+
+Quantitative criteria triggering attic consideration:
+
+.. list-table::
+   :header-rows: 1
+   :widths: 40 60
+
+   * - Metric
+     - Threshold
+   * - PRs submitted
+     - Fewer than 5 PRs in the last 6 months
+   * - PR review time
+     - PRs not being reviewed in more than a month
+   * - Issues reported
+     - Fewer than 10 unique issues filed in the last 6 months
+   * - Contributors
+     - Fewer than 3 unique individuals making contributions (code or documentation) in the last 6 months
+   * - Issue resolution rate
+     - Less than 30% of reported issues closed within 90 days
+   * - Security/release issues
+     - Release and security related issues not getting closed within 30 days
+   * - Feature releases
+     - No feature releases in the last 6 months
+
+Consequences of attic status:
+
+* Modules remain readable but do not receive active maintenance
+* After a period of at least 6 months in the attic, modules can be chosen for removal with
+  appropriate communication (see `Removing community providers`_ below)
+
+**Mature Providers**
+
+Some providers may have very stable interfaces requiring minimal changes on a regular basis (e.g.,
+Slack provider integration). At the discretion of the Airflow PMC, certain providers can be tagged
+as **"mature providers"**, which will not automatically be deprecated and moved into the attic due
+to lack of activity alone.
+
+Periodic Reviews
+^^^^^^^^^^^^^^^^
+
+The Airflow PMC is responsible for reviewing the health status of integrations on a **quarterly
+basis** and making decisions such as:
+
+* Graduating providers from incubation to production
+* Moving providers from production to the attic
+* Granting exceptions for specific providers
+
+These discussions will be held in public and subsequently summarized and shared on the Airflow devlist.
+
+
 Accepting new community providers
 ---------------------------------
 
-Accepting new community providers should be a deliberate process that requires ``[DISCUSSION]``
-followed by ``[VOTE]`` thread at the Airflow `devlist <https://airflow.apache.org/community/#mailing-list>`_.
-
-In case the provider is integration with an open-source software rather than service we can relax the vote
-procedure a bit. Particularly if the open-source software is an Apache Software Foundation,
-Linux Software Foundation or similar organisation with well established governance processes that are not
-strictly vendor-controlled, and when the software is well established an popular, it might be enough to
-have a good and complete PR of the provider, ideally with a great test coverage, including integration tests,
-and documentation. Then it should be enough to request the provider acceptance by a ``[LAZY CONSENSUS]`` mail
-on the devlist and assuming such lazy consensus is not objected by anyone in the community, the provider
-might be merged.
-
-For service providers, the ``[DISCUSSION]`` thread is aimed to gather information about the reasons why
-the one who proposes the new provider thinks it should be accepted by the community. Maintaining the provider
-in the community is a burden. Contrary to many people's beliefs, code is often liability rather than asset,
-and accepting the code to be managed by the community, especially when it involves significant effort on
-maintenance is often undesired, especially that the community consists of volunteers. There must be a really
-good reason why we would believe that the provider is better to be maintained by the community if there
-are 3rd-party teams that can be paid to manage it on their own. We have to believe that the current
-community interest is in managing the provider and that enough volunteers in the community will be
-willing to maintain it in the future in order to accept the provider.
-
-The ``[VOTE]`` thread is aimed to gather votes from the community on whether the provider should be accepted
-or not and it follows the usual Apache Software Foundation voting rules concerning
+The Airflow community welcomes new provider contributions. All new providers enter through the
+**Incubation** stage (unless specifically accelerated by the PMC) to ensure alignment with ASF
+guidelines and community principles.
+
+**Prerequisites for proposing a new provider:**
+
+1. **Working codebase**: A functional implementation demonstrating the integration
+2. **Stewardship commitment**: At least two individuals willing to serve as stewards
+3. **Committer sponsorship**: At least one existing Airflow Committer willing to sponsor the stewards
+4. **Quality standards**: Code, tests, and documentation meeting the Contributing Guide standards
+
+**Approval process:**
+
+Accepting new community providers requires a ``[DISCUSSION]`` followed by ``[VOTE]`` thread at the
+Airflow `devlist <https://airflow.apache.org/community/#mailing-list>`_.
+
+For integrations with well-established open-source software (Apache Software Foundation, Linux
+Foundation, or similar organizations with established governance), a ``[LAZY CONSENSUS]`` process
+may be sufficient, provided the PR includes comprehensive test coverage and documentation.
+
+The ``[DISCUSSION]`` thread should include:
+
+* Description of the integration and its value to the Airflow ecosystem
+* Identification of the proposed stewards and their sponsoring committer(s)
+* Commitment to meet incubation health metrics within 6 months
+* Plan for participating in quarterly governance updates
+
+The ``[VOTE]`` follows the usual Apache Software Foundation voting rules concerning
 `Votes on Code Modification <https://www.apache.org/foundation/voting.html#votes-on-code-modification>`_
 
-The Ecosystem page and registries, and own resources of the 3rd-party teams are the best places to increase
-visibility that such providers exist, so there is no "great" visibility achieved by getting the provider in
-the community. Also it is often easier to advertise and promote usage of the provider by the service providers
-themselves when they own, manage and release their provider, especially when they can synchronize releases
-of their provider with new feature, the service might get added.
+**Alternative: 3rd-party managed providers**
+
+For service providers or systems integrators with dedicated teams to manage their provider and who wish to not participate
+in the Airflow community, we encourage considering 3rd-party management of providers. The
+`Ecosystem page <https://airflow.apache.org/ecosystem/#third-party-airflow-plugins-and-providers>`_
+provides visibility for 3rd-party providers, and this approach allows service providers or systems integrators to:
 
-Examples:
+* Synchronize releases with their service updates
+* Maintain direct control over the integration
+* Support older Airflow versions if needed
 
-Huawei Cloud provider - `Discussion <https://lists.apache.org/thread/f5tk9c734wlyv616vyy8r34ymth3dqbc>`_
-Cloudera provider - `Discussion <https://lists.apache.org/thread/2z0lvgj466ksxxrbvofx41qvn03jrwwb>`_, `Vote <https://lists.apache.org/thread/8b1jvld3npgzz2z0o3gv14lvtornbdrm>`_
-PgVector / Weaviate/ OpenAI provider - `Discussion <https://lists.apache.org/thread/0d669fmy4hn29h5c0wj0ottdskd77ktp>`_, `Lazy Consensus vote <https://lists.apache.org/thread/zrq6554lwobhngtwyzp7tpgnyfsxxybh>`_
-Pinecone / OpenAI / Cohere provider - `Discussion <https://lists.apache.org/thread/0d669fmy4hn29h5c0wj0ottdskd77ktp>`_, `Vote <https://lists.apache.org/thread/skh32jksvcf4yx4fhhsfz8lq6w5nhfjc>`_, `VOTE Result <https://lists.apache.org/thread/oq7h2n88zfo3dzldy5w8xlp9kyngs7x8>`_
+There is no difference in technical capabilities between community and 3rd-party providers.
+
+**Historical examples:**
+
+* Huawei Cloud provider - `Discussion <https://lists.apache.org/thread/f5tk9c734wlyv616vyy8r34ymth3dqbc>`_
+* Cloudera provider - `Discussion <https://lists.apache.org/thread/2z0lvgj466ksxxrbvofx41qvn03jrwwb>`_, `Vote <https://lists.apache.org/thread/8b1jvld3npgzz2z0o3gv14lvtornbdrm>`_
 
-Note that some providers have regular vote and some lazy consensus, please refer to the above sections for explanation why it's not the same for all providers
 
 Community providers release process
 -----------------------------------
@@ -175,19 +359,13 @@ might want to maintain their own providers - as they can decide to support older
 3rd-parties relation to community providers
 -------------------------------------------
 
-Providers, can (and it is recommended for 3rd-party services) also be maintained and released by 3rd parties,
-but for multiple reasons we might decide to keep those providers as community managed providers - mostly
-due to prevalence and popularity of the 3rd-party services and use cases they serve among our community. There
-are however certain conditions and expectations we have in order.
-
+Providers, can also be maintained and released by 3rd parties (service providers or systems integrators).
 There is no difference between the community and 3rd party providers - they have all the same capabilities
-and limitations. The consensus in the Airflow community is that usually it is better for the community and
-for the health of the provider to be managed by the 3rd party team, rather than by the Airflow community.
+and limitations.
+
 This is especially in case the provider concerns 3rd-party service that has a team that can manage provider
-on their own. For the Airflow community, managing and releasing a 3rd-party provider that we cannot test
-and verify is a lot of effort and uncertainty, especially including the cases where the external service is
-live and going to evolve in the future, and it is better to let the 3rd party team manage it,
-as they can better keep pace with the changes in the service.
+on their own, has a rapidly evolving live service, and believe they need a faster release cycle than the community
+can provide.
 
 Information about such 3rd-party providers are usually published at the
 `Ecosystem: plugins and providers <https://airflow.apache.org/ecosystem/#third-party-airflow-plugins-and-providers>`_
@@ -296,7 +474,8 @@ Airflow and with other providers - by merging a PR that removes the suspension a
 Removing community providers
 ----------------------------
 
-The providers can be removed from main branch of Airflow when the community agrees that there should be no
+After a Provider has been deprecated, as described above with a ``[VOTE]`` thread, it can
+be removed from main branch of Airflow when the community agrees that there should be no
 more updates to the providers done by the community - except maybe potentially security fixes found. There
 might be various reasons for the providers to be removed:
 
@@ -305,11 +484,7 @@ might be various reasons for the providers to be removed:
 * there is another, more popular provider that supersedes community provider
 * etc. etc.
 
-Each case of removing provider should be discussed individually and separate ``[VOTE]`` thread should start,
-where regular rules for code modification apply (following the
-`Apache Software Foundation voting rules <https://www.apache.org/foundation/voting.html#votes-on-code-modification>`_).
-In cases where the reasons for removal are ``obvious``, and discussed before, also ``[LAZY CONSENSUS]`` thread
-can be started. Generally speaking a discussion thread ``[DISCUSS]`` is advised before such removal and
+Generally speaking a discussion thread ``[DISCUSS]`` is advised before such removal and
 sufficient time should pass (at least a week) to give a chance for community members to express their
 opinion on the removal.
 
diff --git a/providers/MANAGING_PROVIDERS_LIFECYCLE.rst b/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
index 452e6baf2b1ca..32b02e5d2885e 100644
--- a/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
+++ b/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
@@ -18,6 +18,36 @@
 
 **The outline for this document in GitHub is available at top-right corner button (with 3-dots and 3 lines).**
 
+Provider Governance Overview
+============================
+
+Before diving into the technical details of creating and managing providers, please familiarize
+yourself with the governance framework that applies to all community providers:
+
+* `Provider Governance Framework <https://github.com/apache/airflow/blob/main/PROVIDERS.rst#provider-governance-framework>`_
+
+Key governance concepts:
+
+* **Lifecycle stages**: All providers move through Incubation → Production → Attic/Deprecation
+* **Stewardship**: Each provider requires at least two stewards sponsored by Airflow Committers
+* **Health metrics**: Quantitative criteria determine readiness for promotion or deprecation
+* **Periodic reviews**: The PMC reviews provider health quarterly
+
+All new providers must start in the **Incubation** stage (unless specifically accelerated by the PMC)
+and meet the graduation criteria before moving to Production status.
+
+Stewardship Requirements for New Providers
+------------------------------------------
+
+When proposing a new community provider, you must:
+
+1. Identify at least two individuals willing to serve as stewards
+2. Secure sponsorship from at least one existing Airflow Committer for each steward
+3. Commit to meeting the incubation health metrics within 6 months
+4. Participate in quarterly governance updates on the devlist
+
+Include this information in your ``[DISCUSSION]`` thread when proposing a new provider.
+
 Creating a new community provider
 =================================
 

From 8637e926b2576d946b59f6101a410fa8ce419df7 Mon Sep 17 00:00:00 2001
From: Vikram Koka <vikram@astronomer.io>
Date: Fri, 23 Jan 2026 10:11:20 -0800
Subject: [PATCH 02/12] Update PROVIDERS.rst

Co-authored-by: Ryan Hatter <25823361+RNHTTR@users.noreply.github.com>
---
 PROVIDERS.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/PROVIDERS.rst b/PROVIDERS.rst
index 283f1003ebf07..a9636d05cde02 100644
--- a/PROVIDERS.rst
+++ b/PROVIDERS.rst
@@ -114,7 +114,7 @@ the health criteria described below are met:
   updates, issue resolution, and ensuring the provider meets the health metrics described below. The sponsor
   is NOT responsible for the codebase itself, which remains the responsibility of the stewards.
 * **Accountability**: Ultimate accountability remains with the Airflow PMC and Committers
-* **Transitions**: Neither sponsorship nor stewardship are roles in perpetuity—they can be
+* **Transitions**: Neither sponsorship nor stewardship are roles in perpetuity; they can be
   transitioned to others based on mutual agreement and PMC approval
 
 .. note::

From ad1e38d5653087c1c59d14ac89a6a414c32569e9 Mon Sep 17 00:00:00 2001
From: Vikram Koka <vikram@astronomer.io>
Date: Fri, 23 Jan 2026 10:12:55 -0800
Subject: [PATCH 03/12] Update PROVIDERS.rst

Co-authored-by: Ryan Hatter <25823361+RNHTTR@users.noreply.github.com>
---
 PROVIDERS.rst | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/PROVIDERS.rst b/PROVIDERS.rst
index a9636d05cde02..22c9356adfaa1 100644
--- a/PROVIDERS.rst
+++ b/PROVIDERS.rst
@@ -108,11 +108,12 @@ the health criteria described below are met:
 * **Minimum stewards**: At least two unique individuals must serve as stewards for each provider
 * **Role definition**: Stewards are subject matter experts for the integration (service, language,
   or skill). Stewardship is a responsibility, not an additional authority or privilege
-* **Committer sponsorship**: Each steward must be sponsored by an existing Airflow Committer who
-  ensures stewards fulfill their responsibilities. The sponsor is responsible for guiding the stewards
-  through the process of maintaining the provider, following best practices including regular dependency
-  updates, issue resolution, and ensuring the provider meets the health metrics described below. The sponsor
-  is NOT responsible for the codebase itself, which remains the responsibility of the stewards.
+* **Committer sponsorship**: Each steward must be sponsored by an existing Airflow Committer. The
+sponsor ensures that stewards fulfill their responsibilities and provides guidance on maintaining the
+provider according to best practices. This includes regular dependency updates, issue resolution, and
+ensuring the provider meets the health metrics required for its current lifecycle stage (that is, incubation
+or production). The sponsor is NOT responsible for the provider’s codebase, which remains the
+responsibility of the stewards.
 * **Accountability**: Ultimate accountability remains with the Airflow PMC and Committers
 * **Transitions**: Neither sponsorship nor stewardship are roles in perpetuity; they can be
   transitioned to others based on mutual agreement and PMC approval

From c6c40e776cc54032204c6650d1aceb315be7f33f Mon Sep 17 00:00:00 2001
From: Vikram Koka <vikram@astronomer.io>
Date: Fri, 23 Jan 2026 10:13:16 -0800
Subject: [PATCH 04/12] Update providers/MANAGING_PROVIDERS_LIFECYCLE.rst

Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
---
 providers/MANAGING_PROVIDERS_LIFECYCLE.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/providers/MANAGING_PROVIDERS_LIFECYCLE.rst b/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
index 32b02e5d2885e..fc814b90b0f35 100644
--- a/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
+++ b/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
@@ -24,7 +24,7 @@ Provider Governance Overview
 Before diving into the technical details of creating and managing providers, please familiarize
 yourself with the governance framework that applies to all community providers:
 
-* `Provider Governance Framework <https://github.com/apache/airflow/blob/main/PROVIDERS.rst#provider-governance-framework>`_
+* `Provider Governance Framework <../PROVIDERS.rst#provider-governance-framework>`_
 
 Key governance concepts:
 

From 4a4291eafdcfb3d5bf1a9cd7ca27099c066a9138 Mon Sep 17 00:00:00 2001
From: Vikram Koka <vikram@astronomer.io>
Date: Fri, 23 Jan 2026 10:57:57 -0800
Subject: [PATCH 05/12] Update providers/MANAGING_PROVIDERS_LIFECYCLE.rst

Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
---
 providers/MANAGING_PROVIDERS_LIFECYCLE.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/providers/MANAGING_PROVIDERS_LIFECYCLE.rst b/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
index fc814b90b0f35..972e542eacf66 100644
--- a/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
+++ b/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
@@ -42,7 +42,7 @@ Stewardship Requirements for New Providers
 When proposing a new community provider, you must:
 
 1. Identify at least two individuals willing to serve as stewards
-2. Secure sponsorship from at least one existing Airflow Committer for each steward
+2. Secure sponsorship from at least one existing Airflow Committer for each steward (if steward is not itself a committer)
 3. Commit to meeting the incubation health metrics within 6 months
 4. Participate in quarterly governance updates on the devlist
 

From bbf199c3993e2da40a5c0b205798d02ecec8802a Mon Sep 17 00:00:00 2001
From: Vikram Koka <vikram@astronomer.io>
Date: Fri, 23 Jan 2026 10:58:43 -0800
Subject: [PATCH 06/12] Update PROVIDERS.rst

Co-authored-by: Jens Scheffler <95105677+jscheffl@users.noreply.github.com>
---
 PROVIDERS.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/PROVIDERS.rst b/PROVIDERS.rst
index 22c9356adfaa1..f6b4fd6a8bcfb 100644
--- a/PROVIDERS.rst
+++ b/PROVIDERS.rst
@@ -248,7 +248,7 @@ Consequences of attic status:
 **Mature Providers**
 
 Some providers may have very stable interfaces requiring minimal changes on a regular basis (e.g.,
-Slack provider integration). At the discretion of the Airflow PMC, certain providers can be tagged
+HTTP provider integration). At the discretion of the Airflow PMC, certain providers can be tagged
 as **"mature providers"**, which will not automatically be deprecated and moved into the attic due
 to lack of activity alone.
 

From 41c486e02e99281bcb687143f45b054a7ec9a7ba Mon Sep 17 00:00:00 2001
From: Vikram Koka <vikram@astronomer.io>
Date: Fri, 23 Jan 2026 11:01:07 -0800
Subject: [PATCH 07/12] Update PROVIDERS.rst

Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
---
 PROVIDERS.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/PROVIDERS.rst b/PROVIDERS.rst
index f6b4fd6a8bcfb..f3776570f2f86 100644
--- a/PROVIDERS.rst
+++ b/PROVIDERS.rst
@@ -97,7 +97,7 @@ stewardship model, and quantitative health metrics.
 Airflow's success is built on its extensive ecosystem of community-supported integrations—over 1,600
 hooks, operators, and sensors released as part of 90+ provider packages. These integrations are critical
 for "ubiquitous orchestration." This governance framework establishes a scalable method to grow the
-number of integrations while ensuring quality. All governance remains with the Airflow PMC.
+number of integrations while ensuring quality. Actual code acceptance and release governance remains with the Airflow PMC.
 
 Provider Stewardship Model
 ^^^^^^^^^^^^^^^^^^^^^^^^^^

From 67b943c824fa2cc2b60b120298c76bd0f796ddcc Mon Sep 17 00:00:00 2001
From: Vikram Koka <vikram@astronomer.io>
Date: Fri, 23 Jan 2026 12:29:53 -0800
Subject: [PATCH 08/12] Updated with clarifications

Updated with clarification around process governance and to address feedback.
---
 PROVIDERS.rst                              | 15 ++++++++++-----
 providers/MANAGING_PROVIDERS_LIFECYCLE.rst | 10 ++++++----
 2 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/PROVIDERS.rst b/PROVIDERS.rst
index f3776570f2f86..e0860e64d5e1d 100644
--- a/PROVIDERS.rst
+++ b/PROVIDERS.rst
@@ -111,9 +111,9 @@ the health criteria described below are met:
 * **Committer sponsorship**: Each steward must be sponsored by an existing Airflow Committer. The
 sponsor ensures that stewards fulfill their responsibilities and provides guidance on maintaining the
 provider according to best practices. This includes regular dependency updates, issue resolution, and
-ensuring the provider meets the health metrics required for its current lifecycle stage (that is, incubation
-or production). The sponsor is NOT responsible for the provider’s codebase, which remains the
-responsibility of the stewards.
+monitoring that the provider meets the health metrics required for its current lifecycle stage (that is, incubation
+or production). The sponsor is responsible for PR reviews and merges (including ensuring coding standards are met), but 
+is NOT responsible for active maintenance of the provider’s codebase, which remains the responsibility of the stewards.
 * **Accountability**: Ultimate accountability remains with the Airflow PMC and Committers
 * **Transitions**: Neither sponsorship nor stewardship are roles in perpetuity; they can be
   transitioned to others based on mutual agreement and PMC approval
@@ -121,7 +121,7 @@ responsibility of the stewards.
 .. note::
 
    The quantitative criteria described below are aspirational. The PMC will revisit these metrics
-   based on actual experience 6 months after they are established and published.
+   based on actual experience 6 months from the date of the first quarterly review of the provider metrics being published.
 
 Provider Lifecycle Stages
 ^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -139,7 +139,7 @@ development, and openness.
 Requirements for incubation:
 
 * Working codebase to bootstrap credibility and attract contributions
-* Visibility in the provider health dashboard
+* Visibility in the provider health dashboard (The provider health dashboard is to be added)
 * Designated stewards with committer sponsorship
 
 Quantitative graduation criteria:
@@ -242,8 +242,13 @@ Quantitative criteria triggering attic consideration:
 Consequences of attic status:
 
 * Modules remain readable but do not receive active maintenance
+* Module is not actively tested in "main"  in Airflow CI , it's dependencies are not checked for conflicts 
+  with other main providers, and common refactorings are not applied to it.
 * After a period of at least 6 months in the attic, modules can be chosen for removal with
   appropriate communication (see `Removing community providers`_ below)
+* It is possible for the provider to be resurrected from the attic as long as there is confidence that there is a 
+  clear need for the provider and the (possibly new) stewards are able to maintain it actively on this go around. 
+  It should be noted that significant effort may be required to resurrect a provider from the attic. 
 
 **Mature Providers**
 
diff --git a/providers/MANAGING_PROVIDERS_LIFECYCLE.rst b/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
index 972e542eacf66..c8ca47aa4f02d 100644
--- a/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
+++ b/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
@@ -28,13 +28,15 @@ yourself with the governance framework that applies to all community providers:
 
 Key governance concepts:
 
-* **Lifecycle stages**: All providers move through Incubation → Production → Attic/Deprecation
-* **Stewardship**: Each provider requires at least two stewards sponsored by Airflow Committers
+* **Lifecycle stages**: Providers move through the following lifecycle stages: Incubation → Production → Attic/Deprecation
+* **Stewardship**: Each provider requires at least two stewards (who don't have to be Airflow Committers themselves) 
 * **Health metrics**: Quantitative criteria determine readiness for promotion or deprecation
 * **Periodic reviews**: The PMC reviews provider health quarterly
 
 All new providers must start in the **Incubation** stage (unless specifically accelerated by the PMC)
-and meet the graduation criteria before moving to Production status.
+and meet the graduation criteria before moving to Production status. 
+Existing providers will by default start in the Production stage with the Airflow PMC as stewards, unless 
+stewards have already been identified. 
 
 Stewardship Requirements for New Providers
 ------------------------------------------
@@ -42,7 +44,7 @@ Stewardship Requirements for New Providers
 When proposing a new community provider, you must:
 
 1. Identify at least two individuals willing to serve as stewards
-2. Secure sponsorship from at least one existing Airflow Committer for each steward (if steward is not itself a committer)
+2. Secure sponsorship from at least one existing Airflow Committer (if none of the stewards are a committer)
 3. Commit to meeting the incubation health metrics within 6 months
 4. Participate in quarterly governance updates on the devlist
 

From a6ccde8fc4f94a082e91112bb686b0d0d5ea2642 Mon Sep 17 00:00:00 2001
From: Vikram Koka <vikram@astronomer.io>
Date: Fri, 23 Jan 2026 13:08:41 -0800
Subject: [PATCH 09/12] Addressed feedback

Added more clarifications to address feedback
---
 PROVIDERS.rst                              | 9 +++++----
 providers/MANAGING_PROVIDERS_LIFECYCLE.rst | 3 ++-
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/PROVIDERS.rst b/PROVIDERS.rst
index e0860e64d5e1d..320b0f04a1be2 100644
--- a/PROVIDERS.rst
+++ b/PROVIDERS.rst
@@ -106,8 +106,9 @@ Each provider or integration component must have designated **stewards** respons
 the health criteria described below are met:
 
 * **Minimum stewards**: At least two unique individuals must serve as stewards for each provider
-* **Role definition**: Stewards are subject matter experts for the integration (service, language,
-  or skill). Stewardship is a responsibility, not an additional authority or privilege
+* **Role definition**: Stewards are subject matter experts for the integration. This could be expertise in the
+  service being integrated, the language being supported by the provider, or the framework being integrated. 
+  Stewardship is a responsibility, not an additional authority or privilege
 * **Committer sponsorship**: Each steward must be sponsored by an existing Airflow Committer. The
 sponsor ensures that stewards fulfill their responsibilities and provides guidance on maintaining the
 provider according to best practices. This includes regular dependency updates, issue resolution, and
@@ -126,8 +127,8 @@ is NOT responsible for active maintenance of the provider’s codebase, which re
 Provider Lifecycle Stages
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
-All providers follow a three-stage lifecycle: **Incubation**, **Production**, and **Attic/Deprecation**.
-Additionally, providers may be designated as **Mature** under specific circumstances.
+Providers generallyfollow a three-stage lifecycle: **Incubation**, **Production**, and **Attic/Deprecation**. However, 
+not all providers will move through all stages. Additionally, providers may be designated as **Mature** under specific circumstances.
 
 **Incubation Stage**
 
diff --git a/providers/MANAGING_PROVIDERS_LIFECYCLE.rst b/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
index c8ca47aa4f02d..21767607d6e7b 100644
--- a/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
+++ b/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
@@ -28,7 +28,8 @@ yourself with the governance framework that applies to all community providers:
 
 Key governance concepts:
 
-* **Lifecycle stages**: Providers move through the following lifecycle stages: Incubation → Production → Attic/Deprecation
+* **Lifecycle stages**: Providers move through the following lifecycle stages: Incubation → Production → Attic/Deprecation. To be precise, 
+  not all providers will move through all stages. 
 * **Stewardship**: Each provider requires at least two stewards (who don't have to be Airflow Committers themselves) 
 * **Health metrics**: Quantitative criteria determine readiness for promotion or deprecation
 * **Periodic reviews**: The PMC reviews provider health quarterly

From e0d85fb272248fc30968892c4d72d549c2301a13 Mon Sep 17 00:00:00 2001
From: Vikram Koka <vikram@astronomer.io>
Date: Fri, 23 Jan 2026 13:42:54 -0800
Subject: [PATCH 10/12] Fixed formatting issues

Fixed formatting issues in the docs
---
 PROVIDERS.rst                              | 22 +++++++++++-----------
 providers/MANAGING_PROVIDERS_LIFECYCLE.rst | 12 ++++++------
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/PROVIDERS.rst b/PROVIDERS.rst
index 320b0f04a1be2..a609c390d2f75 100644
--- a/PROVIDERS.rst
+++ b/PROVIDERS.rst
@@ -107,14 +107,14 @@ the health criteria described below are met:
 
 * **Minimum stewards**: At least two unique individuals must serve as stewards for each provider
 * **Role definition**: Stewards are subject matter experts for the integration. This could be expertise in the
-  service being integrated, the language being supported by the provider, or the framework being integrated. 
+  service being integrated, the language being supported by the provider, or the framework being integrated.
   Stewardship is a responsibility, not an additional authority or privilege
 * **Committer sponsorship**: Each steward must be sponsored by an existing Airflow Committer. The
-sponsor ensures that stewards fulfill their responsibilities and provides guidance on maintaining the
-provider according to best practices. This includes regular dependency updates, issue resolution, and
-monitoring that the provider meets the health metrics required for its current lifecycle stage (that is, incubation
-or production). The sponsor is responsible for PR reviews and merges (including ensuring coding standards are met), but 
-is NOT responsible for active maintenance of the provider’s codebase, which remains the responsibility of the stewards.
+  sponsor ensures that stewards fulfill their responsibilities and provides guidance on maintaining the
+  provider according to best practices. This includes regular dependency updates, issue resolution, and
+  monitoring that the provider meets the health metrics required for its current lifecycle stage (that is, incubation
+  or production). The sponsor is responsible for PR reviews and merges (including ensuring coding standards are met), but
+  is NOT responsible for active maintenance of the provider's codebase, which remains the responsibility of the stewards.
 * **Accountability**: Ultimate accountability remains with the Airflow PMC and Committers
 * **Transitions**: Neither sponsorship nor stewardship are roles in perpetuity; they can be
   transitioned to others based on mutual agreement and PMC approval
@@ -127,7 +127,7 @@ is NOT responsible for active maintenance of the provider’s codebase, which re
 Provider Lifecycle Stages
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Providers generallyfollow a three-stage lifecycle: **Incubation**, **Production**, and **Attic/Deprecation**. However, 
+Providers generally follow a three-stage lifecycle: **Incubation**, **Production**, and **Attic/Deprecation**. However,
 not all providers will move through all stages. Additionally, providers may be designated as **Mature** under specific circumstances.
 
 **Incubation Stage**
@@ -243,13 +243,13 @@ Quantitative criteria triggering attic consideration:
 Consequences of attic status:
 
 * Modules remain readable but do not receive active maintenance
-* Module is not actively tested in "main"  in Airflow CI , it's dependencies are not checked for conflicts 
+* Module is not actively tested in "main" in Airflow CI, its dependencies are not checked for conflicts
   with other main providers, and common refactorings are not applied to it.
 * After a period of at least 6 months in the attic, modules can be chosen for removal with
   appropriate communication (see `Removing community providers`_ below)
-* It is possible for the provider to be resurrected from the attic as long as there is confidence that there is a 
-  clear need for the provider and the (possibly new) stewards are able to maintain it actively on this go around. 
-  It should be noted that significant effort may be required to resurrect a provider from the attic. 
+* It is possible for the provider to be resurrected from the attic as long as there is confidence that there is a
+  clear need for the provider and the (possibly new) stewards are able to maintain it actively on this go around.
+  It should be noted that significant effort may be required to resurrect a provider from the attic.
 
 **Mature Providers**
 
diff --git a/providers/MANAGING_PROVIDERS_LIFECYCLE.rst b/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
index 21767607d6e7b..e56c98537b0ad 100644
--- a/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
+++ b/providers/MANAGING_PROVIDERS_LIFECYCLE.rst
@@ -28,16 +28,16 @@ yourself with the governance framework that applies to all community providers:
 
 Key governance concepts:
 
-* **Lifecycle stages**: Providers move through the following lifecycle stages: Incubation → Production → Attic/Deprecation. To be precise, 
-  not all providers will move through all stages. 
-* **Stewardship**: Each provider requires at least two stewards (who don't have to be Airflow Committers themselves) 
+* **Lifecycle stages**: Providers move through the following lifecycle stages: Incubation → Production → Attic/Deprecation. To be precise,
+  not all providers will move through all stages.
+* **Stewardship**: Each provider requires at least two stewards (who don't have to be Airflow Committers themselves)
 * **Health metrics**: Quantitative criteria determine readiness for promotion or deprecation
 * **Periodic reviews**: The PMC reviews provider health quarterly
 
 All new providers must start in the **Incubation** stage (unless specifically accelerated by the PMC)
-and meet the graduation criteria before moving to Production status. 
-Existing providers will by default start in the Production stage with the Airflow PMC as stewards, unless 
-stewards have already been identified. 
+and meet the graduation criteria before moving to Production status.
+Existing providers will by default start in the Production stage with the Airflow PMC as stewards, unless
+stewards have already been identified.
 
 Stewardship Requirements for New Providers
 ------------------------------------------

From 0f1b1effd599bbf323afaf9c27c422119c9ba9f8 Mon Sep 17 00:00:00 2001
From: Vikram Koka <vikram@astronomer.io>
Date: Mon, 26 Jan 2026 13:57:51 -0800
Subject: [PATCH 11/12] Update PROVIDERS.rst

Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
---
 PROVIDERS.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/PROVIDERS.rst b/PROVIDERS.rst
index a609c390d2f75..c8392c77be7f2 100644
--- a/PROVIDERS.rst
+++ b/PROVIDERS.rst
@@ -109,7 +109,7 @@ the health criteria described below are met:
 * **Role definition**: Stewards are subject matter experts for the integration. This could be expertise in the
   service being integrated, the language being supported by the provider, or the framework being integrated.
   Stewardship is a responsibility, not an additional authority or privilege
-* **Committer sponsorship**: Each steward must be sponsored by an existing Airflow Committer. The
+* **Committer sponsorship**: Each steward must be sponsored by at least one Airflow Committer. The
   sponsor ensures that stewards fulfill their responsibilities and provides guidance on maintaining the
   provider according to best practices. This includes regular dependency updates, issue resolution, and
   monitoring that the provider meets the health metrics required for its current lifecycle stage (that is, incubation

From d699b444fe86ee75fa52fdd5a11b3e43c6e32d07 Mon Sep 17 00:00:00 2001
From: Vikram Koka <vikram@astronomer.io>
Date: Mon, 26 Jan 2026 13:58:26 -0800
Subject: [PATCH 12/12] Update PROVIDERS.rst

Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
---
 PROVIDERS.rst | 1 +
 1 file changed, 1 insertion(+)

diff --git a/PROVIDERS.rst b/PROVIDERS.rst
index c8392c77be7f2..a48233eb3e8e0 100644
--- a/PROVIDERS.rst
+++ b/PROVIDERS.rst
@@ -115,6 +115,7 @@ the health criteria described below are met:
   monitoring that the provider meets the health metrics required for its current lifecycle stage (that is, incubation
   or production). The sponsor is responsible for PR reviews and merges (including ensuring coding standards are met), but
   is NOT responsible for active maintenance of the provider's codebase, which remains the responsibility of the stewards.
+  While sponsors should be accountable when it comes to reviews and merges, it's also OK and welcome that other committers merge code providing it fulfill the criteria.
 * **Accountability**: Ultimate accountability remains with the Airflow PMC and Committers
 * **Transitions**: Neither sponsorship nor stewardship are roles in perpetuity; they can be
   transitioned to others based on mutual agreement and PMC approval
