In einem freien Software Projekt, welches eine Menge Patches erhällt, kann es ein Albtraum sein, den Überblick darüber zu behalten, welche Patches angekommen sind un wie über sie entschieden wurde, ganz besonders wenn es auf eine dezentralisierte Art gemacht wird. Die meisten Patches treffen über den Email Verteiler für Entwickler des Projkets ein (obwohl manche zuerst in dem Ticket System auftauchen, oder auf externen Webseiten), und es gibt mehrere Verschiedene Routen, die ein Patch nehmen kann, nach seiner Ankunft.

Manchmal schaut sich jemand einen Patch an, und schickt ihn wieder zurück an den ursprünglichen Author, um ihn aufzuräumen. Das führt normalerweise zu einem sich wiederholenden Vorgang—alle sichtbar auf dem Email Verteiler—bei dem der ursprüngliche Author die überarbeiteten Versionen des Patches wieder zurück schickt, bis der Überprüfende nichts mehr zu kritisieren hat. Es ist nicht immer leicht zu erkennen, wann dieser Vorgang fertig ist: Wenn der Überprüfende den Patch committed, dann ist er eindeutig vorbei. Wenn er es aber nicht tut, kann es daran liegen, dass er einfach nicht genügend Zeit hatte, oder er selber keine commit Berechtigung hat, und keine anderen Entwickler dazu überreden konnte es zu machen.

Eine weitere häufige Antwort auf einen Patch ist eine freilaufende Diskussion, nicht unbedingt über den Patch selber, sondern darüber, ob das Konzept hinter dem Patch gut ist. Der Patch kann zum Beispiel, einen Fehler beheben, wenn das Projekt es aber bevorzugt, den Fehler auf eine andere Art zu beheben, als Teil der Lösung einer algemeineren Klasse von Problemen. Oft ist das nicht im Vorraus bekannt, und es ist der Patch, der die Entdeckung anregt.

Gelegentlich, wird ein eingereichter Patch von völliger Stille empfangen. Normalerweise liegt das daran, dass at that moment kein Entwickler die Zeit hat um den Patch unter die Lupe zu nemen, also hofft jeder, dass jemand anderes es übernimmt. Da es keine bestimmte Grenze gibt, wie lang jede Person wartet bis jemand anderes den Ball ins rollen bringt, und in der Zwischenzeit immer andere Prioritäten auftauchen, passiert es sehr leicht, dass ein Patch durchs Netz schlüpft, ohne das irgend eine einzelne Person das gewollte hat. Das Projekt kann auf diese Art einen Nützlichen Patch verpassen, und es gibt auch andere schädliche Nebenwirkungen: Es ist entmutigend für den Author, der Arbeit in den Patch investiert hat, und es lässt das Projekt ziemlich danach ausschauen, als wäre es nicht entfremdet, ganz besonders im Bezug auf andere die Patches schreiben.

Die Aufgabe des Patch Verwalters ist sicherzustellen, dass Patches nicht "durchs Netz schlüpfen". Das wird erreicht, indem jeder Patch bis zu irgend einem stabilen Zustand verfolgt wird. Der Patch Verwalter beobachtet jeden Thread auf den Email Verteiler, welches sich aus der Einreichung eines Patches ergibt. Wenn es mit einem Commit vom Patch endet, macht er gar nichts. Wenn es in einer Schleife der Überprüfung und Überarbeitung geht, welche in einer finalen Version endet, aber keinen Commit, schreibt er einen Ticket, der auf die finale Version zeigt, sowie auf dem Thread der sich darum dreht, damit es eine permanente Aufzeichnung für Entwickler gibt, die daran später anschließen wollen. Wenn der Patch ein bereits bestehenden Ticket adressiert, schreibt er einen Kommentar dazu in dem Ticket, anstatt einen neuen auf zu machen, mit der relebanten Information.

