[Wikide-l] Review - Versionsnummern

• Vorherige Nachricht: [Wikide-l] Review - Versionsnummern
• Nächste Nachricht: [Wikide-l] The Art of Computer Programming vs. Wikipedia
• Nachrichten sortiert nach: [ Datum ] [ Thema ] [ Betreff (Subject) ] [ Autor ]

Kurt:
> elwp at gmx.de schrieb:
> > Da muss man sich doch fragen, wann "Version 1.0" fertig sein wird.
> > 
> > Ein sehr ambitioniertes Ziel wäre, diese Version in einem Jahr
> > fertig zu haben.
> 
> "Ambitioniert"? Warum sollten wir uns Ziele setzen, die wir unmöglich
> schaffen können?
> [...]
> Zum 10. Geburtstag des Projektes 100.000 _geprüfte_ Artikel vorweisen
> zu können, würde ich ein sehr ambitioniertes Ziel nennen - aber kein
> unrealistisches.

Die englische Wikipedia war vor gut einem Jahr etwa so groß wie die
deutsche heute. Damals schrieb Jimbo über Wikipedia 1.0 und wann
sie erscheinen könnte:

http://mail.wikipedia.org/pipermail/wikipedia-l/2003-August/029065.html

Er nannte 1, 2 oder 5 Jahre, und solche Vorstellungen dürften in vielen
Köpfen herumschwirren. Ich wollte mit meinen Rechnungen nur zeigen, wie
unrealistisch sie sind, wenn man den normalen Reviewprozess verwendet.

> An dieser Stelle würden mich ein paar Zahlen interessieren:
> * Wieviel Prozent aller Artikelaufrufe entfallen auf die 1000, 10.000,
> 100.000 meistaufgerufenen Artikel?

Das hängt davon ab, wieviele Artikel es insgesamt gibt. Aus den
Webalizer-Statistiken dieses Jahres habe ich folgende Werte extrahiert
(Näheres zur Berechnung am Ende dieser Mail):

  1.000: Feb: 22.6%, Apr: 18.8%, Jun: 17.6%, Aug: 15.5%, Okt: 16.5%
 10.000: Feb: 66.2%, Apr: 56.2%, Jun: 53.9%, Aug: 47.9%, Okt: 47.6%
100.000: Feb:100.0%, Apr: 99.6%, Jun: 98.2%, Aug: 95.0%, Okt: 92.0%

Der Wert für die 100.000 meistaufgerufenen Artikel wird sicherlich
noch weiter sinken, ich schätze auf ca. 80%.

> * Oder andersherum: Wieviele der meistaufgerufenen Artikel müssten wir
> prüfen, um damit 50%, 60%, 70%, 80% oder 90% unserer Besucher glücklich
> zu machen?

Das ist schon schwieriger zu beantworten. Die meisten Benutzer dürften
sich ja wohl mehr als nur einen Artikel ansehen und erst dann zufrieden
sein, wenn die überwiegende Mehrzahl der Artikel, die sie lesen, gut und
geprüft ist. Dazu müssten dann tatsächlich etwa die 100.000 meistgelesenen
Artikel geprüft werden, denn erst dann wäre nur jeder 5. gelesene Artikel
ungeprüft (falls der o.g. Wert auf 80% fällt), was wohl noch einigermaßen
erträglich wäre.

Und damit es "nur" 100.000 zu prüfende Artikel sind, müssten auch genau
die 100.000 meistgelesenen Artikel geprüft werden. Tatsächlich werden
aber wohl nur die Artikel geprüft werden, auf die gerade ein paar Prüfer
Lust haben.

> > Mindestens müssten aber täglich so viele Artikel geprüft werden
> > wie neue hinzu kommen, also z.Z. etwa 400, wenn man irgendwann
> > mal alle geprüft haben will.
> 
> Wenn, ja, wenn. Ich denke dies wäre ein schönes Ziel für den 50.
> Geburtstag. Das exponentielle Wachstum kann ganz plötzlich wieder
> einsetzen, und niemand weiß, wann es endlich wieder aufhört ;-)

