Wikipedia Diskussion:Meinungsbilder/Nichtadmins als Benutzeroberflächenadministratoren

message: Das ist eine gute Idee und sollte imho auch für Vorschlag 2 mit aufgenommen werden, also bitte auch dort :"Bei fehlender Nutzung verfällt das Recht wie bei Admins nach 12 Monaten und kann nur mit einer erneuten Wahl wieder erlangt werden." einfügen. Ansonsten gerne bald starten, ist eine gute Idee, da die aktuelle Verbindung mit dem admin unpassend ist. Flossenträger 08:58, 7. Jul. 2020 (CEST)
replies: text: Du hast recht, ich habe es eingesetzt (nach der oben besprochenen neuen Nummerierung ist es jetzt Vorschlag 1). Gruss, --MBq Disk 16:31, 7. Jul. 2020 (CEST)
thread_title:  Angriffsvektor klein halten...  

message: Ich hatte die nachstehende Abstimmungsalternative zu Dienst-Acoounts unter die Vorschläge eingefügt.
* Sie würde die WMDE-Problematik lösen.
* Die Verantwortung, die sonst die Community mit einer erfolgreichen Kandidatur für das immer fachgerechte Handeln der Admins und BOA übernimmt, wäre an die entsendende Organisation übergegangen, also Vorstand, Abteilungsleiter usw. für den dortigen Mitarbeiter.
* Über das WMDE-Feld hinaus sehe ich keinerlei Bedarf für weitere BOA, da wir bereits heute zehnmal so viele BOA haben wie zur Abwicklung der Aufgaben erforderlich wären. Ich selbst bin keiner, aber die Mehrzahl der Veränderungen an Community-JavaScript ging auf meine Vorschläge zurück, die dann nach vorheriger mehrtägiger Inspektion durch die Weltöffentlichkeit mittels eines BOA einkopiert wurden.
* Ich stelle die mit Special:Diff/201746600 gelöschte Abstimmungsoption (ein Abschnitt drüber, „Vorschlag 3“) an dieser Stelle zur Kenntnis der künftig Abstimmenden erneut sichtbar ein.
; Pro
: To be completed by originator and supporters
; Kontra
: To be completed by originator and supporters
VG --PerfektesChaos 15:22, 10. Jul. 2020 (CEST)
replies: text: Grob in etwa so läuft das im übrigen bei Wikidata seit Jahren, und es gibt dabei keine Probleme. WMDE-Entwickler haben dort eine Benutzergruppe wikidata-staff, zu der die Gruppenzugehörigkeit vom Entwicklerteam selbst organisiert wird. Verantwortlich ist vermutlich letztlich Lydia Pintscher als WMDE-Produktmanagerin für Wikidata. Mit der Gruppenzugehörigkeit gehen diverse erweiterte Rechte einher, etwa Admin-Rechte und die Möglichkeit, BOA bei Bedarf auf den eigenen Account zuzuschalten; alles mit der ausdrücklichen Maßgabe, dass diese Rechte nur für Dienstzwecke (Softwareentwicklung) genutzt werden dürfen. Üblicherweise sind so fünf bis zehn Benutzeraccounts in der wikidata-staff-Benutzergruppe; deren Zugehörigkeit kann auch über das markAdmins-Gadget markiert werden.Der Vorteil einer separaten WMDE-Benutzergruppe wäre, dass damit der erlaubte Einsatzbereich der erweiterten Rechte konzeptionell klar abgegrenzt ist, und der Unterschied zu den normalen Trägern der erweiterten Rechte klar ist. Auch wäre eine anders gelagerte Rechtevergabe nachvollziehbar.Inwiefern das hier Akzeptanz findet, möchte ich hier nicht bewerten. Es können sicherlich verschiedene Aspekte diskutiert werden, etwa inwiefern die Community bei der Vergabe der Gruppenzugehörigkeit Mitspracherecht hat, und welche erweiterten Rechte damit überhaupt zugänglich gemacht werden sollten. —MisterSynergy (Diskussion) 11:11, 14. Jul. 2020 (CEST)
replies: text: Klingt eigentlich nach einer guten Idee. Als Seitenbetreiber könnte die Foundation ihren Angestellten ohnehin alle Rechte geben lassen, die sie will, wenn man über eine Benutzergruppe regelt, welche Rechte konkret vorhanden sein sollen, würde das die Transparenz erhöhen. Und es ist dann auch klar, dass diese Rechte nur in dieser Funktion verwendet werden dürfen. -- Perrak (Disk) 16:13, 14. Jul. 2020 (CEST)
thread_title:  Vorschlag zu Dienst-Acoounts 

message: Als kleines Feedback, es hat bereits mit NNW den ersten gegeben, der die BOA-Rechte zurückgegeben hat, da die gewählte Sprache: "Es sind eh zu viele, sie werden nicht benötigt und stellen nur ein Sicherheitsrisiko dar" usw. wenig emphatisch ist. Nun ist NNW jemand, der sich immer an den anfallenden Arbeiten beteiligt hat. Ich finde es schade, wenn unangepasste Formulierungen dazu führen und bitte darum, dass dies in einem Freiwilligen-Projekt nicht vergessen wird.  als Info. --Itti 14:46, 13. Jul. 2020 (CEST)
replies: text: Und auch von meiner Seite mal eine Frage:Was genau will nun dieses Meinungsbild? Ich dachte es geht hier um die Frage, wie nun mit den Nichtadmins umgegangen werden soll, die den Wunsch haben Benutzeroberflächenadmin zu werden. Funkruf  WP:CVU 14:54, 13. Jul. 2020 (CEST)
replies: text:  Hm, ich habe dieses MB einigermaßen auf'm Bildschirm, dann habe ich etwas wohl nicht mitbekommen. Der Umgang mit der Software ist nicht jedermanns Sache, und es ist dabei zuerst nicht entscheidend, ob es sich um einen Admin handlt oder nicht. Insofern macht das MB einen Sinn. Wenn das aber dazu führ, dass einige BOAs sich da tangiert fühlen, so wie NNW, der wohl zu den fähigsten hierfür gezählt werden könnte, so lief hier einiges schief. Und die Überprüfung, ob jemand sich hierfür eignet, müsste ohnehin immer sehr sorgfältig  geschehen. Das ist keine Funktion, mit der man hier eine "Karriere" machen sollt. Also bitte, und dies insbes. auch auf NNW, tief einatmen, durch massenhafte Rücktzritte kriegen wir es nicht hin (drei andere überlegen es derzeit). Leute. -jkb-  15:10, 13. Jul. 2020 (CEST)
replies: text:  "Es sind eh zu viele, sie werden nicht benötigt und stellen nur ein Sicherheitsrisiko dar" - woher stammt das Zitat und wo sagt NNW, dass er deshalb die BOA-Rechte zurückgegeben hat? --Felistoria (Diskussion) 00:04, 14. Jul. 2020 (CEST)
replies: text:  Eins ist irgendwo hier oben, denke ich, sonst da. -jkb-  00:10, 14. Jul. 2020 (CEST)
replies: text: Ich verstehe nichts, vor allem nicht die Aufregung. --Felistoria (Diskussion) 00:32, 14. Jul. 2020 (CEST)
replies: text:  Es ist kein Statussymbol (auch wenn es einige so verstehen könnten), sondern eine scheißkomplizierte und frustrierende Arbeit, wenn man sich da nicht auskennt, und das tun nicht viele (ich musste um 2006, als ich die cs.wikisource gründete, in dem Bereich herumfummeln, denn ich bekam das Projekt in der englischen Rohfassung so zugeschoben und musste sehen, was ich damit als bct mache). Ich würde sagen: Leute, die sich auskennen, und die kennt man, sollten dazu die Rechte haben, andere eben nicht. -jkb-  00:41, 14. Jul. 2020 (CEST)
replies: text: Hm. Ich glaub', das Problem ist, dass das MB kein Ziel hat, sondern eher eine Umfrage ist - es solle geklärt werden, ob und wie.., heißt es - das ist kein Ziel, sondern das sind Fragen. Ob BOA "scheißkompliziert" ist, weiß ich nicht; hier geht es doch darum, ob Nicht-Admins eine bislang administrativ zugeordnete Funktion übernehmen sollen oder nicht oder worum? --Felistoria (Diskussion) 00:51, 14. Jul. 2020 (CEST)
replies: text:  Ju. -jkb-  00:54, 14. Jul. 2020 (CEST)
replies: text:  +1. Warum die Bürokraten nicht selbst eine sinnvolle Regelung aufstellen, sondern von vorn herein von sich aus ein MB aufstellen, kann ich nicht so ganz nachvollziehen. --Krd 07:34, 14. Jul. 2020 (CEST)
replies: text: Rechte und Regeln sind in dieser Wikipedia aus irgendeinem Grund ein Riesending. Ich fürchte es gibt mal wieder einen veritablen Aufstand, wenn die Bürokraten das selbst regeln. —MisterSynergy (Diskussion) 09:32, 14. Jul. 2020 (CEST)
thread_title:  Feedback 

message: Weiter oben meint Funkruf, dass PerfektesChaos doch "ein eigenes Meinungsbild" machen solle. Ich würde es besser finden, wenn wir, statt lauter Meinungsbilder über Einzelaspekte zu machen (sollen Nichtadmins BOA sein können, wieviele BOA braucht es...), eines erarbeiten würden (und dazu könnten wir dieses hier als Grundlage nehmen und weiter bearbeiten), mit dem wir endlich ein Konzept für die BOA erhalten, das zugleich diese Fragen beantwortet. Also halt so etwas wie z.B. "es gibt maximal 20 BOA" (das ist im Moment die genaue Zahl laut Liste auf Wikipedia:Benutzeroberflächenadministratoren, abgesehen von den Oversightern) und "zum BOA wird man separat gewählt, unabhängig von Adminrechten" und "nach einem Jahr ohne Nutzung der BOA-Rechte verliert man diese", so etwas könnte ich mir vorstellen. Gestumblindi 11:29, 14. Jul. 2020 (CEST)
replies: text: Grundsätzlich vernünftig. Ich würde allerdings vorschlagen, sich zuvor einmal anzuschauen, was in den letzten zwei Jahren mit den Rechten gemacht wurde und davon ausgehend Regeln aufzustellen. Um mich unbeliebt zu machen: Dass alle OS und B die Rechte für ihre Aufgaben als OS und B benötigen, ist daraus nicht abzulesen. Außerdem würde ich vorschlagen, dass wenn bspw. die OS weiterhin grundsätzlich die Rechte wegen OS bekommen, dann sollen sie sie auch nur für OS anwenden. Ansonsten ist die Begründung für die Rechtevergabe falsch. „Maximal x BOA“ funktioniert nur, wenn entweder die Rechte regelmäßig neu beantragt werden müssen oder eine Mindestzahl an Aktionen pro Zeitraum y ausgeführt werden muss. Die Erfahrung bei anderen Benutzergruppen zeigt, dass die wenigsten freiwillig ihre Rechte abgeben, wenn sie das Gefühl haben, nicht mehr wirklich aktiv zu sein. NNW 12:14, 14. Jul. 2020 (CEST)
thread_title:  Gesamtkonzept für BOA 

