Wie EmDash gebaut wird und wie du mitmachst

Am 9. Oktober 2026 hat Matt Kane, der Project Lead von EmDash, PR #3808 gemergt. Der Titel „Establish governance and contribution processes“ klingt nach Bürokratie, und es sind auch über 4000 geänderte Zeilen in 53 Dateien. Seitdem steht im Repository, wer bei EmDash was entscheidet, wie ein Feature ins Projekt kommt und was ein Bot darf. Vorbereitet wurde das öffentlich in drei Discussions (#3747, #3782, #3807).

Ich bin einer der fünf Maintainer, die in der neuen GOVERNANCE.md stehen. Hier zeige ich dir, wer entscheidet, welchen Weg eine Änderung nimmt, was der Bot emdashbot macht und wo du einsteigen kannst, auch ohne Core-Code. Wie aus einem Tweet zwei Releases wurden, hat Kevin in seinem Artikel über Feedback erzählt. Hier geht es um das Regelwerk dahinter. Alle Zahlen stammen von GitHub und npm, Stand 15. Oktober 2026.

Auf EmDash bin ich gestoßen, als ich ein passendes CMS für meine Kunden gesucht habe. Mit dem Projekt konnte ich mich sofort identifizieren, und die Community war freundlich. Im August habe ich meine ersten Pull Requests beigetragen. Danach wurde ich ins Project Team eingeladen, das damals noch Triage hieß, und später ins Team der Maintainer, als es gegründet wurde.

Kurz zu den Begriffen: Ein Issue meldet auf GitHub einen Fehler, ein Pull Request (PR) schlägt eine Änderung vor, und „mergen“ heißt, sie ins Projekt zu übernehmen. Die Discussions sind das Forum des Projekts. Willst du gleich loslegen, spring zum Abschnitt „Mitmachen ohne Core-Code“.

Wer bei EmDash entscheidet

GOVERNANCE.md kennt drei Rollen:

Project Lead ist Matt Kane. Er entscheidet, wenn sich die Beteiligten nicht einigen, und ernennt nach Rücksprache mit den Maintainern neue Mitglieder. Ihn selbst ernennt Cloudflare.
Maintainer sind derzeit fünf: Matt Kane, Noah Nguyen Pham, @MA2153, Kevin Kyburz und ich. Wir geben Pull Requests frei, mergen sie und entscheiden im Rahmen der Regeln, ohne auf den Project Lead zu warten.
Project Team sind regelmäßige Mitwirkende, die Issues einordnen und Pull Requests reviewen, aber nicht mergen. Außer uns Maintainern gehören derzeit drei Personen dazu.

Diese Liste ist maßgeblich, nicht die Rechte auf GitHub. Ob eine Freigabe zählt, prüft die Automatisierung anhand genau dieser Liste. Ein Bot steht nie darauf. Ins Project Team kommst du, wenn du über längere Zeit mehrfach Nützliches beigetragen hast, mit Code, Doku, Reviews, Triage oder Support. Meist schlägt dich ein Maintainer vor, auf Discord aktiv sein musst du dafür nicht. Alle Rollen sind ehrenamtlich und ohne Mindeststunden. Wer etwa sechs Monate nichts beigetragen hat, wird privat angefragt, und Rechte, die niemand mehr braucht, werden entzogen, weil ein verwaistes Konto mit Merge-Rechten ein Sicherheitsrisiko ist.

Diskutiert wird öffentlich. Produktrichtung, Architektur, Roadmap und Reviews gehören in Discussions, Issues und Pull Requests. Discord darf helfen, aber nie der einzige Ort sein, an dem eine Entscheidung steht. Ein Kanal fürs Team dient nur der Absprache, wer was übernimmt. Ganz privat bleibt nur, was öffentlich nicht geht, etwa Sicherheitslücken vor dem Fix, Moderationsfälle oder Zugangsdaten.

Dass Cloudflare den Project Lead ernennt, finde ich verständlich, denn EmDash ist ein Projekt von Cloudflare. Trotzdem haben wir Maintainer viel Freiheit, und die Führung erlebe ich bisher als gut. Ob dich EmDash technisch an Cloudflare bindet, hat Kevin im Faktencheck zum Lock-in geprüft.

Welcher Weg für welche Änderung

Welchen Weg eine Änderung nimmt, legt CONTRIBUTING.md fest:

Ein Fehler kommt als Issue. Die Vorlage verlangt Beschreibung, Schritte zum Nachstellen, Umgebung und, bei Fehlern in der Oberfläche, einen Screenshot, und ein Mensch muss den Fehler selbst nachgestellt haben. Siehst du den Fix, öffnest du gleich einen Pull Request, möglichst mit einem Test, der ohne den Fix scheitert.
Ein Wunsch gehört in die Ideas-Discussions, eine Frage in die Q&A.
Doku, Tests, Übersetzungen und kleine Aufräumarbeiten gehen direkt als Pull Request, ebenso Refactorings ohne Verhaltensänderung und Performance-Verbesserungen mit Messwerten.
Ein Feature braucht seit dem 3. Oktober 2026 erst einen angenommenen Entwurf.

Dieser Entwurf ist ein Design-PR, der nur Dateien unter proposals/ ändert (proposals/README.md). Für ein abgegrenztes Feature reicht ein kurzer Feature-Plan, den ein Maintainer freigibt. Berührt die Änderung etwa eine öffentliche API, gespeicherte Daten, die Plugin-Schnittstelle, die Sicherheit oder die Rückwärtskompatibilität, braucht sie einen RFC (Request for Comments), also einen ausführlichen Entwurf. Der beginnt mit einer Ideas-Discussion und braucht jemanden, der den Vorschlag vorantreibt (Champion), einen Maintainer als Sponsor, zwei weitere Maintainer, die zustimmen, die Annahme durch den Project Lead und meist mindestens sieben Tage öffentliche Prüfung. Einen Entwurf braucht jedes Feature, ausdrücklich auch von Maintainern und Cloudflare-Angestellten.

