This document is aimed to clarify how we should operate as a healthy community.

Coordination and communication

For ambitious efforts around the core of Airflow:

Have a design document hence have a soft lock on the area as in people are aware that you are working on this core area of Airflow. Solicit this through the dev-list.
Not all the work can have a meaningful design document in the beginning sometimes you have to get your hands on the code. In these cases the PRs can be accepted as design documents. However be ready to have the PR to be rejected as easily as a design document.
Folks who are undertaking work in the core has to make sure appropriate unit and end to end tests are available if not the scope should include creation of those.

Get PR reviews and approval from at least 1 committer, ideally 2 committers if the change touches the core. Do not merge-then-review.
All PRs need to have a committer champion it to be reviewed and merged.
We should feel comfortable saying No on the non-priority improvements.

Releases should be community driven.

We are hoping that committers can release together until we have better coverage as far as integration testing and unit testing, and a dedicated infrastructure to run those tests so before releases.
For all changes to the core in particular, if there is not enough unit and end to end testing, the committer should cherry pick that change into their branch and run in their production.