> "There is no guarantee if or when this issue will be resolved if it is left to others." (or something alike).
Good idea. Possibly I would phrase it differently - and in a positive way. Smth alongside - "Helping to fix the issue - or finding someone who will - is the fastest way to address it. Airflow is largely a volunteer community, so someone should volunteer to fix each issue". Maybe someone can phrase it a bit shorter. On Tue, Feb 3, 2026 at 5:57 PM Shahar Epstein <[email protected]> wrote: > 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 > > > > > > > > > >
