Wikipedia Diskussion:Meinungsbilder/Änderung der Rechteverteilung

Schade

Dieser Schnellschuss wird sicher nicht durchkommen. Dabei ist die Idee im Kern nicht schlecht. Allerdings halte ich es für bedenklich, insbesondere die Kern-Admin-Rechte Löschen, Sperren und Schützen für alle Sichter (das ist eine viel zu riesige Gruppe, deren Anforderungen viel zu niedrig sind) zugänglich zu machen. Die anderen Rechte (suppressredirect, deletedhistory und unwatchedpages) dagegen würde ich auch den Sichtern anvertrauen. -- Chaddy · D·B - DÜP 17:40, 26. Mai 2010 (CEST)

Sehe ich ähnlich. suppressredirect hat eigentlich kaum ein Risiko; es wird kaum ein Verschiebevandale bis zum Sichter kommen. unwatchedpages kann man sowieso abfragen, wenn man weiß wie, einzig das gezielte Suchen nach unbeobachteten Seiten können derzeit nur Admins (Nutzen?). deletedhistory ist jetzt nicht SO wichtig, könnte aber dabei helfen, dass normale Benutzer irgendwelche "wieso isn der gelöscht?"-Fragen beantworten können. Insbesondere um zwischen "Substub" und "mein Sitznachbar stinkt" unterscheiden zu können (ich erinnere da nur an die fefe-Meldung zu Blowout (Tiefbohrtechnik), die uns damit vermutliche erspart geblieben wäre ;) --TheK? 17:48, 26. Mai 2010 (CEST)

Für DÜP wäre es schon ganz praktisch, auch gelöschte Bilder und deren Beschreibungsseiten einsehen zu können. Dasselbe gilt für Text-URVen. -- Chaddy · D·B - DÜP 17:56, 26. Mai 2010 (CEST)

Dafür würde ich dann aber lieber eine weitere Benutzergruppe einführen. Eine Art "Halbadmins", die alles gelöschte einsehen können. Selbige werden dann nach irgendeinem noch zu klärenden System vergeben. --TheK? 18:07, 26. Mai 2010 (CEST)

So wie ich das derzeit im IRC einstufen kann (und euren Kommentaren), sind vor allem die Funktionen suppressredirect, deletedhistory und unwatchedpages gefragt. Diese würden auch keine neue Usergruppe provozieren. Nur damit wir uns das klar machen: Brisante Versionen werden über ein Verfahren gelöscht, auf das deletedhistory keinen Zugriff hat, die ZQ wird zenisert, sowie der Benutzername. Somit können wirklich nur gelöschte Artikel, in denen nichts brisantes steht, gesehen werden, und davon nur die ZQ. Wirklich nur dafür gedacht, zu wissen, ob der Artikel aus "Mein Nachbar stinkt" besteht. Daher finde ich eine weitere Usergruppe dafür übertrieben. --Z1 18:17, 26. Mai 2010 (CEST)

Die Funktion suppressredirect bitte bitte nicht! Die sollte schon von Admins nur im absoluten Ausnahmefall verwendet werden, eine Ausweitung könnte fatale Folgen haben, da Verschiebungen deutlich schlechter nachvollziehbar sind. Da die Funktion normalerweise nicht verwendet werden sollte, gibt es keinen Grund, sie nicht-Admins zugänglich zu machen. -- Perrak (Disk) 20:23, 26. Mai 2010 (CEST)

Wieso ist das nicht nachvollziehbar? Es gibt einen Eintrag im Verschiebelog und der wird auf der Seite, von der aus verschoben wurde, ja auch angezeigt. XenonX3 - (☎:±) 20:28, 26. Mai 2010 (CEST)

Nicht "nicht nachvollziehbar", sondern "deutlich schlechter nachvollziehbar". Die Logbücher sind ziemlich unübersichtlich, insbesondere, wenn man mal an einer langsamen Verbindung hängt. Eine gelöschte WL ist dagegen leichter nachvollziehbar, als Admin sehe ich dann auch das Verschiebeziel. Und in den meisten Fällen sollte die WL ja auch zumindest temporär erhalten bleiben. -- Perrak (Disk) 22:44, 26. Mai 2010 (CEST)

Vor allem sollen ja auch die Links auf die Seite nicht zu Rotlinks werden; das werden sie so schon häufig genug. Muss nicht noch weiter forciert werden durch die Funktion, die dann sicher regelmäßig angewendet würde. Und dann denkt keiner an die Links aufs Lemma. --Geitost 23:45, 26. Mai 2010 (CEST)

Habt Ihr mal darüber nachgedacht die Rechte nicht en bloc neu zu verteilen, sondern einzeln darüber abzustimmen. Eventuell könnte man auch zwei Gruppen bilden. Eine Gruppe für unproblematische Fälle und eine Gruppe für problematische Fälle. --Goldzahn 14:03, 27. Mai 2010 (CEST)

Wenn wir die Rechte nicht en bloc verteilen, halte ich die Mehrarbeit für Administratoren für größer als deren Nutzen. Allerdings lässt sich nun im Meinungsbild seperat entscheiden, welche Rechte für die Sichter hinzugefügt werden sollen. --Z1 14:29, 27. Mai 2010 (CEST)

Ich bin dem MB nicht strikt abgeneigt, aber bitte überdenkt gewisse Problematiken. Es gibt einige Benutzer mit Sichterrechten, die noch nicht mal mit diesen fertig werden und sie beinahe schon missbräuchlich verwenden, was zu einem Mehraufwand für andere Benutzer führt. Es gibt einfach zu viele Sichter, und es ist relativ einfach ein solcher zu werden. Im Detail zu den Vorschlägen:

suppressredirect: Finde ich gefährlich, da es sicherlich einige Benutzer gibt, die diese Funktion missbräuchlich einsetzen. Der Nutzen ist relativ gering, da man die Weiterleitung einfach zur Schnelllöschung vorschlagen kann und ein Admin regelt das dann.

block: Ganz gefährlich: Passt mir ein Benutzer nicht, sperr ich ihn einfach. Es gibt sicherlich genügt Benutzer mit Sichterrechten, die hier mehr Schaden als Nutzen. Der Prozess über die VM ist wesentlich sicherer, da er transparenter ist und schlussendlich ein Admin über eine Sperre entscheidet.

deletedhistory: Unproblematisch. Missbräuchliche Verwendung eigentlich nicht erkennbar. Mir fällt keine ein.

unwatchedpages: Siehe deletedhistory. Wobei man sie vielleicht auf den ANR eingrenzen sollte.

delete: Bitte nicht. Das ist sehr gefährlich, da hier ein hohes Missbrauchspotential ist. Im Grunde kann so jeder einen Artikel löschen und das kann nicht der Sinn sein. Was hingegen sinnvoll wäre, ist, dass man Unterseiten (also nicht die Benutzerseite und die Diskussion) aus seinem Namensraum löschen kann.

