Leitung von Freiwilligen Leute dazu zu bringen, sich darauf zu einigen, was das Projekt benötigt, und zusammen zu arbeiten, um es zu erreichen, erfordert mehr als nur eine angenehme Atmosphäre und das Vermeiden der gröbsten Fehler. Es erfordert jemanden oder mehrere, die alle beteiligten Personen bewusst leiten. Die Leitung von Freiwilligen mag kein technisches Handwerk sein, vergleichbar etwa mit dem Programmieren, es ist aber dennoch ein Handwerk im dem Sinne, dass es durch lernen und üben verbessert werden kann. Dieses Kapitel ist ein lose Sammlung spezifischer Techniken für die Leitung von Freiwilligen. Es greift vielleicht mehr als vorherige Kapitel auf das Subversion-Projekt als Fallstudie zurück, zum Teil da ich an dem Projekt gearbeitet habe, als ich das hier schrieb und alle primären Quellen griffbereit hatte, und zum Teil weil es akzeptabler ist, wenn man die Steine der Kritik ins eigene Glashaus wirft, als in das anderer. Ich habe aber auch in verschiedenen anderen Projekten die Vorteile der Anwendung der folgenden Emfehlungen kennengelernt – und die Konseqenzen der Nichtanwendung –; wenn es mir politisch korrekt erscheint, Beispiele aus einigen dieser Projekte zu geben, werde ich das tun. Da wir schon einmal über Politik reden, sollten wir dieses äußerst unheilvolle Wort einmal genauer unter die Lupe nehmen. Viele Ingenieure meinen Politik sei etwas, mit dem sich besser andere beschäftigen. "Ich spreche nur für den besten Kurs für das Projekt, aber sie erheben Einsprüche aus politischen Gründen." Ich denke dieser Ekel vor Politik (oder dem was als Politik verstanden wird) ist in Ingenieuren besonders stark, da sie sich die Idee angeeignet haben, dass manche Lösungen objektiv besser sind als andere. Wenn es also scheint, dass jemand sich auf eine Art benimmt, als wäre er durch äußere Überlegungen motiviert – sagen wir der Erhaltung ihrer einflussreichen Position, die Verminderung des Einflusses von jemand anderem, gar offener Kuhhandel oder die Meidung, die Gefühle von jemand zu verletzen – könnten andere Mitwirkende im Projekt genervt sein. Das hindert sie natürlich nicht daran, sich auf die gleiche Art zu benehmen, wenn ihre lebenswichtigen Interessen auf dem Spiel stehen. Wenn Sie "Politik" für ein schmutziges Wort halten, und hoffen Ihr Projekt davon frei zu halten, geben Sie es besser gleich auf. Politik ist unvermeidlich, wann immer Menschen im Verwalten gemeinschaftlicher Ressourcen kooperieren müssen. Es ist völlig vernünftig, dass eine der Überlegungen, die in der Entscheidungsfindung von jemandem einfließt, die Frage ist, wie ein Vorgang sich auf den eigenen zukünftigen Einfluss im Projekt, auswirken wird. Wenn Sie schließlich Ihrem eigenen Urteilsvermögen und Ihren Fähigkeiten vertrauen, wie es bei den meisten Programmierern der Fall ist, dann muss der mögliche Verlust von zukünftigem Einfluss, im gewissen Sinne als techniches Ergebnis in Betracht gezogen werden. Ähnliche Schlussfolgerungen gelten für anderes Verhalten, welche vielleicht oberflächlich betrachtet, nach "reiner" Politik aussieht. Tatsächlich gibt es so etwas wie reine Politik nicht: Es ist genau aus dem Grund, dass Vorgänge mehrere Konsequenzen in der echten Welt habe, dass Menschen überhaupt ein politisches Bewusstsein bekommen. Politik ist, letztendlich, einfach eine Anerkennung, dass alle Konzequenzen von Entscheidungen, in betracht gezogen werden müssen. Wenn eine bestimmte Entscheidung zu einem Ergebinis führt, welches die meisten Mitwirkenden technich zufriedenstellend finden, welches aber mit einer Änderung in den macht Beziehungen zusammenhängt, dass entscheidende Personen ein Gefühl der Isolation gibt, ist letzteres ein genau so wichtiges Ergebnis wie ersteres. Es zu ignorieren, wäre nicht hoch geistig, sondern kurz sichtig. Wärend Sie also die nachfolgenden Ratschläge lesen, und wärend Sie an Ihrem eigenen Projekt arbeiten, denken Sie daran, dass es keinen gibt, der über die Politik steht. Zu erscheinen, als wäre man über die Politik, ist lediglich eine bestimmte politische Strategie, und manchmal ein sehr nützliches, es entspricht aber niemals der Wirklichkeit. Politik ist einfach was passiert, wenn Menschen Meinungsverschiedenheiten haben, und erfolgreiche Projekte sind solche die politische Mechanismen entwickeln um diese Streitigkeiten konstruktiv zu verwalten. Das meiste aus Freiwilligen herausholen Warum arbeiten Freiwillige an freien Softwareprojekten? Diese Frage wurde im Detail untersucht, mit interesanten Ergebnissen, in einer Veröffentlichung von Karim Lakhani und Robert G. Wolf, mit dem TitelWhy Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects (de. Warum Hacker tun was sie tun: Verständnis der Motivation und Bestrebungen in Freien/Open Source Software Projekten). Siehe . Wenn man sie fragt, behaupten biele, dass sie es machen, weil sie gute Software produzieren wollen, oder persönlich daran beteiligt sein wollen, die Fehler zu beheben, die ihnen wichtig sind. Aber diese Gründe sind gewöhnlich nicht die ganze Geschichte. Könnten Sie sich schließlich einen Freiwilligen vorstellen, der bei einem Projekt bleibt, selbst wenn keiner je ein Wort der Anerkennung über seine Arbeit sagen würde, oder keiner ihm in Diskussionen zuhören würde? Natürlich nicht. Menschen verbringen ganz klar Zeit an freien Software-Projekten, aus Gründen die über das Bedürfnis. guten Code zu produzieren, hinaus gehen. Die wirkliche Motivation von Freiwilligen zu verstehen, wird Ihnen helfen, es so einzurichten, dass sie angelockt werden und dabei bleiben. Der Wunsch, gute Software zu produzieren, mag eine dieser Motivationen sein, zusammen mit der Herausforderung und dem Bildungswert an schwierign Problemen zu arbeiten. Menschen haben aber auch ein eingebautes Bedürfnis, mit anderen zusammen zu arbeiten, und Respekt durch Zusammenarbeit zu geben und verdienen. Gruppen die gemeinschaftlich aktiv sind, müssen Normen entwickeln, die es erlauben, Leistungen einzelner die den Zielen der Gruppe dienen, durch Erwerb und Erhalt von Ansehen zu belohnen. Diese Normen werden nicht immer von allein auftauchen. Bei manchen Projekten – erfahrene Open-Source-Entwickler können wahrscheinlich spontan mehere nennen – haben Leute zum Beispiel anscheinend das Gefühl, dass Ansehen durch häufige und ausführliche Nachrichten angeeignet wird. Sie kommen nicht aus versehen zu diesem Schluss; sie kommen darauf, weil sie für lange, komplexe Argument, mit Respekt belohnt werden, ob das dem Projekt hilft oder nicht. Nachfolgend sind einige Techniken um eine Atmosphäre zu erzeugen, in dem Aktivitäten die Ansehen verschaffen auch konstruktive Aktivitäten sind. Delegierung Deligierung ist nicht nur eine möglichkeit um die Arbeit zu verteilen; es ist auch ein politisches und soziales Werkzeug. Betrachten Sie alle Auswirkungen, wenn Sie jemand darum bitten, etwas zu machen. Die offensichtlichste Folge ist, falls er annimmt, dass er die Aufgabe erledigt, und Sie nicht. Eine weitere Folge ist aber, dass ihm bewusst gemacht wird, dass Sie ihm zugetraut haben die Aufgabe zu erledigen. Desweiteren, wenn Sie die Anfrage in einem öffentlichen Forum gemacht haben, weiß er auch, dass ander in der Gruppe auch über dieses Vertrauen unterrichtet wurden. Er mag auch etwas Druck verspüren anzunehmen, was bedeutet, dass Sie derart Fragen müssen, dass es ihm erlaubt taktvoll abzulehnen, falls er die Aufgabe nicht wirklich haben will. Wenn die aufgabe Koordination mit anderen im Projekt erfordert, schlagen Sie effektiv vor, dass er sich mehr beteiligt, Verbindungen aufbaut die vielleicht sonst nicht entstanden wären, und möglicherweise zu einer Autorität auf in einem Teilgebiet des Projekts wird. Die zusätzliche Beteiligung mag einschüchternd sein, oder ihn dazu führen, sich auch auf andere Arten zu engagieren, durch ein erweitertes Gefühl seiner gesamten Verpflichtung. Aufgrund all dieser Auswirkungen, macht es oft Sinn, jemand anderes darum zu bitten, etwas zu machen, selbst wenn Sie wissen, dass Sie es selber schneller oder besser machen könnten. Es gibt natürlich hierfür manchmal sowieso ein gänzlich wirtschaftliches Argument: Die Kosten der Möglichkeit es selber zu machen können zu hoch sein – es mag etwas noch wichtigeres geben, was Sie mit der Zeit machen könnten. Aber selbst wenn das Argument über die Kosten der Möglichkeit nicht gilt, kann es trotzdem in Ihrem Interesse sein, jemand anderen darum zu bitten die Aufgabe an sich zu nehmen, denn auf lange Sicht wollen Sie diese Person tiefer in das Projekt einbeziehen, selbst wenn es etwas mehr Zeit bedeutet, zunächst ein wenig mehr auf sie aufzupassen. Die umgekehrte technig gilt auch: Wenn Sie sich gelegentlich für Arbeit melden, welches jemand anderes nicht machen will oder wofür er nicht die nötig Zeit hat, werden Sie sein Wohlwollen und Respekt ernten. Deligierung und Ersetzung drehen sich nicht nur darum einzelne Aufgaben erledigt zu bekommen; es geht auch darum Leute in eine engere Verpflichung an das Projekt zu bringen. Unterscheiden Sie eindeutig zwischen Anfrage und Anweisung Manchmal kann man erwarten, dass eine Person eine bestimmte Aufgabe annehmen wird. Wenn jemand zum Beispiel eine Bug im Code schreibt, oder Code committed, welche auf irgend eine offensichtliche Art, nicht den Richtlinien des Projekts entspricht, dann reicht es aus auf das Problem hinzuweisen, und sich danach zu verhalten, als würden Sie annehmen, dass sich die Person darum kümmern wird. Es gibt aber andere Situationen bei denen es keineswegs klar ist, dass Sie ein Recht darauf haben, eine Reaktion zu erwarten. Die Person kann machen worum Sie ihn bitten, oder auch nicht. Da keiner es mag, als selbstverständlich erachtet zu werden, müssen Sie für den Unterschied zwischen diesen beiden Arten von Situationen, einfühlsam sein, und Ihre Anfragen entsprechend anpassen. Eine Sache bei dem Leuten fast immer sofort verärgert werden, ist wenn sie auf eine Art gefragt werden etwas zu machen, welches impliziert, dass Sie der Meinung sind, dass es ganz klar ihre Verantwortung ist, wenn Sie anderer Meinung sind. Zum Beispiel ist die Zuweisung eintreffender Meldungen eine besonders reichhaltiger Boden für diese Art von Verärgerung. Die Beteiligten in einem Projekt wissen für gewöhnlich, wer Exerte in welchen Bereichen ist, wenn also eine Bug-Meldung eintrifft, wird es oft ein oder zwei Personen geben, von denen jeder weiß, dass sie das Problem schnell beheben könnten. Wenn Sie jedoch die Meldung einer dieser Personen zuweisen, ohne vorherige Zustimmung, kann er das Gefühl bekommen, in eine unbequeme Lage gebracht zu werden. Er spürt den Druck der erwartung, aber auch, dass er effektiv für seine Kentnisse bestraft wird. Schließlich erlangt man diese Kenntnisse, indem man Bugs behebt, also sollte vielleicht jemand anderes diesen übernehmen! (Beachten Sie, dass Ticket-Systeme die Tickets automatisch bestimmten Personen zuweisen, aufgrund von Informationen in dem Ticket, wahrscheinlich nicht so sehr beleidigend sind, da jeder weiß, dass die Zuweisung automatisch durchgeführt wurde, und keine Andeutung von menschlichen Erwartungen ist.) Obwohl es nett wäre die Last so gleichmäßig wie möglich zu verteilen, gibt es bestimmte Zeiten, wenn Sie einfach die Person die einen Fehler am schnellsten beheben kann, dazu ermutigen wollen. Angesichts dessen, dass Sie es sich den Kommunikationsaufwand bei jeder solchen Zuweisung nicht leisten können ("Wärst du bereit dir diesen Bug anzuschauen? "Ja." "Alles klar, dann weise ich dir den Ticket zu." "Ok."), sollten Sie die Zuweisung einfach in der Form einer Anfrage machen, welche keinen Druck vermittelt. Praktisch alle Ticket-Systeme erlauben, dass ein Kommentar an eine Zuweisung angehängt wird. In diesem Kommentar, können Sie soetwas sagen:
Ich weise dir das mal zu, hmustermann, weil du dich am besten in diesem Code auskennst. Wenn du keine Zeit hast es dir anzuschauen, kannst du es ruhig zurückgeben. (Und sag mir bescheid, wenn du in Zukunft solch Anfragen lieber nicht bekommen würdest.)
Das unterscheidet eindeutig zwischen der Anfrage für eine Aufgabe und Annahme dieser Aufgabe seitens des Empfängers. Das Publikum hier ist nicht nur der Zugewiesene, es sind alle: Die ganze Gruppe sieht eine öffentliche bestätigung der Fähigkeiten des Zugewiesenen, die Nachricht macht aber auch klar, dass es ihm frei steht, die Verantwortung dafür anzunehmen oder abzulehnen. Bleiben Sie nach dem Deligieren auf dem Laufenden Wenn Sie jemanden darum bitten, etwas zu machen, behalten Sie es im Hinterkopf, und schließen Sie mit ihm danach an, egal was passiert. Die meisten Anfragen werden in öffentlichen Foren gemacht, und sind ungefähr von der Art "Kannst du dich um X kümmern? Sag uns bescheid, egal wie du dich entscheidest; kein Problem wenn du keine Zeit hast, wir müssens nur wissen". Sie können darauf eine Antwort bekommen oder auch nicht. Wenn ja, und die Antwort negativ war, ist der Kreis geschlossen – Sie werden eine andere Strategie versuchen müssen um mit X um zu gehen. Wenn es eine positive Antwort ist, da behalten Sie den Verlauf des Tickets im Auge, und machen Sie Anmerkungen zu den Fortschritten die Sie sehen oder nicht sehen (jeder arbeitet besser, wenn er weiß, dass jemand anderes seine Arbeit zu schätzen weiß). Wenn es nach ein paar Tagen keine Antwort gibt, fragen Sie nochmal nach, oder schreiben Sie, dass Sie keine Antwort bekommen haben und jetzt nach jemand anderem suchen der es erledigt. Oder machen Sie es einfach selber, aber vergewissern Sie sich, dass Sie keine Antwort auf die ursprüngliche Anfrage bekommen haben. Öffentlich anzumerken, dass es keine Antwort gab, verfolgt nicht den Zweck, die Person zu beschämen, und Ihre Anmerkungen sollten dementsprechend formuliert sein. Der Sinn ist einfach zu zeigen, dass an Antworten auf Ihre Nachfragen Sie Anfragen gemacht haben, und dass Sie die Antworten die Sie bekommen tatsächlich interessiert sind und sie wahrnehmen. Das erhöht die Wahrscheinlichkeit, dass Leute beim nächsten mal ja sagen, da Sie (wenn auch nur unbewusst) feststellen, dass Sie sicherlich bemerken werden, wenn sie irgend welche Arbeit erledigen, angesichts Ihrer Aufmerksamkeit gegenüber dem viel weniger sichtbaren Ereignis, dass jemand nicht antwortet. Achten Sie darauf, wofür Leute sich interessieren Eine weitere Sache die Leute glücklich macht, ist wenn man ihre Interessen bemerkt – allgemein wird jemand umso gemütlicher sein, je mehr Aspekte seiner Persönlichkeit Sie bemerken und erinnern, und umso eher wird er in Gruppen arbeiten wollen, an denen Sie beteiligt sind. Es gab zum Beispiel eine scharfe Unterscheidung im Subversion-Projekt zwischen Personen die eine endgültige 1.0-Version erreichen wollten (was wir letztendlich schafften), und solchen, die hauptsächlich neue Funktionen hinzufügen sowie an interessante Probleme bearbeiten wollten, die es aber nicht sonderlich kümmerte, wann 1.0 erscheinen würde. Keine dieser Positionen ist besser oder schlechter als die andere; sie sind lediglich zwei unterschiedliche Arten von Entwicklern, und beide erledigen eine Menge Arbeit im Projekt. Wir lernten aber schnell, dass es wichtig war nicht anzunehmen, dass die Aufregung um den Schub auf 1.0 von jedem geteilt wurde. Elektronische Medien können sehr trügerisch sein: Sie können eine Atmosphäre einer gemeinsammen Bestimmung spüren, wenn in Wirklichkeit es nur bon den Personen geteilt wird, mit denen Sie zufällig geredet haben, wären andere völlig unterschiedliche Prioritäten haben. Je ehere Sie sich bewusst sind, was Leute von dem Projekt wollen, desto effektiver können Sie an ihnen Anfragen stellen. Selbst ein Verständnis dafür zu zeigen, was sie wollen, ohne eine zugehörige Anfrage, ist in sofern nützlich, dass es jeder Person bestätigt, dass sie nicht nur eine weiteres Teilchien in einer einheitlichen Masse ist. Lob und Kritik Lob und Kritik sind keine Gegensätze: In vielerlei Hinsicht, sind sie sich sehr änhnlich. Beide sind vor allem Formen von Aufmerksamkeit, und sind am effektivsten, wenn sie eher spezifisch sind als allgemein. Beide sollten, mit konkreten Zielen im Blick, angewandt werden. Beide können durch Iinflation geschwächt werden: Zuviel oder zu oft zu loben, wird den Wert des Lobs mindern; das gleiche gilt für Kritik, obwohl in der Praxis Kritik eher eine Reaktion ist und deshalb etwas weniger anfällig für Wertminderung ist. Eine wichtige Funktion, der technischen Kultur ist, dass detailierte leidenschaftslose Kritik oft als eine Art Lob verstanden wird (wie in im Kapitel beschrieben), aufgrund der Implikation, dass die Arbeit des Empfängers die Zeit, welche für seine Analyse benötigt wird, es wert ist. Beide dieser Bedingungen – detalliert und leidenschaftslos – müssen jedoch erfüllt sein, damit das wahr ist. Wenn jemand zum Beispiel eine schlampige Änderung am Code macht, ist es nutzlos (und sogar schädlich) darauf zu antworten, indem man einfach sagt "Das war schlampig". Schlampigkeit ist letztlich die Eigenschaft einer Person, nicht ihrer Arbeit, und es ist wichtig, Ihre Reaktionen auf die Arbeit zu konzentrieren. Es ist viel effektiver, taktvoll und ohne Böswilligkeit, alles zu beschreiben was an der Arbeit falsch ist. Wenn das die dritte oder vierte sorglose Änderung nacheinander von der selben Person ist, ist es angemessen das am Ende Ihrer Kritik zu sagen – wieder ohne Wut – um klar zu machen, dass man das Muster bemerkt hat. Wenn jemand sich nicht in reaktion auf die Kritik bessert, ist die Lösung nicht mehr oder stärkere Kritik. Die Läsung ist für die Gruppe diese Person aus seiner Position von Inkompetenz zu entfernen, so das es die verletzten Gefühle so gering wie möglich hält; siehe später in diesem Kapitel für Beispiele. Was jedoch selten vorkommt. Die meisten Leute reagieren ziemlich gut auf Kritik die spezifisch und detalliert ist, sowie eine klare (wenn auch nicht ausgesprochene) Erwartung einer Verbesserung beinhaltet. Lob wird natürlich keine Gefühle verletzen, was aber nicht bedeutet, dass sie es weniger vorsichtig nutzen sollten als Kritik. Lob ist ein Werkzeug: Bevor Sie es nutzen, fragen Sie sich, warum Sie es nutzen wollen. In der Regel ist es keine gute Idee, Leute für das zu loben, was sie normalerweise machen, oder für Aktivitäten, welche ein normaler und zu erwartender Bestandteil der Teilnahme an der Gruppe sind. Würden Sie damit beginnen, wäre es schwierig, hierin ein Ende zu finden: Sollten Sie jeden für die übliche Arbeit loben? Wenn Sie dann manche auslassen, werden diese sich fragen warum. Es ist viel besser, Lob und Dankbarkeit sparsamm zum Ausdruck zu bringen, als Reaktion auf ungewöhnliche oder unerwartete Anstrengungen, mit der Absicht mehr solcher Arbeit zu ermutigen. Wenn es scheint, dass ein Beteiligter sich in einem Zustand dauerhaft erhöhter Produktivität bewegt hat, sollten Sie das Maß an Lob bei dieser Person entsprechend anpassen. Wiederholtes Lob für normales Verhalten wird mit der Zeit sowieso bedeutungslos. Stattdessen sollte diese Person spüren, dass ihr hoher Grad an Produktivität als normal und natürlich erachtet wird, und nur Arbeit, die darüber hinaus geht, sollte besonders zur Kenntnis genommen werden. Das soll natürlich nicht heißen, dass die Beiträge der Person nicht gewürdigt werden sollten. Denken Sie aber daran, dass wenn das Projekt richtig eingerichtet wurde, alles was diese Person macht, ohnehin sichtbar sein wird, und die Gruppe wird wissen (und die Person wird wissen, dass die Gruppe weiß), was sie alles macht. Neben direktem Lob gibt es auch andere Möglichkeiten die Arbeit von jemand anzuerkennen. Sie könnten beiläufig erwähnen, wärend Sie ein verwandtes Thema besprechen, dass die Person eine Menge Arbeit in dem entsprechenden Bereich geleistet hat und auf dem Gebiet Experte ist; Sie könnten sie öffentlich zu einer Frage über den Code konsultieren; oder vielleicht am effektivsten, könnten Sie die Arbeit, die sie geleistet hat anderweitig nutzen, damit sie sieht, dass andere sich jetzt mit ruhigem Gewissen auf die Ergebnisse ihrer Arbeit verlassen. Es ist wahrscheinlich nicht nötig das alles auf eine berechnete Art zu machen. Jemand der regelmäßig große Beiträge in einem Projekt leistet, wird es wissen, und wird standardmäßig eine einflussreiche Position einnehmen. Es gibt gewöhnlich kein Bedarf für explizite Schritte, um das sicherzustellen, es sei denn Sie spüren, dass ein Beteiligter aus irgendwelchen Gründen nicht entsprechend geschätzt wird. Verhindern Sie Revierabsteckung Geben Sie auf Beteiligte acht, die versuchen exklusiven Besitz für bestimmte Bereiche im Projekt abzustecken, und bei denen es scheint, als wollten Sie in den Bereichen, die ganze Arbeit machen, sogar bis zu dem Grad, dass sie Arbeit, die andere anfangen, aggresiv übernehmen. Solches Verhalten mag am Anfang sogar gesund erscheinen. Oberflächlich, sieht es aus, als würde die Person mehr Verantwortung übernehmen, und in dem gegebenen Bereich mehr Aktivität zeigen. Auf lange Sicht ist es allerdings schädlich. Wenn Leute ein "Nicht betreten!"-Schild sehen, bleiben sie weg. Das hat eine reduzierte Überprüfung innerhalb dieses Bereichs zur Folge, sowie größere Zerbrechlichkeit, da der einzelne Entwickler zu einem kritischen Ausfallpunkt wird. Schlimmer noch, es zerbricht den gemeinschaftlichen, egalitären Geist des Projekts. Die Theorie sollte immer sein, dass jeder Entwickler gerne bei jeder Aufgabe und zu jeder Zeit helfen kann. In der Praxis, funktionieren die Sachen ein wenig anders: Leute haben doch ihre Bereiche, in denen sie mehr Einfluss haben, und nicht Experten verweisen oft auf die Experten auf bestimmten Gebiten des Projekts. Die Hauptsache ist, dass das alles freiwillig ist: Informelle Autorität wird aufgrund von Kompetenz und bewiesenem Urteilsvermögen erteilt, sollte aber nie aktiv genommen werden. Selbst wenn die Person wirklich Kompetent ist, ist es trotzdem noch kritisch, dass sie diese Autorität informell hält, durch das Bewusstsein des Projekts, und dass die Autorität sie niemals dazu bringt andere davon auszuschließen, in dem Bereich zu arbeiten. Die Arbeit von jemand aus technischen Gründen abzuweisen oder zu bearbeiten ist natürlich etwas föllig anderes. Dort ist die Arbeit das entscheidende, nicht wer zufällig den Torwächter gespielt hat. Es kann sein, dass die selbe Person für einen bestimmten Bereich die meisten commits überprüft, so lange er aber nie versucht jemand anders daran zu hinder auch diese Arbeit zu machen, ist wahrscheinlich alles in Ordnung. Um gegen das einsetzende Entstehen von Revieren anzukämpfen, oder gar sein Auftauchen, sind viele Projekte dazu übergegangen, Namen von Autoren oder Zuständigen in Quellcode-Dateien zu verbieten. Ich stimme diesem Verfahren voll und ganz zu: Wir verfahren so im Subversion-Projekt, und es ist mehr oder weniger eine offizielle Richtlinie bei der Apache Software Foundation. ASF-Mitglied Sander Striker drückt es so aus:
Bei der Apache Software Foundation raten wir von der Nutzung von Autor-Markierungen in dem Quellcode ab. Es gibt dafür verscheidene Gründe, mal abgesehen von den rechtlichen Konsequenzen. Bei der gemeinschaftlichen Entwicklung geht es darum, als Gruppe an Projekten zu arbeiten, und sich als Gruppe um das Projekt zu kümmern. Anerkennung ist gut und sollte gewährt werden, allerdings auf eine Art welche keine falsche Anerkennung erlaubt, selbt implizite. Es gibt keine klare Grenze, wann man eine Autor-Markierung machen oder entfernen soll. Fügen Sie Ihren Namen hinzu, wenn sie ein Kommentar bearbeiten? Wenn Sie einen einzeiligen Fix hinzufügen? Entfernen Sie die alten Markierungen wenn sie den Code neu strukturieren, und es zu 95% anders aussieht? Was machen Sie mit Leuten die herumgehen und jede Datei anfassen, und gerade genug ändern, um eine virtuelle Quote zu erreichen, damit ihr Name überall ist? Es gibt bessere möglichkeiten, Anerkennung zu erweisen, und wir bevorzugen es, diese zu nutzen. Aus technischer Sicht sind Autor-Markierungen unnötig; wenn Sie herrausfinden wollen, wer einen bestimmten Abschnitt im Code geschrieben hat, können Sie das Versionsverwaltungssystem dazu konsultieren. Diese Markierungen neigen auch dazu, zu veralten. Wollen Sie wirklich privat zu einem Stück Code kontaktiert werden, welches Sie vor fünf Jahren geschrieben haben und froh sind, es vergessen zu haben?
Die Quellcode-Dateien eines Software-Projekts sind der Kern seiner Identität; sie sollten die Tatsache wiederspiegeln, dass die Entwicklergemeinschaft im Ganzen dafür verantwortlich ist, und nicht in einzelne Machtbereiche aufgeteilt werden. Manchmal sprechen sich Leute für die Markierung von Autor oder Zuständigen in Quelldateien aus, mit der Begründung, dass es eine sichtbare Anerkennung derjenigen sei, die am meisten Arbeit geleistet haben. Es gibt mit der Argumentation zwei Probleme. Erstens ergibt sich dadurch die Frage, wieviel Arbeit man leisten muss, um seinen Namen dort auch aufgelistet zu bekommen. Zweitens verschmilzt dadurch die Anerkennung und die Zuständigkeit: Arbeit in der Vergangenheit gemacht zu haben, impliziert keinen Besitz des Bereichs, in dem die Arbeit gemacht wurde, es ist aber schwierig wenn nicht sogar unmöglich, solche Andeutungen zu vermeiden, wenn die Namen von Individuen oben in den Quelldateien aufgelistet sind. So oder so kann die Information über Anerkennung schon aus dem Protokoll der Versionsverwaltung sowie aus anderen Kanälen wie den Archiven der Mailinglisten entnommen werden. Es geht also keine Information verloren, wenn man es in den Quelldateien verbietet. Ein gutes Gegenargument liefert der Mailinglisten-Thread mit dem Titel "having authors names in .py files" unter , insbesondere das Posting von William Stein. Der Kerngedanke ist hier, denke ich, dass viele der Autoren einer Kultur (dem Akademisch-mathematischen Kreis) entstammen, in der die direkt in den Quellen angesiedelte Anrechnung der Autorschaft als normgerecht und wichtig empfunden wird. Unter solchen Umständen kann es besser sein, Autorennamen in die Quelldateien aufzunehmen und dazu genau auszuführen, was welcher Autor beigetragen hat, weil die Mehrheit der Beteiligten diesen Stil der Anerkennung erwarten wird. Wenn Ihr Projekt sich entscheidet einzelne Namen nicht in den Quelldateien zu nennen, sollten Sie es nicht übertreiben. Viele Projekte haben zum Beispiel einen contrib/ Bereich, in dem kleine Werkzeuge und hilfsscripte getan werden, die oft von Personen geschrieben werden, die an sonsten nicht mit dem Projekt im Zusammenhang stehen. Es ist völlig in Ordnung wenn diese Dateien die Namen der Autoren beinhalten, da sie nicht wirklich von dem Projekt als ganzes gepflegt werden. Wenn andererseits, an einem Hilfsmittel von anderen Personen aus dem Projekt angefangen wird gehackt zu werden, könnte es irgendwann angebracht sein, es in einen weniger isolierten Bereich zu bewegen und, angenommen der ursprüngliche Autor hat keine Einwände, den Namen des Autors entfernen, damit der Code wie jede andere von der Gemeinschaft gepflegte Ressource aussieht. Wenn der Autor im Bezug darauf sensibel ist, sind Kompromisslösungen annehmbar, wie zum Beispiel:
# indexclean.py: Entferne die alten Daten aus einem Scanley Index. # # Ursprünglicher Autor: K. Maru <kobayashi@nocheinweitereremaildienst.com> # Derzeit gepflegt von: Dem Scanley Projekt <http://www.scanley.org/> # und K. Maru. # # ...
Es ist aber besser wenn möglich solche Kompromisse zu vermeiden, und die meisten Autoren lassen sich überreden, da sie froh sind, dass ihr Beitrag zu einem engeren Bestandteil des Projekts gemacht wird. Wichtig ist es, sich daran zu erinnern, dass es bei jedem Projekt eine fließende Grenze zwischen dem Kern und der Peripherie gibt. Die Hauptdateien des Quellcodes der Software sind ganz klar ein Teil des Kerns, und sollten als von der Gemeinschaft gepflegt, angesehen werden. Begleitende Werkzeuge oder Teile einer Dokumentation können andererseits die Arbeit eines Einzelnen sein, der sie eim wesentlichen alleine pflegt, auch wenn die Werke mit dem Projekt zu tun haben, und sogar verteilt werden. Es muss keine für alle Gültige Regel auf jede Datei angewandt werden, so lange das Prinzip aufrecht erhalten wird, nicht zu erlauben, dass von der Gemeinschaft gepflegte Ressourcen zu den Revieren von Individuen werden. Der Automatisierungsgrad Versuchen Sie nicht, Menschen Arbeiten verrichten zu lassen, die an ihrer Stelle von Maschinen gemacht werden könnten. Als Grundregel ist die Automatisierung einer wiederkehrenden Aufgabe mindestens zehn Mal so viel Einsatz wert, wie das, was ein Entwickler aufbringen würde, wenn er sie einmal macht. Bei sehr häufigen oder sehr komplexen Aufgaben, kann dieses Verhältnis sogar leicht auf das zwanzigfache oder mehr ansteigen. Sich als ein "Projektleiter" anzusehen, im gegensatz zu noch ein weiteren Entwickler, mag an dieser Stelle eine nützliche Einstellung sein. Manchmal sind einzelne Entwickler zu sehr in kleinarbeit verwickelt, um das Gesamtbild zu sehen, und zu erkennen, dass jeder eine menge Mühe daran vergeudet, automatisierbare Aufgaben händisch zu erledigen. Selbst diejenigen, die es erkennen, werden sich nicht unbedingt die Zeit nehmen das Problem zu lösen: Weil jede einzelne Durchführung der Aufgabe sich nicht wie eine riesige Last anfühlt, keiner wird je derart davon genervt, um etwas dagegen zu machen. Was die Automatisierung so wünschenswert macht ist, dass die kleine Last mit der Anzahl der wiederholungen von jedem Entwickler multipliziert wird, und diese Zahl wird wiederum mit der Anzahl der Entwickler multipliziert. Ich benutze hier den Begriff "Automatisiertung" im weiten Sinne, nicht nur um wiederholte vorgänge zu bezeichnen, bei denen ein oder zwei Variablen sich jedes mal ändern, sondern für jede Art von technischer Infrastruktur die Menschen unterstützt. Das mindeste an standardmäßiger Automatisierung die heutzutage erforderlich ist um ein Projekt zu betreiben, wird in beschrieben, aber jedes Projekt kann auch seine eigenen besonderen Probleme haben. Eine Gruppe die an der Dokumentation arbeitet, könnte vielleicht eine Webseite haben wollen, welche zu jeder Zeit die aktuellsten Versionen der Dokumente anzeigt. Da die Dokumentation oftmals in einer Auszeichnungssprache wie XML geschrieben, kann es einen Kompilierungsschritt, meistens ziemlich umständlich, geben um die Dokumente für die Darstellung oder zum herunterladen zu erstellen. Eine Webseite einzurichten, bei dem diese Kompilierung automatisch nach jedem Commit passiert, kann sehr kompliziert und zeitaufwendig sein – es ist es aber wert, selbst wenn Sie mehr als einen Tag brauchen, um es einzurichten. Die übergreifenden Vorteile, Seiten zu haben, die immer aktuell sind, ist enorm, auch wenn die Kosten sie nicht zu haben zu einem Zeitpunkt vielleicht nur nach einer kleinen Unbequemlichkeit, für einen einzelnen Entwickler aussieht. Solche Schritte vorzunehmen, eliminiert nicht nur die verschwendete Zeit, sondern auch die Fesseln und Frustration die entsteht, wenn Menschen Fehler machen (wie es zwangsläufig der Fall sein wird), wenn sie versuchen komplizierte Vorgänge händisch durchzuführen. Dederministische Tätigkeiten, mit mehreren Schritten sind genau das, wofür Computer erfunden wurden; sparen Sie sich ihre Menschen für interesanntere Sachen auf. Automatisiertes Testen Automatisierte Testläufe sind für jedes Softwareprojekt hilfreich, insbesondere aber für Open-Source-Projekte, denn automatische Tests (insbesondere Regressionstests) erlauben es Entwicklern sich bei der Änderung von ihnen unbekanntem Code sicher zu fühlen, und ermutigt daruch experimentelle Entwicklung. Da es so schwierig ist, eine Bruchstelle händich zu finden – man muss im wesentlichen raten wo man etwas kapput gemacht haben könnte, und verschiedene Versuche machen, um das Gegenteil zu beweisen – erspart es dem Projekt eine Menge Zeit, möglichkeiten zu haben, um solche Bruchstellen automatisch zu erkennen. Leute sind dadurch auch viel entspannter, wenn sie große Schwaden von Code neu gestalten, und trägt auf lange Sicht entsprechend zu der Wartbarkeit der Software bei. Regressionstests Regressionstest (en. regression test) bedeutet, nach dem wiederauftauchen bereits behobener Fehler zu suchen. Der Sinn von Regressionstests ist, die Wahrscheinlichkeit zu verinngern, dass Änderungen am Code die Software auf unerwartete weise kaputt machen wird. Wenn ein Softwareprojekt anfängt größer und komplizierter zu werden, nimmt die Wahrscheinlichkeit für solche unerwarteten Nebenwirkungen allmählich. Ein guter Aufbau kann die Geschwindigkeit mit der sie zunimmt veringern, kann das Problem aber nicht komplett beseitigen. Viele Projekte haben aufgrund dessen, eine Testsreihe (en. test suite), eine separate Anwendung welche die Software des Projekts auf Arten aufruft, von denen man weiß, dass Sie in der Vergangenheit bestimmte Fehler aufgezeigt haben. Wenn die Testreihe es schafft einer dieser Fehler wieter auftauchen zu lassen, wird das als Regression bezeichnet, was soviel heißt wie, dass die Änderung von jemand einen vorher behobenen Bug wieder unbehoben gemacht hat. Siehe auch . Regressionstests sind kein Allheilmittel. Zum einen, funktioniert es am besten, bei Anwendungen mit Schnittstellen für die Kommandozeile. Software die vor allem durch graphische Benutzeroberflächen gesteuert wird, ist viel schwieriger programatisch zu betreiben. Ein weiteres Problem ist, dass das Framework der Testreihe oft ziemlich komplex sein kann, mit einer Lernkurve und einer Wartungslast, für sich ganz alleine. Diese Komplexität zu reduzieren, ist eines der nützlichsten Sachen, die Sie machen können, auch wenn es vielleicht eine wesentliche Menge an Zeit in Anspruch nehmen kann. Je einfacher es ist neue Tests zu der Testreihe hinzuzufügen, desto mehr Entwickler werden es machen, und desto weniger Fehler werden es in die fertige Version schaffen. Jede Mühe die aufgebracht wird, um das Schreiben von Tests einfacher zu machen, wird im Verlaufe des Projekts um ein Vielfaches zurückgezahlt werden. Viele Projekte haben eine "Mache den Build nicht Kaputt!" Regel, mit folgender Bedeutung: Machen Sie keinen Commit, welches verhindert, dass die Software kompiliert oder läuft. Die Person zu sein, welche den Build kaputt gemacht hat, ist meistens eine Quelle leichter Peinlichkeit und Verippung. Projekte mit Reihen von Regressionstests haben oft eine begleitende Regel: Mache keinen Commit, der die Tests nicht besteht. Es ist am einfachsten zu erkennen, wenn ein Test fehlschlägt, wenn die komplette Testreihe automatisch, jede Nacht durchgeführt wird, und die Ergebnisse an die Entwickler-Liste oder einen gesonderten Verteiler für die Testergebnisse geschickt werden; was ein weiteres Beispiel für Automatisierung ist, die sich lohnt. Die meisten freiwilligen Entwickler sind bereit, die zusätzliche Zeit zu investieren, um Regressionstests zu schreiben, so lange das Testsystem verständlich und einfach im Umgang ist. Änderungen zusammen mit Tests zu committen, wird als das verantwort Verhalten angesehen, und es ist auch eine einfache Gelegenheit für die Zusammenarbeit: Oft teilen sich zwei Entwickler die Arbeit bei der Behebung eines Fehlers auf, indem der eine den Fix schreibt, und der andere den Test. Der letztere Entwickler kann oft sogar mehr Arbeit haben, und da es schon weniger befriedigend ist einen Test zu schreiben als den Fehler tatsächlich zu beheben, ist es zwingend notwendig, dass es nicht schwieriger ist die Testreihe zu bearbeiten als es sein muss. Manche Projekte gehen sogar noch weiter, und haben die Anforderung, dass alle Bugfixes oder neue Funktionen von Tests begleitet werden. Ob das eine gute Idee ist oder nicht, hängt von vielen Faktoren ab: Die Natur der Software, die Zusammenstellung des Entwicklerteams, und wie schwierig es ist, die Tests zu schreiben. Das CVS () Projekt, hat schon seit langem eine solche Regel. Es ist theoretisch eine gute Richtlinie, da CVS eine Software zur Versionsverwaltung und desshalb sehr risikoscheu ist, in anbetracht der Möglichkeit die Daten der Nutzer zu verunstalten oder falsch handzuhaben. In der Praxis ist das Problem, dass die Regressionstest-Reihe von CVS eine einzige riesige Shellscript-Datei ist (witzigerweise mit dem Namen sanity.sh ), welche schwierig zu bearbeiten oder erweitern ist. Die schwierigkeit neue Tests hinzu zu fügen, zusammen mit der Forderung, dass Patches von neuen Tests begleitet werden bedeutet, dass CVS im wesentlichen vor Patches abeschreckt. Als ich an CVS gearbeitet habe, sahe ich manche Leute die anfingen an dem Code von CVS zu arbeiten und sogar Patches fertig zu stellen, aber aufgaben als ihnen gesagt wurde, dass sie einen neuen Test zu der sanity.sh mussten. Es ist normal etwas mehr Zeit damit zu verbringen, einen neunen Regressionstest zu schreiben, als an der Behebung des ursprünglichen Fehlers. CVS trieb dieses Phänomen aber ins extreme: man konnte Stunden bei dem Versuch verbringen, sein Test richtig zu gestalten, und es trotzdem falsch machen, da es einfach zu viele unvorhersehbare Komplexitäten gab, bei der Änderung einer 35.000 Zeilen lange Bourne-Shellscript-Datei. Selbst langjährige Entwickler murrten, als sie einen neuen Test hinzufügen mussten. Diese Situation entstand, weil wir alle nicht den Grad der Automatisierung in Betracht gezogen hatten. Es stimmt zwar, dass der wechsel auf ein echtes Test-Framework – ob eine Eigenanfertigung oder eine fertige – eine riesige Anstrengung gewesen wäre Man sollte bedenken, dass es nicht notwendig gewesen wäre alle Tests auf das neue Framework zu portieren; beide könnten friedlich neben einander leben, und nur die geänderten Tests würden bei Änderungen übernommen werden.. Es zu unterlassen, hat dem Projekt aber über die Jahre, viel mehr gekostet. Wieviele Bugfixes und Funktionen sind heute nicht in CVS, aufgrund der Behinderung durch eine umständliche Testreihe? Woe werden die genaue Zahl nie erfahren, es sind aber sicherlich eine mehr, wie die Anzahl der Bugfixes und Änderungen, auf denen die Entwickler hätten verzichten müssen, um ein neues Testsystem zu entwickeln (oder ein vorher existierendes zu integrieren). Die Aufgabe hätte eine endliche Zeit beansprucht, wärend der Nachteil, das derzeitige Testsystem weiter zu benutzen, in alle Ewigkeit weiterbestanden hätte, wenn nichts gemacht würde. Der Punkt ist nicht, dass die strikte Anforderungen, Tests schreiben zu müssen, schlecht ist, oder das es schlecht ist, wenn all Ihre Tests in eine Bourne-Shellscript-Datei geschrieben werden. Es kann hervorragend funktionieren, je nachdem wie Sie es entwerfen und was es testen muss. Das Wesentliche ist einfach, dass, wenn das Testsystem zu einer wesentlichen Behinderung für die Entwicklung wird, etwas getan werden muss. Das gleiche gilt für jede wiederkehrende Aufgabe, welche sich zu einem Hindernis oder Flaschenhals entwickelt. Behandeln Sie jeden Nutzer wie einen möglichen Freiwilligen Jede Interaktion mit einem Benutzer ist eine Gelegenheit, einen neuen Freiwilligen zu bekommen. Wenn ein Nutzer sich die Zeit nimmt, auf einer der Mailinglisten des Projekts, eine Nachricht zu schreiben, oder einen Fehler zu melden, hat er sich bereits als jemand gekennzeichnet, der ein größeres Potential zur Beteiligung hat, als die meisten Nutzer (von denen das Projekt niemals hören wird). Greifen Sie dieses Potential auf: Wenn er einen Fehler beschreibt, danken Sie ihn für die Meldung und fragen Sie ihm, ob er es versuchen möchte es zu beheben. Wenn geschrieben hat, um zu sagen, dass eine wichtige Frage in der FAQ gefehlt hat, oder dass die Dokumentation der Anwendung auf irgend eine Art unzureichend war, dann geben Sie das Problem zu (angenommen, es existiert wirklich) und fragen Sie ihr ob er interesiert wäre das fehlenden Material selber zu schreiben. Der Nutzer wird natürlich die meiste Zeit ablehnen. Aber es kostet nicht viel zu fragen, und jedes mal, wenn sie das tun, erinnert es die anderen Zuhörer in dem Forum, dass eine Beteiligung an dem Projekt etwas ist, das jeder leisten kann. Schränken Sie Ihre Ziele nicht darauf ein, neue Entwickler und Autoren für die Dokumentation zu bekommen. Es zahlt sich zum Beispiel auf lange sicht sogar aus, Leute zu trainieren, die gute Bug-Meldungen schreiben, so lange Sie nicht zu viel Zeit mit jeder einzelnen Person verbringen, und sie in Zukunft weiterhin Bug-Meldungen schreiben – was eher wahrscheinlich ist, wenn sie bei der ersten Meldung eine konstruktive Reaktion bekommen haben. Eine konstruktive Reaktion muss nicht die Behebung eines Fehlers sein, auch wenn dass immer ideal ist; es kann auch eine Anfrage nach weiteren Informationen sein, oder gar nur eine Bestätigung, dass das Verhalten tatsächlich ein Fehler ist. Menschen wollen zugehört werden. Zweitrangig, wollen sie das ihre Fehler behoben werden. Sie werden möglicherweise nicht immer letzteres zeitnahe geben können, aber Sie (oder vielmehr das Projekt, als ganzes) kann ihnen ersteres geben. Eine Konsequenz hiervon ist, dass Entwickler keine Wut an Personen auslassen sollten, die gut gemeinte aber vage Bug-Meldungen gemacht haben. Sowas ärgert mich persönlich, ganz besonders; ich sehe Entwickler die es immer wieder auf verschiedenen Open-Source-Mailinglisten machen und der Schaden, den das anrichtet, ist greifbar. Irgend ein unglückseliger Neuling schreibt ein nutzloses Ticket:
Hallo, ich krieg Scanley nicht zum Laufen. Jedes mal wenn ich es starte, gibt es einfach einen Fehler. Hat jemand schon dieses Problem gehabt?
Ein Entwickler – der diese Art von Ticket schon tausendmal gesehen hat, und kurz bedenkt, dass das beim Neuling nicht der Fall ist – wird folgendermaßen antworten:
Was sollen wir eigentlich mit so wenig Informationen machen, meine Fresse! Gib uns wenigstens ein paar Details, die Version von Scanley, dein Betriebssystem, und die Fehlermeldung!
Dieser Entwickler hat es nicht geschafft, die Sache aus der Sicht des Nutzers zu sehen, und auch zu bedenken, welche Auswirkung eine solche Reaktion auf alle anderen Personen die dem Wechsel zuschauen, haben könnte. Ein Nutzer der keine Programmiererfahrung hat, und keine vorhergehende Erfahrung mit Fehlermeldungen, wird nicht wissen, wie man ein Ticket schreibt. Wie behandelt man so eine Person richtig? Schulen Sie sie! Und tun Sie es in einer Weise, dass sie wiederkommt:
Tut mir leid, dass du Probleme hast. Wir werden mehr Informationen brauchen, um herauszufinden, was da los ist. Teile uns bitte deine Version von Scanley, dein Betriebssystem, und den genauen Text der Fehlermeldung mit. Das größte Hilfe wäre eine Auflistung der Befehle, die du ausgeführt hast, und die daraus resultierende Ausgabe. Siehe http://www.scanley.org/wie_man_einen_bug_meldet.html für weiteres.
Diese Art zu reagieren ist sehr viel effektiver, die erforderliche Information aus dem Benutzer herauszubekommen, da der Text aus Benutzersicht geschrieben ist. Erstens drückt das Sympathie aus: Du hattest ein Problem; wir leiden mit dir . (Das ist nicht in jeder Reaktion auf eine Bug-Meldung nötig; es hängt davon ab, wie schwerwiegend das Problem ist, und wie verärgert er zu sein scheint.) Zweitens, teilt es ihm mit wie er ein neues Ticket schreiben soll, damit es genügend Details enthält, um nützlich zu sein, anstatt ihn dafür herabzusetzen, dass er es nicht weiß – zum Beispiel erkennen viele Nutzer nicht das "Zeige uns den Fehler" in Wirklichkeit "Zeige uns den genauen Text des Fehlers, ohne etwas auszulassen oder zu kürzen" bedeutet. Wenn Sie zum ersten Mal mit einem solchen Nutzer arbeiten, müssen Sie im Bezug darauf explizit sein. Am Ende geben Sie einen Hinweis auf eine viel detalliertere und vollständige Anleitung, wie man Fehler melden sollte. Wenn Sie erfolgreich mit dem Nutzer Kontakt aufgenommen haben, wird er sich die Zeit nehmen, dieses Dokument zu lesen und sich danach zu richten. Das bedeutet natürlich, dass Sie das Dockument im voraus bereithalten müssen. Es sollte klare Anweisungen geben, welche Art von Information Ihr Entwicklerteam in jedem Ticket sehen möchte. Im Idealfall sollte es sich mit der Zeit auch entwickeln, entsprechend der bestimmten Art von fehlenden Informationen und Falschmeldungen; die Nutzer Ihres Projekts typischerweise an Sie richten. Die für das Subversion-Projekt erarbeitete Anleitung zum Melden von Fehlern ist so ziemlich ein Standardbeispiel dieser Form (siehe ). Beachten Sie, wie diese Anleitung in einer Einladung zum Einsenden eines Patches für den Bug endet. Das geschieht nicht, weil solch eine Einladung zu einem besseren Verhältnis von Patches zu Bugs führen würde – die meisten Nutzer die in der Lage sind, Fehler zu beheben, wissen bereits, dass ein Patch begrüßt wird, und müssen das nicht gesagt bekommen. Der eigentliche Sinn dieser Einladung ist, für alle Leser (insbesondere solche, die nicht vertraut mit dem Projekt oder freier Software im allgemeinen sind) zu betonen, dass das Projekt von freiwilligen Beiträgen lebt. In gewissem Sinne sind die derzeitigen Entwickler des Projekts nicht stärker dafür verantwortlich, den Bug zu beheben, als die Person, die ihn gemeldet hat. Das ist ein wichtiger Punkt, mit dem viele neue Nutzer nicht vertraut sein werden. Wenn sie es einmal begreifen, werden sie bereitwilliger dabei helfen, den Fix zu erstellen, wenn auch nicht, indem sie Code beitragen, sondern indem sie eine Anleitung zur Reproduktion des Fehlers geben, oder indem sie anbieten, die von anderen eingereichten Patches zu testen. Das Ziel ist, jeden Nutzer klar zu machen, dass es keinen immanenten Unterschied zwischen ihm und den Personen gibt, die an dem Projekt arbeiten – es ist eine Frage der Zeit und der Mühe, die man hinein steckt, nicht wer man ist. Die Mahnung sich vor wütenden Antworten zu hüten, gilt nicht gegenüber unhöflichen Nutzern. Ab und zu werden Fehler gemeldet oder Beschwerden eingereicht, die unabhängig von ihrem Informationsgehalt eine spöttische Verachtung für das Projekt beinhalten, aufgrund irgend eines Mangels. Solche Personen sind abwechselnd beleidigend und schmeichelnd, wie beispielsweise diese Person, die an die Subversion-Liste schrieb:
Wie kommt es, dass nach fast sechs Tagen immer noch keine Binärdateien für Windows hochgeladen wurden?!? Es ist immer wieder das gleiche und es ist ziemlich frustrierend. Warum werden diese Dinge nicht automatisiert, damit sie sofort verfügbar sind?? Wenn ihr einen "RC" Build macht, denke ich eure Idee ist, dass ihr wollt, dass Nutzer den Build testen, trotzdem gebt ihr aber keine Möglichkeit das zu machen. Wazu überhaupt eine Vorlaufphase haben, wenn ihr keine Möglichkeit zum Testen gebt??
Die anfängliche Reaktion zu dieser relativ flamehaften Nachticht war überraschend zurückhaltend: Man wies darauf hin, dass das Projekt eine Richtlinie hatte, keine offiziellen Binärdateien zu veröffentlichen, und man sagte ihm (mit unterschiedlichem Grad an Genervtheit), dass er sich freiwillig melden sollte, sie zu erstellen, wenn sie ihm so wichtig wären. Ob Sie es glauben oder nicht, seine nächste Nachricht fing mit diesen Zeilen an:
Als allererstes will ich sagen, dass ich Subversion Klasse finde und die Anstrenungen, die damit verbunden sind wirklich zu schätzen weiß. [...]
...und ging dann wieder daran, das Projekt dafür zu beschimpfen, dass es keine Binärdateien bereitstellte, wärend er sich immer noch nicht freiwillig meldete, irgend etwas dagegen zu machen. Danach wurde er von ca. 50 leuten auseinandergenommen und ich kann nicht sagen, dass mir das wirklich etwas ausmachte. Die "Null-Toleranz" Richtlinie in Bezug auf Beleidigungen, die in im Kapitel verfochten wurde, gilt für Personen, die mit dem das Projekt eine fortbestehende Interaktion haben (oder haben möchten). Wenn jemand aber von Anfang an klar macht, dass er eine Quelle beständiger Ärgernisses sein wird, hat es keinen Sinn, ihn willkommen zu heißen. Solche Situationen sind zum Glück relativ selten, und sie sind wesentlich seltener in Projekten, die sich bereits beim ersten Kontakt die Mühe machen, sich mit Nutzern auf eine konstruktive und zuvorkommende Art zu befassen. Teilen sie sowohl Verwaltungsaufgaben als auch technische Aufgaben Teilen Sie sowohl die Bürde der Verwaltung als auch die technische Bürde das Projekt in Gang zu halten. Mit zunehmender Komplexität eines Projekts ist mehr und mehr Arbeit in Management und Informationsfluss erforderlich. Es gibt keinen Grund diese Bürde nicht zu teilen; wobei, sie zu teilen, nicht notwendigerweise eine Hierarchie erfordert – was sich in der Praxis entwickelt, entspricht eher einer Peer-to-Peer-Topologie als einer militärichen Befehlsstruktur. Manchmal sind die Rollen der Verwaltung formalisiert, und manchmal bilden sie sich spontan. Im Subversion-Projekt haben wir einen Patchesverwalter, einen Übersetzungsverwalter, einen Dokumentationsverwalter, einen Ticketverwalter (wenn auch inoffiziell), und einen Versionsverwalter. Manche dieser Rollen wurden bewusst von uns eingeführt, andere entstanden von allein; da das Projekt wächst, erwarte ich, dass weitere Rollen hinzukommen. Unten werden wir diese und ein paar andere Rollen im Detail untersuchen (außer der des Versionsverwalters, die bereits in und im vorhergehenden Kapitel besprochen wurde). Achten Sie einmal beim Lesen der Beschreibungen darauf, wie keine der Rollen die exklusive Kontrolle über den entsprechenden Bereich erfordert. So hindert der Ticketverwalter andere nicht daran, Änderungen an der Ticket-Datenbank vorzunehmen, der FAQ-Verwalter besteht nicht darauf, der einzige zu sein, der die FAQ bearbeitet, und so weiter. Bei diesen Rollen geht es durchweg um Verantwortung, nicht um eine Monopolstellung. Ein wichtiger Teil der Arbeit des Verwalters eines Bereichs ist es, zu bemerken wenn andere in diesem Bereich arbeiten, und sie anzuleiten, die Dinge ganauso zu erledigen wie der Verwalter, damit die nebeneinander laufenden Anstrengungen einander stärken, anstatt miteinander in Konflikt zu geraten. Der Verwalter eines Bereichs sollte die Abläufe dokumentieren, nach denen er die Arbeit erledigt, damit, sollte einmal gehen, jemand anders die Rolle übernehmen kann. Manchmal gibt es einen Konflikt: Zwei oder mehr Personen erheben Anspruch auf dieselbe Rolle. Hier gibt es kein Patentrezept. Sie könnten anregen, dass jeder Freiwillige einen Vorschlag (eine "Bewerbung") einreicht, und alle Commit-Berechtigten darüber abstimmen lassen, welche die beste ist. Das ist aber umständlich und unter Umständen ungeschickt. Ich halte es für besser, die Kandidaten einfach darum zu bitten, das unter sich auszumachen. Meist schaffen sie das auch, und sie werden mit dem Ergebnis zufriedener sein als mit einer von außen aufgezwungenen Entscheidung. Patchverwalter In einem freien Software-Projekt, dem eine Menge Patches zugehen, kann es ein Albtraum sein, den Überblick darüber zu behalten, welche Patches angekommen sind und wie über sie entschieden wurde, ganz besonders wenn es auf eine dezentralisierte Art geschieht. Die meisten Patches erreichen das Projekt über die Entwickler-Mailingliste (obwohl manche zuerst in dem Ticket System auftauchen, oder auf externen Webseiten), und es gibt unterschiedliche Routen, die ein Patch nach seiner Ankunft einschlagen kann. Manchmal schaut sich jemand einen Patch an, findet Fehler darin und schickt ihn zur Berichtigung an seinen Autor zurück. Das führt normalerweise zu einem sich wiederholenden Vorgang – für alle auf der Mailingliste sichtbar –, bei dem der ursprüngliche Autor die überarbeiteten Versionen des Patches wieder zurück schickt, bis der Überprüfende nichts mehr zu beanstanden hat. Es ist nicht immer leicht zu erkennen, wann dieser Vorgang abgeschlossen ist: Wenn der Überprüfende den Patch committet, dann ist er eindeutig vorbei. Tut er es aber nicht, kann es auch daran liegen, dass er einfach nicht genügend Zeit hatte, oder selbst über keine Commit-Berechtigung verfügt, und keinen anderen Entwickler dazu überreden konnte, es zu tun. Eine weitere häufige Antwort auf einen Patch ist eine freilaufende Diskussion, nicht unbedingt über den Patch selbst, sondern darüber, ob das ihm zu Grunde liegende Konzept gut ist. Zum Beispiel könnte Der Patch einen Fehler beheben, aber das Projekt bevorzugt es, den Fehler auf eine andere Art zu beheben: als Teil der Lösung einer allgemeineren Klasse von Problemen. Oft ist das nicht im Voraus bekannt, und es ist der Patch, der diese Entdeckung anregt. Gelegentlich geht ein Patch unter völligem Stillschweigen ein. Normalerweise liegt das daran, dass im Moment kein Entwickler die Zeit aufbringt, den Patch unter die Lupe zu nemen, jader hofft, dass jemand anders das übernimmt. Da es keine bestimmte Grenze gibt, wie lang jede Person wartet, bis jemand anders den Ball ins Rollen bringt und in der Zwischenzeit immer andere Prioritäten auftauchen, passiert es sehr leicht, dass ein Patch durchs Netz fällt, ohne dass irgend jemand das gewollt hätte. So kann das Projekt einen nützlichen Patch verpassen, und das hat weitere schädliche Nebeneffekte: Es ist entmutigend für denjenigen, der Arbeit in den Patch investiert hat, und es lässt das Projekt als Ganzes den Anschein der Verwahrlosung erwecken, besonders für andere die im Begriff sind, Patches einzureichen. Die Aufgabe des Patchverwalters ist sicherzustellen, dass Patches nicht "durchs Netz schlüpfen". Das wird erreicht, indem jeder Patch bis zu irgend einem stabilen Zustand verfolgt wird. Der Patchverwalter beobachtet jeden Thread auf der Mailingliste, der sich aus dem Einreichen eines Patches ergibt. Wenn dieser mit einem Commit des Patches endet, tut er gar nichts. Wenn er in eine Schleife von Überprüfung und Überarbeitung übergeht, welche in einer finalen Version, aber ohne Commit endet, schreibt er ein Ticket, das auf die finale Version verweist, sowie auf den entsprechenden Thread, damit es für Entwickler, die daran später anschließen wollen, eine permanente Aufzeichnung gibt. Wenn der Patch ein bereits bestehendes Ticket betrifft, fügt er dem Ticket einen Kommentar mit der relevanten Information hinzu, anstatt ein neues zu eröffnen. Wenn ein Patch überhaupt keine Reaktion erhält, wartet der Patchverwalter ein paar Tage, uns greift es dann auf, indem er fragt, ob irgend 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 angewendet werden sollte, und Gründe dafür angeben, oder er kann es sich anschauen, worauf einer der vorher beschriebenen Wege eingeschlagen wird. Wenn es immer noch keine Antwort gibt, wird der Patchverwalter unter Umständen ein Ticket für den Patch eröffnen oder nicht, je nachdem, wie er es für richtig hält, zumindest hat der ursprüngliche Autor irgendeine Antwort erhalten. Einen Patchverwalter zu haben, hat für das Entwicklerteam von Subversion eine Menge Zeit und geistige Energie gespart. Ohne eine designierte Person, die 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 anders es macht? Sollte ich versuchen ihn im Auge zu behalten? Aber wenn andere das nun auch tun, dann würden wir unnötig unsere Anstrengungen verdoppeln." Der Patchverwalter lässt die zweite Mutmaßung in dieser Situation verschwinden. Jeder Entwickler kann die Entscheidung treffen, die für ihn in dem Moment richtig ist, da er den Patch zum ersten mal sieht. Wenn eine Überprüfung anschließen möchte, kann er das tun – der Patchverwalter wird sein Verhalten entsprechend anpassen. Wenn er den Patch komplett ignorieren will, ist das auch in Ordnung; der Patchverwalter wird dafür sorgen, dass er nicht in Vergessenheit gerät. Da dieses System nur funktioniert, wenn man sich darauf verlassen kann, dass der Patchverwalter ausnahmslos da ist, sollte die Rolle formal vergeben werden. In Subversion schrieben wir diese Stelle auf der Entwickler-Mailingliste und der für Benutzer aus, bekamen mehrere Freiwillige, und nahmen den ersten der geantwortet hatte. Als die Person abtreten musste (siehe später in diesem Kapitel), machten wird das gleiche nochmal. Wir haben nie versucht, mehrere Personen die Rolle teilen zu lassen, da ein Übermaß an Kommunikation zwischen ihnen nötig gewesen wäre; aber bei einer sehr hohen Anzahl von Patches könnte ein mehrköpfiger Patchverwalter vielleicht sinnvoll sein. Übersetzungsverwalter Bei Software-Projekten, kann sich "Übersetzung" auf zwei sehr unterschiedliche Dinge 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. Im Subversion-Projekt, haben wir einen Verwalter, der sich um beides kümmert. Er schreibt natürlich nicht selber die Übersetzungen – er wird vielleicht bei einer oder zweien aushelfen, aber zum Zeitpunkt dieser Niederschrift, hätte er zehn Sprachen sprechen müssen (zwölf wenn man Dialekte mitzählt) um bei allen mitzuarbeiten! Stattdessen verwaltet er die Teams der freiwilligen Übersetzer: Er hilft ihnen dabei, sich zu koordinieren, und koordiniert zwischen ihnen und dem Rest des Projekts. Dass 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 eines verteilten Teams 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ält dann danach ausschau, dass sie sich an diese Konventionen halten. Unterhaltungen zwischen dem Übersetzungsverwalter und den Entwicklern, oder zwischen dem Übersetzungsverwalter und die Übersetzerteam, 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 eines bestimmten Übersetzungsteams sind jedoch meistens in der gemeinsamen Sprache, und eine der anderen Aufgaben des Übersetzungsverwalter ist es, eine gesonderte Mailingliste für jedes Team 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. Internationalisierung kontra Lokalisierung Internationalisierung (I18N) und lokalisierung (L10N) beziehen sich beide auf den Arbeitsablauf, eine Anwendung anzupassen, damit sie in anderen linguistischen und kulturellen Umgebungen funktioniert, als der es ursprünglich geschrieben wurde. Die Begriffe werden oft als unter einander austauschbar behandelt, sind aber in wirklichkeit nicht ganz das selbe. Wie schreibt:
Die Unterscheidung zwischen beiden, ist subtil aber wichtig: Internationnalisierung ist die Anpassung von Produkten damit sie potentiell überall genutzt werden können, wärend die lokalisierung das Hinzufügen spezifischer Funktionen für die Nutzung in einem bestimmten Gebiet bezeichnent.
Ihre Software zum umzustellen, damit es verlustfrei Unicode () Textkodierung handhaben kann, fällt zum Beispiel under die Internationnalisierung, da es nicht um eine bestimmte Sprache geht, sondern darum Text von einer Vielzahl an Sprachen annehmen zu können. Ihre Software dazu zu bringen, alle Fehlermeldungen auf Slovenische auszugeben, wenn es erkennt, dass es unter einer slovenischen Umgebung läuft, fällte andererseits under die Lokalisierung. Die Aufgabe des Übersetzungsverwalters ist desshalb prinzipiell die der Lokalisierung, nicht der Internationalisierung. Dokumentationsverwalter 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ältnis 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 Autors 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 Teams 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 Patchverwalter (siehe 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 Dokumentationsteams sie jeweils haben möchten. (Wenn die gesamte Menge der Patches das übersteigt, was von einem Menschen bewältigt werden kann, ist es wahrscheinlich ein erster Schritt, wenn man auf separate Patchverwalter für Code und Dokumentation wechselt.) Der Sinn eines Dokumentationsteams 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. Ticketverwalter Die Anzahl der Tickets im Bugtracker des Projekts nimmt mit der Anzahl der Personen zu, welche die Software benutzen. Deshalb sollten Sie immer noch erwarten, dass die Anzahl offener Tickets, im wesentlichen ohne Grenzen anwächst, selbst während 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. Ticketverwalter helfen dabei, diese Probleme zu mildern, indem sie in die Datenbank gehen, und periodisch alles durchkämmen, 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 das Ticket ein Duplikat eines bereits in der Dadenbank vorhandenen ist. Offensichtlich wird der Ticketverwalter um so effektiver in der Lage sein, Duplikate zu erkennen, je besser er mit der Bug-Datenbank des Projekts vertraut ist – das ist einer 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, das auf eine dezentralisierte Art zu machen, eignent sich nicht ein einzelner ein tieferes Wissen über den Inhalt der Datenbank an. Ticketverwalter 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 das Entwicklerteam ein Auge auf alle eintreffenden Tickets hält, 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 Ticketverwalter selber Entwickler sind. Abhängig davon wie Ihr Projekt den Bugtracker benutzt, können Ticketverwalter 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" selbst wenn wir kein genaues Datum nennen können. Die neuen Versionen kann man als Meilensteine in dem Bugtracker eintragen, ein Feld welches in IssueZillaIssueZilla ist der Bugtracker, dern wir benutzen; es ist ein Abkömling von BugZilla 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ält 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 Ticketverwalter 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 ändert 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-Methode: Kategorisieren Sie die Tickets, sofort nachdem sie eingetragen wurden und lenken Sie die Aufmerksamkeit der zuständigen Entwickler oder des Teams darauf. Der Empfänger kümmert sich ab dann um das 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 Ticketverwalter eher zu einem globalen Koordinator, der immer weniger Zeit damit verbringt, sich jedes einzelne Ticket anzuschauen, und mehr damit, es in die Hände der richtigen Person zu legen. FAQ-Verwalter 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 Autoren geplant wird, ist eine FAQ von einer gänzlich reaktiven Natur (siehe ). 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ält. 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 Mailinglisten 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 im Kapitel ); 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 im Kapitel ). Ich habe das insbesondere bei Faq-O-Matic () 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ält. 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 , für Beschreibungen und Bewertungen von Open-Source-Hilfsmitteln für die Pflege von FAQs. Übergänge Ab und zu kommt es vor, dass ein Freiwilliger in einer dauerhaften verantwortungsvollen Position (z.B. ein Patchverwalter, Übersetzungsverwalter, usw.) nicht mehr in der Lage sein wird, die Aufgaben seiner Position auszuführen. Es kann daran liegen, dass die Aufgabe sich als mehr Arbeit heraus gestellt hat, als er es vermutet hatte, oder aufgrund von gänzlich äußeren Ursachen: Heirat, ein neues Kint, ein neuer Arbeitgeber, oder sonst etwas. Wenn ein Freiwilliger so überschwemmt wird, bemerkt er es meistens nicht sofort. Es passiert allmählich und es gibt keinen Zeitpunkt, an dem ihm bewussst auffällt, dass er nicht mehr die Pflichten seiner Rolle erfüllen kann. Statt dessen, hört das Projekt eine weile lang nichts von ihm. Dann gibt es eine plötzliche Hektik, wenn er sich dafür schuldig fühlt, dass Projekt so lange Vernachlässigt zu haben, und er arbeitet die Nacht durch, um alles nachzuholen. Dann werden Sie wieder eine Zeit lang nichts von ihm hören, und es kann wieder eine hektische Aktivität geben oder auch nicht. Es gibt aber selten einen unaufgeforderten formalen Abtritt. Der freiwillige macht die Arbeit in seiner Freizeit, also wäre ein Abtritt gleichzeitig ein Eingeständnis an sich selber, dass seine Freizeit permanent veringert ist. Menschen geben so etwas oft nur wiederwillig zu. Es liegt desshalb an Ihnen und die anderen im Projekt zu erkennen was passiert – oder eher, was nicht passiert – und den Freiwilligen zu fragen was los ist. Die Frage sollte freundlich und komplett frei von Schuldzuweisungen sein. Sie wollen eine Information herausfinden, nicht die Person demütigen. Die Anfrage sollte im allgemeinen für das übrige Projekt sichtbar sein, wenn Sie aber einen besonderen Grund haben, warum es privat gehalten werden sollte, dann ist das auch in Ordnung. Der Hauptgrund es öffentlich zu machen, ist damit, wenn der Empfänger antwortet indem er sagt, dass er nicht mehr in der Lage sein wird die Aufgabe zu übernehmen, es eine Kontext gibt, indem Sie Ihre nächste öffentliche Nachricht schreiben können: Eine Anfrage nach einem neuen Freiwilligen, der die Rolle übernimmt. Manchmal ist ein Freiwilliger nicht in der Lage, die Rolle die er übernommen hat, zu erfüllen, weiß es aber entweder nicht oder will es nicht zugeben. Natürlich kann jeder am Anfang Probleme haben, ganz besonders, wenn die Pflichten komplex sind. Wenn jemand jedoch einfach nicht für die Aufgabe geeignet ist, die er übernommen hat, nachdem jeder ihm alle möglichen Hilfen und Vorschläge gegeben haben, dann ist die einzige Lösung für ihn beiseite zu treten, und jemand anderen es versuchen zu lassen. Und wenn die Person das selber nicht sieht, muss man es ihm sagen. Es gibt denke ich, im Prinzip nur eine Möglichkeit, dass zu handhaben, es ist aber ein Vorgang mit mehreren Schritten, von denen alle wichtig sind. Erstens, vergewissern Sie sich, dass Sie nicht irre sind. Sprechen Sie privat mit anderen im Projekt, und schauen Sie ob sie auch das Problem für so ernst halten, wie Sie es tun. Selbst wenn Sie sich schon sicher sind, dienen diese Anfragen, andere wissen zu lassen, dass sie es in betracht ziehen, die Person darum zu bitten, beiseite zu treten. Normalerweise wird keiner dagegen einsprechen – sie werden nur froh sein, dass Sie die heikele Aufgabe übernehmen, weil sie es dann selber nicht müssen! Kontaktieren Sie als nächstes den in Frage stehenden Freiwilligen, im privaten und sagen Sie ihm, freundlich aber direkt, über die Probleme, die Sie sehen. Seien Sie spezifisch, mit sovielen Beispielen wie möglich. Achten Sie darauf, ihm klar zu machen, dass andere versucht haben zu helfen, dass die Probleme aber blieben ohne sich zu verbessern. Sie sollten erwarten, dass es eine weile brauchen wird, diese E-Mail zu schreiben, wenn Sie aber bei dieser Art von E-Mail Ihre Behauptungen nicht untermauern, brauchen Sie sie garnicht erst zu schreiben. Sagen Sie, dass Sie einen neuen Freiwilligen für die Rolle suchen wollen, weisen Sie aber auch darauf hin, dass es viele andere Möglichkeiten gibt, zu dem Projekt etwas beizutragen. Zu diesem Zeitpunkt, sollten Sie nicht sagen, dass Sie mit anderen darüber gesprochen haben; keiner mag es, wenn hinter seinem Rücken Komplotte geschmiedet werden. Es gibt ein paar Wege, wie die Sache danach verlaufen kann. Die wahrscheinlichste Reaktion ist, dass er Ihnen zustimmen wird, oder zumindest nicht widersprechen will, und bereit sein wird abzutreten. In dem Fall, sollten Sie vorschlagen, dass er selber die Ankündigung macht, und Sie können dann mit einer Nachricht anschließen, indem Sie nach einem Ersatz suchen. Oder er wird zustimmen, dass es Probleme gegeben hat, aber um ein wenig mehr Zeit bitten (oder noch eine Chance, bei diskreten Aufgaben wie beim Versionsverwalter). Wie Sie darauf reagieren, liegt bei Ihnen, aber was immer Sie auch machen, Sie sollten nicht nur desshalb zustimmen, weil Sie solch eine Vernünftige Bitte nicht abschlagen können. Das würde den Leid nur ausdehnen, nicht verringern. Es gibt oft einen ziemlich guten Grund, die Bitte abzulehnen, nämlich, dass es bereits genügend Gelegenheiten gegeben hat, und das Projekt desshalb bei dem derzeitigen Stand ist. Ich habe es wie folgt in einer E-Mail formuliert, an eine Person welche die Rolle des Versionsverwalters übernommen hatte, aber nicht wirklich dafür geeignet war:
> Wenn du mich mit jemand anderem ersetzen willst, bin ich gerne > bereit die Rolle an ihm weiter zu geben. Ich habe eine Bitte, die > hoffentlich nicht unvernünftig ist. Ich würde gerne noch eine neue > Version versuchen, um mich beisen zu können. Ich verstehe deinen Wunsch vollkommen (habe ich selber durchgemacht!), ich denke aber, dass wir in diesem Fall nicht "noch einen Versuch" machen sollten. Das ist nicht die erste oder zweite neue Version, es ist die sechste oder siebte... Und bei all denen, ich weiß, dass Sie mit dem Ergebnis unzufrieden sind (weil wir schon mal darüber geredet haben). Wir haben also tatsächlich die Noch-einen-Versuch-Sache durchgezogen. Letztlich muss einer dieser Versuche der letzte sein... Ich denke diese [vergangene] Version ist es.
Im schlimmsten Fall, wird der Freiwillige dem komplett widersprechen. Dann müssen Sie sich damit abfinden, dass die Sache unangenehm wird, und sich trotzdem durchkämpfen. Jetzt, ist die Zeit, zu sagen, dass Sie mit anderen darüber geredet haben (sagen Sie aber immer noch nicht mit wem, bis Sie deren Erlaubnis haben, schließlich waren diese Unterhaltungen privat), und dass Sie nicht denken, dass es gut für das Projekt ist, weiterzumachen, wie bissher. Seien Sie nachdrücklich, aber niemals drohent. Denken Sie daran, dass bei den meisten Rollen der Übergang in dem Moment statfindet, wenn jemand neues die Arbeit anfängt, nicht wenn die alte Person damit aufhört. Wenn es bei der Auseinandersetzung zum Beispiel um die Rolle, von sagen wir dem Ticketverwalter geht, können Sie oder andere einflussreiche Entwickler in dem Projekt, jederzeit eine Anfrage nach einem neuen Ticketverwalter machen. Es ist nicht wirklich notwendig, dass die Person die es vorher gemacht hat damit aufhört, so lange er nicht die Arbeit des neuen Freiwilligen sabotiert (absichtlich oder sonstwie). Was einen verlockenden Gedanken aufbringt: Statt die Person um seine Abdankung zu bitten, warum sollten Sie es nicht einfach so auslegen als wollten Sie ihm etwas Hilfe beschaffen? Warum sollten Sie nicht zwei Ticketverwalter haben, oder Patchverwalter oder was auch immer die Rolle ist? Obwohl das sich theoretisch nett anhören mag, ist es im allgemeinen keine gute Idee. Die Rolle eines Verwalters beruht gerade – das genau ist ihr Nutzen – auf der Zentralisierung. Dinge, die auf eine dezentralisierte Weise geregelt werden können, werden im Allgemeinen schon so gehandhabt. Zwei Personen zu haben, die eine Verwaltungsrolle einnehmen, würde nur einen größeren Kommunikationsaufwand bedeuten, sowie das Potential die Verantwortlichkeiten unklar zu machen ("Ich dachte du hast den Verbandskasten mitgenommen!" "Ich? Nee, ich dachte du hast den Verbandskasten mitgenommen!"). Es gibt natürlich Ausnahmen. Manchmal arbeiten zwei Personen sehr gut zusammen, oder die Natur der Rolle ist derart, dass sie leicht auf mehrere Personen aufgeteilt werden kann. Diese sind aber wahrscheinlich von keinem großen Nutzen wenn Sie jemanden in einer Rolle versagen sehen, für die er nicht geeignet ist. Wenn er das Problem von vorn herein zu würdigen gewusst hätte, hätte er diese Hilfe vorher schon gesucht. In jedem Fall, wäre es respektlos jemand zeit verschwenden zu lassen, bei der Fortführung Aufgabe die keiner achten wird. Das wichtigste wenn Sie jemand darum bitten abzutreten, ist die Privatsphäre: Ihm den Raum zu geben, um eine Entscheidung zu treffen, ohne sich dabei so zu fühlen, als würden andere ihn beobachten und auf ihn warten. Ich habe einmal den Fehler gemacht – im Nachhinein ein offensichtlicher Fehler – alle drei Parteien auf einmal anzuschreiben, um den Versionsverwalter von Subversion darum zu bitten, für zwei andere Freiwillige abzutreten. Ich hatte mit den beiden neuen bereits im Privaten geredet und wusste, dass sie gewillt waren die Verantwortung zu übernehmen. Naiver Weise und etwas taktlos dachte ich also, dass ich etwas Zeit und Mühe sparen würde, wenn ich an alle eine E-Mail schreiben würde, um den Übergang anzustoßen. Ich nahm an, dass der derzeitige Versionsverwalter bereits vollkommen über die Probleme im klaren war und sofort sehen würde, dass meine Anfrage vernüngtig war. Ich irrte mich. Der derzeitige Versionsverwalter war sehr beleidigt, und das mit Recht. Es ist eine Sache, darum gebeten zu werden abzutreten; Es ist eine andere direkt vor den Personen, an die man abgeben soll, darum gebeten zu werden. Als ich verstanden hatte, warum er beleidigt war, entschuldigte ich mich. Er trat schließlich ohne Umstände zurück und ist heute weiterhin an dem Projekt beteiligt. Seine Gefühle wurden aber verletzt und es ist natürlich auch nicht der angenehmste Anfang für die Neuen. Committer Als die einzig wesentlich ausgeprägte Gruppe von Personen die in allen Open-Source-Projekten gefunden werden kann, verdienen Committer hier besondere Aufmerksamkeit. Committer sind ein unvermeidliches Zugeständnis an die Diskriminierung, bei einem System, welches ansonsten so diskriminierungsfrei wie möglich ist. "Diskriminierung" ist hier aber nicht herabsetzend gemeint. Die Funktion die Committer ausüben ist ganz und gar unerlässlich, und ich denke nicht, dass ein Projekt ohne es erfolgreich wäre. Qualitätskontrolle erfordert, nun ja, Kontrolle. Es gibt immer viele Leute die meinen sie wären qualifiziert Änderungen an einer Anwendung zu machen, und irgend eine kleinere Anzahl, die es auch wirklich sind. Das Projekt, kann sich nicht auf das eigene Urteilsvermögen der Leute verlassen; es muss Normen auferlegen, und nur denen Commit-Berechtigung geben, die diese erfüllen Beachten Sie dass Commit-Zugriff bei einem dezentralisierten Versionsverwaltungssystem etwas leicht Abweichendes bedeutet, da jeder sein eigenes Projektarchiv aufsetzen kann, welches mit dem des Projekts verbunden ist, und sich selber zu diesem Projektarchiv Zugriff geben. Nichtsdestoweniger gilt das Konzept vom Commit-Zugriff, trotzdem noch: "Commit-Zugriff" ist steht für "das Recht, Änderungen am Code vorzunehmen, der in der nächsten Version der Software ausgeliefert wird". In zentralisierten Systemen bedeutet es, direkten Commit-Zugriff zu haben; bei dezentralisierten Systemen bedeutet es, dass die Änderungen standardmäßig ins Projektarchiv des Projekts geladen werden. So oder so, ist es das gleiche; die Mechanik, mit dem es realisiert wird, ist nicht sonderlich wichtig. . Andererseits, entsteht ein Machtverhältnis zwischen Leuten die direkt Änderungen committen können, die direkt beben Leuten die es nicht können. Dieses Verhältnis muss so verwaltet werden, dass es dem Projekt nicht schadet. In im Kapitel , haben wir beteits die Mechanismen besprochen, wie neue Committer in Betracht kommen. Hier werden wir uns die Normen anschauen, nach denen neue Committer beurteilt werden sollten, und wie dieser Vorgang der weiteren Gemeinschaft präsentiert werden sollte. Auswahl von Committern 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. Widerruf von Commit-Zugriff 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 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. Eingeschränkter Commit-Zugriff 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 im Kapitel ), 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 im Kapitel für weiteres über die Gründe dafür. Untätige Committer 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 weiter unten für weiteres über diese Liste). In solchen Fällen, sollten das Projekt natürlich den Wünschen der Person nachkommen. Vermeiden Sie Geheimnisse 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 im Kapitel ) 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. Anerkennung Anerkennung ist die hauptsächliche Währung in der Welt der freien Software. Was immer Leute über ihre Motive für die Beteiligung an einem Projekt sagen, ich kenne keine Entwickler die glücklich damit wären, ihre ganze Arbeit anonym zu verrichten, oder unter dem Namen von jemand anderem. Es gibt hierfür konkrete Gründe: Der Ruf innerhalb eines Projekts diktiert ungefähr wieviele Einfluss man hat, und die Beteiligung an einem Open-Source-Projekt kann auch einen indirekten finanziellen Wert haben, weil manche Arbeitgeber bei einer Bewerbung mittlerweile danach Ausschau halten. Es gibt auch vielleicht sogar noch stärkere immaterielle Gründe: Menschen wollen einfach geschätzt werden, und suchen instinktiv nach Zeichen, dass ihre Arbeit von anderen anerkannt wird. Das Versprechen von Anerkennung ist desshalb eines der besten Motivationen, die ein Projekt hat. Wenn kleine Beiträge anerkennung finden, kommen Leute zurück um mehr zu machen. Einer der wichtigsten Funktionen von Software für die gemeinschaftliche Entwicklung (siehe ) ist dass es genaue Protokolle darüber führt, wer was wann gemacht hat. Überall wo es möglich ist, sollten Sie bereits vorhandene Mechanismen benutzen um sicher zu stellen, dass diese Anerkennung genau verteilt wird, und seien Sie spezifisch, über die Natur des Beiträgs. Schreiben Sie nicht einfach "Danke an H. Mustermann <hmustermann@beispiel.de>" wenn Sie statt dessen "Danke an H. Mustermann<hmustermann@beispiel.de> für die Bug-Meldung und die Anleitung zur Reproduktion" in einem Kommentar schreiben könnten. Bei Subversion haben wir eine informelle aber stetige Richtlinie, denjenigen der den Bug gemeldet hat entweder in dem zugehörigen Ticket zu würdigen oder wenn nicht, in dem Commit-Kommentar der Änderung die den Bug behebt. Eine kurze Betrachtung der Kommentare im Subversion-Projektarchiv ergibt, dass mit 14525 ungefähr 10% der Änderungen jemanden bei Namen und E-Mail-Adresse würdigt, üblicherweise die Person, welche den Bug gemeltet oder untersucht hat, der durch die Änderung behoben wurde. Achten Sie darauf, dass diese Person eine andere ist als der Entwickler, der den Commit gemacht hat, dessen Name bereits automatisch vom Versionsverwaltungssystem erfasst wird. Von den ca. 80 Voll- und Teil-Commit-Berechtigten, die Subversion heute hat, wurden 55 in den Commit-Kommentaren (meistens mehrere Male) gewürdigt, bevor sie selber Committer wurden. Das beweist natürlich nicht, dass die Anerkennung ein Grund für die weitere Beteiligung war, baut aber zumindest eine Atmosphäre auf, in der Leute darauf zählen können, dass ihre Beiträge gewürdigt werden. Es ist wichtig zu unterscheiden, zwischen gewöhnliche Anerkennung und besondere Danksagungen. Wenn ein bestimmter Codeteil, oder irgend ein anderer Beitrag den jemand geleistet hat, diskutiert wird, ist es in Ordnung, ihre Arbeit zu würdigen. Wenn Sie zum Beispiel sagen "Die kürzlichen Änderungen von Daniel an dem Delta-Code bedeuten, dass wir jetzt Funktion X implementieren können" hilft den Leuten zu erkennen, um welche Änderungen es sich handelt, und es würdigt gleichzeitig die Arbeit von Daniel. Es dient andererseits keinen direkten praktischen Zweck, Daniel nur für seine Änderungen an dem Delta-Code zu danken. Es fügt keine Informationen hinzu, da das Versionsverwaltungssystem und andere Mechanismen die Tatsache aufgezeichnet hat, wer die Änderungen gemacht hat. Jeden für alles zu danken, wäre ablenkend und würde letztendlich frei von Informationen, da Danksagungen in so weit effektiv sind, wie sehr sie aus den üblichen positiven Kommentaren herausragen, welche die ganze Zeit ablaufen. Das bedeutet natürlich nicht, dass Sie niemals Leuten danken sollten. Sorgen Sie einfach dafür, dass Sie es auf Arten tun, die nicht zu einer Inflation der Anerkennung führen. Diese Richtlinien zu folgen, wird helfen: Je flüchtiger das Forum, desto freier sollten Sie Ihren Dank ausdrücken. Jemandem zum Beispiel im Vorbeigehen, während einer Unterhaltung im IRC, für seinen Bugfix zu danken, ist in Ordnung, genau so wie eine beiläufige Erwähnung in einer E-Mail die hauptsächlich anderen Themen gewidmet ist. Schreiben Sie aber keine E-Mail alleine um jemanden zu danken, es sei denn es ist für eine wirklich ausergewöhnliche Leistung. Sie sollten gleichermaßen nicht die Webseiten des Projekts mit Ausdrücken von Dankbarkeit verunstalten. Wenn Sie erst einmal damit anfangen, wird nie klar sein, wann oder wo man aufhören soll. Und schreiben Sie niemals Danksagungen in die Kommentare des Codes; das wäre nichts als eine Ablenkung vom Hauptzweck der Kommntare, der darin besteht dem Leser beim Verständnis des Codes zu helfen. Je weniger jemand mit dem Projekt zu tun hat, desto angemessener ist es sich für etwas zu danken, was er geleistet hat. Das mag sich nicht eingängig anhören, passt aber mit der Einstellung zusammen, dass Sie Lob ausdrücken sollten, wenn jemand mehr beiträgt als Sie erwartet hätten. Es würde deshalb eine geringere Erwartung an Personen ausdrücken, als sie selber an sich haben, wenn Sie sich ständig für regelmäßige Beiträge bedanken, die sie normerweise machen. Wenn überhaupt, wollen Sie das engegengesetzte Ergebnis erzielen! Es gibt ab und zu Ausnahmen zu dieser Regel. Man kann jemanden dafür danken seine Rolle zu erfüllen, wenn diese Rolle von Zeit zu Zeit temporäre, intensive Anstrengungnen erfordert. Das Paradebeispiel hierfür ist der Versionsverwalter, der in Zeiten der Veröffentlichung einer neuen Version in einen Gang hochschaltet, ansonsen aber untätig ist (zumindest in seiner Rolle als Versionsverwalter – er kann auch als Entwickler aktiv sein, aber das ist eine andere Angelegenheit). Genau so wie Kritik und Anerkennung, sollte Dankbarkeit so spezifisch wie möglich sein. Danken Sie Leuten nicht einfach dafür, dass sie toll sind, selbst wenn das der Fall ist. Danken Sie sie für etwas, dass außergewöhnlich war und es gibt zusätzliche Punkte, wenn Sie auch noch genau sagen, warum das was sie gemacht haben, so toll war. Im allgemeinen, gibt es immer eine Spannung dazwischen zu gewärleiten, dass die einzelnen Beiträge anerkannt werden, und sicher zu stellen, dass das Projekt eher eine gemeinsame Anstrenung ist als eine Ansammlung einzelner Prachten ist. Bleiben Sie einfach im Klaren über diese Spannung und versuchen Sie sich auf die Seite der Gruppe zu halten, und Sachen werden nicht ausarten. Abspaltungen In im Kapitel , haben wir gesehen, wie das Potential für eine Abspaltung (en. Fork) wichtige Auswirkungen darauf hat, wie ein Projekt geführt wird. Was passiert aber, wenn eine Abspaltung wirklich stattfindet? Wie sollten Sie damit umgehen, und welche Auswirkungen können Sie davon erwarten? Wann sollten Sie umgekehrt, eine Abspaltung anstoßen? Die Antworten hängen davon ab, um welche Art von Abspaltung es sich handelt. Manche Abspaltungen sind aufgrund von freundlichen aber unüberbrückbare Meinungsverschiedenheiten, über die Richtung des Projekts; mehr sind vielleicht sowohl auf technische Argumente als auch auf zwischenmenschliche Konflikte zurückzuführen. Natürlich ist es nicht immer möglich, den Unterschied zwischen den beiden zu erkennen, da technische Argumente auch persönliche Anteile beinhalten können. Alle Abspaltungen haben gemeinsam, dass eine Gruppe von Entwicklern (oder manchmal auch nur ein Entwickler) sich entschieden haben, dass die Kosten mit manchen oder alle anderen Entwicklern zu arbeiten, jetzt schwerer wiegen als der Nutzen. Wenn ein Projekt sich spaltet, gibt es keine definitive Antwort darüber, welche Abspaltung das "echte" oder "ursprüngliche" Projekt war. Lete werden umgangssprachlich davon sprechen, dass die Abspaltung A aus dem Projekt P kommt, als ob P weiter seinen natürlichen Lauf nimmt wärend A in neue Gebiete divergiert, was aber im wesentlichen eine Aussage darüber ist, wie dieser bestimmte Beobachter das Thema sieht. Es ist im Grunde genommen eine Frage der Sichtweise: Wenn eine ausreichend große Gruppe damit übereinstimmt, dann fängt die Behauptung an wahr zu werden. Es ist nicht so, dass es eine objektive Wahrheit von vornherein gibt, eine welche wir zunächst zweifelsfrei beobachten können. Sondern vielmehr, die Auffassungen sind die objektive Wahrheit, da ein Projekt – oder eine Abspaltung – letztendlich eine Entität ist, die sowieso nur in den Köpfen der Menschen existiert. Wenn diejenigen, welche die Abspaltung anstoßen das Gefühl haben, dass sie aus dem Hauptprojekt einen neuen Ast entsprießen, ist die Frage der Wahrnehmung sofort und einfach beantwortet. Jeder, sowohl die Entwickler als auch die Nutzer werden die Abspaltung wie ein neues Projekt behandeln, mit einem neuen Namen (vielleicht auf dem alten Namen basierend, aber leicht davon zu unterscheiden), einer eigenen Webseite, und einer anderen Philosopie oder Ziel. Die Sache wird jedoch verwirrender, wenn beide Seiten der Meinung sind, die legitimen Wächter des ursprünglichen Projekts zu sein und desshalb ein Recht haben, ein Recht darauf haben, den ursprünglichen Namen zu benutzen. Wenn es eine Organization gibt, mit Markenrechte auf den Namen, oder rechtliche Kontrolle über die Domaine oder Webseiteb, ist die Angelegenheit über das Recht erledigt: Diese Organisation wird entscheiden wer das Projekt ist und wer die Abspaltung, denn es hält alle Karten in einem Krieg um die öffentliche Wahrnehmung. Natürlich kommen die Sachen meistens nicht so weit: Da jeder bereits weiß, wie die Machtverhältnisse sind, werden sie es vermeiden eine Schlacht zu kämpfen, dessen Ausgang sie bereits kennen, und einfach gleich zum Ende springen. Zum Glück, gibt es selten Zweifel darüber, welches das Projekt ist, und welches die Abspaltung, denn eine Abspaltung ist im wesentlichen eine Vertrauensfrage. Wenn mehr als die hälfte der Entwickler für welche Richtung die Abspaltung auch immer vorschlägt sind, gibt es normalerweise keinen Grund eine Abspaltung zu machen – das Projekt kann einfach selber diese Richtung einschlagen, es sei denn es wird als Diktatur geführt mit einem besonders sturen Diktator. Wenn andererseits, weniger als die Hälfte dafür sind, ist die Abspaltung eindeutig eine Rebellion einer Minderheit, und is ist sowohl entgegenkommend, als auch vernünftig, dass es sich selber als einen Zweig sieht, und nicht als den Stamm. Umgang mit Abspaltungen Wenn jemand droht von ihrem Projekt eine Abspaltung zu machen, bleiben Sie ruhig und denken Sie an Ihre längerfristigen Ziele. Die bloße Existenz einer Abspaltung ist es nicht, was einem Projekt schadet; vielmehr ist es der Verlust von Entwickler und Nutzer. Ihr echtes Ziel ist es desshalb nicht, die Abspaltung zu unterdrücken, sondern diese schädlichen Auswirkungen zu minimieren. Sie können darüber sauer sein, oder der Meinung sein, dass die Abspaltung nicht gerecht und unprovoziert war, das aber öffentlich äußern kann einzig und alleine unentschlossene Entwickler entfremden. Statt dessen, sollten Sie Leute nicht dazu zwingen, exklusive Entscheidungen zu treffen, und so kooperativ sein, wie es bei einer Abspaltung machbar ist. Als erstes, sollten Sie nicht die commit Berechtigung zu ihrem Projekt von jemandem zurücknehmen, der sich entschieden hat an der Abspaltung zu arbeiten. Arbeit an der Abspaltung bedeutet nicht, dass die Person plötzlich seine Kompetenz an dem ursprünglichen Projekt zu arbeiten verloren hat; vorherige Committer sollten auch nacher Committer sein. Darüber hinaus, sollten Sie Ihr Wunsch ausdrücken, so kompatibel wie möglich mit der Abspaltung zu bleiben ausdrücken und sagen, dass Sie hoffen, dass die Entwickler die Änderungen zwischen beiden übernehmen wenn es angemessen ist. Wenn Sie administrativen Zugriff auf die Server des Projekts haben, sollten Sie der Abspaltung am Anfang öffentlich Hilfe bei der Infrastruktur anbieten. Bieten Sie ihnen zum Beispiel eine Kopie des Projektarchiv an, mit der kompletten Historie, wenn es keine andere Möglichkeit für sie gibt, daran zu kommen, ohne auf die die historischen Daten verzichten zu müssen (das muss je nach Versionsverwaltungssystem nicht unbedingt notwendig sein). Fragen Sie danach, ob es irgend etwas anderes gibt, was sie brauchen und geben Sie es ihene wenn möglich. Reißen Sie sich ein Bein aus, um zu zeigen, dass Sie ihnen nicht im Weg stehen, und dass Sie wollen, dass die Abspaltung nach seinen eigenen Verdiensten Erfolg hat oder fehlschlägt und sonst nichts. Der Grund all das zu tun – und es öffentlich zu machen – ist nicht wirklich um der Abspaltung zu helfen, sondern um die Enwickler zu überreden, dass Ihre Seite eine sichere Sache ist, indem Sie möglichst nicht als rachsüchtig erscheinen. In einem Krieg machte es manchmal Sinn (aus strategischer Sicht, wenn auch nicht aus menschlicher Sicht) Leute dazu zu zwingen eine Seite zu wählen, bei freier Software macht es jedoch fast niemals Sinn. Nach einer Abspaltung arbeiten manche Entwickler sogar offen an beiden Projekten, und versuchen ihr möglichstes um beide kompatibel zu halten. Diese Entwickler helfen die Kommunikationspfade nach der Abzweigungung offen zu halten. Sie erlauben es ihrem Projekt von den Interessanten neuen Funktionen in der Abzweigung zu profitieren (ja, die Abzweigung kann Sachen haben, welche Sie haben wollen), und später die Wahrscheinlichkeit einer Zusammenführung vergrößern. Manchmal wird eine Abzweigung derart erfolgreich, dass auch wenn es selbst von seinen Anstiftern zum Beginn als solches angesehen wurde, es zu der Version wird, die jeder bevorzugt, und letztendlich das Original aufgrund der großen Nachfrage ersetzt. Ein berühmtes Beispiel hierfür war die GCC/EGCS-Abzweigung. Die GNU Compiler Collection (GCC, vorher der GNU C Compiler) ist der beliebteste Open-Source-Compiler für nativen Code und auch einer der portabelsten Compiler der Welt. Aufgrund von Meinungsverschiedenheiten zwischen den Personen die es offiziell pflegten, und Cygnus Software,Jetzt ein Teil von RedHat (). einer der aktivsten Entwickler von GCC, machte Cygnus eine Abzweigung von GCC namens EGCS. Die Abzweigung war absichtlich nicht feindlich gesinnt: Die EGCS-Entwickler versuchten nicht, zu irgend einem Zeitpunkt, ihre Version von GCC als die neue ofizielle Version darzustellen. Statt dessen, konzentrierten sie sich darauf, EGCS so gut wie möglich zu machen, und Patches schneller einzubinden, als die offiziellen Entwickler von GCC. EGCS wurde beliebter, und irgendwann entschieden sich einige größere Vertreiber von Betriebssystemen EGCS anstatt von GCC als ihren standard Compiler auszuliefern. Zu diesem Zeitpunkt, wurde es für alle bei GCC klar, dass an dem Namen "GCC" festzuhalte, wärend jeder zu der EGCS-Abzweigung wechselte, jedem eine unnötigen Namensänderung auferlegen würde, aber nichts machen würde, um den Wechsel zu verhindern. GCC übernahm also den Code von EGCS und es gab wieder eine einzige GCC, nun aber durch die Abzweigung wesentlich verbessert. Dieses Beispiel zeigt, warum Sie eine Abzweigung nicht immer als etwas ganz und gar schlechtes betrachten können. Eine Abzweigung mag zu der Zeit etwas schmerzhaft und unwillkommen sein, Sie können aber nicht unbedingt absehen ob es Erfolg haben wird. Sie und das übrige Projekt sollten desshalb ein Auge darauf halten, und bereit sein nicht nur alle Funktionen und Code aufzunehmen, wo es möglich ist, sonder im extreemsten Fall sogar der Abzweigung beizutreten wenn es den größten Teil der Aufmerksamkeit des Projekts einnimmt. Sie werden natürlich oft in der Lage sein den wahrscheinlichen Erfolg einer Abzweigung abzusehen, jenachdem wer ihm beitritt. Wenn die Abzweigung von dem größten Kläger im Projekt angefangen wird und von einer Handvoll verärgerten Entwickler die sich sowieso nicht konstruktiv verhalten haben, haben Sie im wesentlichen für Sie das Problem, durch die Abzweigung, erledigt, und Sie müssen sich wahrscheinlich keine Sorgen machen, dass es vom ursprünglichen Projekt irgend welche Schwung wegnimmt. Wenn Sie jedoch sehen, wie einflussreiche und geachtete Entwickler die Abzweigung unterstützen, sollten Sie sich fragen warum. Vielleicht ist das Projekt übermäßig restriktiv gewesen, und die beste Lösung ist es, einige oder alle Maßnahmen, die von der Abzweigung erwägt werden, in das Hauptprojekt einzubinden – im Wesentlichen vermeiden Sie die Abspaltung indem Sie zu ihr werden. Eine Abspaltung anstoßen Alle Ratschläge hier gehen davon aus, dass Sie als letztes Mittel eine Abspaltung versuchen. Nutzen Sie alle anderen Möglichkeiten, bevor Sie diesen Schritt erwägen. Es bedeutet fast immer, Entwickler zu verlieren, lediglich mit einem ungewissen Versprechen, später neue zu bekommen. Es bedeutet auch, einem Wettbewerb um die Aufmerksamkeit der Benutzer zu beginnen: Jeder, der dabei ist die Software herunterzuladen, wird sich fragen müssen: "Hmm, will ich diesen oder den anderen?" In welcher Position Sie sich auch immer befinden, die Situation ist chaotisch, da eine Frage entsteht, die vorher nicht da war. Manche Leute behaupten nach dem üblichen Argument der natürlichen Auslese, dass Abspaltungen für das Ökosystem der Software in der Gesamtheit gesund ist: Die Tüchtigsten überleben, was letztlich bedeutet, dass jeder bessere Software bekommt. Das mag aus Sicht des Ökosystems wahr sein, trifft aber nicht die Sicht des einzelnen Projekts. Die meisten Abspaltungen sind nicht erfolgreich und die meisten Projekte sind mit einer Abspaltung nicht glücklich. Damit einher geht, dass Sie die Drohung einer Abspaltung in einer Debatte nicht als extreme Technik benutzen sollten – "Macht die Sache auf meine Art, oder ich werde das Projekt spalten!" – da jeder sich darüber im Klaren ist, dass eine Abspaltung, die es nicht schafft Entwickler des ursprünglichen Projekts anzulocken, wahrscheinlich nicht lange überleben wird. Alle Beobachter – nicht nur die Entwickler, sondern auch die Benutzer und Packetverwalter der Betriebssysteme – werden ihr eigenes Urteil darüber fällen, welche Seite sie wählen. Sie sollten deshalb gegenüber einer Abspaltung sehr abgeneigt erscheinen, damit Sie, sollte es letztlich doch geschehen, glaubhaft machen können, es sei der einzig mögliche Ausweg gewesen. Vergessen Sie nicht, alle Faktoren bei der evaluierung des möglichen Erfolgs von Ihrer Abspaltung in Erwägung zu ziehen. Wenn zum Beispiel viele der Entwickler in einem Projekt den gleiche Arbeitgeber haben, dann werden sie, selbst wenn Sie verärgert und im privaten für eine Abspaltung sind, es wahrscheinlich nicht laut sagen, wenn Sie wissen, dass ihr Arbeitgeber dagegen ist. Viele Programmierer freier Software denken gerne, dass eine freie Lizenzierung des Codes bedeutet, keine einzelne Firma könne die Entwicklung dominieren. Es ist wahr, dass die Lizenz im letztendlichen Sinne die Freiheit garantiert – wenn andere den dringenden Wunaxh hegen, das Projekt zu spalten, und die Ressourcen dazu haben, können sie das. In der Praxis sind die Entwicklerteams einiger Projekte zum Großteil durch ein Unternehmen finanziert, und es gibt keinen Grund so zu tun, als würde die Unterstützung dieses Unternehmens keinen Unterschied machen. Wenn es die Abspaltung ablehnt, werden seine Entwickler wahrscheinlich nicht daran teilnehmen, selbst wenn sie es insgeheim wünschten. Wenn Sie trotzdem zu dem Schluss kommen, das Sie sich abspalten müssen, sollten Sie zunächst im privaten dafür Unterstützung suchen, und es dann ohne Feindseligkeit bekannt geben. Selbst wenn Sie wütend oder entäuscht von den derzeitigen Verwaltern sind, lassen Sie es nicht durchblicken. Halten Sie einfach leidenschaftslos fest, was Sie zu der Entscheidung geführt hat, und dass Sie gegenüber dem Projekt von dem Sie abspalten, keine Böswilligkeit hegen. Angenommen, Sie betrachten es als eine Abspaltung (im Gegensatz zu einer notgedrungenen Erhaltung des ursprünglichen Projekts), sollten Sie hervorheben, dass Sie den Code und nicht den Namen abspalten, und wählen Sie einen Namen, der nicht mit dem des ursprünglichen Projekts im Konflikt gerät. Sie können einen Namen wählen, welcher den ursprünglichen beinhaltet oder darauf verweist, so lange es nicht ein Tor für Verwirrung zwischen beiden aufmacht. Es ist natürlich in Ordnung markant auf der Webseite der Abspaltung zu erklären, dass es von dem ursprünglichen Projekt abstammt, und dass es hofft es zu ersetzen. Machen Sie nur nicht das Leben der Benutzer schwieriger indem Sie ihnen aufzwingen, ein Gerangel um die Identität auseinanderzufuseln. Schließlich können Sie der Sache einen guten Start geben, indem Sie automatisch allen Entwicklern des ursprünglichen Projekts Commit-Rechte zu der Abspaltung geben, inklusive denen die nicht der Notwendigkeit einer Abspaltung zustimmten. Selbst wenn sie niemals den Zugang benutzen, ist Ihre Nachricht klar: Es gibt hier Meinungsverschiedenheiten, aber keine Feinde, und Sie heißen Beiträge aus jeder kompetenten Quelle willkommen.