Thanks for the detailed feedback Jarek! The reason that I've even thought of these "dark patterns" is that often people expect that just opening issues will actually solve their problem in a short time. I agree that "tricking" them is probably not the best way to achieve it, and for most of the time it will mask the real intentions of the author - so I'm ok with leaving both checkboxes as they are. Maybe, instead, we could add in parentheses near the first checkbox something like "There is no guarantee if or when this issue will be resolved if it is left to others." (or something alike). WDYT? In the meanwhile, I'll update the proposal according to the above. More opinions will be appreciated so I could proceed with a lazy consensus :)
Shahar On Mon, Feb 2, 2026, 17:13 Jarek Potiuk <[email protected]> wrote: > 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 > > > > > >
