Nope. Separate thread :) On Wed, May 20, 2026 at 12:00 AM Sameer Mesiah <[email protected]> wrote:
> 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 > > > > > >