protect: Führt auch zu einem Mehraufwand. Sinnvoll wäre es allerdings, jedem Sichter das Recht zur temporären Halbsperre (30 Minuten) zu erteilen. So kann man Artikelvandalen, die meistens IP's sind, schnell und unproblematisch für eine kurze Zeit ausschließen. Die meisten verlieren in diesem Zeitraum die Motivation und man ist sie los. Um einen Missbrauch zu verhindern, sollte man die Funktion nach Ablauf der 30 Minuten für einen längeren Zeitraum (12 Stunden) deaktivieren. Wenn es dann wieder zu Vandalismus kommt, ist eine VM so oder so sinnvoll.

Gruß, --Gamma127 18:13, 27. Mai 2010 (CEST)

Du scheinst die Problematik erfasst zu haben, inzwischen bin ich auch nur für unwatchedpages, suppressredirect und deletedhistory. Allerdings scheinst du bei deinen Überlegungen außer Acht gelassen zu haben, dass es programmiertechnisch sehr aufwendig ist, Sichtern ein temporäres Recht zur Halbsperrung zu verpassen. Rechte, die bereits bestehen, können binnen weniger Sekunden auch auf andere Usergruppen übertragen werden.

Desweiteren ist, soweit ich weiß, unwatchedpages auf den ANR reduziert; wen interessiert es, dass eine BD von niemandem beobachtet wird? --Z1 18:35, 27. Mai 2010 (CEST)

Eine weitere Frage ist, wie leicht kann man die Sichterrechte verlieren. Ich kenne mich damit nicht aus. Sollte es leicht sein, könnte man auch kritische Rechte an Sichter verteilen. Mein Vorschlag wäre, dass jeder Admin ohne Diskussion das Sichterrecht einem Sichter entziehen kann. Das Ergebnis wäre eine einfache Struktur, die ohne große zusätzliche Diskussion funktionieren könnte. So kann ein Sichter z.B. einen Artikel nur dann sinnvoll löschen, wenn es ein schnelllöschbarer Artikel ist und Vandalen sperren ist auch nicht kritisch. Das heißt, da wo es keine Abstimmungen braucht, könnte auch ein Sichter mit erweiterten Rechten handeln. Hällt sich ein Sichter nicht an diese klaren Vorgaben, entzieht ein Admin dem Sichter sein Recht. --Goldzahn 19:43, 27. Mai 2010 (CEST)

Vielleicht könnte man die Aufgaben aufzählen, die Sichter machen können/dürfen. Werden die dazu benötigten Rechte anders eingesetzt, verliert der Sichter das Recht (wenn es auffällt). Mehr fällt mir eigentlich nicht zu diesem Meinungsbild ein. --Goldzahn 19:55, 27. Mai 2010 (CEST)

In wie fern es programmiertechnisch möglich ist, darüber habe ich mir keine Gedanken gemacht. Es war mehr oder weniger ein "Brainstorming".

Dem Sichter sein Recht zu entziehen, finde ich problematisch. Was macht man dann mit einem Benutzer, der gute Arbeit an Artikeln durchführt und täglich einige Edits durchführt, die umproblematisch sind. Dann schlägt er mit den erweiterten Rechten einmal über die strenge und schwups, seine Edits müssen nachgesichtet werden. Das kann auch nicht der Sinn sein. Gruß, --Gamma127 19:57, 27. Mai 2010 (CEST)

Im Normalfall hat ein Sichter aber, paralell zu seinen Sichterrechten, auch automatisches Sichterrecht. Dieses kann nur durch eine Sperre entzogen werden; desweiteren kann es ja auch im Ermessen des Admins geben. Wenn der User so erfahren ist und immer sehr gute Arbeit macht, kriegt er einen kurzen Rüffel und die Sache ist gegessen. --Z1 21:06, 27. Mai 2010 (CEST)

Diskussion reduzieren

Das Meinungsbild hat ein wichtiges Thema aufgegriffen. Um eine bedauerliche Zerfaserung des Themas durch kontraproduktive Diskussionen zu minimieren würde ich die Aufteilung auf mehrere, nacheinander folgende, Meinungsbilder vorschlagen.

1. Mehr Rechte: ja-nein
2. welche Rechte,...

Ansonsten ist die Festigung des Status Quo bereits vorbestimmt.

Anmerkung: die gruppendynamischen Prozesse in Wikipedia neigen generell zum Stillstand.
Im Fall dieses Meinungsbildes zum Status Quo. Um diesen Prozeß auf konstruktive Art zu nutzen, muß der "Stillstand-Effekt" verhindert werden.

Wenn ich helfen kann - gerne. Ansonsten: viel Erfolg! BG --Friedrich Graf Werde Kommissar 22:41, 26. Mai 2010 (CEST)

Eine Aufteilung ist sicher sinnvoll, aber nicht in der vorgeschlagenen Art. Aus welchem Grunde sollte man einem pauschalen "mehr Rechte" zustimmen, wenn gar nicht klar ist, welche gemeint sind, wenn man beim zweiten Teil nicht jedesmal mit ja stimmt? Zusätzlich ist die Frage unnötig: Jedes gewünschte Zusatzrecht einfach getrennt abstimmen, dann kann jeder so stimmen, wie er es für richtig hält. Andernfalls sind taktische Stimmen vorprogrammiert - und die werden doch im Allgemeinen für wenig wünschenswert gehalten. -- Perrak (Disk) 22:47, 26. Mai 2010 (CEST)

Wikipedia:Meinungsbilder/Sichtbarkeit gelöschter Artikel

Das (eingeschlafene) MB deckt einen Teil dieses MBs ab. Zwei MBs zum selben Thema sind eher nicht so sinnvoll. Vielleicht kann man die MBs ja zusammenlegen (oder, falls man sich für eine Aufteilung, wie hier bereits von einzelnen vorgeschlagen, entscheiden sollte, das ältere MB gleich als einen der Teile benutzen). -- Chaddy · D·B - DÜP 02:10, 27. Mai 2010 (CEST)

Ich glaube, da gibt es ein Missverständnis. Mit diesem Meinungsbild soll keinesfalls erreicht werden, dass gelöschte Versionen sichtbar sind. Das, was mit deletedhistory gemeint ist (ich glaube, ich verfasse später mal eine Begriffsklärung im MB), ist, dass man die Zusammenfassungszeile des gelöschten Artikels und den Benutzernamen des Erstellers sowie alle weiteren Änderungen sieht. So ist beispielsweise ein SLA schnell zu entdecken, bei Vandalismu ist schon aus der Zusammenfassungszeile heraus zu erkennen, dass es sich um einen Unsinns-Artikel handelt. --80.131.61.188 07:24, 27. Mai 2010 (CEST)

Könnte eine sinnvolle Erweiterung sein. Ist bereits abgeklärt, ob dieses Recht (und die anderen Rechte) überhaupt separat vergeben werden kann? Wenn dafür eine Änderung der Software nötig wäre, sollte das zumindest erwähnt werden. -- Perrak (Disk) 09:43, 27. Mai 2010 (CEST)

