Wikipedia Diskussion:Meinungsbilder/Nichtadmins als Benutzeroberflächenadministratoren

Vor Beginn der Abstimmung

„Ich bin für keinen der Vorschläge 1-3“

Damit stimmt man sowohl gegen die Änderungsvorschläge als auch den Status Quo. Das wäre dann entweder eine Totalablehnung (welche Folgen hätte das in der Auswertung?) oder ähnlich einer Enthaltung (diese wäre dann doppelt). Meiner Ansicht nach wäre es logischer, Vorschlag 1 als Status Quo zu definieren und dann in der inhaltlichen Abstimmung diesen und die zwei Änderungsvorschläge nur für positive Voten aufzustellen. -- hgzh 12:52, 6. Jul. 2020 (CEST)

Ich würde vorschlagen, das anders aufzutrennen.

1. Vorschlag: "Sollen auch Nicht-Administratoren BOA werden können?" Wahlmöglichkeit: Ja/Nein/Enthaltung - Bei Ablehnung bleibt es beim Status quo, Mehrheit einfach oder 2/3.

2. Vorschlag: "Falls der 1. Vorschlag angenommen wird, wie sollen Nicht-Administratoren BOA werden können?" Wahlmöglichkeit: Ernennung durch Bürokraten/Wahl/Enthaltung - Einfache Mehrheit. --Count Count (Diskussion) 13:18, 6. Jul. 2020 (CEST)

Ich verstehe euren Einwand. Der Status quo ist allerdings noch nie zur Abstimmung gestanden, wir hatten das damals ad-hoc so gemacht, weil die Zeit drängte. Deshalb habe ich diese Variante mit aufgelistet. Ich dachte an Leute, die eine ganz andere Methode vorziehen würden, beispielsweise einen einfacheren Wahlmodus, oder [frei erfunden] "Benutzeroberfläche soll nur noch durch WMF-Mitarbeiter verändert werden". Wenn eine Mehrheit hier abstimmt, müsste man deren Wünsche auswerten und ggf. ein neues MB daraus machen. --MBq ^Disk 13:23, 6. Jul. 2020 (CEST)

Wer weder für den Status Quo ist, noch für die anderen Vorschläge, soll sich enthalten. Man die Überschrift auch Ich bin für keinen der Vorschläge 1-3 (Enthaltung) nennen. --Morten Haan 🏄 Wikipedia ist für Leser da 🧉 Übersichtliche Artikelkriterien 16:01, 6. Jul. 2020 (CEST)

MBqs Einwand halte ich bzgl. der getrennten Abstimmung für nachvollziehbar, der Status Quo sollte erkennbar zur Abstimmung stehen. Meinen Ursprungsvorschlag nochmal aufgegriffen: wären die Anwesenden mit Folgendem einverstanden?:

• Vorschlag 1 → Status Quo; Vorschlag 2 → Vorschlag 1; Vorschlag 3 → Vorschlag 2
• Abstimmung
  • Ich bin für die Beibehaltung des Status Quo
  • Ich bin für die Umsetzung des Vorschlags 1
  • Ich bin für die Umsetzung des Vorschlags 2
  • Enthaltung

-- hgzh 20:03, 6. Jul. 2020 (CEST)

OK von meiner Seite —MBq ^Disk 20:26, 6. Jul. 2020 (CEST)

Man hat eine Stimme in der Abstimmung? Dann sehe ich die Gefahr, dass keiner der Punkte die 50%-Hürde überschreitet, insbesondere weil Vorschlag 1 und 2 konkurrieren. --Count Count (Diskussion) 20:32, 6. Jul. 2020 (CEST)

Man könnte es so machen:

• Änderung?
  • Pro Änderung
  • Contra Änderung (Status Quo)
  • Enthaltung
• Welcher Vorschlag?
  • Vorschlag 1
  • Vorschlag 2
  • Enthaltung

--Morten Haan 🏄 Wikipedia ist für Leser da 🧉 Übersichtliche Artikelkriterien 22:35, 6. Jul. 2020 (CEST)

Das entspricht ungefähr Count Counts Vorschlag oben. Für mich auch OK, kann ich heute nachmittag einsetzen. - Ich würde sagen, bei dieser eher wenig bedeutsamen Regeländerung reichen einfache Mehrheiten aus. —MBq ^Disk 06:06, 7. Jul. 2020 (CEST)

Angriffsvektor klein halten...

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)

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)

Neusprech

Muss dieses gruselige "UserInnen" wirklich sein? Und wenn ja, warum ist nur "UserInnen" so gruselig verunstaltet? Da gibts noch etliche Worte, die generisches Maskulinum verwenden. Danke fürs wegmachen. --Wurgl (Diskussion) 15:35, 7. Jul. 2020 (CEST)

Tja, was soll ich sagen... das Binnen-I ist natürlich Geschmackssache, gibt andere orthographische Varianten, ich reklamiere das Recht des Initiators, eine davon auszuwählen. Der Text ist politisch, nicht enzyklopädisch. Ich gendere mit Absicht, weil ich zeigen möchte, dass wir auch - und besonders - Frauen auffordern wollen, sich für solche Ämter zu engagieren. Kann sein, dass ich was vergessen habe, das ist aber vor diesm Hintergrund nicht so wichtig. Gruss, --MBq ^Disk 16:40, 7. Jul. 2020 (CEST)

Unterstützer ? Warum nicht UnterstützerInnen?

Benutzer ? Warum nicht BenutzerInnen?

Benutzeroberflächenadministratoren ? Warum nicht BenutzeroberflächenadministratorInnen?

Initiatoren ? Warum nicht InitiatorInnen?

Und das ist nur bis einschl. der ersten Überschrift. Ich finde es einfach nur blöde wenn man dieses Innen verwendet, aber noch blöder finde ich es, wenn man es nicht durchgängig verwendet. --18:18, 7. Jul. 2020 (CEST) (unvollständig signierter Beitrag von Wurgl (Diskussion | Beiträge) )

„Zwar sind fast alle Änderungen der Benutzeroberfläche unkritisch“

… so heißt es derzeit umseitig.

• Die Ausarbeitenden sind lustig.
• Das hat schon seinen tieferen Grund, warum global der Zugriff auf die JS/CSS-Ressourcen für Admins unterbunden wurde.
• An kritischen Änderungen würden mir einfallen:
  • Verbindung eines Benutzerkontos mit der IP-Adresse und der Browser-Charakteristik
  • Protokollierung jedes Zugriffs jedes Lesers irgendeiner unserer Seiten mit: URL der Seite, IP-Adresse und der Browser-Charakteristik auf beliebigen Fremdservern.
  • Ausspähung der Beobachtungsliste sowie E-Mail-Adresse registrierter Benutzer.
• Einen Review-Prozess oder Sicherheits-Audit kennt die deWP nicht.
• Man hat global den Zugriff auf die Ressourcen auf nur sehr wenige Accounts pro Projekt beschränkt, weil für kommerzielle wie staatliche Interessenten die Analyse von Nutzern und Browser-Fingerprint und damit Zuordnung zu realen Personen und deren Wiki-Interessen sowie Autorenschaft hochinteressant sind.
• Ich bin mit der derzeitigen Ausarbeitung des MB äußerst unzufrieden; habe jedoch zu wenig Zeit, um mich momentan intensiver darum zu kümmern.
• Ich werde sporadisch mit einigen Abschnitten hier aufschlagen; auf der Vorderseite müsste die momentane verharmlosende Darstellung jedoch von den Erstautoren grundlegend umgeschrieben werden.

VG --PerfektesChaos 17:36, 7. Jul. 2020 (CEST)

Hi PerfektesChaos, das ist ein Missverständnis, unkritisch <> ungefährlich. Ich suche eine bessere Formulierung. Gemeint ist "wenig konflikterzeugend", d.h. die normale Adminqualifikation im zwischenmenschlichen Bereich (ausgleichend, moderierend, tener dos cojones ...) ist weniger wichtig als technisches Know-how und Projekterfahrung. --MBq ^Disk 17:53, 7. Jul. 2020 (CEST)

Anders als normale Admin-Tätigkeit, die nur projektintern maximal was mit Benutzersperren anrichten könnte, geht es hier um die Realgefährdung politisch Verfolgter, die Aufdeckung der realen Autoren von Textbeiträgen, die Ausbeutung der Interessengebiete von Lesern unserer Seiten hinsichtlich brisanter Themen. Das ist kein Spaß mehr.

Mir sind das jetzt schon numerisch zu viele BOA, wesentlich mehr als technisch-organisatorisch erforderlich wären, zu viele um deren Aktivitäten in Person überwachen zu können. Allerdings beobachte ich praktisch alle relevanten Seiten mit Ressourcen.

Eine unbemerkte oder womöglich vorsätzliche Einschleusung von Schadcode wäre ein GAU. Mir ist schon seit Jahren äußerst unwohl bei dem blauäugigen Umgang mit den Skin-Ressourcen, und ich begleitete auch den globalen Prozess zur Begrenzung von sysop auf BOA. Eigentlich ist Voraussetzung, dass ausschließlich Fachleute Schreibzugriff auf Ressourcen erhalten, die wissen, nach welchen Sicherheitslücken sie gucken müssten. Zwar vertraue ich der persönlichen Integrität aller momentanen BOA, aber vermute, dass weniger als die Hälfte ein Sicherheitsleck erkennen würden. Unser Bestand ist zwar technisch teils uralt, aber mir bisher nicht mit einer gefährlichen Schwachstelle aufgefallen. Es hat seinen tieferen Sinn, warum die enWP die Anzahl ihrer BOA relativ zu den sysop massiv begrenzt.

VG --PerfektesChaos 18:07, 7. Jul. 2020 (CEST)

Vom RL-Schadpotenzial her sind BOA keine untergeordneten Hilfshausmeister für irgendwelchen Technik-Kram, sondern in der Liga der CU und OS zu suchen. Verglichen damit sind Aspekte der umseitigen Vorschläge, ähm, recht seltsam. Ich habe deshalb umseitig eine Klarstellung der Konsequenzen für die Abstimmenden eingefügt. VG --PerfektesChaos 15:04, 9. Jul. 2020 (CEST)

So gesehen wäre es doch besonders sinnvoll, die Auswahl der betreffenden Personen auf eine solide Grundlage zu stellen. Und es spricht zwar dafür, bei der Auswahl große Sorgfalt walten zu lassen, aber nicht notwendigerweise dagegen, auch Nicht-Admins mit der Aufgabe zu betrauen. Insofern ist dieses MB doch zu begrüßen. -- Perrak (Disk) 15:18, 9. Jul. 2020 (CEST)

• Wir haben 24 BOA-Berechtigte + 1 WMDE für einen relativ überschaubaren Anteil an JavaScript (CSS ist zwar nicht absolut ungefährlich, aber bietet nur sehr wenige und dann offenkundige Möglichkeiten, irgendwann mal gar keine mehr) mit sehr wenig Traffic.
• Die enWP hat 12 BOA-Berechtigte + 1 WMF für ein vielfach komplexeres System Community-gepflegter JS-Gadgets. Alle außer WMF sind dort sysop, bei traditionell um 1000 sysop.
• Ich strebe kein BOA an, mache einen Großteil der Aktivitäten an unserem Community-JavaScript und -CSS, und brauche diesen Hut nicht.
• Ich habe noch niemals gesehen, dass über eine Selbstauskunft hinaus irgendeine fachliche Überprüfung erfolgt wäre, eine Sicherheitslücke erkennen zu können und damit bei der „Auswahl große Sorgfalt walten zu lassen“.
• Ich sage mal ganz locker und freihändig: Wir haben Stand heute mindestens viermal so viele BOA-Berechtigte als für eine Abarbeitung der realen Aufgaben erforderlich wären, und mindestens die Hälfte würde Sicherheitslücken nicht erkennen.
• Too many chiefs, no indians.
• Mir ist doppelplusunwohl, jetzt den Wasserkopf noch per Generalvollmachten immer weiter zu vergrößern.
• Wir haben keinerlei verbindlichen Review-Prozess, keinerlei Sicherheitsmanagement, nix. Jeder BOA darf jederzeit spontan alles anstellen was grad in den Sinn kommt, ohne Kontrolle. Es gibt keinerlei Einschränkungen oder Vorgaben, wer wann warum wo was machen darf. Die ganze Bewusstseinslage ist irgendwie um 2009 bei den „Skriptbastlern“ hängengeblieben, als das noch so ein „Projekt im Aufbau“ gewesen war und ein paar Verrückte irgendwas zusammengewurstelt hatten, das sowieso nur ein paar Jahre halten würde und dem sowieso nichts zu glauben sei.

VG --PerfektesChaos 17:35, 9. Jul. 2020 (CEST)

