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