[Wikide-l] Re: Review - Versionsnummern

[b schewek]

----- Original Message -----
From: "Paul Ebermann" <Paul-Ebermann at gmx.de>
To: "Mailingliste der deutschsprachigen Wikipedia" <wikide-l at Wikipedia.org>
Subject: Re: [Wikide-l] Re: Review - Versionsnummern
Date: Thu, 2 Dec 2004 00:29:33 +0100

> 
> "b schewek" skribis:
> 
> > Meine Datenbankkenntnisse sind nur oberflächlich, aber eine zusätzliche
> > Fliesskommazahl sollte reichen. Die Zahl ist 0, bis ein Review einen
> > Wert 0.1 zuweist. 1.0 wird zugewiesen,, wenn das erste mal eine Exzellenz
> > erreicht ist, dann lassen sich per kleinem Review kleine Verbesserungen
> > auf 1.1, 1.2, ... markieren, und wenn der Review den Eindruck hat,
> > dass eine Deutliche Verbesserung / Umarbeitung vorliegt, kann eine
> > erneute Exzellenzentscheidung zu 2.0 führen...
> 
> Was du beschreibst, ist keine Gleitkommazahl [1], sondern eine
> Festkommazahl. :-)
> 
> Wobei es eigentlich zwei ganze Zahlen sind, durch "." getrennt
> und lexikographisch [2] geordnet, denn 1.12 (der zwölfte kleine
> Review nach dem ersten Mal exzellent) ist ja mehr als 1.2.
> 
> 
> Das Problem ist hier nicht so sehr, die zusätzliche Zahl in
> die Datenbank einzusetzen, sondern die Teile des Programmes
> zu schreiben, mit denen die Nummer hochgezählt werden kann.
> (Oder soll einfach unter der Editbox ein weiteres Eingabe-Feld
>   sein?)
> 
> Außerdem noch eine nicht-technische Frage,
> die zu klären wäre:
> Wer darf die Nummer ändern?
> Gibt es für Änderungen der zweiten Zahl
> andere Berechtigungen als für Änderungen der
> großen Nummer?
> 
> 
> Paul
> 
> [1] Die Übersetzung von "Floating Point" ist Gleitkomma,
>      nicht Fließkomma. "flow - fließen, float - gleiten".
> [2]  (= jede Komponente einzeln, erste hat Vorrang)
> 

Danke für die Richtigstellung. Ich nehme mir mal die Freiheit,
die Vorstellungen genauer darzustellen:

== DB-Erweiterungen ==

Die DB bekommt vier neue Einträge je Artikelversion:
(1) Hauptversion#, (2) Nebenversion#, (3) Verweis auf letzte
stabile bzw. reviewte Version (4) Liste der Reviewer und
(5) evtl. Diskussion, die den Review begleitete.

Zu Anfang ist ein Artikel (1)=0, (2)=0; (3)=letzte Version (4)=leer.
Dann wird (s.u.) eine Version definiert: (1)=1, (2)=0,
(3)=diese artikel ID, (4)=ein paar interessierte benutzer.
Alle Folgeversionen dieses Artikels tragen die Einträge (1)-(3)
fort (d.h. jede Folgeversion verweist direkt auf die stabile
Version (Zugriffsoptimierung), hat aber (4) keine Reviewer und (5)
keine Diskussion).

== Wikimedia Software Interface Erweiterungen ==

Diese Erweiterungen sollten nur optional sein, damit niemand
gezwungen wird, dieses System zu verwenden.

=== Zugriff auf Artikel ===

Wenn keine explizite Einstellung erfolgt, passiert gar nichts.

Wer will, bekommt (ich schreibe jetzt nur für Skin MonoBook) neben
den Artikel und Diskussion Tabs auch noch einen Tab für
"Artikel Rev. 1.2". Wenn eine revidierte Artikelversion angesehen
wird, erscheint eine kleine Anmerkung ("Dieser Artikel ist eine
stabile Rev.) und erhält am Ende die Namen der Reviewer sowie
die Möglichkeit zur Ansicht der dem Review vorausgegangenen Diskussion.

=== Markieren einer Version ===

Je nach Konsens kann
* jeder  (widerspricht allerdings der Idee)
* jeder angemeldete Benutzer
* jeder Admin (meine Vorstellung)
eine neue Version markieren.

Mir schwebt so etwas wie die Exzellente Kandidaten Diskussion
vor, wobei die Ansprüche bei 'kleinen' Versionen geringen wären.
Nach Abschluss der Diskussion liesse sich die Diskussion evtl.
in der neuen Spalte (5) der DB unterbringen.

== Vorteile ==

* Niemand ist gezwungen, dieses neue Feature zu benutzen.
  Es ist keine Schwelle zu überwinden.
* Wikipedia kommt aus dem Ruf heraus, unverläßlich zu sein.
* Es wird leichter, eine CD/DVD herauszugeben.
* Potentielle Beitragende, die bisher mit der Einstellung
  "Ich stelle was ein, und jeder Idiot kann es wieder
  kaputtmachen" ferngeblieben sind, erhalten einen Anreiz
  zur Mitarbeit.
* Der Anreiz, Artikel sichtbar zu verbessern, steigt. Ich sehe,
  dass Leute, deren Arbeit durch eine Aufnahme in die Exzellenten
  Artikel ausgezeichnet werden, motiviert sind.  Eine vergleichbare
  Motivationssteigerung kann durch kleinere Änderungen und
  Auszeichnungen (kleinere stabile Version) erreicht werden.
* Vandalen werden demotiviert, da der Unsinn von allen, die nur
  die stabile Version betrachten, nicht wahrgenommen wird.
* Edit-Wars verlieren ihre Bedeutung aus ähnlichem Grund.
* Man kann davon träumen, dass eine Einstellung für mehrsprachige
  Benutzer zB anzeigt: Hauptversionen zu diesem Artikel bestehen
  in den Sprachen A, B und C. Und dann hoffen, dass es
  sprachübergreifende Gesamtversionen gibt...

== Nachteile ==

=== Nupedia-Angst ===

Es wurde in einigen Antworten angedeutet, ein solches System würde
scheitern, wie auch Nupedia gescheitert sei. Das bezweifele ich.
Zumindest würde diese Änderung, falls ignoriert, keinen Schaden
anrichten.

Nach der Kategorisierungsorgie bezweifele ich allerdings, dass
ein neues Feature einfach so liegenbleibt.

=== Aktuelle Versionen werden übersehen ===

Wenn jeder nur die stabile Version anschaut, bleiben
viele kleine falsche Änderungen unbemerket.

=== Zu viel Arbeit ===

Die Entwickler haben schon genug am Hals.

(Wenn mir jemand eine Einführung gibt, und Einverständnis
über ein derartiges Feater entsteht, versuche ich,
das zu implementieren.)

----

Kann jemand mir Ignorant vorschlagen, wo dieser Beitrag in der WP oder
auf Meta hinkann? Oder gleich dort einstellen?

Gruß,
Schewek

-- 
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org 
This allows you to send and receive SMS through your mailbox.


Powered by Outblaze