Erfahre, wie du eine Open‑Source‑Projekt‑Website planst, erstellst und pflegst, die Community‑Beiträge mit klaren Workflows, Review‑Schritten und verlässlichem Publishing willkommen heißt.
Bevor du ein Theme auswählst oder eine Homepage skizzierst, sei konkret, wofür die Seite da ist. Open‑Source‑Websites versuchen oft, alles auf einmal zu sein — Doku‑Portal, Marketing‑Seite, Community‑Hub, Blog, Spenden‑Funnel — und schaffen am Ende keines davon gut.
Schreibe die wichtigsten 1–3 Aufgaben auf, die die Website erfüllen muss. Häufige Beispiele:
Wenn du den Zweck der Website nicht in einem Satz erklären kannst, werden Besucher das auch nicht können.
Liste deine Hauptzielgruppen und die „first click“, die jede Gruppe machen soll:
Eine nützliche Übung: Schreibe für jede Zielgruppe die drei wichtigsten Fragen auf (z. B. „Wie installiere ich?“, „Wird das aktiv gepflegt?“, „Wo melde ich einen Bug?“).
Wähle einfache Metriken, die mit deinen Zielen verbunden sind und realistisch zu verfolgen:
Liste explizit auf, was die Seite nicht tun wird (vorerst): kundenspezifische Web‑Apps, komplexe Account‑Systeme, schwere Integrationen oder maßgeschneiderte CMS‑Features. Das schützt die Zeit der Maintainer und hält das Projekt auslieferbar.
Teile Inhalte in zwei Bereiche:
Diese Entscheidung beeinflusst später Tools, Review‑Workflow und Contributor Experience stark.
Eine Community‑Website wird schnell unordentlich, wenn du nicht entscheidest, was auf die Seite gehört und was im Repository bleiben sollte. Bevor Tools und Themes ausgewählt werden, einigt euch auf eine einfache Struktur und ein klares Content‑Modell — so wissen Mitwirkende, wo sie Dinge hinzufügen, und Maintainer, wie sie sie prüfen.
Halte die primäre Navigation absichtlich simpel. Eine gute Default‑Sitemap für ein Open‑Source‑Projekt ist:
Wenn eine Seite nicht in eine dieser Kategorien passt, ist das ein Hinweis, dass es sich entweder um etwas Internes handelt (besser im Repo aufgehoben) oder um einen neuen Inhaltstyp.
Nutze das README für Entwickler‑essentials: Build‑Anleitung, lokales Dev‑Setup, Tests und kurzer Projektstatus. Verwende die Website für:
Diese Trennung verhindert doppelte Inhalte, die auseinanderdriften.
Weise Content‑Owner pro Bereich zu (Docs, Blog/News, Übersetzungen). Ownership kann eine kleine Gruppe mit klarer Review‑Verantwortung sein, kein einzelner Gatekeeper.
Schreibe eine kurze Tone‑ und Style‑Guide, freundlich für eine globale Community: einfache Sprache, konsistente Terminologie und Hinweise für nicht‑englische Muttersprachler.
Wenn dein Projekt Releases hat, plane früh für versionierte Dokus (z. B. „latest“ plus unterstützte Versionen). Es ist deutlich einfacher, die Struktur jetzt zu entwerfen als nach mehreren Releases nachzurüsten.
Der Stack sollte es einfach machen, Tippfehler zu korrigieren, neue Seiten hinzuzufügen oder Dokus zu verbessern, ohne selbst Build‑Engineer werden zu müssen. Für die meisten Open‑Source‑Projekte heißt das: Markdown‑first, schneller lokaler Setup und ein reibungsloser PR‑Workflow mit Previews.
Wenn du dich erwartest, schnell an Layout und Navigation zu iterieren, prototypisiere die Site‑Erfahrung bevor du dich an einen langfristigen Stack bindest. Plattformen wie Koder.ai können helfen, eine Docs/Marketing‑Site per Chat zu skizzieren, eine funktionierende React‑UI mit Backend zu generieren und den Quellcode zu exportieren — nützlich, um Informationsarchitektur und Beitrag‑Flows ohne Wochen Setup zu erkunden.
Wie gängige Optionen für mitwirkungsfreundliche Dokus und Projektseiten abschneiden:
mkdocs.yml anpassen und einen Befehl laufen lassen. Suche ist meist stark und schnell.Wähle Hosting, das Preview‑Builds unterstützt, damit Mitwirkende ihre Änderungen live sehen können:
Wenn möglich, mache den Standardweg: „PR öffnen, Preview‑Link erhalten, Review anfordern, mergen.“ Das reduziert Maintainer‑Hin‑und‑Her und stärkt das Vertrauen der Mitwirkenden.
Füge eine kurze docs/website-stack.md (oder einen Abschnitt in README.md) hinzu, der erklärt, was ihr gewählt habt und warum: wie die Seite lokal läuft, wo Previews erscheinen und welche Arten von Änderungen ins Website‑Repo gehören.
Ein einladendes Repo macht den Unterschied zwischen „Drive‑by‑Edits“ und nachhaltigen Community‑Beiträgen. Ziel ist eine Struktur, die leicht zu navigieren ist, für Reviewer vorhersehbar und lokal einfach zu starten.
Halte webbezogene Dateien gruppiert und klar benannt. Ein üblicher Ansatz ist:
/
/website # Marketing‑Seiten, Landing, Navigation
/docs # Dokumentationsquelle (Referenz, Guides)
/blog # Release Notes, Ankündigungen, Stories
/static # Bilder, Icons, Download‑Assets
/.github # Issue‑Templates, Workflows, CODEOWNERS
README.md # Repo‑Übersicht
Wenn dein Projekt bereits Anwendungscode hat, erwäge die Seite in /website (oder /site) zu platzieren, damit Mitwirkende nicht raten müssen, wo sie anfangen sollen.
/website hinzufügenErstelle /website/README.md, das beantwortet: „Wie kann ich meine Änderung previewen?“ Halte es kurz und copy‑paste‑freundlich.
Beispiel‑Quickstart (an dein Stack anpassen):
# Website quickstart
## Requirements
- Node.js 20+
## Install
npm install
## Run locally
npm run dev
## Build
npm run build
## Lint (optional)
npm run lint
Gib auch an, wo sich Schlüsselfiles befinden (Navigation, Footer, Redirects) und wie man eine neue Seite hinzufügt.
Vorlagen reduzieren Format‑Debatten und beschleunigen Reviews. Füge einen /templates‑Ordner hinzu (oder dokumentiere Vorlagen in /docs/CONTRIBUTING.md).
/templates
docs-page.md
tutorial.md
announcement.md
Eine minimale Docs‑Seiten‑Vorlage könnte so aussehen:
---
title: "Seitentitel"
description: "Ein‑Satz‑Zusammenfassung"
---
## What you’ll learn
## Steps
## Troubleshooting
Wenn du Maintainer für spezifische Bereiche hast, füge /.github/CODEOWNERS hinzu, damit die richtigen Personen automatisch als Reviewer angefragt werden:
/docs/ @docs-team
/blog/ @community-team
/website/ @web-maintainers
Bevorzuge eine kanonische Konfigurationsdatei pro Tool und füge kurze Kommentare hinzu, die das „Warum“ erklären. Ziel ist, dass ein neuer Mitwirkender sicher ein Menüelement ändern oder einen Tippfehler beheben kann, ohne dein gesamtes Build‑System lernen zu müssen.
Eine Website zieht eine andere Art von Beiträgen an als der Code‑Basis: Textkorrekturen, neue Beispiele, Screenshots, Übersetzungen und kleine UX‑Änderungen. Wenn dein CONTRIBUTING.md nur für Entwickler geschrieben ist, verlierst du viel potenzielle Hilfe.
Erstelle (oder teile aus) ein CONTRIBUTING.md, das sich auf Website‑Änderungen konzentriert: wo Inhalte leben, wie Seiten generiert werden und was „Done“ bedeutet. Füge eine kurze Tabelle mit „Common Tasks“ hinzu (Tippfehler beheben, neue Seite hinzufügen, Navigation aktualisieren, Blogpost veröffentlichen), damit Neulinge in Minuten loslegen können.
Wenn du bereits tiefere Anleitungen hast, verlinke klar aus CONTRIBUTING.md (z. B. ein Walkthrough unter /docs).
Sei explizit, wann ein Issue zuerst geöffnet werden soll und wann direkte PRs willkommen sind:
Füge eine „good issue template“‑Snippet hinzu: welche Seiten‑URL, welche Änderung, warum sie Lesern hilft und ggf. Quellen.
Die meiste Frustration entsteht durch Schweigen, nicht durch Feedback. Definiere:
Eine leichte Checkliste verhindert Hin‑und‑Her:
Eine Community‑Website bleibt gesund, wenn Mitwirkende genau wissen, was passiert, nachdem sie einen PR öffnen. Ziel ist ein Workflow, der vorhersehbar, wenig reibungsanfällig und sicher ist.
Füge eine Pull Request‑Vorlage hinzu (z. B. .github/pull_request_template.md), die nur das fragt, was Reviewer brauchen:
Diese Struktur beschleunigt Reviews und zeigt Mitwirkenden, wie „gut“ aussieht.
Aktiviere Preview‑Deployments, damit Reviewer die Änderung als echte Seite sehen können. Das ist besonders nützlich für Navigations‑Updates, Styling und Layout‑Bugs, die in einem Textdiff nicht sichtbar sind.
Gängiges Muster:
Nutze CI, um leichte Gates auf jedem PR laufen zu lassen:
Fail fast mit klaren Fehlermeldungen, damit Mitwirkende Probleme ohne Maintainer‑Eingriff beheben können.
Dokumentiere eine einfache Regel: wenn ein PR genehmigt und nach main gemerged wird, deployed die Seite automatisch. Keine manuellen Schritte, keine geheimen Kommandos. Beschreibe das genaue Verhalten in /contributing, damit die Erwartungen klar sind.
Wenn deine Plattform Snapshots/Rollbacks unterstützt (einige Hosts tun das, genauso wie Koder.ai beim Deploy), dokumentiere, wo man den „last known good“ Build findet und wie man ihn wiederherstellt.
Deploys können fehlschlagen. Dokumentiere ein kurzes Rollback‑Playbook:
Eine Community‑Website bleibt einladend, wenn Seiten zusammengehören. Ein leichtes Designsystem hilft Mitwirkenden, schneller zu arbeiten, reduziert nitpicky Reviews und hält Leser orientiert — auch wenn die Seite wächst.
Definiere ein kleines Set an Seitentypen und halte dich daran: Doku‑Seite, Blog/News‑Post, Landing‑Page und Referenzseite. Für jeden Typ entscheide, was immer erscheint (Titel, Zusammenfassung, zuletzt aktualisiert, Inhaltsverzeichnis, Footer‑Links) und was nie erscheinen sollte.
Setze Navigationsregeln, die Klarheit wahren:
sidebar_position oder weight).Anstatt Mitwirkende zu bitten „das konsistent aussehen zu lassen“, gib ihnen Bausteine:
Dokumentiere diese Komponenten in einer kurzen „Content UI Kit“‑Seite (z. B. /docs/style-guide) mit Copy‑&‑Paste‑Beispielen.
Definiere das Minimum: Logo‑Nutzung (wo es nicht verzerrt oder umgefärbt werden darf), 2–3 Kernfarben mit zugänglichem Kontrast und ein bis zwei Schriften. Ziel ist, „gut genug“ einfach zu machen, nicht Kreativität zu unterdrücken.
Einigt euch auf Konventionen: feste Breiten, konsistente Abstände und Namensmuster wie feature-name__settings-dialog.png. Bevorzuge Quellformate für Diagramme (z. B. Mermaid oder editierbare SVGs), damit Updates keinen Designer benötigen.
Füge eine einfache Checkliste zur PR‑Vorlage: „Gibt es dafür schon eine Seite?“, „Passt der Titel zur Sektion?“, „Erzeugt das eine neue Top‑Level‑Kategorie?“ Das verhindert Content‑Sprawl und fördert trotzdem Beiträge.
Eine Community‑Website funktioniert nur, wenn Menschen sie tatsächlich nutzen können — mit assistierender Technik, bei langsamen Verbindungen und über Suche. Behandle Accessibility, Performance und SEO als Defaults.
Beginne mit semantischer Struktur. Verwende Überschriften in der Reihenfolge (H1 auf der Seite, dann H2/H3) und überspringe keine Ebenen nur für größere Schrift.
Für Nicht‑Text‑Inhalte erfordere sinnvollen Alt‑Text. Ein einfacher Merksatz: Wenn ein Bild Informationen vermittelt, beschreibe es; wenn es rein dekorativ ist, nutze leeres Alt (alt="") damit Screenreader es ignorieren.
Prüfe Farbkontrast und Fokuszustände in deinen Design‑Tokens, damit Mitwirkende nicht raten müssen. Sorge dafür, dass jedes interaktive Element per Tastatur erreichbar ist und Fokus nicht in Menüs, Dialogen oder Code‑Beispielen gefangen wird.
Optimiere Bilder standardmäßig: auf die maximale Anzeigengröße skalieren, komprimieren und moderne Formate bevorzugen, wenn dein Build das unterstützt. Vermeide große clientseitige Bundles auf hauptsächlich textlastigen Seiten.
Halte Drittanbieter‑Skripte minimal. Jedes zusätzliche Widget erhöht die Ladezeit und kann die Seite für alle verlangsamen.
Setze auf die Caching‑Defaults deines Hosts (z. B. immutable Assets mit Hashes). Wenn dein SSG es unterstützt, generiere minifizierte CSS/JS und inline nur wirklich kritische Teile.
Gib jeder Seite einen klaren Titel und eine kurze Meta‑Beschreibung, die dem liefert, was die Seite wirklich bietet. Nutze saubere, stabile URLs (keine Daten, außer sie sind wichtig) und konsistente kanonische Pfade.
Generiere eine Sitemap und eine robots.txt, die das Indexieren öffentlicher Dokus erlaubt. Wenn du mehrere Doku‑Versionen publizierst, vermeide Duplicate Content, indem du eine Version als „current“ kennzeichnest und klar auf andere verweist.
Füge nur Analytics hinzu, wenn du die Daten auch wirklich nutzt. Falls ja, erkläre, was gesammelt wird, warum und wie man sich abmelden kann, auf einer dedizierten Seite (z. B. /privacy).
Füge schließlich einen klaren Lizenzhinweis für Website‑Inhalte hinzu (separat von der Code‑Lizenz falls nötig). Platziere ihn im Footer und im Repo‑README, damit Mitwirkende wissen, wie ihre Texte und Bilder wiederverwendet werden dürfen.
Die Kernseiten deiner Website sind die „Rezeption“ für neue Mitwirkende. Beantworten sie die offensichtlichen Fragen schnell — was das Projekt ist, wie man es ausprobiert und wo Hilfe gebraucht wird — dann wandern mehr Leute von Neugier zur Aktion.
Erstelle eine verständliche Übersicht, die erklärt, was das Projekt macht, für wen es ist und wie Erfolg aussieht. Füge ein paar konkrete Beispiele und einen kurzen „Is this for you?“‑Abschnitt hinzu.
Ergänze eine Quickstart‑Seite, die auf Momentum optimiert ist: ein Weg zum ersten Erfolg, mit Copy‑&‑Paste‑Befehlen und einem kurzen Troubleshooting‑Block. Wenn die Einrichtung plattformabhängig ist, halte den Hauptpfad kurz und verlinke zu detaillierten Guides.
Vorgeschlagene Seiten:
Eine einzige /contribute‑Seite sollte verweisen auf:
/docs/contributing)Halte es konkret: nenne 3–5 Aufgaben, die du diesen Monat tatsächlich erledigt haben möchtest, und verlinke zu den exakten Issues.
Veröffentliche die Essentials als First‑Class‑Seiten, nicht versteckt im Repo:
/community/meetings)Füge /changelog (oder /releases) mit einem konsistenten Format hinzu: Datum, Highlights, Upgrade‑Hinweise und Links zu PRs/Issues. Templates reduzieren Maintainer‑Aufwand und machen community‑geschriebene Notes leichter reviewbar.
Eine Showcase‑Seite kann motivieren, aber veraltete Listen schaden der Glaubwürdigkeit. Wenn du /community/showcase hinzufügst, setze eine leichte Regel (z. B. „quartalsweise prüfen“) und biete ein kleines Formular oder PR‑Template zur Einreichung an.
Eine Community‑Site bleibt gesund, wenn Updates einfach, sicher und lohnend sind — auch für erstmalige Mitwirkende. Ziel ist, "Wo klicke ich?"‑Reibung zu reduzieren und kleine Verbesserungen lohnend zu machen.
Füge einen deutlichen „Diese Seite bearbeiten“‑Link auf Dokus, Guides und FAQs hinzu. Verlinke direkt auf die Datei im Repo, sodass ein PR‑Flow mit minimalen Schritten geöffnet wird.
Halte den Linktext freundlich (z. B. „Tippfehler beheben“ oder „Diese Seite verbessern“) und platziere ihn oben oder unten im Inhalt. Verlinke dort auch auf das Contributing (z. B. /contributing).
Lokalisierung funktioniert am besten, wenn die Ordnerstruktur Fragen auf einen Blick beantwortet. Ein gängiger Ansatz:
Dokumentiere Review‑Schritte: wer Übersetzungen freigibt, wie mit partiellen Übersetzungen umgegangen wird und wie veraltete Übersetzungen getrackt werden. Erwäge, am Seitenanfang einen kurzen Hinweis zu setzen, wenn eine Übersetzung hinter der Quellsprache zurückliegt.
Wenn dein Projekt Releases hat, mache deutlich, welche Doku Nutzer lesen sollten:
Auch ohne vollständige Versionierung hilft ein kleiner Banner oder Selector, der den Unterschied erklärt und Verwirrung reduziert.
Lege FAQs im gleichen Content‑System wie deine Dokus ab (nicht in Issue‑Kommentaren). Verlinke sie prominent (z. B. /docs/faq) und ermutige Leute, Fixes beizutragen, wenn sie auf ein Problem stoßen.
Lade ausdrücklich zu Quick Wins ein: Tippfehler, klarere Beispiele, aktuelle Screenshots und "Das hat bei mir so funktioniert"‑Troubleshooting‑Notizen. Diese sind oft der beste Einstieg für neue Mitwirkende — und verbessern die Website konstant.
Wenn du Anreize für Schreib‑ und Pflegearbeit schaffen willst, sei transparent, was belohnt wird und warum. Einige Teams bieten kleine Sponsorships oder Credits; Koder.ai hat ein „earn credits“‑Programm als Inspirationsquelle.
Eine community‑getriebene Seite sollte einladend wirken — aber nicht auf Kosten einiger weniger, die ständig aufräumen. Ziel ist, Wartung vorhersehbar, leicht und teilbar zu machen.
Wähle eine einprägsame Cadence und automatisiere, was möglich ist.
Wenn du diesen Plan in /CONTRIBUTING.md dokumentierst (kurz), können andere mit Vertrauen einspringen.
Content‑Streitigkeiten sind normal: Ton, Benennung, was auf der Homepage steht oder ob ein Blogpost „offiziell“ ist. Vermeide lange Debatten, indem du festhältst:
Es geht weniger um Kontrolle als um Klarheit.
Ein Kalender muss nicht fancy sein. Erstelle ein einzelnes Issue (oder eine einfache Markdown‑Datei) mit bevorstehenden:
Verlinke es von Blog/News‑Planungsnotizen, damit Mitwirkende sich selbst Aufgaben zuweisen können.
Tracke wiederkehrende Website‑Aufgaben (Tippfehler, veraltete Screenshots, fehlende Links, Accessibility‑Fixes) und label sie „good first issue“. Füge klare Akzeptanzkriterien hinzu wie „eine Seite aktualisieren + Formatter laufen lassen + Ergebnis screenshotten".
Lege einen kurzen Abschnitt “Common local setup issues” in deine Docs. Beispiel:
# clean install
rm -rf node_modules
npm ci
npm run dev
Nenne auch die 2–3 häufigsten Stolperfallen (falsche Node‑Version, fehlende Ruby/Python‑Dependency, Port bereits in Benutzung). Das reduziert Rückfragen und spart Maintainer‑Energie.
Schreibe eine Ein-Satz-Zweckaussage und notiere dann die wichtigsten 1–3 Aufgaben, die die Seite erfüllen muss (zum Beispiel: Dokumentation, Downloads, Community, Updates). Wenn eine Seite oder Funktion diese Aufgaben nicht unterstützt, behandle sie vorerst als Non-Goal.
Ein einfacher Check: Wenn du den Zweck der Seite nicht in einem Satz erklären kannst, werden die Besucher es auch nicht können.
Liste deine Hauptzielgruppen auf und definiere den ersten Klick, den du von jeder Gruppe erwartest:
Schreibe für jede Zielgruppe die drei wichtigsten Fragen auf, mit denen sie ankommen (z. B. „Wird das gepflegt?“, „Wo melde ich einen Bug?“) und sorge dafür, dass die Navigation diese schnell beantwortet.
Beginne mit einer bewusst „langweiligen“ Sitemap, die der Denkweise der Nutzer entspricht:
Wenn neuer Inhalt nicht passt, ist das ein Zeichen dafür, dass du entweder einen neuen Inhaltstyp brauchst (selten) oder die Information besser im Repo aufgehoben ist.
Behalte den Developer-Workflow im README und die öffentliche Onboarding‑Information auf der Website.
Nutze das Repo-README für:
Nutze die Website für:
Wähle einen Stack, der „Markdown-first“-Bearbeitungen und schnelle lokale Vorschauen unterstützt.
Gängige Optionen:
Strebe den Standardweg PR → Preview → Review → Merge an.
Praktische Vorgehensweise:
main deployt“)Das verringert Rückfragen bei Reviews und gibt Mitwirkenden Sicherheit, dass ihre Änderung richtig aussieht.
Nutze Struktur und Templates, um Formatdiskussionen zu reduzieren.
Hilfreiche Basics:
Schreibe es „website-first“ und konkret.
Enthalten sein sollten:
Halte es so kurz, dass Menschen es tatsächlich lesen — und verlinke bei Bedarf auf detailliertere Anleitungen.
Behandle Barrierefreiheit, Performance und SEO als Standard, nicht als Feinschliff:
alt="") für dekorative BilderFühre automatisierte Checks ein (Linkchecker, Markdown‑Lint, Formatierer), damit Reviewer das nicht manuell tun müssen.
Ermögliche einfache Updates und mache Wartung vorhersehbar.
Für Community-Updates:
/docs/faq)/docs/en/..., /docs/es/...Für Maintainer‑Nachhaltigkeit:
Diese Trennung verhindert duplizierte Inhalte, die auseinanderdriften.
Wähle das einfachste Werkzeug, das deine heutigen Bedürfnisse erfüllt, nicht das flexibelste, das du später vielleicht brauchst.
/website, /docs, /blog, /.github/website/README.md mit Copy‑&‑Paste-Kommandos zum lokalen Starten/templates-Ordner (Docs‑Seite, Tutorial, Ankündigung)CODEOWNERS, um Reviews nach Bereich zu routenDas Ziel ist, dass jemand einen Tippfehler beheben oder eine Seite hinzufügen kann, ohne Build‑Experte werden zu müssen.
/privacy‑Seite und erkläre, was warum gesammelt wird