Ich habe mich darüber auf der MediaWiki-Seite (und im dort angebotenen IRC) informiert. Die Software muss kaum geändert werden, dort muss nur eine Zeile geändert werden, in der LocalSettings.php, die definiert, was die Benutzergruppe "editor" für Rechte hat. Sollte aber leicht umsetzbar sein, die Administratoren haben auch kürzlich, durch eine Änderung der Versionslöschung, eine solche Änderung der Rechte erfahren. Eine Begriffsklärung könnte auch ich schreiben, wenn ich gleich Zeit habe, liebe IP. --Z1 13:49, 27. Mai 2010 (CEST)

Benutzer sperren

Ich halte das für eine äußerst schlechte Idee, allen Sichtern (was so ungefähr jeder halbwegs aktive Mitarbeiter hier ist) block-Rechte zu geben. Von den wirklich „großen AutorInnen“ hier erwarte ich zwar keinen Missbrauch, aber wenn ich mir anschaue, was bei den VM und im VA so aufschlägt, dürfte es dadurch ständig zu unberechtigten Blocks in Folge von Edit-Wars oder einfach Unstimmigkeiten kommen...--Cirdan ± 13:22, 27. Mai 2010 (CEST)

Das habe ich in Diskussionen außerhalb dieser Plattform (IRC) auch gehört. Genauso wie das Löschen und Ent/Sperren von Artikeln. Daher wird man wohl für jedes Recht einzeln abstimmen können - wer will, dass es alle Rechte gibt, trägt überall seinen Namen ein, wer nur einzelne will, tut es entsprechend nur bei den einzelnen.

Es ist leicht einzusehen, dass Löschungen, Sperrungen und Seitenschützungen nur in Notfällen durchgeführt werden sollten. Daher sollte man eher kleine Brötchen backen und erstmal überprüfen, ob man den Sichtern überhaupt deletedhistory, supressredirect und unwatchedpages aufdrücken kann oder ob das schon zu konflikten führt. --Z1 13:56, 27. Mai 2010 (CEST)

Das Bedürfnis nach deletedhistory

… dürfte sich, wenn das neue revisiondelete einige Zeit angewendet wird, von selber lösen, da auf per revisiondelete gelöschten Versionen normalerweise Bearbeiter und Kommentar sichtbar sind (wenn diese nicht explizit gelöscht wurden, was nur dann geschehen sollte, wenn es gute Gründe dafür gibt). Gruß --dealerofsalvation 17:30, 27. Mai 2010 (CEST)

Und wenn Artikel ganz gelöscht werden? Damit hat revisiondelete nichts am Hut. Und wenn ich die Admin-Notizen richtig gedeutet habe, soll revisiondelete nur sehr dosiert eingesetzt werden. --Z1 17:32, 27. Mai 2010 (CEST)

zum ersten Einwand: Stimmt, damit ist m. E. mein Beitrag hinfällig. Trotzdem noch zum zweiten: Nein, revisiondelete ist das jetzt Standardverfahren für Versionslöschungen, „sehr dosiert“ bezieht sich darauf, dass es nicht häufiger angewendet werden soll als die alten Versionslöschungen. --dealerofsalvation 07:07, 28. Mai 2010 (CEST)

Weitere Rechte

Meiner Meinung nach sollte auch über folgende Rechte diskutiert werden:

• reupload-shared
• browsearchive
• upload_by_url
• (versiondetail) (wobei ich da selbst nicht weiß, wozu das genau gut sein soll...)
• deletedtext
• (import)
• (importupload)
• (move-subpages)

Was sie bedeuten, kann man Spezial:Gruppenrechte entnehmen. -- Chaddy · D·B - DÜP 21:33, 27. Mai 2010 (CEST)

Ich habe einige Probleme mit deiner Liste, ich grase sie mal ab:

· reupload-shared: Verstehe ich nicht, was genau dabei überschrieben werden darf. Sind damit die Commons-Bilder gemeint? Habe in der MediaWiki nachgefragt; mit diesem Recht ist es möglich, Commons-Bilder zu überschreiben. Klares NEIN! Damit geben wir den Sichtern ja internationales Recht der Wikimedia. Wenn wir da Mist bauen, betrifft das die ganze Welt.

· browsearchive: Meinetwegen. Aber was bringt das gezielte Suchen nach gelöschten Dateien, wenn man eh nur die Versionshistorie betrachten kann?

· upload_by_url: Nein. Es macht URVs zu einfach. Nur weil man Sichter ist, heißt es nicht, dass man sich mit der DÜP auskennt.

· versiondetail: Das wird wahrscheinlich nicht erlaubt. Bei der Wikipedia dauert ein Versionsupdate ggf. seine Zeit. Wenn der Sichter jetzt weiß Oh, es ist eine neue Version raus, guck ich mir glatt mal die Bugs an, die behoben wurden, kann er die Bugs sehr leicht ausnutzen. Auch ein nein.

· deletedtext: NEIN! Was sollen die armen Oversighter sagen? Desweiteren haben die Administratoren keinen Platz mehr, Telefonnummern auszutauschen (*gg*). Nein, jetzt mal im Ernst: Wenn ein User eine URV erstellt oder gegen den Datenschutz verstößt, soll eine Löschung dies verstecken. Und nicht für aktive Autoren weiterhin sichtbar bleiben.

· import: Ich sehe dafür keinen Sinn. Selten muss importiert werden und ich glaube, es macht die Arbeit nicht einfacher, wenn wir tausende Artikel an Babbelfisch-Gelabere erhalten.

· importupload: Das Risiko für eine URV ist zu groß, bin dagegen.

· move-subpages: Unterseiten existieren nur selten im ANR. Und nur dort sollte ein Sichter seine erweiterten Rechte einsetzen (gut, wenn rollback mal im BNR sinnvoll ist, ist es ihm dort nicht verwehrt), aber das Verschieben von ganzen Unterseiten produziert:

a.) Haufenweise Systemressourcen

b.) Haufenweise rote Links

Auch da bin ich also gegen.

Ist nur meine eigene Meinung, mal sehen, was die anderen sagen. --Z1 21:51, 27. Mai 2010 (CEST)

