Our issue tracker had grown into a dense forest — 517 open issues, many from the Plone 4/5 era, unlabeled, untriaged, and impossible to navigate.
Over the weekend I did a thorough triage session with the help of Claude (Anthropic's AI), reviewing every single issue older than 1 year. Claude helped by reading each issue, checking the current codebase for whether the reported problem still exists, and drafting comments — but every close/label decision was human-reviewed (as I identify myself).
Here's what happened:
~200 issues closed — each with an individual comment explaining why:
Already fixed: resolved by merged PRs but never closed
Stale: no activity in 5-10+ years, no longer actionable
Duplicates: consolidated into single tracking issues
~170 issues verified & labeled — many with code-level verification against the current Plone 6 codebase:
Bugs confirmed still present, with file paths and line numbers
Enhancements validated as still relevant
Issues marked needs: help where community verification or implementation is needed
Result: 517 → ~310 open issues. (Almost) every remaining issue now has proper type and status labels.
What we intentionally did NOT touch:
PLIPs — these belong to the Steering Circle and the specialized teams
Issues less than ~1 year old (~20 issues) — recent enough that they should be reviewed by the community and their original reporters
Issues with active sprint assignments or open PRs — work in progress, left alone
Why not a stale bot? Some projects use automated stale bots to keep their trackers clean. I don't think that's right for Plone. Our contributors file issues in good faith, often with detailed analysis. An automated "closing due to inactivity" feels dismissive and impersonal. A bug doesn't stop being a bug just because nobody commented for a while. Periodic manual triage — with specific, individual reasoning for each decision — respects the effort people put into their reports. As this session showed, AI-assisted triage makes this scalable even for hundreds of issues.
If you find an issue that was closed and you believe is still relevant — please reopen it. Every closing comment invites this. I am sure because of the pure mass I made mistakes.
The remaining backlog is now a well-labeled, navigable list instead of a forest. Let's keep it that way with periodic triage rather than letting it grow wild again.
Can you explain your setup? How did you access the related GH entries? Through the GH API?
The Plone codebase is huge...did not you run into issues regarding the token window size? Anthrophic made you a poor man? Any idea about the cost?
Thank you Jens! I try to clean up the PLIPs at least once a year before the State of Plone keynote when I need to get an overview over the current state of the PLIPs.
I started Claude in the context of my coredev setup. First I told Claude what I want to achieve. I gave background information and that I want a summary of all CMFPlone issues. I shortly developed a strategy. Then I allowed it to use git and to clone any repository or checkout any branch it needs to analyze the code base. I gave it access to the gh commandline tool. It wrote a script using gh to gather information, mostly metadata of the issues, told to to assemble a markdown table with a rough overview and stats of out issues. I found we best tackle the oldest issues first, work in several phases through it, dont look at PLIPs at all. Then we got some rough map of what we had. Then we worked through slices in time in batches of 50-80, which it handled well to create another table and a rough categorization. For each batch an agent team of 5 then worked through each issue, enriching the table with more information: Is the code still there/relevant? Was there a PR related and closed? And many other questions like this. Some were clear (in the older batch a lot), others ambiguous. Those were used for deeper dives on the topic and semi-manual triage... I reviewed the table iterative and interactive with Claude, it gave me summaries of the code changes, opened files and reasoned what happened in the code base including links to other issues/PLIPs or pull requests open or closed. This until every issue was categorized. Then I told Claude to either close or categorized and comment according to and with the text from the table. It then used gh again and wrote a throw away script to apply all. Then rinse and repeat for the next slice/batch.
No. Claude has now a 1M token window and I did not run in an overflow. Its covered by my subscription. But I throw 180 €/month on Anthropic, so well.
Cool when you know what you are doing…
But Claude does not sit there and ask to work on stale Plone issues.
As Edison puts it once:
«It is not enough to invent something. You need to recognize you invented something.»
So the way how one uses AI as a colleague and sparring partner is completely different to leaving thinking to another head.
«You can only think with the lightnings igniting in your own head.» – acsr
As a general habit it is important not only share the results from working with AI but also try to share the whole process containing the intends in the prompting and agentic workflows. Thanks @jensens
This is the Whylog Approach I am following for my own work. (also read more about #LADR)
For me the "why" is the ladder to climb every hurdle…
