Wikiup:Projektdiskussion/Neue Benutzergruppe zwischen Administrator und Sichter

aus Wikipedia, der freien Enzyklopädie

Dies ist eine archivierte Unterseite der Seite Wikipedia:Projektdiskussion. Wenn du die untenstehende Diskussion reaktivieren willst, dann binde statt der Vorlage:PRD-Diskussionsthemakopf/Archiv am Anfang dieser Seite die Vorlage:PRD-Diskussionsthemakopf ein und trage anschließend diese Unterseite wieder auf der Hauptseite ein, indem du dort am Ende die Zeile
{{<includeonly>safesubst:</includeonly>PRD-Diskussionsthema|Neue Benutzergruppe zwischen Administrator und Sichter}}

ergänzt.

Diskussion vor dem Meinungsbild zur Erweiterung der Sichterrechte (November 2014 - Januar 2015)

Ich bin für die Einführung einer neuen Benutzergruppe, die zwischen Administratoren und Sichtern angesiedelt ist. Auf diese Weise könnten die Administratoren entlastet werden sowie erfahrenere Benutzer einfacher an der Wikipedia mitarbeiten und bei der Organisation unterstützen. Eine solche Idee ist nicht neu, siehe Wikipedia:Meinungsbilder/Änderung_der_Rechteverteilung.
Als Rechte dieser Benutzer habe ich Aufgaben angedacht, die zwar relativ große Erfahrung an der Wikipedia erfordern und vielen Sichtern wohl nicht zugemutet werden können, aber insbesndere bei Streitigkeiten nicht zur Eskalation führen sollten. Die Rechte block (Benutzersperre) und delete/undelete (Löschen) oder gar nuke sind damit natürlich ausgeschlossen. Für eine solche Gruppe, die ich nun im weiteren Verlauf vorest als Erfahrene Benutzer bezeichnen werde, halte ich folgende Rechte für sinnvoll, wobei eventuell problematische Rechte in Klammern stehen:

  • import: Artikelimport könnte von unerfahrenen in ANR kopiert werden
  • unwatchedpages: Keine Vandalismusmöglichkeit
  • deletedhistory: Was war ungefähr da bevor es gelöscht wurde? kann überprüft werden.
  • browsearchive: Weleche Seiten wurden gelöscht (und warum mit deletedhistory)?
  • (deletedtext: Durch den Zugriff auf gelöschte Artikel/Versionen können sinnvolle Teile wiederverwendet werden, kann jedoch rechtliche oder ethische Probleme verursachen)
  • protect: nur ungeschützte Seiten für sehr kurze Zeit (höchste Stufe vielleicht autoconfirmed)
  • suppressredirect: Erfordert viel Erfahrung, da zuvor alle Links umgelenkt werden müssen
  • upload_by_url: Großes Risiko für URVs
  • reupload-shared: Beteiligung bei Rettungen von Dateien aus Commons einfacher möglich
  • movefile: Dateien verschieben

Bei der Auswahl dieser Rechte habe ich mich an dem weiter oben genannten Meinungsbild, an dessen Diskussion sowie an der Seite Spezial:Gruppenrechte orientiert. Die Schwelle für einen solchen Erfahrenen Benutzer richtet sich nach den letzendlich für diese Gruppe zugeteilten Rechten, so erfordern suppressredirect, deletedtext, protect, movefile und upload_by_url mehr Erfahrung als die anderen Rechte. Außerdem stellt sich mir die Frage, warum unwatchedpages und deletedhistory nicht auch für Sichter freigegeben sind.
Eine weitere Frage ist, wie und an wen diese Rechte vergeben werden, auf die gleiche Art wie bei Administratoren erscheint es mir gemessen an der Bedeutung zu aufwendig, eine automatische Vergabe könnte stattdessen genutzt werden, wobei so aber zum einen nicht die wirkliche Erfahrung geprüft werden kann und zum anderen z.B. Editzahlen über 500 nicht mehr repräsentativ für Mitarbeit oder Erfahrung sind. Am besten würde mir hier eine manuelle Vergabe durch Admins gefallen, so wie es bei Sichtungen zumindest teilweise praktiziert wird. (siehe Wikipedia:Gesichtete Versionen/Rechtevergabe). Dabei wäre eine Begründung, sowie einige Richtlinien für Antragsteller natürlich verpflichtend). Da es knapp 250 Admins gibt, sollte es meiner Meinung nach etwa 600-1500 Erfahrene Benutzer geben. (Benutzerststatistik: Spezial:Statistik). Das wären 4% bis 8% der 15000 Sichter.
Zuletzt wollte ich noch anmerken, dass einige Rechte zwar Missbrauchspotential mit sich bringen, aber gerade deswegen möchte ich diese Rechte ja an eine neue Gruppe und nicht an die Sichter vergeben.
Bitte äußert für Meinungen, Anmerkungen, Korrekturen, Ideen und Verbesserungsvorschläge! Sicherlich gibt es einige Probleme, die ich übersehen habe! MfG--MGChecker (Diskussion) 17:24, 11. Nov. 2014 (CET) Weiter Informationen zu den Rechten gibt es hier: Hilfe:Gruppenrechte. --MGChecker (Diskussion) 13:48, 18. Nov. 2014 (CET)

Verschieben ohne Anlage einer Weiterleitung kann man auch dazunehmen – ist ja kein richtiges Löschen.--84.161.175.23 17:33, 11. Nov. 2014 (CET)
Genau das verbirgt sich hinter suppressredirect. --MGChecker (Diskussion) 17:52, 11. Nov. 2014 (CET)
Hier mein Senf zu den oben vorgeschlagenen Rechten:
  • import: Keine Bedenken, Bedarf besteht vor allem bei Nachimporten, wofür allerdings das Löschen und Wiederherstellen von Seiten Voraussetzung ist.
  • unwatchedpages: Dieses Recht könnte man auch den aktiven Sichtern geben.
  • deletedhistory, browsearchive und deletedtext: Dafür brauchen wir wohl ein Wahlverfahren, das mit dem für Administratoren vergleichbar ist.
  • protect: Entsteht dadurch nicht vielleicht zusätzliches Konfliktpotential?
  • suppressredirect: Keine Bedenken.
  • upload_by_url: Auch dieses Recht könnte man aktiven Sichtern geben.
  • reupload-shared: Keine Bedenken.
  • movefile: Zwar glaube ich nicht, dass hier zusätzlicher Bedarf besteht, aber keine Bedenken. --Morten Haan 🌲 Wikipedia ist für Leser da 18:18, 12. Nov. 2014 (CET)
