In dem Subversion-Projekt, wählen wir Committer hauptsächlich nach dem Hippokratischen Prinzip: Erstens, richte keinen Schaden an . Unsere Hauptkriterien sind nicht technische Fähigkeiten oder auch nur Kentnis des Codes, sondern lediglich, dass der Committer ein gutes Urteilsvermögen zeigt. Urteilsvermögen kann auch einfach bedeuten, zu wissen, was man nicht angehen sollte. Eine Person könnte nur kleine Patches einreichen, relativ kleine Probleme im Code beheben; aber wenn die Patches sich sauber anwenden lassen, keine Bugs enthalten, und weitestgehend mit den Richtlinien des Projekts (über die Formatierung von Komentaren und Code) übereinstimmen, und es genügend Patches gibt, dass sich ein klares Muster zeigt, dann wird ein bestehender Committer ihn für gewöhnlich als Kandidaten für den Commit-Zugriff vorschlagen. Wenn mindestens drei Personen zustimmen und es keine Gegenstimmen gibt, wird ein Angebot unterbreitet. Zugegeben, wir haben dann keinen Beweise dafür, dass die Person in der Lage ist, komplexe Probleme in allen Bereichen des Quellcodes zu lösen, aber das macht keinen Unterschied: Die Person hat klar gemacht, dass sie zumindest in der Lage ist, ihre eigenen Fähigkeiten einzuschätzen. Technische Fähigkeiten können gelernt (und gelehrt) werden, für Urteilsvermögen gilt das im Wesentlichen nicht. Deshalb ist es die eine Sache, bei der Sie sicher gehen wollen, dass die Person sie besitzt, vor Sie ihm Commit-Zugriff erteilen.

Wenn ein neuer Committer vorgeschlagen wird, geht es für gewöhnlich nicht um technischen Fähigkeiten, sondern um das Verhalten der Person auf den Mailinglisten oder im IRC. Manchmal zeigt jemand technisches Können und die Fähigkeit innerhalb der formalen Richtlinien des Projekts zu arbeiten, ist jedoch in den öffentlichen Foren immer streitlustig oder nicht kooperativ. Das ist ein ernstes Bedenken; wenn die Person sich mit der Zeit nicht bessert, selbst als reaktion auf Andeutungen, werden wir ihn keinen Commit-Zugriff geben, egal wie Talentiert er ist. In einer Gruppe von Freiwilligen, sind soziale Kompetenzen, oder die Fähigkeit "gut im Sandkasten zu spielen", genau so wichtig wie die rohen technischen Fähigkeiten. Da alles unter Versionsverwaltung steht, sind die Nachteile einen Committer hinzuzufügen den Sie lieber nicht hätten, nicht so sehr die Probleme die es im Code bereiten könnte (Code Überprüfungen sollten das sowieso schnell aufdecken), sondern dass es irgendwann das Projekt dazu zwingen könnte die commit Berechtigung wegzunehmen – etwas, was niemals angenehm ist und manchmal Auseinandersetzungen provoziert.

Viele Projekte bestehen darauf, dass der potentielle Committer einen gewissen Grad an technischen Kentnissen und Ausdauer vorweist, indem er eine gewisse Anzahl nicht trivialer Patches einreicht – diese Projekte wollen also nicht nur wissen, dass die Person keinen Schaden anrichten wird, sondern auch das er sich wahrscheinlich im gesamten Quellcode bewähren wird. Das ist völlig in Ordnung, seien Sie aber vorsichtig, dass die Commit-Berechtigung nicht anfängt, sich in die Mitgliedschft in einem exklusiven Club, zu verwandeln. Die Frage die in allen Köpfen sein sollte ist "Was wird die besten Ergebnisse für den Code liefern?" nicht "Werden wir den sozialen Status veringern, der mit Commit-Berechtigung in Zusammenhang gebracht wird, wenn wir diese Person aufnehmen"? Der Sinn des Commit-Zugriffs ist nicht das Selbstwertgefühl der Leute zu heben, es geht darum, mit möglichst wenigen Umständen Änderungen am Code zu erlauben. Wenn Sie 100 Committer haben, von denen 10 regelmäßig große Änderungen machen, und die anderen 90 beheben nur Tippfehler und kleine Fehler ein paar mal im Jahr, ist das immer noch besser als nur die 10 zu haben.

