Hallo,
bevor hier zu euphorisch über die Zukunft diskutiert wird, sollten wir
uns vielleicht mal mit einer ganz bodenständigen Frage beschäftigen:
Hält sich Wikipedia an geltendes deutsches Recht?
Grund: In der Diskussion zu [[Diskussion:Nationaldemokratische Partei
Deutschlands]] wurde die Frage gestellt, inwieweit deutsches Recht
anwendbar ist. Da diese Frage jedoch auch von anderen Nutzern bereits
zuvor gestellt wurde (vg. [[Wikipedia Diskussion:Verlinken]]), würde
mich jetzt unabhängig von dem konkreten Fall interessieren, ob deutsches
Recht überhaupt ein Argument sein kann, warum wir so viel über
Bilderrechte diskutieren und das Urheberrecht und Wappenrecht genaustens
beachten, wenn ansonsten das geltende Recht offenbar beliebig ignoriert
werden soll.
Matthias - mwka
Die 'Exzellenten Artikel" stellen eine Art Review dar.
Falls, wie in freier Software, 'stabile' Artikelversionen
markiert werden könnten, dann wäre ein reviewter Artikel etwa
per "Der dargestellte Artikel ist die aktuelle Version (in Arbeit).
Der letzte stabile Artikel ist [[Version 0.6]])" leicht erreichbar.
Exzellente Artikel würden dann Version 1.0, und der Versionsmarkierung
würde ein "von Autoren A B und C für gut befunden" angehängt.
Ein einfaches Schema, um Artikel zu Kleinversionen zu promvieren
ist dann notwendig (Konsens von 3-5 Beitragenden), Grossversionen
a ls Exzellenter Artikel.
Besucher könnten dann auch voreinstellen, ob sie bei allen
Artikeln die letzte Hauptversion, die letzte Unterversion
oder die letzte Version sehen wollen. Das Herausgeben in
festem Format würde ebenfalls erleichtert.
Vandalismus würde vielleicht auch weniger attraktiv, wenn die
letzte Version sowieso nur "In Arbeit" ist.
(Oder ist ein derartiger Vorschlag schon in Entwicklung?)
Schewek
----- Original Message -----
From: "Marco Krohn" <marco.krohn(a)web.de>
To: "MailinglistederdeutschsprachigenWikipedia" <wikide-l(a)Wikipedia.org>
Subject: Re: [Wikide-l] Review
Date: Tue, 30 Nov 2004 12:15:53 +0100
>
> Mailingliste der deutschsprachigen Wikipedia
> <wikide-l(a)Wikipedia.org> schrieb am 30.11.04 11:35:41:
>
> > einfach nur eine person, die unterschreibt halte ich fuer zu
> > gefaehrlich und ausnutzbar.
>
> Yup. Dazu wird es aber wohl auch nicht kommen, denn einen wirklich
> langen Artikel gründlich zu überprüfen, würde in einigen Fällen
> Tage dauern und dazu sind nur die wenigsten bereit, mal abgesehen
> davon, dass dann immer noch das Problem bleibt, was nach Änderungen
> geschieht. Jedenfalls sind alle mir bekannten Versuche in der engl.
> Wikipedia (angefangen mit der Nupedia) ein dem traditionellen
> ähnliches review durchzuführen gescheitert.
>
> Viele Grüße,
> Marco
>
> __________________________________________________________
> Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min.
> weltweit telefonieren! http://freephone.web.de/?mc=021201
>
> _______________________________________________
> WikiDE-l mailing list
> WikiDE-l(a)Wikipedia.org
> http://mail.wikipedia.org/mailman/listinfo/wikide-l
--
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
Hallo
Die ersten Anfänge von Wikinews sind durchaus ansprechend.
Aber es bestehen selbstverständlich auch noch viele offene Fragen, die
auf der entsprechenden Diskussionsseite nach und nach geklärt werden können.
Gruß
----- Original Message -----
From: "Paul Ebermann" <Paul-Ebermann(a)gmx.de>
To: "Mailingliste der deutschsprachigen Wikipedia" <wikide-l(a)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
Mit Bezug auf verschiedene Anmerkungen...
>
> die Zuweisung, Verwaltung und Abfrage der Versionsnummern ist in
> dieser Form sicher gut gelöst, ...
Die Softwareseite einer Versions-Nummerierung ist mMn relativ
einfach herzustellen, und auch benutzerfreundlich zu implementieren.
Wie die Fragen (und historischen Diskussionen auf diversen WP-seiten)
zeigen, ist der Review-Prozess problematisch.
Eine flexible Softwarevorgabe gibt der WP-Gemeinschaft die
Freiheit, das Feature nach eigenen Vorstellungen zu nutzen.
> .... aber könntest Du zu dem folgenden
> Punkt noch etwas mehr schreiben?
>
> > === 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.
>
> Wie ist diese Diskussion strukturiert? Welche Ansprüche werden
> gestellt? Wie wird sichergestellt, dass alle Fakten überprüft
> wurden, bevor eine 1.0 vergeben wird? Welche Personen gelten in
> diesem Fall als Reviewer - alle die sich an der Diskussion
> beteiligt haben, alle die zugestimmt haben, ...?
>
> Ich bin sicher, dass die Community auf diese und viel weitere
> Fragen Antworten findet, wenn die Software erstmal die
> Funktionalität zur Verfügung stellt. Was mir allerdings am meisten
> Kopfzerbrechen bereitet ist die Frage, wer die Versionsnummern
> vergeben darf, und somit verbindlich über die Feststellung eines
> (rauhen) Konsens' entscheidet. Sind die Admins wirklich die
> richtigen für diesen Job? Lieber wäre mir, ein überschaubares Team
> von neutralen, selbstlosen und über jeden Zweifel erhabenen
> Regulars mit dieser Aufgabe zu betrauen. Zu den Administratoren,
> Bürokraten und Stewards würde sich eine neue Gruppe gesellen -
> vielleicht nennen wir sie die "Fotografen" (... der
> Artikelmomentaufnahme).
>
Es gibt zwei Funktionen: Den 'Ausführenden' (Admin), der die
Ergebnisse der Review-Diskussion umsetzt, und die 'Reviewer'.
Meine Idee eines Reviews wäre, dass sich (mindestens) 3-5
Reviewer für einen Artikel finden, und eine 'geprüfte' Version
vorstellen. Dann kann jeder, der interessiert ist, seine Meinung
abgeben (evtl. mit Einschränkungen wie mindestens 30 Tage dabei,
mindestens 20 Edits, ...). Bestimmte Mindeststimmabgaben und
Mehrheiten, und dann setzt ein Admin eine akzeptierte geprüfte
Version um, trägt die Reviewer ein. Fertig. (Aber das genaue
Konzept ist nicht wichtig, es muss nur ein strikteres als
'jeder darf machen' her. Ein Review ist eine Gemeinschaftsaussage,
und als solche nicht von einem Einzelnen zu treffen.)
Wenn das Konzept nicht angenommen wird, entsteht kein Schaden,
ausser verschwendeter Programmierarbeit. Der Vorschlag versucht,
so einfach wie es nur geht zu bleiben, um der WP-Gemeinschaft
die weitere Entwicklung zu überlassen. D.h. die Software soll
flexible Möglichkeit schaffen, aber gleichzeitig die in einer
vorigen Mail genannten Vorteile (CD-Version/neue Beitragende/)
bieten.
Ganz grob meine Gedanken...
Schewek
-----
Am Rande
Ich fürchte, dass auch dieser Vorschlaf im Sande verläuft, wenn
vor Softwareimplementierung ein Review-Konzept stehen muss. Ich
würde die Frage trennen in "Welche Softwareänderungen sind notwendig"
und "Wie kann ein Review-Prozess aussehen", und einfach annehmen,
dass die zweite Frage per Konsens beantwortet wird. Unter dieser
Annahme bliebe nur zu diskutieren, wie eine Software-Implementierung
auszusehen hätte.
--
______________________________________________
Check out the latest SMS services @ http://www.linuxmail.org
This allows you to send and receive SMS through your mailbox.
Powered by Outblaze
Unter dem Titel "Browserfutter: Wikipedia.org" ein netter Artikel in der
Financial Times Deutschland:
"Es ist kaum zu glauben, dass diese Inhalte kostenfrei im Netz angeboten
werden, während Lexikonverlage ihre Inhalte für viel Geld in Buchform oder
auf DVD verkaufen. Die dürften in Wikipedia auch eher eine Bedrohung als
eine Bereicherung sehen."
Der ganze Artikel: http://www.ftd.de/tm/me/1100940006787.html?nv=7dm
Grüessli
Kat
Hallo,
Brion Vibber hat gerade MediaWiki 1.4beta1 freigegeben. Was einige vielleicht
interessieren dürfte sind die neuen Features in 1.4, darunter auch das hier
gerade diskutierte "LetzeÄnderungen Patrolie" feature :-)
Desweiteren scheint es eine einfache Möglichkeit zu geben Bilder-Gallerien zu
erstellen, was insbesondere die commons Leute freuen wird und es gibt wohl
auch Unterstützung für die Rasterung von svg (scalale vector graphics)
Dateien.
Viele Grüße,
Marco
---------- Forwarded Message ----------
Subject: [Mediawiki-l] MediaWiki 1.4beta1 released
Date: Friday 03 December 2004 15:40
From: Brion Vibber <brion(a)pobox.com>
To: mediawiki-announce(a)wikimedia.org
Cc: MediaWiki announcements and site admin list <mediawiki-l(a)wikimedia.org>,
Wikimedia developers <wikitech-l(a)wikimedia.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
MediaWiki 1.4beta1 is an experimental release, to help flush out
remaining major problems in the code prior to a final public 1.4.0
release. It is not recommended to use this beta on a public site unless
you're familiar with MediaWiki innards and are willing and able to help
diagnose and fix problems that come up.
=== New features ===
* 'Recentchanges Patrol' to mark new edits that haven't yet been viewed.
* New, searchable deletion/upload/protection logs
* Image gallery generation (Special:Newimages and <gallery> tag)
* SVG rasterization support (requires external support)
* Users can select from the available localizations to override the
default user interface language.
* Traditional/Simplified Chinese conversion support
=== Installation and compatibility ===
* The default MonoBook theme now works with PHP 5.0
* Installation on systems with PHP's safe mode or other oddities
should work more reliably, as MonoBook no longer needs to
create a compiled template file for the wiki to run.
* A table prefix may be specified, to avoid conflicts with other
web applications forced to share a database.
* More thorough UTF-8 input validation; fixes non-ASCII uploaded
filenames from Safari.
* Command-line database upgrade script.
=== Customizability ===
* Default user options can now be overridden in LocalSettings.
* Skins system more modular: templates and CSS are now in /skins/
New skins can be dropped into this directory and used immediately.
* More extension hooks have been added.
* Authentication plugin hook.
* More internal code documentation, generated with phpdoc:
http://www.mediawiki.org/docs/html/
=== Optimization ===
* For many operations, MediaWiki 1.4 should run faster and use
less memory than MediaWiki 1.3. Page rendering is up to twice
as fast. (Use a PHP accelerator such as Turck MMCache for best
results with any PHP application, though!)
* The parser cache no longer requires memcached, and is enabled
by default. This avoids a lot of re-rendering of pages that
have been shown recently, greatly speeding longer page views.
* Support for compiled PHP modules to speed up page diff and
Unicode validation/normalization. (Requires ability to compile
and load PHP extensions).
=== What isn't ready yet ===
* A new user/groups permissions scheme has been held back to 1.5.
* An experimental SOAP interface will be made available as an extension
* PostgreSQL support is largely working, but search and installer
support are not complete. These are being actively worked on
and should come in later betas.
* E-mail notification of watched page changes and verification of
user-submitted e-mail addresses is not yet included. If updates
are available, this may make it into later betas.
* Log pages are not automatically imported into the new log table
at upgrade time. A script to import old text log entries is
incomplete, but may be available by the time 1.4 finishes.
* UI messages may be broken in Latin-1 mode in this release due to some
minor breakage in the language selection module.
Full release notes:
http://sourceforge.net/project/shownotes.php?release_id=287326
Download:
http://prdownloads.sf.net/wikipedia/mediawiki-1.4beta1.tar.gz?download
Wiki admin help mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Low-traffic release announcements mailing list:
http://mail.wikipedia.org/mailman/listinfo/mediawiki-announce
Bug report system:
http://bugzilla.wikipedia.org/
Play "stump the developers" live on IRC:
#mediawiki on irc.freenode.net
- -- brion vibber (brion @ pobox.com)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (Darwin)
iD8DBQFBsHrUwRnhpk1wk44RAmVjAKCS/S0DALe1b8F8OPBwp6POhDdmnwCgiY2n
oXBwQheNUN0xPWUim5qs4FA=
=mkWR
-----END PGP SIGNATURE-----
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
-------------------------------------------------------
Im Telepolis Artikel "Wikinews geht an den Start" (1) wird auf eine Studie
von IBM (2) verwiesen. Die dort gezeigten Grafiken brachten mich auf eine
Idee.
Die erste Grafik dort zeigt, wie sich einzelne Textbestandteile durch die
einzelnen Versionen des Artikels immer weitergereicht wurden, weil keiner
etwas zu beanstanden hatte. Je länger ein Bestandteil drin steht, umso
dunkler wird er. In der Grafik sind außerdem noch der Autor farblich
gekennzeichnet (Bei wenigen Autoren keine Kunst!).
Meine Idee: Neben dem Versionsbutton gibt es noch einen Knopf
"Zuverlässigkeit" (oder so ähnlich). Wer den bei einem Artikel anklickt,
bekommt den Artikeltext mit einer farblich abgestuft Texthintergrundfarbe
angezeigt. Nach dem Ampelprinzip werden dann Textbestandteile die gerade
erst in den letzten Versionen eingefügt wurden rötlich hinterlegt und
Textpassagen, die seit vielen Versionen unverändert drin stehen, grünlich
hinterlegt. Ist also ein Text dunkelgrün hinterlegt, weiß der Nutzer, dieser
Text wurde seit vielen Versionen nicht mehr editiert, also ist er
wahrscheinlich sehr vertrauenswürdig.
Die Farben sollten individuell einstellbar sein z.B. für Leute mit
Rot-Grün-Schwäche haben und auch die Farbabstufung sollte wenn möglich nicht
durch tausende Kleinständerungen im Artikel getäuscht werden können. Für
dieses Problem müsste man schauen wie stark die Veränderungen je Version
prozentual sind.
Vorteil des Verfahrens ist, dass es für alle Artikel dann sofort eine
"Zuverlässigkeit"-Studie gibt. Es entsteht keine Mehraufwand durch
aufwändigen Begutachtungsprozess. Bei problematischen Artikeln sind feste
Bestandteile schnell auszumachen. So wurde z.B. im Artikel der Frauenkirche
(Dresden) um einen einzigen Satz monatelang erbittert gestritten, wohingegen
die Baugeschichte völlig unstrittig war.
Ich hoffe es finden sich noch ein paar Befürworter für so eine farbliche
Zuverlässigkeitskennzeichung und wir können die Programmiere dafür finden.
Stefan
(1) http://www.heise.de/tp/r4/artikel/18/18928/1.html
(2) http://researchweb.watson.ibm.com/history/results.htm
Hallo!
Gerade eben wurden die Wikinews freigeschaltet (de.wikinews.org). Wir
suchen noch Leute die uns helfen und am Anfang erstmal vordergründig
Basisartikel schreiben bzw. von en.wikinews.org übersetzen. Wer helfen
möchte kann sich gerne anmelden, vielleicht wird ja früher oder später
eine eigene Mailingliste dafür aufgemacht.
Gruß,
Leon Weber
Auf Commons wurde heute ein Bild von www.pixelquelle.de als Bild des Tages
eingestellt. http://commons.wikimedia.org/w/wiki/Hauptseite
Im Bild steht das es Public Domain ist.
http://commons.wikimedia.org/wiki/Image:Flaming_cocktails.jpg
Laut Nutzerbedingung sind aber die Bilder von Pixelquelle keinesfalls PD.
http://www.pixelquelle.de/index.php?template=nutzungsbedingungen
"Ausgeschlossen hiervon sind Bilddatenbanken, Bildkataloge oder ähnliche,
bei denen PixelQuelle.de Fotos zum Download oder Verkauf angeboten werden."
Wir haben in der deutschen Wikipedia leider alle Bilder wieder löschen
müssen und jetzt kommen sie über Commons. Das geht so nicht. Kann bitte
einer da mal den Leuten bei Commons sagen, ich kenne mich bei Commons noch
nicht so aus. Danke!
Stefan