Exponentielles Wachstum der Mitarbeit kann es nur geben, wenn die
Anzahl der Internetnutzer, die neu von der Wikipedia erfahren und
sich dafür begeistern können, exponentiell zunimmt. Das ist ja wohl
bei der inzwischen erreichten Bekanntheit der Wikipedia auszuschließen.

Außerdem ist es für mein Argument völlig egal, ob das Wachstum
linear oder exponentiell oder was auch immer ist, solange es nur
gleich ist für die Anzahl der neuen Artikel und die Bereitschaft,
Artikel zu prüfen, wovon ich ausgehe.

> > Wie auch immer man rechnet, es wären viel mehr Reviews nötig als
> > die Leute (sehr wahrscheinlich) bereit sind durchzuführen.
> 
> Was bedeutet "wie auch immer"?

Ich meine natürlich unter der Voraussetzung, dass genügend Artikel
häufig genug geprüft werden.

> > Damit die Benutzer von einer solchen Basisprüfung möglichst
> > häufig Gebrauch machen, muss sie ebenso einfach wie das Ändern
> > der Artikel sein und möglichst vielen Leuten zur Verfügung
> > stehen. Ich habe auch einen konkreten Vorschlag, der evtl.
> > parallel zu Scheweks Versionskennzeichnung laufen könnte:
> > [...]
> 
> Dein Vorschlag ist interessant, und wenn ich es richtig verstanden
> habe eine Weiterentwicklung der von Magnus implementierten
> Bewertungsfunktion.

Ja.

> Allerdings bin ich sehr skeptisch was ihren praktischen Nutzen
> betrifft: Lars Aronsson hatte eine (allerdings einfacher gestrickte)
> Bewertungsfunktion auf susning.nu implementiert, er schaltete diese
> jedoch wieder ab, nachdem offensichtlich wurde, dass ein Großteil der
> Benutzer nicht die Qualität bewertete, sondern der eigenen Meinung
> zum Artikelgegenstand Ausdruck verlieh. (Lars, bitte korrigiere 
> mich, wenn ich das falsch wiedergebe.) Diesem Problem wird man durch 
> Veränderungen an der Bewertungsfunktion sicher verringern können, wie
> stark lässt sich im Vorraus aber kaum abschätzen.

Ich kann mir ja gerade noch vorstellen, dass ein paar Besoffene bei einer
nicht weiter differenzierten Bewertung eines Artikels z.B. über Hitler
eine negative Bewertung abgeben, auch wenn der Artikel gut ist, aber
wenn man wirklich konkret nach Fakten, Vollständigkeit etc. fragt, halte
ich eine solche Verwechselung für nahezu ausgeschlossen.

Es könnte allerdings sein, dass einige Benutzer bei Themen, die sie
intellektuell überfordern, negative Wertungen abgeben, auch wenn
der Artikel auf einem angemessenen Niveau geschrieben ist. Das dürfte
v.a. schwierige naturwissenschaftliche Themen betreffen. Solche
Benutzer muss man dann eben aus der Vertrauensliste entfernen.

> Auch wie fundiert die Selbsteinschätzung als Experte oder Laie ist,
> bleibt für den normalen Leser völlig intransparent.

Diese Selbsteinschätzung ist keine zentrale Information bei der
Bewertung. Ich dachte nur, einige Leute könnten sie evtl. nützlich
finden.

> Und Verknüpfung der Artikelbewertung mit einem Vertrauensnetz brächte
> sehr viele Probleme mit sich, ich denke da sollten wir ggf. separat
> drüber diskutieren.

Angeblich soll man in Mediawiki 1.5 Benutzergruppen definieren können,
und vielleicht lässt sich die Idee dann einfacher umsetzen. Also am
besten erst mal warten und dann weiterdiskutieren.

> Mir ist der Ansatz ansich nicht unsympathisch; Aber ich befürchte, dass
> wir mit so einer Funktion unseren Lesern zwar Artikelversionen anbieten
> können, deren Qualität gesicherter ist, als die jeweils aktuellste Version
> - aber nur im statistischen Mittel.