message: Weder 2018 noch 2008 noch heute wäre irgendwie klar, welche Aufgaben denn BOA eigentlich hätten, und welche Befugnisse ihnen das Projekt einräumt. Bislang gibt es nur technische Features wie editsite*** aber noch nie irgendwelche Spielregeln dazu.
* BOA lassen sich sehr gut mit einer Löschdiskussion vergleichen, die von einem Admin entschieden wird.
** Irgendjemand, und sei es IP, stellt einen LA.
** Es wird mehrere Tage (meist eine Woche) darüber diskutiert.
** Am Ende kommt ein Admin vorbei, prüft die vorgetragenen Argumente und den Sachverhalt, und entscheidet dann gemäß der Richtlinien wie RK, NK usw.
* Für die Skin-Ressourcen schlägt irgendjemand auf WP:MW/Ä eine Veränderung vor.
** Das kann auch eine IP sein.
** Der Vorschlag muss konkret und präzise sein, also die Änderung so exakt beschreiben, dass diese eindeutig mittels C&P oder vergleichbar umgesetzt werden kann („Patch“).
** Dann wird darüber diskutiert; je nach Komplexität einen oder mehrere Tage.
*** CSS ist sicherheitstechnisch praktisch unkritisch.
**** Die Änderung hat Auswirkungen auf die Dekoration; das kann nur eine Angleichung von ein paar Pixeln bedeuten, oder sonst eine Vereinheitlichung von Farben.
**** Kann aber auch eine auffälliger veränderte Präsentation bewirken.
**** Muss man in jedem Einzelfall einstufen.
*** JavaScript mit einer simplen Veränderung eines Bezeichners ist sicherheitstechnisch selten relevant.
**** Kann sein, dass aus einem .hugo eine .paula werden soll.
**** Sollte trotzdem fachlich mal draufgeguckt werden; ist es wirklich .paula oder müsste es nicht .pauline heißen?
*** Änderungen in JavaScript-Strukturen, neue Unterprogramme wären komplexer und benötigen mehr Zeit.
**** Fachlich, Sicherheitslecks, Funktionalität, Nebenwirkungen, besondere Situationen? Muss intensiver getestet werden.
** Nach angemessener Diskussionszeit kommt ein BOA und entscheidet, ob das eingepflegt werden solle oder nicht.
*** Dabei sind Sicherheit, Robustheit, wünschenswerte Funktionalität, Verkomplizierung oder Vereinfachung des Systems zu beachtende Aspekte.
*** Falls ja, ist es überwiegend schlichtes C&P des Vorschlags.
* Die LD und die BOA-Aktionen haben Gemeinsamkeiten:
** Vieraugenprinzip:
*** Eine reguläre LD darf niemals durch den LA-Steller entschieden werden (ausgenommen wäre Herunterstufung auf SLA-Niveau gemäß der expliziten SLA-Spielregeln).
*** Ein Änderungsvorschlag zur Skin-Programmierung darf nicht durch denjenigen entschieden werden, der ihn gemacht hat.
** Alle einschließlich IP können Aktionen beantragen.
* Einen Unterschied gibt es jedoch:
** Für alle anderen Bereiche des administrativen Handelns hat die Community Spielregeln und Rahmenrichtlinien erarbeitet: LD, VM, BSV, AK, SP, LP, AWW, CU, OS usw.
** Nur der Bereich der Software-Konfiguration war nie durch irgendwelche Prinzipien begrenzt worden. Jeder, der technisch dazu in der Lage ist, darf jederzeit ohne irgendeine Ankündigung oder Koordination wirksam rumprogrammieren wie es grad gefällt.
** Das umseitige MB in seiner ursprünglichen Gestalt zielt darauf ab, den Kreis der technisch Berechtigten ohne die allergeringsten Spielregeln auch noch auf beliebige Nicht-Admins ausweiten zu wollen.
* Es gibt das Märchen, man müsse erst mal BOA-Rechte erhalten haben, bevor man Code schreiben könne.
** Das ist schlicht falsch.
** Jede BNR-Seite reicht zur vollständig kompatiblen Entwicklung und Erprobung neuer Skripte aus.
** Mit WP:BETA haben wir seit 2013 eine Simulation der echten, produktiven deutschsprachigen Wikipedia, in der unter praktisch realitätsidentischen Bedingungen neue Gadgets, Skripte, komplexere Vorschläge erprobt werden können (und müssen). Anschließend steht nur noch das C&P der erprobten und als wünschenswert eingestuften Veränderung durch einen BOA an.
** Selbst jede IP kann ohne BNR nur von der eigenen Festplatte aus per Greasemonkey neuen Code entwickeln.
** Von mir selbst wurde ein nennenswerter Teil des jederzeit bei Benutzern aktiven JavaScript in seiner heutigen Form programmiert; ich bin weder Admin noch BOA noch brauche ich sowas.
** Da gemäß Vieraugenprinzip derjenige, der den Code entwickelt, niemals der BOA sein darf, der ihn einpflegt, ist die Verknüpfung auch völlig widersinnig.
* Zurück in den Kindergarten
** In der guten alten Zeit, zum Höhepunkt der „Skriptbastelei“ so etwa um 2009 und in den Jahren danach, hatten viele Admins direkt und ohne vorherige Tests am produktiven Wiki experimentiert, wie sich diese oder jene Veränderung des JavaScript-Code auswirken würde.
** Das klappte häufig, ging aber auch öfters schief.
** Ich erinnere mich an mehrere Fälle, wo ich bei den Admins mit einer Alarmmeldung aufschlug, weil eine Bastelei eine Viertelstunde zuvor die gesamte JavaScript-Ausführung des Projekts zum Absturz brachte, da triviale Fehlersituationen zur Laufzeit nicht bedacht und nicht abgefangen wurden.
** Damals™ war es ein Projekt „im Aufbau“ gewesen, von ein paar Internet-Spinnern, das sowieso völlig unzuverlässig war; heute werden wir oft zu den Qualitätsmedien gezählt.
** Seit 2013 gibt es WP:BETA und seitdem werden durch gute Bearbeiter alle Veränderungen an komplizierten Vorlagen, an produktiven Lua-Modulen, an Systemnachrichten und CSS und ggf. JavaScript vorher erprobt, und erst wenn in allen vorhersehbaren Szenarien kein Verbesserungsbedarf mehr zu finden ist wird der fertige Code abschließend in die produktive, echte Wikipedia kopiert.
** Wir haben für unsere Hauptseite eine Million Abrufe pro Tag, in 86400 Sekunden, also etwa 12 pro Sekunde. Wir haben für alle Artikel und sonstigen Seiten und URL-Kombinationen in der Größenordnung von 100 Millionen Abrufen pro Tag, also über 1000 Abrufe pro Sekunde. Wenn ein BOA bem Basteln einen Fehler macht, und diesen aber schon nach 60 Sekunden bemerkt und revertiert, dann wird inzwischen 60.000 unserer Leser vor den Kopf gehauen.
** Das umseitige MB beruht in seiner Zielrichtung darauf, dass es zukünftig weiter ermöglicht und verstärkt gefördert werden solle, direkt in der Konfiguration der echten Wikipedia für alle Leser herumzubasteln, statt wie in der Software-Entwicklung seit Jahrzehnten üblich und erforderlich jede Änderung erst durch Review, Audit, Check gehen zu lassen, andere und weniger betriebsblinde nochmals draufgucken zu lassen (peer review in der Wissenschaft) und es erst danach wirksam werden zu lassen.
** Zu nichts anderem als zur Fortsetzung dieser fragwürdigen und gefährlichen Praxis ist die vom umseitigen MB angestrebte Politik von immer mehr direkt wirkenden BOA erforderlich.
VG --PerfektesChaos 12:45, 15. Jul. 2020 (CEST)
replies: text: +1 Funkruf  WP:CVU 13:30, 15. Jul. 2020 (CEST)

