Amazing stuff Jarek! I think that we could later automate at least the dry-run execution of the script, along with Slack notification for highly-suspected issues/PRs. Then, it would be easier for maintainers to react fast when needed.
Looking forward for new AI-based features in breeze in particular, and Airflow in general :) Shahar On Sat, Feb 28, 2026, 04:59 Jarek Potiuk <[email protected]> wrote: > Hello everyone, > > While preparing for consensus on the assignment policy, I created PR > https://github.com/apache/airflow/pull/62585. This PR adds a new command > to > Breeze, `breeze issues unassign`, which unassigns anyone who is not a > committer or collaborator. > > I want this to be the first of several Breeze commands I plan to add to > help manage the AI overhead and burden on maintainers. > > I got inspired bu Hugo van Kamerade's (my friend, Python release manager) > tool https://hugovk.dev/blog/2026/gh-triage/. He added the `gh` plugin > that helps him manage spam coming to Python. I hope we can have very > similar set of commands and regular process of performing cleanup with the > issues/prs we are getting. > > BTW. I am using Claude Code to add those commands (so this is a bit like > using AI to fight AI slop). But in a smart way. > > In our case we have `breeze` that we are already using for `ci upgrade` by > maintainers and I see no reason why we could not use our own CLI to make us > far more efficient with assessing and quickly and efficiently processing > incoming spam. > > Starting with AGENTS.md that describes what we expect (and instructs agents > to make good PRs) and changing our assignment process - I think we should > proceed to implement step-by-step handling of the incoming traffic: > > a) Quickly assess how well PRs implement our expectations, point out > problems, and close them > > b) automatically telling the collaborators what is wrong with their PRs if > they are incomplete (for example when tests are failing, or when they need > a rebase) > > c) automatically responding to issues that they are incomplete and need > more information > > d) Allow filtering by area (so that maintainers focusing on a particular > area can periodically review only the areas they are intereste > e) all that with some AI assistance (I plan to imlpement integration with > some modern AI LLMs so that it is seamless for those maintainers who > already use some of those (including Cloud Code, GH Copilot (maintainers > can apply for free access there), Codex and any models someone prefers - > including local models). > > f) all that with maintainer in the driver's seat—we won't do those things > fully automatically - but we will get reviewable action proposal in bulk > that the maintainer will be able to accept, modify or reject. > > .... more... > > All that will be open to contribution and I will be happy to leading > introduction and disseminating those CLI options between maintainers to > make sure those get incorporated in our daily work - relieving some of the > burden we are all experiencing and sharing it between people. > > I think this is a viable approach to address our current burden > proactively, rather than waiting for others to act. > > This is also somewhat experimental since we haven't seen it done before, so > suggestions, comments, ideas and PRs that could help us become more > efficient and better maintainers are most welcome. > > Let me know what you think. > > J. >
