WikiDE-l December 2004

wikide-l@lists.wikimedia.org

102 participants
132 discussions

Wikipedia und deutsches Recht
by Matthias Walliczek 05 Dec '04

05 Dec '04

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

15 34

Re: [Wikide-l] Review - Versionsnummern
by b schewek 05 Dec '04

05 Dec '04

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

14 23

Re: Wikinews
by Stefan Rücker 05 Dec '04

05 Dec '04

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ß

1 0

Re: [Wikide-l] Re: Review - Versionsnummern
by b schewek 04 Dec '04

04 Dec '04

----- 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

4 4

Re: [Wikide-l] Re: Review - Versionsnummern
by b schewek 04 Dec '04

04 Dec '04

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

2 1

Wikipedia in der Financial Times
by Katharina Bleuer 04 Dec '04

04 Dec '04

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

19 29

Fwd: [Mediawiki-l] MediaWiki 1.4beta1 released
by Marco Krohn 04 Dec '04

04 Dec '04

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 -------------------------------------------------------

1 0

Vertrauenswürdige Infos in Artikeln besser erkennen
by Stefan Kühn 04 Dec '04

04 Dec '04

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

5 4

Re: Wikinews
by Leon Weber 03 Dec '04

03 Dec '04

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

1 0

Commons - Bild von Pixelquelle
by Stefan Kühn 03 Dec '04

03 Dec '04

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

3 3

← Newer
1
...
8
9
10
11
12
13
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

WikiDE-l December 2004