Ein Wiki für alles, was kein Blogeintrag ist

Meine Seite hatte einen Blog. Was ihr fehlte, war ein Ort für alles, was kein Datum hat.

Der Unterschied ist der Kern dieses Eintrags: Ein Blogeintrag beschreibt einen Zeitpunkt. Ein Wiki-Eintrag beschreibt einen Zustand.

Ein Text über die Umstellung meiner Datenbank gehört in den Blog — er hat ein Datum, eine Vorgeschichte, eine Entscheidung. Eine Übersicht darüber, welche Einstellungen meine Datenbank braucht, gehört ins Wiki: Sie hat kein Datum, sie hat einen aktuellen Stand, und wenn sich etwas ändert, wird sie geändert und nicht ergänzt.

Warum das ein Unterschied ist

Ich habe eine Zeit lang versucht, beides im Blog zu machen. Das führt zu zwei Problemen:

Veraltete Einträge, die trotzdem gefunden werden. Ein zwei Jahre alter Beitrag über eine Konfiguration steht bei einer Suche ganz oben, obwohl der Inhalt längst falsch ist. Nachträglich ändern kann man ihn nicht, ohne das Datum zur Lüge zu machen.

Nachträge, die niemand liest. Die übliche Notlösung sind Aktualisierungshinweise am Anfang. Nach dem dritten stimmt der Text nicht mehr mit sich selbst überein.

Ein Wiki löst das, weil dort Änderung der Normalfall ist. Es gibt keine Erwartung, dass ein Eintrag den Stand von damals wiedergibt — es gibt die Erwartung, dass er den Stand von heute wiedergibt.

Was bei mir hineingehört

Nachschlagewissen zu meinen eigenen Systemen. Welche Dienste laufen wo, welche Ports, welche Zugänge — natürlich ohne Geheimnisse selbst.

Anleitungen für Vorgänge, die ich selten mache. Einen neuen Dienst veröffentlichen, ein Zertifikat erneuern, eine Datenbank umziehen. Alles, wo ich beim dritten Mal wieder überlegen muss.

Wissen, das nicht zu einem Projekt gehört. Konventionen, Muster, Vergleiche von Werkzeugen. Die Sorte Notiz, die man sonst in Lesezeichen ablegt und nie wiederfindet.

Später auch: Handbücher für Sachen, die andere benutzen. Zu dem Zeitpunkt war das noch nicht absehbar. Ein Jahr später ist genau daraus der nützlichste Teil geworden.

Was ich mir vom Aufbau her überlegt habe

Kategorien statt Ordnerhierarchie. Tiefe Ordnerstrukturen führen zu der Frage, wo etwas hingehört — und wenn man sie nicht in zwei Sekunden beantworten kann, wird der Eintrag nicht angelegt. Kategorien plus Verweise untereinander sind flexibler.

Verweise sind wichtiger als Struktur. Der Wert eines Wikis entsteht dadurch, dass ein Eintrag auf andere zeigt. Wer beim Schreiben verlinkt, baut ein Netz, in dem man sich bewegen kann — statt eines Regals, in dem man suchen muss.

Suche muss gut sein. Bei einem Wiki mit zwanzig Einträgen ist eine Liste ausreichend. Bei hundert nicht. Volltextsuche über Titel, Kurzfassung und Inhalt, ohne die Seite neu zu laden.

Entwurfszustand. Etwas anlegen können, ohne dass es sofort öffentlich ist. Diese Idee habe ich aus dem Content-System übernommen, das ich zwei Jahre vorher wieder rausgeworfen hatte — sie war einer der Punkte, die ich daran gut fand.

Was ich weggelassen habe

Keine Versionshistorie mit Vergleichsansicht. Klingt naheliegend bei einem Wiki. Für einen einzelnen Autor ist es Ballast — ich brauche keine Nachvollziehbarkeit darüber, wer was geändert hat, wenn ich es immer selbst war. Eine schlichte Fassungsspeicherung reicht, um versehentliche Löschungen rückgängig zu machen.

Keine Diskussionsseiten, keine Freigabeabläufe, keine Rollen. Alles Dinge, die ein Wiki im klassischen Sinn ausmachen und bei einer Person keinen Zweck haben.

Was das zeigt: „Wiki" ist bei mir eher eine Textsammlung mit Suche und Verweisen als das, was der Begriff sonst bedeutet. Das ist in Ordnung — der Begriff beschreibt die Form, nicht die Organisation dahinter.

Die Einträge, die ich zuerst geschrieben habe

Um dem leeren System zu entkommen, habe ich mir vorgenommen, zwanzig Einträge zu schreiben, bevor ich weiter an der Technik arbeite. Die ersten waren:

Abläufe, die ich selten mache. Einen neuen Dienst veröffentlichen. Ein Zertifikat prüfen. Eine Datenbank umziehen. Alles, wo ich beim dritten Mal wieder nachdenken muss.

Zugänge und Orte. Welcher Dienst läuft wo, welcher Port, welches Volume, wo liegen die Protokolle. Keine Geheimnisse — nur die Landkarte.

Entscheidungen mit Begründung. Warum diese Datenbank, warum kein zusätzlicher Dienst, warum diese Struktur.

Fallen, die mich schon einmal erwischt haben. Die Konfigurationsdatei, die beim Herunterfahren überschrieben wird. Der Schalter, der auf dem Zielsystem stehen muss.

Die vierte Kategorie ist die, die ich am häufigsten aufrufe. Sie besteht aus lauter Kleinigkeiten, die man einmal mühsam herausfindet und danach zuverlässig vergisst.

Was ein Wiki von einem Blog unterscheidet — praktisch

Die theoretische Unterscheidung ist klar: Zeitpunkt gegen Zustand. In der Praxis zeigt sie sich an einem einzigen Verhalten: Was passiert, wenn sich etwas ändert?

Bei einem Blogeintrag: Es entsteht ein neuer Eintrag. Der alte bleibt stehen und bleibt richtig — für seinen Zeitpunkt.

Bei einem Wiki-Eintrag: Der bestehende wird geändert. Was vorher dort stand, ist nicht mehr interessant, weil es nicht mehr gilt.

Wer das durcheinanderbringt, bekommt zwei unangenehme Zustände: einen Blog voller nachträglich korrigierter Beiträge, die ihren Zeitbezug verlieren — oder ein Wiki mit Einträgen wie „Update vom März: gilt nicht mehr", das nach zwei Jahren aus Widersprüchen besteht.

Meine Faustregel beim Schreiben: Wenn ich in einem Jahr wollen würde, dass dieser Text anders dasteht, gehört er ins Wiki. Wenn ich wollen würde, dass er so stehen bleibt, in den Blog.

Wo ich stehe

Ich schreibe diesen Eintrag, während der Wiki-Bereich noch nicht öffentlich ist. Datenmodell steht, Oberfläche steht in Grundzügen, Inhalte gibt es fast keine.

Und genau das ist der Punkt, an dem solche Vorhaben normalerweise sterben: Ein leeres System, das gepflegt werden will. Ich nehme mir deshalb vor, die ersten zwanzig Einträge zu schreiben, bevor ich weiter an der Technik arbeite. Ein Wiki mit zwanzig echten Einträgen und mittelmäßiger Suche ist nützlich. Eines mit perfekter Suche und drei Beispieltexten ist es nicht.