Das wäre schon ein großer Fortschritt. Leider ist das beim Review (egal
ob ein großer oder kleiner) nicht gesichert, denn im Mittel nimmt die
Artikelqualität auch ohne Review zu, sofern man zumindest offensichtlichen
Vandalismus in Grenzen halten kann, z.B. durch die neue
Recent-Changes-Patrol-Funktion. Deshalb können besonders dann, wenn zu
selten geprüft wird, die geprüften Versionen im Schnitt auch schlechter
als die aktuellen sein.

> Wie verlässlich die Bewertung bei jedem einzelnen Artikel ganz konkret
> ist, wird für den Leser nicht einschätzbar sein.

Den Benutzern sollte klar sein, was es bedeutet, wenn sie als
Qualitätsmerkmal wählen, dass eine bestimmte Anzahl von vertrauenswürdigen
Benutzeren den Artikel abgesegnet haben. Und wenn das zu kompliziert ist,
muss man es eben irgendwie genau erklären.

El

-----------------------------

Zur Berechnung des Anteils der meistaufgerufenen Artikel:

Die Webalizer-Statistiken gibt es hier:
http://wikimedia.org/stats/de.wikipedia.org/
Man kann auf die einzelnen Monate klicken und dann auf
"View All URLs", um die Zugriffslisten herunterzuladen.

Als Artikel habe ich URLs gezählt, die mit /wiki/
beginnen und die weder einen Doppelpunkt noch die
Wörter "Liste" oder "Portal" im Namen haben. Außerdem
habe ich noch einige häufig aufgerufene Seiten ausgeschlossen,
die offensichtlich keine Artikel sind, wie z.B. die Hauptseite.
Aufrufe von Redirects habe ich so behandelt, als wäre die
Seite, auf die umgeleitet wird, aufgerufen worden.

Hier der Quellcode für die, die es ganz genau wissen wollen:

#!/usr/bin/perl

open REDIR, "redir"; # vorher aus cur_table.sql.bz2 erstellt
while(<REDIR>) {
  ($von, $nach) = split;
  $redir{$von} = $nach;
}
close REDIR;

for($monat=2; $monat<=10; $monat+=2) {
  %n=(); @N=(); $N=0; $nSuch=0;
  open URL, sprintf("url_2004%02i.html", $monat);
  while(<URL>) {
    ($n, $x, $x, $x, $url) = split;
    next unless $url =~ /^\/wiki\/(.*)$/;
    $artikel = $1;
    next if $artikel =~ /:/ || $artikel eq "Hauptseite" ||
      $artikel eq "Aktuelle_Ereignisse" || $artikel =~ /Portal/ ||
	$artikel =~ /^Liste/ || $artikel =~ /^Index/ ||
	  $artikel eq "_vti_bin/owssvr.dll" ||
            $artikel eq "MSOffice/cltreq.asp" ||
	      $artikel eq "w/wiki.phtml";
    $n{defined $redir{$artikel}?$redir{$artikel}:$artikel} += $n;
  }
  close URL;
  
  
  foreach $artikel (sort {$n{$b} <=> $n{$a}} keys %n) {
    $N += $n{$artikel};
    $N[$nSuch++] = $N;
  }
  
  print "Monat: $monat; $N Artikelabfragen, " .
    "davon $nSuch unterschiedliche\n";
  for($i=1000; $i<$nSuch; $i*=10) {
    printf "%4.3f %i\n", $N[$i]/$N, $i;
  }
}

-- 
GMX ProMail mit bestem Virenschutz http://www.gmx.net/de/go/mail
+++ Empfehlung der Redaktion +++ Internet Professionell 10/04 +++

• Vorherige Nachricht: [Wikide-l] Review - Versionsnummern
• Nächste Nachricht: [Wikide-l] The Art of Computer Programming vs. Wikipedia
• Nachrichten sortiert nach: [ Datum ] [ Thema ] [ Betreff (Subject)] [ Autor ]