Hallo @Morten Haan:, danke für deinen Kommentar. Bei upload_by_url wird oft als Begründung dagegen aufgeführt, dass Urheberrechtsverletzungen einfacher seien. Dies kann ich nicht nachvollziehen, da nur das Herunterladen der Dateien gespart wird. Die meisten Begründungen gegen Rechte wie import, suppressredirect sind dadurch begründet, das sie auch missbraucht werden können. Ein Vandale sollte es jedoch keinesfalls bis in diese Benutzergruppe schaffen. Um das Problem bei protect näher zu erläutern: Dieses Recht wäre stark eingegrenzt. So könnte ein Erfahrener Benutzer z.B. eine temporäre Sperre für höchstens 6 Stunden festlegen, wobei er dies nur für IPs und kürzlich angelegte Benutzer tun könnte, um Vandalismus zu verhindern. Ist eine solche Begrenzung nicht möglich, fällt dieses Recht heraus und verbleibt bei den Andmins. Eine weitere Idee wäre, den Shutz vieler Seiten von sysop auf experienced zu senken. Deinen Kommentar zu deletedhistory, browsearchive und deletedtext verstehe ich nicht, wäre nett, wenn du ihn noch einmal näher erläuterst. Zuletzt muss man bei der Vergabe solcher Rechte natürlich auch die Wikimedia-Policys (die ich so gut wie gar nicht kenne) bedenken. --MGChecker (Diskussion) 19:37, 12. Nov. 2014 (CET)
Ich denke, dass die Benutzer dieser neuen Gruppe eine gewisse Erfahrung haben und dass Missbrauch als ausgeschlossen gilt.
  • Zum Upload: Ich halte es für möglich, dass der Upload mittels URL bei neuen Benutzern dazu führt, dass sie einfach Dateien von anderen Websites hier hochladen, ohne sich über das Urheberrecht Gedanken zu machen. Das Herunterladen ist eine eine kleine Hürde. Aktive Sichter sollten aber wissen, dass man nicht einfach Bilder von anderen Sites hier einstellen kann.
  • Seiten schützen: Möglicherweise sind diese Einschränkungen (ggf. über den Missbrauchsfilter) möglich. Falls nicht sollte das Recht ausgeschlossen werden.
  • Ansehen von gelöschten Inhalten: Ich kenne mich mit den Policys auch nicht zu gut aus, meine aber schonmal gelesen zu haben, dass die WMF dafür gewisse Anforderungen bezüglich der Vergabepraxis hat.
Morten Haan 🌲 Wikipedia ist für Leser da 21:20, 12. Nov. 2014 (CET)
Siehe dazu z.B. WD:Meinungsbilder/Admin_auf_Probe_2#Antwort_der_WMF_und_weiteres_Vorgehen: I think it is also worth noting, as Geoff has mentioned in posts regarding similar proposals, increasing the size of the group who may view or undelete sensitive legal matters could increase liability risks for the Foundation, established admins, and this new proposed class of trial admins. Without full vetting by the community, the proposed class of trial admins are much more likely to (and therefore are at higher risk of incurring liability for) mistakenly undeleting content that was originally deleted for legal reasons by other admins, general members of the community, or the Foundation. If we are to find a new way of increasing the size of this group, it must be done carefully and include community review. --Grip99 02:01, 14. Nov. 2014 (CET)
Ich glaube nicht, dass man das braucht. Eher bräuchte man eine Sperreinstellung, die zwischen autoconfirmed und adminonly ist, z.B. Stimmberechtigung.
Aber wenn man sowas macht, wie Du es vorschlägst, dann hätte ich (neben deletedtext) Bedenken bei supressredirect (und evtl. auch bei movefile, wenn es dort auch keine Weiterleitung gibt). Und protect ist auch nicht sinnvoll, sonst haben IPs hier bald gar nichts mehr zu melden. --Grip99 02:01, 14. Nov. 2014 (CET)
@Grip99: Die Idee, eine neue Sperreinstellung halte ich auch für eine gute Idee. Die Probleme, die du bei suppressredirect siehst, kann ich hingegen nicht nachvollziehen. Die Benutzer, die in diese Gruppe aufgenommen werden, sollten wissen, dass diese Funktion nur selten verwendet werden darf, wie im Falle von Verschiebungen von Benutzer- in Artikelnamensraum oder Schreibfehlern im Lemma. Diese Benutzer tragen auch eine bestimmte Verantwortung, alle Links auf das Verschiebeziel umzulenken. Und gerade aus diesem Grund bin ich auch dagegen, diese Recht schon Sichtern zu geben. MfG --MGChecker (Diskussion) 00:22, 15. Nov. 2014 (CET)
Durch Verschieben ohne Weiterleitung (z.B. aus dem ANR in den eigenen BNR) kann man eine tausendfach verlinkte Seite mit einem Schlag zur Vollwaise machen. Das hätte de facto (bis zu einer Rückverschiebung) für den Durchschnittsleser fast den Effekt einer Löschung. Gut, auch bei Verschieben mit WL kann man hinterher noch die WL woandershin umbiegen und damit einen ähnlichen Effekt erreichen. Das relativiert meinen Einwand etwas. Aber ohne WL ist es noch unübersichtlicher und es passieren mehr Versehen.
Jedenfalls sollte man sich über diese Gefahr im Klaren sein, bevor man das Recht vergibt. --Grip99 00:31, 17. Nov. 2014 (CET)
Ich habe gerade noch ein Benutzerrecht entdeckt, welches ebenfalls gut für diese Gruppe wäre, und zwar move-subpages. So könnten Unterseiten bei Verschiebungen gleich mitverschoben werden, eventuell sogr etwas für Sichter. Gerade bei Benutzer-, Wikipedia- und Portalseiten wäre das sehr hilfreich.
Weiß jemand, welchen Policies das Meinungsbild Änderung der Rechteverteilung widersprach, sodass es abgebrochen wurde? Um welche Verstöße handelte es sich? Es soll von vornherein vermieden werden, dass es wieder dazu kommt, falls wieder ein Meinungsbild über dieses Thema aufgesetzt wird. Inwieweit solche Rechte auch an Sichter vergeben werden können, muss später entschieden werden. --MGChecker (Diskussion) 13:45, 18. Nov. 2014 (CET)
Siehe WD:Meinungsbilder/Änderung_der_Rechteverteilung#Potentieller_Missbrauch_der_einzelnen_Benutzerrechte. Siehe dort am Ende auch noch ein potenzielles Missbrauchsszenario für suppressredirect. --Grip99 02:44, 24. Nov. 2014 (CET)
Ja, ich weiß, das solche Rechte ein Missbrauchsrisiko mit sich bringen. Darum will ich das Recht ja auch nicht an 15.000 Sichteer, sondern an etwa 1.000 Verlässliche Benutzer. Zur Abstimmung würde ich folgende Rechte stelen (import macht ohnee delete und undelte wenig Sinn, deletedtext aufgrund versch. Problemen gestrichen):
  1. Eventuell auch für Sichter
    • move-subpages
    • unwatchedpages
    • upload_by_url (Eignung für Sichter fragwürdig)
  2. Nur für Verlässliche Benutzer
    • suppressredirect
    • reupload-share
    • movefile
    • deletedhistory
    • (browsearchive)

Vorschlag: Ausarbeitung zweier Meinungsbilder: 1. Sichterrechte erweitern, 2. Neue Benutzergruppe --MGChecker (Diskussion) 21:15, 24. Nov. 2014 (CET)

