Wikis

Um im Team zu arbeiten schätze ich zwei Tools ganz besonders: Ein Issue Tracking System und ein Wiki.
Wikis sind großartig um persönliches, Team- und Organisationswissen zu speichern, teilen, ändern und weiter zu entwickeln. Ein Wiki ist ein lebendiger Garten mit allem, was ein Team, Kollegen, Nutzer oder sonstige Interessierte wissen müssen.
Ein Teamwiki ist meistens nur für Teammitglieder erreichbar, aber man kann mit Wikis auch hervorragend öffentliche Benutzerhandbücher, Lehrbücher, blikis wie dieses hier, klassische Webseiten oder gar Enzyklopädien bauen.

Struktur: Lemma Links und Prosa

Wissen sollte man nicht in Schlagwortlisten, FAQs, Excelsheets oder Blogposts zwingen, sondern in verständliches Prosa fassen. Denn es gibt kein besseres semantisches System als unsere Sprache. Ganze Sätze helfen dem dem Leser den Zusammenhang zu verstehen. Aufzählungslisten, Tabellen oder Graphen sind nur zusätzliche Hilfsmittel.
Stilistische ist der Nachrichtenstil am besten: Der erste Satz, oder auch Absatz, fasst zusammen, worum es auf einer Wikiseite geht. Erst dann beginnen detaillierte Absätze mit den Details.

Wikis ordnen Wissen vor allem in Lemmas. Das sind einfache Begriffe aus der alltäglichen Sprache als Seitennamen. Lemmas müssen kurze, prägnante Begriffe sein: Also nicht "Wie man eine leckeren Apfelkuchen backt" sondern "Apfelkuchen". Natürlich ist die Festlegung auf ein Lemmas sehr subjektiv, aber das ist ok.

Aus diesen Lemmas werden Links erzeugt die zwischen den einzelnen Seiten einen semantischen Kontext schaffen. Bei den meisten Wikis erzeugt man Links mit einer vereinfachten Syntax (z.B.[[Apfelkuchen]]). Der Linktext der URL soll möglichste nahe dem Lemma des Ziels sein. Links darf und soll man gern großzügig setzen. Man sollte jedes mal einen Link setzen, wenn man eine Information an einer Stelle gesucht hat, aber dann doch woanders gefunden hat. So hilft man jedem zukünftigen Suchenden zur richtigen Seite.

Oft haben Wikisoftware auch weitere Strukturmöglichkeiten. Namensräume sieht man als Hierarchie in den URLs, aber sind eingeschränkt, denn jeder Artikel kann nur in einem Namensraum eingeordnet werden. Kategorien haben keinen sprachlichen Kontext und die Benennung ist meist sehr subjektiv. Namensräume und Kategorien sind gute zusätzliche Ordnungseinheiten, aber den Kontext erzeugt man mit Links.

edit!

Wikis leben vom Hinzufügen, Ändern und Spezifizieren von Wissen. Der verpflichtende Wikieintrag muss in jeder Definition of Done verankert sein. Nur so kann man sicherstellen das jede Neuerung auch dokumentiert wird.

No documentation was perfect already at the first attempt, but after numerous iterations and improvements chances are it is better. Und nur durch mutige Änderungen können Andere helfen und verbessern.

Sachliche Verbesserungen soll man nicht "irgendwann mal" machen. Jede fehlende Information, jeden Fehler oder missverständliche Formulierung die man findet, sollte man sofort verbessern. Ich bin zwar kein Fan von Whac-A-Mole Arbeit, also jedem Chat, jeder Mail jedem Gespräch sofort irgendwas zu machen bis die nächste Störung kommt, aber:

• oft sind Verbesserungen sehr kleinteilig und brauchen oft weniger Zeit diese umzusetzen, als sie auf einer Todoliste oder im Issuetracking einzutragen.
• sind Fehler in der Wikikultur zwar erlaubt, aber sollten schnell verbessert werden, um deren Ausbreitung zu vermeiden. Zieht man bei einem Fehler im Wiki den symbolischen Andon-Cord bleibt das Wiki aktuell und bildet das aktuelle Teamwissen ab.
• Die meisten Fehler in jeder Dokumentation findet man im Gespräch mit Anderen, weil etwas fehlt oder missverständlich geschrieben ist. Kann man eine Frage nicht durch sein Wiki möglichst unmissverständlich beantworten, sollte man zuerst sein Handbuch ergänzen und damit dann die Frage beantworten.
• Wikiedits skalieren nachhaltig weil sie nicht nur ein Chat, Frage oder Mail beantworten, sondern gleich die nächste Anfrage mit beantworten.