Wenn ein Patch überhaupt keine Reaktion bekommt, wartet der Patch Verwalter ein paar Tage, greift es dann auf indem er fragt, ob irgen jemand es sich anschauen wird. Darauf gibt es für gewöhnlich eine Reaktion: Ein Entwickler kann erklären, dass er nicht denkt, dass der Patch angewandt werden soll, und Gründe geben, warum das so ist, oder er kann es sich anschauen, worauf einer der vorher beschriebenen Wege eingeschlagen wird. Wenn es immer noch keine Antwort gibt, wird der Patch verwalter unter Umständen keinen Ticket für den Patch schreiben, je nachdem, wie er es für richtig hällt, zumindest hat der ursprüngliche Author irgend eine Antwort erhalten.

Einen Patch Verwalter zu haben, hat der Entwicklermannschaft von Subversion eine Menge Zeit und geistige Energie erspart. Ohne eine designierte Person der die Verantwortung auf sich nimmt, müsste sich jeder Entwickler die ganze Zeit ständig darüber sorgen machen, "Wenn ich nicht die Zeit dazu habe, jetzt auf diesen Patch zu antworten, kann ich mich darauf verlassen, dass jemand anderes es macht? Sollte ich versuchen es aus irgend welchen Gründen im Auge zu behalten, dann würden wir unnötig unsere Anstrenungen Verdoppeln". Der Patch Verwalter entfernt die zweite Mutmaßung aus der Situation. Jeder Entwickler kann die Entscheidung treffen, die für ihn in dem Moment wo er den Patch zum ersten mal sieht, richtig ist. Wenn er mit einer Überprüfung daran anschließen möchte, kann er das tun—der Patch Verwalter wird sein Verhalten entsprechend anpassen. Wenn er den Patch komplett ignorieren will, ist das auch in Ordnung; der Patch Verwalter wird dafür sorgen, dass es nicht in Vergessenheit gerät.

Weil dieses System nur dann funktioniert, wenn man sich darauf verlassen kann dass der Patch Verwalter ausnahmslos da ist, sollte die Rolle formal vergeben werden. In Subversion, bewarben wir um die Stelle auf die Email Verteiler für Entwickler und den für Benutzer, bekamen mehrere Freiwillige, und nahmen den ersten der geantwortet hat. Als die Person abtreten musste (siehe „Übergänge“ später in diesem Kapitel), machten wird das gleiche nochmal. Wir haben es nie versucht mehrere Personen die Rolle teilen zu lassen, da überschüssige Kommunikation die zwischen ihnen nötig wäre; bei einer sehr hohen Anzahl an Patches könnte einen mehrköpfigen Patch Verwalter aber vielleicht Sinn machen.

Bei Software Projekten, kann sich "Übersetzung" auf zwei sehr unterschiedliche Sachen beziehen. Es kann die Übersetzung der Dokumentation in andere Sprachen bedeuten, oder es kann die Übersetzung der Software selber bedeuten—womit gemeint ist, dass die Anwendung seine Fehlermeldungen und Texte in der bevorzugten Sprache des Anwenders darstellt. Beides sind komplexe Aufgaben, wenn aber die richtige Infrastruktur erst einmal eingerichtet ist, kann mal sie größtenteils von der anderen Entwicklung trennen. Weil die Aufgaben sind sich in mancherlei Hinsicht ähnlich, kann es Sinn machen (abhängig von Ihrem Projekt) einen einzigen Verwalter für Übersetzungen zu haben um beides zu handhaben, oder es kann besser sein zwei verschiedene Verwalter zu haben.

In dem Subversion Projekt, haben wir einen Verwalter, der sich um beides kümmert. Er schreibt natürlich nicht selber die Übersetzungen —er wird vielleicht bei ein oder zwei aushelfen, aber zu dem Zeitpunkt dieses Schreibens, müsste er zehn sprachen sprechen (zwölf wenn man Dialekte mitzählt) um bei allen mitzuarbeiten! Statt dessen, Verwaltet er die Mannschaften freiwilliger Übersetzer: Er hilft ihnen dabei unter einander zu koordinieren, und koordiniert zwischen ihnen und dem Rest des Projekts.

Das ein Verwalter für Übersetzungen nötig ist, liegt zum Teil daran, dass Übersetzer eine sehr andere Menschenart sind, als Entwickler. Sie haben manchmal wenig oder gar keine Erfahrung bei der Arbeit mit einer Versionsverwaltung, oder gar überhapt als Teil einer verteilten Mannschaft von Freiwilligen. In anderer Hinsicht, sind sie aber oft die beste Art von Freiwilligen: Menschen mit Kenntnissen auf einem bestimmten Gebiet, die einen Bedarf sahen, und entschieden sich zu beteiligen. Sie sind meistens bereit zu lernen, und enthusiastisch mit der Arbeit anzufangen. Alles was sie brauchen, ist jemand der ihnen sagt wie. Der Übersetzungsverwalter stellt sicher, dass die Übersetzungen auf eine Art ablaufen, welches die gewöhnlichen Entwicklung nicht behindert. Er dient auch als eine Art representativer der Übersetzer, als geeinigten Körper, wann immer die Entwickler über technische Änderungen informiert werden müssen, die nötig sind, um die Übersetzungsarbeit zu unterstützen.

Die wichtigsten Fähigkeiten dieser Position sind desshalb diplomatische und nicht technische. In Subversion haben wir zum Beispiel eine Richtlinie, nach dem alle Übersetzungen, mindestens zwei Personen haben sollte, die an ihnen arbeiten, weil es ansonsten keine Möglichkeit gibt, dass die Texte überprüft werden. Wenn ein neuer Freiwilliger auftaucht, und anbietet Subversion z.B. in Malagasy zu übersetzen, muss der Übersetzungsverwalter ihn entweder mit jemand zusammenbringen der sechs Monate zuvor geschrieben hat, und auch Interesse bekundigt hat eine Übersetzung in Malagasy zu machen, oder ihn höflich darum bitten, einen weiteren Übersetzer für Malagasy zu finden, der mit ihm als Partner arbeitet. Wenn genügend Leute verfügbar sind, gibt der Übersetzungsverwalter ihnen die nötigen Commit Rechte, informiert ihnen über die Konventionen des Projekts (wie man etwa Commit Kommentare schreibt), und hällt dann danach ausschau, dass sie sich an diese Konventionen halten.

Unterhaltungen zwischen dem Übersetzungsverwalter und den Entwicklern, oder zwischen dem Übersetzungsverwalter und die Übersetzungsmannschaften, werden meistens in der ursprünglichen Sprache des Projekts gehalten—also die Sprache von dem alle Übersetzungen gemacht werden. Für die meisten freien Software Projekte ist das Englisch, es macht aber keinen Unterschied, so lange das Projek sich darauf einigt. (Obwohl Englisch wahrscheinlich am besten ist, für Projekte die eine breite Internationale Gemmeinschaft anlocken wollen.)

Unterhaltungen innerhalb einer bestimmte Übersetzungsmannschaft sind jedoch meistens in der gemeinsamen Sprache, und einer der anderen Aufgaben des Übersetzungsverwalter ist es, einen gesonderten Email Verteiler für jede Mannschaft einzurichten. So können sich die Übersetzer frei über ihre Arbeit unterhalten, ohne andere auf den Hauptverteilern des Projekts abzulenken, von denen die meisten eh nicht in der Lage wären, die übersetzte Sprache zu verstehen.

Die Dokumentation der Software auf den neusten Stand zu halten, ist eine niemals endende Aufgabe. Jede neue Funktion oder verbesserung die in den Code geht, hat das Potential, eine Änderung an der Dokumentation zu verursachen. Wenn die Dokumentation des Projekts erst einmal einen gewissen Grad der Fertigstellung erreicht hat, werden Sie auch sehen, dass die Patches die von Leuten eingereicht werden, für die Dokumentation sind, nicht für den Code. Das liegt daran, dass es viel mehr Leute gibt, die in der Lage sind Fehler in Prosa zu beheben, als in Code: Alle Nutzer sind Leser, aber nur wenige sind Programmierer.

Patches für die Dokumentation sind meistens viel einfacher zu überprüfen und anzuwenden, als Patches für Code Es gibt wenig oder nichts zum Testen, und die Qualität der Änderung kann schnell evaluiert werden, alleine indem man ihn durchliest. Da die Menge groß ist, aber die Bürde sie zu überprüfen relativ gering ist, ist das Verhältniss des überschüssigen administrativen Aufwands zu produktiver Arbeit größer als für Patches an dem Code. Desweiteren, werden die meisten Patches wahrscheinlich irgend eine Art Anpassung erfordern, um einen beständigen Ton in der Stimme des Authors in der Dokumentation zu bewahren. In vielen Fällen, werden sich Patches überschneiden, oder andere Patches beeinflussen, und auf einander abgestimmt werden müssen vor sie committed werden.

Angesichts der Anforderungen an die Handhabung der Dokumentation, und der Tatsache, dass der Codebestand ständig überwacht werden muss damit die Dokumentation aktuell gehalten werden kann, macht es Sinn, eine Person oder eine kleine Mannschaft zu haben, die sich der Aufgabe widmet. Sie können ein Protokoll darüber führen, wo genau und wie die Dokumentation hinter der Software herhikt, und sie können geübte Abläufe haben um große Mengen an Patches auf eine gegliederte Art zu verarbeiten.

Das hindert natürlich andere in dem Projekt nicht daran, Patches mal nebenbei auf die Dokumentation anzuwenden, ganz besonders kleine, wie es die Zeit erlaubt. Und der gleiche Patch Verwalter (siehe „Patch Verwalter“ früher in diesem Kapitel) kann sowohl Änderungen an dem Code, als auch an der Dokumentation verfolgen, und sie überall ablegen, wo die Entwickler- und Dokumentationsmannschaften sie jeweils haben möchten. (Wenn die gesamte Menge der Patches die übersteigt, die von einem Mensche verarbeitet werden kann, ist es wahrscheinlich ein erster Schritt, wenn man auf separate Patch Verwalter für Code und Dokumentation wechselt.) Der Sinn einer Dokumentationsmannschaft ist es nicht, Leute zu haben, die sich dafür verantwortlich fühlen, die Dokumentation organisiert, auf dem aktuellsten Stand, und in sich konsistent zu halten. In der Praxis, bedeutet das, die Dokumentation intim zu kennen, den Codebestand zu beobachten, die Änerungen die andere an die Dokumentation machen zu beobachten, nach eintreffenden Patches für die Dokumentation ausschau zu halten, und all diese Informationensquellen zu nutzen, um das zu tun, was nötig ist, um die Dokumentation in einem gesungen Zustand zu halten.

Die Anzahl der Tickets in dem Bug Tracker des Projekts nimmt mit der Anzahl der Personen zu, welche die Software benutzen. Desshalb sollten Sie immer noch erwarten, dass die Anzahl offener Tickets, im wesentlichen ohne Grenzen anwächst, selbst wärend sie Fehler beheben und eine immer robustere Anwendung produzieren. Die Menge der doppelt eingetragenen Tickets wird genau so wie die der unvollständigen und dürftig beschriebenen Tickets zunehmen.

Ticket Verwalter helfen dabei, diese Probleme zu mildern, indem sie in die Datenbank gehen, und periodisch alles durchkehren, auf der Suche nach bestimmten Problemen. Ihre häufigste Aufgabe ist es wahrscheinlich eintreffende Tickets aufzubessern, entweder weil der Meldende einige der Formularfelder nicht richtig gesetzt hat, oder weil der Ticket ein Duplikan eines bereits in der Dadenbank vorhandenen ist. Offensichtlich, wird der Ticket Verwalter um so effektiver in der Lage sein Duplikate zu erkennen, je besser er mit der Bug Datenbank des Projekts vertraut ist—das ist eines der hauptsächlichen Vorteile ein paar Personen zu haben, die sich auf die Bug Datenbank spezialisiern, anstatt das alle es versuchen ad hoc zu übernehmen. Wenn die Gruppe versucht, es auf eine dezentralisierte Art zu machen, eignent sich kein einzelner ein Tieferes Wissen über den Inhalt der Datenbank an.

Ticket Verwalter können auch helfen, zwischen den Tickets und den einzelnen Entwicklern zu vermitteln. Wenn eine Menge Bug Meldungen eintreffen, wird nicht jeder Entwickler die Nachrichten von Verteiler für die Tickets mit der gleichen Aufmerksamkeit lesen. Wenn jemand jedoch weiß, dass die Entwicklermannschaft ein Auge auf alle eintreffenen Tickets hällt, kann sie wenn es angemessen ist, diskret die Aufmerksamkeit bestimmter Entwickler auf spezifische Fehler richten. Das muss natürlich mit einem Gesprür für alles andere was in der Entwicklung abläuft geschehen, und entsprechend den Wünschen und dem Temprament des Empfängers. Es ist desshalb oft besser, wenn Ticket Verwalter selber Entwickler sind.

Abhängig davon wie Ihr Projekt den Bug Tracker benutzt, können Ticket Verwalter auch die Datenbank anpassen, um die Prioritäten des Projekts wider zu spiegeln. Wir in Subversion zum Beispiel, planen wir einen Ticket für eine bestimmte zukünftige Version ein, damit wenn jemand fragt "Wann wird Bug X behoben sein?" wir sagen können "In Zwei Versionen" slelbst wenn wir kein genaues Datum nennen können. Die neuen Versionen kann man als Meilensteine in dem Bug Tracker eintragen, ein Feld welches in IssueZilla^[41] angeboten wird. Grundsätzlich hat jede neue Version von Subversion eine bedeutende neue Funktion, und eine liste spezifischer Fehler die behoben wurden. Wir weisen die entsprechenden Meilensteine allen Tickets zu, die für die Version geplant sind (inklusive der neuen Funktion—es erhällt auch einen Ticket), damit man die Bug Datenbank mit der geplanten Version im Blick anschauen kann. Diese Ziele bleiben jedoch relativ statisch. Wärend neue Fehler gemeldet werden, verschieben sich manchmal die prioritäten, und ein Ticket muss von einem Meilenstein zum anderen verschoben werden, damit jede Version noch im Griff zu behalten bleibt. Das wiederum, wird am besten von Personen gemacht, die insgesamt, einen Sinn dafür haben, was in der Datenbank ist, und wie verschiedene Tickets mit einander verwandt sind.

Eine weitere Sache, die Ticket Verwalter machen, ist zu erkennen, wann Tickets veraltet sind. Manchmal wird ein Bug aus versehen behoben, als Teil einer Änderung an der Software die nicht im Zusammenhang steht. Manchmal änder das Projekt auch seine Meinung darüber, ob ein bestimmtes Verhalten als Fehler einzustufen ist. Veraltete Tickets zu finden ist nicht leicht: Der einzige Weg es systematisch zu machen, ist indem man über alle Tickets in der Datenbank geht. Mit der Zeit, wärend die Anzahl der Tickets anwächst, wird sowas allerdings immer winiger praktikabel. Ab einer bestimmten Grenze, ist die einzige Möglichkeit die Datenbank in einem vernünftigen Zustand zu behalten, die teile und herrsche Mehtode: Kategorizieren Sie die Tickets, sofort nachdem sie eingetragen wurden und lenken Sie die Aufmerksamkeit der passenden Entwickler oder Mannschaft darauf. Der Empfänger kümmert sich ab dann um den Ticket, bis es seine Lebenszeit beendet hat, und hütet es soweit nötig, bis es erledigt ist oder in Vergessenheit gerät. Wenn die Datenbank derart groß ist, wird der Ticket Verwalter eher zu einem globalen Koordinator, der immer weniger Zeit damit verbring, sich jeden einzelnen Ticket anzuschauen, und mehr damit es in die Hände der richtigen Person zu bekommen.

Die Verwaltung der FAQ ist ein überraschend schwieriges Problem. Anders als bei den meisten anderen Dokumenten in einem Projekt, deren Inhalt im vorraus von den Authoren geplant wird, ist eine FAQ von einer gänzlich reaktiven Natur (siehe Die Pflege einer FAQ). Egal wie groß es wird, Sie werden nie wissen, was der nächste Eintrag sein wird. Und weil es immer Stückweise erweitert wird, passiert es sehr leich, dass das Dokument als ganzes ohne Zusammenhang oder Organization ist, und sogar doppelte oder mit einander ähnliche Einträge enthällt. Selbst wenn es keine solche offensichtlichen Probleme hat, gibt es oft unbemerkte Abhängigkeiten zwischen den Einträgen—Verweise die gemacht werden sollten es aber nicht sind—weil die verwandten Einträge ein Jahr auseinander gemacht wurden.

Die Rolle des Verwalters der FAQ ist zweifältig. Erstens pflegt er die allgemeine Qualität der FAQ indem er damit vertraut bleibt, oder zumindest mit den Themen aller Fragen die darin enthalten sint, damit wenn Personen neue Einträge hinzufügen, die einfach nur Duplikate, oder ähnlich zu bereits bestehenden Einträgen sind, die nötigen Anpassungen gemacht werden können. Zweitens, überwacht er die Email Verteiler und anderen Foren, nach immer wiederkehrenden Fragen und schreibt neue Einträge, auf dieser Grundlage. Letztere Aufgabe kann ziemlich Komplex sein: Man muss in der lage sein einen Thread verfolgen zu können, die Kernfragen erkennen zu können, einen Eintrag für die FAQ vorzuschlagen, die Kommentare anderer einzubeziehen (da es unmöglich ist, dass der FAQ Verwalter ein Experte auf jedem Gebiet ist, welches in der FAQ behandelt wird), und merken, wann dieser Vorgang beendet ist, damit der Eintrag endlich hinzugefügt werden kann.

Der FAQ Verwalter wird auch normalerweise zum Experten für die Formatierung der FAQ. Es gibt eine menge kleiner Details die es bei der Pflege einer FAQ zu beachten gibt (siehe „Behandeln Sie alle Resourcen wie Archive“ im Kapitel Kapitel 6, Kommunikation); wenn beliebige Leute die FAQ bearbeiten, werden sie oft einige dieser Details vergessen. Das ist in Ordnugn, so lange der FAQ Verwalter da ist, um nach ihnen aufzuräumen.

Es gibt einige freie Software um die Pflege einer FAQ zu unterstützen. Es ist ok sie zu nutzen, so lange es die Qualität der FAQ nicht gefährdet, seien Sie aber vor all zu viel Automatisierung gewarnt. Manche Projekte versuchen die Pflege der FAQ vollständig zu automatisieren, und erlauben es jedem FAQ Einträge beizutragen und zu bearbeiten, ähnlich wie bei einer Wiki (siehe „Wiki“ im Kapitel Kapitel 3, Technische Infrastruktur). Ich habe das insbesondere bei Faq-O-Matic (http://faqomatic.sourceforge.net/) gesehen, obwohl das daran liegen kann, dass ich Fälle gesehen habe, die lediglich Missbräuche von dem wofür Faq-O-Matic ursprünglich gedacht war. Die komplette dezentralisierung der FAQ Pflege, reduziert zwar den Aufwand für das Projekt, produziert aber in jedem Fall auch eine dürftigere FAQ. Es gibt keine eine Person mit einem groben Überblick über die ganze FAQ, keiner der merkt, wenn bestimmte Einträge aktualisiert werden müssen, oder komplett überflüssig werden, und keiner der nach den Abhängigkeiten zwischen den Einträgen ausschau hällt. Das Ergebnis ist eine FAQ welches es oft nicht schafft, den Nutzern das zu geben, wonach sie gesucht haben und im schlimmsten Fall, sie sogar in die Irre führt. Nutzen Sie welche Werkzeuge Sie auch brauchen um die FAQ ihres Projekts zu pflegen, lassen Sie aber niemals den Komfort dieser Hilfsmittel Sie dazu verleiten die Qualität der FAQ beeinträchtigen.

Siehe den Artikel von Sean Michael Kerner, The FAQs on FAQs, bei http://osdir.com/Article1722.phtml, für Beschreibungen und Bewertungen von Open Source Hilfsmittel für die Pflege von FAQs.