Schriftliche Regeln

Irgendwann wird die Anzahl der Vereinbarungen und Übereinkünfte die in Ihrem Projekt umhergehen derart groß werden, dass sie irgendwo aufgezeichnet werden müssen. Damit ein solches Dokument rechtmäßig ist, sollten Sie klarstellen, dass es auf Diskussionen und Vereinbarungen auf den Mailinglisten beruht, die bereits in Kraft sind. Wenn Sie es zusammenstellen, verweisen Sie auf die relevanten Threads in den Archiven und immer wann Sie an einen Punkt erreichen, bei dem Sie sich nicht sicher sind, fragen Sie nochmal nach. Das Dokument sollte keine Überraschungen enthalten: Es ist keine Quelle für Vereinbarungen sondern lediglich ihre Beschreibung. Wenn es Erfolg hat, werden Leute natürlich anfangen es zu Zitieren, als eine Quelle für Autorität, was aber nur bedeutet, dass es den allgemeinen Wille der Gruppe zutreffend widerspiegelt.

Dieses ist das Dokument, welches in „Richtlinien für Entwickler“ im Kapitel Kapitel 2, Der Einstieg angespielt wird. Wenn das Projekt noch sehr jung ist, werden Sie selbstverständlich die Richtlinien auslegen müssen, ohne den Vorteil einer langen Historie im Projekt, worauf Sie sich beziehen können. Mit zunehmender Reife der Entwicklungergemeinschaft, können Sie die Sprache anpassen um widerzuspiegeln, welche Abläufe sich tatsächlich entwickelt haben.

Versuchen Sie nicht alles abzudecken. Kein Dokument kann alles umfassen, was Leute wissen müssen um an einem Projekt teilzunehmen. Viele der Konventionen die ein Projekt entwickelt werden nie ausgesprochen oder explizit erwähnt und würden von dem wichtigen aber nicht offensichtlichem Material ablenken. Es hat beispielsweise keinen Sinn, Richtlinien wie folgende zu schreiben "Seien Sie höflich und respektvoll zu anderen auf der Mailingliste und fangen Sie keine Flamewars an", oder "Schreiben Sie sauberen, lesbaren, bugfreien Code". Diese Sachen sind natürlich wünschenswert, da es allerdings kein denkbares Universum gibt, indem sie nicht wünschenswert wären, ist ihre Erwähnung der Mühe nicht wert. Wenn Leute auf der Mailingliste unhöflich sind oder fehlerhaften Code schreiben, dann werden sie nicht damit aufhören, nur weil es die Richtlinien des Projekts es vorschreiben. Solche Situationen müssen bei ihrem Auftreten behandelt werden, nicht durch pauschale Ermahnungen sich gut zu benehmen. Wenn das Projekt andererseits spezifische Richtlinien hat wie man guten Code schreibt, z.B. Regeln über die Dokumentation jeder API in einem bestimmten Format, dann sollten diese Richtlinien so vollständig wie möglich niedergeschrieben werden.

Der Inhalt des Dokuments lässt sich gut bestimmen, durch die die Fragen von Neulingen sowie anhand der Beschwerden, denen erfahrene Entwickler am häufigsten begegnen. Das bedeutet nicht zwangsläufig, dass es zu einer FAQ werden sollte – es braucht wahrscheinlich eine kohärentere erzählerische Struktur, als es eine FAQ bieten kann. Es sollte aber genauso auf tatsächlichen Fragen basieren, nicht auf solchen die Sie erwarten gestellt zu bekommen.

Ein Projekt mit einem gütigen Diktator, oder Mitglieder mit besonderen Vollmachten (Präsidenten, Vorsitzende, was auch immer), sollte das Dokument als gute Gelegenheit betrachten, den Ablauf für Nachfolger festzulegen. Manchmal kann das so einfach sein wie bestimmte Personen als Ersatz zu benennen, sollte der gütige Diktator das Projekt aus irgend einem Grund verlassen. Wenn es einen gütigen Diktator gibt, kann im allgemeinen nur der Diktator selber damit durchkommen einen Nachfolger zu benennen. Wenn es gewählte Vorstandsmitglieder hat, dann sollten die gleichen Abläufe die bei ihrer Wahl verwendet wurden in dem Dokument beschrieben werden. Wenn es ursprünglich keinen Ablauf gab, dann sollten Sie sich innerhalb des Projekts auf einen bestimmten Ablauf einigen bevor Sie darüber schreiben. Menschen können empfindlich sein, was hierarchische Strukturen angeht.

Das wichtigste ist vielleicht klarzustellen, dass die Regeln überdacht werden können. Sollten die Konventionen in dem Dokument anfangen das Projekt zu behindern, erinnern Sie alle daran, dass es ein lebendes Spiegelbild der Absichten der Gruppe sein soll, und keine Quelle für Frustration und Behinderung. Wenn jemand es sich zur Gewohnheit macht, unangebrachterweise immer gerade dann wenn ihm Regeln im Weg stehen, darum zu bitten, diese neu zu überdenken – ist Schweigen manchmal die beste Taktik. Wenn andere mit den Beschwerden übereinstimmen, werden sie auch das Wort ergreifen und es wird offensichtlich sein, dass sich etwas ändern muss. Wenn sonst keiner zustimmt, dann wird die Person nicht sonderlich viel Resonanz erhalten und die Regeln werden so stehenbleiben wie sie sind.

Zwei gute Beispiele für Projekt-Richtlinien sind der Subversion Community Guide unter http://subversion.apache.org/docs/community-guide/ und die Dokumente zur Organisation der Apache Software Foundation unter http://www.apache.org/foundation/how-it-works.html und http://www.apache.org/foundation/voting.html. Die ASF ist in Wirklichkeit eine Sammlung von Software-Projekten, rechtlich als eine Gemeinnützige Organisation aufgestellt, also tendieren ihre Dokumente stärker dazu, Leitungsabläufe zu beschreiben als Konventionen für Entwickler. Sie sind es trotzdem lesenswert, denn sie stellen die gesammelte Erfahrung einer Vielzahl von Open-Source-Projekten dar.