So wird Wissen sofort und dauerhaft aktuallsiert, anstatt in 1000enden Update-Mails vergessen zu werden.

Aber natürlich kann man sich große Cleanups oder Umbauten gern als Issue für einen ruhigen Freitagnachmittag vormerken.

prüfen

Das Potenzial eines Wikis hängt von einer offenen Kultur, Zusammenarbeit und dem Vertrauen in sein Team ab. Aber auch einer Fehlerkultur und der Möglichkeit Fehler schnell zu beheben. In Wikis kann man genau genommen gar nichts ändern, sondern nur eine neue Version vorschlagen. Ein Wiki ist im Kern eine Versionsverwaltung.

Der großer Vorteile einer Versionsverwaltung ist, das Änderungen und neue Inhalte:

• im peer-review mit Vorgesetzten, erfahrenen Kollegen, neuen Kollegen aber auch Teamexternen (Kunden etc.) verbessert werden.
• schnell und unbürokratisch verbessert werden, anstatt dass Verbesserungsvorschläge langatmig diskutiert werden müssen.

Durch diese niederschwellige, zeitnahe und schnelle Kontrolle von Änderungen ist der offene Ansatz eines Wikis überhaupt erst möglich.

Selbst fehlerhafte Änderungen sind in einem Wiki nicht schlimm, denn ein Fehler,

• der in einem Wiki steht, anstatt nur mündlich die Runde zu machen, ist viel leichter zu verbessern.
• kann auch nur eine andere Perspektive sein und damit die Grundlage für eine konstruktive Diskussion.

Jedes Wiki bietet eine Übersicht der aller letzten Änderungen oder eine persönliche Beobachtungsliste. Diese sollte man genauso zeitnah lesen wie alle anderen Anfragen aus eMails oder Chats. Jede Änderung in einem Wiki ist ein indirekter Hinweis auf etwas Neues, aber auch eine Aufforderung einen Sachverhalt zu verifizieren und zur Kenntnis zu nehmen.

RTFW?

Read the fine Wiki

Ein perfektes Wiki sollte alle Fragen beantworten können. Aber kein Wiki ist jemals perfekt. Wikis sind nie vollständig, Inhalte sind nicht aus allen Sichtweisen beschreiben oder verständlich genug für alle Leser. Auch findet man nicht immer alles sofort, vielleicht auch weil man gar nicht weiß was man suchen soll. Man wird immer Anfragen von Anderen bekommen, auch wenn die bereits an der richtigen Stelle nachgelesen haben.

Teaminterne oder externe Fragen sollte man immer mit einem Zitat und dem dazu passenden link auf das Wiki beantworten. So hat man eine saubere und verständlicher Formulierung zum kopieren. (Ein Firefoxaddon hilft gleichzeitig Text und Link zu kopieren z.B. copytextandurl) Der Fragende kann den Kontext seiner Frage selbst nachlesen und hat eine Referenz für zukünftige Fragestellungen.

Anfragen sind ein perfekter Zeitpunkt um ein Wiki zu verbessern.

So ein Wiki sollte man auch immer selbst nutzen. Selbst dann wenn man eigentlich selbst weiss was drin steht, weil man es rein geschrieben hat. Denn jedesmal wenn man seine eigene Frage mit seinem Wiki beantwortet, überprüft man dessen Inhalt, ob die Frage auch aus anderen Blickwinkeln zu beantworten wäre.

Werkzeug

Ich habe bisher mit Confluence, BlueSpice, Dokuwiki und Tiki gearbeitet. Meine Favoriten sind aber MediaWiki und GitLab Wiki. Meistens benutze ich GitLab Wiki, denn es hat folgenden Vorteile:

• es nutzt feinstes Markdown.
• eine Toolbar die mit dem Markdownsyntax hilft, schnell ein Markdowntabelle anlegt oder wenn man Bilder hochladen, einbetten und clientseitig resizen will.
• schlägt während des Schreibens eines Links ([[Lore…) exisiterende Zielseiten vor.
• hat aber auch Wikifeatures (z.B. page redirects)
• für Teamwikis helfen so Features wie Todo-Listen und mermaid charts für Diagramme.
• und man benötigt keine Datenbank, alle Inhalte sind in einem git repo. So kann man auf einem lokalen clone mit dem Editor seiner Wahl arbeiten und hat immer offlinefirst ein Backup dabei, fast wie bei einem static site generator.

Was Gitlab Wiki noch fehlt ist ein WYSIWYM Markdown-Editor, z.B. SimpleMDE der zeigt die Markdown-Struktur und das fertige Ergebnis.

MediaWiki hingegen ist ein reiner Server-Dienst und MediaWiki-Sytanx ist etwas umständlicher und nicht so schnell wie Markdown. (leider gibt es kaum stabiles Markdown für Mediawiki). MediaWiki bietet jedoch im Vergleich zu GitLab Wiki einige relevante Funktionen:

• Kategorisierung
• Mit Section editing kann ein bestimmter Abschnitt bearbeitet werden. Das hilft vor allem bei sehr langen Seiten einzelne Abschnitte übersichtlich zu bearbeiten.
• Mit der Extension LinkSuggest schlägt Mediawiki während des Schreibens eines Links ([[Lore…) exisiterende Zielseiten vor.
• Transklusionen ermöglichen es Inhalte eines Dokuments in ein anderes Dokument einzubinden.
• benutzerdefiniertes CSS und JS ein lang ersehnter Wunsch in GitLab.
• server-skalierbare Bilder
• Backlinks von anderen Wikiseiten helfen Inhalte im Kontext einer Seite zu finden.

static site generators

Static site generators (SSG) sind ähnlich dem Prinzip von Wikis: Eine Seite Markdown und ein paar strukturierte Daten als yaml, in eine template mit css und js eingepasst und fertig ist die Seite. Ein Seitentitel, ein Lemma, ein URL-path. Viele dieser Seiten mit (Wiki)-links zu einer Website verknüpft. Hosting auf einem good old Webserver oder cloudnative statichost.eu.
Keine Datenbank, keine Anwendung zur Laufzeit, kein Wordpress, Drupal, Joomla oder Typo3. SSGs sind sicherer, laden schneller und sind schneller zu bearbeiten, wenn es sein muss mit allen bash-Raffinessen (grep, sed, awk). Hängt man ein git-repo dahinter, kann man den ganzen git-kungfuu (branching, merging, blaming, stashing…) nutzen und hat mit Mergrequests den perfekten Workflow.

Mit SSGs kann man auch sein Teamwiki machen, auch wenn dann features wie Bilderupload, Kategorisierung, Redirects oder Section editing fehlen.

Abgrenzung

Und warum geht das alles nicht in Microsoft Word, Libre Office, GoogleDocs, MS365 oder Collabra?
Mit Word kann man ein langes Dokument machen. Wikis aber sind viele Seiten, die mit Links gegenseitig in Kontext gesetzt werden.
Eine anständige Versionskontrolle ist nicht möglich. Auch wenn es den Veränderungsmodus in Word gibt, der funktioniert vielleicht technisch, aber noch nie in der Realtät.
Dazu neigen klassische Office Schreibprogramme zum Überladen und sagen dir du brauchst sicher ständig die Serienbrieffunktion sowie weitere 1000 Funktionen, die Möglichkeit "lustige" Word-Art Bildchen einzufügen oder die Einleitung in ComicSans zu setzen. Das sind alles keine features.

Es gibt noch Echtzeit-Online-Editoren wie Etherpad oder HedgeDoc. Die sind super wenn ich wirklich zeitgleich an einem Dokument arbeiten will und helfen in synchronen Arbeitssituationen: Ich hab wirklich in 30 Minuten Abgabetermin und kann nicht Version für Version bearbeiten lassen. Oder Live-Protokolle in der einer Sitzung, wenn alle Teilnehmer und nicht nur ein Protokollant, mitschreiben.
Aber diese Echtzeit-Online-Editoren bearbeiten auch nur einzelne Seiten, nicht mehrer Dokumente im Kontext. Man könnte so ein Echtzeit-Online-Editor zwar als Interface in ein Wiki einbauen, aber die Echtzeitfunktion braucht man nicht für die klassische langfristigen Wissensarbeit.

persönliches Wiki

Aber nicht nur im Team, auch für das persönliche Wissensmanagement ist ein Wiki sinnvoll. Ein persönliches Wiki oder digitales Notizbuch braucht nicht unbedingt einen Serverdienst mit Zugansgberechtigungen, aktuelle Änderungen ect. Es gibt Obsidian oder Joplin mit zahlreichen Funktionen (Wissensgraphen, Loging, Inhaltsverzeichnisse ect), aber das wichtigste ist bei Obsidian ist Markdown und die einzelne untereinander verlinkte Seiten.
Ich nutze dazu, plain Markdown files mit meinem Text-Editor in einem git repository. Zwar habe ich da keine klickbare Verlinkung, aber ich weiss halt dass ich in einer Notiz zum Thema ''Einkaufen'' bei [[Wohnung]] Informationen in der Datei ''Wohnung.md'' finden werde. Auf dem Mobilteil habe ich das alles in GitJournal dabei, dann sogar mit klickbaren Wikilinks.

Alle meine Ideen zu Organisations-Wikis in Wikis in Organisationen.