text: Als jemand der selbst BOA war und der auch zuvor schon jahrelang an JS/CSS in der WP gearbeitet hat: PerfektesChaos, Du übertreibst. Das ist hier nicht der Linux-Kernel, sondern es geht um triviale Änderungen an einer Webseite. Weder bauen wir die Oberfläche alle 5 Minuten um noch geht es um sicherheitskritische Dinge. Die meisten Änderungen betreffen Leser gar nicht, sondern nur Leute, die sich ein Gadget aktiv eingeschaltet haben. Das ganze Misstrauen kommt von der WMF – jemand KÖNNTE ja irgendwas einbauen was problematisch wäre. Das mag in China, Iran oder Russland ein Problem sein, aber nicht hier. Weder wird ein 10-Augen-Rewiev-Prozeß benötigt, noch muss die Anzahl der BOA auf Menge X beschränkt sein (die Inaktiv-Prüfung ergibt tatsächlich Sinn). It’s a wiki – auch bei der Software. --DaB. (Diskussion) 14:10, 15. Jul. 2020 (CEST)
replies: text: So ist es. Im Übrigen: Unsere Wikiprojekte WikiCommons haben 28 BOA (davon 1 Bot) und WikiData 18 BOA. Also so alleine stehen wir hier also nicht. Funkruf  WP:CVU 14:49, 15. Jul. 2020 (CEST)
replies: text: Die Bewertung von DaB. halte ich für völlig falsch. Wenn der Account eines BOA irgendwie ins JavaScript Schadcode einpflegen würde, ob versehentlich vom Antragsteller versteckten (Phishing etc.) oder durch Hacking, ließen sich dadurch wie von PC beschrieben binnen Minuten Hunderttausende über eine vertrauenswürdige Seite attackieren. Das lässt sich mit +2-(Push)-Rechten auf MediaWiki Core oder auf den Linux-Kernel nicht einmal bewerkstelligen, weswegen man den Angriffsvektor möglichst klein halten muss. --MGChecker – (📞| 📝| ) 15:01, 15. Jul. 2020 (CEST)
replies: text:  Wir haben doch die Geprüften Versionen herumliegen, diese waren ursürnglich mal für den ANR vorgesehen, wurden aber nie aktiviert. Wäre es nicht machbar, diese für MediaWiki:*.js zu aktivieren? Dann würde BOA1 eine Änderung vornehmen und BOA2 diese prüfen, ein Hacker müsste dann zwei entsprechnde Accounts in seine (oder ihre) Gewalt kriegen. --Morten Haan 🏄 Wikipedia ist für Leser da 🧉 Übersichtliche Artikelkriterien 16:12, 15. Jul. 2020 (CEST)

text:  Schadcode, welcher versehentlich vom Antragsteller beantragt und vom BOA-Berechtigten eingebaut wird? Ich erwarte schon von einem BOA-Berechtigten, dass er den Code welchen er einfügt lesen/verstehen kann und erkennt, wenn da was nicht stimmt. Das Account-Hacking mit einem starken Passwort bzw. Zwei-Faktor-Authentifizierung ist selbst wenn ich die gehashten Passwörter und das Salt hab immer noch mehr Zufall/Rechenleistung als Können. Da ist die Wahrscheinlichkeit höher, dass sich jemand über ein zero-day-exploit Zugriff auf das System/die Server holt und dann ist das ein ganz anderes Problem. Wenn jemand über eine Backdoor oder eine Zero-Day Schwachstelle Zugriff zu Accounts hat, dann bringen dir auch 4 BOA-Nutzer die sich das ganze anschauen nichts.  Warum sollte man sich außerdem die Mühe machen Accounts zu hacken, wenn ich auch alternativ die Server als Ziel nehmen könnte. Dort eingeschleuste Zero-Day-Exploits können einen größeren Nutzen bringen, als ein gehackter Account, insbesondere sie länger unentdeckt bleiben. Ich stimme dir zwar zu, dass man zwangsläufig immer die Angriffsvektoren betrachten muss, aber ich halte BOA-Benutzer daher nicht für primäre Ziele. Ich erinnere hier auch an den massiven DDOS von 2019.(Angriffe finden dauern statt, aber man muss auch schauen, wie erfolgreich sie sind) Stewards und Bürokraten oder die Server sind deutlich bessere Ziele, welche mehr Möglichkeiten haben und auch mehr Angriffsvektoren. DaB. hat aber auch insoweit recht, dass Schadsoftware im Linux-Kernel wesentlich gefährlicher ist. Zwar ist es komplizierter, aber wer sich den Zugriff ermöglicht um darauf zuzugreifen, der hat im Regelfall diese Fertigkeiten. Natürlich darf man die Gefahr durch Javascript-Schadcode nicht unterschätzen, aber man darf das ganze auch nicht überdramatisieren, weswegen ein gesunder Mittelweg gewählt werden sollte. Gruß --ExtremPilotHD (Diskussion) 18:21, 15. Jul. 2020 (CEST)
thread_title:  Aufgaben von BOA 