Warum soll das zusätzliche Upload-Recht für Sichter ungeeignet sein? Aktive Sichter sollten ohnehin wissen, dass man nicht einfach Dateien von fremden Websites hier hochladen kann. --Morten Haan ⛄️ Wikipedia ist für Leser da 23:16, 25. Nov. 2014 (CET)
Die neue Benutzergruppe könnte man in de-WP wohl sowieso nicht selbst umsetzen, denn sie müsste vermutlich direkt in die WP-Software reinprogrammiert werden. Erweiterung der Sichterrechte ist möglicherweise einfacher. Die Frage ist, ob die Community das Kosten-Nutzen-Verhältnis einer Umstellung so wie Du sieht. Wenn nicht, dann hast Du Dir natürlich hinterher mit dem MB Arbeit gemacht, ohne dass was dabei rausgekommen ist. Das deletedhistory-Recht fände ich auf jeden Fall sinnvoll. Ich sähe da auch nicht die Notwendigkeit eines Wahlverfahrens, wie Morten Haan oben schreibt. Versionskommentare können ja wohl immer noch versteckt werden. Oder wären die dann zwangsläufig nur noch durch Oversighter für den Nicht-Admin unsichtbar zu machen? --Grip99 01:08, 28. Nov. 2014 (CET)
Tja, man könnte die allgemeine Meinung bestimmt besser erfassen, wenn sich mehr als nur drei Benutzer an ihr beteiligen würden. Zu dem Punkt mit der neuen Benutzergruppe:Wikipedia Diskussion:Meinungsbilder/Sichtbarkeit gelöschter_Artikel#Verfahren_füCr_Aufnahme_in_.E2.80.9Eneue_Benutzergruppe.E2.80.9C
Laut diesm Link wäre das relativ einfach. Wenn, würde ich sowieso das MB zu Sichterrechterweiterungen zuserst durchführen, da dieses einfacher einzurichten ist. Schließlich sind die Kriterien für diese Gruppe bereits fest. Einige der Rechte bieten auch quasi kein Missbrauchsrisiko. Gerade von move-subpages bin ich seit einigen Verschiebungen im Benutzernamensraum großer Fan. Angenommen ich entscheide mich dafür ein MB für Erweiterung der Sichterrechte aufzusetzen, wäre ich dafür, move-subpages, unwatchedpages, upload_by_url und deletedhistory zur Wahl zu stellen. Nur die Farge vor allen Dingen an dich als Admin, @Morten Haan: wie viel Funktion würde deltedhistory ohne browsearchive erfüllen? --MGChecker (Diskussion) 01:27, 28. Nov. 2014 (CET)
Schon deletedhistory ist mMn heikel, denn dann müssten unsere Oversighter alle gelöschten Versionen auf zu versteckende Inhalte überprüfen. Außerdem ist das Recht ohne deletedtext mMn ein wenig sinnlos. --Morten Haan ⛄️ Wikipedia ist für Leser da 02:55, 28. Nov. 2014 (CET)
Soweit ich weiß, sagt deletedhistory nur aus, dass man sehen kann, dass es Versionen gibt und was in ihrer Zusammenfassungszeile steht. Da man ja so höchstens die ersten Wörter des Textes sehen kann, verstehe ich nicht wie da groß brisante Inhalte sichtbar werden könnten. --MGChecker (Diskussion) 10:40, 28. Nov. 2014 (CET)
Mehr als
  • unwatchedpages
  • deletedhistory
  • browsearchive
  • protect
  • suppressredirect
benötigt ein Vielschreiber meiner Meinung nach nicht.
Importwünsche werden (mMn) ausreichend schnell erfüllt, und den deletedtext will ich gar nicht sehen müssen. Kann man mit reupload-shared etwas Anderes tun, außer Logos zu retten? movefile sollte zur Qualitätskontrolle den Commons-Admins vorbehalten bleiben.--kopiersperre (Diskussion) 13:33, 28. Nov. 2014 (CET)
In der Zusammenfassungszeile können Verstöße gegen WP:ANON oder WP:BIO stehen. Diese müssen versteckt werden, bevor das Recht an Sichter o. ä. vergeben wird. Davon abgesehen sehe ich keinen Sinn in der Vergabe an Nicht-Admins. --Morten Haan ⛄️ Wikipedia ist für Leser da 16:33, 28. Nov. 2014 (CET)
In der Tat wäre es vieeleicht wohl doch schlecht, die Zusammenfassungen so weit sichtbar zu machen, du weißt sich aus eigener Erfahrung was da so alles drin steht... Na ja. @Kopiersperre: protect ist nicht unbedingt geeignet, dieser Job sollte dann doch den Admins vorbehalten bleiben. Bei suppressredirect besteht ein zugroßes Fehler und Missbrauchsrisiko (vgl. weiter oben), auch deletedtext und browsearchive haben seine Probleme. An der Stelle frage ich mich, ob browsearchive für Sichter villeicht ganz sinnnvol wäre, Gedankengang: „Ach, ich könnte ja mal einen Artikel über XYZ erstellen, obwohl, vielleicht hat es einen Grund das er nicht da ist, oh das ist ja die löschdiskussion verlinkt.“. Wäre der Gebrauch in der Hinsicht nicht sinnvoll und möglich? Außerdem, was könnte dadurch schon für ein Missbrauchsrisko entstehn? --MGChecker (Diskussion) 17:26, 30. Nov. 2014 (CET)
Ich möchte nur ein Kurz-protect (vielleicht 2 Tage). Außerdem rede ich von Halbschutz. Was für einen Sinn hätte es, wenn ich eine Seite so sperren darf, dass ich sie selbst nicht mehr bearbeiten kann?--kopiersperre (Diskussion) 17:34, 30. Nov. 2014 (CET)
zu browsearchive) Wenn ich z.B. auf https://de.wikipedia.org/w/index.php?title=Aerodyn_Energiesysteme&action=edit&redlink=1 gehe, sehe ich schon jetzt, dass der Artikel bereits zweimal gelöscht wurde. Diese Information ist nützlich – aber völlig ausreichend. Ich habe keinen Mangel an Artikelthemen, warum sollte ich nach – sicher nicht grundlos – gelöschten Artikeln suchen?--kopiersperre (Diskussion) 17:40, 30. Nov. 2014 (CET)
zu protect: Wir haben nun mal Rechte, die relativ einfach auf Benutzer verteilt werden können, so wie ich das verstanden habe. Und wir haben auch kein Kurz-protect, das man eingfach so mit vertretbarem AUfwand verteilen könnten. Auch das Programmieren wäre sicher schwierig. Das ist das eigentliche Problem - eine solche Funktion wäre aber zmindest theoretisch aber auf jeden Fall sinnvoll. Ja, aber dann die Frage: Wozu dient browsearchive überhaupt? --MGChecker (Diskussion) 18:05, 30. Nov. 2014 (CET)
@Morten Haan: >Außerdem ist das Recht ohne deletedtext mMn ein wenig sinnlos.
Doch ich fände deletedhistory schon sinnvoll. Oft will man z.B. nur wissen, wann ein Artikel angelegt wurde oder wer einen SLA eingesetzt hat. Für sowas braucht man den Text nicht zu erfahren. Wenn es natürlich tatsächlich so ist, dass dann zwingend geoversightet werden muss (bist Du Dir da wirklich ganz sicher?), dann würde das eine Aufgabenverschiebung mit sich bringen. --Grip99 02:12, 2. Dez. 2014 (CET)

<Nach-links-rück> Zu browsearchive: Dieses Recht erlaubt es, sich Lemmata mit mindestens einer gelöschten Version anzeigen zu lassen, quasi analog zu Spezial:Präfixindex. Ein Klick auf ein Lemma zeigt berechtigten Benutzern die gelöschten Versionen an. Fazit: Ohne deletedhistory ist das Recht mMn sinnlos.
Zu dem Seitenschutz: Das Sperren von Seiten ist recht heikel. Ein eingeschränktes Schutzrecht ist mMn gar nicht so schwer zu programmieren, allerdings habe ich wenig Hoffnung, dass das (in naher Zukunft) jemand macht. --Morten Haan ⛄️ Wikipedia ist für Leser da 23:01, 30. Nov. 2014 (CET)

So ein Recht, ich nenne es mal semiprotect, würde aber auch Probleme mit sich bringen. So müsste zum Beispiel verhindert werden, dass eine Seite in der Schutzstufe sysop von einem Verlässlichen Benutzer abgesenkt wird. Auch eine zeitliche Begrenzung wäre wichtig (12 Stunden ?) Höchste Schutzsstufe wäre natürlich autoconfirmed. Ich denke aber sowieso, dass dieses Recht zwar für Verlässliche Benutzer, aber nicht für Sichter geeignet ist. Außerdem müsste es dann vielleicht eine Möglichkeit geben um Seiten davor zu schützen, von semiprotect geschützt zu werden. Aber auch ich glaube nicht, dass so etwas realisiert würde. --MGChecker (Diskussion) 18:55, 1. Dez. 2014 (CET)
Anfang Januar versuche ich mal, das erste der beiden Meinungsbilder (das für die Erweiterung der Sichterrechte) auf die Beine zu stellen, vorher habe ich für so ein großes Projekt keine Zeit. Würde mich auch vorher schon über mehr Meinungen (sowohl von Admins als auch von Nicht-Admins) hier sehr freuen. --MGChecker (Diskussion) 21:33, 14. Dez. 2014 (CET)
@Morten Haan, Grip99: Ich bin gerade dabei, dass MB zu entwerfen: Verbesserungsvorschläge, Kommentare und Anmerkungen sind natürlich willkommen! Übrigens habe ich gemerkt das upload_by_url nicht mehr vergeben wird. --MGChecker (Disk. | Beitr. | Bewert.) 03:03, 4. Jan. 2015 (CET)

