The following page is based on a discussion in May 2020 and more importantly another discussion in March 2021, the community agreed on the following definitions for the fields in the FLINK Jira project.


  • clearer communication and expectation management with the community
    • a user or contributor should be able to judge the urgency of a ticket by its priority
    • if a ticket is assigned to someone the expectation that someone is working on it should hold
  • generally reduce noise in Jira
  • reduce overhead of committers to ask about status updates of contributions or bug reports
    • “Are you still working on this?”
    • “Are you still interested in this?”
    • “Does this still happen on Flink 1.x?”
    • “Are you still experiencing this issue?”
    • “What is the status of the implementation”?
  • while still encouraging users to add new tickets and to leave feedback about existing tickets


Issue Types

Bug - bug or vulnerability

Improvement - improvement to existing functionality

New Feature - a new feature

Technical Debt - almost always non-end user facing, hence can be ignored by end users. Necessary refactorings, improvements & clean up that should have happened as part of feature development, but did not.

Tickets Priorities

Blocker - infrastructure failures, bugs that block us from releasing

Critical  - test instabilities, security related issues, important components is non-functional for important use case

Major (default) - typical feature requests, bug that affects some use cases

Minor - nice to have feature requests, wishes, not necessarily under active development or discussion, catch all

Not a Priority - stale feature request or bug report 

Tickets (except Not a Priority) need an assignee or an active public discussion otherwise their priority is slowly reduced up to "Not a Priority" automatically by the flink-jira-bot


Only Bugs can be Blocker/Critical.


Primary component relevant for this feature / fix.
For test-related issues, add the component the test belongs to (for example "Connectors / Kafka" for Kafka test failures) + "Tests".
The same applies for documentation tickets. For example, if there's something wrong with the DataStream API, add it to the "API / DataStream" and "Documentation" components.


Affects Version/s:

Only for Bug / Task-type tickets: We list all currently supported and unreleased Flink versions known to be affected by this.

Example 1: If I see a test failure that happens on "master" and "release-1.11", I set "affects version" to "1.12.0" and "1.11.0".
Example 2: If a bug is found in Flink 1.8.1, it "Affects Version/s": 1.8.1, 1.9.3, 1.10.0 (this example assumes 1.9.3 to be the last stable 1.9.x release, and 1.10. to be unreleased)

Fix Version/s:

For closed/resolved tickets, this field lists the released Flink versions that contain a fix or feature for the first time. Note, if an issue is fixed in "1.11.0", then this fix is implicitly included in "1.12.0" as well. This rule does not apply to 1.11 releases after 1.11.0 (e.g 1.11.x where x >= 1).

For open tickets, it indicates that a fix / feature should be contained in the listed versions. Only blocker issues can block a release, all other tickets which have "fix version/s" set at the time of a release and are unresolved will be moved to the next version.


Person currently working on the ticket. Assigned after conclusion on approach by a committer. Assigned tickets need a regular update otherwise they are automatically unassigned by the flink-jira-bot.
Often, fixes are obvious and committers self-assign w/o discussion.

Resolve / Close

You can either Resolve or Close a ticket once it is done (fixed, rejected, invalid, ...).

As a rule, we Close tickets instead of Resolving them when they are done.


test-stabilityTest stability issues that cause our CI to fail.
starterJira issues that can be picked up by contributors that are not necessarily familiar with Flink-internals, yet, but want to contribute.
usabilityLabels Jira issues that cover improvements in usability of Flink
release-testingLabels Jira issues that are created as part of the release testing phase at the end of a Major/Minor release cycle


A Blocker ticket without an assignee or public discussion. It is about to become  "auto-deprioritized-blocker" by the flink-jira-bot.


A Critical ticket without an assignee or public discussion. It is about to become  "auto-deprioritized-critical" by the flink-jira-bot.


A Major ticket without an assignee or public discussion. It is about to become  "auto-deprioritized-major" by the flink-jira-bot.


A Minor ticket without an assignee or public discussion. It is about to become  "auto-deprioritized-minor" by the flink-jira-bot.


A Blocker ticket that has automatically been moved to Critical by the flink-jira-bot.


A Critical ticket that has automatically been moved to Major by the flink-jira-bot.


A Major ticket that has automatically been moved to Minor by the flink-jira-bot.


A Minor ticket that has automatically been closed by the flink-jira-bot.


A Major+ ticket that is assigned but has not received an update for some time. It is about to become "auto-unassigned" by the flink-jira-bot.

A Major+ ticket that has been automatically unassigned by the flink-jira-bot.

Release Note IMPORTANT

The release notes for a release are composed of the release notes of each of the tickets. Keep it brief, but documented important changes, specifically breaking ones.


  • All other fields are not used not used on a regular basis.
  • Tickets relating to the Project Website do not have an "Affects" or "Fix" version. Flink-statefun and flink-shaded have their own versions.

Flink Jira Bot 

The Flink Jira Bot is located in and it is run on a daily basis via GitHub Actions. 

The rules that is enforces are documented in detail in its repository:

  • No labels


  1. Should we move this page one level up?

  2. Let's move it up one layer and then list it under infrastructure on the home page.