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 > > >> > >> > > > > > > > >> > >> > > > > > > >> > >> > > > > > >> > >> > > > > >> > >> > > > >> > >> > > >> > > > > >> > > > >> > > > > > >