Diskussion nach dem Meinungsbild zur Erweiterung der Sichterrechte (ab Februar 2015)

Ich fange mal hier im neuen Abschnitt an, nachdem mich MGChecker hierher verwies.
Ich hatte tatsächlich auch schon über eine neue Benutzergruppe nachgedacht, der dann weitere Rechte zugewiesen werden könnten. Spätestens mit dem Auftauchen von Flow wäre das dann wohl eh nötig geworden, da damit diverse neue Rechte eingeführt würden, welche nur Admins bekommen sollten (nach WMF-Sicht).
Insgesamt hatte ich über folgende Rechte nachgedacht (hier entnommen):

  • abusefilter-log-private (Logbuch Privater Missbrauchsfilter einsehen)
  • abusefilter-view-private (Private Missbrauchsfilter einsehen)
  • apihighlimits („higher limits in API queries“)
  • browsearchive (Nach gelöschten Seiten suchen)
  • editusercss (Fremde (CSS-Seiten bearbeiten)
  • edituserjs (Fremde JS-Seiten bearbeiten)
  • flow-delete (Flow-Beiträge löschen)
  • flow-edit-post (Fremde Flow-Beiträge bearbeiten)
  • flow-hide (Flow-Beiträge verstecken)
  • flow-suppress („Suppress Flow revisions“)
  • massmessage (Massennachrichten versenden)
  • mf-uploadbutton (Dateien mobil hochladen)
  • move-subpages (Unterseiten mitverschieben)
  • movefile (Dateien verschieben)
  • noratelimit (Aushebeln aller ratelimits, z. B. Wikimail)
  • reupload-shared („Override files on the shared media repository locally“)
  • spamblacklistlog (Logbuch der Spam-Blacklist einsehen)
  • suppressredirect (Weiterleitungen unterdrücken)
  • unwatchedpages (Liste der unbeobachteten Seiten einsehen)

Ich hoffe mal, ich fordere hier keine Rechte, die auch unsere Admins nicht haben (wenn, dann würden die denen natürlich auch zustehen). Mir ist bewusst, dass einige der Rechte gefährlich sein können bzw. zu Problemen führen könnten (z. B. das Einsehen der Missbrauchsfilter), jedoch würde ich das durch hohe Zugangskriterien entschärfen. Die Rechtezuteilung würde automatisch erfolgen. Überlegt hatte ich mir unter anderem:

  • 10.000 Bearbeitungen
  • Mindestens 5.000 Artikel-Bearbeitungen
  • Mindestens ein Jahr angemeldet (oder bestätigter Nachfolgeaccount)
  • Stimmberechtigung zum Schiedsgericht (fraglich ob durchsetzbar, die müssten irgendwie aneinander gekoppelt werden)
  • Möglicherweise Einspruchsrecht bzw. eine Seite, auf der Bedenken angeführt werden können – in dem Fall müsste der Benutzer sich einer „Wahl“ stellen, ob die Community ihm die Rechte zugesteht.

Bei den Kontra-Stimmen beim Meinungsbild kam häufig die Anmerkung, dass das Sichter-Recht zu schnell zu erreichen ist, ich hoffe diese Bedenken durch diese hohen Kriterien aufzulösen. Zumal ich offengestanden darauf setze, dass die entsprechenden Benutzer sich gerne selbst neue Rechte geben würden, solange die nicht zu leicht zu erlangen sind (hier sehe ich zudem einen weiteren Vorteil: den Anreiz, mitzuarbeiten. Viele arbeiten daraufhin, Sichter zu werden – danach kommt nichts mehr, Admin werden nur wenige).
Vielleicht noch zur Orientierung, um wie viele Benutzer es gehen würde. Zum 19. August 2014 hin, hatten 1.897 Benutzer mehr als 10.000 Bearbeitungen – ein Teil davon dürfte gar nicht mehr aktiv sein, so dass die tatsächlich Zahl niedriger liegt. --BHC (Disk.) 17:33, 9. Feb. 2015 (CET)

@BeverlyHillsCop: Darf ich in deinem Beitrag die Rechte entfernen, die ohnehin schon Sichter und niedrigere Benutzer haben? Zu der Rechteübersicht: Spezial:Gruppenrechte könnte ganz hilfreich fpr dich sein. --MGChecker (Disk. | Beitr. | Bewert.) 17:56, 9. Feb. 2015 (CET)
Klar, MGChecker, kannst du natürlich machen. Ich hatte jetzt nur alles rausgeschrieben, was mir sinnvoll erschien, aber nicht nachgeprüft, ob wir die nicht eh bereits haben. Manche Sachen sind halt eher speziell und den Namen weiß man dann nicht unbedingt (und da ich gerade wegmusste, konnte ich nicht gegenprüfen). --BHC (Disk.) 18:51, 9. Feb. 2015 (CET)
@Morten Haan, BeverlyHillsCop, Luke081515: Dann auch mal ein direkt aufs Thema bezogener Kommentar meinerseits:
  • Deine Vorraussetzungen sind schon mal nicht schlecht. Sie haben aber den Nebeneffekt, dass MAssenbearbeitungen zu stark in den Vordergrund gerückt werden. Über 1000 Bearbeitungen sagt der Editcounter nicht mehr viel über die Leistung aus. Eine andere Idee, die mir gerade kommt, ist dass man eine gewisse Anzahl Monate aktiv sein muss (zwischen 6 und 12) und zusätzlich folgende Bedingungen erfüllt sind. Wäre vielleicht besser Die Zahlen sind natürlich noch variabel:
    • Min. 6 Monate mit über 250 Bearbeitungen
    • Min. 600 Bearbeitungen in den letzten 2 Monate
  • Zu den Rechten: Flow werde ich erstmal außen vor lassen, da
    1. ich keine Ahnung von Flow habe
    2. und es hier wohl eh nie eingeführt wird. ^^
  • Zu den anderen Rechten:
    • auf jeden Fall: move-subpages, suppressredirect, unwatchedpages, browsearchive
    • drüber nachdenken, aber sinnvoll: movefile, reupload-shared, deletedhistory
    • weiß nicht: spamblacklist, apihighlimits, noratelimit, abusefilter-log-private, abusefilter-view-private, massmessage
    • eher nicht: edituserjs, editusercss
    • auf keinen Fall:
    • mf-uploadbutton: Das Recht habe ich bisher noch nirgendwo gesehen. Wäre eher wasw für alle. Weiß jemand mehr darüber?
  • Was ich hier noch einbringen will:
    • deletedhistory. Ich weiß, das ist immer schwer, doch es ist auch wichtig.
    • editprotected wär auch so eine Idee. Nur eine Idee. Kaskaddengeschützte Seiten können damit übrigens nicht bearbeitet werden.
  • Ein wesentliches Element dieser Nutzergruppe sollte sein, dass sie passive Rechte erhält, und keine aktiven.
  • Vor einem MB sollten wir zu dieser Thematik auf jeden Fall eine Umfrage starten.
Jo, das wars erstmal von meiner Seite. --MGChecker (Disk. | Beitr. | Bewert.) 19:51, 9. Feb. 2015 (CET)
Mir geht es auch darum, dass diese neue Benutzergruppe eine Art Anerkennung ist. „Erfahrene Benutzer“ nanntest du es oben, mir war sowas wie Verdienter Benutzer eingefallen. Adminrechte sind ein Mittel zum Zweck und nicht etwas, dass man nach dem Motto „Zehn Jahre dabei, da hast du dir die verdient“ erhalten sollte – diese neue Gruppe könnte dagegen genau diese Lücke füllen. Klar, 10.000 sind viel, auch möglich wären 5.000 etc. Wichtig ist nur, dass klar wird, dass diese Benutzer es sich erarbeitet haben. Auch ist eine hohe Edit-Zahl ein wirksamer Schutz gegen Sockenpuppen und Trolle (Stimmberechtigung ist leicht, 1000 Bearbeitungen auch – aber 10.000? Das ist langjährige Arbeit).
Flow kommt nie, wenn wir Glück haben – für den Fall, dass es kommt, sollten diese Rechte gleich mit inbegriffen sein.
  • spamblacklist: Könnte zur Orientierung helfen, hier primär aus Vollständigkeitsgründen enthalten
  • apihighlimits: Dürfte für manchen aus der technik-Fraktion interessant sein, für Ottonormalbenutzer eher weniger, für die Masse ist es aufgrund der Serverbelastung nicht geeignet, da erscheint mir diese Gruppe sinnvoll
  • noratelimit: Die Limits stören bisweilen, der verursachbare Schaden hält sich durch die Eingrenzung beschränkt, warum also nicht
  • abusefilter-log-private, abusefilter-view-private: Private Missbrauchsfilter, einer der wenigen Dinge, auf die Admins exklusiven Zugriff haben und die sich nicht mit WP:BIO etc. rechtfertigen lassen. Das Risiko, es für Sichter freizugeben wäre zu groß (Trolle hätten schnell Zugriff), aber hier sollte es vertretbar sein
  • massmessage: Stammtische, Redaktionstreffen, was auch immer – warum vom Admin abhängig machen? Das Risiko ist gering
  • mf-uploadbutton: keine Ahnung, stand in der Liste, jedoch ist die Möglichkeit, Dateien mobil hochzuladen zumindest für IPs meines Wissens gesperrt – wenn wir davon eh befreit sind, umso besser
  • deletedhistory: Wird immer dann zum Problem, sobald Persönlichkeitsrechte betroffen sein können – da müsste wohl tatsächlich massiv geoversighted werden
  • editprotected: Schwierig, da es nur vollgeschützte Seiten betrifft, welche Seiten dürfte man bearbeiten, welche nicht?
--BHC (Disk.) 20:19, 9. Feb. 2015 (CET)
@BeverlyHillsCop: Naja, solange dauert das nun auch nicht, wenn man sich anstrengt. Ich habe zum Beispiel bisher 2600, obwohl ich erst 4 Monate dabei bin. Zeitbegrenzungen habe ich dabei insbesondere bei den Sichterrechten immer gehasst. Ich weiß auch nicht, on man allzuviele ANR-Edits verlangen sollte. Schließlich kann man ja auch im WP-NR und im P-NR viel gutes tun. Zu deletedhistory: Denek an den Unterschied zwischen deletedhistory und deletedtext. Deletedhistory ist nur die Versionsgeschichte, nicht der Artikel. Es ist aber wegen URVs (in 255 Byte, aber egal) problematisch. Zu überlegen wäre es deshalb, da sowieso nur geschätzt 1000 Autoren auf diese Gruppe zugreifen könnten, und nicht alle Sichter. Zu editprotected: Ist ahlt so ne Sache. War ja auch nur eine Idee. Ach ja: Es hat zwar nichts damit zu tun, aber nachdem das MB zum Abschnitt 1 durch ist, will ich eines starten, was eine zusätzliche Seitenschutzstufe editor=Aktiver Sichter zum Thema hat. Nützlich gegen Honeypots und Vorratssocken. Diesem MB ist der Erfolg sicher. Die zugehörige Disk findest du ein bisschen weiter unten auf WP:PRD. --MGChecker (Disk. | Beitr. | Bewert.) 20:44, 9. Feb. 2015 (CET)
Klar, möglich ist vieles – die 10.000 Bearbeitungen bekommt man problemlos innerhalb eines Monats zusammen. Doch das ist dann immer noch verdammt auffällig. Absolute Sicherheit gibt es nicht, sicher, mir geht es darum, diese Gefahr zu minimieren und dabei gilt: Je mehr Bearbeitungen, umso umständlicher ist es. Ein positiver Nebeneffekt ist es, dass jeder Troll, der das System brechen möchte, vorher tausende sinnvolle Bearbeitungen durchführen muss. ;-) --BHC (Disk.) 22:27, 9. Feb. 2015 (CET)
Eine Benutzergruppe „Verdienter Benutzer“ oder so ähnlich finde ich nicht schlecht, wichtig ist, dass gefährliche Rechte, insbesondere Seiten schützen, Benutzer sperren sowie Seiten löschen nicht (!) dabei ist.
Zu den Bedingungen: Ich denke, dass 5000 Bearbeitungen, ein Jahr dabei (Nachfolgekonto erlaubt) und die SB für das SG sinnvoll sind. Wie genau soll eigentlich die Rechtevergabe ablaufen?
Hoffentlich kommt Flow nie! --Morten Haan 🌍 Wikipedia ist für Leser da 21:32, 9. Feb. 2015 (CET)
Ich würde die Rechtevergabe den BÜs überlassen, geben und entziehen, auf Antrag. Der Büro prüft dann kurz, ob es kein Vergehen in der letzten Zeit gab, denn sonst könnte auch ein öfter Unsinnmachender Benutzer dcas Recht erreichen. Bei Missbrauch => WP:VM. Die Büros haben ja seit Wikidata eh weniger zutun, da weniger Botflags zu vergeben sind. Ich denke, die könnten die Belastung aushalten. Bei inaktivität könnte man einen Bot konstruieren, der das einem BÜ meldet, der dann das Recht entzieht. Was denkt ihr dazu? LG, Luke081515 21:40, 9. Feb. 2015 (CET)
@Morten Haan: Ganz meiner Meinung. Löschen, schützen, sperren – das sind administrative Aufgaben, für welche eine Wahl genau der richtige Weg ist. Das Ziel darf ja nicht sein, die Admins überflüssig zu machen, indem man ihnen die Aufgaben nimmt, sondern altgedienten Nutzern mehr Rechte zuzusprechen, welche ihnen helfen könnten.
@Luke081515: Ich hatte tatsächlich an eine automatische Vergabe gedacht (wie beim aktiven Sichterrecht), eine manuelle Vergabe wäre natürlich auch möglich. Als Mittelweg wären vielleicht gewisse Ausschlusskriterien hilfreich (beim Sichterrecht gilt, dass höchstens 3 % der Bearbeitungen revertiert geworden sein dürfen), wo dann manuell angefragt werden muss.
Ein Problem welches ich sehe, ist die Frage der Einführung. Nicht die technische Implementierung, sondern der politische Aspekt. An einem Meinungsbild dürfte nichts vorbeiführen. Doch wie sollte das aufgebaut sein? Ein Komplettpaket, dem man zustimmen kann oder ein gigantisches Meinungsbild, zum selbst zusammenstellen. Ersteres dürfte zu vielen Kontra-Stimmen führen, weil jemanden ein einzelnes Recht missfällt; letzteres dürfte Kontra-Stimmen aufgrund der Komplexität produzieren. Tatsächlich würde ich letzteres präferieren, ein Meinungsbild, in dem über alles abgestimmt werden darf: Allgemeine Einführung, Rechtevergabe und auch, welche Rechte es nun gibt. Ich baue mal unter Benutzer:BeverlyHillsCop/Test ein Extrembeispiel auf, zur Verdeutlichung. --BHC (Disk.) 22:27, 9. Feb. 2015 (CET)
Ich habe mal ein Grundgerüst für den Abstimmungsteil gebastelt – das ginge so auf keinen Fall, das wäre viel zu groß. Eine mögliche Alternative wäre eine Ausweitung auf Unterseiten mit einem Abstimmsystem wie bei der Steward-Wahl. --BHC (Disk.) 22:47, 9. Feb. 2015 (CET)

