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