Open-Source Project Hub

A home for one open-source project: contributor onboarding, issue triage, RFCs, release notes and read-only CI feeds.

6 categories
32 channels
10 roles
Medium

Choose a server, review what will be created or reused, then confirm. Merge keeps what you have; replace rebuilds the server. Vetox takes a safety backup first either way.

No uses yetNo views yet

Server structure

Channels

PROJECT

start-here
What the project is, where the repository and docs live, and where to ask what. Grab Release Ping below.
code-of-conduct
The code of conduct applies here exactly as it does in the repository.
contributing-guide
How to set up, how to pick an issue, how a pull request gets reviewed. Read it before your first PR.
roadmap
Where the project is going this quarter and what is deliberately not planned.
releases
Release notes, one post per version. Mention Release Ping, never @everyone.

COMMUNITY SUPPORT

questions
One thread per question: version, platform, what you ran, what happened. Tag Answered when it is.
community-chat
Talk about the project and the ecosystem around it. Questions belong in #questions.
community-showcase
Built something with the project? One thread with a link and a screenshot.
plugins-and-integrations
Third-party plugins, wrappers and integrations. Maintainers of those are welcome to hang out here.
docs-feedback
A page that is wrong, missing or confusing. Link it, say what you expected.
sponsors-loungeHidden from @everyone
For the people funding the work. Early previews and a direct line to the maintainers.

CONTRIBUTING

good-first-issues
Curated issues for a first contribution, posted by Triagers and Maintainers. Claim one by commenting on the issue itself.
issue-triage
Labelling, reproducing and closing. Triage day is weekly; the Reminder says when.
pr-review-requests60s slowmode
One message per pull request: link, what it changes, what kind of review you need. Reviews happen on the PR.
dev-discussion
Architecture, design decisions and the why behind the code. Proposals that need a decision go to #rfcs.
rfcs
One thread per proposal. Maintainers move the tag from Draft to Accepted, Rejected or Implemented.
dev-environment
Local setup problems: build failures, test flakes, tooling versions.

FEEDS

commits
Pushes to the default branch, via webhook.
ci-results
Pipeline passes and failures, via webhook.
pull-requests
Opened, reviewed and merged pull requests, via webhook.
new-issues
Every new issue as it is filed, via webhook.
dependency-alerts
Security advisories and dependency update PRs, via webhook.

VOICE

Community Hangout
Pairing Room
Office Hours
AFK

MAINTAINERS

maintainers-roomHidden from @everyone
Maintainers only: governance, funding, who gets commit rights.
core-team
Maintainers and core contributors: what is being worked on, what is blocked, who reviews what.
release-planning
The next version: scope, blockers, the date and who cuts it.
security-reportsHidden from @everyone
Embargoed vulnerability reports and the fix in progress. Nothing here leaves this channel until the advisory is public.
moderation-logHidden from @everyone
Vetox posts moderation actions and member changes here.
Maintainer Sync

Roles

Lead MaintainerAdministrator
MaintainerModerator
ModeratorModerator
Core Contributor
Triager
Contributor
Sponsor
Release Ping
Muted

Overview

Built for a single open-source project whose maintainers want a Discord that helps them ship rather than one that adds noise. Project is read-only and answers the first questions: #start-here, #code-of-conduct, #contributing-guide, #roadmap and a #releases announcement channel that only Maintainers post in. Users of the project live in Community Support, where #questions is a forum tagged Install, Configuration, Bug? and Answered, and #community-showcase collects what people built with it. Contributors work in Contributing: #good-first-issues is curated by Triagers and above, #issue-triage is where issues get labelled and reproduced, #pr-review-requests takes one message per pull request, and #rfcs is a forum whose tags track a proposal from Draft to Implemented. Feeds is a separate, muteable category for the bot: #commits, #ci-results, #pull-requests, #new-issues and #dependency-alerts, all locked to read-only. Maintainers is hidden from everyone else and splits into rooms Core Contributors can see and two they cannot, #maintainers-room and #security-reports, so an embargoed vulnerability stays with the people who can fix it. An Office Hours stage lets maintainers answer questions live, and a Sponsor role unlocks #sponsors-lounge.

When to use it

Your issue tracker is full of usage questions, your Discord has a single #general where bug reports, pull-request pings and release news all land together, and the two people who can merge get pinged for everything. This layout routes users to a tagged questions forum, contributors to triage and review channels with clear posting rights, bot output to a muteable feeds category, and the maintainers to a private room with a separate channel for security reports.

What makes it different

#rfcs is a forum whose tags carry a proposal from Draft through Under review to Accepted or Rejected.
All five bot feeds sit in one read-only category, so members mute the noise without muting the people.
#good-first-issues and #issue-triage are posting-restricted to Triagers and above, so the queue stays curated.
#security-reports is visible to Maintainers only, not to Core Contributors, so embargoes hold.
A Sponsor role unlocks #sponsors-lounge, giving sponsors a visible thank-you.

Recommended Vetox setup

Tickets
Put a ticket panel in #start-here for private security reports and account issues, so a vulnerability is never described in #questions in public.
Notifications
Point an RSS Notification at the repository's release feed and post it into #releases, so a version never ships without a note in the server.
Self-Roles
Offer Release Ping as a Self-Role in #start-here; that role is what makes a #releases mention useful instead of an @everyone.
Reminders
Schedule a weekly Reminder in #issue-triage for triage day, and one in #release-planning the week before each planned release.
Welcomer
Have the Welcomer DM new members the #contributing-guide and the #questions forum link, which cuts the number of bug reports that arrive as chat messages.

Questions

Who can post in #good-first-issues and #issue-triage?

Triagers, Core Contributors and Maintainers. Everyone else can read both, and can reply in threads on #questions or open a thread in #rfcs. The restriction keeps the beginner queue curated rather than crowd-sourced.

Do Core Contributors see everything the Maintainers do?

Almost. They see #core-team, #release-planning and #moderation-log, but #maintainers-room and #security-reports are hidden from them by a channel-level overwrite. Adding someone to the security channel is a deliberate act, not a side effect of a promotion.

What if the project has more than one repository?

Keep one Feeds category and point every repository's webhooks at the same five channels; the message itself names the repository. Split #questions with a tag per repository rather than adding channels.

Common mistakes

Letting the commit and CI webhooks post into the channel people talk in, which trains everyone to mute the whole server.
Giving every contributor the maintainers' room, so the one channel that needs discretion for security reports has none.
Using a text channel for RFCs, where a design discussion is lost the moment the next one starts.

Consider instead

SDK Developer Community The code is a company's commercial API or SDK with a DevRel team rather than a volunteer-run project.
Dev Team Internal The repository is private and everyone in the server is on payroll.

Do you have any doubts?

Our team is there for you

0.0k

Servers

Commands

Users

Languages