• reupload-shared hast du falsch verstanden: Es geht lediglich darum, Bilder mit demselben Namen lokal hochladen zu können, wie ein bereits vorhandes Commons-Bild. Das ist besonders dann praktisch, wenn man wieder mal Bilder von Commons retten muss, weil sie dort gelöscht werden (was recht häufig vorkommt). Bei diesen z. T. recht großen Rettungsaktionen mussten bislang immer Admins aushelfen.
• browsearchive: Es ist damit leichter nachvollziehbar, was alles gelöscht wurde (zeitweise war das recht sogar mal public, wenn ich mich noch richtig erinnere, das wurde dann aber wieder auf Admins beschränkt). Ein besonderes Gefahrenpotential sehe ich darin jedenfalls nicht.
• upload_by_url macht URVs auch nicht viel einfacher als bislang. Man spart sich nur das Zwischenspeichern der Bilder auf dem PC.
• versiondetail: Wie gesagt, ich weiß nicht wirklich, was das ist. Klang jedenfalls nicht besonders gefährlich. Ich hab´s mal nachträglich eingeklammert.
• deletedtext: Bei Datenschutzproblemen muss sowieso per oversight gelöscht werden, das wäre dann mit deletedtext nicht einsehbar. Und URVen würden dann leichter nachprüfbar sein (es kommt leider recht häufig vor, dass eine mögliche URV bereits gelöscht wurde, bevor ein UFler drüber schauen konnte. Somit ist es dann häufig (v. a. auch bei Bildern), schwerer nachvollziehbar, ob die Löschung berechtigt war. Man könnte das Recht aber auch an eine "exklusivere" Benutzergruppe verteilen (die müsste dann aber wohl erst geschaffen werden), denn das ist auch für Nicht-Admins nicht ganz unwichtig.
• import: Importiert werden muss häufiger, als du denkst. So würde die Arbeit von Übersetzern erleichtert werden, wenn sie nicht erst einen Admin bitten müssen, den Text vorher zu importieren. Ist aber wirklich nicht so wichtig, genauso wie importupload, dehalb ja auch die Klammern.
• move-subpages: Ist auch nicht wichtig, hab´s nachträglich eingeklammert.

Alles in allem sind diese Rechte bei weitem nicht so "gefährlich" wie User blocken oder Seiten schützen und auch nicht gefährlicher als suppressredirect oder unwatchedpages. -- Chaddy · D·B - DÜP 22:51, 27. Mai 2010 (CEST)

Okay, ich füge die Optionen mal zum MB hinzu. Wobei ich immer noch sehr stark gegen deletedtext. Danke für deine Verbesserungen :) --Z1 07:25, 28. Mai 2010 (CEST)

14 Optionen

Meint ihr nicht, dass 14 Stimmen pro Benutzer zu kompliziert sind? Kann man das nicht in Päckchen zusammenfassen (also die weniger gravierenden Rechte als ein Abstimmungsblock) oder anderweitig vereinfachen? Denn abgesehen von Bearbeitungskonflikten werden wohl die wenigsten Lust darauf haben, so viele Stimmen hier einzutragen.--Cirdan ± 15:16, 28. Mai 2010 (CEST)

Zunächst waren es 7 Rechte, nachdem über die Diskussion weitere Wünsche eingeträufelt sind, habe ich sie einfach mal hinzugefügt. Eine Sortierung erscheint mir aber sinnvoll. Werde mich mal drum kümmern. --Z1 15:21, 28. Mai 2010 (CEST)

Habe nun drei Blöcke erstellt. Da aber eine Wahl en blok auch unerwünscht war, werde ich mal eine Wahl hier einfügen (Alte Version) --Z1 15:34, 28. Mai 2010 (CEST)

Die Blöcke sind eher ungünstig. Insbesondere, da Du das Recht zur Unterdrückung von Redirects zu den harmloseren gestellt hast - das ist meiner Meinung nach potentiell gefährlicher als das Löschen von Artikeln. Wenn das so blockweise abgestimmt würde, müsste ich Sachen ablehnen, die ich eigentlich bereit wäre (fast) jedem zuzugestehen. -- Perrak (Disk) 22:10, 28. Mai 2010 (CEST)

Warum soll suppressredirect so gefährlich sein? -- Chaddy · D·B - DÜP 00:02, 29. Mai 2010 (CEST)

Sortierung der Optionen

Scheint wohl Streit drum zu geben. Um eine große Zahl an Ablehnung der Meinungsbilder zu vermeiden, fände ich es ganz passend, wenn man mal sagt, wie man die Wahl sortiert haben möchte. --Z1 15:34, 28. Mai 2010 (CEST)

Option 1: Blockartig

In der aktuellen Version vorzufinden. Bitte mit # --~~~~ eventueller Begründung Abstimmen.

Option 2: Alle 14 Optionen einzelnd

Hier sichtbar. Bitte mit # --~~~~ eventueller Begründung Abstimmen.

1. --Z1 15:34, 28. Mai 2010 (CEST) Keine Gruppierung, volle Freiheit für alle. Ist eher unerwünscht, dass man "gezwungen" wird, einen Kompromiss schließen zu müssen
2. -- Perrak (Disk) 22:11, 28. Mai 2010 (CEST) Siehe eins drüber: Bitte keine Blöcke, wie wichtig oder riskant die verschiedenen Rechte sind soll jeder für sich entscheiden können. Und warum künstlich Pakete schnüren? Für jedes Recht eine Stimme, einfacher geht es doch nicht.

Meine Meinung zu den erweiterten Rechten

Sichter zu „Zweit-Administratoren“ zu erheben, ist zu riskant: Die Voraussetzungen, um Sichter zu werden, sind sehr gering. Sichterrechte werden automatisch und ohne große Prüfung vergeben. Nach 300 Edits kann man noch nicht von „erfahren“ sprechen. Die Vergabe aller vorgeschlagenen Rechte an Sichter würde zu neuen Formen des Vandalismus und Edit-Wars führen.

• suppressredirect: JA, sinnvoll ist das bei Schreibfehlern, sowie bei Verschiebungen BNR → ANR. Kann bei Missbrauch mit der gleichen Funktion rückgängig gemacht werden.
• block: NEIN. Kann in Edit-Wars missbräuchlich eingesetzt werden.
• deletedhistory: Nur nach Prüfung, da hier auch beleidigende Bemerkungen sichtbar sein könnten. Vorteil ist aber die bessere Nachvollziehbarkeit, da eventuell der Grund für die Löschung sichtbar ist.
• unwatchedpages: JA. Seiten sollten „adoptiert“ werden, da Benutzer auch mal was auf die Diskussionsseite schreiben. Als Vandalismusbekämpfung ist das aber nicht nötig, dafür haben wir die WP:GSV.
• delete: NEIN. Als nächstes führen wohl Edit-Wars zu Lösch- und Neueinstellungs-Wars.
• protect: NEIN. Seitenschutze werden aufgebaut, um Vandalismus und Edit-Wars zu vermeiden. Wenn ich das Recht nun den Sichtern gebe, dann können die nun bei Edit-Wars dieses Recht missbräuchlich einsetzen.
• reupload-shared: EINGESCHRÄNKT, da das zum Beispiel nur bei Löschanträgen in Commons sinnvoll ist. Dazu müsste man ausschließlich das Bild aus Commons lokal hochladen können.
• browsearchive: Siehe deletedhistory.
• upload_by_url: EVENTUELL, da diese Funktion vielleicht auch URVs produzieren kann.
• versiondetail: Die Version kann ich auch unter Spezial:Version einsehen.
• deletedtext: Nur nach vorheriger Prüfung, da hier intime und/oder beleidigende Bemerkungen begraben sein könnten. Ein Disclaimer wäre sinnvoll, damit niemand versehentlich URV irgendwohin kopiert. Hier wären temporäre Oversighter sinnvoll, die vor Freischaltung die gelöschten Versionen durchkämmen (kann eine ganze Weile dauern).
• import: SPÄTER, wenn das WP:SUL fertiggestellt ist, da es ansonsten zu Chaos kommen könnte. Außerdem müsste die Funktion so gestaltet werden, dass ein nochmaliges Verschieben (mit suppressredirect) nicht mehr nötig ist.
• import-upload: NEIN. Diese Funktion könnte dafür missbraucht werden, fremden Benutzern zum Beispiel persönliche Angriffe in den Mund zu legen.
• move-subpages: JA. Diese Funktion ist sinnvoll, wenn beispielsweise solche Seiten wie Benutzer:Bdk/Benutzerbewertung in den Namensraum eines anderen Benutzers verschoben werden sollen (gesperrter oder inaktiver Benutzer). Missbrauch könnte mit der gleichen Funktion rückgängig gemacht werden.

