Hi Kaxil, I’m so sorry for the delayed response! For some reason, your message landed in my spam folder, and I only caught it after seeing Amogh’s reply.
I wanted to say that I 100% agree with you. I think many recent disagreements and discussions stem from the frustration that our "old ways" no longer work in the current environment and we have not yet found a good way to deal with it. This causes a lot of stress and strain as we desperately try to find solutions. And our approaches to finding those solutions often differ wildly. But I personally think if we work "together" on it and leverage the same AI and automation, we can solve it without forgetting that there is always a human on the other end. Prioritizing the "why" and "why not" is such a vital part of the meaningful conversations we should be having as a community. My goal has always been to ensure that experienced maintainers like you, Ash, and Amogh can focus your energy solely on those high-level insights. This is one reason we automate routine feedback—like fixing CI, adding tests, or formatting subjects—so you don't spend your valuable time on them. And yes - I agree and love Ash's review when he asks "why". In many cases it changed, improved, or redirected the proposals—including some security issue implementations—where Ash's knowledge of the code is invaluable, especially when the original solution didn't actually fully fix the problem or solved a different one. And I love those. And act on those - I get to dig deeper and understand—no matter if I use agents to respond or not and put **my own** thinking into words. And this has not changed - this has been the case for years - whether with or without AI, there were often human mistakes, bad assumptions, or misunderstandings of how things work. People sometimes call these hallucinations now, even when humans make them - not AI—but I think it's a really bad name. Those are what they are: mistakes, bad assumptions, misunderstandings how things work By leaning into automation and the triaging efforts I’ve been working on with Magpie, I believe we can reach a point where maintainers only step in when it’s time for those critical architectural questions. I completely agree that holding a high bar is actually very welcoming; it helps contributors grow. What’s truly tough for newcomers is being left in the dark without any feedback at all. And my focus for the next weeks will be moving from "what we want" to "how we achieve it.". While I’ve been building some of the initial scaffolding for this triage process, and yesterday, Magpie was finally established as a Top-Level Project!) Magpie has finally been established as a Top-Level Project - we could expand it to the next step: ensuring we address the "why?questions are actually asked—currently, we have a big number of PRs that don't even have those questions asked. I think our efforts will only succeed if we all contribute to improving how we use it in Airflow—turning it into an automated CI process wherever possible, and getting maintainers focusing on the "right" reviews. However, this must be a very collaborative process. Simply - whenever you see a check that feels repetitive or automatable, I’d love for us to collaborate on turning that into a permanent part of our automated criteria. Either by submitting PRs yourself, asking in #auto-triage-feedback or implementing new ways to handle it. Also getting more people to understand and contribute to it - as happened with our CI. And make sure whatever is "ready for review" - is actually ready. But most importantly, once a PR is "ready for review," we must ensure a human maintainer actually reviews it—one who won't need to ask about code quality; their first question should be, "Why?" Currently many of those PRs are not even looked at by anyone. So what kind of questions we ask doesn't matter, because we often don't even ask any questions. I’m more than happy to lead this process, and I’d love to have everyone’s active involvement. If we can share the load, we can make sure every high-quality PR gets the thoughtful "why" questions it deserves in a timely manner. Best, Jarek On Mon, Jun 15, 2026 at 4:34 PM Kaxil Naik <[email protected]> wrote: > Hey all, > > While we are talking about contribution quality and ownership in various > separate threads, I do want to say that demanding reviews are one of the > best things this project has, and I'd hate for us to come out of these > various conversations having quietly lowered the bar to feel more > welcoming. > > The reviews I have learned the most from weren't the ones that approved my > code. They were the ones that asked "why this way?", "what does this do to > the person debugging it in two years?", "is this even the problem we should > be solving?" Ash's reviews are the example I keep coming back to. We > disagree plenty, and he's caught things in my own PRs I'd have merged > otherwise. Those questions take real time and care, there is no metric or > leaderboard that rewards asking them, and they are exactly the judgment > that doesn't easily automate. > > After his review comments, I often asked myself why I hadn't thought of > that approach. > > Bolke did the same to me in my early days ( > https://github.com/apache/airflow/pull/2810). The review stung at the time > and made me a better engineer. Most long-time contributors here probably > have a story like it. > > Holding a high bar isn't unwelcoming. It's how contributors actually grow, > and how the codebase stays something we can all still reason about. Waving > work through to dodge friction helps no one, least of all the contributor. > > To be clear, this is a stance on the bar, not on any one way of delivering > feedback. I just don't want the two collapsed into each other, because the > answer to a tone problem is never less rigor. > > Thanks to Ash, and to everyone here who puts this kind of care into > reviews. It's a lot of unsung work, and a big part of why I still trust > this codebase. > > Regards, > Kaxil >
