Wikipedia Diskussion:Meinungsbilder/Oberflächenadministratoren

Grundprinzip

Nach welchem Grundprinzip sollen die Rechte vergeben werden? Hier würde mich ein gewisses Stimmungsbild interessieren. Es gibt grundsätzlich zwei Möglichkeiten, die ich für erwägungswert halte:

1. Die Bürokraten treffen eine Entscheidung nach einer bis zu mehrere Wochen andauernden Diskussion analog zu den Botanträgen. (Aber nicht im Schnellverfahren so wie aktuell. Dies würde auch für Nicht-Administratoren gelten. (Da diese Gruppe darauf ausgelegt ist, technisch versiert Bearbeitungen an Entwickler-relevantem Kram vorzunehmen, und nicht administrative Entscheidungen zu treffen.)
2. Es gibt ein Wahlverfahren ähnlich der Administratorkandidaturen.

Meinungen? Ich halte das zweite für ziemlichen overkill. --MGChecker – (📞| 📝| ) 00:56, 9. Aug. 2018 (CEST)

Vorschlag 1 klingt gut, für gewählte Admins würde ich aber ein verkürztes Verfahren vorschlagen. Wenn die Gruppe auch Löschrechte beinhalten soll, wäre eine Wahl durchaus angebracht, dann aber nur einfache Mehrheit und vllt. sieben Tage lang. --Morten Haan 🖤 Wikipedia ist für Leser da • Übersichtliche Artikelkriterien 14:47, 10. Aug. 2018 (CEST)

Die Löschrechte dürften explizit nur für Seiten angewandt werden, die im MediaWiki-Namensraum liegen oder Datentyp JS, CSS oder JSON haben (alles logische oders, also und/oder). Da werden ja nicht wirklich Löschentscheidungen getroffen. Die Idee dient auch dazu, die Menge der Leute zu erhöhen, die hochproblematische Inhalte (ganz schlimme PAs, ANON) von benutzereigenen JS-/CSS-Seiten entfernen können. Ein verkürztes Verfahren für gewählte Admins würde ich tatsächlich sogar weniger gutheißen, da beide Ämter zwar jetzt noch gekoppelt sind, aber langfristig eigentlich völlig unabhängig sind un völlig unterschiedlichen Aufgabenfeldern entsprechen. --MGChecker – (📞| 📝| ) 03:34, 11. Aug. 2018 (CEST)

Analog zu Bots die Bürokraten entscheiden zu lassen fände ich persönlich am einfachsten. Den Vorgaben der Foundation nach ist das vermutlich nur durchführbar, wenn wir das Recht auf Admins beschränken. Sollten auch Nicht-Admins kandidieren dürfen, was ich für unproblematisch hielte, käme man um einen Wahlprozess wohl nicht herum. Dabei sollte auf jeden Fall auch eine 2/3-Mehrheit erforderlich sein: Wenn sich deutlich später Stimmen als ungültig erweisen, liegt dann immer noch eine breite Zustimmung vor. Einfache Mehrheit für eine Funktion, die die Foundation für so kritisch hält, dass sie nicht mehr jeder Adim automatisch haben soll? Keine gute Idee in meinen Augen. Die Wahlzeit könnte man verkürzen, aber warum? -- Perrak (Disk) 21:26, 18. Aug. 2018 (CEST)

Ich denke nicht, dass die Vorgaben der Foundation eine Wahl zwingend nötig machen. Die Funktion wird primär aus drei Gründen aus den Administratoren ausgekoppelt:

1. Aufgrund der geringeren Zahl der Berechtigten wird der Angriffsvektor reduziert. JS auf Wikipedia einzuschleusen ist eine der Aktionen im Internet, die im Verhältnis zum Aufwand den größten Schaden anrichtet.
2. Die meisten Administratoren benutzen diese Rechte ohnehin nicht.
3. Man kann diese Gruppe (genau wie Bürokraten, Stewards, CUs und OS) dann mittelfristig zu 2FA zwingen, ohne dass das auch Tausende Admins betrifft, die keine Lust darauf haben.

--MGChecker – (📞| 📝| ) 15:22, 20. Aug. 2018 (CEST)

Ein Recht, was man den Admins nehmen will, weil es potentiell besonders schädlich ist, sollte nicht ohne Wahl an irgendjemand vergeben werden. Woraus schließt Du, dass die Foundation das anders sieht? -- Perrak (Disk) 20:43, 20. Aug. 2018 (CEST)

Weitere Rechte

Ich würde gerne zur Diskussion stellen, die Benutzerrechte der neuen Gruppe zu erweitern, um ihre Aufgabe besser wahrnehmen zu können.

• import zur Übertragung von Gadgets und ähnlichem aus anderen Wikis.
• delete um Seiten zu löschen, die JS oder CSS als Datentyp haben, und von anderen Admins in Zukunft nicht mehr gelöscht werden können. Diese Rechte dürften analog SG-A nur eingeschränkt genutzt werden und umfassen nicht den Zugriff auf gelöschte Inhalte.
• editcontentmodel um mit JS und CSS besser operieren zu können. Bei content models geht es gerade um technische Transformationen des Seitentypes (JS/CSS/Wikitext/Massennachrichtenliste/Lua).

Will man eine allgemeine Techniker-Gruppe aus dieser Gruppe basteln, wären auch managechangetags, deletechangetags und abusefilter-modify eine Überlegung wert. --MGChecker – (📞| 📝| ) 00:56, 9. Aug. 2018 (CEST)

Eine allgemeine technische Gruppe klingt nicht schlecht, auch um Admins da zu entlasten. --Morten Haan 🖤 Wikipedia ist für Leser da • Übersichtliche Artikelkriterien 14:47, 10. Aug. 2018 (CEST)

.Was erweiterte Rechte angeht, wäre es sinnvoll, der neuen Gruppe wie bei SG/CU/OS automatisch Adminrechte zuzugestehen, die zur Erledigung der spezifischen Aufgaben genutzt werden dürfen. Das dürfte einfahcer sein, als vorher zu überlegen, welche einzelnen Rechte jeweils benötigt werden. Vermutlich werden die meisten ohnehin aus den Reihen der Admins kommen. -- Perrak (Disk) 21:20, 18. Aug. 2018 (CEST)

Ich halte überhaupt rein gar nichts davon, auf Zuruf noch drei Dutzend sysop-Rechte pro Nase gleich mit zu erteilen, und das womöglich auch noch automatisch und ohne Community-Wahl (anders als beim gewählten SG).

Für ein MB wäre es ein k.o., weil nur Misstrauen durch die Community auslösend, etwa auch wegen Einsichtnahme in alles außer OS.

Es ist aber auch inhaltlich absolut nicht erforderlich, weil die Konstellationen nur extrem selten benötigt werden.

• Kürzlich wurde abgezählt, dass es überhaupt nur 10–20 Anlässe für einschlägige Edits pro Jahr gab (Bearbeitungen, keine Löschungen).
  • Es steht irgendwann ein größeres Aufräumen und Generalmodernisierung an, aber das ist eine einmalige Geschichte alle fünf bis zehn Jahre.
• import zur Übertragung von Gadgets und ähnlichem aus anderen Wikis.
  • Es wurde vermutlich noch nie eine Gadget-Versionsgeschichte aus einem anderen Wiki importiert.
  • Die einzigen Geschichtenimports von JS/CSS in einem Dutzend Jahren waren wohl dieser und dieser, was mir alles in allem kuriose 7 Edits im MW-NR einbrachte.
  • Seit 2010 haben wir keinerlei komplexe Gadgets mehr für die Allgemeinheit aus anderen Wikis übernommen, und das hat auch sehr gute Gründe.
  • Wenn wir was übernehmen, dann schreiben wir in den BK ein Permalink auf die Herkunft, und gut ist.
  • Ansonsten reicht eine Kurznotiz bei den Importeuren, und nach ein paar Stunden wären die nachgetragen. Für die Funktion ist das ohnehin nicht erforderlich. Als alleinige geplante Aktion hätte es keine Eile und könnte auch einen Tag später passieren.
• delete um Seiten zu löschen, die JS oder CSS als Datentyp haben, und von anderen Admins in Zukunft nicht mehr gelöscht werden können.
  • Es gab wohl 2014 die letzte einschlägige Löschung im Rahmen von Aufräumaktionen.
  • Wenn die MW-Software konzeptionell weiter gekommen ist (phab:T201052) und ein Entfernen aus dem Gefahrenbereich dann erneut jedem der 190 Normal-Admins möglich sein wird, können das nicht nur die aktuell neun (mit OS).
  • Zur Abwendung akuter Gefahren genügt es, eine frische Version drüberzuschreiben, notfalls eine völlig leere Seite.
  • Weil nicht jede IP da was reinschreiben oder Seiten anlegen kann, stehen da eigentlich nur langjährig erprobte und diskutierte Sachen drin, und Löschungen ergäben sich nur, um dem allgemeinen technischen Wandel zu folgen und mit Gadgets 2.0 (erwartet seit 2012) etwas besser zu strukturieren und robuster und effizienter zu machen. Dem geht aber eine ein- oder mehrwöchige Entscheidungsphase voraus.
• editcontentmodel um mit JS und CSS besser operieren zu können. Bei content models geht es gerade um technische Transformationen des Seitentypes (JS/CSS/Wikitext/Massennachrichtenliste/Lua).
  • Ich halte absolut rein gar nichts davon, an völlig unerwarteten Stellen das content model einer Seite zu ändern.
  • Das sollte die absolute Ausnahme bleiben. Es gibt praktisch keine wirkliche Notwendigkeit dafür.
  • Alle Seiten stehen mit dem erwarteten content model genau in dem Namensraum mit genau dem Seitennamen, wo sie hingehören. Darüber hinaus irgendwo Überraschungseffekte einzubauen, führt nur dazu, dass man die Seiten nicht mehr findet, weil sie irgendwo versteckt wurden, und Menschen wie Software reingelegt werden.
  • Nicht alles, was technisch irgendwie machbar wäre, soll man auch tun.
• managechangetags, deletechangetags
  • Das hätte nur dann Sinn, wenn beabsichtigt wäre, für alle angemeldeten Benutzer die Benutzeroberfläche zu verändern und in jeder Versionsgeschichte bei jeder Version ein zusätzliches Schaltelement zum Ändern der projektdefinierten Tags einzufügen. Wir verwenden aber keine projektdefinierten Tags, schon um Edit-Wars um das Taggen von Edits als Vandalismus oder URV oder sonstwie missliebig zu vermeiden.
  • Es gab in den letzten fünf Jahren vermutlich nur einen Fall, bei dem absichtlich von Tag-Management Gebrauch gemacht wurde: Von mir selbst in Auftrag gegeben.
  • Alle anderen geschahen durch Verklicken und wurden nach einigen Stunden wieder revertiert.
  • Wobei die Beschreibungstexte wie dieser Link offenbar zu den normalen Systemnachrichten gehören würde und den Oberflächenadministratoren dieses Recht ohnehin zusteht.
• abusefilter-modify
  • Das sollen mal schön die gewählten Admins weiter machen, die sich damit auskennen und die für die betroffenen Benutzer teils recht einschneidenden Konsequenzen anordnen und zu verantworten haben.
  • Programmiertipps und Erprobung komplexer Filter kann auf BETA laufen und von dort kopiert werden.

VG --PerfektesChaos 14:12, 19. Aug. 2018 (CEST)

Wie oben geschrieben käme man um eine Wahl meines Erachtens ohnehin nicht herum, wenn man eine eigene Gruppe haben will, die nicht auf dem Admin aufbaut. Auf Zuruf geht nicht. Insofern sehe ich kein Problem darin, die anderen Adminrechte mit zu vergeben. Vorteil wäre, dass man technisch keine neue Gruppe bräuchte. -- Perrak (Disk) 14:35, 20. Aug. 2018 (CEST)

Naja, die Konstellation MB (umseitig) + BOA – sysop steht ja hier im Raum.

Normaler sysop, normale Wahl, und die JS/CSS will ich auch noch, ist ja nichts Ungewöhnliches und bedürfte dieses MB nicht.

Wenn sysop-Rechte, dann auch Wahl; zumal die Argumentation, man müsse für BOA-Tätigkeiten unbedingt auch sysop-Rechte haben, absolut nicht zieht, wie oben dargestellt. Die BOA-Aufgaben im MW-NR lassen sich problemlos ohne sysop umsetzen, weil reine Programmiererei.

Wenn irgendwann mal eine große Modernisierung, Restrukturierung und Aufräumaktion anstünde (und sie ist eigentlich längst überfällig), dann wird das über Wochen diskutiert und die hinterher als Sahnehäubchen zu löschenden Seiten sind Wochen vorher bekannt. Was eine einmalige Aktion ist.

Dieses MB hier will ja gerade klären, wie BOA ohne sysop aussehen könnte. Dafür ist aber dieser ganze Abschnitt hier ziemlich desorientiert angefangen.

VG --PerfektesChaos 14:57, 20. Aug. 2018 (CEST)

Danke für den kompetenten Input, genau das habe ich mir zu dieser Frage gewünscht. Die „Desorientiertheit“ dieses Abschnittes rührt daher, dass ich keine Richtung einschlagen wollte, wie diese Gruppe auszugestalten wäre, und erstmal einige Ideen, die mir so in den Kopf kamen, dargestellt habe. Ich möchte PC auch dahingehend zustimmen, dass ich nicht denke, dass Administratorrechte mit dieser Funktion einhergehen sollten, da beide im wesentlichen disjunkt sind und bis auf Vandalismus im BNR kaum Berührungspunkte haben.

Ich weiß nicht, ob du bei delete und import in ausreichendem Maße bedenkst, dass Administratoren und Importeure solche Seiten aktuell nicht löschen und wiederherstellen können. Effektiv würde so Nachimportieren auch mit deinem Vorschlag auf eine sehr kleine Gruppe von Nutzern eingeschränkt, aktuell 2, die diese Rechte beide für OS-Tätigkeiten haben. Das halte ich für suboptimal. delete wäre zumindest als Übergangslösung zu erwägen, da Phab-Tasks in den letzten Wochen schon mal insbesondere dann länger dauern, wenn sie eigentlich dringend sind.

managechangetags habe ich gerade aus dem Grund hinzugefügt, dass alle Beschreibungstexte und Anzeigenamen ohnehin bereits durch Oberflächenadministratoren bearbeitet werden können und die Rechte so konsistenter wären.

--MGChecker – (📞| 📝| ) 15:43, 20. Aug. 2018 (CEST)

Ich schrieb, dass es für delete und import keine akute Notwendigkeit gibt, eine solche Aktion auszuführen, weil sie auch Tage und Wochen später umgesetzt werden können.

Im MW-NR geht beidem ein mehrwöchiger Entscheidungsprozess voraus, das letzte delete war 2014, import gab es im letzten Jahrzehnt mutmaßlich nur zwei (meine), die anderen Versionen erfolgten durch trivialen edit + URL in BK, und eine Wiederherstellung im MW-NR hat es meiner Kenntnis nach noch niemals gegeben.

Die MW-Software soll gefälligst lernen, dass für Aktionen, die Seiten und Versionen aus dem Gefahrenbereich entfernen, keine BOA-Rechte erforderlich sein sollten, und gut ist. Mal sehen, wer schneller ist, die MW-Entwickler oder dieses MB?

Die einzige Situation, bei der es für den September auf die aktuell neun Rechteinhaber ankäme, wäre die Entfernung von gemeingefährlichem Müll aus dem BNR, aber dafür tut es auch der OS-Mechanismus. Einen Präzedenzfall hinsichtlich JS/CSS aus dem letzten Jahrzehnt wüsste ich grad nicht.

Alles in allem ist sysop+BOA also eine sehr seltene Angelegenheit, die meist sofort ohne sysop bereits gesichert werden kann, und ansonsten auch eine Woche Zeit hätte.

VG --PerfektesChaos 16:10, 20. Aug. 2018 (CEST)

Bürokraten

@Itti, MBq, Septembermorgen, Xqt: Zur Info, da ihr am Ende die Vergabe durchführen müsst. --MGChecker – (📞| 📝| ) 00:58, 9. Aug. 2018 (CEST)

Vorheriger Konsens unter den Beteiligten (Review)

Zwar ist der Begriff Code of Conduct grad bei MediaWiki unter die Räder gekommen; gleichwohl sollten sich alle Berechtigten fortan auf einen Verhaltenskodex verpflichten; insbesondere ggf. ohne Wahl Berufene.

• Kurz: Wesentliche Änderungen der Oberfläche, die keinen akuten Notfall abwenden, müssen vorher angemessen lange vorher unter allen Berechtigten nebst Einbeziehung der gesamten Community diskutiert und dürfen nur im Wiki-Konsens (=überwiegenden) umgesetzt werden.
• Nähere Einzelheiten, was genau unter schwammigem „wesentlich“ oder „angemessen lange“ oder „akuter Notfall“ zu verstehen wäre, hatte ich 2014 ausführlich vorgestellt.

VG --PerfektesChaos 14:20, 19. Aug. 2018 (CEST)

Hat es einen Grund, dass dieser sehr sinnvolle Ansatz nie „offiziell“ wurde? Ansonsten ist es ja genau das Prinzip, nach dem man beim Bearbeiten von JS heute schon vorgehen sollte. --MGChecker – (📞| 📝| ) 14:26, 20. Aug. 2018 (CEST)

Die damals >200 Admins hüllten sich in Schweigen und wollten keine Stellung dazu nehmen.

Die Handvoll BOA, insbesondere die eher einstellige Zahl nicht-OS, käme da vielleicht eher zu Potte.

Im MW-NR kann/konnte traditionell jeder Admin jederzeit ohne Absprache umbauen, wie es grad gefiel – so wie auch jeder eine LD oder VM einzeln in der Stunde entscheidet, und fertig. Es wurde mit Erschaffung der Projekt-Ressourcen niemals ein spezielles Verfahren, geschweige denn ein Review von Programmierungen eingeführt.

VG --PerfektesChaos 15:11, 20. Aug. 2018 (CEST)

Theoretisch ja. Größere Änderungen wurden meiner Erinnnerung nach aber immer erst angekündigt und nach Diskussion umgesetzt. -- Perrak (Disk) 20:47, 20. Aug. 2018 (CEST)

Nö, nicht ganz immer; ich erinnere mindestens zwei spontane Aktionen, die mittelfristig dann aber keinen Bestand hatten, und bei vorheriger Diskussion nie realisiert worden wären. VG --PerfektesChaos 21:34, 20. Aug. 2018 (CEST)

Wahl

Warum sollen die Oberflächen-admins einzeln von der community gewählt werden? ich würde vorschlagen, interessierte und geeignete direkt zu benennen und ihnen die Möglichkeit zur späteren ko-optation auf Anfrage zu geben. Zudem sollte es eine Projektseite geben, wo öffentliche Diskussionen und eine Liste zugänglich sind.-- Leif Czerny 14:19, 19. Okt. 2018 (CEST)

Ankündigung Verschiebung nach eingeschlafene Meinungsbilder

Da das Meinungsbild seit Erstellung im August inhaltlich nicht bearbeitet wurde und die Diskussion eingeschlafen ist, werde ich das Meinungsbild nach eingeschlafene Meinungsbilder verschieben, wenn die Diskussion / Ausarbeitung nicht in den nächsten 7 Tagen wieder aufgenommen wird. Groetjes --Neozoon (Diskussion) 08:56, 11. Nov. 2018 (CET)

verschoben nach eingeschlafene Meinungsbilder wie angekündigt. Groetjes --Neozoon (Diskussion) 23:42, 27. Nov. 2018 (CET)

Verschoben ins MB Archiv

MB wurde ins MB-Archiv verschoben. Groetjes --Neozoon (Diskussion) 00:23, 21. Aug. 2021 (CEST)