Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Approval Type

Definition

Consensus

Consensus requires 3 binding +1 votes and no binding vetoes.

Lazy Majority

A lazy majority vote requires 3 binding +1 votes and more binding +1 votes than -1 votes.

Lazy Approval

An action with lazy approval is implicitly allowed unless a -1 vote is received, at which time, depending on the type of action, either lazy majority or consensus approval must be obtained.

2/3 Majority

Some actions require a 2/3 majority of active committers or PMC members to pass. Such actions typically affect the foundation of the project (e.g. adopting a new codebase to replace an existing product). The higher threshold is designed to ensure such changes are strongly supported. To pass this vote requires at least 2/3 of binding vote holders to vote +1.

In order to address the case of insufficient active binding voters to reach 2/3 majority, one can follow the process below to exclude a binding vote from the counting of this particular voting thread. 

  1. Wait until the minimum length of the voting passes.
  2. Publicly reach out to the remaining binding voters in the voting mail thread for at least 3 attempts with at least 7 days between two attempts.
  3. If the binding voter being contacted still failed to respond after all the attempts, the binding voter will be considered as inactive for the purpose of this particular voting.

...

Actions

Description

Approval

Binding Votes

Minimum Length (days)

Mailing List

Code Change

A change made to a codebase of the project and committed by a committer. This includes source code, documentation, website content, etc.

one +1 from a committer followed by a Lazy approval (not counting the vote of the contributor), moving to lazy majority if a -1 is received

Active committers

0

JIRA or Github Pull Request (with notification sent to dev@flink.apache.org)

FLIP (Major Change)

A major change to the codebase that meets the FLIP criteria.

ConsensusActive committers3dev@flink.apache.org

Release Plan

Defines the timetable and actions for a release. The plan also nominates a Release Manager.

Lazy majority

Active committers

3

dev@flink.apache.org

Product Release

When a release of one of the project's products is ready, a vote is required to accept the release as an official release of the project.

Lazy Majority

Active PMC members

3

dev@flink.apache.org

Adoption of New Codebase

Adoption of new external projectslarge existing external codebase. These contributions are usually big enough to take many FLIPs to contribute, and will potentially change the shape and direction of the project with massive restructuring.

2/3 majority

Active PMC members

6

dev@flink.apache.org

New Committer

When a new committer is proposed for the project.

Consensus

Active PMC members

3

private@flink.apache.org

New PMC Member

When a committer is proposed for the PMC.

Consensus

Active PMC members

3

private@flink.apache.org

Committer Removal

When removal of commit privileges is sought.
Note: Such actions will also be referred to the ASF board by the PMC chair.

Consensus

Active PMC members (excluding the committer in question if a member of the PMC).

6

private@flink.apache.org

PMC Member Removal

When removal of a PMC member is sought.
Note: Such actions will also be referred to the ASF board by the PMC chair. See PMC Member Change Process for details.

Consensus

Active PMC members (excluding the member in question).

6

private@flink.apache.org

Modifying Bylaws

Modifying this document.

2/3 majority

Active PMC members

6

dev@flink.apache.org

...