Technische Infrastruktur
Freie Software-Projekte beruhen auf Techniken, die das
selektive Aufgreifen und Integrieren von Information ermöglichen. Je
gewandter Sie mit diesen Techniken umgehen und andere dazu bewegen
können, sie zu benutzen, desto erfolgreicher wird Ihr Projekt sein. Mit
zunehmender Größe Ihres Projekts, gewinnt diese Regel umso mehr an
Bedeutung. Eine gute Informationsverwaltung verhindert, dass ein
Open-Source-Projekt unter der Last von Brooks Gesetz ,Aus
seinem Buch The Mythical Man Month, 1975. Siehe
und
.
zusammenbricht. Sie besagt: Der Einsatz zusätzlicher Arbeitskräfte bei
bereits verspäteten Softwareprojekten vergrößert nur die Verspätung. Er
beobachtete, dass die Komplexität eines Projekts mit der Anzahl der
Teilnehmer Quadratisch zunimmt. Wenn nur wenige
beteiligt sind, kann jeder leicht mit jedem reden, wenn aber hunderte
beteiligt sind, ist es nicht weiter möglich, dass jeder über die Arbeit
aller anderen Bescheid weiß. Wenn es bei der Verwaltung eines freien
Software-Projekts darum geht, jedem das Gefühl zu geben in einem Raum
mit allen Anderen zu sitzen, stellt sich die offensichtliche Frage: Was
passiert wenn alle in einem gedrängten Raum versuchen auf einmal zu
reden?
Dieses Problem ist nicht neu. In der Praxis wird es gelöst
wie in einem Parlament: Es gibt formelle Richtlinien für Diskussionen
innerhalb von großen Gruppen, um sicherzustellen, dass wichtige
Meinungsverschiedenheiten nicht durch Zwischenrufe verloren gehen.
Weitere Richtlinien gibt es für die Bildung von Untergremien, sowie um
erkennen zu können, wann Entscheidungen getroffen werden, usw. Ein
wichtiger Teil der parlamentarischen Diskussion ist zu spezifizieren,
wie die Gruppe ihre Informationen verwaltet. Manche Anmerkungen werden
"fürs Protokoll" gemacht, andere nicht. Das Protokoll selbst ist
Gegenstand direkter Änderungen, und wird nicht als wörtliche
Niederschrift der tatsächlichen Ereignisse angesehen, sondern als
Auflistungen der gemeinsam anerkannten Ereignisse.
Das Protokoll ist nicht monolitisch, sondern nimmt verschiedene Formen
an, für verschiedene Zwecke. Es umfasst die einzelnen Sitzungen, die
komplette Sammlung aller Sitzungen, Zusammenfassungen, Tagesordnungen
mit Anmerkungen, Berichte von Gremien und nicht anwesenden
Korrespondenten, Abläufe, usw.
Da das Internet nicht wirklich ein Raum ist, müssen wir nicht die
Teile der parlamentarischen Diskussion replizieren, die manche Leute
ruhig hält, während andere Reden. Wenn es aber um Techniken zur
Verwaltung von Informationen geht, sind gut betriebene
Open-Source-Projekte
wie eine parlamentarische Diskussionen auf Steroiden. Weil
fast die gesamte Kommunikation in Open-Source-Projekten schriftlich
abläuft, haben sich wohl durchdachte Systeme entwickelt um Daten
angemessen zu markieren und an die richtige Stellen zu leiten; um
Wiederholungen zu minimieren, damit Diskussionen nicht auseinander
laufen; um Daten zu speichern und abzurufen; um schlechte oder veraltete
Informationen zu korrigieren; und um getrennte Informationen miteinander
zu verbinden, wenn Zusammenhänge gefunden werden. Aktive Teilnehmer
verinnerlichen viele dieser Techniken und werden oft komplexe manuelle
Aufgaben durchführen, um sicherzustellen, dass Information am richtigen
Ziel ankommen. Diese Bestrebungen hängen aber letztendlich von der
Unterstützung ausgeklügelter Software ab. Die Kommunikationsmedien
sollten so weit möglich, diese Aufgaben selbstständig übernehmen und
Information für Menschen so bequem wie möglich aufbereiten. In der
Praxis werden Menschen natürlich an vielen Stellen eingreifen müssen
und es ist wichtig, dass diese Eingriffe möglichst einfach sind. Im
allgemeinen sollte aber, solange die Menschen sich bemühen
Informationen sorgfältig zu Kennzeichnen und am richtigen Ziel zu
leiten, die Software so konfiguriert sein, dass sie den größtmöglichen
Nutzen aus diesen Metadaten zieht.
Die Ratschläge in diesem Kapitel sind sehr praxisnah und basieren
auf ganz bestimmter Software und Nutzungsverhalten. Es geht hierbei aber
nicht nur darum bestimmte Techniken zu zeigen. Es geht auch darum,
durch viele kleine Beispiele, die beste Haltung zu demonstrieren, um in
Ihrem Projekt eine möglichst gute Informationsverwaltung zu fördern.
Diese Haltung wird eine Kombination aus technischen Fähigkeiten und
sozialer Kompetenz sein. Technische Fähigkeiten sind unentbehrlich, da
die Software konfiguriert, sowie gelegentlich gepflegt und Angepasst
werden muss, sobald neue Anforderungen auftauchen (siehe z.B. den
Abschnitt über die Handhabung von Wachstum, im Abschnitt
später in
diesem Kapitel). Soziale Kompetenz ist nötig, da eine
menschliche Gemeinschaft auch gepflegt werden muss: Es ist nicht immer
sofort ersichtlich wie diese Hilfsmittel am besten genutzt werden,
und manchmal haben Projekte widersprüchliche Konventionen (siehe z.B.
Beispiel die Diskussion um die Einstellung des
Reply-to Headers bei ausgehende Nachrichten
der Mailingliste, in ). Jeder der
mit dem Projekt etwas zu tun hat, wird zur richtigen Zeit und auf die
richtigen Art, dazu ermutigt werden müssen, seinen Teil beizutragen,
die Information des Projekts geordnet zu halten. Je größer die
Beteiligung des Freiwilligen, desto komplexer und spezieller werden
die Techniken die man von ihr erwarten kann, sich anzueignen.
Es gibt keine schablonenhafte Lösung für Informationsverwaltung.
Es gibt einfach zu viele Variablen. Es kann sein das Sie irgendwann
alles richtig eingerichtet haben, genau wie Sie es haben möchten, und
die meisten Freiwilligen überredet haben mitzumachen. Sobald das Projekt
jedoch wächst, können sich manche dieser Vorgänge als nicht skalierbar
erweisen. Wenn der Wachstum sich stabilisiert und die Entwickler und
Nutzer sich an die technische Infrastruktur gewöhnen, kann eine völlig
neues Verwaltungssystem für Informationen aufkommen und neue Freiwillige
werden ziemlich bald fragen, warum Ihr Projekt diese nicht
einsetzt – viele freie Software-Projekte die vor der Erfindung von
Wikis gegründet wurden, erleben das derzeit (siehe
). Viele Fragen sind
Ansichtssache und sind Kompromisse zwischen dem Komfort derjenigen die
Informationen produzieren und dem Komfort derjenigen die diese
konsumieren, oder der Zeit die erforderlich ist, die Software
einzurichten und ihrem Nutzen für das Projekt.
Hüten Sie sich vor der Verlockung allzuviel zu automatisieren,
dass eigentlich die Aufmerksamkeit eines Menschen erfordert. Technische
Infrastruktur ist wichtig, aber ein freies Software-Projekt
funktioniert in Wirklichkeit durch die Fürsorge – und die kluge
Formulierung dieser Fürsorge – der beteiligten Menschen. Die
technische Infrastruktur ist hauptsächlich diesen Menschen das möglichst
zu vereinfachen.
Das nötige Werkzeug
Die meiste Open-Source-Projekte haben ein Mindestmaß an üblichen
Hilfsmitteln um Informationen zu Verwalten:
Webseite
Hauptsächlich ein zentralisierter Kanal für
Informationen vom Projekt in die Öffentlichkeit.
Die Webseite kann auch eine administrative
Schnittstelle für andere Hilfsmittel des Projekts
sein.
Mailinglisten
Meistens das aktivste Forum in einem Projekt und das
Medium "fürs Protokoll".
Versionsverwaltung
Ermöglicht es den Entwicklern Änderungen am Code bequem
zu verwalten, u.a. auch rückgängig zu machen. Erlaubt es
allen zu sehen was mit dem Code passiert.
Bugtracker
Ermöglicht Entwicklern ihre Arbeit im Blick zu behalten,
miteinander zu koordinieren und neue Versionen zu planen.
Erlaubt es jedem den Status von einem Bug zu überprüfen
und Informationen über den Bug festzuhalten (z.B. wie man
ihn reproduziert). Kann außer zur Beobachtung von Fehlern
auch für die Planung von Aufgaben, neuen Versionen,
Funktionen usw. benutzt werden.
Chat
Ein Ort für kurze, oberflächliche Diskussionen und um
Fragen und Antworten auszutauschen. Wird nicht immer
vollständig archiviert.
Jedes dieser Hilfsmittel ist dazu gedacht, einen bestimmten Bedarf
zu decken, ihre Funktionen sind aber auch mit einander verwandt und
müssen so eingerichtet werden, dass sie zusammen funktionieren. Weiter
unten werden wir untersuchen wie man sie so einrichten kann und viel
wichtiger noch, wie man Leute dazu bewegt sie zu benutzen. Die Webseite
wird erst zum Schluss behandelt, da es eher als Klebstoff dient denn als
eigenständig zu sehendes Hilfsmittel.
Sie können sich eine Menge Kopfschmerzen bei der Einrichtung
dieser Hilfsmittel ersparen, mit der Hilfe von Hosting-Bündel: Ein
Server der vorkonfigurierte Seiten und Vorlagen bereitstellt, sowie alle
zugehörigen Hilfsmittel die man braucht um ein freies Software-Projekt
zu betreiben. Siehe
später in
diesem Kapitel indem die Vor- und Nachteile von Hosting-Lösungen
behandelt werden.
Mailinglisten
Mailinglisten sind im Projekt das tägliche Brot der
Kommunikation. Sieht der Nutzer irgend ein anderes Forum außer der
Webseite, wird es wahrscheinlich eine der Mailinglisten sein. Vorher
werden sie sich aber mit der Anmeldung beschäftigen müssen. Das bringt
uns zur ersten Regel von Mailinglisten:
Versuchen Sie nicht, die Mailingliste händisch
zu verwalten – Besorgen Sie sich dazu die nötige
Software.
Es wird verlockend sein, diese Aufgabe hinauszuschieben. Am Anfang
scheint es überflüssig diese Software einzurichten. Kleine Verteiler mit
geringem Nachrichtenverkehr, scheinen verlockend einfach zu verwalten:
Man richtet einfach eine Adresse für die Anmeldung ein, die Anmeldungen
werden an Sie weiterleitet, worauf Sie seine Adresse in einer Text-Datei
eintragen, indem alle Adressen enthalten sind. Was könnte einfacher
sein?
Es gibt allerdings einen Haken. Ein gut verwalteter Verteiler
– was viele mittlerweile erwarten – ist alles andere als
einfach. Es geht nicht nur darum Leute an- und abzumelden wenn sie eine
entsprechende Anfrage stellen. Es geht u.a. darum Spam zu verhindern,
nicht einzelne Nachrichten, sondern Zusammenfassungen zu verteilen und
Informationen über den Verteiler und das Projekt mittels
automatisierter Antworten zu verschicken. Ein Mensch der die Adresse
eines Verteilers beobachtet, bietet nur ein Mindestmaß an Funktionen,
und selbst dann nicht so zuverlässig und schnell wie es eine Software
könnte.
Moderne Mailinglisten-Software bietet für gewöhnlich
mindestens folgende Funktionen:
Anmeldung sowohl per E-Mail als auch über die
Webseite.
Wenn ein Nutzer sich bei der Mailingliste anmeldet, sollte er
umgehend eine automatisierte
Willkommensnachricht bekommen, in der beschrieben steht,
wofür er sich angemeldet hat, wie man weiter mit der
Mailingliste umgeht und (am wichtigsten) wie man sich
abmeldet. Diese automatische E-Mail kann natürlich
bearbeitet werden, um projektspezifische Informationen
einzuschließen, wie z.B. die Webseite des Projekts, wo man
die FAQ findet, usw.
Nachrichten in Kurzform oder als
Einzelnachrichten
Im Digest-Modus wird einmal am Tag eine E-Mail verschickt.
Sie ist eine Zusammenfassung der gesamten Aktivität auf der
Mailingliste, die im Verlauf des Tages aufgekommen ist. Wer
die Liste nur nebenher verfolgt, ohne selbst beteiligt zu
sein, bevorzugt oft diese Form, da dies ihnen erlaubt, alle
Themen auf einmal durchzusehen und hat den Vorteil, die
Ablenkung durch ständig eintreffende E-Mails zu
vermeiden.
Moderation
"Moderieren" bedeutet sicherzustellen, dass Nachrichten
a) kein Spam sind und b) zum Thema
gehören, bevor sie verteilt werden. Moderation muss
zwangsläufig von Menschen erledigt werden, aber Software
kann eine Menge dazu beitragen, die Aufgabe einfacher zu
gestalten. Zu diesem Thema später mehr.
Administrative Schnittstellen
Diese ermöglichen es einem Administrator u.a. ohne Umstände
veraltete Adressen zu löschen. Was dringend werden kann,
wenn die Adresse eines Empfängers anfängt, Antworten wie "Ich bin nicht
mehr bei dieser Adresse" auf jede Nachricht von der
Liste zu schicken. (Manche Listensoftware kann so etwas
automatisch erkennen und die Person abmelden.)
Manipulieren der Header
Viele Leute haben ausgeklügelte Filter- und Antwort-Regeln für
ihre E-Mail-Programm eingerichtet. Mailinglisten-Software
kann bestimmte Header hinzufügen und manipulieren, die die
Empfänger ausnutzen können (mehr dazu später).
Archivierung
Alle Nachrichten an die Liste werden gespeichert und
im Netz bereitgestellt; alternativ bietet manche Software
spezielle Schnittstellen an um externe Archivierungssoftware
einzubinden wie z.B.
(). Archivierung ist
unerlässlich, mehr dazu in
im
Kapitel .
Der Sinn dieser Punkte ist lediglich zu betonen, dass die
Verwaltung einer Mailingliste ein komplexes Problem ist, mit dem
sich schon viele beschäftigt haben und weitestgehend gelöst haben. Sie
müssen sicherlich kein Experte auf diesem Gebiet werden. Aber Sie
sollten sich bewusst machen, dass es immer mehr zu lernen gibt, und
dass die Verwaltung der Liste im Verlauf eines freien Software
Projekts ab und zu etwas Zeit in Anspruch nehmen wird. Im weiteren
werden wir ein paar der häufigsten Punkte beim Konfigurieren einer
Antworten angehen.
Schutz vor Spam
Seit ich diesen Satz schrieb, bis zu seiner Veröffentlichung,
ist das Internet-weite Spam-Problem wahrscheinlich doppelt so schlimm
geworden – oder zumindest wird es einem so vorkommen. Es gab eine
Zeit, nicht all zu lange her, in der man eine Liste betreiben
konnte ohne überhaupt irgend welche Maßnahmen gegen Spam vornehmen zu
müssen. Gelegentlich verirrte sich eine Nachricht, aber selten genug
um nur eine geringes Ärgernis zu sein. Diese Ära ist für immer vorbei.
Heutzutage wird eine Mailingliste, die keine Maßnahmen gegen Spam
unternimmt, schnell von Werbemüll überflutet und dadurch
unbenutzbar. Schutz vor Spam ist unerlässlich.
Wir unterteilen Schutz vor Spam in zwei Kategorien: Spam
daran zu hindern auf Ihrer Liste aufzutauchen, und zu verhindern,
dass Ihre Liste für Spam harvester zu einer Quelle von Adressen wird.
Ersteres ist wichtiger also untersuchen wir es zuerst.
Filterung von Nachrichten
Es gibt drei grundsätzliche Arten, Spam zu vermeiden und die
meisten Mailinglisten bieten alle drei an. Gemeinsam arbeiten sie am
effizientesten:
Es sollten nur Nachrichten von
angemeldeten Nutzern automatisch angenommen
werden.
Diese Einstellung ist weitestgehend effektiv und
ist nicht besonders schwer einzurichten, da es für
gewöhnlich nur eine kleine Änderung an der Konfiguration
der Software des Verteilers bedeutet. Beachten Sie aber,
dass Nachrichten, die nicht automatisch akzeptiert werden,
nicht einfach verworfen werden sollten. Es gibt zwei
Gründe, warum sie stattdessen für weitere Moderation
aufbewahrt werden sollten. Erstens wollen Sie auch
unangemeldeten Benutzer erlauben, Nachrichten an die Liste
zu senden, schließlich sollte eine Person mit einer Frage
oder einem Vorschlag sich nicht gleich anmelden müssen, um
eine einzige E-Mail zu senden. Zweitens kann es vorkommen,
dass auch angemeldete Benutzer eine anderen E-Mail-Adresse
benutzen als die, mit der sie angemeldet sind. E-Mail-Adressen
sind keine zuverlässige Möglichkeit, Menschen zu
identifizieren und sollten nicht als solche behandelt
werden.
Benutzen Sie einen Spam-Filter
Wenn die Software des Verteilers es ermöglicht (was
die meisten tun), können Sie Nachrichten durch einen Spam-Filter
laufen lassen. Automatisierte Spam-Filterung ist
nicht perfekt und wird es aufgrund des andauernden
Wettrüstes zwischen Spammern und den Autoren der
Filtersoftware auch nie sein. Es kann aber einen großen Teil des
Spams reduzieren, der bis zu den Moderatoren durchkommt.
Jede solche Filterung ist vorteilhaft, da die Moderatoren
weniger Zeit mit dem Untersuchen von Nachrichten verbringen
müssen, und deshalb sehr wünschenswert.
Hier ist nicht der Raum für eine detailierte
Anleitung, wie man einen Spam-Filter einrichtet. Sie werden
hierzu die Dokumentation Ihrer Mailinglisten-Software lesen
müssen (siehe
später in diesem Kapitel). E-Mail-Verteiler haben
oft eingebaute Möglichkeiten um Spam zu verhindern, es kann
aber sein, dass Sie weitere Filter von einem dritten
Anbieter hinzufügen wollen. Mit diesen Beiden habe ich gute
Erfahrungen gemacht: SpamAssassin
() und
SpamProbe
(). Das soll
allerdings kein Urteil über andere Open-Source-Filter sein,
von denen einige scheinbar auch ziemlich gut sind. Ich habe
zufällig diese Beiden benutzt und war mit ihnen
zufrieden.
Moderation.
Die Letzte Stufe für Nachrichten die nicht von einem
angemeldeten Benutzer stammen und es durch den Spamfilter
schaffen, ist die Moderation: Die
E-Mail wird an eine bestimmte Adresse geleitet, wo es von
einem Menschen untersucht wird, der sie entweder annimmt
oder ablehnt.
Eine E-Mail zu akzeptieren, kann eine von zwei Formen
annehmen: Sie können die E-Mail nur dieses eine Mal
annehmen oder Sie können die Software anweisen, diese eine
und alle weiteren Nachrichten von dieser Adresse anzunehmen.
Letzteres ist fast immer vorzuziehen, um die zukünftige Bürde
der Moderation zu verringern. Wie man Nachrichten annimmt,
kann sich von System zu System unterscheiden, für gewöhnlich
reicht es aber eine E-Mail, an eine bestimmte Adresse zu
senden, mit einem Befehl wie "accept" (um nur diese eine
E-Mail zu erlauben) oder "allow" (um diese und alle
weiteren Nachrichten zu erlauben).
Um eine Nachricht abzulehnen reicht es meistens sie
einfach zu ignorieren. Wenn der Verteiler niemals eine
Bestätigung erhält, wird er die E-Mail auch nicht
verteilen. Das erwünschte Ergebnis erreicht man also, indem
man die E-Mail einfach ignoriert. Manchmal haben Sie auch
die Möglichkeit mit "reject" oder "deny" an den Verteiler
zu antworten, was dazu führt, dass alle weiteren Nachrichten
von dieser Adresse automatisch abgelehnt werden, ohne
moderiert zu werden. Es gibt selten einen Grund dafür, da
es bei der Moderation meistens darum geht, Spam zu vermeiden
und Spammer selten zwei mal die gleiche Adresse
benutzen.
Die Moderierung sollte allerdings
ausschließlich für Spam und Nachrichten benutzt
werden, die eindeutig nicht auf die Liste gehören, wie z.B. wenn
jemand aus versehen eine Nachricht an die falsche Adresse schickt. Das
System wird Ihnen meistens eine Möglichkeit geben eine E-Mail direkt an
den Absender zu schicken, nutzen Sie diese aber nicht, um Fragen zu
beantworten die eigentlich auf die Mailingliste gehören, selbst
wenn Ihnen sofort die Antwort einfällt. Das würde der Gemeinschaft des
Projekts nur die Möglichkeit entziehen sich ein klares Bild zu machen,
welche Fragen von der Öffentlichkeit gestellt werden und Sie der
Gelegenheit berauben, diese Fragen selber zu beantworten und/oder die
Antworten anderer zu sehen. Die Moderation einer Mailingliste
sollte sich ausschließlich auf Werbemüll und irrelevante Nachrichten
beschränken und sonst nichts.
Verschleierung von Adressen im Archiv
Um zu verhindern, dass Ihr Verteiler zu einer Quelle von E-Mail-Adressen
für Spammer wird gibt es die gebräuchliche Methode, Adressen in
den Archiven zu verschleiern indem man z.B.
hmustermann@einedomain.de
mit
hmustermann_AT_einedomain.de
oder
hmustermannKEINSPAM@einedomain.de
oder irgendetwas (für Menschen) ähnlich offensichtliches ersetzt.
Da Spam-Harvester oft nach dem Prinzip funktionieren, Webseiten
abzugrasen – auch die Archive Ihres Verteilers – und nach
Zeilen mit einem "@" suchen, ist diese Art der Verschleierung eine
effektive Methode E-Mail-Adressen vor Spammern zu verstecken oder
unbrauchbar zu machen. Was natürlich nichts am Spam, der an die Liste
selbst geschickt wird ändert, aber es kann die Menge an Spam
reduzieren, die direkt an die persönlichen Adressen der Nutzer des
Verteilers gesandt wird.
Die Verschleierung von Adressen kann kontrovers sein. Manche
finden, dass es eine gute Idee ist und werden sich wundern wenn Ihre
Archive es nicht automatisch machen. Andere denken es ist eine zu große
Unbequemlichkeit (da Menschen auch die Adresse wieder korrigieren
müssen, vor sie benutzt werden können). Manche behaupten, dass es nicht
effektiv sei, da Harvester theoretisch jede konsistente Verschleierung,
ausgleichen können. Es gibt jedoch empirische Beweise, dass die
Verschleierung von Adressen tatsächlich
funktioniert, siehe
.
Im Idealfall würde die Listensoftware diese Entscheidung jedem
Benutzer überlassen, entweder durch einen zusätzlichen Header oder in
den Einstellungen seines Listenkontos. Ich kenne allerdings
keine Software, die diese Entscheidung für jede Nachricht oder jeden
Nutzer ermöglicht, also wird vorerst der Administrator der Liste,
diese Entscheidung für alle übernehmen müssen (angenommen die
Archivierungssoftware bietet diese Einstellung überhaupt an, was nicht
immer der Fall ist). Ich ziehe es vor die Verschleierung anzuschalten.
Manche sind sehr vorsichtig Ihre Adresse nicht auf Webseiten oder
irgendwo anders zu platzieren, an dem ein Spam-Harvester sie finden
könnte und sie wären enttäuscht, wenn all ihre Mühe vom Archiv einer
Mailingliste zunichte gemacht würden; zudem ist der Aufwand der durch die
Verschleierung den Nutzern auferlegt wird nur sehr gering, da es
trivial ist eine verschleierte Adresse zu korrigieren, sollte man die
Person erreichen wollen. Behalten Sie aber das Wettrüsten im
Hinterkopf: Bis Sie diese Zeilen lesen kann es durchaus sein, dass die
Harvester sich so weit entwickelt haben, dass sie die häufigsten
Verschleierungen erkennen können und wir müssen uns wieder etwas neues
einfallen lassen.
Die große "reply-to"-Debatte
Ich habe vorhin in
betont, wie wichtig es ist, Diskussionen in den öffentlichen Foren zu
halten und erwähnte, dass aktive Maßnahmen manchmal nötig sind, um
zu verhindern, dass Unterhaltungen ins private abgleiten; weiterhin
geht es in diesem Kapitel darum, die Kommunikationssoftware soweit zu
konfigurieren, dass sie möglichst viel Arbeit übernimmt. Es wäre
deshalb anzunehmen, dass Verteiler mit einer Möglichkeit, alle
Nachrichten öffentlich zu halten, diese Option offensichtlich
anschalten sollte.
Nun ja, nicht ganz. Es gibt solch eine Funktion, allerdings hat
sie ein paar schwerwiegende Nachteile. Die Frage ob man sie benutzen
soll oder nicht, ist eine der am heißesten debattierten bei der
Verwaltung von Mailinglisten – zugegeben, es ist nicht
unbedingt eine Kontroverse die es auf die Titelseite Ihres Tageblatts
schaffen würde, aber Sie kann in einem freien Software-Projekt ab und
zu aufflammen. Unten werde ich die Funktion beschreiben, die
Hauptargumente beider Seiten erläutern und die mir bestmögliche
Empfehlung geben.
Die Funktion selbst ist relativ einfach: Wenn Sie wollen, kann
die Listen-Software automatisch den Reply-to (de. Antwort an) Header
auf die Adresse der Liste setzen. Was so viel heißt, dass egal
was der Autor einer E-Mail in den Reply-to Header schreibt (bzw.
selbst wenn er nicht einmal angegeben wird), bei den Empfängern
der Header mit der Adresse der Liste erscheint:
Reply-to: discuss@lists.example.org
Oberflächlich scheint das eine gute Sache zu sein. Praktisch
jede E-Mail-Software berücksichtigt den Reply-to Header. Wenn nun
jemand auf eine Nachricht antwortet, wird seine Nachricht an die
gesamte Liste gerichtet sein und nicht nur an den Autor der
ursprünglichen Nachricht. Natürlich kann der Antwortende immer noch
händisch den Empfänger ändern, wichtig ist aber, dass Antworten
standardmäßig an die Liste gerichtet sind. Es
ist ein perfektes Beispiel für eine Technik, um gemeinschaftliche
Arbeit zu unterstützen.
Leider gibt es einige Nachteile. Der erste ist bekannt als
das Ich-finde-nicht-den-Weg-nach-Hause-Problem:
Manchmal setzt der ursprüngliche Absender seine "echte" E-Mail-Adresse
in den Reply-to Header, da er aus irgendeinem Grund die Nachricht von
einer anderen Adresse absendet, als er Antworten empfangen möchte.
Personen, die immer von der gleichen Adresse absenden und empfangen,
kennen dieses Problem nicht und viele sind überrascht, dass es das
Problem überhaupt gibt. Für Leute mit einer ungewöhnlichen
E-Mail-Konfiguration oder ohne Einfluss auf die Gestalt ihrer E-Mails
(vielleicht weil sie von der Arbeit schreiben und keinen Einfluss
auf ihre IT-Abteilung haben), kann der Reply-to Header die einzig
sichere Möglichkeit sein, Antworten an die richtige Adresse zu leiten.
Wenn Sie nun an eine Liste schreiben, ohne in dieser angemeldet zu
sein, wird ihre Reply-to Einstellung zu einer unabdingbaren Information.
Wenn der Verteiler diese nun überschreibt, wird Sie die Rückmeldung auf
Ihre Nachricht vielleicht niemals erreichen.
Der zweite Nachteil betrifft eine Erwartungshaltung, und das ist
meiner Meinung nach das stärkste Argument gegen die Verunstaltung von
Reply-to. Die meisten erfahrenen E-Mail-Nutzer, sind an zwei
grundsätzliche Arten zu antworten gewohnt: reply-to-all
(Antwort an alle) und reply-to-author
(Antwort an Autor). Alle modernen E-Mail-Programme bieten
beide Optionen an. Nutzer wissen, dass sie reply-to-all wählen
sollten um an alle zu antworten (d.h. inklusive der Personen auf der
Liste), und dass sie reply-to-author wählen sollten, um eine
private Nachricht an den Autor zu schicken. Auch wenn Sie an jeder
möglichen Stelle zu offenen Diskussionen ermutigen sollten, gibt es
doch Situationen, bei denen der Antwortende eine private Nachricht
bevorzugen sollte – zum Beispiel wenn er etwas im Vertrauen
an den Autor schreiben möchte, was unangemessen für die öffentliche
Liste wäre.
Schauen Sie, was nun passiert, wenn der Verteiler den
ursprünglichen Reply-to Eintrag überschreibt und der Antwortende auf
den reply-to-author Knopf drückt, in der Erwartung eine private E-Mail
an den Absender zu schicken. Aufgrund seiner Erwartungshaltung, wird
er die Adresse des Empfängers vielleicht nicht nochmals überprüfen. Er
hat dabei vielleicht eine geheime, vertrauliche Nachricht verfasst,
mit peinlichen Details über ein Mitglied des Verteilers und drückt nun
auf absenden. Seine Nachricht erscheint nun unerwartet, etwas später
auf dem Verteiler! Zugegeben, theoretisch hätte
er sorgfältig auf das Empfänger-Feld achten sollen, und keine Annahmen
über den Reply-to Header machen sollen. Autoren setzen aber fast immer
Reply-to auf ihre eigene persönliche Adresse (bzw. ihre E-Mail-Software
macht es für sie), und viele langjährige Nutzer, erwarten es
mittlerweile. Das geht sogar soweit, dass wenn jemand absichtlich
reply-to auf irgendeine andere Adresse setzt als den Verteiler, er es
explizit in dem Text der E-Mail erwähnt, damit Leute sich bei ihrer
Antwort nicht wundern.
Aufgrund der potentiell schwerwiegenden Folgen dieses unerwarteten
Verhaltens, bevorzuge ich es, Verteiler so zu konfigurieren, dass sie
den reply-to Header niemals anfassen. Es ist ein Beispiel für eine
Technik um Zusammenarbeit zu unterstützen, mit wie es mir scheint,
potentiell gefährlichen Nebenwirkungen. Auf der anderen Seite dieser
Debatte gibt es jedoch auch starke Argumente. Es werden Leute, egal wie
Sie sich entscheiden, ab und zu fragen, warum Sie sich nicht anders
entschieden haben. Da sowas niemals zum Hauptthema einer Diskussion
werden sollte, kann es angebracht sein, hierfür eine vorformulierte
Antwort parat zu haben, die so gestaltet ist, dass sie die Diskussion
eher beendet als anfeuert. Stellen Sie klar, dass Sie
nicht darauf bestehen, die einzig richtige und
sinnvolle Entscheidung getroffen zu haben, (selbst wenn Sie das denken).
Deuten statt dessen darauf wie alt diese Debatte ist, dass es gute
Argumente auf beiden Seiten gibt, keine Entscheidung alle
zufriedenstellen wird und dass Sie einfach die Ihnen bestmögliche
Entscheidung getroffen haben. Bitten Sie höfflich darum diese
Diskussion nicht weiterzuführen, es sei denn jemand hat etwas wirklich
neues zu sagen. Halten Sie sich danach aus dem Thread heraus und
hoffen Sie, dass er eines natürlichen Todes stirbt.
Jemand wird vielleicht vorschlagen eine Wahl darüber zu halten.
Wenn Sie möchten können Sie das tun, ich persönlich finde es in diesem
Fall jedoch unzureichend einfach Köpfe zu zählen. Für jemanden, der ein
gewisses Verhalten erwartet, wäre die Strafe unangemessen hoch
(versehentliche Sendung einer privaten E-Mail an die Liste) und
die Unbequemlichkeit für die übrigen Teilnehmer ist relativ gering (ab
und zu jemand daran erinnern an den ganzen Verteiler zu antworten,
statt nur an den Autor), weshalb man nicht eindeutig sagen kann dass
die Mehrheit, auch wenn sie das ist, eine Minderheit in solch eine
Gefahr bringen darf.
Ich habe nur die wichtigsten Aspekte dieses Themas hier
angesprochen. Für eine vollständige Behandlung des Themas verweise
ich auf folgende zwei anerkannten Dokumente, die bei dieser Debatte
immer wieder zitiert werden:
Lass Reply-to in Ruhe,
von Chip Rosenthal
Setze Reply-to auf die Liste,
von Simon Hill
Trotz meiner angedeuteten leichten Präferenz, denke ich nicht,
dass es auf diese Frage eine "richtige" Antwort gibt und beteilige
mich auch gerne auf vielen Listen die Reply-to setzen. Das
wichtigste zu diesem Thema ist, sich frühzeitig für das eine oder
andere zu entscheiden und sich danach nicht zu Debatten über das Thema
verleiten zu lassen.
Zwei Fantasien
Eines Tages wird jemand auf die geniale Idee kommen, einen
reply-to-list Schlüssel in einer E-Mail
Software zu implementieren. Es würde irgendwelche der vorher
erwähnten spezifischen Header benutzen, um die Adresse der Mailingliste
herauszufinden und direkt bzw. nur an die Liste zu
antworten, ohne gesonderte Adresse für den Empfänger, da diese höchst
wahrscheinlich sowieso die Liste abonniert haben. Mit der Zeit
werden andere E-Mail-Programme diese Funktion übernehmen und diese
ganze Debatte wird sich auflösen. (Tatsächlich gibt es sogar eine
E-Mail-Software namens Mutt
mit einer solchen Funktion. Kurz nachdem dieses Buch
erschien, schrieb mir
Michael Bernstein
folgende Nachricht: "Es gibt weitere E-Mail-Programme außer Mutt, die
eine reply-to-list Funktion implementiert haben. Evolution bietet
diese Funktion z.B. wenn auch ohne eigene Schaltfläche, über die
Tastenkombination (Strg+L).")
Eine noch bessere Lösung wäre es, die Verunstaltung von
Reply-to jedem selbst zu überlassen. Wer haben möchte, dass der
Verteiler ihre Reply-to Header ändert (entweder nur für ihren eigenen
oder für alle Nachrichten) könnten darum bitten und solche die es
nicht wollen, könnten bitten es in Ruhe zu lassen. Ich kenne jedoch
keine Software die so etwas für jeden Benutzer einzeln einstellen lässt.
Es scheint, dass wir derzeit mit einer globalen Einstellung für alle
leben müssen.Seitdem ich das schrieb, habe ich
zumindest von einer Mailinglisten-Software erfahren, die diese
Funktion anbietet:
Siesta. Siehe dazu
auch diesen Artikel:
Archivierung
Wie man genau ein Archiv für Mailinglisten einrichtet, ist bei
jeder Listen-Software unterschiedlich, und würde den Rahmen dieses Buchs
sprengen. Wenn Sie ein Programm zur Archivierung wählen oder konfigurieren,
sollten Sie auf folgendes achten:
Zeitnahe Aktualisierung
Teilnehmer werden oft auf eine archivierte Nachricht
verweisen wollen, die erst vor ein oder zwei Stunden
gepostet wurde. Wenn möglich sollte die Software jede
Nachricht sofort archivieren, sodass im gleichen Moment,
indem es vom Verteiler versandt wird, es auch im Archiv
ist. Wenn diese Option nicht verfügbar ist, versuchen Sie
die Software zumindest so einzustellen, dass es sich ca.
jede Stunde aktualisiert. (Standardmäßig lässt mache
Software die Aktualisierung ein Mal jede Nacht laufen, was
aber bei einer aktiven Mailingliste in der Praxis eine
viel zu große Verzögerung bedeutet.)
Link Stabilität
Sobald eine E-Mail unter einer bestimmten URL archiviert
wurde, sollte sie ewig, bzw. so lang wie möglich unter
genau der gleichen URL erreichbar sein. Selbst wenn die
Archive neu aufgebaut werden, aus einem Backup
wiederhergestellt werden oder sonstwie repariert werden,
sollte jede öffentlich bekannte URL weiterhin gültig sein.
Stabile Verweise ermöglichen es Suchmaschinen die Archive
zu indexieren und das ist für Nutzer die auf der Suche nach
einer bestimmten Nachricht sind, ein großer Segen. Stabile
Verweise sind auch wichtig, da der Bugtracker (siehe
)
später in diesem Kapitel oder Dokumente des
Projekts oftmals auf darin enthaltene Nachrichten
verweisen.
Idealerweise würde die Mailinglisten-Software eine URL
der jeweiligen Nachricht im Archiv, in einem Header
mitschicken oder zumindest den URL-Teil, spezifisch für
die E-Mail. So weiß jeder mit einer Kopie der E-Mail, wo
es im Archiv zu finden ist, ohne die Archive tatsächlich
aufsuchen zu müssen, was hilfreich wäre da jeder Vorgang
mit dem Browser, automatisch einen größeren Zeitaufwand
bedeutet. Ich weiß nicht ob irgendeine Listen-Software
diese Funktion anbietet; diejenigen die ich benutzt habe,
können es leider nicht. Es ist allerdings etwas nachdem
man suchen sollte (oder falls Sie Mailinglisten-Software
schreiben, wäre es eine Funktion, die Sie bitte
in Erwägung ziehen sollten).
Backup
Es sollte ziemlich offensichtlich sein wie man Sicherungen
des Archivs macht und der Vorgang um sie wiederherzustellen
sollte nicht zu schwierig sein. Mit anderen Worten,
behandeln Sie Ihr Archiv nicht wie eine Blackbox. Sie (oder
jemand aus Ihrem Projekt) sollte wissen wo die Nachrichten
gespeichert werden und wie die Seiten des Archivs
sich wiederherzustellen lassen, sollte es jemals nötig
werden. Diese Archive sind wertvolle Daten – wenn ein
Projekt sie verliert, geht auch ein großer Teil seiner
kollektiven Erinnerung verloren.
Unterstützung für Threads
Es sollte möglich sein, von jeder Nachricht aus, zu seinem
zugehörigen thread (eine Gruppe
verwandter Nachrichten) zu gehen. Jeder Thread sollte auch
seine eigene URL haben, getrennt von denen seiner einzelnen
Nachrichten.
Durchsuchbarkeit
Ein Archiv das man nicht durchsuchen kann – sowohl
Volltext, als auch Betreffzeilen – ist nahezu wertlos.
Bedenke, dass manche Archive ihre Suchfunktion über eine
externe Suchmaschinen wie
Google
anbieten, indem sie die Arbeit einfach auslagern. Das
ist zwar akzeptable, aber eine direkte Suchfunktion ist
meistens besser abgestimmt, da es dem Suchenden z.B.
erlaubt, nur die Betreffzeile zu durchsuchen oder den
gesamten Text.
Obiges ist lediglich eine Checkliste, um Ihnen die Evaluierung und
Einrichtung der Software für ihre Archive zu erleichtern. Leute zu
überreden es wirklich zum Vorteil des Projekts zu
benutzen wird in späteren Kapiteln behandelt,
insbesondere im Abschnitt .
Mailinglisten-Software
Hier sind einige Open-Source-Programme für die Verwaltung von
Listen und Archives. Wenn Ihre Projektseite bereits vorkonfiguriert
wurde, werden Sie sich u.U. niemals für eines entscheiden müssen. Wenn
Sie es jedoch selber einrichten müssen, sind hier einige Optionen. Zu
der Software, die ich tatsächlich benutzt habe gehört Mailman, Etmlm,
MHonArc, und Hypermail, was aber keine Aussage über andere sein soll
(und natürlich gibt es bestimmt auch andere Programme die ich einfach
nicht gefunden habe, betrachten Sie diese Liste also nicht als
vollständig).
Software für Mailinglisten:
Mailman –
(Mit einem eingebauten Archiv und die Möglichkeit externe
einzubinden. Mailman ist seit langer Zeit der Standard;
seine administrative Schnittstellen, insbesondere für die
Moderation von Spam und frisch angemeldeten Mitgliedern,
wirken recht angestaubt und können besonders auf diejenigen
frustrierend wirken, die modernere Schnittstellen
gewohnt sind.)
GroupServer –
(Hat eingebaute Archivierung und integriertes Web-Interface.
GroupServer ist etwas schwerer einzurichten als Mailman, und
erfordert (Stand: Anfang 2012) eine sehr spezielle Menge an
Voraussetzungen, aber wenn Sie ihn erst einmal zum Laufen
gebracht haben, bietet es den Benutzern ein besseres
Arbeiten.)
Sympa —
(Entwickelt und gepflegt durch einen Verband französischer
Universitäten, sowohl für sehr große Listen ausgelegt
(> 700000 Mitglieder) als auch eine große Anzahl von Listen.
Es kann mit einer Vielzahl von Abhängigkeiten umgehen;
z.B. können Sie es mit sendmail, postfix, qmail oder exim
als unterliegenden Message Transfer Agent nutzen.
Eine Web-basierte Archivierung ist eingebaut.)
SmartList –
(Für die Nutzung mit Procmail gedacht.)
Ecartis –
ListProc –
Ezmlm –
(Entworfen für
Qmail.)
Dada –
(Trotz des bizarren Versuchs der Webseite die Tatsache zu
verstecken, dass sie freie Software ist, wird sie unter der
GNU GPL veröffentlicht. Es hat auch einen eingebauten
Archiv.)
Software zur Archivierung:
MHonArc –
Hypermail –
Lurker –
Procmail –
(Begleitend zu SmartList, eine allgemeine Software zur
Verarbeitung von E-Mails und scheinbar auch als Archiv
konfigurierbar.)
Versionsverwaltung
Eine Versionsverwaltungim Deutschen
auch manchmal "Versionskontrolle" genannt.
(en. Version Control) ist eine Kombination verschiedener Techniken
und Verfahren um Änderung an den Dateien eines Projekts, insbesondere
Quellcode, Dokumentation und Webseiten, zu verfolgen und verwalten. Wenn
Sie Versionsverwaltung noch nie benutzt haben, sollten Sie sich als
Erstes jemand suchen die es kennt und sie überreden dem Projekt
beizutreten. Heutzutage wird jeder erwarten, dass zumindest Ihr
Quellcode unter Versionsverwaltung steht und keiner wird Ihr Projekt
ernst nehmen, wenn es nicht zumindest halbwegs kompetent mit seiner
Versionsverwaltung umgeht.
Versionsverwaltung ist beim Betrieb eines Projekts allgegenwärtig,
weile es in nahezu jedem Bereich hilft: Kommunikation unter den
Entwicklern, Veröffentlichung neuer Versionen, Bug-Verwaltung,
Code-Stabilität und experimentelle Entwicklungen sowie die Annahme von und
Anerkennung für Änderungen durch bestimmte Entwickler. Die
Versionsverwaltung kann all diese Bereiche zentral koordinieren. Der
Kern der Versionsverwaltung ist die Verwaltung von Änderungen (en.
change management: Sie identifiziert jede
einzelne Änderung an den Dateien eines Projekts, fügt ihnen Metadaten
bei, wie das Datum der Änderung, den Namen des Autors und kann jedem der
danach sucht, diese auf die gewünschte Art aufbereiten. Sie ist eine
Methode zur Kommunikation, bei dem eine Änderung die grundlegende
Einheit der Information ist.
Dieser Abschnitt behandelt nicht alle Aspekte der Bedienung
einer Versionsverwaltung. Dieses Thema ist derart umfassend, dass es im
Verlaufe des Buchs immer wieder angesprochen werden muss. Hier werden
wir uns darauf konzentrieren ein Versionsverwaltung auszuwählen und
einzurichten, die später die gemeinschaftliche Entwicklung
unterstützt.
Vokabular der Versionsverwaltung
Dieses Buch kann Ihnen die Bedienung einer Versionsverwaltung
nicht beibringen ohne vorherige Erfahrung, es wäre aber unmöglich das
Thema zu behandeln, ohne ein paar Begriffe zu klären. Diese sind
unabhängig von der eingesetzten Versionsverwaltung: Sie sind die
grundsätzlichen Nomen und Verben der gemeinsamen Arbeit im Netzwerk
und sie werden immer wieder im Verlaufe des Buches aufkommen. Selbst
wenn es keine Versionsverwaltung gäbe, bestünde das Problem der
Verwaltung von Änderungen und diese Wörter geben uns eine Sprache um
präzise und prägnant über das Problem zu reden.
Commit
Eine Änderung an dem Projekt vornehmen; formeller
gesagt, eine Änderung in die Versionsverwaltung zu speichern, sodass
es in zukünftige Versionen des Projekts eingebunden werden kann.
"Commit" (de. festlegen) kann als Nomen oder als Verb benutzt werden.
Als Nomen ist es im wesentlichen ein Synonym für Änderung. Beispiel:
"Ich habe eben einen Bugfix der bei Nutzern von Max OS X, Abstürze
ihrer Server verursacht hat committed, Jay könntest du dir bitte den
Commit anschauen und überprüfen, dass ich dort mit der Speicher
Zuweisung nicht falsch umgehe?"
Commit-Log
Ein Kommentar der an jedem Commit angehängt wird,
mit einer Beschreibung über die Änderung und sein Nutzen.
Commit-Kommentare sind mitunter die wichtigsten Dokumente in einem
Projekt: Sie sind die Brücke zwischen der äußerst technischen
Sprache der einzelnen Änderungen am Code und der eher Nutzer
orientierten Sprache der Funktionen, Bugfixes und dem
Projektfortschritt. Später in diesem Abschnitt werden wir uns
Möglichkeiten anschauen, Commit-Logs für das entsprechend
angemessene Publikum zu veröffentlichen; ebenso sind in
im
Kapitel Methoden
beschrieben, Beteiligte dazu anzuregen, kurze prägnante und nützliche
Commit-Kommentare zu schreiben.
Update
Eine Anfrage die Änderungen (Commits) anderer
Teilnehmer in die eigenen lokalen Kopie des Projekts einzubinden;
bzw. Ihre Kopie zu aktualisieren. Dies ist ein sehr häufiger
Vorgang; die meisten Entwickler aktualisieren ihren Code mehrmals
am Tag um sicherzustellen, dass sie ungefähr das Gleiche benutzen,
wie die anderen Entwickler und beim Auffinden eines Fehlers sicher
sein zu können, dass er noch nicht behoben wurde. z.B.: "Hallo, ich
habe bemerkt, dass der Code für die Indexierung immer das letzte
Byte fallen lässt. Ist das ein neuer Bug?". "Ja, aber er wurde letzte
Woche behoben – versuch mal ein Update zu machen, dann sollte
er verschwinden."
Projektarchiv (engl. Repository)
Die Datenbank der Versionsverwaltung in der
Änderungen gespeichert werden. Manche Systeme sind zentralisiert: Es
gibt ein Projektarchiv, in dem alle Änderungen am Projekt gespeichert
werden. Andere sind dezentralisiert: dort hat jeder Entwickler sein
eigenes Projektarchiv, und Änderungen können beliebig hin und her
getauscht werden. Die Versionsverwaltung verfolgt die Abhängigkeiten
zwischen den Änderungen und wenn es Zeit wird, eine neue Version zu
herauszugeben, bekommt ein bestimmter Satz von Änderungen den Zuspruch als
neue Version. Die Frage welche der beiden besser ist, ist ein weiterer
der andauernden heiligen Kriege der Softwareentwicklung; versuchen
Sie nicht in die Falle zu tappen, auf Ihrer Mailingliste darüber zu
streiten.
Checkout
Sich eine Kopie des Projekts aus dem Projektarchiv zu
beschaffen. Ein Checkout produziert meistens eine Verzeichnisstruktur,
auch als Arbeitsverzeichnis (siehe unten) bekannt, von dem aus
Änderungen wieder zurück ins Projektarchiv übertragen werden können.
Bei manchen dezentralisierten Versionsverwaltungen ist jedes
Arbeitsverzeichnis selbst ein eigenes Projektarchiv, von dem
aus Änderungen an jedes Projektarchiv hoch- oder heruntergeladen werden
können, das sie annehmen möchte.
Arbeitkopieengl. "working
copy"
Der private Verzeichnisbaum eines Entwicklers,
mit dem Quellcode des Projekts und möglicherweise seine Webseite
oder andere Dokumente. Eine Arbeitskopie enthält auch ein paar
Metadaten, die von der Versionsverwaltung benutzt werden um zu
Kennzeichen, von welchem Projektarchiv sie kommt, welche "Revision"
(siehe unten) der Dateien vorliegen, usw. Im allgemeinen hat jeder
Entwickler seine eigenes Arbeitskopie, indem er seine
Änderungen macht, prüft und anschließend als Commit an das
Projektarchiv schickt.
Revision im engl. auch
change oder
changeset (de. Satz von
Änderungen)
Eine "Revision" ist für gewöhnlich eine bestimmte
Version einer Datei oder einem Verzeichnis. Wenn das Projekt z.B.
mit der Revision 6 der Datei D anfängt und dann jemand eine Änderung
an D committed, entsteht die Revision 7 von D. Manche Systeme
benutzen "Revision" auch als Bezeichnung für einen ganzen Satz an
Änderungen die zusammen als Einheit committed wurden.
Diese Begriffe haben ab und zu eine Bestimmte technische
Bedeutung abhängig von der Versionsverwaltung, im Allgemeinen ist
die Idee jedoch immer die gleiche: Sie ermöglichen es genau über
bestimmte Zeitpunkte in der Geschichte einer Datei zu reden (wie,
direkt vor und nachdem ein Fehler behoben wurde). Beispielsweise:
"Ja, sie hat das in Revision 10 behoben" oder "Sie hat das in
Revision 10 von foo.c behoben."
Wenn man von einer Datei oder einer Sammlung von Dateien
spricht ohne eine bestimmte Revision anzugeben, geht man im
Allgemeinen von der aktuellsten Revision aus.
"Version" kontra "Revision"
Das Wort Version wird manchmal als
Synonym für "Revision" benutzt, ich werde es jedoch in diesem Buch
nicht auf diese Art verwenden da es zu leicht mit "Version" im
Sinne einer bestimmten Version einer Software – also eine
Veröffentlichung, mit einer Versionsnummer wie "Version 1.0", zu
verwechseln ist . Da der Begriff Versionsverwaltung bereits geläufig
ist, werden ich diesen trotzdem weiterhin verwenden.
Diffkurz für
difference(de.
Unterschied) Eine textuelle
Representation einer Änderung. Ein Diff zeigt wie und welche Zeilen
geändert wurden, sowie ein paar zusätzliche Zeilen um einen Kontext zu
geben. Ein Entwickler der bereits ein wenig mit dem Code vertraut ist,
kann für gewöhnlich ein Diff lesen und verstehen was die Änderung
gemacht hat und sogar Fehler bemerken.
Tagde.
Etikett
Eine Beschriftung einer bestimmen Menge an Dateien
ganz bestimmter Revisionen. Tags werden üblicherweise benutzt um
interessante Revisionen des Projekts zu bewahren. Für jede neue
veröffentlichte Version wird z.B. ein neuer "Tag" erstellt, um später
genau dieselben Dateien/Revisionen aus der Versionsverwaltung
herunterladen zu können. Häufige "Tag" Bezeichnungen sind
Version_X_Y,
Auslieferung_00456, usw.
Branchde.
Zweig/AstEine
Kopie des Projekts in der Versionsverwaltung, die aber vom Hauptzweig
isoliert ist, damit Änderungen nicht das Übrige Projekt beeinflussen
und umgekehrt, außer wenn Änderungen absichtlich von einer Seite zur
Anderen portiert werden (siehe unten). Ein Branch kann man auch als
Entwicklungszweig bezeichnen. Selbst wenn ein Projekt nicht explizit
irgendwelche Zweige hat, gibt es dennoch einen sogenannten
"Hauptzweig"engl. "main branch" auch "main line" oder
"trunk" de. "Stamm"als den
Zweig auf dem die Entwicklung stattfindet.
Zweige bieten bei der Entwicklung, die Möglichkeit verschiedene
Richtungen getrennt zu verfolgen. Ein Zweig kann z.B. für
experimentelle Entwicklung benutzt werden, die für den Hauptzweig
nicht stabil genug wären. Umgekehrt kann ein Zweig auch als Ort
benutzt werden um eine neue Version zu stabil zu bekommen. Während der
Entwicklung kann die reguläre Entwicklung im Hauptzweig ohne
Unterbrechung weiterlaufen; währenddessen werden auf dem Zweig der
neuen Version keine Änderungen mehr zugelassen, außer sie werden von
einem Versionsverwalter genehmigt. Auf diese Art, muss eine neue
Version die laufende Entwicklung nicht stören. Siehe
später in diesem
Kapitel für eine detailliertere Erörterung über
Zweige.
Mergeim engl. auch "port" de.
Zusammenführung/Portierung
Eine Änderung von einem Zweig in ein Anders
übernehmen. Was auch portieren von Änderungen aus dem Hauptzweig in
einem anderen Zweig oder umgekehrt bedeuten kann. Tatsächlich ist
das sogar die häufigste Art zu mergen; man portiert selten eine
Änderung zwischen zwei Zweige, die nicht beide Hauptzweige sind.
Siehe für mehr zu dieser Art zu
portieren.
"Merge" hat eine zweite, verwandte Bedeutung: Die
Versionsverwaltung macht einen Merge, wenn zwei Leute die gleiche
Datei bearbeitet haben, sodass die Änderungen sich nicht überlappen.
Da die Änderungen nicht miteinander kollidieren, werden die
Änderungen in die eigenen Kopie (mit eigenen Änderungen) übertragen,
bzw. die Kopie wird aktualisiert. Das kommt sehr häufig vor,
besonders in Projekten bei dem mehrere Entwickler am gleichen Code
arbeiten. Wenn zwei verschiedene Änderungen doch
überlappen, gibt es einen "Konflikt"; siehe unten.
Konflikt
Was geschieht wenn zwei Personen gleichzeitig
unterschiedliche Änderungen vornehmen, an der gleichen Stelle im Code.
Jede Versionsverwaltung erkennt Konflikte automatisch, und
benachrichtigt mindestens einen der Beteiligten, dass ihre
Änderungen mit denen von anderen kollidieren. Der Konflikt muss
dann von einem Menschen bereinigt (engl. resolve)
und an die Versionsverwaltung übermittelt werden.
Lock
(de. Schloss/Sperre) Eine Möglichkeit eine exklusive
Absicht auf eine Datei oder ein Verzeichnis zu erklären. z.B.: "Ich
kann gerade keine Änderungen an der Webseite machen. Es scheint das
Alfred alles gesperrt hat während er die Hintergrundbilder
korrigiert". Nicht jede Versionsverwaltung bieten überhaupt die
Möglichkeit Dateien zu sperren, und solche die es tun erfordern
nicht alle, dass sie auch benutzt wird. Das liegt daran, dass
parallele, gleichzeitige Entwicklung der Normalfall ist und Sperren
auf Dateien, diesem Ideal (üblicherweise) widersprechen.
Eine Versionsverwaltung die einen Lock erfordert um einen
Commit zu machen, benutzt das sogenannte
lock-modify-unlock Verfahren. Solche die es
nicht erfordern, nutzen das copy-modify-merge
Verfahren. Eine ausgezeichnete tiefgehende Erklärung und Vergleich
der beiden Methoden ist auf
zu finden. Im allgemeinen ist die copy-modify-merge Methode besser
für die Open-Source-Entwicklung und jede Versionsverwaltung in
diesem Buch unterstützen sie.
Wahl einer Versionsverwaltung
Zum Zeitpunkt dieses Schreibens sind die beiden verbreitetsten
Systeme für Versionsverwaltung in der Welt der freien Software das
Concurrent Versions System oder auch
CVS ()
und Subversion (SVN,
).
CVS gibt es schon lange. Die meisten erfahrenen Entwickler sind
bereits damit vertraut, es erledigt die Aufgabe mehr oder weniger gut
und da es die Norm ist, werden Sie keine lange Debatten darüber führen
müssen, ob es die richtige Wahl war. CVS hat jedoch einige Nachteile.
Es bietet keine einfache Möglichkeit an, Änderungen über mehrere
Dateien abzufragen; es erlaubt nicht, Dateien im Projektarchiv
umzubenennen oder zu kopieren (was besonders nervt, wenn Sie Ihren Code
neu organisieren wollen, nachdem Sie das Projekt gestartet haben); es
bietet nur dürftige Merge-Unterstützung; es kann nicht sonderlich
gut mit großen oder binären Dateien umgehen; und manche Vorgänge sind
bei vielen Dateien sehr langsam.
Kein Fehler von CVS ist fatal und es ist immer noch ziemlich
beliebt. In den vergangenen Jahren hat das neuere Subversion an Boden
gewonnen, inbesondere bei neuen Projekten.Siehe
und
für beweise für dieses Wachstum.. Wenn Sie ein neues
Projekt anfangen, empfehle ich Ihnen Subversion.
Da ich andererseits selbst an dem Subversion-Projekt arbeite,
könnte man meine Objektivität berechtigt in Frage stellen. In den
letzden Jahren sind ein paar neue Versionsverwaltungssysteme
erschienen. listet alle mir bekannten
auf. Wie diese Liste klar macht kann die Entscheidung für eine
Versionsverwaltung zu einem lebenslangen Forschungsprojekt werden.
Möglicherweise wird Ihnen die Entscheidung erspart bleiben weil sie
von Ihrer Hosting-Seite bereits getroffen wurde. Wenn Sie sich aber
für eines entscheiden müssen, fragen Sie andere Entwickler, finden
Sie heraus womit Andere bereits Erfahrung haben, suchen Sie sich
eines aus und bleiben Sie dabei. Jede stabile, ausgereifte
Versionsverwaltung reicht aus; Sie müssen sich keine Sorgen darüber
machen, dass Sie eine furchtbar schlechte Entscheidung treffen werden.
Wenn Sie sich einfach nicht entscheiden können, dann nehmen Sie CVS.
Es ist immer noch die Norm und wird es auch wahrscheinlich ein paar
Jahre lang bleiben. Viele andere Systeme unterstützen auch die
Konvertierung in eine Richtung von einem CVS Archiv, Sie können sich
also später auch umentscheiden.
Nutzung einer Versionsverwaltung
Die Empfehlungen in diesem Abschnitt sind nicht auf eine
bestimmte Versionsverwaltung abgestimmt und sollten in allen Systemen
einfach zu implementieren sein. Für weitere Details, schlagen Sie in
der Dokumentation Ihrer Versionsverwaltung nach.
Versioniere alles
Benutzen Sie die Versionsverwaltung nicht nur für den Quellcode
Ihres Projekts, sondern auch die Webseite, Dokumentation, FAQ,
Entwurfsskizen und alles andere, was jemand vielleicht bearbeiten
möchte. Behalten Sie alles direkt neben dem Quellcode, im selben
Projektarchiv. Jede Information, die sich lohnt niederzuschreiben, ist es
auch Wert im Projektarchiv zu sein – also jede Information die
sich ändern könnte. Sachen die sich nicht ändern, sollten archiviert
und nicht versioniert werden. Eine E-Mail ändert sich beispielsweise
nicht, wenn sie einmal abgeschickt wurde; deshalb würde es keinen
Sinn machen sie zu versionieren (es sei denn sie wird zu einem Teil
eines größeren, sich entwickelnden Dokuments).
Der Grund warum es wichtig ist alles an einem Ort zu
versionieren ist, dass Personen nur eine Methode lernen müssen um
Änderungen einzureichen. Oftmals, wird ein Beteiligter damit anfangen
Änderungen an der Webseite oder der Dokumentation zu machen, und gehen
später dazu über kleine Beiträge am Quellcode zu machen. Wenn das
Projekt dasselbe System für alle Beiträge verwendet, müssen Beteiligte
nur eine Methode lernen. Alles zusammen zu versionieren, bedeutet
auch, dass neue Funktionen gleich zusammen mit ihrer zugehörigen
Aktualisierungen an der Doku eingereicht werden können, sodass ein
Zweig für den Code auch ein Zweig für die Doku mit sich bringt,
usw.
Behalten Sie keine generierte Dateien im
Projektarchiv. Sie sind nicht wirklich bearbeitbare Daten, da sie aus
anderen Daten erzeugt werden. Manche Build-Systeme erzeugen
beispielsweise configure aus der Vorlage
configure.in. Um eine Änderung an
configure vorzunehmen, würde man
configure.in bearbeiten und es daraus neu
erzeugen lassen; weßhalb lediglich die Vorlage
configure.in "bearbeitbar" ist. Versionieren Sie
lediglich die Vorlage – wenn Sie die erzeugten Dateien auch
versionieren, wird man zwangsläufig vergessen sie neu zu erzeugen
nachdem man eine Änderung an einer Vorlagen eingespielt hat. Die
daraus resultierende Inkonsistenz wird endlose Verwirrung
stiften.Eine andere Meinung im Bezug auf die
Versionierung von configure Dateien, kann man in
"configure.in and version control" bei
von Alexey Makhotkin nachlesen.
Zu der Regel, dass alle bearbeitbare Dateien im Projektarchiv
sein sollten, gibt es eine Ausnahme: den Bugtracker. Eine
Bug-Datenbank enthält eine Menge bearbeitbarer Daten, kann aber aus
technischen Gründen diese Daten im allgemeinen nicht im Projektarchiv
speichern. (Manche Tracker haben eigene primitive Funktionen zur
Versionierung, die allerdings von der Versionsverwaltung des Projekts
getrennt ist.)
Zugang per Browser
Das Projektarchiv eines Projekts sollte per Browser erreichbar sein.
Das bedeutet nicht nur die neuste Version der
einzelnen Dateien einsehen zu können, sondern auch in der Zeit zurück
zu gehen und frühere Revisionen der Dateien zu sehen, die Unterschiede
zwischen den verschiedenen Versionen der Dateien sehen zu können, die
commit-logs bestimmter Änderungen lesen zu können, usw.
Der Browser-Zugang ist wichtig, denn er bietet ein
leichtgewichtiges Portal zu den Projekt-Daten. Ist der Zugriff
per Browser nicht möglich, dann würde jemand, nur um
eine bestimmte Datei zu untersuchen (sagen wir, um nachzuschauen
ob ein bestimmter Bugfix es in den Code geschafft hat), zuerst
lokal eine Versionsverwaltungs-Software installieren müssen, was eine
einfache zweiminutige Anfrage zu einer halbstündigen Aufgabe macht.
Der Browser-Zugang erlaubt auch normale URLs auf bestimmte Revisionen
von Dateien oder die jeweils aktuellste Revisionen. Das
kann bei technischen Diskussionen sehr nützlich sein, oder falls man jemanden
auf die Dokumentation verweisen will. Man könnte zum Beispiel anstatt
"Eine ausführliche Anleitungen zum Fehlermanagement enthält die Datei
community-guide/index.html deiner lokalen Arbeitskopie." folgendes schreiben:
"Eine ausführliche Anleitungen zum Fehlermanagement kannst du unter
http://subversion.apache.org/docs/community-guide/
nachlesen.", wobei die URL auf die aktuelle Version der Datei zeigt.
Die URL ist überlegen: sie ist eindeutig und erübrigt die Frage,
ob der Angesprochene wirklich eine aktuelle Arbeitskopie verwendet.
Manche Versionsverwaltungssysteme haben eine eingebaute Funktion
um das Projektarchiv online zu durchsuchen, andere verlassen sich hierfür
auf zusätzliche Software. Drei Beispiele hierfür sind
ViewCVS
(),
CVSWeb
(), und
WebSVN
(). Ersteres funktioniert
sowohl mit CVS als auch Subversion, das Zweite nur mit CVS und
Letzteres nur mit Subversion.
Commit-E-Mails
Jeder Commit an das Projektarchiv sollte eine E-Mail erzeugen, die
zeigt, wer den Commit gemacht hat, wann er gemacht wurde, welche
Dateien und Verzeichnisse sich geändert haben und was sich an ihnen
geändert hat. Die E-Mail sollte auf eine bestimmte Mailingliste gehen,
eine andere als die Liste der Entwickler. Diese und andere
interessierte Beteiligte sollten ermutigt werden, sich auf der Commit-Liste
anzumelden, da es die effektivste Art ist sich über die
Ereignisse auf Code-Ebene des Projekts auf dem Laufenden zu halten.
Abgesehen von den offensichtlichen technischen Vorteilen der
Überprüfung durch andere Entwickler (siehe
), können die Commit E-Mails dazu
beitragen eine Gemeinschaft aufzubauen, da sie eine gemeinsame
Umgebung schaffen indem Personen auf Ereignisse (Commits) reagieren
können von denen sie wissen das Andere sie auch wahrnehmen.
Wie man Commit E-Mails einrichtet, hängt von Ihrer
Versionsverwaltung ab, meistens gibt es aber hierfür einen Script oder
eine andere Einrichtung bei ihrer Software. Wenn Sie Schwierigkeiten
bekommen es zu finden, schlagen Sie in Ihrer Dokumentation den Begriff
hooks, insbesondere auch
post-commit hook nach, bei CVS auch
loginfo hook genannt. Diese Commit-Hooks sind
eine allgemeine Möglichkeit, Befehle nach jedem Commit zu schalten.
Der Hook wird von einem Commit ausgelöst, ihm werden alle
Informationen über den Commit übergeben, mit denen er dann vordefinierte
Aufgaben ausführen kann, wie z.B. eine E-Mail abschicken.
Bei fertig eingerichteten Systemen für Commit E-Mails werden
Sie möglicherweise das übliche Verhalten ändern wollen:
Manchmal beinhalten die Commit E-Mails nicht die tatsächlichen
Diffs und geben stattdessen eine URL an, bei dem man die Änderungen
über das Web-Portal des Projektarchivs einsehen kann. Obwohl es gut ist
eine URL anzugeben, auf der man später verweisen kann, ist es auch
sehr wichtig, dass die Diffs in den
Nachrichten enthalten sind. E-Mails zu lesen gehört schon zum
Alltag der Leute, wenn also die Änderungen gleich in der E-Mail zu
lesen sind, werden Entwickler sie auf der Stelle untersuchen, ohne
ihre E-Mail-Anwendung verlassen zu müssen. Wenn sie erst auf eine
URL klicken müssen werden es die Meisten bleiben lassen, da es eine
weitere Aktion erfordert anstatt fortzusetzen was sie bereits
angefangen hatten. Desweiteren geht es bei Fragen über die Änderung
viel schneller einfach auf die E-Mail zu antworten und eine
Bemerkung an entsprechender Stelle zu schreiben als eine Webseite
zu besuchen und mühselig den Diff aus dem Webbrowser heraus in die
E-Mail zu kopieren.
(Wenn der Diff natürlich riesig ist, wie z.B. wenn eine große
Menge neuer Code im Projektarchiv eingefügt wurde, macht es
natürlich Sinn den Diff wegzulassen und nur die URL anzubieten. Die
meisten Systeme für Commit E-Mails können diese Art der Verkürzung
automatisch. Wenn Ihres es nicht kann, ist es immer noch besser, die
Diffs mitzuschicken und gelegentlich mit riesigen E-Mails zu leben,
als die Diffs komplett auszuschalten. Bequeme Möglichkeiten zur
Überprüfung und Bewertung sind ein Eckstein der gemeinschaftlichen
Entwicklung und deshalb unerlässlich.)
Der Reply-to-Header der Commit-E-Mails sollte auf
die Mailingliste der Entwickler eingestellt sein, nicht auf die
Commit-Liste. Wenn also jemand eine Commit-E-Mail durchgelesen und
bewertet hat und daraufhin eine Antwort schreibt, sollte die Antwort
an die Liste der Entwickler gehen auf dem technische
Angelegenheiten üblicherweise stattfinden. Es gibt hierfür ein paar
Gründe. Erstens wollen Sie alle technischen Diskussionen auf einer
Liste behalten, Leute erwarten nämlich, dass sie dort gehalten
werden und so auch nur ein Archiv durchsucht werden muss. Zweitens
könnte es interessierte Parteien geben, die nicht bei der Commit-Liste
angemeldet sind. Drittens wird die Commit-Liste als
Dienst verstanden um Commits zu verfolgen und nicht um Commits zu
verfolgen und gelegentlich auch technische
Diskussionen zu führen. Wer sich auf den Commit-Liste angemeldet hat,
will nichts anderes als Commit-E-Mails; wenn Ihnen also anderes
Material über diese Liste zugesandt wird, bricht das ein
ungesprochenes Übereinkommen. Viertens schreiben Beteiligte oft
Programme um die Commit-E-Mails zu lesen und zu verarbeiten (z.B. um
sie auf einer Webseite anzuzeigen). Diese Programme sind auf eine
konsistente Formatierung ausgelegt, nicht jedoch auf inkonsistente
von Menschen geschriebene E-Mails.
Beachten Sie dass dieser Ratschlag, Reply-to umzuschreiben
nicht den Empfehlungen aus
in einem früheren Abschnitt dieses Kapitels
widerspricht. Es ist immer in Ordnung, wenn der
Absender einer Nachricht Reply-to setzt. In
diesem Fall ist der Absender die Versionsverwaltungs selber und es
setzt Reply-to um anzudeuten, dass der angemessene Ort für Antworten
die Entwickler-Liste ist und nicht die Commit-Liste.
CIA: Eine weitere Möglichkeit für Commit-Benachrichtigungen
Commit E-Mails sind nicht die einzige Möglichkeit um Nachrichten
über Änderungen zu verbreiten. Vor kurzem wurde eine weitere
Möglichkeit namens CIA ()
entwickelt. CIA fasst Commit-Statistiken zusammen und verbreitet sie
in Echtzeit. Die verbreitetste Verwendung von CIA ist Commit
Benachrichtigungen an IRC-Kanäle zu senden, damit die Leute dort in
Echtzeit mitbekommen, wann Änderungen gemacht werden. Obwohl diese
Methode nicht ganz so nützlich ist wie Commit E-Mails, da Beteiligte
unter Umständen nicht während einem Commit im IRC anwesend sind, hat
diese Methode trotzdem einen immensen sozialen
Wert. Leute bekommen das Gefühl ein Teil von etwas lebendigem und
aktivem zu sein und der Fortschritt vor ihren Augen
geschieht.
Es funktioniert indem Sie die CIA Anwendung automatisch nach
jedem Commit aufrufen. Es formatiert die Information über den Commit
in eine XML Nachricht, und sendet es an einen zentralen Server
(typischerweise cia.navi.cx). Der Commit-Server
verteilt diese Information dann an andere Foren.
CIA kann auch konfiguriert werden um einen
RSS
feed zu erzeugen. Weiteres dazu können Sie in der Dokumentation bei
nachlesen.
Sie können sich von CIA einen Eindruck verschaffen, indem Sie
sich mit Ihrem IRC-Client bei #commits auf dem
Server irc.freenode.net einloggen.
Benutze Zweige, um Engpässe zu vermeiden
Laien im Umgang mit Versionsverwaltung scheuen sich manchmal
vorm Verzweigen und Zusammenführen. Das ist wahrscheinlich ein
Nebeneffekt des Erfolgs von CVS: Die Schnittstellen von CVS um Zweige
zu machen und wieder zusammenzuführen sind nicht ganz eingängig,
weshalb viele sich angeeignet haben diese Operationen komplett zu
vermeiden.
Wenn Sie zu diesen Leuten gehören, nehmen Sie sich vor alle
Ängste die Sie haben mögen zu besiegen und nehmen Sie sich die Zeit
um zu lernen, wie man Zweige macht und wieder zusammenführt. Es sind
keine schwierigen Vorgänge, wenn man sich erst einmal daran gewöhnt
hat und sie werden mit der Zeit immer wichtiger, sowie ein Projekt
immer mehr Entwickler aufnimmt.
Zweige sind wichtig da sie eine knappe Ressource – den Platz
im Code des Projekts – im Überfluss bereitstellt. Normalerweise
arbeiten alle Entwickler im gleichen Sandkasten und bauen an der
gleichen Burg. Wenn jemand eine neue Zugbrücke anbauen will, jedoch
nicht alle überzeugen kann, dass es eine Verbesserung wäre, ermöglicht
ein Zweig mit ihr in einer eigenen isolierte Ecke zu experimentieren.
Wenn es funktioniert kann sie die anderen Entwickler einladen, sich
das Ergebnis anzuschauen. Wenn alle zustimmen, dass das Ergebnis gut
ist können sie mittels der Versionsverwaltung die Zugbrücke aus dem
Burgflügel in die Haupt-Burg übernehmen (einen "Merge" machen).
Es ist einfach zu erkennen, wie diese Fähigkeit die
gemeinschaftliche Entwicklung fördert. Menschen brauchen die Freiheit
Neues auszuprobieren ohne das Gefühl zu bekommen andere bei der Arbeit
zu stören. Gleichermaßen gibt es Zeiten an denen es wichtig ist,
bestimmten Code von der alltäglichen Entwicklung zu isolieren, um
einen Fehler zu beheben oder eine neue Version stabil zu machen (siehe
und
im Kapitel
) ohne sich über ein
bewegliches Ziel Gedanken zu machen.
Seien Sie großzügig bei der Nutzung von Zweigen und ermutigen Sie
andere, ebenso zu verfahren.
Achten Sie aber auch darauf, dass jeder Zweig nur so lange
aktiv bleibt wie nötig. Jeder aktive Zweig beansprucht die Aufmerksamkeit
der Gemeinschaft ein klein wenig. Selbst diejenigen die nicht an
einem Zweig arbeiten, behalten noch einen groben Überblick über die
Ereignisse darin. Diese Aufmerksamkeit ist natürlich wünschenswert
und Commit-Nachrichten sollten auch für Zweige eingeschaltet sein,
genau wie für jeden anderen Commit. Zweige sollten jedoch nicht zu
einer Methode werden, die Gemeinschaft zu spalten. Mit seltenen
Ausnahmen sollte jeder Zweig das Ziel haben, irgendwann wieder zurück
in den Hauptzweig überzugehen und zu verschwinden.
Eindeutigkeit von Informationen
Merges haben eine wichtige Konsequenz: Dieselbe Änderung
sollte niemals doppelt committet werden. D.h. eine bestimmte Änderung
sollte durch das Versionsverwaltungssystem nur genau einmal übernommen
werden. Die Revision (oder die Gruppe von Revisionen) in dem diese
Änderung eingebracht wurde, ist von da an seine eindeutige Kennung.
Wenn sie auf weitere Zweige angewendet werden soll, sollte sie von ihrem
ursprünglichen Eintrittspunkt aus in diese anderen Ziele portiert
werden – man sollte also nicht mehrere textgleiche Änderungen
committen, was zwar die gleiche Wirkung auf den Code haben würde,
aber eine genaue Buchführung unmöglich machen würden.
Die praktische Auswirkung dieser Empfehlung sind unterschiedlich,
je nach Versionsverwaltungssystem. Manche Systeme erfassen einen Merge
als besonderes Ereignis, grundsätzlich unterschiedlich zu einem normalen
Commit, mit eigenen Metadaten. Bei anderen wird das Ergebnis eines Merges
genau wie jeder andere Commit übernommen, in solchen Fällen sollte man
dafür sorgen, dass sich ein "Merge-Commit" im Commit-Log klar von einem
"Änderungs-Commit" unterscheidet. In dem Commit-Log von einem Merge
sollte nicht die Nachricht der ursprünglichen Änderung wiederholt
werden. Stattdessen sollten Sie lediglich angeben, dass es sich um
einen Merge handelt, und die Revisionsnummer der Ursprünglichen
Änderung angeben und höchstens einen Satz, um die Auswirkungen der
Änderung zusammenzufassen. Wenn jemand den kompletten Commit-Log sehen
will, kann er die ursprünglichen Revisionen aufsuchen.
Es ist wichtig zu vermeiden, die Commit-Logs zu wiederholen, da
Log-Nachrichten manchmal nach dem Commit geändert werden. Wenn die Log-
Nachricht einer Änderung bei jedem Merge wiederholt würde, blieben
selbst bei einer Korrektur der ursprünglichen Nachricht alle Kopien
unverändert – was später unweigerlich zu Verwirrung führen
kann.
Dasselbe Prinzip gilt beim Rückgängigmachen einer Änderung. Wenn
eine Änderung wieder vom Code entfernt wird, sollte sein Commit-Log
lediglich festhalten, dass die Änderung einer bestimmten Revision
rückgängig gemacht wird und nicht eine
Beschreibung der tatsächlichen Änderungen am Code, da diese
Information aus der ursprünglichen Änderungen und sein Log ersichtlich
ist. Selbstverständlich sollte der Log auch den Grund für die
Entfernung nennen, jedoch nichts aus dem ursprünglichen Log
wiederholen. Wenn möglich gehen Sie zurück und Ändern Sie den Log der
ursprünglichen Änderung und weisen Sie darauf hin, dass sie
zurückgedreht wurde.
Die vorhergehenden Passagen implizieren die Verwendenung einer
konsistenten und gleichbleibende Syntax um auf Revisionen Bezug zu
nehmen. Das ist nicht nur in den Logs hilfreich, sondern auch in
E-Mails, dem Bugtracker und anderswo. Wenn Sie CVS verwenden, schlage
ich "path/to/file/in/project/tree:REV" als Format
vor, wobei REV eine CVS Revisionsnummer wie "1.76" darstellt. Wenn Sie
Subversion verwenden, ist die übliche Syntax für die Revision 1729
"r1729" (Datei-Pfade sind bei Subversion nicht nötig, da es globale
Revisionsnummern verwendet). Andere Systemen haben meistens ihre
eigene übliche Syntax um Änderungen zu kenzeichnen. Konsistente
Bezeichnungen erleichtern die Buchhaltung eines Projekts ungemein (was
wir in und
) sehen werden und da ein großer
Teil der Buchhaltung von Freiwilligen erledigt wird, muss es so
einfach wie Möglich sein.
Siehe auch
im Kapitel .
Autorisierung
Die meistene Versionsverwaltungen bieten Funktionen, um
bestimmten Personen Schreibzugriff auf einzelne Bereiche des Projektarchivs
zu erlauben oder zu verwehren. Nach dem Grundsatz, dass jemand, sobald man ihm
einen Hammer in die Hand gibt, anfangen wird, überall Nägel zu sehen, wird
diese Funktion von vielen Projekten benutzt, um den Beteiligten lediglich
Schreibzugriff auf Bereiche zu geben mit denen sie sich offensichtlich auskennen
und so sichergestellt ist, dass sie nirgendwo sonst Schreibzugriff haben. (Siehe
im Kapitel
indem beschrieben ist,
wie Projekte entscheiden wer wo Änderungen machen kann.)
Mit einer solch scharfen Kontrolle können Sie wahrscheinlich kaum
Schaden anrichten, eine lockerere Haltung ist aber auch in Ordnung.
Manche Projekte benutzen einfach ein Vertrauenssystem: Wenn
einer Person Commit-Zugriff gewährt wird, wenn auch nur für einen
Teilbereich des Projektarchivs, erhält diese in Wirklichkeit den Schlüssel,
um überall im Projekt zu Änderungen vorzunehmen. Sie wird einfach
darum gebeten, sich auf ihren Bereich zu beschränken. Denken Sie daran,
dass hierin keine echte Gefahr besteht: In einem aktiven Projekt
wird sowieso jeder Commit überprüft. Wenn jemand in einem Bereich etwas
ändert, in dem er nichts zu suchen hat, werden es andere bemerken und etwas sagen.
Wenn eine Änderung rückgängig gemacht werden muss, ist das auch kein
Problem – es ist sowieso alles in der Versionsverwaltung, also kann man
es einfach rückgängig machen.
Die Sache locker anzugehen hat mehrere Vorteile. Erstens gibt es
keinen weiteren Aufwand um Entwickler zusätzliche Rechte einzuräumen,
sobald sie sich auf andere Bereiche ausweiten (was meistens irgendwann
passiert, wenn sie länger beim Projekt bleiben). Sobald die
Entscheidung getroffen wurde, kann die Person gleich anfangen
Änderungen im neuen Bereich zu machen.
Zweitens kann die Erweiterung viel feiner granuliert werden.
Allgemein wird ein Commit-Berechtigter im Bereich X der auch im Bereich
Y arbeiten will, anfangen Patches für Y einzureichen und darum bitten,
dass sie überprüft werden. Wenn jemand der bereits Zugriff auf dem
Bereich Y hat solch einen Patch sieht und ihm zustimmt, können sie dem
Autor einfach sagen, dass sie die Änderung gleich selber einspielen
können(natürlich mit Namensangabe vom Überprüfenden bzw, Zustimmenden
im Commit-Log). Auf diese Art stammt der Commit von dem, der ihn auch
geschrieben hat, was sowohl aus Sicht der Informationsverwaltung als
auch der Anerkennung vorzuziehen ist.
Schließlich, und das ist vielleicht das Wichtigste, regt ein System,
das auf Ehre basiert, eine Atmosphäre des Vertrauens und des gegenseitigen
Respekts an. Jemandem Commit-Zugriff auf einem Teilbereich zu geben, ist
eine Aussage über ihre fachliche Vorbereitung – es sagt: "Wir
sehen, dass du die Kenntnisse hast, um auf einem Gebiet Änderungen zu
machen, also leg los". Strikte Autorisierung aufzuerlegen, sagt aber:
"Wir behaupten nicht nur, dass deine Kenntnisse begrenzt sind, wir
sind auch ein wenig skeptisch im Bezug auf deine
Absichten". Das ist keine Behauptung, die Sie in
den Raum stellen wollen, wenn es sich vermeiden lässt. Jemanden an dem
Projekt als commit-berechtigt zu beteiligen, ist eine Gelegenheit, ihn
in einen Kreis vertrauter Personen aufzunehmen. Das erreicht man am
besten, indem man ihm mehr Macht gibt als er letztlich braucht, und ihn
darüber informiert, dass es an ihm ist, sich innerhalb der genannten
Grenzen zu bewegen.
Das Subversion-Projekt arbeitet schon seit vier Jahren nach dem
Ehren-Prinzip, mit 33 voll -und 43 teil-berechtigten Entwicklern zum
Zeitpunkt dieses Schreibens. Der einzige Unterschied, den das System
macht, ist zwischen Commit-Berechtigten und nicht Commit-Berechtigten;
weitere Unterteilungen bestehen allein auf zwischenmenschlicher Ebene.
Dennoch hatte man dort nie Probleme mit den Grenzen der Berechtigungen. Es
gab ein oder zwei Missverständnisse über das Ausmaß der
Commit-Berechtigungen, die jedoch immer schnell und freundlich gelöst
wurden.
Offensichtlich muss man sich auf strikte Autorisierung verlassen
können, wenn Selbstkontrolle nicht sinnvoll ist. Solche Situationen
sind jedoch selten. Selbst bei Unmengen Code und hunderten oder tausenden
Entwicklern, sollte ein Commit zu jedem beliebigen Modul von denen
zuständigen Personen überprüft werden, die auch erkennen können ob
jemand an eine Stelle etwas geändert hat die er nicht sollte. Wenn
Änderungen nicht regelmäßig überprüft werden,
dann hat das Projekt ohnehin größere Probleme als die
Commit-Berechtigung.
Insgesamt sollte man nicht allzuviel Zeit damit verbringen, die
Berechtigungen der Versionsverwaltung auszutüfteln, es sei denn Sie
haben einen ganz bestimmten Grund dazu. Es wird für meistens wenig
handfesten Nutzen bringen und es hat seine Vorteile sich stattdessen
auf menschliche Kontrolle zu verlassen.
Natürlich sollte man nichts hiervon so auffassen, dass die
Beschränkungen an und für sich unwichtig sind. Es wäre schlecht für
das Projekt, Teilnehmer anzuregen Bereiche zu ändern, für die sie
nicht qualifiziert sind. Desweiteren geben viele Projekte dem vollen
(uneingeschränkten) Zugriff auf das Projektarchiv einen besonderen
Status: Es impliziert, dass der Teilnehmer das Recht hat, über Fragen
die das ganze Projekt betreffen abzustimmen. Dieser politische
Aspekt der Commit-Berechtigung wird weiter in
im Kapitel
behandelt.
Bugtracker
Bugtracking ist ein weites Feld, von dem viele Aspekte im
Verlauf dieses Buchs besprochen werden. Ich werde versuchen, mich hier
auf Einrichtung und technische Erwägungen zu konzentrieren.
Zuvor müssen wir jedoch eine politische Frage stellen:
Welche Informationen sollen im Bugtracker gehalten werden?
Der Begriff Bugtracker ist irreführend.
Diese Systeme werden häufig auch verwendet, um Anfragen für neue
Funktionen, einmalige Aufgaben, unaufgeforderte Patches – im
Prinzip alles zu verfolgen (engl. to track), was einen eindeutigen
Anfangs- und Endzustand sowie optionale Übergangszuständen hat und
über dessen Lebenszyklus Informationen anfallen. Aus diesem Grund
haben Bugtracker auch häufig NamenIm Deutschen Raum
sind die Begriffe Bugtracker und
Ticket-System am weitesten
verbreitet. wie Issue
Tracker, Defect
Tracker, Artifact Tracker,
Request Tracker, Trouble Ticket
System, usw. Eine Liste verfügbarer Software finden Sie im
Anhang .
In diesem Buch werde ich weiterhin "Bugtracker" für Software
benutzen, die jegliche der vorher erwähnten Angelegenheiten verfolgt,
da es weithin so bezeichnet wird, ein einzelnes Element in der
Datenbank des Bugtracker werde ich jedoch als
Ticket (im engl. auch "issue") bezeichnen. So
können wir zwischen Verhalten oder Fehlverhalten unterscheiden, die ein
Nutzer beobachtet hat, (also einen Fehler) und die
Erfassung seiner Entdeckung, Diagnose und Lösung
im Tracker. Behalten Sie im Hinterkopf, dass auch wenn es bei den
meisten Tickets um Fehler handelt, sie auch benutzt werden können um
andere Aufgaben zu verfolgen.
Der klassische Verlauf eines Tickets sieht wie folgt aus:
Jemand reicht das Ticket ein. Sie machen eine
Zusammenfassung, eine anfängliche Beschreibung
(einschließlich dessen wie man den Fehler reproduziert, falls
anwendbar, siehe
im Kapitel
in der beschrieben wird, wie man gute Bug-Meldungen fördert
ermutigen kann), und sonstige Informationen. die der Tracker
verlangt. Die Person die den Fehler meldet, kann dem
Projekt völlig unbekannt sein – Bug-Meldungen und
Anfragen für Funktion können genau so aus der
Nutzer-Gemeinschaft kommen, wie von den Entwicklern.
Sobald das Ticket gemeldet wurde sagt man, dass es
offen ist. Da bisher nichts
unternommen wurde, kennzeichnen manche Tracker diese auch
als unbestätigt (engl. "unverified")
oder nicht angefangen (engl.
"unstarted"). Er wurde noch niemandem zugewiesen; oder,
in manchen Systemen, wird es einem fiktiven Benutzer
zugewiesen um anzudeuten, dass es nicht wirklich jemandem
zugewiesen wurde. Zu diesem Zeitpunkt steht es in einer
Warteschlange: Das Ticket wurde erfasst, ist jedoch nicht
im Bewusstsein des Projekts aufgenommen.
Andere lesen den Ticket, sie fügen Kommentare hinzu,
und bitten vielleicht dem Meldenden einige Punkte zu
klären.
Der Fehler wird reproduziert.
Dieser Augenblick mag der Wichtigste in seinem
Lebenszyklus sein. Auch wenn der Bug noch nicht behoben
wurde ist die Tatsache, dass jemand außer dem der ihn
gemeldet hat, es geschafft hat selbst den Fehler zu finden.
Dies beweist, dass der Bug valide ist und bestätigt nicht
zuletzt den Berichtenden, dass sie durch die Meldung
eines echten Fehlers etwas zum Projekt beigetragen
haben.
Der Fehler wird untersucht:
seine Ursache wird identifiziert und wenn möglich, wird
der nötige Aufwand geschätzt um ihn zu beheben. Stellen Sie
sicher, dass diese Sachen in dem Ticket erfasst werden;
wenn die Person die den Bug untersucht hat, plötzlich eine
längere Zeit vom Projekt wegtreten muss (was bei
freiwilligen Entwicklern häufig passieren kann), sollte
jemand anders in der Lage sein, seine Arbeit wieder
aufzunehmen.
In dieser Phase oder manchmal schon vorher, kann ein
Entwickler das Ticket in Besitz nehmen, und es sich
selber zuweisen (In
im Kapitel
wird der
diese Zuweisung genauer untersucht. Die
Priorität kann in dieser Phase auch
bestimmt werden. Wenn er z.B. derart schwerwiegend ist,
dass er die nächste Version verzögern würde, muss diese
Tatsache frühzeitig erkannt werden und der Tracker sollte
eine Möglichkeit bieten das zu erfassen.
Es wird geplant wann das Ticket aufgelöst werden
soll, wobei dabei nicht unbedingt ein bestimmtes Datum
gemeint ist an dem es behoben sein soll. Manchmal bedeutet
es einfach ein Entscheiden bis zu welcher Version (nicht
unbedingt die Nächste) der Bug behoben sein soll, oder
dass er keine bestimmte Version blockieren muss. Wenn der
Bug schnell behoben werden kann, ist die Planung
wahrscheinlich überflüssig.
Der Bug wird behoben (oder die Aufgabe wird erledigt,
oder der Patch angewandt, oder was auch immer). Die
Änderung die ihn beheben sollten in einem Kommentar des
Tickets protokolliert werden, worauf er
geschlossen wird und/oder als
gelöst markiert wird.
Dieser Lebenszyklus variiert häufig. Manchmal wird ein Ticket
frühzeitig nach seiner Meldung geschlossen, da sich herausstellt, dass
es sich nicht um einen Fehler handelt, sondern um ein Missverständnis
seitens des Anwenders. Sowie ein Projekt immer mehr Benutzer aufnimmt,
werden immer mehr dieser ungültigen Tickets aufkommen und Entwickler
werden sie zunehmend gereizt schließen. Versuchen Sie der letzteren
Neigung entgegenzuwirken. Sie hilft keinem, da der einzelne Nutzer in
jedem Einzelfall nicht für alle vorhergehenden ungültigen Tickets
verantwortlich ist; die statistische Zunahmen ist lediglich für die
Entwickler sichtbar, nicht für die Nutzer. (In
später in
diesem Kapitel, werden wir die Methoden untersuchen, um die
Anzahl der ungültigen Tickets zu verringern). Wenn verschiedene Nutzer
immer wieder dasselbe Missverständnis haben, kann das ein Hinweis
sein, dass ein bestimmter Bereich der Software überdacht werden muss.
Diese Muster können am einfachsten von einem Ticket-Verwalter bemerkt
werden, der die Bug-Datenbank überwacht; siehe
im Kapitel
.
Eine weitere häufige Abweichung zu diesem Lebenszyklus ist, dass
das Ticket als Duplikat gleich nach dem ersten
Schritt geschlossen wird. Ein Duplikat erscheint wenn jemand ein Ticket
meldet der dem Projekt bereits bekannt ist. Duplikate beschränken sich
nicht auf offene Tickets: Es ist auch möglich, dass ein Bug
wiederkehrt, nachdem er behoben wurde (auch als
Regression bekannt). In solchen Fällen öffnet
man Vorzugsweise wieder das ursprüngliche Ticket und alle neuen
Meldungen werden als Duplikate des Originals geschlossen. Der
Bugtracker sollte diese Beziehung in beiden Richtungen verfolgen
können, um Informationen wie man den Bug reproduziert dem
ursprünglichen Ticket verfügbar zu machen und umgekehrt.
Eine dritte Variante ist, dass Entwickler ein Ticket schließen,
in der Annahme, der Fehler wurde bereits behoben, was der Meldende
allerdings abweist und es erneut öffnet. Meistens geschieht das,
wenn die Entwickler nicht die nötige Umgebung haben, um den Fehler zu
reproduzieren oder nicht mit genau derselben Anleitung zur
Reproduktion beim Testen genutzt haben wie der Meldende.
Abgesehen von diesen Abweichungen, kann es andere kleine Details
im Lebenszyklus geben, die sich abhängig von der Software des
Bugtrackers unterscheiden. Die grundsätzliche Form ist jedoch bei
allen die gleiche, und obwohl der Lebenszyklus nicht eigen zu
Open-Source-Software ist, hat es Auswirkungen darauf wie
Open-Source-Projekte ihre Bugtracker benutzen.
Wie der erste Schritt andeutet, bietet ein Bugtracker der
Öffentlichkeit genau so sehr ein Bild des Projekts wie seine Mailinglisten
oder seine Webseite. Jeder kann ein Ticket aufmachen, jeder kann
sich ein Ticket anschauen und jeder kann die Liste der offenen Tickets
anschauen. Daraus folgt, dass Sie niemals wissen können, wieviele Leute
darauf warten, Fortschritte für ein bestimmtes Ticket zu sehen.
Auch wenn die Größe und Erfahrung der Entwicklergemeinschaft die
Geschwindigkeit einschränken kann, mit der Tickets abgearbeitet
werden, sollte das Projekt zumindest versuchen, jedes Ticket gleich
nach seiner Meldung zu bestätigen. Selbst wenn es eine Weile lang
liegen bleibt, ermutigt eine Reaktion dem Melder gegenüber, sich weiterhin
an seiner Lösung zu beteiligen, da er das Gefühl bekommt, dass ein Mensch
sich seiner Mühe bewusst ist (bedenken Sie, dass ein Ticket aufzumachen
für gewöhnlich einen größeren Aufwand bedeutet, als sagen wir eine
E-Mail zu schreiben). Desweiteren tritt das Ticket, sobald es von
einem Entwickler bemerkt wird, in das Bewusstsein des Projekts, womit
gemeint ist, dass dieser Entwickler darauf achten kann, ob das Ticket
an anderer Stelle irgendwo auftaucht, mit anderen Entwicklern darüber
reden kann, usw.
Die Notwendigkeit zeitnaher Reaktionen, impliziert zweierlei:
Der Tracker muss mit einer Mailingliste verbunden sein,
damit jede Änderung an einem Ticket, inklusive seine erste Meldung,
eine E-Mail erzeugt die beschreibt was passiert ist. Diese
Liste ist normalerweise eine andere als die gewöhnliche
Entwickler-Liste, da nicht alle Entwickler automatisierte Bug-Mails
empfangen wollen, der Reply-to-Header sollte aber (genau
wie bei Commit-Mails) auf die Entwickler-Liste
weisen.
Das Formular um Tickets zu melden sollte die E-Mail-Adresse
der Berichterstatter erfassen, damit sie für weitere Informationen
erreicht werden können. (Die E-Mail-Adresse sollte jedoch nicht
erzwungen werden, da manche Leute es
vorziehen, Fehler anonym zu melden. Siehe
später in
diesem Kapitel in dem die Bedeutung von Anonymität
behandelt wird.)
Interaktion mit Mailinglisten
Sorgen Sie dafür, dass der Bugtracker nicht zu einem
Diskussionsforum wird. Obwohl die menschliche Mitwirkung im
Bugtracker wichtig ist, ist er nicht wirklich für Diskussionen
geeignet. Betrachten Sie ihn eher als Archiv, eine Möglichkeit
Tatsachen und Verweise auf andere Diskussionen zu organisieren, die
hauptsächlich auf Mailinglisten stattfinden.
Es gibt Zwei Gründe diese Unterscheidung zu machen. Erstens ist
die Bedienung des Bugtrackers umständlicher als die einer Mailingliste
(oder, wo wir gerade dabei sind, IRC oder andere Echtzeit-Foren). Das liegt
nicht an der schlechten Benutzeroberfläche im Bugtracker, sondern an
seiner Ausrichtung auf die Erfassung und Darstellung getrennter
Zustände und nicht auf offene Diskussionen. Zweitens beobachtet nicht
jeder den Bugtracker, der auch an der Diskussion eines Tickets
beteiligt sein sollte. Ein Teil guter Ticker-Verwaltung (siehe
im Kapitel
) besteht darin
sicherzustellen, dass jedes Ticket eher die Aufmerksamkeit der
richtigen Leute erhält, als dass jeder Entwickler über jedes Ticket
Beischeid wissen muss. In
im Kapitel
, werden wir Wege untersuchen,
Benutzer davon abzuhalten, versehentlich Diskussionen von den ihnen
angemessenen Foren auf den Bugtracker auszulagern.
Manche Bugtracker können Mailinglisten überwachen und
automatisch alle E-Mails protokollieren, die sich um ein bekanntes
Ticket drehen. Typischerweise erkennen sie das anhand der
Identifikationsnummer des Tickets in der Betreffzeile der E-Mail, als
Teil einer bestimmten Zeichenfolge; Entwickler lernen diese
Zeichenfolgen in ihren E-Mails zu benutzen, um die Aufmerksamkeit des
Bugtrackers anzulocken. Der Tracker kann entweder die E-Mail als
ganzes speichern oder (besser noch) einen Link zu dem Archiv der
Liste. So oder so ist diese Funktion sehr nützlich; wenn Ihr
Tracker sie hat, sollten Sie sie unbedingt einschalten und Teilnehmer
erinnern sie zu nutzen.
Vor-Filterung des Bugtrackers
Die meisten Bugtracker leiden irgendwann an demselben Problem:
Eine erstickende Anzahl doppelter oder ungültiger Einträge die
mit guter Absicht, aber von unerfahrenen oder schlecht informierten
Nutzern gemeldet werden. Der erste Schritt dieser Entwicklung
entgegenzuwirken ist üblicherweise, einen deutlichen Hinweis auf
der Hauptseite des Bugtrackers anzubringen, der erklärt woran man
erkennen kann, ob ein Bug wirklich ein Bug ist, wie man nach bereits
gemeldete Fehler suchen kann und letztendlich, wie man seine
Meldung effektiv gestaltet, wenn man immer noch der Meinung ist,
dass sie einen neuen Bug beinhaltet.
Der Geräuschpegel sollte danach eine Weile reduziert sein, sowie
die Anzahl der Nutzer zunimmt, wird das Problem jedoch wiederkehren.
Kein einzelner Nutzer ist daran Schuld. Jeder versucht nur zum Wohl
des Projekts beizutragen und auch wenn ihre erste Meldung nicht
hilfreich ist, sollten Sie dennoch dazu ermutigen sich weiterhin zu
beteiligen und zukünftig bessere Tickets zu schreiben. In der
Zwischenzeit muss das Projekt die Ticket-Datenbank so frei von Müll
halten wie möglich.
Die zwei größten Abhilfen sind: Sicherzustellen, dass Leute den
Bugtracker beobachten, die genügend wissen um ungültige oder doppelte
Tickets gleich nach ihrer Meldung zu schließen und von Nutzern
erfordern (oder nachdrücklich dazu anregen) ihre Bugs von anderen
bestätigen zu lassen bevor sie eine Meldung im Tracker eintragen.
Die erste Methode scheint universelle Anwendung zu finden. Selbst
Projekte mit riesigen Ticket-Datenbanken (wie der Debian-Bugtracker
bei , mit 315,929 Tickets zum
Zeitpunkt dieses Schreibens) organisieren sich so, dass
irgendjemand jedes eintreffende Ticket sieht. Es
können verschiedene Personen sein, abhängig von der Kategorie des
Tickets. Das Debian-Projekt ist z.B. eine Sammlung verschiedener
Software-Pakete, also leitet Debian automatisch jedes Ticket an die
entsprechend Zuständigen für das Paket. Natürlich kann es manchmal
vorkommen, dass Nutzer ein Ticket falsch einordnen mit dem Ergebnis,
dass das Ticket zunächst an die falsche Person geleitet wird die es
dann möglicherweise wieder umleiten muss. Wichtig dabei ist, dass
diese Last trotzdem verteilt wird – ob der Nutzer beim Ausfüllen
des Formulars richtig oder falsch rät, die Beobachtung der Tickets
sollte dennoch mehr oder weniger gleichmäßig auf die Entwickler
aufgeteilt sein, damit jedes Ticket eine zeitige Antwort erhalten
kann.
Die zweite Technik ist weniger verbreitet, wahrscheinlich da
sie sich schwerer automatisieren lässt. Der Grundgedanke ist jedem
Ticket einen "Buddy" zuzuordnen. Wenn ein Nutzer denkt er hat ein
Problem gefunden, wird er darum gebeten, es auf einer der Mailinglisten
oder im IRC zu beschreiben und sich von jemandem bestätigen
zu lassen, dass es sich auch wirklich um einen Bug handelt. Ein zweites
Augenpaar frühzeitig einzubeziehen kann viele störende Meldungen
verhindern. Manchmal kann die zweite Partei erkennen, dass das
Verhalten kein Fehler ist, oder dass er in einer neuen Version
behoben wurde. Sie kann auch mit den Symptomen aus einem früheren
Ticket vertraut sein und einen doppelten Eintrag verhindern, indem sie
den Nutzer auf das ältere Ticket hinweist. Oftmals reicht es auch
den Nutzer zu fragen, "Haben Sie im Bugtracker geschaut ob er bereits
gemeldet wurde?" Viele denken einfach nicht daran, haben jedoch kein
Problem es zu tun wenn sie wissen, dass jemand es von ihnen
erwartet.
Das Buddy-System kann die Ticket-Datenbank wirklich sauber
halten, hat aber auch einige Nachteile. Viele machen trotzdem alleine
Meldungen, entweder weil sie die Anweisungen, sich für neue Tickets
einen Buddy zu suchen, nicht sehen oder ignorieren. Von daher
ist es immer noch nötig, die Ticket-Datenbank von Freiwilligen
überwachen zu lassen. Desweiteren ist es nicht gerechtfertigt, sie für
ihre Ignoranz gegenüber den Richtlinien allzusehr zurechtzuweisen, da
die meisten die ihre erste Meldung machen, nicht verstehen wie schwer
es ist, die Ticket-Datenbank in Stand zu halten. Die Freiwilligen
müssen deshalb wachsam sein und dennoch Zurückhaltung üben wenn sie
Tickets ohne einen Buddy wieder an seinen Autor zurückweisen. Das Ziel
ist jedem beizubringen, dass er zukünftig das Buddy-System verwenden
soll, um eine wachsende Gemeinschaft entstehen zu lassen, die das
Filter-System für die Tickets verstehen. Bei der Sichtung eines Tickets
ohne einen Buddy ist dies das idealisierte Vorgehen:
Antworten Sie sofort auf das Ticket, bedanken Sie sich bei
dem Nutzer für die Meldung, weisen Sie dabei aber auf die
Buddy-Richtlinien (die natürlich auf der Webseite deutlich
dargestellt sein sollten).
Falls das Ticket eindeutig gültig und kein Duplikat ist,
bestätigen Sie es und und starten den normalen Lebenszyklus.
So ist der Berichterstatter über die Zuordnung informiert und es
gibt keinen Grund die investierte Arbeit zu verschwenden, indem
man einen gültigen Bug wegen eines Formfehlers schließt.
Wenn andererseits das Ticket nicht klar berechtigt ist,
schließen Sie es und bitten Sie den Autor darum, ihn
wiederzueröffnen, sobald er eine Buddy-Bestätigung bekommt,
dann jedoch zusammen mit einem Verweis auf den Thread der
Mailingliste, der die Bestätigung enthält (z.B. per URL in
das Archiv der Mailingliste).
Denken Sie daran, obwohl dieses System mit der Zeit das
Signal-/Rauschverhältnis in der Ticket-Datenbank verbessern wird, es
niemals alle Falschmeldungen unterbinden kann. Der einzige Weg
Falschmeldungen komplett zu verhindern, ist den Bugtracker komplett
für alle außer die Entwickler abzuschalten – eine Medizin die
meistens schlimmer ist als die Krankheit. Es ist besser sich damit
abzufinden, dass die Entfernung ungültiger Tickets immer ein Teil der
üblichen Wartungsarbeiten am Projekt bleiben wird und so viele Leute
wie möglich dazu zu überreden, dabei zu helfen.
Siehe auch
im Kapitel
.
IRC / Echtzeit-Nachrichtendienste
Viele Projekte bieten Chat-Foren über Internet Relay
Chat (IRC) an, in denen Nutzer und
Entwickler einander Fragen stellen können und sofort Antworten erhalten
können. Auch wenn Sie einen IRC-Server über Ihre eigene Webseite
betreiben können, ist es im allgemeinen den
Aufwand nicht wert. Machen Sie statt dessen was alle anderen auch
machen: Betreiben Sie Ihre IRC-Kanäle auf
Freenode (). Freenode bietet Ihnen
die nötige Kontrolle um die IRC-Kanäle für Ihr Projekt zu
verwaltenEs gibt keine Voraussetzung oder Erwartung,
dass Sie an Freenode spenden, wenn Ihr Projekt es sich aber leisten
kann, sollten Sie es in Erwägung ziehen. Sie sind eine von Steuern
befreite gemeinnützige Einrichtung in den USA und sie betreiben einen
wertvollen Dienst., da Sie Ihnen die nicht
unwesentliche Mühe ersparen, einen eigenen IRC-Server zu
betreiben.
Das erste was Sie tun müssen, ist einen Namen für den Kanal
auszusuchen. Die offensichtlichste Wahl ist der Namen Ihres
Projekts – wenn dieser bei Freenode verfügbar ist, nehmen Sie ihn.
Wenn nicht, wählen Sie etwas möglichst ähnliches und leicht zu
merkendes. Bewerben Sie den Kanal auf Ihrer Webseite, damit Besucher
mit kurzen Fragen hat ihn gleich finden. Folgender Hinweis erscheint
z.B. markant in einem Kasten oben auf der Hauptseite von
Subversion:
Wenn Sie Subversion nutzen, empfehlen wir Ihnen
die users@subversion.tigris.org
Mailingliste zu abonnieren und das
Subversion-Buch
sowie die
FAQ zu
lesen. Sie können auch Fragen im IRC stellen auf
irc.freenode.net im
Kanal #svn.
Manche Projekte haben mehrere Kanäle, einen für jedes Unterthema.
Einen z.B. für Probleme bei der Installation, einen weiteren für Fragen
der Nutzer, noch einen für Diskussionen der Entwickler, usw.
( im Kapitel
behandelt wie man die
verschieden Kanäle aufteilt). Wenn Ihr Projekt noch jung ist, sollte
es nur einen Kanal geben, indem alle zusammen miteinander reden.
Später, sobald das Verhältnis von Nutzer zu Entwickler zunimmt, kann
es nötig werden separate Kanäle zu haben.
Wie sollen Leute von allen Kanälen wissen und woher sollen sie
gar wissen in welchen sie reden sollen? Und wenn sie reden, woher
sollen sie die hiesigen Konventionen kennen?
Die Antwort ist, es ihnen zu sagen, indem man den
channel topic entsprechend
setzt.Um den Topic in einem Kanal zu setzen, benutzen
Sie den /topic Befehl. Alle Befehle im IRC fangen
mit einem "/" an. Siehe
wenn Sie nicht mit der Nutzung
und Administration von IRC vertraut sind; insbesondere ist
eine
hervorragende Anleitung. Der Topic des Kanals ist
eine kurze Nachricht, die jeder Nutzer beim betreten des Kanals sieht.
Es gibt Neulinge eine kurze Anleitung und Hinweise wie sie an weitere
Informationen kommen wie z.B.:
Sie sind jetzt in #svn
Topic: #svn ist ein Forum für Fragen von Subversion-Benutzern, siehe
auch http://subversion.tigris.org/. || Entwickler-Diskussionen finden
in #svn-dev statt. || Fügen Sie hier bitte keine langen Protokolle ein,
nutzen Sie hierzu eine Pastebin-Seite wie http://pastebin.ca/. ||
Neuigkeiten: Freigabe von Subversion 1.1.0, weiteres dazu auf
http://svn110.notlong.com/.
Das ist zwar knapp, aber es sagt Neueinsteigern, was sie wissen
müssen. Es sagt genau wofür der Channel ist, enthält den Link zur Webseite
des Projekts (falls jemand an dem Channel vorbei kommt, ohne vorher darauf
gewesen zu sein), erwähnt einen verwandten Channel, und gibt ein wenig
Anleitung dazu, wie umfangreiche Einfügungen zu handhaben sind.
Pastebin-Sites
Der Platz in einem IRC-Kanal wird von allen geteilt: jeder sieht
was der andere sagt. Normalerweise ist das etwas gutes, da es Leute
erlaubt sich an eine Unterhaltung zu beteiligen, wenn sie meinen etwas
beitragen zu können und Beobachtern erlaubt beim zusehen etwas zu
lernen. Wenn jemand aber einen langen Text zitieren muss, wie ein
Protokoll aus einem Debugger wird das problematisch, da eine derart
viele Zeilen andere Unterhaltungen stören würde.
Die Lösung ist eine der pastebin oder
auch pastebot -Sites zu benutzen. Wenn Sie bei
jemandem nach umfangreichen Daten anfragen, bitten Sie ihn darum, diese
nicht direkt in den Kanal einzufügen, sondern ihre Daten (z.B.) auf
abzulegen und die sich ergebende URL
in den Kanal zu kopieren. Diese kann dann jeder besuchen, um sich
die Daten anzuschauen.
Es gibt eine Vielzahl freier Sites, zu viele um alle zu nennen,
hier nur diejenigen, von denen ich weiß, dass sie benutzt werden:
,
,
,
,
und
.
Bots
Viele IRC-Kanäle mit einem technischen Thema haben einen
nicht-menschlichen Teilnehmer, einen sogenannten
Bot, der in der Lage ist,
auf bestimmte Befehle zu reagieren, indem er
Informationen speichert und wiedergibt. Typischerweise wird der Bot
genau wie jeder andere im Kanal angesprochen, d.h. die Befehle werden
übermittelt, indem man den Bot "anspricht". Z.B.:
<kfogel> ayita: learn diff-cmd = http://subversion.tigris.org/faq.html#diff-cmd
<ayita> Thanks!
Dem Bot (mit dem Namen ayita im Kanal angemeldet) wurde dadurch
gesagt, dass er sich eine bestimmte URL merken soll und bei einer
Anfrage nach "diff-cmd" wiedergeben soll. Jetzt können wir ayita
ansprechen und bitten einem anderen Nutzer etwas über das diff-cmd zu
erzählen:
<kfogel> ayita: tell hmustermann about diff-cmd
<ayita> hmustermann: http://subversion.tigris.org/faq.html#diff-cmd
Dafür gibt es auch ein Kürzel:
<kfogel> !a hmustermann diff-cmd
<ayita> hmustermann: http://subversion.tigris.org/faq.html#diff-cmd
Der genaue Befehl und das Verhalten unterscheidet sich bei jedem
Bot. Das obige Beispiel benutzt ayita
(), wovon
üblicherweise in #svn eine Instanz läuft. Andere Bots
sind unter anderem () und
Supybot (). Beachten Sie, dass man
keine besonderen Rechte auf den Server haben muss um einen Bot zu
betreiben. Ein Bot kann auf einem beliebigen Rechner betrieben werden;
jeder kann einen Einrichten und anweisen einen bestimmten
Server/Kanal zu betreten.
Wenn Sie in Ihrem Kanal bemerken, dass immer wieder die gleichen
Fragen gestellt werden, empfehlen ich Ihnen dringend, einen Bot
einzurichten. Nur wenige Nutzer im Kanal werden herausfinden wie der
Bot zu bedienen ist, diese Personen werden aber umso mehr Fragen
beantworten können, wenn der Bot es Ihnen ermöglicht, um so vieles
effektiver zu antworten.
IRC-Archivierung
Auch wenn es möglich ist, alles in einem Kanal zu archivieren,
wird das nicht unbedingt erwartet. Unterhaltungen im IRC sind im Grunde
genommen öffentlich, aber viele betrachten es sie als informelle,
halbwegs private Unterhaltungen. Nutzer neigen dazu nicht so sehr auf
ihre Grammatik zu achten und äußern Meinungen (zum Beispiel über andere
Entwickler im Projekt) die sie nicht unbedingt archiviert haben
möchten.
Es wird natürlich manchmal Auszüge geben,
die erhalten werden sollte und das ist auch in Ordnung. Die meisten
IRC-Anwendungen können, wenn der Nutzer das möchte, Unterhaltungen
mitschneiden oder wenn das nicht geht, kann die Unterhaltung immer noch
aus dem Fenster der Anwendung heraus kopiert und in ein beständigeres
Forum (meistens der Bugtracker) einfügt werden. Alles mitzuschneiden
kann aber manche Nutzer unruhig machen. Wenn sie doch alles
archivieren, stellen Sie sicher, dass es klar im Topic
erklärt wird und geben Sie die URL des Archivs an.
Wikis
Ein Wiki ist eine Website die es jedem
Besucher erlaubt, ihren Inhalt zu bearbeiten; der Begriff "wiki" (von
dem hawaiischen Wort für "schnell" oder "super-schnell") ist auch der
Name für Software, die solche Bearbeitungen ermöglicht. Wikis wurden
1995 erfunden, richtig populär wurden sie aber erst 2000 bzw. 2001,
teilweise befeuert durch den Erfolg von Wikipedia
(), ein wikibasiertes freies
Lexikon. Sie können Wikis zwischen IRC und Webseiten einordnen:
Wikis sind kein Echtzeit-Medium, also haben Benutzer die
Möglichkeit, ihre Beiträge zu überdenken und auszufeilen, es ist aber
auch sehr leicht beizutragen, da der Bearbeitungsaufwand
geringer ist als bei einer normalen Webseite.
Wikis gehören noch nicht zur Standardausstattung für
Open-Source-Projekte, werden es aber wahrscheinlich bald sein. Sie sind
eine relativ neue Technik, und es wird noch mit ihrer Nutzung
experimentiert. Hier ein paar Worte der Vorsicht – derzeit
ist es einfacher, den Missbrauch von Wikis zu untersuchen als ihre
Erfolge.
Wenn Sie sich entschließen, ein Wiki zu betreiben, verwenden Sie
große Aufmerksamkeit auf klare Organisation der Seiten und einen
angenehmes Seitenlayout, damit Besucher (bzw. potentielle Bearbeiter)
instinktiv wissen, wo sie ihre Beiträge einordnen sollen. Genauso
wichtig ist es, diese Richtlinien in das Wiki hinein zu schreiben, damit
die Benutzer etwas zur Orientierung haben. Viel zu oft verrennen sich
Administratoren in dem Glauben, dass wenn eine Horde Besucher für sich
genommen qualitativ hochwertige Beiträge leistet, das Gesamtresultat
automatisch auch insgesamt qualitativ hochwertig sein müsste. So jedoch
funktionieret ein Wiki nicht. Jede individuelle Seite, jeder Abschnitt,
mag für sich genommen gut sein, nicht aber eingebettet in ein
unorganisiertes oder verwirrendes Ganzes. Wikis
leiden viel zu häufig an:
Mangel an
Orientierungsrichtlinien. Eine gut organisierte
Webseite gibt dem Besucher das Gefühl, jederzeit Bescheid zu wissen,
wo er ist. Bei Seiten mit einer guten Aufmachung kann man
beispielsweise intuitiv den Unterschied zwischen dem Bereich für
das "Inhaltsverzeichnis" und dem für den "Inhalt" erkennen.
Autoren des Wikis werden solche Unterschiede auch respektieren,
aber nur wenn die Unterschiede schon am Anfang vorhanden
sind.
Doppelte Informationen.
Häufig passiert es in Wikis, dass irgendwann verschiedene Seiten
ähnliches sagen, da die einzelnen Teilnehmer nicht unbedingt
mitbekommen, was andere schreiben. Teilweise kann das am Fehlen der
oben erwähnten Orientierungsprinzipien liegen, insofern als
Benutzer die bereits vorhandenen Inhalte nicht finden, wenn sie
nicht liegen, wo man sie erwarten würde.
Unklarheit der Zielgruppe.
Zu einem gewissen Grad ist dieses Problem bei einer so großen
Anzahl von Autoren unvermeidbar, kann aber verringert werden, wenn
es schriftliche Richtlinien gibt, wie man die Inhalte erstellt. Es
hilft auch, neue Beiträge am Anfang aggressiv zu bearbeiten, damit
sich ein Standard bildest.
Die übliche Lösung für all diese Probleme ist die gleiche:
Redaktionelle Normen anzusetzen und sich nicht allein auf ihre
Bekanntgabe zu verlassen, sondern sie durch die Bearbeitung von Seiten
durchzusetzen und sich ihnen auch selbst zu unterwerfen.
Im Allgemeinen werden Wikis alle Schwächen im
Ausgangsmaterial verstärken, da die Teilnehmer alle Muster nachahmen
werden, die sie vorfinden. Richten Sie das Wiki nicht nur ein und
hoffen Sie, dass sich alles fügt. Es muss auch mit gut geschriebenen
Inhalten angefangen werden, damit die Besucher Beispiele haben, denen
sie folgen können.
Das leuchtende Beispiel eines gut betriebenen Wikis ist Wikipedia,
obwohl das sicherlich teilweise daran liegt, dass der Inhalt
(Lexikon-Einträge) von Natur aus für das Wiki-Format geeignet ist. Wenn
Sie die Wikipedia aber genauer ansehen, werden Sie feststellen,
dass die Administratoren eine äußerst gründliche
Basis für die Zusammenarbeit ausgelegt haben. Es gibt eine ausführliche
Dokumentation dazu, wie man neue Einträge schreiben soll, wie man einen
angemessenen, neutralen Standpunkt bewahrt, welche Art von Änderungen
man vornehmen oder vermeiden sollte, welche Verfahren dazu taugen,
Konflikte zwischen sich widersprechende Bearbeitungen aufzulösen (mit
mehreren Schritten, mitunter auch durch das letzte Mittel eines
Schiedsgerichts) usw. Sie haben auch eine Verwaltung für die
Autorisierung, damit sie eine Seite für die Bearbeitung sperren können,
sollt sie Ziel mehrfacher unangemessener Bearbeitungen werden,
bis das Problem gelöst wurde. Mit anderen Worten:
werfen sie nicht einfach ein paar Vorlagen auf eine Webseite und
drücken die Daumen! Wikipedia funktioniert deshalb, weil ihre Gründer
sorgfältig darüber nachgedacht haben, wie man tausende Fremde dazu
bringt, ihren Schreibstil einer gemeinsamen Vision anzupassen. Auch
wenn Sie nicht gleichermaßen vorbereitet sein müssen, um in einem freien
Software-Projekt ein Wiki zu betreiben, lohnt es diesem Geist
nachzueifern.
Weitere Informationen über Wikis finden Sie unter
. Das erste Wiki ist
weiterhin wohlauf und beinhaltet viel Material darüber wie man Wikis
betreibt: Siehe ,
, und
für
verschiedene Ansichten.
Website
Es gibt aus technischer Sicht nicht viel darüber zu sagen, wie man
die Website für das Projekt einrichtet: Einen Webserver aufzubauen
und Webseiten zu schreiben, sind relativ einfache Aufgaben, und das
wichtigste im Bezug auf das Layout und die Anordnung wurde bereits im
vorherigen Kapitel abgedeckt. Die Hauptfunktion der Website ist, das
Projekt klar und einladend zu präsentieren und die anderen Werkzeuge
einzubinden (Versionsverwaltung, Bugtracker, usw.). Wenn Ihnen die
Kenntnisse dazu fehlen, selbst einen Webserver aufzusetzen, ist es
normalerweise nicht schwer, jemanden zu finden, der es kann und
bereit ist zu helfen. Trotzdem ziehen es viele vor, bestehende
Hosting-Pakete zu nutzen, um sich Zeit und Mühe zu sparen.
Hosting-Pakete
Es gibt zwei Hauptvorteile bei der Nutzung von Hosting-Paketen.
Der erste ist die Kapazität ihrer Server und ihre Bandbreite: Ihre
Server sind schnelle Kisten mit dicken Leitungen. Egal wie erfolgreich
Ihr Projekt wird, Ihnen wird niemals der Plattenplatz oder
die Bandbreite ausgehen. Der zweite Vorteil ist seine Einfachheit. Sie
haben bereits einen Bugtracker, eine Versionsverwaltung, ein
Malinglisten-System, ein Archiv-System und alles was Sie sonst benötigen,
um eine Site zu betreiben. Sie haben die Programme konfiguriert, und
kümmern sich um die Sicherung aller Daten dieser Programme. Sie müssen
nicht viele Entscheidungen treffen. Sie müssen lediglich ein Formular
ausfüllen, einen Knopf drücken und plötzlich haben Sie eine Website
für Ihr Projekt .
Das sind ziemlich schwerwiegende Vorteile. Der Nachteil ist
natürlich, dass Sie sich mit der angebotenen
Auswahl und
Konfiguration abfinden müssen, selbst wenn etwas anderes für Ihr
Projekt besser wäre. Meistens lassen sich diese Sites innerhalb enger
Grenzen konfigurieren, aber Sie werden niemals die feingranulare
Kontrolle haben wie bei einer selbstgebauten Site mit vollem
administrativen Zugriff auf den Server.
Ein perfektes Beispiel hierfür ist der Umgang mit generierten
Dateien. Bestimmte Webseiten des Projekts können generierte Dateien
sein – es gibt z.B. Systeme, um die Daten für eine FAQ in ein
einfaches Quellformat zu schreiben, von dem aus HTML, PDF und andere
Darstellungsformate generiert werden können. Wie in
früher
in diesem Kapitel beschrieben, wollen Sie nicht die
generierten Formate in der Versionsverwaltung haben, sondern nur die
Quellen. Wenn Ihre Website aber auf den Server von jemand anderem
betrieben wird, kann es unmöglich sein, ein eigenes Script einzubinden,
um die HTML-Version automatisch zu erzeugen, gleich nachdem etwas an
der Quelldatei geändert wurde. Die einzige Abhilfe ist hier, die
generierten Formate zusätzlich in der Versionsverwaltung abzulegen,
damit sie auch in der Website auftauchen.
Es kann auch schwerwiegendere Folgen geben. Sie werden vielleicht
nicht so viel Kontrolle über die Präsentation haben, wie Sie es sich wünschen
würden. Manche Hosting-Sites erlauben es Ihnen, Ihre Webseiten
anzupassen, der vorgegebene Aufbau hinterlässt aber aber meistens an
verschiedenen Stellen erkennbare Spuren. Manche auf SourceForge
gehosteten Projekte haben ausgefeilte eigene Webseiten, verweisen
Entwickler aber immer noch auf ihre "SourceForge Seite" für weitere
Informationen. Die SourceForge-Seite ist, was die Webseite des Projekts
gewesen wäre, wenn das Projekt keine angepasste Seite benutzt hätte. Auf
der SourceForge-Seite sind Verweise auf den Bugtracker, zum
CVS-Repository, Downloads, usw. Eine SourceForge-Seite beinhaltet
unglücklicherweise auch eine ganze Menge belanglosen Rauschens. Oben ist
ein Werbebanner, oftmals eine Animation. Links ist eine vertikale
Anordnung verschiedener Verweise die für jemandem, der am Projekt
interessiert ist, kaum von Bedeutung sein dürften. Rechts ist meistens
noch mehr Werbung. Lediglich der mittlere Bereich der Seiten ist dem
Material des Projekts gewidmet und selbst dieser ist verwirrend
angeordnet, so dass Benutzer unsicher sind, auf was sie als nächstes
klicken sollen.
Hinter jedem einzelnen Aspekt von SourceForge's Design steht
zweifellos ein guter Grund – gut für SourceForge, wie z.B.
die Werbung. Für das einzelne Projekt kann das Ergebnis aber eine nicht
ganz optimale Website sein. Es ist nicht meine Absicht, auf SourceForge
herumzuhacken; ähnliche Bedenken lassen sich auf viele andere Sites
übertragen, die Hosting-Pakete anbieten. Das Wesentliche ist hierbei,
den Kompromiss zu erkennen den man eingeht. Es wird Ihnen die technische
Bürde abgenommen, eine eigene Website zu betreiben, dafür müssen Sie
akzeptieren, dass jemand anderes bestimmt, wie sie betrieben wird.
Sie allein können entscheiden, ob ein Hosting-Paket für Ihr
Projekt das Beste ist. Wenn Sie eine solche Seite wählen, halten Sie
sich die Möglichkeit offen, im nachhinein auf Ihre eigenen Server zu
wechseln, indem Sie einen gesonderten Domain-Namen als Adresse
verwenden. Sie können diese URL für komplizierte Funktionen auf die
Hosting-Seite leiten. Ordnen Sie aber unbedingt alles so, dass
Sie die die Adresse des Projekts nicht ändern müssen, sollten Sie sich
später umentscheiden.
Die Wahl des Hosting-Anbieters
Derzeit (Anfang 2011) dominieren Drei Große den Markt freier
Hosting-Angebote. Alle drei hosten Open-Source-lizenzierte Projekte
kostenlos. Sie bieten Versionskontrolle, Bugtracking und Wikis an (manche
sogar mehr, wie z.B. Downloadmöglichkeiten für Binärpakete):
GitHub
Die Versionskontrolle ist auf Git beschränkt – aber falls Sie
ohnehin Git benutzen, ist das vermutlich genau der richtige Ort
für Ihr Projekt. GitHub hat sich für Git-Projekte zum Zentrum
des Universums entwickelt und integriert all seine Dienste mit
Git. GitHub bietet auch eine vollständige
API, um seine
Dienste aus Programmen heraus zu nutzen. Es bietet keine
Mailinglisten; allerdings werden diese von so vielen anderen
geboten, dass dies kein allzu großes Problem sein dürfte.
Google Code Hosting
Bietet Subversion und Mercurial zur Versionkontrolle (kein Git,
zumindest noch nicht), Wikis, einen Downloadbereich, und einen
ziemlich schicken Bugtracker. Es hat auch APIs zu bieten: die
Versionskontollsysteme sind naturgemäß ihre eigene API; der
Bugtracker hat
eine eigene API; der Wiki-Inhalte ist direkt durch die Versionsverwaltun zugänglich und ist
so auch durch Scripts bearbeitbar; der Downloadbereich bietet
gescriptete Uploads, sprich: eine API. Mailinglisten werden
über Google Groups
geboten (diese Aussage freilich lässt sich auch auf alle anderen
Hostinganbieter übertragen).
SourceForge
Dies ist der älteste und in vielerlei Hinsicht auch der größte
Anbieter für freies Hosting von Projekten. Es bietet alle Features,
die auch die anderen bieten, und seine Benutzerschnittstelle ist
gut benutzbar; Allerdings empfinden viele Menschen die Werbeblöcke
auf den Projektseiten als abstoßend. Es scheint der einzige der
drei Großen, der im Moment alle wichtigen Versionskontrollsysteme
bietet (Git, Subversion, Mercurial, und CVS). SourceForge bietet
eigene Mailinglisten, aber natürlich können Sie dafür auch einen
anderen Anbieter nutzen.
Einige Organisationen, wie z.B. die Apache Software Foundation,
bieten auch freies Hosting für solche Open-Source-Projekte, die ihrer
Mission entsprechen und sich gut in den Bestand der dort bereits
existierenden Projekte eingliedern.
Falls Sie im Zweifel sind, wo Sie Ihr Projekt unterbringen sollen,
empfehle ich Ihnen dringend, sich an einen der großen drei Anbieter
zu halten. Wenn Sie noch mehr Anleitung wünschen: nutzen Sie GitHub,
falls Ihr Projekt Git zur Verionierung benutzt, ansonsten nutzen Sie
Google Code. Natürlich ist auch SourceForge akzeptabel, aber es bietet
keinen Vorteil gegenüber den anderen, und die Werbung kann
schon nerven.
Viele Menschen haben beobachtet, dass freie Projekt-Hosting-Sites
oftmals die Software, die sie benutzen, um diesen Service zu bieten,
selbst nicht unter eine freie Software-Lizenz stellen. (einige, die es
tun sind
Launchpad,
Gitorious and
GNU Savannah).
Aus meiner Sicht wäre es zwar ideal, Zugriff auf all den Code zu haben,
der die Site ausmacht, aber der entscheidende Punkt ist einen Weg zu
haben, die eigenen Daten zu exportieren und die Möglichkeit, mit den
Daten automatisiert zu interagieren. Eine solche Site würde Sie nie
wirklich einsperren können und würde durch die programmgesteuerte
Anbindung sogar zu einem gewissen Grade erweiterbar sein.
Während es einen gewissen Wert darstellen würde, den Code, auf dem eine
Hosting-Site beruht, unter Open-Source-Bedingungen zur Verfügung zu haben,
würden die praktischen Anforderung, diesen Code in eine produktive
Umgebung zu verwandeln, die meisten Benutzer völlig überfordern.
Diese Sites benötigen etliche Server, angepasste Netzwerke, in Vollzeit
beschäftigte Angestellte, die diese warten; allein den Code zu haben,
würde nicht ausreichen, den Service zu kopieren oder zu "forken".
Die Hauptsache ist sicherzustellen, dass Ihre Daten nicht in die
Gefangenschaft geraten.
Wikipedia enthält einen ausführlichen Vergleich von Open-Source-Hosting-Angeboten; es ist
der erste Ort, den Sie bezüglich aktueller umfangreicher Informationen
über Hosting-Optionen für Open-Source-Projekte konsultieren sollten.
Auch Haggen So unternahm eine Evaluierung der vielfältigen
Hosting-Angebote im Rahmen seiner Dr. Phil. Dissertation
Construction of an Evaluation Model for Free/Open Source
Project Hosting (FOSPHost) sites. Auch wenn diese aus dem
Jahre 2005 stammt, scheint er sie zuletzt 2007 aktualisiert zu haben und
seine Kriterien scheinen langfristig gültig. Seine Ergebnisse finden Sie
unter , siehe insb. auch
die sehr lesbare Vergleichstabelle unter
.
Anonymität und Beteiligung
Ein Problem, das nicht allein auf Seiten beschränkt ist,
die Hosting-Pakete benutzen, dort aber am häufigsten auftritt, ist der
Missbrauch der Login-Funktion. Die Funktion selbst ist relativ einfach:
Die Seite erlaubt jedem Besucher, sich mit Benutzernamen und Passwort
zu registrieren. Von da an speichert sie ein Profil für diesen Nutzer und
die Administratoren der Projekte können dem Nutzer bestimmte Rechte
einräumen, z.B. Schreibzugriff auf das Projektarchiv.
Das kann äußerst nützlich sein und es ist tatsächlich eines der
wesentlichen Argumente für fertige Hosting-Pakete. Das Problem ist, dass
Nutzer sich manchmal für Aufgaben anmelden müssen, die eigentlich auch
ohne Anmeldung möglich sein sollten, z.B. ein Ticket im Bugtracker
zu erstellen. Indem man eine Anmeldung für solche Aufgaben voraussetzt,
hebt das Projekt die Einstiegshürden für Angelegenheiten, die
möglichst schnell und einfach sein sollten. Natürlich möchte man
jemanden erreichen können, der Daten in den Bugtracker eingetragen hat,
dazu reicht aber ein Feld, in dem er seine E-Mail-Adresse eingeben kann
(falls er möchte). Wenn ein neuer Benutzer einen Bug findet und ihn
melden möchte, wird er durch die Anforderung verärgert sein, ein
Konto erstellen zu müssen, nur um dem Bugtracker einen Eintrag
hinzuzufügen: leicht könnte er sich entscheiden, es gleich
ganz zu lassen.
Die Vorteile der Nutzerverwaltung wiegen im Allgemeinen
ihre Nachteile auf. Wenn Sie es sich aussuchen können, welche
Aufgaben Sie anonym erlauben wollen, stellen Sie sicher nicht nur
alle Abläufe einzubeziehen, die nur Lesezugriff
erfordern, sondern nehmen Sie auch bestimmte Eingabe-Aktionen hinzu,
insbesondere im Bugtracker sowie, falls vorhanden,
auf den Seiten des Wikis.