Schon richtig, aber der Sicherheitsaspekt ist nicht der einzige, sonst würde WMF alle Modifikationen den eigenen Angestellten vorbehalten. Dass wir Freiwilligen unsere Oberfläche selbst verändern können, ist sehr gefährlich - aber es ist auch eine einzigartige Freiheit, die viele freut und motiviert. Kennst Du Jimbos Steakmesser-Gleichnis? Gruss-MBq ^Disk 13:03, 10. Jul. 2020 (CEST)

Es gab vor einigen Jahren im Rahmen der vorangegangenen Sicherheitsdebatte durchaus die Option und starke Befürworter, den Projekten den Zugriff zumindest auf JavaScript komplett wieder zu entziehen. Dies in den Kinderjahren überhaupt mal nach draußen gegegeben zu haben wird allgemein als schwerer Fehler eingestuft.

Nur das Phänomen der etlichen JavaScript-Gadgets der enWP und dass diese dann zukünftig wohl von den WMF-Entwicklern hätten gepflegt werden müssen und alle Änderungen daran global per Phabricator-Ticket zu beantragen wären ließ nach einer anderen Lösung suchen, die die Betreuung bei den Projekten beließ.

Wobei etwa die russisch-, türkisch- oder chinesischsprachigen Wikis sehr engmaschig überwacht werden, was sich dort im Bereich des JavaScript lokal abspielt.

Jedenfalls stellte man es sich so vor, dass die Wikis einige wenige sehr fachkundige Programmierer an die Pflege der lokalen Gadgets setzen würde. Die enWP handhabt das auch so; die sind mir alle vom Namen auch irgendwie als WMF- oder Cloud-Tool-Entwickler geläufig, und ihre Anzahl passt zum umfangreichen JavaScript-Bestand.

Bei uns gab es im ganzen Zeitraum der BOA wohl nur eine oder zwei JavaScript-Änderungen an Community-Gadgets, deren Änderung nicht von mir programmiert worden war, wenn ich das richtig addiere. Dazu wohl noch ein halbes Dutzend Änderungen im BNR, überwiegend bei PDD. Kann mich an sonst kaum was erinnern. Die sind dann meist éinige Tage nach Beantragung auf MW/Ä durch NNW kopiert worden und gut war. Dafür hätten auch zwei BOA gelangt; und würden meiner Ansicht nach für uns als Gesamtzahl plus etwas Reserve als Urlaubsvertretungen für die deWP hinreichen.

Das scheint mir also eher ein Statussymbol zu sein, auch so einen Hut aufzuhaben, und ein erschreckendes Fehlen an Sicherheitsbewusstsein überhaupt (siehe das Zitat, das in diese Abschnittsüberschrift einfloss), erst recht an Fachkompetenz. Bei uns durften schon immer alle Admins jederzeit am JavaScript rummachen, was ihnen grad einfiel, das soll auch immer so bleiben.

Wir haben noch immer keinerlei Review-Prozess oder Sicherheitsmanagement, oder Regeln, welcher BOA wann was an welchem JavaScript machen darf.

VG --PerfektesChaos 15:07, 10. Jul. 2020 (CEST)

Vorschlag 3

Ich halte den Vorschlag für orthogonal zu den anderen und würde ihn entsprechend als zweite Frage "Soll der Zugang zu BOA-Rechten für Dienst-Accounts erleichtert werden?" formulieren. --MGChecker – (📞| 📝| ) 16:43, 9. Jul. 2020 (CEST)

Ich weiss auch nicht recht, wie man PCs Vorschlag "nnnn" integrieren könnte... Wenn die Community sich entscheidet, Nichtadmins zuzulassen, gilt das auch für Dienstkonten der WMDE-Entwickler. Die vorgeschlagenen Auflagen sind m.E. zu kleinteilig für ein MB, die sollten wir später bei WP:BOA diskutieren und ggf. konsensual festlegen. Haftungsrechtlich können wir durch einseitige Erkärungen gar nichts anderes festlegen als im BGB steht. - Sollen wir statt "nnnn" bei den Vorschlägen 1 und 2 ergänzen, dass beide auch für Dienstkonten der Chapter gelten, wobei die genauen Bedingungen noch zu besprechen wären? --MBq ^Disk 12:45, 10. Jul. 2020 (CEST)

Ich halte überhaupt nichts davon in diesem Meinungsbild über einen Sonderweg für sog. „Dienstkonten“ von WMDE/WMAT/WMCH abstimmen zu lassen. Diese sollten genau wie andere Benutzerkonten behandelt werden. WMF-Mitarbeiter können das Recht sowieso einfach per Antrag auf meta bekommen. --Count Count (Diskussion) 12:49, 10. Jul. 2020 (CEST)

Das sehe ich auch so, zumal ich überhaupt nichts davon halte das Recht einer nicht näher spezifizierten Gruppe "Team WMDE" zu geben. --Itti 12:51, 10. Jul. 2020 (CEST)

OK, dann nehme ich den Abschnitt "Vorschlag nnnn" ersatzlos heraus. --MBq ^Disk 13:06, 10. Jul. 2020 (CEST)

Ich halte den Vorschlag durchaus für sinnvoll, aber er ist wie gesagt orthogonal zum Rest. Dass es Regelungen für Dienstkosten der Wikimedia-Organisationen gibt, die von den Regelungen für Community-Mitgliedern abweichen, finde ich an sich ziemlich sinnvoll; und die Entscheidung darüber würde ich gern der Community überlassen. --MGChecker – (📞| 📝| ) 18:43, 10. Jul. 2020 (CEST)

Vielleicht wäre es sinnvoll. Wir sollten aber keine Rechte und Pflichten für WMDE festlegen, ohne das mit dem Verein zu besprechen. Will er die Verantwortung überhaupt? Für mich ist das nicht nur orthogonal, sondern ein anderes Thema —MBq ^Disk 08:03, 11. Jul. 2020 (CEST)

Ich bin sehr dafür, dass technisch versierte Mitarbeitende von WMxx Benutzeroberflächenadministratoren werden können. Das entlastet die anderen und beschleunigt vor allem die Umsetzung. Nichts halte ich dagegen von Team-Accounts. Ich möchte wissen, wer da gerade arbeitet, da sich Vertrauen in die Arbeit einer Person für mich über das (virtuelle) Kennen ableitet. Nicht umsonst sind Sammel-/Gruppenaccounts in der Wikipedia nicht erwünscht. Wie das im Arbeitsvertrag geregelt ist, kann und muss uns egal sein. Baut jemand - aus welchem Grund auch immer - Mist, kann genau ihr/ihm das Recht entzogen werden und im Notfall auch der die/der ChefIn informiert werden. — Raymond ^Disk. 10:03, 11. Jul. 2020 (CEST)

Was Rechte und Pflichten angeht: Wenn dieser oder irgendein anderer Verein für seinen hauptamtlichen Beschäftigten und dessen Tun und Lassen nicht einstehen mag, obwohl dieser arbeitsvertragliche Bindungen hat – wie käme dann die Community oder gar die Bürokraten unter sich dazu, das zu verantworten, was Software der Community im RL der Leser veranstaltet, im Namen von WMDE?

Und was macht der Verein dann groß, wenn ein mutmaßlich eher immaterieller Schaden entstand? Achselzucken, tut uns leid. Okay, war unser Mitarbeiter, das stimmt schon.

Was das Arbeitsgebiet angeht: Wenn die Organisation einen Entwickler anstellt, dann kennen wir den auch nicht, Thiemo ist eine Riesen-Ausnahme zusammen mit wenigen anderen bei der WMDE-IT, die auch im Projekt programmierend und mehrjährig bekannt sind. Wenn Entwicklerin Petra Meier das Gadget Zauberdings entwickelt und pflegt, weiß ich von ihr und den Menschen dahinter auch Null, auch nicht mehr als von einem Team Zauberdings und von daher wär es mir egal.

Wichtig ist die Einschränkung, dass nur die von der Organisation entwickelte Software eigenverantwortlich angefasst werden darf und der ganze Rest dem Community-Review unterliegen muss. Was sich ohne ausdrückliche Aktivierung oder bewusste Nutzung eines Tools abspielt, muss der Kontrolle der Community unterliegen. Wer das Gadget Zauberdings aktiv startet, muss sich halt mit dem auseinandersetzen was das halt so macht.

Niemand muss BOA sein, um eine Änderung der Ressourcen umzusetzen. Das ist nur erforderlich, um es ohne Review ohne irgendwen zu fragen einfach mal so aus der Lameng machen zu können.

VG --PerfektesChaos 16:56, 11. Jul. 2020 (CEST)

Vorschlag zu Dienst-Acoounts

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.

Jeder Dienst-Account von WMAT, WMCH, WMDE, WMF kann ein BOA-Recht außerhalb der Community-Prozedur erhalten.

• Das gilt auch für nicht-personengebundene Accounts, etwa ein Benutzer:Team Zukunft (WMDE) als anonyme Gruppe.
• Das schließt auch mögliche zukünftige oder sonstige Organisationen unter dem Dach der WMF ein, die ein berechtigtes Interesse geltend machen können.
• Ein Anspruch auf die Gruppenzuordnung besteht nicht.

Die entsendende Organisation (etwa WMDE oder eine zuständige Abteilung) muss dem Wunsch zustimmen bzw. den Antrag stellen.

• Sie bleibt für die Aktivitäten des Benutzerkontos verantwortlich.
• Über Arbeitsverträge usw. gibt es die Möglichkeit, auf die Personen zurückzugreifen.
• Das Verfahren ist wie jedes andere auch über Wikipedia:Benutzeroberflächenadministratoren/Anträge für die Community transparent abzuwickeln.

Jede auf diesem Weg eingeräumte BOA-Eingruppierung ist an die Auflage zu knüpfen,

• dass selbstständige Aktivitäten im Kontext von Software stehen müssen, die diese Organisation früher entwickelt hatte und jetzt weiter betreut oder die zukünftig neu entwickelt und erprobt werden soll
• und deren Wirkung auf Wikipedia-Benutzer beschränkt bleibt, die aktiv für eine Funktionalität optiert hatten oder eine solche neue Funktionalität aktiv starten.
• Was Wirkung auf alle Benutzer hätte, und bisherige und sonstige Funktionalitäten beträfe, müsste wie bei jedem anderen Änderungswunsch durch andere BOA auf WP:MW/Ä vorgeschlagen und erörtert werden.

Pro

To be completed by originator and supporters

Kontra

To be completed by originator and supporters

VG --PerfektesChaos 15:22, 10. Jul. 2020 (CEST)

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)

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)

Anzahl der BOA beschränken?

Wenn wir den plausiblen Ausführungen von PerfektesChaos auf dieser Seite folgen, haben wir eigentlich jetzt schon zu viele BOA ("Wir haben Stand heute mindestens viermal so viele BOA-Berechtigte als für eine Abarbeitung der realen Aufgaben erforderlich wären"). Es ist auch nachvollziehbar, dass deren Anzahl aus Sicherheitsgründen beschränkt sein sollte, da man als BOA ziemlich viel Unsinn und Gefährliches anstellen könnte, wenn man darauf aus wäre. Wir haben ja auch bewusst nur ganze wenige Checkuser-Berechtigte. Mir stellt sich also die Frage, ob nicht zugleich mit der Frage, ob man als BOA Admin sein muss, geklärt werden sollte, wieviele BOA wir überhaupt haben wollen/müssen. Eine Möglichkeit wäre wohl ein "Moratorium": Die Zahl wird auf dem aktuellen Stand eingefroren (das sind ja laut PC eigentlich schon zu viele, aber wir wollen wohl niemandem die Rechte entziehen) und die Rechte werden nur noch vergeben, wenn ein Platz frei wird. Gestumblindi 14:16, 11. Jul. 2020 (CEST)

eigentlich ist das Kriterium ja nicht die absolute Anzahl, sondern die zeitnahe Abarbeitung der Aufgaben. Man könnte z.B. zum Ziel setzen, Request sind im Wochenmittel innerhalb 12 oder 24 Stunden abzuarbeiten, gelingt das nicht wird die Soll-Zahl um 1 erhöht. andy_king50 (Diskussion) 20:01, 11. Jul. 2020 (CEST)

Es wäre auch denkbar, denjenigen BOA, die beispielsweise ein Jahr lang die Rechte nicht nutzen, diese zu entziehen. --Ameisenigel (Diskussion) 20:08, 11. Jul. 2020 (CEST)

Auf Bitten der Bürokraten hab ich vor (fast) zwei Woche eine Quarry getippt: quarry:query/46201 Ich sehe da 6 Admins, die das Recht nicht nutzen, es also offensichtlich nicht benötigen. Rein im Sinne von PC's Sicherheitsbedenken und nicht wegen Degradierung(!) könnte man dieses Recht bei diesen 6 entziehen (einer hat das Recht ganz frisch bekommen, da war natürlich noch nix zu sehen). --Wurgl (Diskussion) 22:04, 11. Jul. 2020 (CEST)