Ich habe ja schon öfter offensiv dagegen argumentiert, dass man auch als User mit 1000 Jahren Mitarbeit und 1 Mio Edits keine substanziell andere Rolle erhält als ein Neuling mit wenigen Dutzend Bearbeitungen. Nicht jeder dieser "erfahrenen Benutzer" wird eine Admin-Rolle haben wollen/brauchen. Also generell finde ich es eine sehr gute Idee. Einige der Rechte wären im Alltagsleben hilfreich. Andererseite vermisse ich in der Diskussion Strategien, was man mit langjährigen Nutzern tun wird, die in einzelnen Fragen bewußt und aktiv gegen die Regeln verstoßen, und die erweiterten Rechte wohl gnadenlos ausnutzen würden. Akutes Beispiel wäre die */† Debatte, in der einige wenige User in religiösen Extrempositionen aktiv sind, die aber als User auch og. Kriterien erfüllen dürften. D.h es müssen gleichzeitig klare Regeln mit der Abstimmung festgelegt werden, wie die zusätzlichen Rechte auch rasch wieder entzogen werden können (+ zusätzliche Sanktion damit es weh tut z.B. 1 Jahr Bewährung bis zu erneuter Freischaltung der Zusatzrechte), wenn sie missbräuchlich verwendet werden. - andy_king50 (Diskussion) 23:00, 9. Feb. 2015 (CET)

