Beitragen dürfen ist nicht beitragen können.

◆ Fakten statt Floskeln

Gedanken vom 07.10.2026

„Die Doku liegt im Repo, Beiträge sind jederzeit willkommen."
Seit zwei Jahren kam keiner.

Das Wissen ist da. Die Entwicklung kennt das Verhalten der Funktion, der Support kennt die Fälle, das Design kennt die Beschriftungen auf den Schaltflächen. Alle dürfen beitragen. Niemand tut es. Als Grund gilt: keine Zeit.

Die Hürde ist umgezogen, nicht verschwunden.

Illustration eines Arbeitsplatzes: Über einem breiten Monitor hängt ein Schild mit der Aufschrift „Du bist eingeladen, mitzumachen!“. Der Bildschirm darunter ist vollständig mit unlesbarem Code, Konfigurationsdateien und verzweigten Git-Historien gefüllt. Links davon steht eine Person mit einem Laptop im Arm und schaut unschlüssig auf den Bildschirm — die Einladung ist eindeutig, der Weg dahin nicht.

Früher hieß beitragen: eine Freigabe einholen, eine Lizenz für das Redaktionssystem bekommen, eine Mail an die Redaktion schreiben. Heute heißt es: Repository klonen, Branch anlegen, Markdown schreiben, Pull Request stellen, Review-Kommentare abarbeiten, Merge-Konflikt auflösen.

Das ist keine Öffnung. Es ist ein Tausch der Zugangsbedingung — von der Erlaubnis zum Werkzeug. Wer täglich in Git arbeitet, merkt den Unterschied nicht. Für alle anderen liegt die Schwelle höher als vorher, und sie liegt an einer Stelle, an der Nachfragen unangenehm ist: Nach dem Weg zu fragen sieht aus wie eine Lücke, die man in einem technischen Beruf nicht haben darf.

Zwei Hürden, die niemand als Hürde führt.

Die eine Stelle, die jemand korrigieren könnte, steht in einem Kapitel, das jemand anders gebaut hat. Hängt an dem Satz eine Definition? Steht dieselbe Angabe noch an drei weiteren Stellen? Wer das nicht überblickt, fasst lieber nichts an — und liegt damit nicht einmal falsch.

Der zweite Fall ist das Gegenteil und kommt dort vor, wo das Beitragen so weit geöffnet wurde, dass niemand mehr zuständig ist. Beiträge liegen wochenlang, nichts wird übernommen, niemand antwortet. Wer einmal etwas einreicht und nie erfährt, was daraus geworden ist, reicht kein zweites Mal ein.

Ablage und Eingang sind zwei verschiedene Fragen.

Docs-as-Code ist eine gute Entscheidung — für die Ablage. Versionierung, Review, Nähe zum Code: alles richtig, und nichts davon muss zurückgebaut werden. Der Fehler passiert an einer anderen Stelle: wenn aus der Ablageform die Eintrittsbedingung wird. Wer einen Hinweis hat, muss das Repository nie zu Gesicht bekommen.

Nicht: „Die Doku liegt im Repo, Beiträge sind willkommen."
Sondern: „Unten auf jeder Seite steht ‚Fehler melden’. Ein Satz reicht." — der Klick legt ein Issue an, vom Repository sieht niemand etwas.

Nicht: „Bitte einen Pull Request mit Angabe der betroffenen Seiten stellen."
Sondern: „Schick die drei Sätze in den Doku-Kanal. Wir bauen sie ein und schicken Dir die fertige Stelle."

Nicht: „Alles Weitere steht in der CONTRIBUTING-Datei."
Sondern: „Wir melden uns innerhalb von zwei Tagen zurück, was aus Deinem Hinweis geworden ist."

Das nimmt niemandem die Sorgfalt ab. Es verlegt nur den Umbau dorthin, wo der Überblick ohnehin sitzt — und lässt den Beitrag dort entstehen, wo das Wissen liegt.

Wo die Dokumentation liegt, ist eine Frage der Ablage. Wie ein Hinweis dort ankommt, ist eine andere. Wer beides zur selben Frage macht, bekommt am Ende genau die Dokumentation, die das Doku-Team allein schreiben kann.