Ich sehe das Wiki halt nicht als Konkurrenz fürs Forum, sondern als Konkurrenz für die Doku. Und der Punkt ist halt, daß es so einiges gibt, was bereits in der Doku fehlt (im Prinzip ist das mit der V8.1 verbesserte Kapitel über DOM ja immer noch arg unvollständig - an das von 8.0 denke ich nur mit Grausen - und 9.0 ist nicht in Sicht).

Dann musst du es aber auch auf _allen_ Ebenen als dessen Konkurrenz sehen. Du greifst einen einzigen Aspekt heraus, nämlich die inhaltliche Aktualität, wo das Wiki-Modell wahrscheinlich Vorteile bieten würde (vorausgesetzt, die entsprechenden Redakteure sind vorhanden, um die eintreffenden Beiträge nachträglich zu filtern und zu "normalisieren"), aber Du gehst nicht auf die Nachteile ein, welche das Wiki-Modell eben auch mit sich bringen kann:

• Die Erscheinungsform des Wiki als CMS mit einem relativ einfachen Editor-Fenster wird erkauft mit einer relativ einfachen Palette an Formatierungsmöglichkeiten. Diese lässt sich natürlich erweitern, entweder durch direkte HTML-Eingabe (was sowohl der Sabotage als auch dem Style-Wirrwarr Tür und Tor öffnet) oder durch zentrale CSS-Klassen-Definitionen, welche dann genau wieder das Layout-Korsett liefern würden, was das bisherige SelfLayout auch schon geliefert hat - und welche jeder Verfasser neuer Beiträge dann natürlich lernen müsste. Da ihm dies kaum bewusst werden würde (die normale Preview-Funktion liefert zunächste einmal "lesbare" Ergebnisse), müsste ein Layouter-Team alle neuen Beiträge erst einmal neu setzen - und das kostet durchaus Zeit.

• Die in MediaWiki angebotene (und in Wikipedia verwendete) Suche liefert nach meiner bisherigen Erfahrung Links auf Dokumente, nicht auf Dokumentpositionen. Sie ist mit dem bisher für SelfHTML und verwandte Publikationen eingesetzten Konzept der Suche (das die Kapitelstruktur der Dokumente versteht und dieses Wissen auch verwendet) also semantisch nicht kompatibel. Das ist durchaus kein zu vernachlässigender Aspekt, denn gerade die Tatsache, dass die Suche bisher "deep links" in die passenden Kapitel hinein liefern kann, hat sie in die Lage versetzt, gute Ergebnisse auch für beliebig lange Artikel zu liefern, also den Autoren von Self-Kapiteln und Feature-Artikeln freie Hand in Sachen Länge und Datei-Fragmentierung ihrer Werke zu lassen. Dies wäre bei der Wikipedia-Suche nicht der Fall: Für jeden Treffer müsste der Suchende den kompletten Artikel durchlesen, um zu begreifen, wieso die Suchfunktion ihn überhaupt dorthin geschickt hat. Man kann dem natürlich entgegenwirken, indem man SelfHTML in kleinere Häppchen zerlegt (die in Wikis durchaus unterstützte hierarchische Dokumentstruktur alleine reicht dafür eben genau _nicht_), aber das würde eine Umstrukturierung des kompletten Materials nach sich ziehen, was vom Arbeitsaufwand wohl nicht zumutbar wäre (die reine Überführung von SelfHTML aus der HTML-Form in eine Wiki-Codierung wäre über Transformationsskripte zumindest teilweise automatisierbar, soweit kompatible Konzepte vorliegen; dies wäre übrigens ein hübsches Teilprojekt, zu dem Wiki-Fans wie Du mal eine Machbarkeitsstudie z. B. in Perl abliefern könnten - ja, das darfst Du als ein großes "I" verstehen, aber ich empfehle die Lektüre der Quelltexte der bereits existierenden Suchmaschinen-Indexer, welche die dabei erforderliche Parsing-Arbeit bereits leisten können müssen). Also müsste SelfHTML in Wiki-Form mit einer _semantisch_ schlechteren Suchfunktion als das bisherige Angebot leben (und das "kurz bevor" die neue Suchfunktion endlich fertig wird... ;-).

Wikis ermöglichen sicherlich gute Ergebnisse für neue Projekte, bei denen zunächst einmal Leute mit gutem Willen und niedriger Eintrittsbarriere gemeinsam Informationen beitragen wollen und Layout, Navigation, Durchsuchbarkeit, Gesamtstruktur etc. von untergeordneter Bedeutung sind bzw. dynamisch wachsen können. Gerade in diesen anderen Bereichen erfüllt SelfHTML aber bereits hohe Standards, die sich mit einem Wiki nicht so ohne weiteres halten lassen werden. Insofern halte ich das Self-Universum nicht für _prädestiniert_, in ein Standard-Wiki übertragen zu werden. Natürlich bietet ein Wiki gewisse Vorteile beim Arbeiten - aber ein customized CMS, das auf die Bedürfnisse des Self-Universums exakt zugeschnitten wäre, könnte dieselben Vorteile mit weniger Nachteilen bieten.

Deshalb würde ich vor einem Wechsel des grundlegenden Datenmodells zunächst einmal versuchen, die den _Bearbeitern_ wichtigen Eigenschaften von SelfHTML zu definieren und diese als Anforderungsprofil für eine zu findende alternative Darstellungsform verwenden. Die vorliegende Datenmenge ist einfach zu groß, um sich bei der Prokrustes-Methode "Wikipedia verwendet Media-Wiki, also muss das für SelfHTML auch funktionieren" einen Fehlversuch zu leisten.
Das Spannende an einer solchen Anforderungsliste wäre übrigens die relative Priorität der einzelnen Anforderungen. Wie hoch wird heute die Priorität der Eigenschaft, "nach SelfHTML auszusehen", bewertet? Wie hoch die Eigenschaft, mit geringem Aufwand in Buchform transformiert werden zu können? Ich denke, vor der Festlegung auf MediaWiki gäbe es durchaus noch einige interessante Diskussionen über Themen, an welche der Nur-Leser von SelfHTML spontan gar nicht denken würde, zu führen.