Meiner Meinung nach sollten lieber neue Administratoren gewählt werden, als Sichtern zu weitreichende Rechte zu geben. Man könnte ja mal Der Wolf im Wald, Inkowik32, KureCewlik81, Matthias Süßen, Umweltschützen und Wahldresdner fragen, ob sie gerne eine AK durchmachen wollen. -- Tofra ^Diskussion _Beiträge 19:28, 28. Mai 2010 (CEST)

Ich denke, du sprichst aus dem Herzen der meisten Benutzer. Man kann protect und block und so ja erstmal stehen lassen, sie werden eh nicht über die 50%-Hürde kommen. Versiondetail übrigens erlaubt eine detaillierte Einsicht von Spezial:Version. Was genau, versuche ich gerade im Testwiki zu erörtern, wenn dort sich mal ein Bürokrat bequemen würde, meinen Antrag zu lesen ;)

Übrigens ist es sehr selten, dass Beleidigungen per ZQ geschrieben werden. Vandalen überspringen diese Zeile meist und Beleidigungen mit konkretem Namen sind eh Fall für Oversight und releatedversion. --Z1 21:07, 28. Mai 2010 (CEST)

Ich kann mich Tofra nur anschließen. Lieber mehr Admins, als jedem Sichter sensible Rechte zu geben. Aktuell und in den letzten Wochen gab es einige Kandidaturen, bei denen größtenteils vorbildliche Kandidaten wegen diversen „Kleinigkeiten“ nicht gewählt wurden. Wenn ich dann sehe, wer hier alles Sichter ist, kann man nur Schlimmes befürchten... Gruß, --Gamma127 14:31, 31. Mai 2010 (CEST)

Das Szenario mit den „nie vergessenden“ Bots

Hat das im ersten Absatz unter Wikipedia:Meinungsbilder/Änderung der Rechteverteilung#Hintergrund beschriebene Szenario, dass z. B. beleidigende Seiten/Versionen in dem Zeitraum, bis sie gelöscht werden, von Suchmaschinen gefunden und „für immer“ gespeichert werden, einen realen Hintergrund? Einerseits löscht die bekannteste Suchmaschine ihren Cache nach gewisser Zeit, andererseits scheint es mir sinnvoll, bei ungesichteten Seiten durch ein geeignetes Meta-Tag (das müsste <meta name="robots" content="noindex" /> sein) Bots anzuweisen, dass die Seite nicht indiziert wird – bisher wird das offensichtlich nicht praktiziert. Würde mir allgemein sinnvoll erscheinen, auch z. B. um der Werbung dienende Beiträge ein Stück unattraktiver zu machen – gibt es Gegenargumente? Weiß jemand, ob dazu eine reine Umkonfiguration von Mediawiki ausreichen würde, oder wäre dazu Programmierung nötig? Ist, um einen ggf. entsprechenden Antrag in den Bugzilla zu stecken, ein MB nötig? --dealerofsalvation 04:07, 29. Mai 2010 (CEST)

Ich denke, für dein meta schon. Desweiteren ist ja eine Umprogrammierung nötig, da ja beim Aufrufen der Seite überprüft werden muss - gesichtet Ja/Nein - und ein entsprechender Header geladen werden muss. Gehört hier aber nicht rein, war ja nur ein Beispiel. --80.131.69.201 10:21, 29. Mai 2010 (CEST)

Potentieller Missbrauch der einzelnen Benutzerrechte

Prämisse

Die Administratoren sollen in ihrer Arbeit entlastet werden. … So wird zumindest das Meinungsbild begründet. Und doch gibt es nicht nur die Forderung nach aktiven, sondern auch nach passiven Rechten. Wieso? … Ich lese hier die Arbeitsweise heraus, einfach mal durch alle Benutzerrechte gegangen zu sein und alles in dieses Meinungsbild getan zu haben, was momentan an keine oder nur wenige Benutzer vergeben ist, ohne wirklich abzuschätzen, was sinnvoll für die einzelnen Benutzergruppen ist. Diese Rechte sollen dann allen Sichtern übergeben werden, weil die „ein großes Maß an Routine und Vertrauen genießen“. … Diese Prämisse an Sichter zu setzen, erscheint mir recht gewagt, wenn man bedenkt, wie einfach es ist, in diesem Projekt Sichter zu werden, und wie groß die Gruppe auch jetzt schon ist (über 9000 Sichter). Da über die Vergabe von zum Teil hoch sensiblen Rechten abstimmen zu lassen, erschreckt mich, da eine Sichtersocke sehr schnell geschaffen ist und potentieller Missbrauch damit erheblich vereinfacht wird. Ein paar Erklärungen zu einzelnen Rechten:

Passive Rechte

