Okay. That is perfectly fair. Also, does this email look fine to you? I believe those previous emails may have looked wrong because I manually copied the thread title and sent the emails. This time I used the reply button so I believe it should be fine as I can see the previous replies now.
On 2026/05/19 22:42:16 Jarek Potiuk wrote: > NOTE. Sameer, there is **something** wrong with The responses of yours > (A few recent emails) regarding the mail setup and the responses are not > ending > in the same thread in Gmail (they do in Ponymail), Likey message id / > thread id > is **lost somewhere** - not sure what setup you have but I **guess** the > email > You are subscribed to the devlist, and it forwards messages, losing the > thread id from > Gmail (which seems interesting because you also use Gmail). So maybe you > can take a look at any non-standard setting you have ;). > > In the meantime I am copying your message here (minus praises - they are > very nice but it's about the merit): > > > That being said, I’ve noticed that some PRs end up in a “needs maintainer > consensus / architectural decision” state rather than having concrete > author-actionable issues. > > > In those cases, the auto-triage agent can repeatedly surface secondary > issues while missing the real blocker, which creates a slightly misleading > signal for contributors. I hit this on one of my Kubernetes PRs where the > underlying issue was really maintainer alignment rather than unresolved > implementation problems. > > > Maybe it would help to introduce a category like 'pending maintainer > consensus” (ormore general 'misc' category) so the tooling can distinguish > between contributor follow-up and PRs that are effectively waiting on > reviewer direction. > > > I understand that with the volume of PRs nowadays, there is only so much > that can be done and perhaps this has already been brought up before. But > the main pain point (or at least what I have personally experienced) is > false negatives. This is more of an annoyance than a major blocker but I > was just curious if something could be done on the tooling side to > alleviate this issue. > > Nope - nobody raised it yet, but I think it's a great feedback, and I think > it can be easily addressed, Generally the triage process does not touch > "Ready for maintainer review" PRs, unless they start failing (Conflicts, > rebases etc. - in which case the "ready for maintainer review" label is > removed > But the fix is simple: it should not be removed if there is a discussion is > started on the merit of that PR - not on mechanical failures. > > Fix here: > > https://github.com/apache/airflow-steward/pull/232 > > We will review it in "Magpie", merge and we upgrade > to the latest version before next triage. > > J. > > > On Tue, May 19, 2026 at 11:19 AM Jarek Potiuk <[email protected]> wrote: > > > Hi all, > > > > I have completed two PR triage sessions using the latest version of > > "Magpie," which includes improved stats and charts: PR Stats Dashboard ( > > https://htmlpreview.github.io/?https://gist.githubusercontent.com/potiuk/d593b7773847e5d2f8638ad59d355842/raw/7125cc996a05e135e93dc26012816b83db1fad51/pr-stats-dashboard.html > > ). > > > > Observations: > > > > - AI Triage: The process is effective; "drive-by" PRs have decreased, and > > we now see a ~50% author response rate. Open/closed PR volume has > > stabilized at approximately 40 per day. > > - Review Queue: We have 154 "ready for review" PRs, over half of which > > have no maintainer comments. This queue is growing quickly despite > > automated "unlabeling" of PRs with conflicts or failing tests. > > - Gaps: The "providers" and "task-sdk" areas lack the most coverage. > > > > Takeaways & Discussion Points: > > > > 1. AI triage successfully filters low-quality PRs, but we need more > > maintainers to conduct periodic reviews in their specific areas. > > 2. Reviews can be done manually via the "ready for review" label or > > assisted by the agent using /setup-steward and /pr-management-code-review. > > 3. We need to revamp CODEOWNERS to clarify whether listing implies > > observation or a commitment to review and to cover unassigned areas. > > > > I look forward to your thoughts on how we can improve these processes. > > > > Thanks, > > Jarek Potiuk > > >
