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