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