Thanks, Jarek! The latest version looks good to me! Best, Wei
Jarek Potiuk <[email protected]> 於 2026年2月25日週三 下午5:57寫道： > 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. > > > >> > > > > > > > > > >
