COMMUNITY_ESCALATION.md
This document describes how the Apache Airflow community responds when a contributor's behaviour repeatedly imposes an unreasonable burden on maintainers or the wider community — for example, Code of Conduct breaches, spamming project channels, abusing project resources, or sustained disruption that the normal review and mentoring process cannot resolve.
It complements the Code of Conduct, which sets the standards of behaviour expected from everyone interacting with the project. The Code of Conduct says what is expected; this document describes what happens when those expectations are repeatedly ignored, and how affected contributors can appeal a decision.
Behaviours that may lead to escalation include (but are not limited to):
This document is not about ordinary disagreements, slow PRs, or contributions that simply need more work — those are handled through normal review and mentoring (see How to communicate and Pull request guidelines).
The community applies the minimum necessary measure at each step. The goal is to protect maintainer time and the health of the project, not to punish contributors. A contributor who acknowledges feedback and changes their behaviour is welcomed to continue contributing at any point in this sequence.
Direct feedback by maintainers. A maintainer points out the problem on the PR, issue, mailing list thread, or Slack message and links to the relevant guideline (Code of Conduct, Gen-AI guidelines, PR quality criteria, communication guidelines, etc.).
Closing PRs or locking threads. If the behaviour persists, maintainers may close one or more of the contributor's open PRs or lock conversations that have become unproductive. When a contributor accumulates multiple PRs flagged for the same problem, maintainers may close all of that contributor's open PRs at once to avoid repeated review burden. Each closure or lock is accompanied by a comment pointing to the violated guideline so the contributor knows what to fix.
PMC-level blocking from the project. If the behaviour continues after the previous steps, PMC members may decide to block the contributor from making further contributions to the Apache Airflow project. Such a block is a last-resort measure to protect the project from sustained harm and to avoid overburdening maintainers. The decision is taken as a LAZY CONSENSUS among PMC members on the private PMC list, so that it is collectively agreed, not vetoed, and recorded in the Apache Software Foundation's archives.
ASF Infrastructure / cross-project block. In extreme cases — for example, behaviour that affects multiple ASF projects or evasion of an Airflow-level block — the PMC may request the ASF Infrastructure team to block the contributor at the organisation level, across all ASF projects.
Reporting to GitHub. If a contributor is evidently spamming the project, evading prior blocks, or otherwise breaching GitHub's Terms of Service, maintainers may report the account to GitHub. GitHub may then take its own action, which can include suspending or deleting the account.
A separate, parallel path applies specifically to Code of Conduct violations: anyone observing such behaviour can — and is encouraged to — also follow the ASF reporting guidelines directly, independently of the steps above.
[email protected]Any contributor affected by a decision taken under this process may appeal it by emailing the Apache Airflow PMC at:
This is the appropriate appeal channel for all escalation decisions described in this document — including PR closures, project-level blocks, and infrastructure-level block requests.
When sending an appeal, please:
Appeals are reviewed by the PMC on the private list and the outcome is communicated back to the contributor. The PMC may uphold the original decision, modify it, or reverse it.
For Code of Conduct matters, contributors also retain the separate right to escalate to the ASF Conduct Committee as described in the ASF Code of Conduct.