Hallo Swen,

Du meist wirklich die Doku wird im Wiki auch _gepflegt_?

was _ich_ meine, ist gar nicht wichtig. Es wurde als Argument für den Einsatz eines Wikis genannt, dass das Redaktionsteam "offensichtlich" nicht nachkommt, CSS und neue HTML-Tags zu dokumentieren - und daran kann sich ja durch ein auf Feature-Artikel und Forum-Auslese limitiertes Wiki nicht wirklich etwas ändern, weil "keiner" dort nachsieht, wenn er in SelfHTML so grundlegende Informationen nicht findet. (Und zwar zu Recht - es ist nicht Aufgabe der Feature-Artikel, unvollständige bzw. veraltete Informationen in SelfHTML zu überschreiben, sondern eher spezielle Anwendungsfälle zu vertiefen, finde ich.) Basierend auf dieser Zielsetzung bin ich ja überhaupt nur in die Diskussion eingestiegen, mit Konverterskript-Idee usw.

Anderseits hat die buchähnliche Form, die SELFHTML bislang hat, ihre didaktischen Vorzüge und erreicht wegen dieser eher tradierten Form viele Leser, die ein Wiki als "neumodischen Krams" abtun.

Es ist durchaus machbar, diese Form im Wiki zu erhalten (durch zusätzliche Infrastruktur, etwa "weiter"-Links am Ende jedes Artikels, ein manuell zu pflegendes Inhaltsverzeichnis etc.) - dies erhöht allerdings signifikant die erforderlichen Kenntnisse zur Pflege des Dokuments und macht damit wesentliche Vorteile der Verwendung eines Wikis (das dann zum Versionskontrollsystem "abgewertet" wird) wieder zunichte.

Ich hätte Angst, dass Wikibeiträge mit ihren unweigerlich verschiedenen Schreibstilen diese Leselust zu Grabe tragen.

Dies "nachzupolieren" halte ich wiederum für _keine_ "Sklavenarbeit", sondern genau für den Job, den ich bei einer "Redaktion" in guten Händen sehen würde. Ein Redakteur, der die Materie grundsätzlich verstanden hat, kann diese Art der "Normalisierung" durchführen; der neue Beitrag erspart ihm aber möglicherweise einen wesentlichen Teil der Recherche-Arbeit, die der Redakteur als alleiniger Autor dieses Artikels zusätzlich auch noch hätte leisten müssen... dies ist ja die Hoffnung bei der Verwendung eines Wiki: Die Autoren brechen die groben Steine aus dem Bergwerk los, und die Redakteure schleifen sie ab. Wobei Teilfunktionen der Redaktionsarbeit wiederum outgesourced werden können - wenn ich beim Lesen in SelfHTML einen gefundenen Tippfehler sofort reparieren dürfte, würde ich es zweifellos tun. (Nicht, dass arg viele drin wären... ;-)

Was sich gegenüber dem bisherigen Verfahren für Feature-Artikel ändern würde, ist folgendes:
1. Es wäre auch SelfHTML selbst von der Aktualisierbarkeit betroffen (zweifellos positiv und vielleicht das Hauptziel des Projekts).
2. Beta-Versionen der "endgültigen" Artikel wären automatisch bereits sichtbar (hat Vor- und Nachteile).
3. auch rein destruktive Beiträge wären nach diesem "commit then review"-Verfahren möglich (zweifellos negativ).
4. Gewisse technische Einschränkungen der Wiki-Möglichkeiten gegenüber frei wählbaren Dateiformaten und der proprietären Suchfunktion (zweifellos negativ).
Die Gewichtungsfunktion seiner subjektiven Bewertung all dieser Effekte muss sich jeder selber definieren.

Ich würde übrigens ein SelfHTML in Wiki-Form mit readonly-Artikeln, aber der Wiki-eigenen Diskussions-Funktion für jeden Artikel auch schon für ein interessantes Projekt halten - das wäre "review then commit", mit weniger Sabotage-Möglichkeiten und weniger Kraut und Rüben beim Stil der veröffentlichten Artikel. Wer dann ein fehlendes HTML-Tag ergänzen will, muss allerdings zusätzlich nachdenken, wo das Tag eigentlich hingehört im didaktischen Aufbau des bestehenden Gesamtwerkes. Es käme etwas Ähnliches heraus wie das mySQL-Manual mit seiner "Comment"-Funktion am Ende eines jeden Kapitels.

Viele Grüße - Michael