Jarek, would it be possible to make autotriage AI PR comments less repetitive (and less verbose)?
It adds inline comments and then there's also a huge summary comment. Some of the content is repetitive and I think the huge summary comment can be made more concise. Code suggestions can be retained but text around it could be reduced. If it's even a slightly less verbose it'll be easier to read and make necessary changes quick (in my opinion). Not sure if you noticed this already, thought to let you know. Thanks. Regards, Omkar On Tue, May 19, 2026 at 11:18 PM Jarek Potiuk <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > >
