Mitwirken

Nützliche Beiträge fangen fast immer damit an, dass jemand auf etwas stößt: Eine Seite verhält sich anders als erwartet, eine Einstellung tut nicht, was das Handbuch nahelegt, ein Satz in der Dokumentation lässt zwei Deutungen zu, ein Schritt setzt Zugänge voraus, die es nicht gibt. Genau daraus entsteht ein besseres Projekt — und ein solches Problem klar zu beschreiben, ist schon ein Beitrag.

Sie müssen nichts reparieren, um zu helfen. Eine genaue Schilderung dessen, was Sie erwartet haben, was stattdessen passiert ist und welchem Dokument Sie gefolgt sind, ist oft wertvoller als ein fertiger Patch, weil sie zeigt, worin die Arbeit eigentlich besteht.

Ein Beitrag ist ein Angebot, und die Menschen, die das Projekt pflegen, entscheiden, was sie annehmen. Eine Änderung kann übernommen, angepasst, zurückgestellt oder abgelehnt werden — weil sie nicht zu dem passt, wofür das Projekt da ist, weil sie eine bewusst gezogene Grenze verschieben würde, weil sie nicht korrekt ist oder weil schlicht noch niemand Zeit hatte, sie anzusehen.

Was das nicht berührt, ist Ihre eigene Kopie: Die Lizenz gibt Ihnen bereits das Recht, die Software für sich zu ändern und Ihre eigene Fassung weiterzugeben. Dafür brauchen Sie niemandes Zustimmung, und Ihre Website profitiert auch dann davon, wenn Ihre Verbesserung nicht in das Projekt aufgenommen wird. Sie zurückzugeben ist das, was sie für alle anderen nützlich macht — deshalb tun es Menschen, und deshalb ist niemand dazu verpflichtet.

Erwartetes und tatsächliches Verhalten. Die Differenz ist der Fehler. „Sprache umgestellt, der Umschalter blieb aber auf Englisch“ sagt etwas; „die Website ist kaputt“ sagt nichts.

Wo es auftritt. Die Foundation-Version, die die Website verwendet, die Seite oder Route und — wenn es nur eine Sprache betrifft — die Sprache selbst. Ein Fehler in einer Sprache und einer in allen Sprachen sind unterschiedliche Arbeiten.

Was Sie geändert haben. Ob es sich um ein neues Foundation-Projekt oder eine angepasste Website handelt: Ein Fehler der Plattform und einer der darauf gebauten Website sind verschiedene Fälle.

Der Wortlaut. Fehlermeldungen sind oft der kürzeste Weg zur Ursache; eine Nacherzählung lässt genau die Einzelheiten weg, die zählen.

Was Sie bereits versucht haben. Das erspart doppelte Arbeit und zeigt manchmal, dass die Dokumentation in die falsche Richtung geführt hat — auch das ist ein Fehler, nur einer in der Dokumentation.

Wenn Sie technisch mitwirken möchten und nicht nur etwas melden wollen, stehen die Erwartungen des Projekts im Repository, und sie lohnen die Lektüre, bevor Sie Zeit in eine Änderung investieren. Drei Dokumente tragen zusammen, was das Projekt verlangt: die Betriebsregeln für Coding-Agenten beschreiben, wie in einer Foundation-Installation gearbeitet wird; die Architektur erklärt Schichten, Grenzen und Abhängigkeitsrichtung; das Validierungshandbuch legt fest, was ein Nachweis zeigen muss — einschließlich der Regel, dass keine Fähigkeit über der Stufe behauptet werden darf, die Implementierung und Tests tatsächlich belegen.

Diese Dokumente sind die Instandhaltungsdisziplin des Projekts und keine Beitragsordnung. Sie sagen nichts darüber, was Sie mit Ihrer eigenen Kopie tun dürfen — das regelt die Lizenz. Sie beschreiben, wie dieser Codebestand zusammenhält, und sie sind ehrlich über die verfügbare Kapazität: Eine kleine Zahl von Maintainern prüft, was eintrifft, und eine Änderung, die eigene Tests mitbringt, das gelöste Problem klar beschreibt und keine sachfremden Änderungen enthält, wird weit eher übernommen als eine, die das Verstehen anderen überlässt.