The PR for airflowctl issue template is ready for review - https://github.com/apache/airflow/pull/64327.
Best regards, Shrividya Hegde On Fri, Mar 27, 2026 at 2:22 PM Buğra Öztürk <[email protected]> wrote: > Sorry for joining late! Thanks Shri! > I have checked the applied simplification and the new changes > that consolidate the templates. They look good and align with the proposed > approach in the Confluence. > Great work! Looking forward to seeing Airflow CTL :) > > Kind regards, > Bugra Ozturk > > > On Thu, Mar 26, 2026 at 8:47 PM Shrividya Hegde < > [email protected]> > wrote: > > > The conflicts have been resolved and the PR( > > https://github.com/apache/airflow/pull/64240) is now ready for review. > > I'm working on the Airflow CTL templates which we currently do not have > in > > place. That would be worked on as a separate PR. > > > > Thanks and regards, > > Shrividya Hegde > > > > On Thu, Mar 26, 2026 at 1:11 AM Rahul Vats <[email protected]> > wrote: > > > > > Thanks, Shri. Great work! I noticed some conflicts in > > > https://github.com/apache/airflow/pull/64240. Could you please resolve > > > them > > > and mark the PR as ready for review? > > > > > > Regards, > > > Rahul Vats > > > > > > > > > > > > On Thu, 26 Mar 2026 at 10:36, Shrividya Hegde < > > [email protected] > > > > > > > wrote: > > > > > > > Hi Everyone, > > > > > > > > Thank you all for your valuable insights throughout this thread. > > > > > > > > I have two updates to share: > > > > > > > > 1. The PR for bug report simplification ( > > > > https://github.com/apache/airflow/pull/63851) has been successfully > > > > merged. > > > > 2. I have drafted a follow-up PR ( > > > > https://github.com/apache/airflow/pull/64240) incorporating a few > > > changes > > > > proposed by Shahar in this thread, with some slight modifications to > > the > > > > approach. > > > > > > > > The proposed changes include: > > > > • Consolidation of multiple issue types under a single issue template > > > with > > > > defined categories and values (as per applicability) > > > > • Removal of redundant fields across the multiple templates > > > > • Removal of the doc issue template > > > > • File name updates across pre-commit YAMLs and > > > > `prek/check_airflow_bug_report_template.py` > > > > > > > > I welcome any feedback and am open to making modifications based on > the > > > > discussion here. Please feel free to leave comments directly on the > PR > > or > > > > share your thoughts in this thread. > > > > > > > > Thanks and Regards, > > > > Shrividya Hegde > > > > > > > > On Mon, Mar 23, 2026 at 3:45 PM Shrividya Hegde < > > > > [email protected]> > > > > wrote: > > > > > > > > > Hey Jarek, > > > > > > > > > > I feel this is a perfect middle ground. The placeholder text , > *"Run > > > > > `airflow version` and paste the output here"* does all the heavy > > > lifting > > > > > of guiding the reporters to the exact command they need without too > > > much > > > > > hand holding while it keeps just enough friction (they have to go > run > > > it > > > > > themselves) while removing the ambiguity of finding the right > > version . > > > > > Clean field, zero clutter, and we get the real version string from > > > their > > > > > actual environment rather than a dropdown guess. > > > > > > > > > > Happy to implement this if the rest of the community is aligned! > > > > > > > > > > Thanks, > > > > > Shrividya Hegde > > > > > > > > > > On Mon, Mar 23, 2026 at 2:24 AM Jarek Potiuk <[email protected]> > > wrote: > > > > > > > > > >> > but GitHub issue form YAML is static and doesn't support > > conditional > > > > >> field visibility natively. > > > > >> > > > > >> Ha.. So it hasn't changed :) . I remember also wanting it badly :) > > > > >> > > > > >> > I also explored dynamically generating version options as a > > > dropdown, > > > > >> but > > > > >> that felt like it would add more complexity than it removes, which > > > works > > > > >> against this PR's simplification goal. > > > > >> > > > > >> Actually that might be a good idea with a pre-K hook; however, we > > > still > > > > >> want some friction. One way I saw other projects handle similar > > > > situations > > > > >> was to add a small amount of friction while still being helpful: > ask > > > the > > > > >> user to generate the version. For example in the hint for the > other > > > > field > > > > >> (the gray text displayed until you click it) we can state > something > > > > like: > > > > >> "Run `airflow version` and copy & paste the output."". On one > hand, > > it > > > > >> creates some friction (because you need to switch context and, > > instead > > > > of > > > > >> selecting a version in the form you need to figure out how to run > > > > >> Airflow). > > > > >> On the other hand, it's helpful suggestion that tells you exactly > > how > > > > you > > > > >> find out the version. > > > > >> > > > > >> J. > > > > >> > > > > >> On Mon, Mar 23, 2026 at 1:28 AM Shrividya Hegde < > > > > >> [email protected]> > > > > >> wrote: > > > > >> > > > > >> > Hi all, > > > > >> > > > > > >> > I've retained the Airflow version field in the PR as-is for now. > > > > >> Ideally, > > > > >> > we'd conditionally hide the "other versions" input once a main > > > version > > > > >> is > > > > >> > selected , but GitHub issue form YAML is static and doesn't > > support > > > > >> > conditional field visibility natively. I also explored > dynamically > > > > >> > generating version options as a dropdown, but that felt like it > > > would > > > > >> add > > > > >> > more complexity than it removes, which works against the > > > > simplification > > > > >> > goal of this PR. > > > > >> > > > > > >> > I plan to revisit this properly while working on unifying the > core > > > and > > > > >> > providers bug report templates , as that feels like the right > > scope > > > to > > > > >> > address it holistically. In the meantime, I'd welcome any ideas > > from > > > > the > > > > >> > community on handling this elegantly within GitHub's YAML > > > constraints. > > > > >> > > > > > >> > Thanks, > > > > >> > Shrividya Hegde > > > > >> > > > > > >> > On Sun, Mar 22, 2026 at 11:44 AM Shrividya Hegde < > > > > >> > [email protected]> wrote: > > > > >> > > > > > >> > > Hey Potiuk, > > > > >> > > > > > > >> > > I'm working on it and will commit the changes soon. > > > > >> > > > > > > >> > > Thanks, > > > > >> > > Shrividya Hegde > > > > >> > > > > > > >> > > On Sun, 22 Mar, 2026, 11:08 am Jarek Potiuk, < > [email protected]> > > > > >> wrote: > > > > >> > > > > > > >> > >> > Rahul's conditional field idea makes sense to me: keep the > > > > dropdown > > > > >> > with > > > > >> > >> its nudge toward testing on latest, but only show the exact > > > version > > > > >> text > > > > >> > >> field when "Other" is selected. That reduces visual noise > > without > > > > >> > changing > > > > >> > >> the intent. > > > > >> > >> > > > > >> > >> Not sure if that is possible. > > > > >> > >> > > > > >> > >> On Sun, Mar 22, 2026 at 3:34 PM Shrividya Hegde < > > > > >> > >> [email protected]> > > > > >> > >> wrote: > > > > >> > >> > > > > >> > >> > Thanks for the context on the deliberate friction, that's a > > > fair > > > > >> point > > > > >> > >> and > > > > >> > >> > I hadn't fully considered it. > > > > >> > >> > > > > > >> > >> > Rahul's conditional field idea makes sense to me: keep the > > > > dropdown > > > > >> > with > > > > >> > >> > its nudge toward testing on latest, but only show the exact > > > > version > > > > >> > text > > > > >> > >> > field when "Other" is selected. That reduces visual noise > > > without > > > > >> > >> changing > > > > >> > >> > the intent. > > > > >> > >> > > > > > >> > >> > Happy to update the PR along those lines if it works for > > > > everyone. > > > > >> > >> > > > > > >> > >> > Thanks, > > > > >> > >> > Shrividya Hegde > > > > >> > >> > > > > > >> > >> > On Sun, 22 Mar, 2026, 5:05 am Jarek Potiuk, < > > [email protected]> > > > > >> wrote: > > > > >> > >> > > > > > >> > >> > > Hey Shrividya, > > > > >> > >> > > > > > > >> > >> > > Agree with Rahul here. We deliberately introduced > friction > > - > > > > and > > > > >> > make > > > > >> > >> it > > > > >> > >> > a > > > > >> > >> > > bit "harder" to report issues for older versions - we > even > > > > >> > >> specifically > > > > >> > >> > > "hint" people to check it on the latest version: > > > > >> > >> > > > > > > >> > >> > > > On what 3.X version of Airflow are you currently > > > experiencing > > > > >> the > > > > >> > >> > issue? > > > > >> > >> > > Remember, you are encouraged to > > > > >> > >> > > > test with the latest release or on the `main` branch to > > > > verify > > > > >> > your > > > > >> > >> > issue > > > > >> > >> > > still exists, especially if > > > > >> > >> > > > your version is at least a minor version older than the > > > > >> [current > > > > >> > >> stable > > > > >> > >> > > release]( > > > > >> > >> > > > > > > >> > >> > > > > > > >> > >> > > > > > >> > >> > > > > >> > > > > > >> > > > > > > > > > > https://airflow.apache.org/docs/apache-airflow/stable/installation/supported-versions.html#version-life-cycle > > > > >> > >> > > ). > > > > >> > >> > > > > > > >> > >> > > And yes - your goal when designing such an interaction > > might > > > > not > > > > >> be > > > > >> > >> "to > > > > >> > >> > > make it easier for the user." In this case our > optimisation > > > > goal > > > > >> is > > > > >> > to > > > > >> > >> > make > > > > >> > >> > > things deliberately harder, when you want user to at > least > > be > > > > >> aware > > > > >> > >> that > > > > >> > >> > > there is potentially another path they could make - > upgrade > > > or > > > > >> check > > > > >> > >> the > > > > >> > >> > > issue. > > > > >> > >> > > That design was deliberately built into the template form > > > and I > > > > >> > think > > > > >> > >> it > > > > >> > >> > > should stay. > > > > >> > >> > > > > > > >> > >> > > You might of course propose another solution for it - but > > > make > > > > >> sure > > > > >> > to > > > > >> > >> > > target the goal > > > > >> > >> > > > > > > >> > >> > > J. > > > > >> > >> > > > > > > >> > >> > > > > > > >> > >> > > > > > > >> > >> > > On Sun, Mar 22, 2026 at 9:32 AM Rahul Vats < > > > > >> [email protected]> > > > > >> > >> > wrote: > > > > >> > >> > > > > > > >> > >> > > > Thanks Shrividya! > > > > >> > >> > > > > > > > >> > >> > > > On version awareness, most users are data engineers and > > in > > > my > > > > >> > >> > experience, > > > > >> > >> > > > triaging issues, they generally know the version > against > > > > which > > > > >> bug > > > > >> > >> is > > > > >> > >> > > being > > > > >> > >> > > > raised. I have not really come across cases where > someone > > > > >> picked > > > > >> > the > > > > >> > >> > > wrong > > > > >> > >> > > > version because they were unsure. > > > > >> > >> > > > On the "Other Airflow 3 version" option, I think the > > intent > > > > >> was to > > > > >> > >> keep > > > > >> > >> > > the > > > > >> > >> > > > dropdown from growing too long as new patch versions > are > > > > >> released, > > > > >> > >> > rather > > > > >> > >> > > > than a sign that the dropdown is not solving the > > problem. A > > > > >> > curated > > > > >> > >> > list > > > > >> > >> > > > actually makes it easier for reporters to pick the > right > > > > value > > > > >> > >> quickly. > > > > >> > >> > > > > > > > >> > >> > > > I think the other changes in this PR are solid. Merging > > > "What > > > > >> > >> happened" > > > > >> > >> > > and > > > > >> > >> > > > "How to reproduce" makes a lot of sense, and making OS > > and > > > > >> > >> deployment > > > > >> > >> > > > optional is a good call. My concern is specifically > > around > > > > the > > > > >> > free > > > > >> > >> > form > > > > >> > >> > > > text field, but happy to listen to other opinions as > well > > > > >> > >> > > > > > > > >> > >> > > > Thanks, > > > > >> > >> > > > Rahul > > > > >> > >> > > > > > > > >> > >> > > > On Sun, 22 Mar 2026 at 12:10, Shrividya Hegde < > > > > >> > >> > > [email protected] > > > > >> > >> > > > > > > > > >> > >> > > > wrote: > > > > >> > >> > > > > > > > >> > >> > > > > Thanks for the response, Rahul! > > > > >> > >> > > > > > > > > >> > >> > > > > I get the reasoning behind the two-field setup, but I > > > think > > > > >> the > > > > >> > >> > version > > > > >> > >> > > > > confusion problem exists with a dropdown too. A > > reporter > > > > who > > > > >> > >> doesn't > > > > >> > >> > > know > > > > >> > >> > > > > their exact version might just pick "3.x latest" even > > if > > > > >> they're > > > > >> > >> on > > > > >> > >> > an > > > > >> > >> > > > > older release. The issue is that they don't know > their > > > > >> version, > > > > >> > >> not > > > > >> > >> > how > > > > >> > >> > > > > they're entering it. > > > > >> > >> > > > > > > > > >> > >> > > > > Also, having "Other Airflow 3 version" as an option > in > > > the > > > > >> > >> dropdown > > > > >> > >> > is > > > > >> > >> > > a > > > > >> > >> > > > > bit of a hint that the dropdown isn't really solving > > the > > > > >> problem > > > > >> > >> on > > > > >> > >> > its > > > > >> > >> > > > > own. > > > > >> > >> > > > > > > > > >> > >> > > > > A simple text field with a placeholder like `e.g. > > 3.1.8` > > > > does > > > > >> > the > > > > >> > >> > same > > > > >> > >> > > > job > > > > >> > >> > > > > with one less field, which is kind of the whole point > > of > > > > this > > > > >> > PR. > > > > >> > >> > > > > > > > > >> > >> > > > > That said, if the group prefers keeping some > structure, > > > the > > > > >> > >> > conditional > > > > >> > >> > > > > field idea you mentioned is a good middle ground. > > > > >> > >> > > > > > > > > >> > >> > > > > +1 on unifying the core and providers templates too! > > > > >> > >> > > > > > > > > >> > >> > > > > On Sun, 22 Mar, 2026, 2:24 am Rahul Vats, < > > > > >> > [email protected] > > > > >> > >> > > > > > >> > >> > > > wrote: > > > > >> > >> > > > > > > > > >> > >> > > > > > Thanks for raising this, Shrividya. I am totally in > > > favor > > > > >> of > > > > >> > >> > > > simplifying > > > > >> > >> > > > > > templates. > > > > >> > >> > > > > > > > > > >> > >> > > > > > One thing I wanted to clarify on the current > > two-field > > > > >> setup: > > > > >> > >> the > > > > >> > >> > > > > dropdown > > > > >> > >> > > > > > covers the common versions (2.x, 3.x latest, main), > > and > > > > the > > > > >> > >> > secondary > > > > >> > >> > > > > text > > > > >> > >> > > > > > field is there for users who pick "Other Airflow 3 > > > > >> version" so > > > > >> > >> they > > > > >> > >> > > are > > > > >> > >> > > > > not > > > > >> > >> > > > > > really redundant, they serve different purposes. > > > > >> > >> > > > > > > > > > >> > >> > > > > > My hesitation with a fully free-text field is the > > > version > > > > >> > >> format. > > > > >> > >> > > > 3.1.8, > > > > >> > >> > > > > > v3.1.8, airflow 3.1.8, 3.1 are all valid ways > someone > > > > might > > > > >> > type > > > > >> > >> > the > > > > >> > >> > > > same > > > > >> > >> > > > > > version. The placeholder added in the PR helps, but > > it > > > > does > > > > >> > not > > > > >> > >> > > > enforce a > > > > >> > >> > > > > > format. One thing worth exploring: can the "If > Other > > > > >> Airflow 3 > > > > >> > >> > > version > > > > >> > >> > > > > > selected, which one?" field be shown conditionally > > only > > > > >> when > > > > >> > >> "Other > > > > >> > >> > > > > Airflow > > > > >> > >> > > > > > 3 version" is selected in the dropdown? That would > > > reduce > > > > >> the > > > > >> > >> > visual > > > > >> > >> > > > > noise > > > > >> > >> > > > > > without losing the structure we have today. > > > > >> > >> > > > > > > > > > >> > >> > > > > > Also +1 to Shahar's idea of unifying the core and > > > > providers > > > > >> > bug > > > > >> > >> > > report > > > > >> > >> > > > > > templates. That feels like the bigger > simplification > > > win > > > > in > > > > >> > >> > reducing > > > > >> > >> > > > the > > > > >> > >> > > > > > current template count. > > > > >> > >> > > > > > > > > > >> > >> > > > > > Thanks, > > > > >> > >> > > > > > Rahul > > > > >> > >> > > > > > > > > > >> > >> > > > > > > > > >> > >> > > > > > > > >> > >> > > > > > > >> > >> > > > > > >> > >> > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > > > > > >
