Inhaltsverzeichnis
Leute dazu zubringen, sich zu einigen, was das Projekt benötigt, und zusammen zu warbeiten, um es zu erreichen, erfordert mehr als nur eine angenehme Atmosphäte und ein Mangel an offensichtlicher Dysfunktion. Es erfordert jemand oder mehrere jemande, wissentlich alle beteiligten Personen zu leiten. Die Leitung von Freiwilligen mag kein technisches Handwerk sein im selben Sinne wie das Programmieren, es ist aber ein Handwerk im Sinne, dass es durch sein Studium und Übung 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 eher tragbar ist, wenn man kritik behaftete Steine in das eigene Glashaus wirft, als in dem von anderen. Ich habe aber auch, in verschiedenen anderen Projekten die Vorteile der Anwendung—und die Konseqenzen der nicht Anwendung— der Emfehlungen die folgen; wenn es politisch möglich ist Beispiele aus einigen dieser Projekte zu geben, werde ich das tun.
Wo wir schon von Politik reden, können wir genau so gut dieses äuserts unheilvolle Wort für eine genauere Untersuchung herauszuzerren. Viele Ingenieure denken gerne über Politik, als wäre es etwas womit andere sich beschäftigen. "Uch spreche nur für den besten Kurs für das Projekt, aber sie erhebt Einsprüche aus politischen Gründen." Ich denke dieser Ekel vor Politik (oder 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 sie 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önnen andere Mitwirkende im Projekt genervt werden. Das hindert sie natürlich nicht daran, sich auf die gleiche Art zu benehmen, wenn ihre lebenswichtigen Interessen auf dem Spiel stehen.
Wenn "politik" als ein schmutziges erachten, und hoffen Ihr Projekt davon frei zu halten, geben Sie es gleich auf. Politik ist immer dann unvermeidlich, wenn Menschen zusammen eine geteilte Resource verwalten müssen. Es ist völlig vernünftig, dass eines 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 Ihr eigenes Urteilsvermögen und Ihre 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 aussehen. Tatsächlich gibe es nicht so etwas wie reine Politik: 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.
Warum arbeiten Freiwillige an freien Software Projekten? [39]
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 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ürfniss guten Code zu produzieren, hinaus gehen. Die wirklichen Motivationen von Freiwilligen zu verstehen wird Ihnen helfen, Sachen so einzurichten, dass sie angelockt werden und dabei bleiben. Der Wunsch gute Software zu produzieren mag eines dieser Motivationen sein, zusammen mit der Herausforderung und dem Bildungswert an schwierign Problemen zu arbeiten. Menschen haben aber auch ein eingbautes Bedürfniss, mit anderen zusammen zu arbeiten, und Respekt durch Zusammenarbeit zu geben und verdienen. Gruppen die sich mit gemeinschaftlichen Aktivitäten beschäftigen, müssen Verhaltensnormen derart entwickeln, dass Ansehen durch Leistungen die den Zielen der Gruppe dienen, angeeignet und behalten werden können.
Diese Normen werden nicht immer von alleine 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.
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 Authoritä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 Argumen über die Kosten der Möglichkeit nicht gilt, kann es trotzdem in Ihrem Interesse sein jemand anderes 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 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.
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.
Wenn Sie jemand 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.
Der Sinn der öffentlichen Bemerkung, dass es keine Antwort gab ist nicht um die Person zu beschämen, und Ihre Anmerkungen sollten so formuliert sein, dass sie nicht diese Wirkung haben. Der Sinn ist einfach zu zeigen, dass Sie dem nachgehen, wofür Sie Anfragen gemacht haben, und dass Sie die Antworten die Sie bekommen bemerken. Das erhöht die Wahrscheinlichkeit, dass Leute beim nächsten mal Ja sagen, da Sie feststellen werden (wenn auch nur unbewusst) dass Sie eher bemerken, wenn sie irgend welche Arbeit erledigen, wenn man bedenkt, dass Sie das viel weniger sichtbare Ereignis bemerkt habe, dass jemand nicht geantwortet hat.
Eine weitere Sache die Leute glücklich macht, ist wenn man ihre Interessen bemerkt—allgemein, wird jemand um so gemütlicher sein, je mehr aspekte seiner Persönlichkeit Sie bemerken und erinnern, und je eher wird er in Gruppen arbeiten wollen, von denen Sie ein Teil sind.
Es gab zum Beispiel eine scharfe Unterscheidung in dem Subversion Projekt zwischen Personen die eine endgültige 1.0 Version erreichen wollten (was wir letztendlich schafften), und solche die hauptsächlich neue Funktionen hinzufügen sowie an interesanten Probleme arbeiten wollten, denen es aber nicht sonderlich kümmerte, wann 1.0 erscheinen würde. Keiner dieser Positionen ist besser oder schlimmer als die andere; sie sind lediglich zwei unterschiedliche Arten von Entwickler, 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ändniss 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 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 inflation geschwächt werden: Zuviel oder zu oft zu Loben wird seinen Wert vermindern; das gleiche gilt für Kritik, obwohl in der Praxis, Kritik eher eine Reaktion ist und desshalb 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 „Erkennung von Unhöflichkeit“ im Kapitel Kapitel 6, Kommunikation 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 letztendlich 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 angemesen 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 „Übergänge“ 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: Vor 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 in der Gruppe sind. Wenn Sie das machen würden, wäre es schwierig zu wissen wan man aufhören soll: Sollten Sie everyone für die übliche Arbeit loben? Wenn Sie schließlich manche auslassen, werden sie sich fragen warum. Es ist viel besser, Lob und Dankbarkeit sparsamm zum Ausdruck zu bringen, als Reaktuin auf ungewöhnliche oder unerwartete Anstrengungen, mit der Absicht mehr solcher Arbeit zu ermutigen. Wenn es scheint, dass eine Beteiligte in einem Zustand dauerhaft erhöhter Produktivität bewegt zu haben, sollten Sie die Grenze für Lob bei dieser Person entsprechend anpassen. Wiederholtes Lob für normales Verhalten wird mit der Zeit sowieso langsam bedeutungslos. Statt dessen, 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 Kenntniss genommen werden.
Was natürlich nicht heißen soll, dass die Beiträge der Person nicht gewürdigt werden sollten. Denken Sie aber daran, dass wenn das Projekt richtig eingerichtet wurde, wird alles was diese Person macht eh schon sichtbar sein, und die Gruppe wird wissen (und die Person wird wissen, dass die Gruppe weiß), was sie alles macht. Es gibt auch Möglichkeiten die Arbeit von jemand anzuerkennen, außer direkem Lob. Sie könnten immer im vorbeigenen erwähnen, wärend Sie ein verwandtes Thema besprechen, dass sie eine Menge arbeit in dem entsprechenden Bereich geleistet hat und auf dem Gebiet die Expertin ist; Sie könnten sie öffentlich eine 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 explizite Schritte vorzunehmen, um das sicherzustellen, es sei denn Sie spüren, dass ein Beteiligter aus irgend welchen Gründen nicht entsprechend geschätzt wird.
Halten Sie Acht, nach Beteiligten, die versuchen exclusiven Besitz, für bestimmte Bereiche im Projekt abzustecken, und bei denen es scheint, als wollten Sie in den Bereichen, die ganze Arbeit machen, sogar zu dem Grad, dass sie die 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 zeigt. 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 diesem Bereich zur Folge, sowie größere Zerbrechlichkeit, da der einzelne Entwickler zu einem kritischen Ausfallpunkt wird. Schlimmer noch, zerbricht es 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 Hauptsach ist, dass das alles freiwillig ist: Informelle Authoritä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 Authorität informell hällt, durch das Bewusstsein des Projekts, und dass die Authoritä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, die Namen der Authoren oder Zuständigen in Quellcode Dateien zu verbieten. Ich stimme diesem Verfahren voll und ganz zu: Wir benutzen es 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 Author 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 Projekte zu arbeiten, und sich als Gruppe um das Projekt zu kümmern. Anerkennung ist gut und sollte gemacht werden, allerdings auf eine Art welche keine falsche Anerkennung erlaubt, selbt implizite. Es gibt keine klare Grenze, wann man eine Markierung des Authors 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 vituelle Quote erreich, damit ihr Name überall ist?
Es gibt bessere möglichkeiten Anerkennung zuzuweisen, und wir bevorzugen es, diese zu nutzen. Aus technischer Sicht, sind Author 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 veraltet zu werden. Wollen Sie wirklich privat zu einem Stück Code kontaktiert werden, welches Sie vor fünf Jahren geschrieben haben und froh waren vergessen zu haben?
Die Quellcode Dateien von einem Software Projekt sind der Kern siener Identität. Sie sollten die Tatsache wiederspiegeln, dass die Entwickler Gemeinschaft im Ganzen dafür verantwortlich ist, und nicht in einzelne Machtbereiche aufgeteilt werden.
Manchmal sprechen sich Leute für die Markierung des Autors oder eines Zuständigen in den Quellcode Dateien, mit der Begründung, dass es eine sichtbare Anerkennung derjenigen gibt, 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, indem 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 Quellcode Dateien aufgelistet sind. So oder so, kann die Information über Anerkennung schon aus dem Protokoll der Versionsverwaltung sowie andere aus anderen Kanälen wie die Archive des Email Verteilers entnommen werden. Es geht also keine Information verloren, wenn man es in den Quellcode Dateien nicht erlaubt.
Wenn Ihr Projekt sich entscheidet einzelne Namen nicht in den Quellcode Dateien 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 Authoren 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 Author hat keine Einwände, den Namen des Authors entfernen, damit der Code wie jede andere von der Gemeinschaft gepflegte Ressource aussieht. Wenn der Author im Bezug darauf sensibel ist, sind Kompromisslösungen annehmbar, wie zum Beispiel:
# indexclean.py: Entferne die alten Daten aus einem Scanley Index. # # Ursprünglicher Author: 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 Authoren lassen sich überreden, da sie froh sind, dass ihr Beitrag zu einem engeren Bestandteil des Projekts gemacht wird.
Das Wichtig ist 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.
Versuchen Sie nicht Menschen Arbein machen zu lassen, die an ihrer Stelle von Machinen 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 ein mal macht. Bei sehr häufigen oder sehr komplexen Aufgaben, kann dieses Verhältniss sogar leich auf das zwansigfache oder gar 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 Kapitel 3, Technische Infrastruktur 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.
Automatisierte Testläufe sind für jedes Software Projekt 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.
Regressions Tests 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 Verteiler oder einen gesonderten Verteiler für die Test Ergebnisse, geschickt werden; was ein weiteres Beispiel für Automatisierung die sich lohnt.
Die meisten freiwilligen Entwickler sind bereit, die zusätzliche Zeit zu investieren, um Regressionstests zu schreiben, so lange das Test System 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 der Entwicklermannschaft, und wie schwierig es ist die Tests zu schreiben. Das CVS (http://www.cvshome.org/) 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 Regressions Testreihe 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 war 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 [40]. 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 weitergehen wird, wenn nichts gemacht wird.
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 herrlich funktionieren, je nachdem wie Sie es entwerfen und was es testen muss. Das Wesentliche ist einfach, dass wenn das Testsystem zu einer wesendlichen Behinderung für die Entwicklung wird, etwas getan werden muss. Das gleiche gilt, für jede wiederkehrende Aufgabe, welches sich zu einem Hinderniss oder Flaschenhals entwickelt.
Jede Interaktion mit einem Benutzer ist eine Gelegenheit, einen neuen Freiwilligen zu bekommen. Wenn ein Nutzer sich die Zeit nimmt, auf einem der Email Verteiler 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, was jeder machen kann.
Schränken Sie Ihre Ziele nicht darauf ein, neue Entwickler und Authoren 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 Enwickler 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 Email Verteilern machen und den Schaden den es anrichtet greifbar. Irgend ein unglückseliger Neuling schreibt eine nutzlosen 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 thausend mal 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, wie 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 Programmier Erfahrung hat, und keine vorhergehende Erfahrung mit der Meldung von Fehler, wird nicht wissen, wie man einen Ticket schreibt. Wie behandelt man so eine Person richtig? Schulen Sie ihn! Und machen Sie es derart, dass sie wieder für mehr kommen:
Tut mir leid, dass du Probleme hast. Wir werden mehr Informationen brauchen, um herauszufinden, was da los ist. Sag uns bitte deine Version von Scanley, dein Betriebssystem, und den genauen Text der Fehlermeldung. Das beste was du machen kannst ist, eine Abschrift der Befehle zu geben, 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 dabei, die erforderliche Information aus dem Benutzer heraus zu bekommen, da es entsprechend der Sicht des Nutzers geschrieben ist. Erstens drückt es Sympathie aus: Du hattest ein Problem; wir leiden mit dir . (Das ist nicht nötig in jeder Rückmeldung zu einer Bug Meldung; es hängt davon ab, wie schwerwiegend das Problem ist, und wie verärgert er zu sein scheint.) Zweitens, sagt es ihm wie sie einen neuen Ticket schreiben soll, damit es genügend Details enthällt, 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 weg zu lassen oder zu kürzen" bedeutet. Wenn Sie zum ersten mal mit einem solchen Nutzer arbeiten, müssen Sie im Bezug darauf explizit sein. Zuletzt, gibt es einen Hinweis auf eine biel detalliertere und komplette Anleitung, um Fehler zu melden. Wenn Sie erfolgreich mit dem Nutzer Kontakt aufgenommen haben, wird er sich oft die Zeit nehmen, dieses Dokument zu lesen und sich danach zu richten. Das bedeutet natürlich, dass Sie das Dockument im voraus bereit haben müssen. Es sollte klare Anweisungen geben, welche Art von Information Ihre Entwicklermannschaft in jedem Ticket sehen möchte. Im Idealfall, sollte es sich mit der Zeit auch enwickeln, entsprechend der bestimmten Art von fehlenden Informationen und Falschmeldungen die Nutzer bei Ihrem Projekt eher machen.
Die Anleitung um Fehler zu melden sind beim Subversion Projekt, eine relativ standardmäßiges Beispiel dieser Form (siehe Anhang D, Beispiel Anleitung für die Meldung von Fehlern). Beachten Sie, wie sie mit einer Einladung, einen Patch für den Bug, bereit zu stellen aufhören. Das liegt nicht daran, dass solch eine Einladung zu einem besseren Verhältniss von Patches zu Bugs führen wird—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 echte Sinn dieser Einladung ist, für alle Leser, insbesondere solchen, die neu zu dem Projekt oder freier Software im allgemeinen sind, zu betonen, dass das Projekt von freiwilligen Beiträgen lebt. Im gewissen Sinne, sind die derzeitigen Entwickler des Projekts, nicht mehr 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 eher dabei helfen, den Fix zu erstellen, wenn auch nicht indem sie Code beitragen, sondern indem sie eine Anleitung geben, um die Fehler zu reproduzieren, oder indem sie anbieten, die Patches welche andere einreichen Testen. Das Ziel ist, jeden Nutzer klar zu machen, dass es keinen immanenten Unterschied gibt, zwischen ihm und den Personen die an dem Projekt arbeiten—dass es eine Frage davon ist, wie viel Zeit und Mühe man hinein steckt, und keine davon wer man ist.
Die Mahnung dagegen, wütend zu antworten, gilt nicht für unhöfliche Nutzer. Ab und zu werden Fehler gemeldet oder beschwerden eingereicht, die unabhängig von ihrem Informationsgehalt, eine spöttische Verachtung für das Projekt, aufgrund von irgend einem Mangel. Solche Personen sind abwechselnd beleidigend und schmeichelnd, wie diese Person, die an dem Subversion Verteiler schrieb:
Warum ist 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 sachen nicht automatisiert, damit sie sofort verfügbar wären?? Wenn Ihr einen "RC" Build macht, denke ich Eure Idee ist, dass Ihr wollt, dass Nutzer den Build testen, tretzdem gebt ihr aber keine möglichkeit das zu machen. Warum soll man überhaupt eine einweich Phase haben, wenn ihr keine möglichkeit zum testen gibt??
Die anfängliche Reaktion zu dieser relativ flamehaften Nachticht war überraschend zurückhaltend: Man wies darauf hin, dass das Projekt eine Richtlinier 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 aller erstes, 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 auseinander genommen und ich kann nicht sagen, dass es mir wirklich was ausmachte. Die "Null-Toleranz" Richtlinie im bezug auf Beleidigungen die in „Unhöflichkeit im Keim ersticken“ im Kapitel Kapitel 2, Der Einstieg verfechtet wurde, gilt für Personen die mit dem das Projekt eine fortbestehende Interaktion hat (oder haben möchte). Wenn jemand es aber von Anfang an klar macht, das er ein Springbrunnen für Galle sein wird, hat es keinen Sinn ihn wilkommen zu heißen.
Solche Situationen sind zum Glück relativ selten, und sie sind wesentlich seltener bie Projekten, die sich die Mühe machen mit Nutzern ab dem ersten Dialog, auf eine konstruktive und zuvorkommende Art zu befassen.
[39] 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ändniss der Motivation und Bestrebungen in Freien/Open Source Software Projekten). Siehe http://freesoftware.mit.edu/papers/lakhaniwolf.pdf.
[40] 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.