message: Ich weiß, dieses MB dient eigentlich nur dazu, Regelungen festzulegen, wie ein Benutzer BOA werden kann. Letztlich (und das hat PC oben schon angesprochen) wäre aber auch eine Regelung nötig, wie die Rechte wieder entzogen werden können. So ein wenig ist aber beides dann doch verknüpft:
Entscheidet die Community dafür, dass nur gewählte Admins auch BOA werden dürfen, stellt sich die Frage, ob ein Ausscheiden aus dem Admin-Amt zwingend auch den Entzug der BOA-Rechte beinhaltet. Das könnte vorne so festgelegt werden. Gleichzeitig könnte festgelegt werden, dass die klassischen Admin-Beschwerdewege (AWW-Seite, AP, ggf. SG) auch für alle Probleme rund um die Ausübung der BOA-Rechte zuständig sind.
Werden Nicht-Admins als BOA zugelassen, könnte festgelegt werden, dass diese eine AWW-Seite haben müssen, und dass BOA-Probleme via AP behandelt werden können.
In beiden Fällen sollten mM für die AWW-Seite zumindest zunächst die Standard-Regeln gelten, die auch für klassische Admins gelten (Quorum, Schutz nach Erreichen des Quorums). Bei Bedarf könnte man schärfere Regeln festlegen (bspw. Seite wird entgegen den Admin-Regeln nicht für 12 Monate nach erfolgter Wahl geschützt; für den Zeitraum zwischen Erreichen des Quorums und einer BOA-WW müssen die BOA-Rechte ruhen;...).
Wenn mit diesem MB aber auch Wege zum Entzug der Rechte beschlossen werden, dann sollten mM auch die derzeitigen BOAs diese nachträglich anerkennen.--Mabschaaf 16:15, 24. Jul. 2020 (CEST)
replies: text: Dein erster Fall ist der Status quo, und demnach ist eben BOA fest an den Adminstatus gekoppelt. Selbstverständlich geht BOA dann bei Aufgabe des Adminstatus aus egal welchem Grund auch verloren. Da das der Status quo ist, ist eine Ausgestaltung dieses Falls nicht möglich. Bei den anderen Optionen sollte dazugeschrieben werden, wie BOA wieder entzogen werden kann. Ansonsten kann man den Vorschlägen vernünftigerweise nicht zustimmen. AP dient im Zweifelsfall für alle Beschwerden über falschen Einsatz erweiterter Rechte, spezielle Seiten für Bürokraten-, Oversighter- und Checkuserprobleme haben wir ja auch nicht. MBxd1 (Diskussion) 11:02, 25. Jul. 2020 (CEST)
replies: text: Besser als das hier mit reinzupacken wäre vermutlich ein gesondertes MB. Dort könnte man das dann allgemein regeln, auch für BOA, die bereits Admin sind. Mag ja sein, dass jemand ein guter Admin ist, man ihm aber trotzdem nicht zutraut, den BOA-Job mit der gebotetenen Fachkompetenz auszufüllen. Könnte man prinzipiell auch für CU und/oder OS überlegen, aber da bin ich natürlich befangen ;-) -- Perrak (Disk) 12:37, 25. Jul. 2020 (CEST)
thread_title:  De-BOA 

message: Umseitig wird zwar die Ausgangssituation beschrieben, aber nicht das Problem dargestellt, dass eine Änderung erforderlich macht. Was ich da zu den Vorteilen der Vorschläge lesen kann, fällt nach meinem Verständnis alles unter "nice to have", das MB somit unter "Lösung sucht Problem". Sind da reihenweise Aufgaben, die mangels BOA nicht erledigt werden? Oder was ist das Problem? MBxd1 (Diskussion) 11:12, 25. Jul. 2020 (CEST)
replies: text: Das Problem ist, dass mit dem Mitarbeiter von WMDE sich jemand um die Rechte beworben hat, der sie eigentlich nicht hätte bekommen dürfen. Es gab intern die Meinung, dass dies nach der sehr eindeutigen Diskussion auf der Rechteseite möglich ist, bzw. dass dies eben nicht möglich ist, da er kein deWP-Admin ist. Als Kompromiss bekam er für 3 Monate die Rechte und hier soll in dieser Zeit ein Meinungsbild gestartet werden, ob die ok ist, oder nicht. Nach den Diskussionen oben bin ich inzwischen dafür ihm schlicht die Rechte vorzeitig einfach zu entziehen, denn ich sehe hier nur, dass versucht wird, immer mehr und mehr in ein Meinungsbild zu pressen, was hier an dieser Stelle gar nicht hingehört. --Itti 11:24, 25. Jul. 2020 (CEST)
replies: text: Soweit ist das nachvollziehbar, aber das MB zielt seiner Darstellung nach nicht darauf. Wenn man in dem Problem "Was machen wir mit solchen Anfragen?" weiterbohrt, kommt man zur Frage "Wozu braucht der die Rechte eigentlich, bringt das letztlich der Wikipedia Nutzen, und gäbe es vielleicht auch alternative Lösungen?". Diese Frage finde ich umseitig aber nicht beantwortet. Und einem Vorschlag, der seine Notwendigkeit nicht wenigstens glaubhaft macht, kann ich nicht zustimmen. Was geht kaputt, wenn es beim Status quo bleibt? MBxd1 (Diskussion) 11:55, 25. Jul. 2020 (CEST)
replies: text:  Nichts, dem WMDE-Mitarbeiter wird das Recht entzogen und fertig. --Itti 12:14, 25. Jul. 2020 (CEST)
replies: text: Danke für die klare Aussage. MBxd1 (Diskussion) 12:21, 25. Jul. 2020 (CEST)
thread_title:  Problembeschreibung fehlt 

