How to Set Up a Discord Server for an Open-Source Project

Many open-source projects have a Discord server: it's where users ask for help, contributors coordinate, and maintainers share what's coming. The challenge is keeping it useful without letting it swallow your issue tracker or your maintainers' time.

Here's a layout that works for most projects, from a handful of contributors to a large community.

The layout

📌 START HERE

• #welcome: what the project is, links to the docs, repository and code of conduct
• #rules: your code of conduct, summarized
• #announcements: releases and important news (read-only)

🆘 HELP

• #help: questions from users (a forum channel works well)
• #show-and-tell: things people built with the project

🛠️ CONTRIBUTING

• #contributing: how to get started, good first issues
• #dev: development discussion
• #design: proposals and bigger changes
• #docs: documentation work

💬 COMMUNITY

• #general, #off-topic

🔒 MAINTAINERS

• #maintainers: private coordination
• #security: for handling security reports privately

🔊 VOICE

• 🔊 Community call
• 🔊 Pairing

Roles

Role	Purpose
Maintainer	Core team. Manage Messages, Manage Threads; sees the Maintainers category
Contributor	Has had a contribution merged. Recognition, and maybe access to a contributors' channel
Helper	Regulars who answer questions. Manage Threads in #help
Release Pings	Opt-in role for release announcements
@everyone	Users and visitors

Contributor and Helper roles are great motivation. Make them visible with a color and show them separately in the member list.

Keep chat from replacing the issue tracker

Discord is fast, but it's also forgetful: messages scroll away and aren't searchable from outside the server. Set some ground rules:

• Bugs go to the issue tracker. Put a link in #help's description and pin it. When a bug turns up in chat, ask the person to open an issue and link it.
• Decisions get written down. If something is decided in #design or on a call, record it where the rest of the project can find it.
• Answer common questions in the docs, then link to them.

Help that scales

Use a forum channel for #help, with tags like question, bug?, installation and solved. Each question gets its own thread, and people can search earlier ones before asking. See forum channels explained.

Add slowmode to #help if it gets busy, and a short template in the forum's guidelines: version, what you tried, what happened. See slowmode explained.

Security reports

Never ask people to report security issues in a public channel. Say in #welcome and #help how to report them privately: your project's security policy, a private email, or a private channel only maintainers can see.

Release announcements

Make #announcements an announcement channel so downstream projects and fans can follow it into their own servers. Ping a Release Pings role rather than @everyone. See announcement channels explained.

Mistakes to avoid

1. Maintainers answering every question. Recognize helpers and let them carry the load.
2. Support in DMs. Public answers help the next person.
3. Too many channels for a small project. Start with #help, #dev and #general.
4. Public security reports. Give a private route.

Build it with Cordary

Tell Cordary about your project, something like "an open-source server with releases, a help forum, contributing and dev channels, and maintainer and contributor roles", and it drafts the whole layout for you to review. It can also write your welcome and rules posts. Nothing changes until you approve.