Ich halte grundsätzlich nichts von Karteileichen und wenn wir die Anzahl der BOA beschränken, halte ich es sogar für dringend geboten, das Recht Benutzern wieder zu entziehen, die es nicht nutzen. --Morten Haan 🏄 Wikipedia ist für Leser da 🧉 Übersichtliche Artikelkriterien 22:59, 11. Jul. 2020 (CEST)

Meiner Meinung nach könnte man, gerade bei diesem Recht, sogar nur 6 Monate ansetzen und die Anzahl auf zunächst 20 begrenzen, vielleicht später sogar auf nur 10. Ich würde es aber gern vermeiden, Anreize zu schaffen, an seinen Rechten zu kleben, weil man "die ja sonst nie wieder bekommt", wegen dem Moratorium. @Wurgl: Mich verwirren die dritte und vierte Spalte. Zumindest bei Doc Taxon ist das nicht der letzte Edit in der Funktion, und viele der aufgeführten Änderungen erfordern keine BOA-Rechte. --MGChecker – (📞| 📝| ) 23:36, 11. Jul. 2020 (CEST)

DIe dritte Spalte sagt, wieviel Bearbeitungen in den Namensräumen gemacht worden sind. Und die vierte Spalte zeigt die letzte Bearbeitung im Zeitmodus YYYYMMDDHHMMSS an. Die Abfrage ist übrigens auch schon etwas her (28. Juni 2020). --Funkruf ^WP:CVU 23:43, 11. Jul. 2020 (CEST)

Nein! Die dritte Spalte ist der Namespace der letzten Bearbeitung! 8=MediaWiki und 2=Benutzer Und spalte 4 ist das Datum der Bearbeitung im Format YYYYMMDDHHMMSS (Jahr, Monat, Tag, Stunde, Minute, Sekunde in UTC, also je nach Normalzeit/Sommerzeit 1 oder 2 Stunden gegenüber unserer Uhrzeit verschoben). Die Anzahl der Bearbeitungen führt wahrscheinlich zu einem Timeout, weiß nicht ob ich das mit einer Query schaffe. Die Einschränkungen der Sichtbarkeit von Versionen führen zu so komplexen Abfragen, dass die Datenbank bei der Datenmenge nicht zurechtkommt. Daher nur kommt nur "Wann hat der Benutzer zuletzt dieses Recht benutzt und welche Datei /welcher Namespace". Funkruf hat eben (übrigens damals auf meine Bitte) Benutzer:APPER/WikiHistory.js geändert, bzw. NordNordWest hat MediaWiki:Protectedpagewarning angefasst. --Wurgl (Diskussion) 23:53, 11. Jul. 2020 (CEST)

Die Anzahl siehst du hier: quarry:query/46596 --Wurgl (Diskussion) 00:15, 12. Jul. 2020 (CEST)

Danke für die Aufklärung. Funkruf ^WP:CVU 00:46, 12. Jul. 2020 (CEST)

Einmal noch, dann begebe ich mich in die Furzkuhle: quarry:query/46201 behandelt wer hat wann zuletzt was mit diesen Rechten gemacht bzw. wer benötigt/verwendet das Recht überhaupt, quarry:query/46596 zeigt wie oft was gemacht wurde bzw. wie oft benötigt/verwendet. Diese beiden sind für css und javascript. Also fehlt noch die Einschränkung auf das kritische Javascript quarry:query/46598 für die Frage: Haben die Rechteinhaber genügend Wissen um "Schweinereien" in Javascript zu erkennen. Jemand mit wenig Ahnung bzgl. Javascript der nur css-Scripte ändert bzw. nur bei den Texten von Mediawiki herummacht ist eher kein Problem (wobei es natürlich auch darum geht, was die Personen tatsächlich machen, das kann so eine Query nicht auswerten, die Query kann nur quantitativ auswerten). Bei allen Rechteinhabern ist natürlich die Frage: Sind die Accounts gehackt bzw. sind die Accounts hackbar (aka. unsicher). --Wurgl (Diskussion) 01:22, 12. Jul. 2020 (CEST)

• Die Frage, wie viele BOA ein Projekt eigentlich benötigt, hängt mit der Organisation der Software-Pflege und den Verantwortlichkeiten zusammen.
  • Hier hat die deWP und insbesondere ihre Adminschaft im letzten Jahrzehnt wenig vorangebracht.
  • Schnark und ich hatten uns mehrfach dazu ausgetauscht, und wenn wir auch öfters unterschiedliche Ansichten im Detail haben, so sind wir doch in den Grundsätzen und in den Fragen hier in großer Übereinstimmung und ich sehe mich mit ihm insoweit großflächig nicht im Dissens.
• Kernstück ist der fehlende Review-Prozess. Ich schildere mal im nachstehenden etwas längeren Kasten, wie ich diesen schon vor mehreren Jahren und insbesondere auch 2018 bei Einführung der BOA mal skizziert hatte, was aber praktisch reaktionslos blieb.

Review

• Alle Änderungen sind vorab auf WP:MW/Ä vorzuschlagen.
• Davon ausgenommen ist eine Not-Deaktivierung von Komponenten, etwa wegen mutmaßlicher böswilliger Schadfunktion oder kompletter Unbrauchbarkeit wesentlicher Teile des Projekts, insbesondere für Leser. Abschaltungen können unverzüglich erfolgen.
• Gleichfalls kann sofort ein rollback auf eine frühere als stabil bekannte Version erfolgen, wenn sich in den Tagen oder Wochen nach einer Änderung herausstellt, dass eine kürzliche Modifikation doch nicht das Gelbe vom Ei war.
• Die Community muss je nach Art der konkret dargestellten Absicht (entsprechend einem Patch) ein, drei, fünf Tage Zeit haben, sich das vorher anzusehen und auf mögliche unbeabsichtigte Nebenwirkungen oder gar sicherheitsmäßige Bedenken zu untersuchen.
• Wenn keine stichhaltigen Einwände erhoben werden, kommt bei planmäßigen Änderungen nach ein paar Tagen ein BOA vorbei, prüft die Umstände (Versionsgeschichte, Bearbeiter passen? Auffällige Programmierungen, die wir nicht dulden sollten?) und pflegt das wie vorgeschlagen ein, falls das sinnvoll erschiene.
• Das gilt auch für CSS.
  • Theoretisch bestünde auch bei CSS zurzeit noch ein Sicherheitsrisiko.
  • Wenn irgendwann der neue Gadget-Namensraum von 2015 in Betrieb ginge, könnte man für CSS nach menschlichem Ermessen Sicherheitsprobleme ausschließen.
  • Böswilliges CSS ist wegen mangelnder Dynamik dieser Sprache jedoch so augenfällig, dass es bei kurzer Durchsicht auch jetzt schon sofort ins Auge springen würde.
  • CSS führt seiner Natur nach zu Veränderungen in der Dekoration. Das mag nicht jeden Geschmack treffen. Kann auch sein, dass irgendeine Seitendarstellung mal für ein paar Stunden kaputt aussieht. Das kann bei jedem Edit an Vorlagen und Artikeln aber auch passieren.
• JavaScript wie auch andere komplexe Programmierungen haben im Vorfeld gründlich getestet zu werden; unter Berücksichtigung aller verfügbarer Szenarien, die halt gehen.
  • Es muss also sowieso in einer Test-Umgebung, auf BETA oder in einem BNR oder auf der privaten Festplatte, eine sich allmählich entwickelnde Version geben.
  • Zur Entwicklung selbst sind keinerlei BOA-Rechte erforderlich.
  • Diese braucht es erst hinterher, nach der Erprobung der beabsichtigten Änderung und dem Review, zum Kopieren des vorgeschlagenen Codes.
• Im Review-Prozess müsste es zurzeit noch eine Ausnahmeregelung für triviale Änderungen an Benutzer:PDD/markAdmins.js geben; also das Hinzufügen oder Entfernen eines Nick in den Gruppen.
  • Hierzu bin ich bereits per WP:MW/Ä #markLinks mit einem Nachfolgekonzept aktiv geworden, das die historische Architektur und die Notwendigkeit von BOA hierfür überwinden soll.
  • Die derzeitig wirksame BNR-Programmierung habe ich auf der Beo, ein paar andere sicher auch; da dräut einstweilen keine Gefahr.
• Der Review-Prozess betrifft nur die von der Community gepflegten Ressourcen, also das, was in den Namensräumen MediaWiki: bzw. irgendwann Gadget: passiert.
  • Wie mit den technisch möglichen aber nicht mit dem Benutzer abgesprochenen Bearbeitungen im BNR verfahren werden soll ist unklar.
  • Grundsätzlich ist für ein Skript im BNR immer der Account verantwortlich, dessen Name zwischen Doppelpunkt und erstem Schrägstrich steht.
  • Es gibt Skripte im BNR von nicht mehr aktiven Benutzern, die aber von anderen Benutzern weiter verwendet werden. Diese sind irgendwie herrenlos, ungepflegt, und werden hin und wieder aber selten von BOA not-repariert.

• Zurück zur Ausgangsfrage dieses Abschnitts: Wie viele BOA braucht es eigentlich?
  • Nach dem Review-Prozess und für Notfälle müsste eine nahezu 24/7-Abdeckung kurzfristig organisierbar sein; planmäßige Änderungen nach Review haben ein oder mehrere Tage Vorlauf.
  • OS und CU leisten sowas Ähnliches.
  • OS/CU stehen immer so bei vier, fünf Greteln und Hanseln über die Jahre, wenn ich richtig mitzähle; problemlos würde ich auf sechs BOA als Mindestbestand kommen, einschließlich Urlaub und Krankheit (Gesundheit und ein langes Leben wünsche ich allen Mitlesenden). WMF und Stewards können bei absoluten Notfällen deaktivierend binnen Minuten eingreifen.
  • Mit zurzeit über zwanzig sehe ich nicht wirklich einen Personalengpass, wodurch sich mir die Zielsetzung umseitigen MBs auch nicht ganz erschließt.
  • Wir haben ganz bewusst einen eher mageren Bestand an Community-gepflegten Gadgets.
• Stellt sich mir eine weitere Frage: Was dürfen und können BOA eigentlich unter welchen Bedingungen?
  • In den Jahren seit um 2006, als technisch diese „Skriptbastelei“ durch die WMF ermöglicht wurde (was einige dort inzwischen bedauern), gab es in der deWP meines Wissens noch nie eine klare Regelung, welcher der 200 Admins (inzwischen BOA) nach welchem Vorlauf was wo verändern dürfe oder solle.
  • Welche Qualifikation müssten BOA eigentlich auf- bzw. nachweisen, um insbesondere böswillige Haken vor der produktiven Aktivierung zu erkennen?
• Ich sehe nicht, dass wir fachlich eine Personaldecke hätten, die über die Pflege der in Teilen verrotteten, in Teilen vorrangig durch mich modernisierten Bestands-Gadgets noch viele neue eigene Gadgets lokal werden anbieten können. Hier wird man dann wohl auf global durch die WMF gepflegte und verantwortete Gadgets zurückgreifen müssen.
  • Eine Alternative sind die Benutzerskripte, von denen es Dutzende gibt. Hier ist aber die Verantwortlichkeit für die Pflege eindeutig: immer was zwischen Doppelpunkt und erstem Schrägstrich steht.
• TL;DR: Um Programmierungen für Community-Gadgets zuzuliefern ist es nicht erforderlich BOA zu sein; ein guter Teil der aktuellen Codes ging über meine Tastatur und ich bin Nichtadmin und Nicht-BOA.
  • Insbesondere wird nicht an den produktiv wirksamen Versionen entwickelt, wo für jede Bearbeitung BOA-Rechte erforderlich wären, sondern es wird erst etwas entwickelt und erprobt, dann zum Review gestellt und dann einkopiert.

VG --PerfektesChaos 15:42, 13. Jul. 2020 (CEST)

Danke, aufschlussreich. -jkb- 16:06, 13. Jul. 2020 (CEST)

OK, kannst du dann bitte ein eigenes MB zu deinem Thema dazu machen und deinen Wunsch vortragen, PerfektesChaos? Dieses Meinungsbild ist leider nicht der richtige Ort. Das einzige was damit erreicht wird, ist das es zu Erosionen kommt. Siehe unten. LG, Funkruf ^WP:CVU 16:34, 13. Jul. 2020 (CEST)

• Das Problem an dem umseitigen MB ist, dass schon seit 2018 und letztlich 2008 völlig unklar ist, was wann wo ein BOA tun darf und was nicht, unter welchen Voraussetzungen kritische Programmierungen verändert werden dürfen.
• Jetzt sollen gemäß Titel des umseitigen MB weitere und gemäß Überschrift Nichtadmins ebenfalls BOA werden, auf Beschluss der Bürokraten laut Vorschlag 1, und es ist immer noch nicht klar was wann wo diese dann tun sollen, nach welchen vorherigen Absprachen, aber sie erhalten schon mal die Berechtigungen dafür.
• Mit dem für kritische Software-Entwicklungen üblichen Review-Prozess bedarf es sechs, von mir aus zehn BOA. Wozu brauchen wir dann immer mehr und immer mehr BOA, wie es das MB anstrebt?
• Um JavaScript zu entwickeln, muss man noch nicht mal angemeldeter Benutzer sein oder eine Seite im BNR haben. Ich schaff das auch so.
• Ich verstehe das wirkliche Ziel dieses umseitigen MB nicht.

