Add description of the provider suspension process

README.md

@@ -404,6 +404,8 @@ might decide to add additional limits (and justify them with comment)
 
 ## Release process for Providers
 
+### Minimum supported version of Airflow
+
 Providers released by the community (with roughly monthly cadence) have
 limitation of a minimum supported version of Airflow. The minimum version of
 Airflow is the `MINOR` version (2.2, 2.3 etc.) indicating that the providers
@@ -424,6 +426,8 @@ will be able to use the new version without breaking their workflows. When we up
 2.2+, our approach was different but as of 2.3+ upgrade (November 2022) we only bump `MINOR` version of the
 provider when we increase minimum Airflow version.
 
+### Mixed governance model
+
 Providers are often connected with some stakeholders that are vitally interested in maintaining backwards
 compatibilities in their integrations (for example cloud providers, or specific service providers). But,
 we are also bound with the [Apache Software Foundation release policy](https://www.apache.org/legal/release-policy.html)
@@ -473,6 +477,38 @@ of the contributors to perform the cherry-picks and carry-on testing of the olde
 The availability of stakeholder that can manage "service-oriented" maintenance and agrees to such a
 responsibility, will also drive our willingness to accept future, new providers to become community managed.
 
+### Suspending releases for providers
+
+In case a provider is found to require old dependencies that are not compatible with upcoming versions of
+the Apache Airflow or with newer dependencies required by other providers, the provider's release
+process can be suspended.
+
+This means:
+
+* The provider's status is set to "suspended"
+* No new releases of the provider will be made until the problem with dependencies is solved
+* Sources of the provider remain in the repository for now (in the future we might add process to remove them)
+* No new changes will be accepted for the provider (other than the ones that fix the dependencies)
+* The provider will be removed from the list of Apache Airflow extras in the next Airflow release
+  (including patch-level release if it is possible/easy to cherry-pick the suspension change)
+* Tests of the provider will not be run on our CI (in main branch)
+* Dependencies of the provider will not be installed in our main branch CI image nor included in constraints
+* We can still decide to apply security fixes to released providers - by adding fixes to the main branch
+  but cherry-picking, testing and releasing them in the patch-level branch of the provider similar to the
+  mixed governance model described above.
+
+The suspension may be triggered by any committer after the following criteria are met:
+
+* The maintainers of dependencies of the provider are notified about the issue and are given a reasonable
+  time to resolve it (at least 1 week)
+* Other options to resolve the issue have been exhausted and there are good reasons for upgrading
+  the old dependencies in question
+* Explanation why we need to suspend the provider is stated in a public discussion in the devlist. Followed
+  by LAZY CONSENSUS or VOTE (with the majority of the voters agreeing that we should suspend the provider)
+
+The suspension will be lifted when the dependencies of the provider are made compatible with the Apache
+Airflow and with other providers.
+
 ## Contributing
 
 Want to help build Apache Airflow? Check out our [contributing documentation](https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst).