Wikipedia Diskussion:Umfragen/Reform der Adminrechte
Letzter Kommentar: vor 3 Jahren von Indoor-Fanatiker in Abschnitt Überschrift "Sollte man mehr Nutzer zu Admins wählen?"
Hanebüchener Unsinn
BearbeitenDiese Diskussion bezog sich auf eine frühere Version mit ganz anderem Inhalt. --Indoor-Fanatiker (Diskussion) 01:35, 8. Jun. 2021 (CEST)
Und zwar vom ersten bis zum letzten Zeichen, wirklich.
Vorschlag 1:
- „im Jahr 2012 hatten wir noch 271 Admins, heute sind es nur noch 187“: Wir haben keine 187 Admins, wir haben 178 Admins und acht Schiedsrichter. Admin ≠ Schiedsrichter = Benutzer mit Adminrechten ohne diese auszuüben.
- „Einsichtnahme in gelöschte Artikel“: Ohja, knapp 2000 Konten mit Einblick in potenziell Persönlichkeitsrechte verletzende Versionen, die noch nicht geoversighted wurden.
- „Bearbeiten vollgeschützter Seiten“: Dürfen auch aktive Admins nicht, außer es handelt sich um eine administrative Handlung oder einen abgesprochenen Edit.
- „evtl. sollten passive Admins nicht gesperrt werden können bzw. sich selbst wieder entsperren können“: Aktive Admins können wie jeder andere Benutzer gesperrt werden und können sich schon technisch nicht selbst entsperren.
- „sinnvolle Anzahl errechnet sich nach dem geometrischen Mittel aus Anzahl Admins und Anzahl aktiver Sichter, das wären im Moment ungefähr 1940 passive Admins“: Nein, nicht sinnvoll. Knapp 2000 Konten, die nicht gesperrt werden oder sich selbst entsperren können – Wikifreinacht 24/7, klingt lustig.
Übrigens – welche 1940 Benutzer wären das dann, denen die Ehre zuteil würde? Müssten die weiterhin gewählt werden oder entscheidet eine Zufallsauswahl?
Vorschlag 2:
- „Benutzer, die schon länger am Projekt mitarbeiten (z.B. aktive Sichter) können die „gelöschten“ Artikel weiterhin lesen“: Siehe Vorschlag 1, Punkt 2.
- „Längere (auch dauerhafte) Sperren können nur von Checkuser-Berechtigten oder Schiedsrichtern verhängt werden“: Weder Checkuser noch Schiedsrichter haben ein Mandat, eigenmächtig Sperren zu verhängen.
Vorschlag 3:
- „könnte man den Zugang zur Gruppe der Vandalismusbekämpfer einfacher gestalten (kein aufwändiges Wahlverfahren)“: Wer Benutzer sperren will, muss kandidieren und mit großer Mehrheit gewählt werden, fertig.
- „Niemand kann gleichzeitig in beiden Gruppen Mitglied sein (Unvereinbarkeit)“: Bereits jetzt handhaben es einige Admins so, entweder LD/LP oder VM/SP abzuarbeiten und nicht beides (ich zum Beispiel).
Bitte beschäftige dich erst mit den Abläufen und siehe ein, dass deine persönliche Meinung, untermauert mit einigen wenigen Diskussionsbeiträgen anderer, nicht im 24-Stunden-Takt ein Anlass ist, die Leute mit solchen abstrusen und unpraktikablen Vorschlägen zu beschäftigen.
Danke. – Siphonarius (Diskussion) 14:28, 30. Mai 2021 (CEST)
Hallo, auch wenn du hier harsche Kritik übst, bin ich dir trotzdem für diesen Beitrag dankbar, denn nur so kann ich die Umfrage verbessern. Vielleicht ist es generell nicht sinnvoll, meine Vorschläge auf der Vorderseite als Aussagesätze zu formulieren (das erweckt Absolutheitsanspruch). Ich denke darüber nach, sie auch grammatikalisch als Fragesätze aufzuschreiben, um so bessere Antworten zu bekommen.
zu 1.1. Der Baustein {{ADMINANZAHL}} spuckt das so aus.
zu 1.3. Mir geht es dabei um die technische Möglichkeit zum Editieren, nicht ob das auch moralisch vertretbar oder erlaubt ist.
Ich bin hier bei diesem Projekt schon so lange dabei, dass ich die Abläufe ziemlich gut kenne. Die Grafik auf WP:KON entspringt beispielsweise meiner Feder.
zu 1.4. Außerdem hatte ich die Ehre, Benutzer:Dickbauch noch in seiner aktiven Zeit kennen zu lernen, und der hat sich damals mehrfach selbst „entlöscht“ (ältere, inkorrekte Bezeichnung für „entsperrt“). Kann natürlich sein, dass ich nicht mitbekommen habe, dass dieses Recht inzwischen aufgehoben wurde.
Nachtrag: für globale Admins wurde das Recht unblockself 2018 entfernt. Also vermutlich im gleichen Zeitraum auch für lokale Admins.
zu 1. Wie dieses Recht vergeben wird, ist in der Umfrage herauszufinden (dafür ist sie schließlich da). Vorschläge meinerseits wären entweder Benutzer mit sehr vielen Edits (z.B. mehr als 10.000 im ANR) oder ein vereinfachtes Wahlverfahren, das ähnlich funktionieren könnte wie das Wikipedia:Vertrauensnetz, bzw. auf diesem aufbauen könnte. Dass derart langgediente Benutzer auf einmal „frei drehen“ (siehe 1.5.), ist nicht zu erwarten.
zu 2. Dass langjährige und infinite Sperren immer wieder Gegenstand von wiki-interner Kritik werden, ist evident. Nicht umsonst gab es schon mehrere Meinungsbilder, die das ändern wollten, diese habe ich auch umseitig verlinkt. Häufig liest man darin immer wieder Sätze wie „langjährige Sperren nur durch die Community per BSV“ oder „dauerhafte Sperren nur durch Schiedsgerichtsurteil“.
Man könnte Checkuser per MB legitimieren, bspw. BSV-Entscheidungen umzusetzen.
zu 3.1. Denkbar ist auch hier ein vereinfachtes Wahlverfahren, z.B. wo einfache Mehrheit ausreicht.
zu 3.2. Mag sein, dass einige Admins einen Teil ihrer Rechte freiwillig nicht ausüben, aber auch hier ist die technische Möglichkeit gemeint. --Indoor-Fanatiker (Diskussion) 16:28, 30. Mai 2021 (CEST)
Ausführliche Auflistung der Nutzergruppen und ihrer Rechte
Bearbeiten| alle | Benutzer | IP-Sperren- Ausge- nommene |
Automatisch bestätigte Benutzer |
Passive Sichter |
Limit- Ausge- nommene |
Benutzer- kontener- steller |
Transwi- ki-Im- porteure |
Impor- teure |
Prüfer | Sichter | Bots | Oberflä- chenadmi- nistratoren |
Adminis- tratoren |
Büro- kraten |
Checkuser- Berechtigte |
Oversighter | Stewards | |
| Anzahl Benutzer | ∞ | 4.472.731 | 218 | ? | 46.004 | 23 | 0 | 0 | 13 | 0 | 22.237 | 95 | 18 | 175 | 4 | 5 | 0 | 0 (3) 1 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Anzahl Rechte | 16 | 29 | 31 | 41 | 42 | 43 | 43 | 45 | 46 | 46 | 46 | 49 | 51 | 90 | 91 | 94 | 96 | 112 |
| abusefilter-hidden-log | 1 | 1 | ||||||||||||||||
| abusefilter-hide-log | 1 | 1 | ||||||||||||||||
| abusefilter-log | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| abusefilter-log-detail | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| abusefilter-log-private | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| abusefilter-modify | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| abusefilter-modify-restricted | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| abusefilter-privatedetails | 1 | 1 | ||||||||||||||||
| abusefilter-privatedetails-log | 1 | 1 | ||||||||||||||||
| abusefilter-view | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| abusefilter-view-private | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| apihighlimits | 1 | 1 | 1 | 1 | 1 | 1 | ||||||||||||
| applychangetags | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| autoconfirmed | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| autopatrol | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||||||||||
| autoreview | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | ||||
| bigdelete | 1 | |||||||||||||||||
| block | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| blockemail | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| bot | 1 | 1 | ||||||||||||||||
| browsearchive | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| centralauth-createlocal | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| centralauth-merge | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| changetags | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| checkuser | 1 | 1 | ||||||||||||||||
| checkuser-log | 1 | 1 | ||||||||||||||||
| collectionsaveascommunitypage | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| collectionsaveasuserpage | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| createaccount | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| createpage | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| createtalk | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| delete | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| deletechangetags | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| deletedhistory | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| deletedtext | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| deletelogentry | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| deleterevision | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| edit | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| editcontentmodel | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| editeditorprotected | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||||||||||
| editinterface | 1 | 1 | 1 | 1 | 1 | 1 | ||||||||||||
| editmyoptions | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| editmyprivateinfo | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| editmyusercss | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| editmyuserjs | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| editmyuserjson | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| editmywatchlist | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| editprotected | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| editsemiprotected | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| editsitecss | 1 | 1 | ||||||||||||||||
| editsitejs | 1 | 1 | ||||||||||||||||
| editsitejson | 1 | 1 | 1 | 1 | 1 | 1 | ||||||||||||
| editusercss | 1 | 1 | ||||||||||||||||
| edituserjs | 1 | 1 | ||||||||||||||||
| edituserjson | 1 | 1 | 1 | 1 | 1 | 1 | ||||||||||||
| globalblock-whitelist | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| hideuser | 1 | 1 | ||||||||||||||||
| import | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||||||||||
| importupload | 1 | 1 | ||||||||||||||||
| ipblock-exempt | 1 | 1 | 1 | 1 | 1 | 1 | ||||||||||||
| managechangetags | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| markbotedits | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| massmessage | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| mergehistory | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| minoredit | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| move | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| move-categorypages | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| move-rootuserpages | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| move-subpages | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| movefile | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| movestable | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| mwoauthmanagemygrants | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| nominornewtalk | 1 | 1 | ||||||||||||||||
| noratelimit | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||||||
| nuke | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| oathauth-enable | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | ||||||||||
| override-antispoof | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| patrol | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| patrolmarks | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| protect | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| purge | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| read | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| reupload | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| reupload-own | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| reupload-shared | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| review | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||||||||||
| rollback | 1 | 1 | 1 | 1 | 1 | 1 | ||||||||||||
| sendemail | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| skipcaptcha | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| spamblacklistlog | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |
| stablesettings | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| suppressionlog | 1 | 1 | ||||||||||||||||
| suppressredirect | 1 | 1 | 1 | 1 | 1 | 1 | ||||||||||||
| suppressrevision | 1 | 1 | ||||||||||||||||
| tboverride | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| titleblacklistlog | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| torunblocked | 1 | 1 | ||||||||||||||||
| transcode-reset | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| transcode-status | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| undelete | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| unreviewedpages | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||||||||||
| unwatchedpages | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| upload | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | |||
| userrights | 1 | |||||||||||||||||
| userrights-editor 2 | 1 | 1 | 1 | 1 | 1 | |||||||||||||
| userrights-sysop 2 | 1 | 1 | ||||||||||||||||
| validate | 1 | 1 | ||||||||||||||||
| viewmyprivateinfo | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| viewmywatchlist | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| viewsuppressed | 1 | 1 | ||||||||||||||||
| vipsscaler-test | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
| writeapi | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 |
1
Die Nutzergruppe der Stewards existiert definitionsgemäß in keinem lokalen Wiki, sondern nur projektübergreifend auf Meta. Dort gibt es jedoch 3 Stewards, deren Heimwiki die deutschsprachige Wikipedia ist: Benutzer:DerHexer, Benutzer:Hoo man und Benutzer:Schniggendiller.
2
Diese beiden Rechte existieren in der MediaWiki-Software nicht wirklich. Ich habe sie nur so genannt, um den vollen
userrights-Zugriff der Stewards abzugrenzen von dem Recht der Admins, Benutzer zu Sichtern zu machen, und dem Recht der Bürokraten, Admins zu ernennen.(nicht signierter Beitrag von Indoor-Fanatiker (Diskussion | Beiträge) 04:17, 3. Jun. 2021 (CEST))
Gruppenrechte vom Kopf auf die Füße stellen
Bearbeiten| Löschen | |
|---|---|
| Momentan gibt es folgende Rechte, die mit der Löschung von Seiten zusammenhängen: | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Stattdessen sollte man die Seitenlöschung mit folgenden Rechten organisieren: | |
|
|
|
|
|
|
| |
| Seitenschutz | |
| Momentan gibt es folgende Rechte, die mit dem Seitenschutz zusammenhängen: | |
|
|
| |
| |
| |
| |
| Stattdessen sollte man den Seitenschutz mit folgenden Rechten organisieren: | |
|
|
| |
| |
| |
| Benutzersperre | |
| Momentan gibt es folgende Rechte, die mit der Sperrung von Benutzern zusammenhängen: | |
|
|
|
|
| Analog zum Seitenschutz sollte auch die Benutzersperrung wie folgt organisiert werden: | |
|
|
| |
| |
| |
| |
-- Indoor-Fanatiker (Diskussion) 08:06, 7. Jun. 2021 (CEST)
Zur Diskussion der obenstehenden Tabelle
Bearbeiten- Dazu wären umfangreiche Änderungen an der Software nötig. Einige der Vorschläge halte ich für nicht durchdacht und eher schädlich, andere sind rechtlich problematisch. Hast Du eine Begründung für die Änderungsvorschläge? -- Perrak (Disk) 13:16, 7. Jun. 2021 (CEST)
- Abgesehen davon, dass die Anpassung auf diese Rechte einem weitgehenden Neuschrieb von MediaWiki gleichkäme: Welche Rechtekonstellation fehlt dir denn, die sich mit den derzeitigen Rechten nicht abbilden lässt?--Cirdan ± 14:50, 7. Jun. 2021 (CEST)
Ja, es gibt sogar mehrere gute Gründe, warum man die Rechteverwaltung ändern sollte:
- Löschen: das aktuell bestehende
delete-Recht funktioniert nach dem Prinzip „alles oder nichts“. Wenn ein Admin seindelete-Recht ausübt, kann kein Nicht-Admin den Artikel mehr einsehen, egal ob IP oder Sichter. Mit den neuen Rechtenhide, hide-confirmed und hide-editorist eine feingranularere Abstufung der Unsichtbarkeit möglich. Inhalte, die keine Rechtsverletzungen darstellen, brauchen vielleicht nur mithidevor IPs versteckt werden oder mithide-confirmedvor IPs und Angemeldeten, die noch keine Sichter sind. - Seitenschutz: Wem verleiht man die Rechte? Ebenso ist auch eine feinere Abstufung dahingehend möglich, wer welches Recht in welchem Umfang ausüben darf. Insbesondere das bestehende
protect-Recht kann nur als „Komplettpaket“ vergeben werden. Es ist also nicht möglich, einem Benutzer dasprotect-Recht zu verleihen und ihm zu sagen: „bitte verhänge damit nur Halbsperren.“ Wenn er dasprotect-Recht einmal hat, kann er damit genauso gut Seiten dreiviertel- und vollschützen.
Mit dem reformiertenprotect-Recht hingegen kann man Seiten nur halbschützen. Dieses Recht kann, wie bereits in der Tabelle steht, gefahrlos auch an Sichter verliehen werden, damit Sichter die Admins im Kampf gegen IP-Vandalismus unterstützen können (wegen „Adminmangel“). Seiten, die mit dem neuenprotect-Recht geschützt werden, bleiben nämlich für auto-confirmed user (und höher Berechtigte) in jedem Fall bearbeitbar. - Benutzersperre: Ebenso sollte auch das
block-Recht differenzierter auf verschiedene Benutzergruppen verteilt werden. Einen ganzen IP-Adressbereich zu sperren, ist ein viel stärkerer Eingriff als eine einzelne IP-Adresse. Daher finde ich es etwas übertrieben, dass „normale“ Admins ganze IP-Adressbereiche sperren können. Dasblock-range-Recht würde ich nur noch an Checkuser-Berechtigte verleihen. - Obwohl in der Tabelle nicht direkt abgebildet, müsste man sich Gedanken machen, ob man eine Zeitdauerbegrenzung für bestimmte Benutzersperren einführt (z.B. bis max. einige Monate Sperrdauer). Dieses Thema wird umseitig weiter ausgeführt.
- Das neu vorgeschlagene System ist generell zukunftssicherer. Umseitig wird vorgeschlagen, eine neue Benutzergruppe namens „Hilfs-Admins“ einzuführen, die von ihren Möglichkeiten her irgendwo zwischen Sichtern und Admins stehen sollen. Doch welche Rechte sollen die „Hilfs-Admins“ bekommen? Ihnen ein ganzes Rechte-„Komplettpaket“ (z.B.
block) zu verleihen, wird als zu weitreichend angesehen. Es wäre jedoch tolerierbar, wenn sie nur eingeschränkte Rechte bekämen, z.B. nurhide-confirmed, siehe Punkt 1. - Damit auch „Hilfs-Admins“ keine rechtlich geschützten Daten einsehen können, lässt sich auch einfach das Recht
hide-helpereinführen, mit dem Seiten auch vor den Augen der „Hilfs-Admins“ verborgen werden können. Analog können auch die Rechteprotect-helperundblock-helperhinzugefügt werden. Kurz gesagt: die neue Software ist leichter erweiterbar. --Indoor-Fanatiker (Diskussion) 01:35, 8. Jun. 2021 (CEST)
- Okay, danke für Deine Antwort.
- Zu 1.: Eine feinere Unterteilung der Löschmöglichkeiten wäre möglich, ja. Das würde aber die Gefahr in sich bergen, dass vieles auf der falschen Stufe gelöscht würde und damit immer noch für Leute zugänglich wäre, die es nicht sehen sollten. Eine Begründung, warum das sinnvoll wäre, fehlt mir. Es gibt nur wenig, was gelöscht wird, was man Nicht-Admins zugänglich machen könnte, wo sich das auch lohnt. Es gibt genügend Admins, die das auf Nachfrage machen. Warum also die Regeln unnötig komplizieren?
- Zu 2.: Woher nimmst Du die Gewissheit, man könne Teil-Protects gefahrlos an Sichter verteilen? Das würde Trollen eine ganze neue Spielwiese bieten. Nein, absolut unbrauchbar der Vorschlag.
- Zu 3.: Dir ist schon klar, dass CUler bisher in der de-WP gar nicht sperren? Die meisten sind zwar auch Admins, und dürfen in dieser Funktion Benutzer sperren, aber gerade nicht in den Fällen, wo sie als CU tätig waren. Ich hale es für richtig, das zu trennen.
- Zu 4.: Das haben wir vor ein paar Monaten erst diskutiert, mit dem recht klaren Ergebnis, dass das nicht gewünscht wird.
- Zu 5.: Auch die Hilfsadmins haben wir vor kurzem erst diskutiert, vor zwei oder drei Jahren oder so. Auch da wurde recht klar, dass das nicht sinnvoll abgrenzbar ist.
- Zu 6.: Äh, welche neue Software? Das ist ja die Krux an Deinem Vorschlag, die Software müsste erst programmiert werden. Und die von Dir vorgeschlagenen Änderungen sind nicht-trivial, da bräuchte es schon eine sehr gute Begründung, damit sich jemand damit befasst. Die fehlt aber - Du schilderst nur die zusätzlichen Möglichkeiten, es fehlt aber eine Begrünung, warum diese Möglichkeiten, die bisher nicht gefehlt haben, jetzt plötzlich so nützlich sein sollte. Die meisten helfen wenig bis nichts, ein paar würden mit Sicherheit deutlich mehr Probleme verurschen als beheben. -- Perrak (Disk) 02:36, 8. Jun. 2021 (CEST)
- Zu 1. Gegenfrage: warum werden rechtlich problematische Versionen nicht ohnehin oversighted? Diese sollten eigentlich auch für Admin-Augen unsichtbar sein. Schließlich ist bei rund 180 Admins die Gefahr eines „Datenlecks“ viel größer als bei 5 Oversightern. Zudem brauchen Admins auch keine Verschwiegenheitserklärung unterschreiben, theoretisch könnte es auch minderjährige Admins geben.
Aber auf der anderen Seite gibt es zahlreiche Artikel, die prinzipiell unproblematisch sind, aber wegen fehlender Relevanz gelöscht werden. Wären sie für Sichter weiterhin einsehbar, wäre eine Wiederherstellung einfacher, falls sich eines Tages doch noch genug Relevanz ergibt (siehe auch: Benutzer:Jungfischbecken). - Zu 2. Unverständlich. Durch Seiten-Halbschutz könnte man trollige IPs viel leichter von Artikeln fernhalten, vor allem in der Nacht, wenn nur wenige Admins online sind. Vielleicht sollte man dieses Recht noch dahingehend einschränken, dass es nur im ANR benutzt werden kann.
- Zu 3+4. Nicht ohne Grund haben nur Stewards das
bigdelete-Recht, da man es in den Händen von Admins für zu gefährlich einschätzt. Leider ist es schon vorgekommen, dass ein langjähriger, aktiver Benutzer mit lupenreinem Sperrlogbuch wegen einer einmaligen Verfehlung sofort infinit gesperrt wurde (Beispiel müsste ich raussuchen). Daher sollte man dasblock-editor-Recht auf zeitlich begrenzte Sperren einschränken.
Die Rechteblock-rangeund auchnukehalte ich für zu gefährlich, um sie Admins zur Verfügung zu stellen. Sie sollten nur an „höher Beknopfte“ verliehen werden. Das müssen nicht unbedingt die CUler sein, ebenso kommen Schiedsrichter oder auch nur Stewards (siehe bigdelete) infrage. Wer die Rechte bekommt, soll die Umfrage ergeben. - Zu 5. Vor Kurzem ≠ vor 3 Jahren. Eine Neuauflage könnte inzwischen sinnvoll erscheinen. --Indoor-Fanatiker (Diskussion) 12:42, 8. Jun. 2021 (CEST)
- Wenn wegen Verletzung von WP:BIO gelöscht wird, wird regelmäßig geoversighted, ja. Löschungen wegen URV müssen nicht OSt werden, 200 oder 300 Admins sind wenig genug. Haben tausende Sichter das Recht, gelöschte Artikel einzusehen, müsste man eine zusätzliche Stufe einführen, wenn man die OSler nicht überlasten will.
- Was verstehst Du nicht? Sichterrechte sind leicht zu bekommen, Sockenpuppen leicht anzulegen. Wenn jeder Sichter Artikel sperren könnte, gäbe es Trolle, die sich Sichterrechte durch ein paar hundert unauffällige Edits besorgen, und dann in ein oder zwei Nächten ein paar hundert Artikel sperren. Wer soll da hinterherräumen? Trollige IPs sind harmlos, solange nicht gesichtet wird, ist das für außenstehende ja unsichtbar. Vorschlag verursacht also mehr Probleme, als er lösen kann.
- Dass auch Einzeladmins infinit sperren können ist explizit gewünscht, die Diskussion hatten wir gerade. Die Umfrage sollte man ein paar Jahre auf Eis legen.
- Doch, drei Jahre ist kürzlich. Eine Neuauflage bedürfte zumindest einer guten Begründung. Ich lese von Dir gar keine Begründung, nicht e3inmal eine schlechte. Warum sollte man all diese Änderungen einführen? -- Perrak (Disk) 15:25, 8. Jun. 2021 (CEST)
- Ok, dein Einwand mit den Sichtern ist nachvollziehbar. Zwar beinhaltet das
protect-Recht auch die Möglichkeit, Artikel wieder freizugeben, das könnte also auch von anderen Sichtern (nicht nur von Admins) übernommen werden. Aber die von dir genannten Trolle würden sich natürlich kleine, unbedeutende Artikel aussuchen, die von fast niemandem beobachtet werden, wo also niemand merkt, dass dort etwas schief gelaufen ist. IPs, die etwas sinnvolles beitragen möchten, finden aus Unwissenheit oft nicht die Seite WP:ESW. Zudem könnte es auch zu Wheel-Wars kommen, wenn jeder Sichter das Recht hätte Artikel zu schützen und wieder freizugeben. --Indoor-Fanatiker (Diskussion) 05:58, 10. Jun. 2021 (CEST)
- Ok, dein Einwand mit den Sichtern ist nachvollziehbar. Zwar beinhaltet das
- Zu 1. Gegenfrage: warum werden rechtlich problematische Versionen nicht ohnehin oversighted? Diese sollten eigentlich auch für Admin-Augen unsichtbar sein. Schließlich ist bei rund 180 Admins die Gefahr eines „Datenlecks“ viel größer als bei 5 Oversightern. Zudem brauchen Admins auch keine Verschwiegenheitserklärung unterschreiben, theoretisch könnte es auch minderjährige Admins geben.
Eine dritte sinnlose Umfrage ...
Bearbeitenbrauchen wir eigentlich gerade nicht. Oder ist schon Sauregurkenzeit?--Riepichiep (Diskussion) 08:17, 3. Jun. 2021 (CEST)
- Just my 2 cents: Ich habe mich aus den LD zurückgezogen, weil es einem Nicht-Admin aus o.g. Gründen oft gar nicht möglich ist, über die Sinnhaftigkeit von LA (insbesondere bei der sogenannten Wiedergänger-Problematik) qualifiziert zu entscheiden. Man ist auf den goodwill der Admins angewiesen, die ihre kostbare Zeit lieber anderweitig einsetzen sollten. Von daher verstehe ich das Anliegen hier gut und würde es ausdrücklich unterstützen. Das ist imho keine Abwertung der Admins, eher eine Entlastung. Hodsha (Diskussion) 18:38, 14. Jun. 2021 (CEST)
Überschrift "Sollte man mehr Nutzer zu Admins wählen?"
BearbeitenHallo,
was soll die Überschrift "Sollte man mehr Nutzer zu Admins wählen?" Wenn das gewollt würde, könnte man das einfach tun, dafür muss man nichts ändern. Eine deutliche Senkung des Quorums wäre übrigens nicht nur unsinnig, sondern sogar unmöglich, weil das der Betreiber der Website nicht will. Das könnten wir als Community selbst dann nicht ändern, wenn wir das wollten. -- Perrak (Disk) 00:01, 13. Jun. 2021 (CEST)
- Ok, danke für den Hinweis. Und was sagt die Betreiberin (WMF) zu unserem, etwas komischen Wahlverfahren zum Schiedsgericht? Hätten bei der letzten SG-Wahl dieselben Anforderungen gegolten wie bei Adminwahlen, wären 2 Kandidaten (Luke081515 und Lantus) nicht gewählt worden. Wie bereits in meiner anderen Umfrage erwähnt, finde ich ehrlich gesagt etwas absurd, dass Schiedsrichter zwar das mächtigere Amt bekleiden (sie können sogar einen Admin seines Amtes entheben), aber trotzdem schwächer legitimiert sind. --Indoor-Fanatiker (Diskussion) 02:32, 13. Jun. 2021 (CEST)
- Du irrst, wenn Du denkst, dass ein SG-Mitglied "mächtiger" ist als ein Admin. Ein SG-Mitglied, das nicht auch als Admin gewählt ist, hat keine größeren Rechte als ein "Fußgänger". Das SG als Kollegialorgan kann beschließen, dass einem Admin die Rechte entzogen werden. Aber auch nicht willkürlich, die Durchführung obliegt anderen. Als Admin kann man Benutzer infinit sperren. Wenn das nicht völlig unzureichend begrünet wird, wird das meist auch in einer Löschprüfung bestätigt.
- Ein wichtiger Unterschied zwischen der Wahl eines Admins und der Wahl des SG besteht darin, dass das eine eine Einzelwahl ist, auch wnen gelegentlich mehrere Wahlen parallel stattfinden, während das SG als Gruppe gewählt wird. Wird eine einzelne Admin-Kandidatin nicht gewählt, kann schon morgen der nächste kandidieren und gewählt werden. Erreichen bei der Wahl zum SG zu wenig Leute das Quorum, dann ist das SG bis zur nächsten Wahl unterbesetzt. -- Perrak (Disk) 10:40, 13. Jun. 2021 (CEST)
- Immerhin wird das SG aber zu den sogenannten „höheren Service-Funktionen“ gezählt, also zu jenen Berechtigungsgruppen, die nach allgemeinem Verständnis auf den Adminrechten aufbauen und somit auch als "mächtiger als Admins" gelten. Das SG steht auf einer Stufe mit den Bürokraten, CU-Berechtigten und Oversightern.
- Zu deinem Einwand: man sollte sich vielleicht Gedanken machen, ob man das Wahlverfahren zum SG (und auch zu den anderen höheren Service-Funktionen) dahingehend ändert, dass man eine Nachwahl mit neuen Kandidaten ermöglicht, falls Unterbesetzung (z.B. durch Rücktritt) eintritt. --Indoor-Fanatiker (Diskussion) 20:42, 14. Jun. 2021 (CEST)
- Letzteres wäre ein sinnvolleres Umfragethema als manche andere. -- Perrak (Disk) 20:47, 14. Jun. 2021 (CEST)
- Das ist eine gute Anregung für meine andere Umfrage zu den höheren Service-Funktionen. --Indoor-Fanatiker (Diskussion) 08:05, 15. Jun. 2021 (CEST)
- Letzteres wäre ein sinnvolleres Umfragethema als manche andere. -- Perrak (Disk) 20:47, 14. Jun. 2021 (CEST)