VG --PerfektesChaos 17:38, 13. Jul. 2020 (CEST)

• Auslöser war der BOA-Antrag von Thiemo Kreuz (WMDE), siehe umseitig in der Problembeschreibung.
• Um Nicht-Administratoren wie z.B. ihm das Recht temporär oder permanent zu erteilen, braucht es nach Ansicht der Bürokraten einen von der Community abgesegneten Prozess. Ich denke, ein Großteil der Unterstützer dieses MBs teilt diese Ansicht.
• Ein Vorschlag, der ausschließlich WMDE/WMCH/WMAT-Angestellten oder -Gruppen-Dienstaccounts die Erlangung von BOA-Rechten ohne Community-Beteiligung ermöglicht, so wie du es dir vorstellst, halte zumindest ich nicht für mehrheitsfähig.
• Ich gehen davon aus, dass die Bürokraten die Vergabe dem Risiko angemessen restriktiv handhaben (< 1 Vergabe/Jahr).
• Eine Begrenzung der Anzahl der Administratoren, die BOA-Rechte haben dürfen, oder eine Verfallsregelung für die Rechte bei Nicht-Gebrauch, etc. sollten meiner Meinung nach nicht Gegenstand dieses Meinungsbildes sein. Das könnte man ggfs. in einem weiteren Meinungsbild zur Abstimmung bringen. --Count Count (Diskussion) 18:10, 13. Jul. 2020 (CEST)

Community-JavaScript-Edits durch BOA der deWP
für die letzten zwölf Monate

BOA@deWP	MediaWiki:***.js	Difflink / Zeitstempel (UTC)
Artregor	Gadget-Direct-link-to-Commons.js	2019-09-29 104107
Doc Taxon	Gadget-contribsrange.js	2019-08-15 090257
Itti	Gadget-old-movepage.js	2019-07-27 104730
NordNordWest	Gadget-navigation-popups/de.js	2019-07-22 195043
NordNordWest	Gadget-navigation-popups/de.js	2020-01-01 160357
NordNordWest	Gadget-navigation-popups/de.js	2020-01-01 160512
NordNordWest	Gadget-navigation-popups.js	2020-01-14 085213
NordNordWest	Gadget-navigation-popups.js	2020-01-14 142403
NordNordWest	Gadget-navigation-popups/de.js	2020-01-18 143643
NordNordWest	Gadget-navigation-popups.js	2020-01-18 143809
Raymond	Guidedtour-tour-einfuhrung.js	2020-05-04 091734

Credits2Wurgl --PerfektesChaos 12:55, 15. Jul. 2020 (CEST)

Feedback

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. @PerfektesChaos, MBq: als Info. --Itti 14:46, 13. Jul. 2020 (CEST)

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)

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)

"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)

Eins ist irgendwo hier oben, denke ich, sonst da. -jkb- 00:10, 14. Jul. 2020 (CEST)

Ich verstehe nichts, vor allem nicht die Aufregung. --Felistoria (Diskussion) 00:32, 14. Jul. 2020 (CEST)

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)

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)

Ju. -jkb- 00:54, 14. Jul. 2020 (CEST)

+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)

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)

Gesamtkonzept für BOA

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)

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)

Startklar?

Liebe Unterstützer, vielen Dank für eure Beteiligung und die angebrachten Verbesserungen. Aus meiner Sicht ist das MB nun startklar - oder was meint ihr? Mein Vorschlag wäre, die Abstimmung vom 1. - 14. August durchzuführen.

Was die weiterführenden Vorschläge angeht, die BO-Arbeit ganz neu zu organisieren, eventuell mit Beteiligung von Hauptamtlichen der Chapter, und mit einer strukturierten Review-Prozedur: das sind IMHO sinnvolle Ideen. Nur denke ich, das kann hier nicht mitbehandelt werden, braucht einfach mehr Gespräche und Ausformulierung, damit die Community schließlich darüber entscheiden kann. Unter Zeitdruck kommt es sonst zu Mißverständnissen und Verstimmungen, wie wir gesehen haben. Mein Vorschlag wäre, das auf WP:MW/Ä oder einer Unterseite davon vorzubereiten. Gruss --MBq ^Disk 09:33, 15. Jul. 2020 (CEST)

Es ist alle zwei bis drei Wochen eine BOA-Aktion erforderlich (die einen oder mehrere Edits betreffen kann).

Dafür stehen zurzeit 20 Berechtigte zur Verfügung.

Es gibt überhaupt keinerlei Eile, jetzt forciert dieses MB loszutreten, um überhastet einen vorgeblichen Personalnotstand zu beseitigen, ohne geklärt zu haben, was denn diese vielen neuen BOA hinterher dürfen und machen sollen.

Der MB-Entwurf macht den dritten Schritt vor dem ersten; dann ist es kein Wunder wenn man sich verstolpert.

Die sinnvolle Reihenfolge wäre:

1. Was sind Aufgaben und Befugnisse von BOA?
2. Wie viele BOA benötigt das Projekt, um diese in angemessener Zeit wahrnehmen zu können?
3. Wenn die vorhandene Anzahl der Berechtigten dafür offenbar dauerhaft nicht ausreicht – unter welchen konkret und präzise beschriebenen Auflagen könnte für Sonstige (=Nicht-Admins) zusätzliches Personal rekrutiert werden?

Ich rate dringend von der momentanen Zielrichtung ab, zuallererst eine Generalvollmacht für technische Möglichkeiten zu verteilen, und dann hinterher anzufangen darüber nachzudenken wer wann was wozu mit den technischen Möglichkeiten anstellen solle.

VG --PerfektesChaos 12:51, 15. Jul. 2020 (CEST)

Es geht nicht darum "überhastet" etwas zu klären, es geht darum zu klären, ob jemand ohne Admin-Rechte die BOA-Rechte überhaupt bekommen kann. Müssen wir nicht klären, wir können sie ihm auch einfach entziehen. Gruß --Itti 13:03, 15. Jul. 2020 (CEST)

Das ist richtig, und wenn mir bspw. zwei Leute einfallen sollten, die nicht Admins sind sich aber ausgezeichnet hierfür eignen würden, so wären es Benutzer:PerfektesChaos und Benutzer:Schnark. Wenn die aber (vertretungsweise durch den ersten) vor einer allzuschnellen Abstimmung von etwas, was nicht reif ist, abraten, so ist das für mich ein Zeichen. -jkb- 13:41, 15. Jul. 2020 (CEST)

Ich verstehe nicht, wo das Problem liegt. Darin, dass die Bürokraten die Rechte nach ihrem Ermessen vergeben und es keine Obergrenze für die Anzahl ihrer Träger gibt? Es ist doch völlig gleich, ob es jetzt fünf oder zwanzig BOA gibt, solange die alle vertrauenswürdig sind. Die fünf Bürokraten, die wir haben, haben doch genug Mandat und Standing, dass man ihnen zutraut, diese Rechte nicht einfach an irgendwen zu vergeben. Hier geht es doch nur darum, die BOA-Rechte von der bisher notwendigen Adminwahl abzukoppeln. – Siphonarius (Diskussion) 14:09, 15. Jul. 2020 (CEST)

Ich habe das MB an sich nicht so verstanden, dass man hinterher "diese vielen neuen BOA" hätte. Es ghet darum, einzelnen Leuten die Rechte einzuräumen, ohne dass diese unbedingt Admin sein müssen. Dass das natürlich immer noch eher wenige sein sollte, liegt doch auf der Hand.

Ganz davon abgesehen: Zur Zeit dürften die Bürokraten prinzipiell jeden zum BOA machen, es gibt keinerlei Beschränkung in den Regeln. Egal, was bei diesem MB herauskommt, es schränkt die Möglichkeiten ein, es weitet sie nicht aus. -- -- Perrak (Disk) 17:11, 15. Jul. 2020 (CEST)

• Was WMDE angeht, so hatte ich hierfür bereits oben per #Vorschlag zu Dienst-Acoounts einen Lösungsweg in das MB hineingeschrieben, der jedoch wieder eliminiert wurde.
• Was die Community ansonsten angeht, so gibt es bei einer BOA-Aktion alle zwei, drei, vier Wochen und zwanzig dazu Berechtigten keinerlei Problem, das dringend gelöst werden müsse.
• Das MB ist deshalb grottenschlecht ausgearbeitet, weil es lediglich von der Freischaltung einer Software-Funktion handelt, ohne auch nur mit einer halben Silbe darauf einzugehen, was denn hinterher nach der technischen Freischaltung passieren solle. Was ist das eigentlich, ein BOA, der da ermächtigt werden soll? Was dürfen die, mit wem müssten sie sich vorher absprechen, was dürfen sie nicht; was genau sollen sie eigentlich machen?
• Nach traditioneller Lesart seit 2005 darf jeder Admin/BOA jederzeit spontan überall alles umprogrammieren, ohne sich mit irgendwem koordinieren zu müssen. Und Negativbeispiele dazu habe ich so einige unmittelbar vor Augen. Diese Politik nahtlos und ungebrochen fortzusetzen strebt der momentane MB-Tenor an.
• Seriös wäre es, zunächst mal zu definieren, was für Befugnisse mit diesem ominösen „BOA“ verbunden wären, und das den Abstimmenden auch glasklar und unmissverständlich zu kommunizieren. Erst danach kann die Community sinnvoll darüber abstimmen, wie was wann wem sie mittels welcher Prozeduren diese Befugnisse erteilen möchte.
• Dass die Bürokraten so verbissen einen schnellstmöglichen Start durchzudrücken versuchen, um die Abstimmenden eine Katze im Sack und unklares Wischi-Waschi ihrem Vertrauensvorschuss abkaufen zu lassen, macht mir die undurchschaubaren Ziele dieser Hauruck-Aktion äußerst verdächtig.

VG --PerfektesChaos 12:52, 16. Jul. 2020 (CEST)

Sehr verdächtig oder man schaut mal hier und erkennt ganz klar den Auslöser für das Meinungsbild und das da ein Dienst-Account derzeitig die BOA-Rechte hat ohne Admin zu sein. Damit das schnellstmöglich auf einer Community-Entscheidung fußt oder eben entzogen wird, wollen die Bürokraten halt eine gewisse Zügigkeit bei der Prozedur. Dir steht es jederzeit frei ein MB vorzubereiten und vorzuschieben, welches das entsprechend regelt, aber das gehört hier nicht rein. --ExtremPilotHD (Diskussion) 12:59, 16. Jul. 2020 (CEST)

Was sehr sauber mit #Vorschlag zu Dienst-Acoounts unter der Verpflichtung, nur WMDE-eigene Software bearbeiten, sehr schnell zu lösen wäre.

• Da steht konkret und präzise drin, für was Chapter am Review vorbei („selbstständige Aktivitäten“) eine Befugnis erhalten würden.
• Über die aktuelle Causa Thiemo hinaus gibt es nichts, was zu regeln wäre.

Ich finde jedoch umseitig sehr ausgedehnte Generalvollmachten, nach denen auf undurchsichtigen Wegen eine über Checkuser hinausgehende Gewalt zu verteilen einem kleinen Zirkel übertragen werden soll, ohne dass es die allerallergeringste Notwendigkeit dafür gibt, und noch nicht einmal klar ist, welche Regeln einzuhalten wären; zur Zeit gibt es unbeschränkte Befugnisse für jeden BOA, zu tun und zu lassen was immer man wolle.

Bei einer Aktion alle paar Wochen und zwanzig BOA der Community (es gibt auch noch global tätige) ist völlig unbegreiflich, worin diese Eile „schnellstmöglich“ für eine völlig unbestimmte, im Nebel liegende Geschichte begründet wäre.

VG --PerfektesChaos 13:26, 16. Jul. 2020 (CEST)

Es gibt keine „Generalvollmacht“, denn die Rechte werden nicht an jeden beliebigen Benutzer vergeben werden, und „undurchschaubare Ziele“ mit Sicherheit auch nicht. Gerade angesichts des letzten Satzes aus deinem Beitrag von 12:52 Uhr, du übertreibst mit deinem Misstrauen. Das ist im Grunde auch das, was ich geschrieben habe: Problem ist für dich offenbar, dass ein „kleiner Zirkel“, nämlich die Bürokraten, darüber entscheidet. Aber es war doch jahrelang so, dass dieses Recht ein Kreis von weit mehr als 200 Personen innehatte, und hat’s wen gestört? Jetzt geht es doch erstmal nur darum, dass die Rechtevergabe an einen WMDE-Mitarbeiter durch die Community legitimiert wird. Das ist sie nämlich bislang nicht. – Siphonarius (Diskussion) 14:33, 16. Jul. 2020 (CEST)

