em—dash

Roadmap Public plan No theatre

Build the ecosystem in public.

This roadmap explains what exists now, what should improve next, and what emdashcms.org should not claim until the community earns it with real installs, real authors, and real maintenance.

The current path.

WordPress.org is a large public project surface. EmDash is earlier, so the roadmap stays smaller and more explicit about what is real.

Now

Make the registry useful and inspectable.

  • Plugin and theme directories with public metadata, install counts, downloads, audit state, and author signals.
  • Start, Learn, Support, Developer, Community, About, transparency, status, and digest surfaces for people and crawlers.
  • Fail-closed review, listing reports, security policy, moderator docs, and source links for public scrutiny.

Next

Tighten the author and reviewer loop.

  • Sharper publisher guidance around duplicate projects, release fixes, support links, licensing, and screenshots.
  • More review explanations that help authors fix rejected bundles without weakening the scanner rules.
  • Better public examples for manifests, capabilities, install prompts, badges, feeds, OpenAPI, MCP, and llms.txt.

Soon after

Prove the ecosystem with real work.

  • Seed the catalog with real extensions and themes that can be installed, reviewed, reported, and updated end to end.
  • Collect verified usage notes from real EmDash sites before opening a public showcase.
  • Turn repeated support questions into docs before introducing a central forum or heavier community process.

Later

Scale only what the community can maintain.

  • Contributor roles for docs, moderation, scanner rules, release review, support routing, and marketplace infrastructure.
  • A central discussion/support space only when author links, docs, reports, and GitHub issues stop being enough.
  • A richer showcase, pattern library, or events surface only after there is real public activity to point at.

Guardrails.

A roadmap is only useful if it resists vanity surfaces. These rules keep the project honest while it is small.

This is not a promise of dates

Items move when code, docs, review coverage, and maintainers are ready. A public roadmap is a map of intent, not a release contract.

Security can interrupt the plan

Scanner fixes, report handling, revocations, abuse response, and policy corrections outrank catalog growth.

No fake showcase

emdashcms.org should not invent adoption, sites, testimonials, support forums, events, or community scale before those things exist.

Public issue trails first

Work that affects publishers or site owners should land through visible issues, pull requests, docs, changelog entries, or transparency notes.

Move it forward.

The roadmap should change when contributors prove a better path with code, docs, testing, reports, or real extension work.

Publish or test an extension

The fastest way to improve the roadmap is to run the marketplace flow on real plugins and themes.

Improve a public surface

Docs, install copy, error states, status explanations, and reviewer notes are all useful first contributions.

Open a focused issue

Use GitHub when the roadmap misses a practical problem in the registry, dashboard, API, docs, or audit flow.

Check current health

Use live status and transparency data to see what the marketplace is actually doing now.

Get involved Read transparency