> 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.
Yes. I would like to run it manually—ideally with several volunteer maintainers - for a while to see how it works, improve and iterate and possibly add more quality gates. When we have more confidence we could run it automatically for some parts or even the whole process eventually (especially for high-confidence/sensitive stuff), keeping the sensitive parts with Human-In-The-Loop. But also (and this is my hope) - similarly to `breeze ci upgrade` it might turn out that the process is so efficient and "nice" to follow that we could continue trigger it manually, regularly, perhaps with a rotational maintainer handling the triage. I think comments and actions coming from a human maintainer have more value than those from a bot—even if the human action is merely confirming what an automated system or LLM proposed. J. On Mon, Mar 2, 2026 at 10:04 AM Shahar Epstein <[email protected]> wrote: > 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. > > >