Eine rein automatische Vergabe halte ich für zu heikel, denn eine gewisse Missbrauchsgefahr wird es schon geben. Besser wäre eine manuelle Vergabe durch die Bürokraten mit einer klaren Richtschnur, von der aber im Einzelfall abgewichen werden kann. Wichtig ist, dass wir auch ein Verfahren für den Entzug der Rechte miteinführen. Wie gehen wir eigentlich mit ehemaligen Admins um?
Zum MB: Als Kompromiss könnten wir mehrere Pakete mit Rechten machen und dann über die einzelnen Pakete abstimmen lassen. --Morten Haan 🌍 Wikipedia ist für Leser da 23:25, 9. Feb. 2015 (CET)
Wichtiger wären zum Vergleich wohl die Richtlinien zum Entzug des Sichterrechts – ehemalige Admins sind ja einfach ehemalige Admins. Oder meintest du, ob die ebenfalls aufgenommen werden? Ich würde sagen, die werden ebenso aufgenommen, sofern sie die Kriterien erfüllen; Admin-Karteileichen, die eh nicht aktiv sind und die Vorgaben nicht erfüllen, brauchen auch diese Rechte wohl nicht (angenommen Aktivität wird über Stimmberechtigung gemessen).
Bei den Paketen stellt sich dann die Frage der Zuteilung: Was ist wichtig genug, um einzeln behandelt zu werden, was nicht. Bei meiner Testseite hatte ich bereits acht Vorschläge zu dreien summiert – es waren weiterhin 14. Ich muss sagen, mir gefällt für diesen Punkt das Steward-System besser: Eine Abstimmungsbox für die Rechte auf die Hauptseite des MB und die einzelnen Abstimmungen dann auf Unterseiten, dann ist nichts zu überfrachtet. Wie siehst du das System? --BHC (Disk.) 23:54, 9. Feb. 2015 (CET)
Die Idee mit den Unterseiten ist zwar nicht schlecht, allerdings befürchte ich auch dabei eine mehrheitliche Ablehnung. Bei den Paketen ist natürlich die Zuteilung ganz wichtig. --Morten Haan 🌍 Wikipedia ist für Leser da 00:26, 10. Feb. 2015 (CET)
Mit welcher Begründung? Unübersichtlichkeit? Verstecken der Abstimmung? Oder allgemein „Manipulation“? Aber ja, risikoreich wäre es, vielleicht ginge es noch mit zwei Seiten (einer Hauptseite und der Abstimmseite zu den Rechten), dass wäre dann nicht so überladen wie bei sechs, sieben Abstimmungsblöcken. --BHC (Disk.) 08:57, 10. Feb. 2015 (CET)
Ich liebe es, wenn die Diskussion so blüht! Jetzt mein Senf:
  • bei flow würde ich erstmal darauf warten, dass es eingeführt wird. Und dann muss man sich um die Rechtevergabe kümmern.
  • Zur Vergabe: Automatisch ist bei dieser Berechtigungsflut ein abolutes No-Go. Wie gesagt, bestimmte Richtlinien, und dann eine Einspruchsliste für stimmberechtigte Benutzer halte ich am geeignetesten. Eine Wahl halte ich hier eindeutig für überzogen.
  • Zum Entzug: Selbstverständlich muss der möglich sein, wie, weiß ich noch nicht. Vielleicht per Mini-MB, vielleicht akut durch Büros mit anschl. Mini-MB.
  • Vor dem MB muss schon mal voselektiert wrden, welche Rechte wir nehmen, und sich auch auf ein oder zwei Vergabekonzepte geeinigt werden. Eine votherige Umfrage halte ich bei diesem Thema angemessen. Ich denke aber, dass zumindets in Teilen der Abstimmung 66,7% als Hürde angemessen ist. Und zwar bei der Einführung an sich, die einzelnen Rechte können dann mit 55% verabschiedet werden.
  • browsearchive und deletedhistory könnte man wohl zusammenfassen.
MBs, die als unübersichtlich und/oder komplex gelten, haben eine hohe Ablehnungsgefahr. Mehrere Pakete halte ich daher für sinnvoll. Heute Abend werde ich mal ein paar Beispielpakete basteln. Die Rechte bezüglich Flow würde ich vorerst weglassen, dafür würde ich das Recht upload_by_url dazu nehmen. --Morten Haan 🌍 Wikipedia ist für Leser da 17:44, 10. Feb. 2015 (CET)
Ich find upload_by_url ja auch cool. Aber es wurde aus irgendeinem Grund (ich glaube es hat nicht funktioniert oder so) allen gestrichen, auch den Admins. Auf anderen Wikia funktioniert es komischerweise. Ich weiß nicht mehr wo ich das gefunden habe, aber es ist auf jeden Fall so, sonst wäre es schon im laufenden MB enthalten. Ach ja: Was haltet ihr von deletedtext? edituserjs/css sollte was für Admins bleiben. --MGChecker (Disk. | Beitr. | Bewert.) 18:01, 10. Feb. 2015 (CET)
Evtl. in Frage käme noch titleblacklistlog. --MGChecker (Disk. | Beitr. | Bewert.) 20:19, 10. Feb. 2015 (CET)

Hallo, etwas verspätet schlage ich hier mal die versprochenen Beispielpakete vor. Rechte, die ich als zu heikel ansehe, habe ich ausgelassen.

  • Paket Blacklist: spamblacklistlog, titleblacklistlog
  • Paket Missbrauchsfilter: abusefilter-log-private, abusefilter-view-private
  • Paket Seiten verschieben: move-subpages, suppressredirect
  • Paket Dateien: movefile, reupload-shared
  • Paket Limits: apihighlimits, noratelimits
  • Über die verbleibenden Rechte wird jeweils einzeln abgestimmt:
    • browsearchive
    • massmessage
    • unwatchedpages

--Morten Haan 🌍 Wikipedia ist für Leser da 00:03, 12. Feb. 2015 (CET)

