Generally the proposal looks good but I would adapt it slightly. Mostly because (and this has been also a theme at many community talks and discussions in FOSDEM) - some "healthy" friction when creating issues, prs, reports - is a good idea, when it is too easy to create them, people start misusing them. So two things:
1) if the user "has to" check the box "I agree to followed code of conduct", this is a manual, deliberate action of the user that bears certain accountability - enabling it by default removes that, because essentially the user does not explicitly agreed to the code of conduct - this was not their deliberate action. Similarly "Are you willing to submit a PR?" is unchecked for a reason. If we leave it as default, we cannot reasonably assume that the user wants to help with PR - it might be simply because they left the default. Checking the boxes by default do not encourage deliberate decision of such users, at most some might say they "trick them" into stating they want to submit the PR. Such an approach is often named "dark patterns" in the UI - when you build your UI in the way that it makes decisions for the users rather than give them a chance to decide if they want to make a commitment. So I would leave both check-boxes as they are today. 2) I think links to discussions (not stackoverflow) should stay - because discussions are not very easily discoverable. Since discussions are optional and disabled by default, many GitHub repos have no Discussions visible and many people do not even realize they exist. Having a link directly in the issue showing the users alternative when all they know is "issue creation" is mostly educational and might help to guide people to actually change their mind and open a discussion instead of issue (which in many cases is actually way better for us than opening an issue). I am perfectly fine with other changes. J. On Sat, Jan 31, 2026 at 7:00 PM Shahar Epstein <[email protected]> wrote: > Thanks for posting it Josef! > My intent was to discuss it in an even more broader perspective, as for > what types of GitHub issue templates we need today, and what fields we need > in each. > I hope that it's ok to take this thread in that direction. > > I've outlined a more detailed suggestion on Airflow's wiki: > https://cwiki.apache.org/confluence/x/BYg8G > > tl;dr: > - Primary categorization of reportable issues by release type, with some > unions: > - Airflow & Providers (& Task SDK & Python Client, omitted from title > from brevity) > - CTL > - Helm Charts > - Removal of secondary categorization by "issue type" (feature/bug) > - Removal of "docs" issues (see reasonings and alternatives in the > proposal) > - Removal of external links to "Discussions" and "Stackoverflow" > - *In Airflow & Providers* - Reducing the number of required fields to 3 > > > I'll be happy with Buğra & Jed's perspectives specifically regarding > optimizations in fields of CTL and helm charts, > and I'll appreciate everyone's feedback regarding my proposal in general. > > > Shahar > > > On Sat, Jan 31, 2026 at 4:17 PM Josef <[email protected]> wrote: > > > Hi, > > > > > > I'd like to propose simplifying the bug report template by making the > > "Operating System" and "Deployment" fields optional instead of required. > > > > > > Pull Request: https://github.com/apache/airflow/pull/61285 > > > > > > Currently, the bug report template requires 6 fields. This proposal would > > reduce mandatory fields from 6 to 4 by making OS and Deployment optional. > > > > > > Why? > > > > > > - Many core bugs don't depend on deployment method or OS > > > > - Users reporting deployment-specific issues naturally include this info > > > > - Making fields optional doesn't prevent users from providing the info > when > > relevant > > > > > > @shahar1 raised valid concerns about losing/missing diagnostic > information, > > particularly for managed services (like Cloud Composer). I proposed > adding > > help text to explain when these fields are important rather than keeping > > them required at all times. > > > > > > Would appreciate your thoughts on this approach. > > > > > > Thanks, > > > > Josef > > >
