Why the Renovate project uses GitHub Discussions as our triage process

(Note that this is also posted on the Renovate project's Discussions, too)

Over the weekend, there has been some good discussion on Hacker News about how the Ghostty project uses GitHub Discussions for triage purposes, and then promotes the feature request/bug reports into Issues when they're triaged effectively.

When Mitchell Hashimoto looked to add the wording around this process to Ghostty, Renovate's own notice was a heavy source of inspiration, which was very flattering!

Given some of the conversation around this, I thought it'd be worth writing about how we've found following this as our triage model since late 2020 and what we've learned over the years of this model.

A brief history lesson about Renovate

The Renovate project has been moving from strength to strength since 2017, providing a simpler and more secure way to keep your dependencies up-to-date. Renovate boasts a tonne of features compared to the alternatives, of which a significant percentage of changes have come from ~1500 contributors over the years, and the project is maintained by a small team of dedicated maintainers inside and outside Mend.

One of the things I've loved about Renovate - before starting work as a maintainer and the Community Manager for the project - was the pace of the Open Source project, and how there were constantly new releases shipping with features, bug fixes and improved documentation.

To make this work, there's a tonne of behind-the-scenes work that goes into this by the maintainers (the team who have final say on new features, and whom have merge rights) and contributors (people who regularly contribute to Renovate's features, fix bugs, improve documentation and help answer user questions) to make this both achievable to deliver at pace, while not compromising on quality, while also putting in guardrails to make it sustainable for those of the team doing the work.