• deletedhistory: Wofür braucht der normale Benutzer dies? Kann mir irgendwie schwer vorstellen, inwiefern es sinnvoll ist, dass ein Benutzer zwar sieht, dass es gelöschte Versionen gibt, aber nicht deren Inhalte sieht. Rein über die Befriedigung von Neugier kann der Wunsch, dieses Recht zu besitzen, nicht gehen. Gefährlich wird dies zudem dann, wenn Benutzernamen, Zusammenfassungen und bei Artikelanlage oft die ersten Wörter zu lesen sind. Hier können sich neben Beleidigungen jeglicher auch persönliche Daten befinden. Solch hoch sensible Daten dürfen gemäß wmf:Privacy policy nicht Massen von Benutzer zugänglich gemacht werden. Die Forderung nach diesem Recht für Sichter läuft somit den Richtlinien der Wikimedia Foundation zuwider. Der Punkt sollte also zwingend entfernt werden.
• deletedtext: Das gleiche gilt natürlich in gleicher Konsequenz auch für die Einsicht von gelöschten Versionen. Erst seit letztem Jahr haben wir Oversights, erst seit letztem Jahr werden genau die Forderungen auf Datenschutz zumindest marginal erfüllt. Ich will nicht wissen, wie viele Administratoren noch immer soetwas löschen und nicht an die Oversights weiterleiten. Wenn ich mir einen halben Tag die letzten Änderungen angucke, gibt es mindestens drei Fälle, die ich melde. Mach ich dies nicht, werden im Pseudo-Logbuch seltenst so viele Sachen gemeldet. Ansprachen an Administratoren direkt, auf WP:AN, wo auch immer, waren bisher nicht erfolgreich. Sechs Millionen Versionen zu überprüfen, wie dies oben vorgeschlagen wurde, ist fern jeglicher Realität. Damit wären dutzende Personen monatelang nur damit beschäftigt. Und wozu dies allse? Auch hier anscheinend wieder nur, um Interesse an gelöschten Inhalten zu befriedigen. Eine Gefahr im Verzug ist nirgends zu erkennen, die Versionen sind ja gelöscht. Wer Einsicht benötigt, kann dies von Administratoren erfragen. Wenn diese das erst 24 Stunden später durchführen, ist dies für keine Seite ein Beinbruch. Sollte eines der beiden Rechte eingeführt werden, wäre die zwingende Konsequenz, dass alle Admins Oversights würden, um Informationen vor Massen von Benutzern verbergen zu können. Nun haben wir aber gerade Oversights gewählt, damit auch nicht die relative große Anzahl an Administratoren dies sieht. Hier wäre dann konsequenterweise noch eine Benutzergruppe über den dann-Oversights einzurichten. Womit das Verhältnis gleich bliebe; nur hätte jeder (unnötigerweise) ein Recht mehr.
• unwatchedpages: Um Missbrauch dieses Rechtes zu verhindern, hat vor kurzem Jimbo Wales Schlachten auf enwikiversity geschlagen und zumindest teilweise verloren. Dort wurden Initiativen gegründet, die genau danach zielen, nicht oder nur wenig beobachtete Seiten über lebende Personen zu manipulieren und zu schauen, wie lange dies so stehen bleibt. Hier für knapp 10.000 und tausende neue Benutzer die Möglichkeit zu schaffen, läuft wmf:Resolution:Biographies of living people zutiefst entgegen. Ein Freischalten dieses Rechtes für die Sichtergruppe wird nicht gestattet werden.

  Addendum Einige Benutzer kennen sicherlich das Programm http://toolserver.org/~mzmcbride/cgi-bin/login.py , das ausgibt, wie viele Benutzer eine bestimmte Seite beobachten. Anfangs war dies für alle Seiten verfügbar, bis Entwickler einschritten und eine höhere Grenze forderten; siehe en:User_talk:MZMcBride/watcher#Fewer_than_30_watchers. Momentan liegt die bei 30; sie kann aber, mit Zustimmung von meta-Administratoren auch aufgehoben werden.

• browsearchive: Das nächste Recht, das ein Tor für das Auffinden privater Daten öffnet. Selbst geoversightete Seiten sind darüber noch zu finden, jegliche private und verleumderische Information kann auch jetzt noch, selbst von nur Administratoren eingesehen werden. Der Bug, den ich damals zusammen mit Mike.lifeguard erstellt hatte, wird auch weiterhin von den Entwicklern ignoriert: bugzilla:19725. Und selbst wenn er gefixt würde, müsste man tausende Seiten im Nachhinein überprüfen, da nicht konsequent aufgeräumt wurde. Und auch hier stellt sich wieder die Frage: Wieso dies alles? Nur, damit der einzelne Benutzer sich selbst Informationen beschaffen kann, für die es keinen zeitlichen Drang gibt.
• versiondetail: Weder dem Ersteller des Meinungsbildes noch mir selbst ist klar, was dieses Recht bezweckt. Insofern ist deren Erlangung nicht hinreichend motiviert; nur es zu besitzen, weil es da ist, erscheint mir ein schwaches Argument zu sein. Eine Änderung von Spezial:Version ist für mich als Administrator angemeldet gegenüber der unangemeldeten Variante nicht erkennbar.

Aktive Rechte

