BTW. Pandas https://github.com/pandas-dev/pandas/issues/62561 and sci-kit https://github.com/scikit-learn/scikit-learn/pull/31568 also stopped doing assignments for exactly the same reasons we did.
On Mon, Mar 2, 2026 at 8:14 PM Jarek Potiuk <[email protected]> wrote: > Lazy consensus passed. > > On Sat, Feb 28, 2026 at 12:01 PM Jarek Potiuk <[email protected]> wrote: > >> I am merging the PR now - before the lazy consensus passes, to be better >> prepared to run unassignment and link to the new policy in comments when it >> happens. >> >> On Fri, Feb 27, 2026 at 12:57 AM Jarek Potiuk <[email protected]> wrote: >> >>> 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. >>>> > > > >> >>>> > > > > >>>> > > > >>>> > > >>>> > >>>> >>>