Der erste Entwurf, der nach dem neuen Verfahren angenommen wurde, ist ein Feature-Plan von Noah Nguyen Pham für eine lesbare Versionsgeschichte. Der Design-PR (#4127) wurde am 13. Oktober gemergt, die Umsetzung (#4136) zwei Tage später.

Einen Pull Request öffnest du nur, wenn mindestens eins davon zutrifft: Du nutzt EmDash und bist selbst auf das Problem gestoßen, du pflegst ein Werkzeug, das EmDash verwendet, und die Änderung betrifft genau diese Anbindung, oder ein Maintainer hat die Änderung vorab abgesegnet. Was zutrifft, kreuzt du in der PR-Vorlage an. Änderungen im Vorbeigehen, um die niemand gebeten hat, spekulative Refactorings und Massen-PRs wie „alle Lint-Warnungen beheben“ werden geschlossen.

Vom Pull Request zum Release

Die PR-Vorlage ist Pflicht, ein PR ohne ausgefüllte Vorlage wird automatisch geschlossen. Dann laufen drei Dinge an. Die CI prüft Typen, Lint und Tests, bei deinem ersten Beitrag aber erst, wenn jemand aus dem Team deinen Code gelesen und freigegeben hat. emdashbot schreibt ein Review. Und pkg.pr.new baut aus dem PR ein Vorschaupaket, das du per npm i in deiner eigenen Site testen kannst.

Gemergt werden darf laut MAINTAINING.md, wenn die Pflicht-Checks grün sind, blockierende Review-Threads gelöst sind und ein menschlicher Maintainer, der nicht Autor ist, den aktuellen Stand freigegeben hat. Ein neuer Commit danach braucht eine neue Freigabe. Änderungen an Governance, Release-Automatisierung und anderen sicherheitskritischen Pfaden brauchen zwei. Das gilt für alle, auch für den Project Lead. Wo ein PR steht, zeigen Labels wie review/needs-review oder review/approved, die eine Automatisierung setzt.

Ändert dein PR ein veröffentlichtes Paket, gehört ein Changeset dazu, eine kleine Markdown-Datei, die du mit pnpm changeset anlegst. Sie legt fest, ob die Version als Patch oder Minor steigt, und ihr Text landet wörtlich im Changelog. Schreib ihn deshalb für Leute, die EmDash betreiben, nicht für Leute, die den Diff kennen (Leitfaden). Für Doku, Tests und CI brauchst du keins.

Die Changesets sammelt ein Workflow in einem Release-PR namens ci: release. Wird der gemergt, landen die Pakete auf npm. Nach 1.0 am 28. September sind so 1.1.0 am 1. Oktober, 1.2.0 in der Nacht zum 7. Oktober und 1.3.0 am 15. Oktober erschienen. Was in 1.3 steckt, steht in Kevins Artikel zu EmDash 1.3.

Der Sweep räumt auf

Bis vor Kurzem blieben Pull Requests einfach liegen. Der PR-Sweep, ein Workflow, sollte alte PRs markieren und schließen, hat aber nie einen geschlossen, weil seine eigenen Labels und Kommentare die Uhr jedes Mal zurücksetzten. Laut PR #3927 hatten 44 offene PRs eine Warnung bekommen, geschlossen wurde keiner. Ein Probelauf der neuen Regeln über die 169 offenen PRs ergab vorab 7 Erinnerungen ans CLA, 22 Warnungen und keine Schließung. Seit dem 9. Oktober gelten neue Regeln, und der Sweep läuft alle sechs Stunden:

Veraltet ist ein PR nur, solange er auf dich als Autor wartet, also wenn ein Maintainer Änderungen verlangt hat, wenn er Merge-Konflikte hat oder noch ein Entwurf ist. Nach 14 Tagen ohne menschliche Aktivität kommt eine Warnung, sieben Tage später wird er geschlossen. Kommentare von Bots zählen nicht als Aktivität.
Wartet ein PR auf ein Review, wird er nie als veraltet markiert. Design-PRs werden wegen Inaktivität nie geschlossen.
Ohne CLA läuft eine eigene Uhr: Erinnerung nach einem Tag, geschlossen nach sieben Tagen, egal wie aktiv der PR ist.

Mit CLA ist dabei das Contributor License Agreement von Cloudflare gemeint, nicht signierte Commits oder ein DCO-Sign-off. Bei deinem ersten PR fragt der CLA Assistant danach, und du unterschreibst mit einem Kommentar, der genau diesen Satz enthält: I have read the CLA Document and I hereby sign the CLA. Der Code selbst steht unter der MIT-Lizenz.

Ein geschlossener PR ist nicht verloren. Du öffnest ihn wieder oder kommentierst, dann öffnet ihn jemand aus dem Project Team.

emdashbot: viel Arbeit, keine Freigabe

emdashbot hat laut TRIAGE.md zwei Aufgaben. Er reviewt Pull Requests, sobald einer geöffnet oder aus dem Entwurf geholt wird, Design-PRs ausgenommen. Nach neuen Commits holt ihn erst das Label bot:review zurück. Bei einem Feature vergleicht er die Umsetzung mit dem angenommenen Entwurf. Und er arbeitet an Issues. Neue Issues von außen ordnet er ein, setzt Labels und fragt nach, wenn etwas fehlt. Einen offensichtlichen, risikoarmen Fix darf er gleich bauen. Er legt ihn auf einen Branch bot/fix-<n>, öffnet einen PR und bittet die Person, die den Fehler gemeldet hat, das Vorschaupaket auszuprobieren. Alles Tiefere wartet auf einen Maintainer.

Maintainer lenken ihn mit Kommentaren. @emdashbot triage ordnet ein Issue ein, investigate sucht nur die Ursache, work baut einen Fix. needs changes mit einer Begründung schickt ihn in eine neue Runde, decline lehnt ab, und mit take over übernimmt ein Mensch, bis er mit hand back zurückgibt. Hast du den Fehler gemeldet, antwortest du nach dem Test des Vorschaupakets einfach im Issue oder schreibst selbst needs changes. Issues von Mitgliedern der Organisation fasst er erst an, wenn ein Maintainer triage schreibt, denn die haben sich das Problem meist schon angesehen. Diese Regel kam mit einem PR von mir (#3424).

Vom 15. September bis 14. Oktober wurden 63 PRs gemergt, die emdashbot geöffnet hatte, zwölf davon Release-PRs, fast alle anderen Fixes. Fehlerfrei läuft er nicht. Matt Kane hat ausgewertet, was der Bot vom 27. September bis 7. Oktober an Issues getan hat (PR #3983). Zu dem Zeitpunkt hingen 30 offene Issues fest, und 85 Läufe waren gescheitert oder abgebrochen. Seitdem hört der Bot nach drei Versuchen auf, seinen eigenen PR zu reparieren, und schreibt, was noch scheitert, und er legt nicht von selbst los, wenn schon ein Mensch einen PR zum Issue offen hat.

Die wichtigste Grenze steht in MAINTAINING.md: Bot-Reviews helfen dem Menschen, der freigibt, ersetzen ihn aber nie, und auch jeder PR des Bots braucht einen Maintainer. TRIAGE.md zählt selbst auf, was der Bot nicht kann: eine echte Site durchklicken, beurteilen, ob eine Änderung überhaupt passieren soll, und jemandem, der zum ersten Mal etwas beiträgt, zeigen, dass ein Mensch den Beitrag gelesen hat.

Meine Erfahrung als Maintainer: Bei kleineren Issues ist der Bot gut. Nicht für jedes Issue findet er schon eine Lösung, aber er nimmt uns viel Arbeit ab und macht die Entwicklung schneller.

Was die KI-Regeln verlangen

Mit #3808 kam auch eine AI_POLICY.md. Beiträge mit KI-Hilfe sind willkommen, die Verantwortung bleibt beim Menschen. Du nennst in der PR-Vorlage jedes Modell und Werkzeug, liest den kompletten Diff, lässt die Tests laufen und probierst die Änderung selbst aus. Ein Agent öffnet nur einen PR, den du einzeln freigegeben hast. Agenten, die sich selbst Arbeit suchen, sind nicht erlaubt.

Gespräche bleiben menschlich. Agenten kommentieren weder auf Issues noch in Discussions noch auf Design-PRs. Auf anderen PRs dürfen sie nur zweierlei, jeweils mit einer Signatur samt Modellname: fremden Code reviewen, wenn ein Mensch genau dieses Review anstößt, und dir auf deinem eigenen PR beim Antworten auf Reviews helfen. Ausgenommen ist nur emdashbot bei seiner Arbeit an Issues. Hilfe bei Rechtschreibung oder Übersetzung deines eigenen Textes ist überall in Ordnung.

Wie groß die Community ist

Zum Release von 1.0 hatten laut Kevins Feedback-Artikel über 175 Leute mitgearbeitet. Am 15. Oktober zählt die Contributor-Liste auf GitHub 206 Konten, dazu vier Bots.

Das Tempo ist hoch. Vom 15. September bis 14. Oktober wurden 583 Pull Requests gemergt, fast 20 am Tag, geöffnet von 59 Personen und emdashbot. Seit dem 28. September, dem Tag von 1.0, waren es 318 PRs von 42 Personen und dem Bot.

Verteilt ist die Arbeit aber ungleich. Von den 583 PRs kamen 397 von vier Leuten: Matt Kane (137), mir (101), Kevin (92) und Noah Nguyen Pham (67). Mit den 63 PRs des Bots sind das fast vier Fünftel. Die übrigen 55 Personen haben zusammen 123 PRs beigetragen, 41 von ihnen einen oder zwei.

Für so wenige Leute ist das viel Arbeit. Deshalb lade ich alle ein, die Lust haben: Werde Contributor, und wenn es passt, kommst du ins Project Team.

Mitmachen ohne Core-Code

Für die Beiträge in diesem Abschnitt musst du weder TypeScript können noch die Architektur kennen.

Übersetzungen

In locales.ts, aus der alle Sprachlisten des Admins kommen, stehen neben Englisch 33 Sprachen, 31 davon kannst du im Adminbereich auswählen. Anfang Oktober kamen zwei dazu: Kroatisch (#3934), am 8. Oktober gemergt und gleich auswählbar, und Italienisch (#4026), das ich am selben Abend gemergt habe. Italienisch ist noch ausgeschaltet, weil erst ein kleiner Teil übersetzt ist. Eine neue Sprache schaltet ein Maintainer frei, wenn genug fertig ist. Auch Koreanisch steht derzeit auf aus.

Wie weit jede Sprache ist, zeigt das Lunaria-Dashboard. Die Texte liegen als PO-Dateien unter packages/admin/src/locales/<sprache>/messages.po. Du füllst die leeren msgstr-Einträge, lässt Platzhalter wie {email} stehen, prüfst das Ergebnis im laufenden Admin und öffnest einen PR mit einem Titel wie i18n(de): …. Die Schritte stehen in Translating EmDash.

Zwei Regeln sind streng. Übersetzungs-PRs öffnen nur Leute, die die Sprache als Muttersprache oder fließend sprechen. Eine KI darf vorübersetzen, aber ein fließender Sprecher prüft jeden Eintrag im laufenden Admin. Und lieber lässt du einen Eintrag leer, als ihn falsch zu übersetzen, dann zeigt der Admin eben den englischen Text. Beim italienischen PR habe ich deshalb als Erstes gefragt, ob der Autor Muttersprachler ist. Er ist es.

Die deutsche Übersetzung pflege ich. Ich habe deutsche Kunden, und in der deutschen Fassung waren viele Einträge offen, also habe ich sie nachgezogen. Der erste PR (#2400) hat 373 leere Einträge auf einmal gefüllt. Seitdem übersetze ich einmal pro Woche nach, was neu dazukommt, denn das Projekt entwickelt sich schnell. Seit August 2026 sind so acht Übersetzungs-PRs von mir gemergt worden. Der letzte, #4084, hat am 13. Oktober die 142 Einträge nachgezogen, die am 10. fehlten, vor allem rund um den neuen Video-Block und die Menüs im Editor. Am 15. Oktober fehlen auf main schon wieder 146, die meisten für die neue Versionsgeschichte. Oft geht es dabei um Begriffe: Manche müssen idiomatisch übersetzt werden statt Wort für Wort, und jeder soll überall gleich heißen. Seit #4084 heißt es bei Plugins „Update“ statt „Aktualisierung“, passend zu „Update-Status“. „Aktualisierung“ bleibt für Inhalte und Daten.

Doku

Die Doku unter docs.emdashcms.com liegt im selben Repository unter docs/, und jede Seite verlinkt auf ihre Quelldatei auf GitHub. Doku-PRs gehen direkt, ohne Design-PR und ohne Changeset, auf Englisch und nach einem eigenen Styleguide. Oft sind es Kleinigkeiten. Anfang Oktober habe ich vier Seiten korrigiert, deren Schritte nicht mehr zum Adminbereich passten, etwa beim WordPress-Import (#3947 bis #3950).

Bugreports und Triage

Ein guter Bugreport ist schon ein Beitrag. Nimm die Vorlage, nenn Version, Adapter (Node oder Cloudflare) und Schritte von einem frischen Projekt aus, und häng bei allem, was die Oberfläche betrifft, einen Screenshot an. Sicherheitslücken meldest du nicht öffentlich, sondern über das Formular für Sicherheitsmeldungen.

Fremde Issues kannst du genauso voranbringen. TRIAGE.md schlägt vor, ein Bug-Issue ohne Priorität zu nehmen, den Fehler nachzustellen und aufzuschreiben, was du gefunden hast, auch wenn es nur „bis hier kam ich“ ist. Sprichst du eine Sprache fließend, ist dein Review auf einem Übersetzungs-PR besonders wertvoll, denn da kommen weder der Bot noch Maintainer ohne die Sprache weiter. Mit genau solcher Arbeit wächst man ins Project Team hinein.

Plugins

Neue Plugins kommen nicht in den Core, du veröffentlichst sie selbst. Plugins für die Sandbox lädst du mit emdash-plugin publish in die Registry hoch (Doku), mit einem Atmosphere-Konto wie dem von Bluesky als Herausgeber. Native Plugins verteilst du über npm. Was die Sandbox schützt und was nicht, hat Kevin im Artikel zur Plugin-Sandbox gemessen.

Discord

Im öffentlichen Discord ist fürs Mitmachen der Kanal #contributing gedacht. Nach deinem ersten gemergten PR lädt dich emdashbot ein, dein GitHub-Konto dort mit /link zu verbinden, dann bekommst du die Rolle „Contributor“.

Fazit

Jede Änderung gibt ein Mensch frei, auch die des Bots und die des Project Lead. Ein Feature braucht erst einen Entwurf, und was auf seinen Autor wartet, schließt der Sweep nach drei Wochen, ohne CLA schon nach einer. emdashbot nimmt viel Routine ab, entscheidet aber nichts. Für dich heißt das: Einen Bugfix, eine Korrektur in der Doku oder eine Übersetzung schickst du direkt als PR, wenn du das Problem selbst hattest oder die Sprache sprichst. Ein Feature fängt mit einer Idee in den Discussions an, nicht mit Code.

Wir freuen uns über Hilfe in allen Bereichen, und es muss nicht immer Code sein. Wer im Discord oder in den GitHub-Discussions mitredet, hilft genauso.