Just a reminder: the proposal has undergone a few refinements. These changes clarified some statements without altering the substance. I believe it is good as-is now, and I will let the lazy consensus continue until Monday as planned. Please raise any objections if you have some.
The PR is here: https://github.com/apache/airflow/pull/62417 On Wed, Feb 25, 2026 at 10:10 AM Wei Lee <[email protected]> wrote: > 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. > > > > >> > > > > > > > > > > > > > > >
