Vorwort Eine schlechte FAQ (Frequently Asked Questions) Seite ist eine, die nicht aus den Fragen zusammengestellt wurde, welche wirklich gefragt wurden, sondern die aus den Fragen besteht, von denen gewünscht wird, dass sie gefragt werden. Vielleicht haben Sie solche schon gesehen:
Q: Wie kann ich Glorbosoft XYZ einsetzen um die Team-Produktivität zu maximieren?
A: Viele unserer KundInnen wollen wissen, wie Sie Ihre Produktivität mit unseren patentierten Office Groupware Verbesserungen maximieren können. Die Antwort ist einfach: zuerst klicken Sie auf das Datei Menü, fahren hinunter zum Punkt Erhöhe Produktivität, und dann …
Das Problem mit solchen FAQs ist, dass sie keine FAQs im eigentlichen Sinne sind. Niemand fragt beim technischen Support Wie können wir unsere Produktivität steigern?. Üblicherweise fragen Leute sehr spezifische Fragen, wie Wie können wir das Kalendersystem so ändern, dass es die Erinnerungen zwei Tage im Vorhinein aussendet anstatt einen Tag vorher? und so weiter. Aber es ist viel leichter häufig gestellte Fragen zu erfinden, als die richtigen Fragen zu entdecken. Eine sinnvolle FAQ-Sammlung zusammenzustellen erfordert ausdauernde organisatorische Anstrengung: über die Lebensdauer einer Software müssen hereinkommende Anfragen ausgewertet und Rückmeldungen evaluiert werden und zu einem konsistenten, benutzungsfreundlichen Ganzen zusammengeführt werden, das die gesammelte Erfahrung der AnwenderInnen wiedergibt. Es verlangt die geduldige Achtsamkeit eines Naturforschers. Nicht grossartige Hypothesen und visionäre Vorhersagen sondern hauptsächlich offene Augen und genaue Wahrnehmung sind gefragt. Was ich an diesem Buch liebe, ist dass es genau aus solch einem Prozess gewachsen ist und dass das auf jeder Seite sichtbar ist. Es ist das direkte Ergebnis der Begegnung des Autors mit BenutzerInnen. Es begann mit Ben Collins-Sussmans Beobachtung, dass Leute die gleichen grundlegenden Fragen auf der Subversion- Mailingliste immer und immer wieder stellten: Was sind die Standard- Arbeitsabläufe mit Suversion? Haben Branches und Tags die gleiche Bedeutung wie in anderen Versions-Kontroll-Systemen? Wie finde ich heraus, wer eine bestimmte Änderung durchgeführt hat? Frustriert davon die gleichen Fragen Tag für Tag immer wieder zu sehen arbeitete Ben im Sommer 2002 über ein Monat intensiv daran The Subversion Handbook zu schreiben, eine Sechzig-Seiten-Anleitung, welche die Grundlagen der Benutzung von Subversion beschrieb. Die Anleitung erhob keinen Anspruch auf Vollständigkeit, aber es wurde mit Subversion verteilt und half AnwenderInnen über die ersten Hürden in der Lernkurve. Als O'Reilly and Associates sich entschieden ein vollständiges Subversion-Buch herauszugeben, war der Weg vorgezeichnet: Erweiterung des Subversion Handbook. Die drei Co-Autoren des neuen Buches waren mit einer unüblichen Möglichkeit konfrontiert. Eigentlich war es ihre Aufgabe ein Buch von oben nach unten, beginnend mit einer Inhaltsübersicht und einem Grobkonzept, zu schreiben. Aber sie hatten auch Zugang zu einem ständigen Strom — eigentlich einem unkontrollierbaren Geisier — von unten nach oben Material. Subversion war bereits in der Hand von tausenden frühen InteressentInnen und diese AnwenderInnen gaben Tonnen an Rückmeldungen — nicht nur über Subversion, sondern auch über die Dokumentation. Während der ganzen Zeit in der sie dieses Buch schrieben, verfolgten Ben, Mike und Brian ständig aufmerksam die Subversion-Mailinglisten und Chat-Räume und nahmen die Probleme wahr, die wirkliche Leute in realen Situationen hatten. Das Buch spiegelt das wieder. Es steht auf dem festen Boden der Erfahrung und ist nicht auf dem Sand von frommen Wünschen gebaut. Es vereint die Vorteile von Bedienungsanleitung und FAQ-Seiten. Diese Zweigleisigkeit ist vielleicht nicht gleich zu erkennen. Von vorne nach hinten gelesen ist das Buch einfach eine Beschreibung einer Software. Es gibt die Übersicht, die obligatorische geführte Rundreise, das Kapitel über Administration, einige fortgeschrittene Themen und natürlich eine Funktionsübersicht und eine Problemlösungs-Anleitung. Nur wenn Sie später das Buch wieder zur Hand nehmen um die Lösung für bestimmte Probleme zu suchen wird sichtbar: die beschriebenen Details können nur aus der Erfahrung mit dem Unerwarteten, die Beispiele aus dem tatsächlichem Einsatz stammen und berücksichtigen in erster Linie die Bedürfnisse und den Blickwinkel der AnwenderInnen. Narürlich kann niemand versprechen, dass dieses Buch alle Fragen beantwortet, die Sie mit Subversion haben werden. Manchmal wird die Genauigkeit, mit der es auf Ihre Fragen eingeht, unheimlich telepathisch erscheinen; gelegentlich werden Sie in eine Lücke im Wissen der Gemeinde stolpern und mit leeren Händen dastehen. Wenn das passiert schreiben Sie am Besten eine Mail an users@subversion.tigris.org und präsentieren ihr Problem. Die Autoren sind nach wie vor dort und beobachten. Und das betrifft nicht nur die drei, die am Umschlag aufgezählt sind, sondern viele andere, die Korrekuren und neues Material beigesteuert haben. Aus der Sicht der Gemeinde ist die Lösung Ihres Problems lediglich ein erfreulicher Nebeneffekt eines viel grösseren Projektes — nämlich das Buch und schlussendlich auch Subversion selbst immer näher an die Art anzupassen, in der es tatsächlich benutzt wird. Diese Personen sind begierig darauf, von Ihnen zu hören, nicht nur weil sie Ihnen helfen können, sondern auch weil ihnen selbst damit geholfen ist. Für Subversion — so wie für alle aktiven freien Software-Projekte — gilt: Sie sind nicht allein. Dieses Buch soll Ihr erster Begleiter beim Einstieg sein. — Karl Fogel , Chicago, 14 March, 2004