Ich widerspreche der Darstellung auf der Vorderseite, dass bisher nur Admins BOA werden konnten, und dass auf dieser Darstellung der Status quo im Abstimmungsprozedere aufgebaut ist. Der eine, spezielle Fall, der zu diesem MB geführt hat, steht völlig konträr zu dieser Darstellung. Das Minimum, das mir notwendig erscheint, ist, diesen Fall transparent anzusprechen und nicht (ungewollt?) vorzutäuschen, das WMDE-Konto hätte keine BOA-Rechte bekommen oder dass dieses dem Status quo entsprechend ein gewählter Admin sei. Auch die Darstellung, dass jener Antrag der erste von einem Nicht-Admin war, entspricht nicht den Tatsachen. … «« Man77 »» Alle Angaben ohne Gewehr. 13:28, 16. Jul. 2020 (CEST)

Wenn das nicht den tatsachen entspricht, dann entferne ich das "erstmals" umseitig einfach. Immerhin erstmals erfolgreich ;-) -- -- Perrak (Disk) 19:53, 16. Jul. 2020 (CEST)

Aufgaben von BOA

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) kl.erg. 22:50, 20. Jul. 2020 (CEST)

Du redest völlig am MB vorbei. Es soll die Lücke zu nicht-Admins schließen, mehr nicht. Wenn du insgesamt das System ändern möchtst, nur zu, starte ein entsprechendes Meinungsbild. Die Rechte für den WMDE-Entwickler werde ich jedoch direkt entziehen, sollte es sich nicht ergeben, dass die Community eine entsprechende Entscheidung wünscht und trifft, denn nach den bisherigen Regeln stehen ihm die Rechte nicht zu. Gruß --Itti 12:50, 15. Jul. 2020 (CEST)

+1 Funkruf ^WP:CVU 13:30, 15. Jul. 2020 (CEST)

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)

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)

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)

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)

@MGChecker: 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)

Option 3 nochmal, jetzt kürzer und vielleicht für alle akzeptabel

Ich versuche einen Kompromissvorschlag, um PerfektesChaos' Bedenken einzubringen. Als dritte Option könnten wir Folgendes dazunehmen. Ich habe PCs Text stark gekürzt. Die Regelungen wo und wie zu konsentieren ist, sind m.E. zu detailliert. Ausserdem kann das nur für persönliche Dienstkonten wie das von Thiemo gelten; Sammelkonten sind weiter oben von mehreren Leuten definitiv abgelehnt worden.

"Vorschlag 3: Ohne Adminrechte können nur persönliche Dienstkonten von angestellten Entwicklern der WMF oder der DACH-Chapter (derzeit WMAT, WMCH, WMDE) bei den Bürokraten befristet BOA-Rechte beantragen. Dabei gelten folgende Einschränkungen: Die entsendende Organisation muss zustimmen und die Verantwortung übernehmen. Diese BOA dürfen nur im Kontext von Software handeln, die ihre Organisation früher entwickelt hatte und jetzt weiter betreut oder die zukünftig neu entwickelt und erprobt werden soll. Wenn bestehende Funktionen geändert werden sollen, oder wenn Benutzer betroffen wären, die nicht aktiv für eine neue Funktionalität optiert hatten oder eine solche neue Funktionalität aktiv starten, müssen die Änderungen mit der Community konsentiert werden.

Pro: Effizient und wenig Konfliktpotential. So zugelassene BOA haben gesichert Fachkunde. Die Gesamtzahl bleibt voraussichtlich sehr niedrig, was vom Sicherheitsaspekt her wünschenswert ist. Ihre Arbeit kann durch die Community kontrolliert werden. Die Verantwortung geht zumindest teilweise auf den Arbeitgeber über. Der aktuelle Fall wäre von der Regelung erfasst.

Kontra: Externe Personen bekommen Zugriffsrechte, von denen Community-Fachleute ohne Adminrechte ausgeschlossen bleiben."

Die Empfehlung der Büros bliebe bei Vorschlag 1, aber mit einem Ergebnis pro 3 hätte ich kein Prob. Was meint ihr dazu? --MBq ^Disk 10:33, 17. Jul. 2020 (CEST)

Dieser Vorschlag ist eine Konkretisierung zu einer bestimmten Benutzergruppe, die per Vorschlag 1 eigentlich mit erfasst wäre. Damit würde dieser Vorschlag in Konkurenz zu Vorschlag 1 treten und beide würden die nötigen Stimmen neutralisieren. Halte ich nicht für gut. Wenn, dann müsste es als Konkretisierung zu Vorschlag 1 und 2 erfasst werden, oder als neutrale Position, über die Abgestimmt wird, die jedoch nur Vorschlag 1 oder 2 konkretisiert, nicht jedoch in Konkurenz dazu steht. --Itti 11:54, 17. Jul. 2020 (CEST)

Natürlich muss das in Konkurrenz stehen, es konkretisiert Vorschläge 1 und 2 nicht, es schränkt sie ein. Wenn V1 oder V2 angenomen würden, wäre diese Option unnötig.

Wäre auch einfach abzustimmen: Jeder Abstimmende hat für jede der drei Optionen eine Stimme. Gewonnen hat der Vorschlag, der die meisten Ja-Stimmen erhält, wenn das gleichzeitig mehr Ja- als Nein-Stimmen sind. Oder, gewonnen hat der Vorschlag, bei dem das Übergewicht der Ja-Stimmen gegen die Nein-Stimmen größer ist, wenn man eine möglichst konsensuale Regel will. -- Perrak (Disk) 17:02, 17. Jul. 2020 (CEST)

Ich habe den Vorschlag jetzt eingesetzt. Ich hoffe, PerfektesChaos' Beschreibung einigermassen sinnerhaltend gekürzt zu haben. Absonsten bitte ändern - allerdings glaube ich nach wie vor, dass die Details noch nicht abstimmungsreif sind. Um die kümmern wir uns, wenn der Vorschlag an sich eine Mehrheit findet. Die drei Varianten sind so formulert, dass sie sich gegenseitig ausschliessen. Die Abstimmung würde so ausgewertet: Änderung ja/nein? Falls >50% pro, gilt der Änderungsvorschlag mit den meisten Stimmen. Wenn es keine Gegenrede gibt, kann das MB in den nächsten Tagen bekanntgemacht werden und die Abstimmung am 1. August starten. OK? --MBq ^Disk 10:49, 20. Jul. 2020 (CEST)

Das halte ich für nicht sinnvoll. Wie soll jemand abstimmen, der einen der Vorschläge gut findet, die anderen aber nicht? Wenn er die erste Frage mit "Ja" beantwortet, befürwortet er vielleicht etwas, was er nicht will. Ganz davon abgesehen ist die Frage nach dem status quo unnötig, dieser gilt immer weiter, wenn nichts anderes beschlossen wird.

Deshalb wäre es sinnvoller, die drei Vorschläge abzustimen. Bekommt einer die Mehrheit, dann wird der umgesetzt. Bekommt mehr als einer eine Mehrheit, dann der mit der größten Mehrheit. Und wenn keiner die Mehrheit bekommt, dann wird halt keiner umgesetzt. Einfach und klar, warum komplizierter? -- Perrak (Disk) 16:19, 20. Jul. 2020 (CEST)

Kannst Du's mal umseitig unter "Auswertung" [1] formulieren? --MBq ^Disk 16:33, 20. Jul. 2020 (CEST)

Klar, gerne. -- Perrak (Disk) 16:36, 20. Jul. 2020 (CEST)

Ich habe es umseitig mal entsprechend formuliert, außerdem bei den Abstimmpunkten jeweils einen Abschnitt für Ja/Nein/Enthaltung beigefügt. Außerdem, weil mir das bei anderen MBs schon gefehlt hat, bei den Abstimmpunkten eine Kurzfassung der Option zugefügt. -- Perrak (Disk) 16:52, 20. Jul. 2020 (CEST)

Zur Klarstellung würde ich noch aufgenommen wissen wollen:

• „dürfen nur im Kontext von Software handeln“
  • ergänzt um eine Präzisierung „außerhalb des Community-Review“
  • Weil, wenn dem Community-Review unterliegend, dann kann auch jede IP einen Vorschlag machen, und dieser Dienst-BOA wäre sinnbefreit.

Weiterhin würde ich explizit erwähnt sehen wollen:

• „befristet BOA-Rechte beantragen“.
  • ergänzt um das Linkziel Wikipedia:Benutzeroberflächenadministratoren/Anträge
  • Damit klar ist, welche Seite zu beobachten wäre und wo ggf. Einwände erhoben werden könnten; auf welchen Wegen die Kommunikation mit einem Chapter zu laufen habe.

Es ist immer hilfreich, klare und eindeutige Vorschläge in geltende Richtlinien umzusetzen, weil das hinterher langwierige Streitigkeiten und Unbrauchbarkeit vermeidet, die durch interpretationsfähige unklare Gummiformulierungen verursacht werden. Dann weiß auch jeder, über was eigentlich entschiéden werden soll; diffuse Vorschläge müssen per se zur formalen Gesamt-Ablehnung führen.

VG --PerfektesChaos 22:47, 20. Jul. 2020 (CEST)

Ist ergänzt [2] --MBq ^Disk 13:38, 21. Jul. 2020 (CEST)

Auswertungsmodus

Derzeit: Ereichen mehrere Vorschläge eine Mehrheit, dann wird derjenige umgesetzt, der die meisten Ja-Stimmen erreicht hat.
Annahme:

• Vorschlag X: 501 Ja / 500 Nein
• Vorschlag Y: 500 Ja / 1 Nein

Umgesetzt würde Vorschlag X obwohl offenbar hoch umstritten. Eine Formulierung wie Ereichen mehrere Vorschläge eine Mehrheit, dann wird derjenige umgesetzt, der die meisten Prostimmen abzüglich Kontrastimmen auf sich vereint. wäre wohl gerechter. Ein Satz zu Enthaltungen würde ich ebenfalls empfehlen.--Mabschaaf 18:05, 23. Jul. 2020 (CEST)

Well, und dann würde die Logik auch noch erfordern, dass kein Vorschlag erfolgreich sein kann, auf den mehr Nein- als Ja-Stimmen entfielen, was ich umseitig auch noch nicht zweifelsfrei klargestellt sähe, sondern von Interpretationen des Begriffs „Mehrheit“ abhinge, in die wiederum Enthaltungen hineinspielen.

Es ist immer besser, vorher konkrete und präzise Regelungen zu treffen, als auf unklarer Grundlage irgendwas zu verabschieden und hinterher nicht zu wissen was es eigentlich bedeutet was man da entschieden habe.

VG --PerfektesChaos 18:43, 23. Jul. 2020 (CEST)

"eine Mehrheit" als Akzeptanzkriterium ist ein schlechter Witz, und der Vorrang des Vorschlags mit der höchsten absoluten Zustimmung statt der höchsten Zustimmungsquote ein absolutes Unding. Davon abgesehen erwarte ich für ein MB mit Auswirkungen auf Benutzerrechte eine 2/3-Mehrheit. Das gilt erst recht in Anbetracht der Konsequenz, dass in Zukunft erweiterte Rechte u. U. quasi auf Zuruf vergeben werden sollen. MBxd1 (Diskussion) 21:18, 23. Jul. 2020 (CEST)

Ich würde sagen, wir ziehen von den Pro-Stimmen die Contra-Stimmen doppelt ab. Es gewinnt der Vorschlag mit der besten Differenz, sofern der Wert größer Null ist. Das ergibt eine 2/3-Mehrheit. Beispiel von oben:

• Vorschlag X mit 501 Pro und 500 Contra, ergibt eine Differenz von −499
• Vorschlag Y mit 500 Pro und 001 Contra, ergibt eine Differenz von +498

Es gewinnt damit Vorschlag Y. --Morten Haan 🏄 Wikipedia ist für Leser da 🧉 Übersichtliche Artikelkriterien 21:37, 23. Jul. 2020 (CEST)

Den Vorschlag, die Nein-Stimmen mit zu gewichten, hatte ich weiter oben bereits gemacht, da kam keine Resonanz, daher die momentane Formulierung. Eine 2/3-Mehrheit halte ich auch für sinnvoll. wie wäre es mit folgender neuer Formulierung:

Inhaltliche Abstimmung

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. Erreicht genau einer der Vorschläge mindestens doppelt so viele Ja-Stimmen wie Nein-Stimmen und gleichzeitig mehr Ja-Stimmen als die anderen Vorschläge, dann wird dieser umgesetzt. Ist das nicht der Fall, wird derjenige Vorschlag umgesetzt, bei dem die Zahl der Ja-Stimmen abzüglich des doppelten der Neinstimmen am größten ist, vorausgesetzt, diese Zahl ist nicht negativ. Erfüllt keiner der Vorschläge eine dieser Bedingungen, gilt der status quo.

