Background

As of today, we deal with the following tpyes of releases:

• Airflow core
  • Python Client (derived from core)
• Task SDK
• Providers
• Airflow CTL
• Helm Chart

Problem definition

As of Jan. 2026:

1. The current division of GitHub Issues to categories:

1. 1. Overwhelms the average user due to many categories

   2. Does not fully cover all existing release types

   3. Does not scale well to support additional release types from a UI/UX perspective
      

      Release Type X [feature,bug] + Docs + Task & Meta + external links >= 25 categories

2. Additionally, many issue types include unnecessary mandatory or extra fields, which:
   

   1. Overwhelm users due to the number of required fields

   2. Increase maintenance burden because of significant code duplication

Figure 1 - Current "Create new issue" window

Proposal

This proposal suggests restructuring GitHub Issues, inc. both categories and fields, to improve UI/UX while accommodating current and future requirements.

To simplify issue reporting for end users, it is proposed to base the initial categorization solely on release type (with some unions where appropriate), following the scheme outlined below.

Since there is already automation in place that labels GitHub issues as bug or feature request, introducing a secondary manual categorization by bug/feature provides little to no additional value, given that final classification often changes during triage and reported bugs frequently reflect intended behavior or incomplete features.

Ultimately, the final classification should be determined by the triager, though user input may still be considered helpful where relevant.

Things to consider

Removal of "Docs" section

The “Docs” section should be considered for removal for the following reasons:

• Documentation issues are generally the easiest to quickly resolve, especially with the assistance of LLMs.

• With over 1.4K open issues, this section adds load for triagers and tends to mask more critical issues.

• Docs issues could instead be reported under the regular issue types; making the reporting process slightly more demanding may encourage contributors to implement fixes themselves.

Removal of "Ask a question or get support"/"Questions on Stack Overflow" section

These sections should be considered for removal for UI/UX reasons:

• Support and discussion channels are already discoverable from the main repository.

• Platforms such as Stack Overflow are widely known and complemented by LLM-based assistance.

• Including these options in the issue creation flow adds unnecessary complexity and increases cognitive load for users.

Suggested Issue Scheme

Airflow Core & Providers* (+ Task SDK & Python Client**)

• Airflow version (required), choice between:

  • Latest stable (e.g., 3.1.6)

  • Main (development)

  • Other Airflow 3 version (with input field to specify which)

• If “Other Airflow 3 version” is selected, which one? (optional)

• Providers (optional), input for relevant provider(s) and their version(s)

• How would you consider this issue? Choice between: N/A, Bug or Feature Request (or Docs?)

• Current behavior (required)
  Includes background details, reproduction steps, and logs for alleged bugs

• Desired behavior (required)
  Includes usage examples for feature requests

• Deployment (optional), choice between:

  • N/A (default)

  • Official Helm chart

  • Managed service (Astronomer, MWAA, GCC, ADF)

  • Local deployment (Breeze / Docker Compose)

  • Other

• Deployment details (optional)

• Checkboxes (both checked by default to encourage action from the reporter):

  • Are you willing to submit a PR?

  • Code of Conduct

Other / Open Questions

• Airflow CTL (Buğra Öztürk ) - ?

• Helm Chart (Unknown User (jedcunningham) ) - ?

• Task and Meta (Maintainers only)

• Report a security vulnerability

* Current description should be shortened
** Omitted for brevity; the description should be added later

Illustration of the suggested "Create new issue"

Figure 2 - Suggested "Create new issue" window