Änderungen durch unangemeldete freigegeben.
dedlfix
Änderungen durch unangemeldete freigegeben.
dedlfix
Matthias ApselTach!
Soeben habe ich im SELFHTML-Wiki zunächst testweise freigegeben, dass bestehende Seiten ohne Anmeldung geändert werden können. Neu-Anlegen geht ohne Anmeldung allerdings nur für Diskussionsseiten. Ziel ist, die Mitmach-Hürde einen Schritt zu senken.
Alle Änderungen werden jedoch nicht sofort angezeigt sondern müssen erst "gesichtet" werden. Solange wird die alte Version angezeigt zuzüglich eines Hinweises, dass es eine neuere Version gibt (die man sich durch Klick anschauen kann). Zum Spam-Schutz werden Änderungen gegen die von der Wikipedia und Wikimedia gepflegten Spam-Black-Lists geprüft.
Wer es testen möchte, kann das im Test-Wiki tun.
dedlfix.
-
Ziel ist, die Mitmach-Hürde einen Schritt zu senken.
Alle Änderungen werden jedoch nicht sofort angezeigt sondern müssen erst "gesichtet" werden.
Wiki-Sichtung = Benutzer dürfen seiner Herrlichkeit, dem Fürst der betroffenen Artikelprovinz, untertänigst Vorschläge bereiten, die dieser nach Gutdünken kommentarlos ablehnt oder als quasieigenen Beitrag übernimmt.
Aber immerhin kann man bei euch ein Grundmaß an Sachkenntis voraussetzen …
-
gudn tach!
Alle Änderungen werden jedoch nicht sofort angezeigt sondern müssen erst "gesichtet" werden.
Wiki-Sichtung = Benutzer dürfen seiner Herrlichkeit, dem Fürst der betroffenen Artikelprovinz, untertänigst Vorschläge bereiten, die dieser nach Gutdünken kommentarlos ablehnt oder als quasieigenen Beitrag übernimmt.
da lese ich mediawiki-/wikipedia-kritik heraus, und zwar unangemessene.
zu "kommentarlos ablehnt":
jeder user (also auch ein unangemeldeter) kann bei kommentarlosen reverts, die ohnehin nur bei offensichtlichem vandalismus erfolgen sollten, auf der jeweiligen talk page des artikels nachfragen. fuer den fall, dass dort keine antwort erfolgt, gibt es weitere anlaufstellen. es gibt diesbzgl. also mehrere mechanismen, die einem "kommentarlosen ablehnen" vorbeugen.zu "quasieigenen Beitrag":
das ist quark, denn in der history erscheint primaer der urheber, also z.b. die ip-adresse. in einem separaten log werden die sichtungen erfasst, die nur von sekundaerer bedeutung sind.das sichten hat zwar auch nachteile (die du nicht nanntest), aber insg. ueberwiegen die vorteile (leser bekommt mit hoeherer wahrscheinlichkeit was qualitativ besseres vorgesetzt; intendiertem vandalismus wird etwas spass/reiz genommen).
prost
seth -
Tach!
Alle Änderungen werden jedoch nicht sofort angezeigt sondern müssen erst "gesichtet" werden.
Wiki-Sichtung = Benutzer dürfen seiner Herrlichkeit, dem Fürst der betroffenen Artikelprovinz, untertänigst Vorschläge bereiten, die dieser nach Gutdünken kommentarlos ablehnt oder als quasieigenen Beitrag übernimmt.Die verwendete Extension heißt ApprovedRevs, also "bestätigte Versionen". Ich habe in den zugehörigen Systemtexten alles was "bestätigen" hieß nach "sichten" geändert. Das beschreibt unser Ziel etwas besser. Uns geht es nicht darum, jede Änderung inhaltlich abzunicken sondern nur Vandalismus bis zu seiner Entfernung nicht gleich sofort anzuzeigen.
ApprovedRevs ist im Gegensatz zum in der Wikipedia verwendetem FlaggedRevs deutlich kleiner. Es gibt nur gesichtet(/bestätigt) oder nicht, eine Qualitätsbewertung ist nicht enthalten. Vielleicht werden wir diese Extension auch wieder deaktivieren, wenn sich herausstellt, dass der Spam sowieso schon durch die Anti-Spam-Extensions wirksam unterbunden wird.
dedlfix.
-
Hallo
Vielleicht werden wir diese Extension auch wieder deaktivieren, wenn sich herausstellt, dass der Spam sowieso schon durch die Anti-Spam-Extensions wirksam unterbunden wird.
Gibt es jeweils ein Log für die beiden Mechanismen?
Gruß
Kalk-
Tach!
Vielleicht werden wir diese Extension auch wieder deaktivieren, wenn sich herausstellt, dass der Spam sowieso schon durch die Anti-Spam-Extensions wirksam unterbunden wird.
Gibt es jeweils ein Log für die beiden Mechanismen?Spam-Versuche (also wer erfolgreich gegen einen der Filter rennt) werden generell nicht protokolliert. Das ist in den verwendeten Extensions auch nicht vorgesehen, soweit ich weiß. Hier vertrauen wir auf die Expertise der Wikipedia/-media, dass sie ihre Listen ordentlich pflegen.
Spam, der es schafft, wird gelöscht, und zwar so, dass auch öffentlich nichts in der Versionsgeschichte zu sehen ist. Lediglich die Löschung und Wiederherstellung ist in den Logbüchern zu sehen. Die Administratoren können allerdings auch die gelöschten Versionen anschauen.
dedlfix.
-
Om nah hoo pez nyeetz, dedlfix!
Spam-Versuche (also wer erfolgreich gegen einen der Filter rennt)
erfolglos ;-) Eine negative Diagnose ist meistens positiv.
Matthias
--
1/z ist kein Blatt Papier.
-
-
-
-
-
Tach!
Alle Änderungen werden jedoch nicht sofort angezeigt sondern müssen erst "gesichtet" werden.
Die Sichtung (durch ApprovedRevs) ist wieder deaktiviert. Die Extension hat sich nicht mit ConfirmEdit vertragen. ConfirmEdit ist bei uns so konfiguriert, dass beim Einfügen von URLs (nicht jedoch bei Änderungen ohne URL-Einfügung) durch Unangemeldete und Neulinge ein simples Captcha zu lösen ist. Die Prävention durch das Captcha ist wichtiger, weil arbeitssparender als die Sichtungsmarkierung.
dedlfix.