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
BearbeitenWas ist BOSCU?
BearbeitenBOSCU 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
BearbeitenGemeinsame Regeln für den BOSCU-Bereich
BearbeitenFü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
BearbeitenEs 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
BearbeitenDerzeit (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
BearbeitenAchtung! 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.
Umfrage
BearbeitenAllgemeine Anregungen
BearbeitenHier 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)
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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- @Filzstift Welchen "Dienstweg" meinst du? --Der-Wir-Ing ("DWI") (Diskussion) 02:48, 8. Feb. 2023 (CET)
- @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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- @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)
- @Filzstift Welchen "Dienstweg" meinst du? --Der-Wir-Ing ("DWI") (Diskussion) 02:48, 8. Feb. 2023 (CET)
- Entschieden dagegen, das Verbot der Ämterhäufung aufzuheben.--Altaripensis (Diskussion) 12:25, 7. Feb. 2023 (CET)
- 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)
- 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)
- Ä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)
- 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)
- Wenn möglich sollten auch B und A unvereinbare Ämter werden.~~~ ---- Leif Czerny 15:26, 11. Feb. 2023 (CET)
- Tendiere sehr zu Mautprellers Ansicht. --Björn 18:15, 22. Feb. 2023 (CET)
Mindestanzahl
Bearbeiten- War so im Nachhinein nicht so sinnvoll das einzuführen. --Der-Wir-Ing ("DWI") (Diskussion) 21:26, 5. Feb. 2023 (CET)
- Nachtrag: Letztendlich geht es um die Frage "Wenn wir weniger als 3 B/CU/OS haben, sollen dann die Stewards die Aufgabe übernehmen?" und nicht um Machtmissbrauch und wechselseitige Kontrolle. Die S können auch jetzt schon alles prüfen. Und wenn ihr mich fragt, dann ist es mir einfach lieber, dass jemand der per Wahl ausdrücklich das Vertrauen der de-Community genießt diese Aufgaben übernimmt als jemand der nicht mal Deutsch kann und die Anfragen per google Translate übersetzen muss. (denn die deutschen Stewards werden da nicht aktiv) --Der-Wir-Ing ("DWI") (Diskussion) 23:37, 8. Feb. 2023 (CET)
- Hat schon seine Berechtigung, auch wenn es jetzt gerade mal unpraktisch ist. MBxd1 (Diskussion) 21:44, 5. Feb. 2023 (CET)
- Bei Bürokraten in der Tat nur mäßig erklärbar. Bei CU und OS notwendig, damit überhaupt eine lokale gegenseitige Kontrolle stattfinden kann. ~ ToBeFree (Diskussion) 01:04, 6. Feb. 2023 (CET)
- Prinzipiell halte ich eine Mindestzahl für sinnvoll. Hier aber weniger wegen der gegenseitigen Kontrolle als eher dafür, dass man einen Backup hat, falls mal eine/r ausfällt. Alex muc86 (Diskussion) 08:54, 6. Feb. 2023 (CET)
- Eine Mindestanzahl erscheint mir schon sinnvoll. Nur weil es uns jetzt auf die Füße gefallen ist, muss man das nicht gleich abschaffen. Stattdessen sollten wir für einen genügend großen Puffer sorgen. --Ameisenigel (Diskussion) 11:10, 6. Feb. 2023 (CET)
- Bei Mindestanzahlen von zwei oder drei sehe ich das Problem nicht. Ist die Community wirklich so klein und gleichzeitig so zerstritten, dass man niemanden für eine Zweit- oder Drittbesetzung findet? --Sabrieleauftistik (Diskussion) 15:03, 6. Feb. 2023 (CET)
- Beibehalten. Gerade CU braucht mindestens drei (schon 3 sind fast zu wenig, bei folgendem Szenario: Einer ist ständig inaktiv, einer ist dominant, einer ist ein "Mitläufer"). OS kann ich nicht beurteilen. --Filzstift (Diskussion) 17:04, 6. Feb. 2023 (CET)
- Beibehalten.--Altaripensis (Diskussion) 12:25, 7. Feb. 2023 (CET)
- Mindestzahl von eins ist selbsterklärend, Mindestzahl von zwei das Minimum um irgendeine gegenseitige Kontrolle zu haben, Mindestzahl von drei immer noch nicht übertrieben. Es ist immer wieder mal einer inaktiv, im Krankenhaus, verreist etc. Vielleicht sollte man definieren, was zu tun und was (nicht) erlaubt ist, wenn man unter die Mindestzahl rutscht. Das scheint ja zu fehlen. … «« Man77 »» Alle Angaben ohne Gewehr. 17:28, 7. Feb. 2023 (CET)
- Könnte man bei den Bürokraten wirklich abschaffen – bei allen anderen Ämtern aber nicht. --DaB. (Diskussion) 18:41, 7. Feb. 2023 (CET)
- Lupe (Diskussion) 20:42, 7. Feb. 2023 (CET) Ja Beibehalten. --
- Ich würde die Mindestanzahl in eine Richtschnur umwandeln: Wenn nur 2 Bürokraten existieren, dürfen sie bis zur Wahl eines dritten Bürokraten nur bestimmte Aktivitäten (z.B. den gewählten zum Bürokraten befördern (Bot-Rechte (wenn dies in Zukunft auch die Admins dürfen))) ausführen. Nach Abschluss der Wahl dürfen dann alte Anträge (/ Kandidaturen) abgearbeitet werden. LG Dwain 14:26, 10. Feb. 2023 (CET)
- Mindestzahl für B verschiedenen von der globalen Zahl ist unsinnig. Es sollte aber üblich sein, dass es mehr als die Mindestzahl aktiv im Amt ist, so dass ein Mehraugenprinzip möglich bleibt.-- Leif Czerny 14:49, 11. Feb. 2023 (CET)
Kommentare zu Bürokraten
BearbeitenBürokraten allgemein
BearbeitenErteilung 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)
- Dwain 13:39, 10. Feb. 2023 (CET) Pro Halte ich ebenfalls für sinnvoll. LG
- Ameisenigel (Diskussion) 22:23, 10. Feb. 2023 (CET) 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. --
- 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)
Vergabe des Rechtes "Importeur" lokal durch Bürokraten
Bearbeiten- Warum nicht. -- Chaddy · D 20:46, 5. Feb. 2023 (CET)
- Gute Idee. --Count Count (Diskussion) 21:11, 5. Feb. 2023 (CET)
- Ja. Aber nur, wenn es bei B als gesondert zu wählende Zusatzfunktion (wie bisher) bleibt. MBxd1 (Diskussion) 21:37, 5. Feb. 2023 (CET)
- es wurden afaics bisher keine nachteile dazu genannt. -- seth 21:57, 5. Feb. 2023 (CET)
- Ja. -- Marcus Cyron Stand with Ukraine and Iran! 22:37, 5. Feb. 2023 (CET)
- +1 -jkb- 22:45, 5. Feb. 2023 (CET)
- Klar. - Squasher (Diskussion) 22:49, 5. Feb. 2023 (CET)
- Ja. --Ghilt (Diskussion) 23:14, 5. Feb. 2023 (CET)
- +1 --ɱ 00:00, 6. Feb. 2023 (CET)
- Lutheraner (Diskussion) 00:39, 6. Feb. 2023 (CET) Pro --
- Morten Haan ⛄ Wikipedia ist für Leser da 00:39, 6. Feb. 2023 (CET)
- Die Berechtigung "Seiten über Hochladen von Dateien importieren (importupload)" bietet ein gar nicht so unerhebliches Missbrauchspotenzial. Sie ermöglicht es, beliebige gefälschte Bearbeitungen in den Versionsgeschichten jeder beliebigen Seite im Namen beliebiger Benutzer unterzubringen; das übliche "en>"-Präfix vor den importierten Benutzernamen ist rein optional. Nur, damit das mal erwähnt wurde. ~ ToBeFree (Diskussion) 01:11, 6. Feb. 2023 (CET)
- Habe nie verstanden, warum um die Funktion soviel Aufhebens gemacht wurde. Daher: +1. Viele Grüße, Aschmidt (Diskussion) 07:28, 6. Feb. 2023 (CET)
- kann man machen, teile aber die Ansicht von ToBeFree und halte das Importeursrecht für etwas, das großes Vertrauen in den jeweiligen Inhaber fordert. Ggf. sollten sich die Bürokraten dann einen gewissen formalen Prozess für neue Rechtevergaben überlegen (wie aktuell bei BOA schon). -- hgzh 09:14, 6. Feb. 2023 (CET)
- Das ist auch jetzt so, es wird ein "Antrag" gestellt, dann überlegt und danach wurde durch ein Steward umgesetzt. Zuletzt bei M.ottenbruch. Viele Grüüße --Itti 09:17, 6. Feb. 2023 (CET)
- Danke, das war mir so nicht bewusst. -- hgzh 14:59, 6. Feb. 2023 (CET)
- Das ist auch jetzt so, es wird ein "Antrag" gestellt, dann überlegt und danach wurde durch ein Steward umgesetzt. Zuletzt bei M.ottenbruch. Viele Grüüße --Itti 09:17, 6. Feb. 2023 (CET)
- --Icodense 10:15, 6. Feb. 2023 (CET) wie bei Entzug der Adminrechte.
- --Kurator71 (D) 14:30, 6. Feb. 2023 (CET) Ja!
- Ja. Warum genau dürfen die das bisher nicht? --Sabrieleauftistik (Diskussion) 15:04, 6. Feb. 2023 (CET)
- Ja. Grüße, --Snookerado (Diskussion) 15:43, 6. Feb. 2023 (CET)
- ja. --Alraunenstern۞ 16:13, 6. Feb. 2023 (CET)
- ja, aber nur, wenn nicht jeder A automatisch auch B wird (wer A sagt, muss nicht auch sagen). --Mogelzahn (Diskussion) 16:52, 6. Feb. 2023 (CET)
- OK --Filzstift (Diskussion) 17:06, 6. Feb. 2023 (CET)
- Ameisenigel (Diskussion) 17:29, 6. Feb. 2023 (CET) Pro Gefährlicher als BOA-Rechte sind Import-Rechte auch nicht. --
- Ja. --Holder (Diskussion) 17:39, 6. Feb. 2023 (CET)
- Warum nicht?--Altaripensis (Diskussion) 12:25, 7. Feb. 2023 (CET)
- Ja. --Brettchenweber (Diskussion) 15:01, 7. Feb. 2023 (CET)
- Dwain 13:47, 10. Feb. 2023 (CET) Pro LG
- Ja. Das Amt muss mit weiteren Aufgaben interessant und für die Community sichtbarer gemacht werden -- Leif Czerny 14:52, 11. Feb. 2023 (CET)
- Wenn die WMF mitspielt, gerne. Natürlich darf das Import-Recht nur an (untadelige) Admins vergeben werden, weil tatsächlich per XML ein Einspielen gefaketer Versionsgeschichten möglich wäre (allerdings rekonstuierbar). Ist aber kein Fall bekannt, und dass die WMF diesbezüglich die Zuverlässigkeit besser beurteilen könnte als Hiesige, erschließt sich mir nicht. Bedarf eines Community Consensus, und dieser Abschnitt hier mag als solcher bereits hinreichen. --PerfektesChaos 15:03, 12. Feb. 2023 (CET)
Entzug von Adminrechten auch durch Bürokraten
Bearbeiten- mMn eine gute Idee. --Der-Wir-Ing ("DWI") (Diskussion) 20:23, 5. Feb. 2023 (CET)
- Warum nicht -- Chaddy · D 20:46, 5. Feb. 2023 (CET)
- lange überfällig. Es macht keinen Sinn, damit die überarbeitenden Stewards zu belasten. --Count Count (Diskussion) 20:56, 5. Feb. 2023 (CET)
- Ja. Aber nur, wenn es bei B als gesondert zu wählende Zusatzfunktion (wie bisher) bleibt. MBxd1 (Diskussion) 21:37, 5. Feb. 2023 (CET)
- Ja. -- Marcus Cyron Stand with Ukraine and Iran! 22:38, 5. Feb. 2023 (CET)
- +1 -jkb- 22:45, 5. Feb. 2023 (CET)
- Klar. - Squasher (Diskussion) 22:49, 5. Feb. 2023 (CET)
- Ja. --Ghilt (Diskussion) 23:13, 5. Feb. 2023 (CET)
- +1 --ɱ 23:35, 5. Feb. 2023 (CET)
- Morten Haan ⛄ Wikipedia ist für Leser da 00:40, 6. Feb. 2023 (CET)
- Lutheraner (Diskussion) 00:40, 6. Feb. 2023 (CET) Pro wie oben MBxd1 --
- Ja, kann man machen. ~ ToBeFree (Diskussion) 01:20, 6. Feb. 2023 (CET)
- Das wäre ein Element von Selbstverwaltung des lokalen Projekts. Daher: +1. Viele Grüße, Aschmidt (Diskussion) 07:27, 6. Feb. 2023 (CET)
- Sinnvolle Idee. Und hier ja auch nicht ganz unwichtig: ich halte sie auch für Mehrheitsfähig. Alex muc86 (Diskussion) 08:52, 6. Feb. 2023 (CET)
- Ja, mit der Einschränkung von MBxd1 oben (nur als separate Benutzergruppe). -- hgzh 09:15, 6. Feb. 2023 (CET)
- Sinnvoll, unter der von MBxd1 genannten Bedingung. --Icodense 10:15, 6. Feb. 2023 (CET)
- ebenfalls wie MBxd1, dann sollten nicht alle A auch B sein (die Gruppe der B darf trotzdem gern größer sein als in den letzten Jahren) --Johannnes89 (Diskussion) 12:52, 6. Feb. 2023 (CET)
- ja, warum nicht. --Kurator71 (D) 14:30, 6. Feb. 2023 (CET)
- Ja. Warum genau müssen das bisher die Stewards machen? --Sabrieleauftistik (Diskussion) 15:05, 6. Feb. 2023 (CET)
- ja --Snookerado (Diskussion) 15:44, 6. Feb. 2023 (CET)
- ja. --Alraunenstern۞ 16:14, 6. Feb. 2023 (CET)
- Ameisenigel (Diskussion) 17:31, 6. Feb. 2023 (CET) Pro Habe ich auch schon mal irgendwo vorgeschlagen, ist in der Vergangenheit aber schon mal bei einem MB abgelehnt worden. --
- Ja. --Holder (Diskussion) 17:39, 6. Feb. 2023 (CET)
- Ja. --Louis ♫ Bafrance ☼ Schwätz halt mit m'r, wenn da ebbes saga witt 19:28, 6. Feb. 2023 (CET)
- Wenn wir gesonderte Bürokraten behalten, wäre das sinnvoll. -- Perrak (Disk) 09:56, 7. Feb. 2023 (CET)
- Wie der Vorredner. Ich sehe keinen sachlichen Grund, weshalb B's die Rechte zwar vergeben, aber - natürlich den Regularien gemäß - nicht auch sollen entziehen dürfen.--Altaripensis (Diskussion) 12:25, 7. Feb. 2023 (CET) PS: Dieses Beispiel zeigt erneut, wie sinnvoll das wäre.--Altaripensis (Diskussion) 16:05, 27. Feb. 2023 (CET)
- Ja. --Brettchenweber (Diskussion) 15:01, 7. Feb. 2023 (CET)
- Dafür, aber nur, wenn es bei B als gesondert zu wählende Zusatzfunktion bleibt. --Wwwurm Paroles, paroles 15:21, 7. Feb. 2023 (CET)
- Ich ärgere mich heute noch über die damalige Mehrheit, die diese Vereinfachung mit "Lösung sucht Problem" abgebügelt hat. … «« Man77 »» Alle Angaben ohne Gewehr. 17:15, 7. Feb. 2023 (CET)
- Dwain 13:42, 10. Feb. 2023 (CET) Pro Sehe ich genauso wie Count Count. LG
- Ja, bitte -- Leif Czerny 14:52, 11. Feb. 2023 (CET)
- Nur wenn nicht auch alle A gleichzeitig B-Rechte haben. Dann eine sinnvolle Komplettierung. Missbrauch durch B nicht zu befürchten, zumal per Mindestanzahl von drei B jederzeit unbefugtes Handeln rückgängig gemacht werden kann („wheel war“). --PerfektesChaos 15:08, 12. Feb. 2023 (CET)
- Der Bedingung würde ich ebenfalls zustimmen -- Leif Czerny 15:49, 13. Feb. 2023 (CET)
- KnightMove (Diskussion) 14:53, 17. Feb. 2023 (CET) Pro --
- Brettchenweber (Diskussion) 23:12, 20. Feb. 2023 (CET) Pro --
- Ra'ike Disk. P:MIN 18:09, 11. Mär. 2023 (CET) wie Count Count und Altaripensis Pro --
Abschaffung der Benutzer*innengruppe "Bürokrat" und Kopplung der entsprechenden Rechte an die Gruppe "Administrator"
Bearbeiten- Im Prinzip wie #Alle Admins sollen auch Bürokrat sein, bloß mit weniger Bürokratie (ja, ja, Wortspiel und so, ich weiß). -- Chaddy · D 20:45, 5. Feb. 2023 (CET)
- Nein. Die Admins verfügen bereits über zu viele Rechte. Wahlauswertungen sollten grundsätzlich von einer separaten kleinen Gruppe vorgenommen werden, sonst ist Willkür vorprogrammiert.--Mautpreller (Diskussion) 21:16, 5. Feb. 2023 (CET)
- Auf den ersten Blick sinnvoll, danach nicht mehr. Bei gekapertem Konto (z. B. eines kaum aktiven Admin, der die B-Rechte nebenbei noch bekommen hat) kann enormer Schaden angerichtet werden, da dann beliebige Accounts Admin-Rechte bekommen könnten. Zudem kollidiert das mit der unten vorgeschlagenen Ausdehnung der B-Befugnisse, da dann im schlimmsten Fall des gekaperten Kontos sogar sämtliche Admins (und wohl auch Bürokraten) entmachtet werden könnten. MBxd1 (Diskussion) 21:31, 5. Feb. 2023 (CET)
- Sowas ist nicht optimal und es kann großer Schaden angerichtet werden, das ist mir klar. Allerdings auch schon beim bisherigen Zuschnitt der Admin-Gruppe wäre eine Accountkaperung fatal. Und auch die Accounts von Bürokrat*innen können gekapert werden. Andererseits jedoch kann ein fälschlich getätigter Rechtevergabe/-entzug auch wieder rückgängig gemacht werden. -- Chaddy · D 21:49, 5. Feb. 2023 (CET)
- Für mich die sinnvollste Sache, die möglichen hier ins Spiel gebrachten Probleme halte ich für rein akademisch. -- Marcus Cyron Stand with Ukraine and Iran! 22:34, 5. Feb. 2023 (CET)
- Ameisenigel (Diskussion) 11:07, 6. Feb. 2023 (CET) Kontra Ich sehe keinen Bedarf für 180 Bürokraten, zumal so die ohnehin inaktiven Admins auch noch zusätzliche Rechte erhalten --
- Wwwurm Paroles, paroles 12:54, 6. Feb. 2023 (CET) Kontra Wie mein Vorschreiber. --
- Sabrieleauftistik (Diskussion) 14:57, 6. Feb. 2023 (CET) Kontra wie Mautpreller, während ich den Einwand von MBxd1 bei aller Wichtigkeit für entkräftbar halte. --
- Mogelzahn (Diskussion) 16:46, 6. Feb. 2023 (CET) Kontra wie meine Vorredner. --
- Filzstift (Diskussion) 17:02, 6. Feb. 2023 (CET) Kontra Missbrauchspotenzial gering (softwareseitig ein Limit einführen, so dass z.B. nur 5 A-Rechtevergabungen/Tag möglich sind). Dennoch Bauchweh aus anderen Gründen. --
- Holder (Diskussion) 17:39, 6. Feb. 2023 (CET) Kontra Würde die Hürde für eine erfolgreiche Adminwahl noch mehr erhöhen. --
- Yellowcard (D.) 18:11, 6. Feb. 2023 (CET) Pro In meinen Augen bietet der Vorschlag, die paar zusätzlichen technischen Rechte in die Admin-Benutzerrolle zu packen, zwei evidente Vorteile: 1. der Wegfall der Sperre der AWW-Seite bei den Bürokraten, während es sich bei den Bürokraten-WW logischerweise wenig um die Admintätigkeiten dreht; und 2. die Möglichkeit, dass ein A/B auch Zusatzfunktionen wie CU oder OS wahrnehmen könnte. (3. Verzicht auf die eher überflüssigen Bürokraten-Wiederwahlen finde ich eher von geringerem Gewicht). Die vorstehenden Gegenargumente kann ich ehrlich gesagt nur wenig verstehen: Das Orchester der A-Rechte und damit einhergehend das Missbrauchspotenzial ist groß. Integriert man in diese Rolle die paar technischen Zusatzaspekte der Bürokraten, ergibt das in meinen Augen keinen relevanten Unterschied. Dar Argument von Ameisenigel verstehe ich erst recht nicht – es gäbe dann ja keine 180 Bürokraten, sondern derer null, während sich die Rolle des Admins um wenige Aspekte erweitert, während ein paar mehr AWW-Seiten ungesperrt bleiben. Das reduziert doch gerade das inhaltliche Missbrauchspotenzial.
- Kurator71 (D) 18:57, 6. Feb. 2023 (CET) Pro Ja, ich würde aber keine automatischen Bürokratenrechte vergeben, sondern auf – Achtung Wortspiel – unbürokratischen Antrag auf AN, ähnlich wie bei den Importrechten. Spricht sich kein Admin gegen den Antrag aus, dann werden die rechte vergeben. --
- Altaripensis (Diskussion) 12:25, 7. Feb. 2023 (CET) Kontra, u.a. wie Ameisenigel.--
- Brettchenweber (Diskussion) 14:53, 7. Feb. 2023 (CET) Kontra Wie Ameisenigel. Zum Bürokratenstatus per Adminanfrage: Es käme vermutlich nicht gut an, wenn man den normalen Benutzern diesbezüglich das Wahlrecht entzöge, um es dann den Administratoren zu verleihen. Die zweijährige Sperre der AWW-Seite könnte m. E. aber entfallen. --
- Lutheraner (Diskussion) 15:30, 7. Feb. 2023 (CET) Kontra--
- DaB. (Diskussion) 18:38, 7. Feb. 2023 (CET) Kontra Das es in anderen WPs so gemacht wird, war schon immer ein Fehler. Die beiden Ämter sind aus guten Gründen getrennt. --
- ไม่เป็นไร (Valanagut) (Diskussion) 19:59, 7. Feb. 2023 (CET) Kontra Administratoren haben zu viele und nicht zu wenig Rechte.
- Lupe (Diskussion) 20:38, 7. Feb. 2023 (CET) Kontra wie Ameisenigel und Holder --
- Ralf Roletschek (Diskussion) 16:58, 8. Feb. 2023 (CET) Pro ist auf Wikiversity Standard und hat noch nie Probleme bereitet --
- Dwain 13:44, 10. Feb. 2023 (CET) Kontra Die beiden Ämter sind aus gutem Grund selbst bei Fandom getrennt (bis auf den „Gründer“ des jeweiligen Wikis, der ist beides) LG
- Nein. Einzelne Admins sind sicher sehr geeignet, die Gruppe als ganze aber nicht.-- Leif Czerny 14:53, 11. Feb. 2023 (CET)
- PerfektesChaos 15:14, 12. Feb. 2023 (CET)
- Ein hohes Quorum ist undemokratisch. Je höher das Qurum, desto leichter ist es für eine kleine Minderheit, die überwiegende Mehrheit zu blockieren. Ich finde 70 % schon deutlich zu viel, 75 % lehne ich strikt ab. -- Chaddy · D 15:30, 12. Feb. 2023 (CET)
Kontra Die technische Machtfülle sollte an einen kleinen „Senat“ vergeben werden, und für den wären 75 % als Hürde für mich angemessen. Die 150–200 Normal-Admins mögen in vielerlei Alltagsaufgaben tätig werden; die kritischen Power-Entscheidungen sollte ein deutlich kleineres Gremium entscheiden und umsetzen. -- - Ra'ike Disk. P:MIN 18:16, 11. Mär. 2023 (CET) wie DaB. Kontra --
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))
- 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)
- Finde ich keine gute Lösung. Wir haben die Möglichkeit, uns selbst zu verwalten, so prekär ist unsere Lage nicht. -- Chaddy · D 14:33, 17. Feb. 2023 (CET)
- Ameisenigel (Diskussion) 22:05, 20. Feb. 2023 (CET) Kontra Ich sehe keinen Grund, den Stewards zusätzliche Arbeit aufzudrücken. --
- Dwain 23:07, 20. Feb. 2023 (CET) KontraLG
- Ra'ike Disk. P:MIN 18:17, 11. Mär. 2023 (CET) Kontra Unser Projekt sollte unabhängiger und nicht abhängiger werden --
Alle Admins sollen auch Bürokrat sein
Bearbeiten- Nein, das sollte aus Gründen der Risikominimierung einer kleinen Gruppe vorbehalten sein, insbesondere falls Bürokraten künftig Admins entknopfen können. --Count Count (Diskussion) 20:59, 5. Feb. 2023 (CET)
- Siehe oben, letztlich nicht überzeugend. MBxd1 (Diskussion) 21:37, 5. Feb. 2023 (CET)
- Morten Haan ⛄ Wikipedia ist für Leser da 00:41, 6. Feb. 2023 (CET) Nein --
- Lutheraner (Diskussion) 00:43, 6. Feb. 2023 (CET) Nein Wie MBxd1 --
- Falk2 (Diskussion) 02:26, 6. Feb. 2023 (CET)
- Das mit dem "Wiki-Adel" ergibt doch überhaupt keinen Sinn. -- Chaddy · D 03:35, 6. Feb. 2023 (CET)
- Leider gibt das nur zu viel Sinn. Den Wiki-Adel gibt es doch leider schon mehr oder weniger, zumindest fühlt es sich so an als wenn sich manche dafür halten.--Maxl (Diskussion) 12:50, 6. Feb. 2023 (CET)
Nein, siehe oben, außerdem sehe ich einen Interessenkonflikt. Es darf nicht zur Entstehung eines Wiki-Adels kommen. – - Das mit dem "Wiki-Adel" ergibt doch überhaupt keinen Sinn. -- Chaddy · D 03:35, 6. Feb. 2023 (CET)
- Hat schon einmal jemand die derzeitigen Bürokraten gefragt, was sie davon halten? Viele Grüße, Aschmidt (Diskussion) 07:26, 6. Feb. 2023 (CET)
- Siehe Ittis Anmerkung auf der Diskussionsseite. Itti hält nichts davon.--Mautpreller (Diskussion) 10:07, 6. Feb. 2023 (CET)
- Aschmidt (Diskussion) 21:43, 6. Feb. 2023 (CET) Nein Dann würde ich dem folgen. --Viele Grüße,
- Siehe Ittis Anmerkung auf der Diskussionsseite. Itti hält nichts davon.--Mautpreller (Diskussion) 10:07, 6. Feb. 2023 (CET)
- Roland Kutzki (Diskussion) 12:43, 6. Feb. 2023 (CET) Nein --
- Maxl (Diskussion) 12:50, 6. Feb. 2023 (CET) NeinDas wäre für manche zu viel Macht. --
- Auch wenn ich gestern den "Advocatus diaboli" auf AN gespielt habe, ich halte das auch für keine gute Idee, eben auch aus Gründen der Risikominimierung. --Kurator71 (D) 14:32, 6. Feb. 2023 (CET)
- Sabrieleauftistik (Diskussion) 15:07, 6. Feb. 2023 (CET) Nein, siehe oben. --
- Alraunenstern۞ 16:14, 6. Feb. 2023 (CET) Nein --
- Mogelzahn (Diskussion) 16:56, 6. Feb. 2023 (CET) Nein, siehe oben. --
- Filzstift (Diskussion) 17:07, 6. Feb. 2023 (CET) Nein --
- #Abschaffung der Benutzer*innengruppe "Bürokrat" und Kopplung der entsprechenden Rechte an die Gruppe "Administrator" --Ameisenigel (Diskussion) 17:32, 6. Feb. 2023 (CET) Kontra Begründung analog zu
- Holder (Diskussion) 17:39, 6. Feb. 2023 (CET) Nein --
- Altaripensis (Diskussion) 12:25, 7. Feb. 2023 (CET) Nein --
- Brettchenweber (Diskussion) 15:01, 7. Feb. 2023 (CET) Nein, siehe oben. --
- Nicht alle. Die, die andere höhere Dienstposten haben, nicht – die Aufgabentrennung würde ich schon beibehalten. Die, die nicht wollen, auch nicht. Die, die nicht dazu gewählt worden sind, wohl auch nicht. Ich könnte mir aber schon vorstellen, dass bei zukünftigen Adminwahlen die Bürokratenknöpfe auf Wunsch des Kandidaten hin "mitgewählt" werden. Ich glaub dabei eigentlich nicht an den Dammbruch. … «« Man77 »» Alle Angaben ohne Gewehr. 17:19, 7. Feb. 2023 (CET)
- ไม่เป็นไร (Valanagut) (Diskussion) 20:10, 7. Feb. 2023 (CET) Nein Auf keinem Fall, und Bürokraten dürfen nett normale Admins sein.
- #Abschaffung der Benutzer*innengruppe "Bürokrat" und Kopplung der entsprechenden Rechte an die Gruppe "Administrator" --Lupe (Diskussion) 20:39, 7. Feb. 2023 (CET) Nein analog zu
- offensichtlich widersinnig. Wenn man das koppeln möchte, müsste der Vorschlag sein: „Bürokraten können auch Admins sein.“ --Fan-vom-Wiki (Diskussion) 02:28, 8. Feb. 2023 (CET)
- Dwain 13:45, 10. Feb. 2023 (CET) Kontra Um Gottes willen, nein! LG
- Nein. Mein Wunsch wäre es, dass Admins tatsächlich aktivere Rollen in der Community hätten und weniger technische Aufgaben.-- Leif Czerny 14:55, 11. Feb. 2023 (CET)
- PerfektesChaos 15:15, 12. Feb. 2023 (CET) Kontra Die technische Machtfülle sollte an einen kleinen „Senat“ vergeben werden, und für den wären 75 % als Hürde für mich angemessen. Die 150–200 Normal-Admins mögen in vielerlei Alltagsaufgaben tätig werden; die kritischen Power-Entscheidungen sollte ein deutlich kleineres Gremium entscheiden und umsetzen. --
- KnightMove (Diskussion) 10:33, 17. Feb. 2023 (CET) Kontra --
- Ra'ike Disk. P:MIN 18:20, 11. Mär. 2023 (CET) Kontra Wie zwei Abschnitte weiter oben. Ämtertrennung hat schon seinen Sinn --
Wahlmodalitäten Bürokraten (Insb. 70 % Hürde)
Bearbeiten- Die Hürde muss nicht so hoch sein, dazu sind diese Knöpfe viel zu unbedeutend/unkritisch. -- Chaddy · D 20:48, 5. Feb. 2023 (CET)
- Die Hürde sollte mindestens so hoch sein wie bei Admins, da sie erweiterte Rechte vergeben können. Außerdem sollten Bürokratenrechte Adminrechte umfassen. Es macht keinen Sinn, jemand nur zum Bürokraten zu wählen. --Count Count (Diskussion) 21:10, 5. Feb. 2023 (CET)
- Wenn die Zusatzrechte hinzukommen, sollte man am Wahlmodus nicht rütteln. 70% waren für die Kandidaten kaum mal eine echte Hürde. MBxd1 (Diskussion) 21:39, 5. Feb. 2023 (CET)
- Hürden sind eh schon zu hoch, eine Gegenstimme hat bei einer 2/3-Wahl schon immer den doppelten Wert einer Prostimme. Das es das noch höher gibt ist absurd. Persönliche Eitelkeiten haben schon so manchen guten Kandidaten/gute Kandidatin scheitern lassen. -- Marcus Cyron Stand with Ukraine and Iran! 22:39, 5. Feb. 2023 (CET)
- Keine Änderung - wie Wie MBxd1 --Lutheraner (Diskussion) 00:44, 6. Feb. 2023 (CET)
- Welche Bürokratenkandidatur ist denn bisher mit 66 bis 70 Prozent Zustimmung gescheitert? Kann ja sein, dass es welche gibt. Falls nicht, ist es offenbar egal. ~ ToBeFree (Diskussion) 01:28, 6. Feb. 2023 (CET)
- Eine Anpassung an die Regeln für Admin-Wahlen würde ich befürworten. Viele Grüße, Aschmidt (Diskussion) 07:25, 6. Feb. 2023 (CET)
- sehe keinen Änderungsbedarf. -- hgzh 09:16, 6. Feb. 2023 (CET)
- Lösung sucht Problem. Marginal höhere Anforderungen als für Admin passen dafür doch genau. --Icodense 10:24, 6. Feb. 2023 (CET)
- wie bei Admins --Roland Kutzki (Diskussion) 12:49, 6. Feb. 2023 (CET)
- Die Admin-Hürde reicht, wobei ich das nicht für ein großes Problem halte. Die Mehrheit der Kandidaten schafft die 70 % auch gut. --Kurator71 (D) 14:33, 6. Feb. 2023 (CET)
- sicherlich keine Reform, die zwingend notwendig wäre. Falls aus der Umfrage aber ein größeres Bürokraten-Reform-MB entstehen sollte, kann man über den Punkt ruhig auch abstimmen lassen; die Zwei-Dritte-Mehrheit ist ausreichend. Grüße, --Snookerado (Diskussion) 15:45, 6. Feb. 2023 (CET)
- Zwei-Drittel-Mehrheit halte ich für ausreichend hoch. --Alraunenstern۞ 16:16, 6. Feb. 2023 (CET)
- Ob 2/3 oder 70 % ist mir egal. --Mogelzahn (Diskussion) 16:58, 6. Feb. 2023 (CET)
- Wie AK: Keine tiefere Hürde als AK, denn es sind die Bürokraten, die Personen zu Admins machen. --Filzstift (Diskussion) 17:07, 6. Feb. 2023 (CET)
- Ich sehe hier keinen Änderungsbedarf --Ameisenigel (Diskussion) 17:33, 6. Feb. 2023 (CET)
- Kein Änderungsbedarf ersichtlich. --Holder (Diskussion) 17:39, 6. Feb. 2023 (CET)
- 70 % ist in Ordnung. --Ghilt (Diskussion) 22:52, 6. Feb. 2023 (CET)
- 70 % ist in Ordnung. --Altaripensis (Diskussion) 12:25, 7. Feb. 2023 (CET)
- 70 % sind ziemlich aus der Luft gegriffen; auch unsere staatliche Verfassung kennt stattdessen 66,7 oder 75 % – und eins dieser beiden Quoren sollte es sein. --Wwwurm Paroles, paroles 15:24, 7. Feb. 2023 (CET)
- 70% ist in Ordnung, meinetwegen auch 65% LG Dwain 13:48, 10. Feb. 2023 (CET)
- 70% ist Quatsch. Schon 2/3 der Abstimmenden ist sehr stark. Wie wäre eine absolute Mehrheit der abgegebenen Stimmen mit einem Quorum von mindestens 144 abgegebenen Stimmen? Das würde Enthaltungen aufwerten und die Mindestzahl der absolut erforderlichen Prostimmen sogar erhöhen, aber so einen Unsinn wie die 70%-Hürde abschaffen. Zusätzlich sollte die Stimmberechtigung und die Wählbarkeit gemäß der SG-Stimmberechtigung eingeschränkt werden: Wikipedia:Meinungsbilder/Schiedsgericht_Oktober_2007 um B mehr Legitimität zu verleihen. Satt der 144 könnte man, wenn das technisch einfach ist, auch einen Prozentsatz der SG-Stimmberechtigten als Quorum setzten. -- Leif Czerny 15:08, 11. Feb. 2023 (CET)
- Ich wäre eher für 75 %, und eine Rückschau über vergangene Wahlergebnisse dürfte die weitaus überwiegend sogar überstiegen haben. Die Bürokraten haben auf zwei Jahre eine erheblich missbräuchlich einsetzbare Macht und müssen ggf. schwerwiegende Entscheidungen in Konflikten verantworten, und dafür sollten sie mit einem klaren Vertrauensvorschuss der Community ausgestattet sein. --PerfektesChaos 15:19, 12. Feb. 2023 (CET)
- Bin auch für 75%. Qualifizierte Mehrheiten entsprechen meist den natürlichen Brüchen 2/3 und 3/4. Es ist auch leichter zu merken. Wie wir an den aktuellen Bürokratenwahlen gesehen haben, ist dieses Quorum für gute Kandidaten leicht und deutlich zu überbieten - und so soll es auch sein. --KnightMove (Diskussion) 09:18, 23. Feb. 2023 (CET)
- In der englischen Wikipedia sind sie seit einigen Jahren nicht mehr in der Lage Bürokraten zu wählen. Grenze war dort 80 % und das problem war dass die unerfahrenen abgelehnt wurden, als zu unerfahren, während die erfahrenen abgelehnt wurden von einer 20 % Minderheit, gerade weil die Kandidaten aktiv waren, sprich die haben im Laufe der Jahre auch mal Sachen gemacht die bei paar Leuten nicht gut ankamen. Seither werden die en-Büros vom SG ernannt. --Der-Wir-Ing ("DWI") (Diskussion) 10:24, 23. Feb. 2023 (CET)
- Bei uns aber nicht. 75% hätte nur in zwei der letzten ca. 30 Wahlen einen Unterschied gemacht - und da ist es Ansichtssache, ob das Scheitern gut oder schlecht gewesen wäre. Die meisten Kandidaten kommen locker über 80% oder auch 90%. --KnightMove (Diskussion) 11:51, 23. Feb. 2023 (CET)
- Ein derart hohes Quorum ist undemokratisch, da es so kleinen Minderheiten ermöglicht, die Entscheidung einer deutlichen Mehrheit zu blockieren. Dass das in der Realität bei uns derzeit kein Problem ist macht die Sache trotzdem nicht besser. Außerdem ist die Hürde auch einfach so oder so absurd hoch. Was erhofft man sich denn aus einer so hohen Hürde, was man mit 66,67 % (was auch schon ein sehr hohes Quorum ist) nicht auch hätte? -- Chaddy · D 17:11, 23. Feb. 2023 (CET)
- Ich stimme diesbezüglich genau meinem Vorstimmer PerfektesChaos bezüglich "klarem Vertrauensvorschuss" zu. Ungeachtet dessen ist unsere Position hier klar in der Minderheit, also wozu lange diskutieren... --KnightMove (Diskussion) 17:24, 23. Feb. 2023 (CET)
- Um die Meinungen der anderen zu ändern. Ich halte auch 75% für zu eng, weil die Wahl dann mehr davon abhängig ist, wer abstimmt und wer nicht.-- Leif Czerny 12:09, 24. Feb. 2023 (CET)
- Ich stimme diesbezüglich genau meinem Vorstimmer PerfektesChaos bezüglich "klarem Vertrauensvorschuss" zu. Ungeachtet dessen ist unsere Position hier klar in der Minderheit, also wozu lange diskutieren... --KnightMove (Diskussion) 17:24, 23. Feb. 2023 (CET)
- Ein derart hohes Quorum ist undemokratisch, da es so kleinen Minderheiten ermöglicht, die Entscheidung einer deutlichen Mehrheit zu blockieren. Dass das in der Realität bei uns derzeit kein Problem ist macht die Sache trotzdem nicht besser. Außerdem ist die Hürde auch einfach so oder so absurd hoch. Was erhofft man sich denn aus einer so hohen Hürde, was man mit 66,67 % (was auch schon ein sehr hohes Quorum ist) nicht auch hätte? -- Chaddy · D 17:11, 23. Feb. 2023 (CET)
- Das SG der en:WP ist ohnehin ein problematischer Fall. Was die sich da einfallen lassen haben mit diesem Gremium wird sich mir nie erschließen. Etwas derart undemokratisches ... --Marcus Cyron Stand with Ukraine and Iran! 03:46, 8. Mär. 2023 (CET)
- Bei uns aber nicht. 75% hätte nur in zwei der letzten ca. 30 Wahlen einen Unterschied gemacht - und da ist es Ansichtssache, ob das Scheitern gut oder schlecht gewesen wäre. Die meisten Kandidaten kommen locker über 80% oder auch 90%. --KnightMove (Diskussion) 11:51, 23. Feb. 2023 (CET)
- In der englischen Wikipedia sind sie seit einigen Jahren nicht mehr in der Lage Bürokraten zu wählen. Grenze war dort 80 % und das problem war dass die unerfahrenen abgelehnt wurden, als zu unerfahren, während die erfahrenen abgelehnt wurden von einer 20 % Minderheit, gerade weil die Kandidaten aktiv waren, sprich die haben im Laufe der Jahre auch mal Sachen gemacht die bei paar Leuten nicht gut ankamen. Seither werden die en-Büros vom SG ernannt. --Der-Wir-Ing ("DWI") (Diskussion) 10:24, 23. Feb. 2023 (CET)
- Anders als bei Oversightern und Checkusern, die aufgrund der hohen Verantwortung einen starken Rückhalt der Community brauchen, halte eine 2/3-Mehrheit bei Bürokraten für ausreichend. -- Ra'ike Disk. P:MIN 18:25, 11. Mär. 2023 (CET)
Schutz der Wiederwahl-Seite von Bürokraten
Bearbeiten- Man sollte den Schutz der WW-Seite für Bürokraten abschaffen, gleichzeitig aber auch die Begrenzung der Amtszeit auf zwei Jahre. --Count Count (Diskussion) 21:16, 5. Feb. 2023 (CET)
- Ist nicht mehr zeitgemäß, zumal sich auch das Verständnis als Zusatzfunktion ändert. Sämtliche Zusatzfunktionen sollten wahltechnisch vom Adminamt entkoppelt werden, d. h. es soll bei der turnusmäßigen Wahl für die Zusatzfunktionen bleiben, die Wiederwahlaufforderung für Admin folgt dem Standardprozess für Admins, und die Bestätigungswahl der Zusatzfunktion löst auch keine Wiederwahlseitensperre aus. Einfach so, als hätte beides nichts miteinander zu tun. MBxd1 (Diskussion) 21:43, 5. Feb. 2023 (CET)
- ich stimme MBxd1 hier zu (sofern ich's richtig verstanden habe). es ist fuer mich nicht nachvollziehbar, weshalb ein admin, der zum B/OS/CU/SG gewaehlt wurde, nicht als admin abgewaehlt werden koennen sollte (und dann den gleichen status haette wie ein nicht-admin, der zum B/OS/CU/SG gewaehlt wurde). -- seth 22:15, 5. Feb. 2023 (CET)
- Abschaffen klingt gut. Eine Amtszeitbegrenzung noch besser. Aber dann bei allen drei Funktionen. Oder zwei, wenn die Bürokraten endlich abgeschafft sind. -- Marcus Cyron Stand with Ukraine and Iran! 22:40, 5. Feb. 2023 (CET)
- Abschaffen erscheint sinnvoll. --Ghilt (Diskussion) 23:11, 5. Feb. 2023 (CET)
- +1 abschaffen --ɱ 00:00, 6. Feb. 2023 (CET)
- Ja, bitte auf jeden Fall. Weder die zwangsweise exakt alle zwei Jahre stattfindende Wiederwahl noch der Schutz eines Adminpostens durch Bürokratentätigkeit ist erklärbar. ~ ToBeFree (Diskussion) 01:31, 6. Feb. 2023 (CET)
- Hat schon einmal jemand die derzeitigen Bürokraten gefragt, was sie davon halten? Viele Grüße, Aschmidt (Diskussion) 07:22, 6. Feb. 2023 (CET)
- Warum sollte man das tun? --Marcus Cyron Stand with Ukraine and Iran! 03:47, 8. Mär. 2023 (CET)
- ja, kann abgeschafft werden. Analog zu BOA dann gern auch ohne regelmäßige Wiederwahl. -- hgzh 09:21, 6. Feb. 2023 (CET)
- ja, und evtl. auch die zweijährigen Wiederwahlen komplett abschaffen oder zumindest den Turnus auf vier Jahre verdoppeln. --Icodense 10:23, 6. Feb. 2023 (CET)
- Ja --Roland Kutzki (Diskussion) 12:50, 6. Feb. 2023 (CET)
- ich verstehe die Gründe für den Schutz, halte das aber auch nicht mehr für zeitgemäß und würde den Schutz abschaffen. --Kurator71 (D) 14:35, 6. Feb. 2023 (CET)
- wie Kurator. Ist aber mMn nicht nur für die Bürokraten überlegenswert. Grüße, --Snookerado (Diskussion) 15:47, 6. Feb. 2023 (CET)
- Wenn der Schutz der WW-Seite für Bürokraten abgeschafft wird, dann aber auch die Begrenzung der Amtszeit auf zwei Jahre. Also analog wie das Prozedere bei Admins. --Alraunenstern۞ 16:19, 6. Feb. 2023 (CET)
- Für alles abschaffen. CU, OS, B. --Filzstift (Diskussion) 17:08, 6. Feb. 2023 (CET)
- Kann abgeschafft werden --Ameisenigel (Diskussion) 17:35, 6. Feb. 2023 (CET)
- Ist seit langem mein ceterum censeo. Das sind verschiedene Aufgabenbereiche. Jemand kann als B eine ordentliche Arbeit machen, aber als Admin eine Katastrophe sein.--Altaripensis (Diskussion) 12:28, 7. Feb. 2023 (CET) PS: Die zwei Jahre Amtszeit sollten aber beibehalten werden.--Altaripensis (Diskussion) 12:32, 7. Feb. 2023 (CET)
- Es muss möglich sein, einen Admin, der ein guter Bürokrat, aber ein schlechter Admin ist, abzuwählen. Ich bin gegen eine geschützte AWW-Seite bzw. für zwei getrennte WW-Seiten: eine AWW und eine BWW. --Brettchenweber (Diskussion) 15:01, 7. Feb. 2023 (CET)
- Pro Abschaffung des Schutzes. Die Idee mit je einer WiWa-Seite für (A) und (B) unterstütze ich. --Wwwurm Paroles, paroles 15:27, 7. Feb. 2023 (CET)
- @Www und Brettchenweber: Extra eine B-WW-Seite aufzumachen fände ich zu viel Bürokratie. Wenn B's weiterhin alle 2 Jahre gewählt werden, braucht man das nicht.--Altaripensis (Diskussion) 17:17, 7. Feb. 2023 (CET)
- Kontra Abschaffung des Schutzes - kein Änderungsbedarf--Lutheraner (Diskussion) 15:35, 7. Feb. 2023 (CET)
- Als das Sytem eingeführt wurde, hat das gut gepasst, heute find ich das eigentlich nicht mehr zeitgemäß. Ich bin auch kein Freund davon, dass (vereinzelt) Bürokraten im alltäglichen Admingeschäft äußerst umtriebig sind, aber dieser Kontrollmechanismus bei ihnen ausgeschaltet ist. … «« Man77 »» Alle Angaben ohne Gewehr. 17:23, 7. Feb. 2023 (CET)
- Wenn B und A unvereinbar wären und stattdessen eine Amtszeitbegrenzung für B bestünde, wäre ich gegen WW-Seiten für B. So bin ich aber für eine Öffnung der WW-Seite für B nach 28 Tagen.-- Leif Czerny 15:10, 11. Feb. 2023 (CET)
- Abschaffen. --Gardini ⋅ RC 💞 RM 23:00, 28. Feb. 2023 (CET)
Bürokraten als Notariat
BearbeitenDas 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.
- 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)
Oversighter
Bearbeiten- Abschaffung der Wiederwahlseitensperre (auch für CU): Wer das Quorum erreichte und nicht wiedergewählt wird, darf Adminrechte nur noch im Rahmen seiner OS-Arbeit einsetzen (analog SG, CU). --Filzstift (Diskussion) 17:09, 6. Feb. 2023 (CET)
- Nachträgliche Anmerkung: Es gab bereits 2015 ein MB dazu: Wikipedia:Meinungsbilder/Öffnung der Wiederwahlseite trotz höherer Funktion. --Filzstift (Diskussion) 22:54, 6. Feb. 2023 (CET)
- Volle Zustimmung zu Filzstift --Ameisenigel (Diskussion) 17:36, 6. Feb. 2023 (CET)
- Wie Filzstift --Ghilt (Diskussion) 22:47, 6. Feb. 2023 (CET)
- Wie die Vorredner.--Altaripensis (Diskussion) 12:33, 7. Feb. 2023 (CET)
- Kein Änderungsbedarf--Lutheraner (Diskussion) 15:36, 7. Feb. 2023 (CET)
- Wie 1. - keine WW-Sperre, sofern sich diese nur auf das A bezieht.-- Leif Czerny 15:12, 11. Feb. 2023 (CET)
- Klingt vernünftig. --DaB. (Diskussion) 22:06, 13. Feb. 2023 (CET)
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)
- 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)
- Und darum dauern CU-Abfragen zum Teil Monate? --Marcus Cyron Stand with Ukraine and Iran! 22:41, 5. Feb. 2023 (CET)
- 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)
- 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)
- 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)
- "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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- "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)
- 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)
- 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)
- 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)
- In diesem Abschnitt ack zu Squasher. -jkb- 23:55, 5. Feb. 2023 (CET)
- 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)
- Die Funktion ist so wichtig, dass es nicht zuviele Checkuser geben kann. Viele Grüße, Aschmidt (Diskussion) 07:31, 6. Feb. 2023 (CET)
- 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)
- 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)
- Die Idee habe (unter anderem?) ich geäußert. --Sabrieleauftistik (Diskussion) 15:17, 6. Feb. 2023 (CET)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Bist du sicher, dass „Schnüffler“ der richtige Begriff für eine sachliche Debatte ist? - Squasher (Diskussion) 16:02, 6. Feb. 2023 (CET)
- Ich hab’s auf „Ermittler“ geändert. --Sabrieleauftistik (Diskussion) 16:21, 6. Feb. 2023 (CET)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- Ich hab’s auf „Ermittler“ geändert. --Sabrieleauftistik (Diskussion) 16:21, 6. Feb. 2023 (CET)
- Bist du sicher, dass „Schnüffler“ der richtige Begriff für eine sachliche Debatte ist? - Squasher (Diskussion) 16:02, 6. Feb. 2023 (CET)
- 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)
- 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)
- 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)
- 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)
- Die Sperrbegründung „Vandalismus“ lässt sich recht einfach über die Beitragsliste nachvollziehen, „Sockenspielen“ eher nicht. -- hgzh 07:42, 7. Feb. 2023 (CET)
- Und dennoch fändest du beides im Sperrlogbuch. Soviel zum „Verborgenen“. - Squasher (Diskussion) 09:05, 7. Feb. 2023 (CET)
- 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)
- Und dennoch fändest du beides im Sperrlogbuch. Soviel zum „Verborgenen“. - Squasher (Diskussion) 09:05, 7. Feb. 2023 (CET)
- Die Sperrbegründung „Vandalismus“ lässt sich recht einfach über die Beitragsliste nachvollziehen, „Sockenspielen“ eher nicht. -- hgzh 07:42, 7. Feb. 2023 (CET)
- 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)
- 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)
- Erhöhung wäre okay. Aber auch hier sollte der WW-Seitenschutz entfallen.--Altaripensis (Diskussion) 12:34, 7. Feb. 2023 (CET)
- 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)
- 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)
- 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)
- 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)
- 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)
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)
- 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)
- 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)
- 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)
- +1: das scheint mir auch so. --Holmium (d) 22:50, 5. Feb. 2023 (CET)
- bei genügend Transparenz könnte ich mich damit u. U. anfreunden, ist aber eher unwahrscheinlich. -jkb- 23:13, 5. Feb. 2023 (CET)
- 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)
- Es gäbe keinen sachlichen Grund, SG-Admins CU-Rechte zu geben. Viele Grüße, Aschmidt (Diskussion) 07:24, 6. Feb. 2023 (CET)
- 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)
- @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)
- 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)
- 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)
- 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)
- @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)
- Wie Icodense. --Maxl (Diskussion) 12:54, 6. Feb. 2023 (CET)
- 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)
- 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)
- 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)
- 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)
- Wie Perrak. Es ist gut, wenn die eine Institution die andere braucht.--Altaripensis (Diskussion) 12:42, 7. Feb. 2023 (CET)
- 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)
- 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)
- Das SG braucht kein CU um zu funktionieren. LG Dwain 14:06, 10. Feb. 2023 (CET)
- 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)
- 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)
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)
- Halte ich für eine pragmatische Idee LG Dwain 13:36, 10. Feb. 2023 (CET)
- Brettchenweber (Diskussion) 13:57, 10. Feb. 2023 (CET) Pro. Diese Vizepräsidentenregel ist keine schlechte Idee. Klären müsste man dann noch, wann – so wir bei einem regelmäßigen Wiederwahlturnus bleiben – die Amtszeit endet: Gilt das Nachrückdatum als Amtsbeginn oder der Amtsbeginn des Vorgängers? --
- 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)
- Halte ich für eine Überlegung wert. Die Zeit sollte ab der Wahl laufen. -- Perrak (Disk) 19:09, 10. Feb. 2023 (CET)
- Ameisenigel (Diskussion) 22:28, 10. Feb. 2023 (CET) Pro Klingt für mich sinnvoll --
- Haben wir nicht schon ne Nachrückerregel [2]? Hätte aber meines Wissens eh nie was geändert, wegen Kandidatenmangel. --Der-Wir-Ing ("DWI") (Diskussion) 23:33, 10. Feb. 2023 (CET)
- 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)
- 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)
- 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)
- Nagut, ich hatte mich auf die CU-Wahlen beschränkt. --Der-Wir-Ing ("DWI") (Diskussion) 11:31, 11. Feb. 2023 (CET)
- Ich schrieb "Bei SG-Wahlen..."--Altaripensis (Diskussion) 11:33, 11. Feb. 2023 (CET)
- Nagut, ich hatte mich auf die CU-Wahlen beschränkt. --Der-Wir-Ing ("DWI") (Diskussion) 11:31, 11. Feb. 2023 (CET)
- 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)
- 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)
- 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)
- Ob wir mehr Kandidaten hätten, wenn man von vornherein als Vize-BOSCU, also als Notbesetzung, kandidieren könnte? --Brettchenweber (Diskussion) 11:40, 11. Feb. 2023 (CET)
- 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)
- 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)
- 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)
Ablehnung der Umfrage
BearbeitenKommentare
BearbeitenBitte die Diskussionsseite benutzen.
Ergebnis
BearbeitenDie 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) | |||
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)