Dass Enthaltungen wie üblich keine direkte Auswirkung auf das Ergebnis haben, steht damit auch implizit mit drin. -- Perrak (Disk) 22:40, 23. Jul. 2020 (CEST)

Erreicht genau einer der Vorschläge mindestens doppelt so viele Ja-Stimmen wie Nein-Stimmen und gleichzeitig mehr Ja-Stimmen als die anderen Vorschläge, dann wird dieser umgesetzt. Dieser Satz ist unnötig, denn wenn nur ein Vorschlag die die 2/3-Mehrheit erreicht, aber ein anderer mehr Pro-Stimmen hat, wird ersterer trotzdem umgesetzt, weil er nämlich automatischer derjenige ist, der die größte Differenz aus Pro- abzüglich doppelter Contra-Stimmen hat. Es gibt in meinen Augen drei mögliche Fälle:

• Fall α: Genau ein Vorschlag hat eine 2/3-Mehrheit. → Dieser wird umgesetzt.
• Fall β: Es haben mehrere Vorschläge eine 2/3-Mehrheit. → Es wird derjenige umgesetzt, der die größte Differenz Pro- minus doppelter Contra-Stimmen hat.
• Fall γ: Keiner der Vorschläge hat eine 2/3-Mehrheit. → Es gibt weiterhin der Status Quo.

Morten Haan 🏄 Wikipedia ist für Leser da 🧉 Übersichtliche Artikelkriterien 23:30, 23. Jul. 2020 (CEST)

Fall δ: Zwei oder drei Vorschläge erreichen eine 2/3-Mehrheit und habe exakt die gleiche gewichtete Stimmdifferenz. --Count Count (Diskussion) 23:32, 23. Jul. 2020 (CEST)

1. Die Variante mit 2/3 ist angesichts der ganz massiven Möglichkeiten der BOA sehr zu begrüßen.
   • Ich habe immer noch den Eindruck, die Bürokraten können Bot-Accounts und BOA nicht auseinanderhalten. Bots bleiben ganz normale Benutzer, außer dass ihr Wirken von vielen Beobachtern ausgeblendet wird, und die Limits der Menschen nicht greifen. Ausnahme von Limits oder IP-Ranges hat keinerlei Folgen für Leser, betrifft nur unsere Schutzmechanismen gegen unerwünschte Seitenbearbeitungen. BOA stehen im Rang von CU und OS.
2. Dieses 2/3 formuliert in präziser Sprache würde heißen:
   Der Vorschlag ist angenommen, wenn er mehr als doppelt so viele Pro- als Kontra-Stimmen erhält und kein anderer Vorschlag einen größeren Überschuss an Pro-Stimmen erhielt.
3. Bei Zahlengleichheit ist nach momentaner Konstruktion kein Vorschlag angenommen (eben von mir per nicht-größer/gleich zugelassen).
   • Wobei sich aber die Vorschläge 2 und 3 technisch nicht ausschließen; sie eröffnen zwei verschiedene Wege zum BOA:
     Weg 2 für Freiwillige/jeden,
     Weg 3 eine zusätzliche Alternative für Chapterer.
     Selbst 1 plus ein oder zwei andere sind technisch praktizierbar, jedoch weder gleichzeitig intendiert noch wünschenswert; es würde den Bürokraten ein Präsidialrecht einräumen, nach Belieben ohne Befragung der Community BOA-Rechte zu vergeben, während sie nach einem Community-Entscheid für oder gegen einen Benutzer sich hoffentlich daran gebunden fühlen würden (das aber im Fall einer Ablehnung noch nicht einmal müssten). Wenn also 1 und andere zufällig identische Ergebnisse liefern, dann sollten die Bürokraten auf die Ausübung von 1 verzichten.
   • Was ein weiteres Problem mit Vorschlag 1/2 eröffnet: Es gibt keinen Weg für die Community, einem fachlich unsauber agierenden von den Bürokraten zum BOA gemachten Nicht-Admin die Rechte wieder zu entziehen. Es greift kein AP (hatten wir schon mal mit SG-Mitgliedern, die ihre Admin-Knöpfe dreist zur Erleichterung ihrer Artikel-Arbeit missbrauchten, weil sie es konnten, und ein AP abgelehnt wurde weil es keine Admins waren), keine AWW oder De-Admin, und es bliebe als einziges Instrument der Community BSV oder aber MB zu einer Einzelperson.

VG --PerfektesChaos 13:59, 24. Jul. 2020 (CEST)

Beim Fall δ würde der Status Quo weiterhin gelten und wir würdem um eine Folge-MB (also eine Stichwahl) nicht herumkommen. --Morten Haan 🏄 Wikipedia ist für Leser da 🧉 Übersichtliche Artikelkriterien 18:00, 24. Jul. 2020 (CEST)

Da die Vorschläge sich nicht grundsätzlich ausschließen, könnte man das mit dazu nehmen. Wenn zwei Vorschläge exakt die gleiche Zahl von Stimmen erhalten, dann gelten halt beide. Ohnehin sehr unwahrscheinlich, und wenn die Community das will, dann will sie das halt. -- Perrak (Disk) 12:34, 25. Jul. 2020 (CEST)

Die momentane Überschrift „Vorschlag 3: Außer Admins nur professionelle Entwickler“ schließt eine Ko-Existenz zurzeit aus.

• Das war nicht in meinem Sinn gewesen und ist sachlich nicht begründet.
• Sowohl 2 wie auch 3 können unabhängig voneinander existieren und beeinflussen sich nicht, wie ich weiter oben schon schrub:
  • Weg 2 für Freiwillige/jeden,
  • Weg 3 eine zusätzliche Alternative nur für Chapterer.
• Sollte auf 1 Gleichstand mindestens mit 2, aber auch 3 entfallen, sollten die Bürokraten auf das ihnen konkurrierend eingeräumte Präsidialrecht verzichten und sich betreffend Community-Nichtadmins an die expliziten Voten der Community halten.
• Ceterum Censeo: Bislang ist in anderthalb Jahrzehnten nie definiert worden, was ein BOA ist und was diese wann nach welchen Spielregeln und Absprachen dürfen. So lange man noch gar nicht weiß was ein BOA ist und darf kann nicht sinnvoll darüber entschieden werden wer diese unbekannten Befugnisse bekommen solle, deren Möglichkeiten weit über CU hinausgehen.

VG --PerfektesChaos 15:42, 25. Jul. 2020 (CEST)

Stimmt, das hatte ich übersehen. Also, folgender Vorschlag, da Nummer II und III jeweils über I hinausgehen:

• Wir streichen das "nur" bei Vorschlag III
• In der Auswertung wird festgelegt, dass bei jeweils ausreichender Mehrheit Vorschlag II und III beide als angenommen gelten, Vorschlag I nur dann, wenn er mehr gewichtete Ja-Stimmen erhält als jeder der beiden anderen Vorschläge.

Okay? -- Perrak (Disk) 16:17, 25. Jul. 2020 (CEST)

OK —MBq ^Disk 19:30, 25. Jul. 2020 (CEST)

Ich habe umseitig mal ausformuliert, was ich hier vorgeschlagen hatte. Den status quo habe ich nach oben verschoben, da er kein gesonderter Abstimmungspunkt ist. -- Perrak (Disk) 19:19, 26. Jul. 2020 (CEST)

De-BOA

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)

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)

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)

Problembeschreibung fehlt

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)

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)

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)

Nichts, dem WMDE-Mitarbeiter wird das Recht entzogen und fertig. --Itti 12:14, 25. Jul. 2020 (CEST)

Danke für die klare Aussage. MBxd1 (Diskussion) 12:21, 25. Jul. 2020 (CEST)

Verständnisfrage

Nach WP:BOA werden die Rechte bei 12 Monaten Inaktivität entzogen, umseitig heißt es jedoch, dass die Rechte entzogen werden, wenn sie 12 Monate nicht genutzt werden. Was soll also gelten: 12 Monate grundsätzliche Inaktivität oder 12 Monate BOA-Inaktivität? Bzw.: Ist tatsächlich eine unterschiedliche Regelung für Admin-BOAs und Nicht-Admin-BOAs vorgesehen? --Ameisenigel (Diskussion) 17:11, 26. Jul. 2020 (CEST)

Das sit richtig. die Adminrechte verliert man automatisch, wenn man 12 Monate komplett inaktiv ist, ob als Admin oder Autor. Ein reparierter Rechtschreibfehler reicht, das zu verhindern. Die BOA-Rechte verliert man nach zwölf Monaten, in denen man diese Rechte nicht eingesetzt hat, egal wie aktiv man ansonsten ist. -- Perrak (Disk) 18:55, 26. Jul. 2020 (CEST)

Jetzt habe ich aber eine Verständnisfrage – wo bitte steht das, oder wo stünde das in exakt dieser Auslegung?

Mir wäre ein Aspekt bekannt, dass hochwertige Rechte nach einigen Monaten Inaktivität eingefroren werden sollen, so zumindest auf anderen Wikis; die gibt es aber zurück sobald man wieder auftaucht und glaubhaft macht dass Identität mit sich selbst bestünde. Das geschieht nur aus Sicherheitsgründen, um bei längerer Abwesenheit feindliche Übernahmen zu verhindern, und wird auch bei CU und OS so gehandhabt.

Wir haben seit anderthalb Jahrzehnten keinerlei Regeln für BOA, auch keine für den Fall längerer Inaktivität, und vor allen Dingen noch niemals irgendwelche Spielregeln gehabt, was BOA unter welchen Voraussetzungen machen dürfen oder in welchen Fällen sie das vorher anzukündigen hätten oder der Community Einspruchsmöglichkeiten einzuräumen. Heißt traditionell: Alle BOA dürfen jederzeit spontan alles, ohne sich vorher irgendwie absprechen zu müssen.

VG --PerfektesChaos 19:15, 26. Jul. 2020 (CEST)

Dass BOA das Recht verleiren, wenn sie inaktiv als solche sind, ist meine Auslegung von WP:BOA, hatte ich in Diskussionen auch immer so verstanden. Dass sie das Recht wieder bekommen, wenn sie es wieder benötigen, steht dem ja nicht entgegen. Wie das bei CU oder OS gehandhabt wird weiß ich nicht, das kam in der de-WP in den letzten Jahren nicht vor. Dass Admins ihre Recht nur dann verlieren, wenn sie auch als Benutzer inaktiv sind, ist gelebte Praxis.

Dass wir bisher keine Regeln für BOA aufgeschrieben haben, heißt nicht, dass es keine Regeln gäbe. Ich stimme Dir allerdings zu, dass es sinnvoll wäre, Regeln schriftlich zu fixieren. Das sollte aber nicht unbedingt im Rahmen dieses MBs passieren. -- Perrak (Disk) 19:26, 26. Jul. 2020 (CEST)

• „ist meine Auslegung von WP:BOA“
  • Äh – zurück zu meiner Eingangsfrage: Genau welchen Satz, welches Wort hast du da ausgelegt?
  • BOA ist mit futsch, wenn sysop-Admin nicht mehr Admin, AWW, Dead-min oder was immer. Mehr sehe ich nicht.
• „ist meine Auslegung“
  • Wenn ich sowas lese, kräuseln sich mir die Fußnägel.
  • Sowas hat klipp und klar und unmissverständlich dranzustehen. Wenn es erstmal verschiedene „Auslegungen“ gibt, dann ist grundsätzlich was schiefgelaufen.
• „sollte aber nicht unbedingt im Rahmen dieses MBs passieren“
  • Die Abstimmenden sollen Personen Befugnisse unter bestimmten Bedingungen erteilen lassen, so Vorschläge 1 und 2.
  • Nur konnte mir bis heute noch nie jemand sagen, welche Befugnisse erteilt werden sollen, über die da abzustimmen sei.
  • Man kennt nur eine Softwarefunktion, die technisch erlaubt, bestimmte Seiten zu verändern. Aber niemand weiß, welche Befugnisse damit verbunden sind. Also: Jeder darf jederzeit alles, ohne irgendwelche Einschränkungen oder vorherige Absprachen, und darüber soll umseitig abgestimmt werden. Das sollte dann auch ehrlich hingeschrieben sein.

VG --PerfektesChaos 21:42, 26. Jul. 2020 (CEST)

Steht doch umseitig, oder liest Du das etwas anderes? Was die Auslegung betrifft: Jede Regel ist auslegungsbedürftig. Mag sein, dass ich mich irre. Andererseits sind inaktive BOAs je weniger das Problem, sondern eher welche, die in der falschen Weise aktiv wären.

