Community escalation process

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.

Scope

Behaviours that may lead to escalation include (but are not limited to):

• Code of Conduct violations — harassment, personal attacks, discriminatory behaviour, or any other conduct that breaches the ASF Code of Conduct.
• Spamming the project — opening low-quality or duplicate issues and PRs in bulk, mass-pinging maintainers, or posting promotional, off-topic, or unsolicited content on GitHub, the mailing lists, Slack, the CWiki, or any other project channel.
• Repeatedly disregarding maintainer feedback — for example, reopening the same PR after closure with no substantive change, or continuing to bypass project quality criteria after being asked to stop. The general PR quality bar is described in Pull request quality criteria.
• Submitting unvetted Gen-AI-generated content — the specific expectations around generative-AI-assisted contributions are described in Gen-AI Assisted contributions; the escalation steps that follow when those expectations are ignored are the ones described here.
• Conduct that violates GitHub's Terms of Service — for example, evading prior blocks, automated abuse, or coordinated harassment.
• Being generally and persistently disruptive to the community in ways that are not covered by the categories above but that similarly burden maintainers or other contributors.

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).

Escalation steps

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.

1. 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.).

2. 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.

3. 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.

4. 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.

5. 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.

Appeals — private@airflow.apache.org

Any contributor affected by a decision taken under this process may appeal it by emailing the Apache Airflow PMC at:

private@airflow.apache.org

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:

• Identify the decision being appealed (link to the PR, issue, thread, or block notice where possible).
• Describe the grounds for the appeal — what the decision got wrong, what additional context the PMC should consider, or what has changed since the decision was taken.

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.