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.