Die Abstimmenden sollen nicht "Personen Befugnisse (...) erteilen lassen", es geht hier darum, die Möglichkeit der Bürokraten, diese Rechte zu erteilen, einzuschränken. Bisher gibt es keine Regel dazu, die Bürokraten könnten also tun, was sie für richtig halten. Ich verstehe nicht, warum Du gegen eine Einschränkung dieses Rechts polemisierst. -- Perrak (Disk) 22:00, 26. Jul. 2020 (CEST)

„Steht doch umseitig“ – das ist vom Himmel gefallen und durch nichts fundiert; hat der Entwerfer des MB halt mal so dahingeschrieben.

Inaktive BOA sind insofern Sicherheitsrisiko, als die Rechte bei jemandem schlummern, von dem man nicht weiß was damit ist. Irgendwo las ich wohl mal vor Jahren in einem Wiki mit Amtssprache Englisch, dass bei drei oder was Monaten Inaktivität die CU, OS, Bürokraten und BOA (Stewards?) eingefroren werden sollen; gäbe es nach Auferstehung formlos zurück.

Die Abstimmenden können nur Befugnisse erteilen, um irgendwas für die Community zu tun. Man weiß aber nicht welche und was. Man kennt nur eine Software-Funktion.

VG --PerfektesChaos 23:08, 26. Jul. 2020 (CEST)

dieses MB ist noch nicht gestartet, wenn Du einen besseren Formulierungsvorschlag hast, dann tu Dir keinen Zwang an. Ich denek aber schon, dass die Beschreibung umseitig einigermaßen passt und auch nicht verschleiert, dass es um potentiell gefährliche Rechte geht.

Nein, Befugnisse erteilen die Bürokraten. Zur Zeit gibt es keine Regeln dafür, wie sie das handhaben. An sich könnten sie jedem diese Rechte erteilen, bei dem sie das für richtig halten. Durch dieses MB werden ihre Möglichkeiten höchstens eingeschränkt, nicht ausgeweitet. Sollten die Abstimmenden alle Vorschläge ablehnen, gilt zwar prinzipiell der status quo weiter, implizit würde dieser aber eingeschränkt, eine Vergabe der Rechte an Nicht-Admins wäre dann kaum mehr vermittelbar und auch offensichtlich nicht beabsichtigt. -- Perrak (Disk) 23:30, 26. Jul. 2020 (CEST)

@Perrak: Das habe ich eben anders verstanden. Die Formulierung auf WP:BOA Dauerhaft (>12 Monate) inaktiven Benutzern soll das Recht entzogen werden, um die Angriffsfläche zu verringern. habe ich so verstanden, dass die Rechte – wie die Admin-Rechte auch – bei grundsätzlicher Inaktivität entzogen werden. Dem würde halt die umseitige Formulierung Falls länger 12 Monate ungenutzt, verfällt das Recht widersprechen. Wenn aber tatsächlich BOA-Inaktivität gemeint ist, sollte die Formulierung auf WP:BOA IMHO weniger zweideutig geschrieben werden. --Ameisenigel (Diskussion) 09:22, 27. Jul. 2020 (CEST)

Wenn jetzt schon die Regel der 12 Monate BOA-Inaktivität gelten sollte, gäbe es bereits Nutzer, denen die Rechte wieder entzogen worden sein müssten, siehe #Anzahl der BOA beschränken?. --Ameisenigel (Diskussion) 09:34, 27. Jul. 2020 (CEST)

Ich sehe das genauso wie Ameisenigel. Die beiden Formulierungen sind für sich jeweils relativ klar und widersprechen einander. Yellowcard (D.) 09:38, 27. Jul. 2020 (CEST)

Und noch einmal:

• Eine derartige Regel existiert nicht.
• Die umseitige Darstellung wurde durch den Verfasser des MB frisch erfunden.
• Was es gibt oder geben kann:
  1. Für alle Inhaber erweiterter Rechte (≥sysop) verfallen diese nach 12 Monaten Inaktivität.
     • (gab wohl schon vor einem Jahrzehnt ein MB dazu; welches die letzte gültige Regelung wäre weiß ich grad nicht)
  2. (möglich, intern absprechbar) Nach drei, zwei Monaten Inaktivität von CU, OS, Bür, BOA werden die Rechte aus Sicherheitsgründen eingefroren, gibt es bei glaubhafter Rückmeldung zurück.

VG --PerfektesChaos 12:42, 27. Jul. 2020 (CEST)

Vor zwei Jahren haben die Bürokraten das gegenwärtige System eingesetzt. Wir hatten uns auch geeinigt, das Flag aus Sicherheitsgründen bei Leuten abzuschalten, die es nicht mehr brauchen, allerdings bisher ohne feste Frist. Meines Wissens bisher auch noch nicht umgesetzt. Um das künftig einheitlicher zu haben, stehen "12 Monate" in den Vorschlägen 1 und 2. Gemeint ist tatsächlich die Nichtnutzung des BOA-Rechts, nicht die allgemeine Aktivität. Technisch wird die Überwachung etwas erschwert, weil kein automatisches Log existiert, wir müssen das regelmäßig von Hand abfragen (danke @Wurgl für die SQLs oben!). - Es gibt Nutzer, auf die das zutreffen würde. Aber wir warten noch ab, was hier entschieden wird. --MBq ^Disk 11:24, 28. Jul. 2020 (CEST)

Das bedarf keiner Abstimmung durch die Community, und es ist auch umseitig nicht als „Vorschlag“ explizit dargestellt.

• Es wäre nicht redlich, das als „hier entschieden“ zu verbuchen, weil es nebenbei gesprächsweise in der Einleitung eines MB mal erwähnt wurde.

Eine solche Regelung gibt es auf diversen Wikis, und es ist kein Entzug der Rechte, sondern ein sicherheitsmäßiges Kaltstellen für CU, OS, Bür, BOA, Stewards und nach Rückmeldung gibt es den Flag unbürokratisch zurück.

Gekoppelt ist es an die allgemeine Aktivität des Accounts und soll bei Inaktivität durch Weltreise oder Krankheit (Merl, seufz) greifen; hat nichts mit spezifischen BOA-Aktivitäten zu tun.

Bei 20 echten BOA-Aktivitäten pro Jahr und 20 Berechtigten ist es nicht möglich, dass alle BOA einmal monatlich eine BOA-Aktivität ausführen.

Können die Bürokraten unter sich als gängige Praxis ausmachen und zwecks Erläuterung auf ihrer Projektseite mit expliziten Details und Hintergrundinfo veröffentlichen.

VG --PerfektesChaos 14:17, 28. Jul. 2020 (CEST)

Einverstanden. Dann würde ich das unter "Status quo" etwas ausführen und den letzten Satz in Vorschlag 1 und 2 ersetzen durch "Die Regelung bei Nichtnutzung bleibt wie bisher." OK? --MBq ^Disk 15:36, 28. Jul. 2020 (CEST)

Gern – ich würde es umseitig streichen und nur die für Admins allgemein geltende 12-Monats-Regel erwähnen; insofern dass diese für (Community-)Nichtadmins analog gelten würde.

Damit wäre das Thema „Verständnisfrage“, welches diesen Abschnitt eröffnete, erstmal beendet und niemand mehr verwirrt.

Unabhängig davon können die Bürokraten eine allgemeine Politik des sicherheitstechnischen Einfrierens für alle CU, OS, Bür, BOA bei sich veröffentlichen; das bedarf keiner sonstigen Kommunikation.

Weil die betreffenden Erweiterten meist schon ein Jahrzehnt Dinger zusammen gedreht hatten, ihre E-Mail-Adressen und Telefonnummern teilweise kennen, ist das wohl auch global ein sehr seltener Vorgang, aber bei Unfällen oder dergleichen eine sinnvolle Notmaßnahme, falls jemand unerklärlich aus dem Netz verschwindet.

VG --PerfektesChaos 15:50, 28. Jul. 2020 (CEST)

Während der Abstimmung

Status Quo

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)

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)

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)

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)

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)

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)

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)

Status quo nicht durch Community legitimiert

Solange es keine von der Community legitimierten Regeln für die Rechtevergabe an Admins gibt, sollte sie auch nicht zur Rechtevergabe an Nicht-Admins befragt werden. Die derzeitige Praxis (Erteilung der Rechts an Admins auf Zuruf wegen angeblichen Bestandsschutzes) bedurfte auch keines MBs, das konnte einfach von wenigen Leuten in Hinterzimmern beschlossen werden. Für die Rechtevergabe an Nicht-Admins braucht es plötzlich ein MB? Es bedürfte eines grundsätzlichen MB, wer wem nach welchen Regeln und Verfahren das Flag geben darf. So war es auch 2018 seitens WMF vorgesehen, als den Admins das Flag entzogen wurde. --DaizY (Diskussion) 14:58, 7. Aug. 2020 (CEST)

Hier braucht es ein MB, weil das Hinterzimmer sich da nicht einig war. Ich vermisse noch die Problembeschreibung, warum rein technische Fragen nicht in rein technischen Hinterzimmern geklärt werden können. Die Notwendigkeit für ein MB, um die Grundregeln zum Einsatz, nicht wirklich der Vergabe, des Flags festzulegen, bräuchte es aber allemal. Dazu hat PerfektesChaos weiter oben schon genug geschrieben. --MGChecker – (📞| 📝| ) 16:09, 7. Aug. 2020 (CEST)

Ob das MB notwendig ist, kann man unterschiedlich beurteilen. MBs sind aber auch dann zulässig, wenn sie nicht notwendig sind. Und es ist auch erlaubt, MBs zu Teilaspekten zu formulieren, wenn eine grundlegendere Frage noch eines passenden MBs harrt.

It's a wiki, jede/r macht sich die Arbeit, die er/sie für sinnvoll hält. -- Perrak (Disk) 17:12, 7. Aug. 2020 (CEST)

Vorschlag 1 lautet: "Bürokraten können auch Nichtadmins das Flag geben​." Der Vorschlag impliziert doch, aktuell seien die Bürokraten legitimiert, das Flag an Admins (auf Zuruf) zu vergeben. Das ist jedoch nicht richtig. Die Bürokraten haben allerdings intern beschlossen, für Alt-Admins der DE-WP einen Bestandsschutz einzuführen und neuen Admins das Recht auf Zuruf zu erteilen. Die DE-WP ist daher schon jetzt die Community mit den meisten Benutzeroberflächenadministratoren und das, ohne dass es dazu ein von ihr legitimiertes Regelwerk gibt. --DaizY (Diskussion) 20:15, 7. Aug. 2020 (CEST)

Das stimmt nicht. Admins ohne Bestandsschutz müssen explizit zusätzlich für BOA kandidiert haben. 21:24, 7. Aug. 2020 (CEST) (unvollständig signierter Beitrag von MBxd1 (Diskussion | Beiträge) )

"Was machen wir, wenn 1 und 2 angenommen wird, 3 aber nicht"

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)

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)

Stimmt. Perraks Antwort ist so pauschal falsch. MBxd1 (Diskussion) 21:22, 7. Aug. 2020 (CEST)

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)

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)

Diskussion zu der Stimme von KaiMartin bei Vorschlag 3

