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 >
