Stand der Beitragsregeln
Status
Offen. Diese Seite hält fest, welche Regeln für Beiträge in diesem Bestand belegbar gelten und welche nicht bestehen. Sie wird abgelöst, sobald die offenen Punkte entschieden sind.
Ausgangslage
Der Bereich Projekte führt Mitwirkende bis zum Einreichen einer Änderung. Ab dort greifen Regeln, die ein Projekt sich gibt: welcher Branch, wer prüft, wann übernommen wird. Ein Teil dieser Regeln ist in diesem Bestand geschrieben und nachweisbar in Kraft, ein anderer Teil nicht. Ohne diese Unterscheidung entsteht die teuerste Sorte Dokumentation: eine, die eine Regel behauptet, an die sich niemand gebunden hat, und die deshalb weder befolgt noch widerlegt wird.
Was belegbar gilt
| Bereich | Regel | Woran sie nachweisbar ist |
|---|---|---|
| Kodierstil | PSR-12, ohne Regelausnahmen | die Prüfkonfiguration des Arbeitsbereichs und die Aufrufe composer cs und composer cbf |
| Statische Analyse | vorgesehen, Stufe 4 | die Analysekonfiguration und der Aufruf composer stan |
| Commit-Text | jeder Commit nennt sein Arbeitselement in einer eigenen Schlusszeile | die Projektregeln des Bestands; ohne diese Zeile entsteht kein Bezug zwischen Arbeitselement und Code |
| Mit-Autorschaft | kein Modell wird als Mit-Autor eines Commits ausgewiesen | die Projektregeln des Bestands |
| Abnahme je Änderung | Syntaxprüfung, Bootlauf, Oberflächentexte in fünf Sprachen, Neubau des CSS-Bündels, Vergleich des Fehlerprotokolls | die Projektregeln des Bestands |
| Sprache | Quelltextkommentare und Dokumente im Repository englisch, Wiki-Dokumentation deutsch, Oberflächen in fünf Sprachen | die Projektregeln des Bestands |
| Autorenangabe | eine feste Autor- und Adressangabe für eigenen Code | die Projektregeln des Bestands |
| Freigabesignal | das Datum im Paketmanifest ist das Signal, an dem eine Aktualisierung erkannt wird | die Projektregeln des Bestands |
| Wer über Mitarbeit entscheidet | die Maintainer des jeweiligen Projekts, ohne Wiki-Administrationsrechte | der Bildschirm Mitglieder je Projekt; die Prüfung liegt in Domain/ProjectMembership und wird von eigenen Tests gehalten |
| Grenze dieser Zuständigkeit | ein Maintainer vergibt Leser und Contributor, nicht Maintainer | dieselbe Prüfung; sie weist auch eine von Hand gebaute Absendung ab |
| Testaufruf | jedes Paket mit Testverzeichnis hat eine eigene Testkonfiguration und wird aus seinem Wurzelverzeichnis aufgerufen | die Konfigurationsdateien selbst, alle mit denselben Strengeschaltern; kein Paket mit Testverzeichnis ist ohne |
| Statische Analyse in der Praxis | alle Suite-Pakete, Stufe 4, Bestand eingefroren | die Pfadliste in der Analysekonfiguration; ein Lauf endet nur ohne Befund, wenn nichts Neues hinzugekommen ist. Sie zählt jedes Paket einzeln auf — ein neues Paket ist nicht von selbst erfasst, und wer eines anlegt, trägt es dort ein |
| Branchname beim Zurückgeben | auf der Stufe vorschlagen nimmt der Git-Endpunkt nur Refs unter refs/heads/users/<Anmeldename>/ an und weist alles andere ab, bevor es das Quellsystem erreicht; auf der Stufe schreiben gilt die Schranke nicht | die Prüfung liegt in Domain/ReceivePackGuard und wird von eigenen Tests gehalten. Keine der vier Einbindungsvorlagen vergibt vorschlagen; die Stufe entsteht nur aus einer eigens geschriebenen Regel |
Was nicht besteht
| Bereich | Befund |
|---|---|
| Branching-Modell | Keine Regel. Es ist nicht festgelegt, auf welchen Branch eine Änderung gehört, wie er heißen soll oder wann er wieder verschwindet. Die technische Schranke der Stufe vorschlagen in der ersten Tabelle ist keine solche Regel: sie begrenzt, was der Endpunkt annimmt, und sagt nichts darüber, wohin eine Änderung fachlich gehört. |
| Review-Verfahren | Keine Regel. Weder Zuständigkeit noch Bestehenskriterium sind festgelegt. |
| Merge-Regeln | Keine Regel. |
| Versionierung | Kein Schema. Seit dem Paket-Baukasten stehen ZWEI Freigabesignale nebeneinander: das Manifestdatum in plugin.info.txt und der festgeschriebene Stand in release.stable der wkcomponent.json. Der zweite ist genau, unveränderlich und nachvollziehbar — und er zeigt derzeit auf einen Commit, nicht auf eine benannte Fassung, weil kein Repository einen Tag trägt. Der Kanal Stabil liefert damit „was an einem Tag grün war und ausgerollt ist„, nicht „was freigegeben wurde“. Eine Versionsfolge ist von beidem nicht ausgesagt. |
| Änderungsprotokoll | Keine Konvention. Von den eigenen Paketen führt eines ein Änderungsprotokoll. |
| Meldeweg für Sicherheitslücken | Keiner für die eigenen Pakete. |
| Ernennung von Maintainern | Keine Regel. Wer Maintainer eines Projekts wird, entscheidet die Wiki-Administration; nach welchem Maßstab, ist nicht festgelegt. |
Folgen
Wer Dokumentation zu diesem Bereich schreibt, darf für die zweite Tabelle keine Regel formulieren. Eine erfundene Regel ist hier teurer als eine fehlende: sie sieht aus wie eine Festlegung, wird als solche zitiert und bindet niemanden.
Die Anleitung Änderung einreichen beschreibt deshalb nur, was die Plattform tatsächlich leistet, und benennt die offenen Punkte, statt sie zu füllen.
Wer einen der offenen Punkte entscheidet, trägt ihn in die erste Tabelle ein, nennt den Beleg und passt die betroffene Anleitung an.