EmDash, Long-Term: Building Through Community

[CacheMeOwside]

Hey everyone, 👋

This is not urgent, but I wanted to share something with the hope that we can sustain our momentum and energy over the long run.

I've been contributing to EmDash for a while now, and have been thinking about what makes a CMS survive long-term. WordPress may not be the best CMS out there, but I believe it's still here because of its community. The product matters, and the people around it matter just as much.

I have a couple of ideas on how we could build and sustain a stronger contributor community alongside the engineering work. WordPress does this well through structured, punctual, and recurring collaboration, like their scheduled Slack meetings with clear agendas and shared vision.

Here are a few ideas we can consider:

1. Bi-weekly issue scrub on Discord/Slack: Maintainers & contributors triage issues together, label priorities, and loosely align on priorities for the next release. Not expecting anyone to commit to deadlines (I know that's unrealistic for open-source contributors with day jobs), but just having a shared big picture.

2. Pre-release testing sessions: Before a major release, we can have a coordinated window where people, including non-technical users like editors and content creators, can try the new features/fixes, and flag anything that feels off. This gives people who aren't writing code a meaningful way to contribute, and gives maintainers extra eyes on real-world usage.

Why this matters:

CMSes come and go. The ones that stick around are the ones where people feel ownership and connection beyond just using the product. If we set a vision to build a community that nourishes both the product, and the contributors, that will help EmDash not just survive, but thrive.

Looking further ahead

When EmDash grows even more, we could explore local meetups too. Networking, sharing ideas, bad coffee, and a whole lot of live demos. The whole experience. Just planting the seed here.

Would love to hear what fellow EmDashers think, especially from the maintainers on what would be helpful.

[ascorbic]

Hi @CacheMeOwside,
I like this a lot. I think some sort of regular thing on DIscord would be good, though I'm not sure how it would work best. Any idea welcome.

[MA2153]

Discord has native "events" capability that supports recurring events. You just create a voice channel then a recurring event.

[CacheMeOwside]

+1 to @MA2153's suggestion.

Discord's Scheduled Events seems like a good way to get this rolling. We can schedule an event for a text channel.

I'd also love to help with issue triaging, and do a first pass on reproducing bugs, adding labels, flagging critical issues and duplicates, so our scheduled sessions can be focused.

It would also be useful, if we can create a project board (or milestone view) so there's a shared place to see what's planned, queued, or blocking. I'm happy to help here as well.

Also, it would be great if we can announce the recurring sessions on the Cloudflare blog to reach a wider audience (technical folks and also content creators/editors), to make these sessions sustainable in the long-run.

[masonjames]

I'm pumped about emdash's prospects and would love to participate here as well.

[ascorbic]

Ok, this is great. Let's make this happen. As always with these sort of thing, timezones are our main enemy here. The best solution there is usually to alternate times, but mid afternoon UTC is usually the best compromise.

@CacheMeOwside you seem to have the most well-formed ideas on this. What sort of structure do you think would be best for the first one? Discussions? Reviewing PRs and issues? Live coding? Planning? A mix?

[CacheMeOwside]

@ascorbic I'm excited about this! I have a few ideas in mind. I'd like to give those a bit more thought and share them here over the weekend.

[CacheMeOwside]

@ascorbic 👋
Building on the bi-weekly triage idea:

Session structure

For the first few sessions, I'd lean toward keeping it simple, something like a 45–60 min issue triage + lightweight planning round.

While Discord's Scheduled Events feature only supports one-time events, there are some Discord plugins like Apollo and Make which help create recurring events. We can share the event links/calendar on the Cloudflare blog, as a "Call for Contributors" post, and reach a wider audience.

The structure of the sessions could be something like this:

1. Walking through open issues, and assigning clearer labels (component, bug, feature, good-first - for new contributors).
2. Contributors can escalate any critical issues/features to maintainers, which can then be discussed and prioritized during the session by assigning release milestones to them. This way, those critical issues can be picked by on priority by contributors.
3. Updating the project board, if we can create one. Roadmap visibility especially matters here. It keeps contributors excited, helps people align their work, and gives the community a sense that the project is actively moving forward together.

Live PR reviews and live coding are great in their own right, but since they can happen independently outside the scheduled sessions, we may not need to fit them in, at least not right away.

Like you said, mid afternoon UTC time might work well for most contributors.

I see that we already have these labels created. We could add more, and start assiging those to issues. These labels could also mirror as Discord channels. A single general channel works fine today, but as traffic grows, topic threads may start colliding.

Component-based Discord channels (like Admin, Core, Cloudflare, Auth, Plugins, etc. ) would give contributors a clearer place to ask questions, share progress, and follow conversations relevant to the area they are working on.

---

Slightly tangential ideas, but related to scaling the community side. Here are a few things WordPress did well early on that we can learn from.

Encouraging contributors

One thing WordPress does exceptionally well is making contributors feel visible and appreciated. Every WordPress Core release publicly acknowledges contributors on the official release pages, and even small contributions are recognized. That gives contributors something they can proudly share, add to resumes, and feel genuinely connected to.

Recognition matters a lot in open source, especially for newer contributors. EmDash could adopt something similar over time:

• Contributor mentions in release notes
• Community shoutouts on the blog
• Highlighting first-time contributors
• Recognizing testing, documentation, and community support contributions, not just code

Small acknowledgements compound, and they're one of the best things a project can do to encourage contributors.

Giving trusted contributors real ownership

WordPress organizes development into components and lets consistent contributors become trusted maintainers of specific areas, giving them commit access, real ownership and responsibility.

Contributors who consistently show commitment, good judgment, and collaboration help guide the direction of those areas alongside maintainers. The idea is real ownership creates much stronger investment.

This is probably for later stages, but worth thinking about early. For the near future, it might help to delegate triage permissions (labels, milestones, etc.) to a few regular contributors. If those duties stay entirely on maintainers, the volume of mentions, and notifications they'd need to handle would scale quickly, as EmDash gains popularity.

The rationale behind this:

There's a line from song Keep Talking by Pink Floyd that fits open-source well: "All we need to do is make sure we keep talking".

WordPress understood this in its early years. The project was active not just from an engineering perspective, but from a community one. There were always discussions happening on blogs, Slack conversations, roadmap discussions, contributor meetings, release notes, experimentation, feedback, local meetups, and WordCamps.

That constant communication keeps the ecosystem alive and the contributors emotionally invested. Recognition, coordination, and ownership are all really mechanisms for giving people reasons to keep talking about EmDash, and to each other, over years.

EmDash being this early is actually a huge advantage, since community culture can still be shaped intentionally from the beginning. Strong open-source projects are built through code, as well as through shared momentum, communication, trust, and contributor ownership over time.

Would love to hear how others see this, and if there's anything you'd add. I am happy to help with any of these tasks.

[MA2153]

Thank you for sharing. FYI this is inaccurate:

While Discord's Scheduled Events feature only supports one-time events, there are some Discord plugins like Apollo and Make which help create recurring events.

Discord natively supports recurring events:

[MA2153]

I agree with the general direction of those suggestions, but I am going to point out specific things I disagree with.

I see that we already have these labels created. We could add more, and start assiging those to issues. These labels could also mirror as Discord channels. A single general channel works fine today, but as traffic grows, topic threads may start colliding.

Component-based Discord channels (like Admin, Core, Cloudflare, Auth, Plugins, etc. ) would give contributors a clearer place to ask questions, share progress, and follow conversations relevant to the area they are working on.

IMO this will only make things worse. The current #contributing channel is barely active. I don't see a compelling reason to divide it more. Even big projects like Astro don't have separate channels for contributors by area.

Giving trusted contributors real ownership
WordPress organizes development into components and lets consistent contributors become trusted maintainers of specific areas, giving them commit access, real ownership and responsibility.

Contributors who consistently show commitment, good judgment, and collaboration help guide the direction of those areas alongside maintainers. The idea is real ownership creates much stronger investment.

This is probably for later stages, but worth thinking about early. For the near future, it might help to delegate triage permissions (labels, milestones, etc.) to a few regular contributors. If those duties stay entirely on maintainers, the volume of mentions, and notifications they'd need to handle would scale quickly, as EmDash gains popularity.

I am not sure discussing governance is appropriate at this early stage. But I agree that maintainers should try to delegate tasks when they can to move development faster (which I think is your general point). Commit access seem too much, at least for main.

Side note: This may have gone a little beyond what Matt asked for (ideas for first meeting) 😄

Once again, thank you motivating this discussion!

[Rimander]

Excellent initiative. I believe focusing on community organization is the right path, as it is a fundamental pillar for the success of any open-source project.

It would be valuable to analyze the strengths and weaknesses of WordPress. This would help us establish a solid and transparent roadmap, building confidence for those considering EmDash who need clarity regarding the platform's future.

[masonjames]

Thanks again to @CacheMeOwside for kicking off this discussion.

A regularly scheduled issue scrub sounds great to me, especially if the first few sessions stay focused and lightweight: reviewing open issues, checking unanswered discussions, reproducing bugs where possible, and identifying where maintainer feedback is needed.

One useful starting point might be discussion hygiene. Current guidance encourages most requests to begin as discussions, but there are several open discussions with no comments or feedback yet. These are easy to find with the is:open comments:0 filter. Thoughtful first responses, clarifying questions, and light categorization would go a long way toward making new contributors and users feel heard.

Bug reproduction also seems like a strong fit for these sessions. Contributors could help confirm whether an issue is reproducible, gather environment details, identify duplicates, and surface the items that need maintainer attention. I know I’ve gone through open issues looking for opportunities to contribute and would personally appreciate guidance on which issues are useful to investigate. (@ascorbic has been incredibly kind with feedback and the early responses encouraged my continued contributions)

Over time, consistent participation in this kind of work could also help establish simple community guidelines for issue/discussion triage: when to label something, when to ask for more detail, when to escalate, and how to provide helpful feedback to first-time posters. The current CONTRIBUTING.md focuses mostly on development contributions, so it may be worth eventually expanding it to include non-code contribution paths as well.

I also like the idea of encouraging content creation outside the repository: blog posts, short YouTube demos, walkthroughs, and examples that help new users find their bearings. That kind of material can make the project feel more approachable while also increasing awareness. I hope to lead by example in this area in the near future.

I see a real opportunity here to make EmDash easier to contribute to, not just by writing code, but by helping people understand where their effort would be useful. I’d be happy to participate and help with issue/discussion review, bug reproduction, or lightweight triage during these sessions.

[ascorbic]

The first community call will be happening this Wednesday! Join us on Discord: https://discord.gg/9f8rhDuY?event=1503436803976335410