All of them or some specific oness? Some example links? On Thu, May 21, 2026 at 11:56 AM Omkar P <[email protected]> wrote:
> 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
