GitHub Discussions versus Discourse

Some projects get by just fine with only communicating in the issue tracker and commits (or pull requests). Most projects need to talk more. They need to discuss governance issues, get community feedback on feature ideas, address user questions, plan events, and more. There’s no end to the number of venues to have these conversations, but for many projects, it comes down to one choice: GitHub Discussions versus Discourse.

Both of these platforms have their advantages and disadvantages. As I wrote in the appendix to Program Management for Open Source Projects, there’s no right tool, just the right tool for your community. I have used both of these tools, and can recommend both for different needs.

GitHub Discussions

GitHub Discussions is a relatively simple forum add-on available to GitHub repositories. Project administrators can add it with a simple checkbox. As a result, it requires no additional infrastructure and participants can use their existing GitHub account. You can easily convert issues to discussion threads or discussion threads into issues — some projects even require a discussion thread as a prerequisite for issue creation.

GitHub Discussions is tightly integrated into the rest of GitHub, as you might expect. This means it’s easy to tag users, cross-reference issues/commits, watch for new activity, and so on. On the other hand, this tight integration isn’t helpful if your project isn’t tightly integrated into GitHub. Depending on the nature of your project, users who come to ask questions may not even have a GitHub account.

Discourse

Discourse (not to be confused with the chat platform Discord) is an open source discussion platform. You can self-host it or pay for hosting from Discourse or their partners. Because it’s designed to be a community communication tool, it offers a lot more flexibility. This includes both themes as well as plugins and other configuration options.

Discourse includes a concept of “trust levels” that can automatically move users up through greater privileges based on a history of prosocial behavior. Moderators and access control can be adjusted on a per-category basis, which is particularly helpful for the largest of communities.

Discourse has a mailing list mode so that users who prefer can treat it like a mailing list. It also supports private conversations so that moderators and administrators can discuss concerns candidly.

GitHub Discussions versus Discourse: pick your winner

How you decide which tool to use will depend on several factors:

• Other tooling. If your project’s infrastructure is entirely contained on GitHub, then GitHub Discussions is probably the best choice for you. If you don’t use GitHub at all, then Discourse makes more sense. In general, the more non-GitHub tooling you have (CI systems, for example), the more Discourse makes sense on this axis.
• Infrastructure resources and budget. GitHub Discussions has zero (financial) cost to your community, so that’s a good fit for the vast majority of open source projects. Discourse requires you to have a budget to pay for hosting or the resources and skills to self-host. In my experience, self-hosting is fairly easy — if you have people in the community who can do it.
• Project purpose. Communities that primarily build software — and mostly have development-oriented contributors — benefit from the tight integration that GitHub Discussions offers. If the community is not software-focused (e.g. if it’s an affinity group, advocacy organization, etc), then Discourse may be a better choice.
• Target audience. If the people who will be participating in the conversation are primarily contributors or developer-like people, then GitHub Discussions can be a good fit. If you’re expecting general computer users — who may or may not even know what GitHub is — then Discourse is probably more approachable.
• Community size. Discourse has a lot of flexibility and power to handle thousands of users. When you have ones or dozens of users, the simplicity of GitHub Discussions can be more appealing.

Ultimately, there’s no simple answer. You have to compare the tools across the axes above (plus any other technical or philosophical requirements you have).

This post’s featured photo by Volodymyr Hryshchenko on Unsplash.