message: Sorry, hab's bisher nur überflogen, aber wo ist denn der Abstimmungspunkt "Beibehaltung des Status Quo"? Viele Grüße, Grueslayer 07:38, 7. Aug. 2020 (CEST)
replies: text: Jeder Vorschlag steht einzeln zur Abstimmung. Wer den Status quo erhalten will, stimmt einfach bei allen drei Vorschlägen mit Contra. MBxd1 (Diskussion) 07:45, 7. Aug. 2020 (CEST)
replies: text:  Wird so nicht bei einigen Lesern der Eindruck erweckt, er müsse sich für eine der drei Optionen entscheiden? Viele Grüße, Grueslayer 07:51, 7. Aug. 2020 (CEST)
replies: text: Es gibt immer Leute, die nicht richtig lesen, darauf kann man nur begrenzt Rücksicht nehmen. "Zur Abstimmung stehen die drei Vorschläge, wie die Änderung ggf. umgesetzt werden soll, jeder für sich. Es kann jeweils eine Ja- oder Nein-Stimme vergeben oder eine Enthaltung vermerkt werden." Das ist eigentlich eindeutig. MBxd1 (Diskussion) 07:56, 7. Aug. 2020 (CEST)
replies: text:  Man hätte durch eine einfache Ergänzung des Standardabstimmungspunkts "Status Quo bleibt" Rücksicht nehmen und die Sache auch uneigentlich eindeutig gestalten können. Aber nun ja, ist jetzt halt so. Viele Grüße, Grueslayer 08:02, 7. Aug. 2020 (CEST)
replies: text: Das steht doch vorne eindeutig im Abschnitt "Auswertung" als 1. und 2. Satz im Unterabschnitt „Inhaltliche Abstimmung“ drin. Funkruf  WP:CVU 08:55, 7. Aug. 2020 (CEST)

text: Den Status Quo habe ich absichtlich wieder rausgenommen, damit es nicht so aussieht, als wäre das ein Abstimmungspunkt. Bei MBs ist der status quo immer privilegiert, es reicht die Ablehnung der anderen Vorschläge, damit der status quo gewinnt. Ein MB, das aussagte, dass ein Vorschlag umgesetzt wird, wenn es mehr Stimmen erhält als der status quo, wäre formal ungültig. Zudem ist es häufig nicht ganz klar, was eigentlich der status quo ist, wenn man das als Abstimmungspunkt definiert, würde das zusätzliches Streitpotential eröffnen. -- Perrak (Disk) 14:53, 7. Aug. 2020 (CEST)
thread_title:  Status Quo 

message: Hallo,Krd fragt umseitig, "Was machen wir, wenn 1 und 2 angenommen wird, 3 aber nicht" - hast Du die Auswertung nicht gelesen? Vorschlag 1 wird nur dann umgesetzt, wenn "er die größte gewichtete Differenz erreicht". In Deinem Beispiel würde also Vorschlag 2 umgesetzt. Was soll daran nicht auswertbar sein? -- Perrak (Disk) 17:17, 7. Aug. 2020 (CEST)
replies: text: Ist wohl doch nicht so einfach. Ich würde die Regeln so lesen, dass im Falle des Beispiels der Vorschlag von 1 und 2 umgesetzt wird, der die größere gewichtete Differenz erreicht (welcher das ist, definiert das Beispiel nicht). Falls die beiden den gleichen Wert erzielen, würde Vorschlag 2 umgesetzt.--Senechthon (Diskussion) 21:10, 7. Aug. 2020 (CEST)
replies: text: Stimmt. Perraks Antwort ist so pauschal falsch. MBxd1 (Diskussion) 21:22, 7. Aug. 2020 (CEST)
replies: text:  Trotzdem habe ich da was falsch gelesen. In dem Beispiel wird auf jeden Fall Vorschlag 2 umgesetzt. Falls Vorschlag 1 die größere Differenz haben sollte, wird er ebenfalls umgesetzt. Dabei hat es keine Bedeutung, dass die beiden sich eigentlich widersprechen. Na ja, zumindest weiß ich jetzt, wie ich abstimme.--Senechthon (Diskussion) 22:05, 7. Aug. 2020 (CEST)
replies: text: Stimmt, und es stimmt auch, dass 2 (und 3) neben 1 keinen Sinn hat. Ist aber so gewollt. Allerdings ist 1 sowieso schon gescheitert. MBxd1 (Diskussion) 22:13, 7. Aug. 2020 (CEST)
thread_title:  "Was machen wir, wenn 1 und 2 angenommen wird, 3 aber nicht" 