Das erste was zu der Rücknahme von Commit-Zugriff gesagt werden muss ist: Versuchen Sie möglichst gar nicht erst in die Lage zu geraten. Abhängig davon, wessen Zugriff zurückgezogen wird, und warum, können die Diskussionen um solche Maßnahmen sehr geteilt sein. Selbst wenn sie nicht geteilt sind, können sie eine sehr zeitaufwendige Ablenkung von der produktiven Arbeit sein.

Wenn Sie es jedoch tun müssen, sollte die Diskussion im privaten mit den selben Personen geführt werden, die ein Stimmrecht für die Gewährung des Zugriffs haben, welche diese Person gerade hat. Die Person selber sollte nicht mit einbezogen werden. Das wirderspricht die gewöhnliche Vorschrift gegen die Geheimhaltung, ist aber in diesem Fall notwendig. Erstens, könnte sonst keiner frei reden. Zweitens, wenn der Antrag fehlschlägt, wollen Sie nicht unbedingt, dass die Person weiß, dass es überhaupt zur Debatte stand, da es Fragen aufwerfen könnte ("Wer war auf meiner Seite? Wer war gegen mich?") die zu der schlimmsten Art von Parteibildung führen. Unter bestimmten seltenen Umständen, kann die Gruppe jemandem sagen wollen, dass der Widerruf in Betracht gezogen wird oder wurde, als Warnung, diese Offenheit sollte aber eine Entscheidung der Gruppe sein. Keiner sollte jemals aus Eigeninitiative jemandem Informationen aus einer Diskussion und einer Wahl preisgeben, von denen andere angenommen haben, dass sie Geheim waren.

Nachdem der Zugriff widerrufen wurde, ist diese Tatsache zwangsläufig öffentlich (siehe „Vermeiden Sie Geheimnisse“ später in diesem Kapitel), also versuchen Sie so Taktvoll wie möglich zu sein, in der Art wie Sie es der Öffentlichkeit präsentieren.

Manche Projekte bieten eine Abstufung bei der Commit-Berechtigung an. Es kann zum Beispiel Freiwillige geben, die freien Zugriff auf die Dokumentation habem, die aber nicht an den Code selber committen können. Häufige Bereiche für den Teilzugriff sind unter anderem die Dokumentation, Übersetzungen, Code für die Anbindung anderer Programiersprachen, bestimmte Dateien um Packete zu erstellen (z.B. Dateien spezifisch zum RPM von RedHat usw.), sowie andere Orte, an denen ein Fehler nicht zu einem großen Problem für das Projekt werden wird.

Da es beim Commit-Zugriff nicht nur darum geht Änderungen zu machen, sonderan auch einen Teil der Wahlberechtigten zu sein (siehe „Wahlberechtigung“ im Kapitel Kapitel 4, Soziale und politische Infrastruktur), stellt sich natürlich die Frage: Worüber können teilberechtigte Committer abstimmen? Es gibt keine eine richtige Antwort; es hängt davon ab, welche Arten von Bereichen Ihr Projekt mit Teilzugriff hat. In Subversion haben wir alles relativ einfach gehalten: Ein Committer mit Teilzugriff, kann über Angelegenheiten abstimmen, die exclusiv mit seinem Bereich zu tun haben und auf nichts anderes. Wichtig dabei, ist dass wir eine Möglichkeit haben, um beratende Stimmen abgeben können (im Wesentlichen, schreibt der Committer "+0" oder "+1 (nicht-bindend)" statt einer einfachen "+1" Stimme). Es gibt keinen Grund, Leute komplett zum Schweigen zu bringen, nur weil ihre Stimme nicht formal bindend ist.

Vollständig Commit-Berechtigte können über alles abstimmen, genau so wie sie überall committen können, und nur Vollberechtigte können über die Aufnahmen von neuen Committern jedweder Art abstimmen. In der Praxis, wird die Fähigkeit neue Teilberechtigte aufzunehmen, jedoch weitergegeben: Jeder Vollberechtigte kann für einen neuen Teilberechtigten "bürgen", und teilberechtigte Committer können im wesentlichen neue Committer für den gleichen Bereich wählen (das ist besonders hilfreich, damit die Übersetzungsarbeit glatt verläuft).

