{"slug": "looking-back-at-my-first-year-as-the-renovate-project-lead", "title": "Looking back at my first year as the Renovate Project Lead", "summary": "Renovate Project Lead Jamie Tanna marked his first year at Mend with a retrospective showing \"Request Help\" discussions on the Renovate project fell 43% over the past year, from roughly 180 per month in 2024 to about 80 per month by the end of August 2026, a decline he attributes to users asking LLMs instead of the project's maintainers. Tanna said the shift removes a feedback loop that previously surfaced common user issues, and he noted the project added agent-oriented contributions improvements including an AGENTS.md file and a `pnpm check` command that runs CI-like checks locally. The analysis drew on the project's maintainer dashboard and main-branch commits, with charts generated by Claude Opus 5.", "body_md": "A year ago on Thursday, I logged on for my first day [joining Mend to work on Renovate full-time](https://www.jvt.me/posts/2025/08/27/joining-mend/).\n\nSimilar to [what I did after my first 100 days](https://www.jvt.me/posts/2026/01/21/renovate-100-days/), I thought now would be a good time to recap how this last year has gone. This is also a fun way of doing a public mini performance review!\n\nI'd planned to try and land this on my actual anniversary, but I know this is going to be a busy week - as they all seem to be, nowadays - so thought I'd pre-publish it (and [because I don't like waiting to hit publish](https://www.jvt.me/posts/2022/02/07/blog-publish-date/)).\n\nPlus, publishing this now means that I don't have to keep re-writing this as the stats change!\n\nNote that below includes analysis from Claude Opus 5, based on data from our [\"maintainer dashboard\"](https://github.com/renovatebot/maintainer-dashboard/) and commits on `main` over the last year. I've done some double-checking of some of these stats. Claude Opus 5 has created each of the charts on this page.\n\nBefore I get into how things have gone with the Renovate project, I wanted to look at the wider industry's context.\n\nIn the last year, we've seen:\n\nOver the last year, we've also seen some changes in how folks interact with [Renovate](https://docs.renovatebot.com/).\n\nFirstly, it appears that there is an increase in adoption of Renovate, which is great! I'm especially biased right now, but I still think that [Renovate is the best tool for dependency updates out there](https://www.jvt.me/posts/2024/04/12/use-renovate/).\n\nSecondly, we've seen an interesting trend in how folks interact with the project. In prior years, we would have a fair few \"Request Help\" discussions - often \"how do I get Renovate to do ...\" or \"I've configured ..., but it's not working how I expect it to\" - which are down 43% this last year:\n\nA breakdown of how the trend of Discussions being created against the project has changed since September 2024.\nIn 2024, we saw ~180/month \"Request Help\"s and ~50/month \"Suggest an Idea\"s being raised.\n\nBy September 2025, \"Request Help\"s were down to ~140/month and \"Suggest an Idea\"s down to ~25/month.\n\nThrough to the end of August 2026, the \"Request Help\"s are down to ~80/month and \"Suggest an Idea\"s up to ~30/month.\n\nMy instinct is that with the rise of LLM usage, more folks are asking their LLMs to answer questions like this, instead of coming to us. I can't fault folks for using a tool with immediate responses - even if it's likely got outdated knowledge, or the chance of suggesting solutions we wouldn't recommend any more - as it gives them that faster feedback so they can get unblocked.\n\nI do think this is a shame, however, because previously we could use the contents of \"Request Help\"s as a feedback loop for what issues folks are seeing most commonly, and what areas we may need to improve, but now it's hidden inside a user's chat windows. We've been quite fortunate to have this as a signal in the past, and now we're going to need to work a bit harder to see how we can improve this going forwards.\n\nI don't have any numbers to hand on this, but when we do receive \"Request Help\"s, a lot of the time, they include a \"I got an agent to trace through the code and it looks like this line needs a fix\", rather than a real case of \"I honestly don't know how to do this, please help\".\n\nSpeaking of AI agents, we've also made several improvements over the last year to try and make it easier for agents to contribute:\n\n`AGENTS.md`` pnpm check` command that runs all CI-like checks, locally\nSergei and Sebastian have been doing some really great work on this - as well as a few other folks - and it's made a massive difference for my own usage of LLMs with the codebase, and getting even better code out the other end.\n\nThat being said, prior to these changes were we seeing - for the most part - fairly technically correct code, but it wouldn't necessarily fit in the areas that it was added for, or wouldn't completely fit our code style, but would handle a lot of file-directory architecture choices.\n\nIt's pretty great that work we've done for years to keep the codebase well-defined has made it easier for humans and LLMs both to contribute, and we can see this in the data of contributions.\n\nPrior to September last year, every 6-month block of the year for the last 18 months, we saw ~700 commits every 6 months. In the first half of 2026, we saw that number increase to 1035 (48% increase), which is a whopping increase for a 0% increase in maintainers on the project 🤓\n\nWe can see this in how the external contributions have increased over the months:\n\nA breakdown of how the trend of PRs being created against the project has changed since September 2024.\nBetween September 2024 and March 2026, we saw fairly consistent number of external PRs between 47 and 79 PRs/month, from 35-58 distinct authors.\n\nIn March 2025, we see this increase to 96 PRs from 677 distinct authors, up to a peak of 124 PRs from 86 distinct authors.\n\nSimilarly, we're receiving increased numbers of PRs, but are still continuing to merge them, albeit it's taking a bit longer:\n\nThe breakdown of how many PRs are merged/closed without merge/not-yet-merged-or-closed, looking at 6 month periods (as a \"cohort\").\nWe see a fairly stable percentage of PRs closed without merge (17% to 23%) over the cohorts.\n\nIn 2024-H1, we see 83% of the 336 PRs are merged.\n\nIn 2024-H2, we see 79% of the 390 PRs are merged.\n\nIn 2025-H1, we see 76% of the 393 PRs are merged, and 1.3% still needing a decision.\n\nIn 2025-H2, we see 69% of the 375 PRs are merged, and 8% still needing a decision.\n\nIn 2026-H1, we see 61% of the 494 PRs are merged, and 20% still needing a decision.\n\nConsidering we're seeing an increase in new contributors, these are folks who aren't necessarily going to know the practices of the project, so it may take more time to iterate through changes:\n\nThe breakdown of the number of new contributors to the project, looking at 6 month periods, and based off merged contributions.\nIn 2024-H1, there were 183 new contributors.\n\nIn 2024-H2, there were 193 new contributors.\n\nIn 2025-H1, there were 179 new contributors.\n\nIn 2025-H2, there were 171 new contributors.\n\nIn 2026-H1, there were 205 new contributors.\n\nAs noted above, [because we use GitHub Discussions for triage](https://www.jvt.me/posts/2026/01/07/renovate-why-discussions/), there shouldn't be any Issues being created by folks outside of the project, but that doesn't stop them right? Although we've done a few things to try and stop users doing this - like a big glaring warning, and auto-closing them if they're not raised by a collaborator on the project - there were still some cases we'd get repeat offenders, especially as GitHub still didn't block it via the API or in specific UI widgets.\n\nI'd often give a temporary block to \"nudge\" the user that their behaviour wasn't correct, but a lot of the times, these were created by an AI Agent, not even a human who was being a bit of a dick.\n\nThankfully by August (after a needed [follow-up fix](https://github.blog/changelog/2026-08-03-triage-role-can-bypass-issue-creation-restrictions/) to the [original release in June](https://github.blog/changelog/2026-06-29-restrict-issue-creation-to-collaborators-only/)), it was possible to completely close out Issue creation from non-collaborators, which also means there's one fewer place I need to keep on top of.\n\n`E_TOO_MANY_RELEASES`\nAnother big issue we've hit this year is that when publishing new npm packages, we hit:\n\n```\nnpm error code E406\nnpm error 406 Not Acceptable - PUT https://registry.npmjs.org/renovate - Package publish failed.\nnpm error Your package metadata is too large (100.01 MB > 100 MB).\n```\n\nThis is quite a novel error in the npm ecosystem, as there aren't that many projects that release quite so much that they hit hard limits on the registry size 😅\n\nThis happened twice this year:\n\nDuring this window, we were still able to publish Docker images, but not having the npm package led to a lot of knock-on effects that weren't ideal. We've performed some significant cleanup at this point, and aren't yet planning on reducing our release cadence, due to the utility it provides to us as a project.\n\nSpeaking of our frequent release cadence, over this year, we shipped:\n\nA count of the releases that Renovate shipped over the last year, showing (at time of data collection) 1813 releases, of which 1276 are patch releases, 533 are minor releases and 3 major releases.\n(Of which one major version [wasn't intentional](https://github.com/renovatebot/renovate/discussions/44952))\n\nThese changes also led to a number of changes across Renovate's excellent support of things it can update:\n\nA timeline of changes to the modules that Renovate supports, showing that in the last year:\nIt's been great to see how much stuff we've got done considering the small team, and I'm always incredibly appreciative of maintainers Sebastian and Michael, who also do a tonne to keep this project going!\n\nI'm very happy with some of the key things I've led on:\n\n`minimumReleaseAge`, before the rest of the ecosystem\n`pnpm`` config:best-practices` users, we saw more `vulnerabilityAlerts` through Open Source Vulnerabilities (OSV), but being able to block dependency updates to a known malicious version is really important`constraintsFiltering=strict`` go` directive unnecessarily, you can now use `apk add` extraction in `Dockerfile` s`@renovate-bot` user on GitHub.com`depTypes` this manager supports\", or \"what `tool` s can I tell Renovate to install i.e. with `constraints`?\", as well as working to make our JSON Schema as representative as possible\nThere's actually a load of other things that I'm happy we've got done over this year, but this section is getting very long 😹\n\nWhen I officially joined Mend, I had a bit of a mouthful of a job title, which also didn't really reflect the work and impact I was having when folks inside and outside of Mend read it.\n\nIn May, we changed my title to make the scope of the work and impact I was having official:\n\n```\n-Senior Developer and Open Source project maintainer\n+Renovate Project Lead\n```\n\nThis is probably a little bit of a vanity thing, but it made sure that it was clear that my role is leading the Renovate project, shaping direction of where both the Open Source project and our product offerings go.\n\nLet's look at some of how I spent my year.\n\nI've intentionally not included code review, which has been a chunk of my time, but not as significantly as it has been for Michael.\n\nFor instance, let's refresh ourselves on how many external PRs we've been seeing recently:\n\nThe breakdown of how many PRs are merged/closed without merge/not-yet-merged-or-closed, looking at 6 month periods (as a \"cohort\").\nIn 2024-H1, we see 83% of the 336 PRs are merged. In 2024-H2, we see 79% of the 390 PRs are merged. In 2025-H1, we see 76% of the 393 PRs are merged, and 1.3% still needing a decision. In 2025-H2, we see 69% of the 376 PRs are merged, and 8% still needing a decision. In 2026-H1, we see 61% of the 500 PRs are merged, and 20% still needing a decision.\n\nIf we look at human (or agent) commits, we can see that I've started taking up more time in the overall percentage of project's commits.\n\nThe breakdown of how many human commits there are in the last year, looking at 6 month periods, between \"everyone else\" and me.\nIn 2024-H1 through 2025-H1 I have 0 commits, so \"everyone else\" is doing very well.\n\nIn 2025-H2, I have ~180 commits compared to ~510 from \"everyone else\".\n\nIn 2026-H1 I have ~410 commits compared to ~620 from \"everyone else\".\n\nIn 2026-H2 (so far) I have ~270 commits compared to ~370 from \"everyone else\".\n\nHowever, this is then much more drastic if you look at it based on number of commits per person:\n\nThe breakdown of how many human commits there are in the last year, broken down by GitHub username, showing the top 10 usernames.\nAt the top, `@jamietanna` (the author of this post) has 875 commits.\n\nThe next best, in order, are the other two Renovate maintainers with `@viceice` at 186 and `@secustor` with 137 commits.\n\n7 of the top 10 contributors are collaborators on the project, and 2 of them are for the same human, under two different usernames.\n\nThe 10th place has 12 commits in the last year.\n\nThese commits are a mix of things:\n\nBased on my commit messages, there were:`fix`` docs``chore`` feat``test`` ci``refactor`\nAcross a mix of files and parts of the project:\n\nOver the year, including i.e. linting fixes, I've touched:\nNote that this isn't the entirety of Renovate, and I've purposefully omitted the other areas for brevity.\n\nThese changes have been across Mend customers' requests, reports of bugs from the community, features I want to deliver as well as a mix of other backlogs that we have, and I'm working to make more explicit.\n\nWith the small team we have, we're trying to review as best as we can while this number keeps on growing. And it's clear to see that the more changes I'm authoring, there is a smaller percentage of community PRs that get in, because we have limited review time - something we're hoping to try and improve where we can.\n\nWe can see that as well as committing a lot of things, I also am largely present in the GitHub Discussions:\n\nBefore I joined the project, I naturally didn't spend much of my time regularly interacting with the the GitHub Discussions, unless I had an issue or feature request, so up until September 2025, I effectively had 0 engagement.\nHowever, from September 2025, the amount of discussion comments from others decreased as I did more, as well as the general decline of folks using GitHub Discussions to ask questions.\n\nAn interesting view that Claude Opus 5 noted was that - since I've joined - I've done a bad job with keeping on top of labelling our Issues appropriately 😅\n\nBefore I joined, our labelling of Issues on the repo was at ~95%-98% over time.\nSince I've joined, we're down to ~45% of newly created Issues with any `priority` label, and ~75% with any labels at all.\n\nThis isn't ideal, and is hopefully something we can fix! This is largely because the intake form for Issues would guide you towards creating the Issue with the right fields, but as GitHub (maybe late last year?) allowed maintainers to use free-form inputs, I lazily started using that.\n\nI'd hoped that with [the new structured Issue metadata](https://github.blog/changelog/2026-03-12-issue-fields-structured-issue-metadata-is-in-public-preview/), we'd be able to migrate to them for a number of the \"mandatory\" labels we used, but unfortunately [due to platform limitations of 100 items per field](https://github.com/orgs/community/discussions/190548), we unfortunately can't take advantage of it for some of our fields.\n\nAs much as I continue to say I'm an AI skeptic, you may not believe me when you look at how many of my commits are now including AI-generate content in them:\n\nA stacked bar chart showing my commits (on `main`) per month from October 2025 to September 2026. From October 2025 to January 2026, the AI usage was between 2% and 7%. In February this increases to ~29%, and in August and September 2025 (so far), we're seeing roughly 88% AI usage.\nI've definitely been using AI a whole lot more this last year. Some of it is absolutely to \"keep up\" - with the increased load on maintainers, [if there are metrics needing to be hit](https://www.jvt.me/posts/2026/06/18/ai-adoption-commits/) or even for fear of \"being left behind\".\n\nBut it's also disingenuous to not also say that I *am* enjoying having AI agents available to me, that I can use to parallelise tasks while working on other things (for instance, writing this blog post 😉), while also [lamenting whether \"craft\" can exist](https://www.jvt.me/posts/2026/05/26/ai-craft/) and [the worries about how Open Source survives](https://www.jvt.me/posts/2025/11/17/llm-oss/).\n\nAs I noted in [*How much AI can a maintainer get away with using without losing their humanity?*](https://www.jvt.me/posts/2026/08/02/ai-maintainer/), I'm not at the point - and I don't think I really want to be - of replying to other human people with AI. I'm still thinking fairly critically, doing my own writing of my blog - [also as Bryan Cantril recommends](https://bcantrill.dtrace.org/2026/09/05/the-revolt-of-the-reader/) - and my replies to humans, but worrying that the increase in workload will lead to compromises needing to be made.\n\nI won't go into this in the same level of detail here, but there are a number of key changes that I've done/helped shape this year that I'm very happy about, and I know a number of our customers have been very appreciative of!\n\nI'll also note that I've ended up shipping ~102 Renovate upgrades to Mend-hosted apps, roughly up ~50% compared to the previous year.\n\nI'm pretty happy with how the last year has gone.\n\nThere are of course some situations and conversations we could've handled better, there are areas that I wish we'd tested a little better before they got merged, but given [the tiny core team we have](https://www.jvt.me/posts/2026/01/21/renovate-100-days/#shipping-despite-a-tiny-team) we've done very well generally with the increase in workload.\n\nBut I'm also big-headed enough to say that I think I'm absolutely the right person to have picked up the mantle with Rhys leaving, and I'm very happy I did. It would have been interesting to see how someone else would've responded to a number of the changes over this last year, but I guess we don't get to see that.\n\nLooking forward to seeing how things go this coming year!", "url": "https://wpnews.pro/news/looking-back-at-my-first-year-as-the-renovate-project-lead", "canonical_source": "https://www.jvt.me/posts/2026/09/21/renovate-1-year/?utm_medium=rss&utm_source=rss", "published_at": "2026-09-21 15:58:39+00:00", "updated_at": "2026-09-21 16:23:25.750896+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools"], "entities": ["Renovate", "Mend", "Jamie Tanna", "Claude Opus 5", "Sergei", "Sebastian", "pnpm"], "alternates": {"html": "https://wpnews.pro/news/looking-back-at-my-first-year-as-the-renovate-project-lead", "markdown": "https://wpnews.pro/news/looking-back-at-my-first-year-as-the-renovate-project-lead.md", "text": "https://wpnews.pro/news/looking-back-at-my-first-year-as-the-renovate-project-lead.txt", "jsonld": "https://wpnews.pro/news/looking-back-at-my-first-year-as-the-renovate-project-lead.jsonld"}}