Der Preis vom Erfolg ist bei groß in der Open-Source-Welt. Während Ihre Software beliebter wird, nimmt die Anzahl der Menschen zu, die auftauchen um nach Informationen zu suchen, dramatisch zu, während die Anzahl der Menschen die in der Lage sind Informationen bereitzustellen sehr viel langsamer zunimmt. Desweiteren, gäbe es selbst wenn das Verhältnis ausgeglichen wäre immer noch das Problem, mit der Art wie die meisten Open-Source-Projekte Kommunikation handhaben. Betrachten Sie zum Beispiel Mailverteiler. Die meisten Projekte haben Mailverteiler für allgemeine Fragen von Nutzern – manchmal heißt der Verteiler "users", "discuss", "help" oder irgend etwas anderes. Unabhängig von Namen, ist der Sinn des Verteilers immer der gleiche: Einen Ort zur Verfügung zu stellen, wo Leute auf ihre Fragen Antworten bekommen können, während andere zuschauen und (vermutlich) aus der Beobachtung dieses Austauschs Wissen aufsaugen.
Diese Mailverteiler funktionieren sehr gut, bis zu ein paar Tausend Nutzern, und/oder ein paar hundert Nachrichten am Tag. Irgendwo danach fängt das System jedoch an zusammenzubrechen, weil jeder der angemeldet ist jede Nachricht sieht; wenn die Anzahl der Nachrichten an einem Verteiler über das hinaus geht, was eine einzige Person am Tag verarbeiten kann, wird der Verteiler zu einer Last für seine Mitglieder. Stellen Sie sich zum Beispiel vor, wenn Microsoft einen solchen Verteiler für Windows XP hätte. Windows XP hat Hunderte von Millionen von Nutzern; wenn auch nur ein Promille von denen in einer vierundzwanzigstündigen Zeitspanne Fragen hätte, dann bekäme dieser Verteiler theoretisch Hunderte von Tausende von Nachrichten am Tag! Solch einen Verteiler könnte es natürlich niemals geben, denn keiner bliebe bei ihm angemeldet. Dieses Problem beschränkt sich nicht auf Mailverteiler; die gleiche Logik lässt sich anwenden, auf IRC, Online-Diskussionsforen, sogar jedes System in dem eine Gruppe die Fragen von Einzelnen hört. Die Implikationen sind bedenklich: Das gewöhnliche Open-Source-Modell von massiv paralleler technischer Unterstützung skaliert schlicht und einfach nicht auf der Ebene, die für Weltherrschaft nötig ist.
Es wird keine Explosion geben, wenn die Foren anfangen überzulaufen. Es wird nur einen leisen Folge negativer Rückmeldungen geben: Leute melden sich von den Verteilern ab, oder verlassen das IRC, oder hören zumindest auf sich die Mühe zu machen Fragen zu stellen, da sie sehen können, dass man Sie in dem ganzen Lärm nicht gehört werden. Sowie immer mehr Leute diese im hohen Maße vernünftige Wahl treffen, wird die Aktivität auf dem Forum aussehen als wäre es auf einer annehmbaren Stufe. Es es bleibt genau deshalb annehmbar, weil die Vernünftigen (oder zumindest erfahrenen) Leute anfangen an anderen Orten nach Informationen zu suchen – während die unerfahrenen zurück bleiben und weiterhin Nachrichten schreiben. Mit anderen Worten, während das Projekt wächst, ist eine weitere Nebenwirkung von nicht-skalierbaren Kommunikationsmodellen, dass die durchschnittliche Qualität sowohl der Fragen, als auch der Antworten dazu neigt schlechter zu werden, was es danach aussehen lässt, als wären die neuen Nutzer blöder als es ehemals der Fall war, obwohl das wahrscheinlich nicht der Fall ist. Es ist nur, dass das Kosten/Nutzen-Verhältnis dieser Foren mit einer hohen Bevölkerung weniger wird, also fangen diejenigen mit mehr Erfahrung natürlich zuerst an woanders nach Antworten zu suchen. Die Kommunikationsmechanismen anzupassen, um mit dem Wachstum des Projekts umzugehen, beinhaltet deshalb zwei verwandte Strategien:
Zu erkennen, wann bestimmte Teile eines Forums nicht unter unbegrenztem Wachstum leiden, selbst wenn das für das Forum insgesamt der Fall ist, und diese Teile in neue, speziellere Foren zu Trennen (d.H. lassen Sie das Gute nicht vom Schlechten herunterziehen).
Stellen Sie sicher, dass viele automatisierte Informationsquellen zur Verfügung stehen, und dass Sie organisiert, aktuell, und leicht auffindbar gehalten werden.
Strategie (1) ist gewöhnlich nicht all zu schwer. Die meisten Projekte fangen mit einem Hauptforum an: Ein Mailverteiler für allgemeine Diskussionen, auf dem Ideen für neue Funktionen, Fragen zum Aufbau der Software, und programmier-Probleme zerlegt werden können. Jeder der an dem Projekt beteiligt ist, ist auf dem Verteiler. Nach einer Weile, wird es für gewöhnlich offensichtlich, dass der Verteiler sich in mehrere unterschiedliche Unterverteiler, auf bestimmten Themen basierend, aufgeteilt hat. Zum Beispiel geht es in manchen Threads eindeutig um Entwicklung und Aufbau des Codes; andere sind eher Benutzerfragen, von der Art "Wie mache ich X?"; es gibt vielleicht eine dritte Familie die sich um die Verarbeitung von Bug-Meldungen und Erweiterungs-Wünsche dreht; und so weiter. Eine beliebige Person mag sich natürlich an vielen verschiedenen Thread-Arten beteiligen, das Wichtige ist aber, dass nicht viel Überlappung zwischen den verschiedenen Arten gibt. Sie könnten in separate Verteiler aufgeteilt werden ohne irgend eine schädliche Balkanisierung zu verursachen, da die Threads selten mehrere Themen überspannen.
Diese Aufteilung wirklich zu machen, ist ein Vorgang mit zwei Schritten. Sie werden einen neuen Verteiler (oder einen IRC-Kanal, oder was immer es auch sein soll), und dann müssen Sie welche Zeit auch immer nötig ist, um Leute zu nerven und erinnern die neuen Foren entsprechend zu nutzen. Letzteres kann Wochen andauern, letztendlich werden es die Leute aber kapieren. Sie müssen es sich nur zum Prinzip machen, dem Absender immer zu sagen, wenn er an das falsche Ziel geschickt hat, und es auf eine sichtbare Art tun, damit andere dazu ermutigt werden, beim umleiten mitzuhelfen. Es ist auch nützlich, eine Webseite mit einem Wegweiser zu allen Verteilern bereit zu haben; Ihre Rückmeldungen können einfach auf diese Seite verweisen und als Bonus, mag der Empfänger etwas darüber lernen, nach Richtlinien zu suchen, vor er eine Nachricht schreibt.
Strategie (2) ist ein anhaltender Vorgang, welcher die ganze Lebensdauer des Projekts überdauern kann und mit vielen Beteiligten zu tun haben kann. Natürlich handelt es sich dabei zum Teil auch um die Frage eine aktuelle Dokumentation zu haben (siehe „Dokumentation“ im Kapitel Kapitel 2, Der Einstieg) und weisen Sie Leute darauf hin. Es ist aber auch viel mehr als das; die Abschnitte die folgen, behandeln diese Strategie im detail.
Typischerweise, werden alle Kommunikationen in einem Open-Source-Projekt (außer manchmal IRC-Unterhaltungen) archiviert. Die Archive sind öffentlich, können durchsucht werden und referenzen darauf bleiben Stabil: Dass heißt, sobald ein Stück Information unter einer bestimmten Adresse aufgezeichnent wird, bleibt es ewig an dieser Adresse.
Benutzen Sie diese Archive so viel wie möglich, und so auffällig wie möglich. Selbst wenn Sie die Antwort auf eine Frage aus dem Kopf wissen, wenn Sie denken, dass es eine Referenz auf die gleiche Frage in den Archiven gibt, welche die Antwort beinhaltet, nehmen Sie sich die Zeit es auszugraben und zu präsentieren. Jedes mal wenn Sie das auf eine öffentlich sichtbare Art tun, lernen manche Leute zum ersten mal, dass es die Archive gibt, und sie zu durchsuchen, Antworten hervorbringen kann. Indem Sie auf die Archive referenzieren, bestärken Sie auch die soziale Norm, Informationen nicht zu duplizieren. Warum die gleiche Antwort an zwei verschiedenen Stellen haben? Wenn die Anzahl der Stellen an der es gefunden werden kann, auf ein minimum beschränkt wird, werden Leute die es vorher gefunden haben sich eher daran erinnern wonach sie suchen müssen um es wieder zu finden. Gut platzierte Referenzen tragen auch allgemein zu der Qualität der Suchergebnisse bei, da Sie den Rang der referenzierten Ressourcen in Suchmachinen erhöhen.
Es gibt Zeiten, wann die Verdopplung von Informationen jedoch Sinn macht. Nehmen wir zum Beispiel an, es gäbe bereits eine Rückmeldung in den Archiven, nicht von Ihnen, welche sagt:
Es scheint, dass Ihre Scanley-Indexe verfrobbt wurden. Führen Sie diese Schritte aus, um sie zu entfrobben: 1. Schalten Sie den Scanley-Server aus. 2. Lassen Sie das 'Entfrobb'-Programm, welches mit Scanley ausgeliefert wird, aus. 3. Starten Sie den Server.
Monate später, sehen Sie dann eine weitere Nachricht, welche andeutet, dass die Indexe von jemand verfrobbt wurden. Sie suchen in den Archiven und finden obige Rückmeldung, sehen aber, dass ein paar Schritte Fehlen (vielleicht aus versehen, oder weil die Software sich, seitdem die Nachricht geschrieben wurde, geändert hat). Die eleganteste Art das zu handhaben, ist es eine neue vollständigere Nachricht zu schreiben, und die alte Information explizit als obsolet zu markieren, indem Sie es erwähnen:
Es scheint, dass Ihre Scanley Indexe verfrobbt wurden. Wir haben dieses Problem im July gesehen und H. Mustermann schrieb eine Lösung bei http://blahblahblah/blah. Unten ist eine vollständigere Beschreibung wie Sie Ihre Indexe entfrobben können, basierend auf der Anleitung von H. Mustermann aber ein wenig erweitert: 1. Schalten Sie den Scanley-Server aus. 2. Wechseln Sie zum Benutzer, unter dem Scanley normalerweise läuft. 3. Lassen Sie mit diesem Benutzer das 'Entfrobb'-Programm über die Indexe laufen. 4. Lassen Sie Scanley per Hand laufen, um zu sehen, ob die Indexe jetzt funktionieren. 5. Starten Sie den Server neu.
(In einer idealen Welt wäre es möglich, eine Anmerkung an die alte Nachricht anzuhängen, welche sagt, dass eine neuere Version der Information zur Verfügung steht, und auf die neue Nachicht hinzuweisen. Mir ist allerdings keine Archivierungssoftware bewusst, welche eine "obsolet durch" Funktion anbietet, vielleicht wäre es ein wenig schwierig, auf eine Art zu implementieren, welche die Vorgabe eines Archivs, eine wortgetreue Aufzeichnung zu sein, nicht verletzen würde. Das ist ein weiterer Grund, warum es eine gute Idee ist, Webseiten zu erstellen, die der Beantwortung von häufigen Fragen gewidmet sind.)
Archive werden wahrscheinlich am häufigsten nach Antworten zu technischen Fragen durchsucht, ihre Bedeutung für das Projekt geht jedoch weit darüber hinaus. Wenn die formalen Richtlinien eines Projekts seine in einer Satzung festgelegten Gesetze sind, sind die Archive seine allgemeinen Gesetze: Eine Aufzeichnung aller Diskussionen die geführt wurden, und wie sie erreicht wurden. Bei jeder wiederkehrenden Diskussion, ist es heutzutage quasi bindend, mit einer Suchen in den Archiven anzufangen. Das erlaubt es Ihnen, die Diskussion mit einer Zusammenfassung des derzeitigen Standes anzufangen, Einsprüche vorauszuahnen, Konterargumente vorzubereiten, und möglicherweise Sichtweisen zu entdecken, an der Sie noch nicht gedacht hatten. Die anderen Beteiligten, werden auch erwarten , dass Sie eine Durchsuchung des Archivs gemacht haben. Selbst wenn vorangehende Diskussionen nirgendwo hingeführt haben, sollten Sie Verweise darauf einbeziehen, wenn Sie das Thema wieder aufgreifen, damit Leute sich selber davon überzeugen können a) dass sie nirgends hingeführt haben, und b) dass Sie Ihre Hausaufgaben gemacht haben, und desshalb wahrscheinlich etwas sagen, was noch keiner zuvor gesagt hat.
Alle vorhergehenden Ratschläge gelden für mehr als nur die Archive von Mailverteilern. Bestimmte Informationsstücke an einer stabilen, leicht auffindbaren Adresse zu haben, sollte ein Organisationsprinzip alle Informationen des Projekts sein. Lass uns die FAQ des Projekts als Fallstudie betrachten.
Wie nutzen Leute eine FAQ?
Sie wollen es nach bestimmten Worten und Begriffen durchsuchen.
Sie wollen darin stöbern, Informationen aufsaugen, ohne zwangsläufig nach Antworten zu bestimmten Fragen zu suchen.
Sie erwarten, dass Suchmachinene wie Googel über den Inhalt der FAQ bescheid wissen, damit Suchergebnisse Einträge der FAQ beinhalten können.
Sie wollen Leute direkt auf bestimmte Einträge in der FAQ verweisen können.
Sie wollen neues Material zu der FAQ hinzufügen können, bedenken Sie aber, dass das sehr viel weniger geschiedt, als die Antworten aufgerufen werden – in einer FAQ wird sehr viel öfter geschieben als gelesen.
Punkt 1 impliziert, dass die FAQ in irgend einem textuellen Format zur verfügung stehen sollte. Punkte 2 und 3 implizieren, dass die FAQ als HTML Seite zur verfügung stehen sollte, zusätzlich impliziert Punkt 2, dass diese HTML Datei auf eine lesbare Art aufgebaut sein soll, (d.H. Sie werden etwas Einfluss auf sein Aussehen), und sollte ein Inhaltsverzeichnis haben. Punkt 4 bedeutet, dass jeder einzelne Eintrag in der FAQ einen HTML benannten Verweis (en. "anchor") zugewiesen haben sollte, ein tag welches es Leute erlaubt, eine bestimmte Stelle in der Seite auf eine bequeme Art zu erreichen (siehe „Versioniere alles“ im Kapitel Kapitel 3, Technische Infrastruktur), in einem Format welches leicht zu bearbeiten ist.
Die FAQ zu formatieren, ist ledigleich eines der Beispiele, wie Sie eine Ressource vorzeigbar machen können. Die gleichen Eigenschaften – direkte Durchsuchbarkeit, Verfügbarkeit für größere Suchmaschinen, stabile Referenzen, und (wo möglich) Bearbeitbarkeit – gelten für andere Webseiten, den Quellcode-Baum, den Bugtracker usw. Es ist zufällig so, dass die meiste Software zur Archivierung von Mailinglisten schon lange erkannt haben, wie wichtig diese Eigenschaften sind, weshalb Mailverteiler dazu neigen, diese Funktionen von sich aus eingebaut zu haben, während andere Formate unter Umständen etwas zusätzliche Mühe seitens des wartenden (Kapitel 8, Leitung von Freiwilligen behandelt, wie Sie diese Bürde der Wartung über viele Entwickler verteilen können).
Während das Projekt Geschichte und Komplexität ansammelt, nimmt die Menge an Daten zu, die ein neuer Teilnehmer sich aneignen muss. Solche die schon seit langen bei dem Projekt sind, konnten die Konventionen des Projekts im laufe der Zeit lernen und erfinden. Sie werden sich oft nicht der riesigen Menge an Traditionen die sich angesammelt hat bewusst sein, und mögen überrascht sein, wie viele Fehlschritte neue Mitglieder scheinbar machen. Natürlich, liegt das nicht daran, dass die Neuen von einer schlechteren Qualität sind als vorher; es ist lediglich, dass Sie einer größeren bürde der kulturellen Anpassung als in der Vergangenheit gegenüberstehen.
Die Traditionen, die ein Projekt ansammelt haben genau soviel damit zu tun, wie man komunizieren und Informationen bewahren, wie es um die Festhaltung von Standards und andere technische Kleinigkeiten geht. Wir haben uns bereits beide Standards im Kapitel „Entwickler-Dokumentation“ sowie Kapitel 2, Der Einstieg und „Schriftliche Regeln“ im Kapitel Kapitel 4, Soziale und politische Infrastruktur jeweils, und mit Beispielen angeschaut. In diesem Abschnitt, geht es darum, wie man solche Richtlinien aktuell hält, während das Projekt sich weiter entwickelt, insbesondere Richtlinien darüber, wie Kommunikation gehandhabt wird, denn das sind diejenigen die sich am meisten ändern wärend das Projekt an Größe und Komplexität zunimmt.
Erstens, halten Sie ausschau danach, wie Leute verwirrt werden. Wenn Sie die gleichen Situationen immer wieder auftauchen sehen, insbesondere bei neue Beteiligten, ist die Wahrscheinlichteit groß, dass eine Richtlinie dokumentiert werden muss, es aber noch nicht ist. Zweitens, werden Sie nicht müde die gleichen Sachen immer wieder zu sagen, und klingen Sie nicht, als würden Sie langsam davon müde werden. Sie und die anderen Verteranen im Projekt werden sich oft wiederholen müssen; es ist ein unausweichliche Nebenwirkung von dem Ankommen von Neuankömmlinge.
Jede Webseite, jede Nachrich im Mailverteiler, und jeder IRC-Kanal sollte als eine Werbefläche betrachtet werden – nicht für kommerzielle Werbung, sondern für Werbung über die Ressourcen Ihres eigenen Projekts. Was Sie auf dieser Fläche anbringen, hängt ab von der Demographie von denen die es wahrscheinlich lesen werden. Ein IRC-Kanal für Benutzerfragen zum Beispiel, wird wahrscheinlich Leute anlocken, die noch nie zuvor mit dem Projekt zu tun hatten – oftmals jemand der eben erst die Software installiert hat, und eine Frage hat, die er gleich beantwortet haben möchte (schließlich hätte er es statt dessen an den Mailverteiler schicken können, wenn es hätte warten können, was wahrscheinlich weniger von seiner Zeit insgesamt in anspruch genommen hätte, obwohl es länger gedauert hätte, bis er eine Antwort erhalten hätte). Leute machen für gewöhnlich keine permanente Investition in einem IRC-Kanal; sie tauchen auf, stellen ihre Frage und gehen wieder.
Desshalb, sollte das Thema des Kanals auf Leute abgesehen sein, die technische Fragen genau jetztüber die Software haben, eher als sagen wir, Leute die sich vielleicht auf längere Sicht an dem Projekt beteiligen wollen und für die Richtlinien für den Umgang innerhalb der Gemeinschaft eher angebracht wären. Ein wirklich betriebsammer Kanal handhabt es folgendermaßen (Vergleichen Sie es, mit dem früheren Beispiel in „IRC / Echtzeit-Nachrichtendienste“ im Kapitel Kapitel 3, Technische Infrastruktur):
Sie reden jetzt in #linuxhelp Das Thema für #linuxhelp ist Bitte LESEN Sie http://www.catb.org/~esr/faqs/smart-questions.html && http://www.tldp.org/docs.html#howto BEVOR Sie Fragen stellen | Regeln für den Kanal finden Sie bei http://www.nerdfest.org/lh_rules.html | Bitte schauen Sie sich http://kerneltrap.org/node/view/799 bevor Sie Fragen über einen Upgrade nach Kernel 2.6.x stellen | Speicher Abfrage möglich: http://tinyurl.com/4s6mc -> update nach 2.6.8.1 oder 2.4.27 | hash algo Katastrophe: http://tinyurl.com/6w8rf | reiser4 weg
Bei Mailverteilern ist die "Werbefläche" eine kleine Fußnote, die an jeder Nachricht angehängt wird. Die meisten Projekte schreiben Anweisungen zur Anmeldung/Abmeldung dort, und vielleicht einen Hinweis auf die Webseite des Projekts oder auch von der FAQ. Sie denken vielleicht, das jeder der an dem Veriteiler angemeldet ist, wissen würde, wie man diese Informationen findet, und das ist wahrscheinlich auch der Fall – aber viel mehr Leute als nur die angemeldeten sehen diese Nachrichten des Verteilers. Auf eine archivierte Nachricht, kann von vielen Stellen aus verwiesen werden; tatsächlich werden manche Nachrichten derart bekannt, dass sie letztendlich mehr Leser erhält, als der gesamte Verteiler angemeldete Nutzer hat.
Formatierung kann einen großen Unterschied machen. Im Subverison-Projekt zum Beispiel hatten wir eingeschränkten Erfolg bei der Verwendung der Methode zur Filterung von Bugs, beschrieben in „Vor-Filterung des Bugtrackers“ im Kapite Kapitel 3, Technische Infrastruktur. Viele falsche Bug-Meldungen wurden immer noch von unerfahrenen Personen eingereicht, und jedes mal, als das geschah, musste der Absender auf genau die gleiche Art aufgeklärt werden, wie die 500 Personen vor ihm. Eines tages, nahdem bei einem unserer Entwickler schließlich der Faden gerissen war, und irgend einen armen Nutzer zugeflamed hatte, der die Richtlinien für den Bugtracker nicht sorgfältig genug gelesen hatte, entschied sich ein anderer Entwickler, dass dieses Muster schon viel zu lange gelaufen war. Er schlug vor, dass wir die erste Seite des Bugtrackers neu formatieren sollten, so dass der wichtigste Teil, die Vorgabe den Bug zuerst auf dem Mailverteiler oder im IRC zu diskutieren, vor man einen Bug meldet, in riesigen, fetten, roten Buchstaben auf einem gelben Hintergrund, in der Mitte der Seite über alles andere stehen würde. Das machten wir (Sie können das Ergebnis bei folgender Seite sehen http://subversion.tigris.org/project_issues.html), und das Ergebnis, war ein merklicher Abfall in der Anzahl der falschen Bug-Meldungen. Wir bekommen sie natürlich immer noch – das wird immer der Fall sein – aber die Menge ist wesentlich weniger geworden, selbst wärend die Anahl der Nutzer zunimmt. Die Folge ist, dass die Bug-Datenbank nicht nur weniger Müll enthält, sondern, dass diejenigen die auf diese Meldungen reagieren, besser gelaunt bleiben und eher freundlich bleiben, wenn sie auf einer der nunmehr seltenen Falschmeldungen reagieren. Das verbessert sowohl das Erscheinungsbild des Projekts als auch die psychische Verfassung seiner Freiwilligen.
Die Lektion die wir hierraus ziehen konnten war, dass es nicht ausreichte, die Richtlinien einfach nur nieder zu schreiben. Wir mussten sie auch dort platzieren wo sie von denjenigen gefunden werden, die sie am meisten brauchen, und sie so formatieren, dass ihr status als Einführungsmaterial sofort für Personen klar wird, die noch nicht mit dem Projekt vertraut sind.
Statische Webseiten sind nicht die einzige Ort um für die Bräuche des Projekts zu werben. Eine bestimmte Menge an interaktiver Kontrolle (im sinne von freundlichen Hinweisen, nicht grober Zurechtweisung) ist auch notwendig. Jede Überprüfungm auch die Überprüfung von Commits, beschrieben in „Code Review“ im Kapitel Kapitel 2, Der Einstieg, sollten auch eine Evaluierung in wiefern es mit den Normen des Projekts übereinstimmt oder nicht, insbesondere im Bezug auf Konventionen über die Kommunikation.
Ein weiteres Beispiel aus dem Subversion-Projekt: Wie einigten uns auf die Konvention wonach "r12908" für "Revision 12908 des Projektarchivs der Versionsverwaltung." Das klein geschriebene vorangehende "r" ist einfach zu schreiben und da es lediglich die halbe höhe der Zahlen ist, ergibt es einen leicht zu ekennnenden Textblock, wenn man es mit den Zahlen kombiniert. Sich auf diese Konventien zu einigen, bedeutet natürlich nicht, dass jeder gleich anfangen wird, sie gleich zu benutzen. Deshalb, wenn eine Commit-E-Mail mit folgendem Kommentar eintrifft:
------------------------------------------------------------------------ r12908 | qsimon | 02-02-2005 14:15:06 -0600 (Mit, 02 Feb 2005) | 4 Zeilen Patch vom Freiwilligen H. Mustermann <hmustermann@gmail.com> * trunk/contrib/client-side/psvn/psvn.el: Einige Rechtschreibfehler in revision 12828 behoben. ------------------------------------------------------------------------
...gehört es zur Überprüfung des Commits, zu sagen "Übrigens, benutze bitte die 'r12828', nicht die 'revision 12828' schreibweise um auf vergangene Änderungen zu verweisen." Das ist nicht einfach nur pedantisch; es ist genau so wichtig um es automatisch parsen zu können, wie für die menschliche Leserschaft.
Indem Sie das allgemeine Prinzip verfolgen, dass es kanonische Methoden geben sollte, um auf häufige Entitäten zu verweisen und dass man diese verweis Methoden überall auf eine konsistente Art verwenden sollte, exportiert das Projekt in Wirklicheit gewisse Standards. Diese Standards ermöglichen es andere, Werkzeuge zu schreiben, welche die Kommunikationen des Projekts auf andere brauchbarere Arten zu presentieren – zum Beispiel könnte eine Revision mit dem Format "r12828" in einen Link zu der Seite des Projektarchivs verwandelt werden. Das wäre schwieriger, wenn die Revision als "revision 12828" geschrieben würde, sowohl weil diese Form durch einen Zeilenumbruch getrennt werden könnte, und weil es weniger eindeutig ist (das Wort "revision" wird häufig alleine erscheinen, und gruppen von Zahlen erscheinen heufig alleine, wohingegen die Kombination "r12828 sich nur auf eine Revisionsnummer beziehen kann). Ähnliche Bedenken gelten für die Meldungsnummern im Bugtracker, FAQ Einträge (tipp: Benutzen Sie eine URL mit einem benannten Verweis, wie in Benannte Verweise und ID-Attribute beschrieben), usw.
Selbst bei Einträgen, wo es keinen offensichtlichen kurze, kanonische Form gibt, sollten Leute dazu ermutigt werden, wesentliche Informationen einheitlich anzugeben. Wenn man zum Beispiel auf eine Nachricht im Mailverteiler verweist, geben Sie nicht nur den Absender und die Überschrift an; geben Sie auch die URL im Archiv und den Message-ID-Header an. Letzteres erlaubt es Leute die ihre eigene Kopie des Mailverteilers haben, (manche Leute halten offline Kopieen, zum Beispiel auf einem Laptop für die Nutzung auf Reisen) eindeutig die richige Nachricht zu identifizieren, selbst wenn sie keinen Zugriff auf die Archive haben. Der Absender und die Überschrift würden dazu nicht ausreichen, weil dieselbe Person vielleicht mehrere Nachrichten im selben Thread schreibt, sogar am selben Tag.
Je mehr ein Projekt wächst, desto wichtiger wird diese Art von Konsistenz. Konsistent bedeutet, dass überall wo Leute hinschauen, sie die gleichen Muster in verwendung sehen, also wissen sie auch sie selber zu befolgen. Das wiederum, verringert die Anzahl der Fragen die sie stellen müssen. Die Bürde millionen Leser zu haben ist nicht größer, als die einen zu haben; Probleme der Skalierbarkeit fangen nur dann aufzutreten, wann ein gewisser Prozentsatz dieser Leser Fragen stellen. Wärend ein Projekt wächst, muss es desshalb diesen Prozentsatz verringern, indem es die Dichte und Verfügbarkeit von Informationen erhöht, damit jede beliebige Person eher das findet, wonach sie sucht, ohne fragen zu müssen.