Now, all is good. On Wed, May 20, 2026 at 12:11 AM Sameer Mesiah <[email protected]> wrote:
> How does this look now? I was creating new emails before. Now, I am > replying in the same thread. > > > On Wed, 20 May 2026 at 00:02, Jarek Potiuk <[email protected]> wrote: > > > 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 > > > > > > > > > > > > > > >
