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