(Aside: there's a separate post I'll be writing about "what I've learned in the first 100 days" which goes into some more of the surprising and mundane things I've learned since onboarding as a maintainer)

Over the years, we've tested a few things out and worked to make the project more sustainable to work on, and to make it a more straightforward contribution process.

As noted, we have ~1500 contributions (304 of which have contributed >= 3 times) and according to GitHub's contribution stats, over the last year we've had ~3000 "Discussions daily contributors":

Count of unique users who have reacted, upvoted, marked an answer, commented, or posted in the selected period.

This makes us a pretty busy project, and there's a lot of user-reported questions - some of which are bugs, some of which are misunderstandings, and some of which are feature requests - to go through.

Something I think a lot of maintainers will relate to is the ever-present work to improve the documentation - I'm a little biased, but I'd say our docs are pretty great (compared to a lot of Open Source projects), but there's always work to do to help new users with how to use Renovate most effectively, and with new package managers (or supply chain attacks) coming out seemingly every day - it's great to see folks wanting to keep their dependencies updated without compromising security.

Optimising for the people doing the work

An interesting approach we've taken for the project is to optimise for the people doing the work (the maintainers and contributors) rather than the users.

For instance, our Code of Conduct explains this succinctly:

We are not a village square

This repository is a place where a minority show up to do the work. The vast majority benefit, for example by getting their support questions answered.

This repository is not a "village square" where all opinions are equal. Nor is everyone's time equal here.

This isn't seen as commonly in Open Source - or maybe it's not seen written as explicitly - and has helped us keep the project more sustainable over the years, as we try to temper users' expectations.

We do absolutely still treat users with respect, and expect that there's a high bar for how folks interact on the project - we're not trying to hide behind the Code of Conduct to say maintainers aren't sometimes wrong, but to clarify that we're doing a significantly high percentage of the work.

This can come as a shock to folks reading this for the first time, and I remember being surprised the first time I read it but respecting the choice and how explicit the project with it, as someone who loves the explicit over the implicit.

As such, we've found that over the years, working towards a model that allows our maintainers and contributors to feel that they have their time respected, and not feel like they're having to deal with grump or entitled users will lead to them continuing to come back.

Settling on Discussions for triage

Over the years, we've had a few attempts to make triaging more effective for the maintainers. As mentioned before, the project receives a lot of user-reported questions, the majority of which are "how do I ...?", but sometimes these lead into bug reports, or are gaps in functionality that lead to a feature request.

Originally, triaging of Discussions was solely handled by Rhys (Renovate creator), but over time as we've scaled the project by adding more maintainers and contributors into the mix, we've also worked to scale the triage + support side of the project.

About ~1 year after the project started, Rhys created the renovatebot/config-help repo, which kept questions about usage separate to the main project's issue tracker, and as triage occurred, Rhys would then create Issues to track bugs/features.

Because we'll very often have a user report "Renovate isn't doing the thing right", when this is either a strong assumption on the behalf of the user, or a very specific workflow they expect to follow, we keep them separate to confirmed bug reports. If something is a bug, we'll absolutely treat it as much, but it takes time to go from the first report to confirming what behaviour actually is, and whether Renovate is doing something it shouldn't do, given their repository and configuration.

Over the years, we adopted Issue templates to make sure that our users provided us specific information we needed to help. It doesn't necessarily mean everything will be present, or all the information is there, but it makes a great start for the triage process.

Using Issues in a separate repo worked well, but when GitHub launched Discussions in mid-2020, we were intrigued by the new area we could target for these questions.

After some testing, we decided to move the main user-reported questions into GitHub Discussions in late 2020, and then in 2021, Discussions was the required space for questions.

Generally, our usage of Discussions hasn't really changed. We've made a few changes to improve things, but the flow has stayed consistent:

• User raises a Discussion (to report a problem, or suggest a feature)
• Maintainers/contributors triage it, working asynchronously with the user to determine whether this is a question that needs an answer, or is a bug or feature request
• If it is a bug/feature, maintainers/contributors create an Issue (or if it's a straightforward piece of work, may instead create a PR instead)
• At some point in the future, someone will pick up the bug/feature - sometimes the user who raised it, sometimes another user, but more regularly a contributor or maintainer

To start with, we had 3 Discussion categories - "I have an idea", "I have an issue with a Mend-hosted app" and "Q&A", which used Discussion category forms.

In the years since, we've dropped this down to 2 categories - "Request Help" (for questions and possibly bug reports) and "Suggest an Idea" (for feature requests). We've found that issues with our Mend-hosted apps are covered under "Request Help", and generally aren't specific to the Mend-hosted apps, although for the percentage they are true, we make sure that the folks at Mend take a look.

(We have a few other categories on the project, 2 of which are only used by maintainers and 1 which is infrequently used)

We've also made a number of other changes over the years, like improving our usage of labelling, and improving our Discussion forms to make them more clear and require more structured information up-front (where possible).

Most recently, in late 2024, we decided that we'd make it super explicit that only Discussions should be used, and did what we could to stop users from raising Issues.

Towards the end of 2025 we made it even more clear that you shouldn't try and create an Issue:

There are unfortunately still a few ways that GitHub will allow someone to avoid going through the Issue form, but if users do bypass that, they'll be temporarily blocked and told why. This reminds these users that they're purposefully bypassing our requirements and we're not a fan of it, which has helped reduce folks doing this.

Periodically, we get old Discussions that had been solved (but maybe not marked as answered and/or closed) that would then have another user bump them to share their own issue. Because we don't necessarily have notifications on all the Discussions, we may miss these, as well as the fact that this new user's question may be subtly different to the answered Discussion, we ask them to move to a new Discussion.

In late 2025, we set up GitHub Actions to auto-close (and lock) any answered GitHub Discussions, 30 days after they've been answered. This has helped with forcing users to create a fresh Discussion, and getting a more appropriate answer.

Why has the Discussions/Issues split been better?

With that background context, let's talk about why we've found Discussions have been better than triaging through Issues in the last 5 years.

Separate views for triage + confirmed work to deliver

For the most part, triage continues to be now by me (as the Community Manager for the project) and Rahul, one of our trusty contributors.

This leaves our other maintainers + contributors free to work on what they see fit, and allows for them to not even need to delve into the Discussions if they so wish.

As the to-be-triaged work is all now in Discussions, a maintainer or contributor can come to the Issue tracker and pick up a piece of work that's ready to go, instead of trying to filter it down i.e. with a ready-to-work-on label.

As an aside, I'd like to clarify that other contributors and maintainers absolutely do a fair bit of triage, but they don't need to, as it's primarily handled by Rahul and I.

Expectation setting

It's now even clearer to users who've previously raised Discussions about how our triage process works:

• users raise "Request Help" Discussions if they have a question
• once a bug is confirmed (in code or documentation) or it's determined to be a gap in functionality (as it's a feature request), an Issue is created

They will understand the flow of the process, and how they can help support the work, for instance creating minimal reproduction repositories. Users who've been in the community for a bit will even raise a Discussion already with a minimal reproduction, which saves a lot of time, and makes it much more straightforward to diagnose.

As many other projects will know, a user who comes to you for the first time won't know your norms or be aligned with them. Unfortunately there's no way to solve this, but we find that repeat interactions improve.

We prefer Issues before a PR, but don't require them

There are times where sometimes you want to fix something without needing to go through the Discussion → Issue → PR process. This is most common with documentation changes, but we'll often have changes like adding presets to auto-group monorepos into a single PR.

To make it clearer as this option is possible, in August this year, we improved our Pull Request template for contributions to add a checkbox:

Please select one of the following:

• This closes an existing Issue, Closes: #
• This doesn't close an Issue, but I accept the risk that this PR may be closed if maintainers disagree with its opening or implementation

The PR author is now not-so-subtly reminded that if it's something that needs more discussion, it'll may be closed, but that they accept the risk.

Discussions can stay open and unanswered (forever?)

The number of Issues is prominently displayed at the top of the repo, which as Mitchell notes, has a psychological impact to (potential) users.

Because Discussions doesn't readily display this, it provides a bit of psychological safety for maintainers, who don't need to focus on trying to keep that number down, but can instead leave Discussions open.

For instance, we have open Discussions which are waiting for a user to provide more information. If we were using Issues, we'd likely need to set up stale bot to auto-close an Issue that hadn't had a reply in i.e. 90 days, but with Discussions, it's more socially acceptable to keep them open indefinitely.

I'm trying to spend an hour a week to go through our really old Discussions and mark as answered/closed where possible, or see if it's something that I know has changed since it was last reviewed, but there's nothing that needs this to be done, which is nice.

Label-based automation

Although not tied specifically to Discussions, it wasn't until a few months of working with GitHub Discussions that we started to invest in automating some of our triaging using Armin Sebastian's label-actions Action.

As we found that we were starting to ask the users the same things, we realised we shouldn't type the same thing each time because after all, we only have so many keystrokes left to type.

For instance, we can add the auto:reproduction label to a Discussion, and the user will be informed that they need to provide a minimal reproduction, with documentation links on how to do that.

This both saves time writing the same things time and again and keeps the message consistent between all maintainers and contributors, but also means that it's a much simpler first-pass for triage, as you don't need to craft the perfect message - an automated one is fine, if a little less personal.

Making the process work for maintainers and contributors

As noted above, we modified our Issue template to make it even more obvious that you shouldn't try and create an Issue:

Even with this big warning, we'll still see users creating them through this form (and other means that GitHub still makes available), regardless of the warning.

To avoid maintainers and contributors needing to triage these, we have a needs-discussion label auto-added to new Issues - if that gets added, the Issue will be auto-closed and locked.

But what happens when maintainers or contributors raise an Issue? In this case, we have the ability to remove that label before the Issue is raised.

It's a little annoying, but until GitHub allows restricting the creation of Issues to only collaborators on a repo, it's a bit more friction we have to take on.

Discussions (sometimes) lead to community answers

We've seen a small percentage of the time that Discussions will get an answer from a community member, instead of a maintainer of contributor, which is pretty awesome!

It's unclear if there is more likelihood of a user contributing an answer on a Discussion vs an Issue, but we've found a reasonable (but low) percentage of our Discussions are filled with users helping each other, on top of the maintainers + contributors.

"User error"

A chunk of the time, a user's "Request Help" Discussion ends up can be summarised as "the user is holding it wrong". Most of the time, this is where we have a gap in our documentation that we can work to improve and clarify the intended behaviour.

We can only make things clearer based on diversity of users and it's incredibly valuable with continued usage from new and experienced users alike, and we'll regularly work to improve our documentation off the back of a report like this.

Having these in Discussions and separate from reported bugs our Issues is useful, and although we don't categorise "this was a user error", we can guess this from reading the answer to the Discussion.

Some tips

When could this work for us?

If you have a lot of "how do I ...?" questions or first-level triage needed, and it's making it hard for maintainers to work out what work is ready to work on, it might be worth giving Discussions a go.

This isn't a "silver bullet", nor is it the only way to solve this, but it could be a good opportunity to give it a go, and see if it works for you.

I'll also say that depending on how many questions you get like this, you will want at least 1 person triaging!

Use label-based automation

As I mention above, using labels heavily is a great way of keeping things consistent while also reducing the amount of manual typing needed, so you can focus on replying with the important things.

Use templates heavily

It's likely that you'll ask for the same sorts of things from your users when they get in touch - use a template to funnel that data in.

For instance, I'll often look at the Renovate version that a user is using, and annotate it with the date that version was released, as if it's either 1-2 major versions behind or 12+ months behind, it's likely that things have changed considerably, and it's worth them re-testing.

Although we've not yet taken this as a next step, it may be possible to then wire that structured input into tooling (such as an LLM) to then feed into other suggested answers.

Wielding the banhammer

We've found that being a bit more liberal with the banning of users has helped us over the years. This isn't specific to only using Discussions, but has come out of running a very large project for many years.

These bans are mostly temporary, for instance to give them a warning if they bypass Issue creation policies, or are acting in a way that is against our Code of Conduct.

We've found that this helps remind users that they're doing something we're not happy about, on top of saying "I don't like what you're doing", and that we're taking it seriously.

In some cases, we do need to issue year-long or permanent bans, after sufficient warnings, because we're not here to work with folks who are abusive or spamming the project.

It works for us

This works for us, and a similar approach works for Ghostty - but it doesn't mean it's a "one size fits all", and it's possible it won't work for your size of project, the amount of maintainers/contributors you have, how many Q&A-style questions you have, and more.

It also doesn't mean it'll work forever, and I'm sure we'll continue to tweak this over time.

If you're interested in giving it a go, let us know how you find it as an approach.