Ihr Projekt kann eine etwas andere Anordnung erfordern, abhängig von der Natur der Arbeit, die selben allgemeinen Prinzipien gelten aber für alle Projekte. Jeder Committer sollte über Angelegenheiten abstimmen können, die in dem Bereich fallen auf den er Zugriff hat, und nicht auf solche die außerhalb davon liegen, und Wahlen über Generelle Abläufe, sollten automatisch auf die vollen Committer gehen, es sei denn es gibt einen Grund (welcher von den vollen Committern entschieden wurde) um den Wahlkreis auszuweiten.

Was die Druchsetzung des Teilzugriffs angeht: Es ist of am besten, wenn das Versionsverwaltungssystem nicht den Teilzugriff erzwingt, selbst wenn es dazu in der Lage ist. Siehe „Autorisierung“ im Kapitel Kapitel 3, Technische Infrastruktur für weiteres über die Gründe dafür.

Manche Projekte entfernen den Zugriff auf das Projektarchiv nach einer gewissen Zeit (sagen wir, einem Jahr) ohne Commit-Aktivität. Ich denke dass das meist nicht hilfreich und sogar aus zwei Gründen kontraproduktiv ist.

Erstens kann es Leute dazu verleiten, annehmbare aber unnötige Änderungen zu committen, nur um zu verhindern, dass ihr Commit-Zugriff abläuft. Zweitens dient es keinen wirklichen Zweck. Wenn die Hauptkriterien, Leuten Commit-Zugriff zu gewähren, ein gutes Urteilsvermögen ist, warum sollte man annehmen, dass das Urteilsvermögen von jemand verfällt, nur weil er dem Projekt eine Weile fernblieb? Selbst wenn er komplett über Jahre verschwindet, sich nicht den Code anschaut, noch die Diskussionen über die Entwicklung mitverfolgt, wird er wenn er wieder auftaucht wissen wie fremd er der Sache ist und sich entsprechend verhalten. Sie haben seinem Urteilsvermögen vorher vertraut, warum sollten Sie es nicht immer vertrauen? Wenn ein Diplom nicht abläuft, dann sollte es der commit Zugriff auch nicht.

Manchmal wird ein commiter darum bitten entfernt zu werden, oder in der Auflistung der Committer explizit als abwesend markiert zu werden (siehe „Vermeiden Sie Geheimnisse“ weiter unten für weiteres über diese Liste). In solchen Fällen, sollten das Projekt natürlich den Wünschen der Person nachkommen.

Auch wenn die Diskussionen um die Aufnahme eines bestimmten neuen Committers geheim gehalten werden sollte, müssen die Regeln und Abläufe selber nicht geheim seit. Es ist sogar am besten, wenn sie veröffentlicht werden, damit Leute erkennen, dass die Committer nicht irgend einer mysteriösen, prominenten Kaste angehören, die für Normalsterbliche verschlossen ist, sondern dass jeder einfach eintreten kann, indem er gute Patches einreicht, und sich in der Gemeinschaft zu verhalten weiß. Im Subversion-Projekt präsentieren wir diese Information direkt im Dokument der Entwicklerrichtlinien, da diejenigen die am ehesten daran interesiert sind Commit-Zugriff zu bekommen, solche sind die darüber nachdenken, Code zum Projekt beizutragen.

Zusätzlich zu der Veröffentlichung der Richtlinien, sollten Sie die Liste der Committer veröffentlichen. Der traditionelle Ort hierfür ist eine Datei namens MAINTAINERS oder COMMITTERS im obersten Verzeichnis des Quellcodes vom Projekt. Es sollte zuerst alle vollen commit Berechtigten auflisten, gefolgt von verschiedenen Bereichen und die zugehörigen teilberechtigten Committer. Jede Person sollte mit Namen und E-Mail-Adresse aufgeführt sein, wobei die Adresse kodiert sein darf, um Spam zu verhindern (siehe „Verschleierung von Adressen im Archiv“ im Kapitel Kapitel 3, Technische Infrastruktur) wenn die Person das bevorzugt.

Da die Unterscheidung zwischen Voll- und Teilzugriff auf das Projektarchiv offensichtlich und gut definiert ist, ist es auch angemessen, wenn diese Liste diese Unterscheidung auch macht. Darüber hinaus, sollte die Liste nicht versuchen die informellen unterschiede anzudeuten, die sich zwangsläufig in einem Projekt ergeben, wie wer besonders einflussreich ist und wie. Es ist ein öffentliches Protokoll, keine Datei für Anerkennungen. Listen Sie die Commiter in alphabetischer Reihenfolge auf, oder in so wie sie angekommen sind.