• Anzeigen
• Bearbeiten
• Versionen
• Druckansicht
• Rückverweise

Motivation für Wiki-Gruppen

für die Liste aller Seiten

Was spricht für Wiki-Gruppen?

Erklärungen zu Wiki-Gruppen von Patrick R. Michaud in den [pmwiki-users] mailing-listen

"Im Verlaufe der Zeit haben Leute nach etwas gefragt, das den Unterschied zwischen Wiki-Gruppen und Wiki-Farmen verdeutlichen könnte, insbesondere die jeweiligen Vor- und Nachteile, und ich stimme zu, dass eine solche Dokumentation nötig ist." Aber bisher bin ich nicht dazu gekommen, eine kurzgefasste Beschreibung zu verfassen. In Ermangelung einer solchen werde ich einfach von der Geschichte, den Motivationen und den Konzepten hinter den beiden berichten, und vielleicht können wir das alle verfeinern zu etwas, das auf einer Seite gut funktioniert – oder vielleicht reichen ja schon die Geschichten.

Für diese Nachricht werden ich vor allem über Wiki-Gruppen sprechen und Wiki-Farmen in einer anderen Nachricht behandeln (weil die in der Entwicklung später kamen). Und ich werde die Dinge schlicht als Erzählung – als geschichtliche Entwicklung – präsentieren, da dies halt das Beispiel ist, von dem ich ausgegangen bin, als ich darüber nachdachte, wie Wiki-Gruppen funktionieren könnten. Ich bitte schon im Vorhinein um Entschuldigung für die Länge der Erzählung – wenn ich einen guten Weg wüsste, sie zu kürzen, hätten wir unsere Beschreibung.

Im September 2001, als ich die erste Version von PmWiki (pmwiki-0.1) schrieb, war mein Wunsch, dass die verschiedenen Gruppen, mit denen ich in der Universität und sonst wo zusammen gearbeitet habe, "Wiki"-Konzepte benutzen könnten, um Webseiten zu pflegen, die andernfalls ungepflegt sein würden. Ganz allgemein war das umfassende Thema, dass jede dieser Websites seinen eigenen ausgewiesenen Webmaster hatte, aber dass die Pflege der Website nur ein kleiner Teil der Pflichten jedes dieser Webmaster war. Darüber hinaus stellte der Webmaster einen Flaschenhals dar, wo selbst dann, wenn es mehrere Leute gab, die gewillt waren den Seiteninhalt zu aktualisieren, sie immer die Änderungen an den Webmaster liefern mussten, damit sie wirksam wurden. Also passierten Aktualisierungen nur spärlich, wenn überhaupt, und die Sites veralteten ("Page rot" ist der gebräuchliche Ausdruck – verrottete Seite).

Da ich der Webmaster für mehrere dieser Sites war, war Alles, was ich machen konnte, um andere zu ermächtigen, die Seiteninhalte zu aktualisieren ohne mich einzubinden, eine gute Sache. Das ist das zentrale Thema hinter der Entwicklung von PmWiki – andere Leute in die Lage zu versetzen, die Arbeit zu machen, die ich sonst hätte machen müssen. :-)

Also schuf ich die erste Version von PmWiki und begann es zu nutzen, um Webseites aufzusetzen und zu pflegen für die verschiedenen Projekte und Gruppen, in denen ich involviert war. Diese schlossen eine Forschungsgruppe, den Informatik-Club, das College, meine akademische Abteilung, jeden der verschiedenen Kurse, die ich abhielt, und schließlich meine eigenen persönlichen Seiten, ein. Anfangs habe ich für jede "Gruppe" eine Kopie von PmWiki installiert, für die ich einen Satz von Seiten im Internet haben wollte.

Ziemlich bald haben andere Leute, Abteilungen, Kursleiter und Organisationen mitbekommen, wie ich Wiki benutzte, um meine Site zu pflegen, und sie alle wollten ihr eigenes Wiki haben. Also kriegte ich sie entweder dazu, Seiten in einem der Wikis einzubauen, die ich schon aufgesetzt hatte, oder ich installierte ihnen woanders eine Kopie der Software, so dass sie sie benutzen konnten.

Mit nur einer Ebene von Seitennamen funktionierte es nicht immer so gut, unabhängige Gruppen zu haben, die sich den gleichen Namensraum teilten. Es konnte nur eine Seite "meineZusammenfassung" geben, und dadurch mussten die Autoren weit vorausplanen, wie sie ihre Seiten und Verweise nennen wollten.

Auch gab es keinen guten Mechanismus, wie man einen Satz von Seiten vorm Ändern schützen konnte – man konnte einzelne Seiten schützen, aber es wurde wirklich ermüdend, wenn es dutzende Seiten zu schützen galt (und zu jeder neuen Seite musste man ein Passwort hinzufügen).

Weil also der einzelne Namensraum nicht so gut funktionierte, ackerte ich weiter an Anfragen zu unabhängigen Wikis. Das bedeutete eine neue Kopie der Software zu installieren, Softwareaktualisierungen zu koordinieren und zu versuchen, hinter all den RecentChanges (aktuellen Änderungen) hinterherzukommen, um sicher zu sein, dass die Dinge gut liefen.

