Thanks for the feedback -> I attempted to address it in new push: * Discussion comment is softened now. I think it would be great if more maintainers participated in discussions, but it's not **strictly** necessary. A lot of people already use the discussions and discuss with each other - and I think that should be the main purpose: a place where different community members might discuss things - with or without maintainer participation. That should be the big difference vs. issues * I stressed the need for reproducibility in issues/bugs. * We already have mandatory 'steps to reproduce' in the bug template * I also added more about the "maintainer must know the person". - > I think from the discussion it emerged that assignment is something the maintainer originates—the maintainer should reach out to ask if the person wants to be assigned, not the other way around. I think that explains the intention well and might help limit the number of 'I want to be assigned' comments (and better reflects how we would like this to work).
J. On Wed, Feb 25, 2026 at 7:15 AM Wei Lee <[email protected]> wrote: > Love this no-assignment by default policy! > > I do have some concerns about using GitHub Discussion. It's relatively new; > many maintainers and users don't use it often. Maybe a good topic for > another discussion on whether we want to use GitHub Discussions more > heavily. > > A way to mitigate Shahar and Rahul's concerns might be to list what is > expected as a feature or a bug in a GitHub issue. e.g., reproducible steps > for bugs and possible solutions for features (these are the questions we > have in another project). > > Best, > Wei > > > Rahul Vats <[email protected]> 於 2026年2月25日週三 下午2:33寫道： > > > Thanks, Jarek, for bringing this up. I am also aligned with Shahar on > this. > > > > If it is a reproducible bug, users should go ahead and create an issue > with > > clear steps to reproduce. In the case of a new feature request, or if > they > > are not sure whether it’s a bug, we should use Discussions instead of > > creating issues. > > > > Regards, > > Rahul Vats > > > > On Wed, 25 Feb 2026 at 04:02, Shahar Epstein <[email protected]> wrote: > > > > > Thanks for bringing it up Jarek, had my comments on the PR. > > > > > > My main concern is regarding referring people to open GitHub > discussions > > > instead of GitHub issues as a default choice, due to the following > > reasons: > > > 1. It's not really suitable for informing of real reproducible bugs, or > > > suggesting feature requests (if this specifically is a misunserstanding > > of > > > the original intent - I'll be happy if you could clarify that part). > > > 2. Currently it's a dead spot for most of maintainers/triages - we > should > > > agree to show more precense there. Otherwise, the statement > "Discussions > > > are better than issues" is rather null, IMO. > > > > > > Other than that, as I wrote in the previous thread - I'm ok with giving > > it > > > a chance and see how it goes. > > > > > > > > > Shahar > > > > > > > > > > > > > > > On Tue, Feb 24, 2026, 17:52 Jarek Potiuk <[email protected]> wrote: > > > > > >> Following the discussion in > > >> https://lists.apache.org/thread/slgcqs2csn1fngn65g5srrqn8xtsghn7 > > >> > > >> I wanted to propose a Lazy consensus on the change - described in the > PR > > >> here: https://github.com/apache/airflow/pull/62417 > > >> > > >> I tried to capture most of the discussed points, but the PR is not > > >> "final". > > >> I propose we continue discussing any concerns there as comments and > > >> suggestions, and I hope we can agree on the approach and wording. > > >> > > >> It might be helpful to push back against AI-generated content and > people > > >> who somehow treat assignments as a "badge." > > >> > > >> I will keep the PR running until Monday next week (March 2nd, 6 PM > > >> CEST)—hoping we get enough approvals and resolved comments and no > > >> unresolved oppositions (in the form of "request change" or unresolved > > >> comments). > > >> > > >> J. > > >> > > > > > >