Gut, unwatchedpages können wir vllt rausnehmen, jenachdem wie das aktuelle MB ausgeht. Aber amsonsten finde ich diese Pakete einen guten Vorschlag. In dem MB müssten wir natürlich noch die Rechte genauer beschreiben, aber ansonsten finde ich den Vorschlag sehr gut. LG, Luke081515 09:22, 12. Feb. 2015 (CET)
Könnte man auf jeden Fall so machen. Noch eine Frage zu deletedhistory: Lässt das auch Versionsgelöschtes sichtbar werden? Ich glaub nüämlich schon. Dann würde ich das ebenfalls ausschließen. Das mit unwatchedpages wird aber wohl leider doch eher nichts. --MGChecker (Disk. | Beitr. | Bewert.) 14:26, 12. Feb. 2015 (CET)
Zumindest bei Versionslöschungen nach dem alten Verfahren (Seite löschen und ohne bestimmte Versionen wiederherstellen) ist das auf jeden Fall möglich, bei dem neuen Verfahren bin ich mir nicht ganz sicher. --Morten Haan 🌍 Wikipedia ist für Leser da 17:30, 12. Feb. 2015 (CET)

@Informationswiedergutmachung, Codc, -jkb-: Da ihr für sowas Interesse gezeigt habt (auf WP:AN), mal ein Ping. --BHC (Disk.) 12:27, 15. Feb. 2015 (CET)

Meinungen zu den einzelnen Rechten

Zur Übersicht gerne in Stufen bewerten : +2, +1, 0, -1, -2.

  • deletedhistory + browsearchive
    • +2: Find ich auf jeden Fall angebracht. --MGChecker (Disk. | Beitr. | Bewert.) 20:19, 10. Feb. 2015 (CET)
    • browsearchive kann eventuell nützlich sein (+1), deletedhistory halte ich für zu heikel (−2). --Morten Haan 🌍 Wikipedia ist für Leser da 21:09, 10. Feb. 2015 (CET)
      • @Morten Haan: Was bringt browsearchive ohne deletedhiostory; und was ist das Problem bei deletedhistory genau? --MGChecker (Disk. | Beitr. | Bewert.) 21:17, 10. Feb. 2015 (CET)
        • Genauso wie im Quelltext können sich in der Zusammenfassungszeile gelöschter Versionen URV, persönliche Angriffe sowie Verstöße gegen WP:BIO befinden, daher sollten deletedhistory und deletedtext Admins vorbehalten bleiben. Mit browsearchive kann man nach gelöschten Seiten suchen, daher ist das Recht zumindest nicht heikel. Allzu sinnvoll ohne deletedhistory ist es aber wohl nicht. --Morten Haan 🌍 Wikipedia ist für Leser da 21:25, 10. Feb. 2015 (CET)
    • +2 sinnvoll bei VMs mit gelöschten Beiträgen etc. Luke081515 21:37, 10. Feb. 2015 (CET)
    • Bei browsearchive sehe ich keinen Schaden, könnte zur Recherche taugen (+1), bei deletedhistory sehe ich zu große Problemfaktoren (URV, BIO) daher nein (-2). --BHC (Disk.) 22:43, 10. Feb. 2015 (CET)
  • abusefilter-log-private + abusefilter-view-private
    • 0: Es hat ja schon einen Grund, wenn abusefilter als privat markiert werden. --MGChecker (Disk. | Beitr. | Bewert.) 20:19, 10. Feb. 2015 (CET)
    • +1 Der Grund dürfte in der Regel sein, dass Vandalen den Filter nicht umgehen können. --Morten Haan 🌍 Wikipedia ist für Leser da 21:09, 10. Feb. 2015 (CET)
    • +2 kein Missbrauch zu erwarten Luke081515 21:37, 10. Feb. 2015 (CET)
    • +2 Wenn Missbrauchsfilter auf privat gestellt sind, dann weil dort z. B. steht, wie ein Troll gefunden wird. Bei Sichtern wäre mir das zu heikel, hier keinesfalls. --BHC (Disk.) 22:43, 10. Feb. 2015 (CET)
  • editusercss + edituserjs
    • -2: Sowas sollte den Admins vorbehalten bleiben. --MGChecker (Disk. | Beitr. | Bewert.) 20:19, 10. Feb. 2015 (CET)
    • −2 Selbst Admins haben auf CSS- und JS-Seiten anderer Benutzer normalerweise nichts zu edieren. --Morten Haan 🌍 Wikipedia ist für Leser da 21:09, 10. Feb. 2015 (CET)
    • -2 siehe vorherigen
    • 0 Ich dachte da an Skript-Fixe vom Ersteller, aber muss nicht sein. --BHC (Disk.) 22:43, 10. Feb. 2015 (CET)
  • apihighllimits + noratelimit
    • +1: Ist zwar gut, aber ist schon eine sinnvolle Schutzvorrichtung. --MGChecker (Disk. | Beitr. | Bewert.) 20:19, 10. Feb. 2015 (CET)
    • +1 --Morten Haan 🌍 Wikipedia ist für Leser da 21:09, 10. Feb. 2015 (CET)
    • 0 sinnvolle Einschränkung Luke081515 21:37, 10. Feb. 2015 (CET)
    • +1 Bei dieser Nutzergruppe ist (ebenso wie bei Admins) kein solcher Missbrauch zu erwarten, als dass es untersagt werden müsste. --BHC (Disk.) 22:43, 10. Feb. 2015 (CET)
  • editprotected
    • -1: Ich weiß nicht. --MGChecker (Disk. | Beitr. | Bewert.) 20:19, 10. Feb. 2015 (CET)
    • −2 Ich sehe keinen Grund für die Vergabe, dafür aber eine gewisse Missbrauchsgefahr bei Edit-Wars. --Morten Haan 🌍 Wikipedia ist für Leser da 21:09, 10. Feb. 2015 (CET)
    • -2 Warum denn? Vollgeschützte seiten dürfen nicht bearbeitet werden... Luke081515 21:37, 10. Feb. 2015 (CET)
    • -2 Vollgeschützte Seiten dürfen im Regelfall auch von Admins nicht bearbeitet werden, daher sehe ich keinen Grund. --BHC (Disk.) 22:43, 10. Feb. 2015 (CET)
  • proxyunbannable
    • 0: Ich weiß nicht, ob das benötigt wird, und kenne mich mit dem Recht auch nicht aus. --MGChecker (Disk. | Beitr. | Bewert.) 08:13, 18. Feb. 2015 (CET)
  • ipblock-exempt
    • +1: Meinetwegen gerne aber wegen IP-Sperren-Ausgenommenen nicht erforderlich. --MGChecker (Disk. | Beitr. | Bewert.) 08:13, 18. Feb. 2015 (CET)
  • weitere nach Absprache gern ergänzen (vorest kein flow + upload_by_url)

@BeverlyhillsCop, Luke081515: Euer Senf würde mich interessieren. --MGChecker (Disk. | Beitr. | Bewert.) 21:18, 10. Feb. 2015 (CET)

@BeverlyHillsCop: --MGChecker (Disk. | Beitr. | Bewert.) 21:22, 10. Feb. 2015 (CET)

abusefilter-log-private + abusefilter-view-private: Datenschutz

@XenonX3: Du hast bei der Umfrage deine Ablehnung damit begründet, dass durch eine Freigabe „datenschutzrechtlich relevante Inhalte lesbar“ wären. Könntest du das bitte etwas weiter ausführen? Welche Daten wären das denn und gilt dies nur beim Logbuch, nur bei der Filterseite oder bei beiden? Ich war bislang davon ausgegangen, dass die Filter deshalb privat sind, weil sonst die Vandalen diese einfacher umgehen könnten. Unter „datenschutzrechtlich relevanten Inhalten“ kann ich mir in diesem Zusammenhang nur wenig vorstellen, IP-Ranges dürften es ja eher weniger sein, da die auf diverseren Seiten gesammelt werden. Wenn es jedoch heikles Material gibt, wäre eine Freigabe natürlich kritisch. Also: Worum geht es genau, wenn man fragen darf. Gruß, BHC (Disk.) 23:15, 24. Feb. 2015 (CET)