message: Ich gehe davon aus, die (WMF)er haben diese Berechtigung qua Wurmfortsatz, oder wie ist das da geregelt? Ich hatte den Eindruck, dass die ungewählten Devs der Stiftung recht freie Hand haben bei der Durchsetzung ihre Steckenpferdchen, auch wenn niemand in der Community ihre Machwerke goutiert. Ich sage nur Superputsch. Grüße vom Sänger ♫ (Reden) 10:32, 10. Aug. 2020 (CEST)
replies: text: Sie haben die Rechte dafür, das ist korrekt. Hier hast du mal die Rechte vom "staff". Er braucht hier also nicht die BOA-Rechte, den er hat sie ja schon global selber. Funkruf  WP:CVU 14:28, 10. Aug. 2020 (CEST)
replies: text: Dann ist das ganze MB doch bloss eine Alibiübung? D.h. Fall 3 ist schon heute so, mit dem Unterschied, dass das unbefristet ist? --Filzstift (Diskussion) 11:53, 13. Aug. 2020 (CEST)
replies: text:  WMF-Mitarbeiter haben andere Rechte, als WMDE-Mitarbeiter, sprich WMDE-Mitarbeiter haben keine Staff-Rechte. Viele Grüße --Itti 12:01, 13. Aug. 2020 (CEST)
replies: text:  Hat jetzt nichts mehr mit dem MB zu tun, aber: Warum eigentlich nicht? --Filzstift (Diskussion) 13:12, 13. Aug. 2020 (CEST)
replies: text: Weil es global ist. Funkruf  WP:CVU 13:14, 13. Aug. 2020 (CEST)
thread_title:  Wie ist die Berechtigung von Staffern geregelt? 

message: Das MB läuft noch bis zum 21. August, und normalerweise sollte man das Ergebnis abwarten. In diesem Fall ist es jedoch mehr als wahrscheinlich, dass der Status Quo als Ergebnis erhalten bleibt. Deshalb würde ich gern die nun noch vorhandene Aufmerksamkeit für das Thema nutzen um gemeinsam eine alternative Lösung zu suchen. 
Ich selbst habe das BOA Rechte nicht und strebe dies trotz Programmierkenntnisse auch nicht an.
1. Wenn Änderungen die BOA Rechte erfordern potentiell kritisch sind, so ist ein mehraugenprinzip nicht verkehrt. 
2. Es gibt mehrere Kollegen die das BOA Recht haben und Änderungen umsetzen können
3. Änderungen die BOA Rechte erfordern geschehen (zur Zeit) in Überschaubarer Anzahl
4. Wäre es eine Alternative Lösung, eine Seite einzurichten die Spezifisch Änderungen mit BOA Rechten anfordert, so das der Zweck der Änderung einfach sichtbar wird und auch die Änderung selbst einfach durch die BOA rechteinhaber durchgeführt werden kann? Ich stelle mir das so vor wie eine Request for change Section mit den Überschriften: 
* Was (Kurzbeschreibung worum es geht),
* Warum (Kurzbeschreibung des Zwecks der Änderung),
* Wie (Was genau wie geändert werden muss (der Code) 
So das ein BOA Kollege die Änderung durchführen kann, sobald er die drei W verstanden hat. 
Vorteil wäre das die Änderungen transparent wären, durch den Blick von weiteren BOAs das Risiko minimiert wäre und zugleich eine Art Qualitätskontrolle für BOA changes eingeführt wäre. 
Wie äufwändig wäre es die Änderungen von Thiemo K erst auf solch eine Seite zu pasten und von einem anderen durchführen zu lassen?
Was wären andere Alternative für die Durchführung von (nötigen/wünschenwerten) BOA changes durch nicht berechtigte? 
Groetjes --Neozoon (Diskussion) 09:26, 15. Aug. 2020 (CEST)
replies: text: Hallo Neozoon, so etwas gibt es mit Wikipedia:Technik/Skin/MediaWiki/Änderungen (zugegeben, komplizierter Name) bereits. Gruß, -- hgzh 14:01, 15. Aug. 2020 (CEST)
thread_title:  Praktikabele Lösung bei Erhalt des Status Quo 

message: Was wäre eigentlich der Unterschied zwischen Vorschlag 2 und dem Status quo, bei dem man sich ja theoretisch auch zum Admin wählen lassen kann mit der Begründung, dass man hauptsächlich bis ausschließlich BOA werden möchte? --MannMaus (Diskussion) 20:14, 17. Aug. 2020 (CEST)
replies: text: Beim Status quo ist es eine unverbindliche Ankündigung, bei Vorschlag 2 wäre es eine strikte Einschränkung gewesen. MBxd1 (Diskussion) 21:31, 17. Aug. 2020 (CEST)
replies: text: Nun gut, danke, das würde mich jetzt wohl kaum daran hindern, jemanden zum Admin zu wählen, weil er das nur unverbindlich ankündigt, aber dann doch löschen darf und so weiter. Ich dachte vielleicht, nachdem ich die Frage geschrieben habe, der Ermessensspielraum der Bürokraten die BOA-Rechte zu vergeben wäre vielleicht jetzt sehr groß und dann minimal. --MannMaus (Diskussion) 20:15, 18. Aug. 2020 (CEST)

text: Bei normalen Admins ist geregelt, wie die Rechte entzogen werden können. Das MB sieht momentan nur Inaktivität als Kriterium vor. --AFBorchert 🍵 12:13, 19. Aug. 2020 (CEST)
thread_title:  Vorschlag 2 "durchs Hintertürchen"