Background
In the celebration thread (#1603), @profvjreddi raised the question of how to improve communication and reduce the notification gap between contributors. I suggested that a dedicated Slack or Discord server for contributors could help -- one focused specifically on the development ecosystem (TinyTorch, MLSysim, Labs, Kits, StaffML) rather than the broader community server that serves many purposes at once.
This is a formal proposal to build and maintain that server.
What I'm proposing
A contributor-focused Discord server for developers actively working on the cs249r ecosystem. Not a general learner/reader community -- a dev space.
Suggested channels:
#announcements -- maintainer broadcasts (releases, PRs merged, breaking changes)
#tinytorch -- TinyTorch dev discussion
#mlsysim -- MLSysim dev discussion
#labs -- Lab content bugs, answer key issues, new lab ideas
#kits -- Kit development
#staffml -- StaffML discussion
#prs-and-reviews -- PR coordination, reviewer requests
#dev-meetings -- agenda, notes, and follow-ups from periodic sync calls
#off-topic -- general dev chat
What I'd own:
- Server setup, channel structure, roles, permissions
- Bot configuration (GitHub webhook for new issues/PRs, if wanted)
- Moderation and keeping it focused on dev work
- Ongoing maintenance
Ownership model
I'd like to propose co-ownership with @profvjreddi rather than just handing over admin. Concretely:
- @profvjreddi holds Owner role -- final say on structure, membership, and direction
- I hold Admin role -- day-to-day build, moderation, and maintenance work
- Any core maintainer can be elevated to Moderator as the server grows
This way the server stays under the project's authority while I carry the operational load.
Dev meetings
One thing a Discord server enables that GitHub doesn't: periodic contributor sync calls. A short voice/video standup (even 30 minutes every few weeks) where active contributors can:
- Sync on what's in-flight across sub-projects
- Unblock PRs that have been stuck in review
- Discuss direction for upcoming milestones (Vol. 2 labs, TinyTorch modules, etc.)
- Onboard new contributors faster than async comments allow
The #dev-meetings channel would hold agendas beforehand and written summaries after, so async contributors stay in the loop.
Why Discord beats GitHub Discussions for a dev team
GitHub Discussions were built for community Q&A, not active development coordination. Discord is purpose-built for exactly this:
- Notifications that actually work -- no more missed threads; Discord pings are reliable and instant
- Real-time unblocking -- a 2-minute chat in
#prs-and-reviews resolves what would take 3 days of async comment threads
- Threaded conversations per sub-project -- TinyTorch, MLSysim, Labs each get their own focused space instead of everything collapsing into one feed
- Built-in voice/video -- dev meetings, pair debugging, onboarding calls without needing a separate Zoom/Meet link
- Search that works for devs -- Discord's search is fast and scoped per channel; good enough for "what did we decide about X last week"
- Better contributor onboarding -- new contributors can ask quick questions without opening a formal issue; reduces friction significantly
- Roles and permissions -- maintainers, contributors, and readers can have different access levels, something GitHub Discussions can't do
GitHub Discussions still has value for formal decisions that need a permanent public record. The hybrid works well: Discord for coordination and speed, Discussions only when something needs to be documented for posterity.
Ask
@profvjreddi -- if you're open to this, I can have the server set up and ready to share within a day. You'd hold Owner, I'd hold Admin, and we build it together from there. Happy to adjust the structure or ownership model to whatever fits your constraints.
Background
In the celebration thread (#1603), @profvjreddi raised the question of how to improve communication and reduce the notification gap between contributors. I suggested that a dedicated Slack or Discord server for contributors could help -- one focused specifically on the development ecosystem (TinyTorch, MLSysim, Labs, Kits, StaffML) rather than the broader community server that serves many purposes at once.
This is a formal proposal to build and maintain that server.
What I'm proposing
A contributor-focused Discord server for developers actively working on the cs249r ecosystem. Not a general learner/reader community -- a dev space.
Suggested channels:
#announcements-- maintainer broadcasts (releases, PRs merged, breaking changes)#tinytorch-- TinyTorch dev discussion#mlsysim-- MLSysim dev discussion#labs-- Lab content bugs, answer key issues, new lab ideas#kits-- Kit development#staffml-- StaffML discussion#prs-and-reviews-- PR coordination, reviewer requests#dev-meetings-- agenda, notes, and follow-ups from periodic sync calls#off-topic-- general dev chatWhat I'd own:
Ownership model
I'd like to propose co-ownership with @profvjreddi rather than just handing over admin. Concretely:
This way the server stays under the project's authority while I carry the operational load.
Dev meetings
One thing a Discord server enables that GitHub doesn't: periodic contributor sync calls. A short voice/video standup (even 30 minutes every few weeks) where active contributors can:
The
#dev-meetingschannel would hold agendas beforehand and written summaries after, so async contributors stay in the loop.Why Discord beats GitHub Discussions for a dev team
GitHub Discussions were built for community Q&A, not active development coordination. Discord is purpose-built for exactly this:
#prs-and-reviewsresolves what would take 3 days of async comment threadsGitHub Discussions still has value for formal decisions that need a permanent public record. The hybrid works well: Discord for coordination and speed, Discussions only when something needs to be documented for posterity.
Ask
@profvjreddi -- if you're open to this, I can have the server set up and ready to share within a day. You'd hold Owner, I'd hold Admin, and we build it together from there. Happy to adjust the structure or ownership model to whatever fits your constraints.