Thirteen backlogs in a trenchcoat: Analysing Renovate's many requests

In 2019, I saw a talk called Building and Growing an Agile Team by Tom Hoyland, which has probably been one of the most impactful talks I've attended in my career.

In the talk, Tom talks about how he worked with a team to build them into a high-performing team, which, among other things, involved measuring things like "cycle time", improving the way the team's deployment process worked by doing it for every story, and by discovering the sources of work coming into the team.

In the latter case, by understanding the sources of work the team was being given, the team could then have full visibility into their different backlogs, which had always been present, but maybe not clearly thought of as a backlog, and make better choices going forwards.

This is something that I've internalised quite deeply over the years, and have used to build teams that enjoyed working together across several companies.

Most recently, this talk has come up as I've been thinking about how the Renovate project has quite a large backlog of work, in part due to increased contribution over the last ~18 months due to AI.

As the Project Lead, I've been thinking about how we can approach this better in the future, and decided that one step towards this is to map out the different "backlogs" that we have as a project. This exercise will help us understand more generally what sources of work we have to help us better prioritise the existing backlog alongside new requests that come in.

A brief summary of the project

For those that don't know, Renovate is the excellent dependency update tool that's always been Open Source and very much open to contributions + extensions.

I've been an avid user for years, and prior to joining Mend to work on Renovate last year, I'd been waxing lyrical about Why I recommend Renovate over any other dependency update tools which holds true to today - or maybe even more so, given the features we've been shipping ever since.

Renovate itself is a great project that's powered by a tiny team that ships a lot of stuff considering its size, where we're broken up into 3 distinct categories:

• maintainer: one of the official maintainer team: Michael and I are employed by Mend, Sebastian is completely independent
• collaborator: a wider group of folks who have Triage+ access on the GitHub repo, and are the wider team in and around Renovate
• community: anyone else contributing to Renovate - be they users (asking for support, or trying to fix their own issues), customers of Mend, or anything else

We can see in the below graph that we moved from GitHub Issues to GitHub Discussions in 2023, and have 3 sets of interaction with the community:

• "Request Help" Discussions: sometimes a feature request (if Renovate doesn't support something the user thinks Renovate does) but is often a bug
• "Suggest an Idea" Discussions: almost entirely feature requests
• Pull Requests

When a Request Help or Suggest an Idea Discussion leads to tangible change the project needs, we'll end up either with a PR or an Issue recorded to be delivered at a later point.

You can also see how Renovate's Pull Requests have changed over time:

For simplicity, I'll refer to "Renovate" here or "the Renovate project", and show stats out of the primary repository, renovatebot/renovate. What most folks don't really realise is that Renovate itself is built out from ~125 GitHub repos, which are spread across the @renovatebot and @containerbase GitHub orgs.

How did we come up with the "buckets" of work?

To try and understand our backlogs of work, I tried to reason about our work in terms of "buckets" of similar pieces of work.

As early as June I'd been putting some thinking towards this, and most recently in September and October, I've been working on this in a focussed fashion, landing on the definitions a couple of weeks ago.

To actually break down our backlog into these "buckets", I went through the following process:

1. Using my "gut feel", consider the recent work I've been doing, and how I'd generally group the various bits of work together
2. Spend a little time reviewing the definitions I came up with, and added an example/rough explanation to then share with the other maintainers
3. Discussed with the other maintainers, got their thoughts - we were generally in agreement with the definitions
4. Gave the definitions to an LLM, alongside my local sync of all our GitHub Discussions, Issues and Pull Requests, and asked it to investigate any gaps in the buckets or anything it could come up with
5. Given the feedback - and some additional suggestions - refined it with some more discussion
6. Tweaked my original buckets, and some additional buckets + categories from the LLM, and broke them down into the groupings I wanted to continue with, alongside a short definition of each one
7. Asked Claude Fable 5.1 and Claude Opus 5.5 sub-agents to go and review the buckets against the GitHub Discussions, Issues and Pull Requests I had synced locally
8. (Did a couple of rounds of tweaks)
9. Asked Claude Fable 5.1 to use Claude Opus 5.5 and Claude Sonnet 5.5 sub-agents to review the finalised descriptions
10. Reviewed ~300 "disagreements" between Claude Opus 5.5 and Claude Sonnet 5.5 in which labels to apply
11. Reviewed ~50 "high confidence" labels
12. Reviewed the definitions with other maintainers

What did we end up with?

Once I'd worked through this all, the resulting artifact was this, still somewhat LLM-written document on the "bucket definitions".

(I did work to reword a lot of the document to make it read as if I had written it, but we still need to reword some LLM-written docs. I don't like LLM-written documentation, but in this case, I needed to get the PR merged so we could start progressing with it)

What we thought was one large backlog ended up actually being 13 smaller backlogs:

• bucket:ecosystem-depth: Improving an existing integration Renovate has, based on upstream functionality being added - for instance, providing updates for new tools that mise supports
• bucket:new-ecosystem: e.g. "please add support for the kas package manager"
• bucket:ecosystem-data: e.g. "add this common monorepo to the monorepo presets" or "add this package as a replacement for known users"
• bucket:platform: e.g. "add support for GitHub's Merge Queue"
• bucket:security-supply-chain: anything in and around supply chain security, security hardening (in and around Renovate) and "don't log credentials in ..."
• bucket:workflow-fit: "help Renovate fit into my organisation's workflow"
• bucket:predictability: "provide better config validation and error messages", and "tell me where a config option is being silently ignored"
• bucket:observability: "how can we make it clearer what Renovate is trying to do, or why it did what it did?"
• bucket:performance-scale: "how can we make it easier to run Renovate at larger scale"
• bucket:bug-fix: a bug with a feature Renovate has, but isn't doing something it should do - sometimes users come to us with a "bug" that's actually a feature request
• bucket:engineering-health: anything to help make Renovate easier to maintain as a project, improving how our release process works, etc
• bucket:docs: anything related to improving our docs, which could also line up with e.g. bucket:performance-scale if it's related to documenting how to improve your caching
• bucket:dependency-updates: updates of our own dependencies by renovate[bot], which is one we cover separately

A bucket I had originally planned for - and something I called out as one of my key achievements of the last year - is "being competitive" against other tools in the space, adding features that give us an opportunity to show we're moving faster than the others on the market.

However, we decided not to add this as a bucket/cross-cutting concern at this point - it's more of a "gut feel" that's based on manually deciding this was the case, and so not something we're going to try and backfill.

As we'll see later, there are also a few other cross-cutting concerns.

So what do our users want?

As of the data of ~2 weeks ago (13th October), we can see the breakdown of the buckets between "suggest an idea" Discussions, Issues and PRs:

We can see that the largest share of features folks want is "ecosystem depth" and "workflow fit", which tracks with folks wanting Renovate to work even better with the tools or processes they're already using - for instance supporting a new tool that mise can install or adding more control over how security update PRs are raised.

This work requires a maintainer to weigh in on the design decisions, so often doesn't get done until that's been worked through - or a contributor has to work through the design with us when they've opened a PR.

My gut feel was that what folks asked for had changed over time, but looking at the data it hasn't really, which is interesting!

If we look at how community PRs are broken down:

Understandably, folks in the community want to fix bugs that are affecting them, and as they're generally more nicely scoped, it's a more straightforward contribution than adding something more involved like a new package manager.

We see a lot of contributions around ecosystem data, which are generally edits to our monorepo or replacement presets, and can be a pretty quick change to review.

If we then compare this to the "Suggest an Idea" Discussions over the years, we can see that this tells us a different story:

In general, feature requests users want are around ecosystem depth and workflow fit, but we're also seeing an increase in "new ecosystem" this year.

Increased interest in Supply Chain Security

As we've seen from reports like Sonatype's State of the Software Supply Chain, there's been a significant uptick in supply chain attacks in the last few years, and understandably, our users are also quite keen on ensuring they don't fall prey to attacks.

We can see that over the last few years, we've had quite a rise in our supply chain security requests:

Foreseeing the risks compounding, I decided to build on top of Renovate's minimumReleaseAge functionality (which we've had since 2019) - and also referred to as "cooldowns" - and introduce a safer set of defaults for our users in the npm ecosystem.

In July this year, Dependabot decided to do something similar, which is great to see after a lot of the major package managers have put their own controls in place, for defence in depth.

One of the fun things of working in this space is that you're never "done" and that we're always working to further secure our users and operators alike.

More PRs, but not from everyone

It's fair to say that in the last couple of years, the rise of access to LLMs has led to an increase in folks contributing to Open Source, and it feels like we're seeing the same with Renovate.

However, when you look at the raw numbers, that's not the full story:

We've seen an increase from 1614 human PRs in 2024 to 2393 so far in 2026, and it looks like we'll have ~3000 by the end of the year.

(My local sync only starts in 2024 and undercounts that year by ~10% - GitHub's search totals put 2024 at roughly 1800 PRs, with roughly 810 from the community.)

PRs from the community have risen from 739 in 2024 to what could be ~1100 by the end of the year, which we believe is a mix of more folks using Renovate, but also AI making it easier to contribute (on top of improvements we've made for agents to contribute).

Since August 2025, our PR template has asked contributors to tell us how they've used AI, which gives us a good idea of what's behind this:

Over the first three quarters of 2026, community PRs went from 207 to 287 to 340. PRs disclosing substantive AI use went from roughly 75 to 145 to 225 during that time, while all other PRs stayed roughly flat.

This is self-reported, so it isn't perfect, but it suggests that this year's growth is almost entirely from AI-assisted PRs.

Separately, the number of people contributing has been growing steadily for a few years:

Collaborators are hitting similar numbers to previous years, but it's the maintainers where we've seen the most significant rise - from 507 PRs in 2024 to 1230 so far this year.

It's all about me

If you look at the breakdown of contribution per person, you can also see my personal impact on the project (or, why everyone else's PRs may not be getting reviewed as much):

Part of my role is the Community Manager, where I'll be primarily looking into issues reported by users. Where there are documentation improvements, or areas that I can improve the observability into what Renovate is doing, I'll raise that PR as part of the investigation, rather than creating an Issue to come back to. Or if the issue they're facing is something straightforward enough, I'd make the change.

On top of that, some of this comes down to the fact that I'm someone who has a lot of thoughts about Git commits, and in particular loves atomic commits.

However, in Renovate we squash merge, which means that if I want atomic changes, I need to break them out over multiple PRs.

While I used to have to manage this a bit manually, it's now much easier with Stacked PRs on GitHub, so you'll start seeing much larger stacks of PRs from me.

I'll also generally pick up some of our larger pieces of work - either as things that we want to do for the project, or that are customer-requested - so this also contributes to a larger share of the work.

The community

Echoing the data we saw before, we're seeing that the community continue to want to fix the issues blocking them, and integrate Renovate more closely into the tools it interacts with.

We can see that some of the more straightforward changes merge more easily, but cases where there's a bit more thinking around the changes, like "workflow fit", merge far less often.

Dependency updates galore

And finally, even poor renovate[bot] is busier than ever:

Renovate's been working tirelessly to keep our software up-to-date, as it has for everyone else who uses it.

This is not only due to the fact that in recent years we have more dependencies (for instance, we have a -full Docker image, which bundles helm, node, java, etc, so you can run it air-gapped) but also because the general software ecosystem is needing to update things more often - partially due to the increase in security advisories, driven by AI.

We're getting slower

In recent years, anyone with a few dollars worth of tokens (or a subscription) can throw up hundreds more lines of code a minute than a real human could in the years before.

As we're seeing an increased number of contributions, we're working out how to scale ourselves, without turning into robots or meat proxies.

I very much don't want to turn into one of those people who replies to everything with AI, because I feel my humanity is more important.

While we've seen a drop in Request Help threads - possibly because people are asking AI instead of us - and we're seeing fairly flat Suggest an Idea threads, we've got many more PRs to review - if you've got any recommendations, let me know.

Some stats about the increase in response times:

We're very aware that we're running slower than we have done in the past (while also potentially getting a lot more shipped, as a project). I fully appreciate and feel the frustration - and I share it too. As I mentioned to someone close to the project recently, I feel I'm constantly dropping the ball, and that every day I'll start trying to do something, and yet there are 10 new threads to deal with.

Until we're able to scale the maintainer team with more meatbags, we're working out how we go forward with this.

Cross-cutting concerns

As well as looking at what buckets work could land in, the investigation via Claude noticed that there were some cross-cutting concerns that could be labelled alongside the buckets.

Rough edges

While at Deliveroo, we worked on an initiative called "papercuts", where we looked to reduce the small, annoying rough edges with a service we provided to our customers. This initiative shipped some real quality-of-life improvements that made a noticeable, meaningful difference.

While looking at the resulting categorisation Claude was working on, I asked the agent to look at whether there were "papercuts" of sorts, which morphed into the "rough edge" concept.

Out of this, we can see a breakdown of some of the areas that folks feel this pain in:

These are generally small, fairly uncontroversial changes, which we can merge much readily, but the open ones linger just as long in our backlog:

Looking for these rough edges will give us an area where we can make effective changes that make Renovate nicer to work with.

For instance, if we see something that's a bucket:bug-fix and rough-edge, then it's generally going to be a better choice to prioritise that more highly than someone looking to add a whole new Platform to Renovate.

Audience

Another angle for the different pieces of work we look at are who it's solving an issue for:

• audience:user: someone using Renovate to keep their dependencies up to date
• audience:operator: someone self-hosting Renovate (either for themselves, their organisation, or for a much wider group of folks)
• audience:maintainer: the Renovate maintainers and collaborators - generally "how to make the project easier to maintain" and/or "keeping the codebase fresh and up-to-date with standards"

This gives us an interesting breakdown of cases where predominantly our buckets are user-facing, but some buckets, like "Performance & scale" and "Observability" skew more towards the operator who runs a Renovate deployment:

We also have audience:mend-hosted, for a subset of requests that are only important for Mend-hosted environments (and target those of us working at Mend), which is omitted as it's a very small percentage of cases.

Customer requests

Since joining the project, I've been trying to label tickets as something explicitly requested by a customer for us to add/change or something customers have expressed interest in, including doing a bit of historical digging to clarify specific asks.

For those of us employed by Mend, they're naturally higher priority, and labelling them makes it more visible to us. As these labels are public, it's also a good insight for all Renovate users to see where customers are shaping the roadmap.

I'll remind folks that the key way that you can support Renovate continuing to be a sustainable Open Source project is to convince your company to buy an Enterprise (Self-Hosted or Cloud) license.

Buying a license isn't the only way to get something into Renovate - we've seen 1664 PRs since January 2025 from the community, and most bug fixes and ecosystem depth PRs get merged. This last year, I've also pushed for us to take on features that historically we wouldn't have supported, like providing security updates for transitive dependencies, through a lockfile edit.

A path to better prioritisation

Now we have these buckets decided and analysed, we'll be using them going forwards to try and improve the way we review incoming requests.

Our plan is to use the buckets when reviewing priority of a request - for instance, prioritising a bug-fix PR that has a minimal reproduction repository over "I've released v0.3 of my package manager, please add support for it", and areas that Mend customers are interested in will also bump up on the priority list. Additionally, if there's a ticket that would solve a rough edge, we'll also more highly prioritise that to improve the overall experience.

We've not fully finalised the approach we're going to take, and I'm sure we'll iterate over it either way.

Key takeaways

Running a large Open Source project is hard.

We've seen countless maintainers say "fuck it" and disable their Issue trackers or stop accepting Pull Requests, or completely leave the space and archive their project - and that was happening before AI made it so much easier to throw up code or bug reports, so it's only more common now.

We're fortunate to have a company behind the project, and have a number of folks who are paid to work on this awesome project - but that doesn't mean we're immune to the issues that others have (like burnout, overwhelm, and too-many-things-to-do-all-the-time-itis) and we're still feeling the issue of trying to scale ourselves.

As with many other projects over the last ~12-18 months, we've seen a significant increase in contributions, and we're seeing what we can do to scale our small team without resorting to becoming robots.

I'm empathetic for those of you who are feeling frustration at contributions moving more slowly through the project than they have been in the past - I also very much wish that this wasn't the case! I know that this isn't the best experience, and trust me, we're aware - I'm constantly feeling like I'm dropping the ball on things, which isn't fun - please remember this empathy goes both ways, and that we're all trying.

We do believe that this work to define our buckets will make a difference, and we are working to be more intentional going forwards with what we prioritise, how we respond to incoming requests, and try and keep this sustainable.

Thanks to all continuing to use and contribute to Renovate, we wouldn't be able to do this without you 💜