-<)kmk(>- (Diskussion) 23:17, 7. Aug. 2020 (CEST) Die Weiterentwicklung von Mediawiki findet selbstverständlich nicht am Produktivsystem statt. Entsprechend gibt es keinen Grund, warum sie dort häufiger Änderungen vornehmen müssten. Da die Entwickler üblicherweise nicht zur Wikipedia-Community gehören, fehlt ihnen der Hintergrund, um die "sozialen" Folgen von Eingriffen realistisch abschätzen zu können. Entsprechend leicht können Sie sich verschätzen (Siehe zum Beispiel das Superprotect-Flag) Bei Ausnahme-Situationen ist es zumutbar, dass die Entwickler sich von regulären Halter des BOA-Flags helfen lassen.

Diese Aussage ist nicht zutreffend. Jede Woche wird eine neue Alpha-Version von MediaWiki als neue Software für Wikipedia verwendet, die nach einem halben Jahr Entwicklung auch dem Rest der Welt zugemutet wird. JavaScript ist sogar noch volatiler. In den Fällen, die dieses MB herausbeschworen haben, ist der zweite Einwand nicht tragfähig, und durch die vorgeschlagene Regelung werden derartige Eingriffe ohnehin ausgeschlossen. --MGChecker – (📞| 📝| ) 00:28, 8. Aug. 2020 (CEST)

Die Frequenz mit der neue Versionen ins Produktivsystem ausgerollt werden, hat nichts mit dem angesprochenen Aspekt zu tun. Bei jeder halbwegs komplexen Software findet die Entwicklung nicht dort, sondern in und an Testinstallationen statt. Entsprechend müssen zur Erfüllung ihrer Aufgabe das Produktivsystem nicht anfassen. Ich sehe keinen Grund warum das bei Wikimedia anders sein sollte. ---<)kmk(>- (Diskussion) 23:50, 8. Aug. 2020 (CEST)

Ich finde eher Deine Argumentation nicht zutreffend. Zum einen wird selbstverständlich Software durch die Entwickler nicht im Produktivsystem entwickelt und auch nicht getestet, trotzdem ist irgendwann ein Deployment notwendig und bei jeder Software auch Bugfixes und Updates. Ich sehe keinen Vorteil, weshalb die Entwickler diesen Code einem BOA überreichen sollten, der diesen dann in die entsprechenden Seiten einfügt, demgegenüber aber eine Menge Nachteile. Oder siehst Du derzeit auch nur einen BOA, dem Du ein solches Code-Review zutrauen würdest? Das ist derzeit jedenfalls nicht der Anspruch an die BOAs. Und falls es Dir um bewusste Beeinflussung / Missbrauch geht, da ist die Rechtegruppe BOA eh völlig irrelevant: Wenn WMF-Softwareentwickler Änderungen umsetzen wollen, können sie das völlig unabhängig von den Benutzergruppen auch tun. Superprotect wurde gar nicht per JavaScript umgesetzt. Insofern ist Deine Argumentation in meinen Augen krumm und schief und ich stimme MGChecker zu. Yellowcard (D.) 00:40, 9. Aug. 2020 (CEST)

Komischerweise hat es aber bisher ohne BOA-Rechte für Wikimedia-Entwickler offensichtlich funktioniert. Warum geht es jetzt auf einmal nicht mehr? MBxd1 (Diskussion) 09:05, 9. Aug. 2020 (CEST)

Ich bin kein Unterstützer von Vorschlag Nr. 3 und kann Dir diese Frage daher nicht pauschal beantworten. Anlass für dieses MB war die Beantragung dieses Rechts für einen (!) Entwickler von WMDE (!), welche anders als die WMF-Developer natürlich nicht ohne Weiteres Zugriff erhalten. In diesem konkreten Fall wäre die Erteilung des BOA-Rechts offensichtlich sinnvoll. „Bisher hat es doch auch funktioniert“ ist übrigens ganz generell selten ein gutes Argument. Yellowcard (D.) 10:40, 9. Aug. 2020 (CEST)

Natürlich kann es unter Umständen nötig sein, das Entwickler auch Dateien bearbeiten muss die außerhalb der Kernsoftware laufen.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 _{Rechte | Kenst du scho de boarische Wikipedia?} 11:12, 9. Aug. 2020 (CEST)

"Bisher hat es doch auch funktioniert" ist im Gegensatz zu "Haben wir immer schon so gemacht" durchaus ein Argument. Es erfordert eine Klärung, warum es plötzlich nicht mehr funktionieren soll. Aber an der Darstellung eines Handlungsbedarfs fehlt es bei diesem MB an allen Enden. MBxd1 (Diskussion) 13:24, 9. Aug. 2020 (CEST)

Dieses MB hatte die Intention zu klären, wie und ob eine Vergabe der Rechte an Nicht-Admins möglich sein kann. Ausgangspunkt war die Bitte eines WMDE-Mitarbeiters, der die Rechte sinnvoll benötigt, sie aber eigentlich nicht bekommen kann. Dann kam die "Kaperung" es sollten unzählige weitere Punkte gleichzeitig geklärt werden. Entzug, Auflagen, Bedingungen, usw., usw. Deine Frage ist zu kurz gesprungen, ja es hat bisher funktioniert, aber das ist ja nicht die Frage. Ich habe meine Rechte inzwischen zurückgegeben. Ich hatte sie, damit ich die Skripte nach einer Admin-, bzw. Mentoren-Wahl anpassen konnte. Mache ich jetzt halt nicht mehr. NNW auch nicht mehr, es wird sich dann wohl jemand anderes finden und es wird weitergehen, wie bisher. Aber die Frage ist schlicht, was machen wir mit dem WMDE-Mitarbeiter, der sie benötigt, aber nach bisherigem Regelstand nicht haben darf. Entknopfen ist eine Möglichkeit. Dann bleibt halt alles, wie es war. Er kann dann aber nichts machen und es muss sich jemand finden, der seine Bearbeitungen überträgt. Oder auch nicht, dann kann er halt nichts machen. --Itti 14:00, 9. Aug. 2020 (CEST)

Doof nur, dass ein signifikanter Teil der Abstimmenden genau kritisiert, dass wir genau diese grundlegenden Fragen immer noch nicht geklärt haben, bevor die Frage der Nicht-Admins für die Position diskutiert wird. --MGChecker – (📞| 📝| ) 19:37, 9. Aug. 2020 (CEST)

Die Frage geht dann weiter, wieso erstmals ein WMDE-Mitarbeiter BOA-Rechte braucht, nachdem bisher offensichtlich kein Bedarf bestand. Mag sein, dass das schnell zu klären wäre, aber die Frage tritt tatsächlich hinter dem Rest der Abstimmung zurück, was durchaus an deren Überladung liegen kann. MBxd1 (Diskussion) 23:06, 9. Aug. 2020 (CEST)

Soweit so gut, dennoch muss die Frage erlaubt sein, warum er jetzt die Rechte braucht, darüber schweigt sich das MB (und hier die Disk) konmplett aus. Auch ein Link auf die Anfrage hätte sicher geholfen: Wikipedia:Benutzeroberflächenadministratoren/Anträge/Archiv/2020#Thiemo_Kreuz_(WMDE) (wäre ein Service gewesen, damit sich das nicht jeder selber raussuchen muss). Leider ist die Diskussion der Bürokraten nicht so einfach zu finden (will heißen: ich habe sie nicht gefunden). Damit ist das Ganze aber ziemlich frei schewebend. Die Frage des MB ist natürlich legitim, aber die Frage warum er sie braucht auch.

Eigentlich kein großes Ding, er will nach eigenen Angaben nur Kopierfehler vermeiden und effizienter arbeiten, seine Qualifikation ist wohl unzweifelhaft. Schön wäre es halt gewesen spätzestens bei den ersten Nachfragen diese Geschichte nachzuliefern. Das hätte der Initiator oder die Unterstützer machen sollen. So finde ich die Komunikation des Ganzen etwas misslungen. Flossenträger 09:39, 10. Aug. 2020 (CEST)

Die Diskussion ist im Abschnitt Hintergrund letzter Satz bereits seit der ersten Version des MBs verlinkt. Ich zumindest habe mir nichts schlimmes dabei gedacht, sie nicht erneut zu verlinken. Viele Grüße --Itti 14:46, 10. Aug. 2020 (CEST)

Ups, sorry, ist sie nicht. Mein Fehler, da habe ich gepennt. Ja, dann hätte sie verlinkt werden sollen. Viele Grüße --Itti 14:47, 10. Aug. 2020 (CEST)

So, nun aber, die Ergänzung kam mit diesem Edit. --Itti 14:58, 10. Aug. 2020 (CEST)

Wie kann man Einsatz der BOA-Rechte tracken

Es wird ja Entzug der Rechte bei Nichtverwendung der Rechte erwähnt. Wie und wo kann der Einsatz der BOA Rechte durch die bisherigen BOA Rechteinhaber denn gesehen werden? Wieviele Änderungen die BOA Rechte erforderten gab es dennn in den letzten 12 / 24 Monaten? (Ich finde die Pflicht solche Änderungen zu machen sonst verliert an sein Recht befremdlich, wenn es selten nötig ist würde es bedeuten die Rechteinhaber müssten sinnlosedits machen um das Recht nicht zu verlieren) Groetjes --Neozoon (Diskussion) 09:40, 9. Aug. 2020 (CEST)

Berechtigte Frage, hier bleibt wohl nur die Suche in den Benutzerbeiträgen, indem man auf den MediaWiki- und Benutzer-Namensraum filtert.

Zu Deiner Klammer-Anmerkung: Auch das sehe ich genauso. Leider ist zugleich die Gruppe der BOAs viel zu groß geworden, da die Bürokraten pauschal allen „Bestandsadmins“, die Interesse an dem Flag hatten, dieses erteilt haben. Zugleich haben viele Admins dieses Flag beantragt, bei einigen nach meinem Gefühl eher nach dem Motto „haben ist besser als brauchen“. Da dieses MB inhaltlich wohl dreimal auf Ablehnung trifft, kann ich nur hoffen, dass die Bürokraten zunächst überhaupt keine BOA-Flags mehr vergeben, es sei denn diese sind inhaltlich gut begründet. Yellowcard (D.) 10:43, 9. Aug. 2020 (CEST)

Wurgl (01:22, 12. Jul.) hat das weiter oben (Abschnitt #Anzahl der BOA beschränken?) mit technischen Mitteln demonstriert und die Ergebnisse vorgelegt (ich zitiere, leicht umformuliert):

• quarry:query/46201 behandelt, wer hat wann zuletzt und was zuletzt mit diesen Rechten gemacht bzw. wer benötigt/verwendet das Recht überhaupt,
• quarry:query/46596 zeigt, wie oft und was gemacht wurde bzw. wie oft benötigt/verwendet,
• quarry:query/46598 (Einschränkung auf das kritische Javascript) zeigt (annähernd, weil die Query nur quantitativ auswerten kann): Haben die Rechteinhaber genügend Wissen um "Schweinereien" in Javascript zu erkennen.

[Zitat Wurgl ebd: "Bei allen Rechteinhabern ist natürlich die Frage: Sind die Accounts gehackt bzw. sind die Accounts hackbar (aka unsicher)."]

Und am konkreten Beispiel: Ich selbst verwende/te die BOA-Rechte (wie beim Antrag 2018 angegeben) sehr(!) sporadisch im MW-Namespace (zuletzt 4/20), ebenso sehr(!) sporadisch auf Wunsch auf Benutzer/js./css.-Seiten bei Bearbeitung solcher Anfragen (zuletzt 4/2020) oder bei Wartungsarbeiten im BNR (PDD/markAdmins.js zuletzt 10/19, dort davor zuletzt 2017). (PS: ausgerechnet der Admin, der die PDD/markAdmin.js sehr intensiv betreute, hat die BOA-Rechte jüngst abgegeben, zwei weitere haben die Rückgabe dort angekündigt.)
Grüße --Rax post 12:44, 9. Aug. 2020 (CEST)

@Yellowcard: Leider nicht ganz richtig. Admins, die bis Juli 2018 gewählt wurden, können das Recht nachträglich auf der Antragsseite von WP:BOA beantragen. Alle Admins, die ab August 2018 gewählt worden sind und werden, müssen bei ihre Kandidatur nun angeben, ob sie dieses BOA-Recht haben möchten. Es wird dann also Admin (mit eventuellen BOA-Recht) gewählt. Funkruf ^WP:CVU 12:48, 9. Aug. 2020 (CEST)

Das meinte ich mit „Bestandsadmins“. :) Grüße, Yellowcard (D.) 12:57, 9. Aug. 2020 (CEST)

PS: In dem Zusammenhang eine Rückfrage. Dass seit 2018 in einer AK angegeben werden muss, ob die Kandidatur auch für das BOA-Flag gilt, ist mir bewusst. Aber wie kam diese Prozedur eigentlich zustande? Angenommen, dieses MB wird inhaltlich in allen drei Vorschlägen abgelehnt (danach sieht es ja leider derzeit aus), würde diese Prozedur beibehalten? Ich finde dieses Vorgehen nämlich insgesamt sehr unglücklich, auch wenn es natürlich durch die Neuschaffung dieses Flags wenig bessere Alternativen gab. Yellowcard (D.) 12:59, 9. Aug. 2020 (CEST)

Du hast offensichtlich den Sinn dieser MB nicht verstanden. Es geht hier garnicht um den BOA an sich. Sondern was mit den Nicht-Admins gemacht werden soll, die BOA werden wollen. Das ist das Problem, wenn man ein Meinungsbild "verzerrt". Es fehlt nämlich eigentlich sogar noch ein Abschnitt. Und der lautet "Möchtest du, dass Nicht-Admins BOA werden?" Und so sieht das hier aus, als ob es für alle zutrifft. Funkruf ^WP:CVU 13:09, 9. Aug. 2020 (CEST)

Wie ist die Berechtigung von Staffern geregelt?

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)

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)

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)

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)

Hat jetzt nichts mehr mit dem MB zu tun, aber: Warum eigentlich nicht? --Filzstift (Diskussion) 13:12, 13. Aug. 2020 (CEST)

Weil es global ist. Funkruf ^WP:CVU 13:14, 13. Aug. 2020 (CEST)

Praktikabele Lösung bei Erhalt des Status Quo

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)

Hallo Neozoon, so etwas gibt es mit Wikipedia:Technik/Skin/MediaWiki/Änderungen (zugegeben, komplizierter Name) bereits. Gruß, -- hgzh 14:01, 15. Aug. 2020 (CEST)

Vorschlag 2 "durchs Hintertürchen"

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)

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)

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)

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)