Governance für ein kleines Projekt: Entscheidungsrechte festgehalten, bevor sie gebraucht werden

Worum es geht

Governance ist die Regelmenge, die festlegt, wer was entscheiden darf und wie eine Entscheidung als getroffen gilt. Drei Formen decken die meisten kleinen Projekte ab. Ein einzelner Maintainer entscheidet alles und sagt das auch so. Eine kleine Gruppe entscheidet per Lazy Consensus, den das Apache-Glossar als eine Regel definiert, die allgemeine Zustimmung annimmt, wenn innerhalb einer festgelegten Frist keine Rückmeldungen erfolgen, mit einer ausdrücklichen Abstimmung nur bei umstrittenen Fragen. Ein Rat hält die letzte Autorität: PEP 13 gibt Python einen fünfköpfigen Steering Council mit weitreichender Autorität, den das Dokument dazu anhält, diese so selten wie möglich auszuüben, Konsens und Standardverfahren gegenüber Entscheidungen zu bevorzugen, mit strikter Mehrheit der nicht enthaltenen Mitglieder abzustimmen und, wo immer möglich, öffentlich zu beraten.

Warum es wichtig ist

Ohne schriftliche Regeln werden Streitigkeiten von der lautesten Stimme oder durch Schweigen entschieden, Mitwirkende können nicht erkennen, ob ein Vorschlag genehmigt oder lediglich unwidersprochen ist, und eine Übergabe hat keine Grundlage, auf die sie sich stützen kann. Die Regeln zählen an gewöhnlichen Tagen am wenigsten und an dem Tag am meisten, an dem sich zwei Maintainer über die öffentliche API uneinig sind.

So wird es angewendet

• Eine einseitige GOVERNANCE-Datei schreiben: Maintainer namentlich und nach Zuständigkeitsbereich; wer was mergen darf; die Standard-Entscheidungsregel (Lazy Consensus mit festgelegter Frist für Routineänderungen, ausdrückliche Zustimmung aller Maintainer für öffentliche API, Lizenz, Projektumfang und das Hinzufügen eines Maintainers).
• Für den Fall von zwei Maintainern einen Tie-Break benennen: einen Bereichsverantwortlichen pro Modul oder ein rotierendes letztes Wort, jetzt entschieden statt während eines Streits.
• Festlegen, wie ein Maintainer hinzugefügt wird (Vorschlag, Frist, Zustimmung) und wie er inaktiv wird oder entfernt wird, einschliesslich des Falls eines nicht erreichbaren Maintainers.
• Entscheidungen dort festhalten, wo sie getroffen wurden: im Issue- oder Pull-Request-Thread, und ein Architecture Decision Record für alles, was die Codebasis prägt.
• Die Beratung öffentlich halten, wie PEP 13 es von seinem Rat verlangt, wann immer möglich; eine private Entscheidung sollte danach mit ihren Gründen veröffentlicht werden.
• Die Datei sich nur nach ihrer eigenen Regel selbst ändern lassen und jede Änderung datieren.

Stolpersteine

Eine Ratsstruktur für zwei Personen kopieren. Regeln, die geschrieben, aber nie angewendet werden, sodass der erste echte Einsatz zugleich der erste Test ist. Schweigen ohne festgelegte Frist als Zustimmung gewertet, wodurch ein Vorschlag durchgeht, weil ihn niemand gelesen hat. Governance, die Personen, aber keine Zuständigkeitsbereiche nennt, sodass jede Frage bei der Gründerperson landet.