Ich möchte nicht zu sehr ins Detail gehen. In manchen Filtern landen regelmäßig persönliche Daten, da sie vor allem Edits von Neulingen filtern, die unbedarfterweise ihre Daten ins Netz stellen. Stehen diese Filter auf Privat, sind die Trefferlisten inkl. der Daten nur für Admins einsehbar. Diese Filter werden täglich kontrolliert und kritische Treffer geoversightet. Grüße, XenonX3 – (☎) 23:45, 24. Feb. 2015 (CET)
@XenonX3: Also geht es nur um das Logbuch, in dem derartige Daten vorkommen, die Filter-Seite selbst könnte aber freigegeben werden (mir geht es dabei um Transparenz: Was wird geloggt, nicht wer), oder habe ich was falsch verstanden? Wenn abusefilter-view-private für eine größere Gruppe öffentlich ist, abusefilter-log-private aber nicht, dann sollten die Ergebnisse ja unangezeigt bleiben, nicht aber die allgemeinen Einstellungen, oder? --BHC (Disk.) 00:44, 25. Feb. 2015 (CET)
In manchen Fällen geht aus der Filtereinstellung hervor, auf welchen Seiten vermehrt persönliche Daten landen, wodurch dann jemand gezielt diese Seiten überwachen könnte, um die Daten abzufischen, bevor sie entfernt werden können. Daher würde ich beide Rechte ungerne in falschen Händen sehen. XenonX3 – (☎) 00:49, 25. Feb. 2015 (CET)
Verstehe, dass ist natürlich problematisch. Nachdem ich das jetzt weiß (und genau da steckt der Nutzen der Umfrage) bin ich auch der Ansicht, dass abusefilter-log-private aus dem Rennen ist, was abusefilter-view-private angeht, verstehe ich deine Bedenken, und klar ist, dass darüber noch einmal nachgedacht werden muss (glücklicherweise entscheide ich ja nicht alleine über ein mögliches Meinungsbild). Mal sehen, was andere dazu sagen. Wenn tendiere ich aktuell zu mindestens einer 2/3-Mehrheit (verschiedene Rechte=verschiedene Quoren), falls überhaupt. Meine Stimme würde ich wohl davon abhängig machen, wie hoch die Zulassungshürden sind (10.000 Bearbeitungen machen es wahrscheinlicher als 5.000). Auf jeden Fall möchte ich dir für die Antworten danken, sie waren auf jeden Fall sehr hilfreich. --BHC (Disk.) 00:57, 25. Feb. 2015 (CET)

Diskussionen zu weiteren Rechten

Ich will nur noch mal mergehistory und import ins Gespräch bringen. Das sind einmal die unkompliierte Variante, Versionsgechichten zu vereinigen, bei der sie mit einem Mausklick wieder getrennt werden können und dann noch das Importieren von Seiten. --MGChecker (Disk. | Beitr. | Bewert.) 21:18, 17. Feb. 2015 (CET)

Habe keine Bedenken, diese Rechte können durchaus nützlich sein, das wäre dann ein weiteres Paket, welches ich „Paket Importieren“ taufe. --Morten Haan 🐠 Wikipedia ist für Leser da 22:54, 17. Feb. 2015 (CET)
Das Paket an sich gerne, aber Paket Versionsgeschichten oder Paket Versionen trifft den Sinn besser. --MGChecker (Disk. | Beitr. | Bewert.) 08:04, 18. Feb. 2015 (CET)
Gut, dann nenne ich es „Paket Versionen“. --Morten Haan 🐠 Wikipedia ist für Leser da 15:56, 18. Feb. 2015 (CET)

Dann will ich mal das „Paket Ausnahmen von Sperren“ ins Gespräch bringen. Darin finden sich die Rechte ipblock-exempt und proxyunbannable. Diese Rechte könnten für Benutzer hilfreich sein, die hin und wieder von IP- oder Proxy-Sperren betroffen sind. --Morten Haan 🐠 Wikipedia ist für Leser da 22:54, 17. Feb. 2015 (CET)

Ich weiß nicht, ob man das wirklich braucht, schließlich gibt es schon IP-Sperren-Ausgenommene, zu proxyunbannale kenn ich mich jeodch nicht aus, das haben nur Administratoren. --MGChecker (Disk. | Beitr. | Bewert.) 08:04, 18. Feb. 2015 (CET)
Ob man das braucht, ist wohl von Benutzer zu Benutzer verschiedenen. In jedem Fall schadet es nicht. --Morten Haan 🐠 Wikipedia ist für Leser da 15:56, 18. Feb. 2015 (CET)

Weiterführende Diskussionen zu einzelnen Rechten

Diskussion zu Vergabe und Entzug

Ggf. wäre ein reines Antragsverfahren, und zwar mit Bezug auf konkrete einzelne Rechte aus einem Katalog möglich? Dh. "ich brauche die Berechtigung "XYZ", weil ich (regelmäßig, belegt) folgendes mache: ..." --> Wenn keine objektiven Gründe dagegensprechen (bisheriger Missbrauch ähnicher Rechte...) soll dem Antrag in der Regel stattgegeben werden. Natürlich müsste man die Zugangsvoraussetzungen, um so einen Antrag stellen zu können genau (Editzahlen, max. x Sperren im letzen Jahr) definieren, um Socken incl. Vorratssocken wirksam aussen vor zuhalten. Ein Entzug der Rechte sollte mit schlüssiger Begründung möglich sein, vor allem bei deren Missbrauch. Da sollte eine Lösung her, die "Diskussionshanseln" von vorn herein wenig Möglichkeiten bietet, aber einen einmaligen, begründeten Widerspruch des Betroffenen zulässt. -- andy_king50 (Diskussion) 21:28, 10. Feb. 2015 (CET)

Das Problem daran ist, dass man nicht Rechte vergeben kann, sondern nur Gruppen - und für jedes Recht eine eigene Gruppe ist zu unübersichtlich und darum nicht vertretbar. --MGChecker (Disk. | Beitr. | Bewert.) 21:32, 10. Feb. 2015 (CET)
Ich denke, Entzug könnte ein BÜ bei Missbrauch machen, sollte der BÜ das aus Willkür etc. machen (unwahrscheinlich) gäbe es noch das AP. Aber bitte keine Automatische Vergabe, das macht es für Socken leichter.... Gruß, Luke081515 21:39, 10. Feb. 2015 (CET)
na ja da schließt sich der Kreis bei der Frage "wenn wir zu wenig User haben, die solche Aufgaben wahrnehmen, haben wird dann zu wenig Admins? Haben wir zu wenig Admins, da an Neuaufnahmen als Admin überhöhte Maßstäbe angelegt werden, die eine Reihe amtierender Admins so auch nicht erfüllen ? (so ähnlich wie im Tierheim, die kriegen die Viehcher auch so schwer los weil sie überhöhte Kontrollansprüche stellen). Ich denke ab 10,000 Edits im BNR sollte man schon die "Wikipedia Gold card" mit Adminrechten (gern mit Rückrufrecht bei Missbrauch) kriegen ;-) - andy_king50 (Diskussion) 21:48, 10. Feb. 2015 (CET)

Siehe auch

Abgerufen von „https://de.wikiup.org/index.php?title=Wikiup:Projektdiskussion/Neue_Benutzergruppe_zwischen_Administrator_und_Sichter&oldid=176657818“