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 > > > > > > > > > >
