Diese Umfrage begann am 5. Februar 2023 um 19:55 und endete am 12. März 2023 um 19:55.

Initiator der Umfrage ist Benutzer:Der-Wir-Ing.

Diese Umfrage dient der möglichen Vorbereitung eines Meinungsbildes zu Reformen im BOSCU-Bereich (Bürokraten, Oversighter und Checkuser).

Konkreter Anlass war der Rücktritt zweier Bürokraten, der zur Handlungsunfähigkeit der verbleibenden beiden Bürokraten führte, siehe hier + folgender Abschnitt (Permalink). Diese Umfrage beschränkt sich aber bewusst nicht auf B, sondern zieht die vergleichbaren CU und OS mit ein, insbesondere, weil die Regeln zur Aufgabentrennung es Benutzern nur erlauben, eines dieser Ämter zu übernehmen. Zusätzliche Bürokraten bedeutet also weniger Kandidaten für die anderen Bereiche, in denen es auch Kandidatenmangel gibt.

Einleitung

Bearbeiten

Was ist BOSCU?

Bearbeiten

BOSCU ist wikipediainterner Jargon für drei technische Sonderrechte:

  • Bürokraten: werten Adminkandidaturen aus und vergeben Adminrechte sowie Bürokratenrechte. Außerdem erteilen sie eine Reihe weiterer Rechte wie Bot oder Benutzeroberflächenadministrator. De facto übernehmen sie oft auch die Auswertung anderer Kandidaturen (Schiedsgericht, CU, OS), obwohl das nicht ausdrücklich geregelt ist.
  • Oversighter: können Artikel und Versionen auf eine Weise löschen, die auch für reguläre Admins nicht mehr einsehbar ist.
  • Checkuser: können bei Bearbeitungen durch Benutzerkonten deren IP-Adressen ermitteln, um Personen zu finden, die mehrere Konten nutzen.

Aktuelle Situation

Bearbeiten

Gemeinsame Regeln für den BOSCU-Bereich

Bearbeiten

Für BOSCU gelten ein paar gemeinsame Sonderregeln.

  • Alle drei haben immer zusätzlich auch Adminrechte. Falls nicht-Admins gewählt werden, erhalten sie die Adminrechte ausschließlich zur Erfüllung ihrer BOSCU-Aufgaben, nicht für reguläre Adminaufgaben.
  • Sperrung der Wiederwahlseite: Alle drei Arten von Funktionsträgern werden für eine Amtszeit von 2 Jahren gewählt. Während dieser Zeit ist im Normalfall deren Wiederwahlseite geschützt (oder freiwillig offen).
  • Für diese drei Funktionen und Mitglieder des Schiedsgerichts, SG, gilt das Meinungsbild zur Aufgabentrennung von 2009: Wer eines dieser 4 Ämter innehat (inkl. SG), darf kein weiteres dieser Ämter übernehmen. (Sie dürfen aber gleichzeitig Admin sein und sind das auch meist (BOSCU) oder manchmal (SG).)

Weitere Regeln

Bearbeiten

Es gibt einige globale Regeln (von der WMF vorgegeben, teils von der globalen Community):

  • In einem Projekt (wie bspw. deutschsprachige Wikipedia) muss es entweder mindestens 2 Checkuser oder 2 Oversighter geben oder gar keinen CU / OS. Für Bürokraten gibt es keine Mindestanzahl seitens der WMF. Die Mindestanzahl von 3 Bürokraten (und 3 CU/OS) hat sich die deutschprachige Community in eigener Entscheidung selbst gegeben.
  • Für CU und OS sind durch globale Regeln bei Wahlen mindestens 70% Zustimmung vorgesehen. Für B gibt es keine globalen Vorgaben; 50 % würden ausreichen. (Vgl. aber lokale Regel weiter unten)
  • CU und OS müssen eine Vertraulichkeitserklärung unterzeichnen sowie einige weitere Regeln beachten, die hier nicht weiter von Bedeutung sind. (meta:CheckUser policy, meta:Oversight policy)

Lokale Regeln (de-Wikipedia):

  • Wie in den meisten Projekten können de-Bürokraten Adminrechte vergeben, aber nicht entziehen. Es ist aber möglich, Bürokraten auch das Recht zum Entzug dieser Rechte zu geben, was bspw. in der englischen Wikipedia und einigen weiteren praktiziert wird.
  • Bürokraten benötigen mindestens 70 % Zustimmung in Wahlen.
  • Die Anzahl der CU und OS ist auf je 5 begrenzt. Für Bürokraten gibt es ausdrücklich keine Maximalzahl. (Wikipedia:Meinungsbilder/Prozedere bei Bürokratenkandidaturen)
  • Für CU und OS gibt es jährliche, feste Wahltermine. Nur zu diesen Terminen sind Kandidaturen möglich. Eine Bürokratenkandidatur kann dagegen jederzeit begonnen werden.
  • Für CU gilt Wikipedia:Checkuser#Richtlinien:
    • „Die Checkuser-Berechtigten werden ausschließlich bei Anfragen Dritter aktiv.“
    • „Sie führen die Abfragen durch und teilen Ergebnisse mit, überlassen aber im Sinne der Aufgabentrennung darauf folgende Maßnahmen zuvor unbeteiligten Administratoren.“

Jüngste Ereignisse und kurzer Rückblick

Bearbeiten

Derzeit (05. Feb. 2023) haben wir nur zwei amtierende Bürokraten, während die Regel zur Aufgabentrennung besagt, dass es immer 3 Bürokraten (und OS sowie CU) geben muss. Die deutschsprachige Wikipedia ist daher was die Vergabe von Adminrechten angeht (Aufgabe der Bürokraten) handlungsunfähig, was die Regeln angeht, obwohl die verbleibenden beiden Bs technisch dazu in der Lage wären.

