[Wikide-l] Wikipedia bremsen, Qualitaet sichern

[elwp at gmx.de]

Agon:
> Eine andere Erfahrung aus dem FLOSS-Bereich, die Wikipedia adaptieren 
> könnte, ist die Unterscheidung von stabilen und Entwicklerversionen; 
> Debian macht das optimal mit den offiziellen Zweigen "stable", "testing" 
> und "unstable" sowie dem inoffiziellen Zwei "experimental".

Eine getrennte Entwicklung für geprüfte und ungeprüfte Versionen
lohnt sich nicht. Der Vergleich mit Software-Entwicklung hinkt:
Dort dürfte einer der Hauptgründe für unterschiedliche
Entwicklungszweige nämlich die Abstimmung der Komponenten
aufeinander sein. Das ist bei der Text-Entwicklung nicht so wichtig,
jedenfalls stürzt die Enzyklopädie nicht gleich ab, wenn zwei
Artikel nicht ganz zusammen passen. Ein zweiter wichtiger Grund,
weshalb man bei umfangreichen Software-Projekten Entwicklungszweige
einführt, ist, dass man unbedingt verhindern möchte, dass sich in
die stabile Line unbemerkt und trotz Prüfung neue Fehler durch
neue Features einschleichen. Auch hier liegt die Situation in der
Wikipedia anders: Bislang werden die Artikel ganz ungeprüft
veröffentlicht. Das zu entwickelnde Review-System soll erreichen,
dass die Texte überhaupt erst einmal geprüft werden, und nicht,
dass man einen Hochsicherheitsbereich für einmal geprüfte Artikel
errichtet, in dem nicht einmal durch vertrauenswürdige Prüfer
abgenickte inhaltliche Verbesserungen möglich sind.

> Konzeptionell zu überlegen wäre dabei, ob man die Versionsstände 
> komplett voneinander abkoppelt (z.B. testing.de.wikipedia.org und 
> stable.de.wikipedia.org) oder den jeweiligen Revisionsstand nur im 
> Artikel kenntlich macht.

Der Revisionsstand wird am besten für jede Version einzeln
gespeichert, und Review-Markierungen vererben sich nicht auf
nachfolgende, noch ungeprüfte Versionen.

Es spricht nichts dagegen, auch bei linearer Entwicklung
geprüfte Versionen über leicht merkbare und stabile URLs zugänglich
zu machen. Z.B. könnte de-beta.wikipedia.org/wiki/Artikelname
einfach die letzte geprüfte Version anzeigen, und diese könnte
man dann auch Suchmaschinen anbieten, so dass man sogar sehen
könnte, ob die geprüfte oder die ungeprüfte Version ein höheres
Ranking bekommt.

> Letzteres halte ich für inhaltlich sinnvoller, softwaretechnisch 
> allerdings für schwer umsetzbar: Sobald jemand eine signifikante 
> Änderung vornimmt, muss der Artikel den "stable"-Status verlieren, es 
> sei denn, man entwickelt etwas analoges zu Bug- und Securityfixes (also 
> einen Mechanismus, der es beispielsweise erlaubt, inhaltliche Fehler und 
> Orthografie zu korrigieren, den Inhalt und die Argumentation des Artikel 
> darüber hinaus jedoch nicht modifiziert; der Verbesserungen von 
> Formulierungen zulässt, solange sie nicht sinnenverändernd sind; der 
> keine neuen "Features" [= Ergänzungen] zulässt, weil diese 
> ausschließlich in "unstable" einfließen dürfen usw.).

Ich glaube nicht, dass es unbedingt nötig ist, in geprüften Versionen
noch mal kleine Korrekturen vorzunehmen. Da kann man besser gleich
die aktuelle ungeprüfte Version verbessern und evtl. neu prüfen
(lassen) oder bis zur nächsten Prüfung warten.

Es wäre nicht schlecht, wenn es mal bald ein funktionierendes
Review-System geben würde, denn sonst wird sehr wahrscheinlich
irgendjemand ein Projekt mit höherem Qualitätsanspruch starten
und dann evtl. die Autoren von der Wikipedia abziehen, denen
Qualität besonders wichtig ist. Der Nachteil dabei wäre, dass
das neue Projekt nicht die Verknüpfungen bieten könnte, die auf
einem Wikimedia-Server möglich wären, und dass dann viele
Arbeiten doppelt gemacht werden müssten.

Programmiert z.Z. jemand an einer Review-Funktion?

El

-- 
Sparen beginnt mit GMX DSL: http://www.gmx.net/de/go/dsl