• reupload-shared: Hier wird mir überhaupt nicht klar, wieso dieses Recht benötigt wird. Neben der Tatsache, dass damit wieder tausenden Benutzern ein Mittel in die Hand gegeben wird, das man wunderbar einfach missbrauchen kann. Man lade einfach ein widerwärtiges Bild auf dewiki hoch, das von Commons kommend zum Beispiel gerade auf der Hauptseite verlinkt ist. Auch hier besteht kein Zeitdruck, wir sind in einem perpetuierenden Projekt; wir können warten, sollte es wirklich mal nötig sein, dieses Recht zu benutzen. Und auf WP:AAF oder WP:FZW schauen ständig Administratoren vorbei; zudem gibt es nur das Support-Team und die Diskussionsseiten einzelner Administratoren. Das Missbrauchspotential übersteigt den Nutzen bei weitem.
• upload_by_url: Davon einmal abgesehen, dass ich dieses Recht jemals genutzt habe, noch wüsste, wo ich es benutzen sollte, erscheint mir hier höchstens die Vereinfachung von Urheberrechtsverletzungen dagegen zu sprechen. Allein für dieses Recht allerdings ein Meinungsbild aufzusetzen, übersteigt die Kosten-Nutzen-Rechnung meines Erachtens bei weitem.
• move-subpages: Ich erträume mir zwar hier Verschiebevandalismus der ganz besonderen Art, viel kann man damit aber wirklich nicht kaputt machen. Passiert halt nur, dass man auf einmal nicht nur ein potentiell verleumderisches oder persönichkeitsrechtsverletzendes Lemma hat, sondern gleich mehrere; dies dann mehrfach auf Beobachtungslisten, in Logbüchern zu haben etc. mag nur ein schwaches Argument sein. Die Reversibilität spricht allerdings für das Recht.
• block: Am besten inklusive dem hoffentlich bald abgetrennten Recht auf unblock. Dann können wir sehen, wie tagtäglich Wheel wars geschehen, wo Sichter sich gegenseitig sperren und wieder entsperren. Schon jetzt mit der überschaubaren Gruppe an aktiven Administratoren funktionieren Sperrungen nur bedingt, da schon jetzt die Gruppe zu heterogen ist und die oft nötige Konsequenz unterbleibt, weswegen wir immer mehr Gremien einrichten, die dann doch nicht die Konsequenz bieten können, die wir dann manchmal doch brauchen.
• delete: Ohne das Benutzerrecht undelete? Damit zwar tausende Benutzer die Möglichkeit haben, sofort vandalierend dutzende Artikel löschen zu können, aber nur ein paar hundert Administratoren dem hinterherarbeiten können? Ich stelle mir Absprachen vor, wo eine, sei es auch nur kleine Gruppe sich an exzellente oder Hauptseitenartikel ranmacht. Und es würde nichtmal reichen, sie zu sperren. Sie haben ja gleich auch noch das unblock-Recht, mit dem sie sich entsperren können, woraufhin sie weiterlöschen können. Also müsste man ihnen erst die Sichterrechte entziehen, bevor man sie sperren kann, bevor man die Artikel wiederherstellen kann. Man stelle sich dies zu einer Zeit vor, in der wirklich nur wenige Administratoren aktiv/wach sind. Ein Chaos würde entstehen! Ein leider ebenso vollkommen unrealistisch-problematischer Vorschlag. … Mit undelete wäre es möglich, lizenzwidrige Versionvermengungen en masse zu produzieren; mir wurde gesagt, dass ein Developer die dann einfach auseinanderdividieren kann. Ich glaube irgendwie nicht wirklich dran. Man schiebe einfach mal ein paar exzellente Artikel auf die Hauptseite und stelle wieder her. Das kann es irgendwie nicht sein.
• protect: Vermutlich bin ich einfach zu pessimistisch (oder habe in meiner Wikikarriere schon zu viele gerissene Vandalen gesehen), aber hier stelle ich mir Protection-wars über die „richtige“ Version vor. Zudem hätten dann die Sichter die Möglichkeit, Seitenvollschutze zu entfernen; ich denke da zum Beispiel an die Hauptseite. Gezüchtete Sichter, allein mit der Intention, die Hauptseite mit irgendwelchen ASCII-Gesäßen oder sonstigem Vandalismus zu zerstören. Auch dies leider ein utopischer Vorschlag, der zu viel Missbrauchspotential bietet.
• import: Da warte ich nur auf die ersten Personen, die Artikel absichtlich über andere importieren, um auch hier Versionsvermengungen zu erreichen. Wie oben geschildert erachte ich dies als wenig sinnig. Zwar kann man beim import nur den Zielnamensraum und nicht das Ziellemme angeben, gepaart mit anderen Rechten kann dies aber gefährlich werden. Und auch hier stellt sich die Frage: Wozu? Kommen auf WP:IMP die Administratoren nicht hinterher, die Anträge abzuarbeiten? Einen Antrag sehe ich gegenwärtig da, sonst sind alle abgearbeitet. Eine Not, dies tausenden Benutzern zu ermöglichen, besteht ebenso wenig.
• importupload: In jedem Falle das Benutzerrecht mit dem großten Missbrauchspotential. Dies allein vorzuschlagen, zeugt von wenig Fingerspitzengefühl in Bezug auf Missbrauch oder Datenschutz. Hiermit kann man faktisch alles machen, nichtmal Administratoren haben dies – nur Stewards und wenige Importe hier, denen das zugetraut wird. Dem Missbrauch sind kaum Grenzen gesetzt, geloggt wird überaus dürftig. Auch hier wurde mir von Entwicklerseite angetragen, dass man trotzdem noch erkennen könnte, was importiert wurde und was nicht. Hier muss ich diesem Wort vertrauen. Und nein, ich vertraue ganz und gar nicht zehntausenden Menschen, dies mit bestem Wissen und Gewissen zu tun.

Ich subsummiere: Fast alle Rechte, die vorgeschlagen wurde, enthalten entweder so viel Missbrauchspotential, dass ein Aktivieren mehr Ärger als Nutzen brächte, oder laufen direkt Resolutionen und Policys der Wikimedia Foundation entgegen. Einzig upload_by_url und move-subpages könnte ich vertreten; bei dem einen vorwiegend aus Unkenntnis und wenig Vorstellungskraft, wie man das nutzen und dementsprechend dann auch missbrauchen kann, bei dem anderen aufgrund hoher Reversibilität bei gleichzeitig geringem Missbrauchspotential (solange man nicht noch Verschieben mit Löschen der Zielseite aktiviert). Dafür ein derart gewaltiges Meinungsbild aufzuziehen, scheint mir fern jeglicher Realität. Meine Meinung. Liebe Grüße, —DerHexer (Disk., Bew.) 16:23, 29. Mai 2010 (CEST)

Erstmal freue ich mich über Kritik eines Stewards.

In der Tat, Du hast Recht, ich weiß nicht, was "Versiondetail" heißt, auch nachdem ich im Testwiki mal selber als Administrator drübergeschaut habe. Ohne jetzt aber jede Schuld von mir abzuweisen, so sah die "neue" Rechteliste zu Beginn des Meinungsbildes so aus:

• Beim Verschieben die Erstellung einer Weiterleitung unterdrücken (suppressredirect)
• Benutzer sperren (Schreibrecht) (block)
• Gelöschte Versionen in der Versionsgeschichte ansehen, ohne zugehörigen Text (deletedhistory)
• Liste der unbeobachteten Seiten ansehen (unwatchedpages)
• Seiten löschen (delete)
• Seitenschutzstatus ändern (protect)

Viele Rechte kamen durch einen entsprechenden Antrag hier auf der BD hinzu, desweiteren distanzierte ich mich bereits (ausdrücklich) von fast allen Rechten, bis auf "suppressredirect" (wozu Du dich übrigens überhaupt nicht geäußert hast), deletedhistory und unwatchedpages. Eine Entfernung dieser Rechte wollte ich aber erst nach einiger Zeit der Diskussion vollziehen.

Deine Einwende sind durchaus berechtigt, allerdings sehe ich in deiner Kritik ein sehr starkes Misstrauen gegenüber der Sichtergruppe. supressredirect kann ungefähr so stark missbraucht werden wie die rollback-Funktion, mit der es keine Probleme gibt. Ich streite nicht ab, dass Sichter sich in Edit-Wars verfangen und auch mal über die Strenge schlagen. Ihnen aber vorzuwerfen, dieses Projekt massiv und mutwillig zu zerstören, halte ich für überzogen. Da ich in vielen Punkten deiner Argumentation seit kurz nach dem Erstellen des Meinungsbild einstimme (gegen die neuen Rechte habe ich mich z. T. von Anfang an gesträubt, siehe im Abschnitt Weitere Rechte) werde ich nur Argumente für die oben genannten Rechte, für die ich mich ausspreche bringen:

• supressredirect: Diese Funktion kann kaum missbräuchlich eingesetzt werden. Bei Missbrauch lässt sich der Artikel sehr einfach zurückverschieben, auch von Benutzern, die nur der Autoconfirmed-Gruppe angehören. Meiner Meinung nach erspart supressredirect den Administratoren nur mehr Arbeit. Allerdings sollte den Sichtern klar sein, dass supressredirect lediglich bei Verschiebung von Artikeln aus dem Benutzernamensraum in den Artikelnamensraum (oder umgekehrt) oder bei Falschschreibungen eingesetzt werden sollte. Bei allen Rechten, die über die autoconfirmed-Rechte hinausgehen, gilt doch sowieso "So viel wie nötig, so wenig wie möglich". Das sollte ein Sichter aber gemerkt haben, denn er ist ja nicht gänzlich unerfahren und der gerade genannte Satz gilt auch bei der rollback-Funktion. Sie wird auch nur sehr dosiert bei Vandalismus angewendet. Ich sehe darin kein Problem.
• unwatchedpages: Ich habe mich bemüht, via IRC, mit sovielen Administratoren wie möglich über dieses Recht zu sprechen. Allesamt wundern sich über das Verstecken dieser Spezialseite, wieso sollte es missbräuchlich verwendet werden? Der Unterschied zwischen der dewiki und der enwiki besteht zudem darin, dass wir mit der flaggedrevision-extension eine Benutzergruppe haben, denen man leicht vertraut. Zwar ist das Erhalten dieser Rechte für die meisten der hier arbeitenden ziemlich leicht zu erhalten; ein Vandale aber hat keine Lust, über eine Dauer von 2 Monaten unentwegt hier sinnvolle Edits zu machen.
• deletedhistory: Dieses Recht habe ich nicht allein um des Rechtes willen eingeführt (von wegen Ja, Macht!), sondern um die Nachvollziehbarkeit zu erleichtern und die Anträge auf WP:A/A zur Einsicht in den alten Quelltext möglichst gering zu halten. Beleidigungen, bei denen konkrete Namen erwähnt werden, werden doch, soweit ich WP:A/N richtig verstanden habe, seit neustem mit revisiondelete entfernt - verschwiden also aus deletedhistory. Andere Beleidigungen ohne Namen (Du stinkst) halte ich für nicht schlimm, da würde auch heute kein Oversighter für einspringen. --Z1 17:04, 29. Mai 2010 (CEST)

Oh, ja, suppressredirect habe ich vergessen, da spricht nicht allzu viel dagegen. Also abgesehen von Verschiebungen, die damit leichter übersehen werden könnten. Zudem unterstelle ich, dass nicht jeder Sichter weiß, dass man Seiten erst löschen soll, wenn keine Links mehr auf sie zeigen. Schon bei Administratoren hat man gesehen, dass sie soetwas vergessen haben, ist sicherlich auch mir mal passiert. Bei jedem der tausenden Mitarbeiter diese Kenntnis anzunehmen, erscheint mit zu idealistisch. „Allerdings sollte den Sichtern klar sein, dass supressredirect lediglich bei Verschiebung von Artikeln aus dem Benutzernamensraum in den Artikelnamensraum (oder umgekehrt) oder bei Falschschreibungen eingesetzt werden sollte.“ … mir ebenfalls zu idealistisch. Wieso außerdem nicht nicht nutzen, wenn die Links schon gefixt sind. Bisher kontrollierten (idealerweise) Administratoren beim Ausführen des SLAs nach Verschiebung, dass die Links gefixt sind. Als neuer Sichter wird man sich denken: Hey, ich kann ja ohne Weiterleitung verschieben; dann kann ich das ja auch nutzen. Jedes Mal müsste man dann erklären, wie es richtig abzulaufen hat. Letzlichen sehe ich hier aber mehr Nutzen als mögliche Nachteile. … Rollback ist ein ganz anderes Thema, jeder Benutzer hat das undo-Recht; rollback macht dies nur schneller und für eine Person auf einmal. … „Ihnen aber vorzuwerfen, dieses Projekt massiv und mutwillig zu zerstören, halte ich für überzogen.“ 99 % der Sichter werden dies auch nicht machen. Für ein Prozent postuliere ich dies; das wären 100 Personen. Ein Prozent an Admins sind drei. Damit steigert sich die Zahl der potentiellen Vandalen um rund 3200 %. Bekanntlich wissen wir, dass nur ein Vandale (denken wir an Diesel oder Edgar), die Kräfte von mehr als genug Personen binden können, erscheint mir das wenig sinnvoll. Einberechnet in dieses Zahlenbeispiel ist noch nicht, dass es viel einfacher ist, Sichter als Administrator zu werden. Wenn solche Machtmöglichkeiten bekannt sind, werden Personen eher Kraft darauf verwenden, diese ausspielen zu können. Bei Sichtern sind dies nur 200 Edits und 2 Monate (Potential 400); für Admins ca. 8000 Bearbeitungen und 12 Monate (96000), damit eine Steigerung von 24000 %. Das sind zwei Zahlen, die mir viel zu hoch sind. Und selbst wenn sie abwichen, sind dies noch immer Dimensionen, die dazwischen liegen. Zu viele, zu schnell zu erlangende Sichterrechte gegenüber wenigen gewählten Administratoren. … Zu unwatchedpages siehe Addendum oben, zu deletedhistory habe ich geschrieben, dass dies keineswegs konsequent früher gemacht gemacht wurde, noch gegenwärtig konsequent gemacht wird, noch überhaupt jemals rückwirkend dies getan wird. Diese Informationen sind da und werden wohl auch immer da verbleiben. Auch persönliche Informationen habe ich da gesehen, ich denke da zum Beispiel an meinen Klarnamen, der in mehreren gelöschten Versionen meiner Benutzerseite zu finden, ist höchstwahrscheinlich, jedenfalls bei anderen auch anderer Stelle auch in den Zusammenfassungen. Nun müssten Oversights dies alles nachträglich entfernen. Unpraktisch hoch Zehn, und dies nur, weil auf AN die Administratoren den Wünschen nur innerhalb von 10 und nicht von 2 Minuten nachgehen? Transparenz durch Aufgabe von Datenschutz zu erreichen, erscheint mir auch ein wenig merkwürdig. Grüße, —DerHexer (Disk., Bew.) 18:43, 29. Mai 2010 (CEST)

Addendum Beim suppressredirect habe ich leider übersehen, dass man da wunderbar den Dreieckstausch zum Missbrauch nutzen könnte (ausführlich siehe hier). —DerHexer (Disk., Bew.) 14:21, 2. Jun. 2010 (CEST)

Ich stimme DerHexer in so gut wie allen Punkten zu. Das Missbrauchspotential, das dabei entsteht ist höher als der Nutzen. Es gibt bereits aktuell Sichter, denen man "vandalistische Tendenzen" unterstellen kann. Die erforderliche Anzahl an Edits bekommt man auch relativ schnell oder nach einer längeren Zeit als "Gelegenheits-User".

Wie ich schon oben einmal schrieb: Es wurden schon einige Admin-Kandidaten wegen „Kleinigkeiten“ (z.B. geringe Anzahl von Edits, man kann den Kandidaten nicht einschätzen, etc...) abgelehnt. Es macht in gewisserweise sind, dass nicht jeder Benutzer an sensible Rechte kommt. Auch bei der unwatchedpages-Funktion kann ich nach der Begründung von DerHexer gut verstehen, dass man sie nicht jedem Benutzer geben darf. Gruß, --Gamma127 15:05, 31. Mai 2010 (CEST)