2022 gab es nur 3 amtierende Checkuser (vgl. Diagramm im Abschnitt Wikipedia:Checkuser#Checkuser-Berechtigte), was ebenfalls die Minimalzahl darstellt. Einer der drei hatte eigentlich einen Rücktritt geplant (der Initiator dieser Umfrage), hätte aber wegen der Mindestens-3-CUler-Regel durch den Rücktritt ebenfalls die verbleibenden Kollegen handlungsunfähig zurückgelassen. Bei den Wahlen der letzen Jahre gab es meist gerade genügend Kandidaten, um die freien Plätze zu füllen.

Insbesondere beim Schiedsgericht kam es über die letzen Jahre immer wieder zu Kandidatenmangel, sodass Plätze unbesetzt blieben. (vgl Diagramm auf Wikipedia:Schiedsgericht#Besetzung_des_Schiedsgerichts). Statt der vorgesehenen 10 Mitglieder gab es des Öfteren nur 8 oder 9 (von denen manche wenig aktiv waren).

Probleme / Auswirkungen

Bearbeiten

Achtung! Hier fängt die Meinung des Initiators an. Ob diese Zustände problematisch oder wünschenswert sind, muss letztendlich jeder selber für sich beantworten.

  • Die Rechtevergabe an neu gewählte Admins und Bürokraten muss derzeit von den Stewards übernommen werden. Ebenso Vergabe und Entzug weiterer Rechte, die üblicherweise von Bürokraten erledigt werden (Importeur, Bot,....)
  • Nachdem die Bürokraten nicht mehr für Umbenennungen von Benutzerkonten zuständig sind, haben sie an Bedeutung verloren. Diskutiert wurde sowohl die Abschaffung der B als auch ihnen zusätzliche Rechte zu übertragen.
  • Die 70 % Hürde für Bürokraten schränkt die Anzahl der erfolgreichen Kandidaten mehr ein als seitens der WMF als unbedingt nötig erachtet wird.
  • Rechtevergabe an Admins und Bürokraten erfolgte bislang lokal (in der de-Wikipedia) der Entzug dagegen auf meta und wurde von Stewards durchgeführt.
    • Dadurch werden Vergabe und Entzug der Rechte in verschiedenen Projekten geloggt. Innerhalb der de-WP sieht man also nur die Vergabe der Rechte, aber keinen Entzug.
    • Dadurch mehr Aufwand für Stewards. Insb. bei knappen/umstrittenen Wiederwahlen (Abwahlen), da dann die speziellen de-Regeln zum Prozedere geprüft werden müssen.
  • Geringer Kandidatenpool aufgrund der Regeln zur Aufgabentrennung. (Zusätzliche Bürokraten bspw. bedeutet also weniger Kandidaten für die anderen Bereiche in denen es auch Kandidatenmangel gibt. Der ehemalige Bürokrat MBq bspw. musste das B abgeben um CUler zu werden. Mehrere ehemalige Schiedsrichter wurden nach ihrer SG-Zeit CUler und stehen damit als SG-Kandidaten nicht mehr zur Verfügung. (Bspw. Alraunenstern, Perrak, Der-Wir-Ing: SG->CU, Krd: SG->B)
  • Schiedsrichter dürfen keine OS- und CU-Rechte haben, was teils den ihnen zugewiesenen Aufgaben widerspricht oder sie erschwert:
    • Das SG ist ausdrücklich zuständig bei Sockenpuppenmissbrauch, kann aber ohne CU-Recht den Vorwurf nicht selbst prüfen.
    • Das SG ist zuständig für "Auseinandersetzungen um Adminfunktionen" und damit auch für die Prüfung von Benutzersperren. Falls diese auf CU-Ergebnissen oder oversighteten Versionen/Seiten beruhen, kann das SG nicht vollständig überprüfen. (Vgl. auch das klar abgelehnte MB Schiedsgericht und Oversight-Maßnahmen das auf einem konkreten Vorfall basierte)
    • Durchsetzung von SG-Auflagen und Maßnahmen ist erschwert wenn diese mit Socken oder per IP umgangen werden. CUler dürfen teils aufgrund globaler Regeln entscheidungsrelevante Informationen nicht ans SG weitergeben, weil die SG-Mitglieder keine CU-Rechte haben. (Kommentar DWI: Kein theoretischer Fall. Kam schon mehrfach vor. Details können aufgrund der Verschwiegenheitserklärung nicht veröffentlicht werden.)
  • Die beiden lokalen Regeln zum CU schränken den Umgang damit ein. Bei potentiellen Mehrfachabstimmern von ansonsten konstruktiven (langjährigen) Benutzern unproblematisch. Bei Vandalen, Sperrumgehern, Spambots, Agenturen für (undeklariertes) bezahltes Schreiben, etc. teils [laut DWI; umstritten] stark einschränkend:
    • Auch bei relativ offensichtlichen Socken, Vandalen, etc. muss auf die Anfrage eines Dritten gewartet werden. Selbst wenn nach einer CUA Socken gesperrt werden und diese Person unmittelbar mit neuen Konten weiter vandaliert oder ein bezahlter Autor unmittelbar mit neuem Konto weiterschreibt.
    • Gerade im Falle von Sperrumgehungen könnte die IP gesperrt werden von der die Bearbeitungen/Kontenerstellungen kommen. Administrative Maßnahmen (wie IP-Sperren) müssen aber unbeteiligten "Admins" überlassen werden. Laut globalen Regeln dürfen reguläre Admins (die nicht CUler sind) diese IPs aber nicht erhalten. Vgl. dazu auch die Regeländerung der niederländischen Wikipedia die seit Januar 2013 CUlern ausdrücklich erlaubt IPs zu sperren. In vielen Projekten bereits üblich. Vgl. auch Wikipedia:Checkuser/Anfragen/Casinospam:_Slotdepositdana#Entscheid_und_Ergebnisse "Offensichtlicher Spambot. Ich kenn die IPs nun. Ich darf sie nicht veröffentlichen."
    • Das CU-Tool erlaubt es gefundene Konten auszuwählen und mit wenigen Klicks alle gleichzeitig zu sperren, bei allen gleichzeitig die selbe Sperrbegründung zu verwenden, gleichzeitig die Benutzer(diskussionsseite) zu sperren und/oder durch einen anderen Text zu ersetzen (bspw. Vorlage:Gesperrter Benutzer). Gerade bei Sockenspielern mit sehr vielen Konten (Beispiele 1, 2) Würde das den Aufwand reduzieren auf wenige Minuten von mehreren Stunden (alle Konten manuell aus dem CU-Tool in die öffentliche Anfrage kopieren, für jede IP einzeln Prüfen, danach von Admins alle einzeln gesperrt, Benutzerseite geschützt, Disk geschützt, Vorlage:GB gesetzt).
    • Manche Langzeit-Vandalen umgehen Auflagen und Projektausschlüsse einfach via IP: Die via CU gefundenen Bearbeitungen/Seitenerstellungen bleiben dann häufig. Selbst wenn die Personen bekannt sind für Urheberrechtsverstöße, Fake news, etc.

Allgemeine Anregungen

Bearbeiten

Hier können eigene, weiter unten nicht aufgeführte Vorschläge notiert werden.

  • Für alle Boscu-Wahlen sollte für das aktive und passive Wahlrecht die SG-Stimmberechtigung vorausgesetzt werden. Für die Gültigkeit der Wahlen sollte eine erforderliche Mindestbeteiligung gelten, die dem Verhältnis der gegenwärtigen Zahl stimmberechtigter Nutzer und der durchschnittlichen Wahlbeteiligung entspricht. -- Leif Czerny 15:25, 11. Feb. 2023 (CET)[Beantworten]

Aufgabentrennung (Ämtertrennung) allgemein

Bearbeiten
  • Einerseits möchte ich keine Superadmins a la (B/OS/CU/SG/A), andererseits ist die derzeitge Variante schon sehr restriktiv. Bei der Variante, dass alle A auch B sind, müsste man B von der Ämtertrennung ausnehmen. Kommt mir sinnvoll vor. Ebenso beim SG, denn die können insbesondere CU-Rechte brauchen, selbst wenn man dann per Regeln festlegt, dass sie selber nicht abfragen dürfen. Dann könnte mann zumindest die nötigen Infos zukommen lassen und das SG hätte Mittel um Missbrauch (der CU-Rechte) zu prüfen. --Der-Wir-Ing ("DWI") (Diskussion) 20:27, 5. Feb. 2023 (CET)[Beantworten]
  • Ich sehe kein Problem. Eine Abschaffung der Ämtertrennung hätte katastrophale Folgen für die Transparenz. Kein Reformbedarf gegeben.--Mautpreller (Diskussion) 20:56, 5. Feb. 2023 (CET)[Beantworten]
  • Eine Kombination B und CU könnte akzeptabel sein, CU und OS wohl auch. SG sollte man hier nicht berücksichtigen, es ist auch egal, weil dort die einfache Mehrheit reicht, weswegen dort eher die zweite Garnitur aktiv ist, bei der es zum Admin nicht (mehr) reicht. Da besteht eh keine Konkurrenz um die anderen Posten. MBxd1 (Diskussion) 21:35, 5. Feb. 2023 (CET)[Beantworten]
  • SG ist etwas eigenständiges, gehört nicht wirklich in diese Diskussion. Dass B in den beiden anderen Gruppen aufgehen sollen (bzw. in einer davon, OS wäre meine erste Wahl) predige ich schon lange. OS und CU sollten in jedem Fall immer und dauerhaft in getrennten Händen sein. Und wer im SG ist, kann nicht CU/OS sein. -- Marcus Cyron Stand with Ukraine and Iran! 22:36, 5. Feb. 2023 (CET)[Beantworten]
  • Aufhebung der Ämtertrennung wäre mMn langfristig nicht hilfreiche Flickschusterei am Problem fehlender Kandidaten. Lieber fehlen mal kurzfristig ein paar Leute, als dass gar keine „neuen“ Leute mehr kandidieren, weil es so aussieht, als wäre ja alles besetzt und es würde kein Bedarf bestehen, obwohl insgesamt dann weniger Personen da sind als vorher. --Icodense 10:29, 6. Feb. 2023 (CET)[Beantworten]
  • Meinetwegen kann man die Ämtertrennung aufheben. Man kann im konkreten Fall ja trotzdem bei einer Wahl mit Kontra stimmen, wenn die Person bereits ein anderes Amt hat. --Ameisenigel (Diskussion) 11:09, 6. Feb. 2023 (CET)[Beantworten]
  • Sehe kein Problem darin, wenn B zusätzlich entweder CU oder OS sind (was einen Fall wie MBq verhindern würde, der kürzlich im Zuge seiner CU-Wahl als Bürokrat zurücktreten musste). Sehe in der Konstellation weder ein Transparenzproblem noch gefährlich viel Macht. Verstehen kann ich solche Bedenken in Bezug auf die Kombi CU + OS, wo man die Ämtertrennung gern beibehalten kann. --Johannnes89 (Diskussion) 12:50, 6. Feb. 2023 (CET)[Beantworten]
  • Wir dürfen auf keinen Fall eine Kombination von CU und OS erlauben. Kollisionen mit dem Bürokratenamt sehe ich nur wie bei Mautpreller einen Abschnitt höher (ist eventuell bei diesen Funktionen nicht so wichtig). Das SG ist mir völlig egal, keine Ahnung, was die treiben. --Sabrieleauftistik (Diskussion) 15:00, 6. Feb. 2023 (CET)[Beantworten]
  • Insbesondere keine Kombination von CU und SG. Die Checkuser sollen auf Anzeige hin ermitteln, Schiedsgericht im Streitfall entscheiden. Das halte ich für inkompatibel. --Mogelzahn (Diskussion) 16:49, 6. Feb. 2023 (CET)[Beantworten]
  • CU, OS und SG haben getrennt zu bleiben: CU/SG (und OS/SG) siehe Mogelzahn, CU/OS getrennt zur Vermeidung eines Machtvakuums (und sofern ein CU OS-Infos braucht: Dienstweg einschlagen). Bei B ist es egal. --Filzstift (Diskussion) 16:58, 6. Feb. 2023 (CET)[Beantworten]
    @Filzstift Welchen "Dienstweg" meinst du? --Der-Wir-Ing ("DWI") (Diskussion) 02:48, 8. Feb. 2023 (CET)[Beantworten]
    @Der-Wir-Ing Sobald Dinger versteckt werden müssen, ich da aber weitere Informationen brauche. Beispiel: Socke soll Details zu einer Person preisgegeben haben, ähnlich wie es der Hauptaccount tut. Dann geht eine Mail raus an die OS mit Bitte um Informationen. Wird dann ins OS-Pseudolog eingetragen: "Feedback" (Beispiel). --Filzstift (Diskussion) 08:03, 8. Feb. 2023 (CET)[Beantworten]
    Und die Antwort ist "Wir dürfen dir keinen Daten geben" Sinnloser Dienstweg. Die dürfen ja auch keine Infos rausrücken. Nie. --Der-Wir-Ing ("DWI") (Diskussion) 20:10, 8. Feb. 2023 (CET)[Beantworten]
    es gehr nicht um Inhalte sondern Angaben wie: "Ja der Text ist ähnlich/identisch". Und ja, dieser Dienstweg hilft. --Filzstift (Diskussion) 21:34, 8. Feb. 2023 (CET)[Beantworten]
    Da scheinst du ganz andere Erfahrungen zu haben. Mir haben schon mehrer Admins berichtet, dass die da nie auch nur igendwas erfahren hätten als "Wir dürfen dir nichts verraten" Sogar von Admins die mit OSlern befreundet sind. Ich dürfte auch andersherum den OS keine IPs verraten. Wenn die Community das so möchte, muss die die Leute eben in beide Funktionen wählen. (oder die WMF überzeugen die globale Policy zu ändern, das die sicher nicht tun werden) --Der-Wir-Ing ("DWI") (Diskussion) 22:12, 8. Feb. 2023 (CET)[Beantworten]
    Aber was ist die Alternative? Eine „Gott-Benutzergruppe“, die alles sehen, auswerten und entscheiden darf, weil jede Form der Spezialisierung dazu führt, dass irgendwem irgendwann für irgendeine Entscheidung irgendwas nicht zur Verfügung stehen würde? (Wobei es die wohl schon gibt: die Stewards.) Das ist eine Lösung, aber eine höchst unzufriedenstellende (würde ich sagen). Dann sollte man vielleicht wirklich an die Prozesse ran und zusehen, dass der „Dienstweg“ möglich wird. Und damit meine ich nicht, dass der OSler gelöschte Texte rausgeben darf. Wenn der einfach sagt, er dürfe nichts verraten, macht der sich einen schlanken Fuß. Ich weiß zugegebenermaßen nicht, welche globale Richtlinie eine Information der von Filzstift genannten Form verbieten würde, aber ich würde eine solche für ausgesprochen sinnfrei halten. --Sabrieleauftistik (Diskussion) 23:47, 8. Feb. 2023 (CET)[Beantworten]
    meta:Access to nonpublic personal data policy --Der-Wir-Ing ("DWI") (Diskussion) 01:01, 9. Feb. 2023 (CET)[Beantworten]
    2012 war das vielleicht noch etwas anders (da war die Policy noch eine andere [1]) - da schien man irgendwie noch zwischen der Preisgabe des overgesighteten Inhalts von einer allgemeinen Auskunft differenzieren zu können (vorausgesetzt natürlich, die Anfrage wirkt legitim). --Filzstift (Diskussion) 08:21, 9. Feb. 2023 (CET)[Beantworten]
    In der verlinkten Policy sehe ich ehrlich gesagt nichts, was eine Information der Form „Ja, der Text ist ähnlich“ verbieten würde. Da steht natürlich auch, dass kein CUler/OSler verpflichtet wäre, eine Information zu geben. Aber wie ich oben geschrieben habe: Wenn man auf dieser Basis Auskünfte pauschal ablehnt, macht man sich einen leichten Fuß.
    Letztendlich geht es um die Auslegung, was „Nonpublic Personal Data“ sind. Da die Policy dies nicht vollends ausspezifiziert, haben meiner Ansicht nach die Communities durchaus die Möglichkeit, in dieser Hinsicht lokal eigene Regeln aufzustellen. (Zumindest habe ich in dieser Frage nicht mehr gefunden als einen Verweis auf meta:Privacy policy, wo es auch nur eine Minimaldefinition von „Personal information“ gibt – worunter Textähnlichkeit eher nicht fällt.) --Sabrieleauftistik (Diskussion) 10:27, 9. Feb. 2023 (CET)[Beantworten]
    Die Communitys können immer strengere Regeln einführen, aber nie etwas erlauben was die WMF verboten hat. OS ist dazu da "Nonpublic Personal Data" verschwinden zu lassen (und auch paar andere Dinge wie URV). Bei URV mag es erlaubt sein Infos herauszugeben, aber eben nicht bei nicht-öffentlichen personenbezogenen Daten. Definiert ist das ganze in der Vertraulichkeitserklärung meta:Confidentiality agreement for nonpublic information:Nonpublic personal data includes "personal information" as defined by the Wikimedia Privacy Policy, IP addresses, and other personally identifying information that are not otherwise publicly available. It does not include information about a user that that user has made public on the Wikimedia projects. Und "Personal information" ist dann in der erwähnten foundation:Privacy_policy#Definitions. --Der-Wir-Ing ("DWI") (Diskussion) 11:14, 9. Feb. 2023 (CET)[Beantworten]
    Genau die habe ich doch gelesen. (Zumindest sieht das aus wie das, was ich verlinkt habe.) Wir mögen sie unterschiedlich interpretieren, aber ich jedenfalls lese dort nicht heraus, dass OSlern nicht gestattet wäre, den Inhalt einer per OS versteckten Seitenversion zu kommentieren, natürlich nur, solange sie dabei keine der genannten Informationen („your real name, address, phone number, email address, password …“ usw., wahrscheinlich auch strafrechtlich relevante Aussagen, die zum Verstecken der Version führten, usw.) veröffentlichen. Analogie zum CU: Es ist CUlern erlaubt, öffentlich zu bestätigen, dass zwei Konten dieselben IP-Adressen benutzen, aber nicht, die IP-Adressen selbst zu veröffentlichen. Ich sehe keinen Grund, warum ein OSler nicht zum Beispiel auf Nachfrage bestätigen dürfen sollte, dass eine OS-versteckte Version die gleichen volksverhetzenden Verschwörungstheorien und gruppenbezogen menschenfeindlichen Aussagen beinhaltet wie eine andere.
    Worauf ich hinauswill, ist, dass es uns als Community freisteht, Zusatzregeln einzuführen (wie du schreibst: „können immer strengere Regeln einführen“), und wenn die globalen Regeln etwas nicht regulieren (zum Beispiel, ob inhaltliche Vergleiche zwischen versteckten Versionen ohne Bekanntgabe persönlicher Informationen öffentlichkeitsfähig sind), „dürfen“ wir als Community diese Regulierungslücke für uns mit eigenen Vorgaben füllen. Noch mal: Es kann sein, dass wir beide die globalen Regeln unterschiedlich interpretieren. Aber im Zweifel könnte man vor einem Meinungsbild oder dergleichen auch mal bei der WMF nachfragen, wie sie zu diesem Thema steht. Dass die globalen Regeln sehr schwammig formuliert sind, ist ja grundsätzlich ein Missstand. --Sabrieleauftistik (Diskussion) 12:22, 9. Feb. 2023 (CET)[Beantworten]
  • Entschieden dagegen, das Verbot der Ämterhäufung aufzuheben.--Altaripensis (Diskussion) 12:25, 7. Feb. 2023 (CET)[Beantworten]
  • Es gibt Gründe dafür, und auch wenn der Personalpool schon mal größer war, sollten wir es schaffen, die Posten zu besetzen. … «« Man77 »» Alle Angaben ohne Gewehr. 17:30, 7. Feb. 2023 (CET)[Beantworten]
  • Man sollte die Ämtertrennung beibehalten. Besser bei den Wahlen fähige Kandidaten unterstützen und auch mal 10 Jahre alte Geschichten vergessen. --DaB. (Diskussion) 18:40, 7. Feb. 2023 (CET)[Beantworten]
  • Ämtertrennung ausbauen nett abbauen. Ein Erster Schritt wäre keine Löschanträge durch Admins , Schiedsgerichtler und sonstigen Würdenträger. Auch sollte man bei Adminwahlen darüber nachdenken ob nur das Fussvolk darüber abstimmen darf. ไม่เป็นไร (Valanagut) (Diskussion) 20:05, 7. Feb. 2023 (CET)[Beantworten]
  • Die Ämtertrennung ist wertvoll, aber die Aufgabenverteilung unter den Ämtern nicht. B sollte deadministreien drüfen (gemöß der etablierten Verfahren) CU sollte sprren dürfen. Es sollte eine zentrale Clearingstelle geben, wo SGs von OS und CU Auskünfte, so weit es globale Regelungen zulassen, für SG, CU, OS einsehbar von CU, OS und B anforderen können, so dass hier eine Auskunftspflicht und Mehraugenprinzip gelten. -- Leif Czerny 14:47, 11. Feb. 2023 (CET)[Beantworten]
    Wenn möglich sollten auch B und A unvereinbare Ämter werden.~~~ ---- Leif Czerny 15:26, 11. Feb. 2023 (CET)[Beantworten]
  • Tendiere sehr zu Mautprellers Ansicht. --Björn 18:15, 22. Feb. 2023 (CET)[Beantworten]

Mindestanzahl

Bearbeiten

Kommentare zu Bürokraten

Bearbeiten

Bürokraten allgemein

Bearbeiten

Erteilung von Bot-, Limit-Ausgenommener und Status als bestätigter Benutzer durch Admins

Bearbeiten
  • Die Rechte zur Erteilung von Bot-, Limit-Ausgenommener und der Status bestätigter Benutzer sollten den Admins zugeordnet werden. Diese Rechte stellen kein besonderes Missbrauchspotential dar. Erstere werden eh nur einige Male im Jahr benötigt. Botrechte sind zwar bedeutsamer. Bürokraten wurden jedoch nicht gewählt, weil sie spezielles Know-how dafür mitbringen. Sie folgen lediglich der Einschätzung der technischen Community auf WP:BFA. Sinnvoller würde ich es daher halten, wenn die Anträge auf Neuerteilung der Botflag von allen sich darauf spezialisierten Admins ausgewertet und erteilt werden könnten. --Wnme (Diskussion) 20:26, 8. Feb. 2023 (CET)[Beantworten]
    Pro Halte ich ebenfalls für sinnvoll. LG Dwain 13:39, 10. Feb. 2023 (CET)[Beantworten]
  • Kontra zumindest was Bot-Rechte angeht, denn diese stellen durchaus ein Missbrauchspotential dar. Die harmlosen Limit-Ausnahmen und bestätigten Benutzer können meinetwegen auch Admins vergeben. Da diese Rechte nur ziemlich selten benötigt werden, sehe ich allerdings auch kein zwingendes Erfordernis dafür. --Ameisenigel (Diskussion) 22:23, 10. Feb. 2023 (CET)[Beantworten]
  • Nein. Im Gegensatz zu BOSCU ist die Gruppe der Admins zu groß, das führt zu Schwierigkeiten in der Zuschreibung von Verantwortung und in der Abstimmung. Manche Admins schaffen es ja nicht mal, dem Mattermost-Chat beizutreten.14:51, 11. Feb. 2023 (CET)
  • Bot: Klar nein, bedarf regelmäßiger Involvierung in WP:BFA. Bestätigte Konten haben sich nach einer Woche ohnehin erledigt, und die unbefristete Limit-Ausnahme sollte einmal jährlich durch die Bürokraten durchgeguckt werden, ob die Gründe noch bestehen – befristete Limit-Ausnahme bekannter Sichter-Konten durch Admins birgt keine erkennbare Risiken. --PerfektesChaos 14:57, 12. Feb. 2023 (CET)[Beantworten]

Vergabe des Rechtes "Importeur" lokal durch Bürokraten

Bearbeiten

Entzug von Adminrechten auch durch Bürokraten

Bearbeiten

Abschaffung der Benutzer*innengruppe "Bürokrat" und Kopplung der entsprechenden Rechte an die Gruppe "Administrator"

Bearbeiten

Abschaffung der Benutzer*innengruppe "Bürokrat", Übergabe der Aufgaben an die Stewards

Bearbeiten

(Nachtrag am 17.02.2023, weil das bei Diskussionen regelmäßig vertreten wird. Dies ist KEINE Stimmabgabe dafür. --KnightMove (Diskussion) 10:32, 17. Feb. 2023 (CET))[Beantworten]

Hinweis: Sowas nennt man eigentlich „Vertrag zu Lasten Dritter“. Heißt: Hierzu müssten fairerweise auch die Stewards einwilligen, ob sie diese Zusatzaufgabe übernehmen wollen. VG --PerfektesChaos 10:41, 17. Feb. 2023 (CET)[Beantworten]

Alle Admins sollen auch Bürokrat sein

Bearbeiten
Siehe Ittis Anmerkung auf der Diskussionsseite. Itti hält nichts davon.--Mautpreller (Diskussion) 10:07, 6. Feb. 2023 (CET)[Beantworten]
Nein Dann würde ich dem folgen. --Viele Grüße, Aschmidt (Diskussion) 21:43, 6. Feb. 2023 (CET)[Beantworten]

Wahlmodalitäten Bürokraten (Insb. 70 % Hürde)

Bearbeiten

Schutz der Wiederwahl-Seite von Bürokraten

Bearbeiten

Bürokraten als Notariat

Bearbeiten

Das meint: Überwachen von Wahlen und Abstimmungen, Feststellung des Endergebnisses, Klärung der Stimmberechtigung, verbindliche Entscheidung bei problematisch zustandegekommenen Ergebnis.

  • Es ist immer besser, im Vorfeld unabhängig von einem konkreten Anlass eine Prozedur auf Vorrat zu vereinbaren, nach der dann im Konfliktfall verfahren werden kann.
  • Der letzte Fall spielte sich 2019 ab; die letzte aufgearbeitete Manipulation zuvor war wohl 2012. Das ist nicht häufig, aber kann in jedem Monat wiederkehren.
  • Heute müssen die Berliner ihre Landtagswahl wiederholen. Vor zwei Wochen hatte das Bundesverfassungsgericht vorläufig entschieden, dass die Wahlwiederholung stattfinden darf, sich aber die Entscheidung in der Hauptsache vorbehalten, die erst in einigen Monaten fallen wird und mit der theoretisch die heutige Wahl wieder ungültig werden könnte. Heißt: Auch hier gibt es keine exakten Prozeduren und Zuständigkeiten, wer wann worüber letztendlich entscheiden kann. Ewige Hängepartien sind die Folge.
  • Wenn erst im konkreten Streitfall über die Prozedur zur Lösung nachgedacht wird, dann folgt aus jedem Vorschlag sofort die voraussichtliche Auswirkung auf die momentane Situation.
  • Neben dem Ergebnis ist auch das korrekte Zustandekommen einer formalen Entscheidung hinsichtlich eingehaltener Fristen, Zahl zulässiger Unterstützer und hinreichende Bekanntmachung in der Community oder nachträgliche kleine Änderungen von Vorschlägen potenzieller Grund für den Abbruch bereits angelaufener Beteiligung mit vielerlei denkbaren Konstellationen und Auslegungen.

Vorschlag für formalen Richtlinientext:

Die Bürokraten überwachen die formalen Entscheidungsprozesse der Community (namentlich Wahlen, Meinungsbilder und BSV) hinsichtlich ordnungsgemäßem Zustandekommen, Stimmberechtigung und Ablauf, stellen das Ergebnis fest und dokumentieren es in entsprechenden Projektseiten. Bei Verdacht auf Unregelmäßigkeiten bewerten sie die Situation und treffen eine verbindliche Entscheidung, wie damit umgegangen werden soll.

  • CU können nur in sehr klaren Fällen (bei technisch arg depperter Socke) eine Manipulation feststellen. Die Vorstellung, CU wäre unter heutigen Bedingungen noch zu Wertungen in der Lage, ist zwei Jahrzehnte hinter der Realität zurück.
  • Eine Einstufung als Wahlsocke ist praktisch nie zu 100 % durch softwareseitige Merkmale möglich, sondern bedarf regelmäßig einer Bewertung anhand des gesamten sonstigen Editierverhaltens, um dies einem anderen Konto zuzuordnen.
  • Bürokraten haben per Mindestquote ein hohes Vertrauenspotenzial in der Community und eignen sich deshalb gut als Instanz zur Entscheidung unklarer formaler Vorgänge. Sie müssen diese Prüfung bisher von Amts wegen nur vornehmen, wenn Software-Rechte vergeben werden, weil sie sich hierzu von einer ordnungsgemäß erfolgten Wahl überzeugen müssen. Dies kann leicht auf alle formalen Entscheidungen ausgeweitet werden.
  • Um als kurzfristige Entscheidungsinstanz agieren zu können, sind etwa drei bis sieben Berechtigte sinnvoll. Theoretisch wäre eine ungerade Zahl von mindestens drei für eine Entscheidung zu fordern; weil jedoch wegen Urlaub oder Krankheit immer jemand vorübergehend inaktiv oder nicht erreichbar sein kann, ist nicht einmal eine ungerade Anzahl vorhersagbar.

--PerfektesChaos 14:53, 12. Feb. 2023 (CET)[Beantworten]

Was die Möglichkeiten und Grenzen einer CU-Abfrage angeht bestätige ich die Einschätzung. Deshalb sollten die Bürokraten in diesem Punkt Entscheidungsspielraum haben. -- Perrak (Disk) 19:27, 12. Feb. 2023 (CET)[Beantworten]

Oversighter

Bearbeiten

Checkuser

Bearbeiten
  • Die Maximalzahl von nur 5 CUlern sollte erhöht werden. Dann könnte man erfahrenen Vandalenjägern und Filterexperten wichtige IPs mitteilen, insbesondere Seewolf und Johannnes89 könnten damit viel anfangen. Außerdem wäre dann bischen mehr Luft wenn mal jemand zurücktritt oder inaktiv ist.
Die beiden Regeln der de-WP ermöglichen de facto einigen Vandalismus oder verhindern zumindest eine Bekämpfung. Da manch einer Bedenken hat, könnte man die beiden Regeln auch nur bzgl. Benutzern aufrecht erhalten die keine Stimmberechtigung haben (oder keine aktiven Sichter sind). Das wäre vollkommen ausreichend.
--Der-Wir-Ing ("DWI") (Diskussion) 20:22, 5. Feb. 2023 (CET)[Beantworten]
Die CU-Regeln sind bereits äußerst knapp am datenschutzrechtlich Notwendigen. Eine weitere Liberalisierung wäre nicht tragbar. Insbesondere werden nicht mehr CU-Beauftragte benötigt. --Mautpreller (Diskussion) 21:42, 5. Feb. 2023 (CET)[Beantworten]
Und darum dauern CU-Abfragen zum Teil Monate? --Marcus Cyron Stand with Ukraine and Iran! 22:41, 5. Feb. 2023 (CET)[Beantworten]
Dass die jetzigen CU-Regeln bestimmten Vandalismus ermöglichen bzw. bestimmter Vandalismus durch unser Regelwerk nicht effektiv verhindert werden kann, ist leider ein Fakt. Mit Datenschutz hat das, abgesehen von dem Thema Mindestzahl, tatsächlich nichts zu tun, sondern mit Prozess- und Governance-Fragen. Und bei dem Hinweis, dass z.B. 7 CUs besser als 5 wären, direkt davon zu reden, eine Liberalisierung sei „nicht tragbar“, ist mindestens arg übertrieben. - Squasher (Diskussion) 22:45, 5. Feb. 2023 (CET)[Beantworten]
CU-Regeln "ermöglichen" weder Vandalismus noch können sie ihn "verhindern". Das ist eine Illusion, die derzeit leider als Fakt verkauft wird. Dass, wer den Datenschutzeingriff vollzieht, nicht selbst sperren darf, ist sehr wohl datenschutzrechtlich höchst relevant.--Mautpreller (Diskussion) 22:49, 5. Feb. 2023 (CET)[Beantworten]
Für dich persönlich mag das höchst relevant sein, im Allgemeinen ist das aber eine schlichte Prozessfrage, die die Community für sich klären muss. Es gibt Konstellationen, in denen wir eine auch dann eine Prozesslücke haben, wenn ein einzelner User ohne jedes Admin- und CU-Recht dies kategorisch abstreitet, und die geschlossen werden könnte, sofern die Community das für in Ordnung befindet. Bei diesem Prozess würde der selbe Umfang an Datenschutzeingriffen stattfinden wie sonst auch. - Squasher (Diskussion) 23:00, 5. Feb. 2023 (CET)[Beantworten]
"Prozesslücke", sehr schön. So kann mans auch ausdrücken, dass man gern mehr Sonderrechte haben möchte. Der Benutzer ohne jedes Admin- und CU-Recht wird es sich für die nächsten CU-Wahlen merken.--Mautpreller (Diskussion) 23:06, 5. Feb. 2023 (CET)[Beantworten]
Aha. Gibst du mir dann wieder wie bei der Wahl im letzten September ein Kontra? Das ist eine für dich sehr untypische, weil ziemliche unsouveräne Reaktion. Meinen Seitenhieb habe ich deshalb eingebaut, um zu verdeutlichen, aus welcher Perspektive du deine als Tatsache verpackte Meinung abgibst, aus der es meiner Meinung nach sehr bequem ist zu behaupten, es gäbe ja gar kein Problem - man hat es ja nicht. Du redest oben gegen eine Liberalisierung an, die bei dem in Rede stehenden Problem - Thema Mindestanzahl ausgeklammert - gar keine Rolle spielt. Und statt darauf einzugehen baust du den Strohmann „Sonderrechte“ auf. Welche Sonderrechte sollen das bei einem Admin, der heute schon sperren kann, und einem CU, der heute schon Datenschutzeingriffe tätigen kann, denn sein? Alle betroffenen Rechte hat jeder aktuelle CU'ler doch schon. Man traut jedem Admin zu, einen eindeutigen Vandalen auch ohne VM sofort zu sperren. Man traut jedem CU zu, seine Arbeit regelkonform zu verrichten und vor allem absolut eindeutige Fälle zu erkennen. Man vertraut dem CU, der auch regulärer Admin ist, aber nicht soweit, diesen Vandalen selbst zu sperren, er muss dafür zwingend jemand anderen darüber informieren - sofern das im Falle von IP-Vandalismus überhaupt zulässig ist. Und da reden wir noch gar nicht über auch nur leicht strittige Fälle, bei denen ein 4-Augen-Prinzip schon sinnvoll ist. Ist das wirklich eine sinnvolle Regelung? Und nirgends in dieser Fragestellung würden Datenschutzfragen berührt, die nicht ohnehin schon durch die CU-Abfrage berührt sind. Es ist m.E. eine reine Prozessfrage. - Squasher (Diskussion) 23:40, 5. Feb. 2023 (CET)[Beantworten]
Zur Eingangsfrage: Ja. Zur Schlussfrage: Ebenfalls ja. Das ist eine sinnvolle Regelung, die dem Missbrauch bei sensiblen Datenschutzfragen vorbaut.--Mautpreller (Diskussion) 23:42, 5. Feb. 2023 (CET)[Beantworten]
Ich werde damit wie in der Vergangenheit wohl gut klar kommen. Welcher vermeintliche Missbrauch soll das sein? Konkretes Beispiel bitte. - Squasher (Diskussion) 23:44, 5. Feb. 2023 (CET)[Beantworten]
Ich bezog mich auf den letzten Absatz in der Vorstellung der Umfrage ("Die beiden lokalen Regeln zum CU ..."). Hier werden sehr wohl weitreichende Vorschläge zur Liberalisierung der CU-Praxis gemacht, die ich aus Datenschutzerwägungen strikt ablehne. Der mögliche Missbrauch liegt auf der Hand. Es besteht die Gefahr, dass Datenschutzeingriffe ohne Not und ausreichende Rechtfertigung vorgenommen werden, um eine Sperrung zu erreichen, die man dann ohne weitere Kontrolle selbst vollziehen kann. Die Zahl der CU ist nicht mein Hauptargument. --Mautpreller (Diskussion) 23:52, 5. Feb. 2023 (CET)[Beantworten]
Dann reden wir ja schonmal vom selben Thema, gut. Dass die Möglichkeit allein, einen Benutzer selbst sperren zu können, sofern eine Abfrage ein dies zu rechtfertigendes Ergebnis liefern würde, eine Motivation dazu sein könnte, bei der Abwägung, ob eine Abfrage erfolgen sollte oder nicht, sich eher für eine Abfrage entscheiden zu können, macht für sich ja keinen Sinn, da dürften wir uns einig sein. Es wäre ja einerlei, ob der CU selbst sperrte oder ein von ihm informierter zweiter Admin oder CU mit Adminrechten. Wo ich nicht bei dir bin ist die Stelle, an der eine Sperre ohne Kontrolle machbar wäre; eine Prämisse in deinem obigen Beispiel. Die Sperre fände aber doch wie jede andere Sperre heute auch statt. Ich kann morgen früh um 9 Uhr ins RC gehen und unter Ausblendung von WP:VM eine Stunde lang jeden Schülervandalen sofort sperren - deswegen wird niemand auf meiner Disk aufschlagen und sich beschweren. Und dennoch sieht jeder im Benutzersperrlogbuch die Sperren, offen verewigt, von jedem einsehbar, der sich die Mühe macht. Sie wäre nur nicht separat auf einer Funktionsseite dokumentiert weil, genau, Datenschutz. Als CU kann man ja gerade nicht irgendwo dokumentieren, man habe die folgenden IPs oder Ranges im Zusammenhang mit einem bestimmten Dauervandalen gesperrt. Dein Beispiel ist zwar nun konkret - dafür danke - aber eben auch der worst case mit einem meiner Meinung nach klaren Haken: das könnte jeder aktuelle CU'ler - ausreichend ABF vorausgesetzt - heute schon so machen. Ohne genaue Abwägung abfragen, weil man die Sperre ja erreichen will, in der CU vermelden, dass das alles nicht so koscher aussieht und die Sperre des Accounts dem abarbeitenden Admin überlassen. Nebenbei sperrt Admin, der man als CU'ler eben auch ist, zwei Tage später ein, zwei gefundene Ranges, auf denen der Account so unterwegs war und hofft die Logeinträge fallen niemandem auf und niemand aus der Range oder die betroffene Person selbst beschwert sich lauthals (wovon man aber in aller Regel ausgehen kann). Es wäre sicher ein größeres Missbrauchspotential gegeben, wenn die heutigen CUler keine Adminrechte hätten. So aber sehe ich dieses Potential nicht, weil der unterstellte worst case bereits machbar ist. Es ist m.E. letztlich unmöglich, wirklich ohne Kontrolle jemanden zu sperren. Und ohne diese Prämisse landen wir bei meinem zweiten und dritten Satz dieses Postings. - Squasher (Diskussion) 00:29, 6. Feb. 2023 (CET)[Beantworten]
Doch, die Möglichkeit, selbst zu sperren, kann die Entscheidung für eine Abfrage beeinflussen. Da ohnehin eine Tendenz besteht, zu viele Abfragen vorzunehmen, finde ich das keineswegs fernliegend. --Mautpreller (Diskussion) 00:42, 6. Feb. 2023 (CET)[Beantworten]
Im worst case mit unterstelltem voll-ABF, der wie oben beschrieben heute schon genau so möglich ist. Der Punkt wird durch Wiederholung nicht valider. - Squasher (Diskussion) 11:51, 6. Feb. 2023 (CET)[Beantworten]
In diesem Abschnitt ack zu Squasher. -jkb- 23:55, 5. Feb. 2023 (CET)[Beantworten]
  • Der Grat zwischen dem Minimum für Arbeitsfähigkeit (3 CUler) und dem Maximum der Amtsträger (5 CUler) ist zu schmal. Da nach unten hin gerade durch fehlende Schiedsgerichts-Kontrolle ein Aufheben des Limits keine Option ist, bleibt zur Lösung nur eine Erhöhung der "5". ~ ToBeFree (Diskussion) 01:46, 6. Feb. 2023 (CET)[Beantworten]
  • Die Funktion ist so wichtig, dass es nicht zuviele Checkuser geben kann. Viele Grüße, Aschmidt (Diskussion) 07:31, 6. Feb. 2023 (CET)[Beantworten]
  • Vor einigen Monaten wurde irgendwo (auf der WikiCon?) mal die Idee geäußert, eine kleine Zahl „passiver“ Checkuser zu wählen, die die Gruppe der CUler erweitern. Diese dürften ihre Rechte nicht aktiv nutzen (also keine Daten selbst abfragen, was sich per CU-Log kontrollieren lässt), aber könnten nach CU-Abfragen der fünf normalen CUler eventuelle nicht-öffentliche CU-Ergebnisse als Admins verwerten (z.B. IP-Adressen/-Ranges von global/lokal ausgeschlossenen Nutzern sperren). Muss aber nicht sein, wenn man klarstellt, dass auch an einer Anfrage unbeteiligte CUler als „unbeteiligte Administratoren“ im Sinne von WP:CU#Richtlinien gelten. --Johannnes89 (Diskussion) 13:03, 6. Feb. 2023 (CET)[Beantworten]
    Finde ich gar nicht so schlecht. Es wären dann zwei Leute beteiligt, die voneinander unabhängig sind. Und wer selbst prinzipiell keine Daten abfragt, aber die Verpflichtungserklärung unterschrieben hat, wäre sicher als unabhängig zu werten. --Mautpreller (Diskussion) 13:17, 6. Feb. 2023 (CET)[Beantworten]
    Die Idee habe (unter anderem?) ich geäußert. --Sabrieleauftistik (Diskussion) 15:17, 6. Feb. 2023 (CET)[Beantworten]
    Ahh ja, danke für den Hinweis. Stellt sich die Frage, wie viele „passive CUler“ es bräuchte?
    Eine IP-(Range-)Sperre (z.B. um Avoided abzuhalten, wenn er mal wieder im Minutentakt das Neuanmeldugslog mit Nazikram flutet) ist prinzipiell schnell gesetzt, gleichzeitig ist ein einzelner passiver CUler ja auch nicht ständig online. Auf der anderen Seite sollte der Kreis der CUler aus gutem Grund klein bleiben, selbst wenn die passiven CUler nicht selbst abfragen dürfen, sondern „nur“ Zugang zu nicht-öffentlichen CU-Ergebnissen erhalten.
    Wären 3-5 „passive“ CUler analog zur Zahl der normalen CUler zu viel? --Johannnes89 (Diskussion) 19:04, 6. Feb. 2023 (CET)[Beantworten]
    Inwiefern würde ein "passiver CUler" bei Avoided helfen? Der müsste ja erstmal (aktiv) die IPs ermitteln und könnte erst dann sperren. Man müsste also erstmal aufwendig eine CUA-Seite anlegen, warten bis das jemand sieht und abarbeitet, die IP zurückmeldet und könnte dann erst sperren. Bis dahin hat avoided schon 100 konten angelegt: Viel spaß beim sperren. Als "passive CUler" machen überhaupt nur wenige Leute sinn, nämlich solche die häufig mit Dauervandalen und Sperrumgehern zu tun haben: Itti, Seewolf, Johannnes89 und paar weitere. Denen könnte ich verraten welche IPs Avoided das letzte mal genutzt hat und dann könnten sie die auf gut Glück sperren wenn er das nächste mal kommt. --Der-Wir-Ing ("DWI") (Diskussion) 19:13, 6. Feb. 2023 (CET)[Beantworten]
    Ja genau, so ist es. Das ist genau der Sinn der Sache: CU soll nur auf Antrag tätig werden und wer den Datenschutzeingriff vollzieht, sperrt nicht selbst. Ich bin mir ziemlich sicher, dass auf diese Weise viel bedrohlichere Pannen verhindert werden. "Auf gut Glück sperren" ist grad das, was wir eher nicht brauchen. --Mautpreller (Diskussion) 20:13, 6. Feb. 2023 (CET)[Beantworten]
  • Gegen eine – moderate – Erhöhung der Zahl von CUn spricht aus meiner Sicht nichts, höchstens, dass sich nicht so viele dazu fähige, bereite und das Vertrauen genießende Nutzer finden. Mit „moderat“ meine ich „bis zu insgesamt 9“, was ja fast eine Verdoppelung bedeutete. --Wwwurm Paroles, paroles 15:13, 6. Feb. 2023 (CET)[Beantworten]
  • Ich bin strikt gegen Ermittler, Richter und Henker in einer Person, also sperrende CheckUser-Berechtigte, die das dann (zum Teil zwangsläufig) auch noch nichtöffentlich machen. Für ebenso problematisch halte ich die Vergabe von CU-Rechten an Vandalenjäger, vor allem, wenn sie als Administratoren private Filter schalten dürfen. Ob wir generell mehr CUler brauchen, weiß ich nicht. Vorschläge für die Ermöglichung CU-basierter IP-Sperrungen bei gleichzeitiger Beibehaltung des Vier-Augen-Prinzips sind auf dem Tisch. Ich glaube allerdings nicht, dass dieser Problembereich irgendeine Relevanz für die Frage hat, wie viele CU-Kandidaturen wir haben (oder nicht haben). --Sabrieleauftistik (Diskussion) 15:17, 6. Feb. 2023 (CET)[Beantworten]
    Bist du sicher, dass „Schnüffler“ der richtige Begriff für eine sachliche Debatte ist? - Squasher (Diskussion) 16:02, 6. Feb. 2023 (CET)[Beantworten]
    Ich hab’s auf „Ermittler“ geändert. --Sabrieleauftistik (Diskussion) 16:21, 6. Feb. 2023 (CET)[Beantworten]
    Viele Admins gehen jetzt schon die jüngsten Änderungen durch, finden Vandalen und sperren sie (ohne VM). Die sind also jetzt schon "Ermittler, Richter und Henker in einer Person" Nur mal so angemerkt. --Der-Wir-Ing ("DWI") (Diskussion) 19:16, 6. Feb. 2023 (CET)[Beantworten]
    Das ist auch nicht unproblematisch, aber wenigstens noch halbwegs öffentlich. Auf allen Seiten werden Abstriche nötig sein (Kompromiss). Wegen der Datenschutzhürden wird man sich beim CU immer darauf verlassen müssen, dass die notwendige Kontrolle der Ergebnisse und ihrer Interpretationen gewissenhaft durch andere CUler stattfindet, da sie nicht öffentlich sein dürfen. Ich fände es sinnvoll, wenn das obligatorisch vor der Sperrorgie stattfinden würde, nicht als wünschenswertes Extra hinterher. --Sabrieleauftistik (Diskussion) 22:17, 6. Feb. 2023 (CET)[Beantworten]
    Ach so, und noch was: Auch im „echten Leben“ hat die Polizei bei Gefahr im Verzug erweiterte Befugnisse. Während man bei laufendem Vandalismus noch „Gefahr im Verzug“ begründen kann, liegt das bei CU in aller Regel (Ausnahmen: Ankündigungen von Suizid, Terroranschlag etc., also Ermittlung von IPs für Strafverfolgungsbehörden oder andere Institutionen) nicht vor. --Sabrieleauftistik (Diskussion) 22:22, 6. Feb. 2023 (CET)[Beantworten]
    Wie du schon selber schreibst, nur "in der Regel". Ich hatte mehrere Fälle wo ich bei akutem Vandalismus der einzige war der technisch was machen konnte, aber wegen der Regeln nicht durfte. Sowas tut schon weh, aber wenn ihr das so wollt, OK. Wenn irgendein Spinner mit dutzenden Konten deinen Klarnamen überall verbreitet, könnte ich abfragen und die IPs sperren, dann ist schluss mit lustig. Derzeit muss ich tatenlos zusehen. (In dem Fall, dass Benutzersperren wirkungslos bleiben, weil der Vandale mit zahlreichen IPs und Konten arbeitet. Kam bereits vor, allerdings als stupider Vandalismus, nicht als Doxing.) --Der-Wir-Ing ("DWI") (Diskussion) 22:04, 7. Feb. 2023 (CET)[Beantworten]
    Ich finde es eigentlich widersinnig, dass CUler keine IP-Adressen rausgeben dürfen, weder im Normalfall (wo diese Einschränkung aus Datenschutzgründen noch ziemlich verständlich ist) noch im geschilderten Doxing-Fall (wo es sich effektiv um Täterschutz handelt, wenn der Täter dann ungestraft selbst gegen den Datenschutz verstoßen darf). Mein Vorschlag zur Lösung oder Linderung des Problems war ja Zwei-Augen-Prinzip bei den CUlern (am besten zwischen zwei getrennten Gruppen). Darüber hinaus hätte ich auch kein grundsätzliches Problem damit, wenn ein CUler im Notfall („Gefahr im Verzug“) selbst sperren darf, nur müsste es für so einen Fall dann ein klares Prozedere geben, dass diese Sperren hinterher noch einmal überprüft werden. Zum Normalfall sollte das keinesfalls werden. --Sabrieleauftistik (Diskussion) 10:25, 8. Feb. 2023 (CET)[Beantworten]
  • Eine Erhöhung der Maximalzahl erscheint mir sinnvoll, aktuell ist der Grat zwischen Minimum und Maximum recht schmal. --Ameisenigel (Diskussion) 17:38, 6. Feb. 2023 (CET)[Beantworten]
  • Anstelle von Erhöhung erscheint es mir sinnvoll, den CUler das Recht zum Sperren zu geben. Aber ob das Mehrheitsfähig per MB ist, keine Ahnung. --ɱ 20:44, 6. Feb. 2023 (CET)[Beantworten]
  • Eine Erhöhung auf z.B. 7 ist kein Problem. Zum Thema Aufgabentrennung: Als Befürworter der "Gewaltentrennung" bin ich dagegen dass CUB auch vollziehen dürfen. Problem ist die fehlende Kontrolle, da alles im Verborgenen läuft (bei den Admins hingegen ist alles transparent -> gibt's halt AWW-Stimmen oder ein AP). Eine zweite Gruppe ("CU-Exekutoren"), die mit dieser Aufgabe betraut wäre, wäre daher sicher sinnvoll. --Filzstift (Diskussion) 23:05, 6. Feb. 2023 (CET)[Beantworten]
    Zur Kontrolle siehe oben. Was unterscheidet eine nicht öffentlich dokumentierte Sperre einer sockenspielenden IP durch einen CU'ler von einer nicht öffentlich dokumentierten Sperre einer Schülervandalen-IP (ohne VM!) durch einen Admin? Beides erzeugt einen Eintrag im Sperrlogbuch, ersteres ist aktuell nicht erlaubt, letzteres passierte heute schon täglich. - Squasher (Diskussion) 23:16, 6. Feb. 2023 (CET)[Beantworten]
    Die Sperrbegründung „Vandalismus“ lässt sich recht einfach über die Beitragsliste nachvollziehen, „Sockenspielen“ eher nicht. -- hgzh 07:42, 7. Feb. 2023 (CET)[Beantworten]
    Und dennoch fändest du beides im Sperrlogbuch. Soviel zum „Verborgenen“. - Squasher (Diskussion) 09:05, 7. Feb. 2023 (CET)[Beantworten]
    Das war nicht meine Wortwahl. Und natürlich ist die Sperre selbst im Log nachvollziehbar, nur die Begründung dann nicht mehr. -- hgzh 15:08, 7. Feb. 2023 (CET)[Beantworten]
  • Eine Erhöhung auf sieben könnte man machen, ist in meinen Augen aber nicht unbedingt notwendig. Bisher schaffen wir das Pensum ganz gut. Damit die Mindestzahl nicht unterschritten wird, wäre eventuell eine Nachrückerregelung sinnvoll. -- Perrak (Disk) 10:00, 7. Feb. 2023 (CET)[Beantworten]
  • Erhöhung wäre okay. Aber auch hier sollte der WW-Seitenschutz entfallen.--Altaripensis (Diskussion) 12:34, 7. Feb. 2023 (CET)[Beantworten]
  • Eine Erhöhung wäre kein Fehler, der Grat zwischen drei und fünf ist sehr schmal und wir hatten es schon öfter, dass Funktionsträger lange Zeit weg waren. Ob man mehr Leute finden wird können, ist eine andere Frage. Was ich aber schon noch schreiben möchte: Man sollte sich ernsthaft überlegen, wie man das Instrumentarium und das Regularium in Zukunft anwenden möchte. Dass ein CU-Berechtigter im hellen Graubereich von dem allen zwar eine Abfrage machen kann, aber weder sagen kann, was nun ist, noch Umsetzungsaufträge geben kann, noch selbst was administrieren darf, ist eine Komödie. … «« Man77 »» Alle Angaben ohne Gewehr. 17:13, 7. Feb. 2023 (CET)[Beantworten]
  • Moderate Erhöhung wäre ok. Viel sinnvoller wäre es mMn. aber, einfach ein paar Stellvertreter-CUs bei jeder Wahl zu wählen. Die bekommen die Rechte erstmal nicht, aber wenn ein CU während der Zeit zurücktritt, dann rückt automatisch ein Stellvertreter nach. --DaB. (Diskussion) 21:48, 7. Feb. 2023 (CET)[Beantworten]
  • Mehr wäre OK, insbesondere wäre dann auch die Möglichkeit, die z.B. in der nlWP umgesetzt wurde, einfacher: ein CU prüft, ein anderer sperrt IPs, denn diese Daten dürfen ja nicht an Leute weitergegeben werden, die keine Verschwiegenheitserklärung unterschrieben haben. Sprich: 2 Augenpaare schon, aber beide CU. Einfach allen (A) eine solche Erklärung abzuverlangen wäre zwar theoretisch auch möglich, aber imho nicht wünschenswert, das würde vermutlich die Zahl der Admins deutlich verkleinern, und davon haben wir eh schon zu wenige. Grüße vom Sänger ♫ (Reden) 11:11, 8. Feb. 2023 (CET)[Beantworten]
  • Mehraugenprizip und teilung von Prüfung und Maßnahmen (wie Sänger), dafür muss aber die Zahl nicht erhöht werden. Dann eher "vertetende CU" wählen, die die Funktion erhalten, wen ein amtierender CU mehr als 10 Tage MiA ist. diese vertredenen CU können z.B. auch Urlaubsvertretungen machen, so dass es max 5 amtierene CU und 5 stellvertreter gibt, die den "paierkram" bereits erledigt haben, aber die Knöpfe nciht besitzen.-- Leif Czerny 15:16, 11. Feb. 2023 (CET)[Beantworten]
  • Ein Weg als „passive CU“ wäre eine technische Vergabe an die Bürokraten, die dann (nur) im Beschwerdefall CU-Abfragen unabhängig überprüfen dürften, falls zurzeit nicht genügend „unbeteiligte“ aktiv sind. Für das Tagesgeschäft reicht das Quorum von drei als Minimum aus, die sich gegenseitig regelmäßig auf die Finger gucken sollen. Falls es zum Konflikt und Drama käme, könnten dann die Bürokraten als lokale „Ombudsleute“ agieren und technische CU-Rechte nutzen, ohne sie aktiv ausüben zu dürfen (so wie OS auch BOA sind, und SG auch A haben). Wäre an eine Klausel zu binden, etwa dass es nicht mehr unbeteiligte als beteiligte Standard-CU im Konfliktfall gäbe. Auch jeder passive Einblick in die CU-Aktivitäten wird wohl protokolliert; normalerweise sollten Bürokraten also niemals bei CU aufschlagen. Mit dieser Reserve an Kontrolle ist die Mindestanzahl „drei“ nicht mehr kritisch, weil diese drei die Überprüfung des einen aktiven CU in einer Angelegenheit sicherstellen sollen und nun ggf. durch die passiven Bürokraten verstärkt würden. Bedingt Unvereinbarkeit von B und CU. --PerfektesChaos 15:34, 12. Feb. 2023 (CET)[Beantworten]

Schiedsgericht

Bearbeiten
  • Das SG braucht keine CU-Rechte und sollte sie auch unter keinen Umständen haben.--Mautpreller (Diskussion) 22:20, 5. Feb. 2023 (CET)[Beantworten]
    Ich finde es traurig, dass das Schiedsgericht in der deutschsprachigen Wikipedia weniger Vertrauen genießt als Checkuser und Oversighter. Wenn dann tatsächlich mal Beschwerden aufkommen, landen diese nicht bei einer lokalen Instanz, sondern bei der globalen Ombudskommission. Daran wird sich vermutlich auch nichts ändern, wenn sich hauptsächlich Nicht-Administratoren für das SG-Amt bewerben und mangels damit verbundener Verantwortung durchgewunken werden. ~ ToBeFree (Diskussion) 01:38, 6. Feb. 2023 (CET)[Beantworten]
    Ist das ein Wunder, wenn sie meistens das tun, was die Admins wollen und SG-Anfragen, die den Admins nicht passen generell ablehnen? --Maxl (Diskussion) 12:54, 6. Feb. 2023 (CET)[Beantworten]
  • +1: das scheint mir auch so. --Holmium (d) 22:50, 5. Feb. 2023 (CET)[Beantworten]
  • bei genügend Transparenz könnte ich mich damit u. U. anfreunden, ist aber eher unwahrscheinlich. -jkb- 23:13, 5. Feb. 2023 (CET)[Beantworten]
    Transparenz erreicht man in der Regel nicht durch das Kleinhalten der Gruppe, die Aktionen überprüfen kann. ~ ToBeFree (Diskussion) 01:42, 6. Feb. 2023 (CET)[Beantworten]
  • Es gäbe keinen sachlichen Grund, SG-Admins CU-Rechte zu geben. Viele Grüße, Aschmidt (Diskussion) 07:24, 6. Feb. 2023 (CET)[Beantworten]
  • kann mir kein Szenario vorstellen, in dem das nötig wäre. Ist ja auch nicht so, als könnte man als SGler keinen CU-Antrag stellen, falls das nötig wäre. --Icodense 10:20, 6. Feb. 2023 (CET)[Beantworten]
    @Icodense99: "Durchsetzung von SG-Auflagen und Maßnahmen ist erschwert wenn diese mit Socken oder per IP umgangen werden. CUler dürfen teils aufgrund globaler Regeln entscheidungsrelevante Informationen nicht ans SG weitergeben, weil die SG-Mitglieder keine CU-Rechte haben. (Kommentar DWI: Kein theoretischer Fall. Kam schon mehrfach vor. Details können aufgrund der Verschwiegenheitserklärung nicht veröffentlicht werden.)" --Der-Wir-Ing ("DWI") (Diskussion) 22:22, 6. Feb. 2023 (CET)[Beantworten]
    Das ist aber eher ein Problem der CU-Policy, finde ich. Außerdem obliegt die Umsetzung von SG-Maßnahmen ja im Allgemeinen den Admins und nicht dem SG selbst. --Icodense 22:31, 6. Feb. 2023 (CET)[Beantworten]
    Naja, verursacht wird das Problem aus der Kombi von globaler CU-Policy und lokalen de-Regeln. Das SG beschließt dann (unabsichtlich) Regeln die mich vor die Wahl stellen: Gegen die globalen Regeln verstoßen oder einfach zusehen wie URVs von gebannten Benutzern eingestellt werden. --Der-Wir-Ing ("DWI") (Diskussion) 23:13, 6. Feb. 2023 (CET)[Beantworten]
  • Wie Icodense. --Maxl (Diskussion) 12:54, 6. Feb. 2023 (CET)[Beantworten]
  • Das SG braucht keine CU-Rechte und sollte sie auch unter keinen Umständen bekommen. Die Tränendrüsenquetsch-Erwiderung zu Mautpreller ganz zu Beginn dieses Abschnittes bitte ignorieren: Nicht jedes häufig vorgebrachte Argument ist auch ein gutes Argument. --Wwwurm Paroles, paroles 12:59, 6. Feb. 2023 (CET)[Beantworten]
  • Nö. Das ist keine Frage des Vertrauens. Zum einen sind Checkuser-Abfragen sind bedeutende juristische Eingriffe in den Datenschutz und sollten sehr restriktiv vergeben werden, zum anderen sehe ich die Notwendigkeit für CU-Rechte auch nicht. Warum und wozu sollte das SG Checkuser-Anfragen durchführen? --Kurator71 (D) 15:51, 6. Feb. 2023 (CET)[Beantworten]
  • Ich hatte bisher nicht den Eindruck, dass das SG CU-Rechte benötigt. Üblicherweise trifft das SG eine Entscheidung, die dann von anderen (Admins, CU) umgesetzt wird. --Ameisenigel (Diskussion) 17:40, 6. Feb. 2023 (CET)[Beantworten]
  • Ins SG möchte ich aus Gründen der Vielfalt auch Leute wählen können, denen ich die CU-Rechte nicht geben würde. Insofern solten SG-Mitglieder auch keine CU-Rechte haben, auch wenn es gelegentlich praktisch wäre. -- Perrak (Disk) 10:02, 7. Feb. 2023 (CET)[Beantworten]
  • Wie Perrak. Es ist gut, wenn die eine Institution die andere braucht.--Altaripensis (Diskussion) 12:42, 7. Feb. 2023 (CET)[Beantworten]
  • Punktuell wird es so sein, dass die CU-Policy eine ordentliche Beweisaufnahme beim SG verunmöglicht. Da sollte aber eher an der CU-Policy angesetzt werden, auch wenn ich nicht daran glaube, dass da was gemacht werden wird. Ansonsten wie Vorredner – checks and balances und so Zeug. … «« Man77 »» Alle Angaben ohne Gewehr. 17:04, 7. Feb. 2023 (CET)[Beantworten]
  • Das SG macht schon genug Mist – es braucht nicht auch noch in sensiblen Bereichen Unsinn zu stiften! --DaB. (Diskussion) 21:50, 7. Feb. 2023 (CET)[Beantworten]
  • Das SG braucht kein CU um zu funktionieren. LG Dwain 14:06, 10. Feb. 2023 (CET)[Beantworten]
  • SG sollte Clearing-Stelle mit CU und OS haben, auf der Anfragen - für SG CU und OS einsehbar - gestellt und beantwortet werden, sofern dies mit Rahmen der DSGVO möglich ist.-- Leif Czerny 15:17, 11. Feb. 2023 (CET)[Beantworten]
  • Das SG soll verzwickte Kommunikationsstörungen lösen und langjährige inhaltliche und persönliche Konflikte in alltäglich umsetzbare Lösungen überführen. Dazu können auch Auflagen und Benutzersperren gehören. Aber sie dürfen ihre Admin-Rechte nicht exekutiv außerhalb der SG-Projektseiten nutzen, sondern müssen begründete Sperrentscheidungen den Admins vortragen. Alle zehn mit dem CU-Datenschutzeingriff auszustatten ist uferlos und unkontrollierbar. Wir müssen nicht alles genauso machen wie die enWP es mit einer anderen Community und anderer Tradition handhabt. CU können vom SG angefragt werden, gemäß für alle anderen auch gültiger Regeln, und CU können offen eine softwaretechnische Einschätzung abgeben; ohnehin ist heutzutage der Wert von CU für intelligente Zweitaccounts gleich Null. OS können genauso eine Anfrage des SG offen beantworten („hat X eine Telefonnummer dorthingeschrieben?“), ohne dass sie diese Telefonnummer bekanntgeben müssten. --PerfektesChaos 15:45, 12. Feb. 2023 (CET)[Beantworten]

Nachrückerregel

Bearbeiten

(Ich weiß nicht, ob es noch geht, hier ein weiteres Thema einzutragen; allerdings ist die Durchführung von Umfragen wenig formalisiert, deshalb setze ich es mal ein. Falls nicht gewünscht, kann es auch wieder entfernt werden.)

Nicht immer ist die Kandidatenzahl gerade nur ausreichend. Manchmal erhalten bei turnusmäßigen Wahlen (OS, CU, SG) mehr Kandidaten die für das jeweilige Amt erforderlichen Stimmen, als Plätze zu vergeben sind. Wenn dann jemand aus dem Gremium ausscheidet, wird der freigewordene Platz nicht besetzt. Dem könnte durch eine Nachrückerregel vorgebeugt werden, d.h. wer das Quorum erreicht, aber weniger Stimmen bekommt als die zunächst Gewählten, steht auf einer Nachrückerliste und kommt dann zum Zuge, wenn ein Platz im entsprechenden Gremium frei wird.--Altaripensis (Diskussion) 13:21, 10. Feb. 2023 (CET)[Beantworten]

Nach meiner Vorstellung träte der Nachrücker in die Position des ausgeschiedenen Funktionsträgers ein und übernähme das Amt für den Rest der Wahlperiode, denn er hatte für genau die kandidiert. So wird es z.B. bei Betriebsräten praktiziert.--Altaripensis (Diskussion) 14:12, 10. Feb. 2023 (CET)[Beantworten]
Diese Regeländerung war mir noch nicht bekannt. Sie bezieht sich aber offenbar nicht auf Rücktritte. Zum andern: Bei SG-Wahlen erreichten durchaus schon mehr Kandidaten das Quorum, als Plätze zu vergeben waren.--Altaripensis (Diskussion) 10:41, 11. Feb. 2023 (CET)[Beantworten]
Ja es "erreichten durchaus schon mehr Kandidaten das Quorum, als Plätze zu vergeben waren." Das letzte mal war 2012. --Der-Wir-Ing ("DWI") (Diskussion) 11:15, 11. Feb. 2023 (CET)[Beantworten]
Bei dieser Wahl im November 2019 hätte der Kandidat "DWI", wenn auch knapp, die Nachrückerposition erreicht, bei dieser im November 2018 der Kandidat Lapp. --Altaripensis (Diskussion) 11:23, 11. Feb. 2023 (CET)[Beantworten]
Nagut, ich hatte mich auf die CU-Wahlen beschränkt. --Der-Wir-Ing ("DWI") (Diskussion) 11:31, 11. Feb. 2023 (CET)[Beantworten]
Ich schrieb "Bei SG-Wahlen..."--Altaripensis (Diskussion) 11:33, 11. Feb. 2023 (CET)[Beantworten]
Ich kann mir vorstellen, dass bei einer Nachrückerregel mehr Leute kandidieren. Oft stellen sich die bisherigen Amtsinhaber zur Wahl, die in der Regel deutlich bestätigt werden. Da ist eine zusätzliche Kandidatur für den virtuellen Papierkorb. Wenn die Chance besteht, beim Ausscheiden eines Funktionsträgers aufzurücken, überlegen es sich manche vielleicht. Die Idee mit dem Vize ist interessant, aber ich weiß nicht, ob sie Chancen hätte.--Altaripensis (Diskussion) 14:26, 11. Feb. 2023 (CET)[Beantworten]
Man müsste nur erlauben jederzeit kandidieren zu können, so wie derzeit für Admin und Bürokrat. Kann man bei OS und CU auch etablieren. Fürs SG ergeben gebündelte Wahlen nich irgendwie Sinn, weil die nur als Team arbeiten können. --Der-Wir-Ing ("DWI") (Diskussion) 14:34, 11. Feb. 2023 (CET)[Beantworten]
  • Keine "Nachrücker", aber Stellvertreter, die aktiviert werden können, wenn Aktive mehr als 10 Tage MIA sind. nur bis zur Rückkehr der gwähöten aktiven, nur innerhalb der Amtszeit, nur für CU und OS, nur soviele Stellvertreter wie aktive, nur mit denselben Voraussetzungen für die Wahl. Kann auh geplant als Urlaubsvertreung erfolgen.-- Leif Czerny 15:20, 11. Feb. 2023 (CET)[Beantworten]

Ablehnung der Umfrage

Bearbeiten

Kommentare

Bearbeiten

Bitte die Diskussionsseite benutzen.

Ergebnis

Bearbeiten

Die Umfrage wurde *nicht* abgelehnt. Grobe Teilauswertung:

Pro Kontra Ent Kommentar
2.1 #Allgemeine Anregungen nur eine (Wahlverfahren)
2.2 #Aufgabentrennung (Ämtertrennung) allgemein sehr differenzierte Meinungen, Sorge vor Superadmins. Vergabe von CU wohl rechtlich nicht sinnvoll, gerade in Kombination mit OS
2.3 #Mindestanzahl differenzierte Meinungen zu den verschiedenen Ämtern, tendentiell für Mindestzahlen
2.4 #Kommentare zu Bürokraten keine Abstimmung
2.4.1 #Bürokraten allgemein keine Abstimmung
2.4.2 #Erteilung von Bot-, Limit-Ausgenommener und Status als bestätigter Benutzer durch Admins 2 3
2.4.3 #Vergabe des Rechtes "Importeur" lokal durch Bürokraten 27 0 1
2.4.4 #Entzug von Adminrechten auch durch Bürokraten 35 0 0 Pro z.T. mit Hinweis darauf, dass das Amt Bürokrat:* dann getrennt erhalten bleiben sollte
2.4.5 #Abschaffung der Benutzer*innengruppe "Bürokrat" und Kopplung der entsprechenden Rechte an die Gruppe "Administrator" 5 18 0
2.4.6 #Abschaffung der Benutzer*innengruppe "Bürokrat", Übergabe der Aufgaben an die Stewards 0 5 0
2.4.7 #Alle Admins sollen auch Bürokrat sein 0 26 0 überschneidet sich in der Auswirkung mit 2.4.5.
2.4.8 #Wahlmodalitäten Bürokraten (Insb. 70 % Hürde) 10 für 70 %, 11 für weniger (meist 66,7%), 2 für 75%
2.4.9 #Schutz der Wiederwahl-Seite von Bürokraten 1 21 1 gegen Abschaffung des AWW-Schutzes, 21 dafür, davon 5 für gleichzeitige Aufhebung der 2-jährigen Amtszeit
2.4.10 #Bürokraten als Notariat konkreter Vorschlag der Ausweitung der Funktion, keine Abstimmung
2.5 #Oversighter 6 1 Abschaffung der Wiederwahlseitensperre (auch für CU)
2.6 #Checkuser [...] (ist mir persönlich zu unübersichtlich für eine Auswertung, kann gerne jd. anders übernehmen und dann diesen Satz entfernen) --Altaripensis (Diskussion) 10:13, 13. Mär. 2023 (CET)[Beantworten]
2.7 #Schiedsgericht 1* 15 CU-Rechte für das SG, Pro mit Vorbehalt

--Altaripensis (Diskussion) 10:13, 13. Mär. 2023 (CET) erg-- Leif Czerny 09:04, 14. Mär. 2023 (CET)[Beantworten]