Natürlich lief das genau gegen mein Ziel, andere die Arbeit machen zu lassen. :-) Klar, ich hätte anfangen können, den Leuten die Software auszuhändigen und ihnen zu erklären, wie man sie installiert und pflegt, oder es für Leute möglich zu machen, ihr eigenes Wiki in einer Wikifarm zu erstellen, aber das hätte erfordert, dass andere die gleichen Dinge wissen, die ein Administrator wissen muss, und viele der Leute, die ihr eigenes Wiki haben wollten, hatten noch nicht mal ein Unixaccount.

Was ich *wirklich* haben wollte, war, die >>Autoren<< in die Lage zu versetzen, ihre eigenen "wiki spaces" zu erstellen ohne dass sie Wikiadministratoren werden müssten oder mich bitten müssten, die Dinge für sie zu erledigen. Und ich wollte, dass Gruppen von Leuten in der Lage sind, die Seiten zu erstellen und zu reorganisieren mit einer einfachen Notiz. Damit war das Konzept der Wikigruppen geboren – als Weg für Leute (Nicht-Admins), ihren eigenen Wikispace zu erstellen ohne einen Administrator zu suchen oder einer zu werden.

Eine der Schlüsselideen hinter Wiki-Gruppen war, dass es möglich wäre, jede Gruppe den Autoren "erscheinen" zu lassen, als sei sie von den anderen Wikis der Gruppe getrennt. So sollte jede Gruppe ihre eigenen Passwörter, Header, Footer und Skins haben können. Jede Gruppe sollte ihre eigene "HomePage", "RecentChanges" etc. haben, und für jemanden, der von Wikis wenig weiß, scheint das ein Wiki für sich zu sein. Aber jene, die wussten, was dahinter steckt – und es dauerte nicht lang, bis sie das herausbekommen haben – konnten sich einen gemeinsamen Satz von Dokumentationen, Hilfeseiten, Tipps zum Gebrauch eines Wikis etc. teilen. Und sie konnten außerdem einfach auf relevante Seiten einer anderen Gruppe verweisen (z. B. der Informatikklub konnte auf Seiten der Informatikabteilung verweisen oder auf Kurshinweise in der KursInf1435-Gruppe).

Von meiner Perspektive als ein Administrator war das ein viel besseres Szenario als das originale. Erstens: wenn jemand einen Ort für Wikiseiten haben wollte, musste ich ich nichts weiter installieren, ich sagte ihm einfach, "lege eine neue Seite in einer neuen Gruppe an". Noch besser war, dass sie aufhörten, mich danach zu fragen – denn es gab (außer mir) viele andere, die ihnen sagen konnte, wie man das macht. Bald teilten die Leute mit anderen die Details, wie man Gruppenpasswörter setzt, neue Seiten erstellt, "Skins" mit Hilfe von Groupheader und Groupfooter macht etc. Mein Anteil wurde mehr zur Verbesserung der Software verlagert, zum Aktualisieren weniger Installationen, und zum Hilfe anbieten bei gelegentlichen Problemen oder bei Anfragen zu Features.

Ein weiterer Vorteil der Wiki-Gruppen-Struktur war, dass ich ein ganzes Bündel von Gruppen überwachen konnte über die AllRecentChanges-Seite.

Die Dinge, die seitdem mit Wiki-Gruppen geschehen sind, sind wirklich nur Erweiterungen des originalen Konzepts – z. B. den Autoren zu ermöglichen, spezialisierte Inhaltsabschnitte zu erstellen, ohne notwendigerweise einen Administrator dafür bemühen zu müssen.

Um zu zeigen, wie gut das in der Praxis funktioniert: das Studentenwiki an der Texas A&M University- Corpus Christi hat augenblicklich 5.372 Wiki-Gruppen. Ja, das ist *Gruppen* – es gibt über 180.000 *Seiten* in dem Wiki. Die Kursleiter des Erstjahresprogramms gehen am Anfang mit den Teilnehmern die grundlegenden Dinge durch wie eine persönliche Wiki-Gruppe anlegen, Seiten in der Gruppe bearbeiten und auf andere Seiten verweisen, und die Studenten nutzen das während des ganzen akademischen Jahres für verschiedene Studienarbeiten, für Informationen und für die Zusammenarbeit in Projekten mit anderen Studenten. Die Wikiadministratoren (alle in Teilzeit) haben nichts zu tun mit Gruppen anlegen, eher mit gelegentlichen Problemen durch vergessene Passwörter oder mit dem Aktualisieren der Software. (Und mehrere der Kursleiter in dem Programm haben das Sitepasswort bekommen, so dass sie Probleme mit dem Passwort oder mit Inhalten lösen können ohne einen Administrator anzusprechen.)

Das also ist die Geschichte und die originale Motivation für Wiki-Gruppen. Ihr primäres Feature ist, dass sie erlauben, neue Abschnitte von verwandten Inhalten anzulegen, ohne einen Administrator zu behelligen, dass sie aber immer noch einen "Überblick" über alle Gruppen erlauben.

Mehr über Wiki-Gruppen contra Wiki-Farmen in einer späteren Nachricht.

für die Liste aller Seiten