Wikipedia Diskussion:Meinungsbilder/Einführung SG-Benutzergruppe

Letzter Kommentar: vor 12 Jahren von SG-Benutzergruppe-MB-Ersteller

Dieses Meinungsbild wurde vom Initiator zurückgezogen, da unter den Mitgliedern des Schiedsgerichts und vielen anderen Benutzern keine Notwendigkeit für getrennte Benutzerrechte gesehen wird. Kann man verstehen, da keiner gerne in seinen Rechten beschnitten wird. Nur wenige Benutzer haben sich bei der Ausarbeitung hierfür interessiert.

Unabhängig davon, wurde auf der Diskussionsseite auch über Rechte diskutiert, die nichts mit der Schiedsgerichtsarbeit zu tuen haben, welche man aber weiteren Benutzern geben könnte. Diese Diskussion kann gerne geführt werden, sollte dann aber im Rahmen eines anderen Meinungsbildes passieren, damit nicht nur die 10 Mitglieder des Schiedsgerichts von diesen eher unkritischen Rechten profitieren können, sondern eine neue Benutzergruppe für alle Benutzer geschaffen wird, die entweder automatisch oder per Antrag verteilt wird.

Aus den genannten Gründen zieht der Initiator das Meinungsbild zurück. Gerne kann das Meinungsbild von anderen Benutzern auf dieser Seite oder auf einer neuen Seite weitergeführt werden. Benutzer:SG-Benutzergruppe-MB-Ersteller muss dabei dann nicht weiter erwähnt werden. Vielen Dank.

SG-Benutzergruppe-MB-Ersteller (Diskussion) 06:48, 23. Nov. 2012 (CET)Beantworten

Bitte nur zum Thema Einführung einer Benutzergruppe "Mitglied des Schiedsgerichts".

Allgemeine Anregungen und Diskussionen zum Thema Schiedsgericht sind auf der entsprechenden Diskussionsseite besser aufgehoben.

Entsprechende Abschnitte sollten hier entfernt werden.

browsearchive

Bearbeiten

Grundsätzlich ist browsearchive sinnvoll, das führt auf Spezial:Wiederherstellen, wo man mit Wildcards gelöschte Seiten suchen kann. Nun gibt es leider ein Problem mit der Seite, das mich schon eine Weile zerknirscht. Und niemand kann oder will es lösen. Es ist der Bug bugzilla:19725 (den Mike.lifeguard imho auf mein Anraten mal angelegt hatte); in kurz: Auch wenn ein Oversight alles der gelöschten Seite geoversightet hat, die ganze Aktion entfernt hat etc., kann man immer noch über Special:Undelete (= Spezial:Wiederherstellen, Speciaal:Terugplaatsen etc.) die geoversighteten Namen sich anschauen. So führt dies noch immer auf den Namen Gebruiker:XXX ist eine miese Sau!. Das ist ja nun noch nicht so schlimm, man stelle sich aber mal Telefonnummern, Adressen, Realnamen etc. vor (alles schon erlebt). Ich spreche mich hiermit bis zur Klärung des Bugs gegen browsearchive aus. Grüße, —DerHexer (Disk.Bew.) 01:10, 6. Jun. 2011 (CEST)Beantworten

Bei dem von dir genannten Fall wurde das Benutzerkonto umbenannt, somit ist der Name auch noch im Logbuch verzeichnet. Hier könnte man die geoversighten Versionen ja hinterherschieben und hätte das gelöst. Bei Verschiebung ohne Weiterleitung begrenzt sich damit das ganze nur noch aufs Logbuch, welches man zur Not auch noch unsichtbar machen kann. Ist Aufwand, das stimmt, aber wenn man generell die Transparenz einschränkt, ist das ungünstig, da beim Oversighten ja immer erkennbar sein soll, das dort etwas war, nur nicht was. Da aber die Identifizierung von Versionen immer über den Seitennamen geschieht, ist es schwierig hier zu trennen.
Ich würde aber trotzdem dieses Recht vergeben wollen, da es maximal 10 weitere Benutzer in den Kreis einschließt, die ein gewisses Vertrauen der Community bekommen haben. Das sollte nicht das Fass zum überlaufen bringen, wenn auch das grundlegende Probem unschön ist. SG-Benutzergruppe-MB-Ersteller 22:33, 10. Jun. 2011 (CEST)Beantworten
+1 zum letzten Satz. --Leyo 15:22, 16. Jun. 2011 (CEST)Beantworten
Es schließt ja gar nicht weitere 10 Benutzer in den Kreis ein, da diese weiteren 10 Benutzer das Recht ja bislang auch schon immer hatten, es würde also am jetzigen Zustand gar nichts verändern, die SGler könnten das Recht einfach normal weiter benutzen. Und das ist ja der Sinn der Sache, egal welche Bugs dazu nun existieren oder auch bereits inzwischen gelöst sein mögen. Den SGlern wird ja durch die Wahl das Vertrauen ausgesprochen, die so erlangten Daten nicht zu missbrauchen, sonst könnte man sich die Wahl ja auch ersparen und einfach ein paar Freiwillige dafür nehmen. Zudem müssen sie ja jetzt neuerdings sogar noch mehr als 50 % der Stimmen erhalten. --Geitost 00:45, 23. Sep. 2012 (CEST)Beantworten

benötigte Rechte – Missbrauchsfilter

Bearbeiten

ebenfalls nötig bzw zweckdienlich und nicht missbrauchsgefährdet wären aus meiner sicht abusefilter-log-detail, apihighlimits. ca$e 16:40, 16. Jun. 2011 (CEST) ps: zwei gestrichen. evtl. auch noch abusefilter-modify. ca$e 18:33, 16. Jun. 2011 (CEST)Beantworten

Klingt sinnvoll. Gibt's eine Seite, wo diese Rechte genau beschreiben werden und im MB verlinkt werden könnte? --Leyo 17:39, 16. Jun. 2011 (CEST)Beantworten
habe in den Manuals auf mediawiki.org gesucht, nix da... -jkb- 17:50, 16. Jun. 2011 (CEST)Beantworten
nicht wirklich, aber immerhin [1], [2], [3]. ca$e 17:53, 16. Jun. 2011 (CEST)Beantworten
etwas auch hier: http://www.mediawiki.org/wiki/Abusefilter -jkb- 17:54, 16. Jun. 2011 (CEST)Beantworten
hier http://meta.wikimedia.org/wiki/Abuse_filter kann man sehen, wo was aktiviert ist, -jkb- 18:18, 16. Jun. 2011 (CEST)Beantworten
hm stimmt. da hatte ich mich offensichtlich vertan, insb. ist ja bei uns abusefilter-log-detail schon bei autoconfirmed mit dabei. wenn ich richtig sehe, kann man die abusefilter-konfiguration, wenn sie geschützt ist, auch nur mit abusefilter-modify anschaun, oder? das fände ich schon nützlich, auch die letzten SG-fälle hatten partiell mit einem befund zu tun, der die abusefilter-logs mitbetraf und da sollte man schon sehen können, wie genau das konfiguriert war, als es den logeintrag generierte. siehe auch noch http://de.wikipedia.org/wiki/Spezial:Gruppenrechte . ca$e 18:33, 16. Jun. 2011 (CEST)Beantworten
apihighlimits braucht es nur für Abfragen mit der API, das werden die Schiedsgerichts-Mitglieder wohl er weniger im Rahmen des Schiedsgerichts machen.
Zum AbuseFilter: Es gibt aktuelle folgende Rechte zu vergeben. Wobei einige Rechte andere wieder einschließen, daher werden nicht alle Rechte aktuell auch verwendet.
  • abusefilter-modify (Bearbeitungsfilter bearbeiten)
  • abusefilter-log-detail (Erweitertes Bearbeitungsfilter-Logbuch einsehen)
  • abusefilter-view (Bearbeitungsfilter ansehen)
  • abusefilter-log (Bearbeitungsfilter-Logbuch einsehen)
  • abusefilter-private (⧼right-abusefilter-private⧽)
  • abusefilter-modify-restricted (Bearbeitungsfilter mit privilegierten Aktionen bearbeiten)
  • abusefilter-revert (Alle Bearbeitungen durch einen bestimmten Missbrauchsfilter zurücksetzen)
  • abusefilter-view-private (Als privat markierten Bearbeitungsfilter einsehen)
  • abusefilter-hidden-log (Versteckte Einträge im Bearbeitungsfilter-Logbuch einsehen)
  • abusefilter-hide-log (Einträge aus dem Bearbeitungsfilter-Logbuch ausblenden)
Ich werde mal schauen, welche Rechte hier sinnvoll sind. Ich habe gesehen, das es einige Filter gibt, die als privat gekennzeichnet sind, wenn hier sinnvolle Informationen für Mitglieder des Schiedsgerichts bei sind, dann sollten Sie die Daten auch einsehen können. SG-Benutzergruppe-MB-Ersteller 16:33, 17. Jun. 2011 (CEST)Beantworten
Ich glaube, dass ein Mitglied des Schiedsgerichts Probleme beim Verständnis der Bedingung des Filters haben wird. Daher halte ich es für sinnvoller, wenn ein Admin dem Schiedsgericht per Mail im Fließtext erklärt, was der Filter zu der Zeit gemacht hat. Das notwenige Benutzerrecht ist abusefilter-view-private, es erlaubt, die eingestellte Aktion des Filters einzusehen, aber es erlaubt nicht die Versionsgeschichte einzusehen, daher glaube ich nicht, dass dieses Benutzerrecht einen Mehrwert hat. Falls es doch so sein sollte, ergänzt es bitte vorne. SG-Benutzergruppe-MB-Ersteller 18:18, 17. Jun. 2011 (CEST)Beantworten
"Ich glaube, dass ein Mitglied des Schiedsgerichts Probleme beim Verständnis der Bedingung des Filters haben wird." - eines vielleicht schon, anderes vielleicht nicht.
und zu apihighlimits: erst vor kurzem gab es SG-anträge bzgl. DWR und BF. falls man diesen weiter nachgegangen wäre, hätte man durchaus davon gebrauch machen können. ca$e 18:21, 17. Jun. 2011 (CEST)Beantworten
Ohne jemandem zu Nahe tretten zu wollen: Ich denke, es werden aber immer weniger als mehr Leute gewählt werden, die die Syntax und das Zusammenwirken verstehen, daher mein Satz, kann natürlich auch anders sein.
Zu apihighlimit: Dann weiß ich wohl zu wenig über die Arbeitsweise des Schiedsgerichts und stelle sie mir gerade etwas komisch vor, aber gut, soll es auch geben. Der Umfang kann auch mal sehr groß werden. SG-Benutzergruppe-MB-Ersteller 18:33, 17. Jun. 2011 (CEST)Beantworten
es gibt nicht "die" arbeitsweise "des" SG, sondern arbeitsweisen einzelner SG-mitglieder. im derzeitigen SG finden sich mehrere leute, die mathe, physik, chemie, informatik o.ä. mindestens studiert haben, programmierpraktika etc gehören da normalerweise immer noch zum curriculum und soo kompliziert ist die abusefilter-syntax dann auch wieder nicht; man kann sich sowas auch zusammenstückeln, soo wichtig ist es also nicht, aber ich sehe gar keinen grund, um derlei zu feilschen. ca$e 18:54, 17. Jun. 2011 (CEST)Beantworten
+1, und übrigens darf man annehmen, dass es unter den SG-Mitgliedern vielleicht ein oder zwei geben dürfte, die wissen, bei wem man die Deataills im Bedarfsfall nachfragen könnte. -jkb- 14:45, 18. Jun. 2011 (CEST)Beantworten
Da mit MediaWiki 1.19 die Logeinträge zu privaten Filtern auch als privat markiert werden, habe ich mal das Recht zum anschauen der privaten Filter ergänzt, weil die Logbucheinträge vermutlich interessant sein können. SG-Benutzergruppe-MB-Ersteller (Diskussion) 21:28, 3. Apr. 2012 (CEST)Beantworten
Seit dem 2. Juli gibt es eine neues Benutzerrecht "abusefilter-log-private", welches nur das einsehen der Logbucheinträge zu privaten Filtern ermöglicht, ohne das einsehen des Filters an sich. SG-Benutzergruppe-MB-Ersteller (Diskussion) 08:15, 1. Aug. 2012 (CEST)Beantworten

Nötigkeit

Bearbeiten
Klingt ja ganz sinnvoll, diese Trennung in zwei verschiedene Benutzergruppen mit klaren Namen, die auch von lokalen Bürokraten vergeben werden können - das würde das Log bestimmt übersichtlicher machen.
Was mich jetzt aber noch interessieren würde: Wie viele Benutzer sitzen/saßen im Schiedsgericht, die nicht bereits Admin waren? Haben diese Benutzer irgendwann Rechte verwendet, die ihnen mit der neuen Gruppe entzogen würden, und wenn ja wozu? Oben wurde etwa bereits eine Sperrung von SG-Seiten genannt. -- Bergi 16:35, 16. Sep. 2012 (CEST)Beantworten
Aktuellen gibt es 7 Mitglieder die die Adminrechte bekommen haben, siehe Wikipedia:Liste der Administratoren#Administratoren als Schiedsrichter, da sie aktuell keine Admins sind. Da dies mehr als die Hälfte des Schiedsgerichts ist, kann man nicht mehr von einer Ausnahme für "ein paar" Mitglieder sprechen. Ob ein Mitglied des Schiedsgerichts mit seinen Rechten (unbewusst) etwas gemacht hat, was er eigentlich nicht durfte, ist schwierig nachzuvollziehen. Ich möchte auch keinen Anprangern. Ich habe nur mal gelesen, das jemand die JS/CSS-Seiten eines Fremden bearbeitet hatte, obwohl er es eigentlich nicht sollte/durfte. SG-Benutzergruppe-MB-Ersteller (Diskussion) 19:29, 16. Sep. 2012 (CEST)Beantworten
Es wurden mehrfach von einigen SGlern (Nichtadmins) Seiten gelöscht oder geschützt (außerhalb des SG-Bereichs) und dergleichen. --Geitost 21:03, 18. Sep. 2012 (CEST)Beantworten
Dürfen die SG-A auch Seiten unterhalb von WP:SG löschen? Beispielsweise Wikipedia:Schiedsgericht/Anfragen/Admin löscht einen Link und diskutiert nicht sondern diktiert? Ich dachte, es wird nur das bearbeiten von geschützten Seiten gebraucht. SG-Benutzergruppe-MB-Ersteller (Diskussion) 21:18, 18. Sep. 2012 (CEST)Beantworten
Eigentlich nicht, denke ich, aber ich meinte hier explizit auch das Löschen/Wiederherstellen von Seiten, die gar nix mit dem SG zu tun haben, da ist es jedenfalls völlig eindeutig (beispielsweise eigene Benutzer(unter)seiten, statt das normal per SLA zu machen, gerade vor einer Woche noch). Es gibt ja immer auch ein paar reguläre Admins im SG, die dann SG-Seiten löschen oder Versionen davon versionslöschen können (wenn nötig) und das auch schon mal gemacht haben. Das sollte auch ausreichen. Ist normal nicht so gedacht, dass ein SG-Mitglied irgendwas löscht, ohne regulär Admin zu sein; insbesondere das Bearbeiten-Können vollgeschützter SG-Seiten ist sinnvoll und auch die SG-Seiten-Schutze waren ja so ok, das wäre aber auch möglich durch die gewählten Admins im SG, wäre also auch nicht tragisch. Es ist ja nicht möglich, Seitenschutze nach Namensraum oder nur SG-Seiten schützen zu können.
Was ich sinnvoll fände (wenn schon das Seitenschützen der SG-Seiten wegfällt, das bis dato unproblematisch erledigt werden konnte, wäre eine Aufwertung der Rechte, die sie durch die neue Benutzergruppe erhalten. Beispielsweise editprotected hatte ich ja eben hinzugefügt. Da könnte man ihnen mMn auch erlauben, alle vollgeschützten Seiten wie Admins bearbeiten zu können, das ist ja bisher nicht so. Dann wäre das Recht auch uneingeschränkt benutzbar und sie müssten dabei nicht nachdenken, wo sie gerade was bearbeiten dürfen und wo nicht.
Außerdem fände ich es noch nett, wenn sie auch MediaWiki-Seiten normal bearbeiten dürften (editinterface). Schließlich wird ihnen durch die Wahl ja explizit Vertrauen ausgesprochen. Wenn also unproblematische Dinge im MWNR erledigt werden müssten, warum sollten sie das eigentlich nicht machen dürfen? Wer sich die Arbeit mit den SG-Anfragen freiwillig aufbürdet, sollte auch ein paar Extrarechte dafür bekommen. Oder gibt es dafür irgendwelche Bedenken? So was ist ja jederzeit von jedem nachvollziehbar und einsehbar, im Gegenteil zu sensibleren Funktionen wie das Löschen von Seiten, wo der Seitentext dann ja weg ist. Oder gibt es bezüglich editinterface irgendwelche Bedenken? --Geitost 21:44, 18. Sep. 2012 (CEST)Beantworten
Übrigens wurde gerade erst vor 4 Stunden von dem SG-Admin eine Seite im eigenen BNR (eigentlich unproblematisch) verschoben, ohne eine Weiterleitung anzulegen, das ist also sicher keine Ausnahmesituation. Da stellt sich dann auch die Frage, ob man das standardmäßig ins Repertoire mit aufnehmen sollte, damit das dann einfach (neu nach dem MB!) ganz normal genutzt werden darf, statt das eigentlich ja nicht zu sollen. Denn warum man als Admin plötzlich nach einer Adminwahl alle möglichen sensiblen Rechte bekommen soll, als SG-Mitglied aber nur eine winzige Auswahl nur fürs SG, aber dort eine wichtige Arbeit für die Gemeinschaft erledigt, müsste man ja auch noch mal schlüssig jemandem erklären. --Geitost 21:54, 18. Sep. 2012 (CEST)Beantworten
Deine Gedanken sind nachvollziehbar, aber ich wollte nur eine Gruppe schaffen, die auf die Arbeit des Schiedsgerichts zugeschnitten ist. Bei deinen Überlegungen kommt wieder der Gedanke einer Gruppe zwischen Sichter und Admins durch. Dieses sollte aber nicht hier geklärt werden und auch wohl nicht diese Gruppe sein.
Soweit ich es sehe, geht es nicht nur um die Bearbeitung von geschützten Seiten, sondern auch um das Schützen der Seiten des SGs, daher braucht man nicht editprotected verteilen, sondern sollte darüber nachdenken, ob das Schützen von Seiten überhaupt notwendig ist, wenn doch noch Änderungen kommen können. SG-Benutzergruppe-MB-Ersteller (Diskussion) 18:06, 19. Sep. 2012 (CEST)Beantworten
Zur Frage "Dürfen die SG-A auch Seiten unterhalb von WP:SG löschen?": Bisher gibt es keine offizielle Einschränkung dessen, was Mitglieder des SG dürfen. Es gibt nur die freiwillige Beschränkung auf solche Funktionen, die mit der Tätigkeit im SG zusammenhängen. -- Perrak (Disk) 18:01, 20. Sep. 2012 (CEST)Beantworten

markAdmins & Technik

Bearbeiten

Ich unterstütze den Vorschlag, weil ich denke, dass er zur Klarheit und Transparenz beiträgt.

  • Insbesondere verspreche ich mir im Helferlein markAdmins klarere Titel. Es hat Ewigkeiten gedauert, bis ich den Unterschied zwischen einem SG-A und einem SG/A (oder A/SG?) überhaupt mitbekommen hatte, dass das ein Minuszeichen darstellen soll und was und warum.
  • Ich erwarte von keinem SG-Mitglied eine bewusste Fehlbenutzung irgendwelcher Rechte, und dies war auch offenbar noch nie der Fall und bietet deshalb keinen Anlass zur Besorgnis. Was bei diesem Einzelfall los gewesen wäre, was hinterher der geänderte Benutzer dazu gesagt hatte oder ob jener überhaupt noch aktiv war; ich buche das mal unter Edit-Unfall.
  • Die gegenwärtige Situation bringt die SG-Mitglieder allerdings in die Gefahr, einmal aus Versehen verbotene Aktivitäten auszuführen; sei es durch schlichten Fehlklick oder infolge Irrtum über die Zulässigkeit einer Aktion in diesem Zusammenhang. Das wäre zwar technisch zu umgehen, indem per CSS alle bekannten Knöpfe und Links ausgeblendet würden, aber es kann immer mal bei einem Gadget ein Aktionsfeld auftauchen, das gar nicht benutzt werden darf.
  • Die Mediawiki-Software ist bewusst so geschrieben, dass eine freie Definition von Benutzergruppen leicht möglich ist wie auch die freie Zuordnung von Rechten zu dieser Gruppe. Hiervon sollte man bei berechtigtem Interesse auch Gebrauch machen; die einmalige Erstellung ist kein großer Akt. Ein englischsprachiger Name (arbiter) könnte weltweites Vorbild sein und würde die Software-Wartung und das Verständnis erleichtern. Ob dann die Bürokraten anhand von Wahlergebnissen nun SG oder A neu zuordnen, entziehen oder was immer, ist aufs Jahr kein dramatischer Unterschied.
  • Um welche Rechte es sich konkret handeln soll und um welche nicht mögen Sachkundigere ermitteln. Es sind alle Admin-Rechte, die SG-Mitglieder nutzen dürfen; unabhängig davon, ob sie es technisch können oder wollen. Ich hoffe, darüber besteht Klarheit; es wäre gar irgendwo nachlesbar? Falls nicht, ist es ja eine schöne Gelegenheit, das mal explizit zu erarbeiten.

Beste Grüße --PerfektesChaos 22:23, 16. Sep. 2012 (CEST)Beantworten

Nicht nur da, sondern auch auf Spezialseiten wie Spezial:Benutzer oder in anderen Gadgets wie NavPops, die auf Basis einer API-Abfrage die Bentzergruppenzuordnung vornehmen. markAdmins müsste man vorne noch einpflegen. SG-Benutzergruppe-MB-Ersteller (Diskussion) 21:01, 17. Sep. 2012 (CEST)Beantworten
Nachtrag: Ich bin entsetzt über die Causa Hosse. Als ich das Vorstehende vor einer Woche schrieb, hatte ich sowas nicht für möglich gehalten. Unbeabsichtigte Bedienungsfehler interessieren mich nicht. Aber hier wurden vorsätzlich Admin-Funktionen ausgeübt, um die Normalbenutzer einen mit 2/3-Mehrheit-Mandat versehenen Admin bitten müssen. SG-Mitglieder sind jedoch Normalbenutzer. Und da ist offensichtlich mindestens einem Würdenträger der höchsten Instanz etwas zu Kopf gestiegen. --PerfektesChaos 11:29, 23. Sep. 2012 (CEST)Beantworten
Besonders glücklich bin ich über diese Nutzung zwar auch nicht, aber bevor hier mit zweierlei Maß gemessen wird, gestatte ich mir den Hinweis, dass der Normalbenutzer mitnichten eine Zweidrittelmehrheit benötigt, sondern dieses Recht durch die Hintertür per Bot-Account abgreifen kann. Schon bevor überhaupt Admins das Recht zum Verschieben mit unterdrückter Weiterleitung erhielten hatte jeder Bot das Recht, was einige der Bot-Betreuer veranlasste, sich mit dem Bot-Account anzumelden und händisch ohne Weiterleitung zu verschieben. Stellt sich also die Frage, warum auf jemanden eingedroschen wird, der irgendwie gewählt wurde, während andere sich für nichts rechtfertigen müssen, solange sie nur einen Zweitaccount aufgemacht und sich auf Zuruf (ohne Bewertung der Person) das Botflag abgeholt haben. --32XAutorenngilde № 1 15:03, 23. Sep. 2012 (CEST)Beantworten
Na ja, auf Zuruf? Immerhin müssen ja die Bürokraten auch dort das Flag vergeben genau wie bei Admins auch. Auch wenn es da keine Wahl gibt. Aber das ist interessant, was du da schreibst.
Aber bevor allzu sehr auf Hosse rumgeritten wird: Hosse ist nicht die Spitze des Eisbergs, denn er hat nicht in fremdem BNR eine Seite gelöscht und niemandem das Recht IP-Sperre-Ausnahme erteilt, das waren 2 andere (Ex-)SGler. Wobei einer davon die Hosse-Sache im SG beurteilen sollte und hat. Irgendwie auch seltsam. Insofern tatsächlich Kirche und Dorf, was das angeht. --Geitost 15:30, 23. Sep. 2012 (CEST)Beantworten

Ganz andere Idee

Bearbeiten

Wie wär's damit: Alle Mitglieder des Schiedsgerichts sind automatisch auch "vollwertige" Admins und dürfen diese Rechte in vollem Umfang nutzen. Es gibt ja schon immer SG-Mitglieder, die zugleich Admins sind, das scheint kein grösseres Problem zu sein. Wir brauchen sowieso mehr Admins. Gestumblindi 00:44, 19. Sep. 2012 (CEST)Beantworten

Wir brauchen ein Schiedsgericht, dessen Mitglieder bereit sind, ihre Adminrechte abzugeben. --Felistoria (Diskussion) 00:52, 19. Sep. 2012 (CEST)Beantworten
Und warum? Das Schiedsgericht gibt's ja nun schon ein Weilchen, und dass stets einige der Schiedsrichter gleichzeitig "vollwertige", gewählte Admins waren, hat sich m.E. in dieser Zeit nicht als eines seiner erheblichen Probleme gezeigt, oder irr' ich mich? Gestumblindi 02:03, 19. Sep. 2012 (CEST)Beantworten
Aber die waren dann auch mit 2/3-Mehrheit vorher gewählt. Also: nein, bin dagegen. Dann müssten die Regularien bei AKs geändert werden, dass man auch schon mit einfacher Mehrheit Admin werden kann, und das finde ich nicht sinnvoll. --Geitost 03:02, 19. Sep. 2012 (CEST)Beantworten
Nun, ich wäre dafür, aber das ist ja wohl bekannt ;-) (MB-Entwurf liegt seit 2010 auf Eis, da die Resonanz damals überwiegend negativ war, aber mir ist in letzter Zeit immer mal wieder durch den Kopf gegangen, dass eine Wiederbelebung sinnvoll sein könnte - jedenfalls bei der nächsten pauschalen Admin-Abwahlaktion, ein paar Admins müssen wir am Ende doch noch haben...) Gestumblindi 03:06, 19. Sep. 2012 (CEST)Beantworten
Ja sicher muss man einige haben, aber die einfache Mehrheit ist mMn jedenfalls der falsche Ansatz dafür. Ist sicher etwas schwierig, einen guten anderen bzw. besseren Ansatz zu finden. Aber der Schlüssel liegt auf jeden Fall bei den AKs usw. bzw. darin, wie die Arbeit wertgeschätzt wird und wie viele PAs man sich hier überhaupt gefallen lassen muss. Das Klima lässt ja allgemein eh schon zu wünschen übrig, da ist es völlig klar, dass sich das am Ende auch bei den Admins selbst wieder bemerkbar macht und dann kaum noch wer sich so was antun mag. --Geitost 03:12, 19. Sep. 2012 (CEST)Beantworten
Und es gehen ja auch nicht nur die aktiven Admins flöten, sondern auch die aktiven normalen Mitwirkenden und Autoren. Ich bin gerade heute beim Fixen von Seiten noch über Benutzer Diskussion:Guidod gestolpert, der seine reguläre Sig irgendwie ständig durchgestrichen hat und der sich durch die zu erwartenden LDs mit unterirdischem Diskussionsstil zu neuen Artikeln sich von dannen gemacht hat (anscheinend hat man es aber doch noch nicht ganz geschafft, ihn von hier zu vertreiben). Geht mir ja auch nicht anders, ich schreib oder übersetz ja auch keine Artikel mehr, was soll man sich die Arbeit damit machen, damit es dann möglichst schnell wieder getonnt wird und man dafür auch noch blöd angemacht wird? So was kann ich mir auch gut ersparen. Also bitte an einer anderen Stelle ansetzen, zum Beispiel einer Reform der nicht recht funzenden Strukturen um VM/SP/LD oder so. --Geitost 03:21, 19. Sep. 2012 (CEST)Beantworten
Hm, aber im Meta-Bereich beteiligst du dich ja noch recht fleissig, möchtest du dich nicht auf WP:AK eintragen? ;-) Gestumblindi 04:03, 19. Sep. 2012 (CEST)Beantworten
Nein, sicher nicht. Es hat aber etwas Tragikomisches, dass du das fragst, wo du doch gegen Formalismus und Regelhuberei bist. Da ich dafür bin, dass man Regeln auch einhält und innerhalb der Adminschaft anscheinend damit recht alleine dastünde, wäre ich da völlig falsch. Und warum sollte man einen administrativ bestätigten Adminhasser wählen? Besser ich mache noch größere Bögen um den ganzen VM/SP/LD/LP-Bereich. --Geitost 14:28, 19. Sep. 2012 (CEST)Beantworten
Ich bin gegen Regelhuberei, aber nicht gegen Regeln :-) Zwischen "Regeln einhalten" und "Regeln sklavisch (regelhubernd) einhalten" besteht m.E. ein nicht unwichtiger Unterschied. Hätte z.B. Hosse, über den sich regelhubernde Benutzer aktuell aufregen, seine Adminrechte eingesetzt, um einen Benutzer zu sperren, hätte ich mich auch aufgeregt und Massnahmen gefordert, da ein solcher Einsatz von SG-Adminrechten nach aktuellem Stand eindeutig nicht vorgesehen ist und zu weit geht (so lange die Richtlinien nicht z.B. nach meinem obigen Vorschlag geändert werden). - Es ist im übrigen gut, wenn in der "Adminschaft" ein möglichst breites Meinungsspektrum vertreten ist, daher würde ich dich persönlich sehr gerne mit Adminrechten ausgestattet sehen, mit denen du meines Erachtens keinen Unsinn anstellen würdest. Gestumblindi 22:23, 19. Sep. 2012 (CEST)Beantworten
Wer weiß, vielleicht würde ich die unsinnigerweise gelöschten, sinnvollen Klammerweiterleitungen, auf denen Artikel jahrelang lagen, ja statt sie neu anzulegen einfach wiederherstellen? (Oder auch die gelöschten erwünschten WL von der vollen Rechtsform, das passiert leider auch zu oft; wenn man dann noch die WL unterdrückt dabei, findet man sie nicht mal mehr im Löschlog, sondern nur noch im Verschiebelog, na danke.) :-P Nur dass dabei wohl kein sinnvoller Kommentar dazu möglich wäre, wenn ich das richtig sehe. Na ja, liefe ungefähr aufs Selbe hinaus.
Was die Regelhuberei angeht, wo ist denn da die Grenze? Die schwimmt doch. IP-Sperre-Ausnahme-Vergaben sind auch eindeutig nicht von den MBs als Einsatz der Rechte vorgesehen und Löschungen in irgendjemandes BNR auch nicht – intransparent ist das zudem für alle Nichtadmins, was da nun gelöscht worden sein mag. Trotzdem hat sich darüber keiner aufgeregt, obwohl es doch diese Selbstverpflichtungen noch extra gab (wozu machte man die denn eigentlich, dann kann man sich das ja auch wirklich schenken?). Ich glaube, es regt sich sowieso kaum jemand auf, weil so was einfach dann erst mal keener mitbekommt. Das ist ja das Problem dabei. Wie auch immer, macht man es endlich mal eindeutig und als eigene Benutzergruppe, dann hat man das Problem auch gar nicht erst. Ich weiß eh nicht, warum das nicht schon vor Jahren passiert ist, so schwierig ist es doch gar nicht, eine neue Benutzergruppe einzurichten. Ich kapiere auch nicht, was daran Regelhuberei sein soll, wenn man für neue Benutzergruppen (und das SG ist ja nun mal eine solche) auch die technische zugehörige Benutzergruppe definiert und einrichtet. Das gibt’s bei CU, bei den Bürokraten, bei OS, bei den Sichtern usw., nur ausgerechnet das SG hat keine und soll irgendwie wohl auch keine haben, das Problem dabei kapier ich gar nicht. --Geitost 18:40, 20. Sep. 2012 (CEST)Beantworten

Ganz andere Idee Version 2.0

Bearbeiten

Schiedsgerichtsmitglieder müssen künftig mit Zweidrittelmehrheit gewählt werden (solange dies auch für Adminwahlen gilt), dafür erhalten sie aber auch die vollen Adminrechte, die sie in vollem Umfang einsetzen dürfen. Na? Gestumblindi 22:33, 24. Sep. 2012 (CEST)Beantworten

Ok, 2/3-Mehrheit also. Der Vorschlag kommt mir doch bekannt vor. Siehe dazu auch WD:Meinungsbilder/Ergänzung zum Schiedsgerichtswahlverfahren#Einfache Mehrheit und nicht 2/3 Mehrheit für Kandidaten?. Eine Minderheit von 33,3 % könnte damit das SG faktisch abschaffen. --Geitost 02:36, 26. Sep. 2012 (CEST)Beantworten
Andersrum wird ein Schuh draus: Man wählt nur noch Admins ins SG, dann können sie die Rechte nutzen, wie sie wollen. --Geitost 02:39, 26. Sep. 2012 (CEST)Beantworten

Anfrage-Seiten des SGs überhaupt schützen?

Bearbeiten

Müssen die Anfrage-Seiten des SGs überhaupt geschützt werden? Es scheint in der deutschsprachigen Wikipedia sehr gerne als Arbeitsbeschaffung gemacht zu werden, so werden Diskussionsarchive, Kandidaturen, Wahlen, Meinungsbilder und auch Anfragen geschützt, obwohl die Wahrscheinlichkeit einer Bearbeitung durch andere sehr gering ist und somit ein Schutz eigentlich nicht notwendig ist, weil ja nicht (so viel) präventiv geschützt werden möchte.

Wenn man die Anfrage-Seite sperrt, heißt es für mich, das man den Fall bearbeitet und abgeschlossen hat. Wenn man jetzt noch nachträglich etwas anpassen möchte, Frage ich mich, warum muss das passieren? Und wenn das Regelmäßig ist, warum muss die Seite dann geschützt werden?

Vielleicht könnte man auch hier mit dem Missbrauchsfilter arbeiten und alle Unterseiten des SGs, die in einer bestimmten Kategorie stehen nur durch die neue Benutzergruppe und Admins bearbeitbar machen? Man muss natürlich auch das eintragen der Kategorie entsprechend blockieren. Aber dann wären garkeine Aktionen mehr notwendig und jeder Bearbeitungsversuch wäre nachvollziehbar. Könnte aber auch andere Nachteile haben, die man auf die Schnelle nicht sieht. SG-Benutzergruppe-MB-Ersteller (Diskussion) 18:12, 19. Sep. 2012 (CEST)Beantworten

Welche Probleme hier mit diesem MB künstlich produziert werden ist schon überwältigend. -jkb- 18:28, 19. Sep. 2012 (CEST)Beantworten
Kandidaturen/Wahlen/BSVs (also Abstimmungen zu bestimmten Personen, nicht aber zu Sachfragen) und halt SG-Anfragen (betreffen ja auch normalerweise Personen) werden aus welchen Gründen auch immer vollgeschützt, wodurch das gedeckt ist, erschließt sich mir auch nicht. Meinungsbilder und auch Umfragen (also Abstimmungen über Sachfragen) werden aber nicht geschützt; falls sie das doch mal irgendwann wurden, werden sie wieder entschützt (solange kein akuter Editwar oder ähnlicher anderer Grund als „beendete Abstimmung“ für einen Schutz vorliegt). Zeig mir nur ein einziges vollgeschütztes MB, ich denke, es gibt keins mehr. Wenn du eins findest, kannst du es direkt auf WP:EW zum Entschützen vorschlagen. Ich habe wohl inzwischen alle wieder entschützen lassen, die mal geschützt wurden. Auch Diskussionsarchive werden normalerweise nicht vollgeschützt, das betrifft wohl nur alte Seitenvollschutze, die heute auch niemanden stören. Dasselbe könnte man auch mit SG-Anfragen machen, da auch diese nach Abschluss normalerweise kein typisches Vandalismusziel (oder Ähnliches) mehr darstellen.
Was die Ausweitung dieser sowieso schon zu oft missbräuchlich verwendeten Missbrauchsfilter angeht, so meine ich, dass man diese auf eine möglichst kleine Verwendung einschränken und nicht noch künstlich weitere MBF einrichten sollte. Dann lieber den Seitenschutz belassen, bevor so was wieder dafür eingeführt wird. :-/ Was da heute schon alles gefiltert wird, durchschaut sowieso schon keiner mehr, es sollten viele MBF einfach mal abgeschafft werden. Was ist daran Missbrauch, wenn ein anderer normaler Benutzer in einer ungeschützten Seite in einer Überschrift einen Typo korrigieren würde, weil die Seite halt dann ungeschützt wäre? So etwas erwarte ich nicht in einem Missbrauchsfilter wiederzufinden und es gehört dort auch überhaupt nicht hinein. Zumal es durch keine Regel gedeckt ist, völlig korrekte Bearbeitungen in solchen Missbrauchsfiltern zu filtern. Dasselbe gilt auch für „schweizbezogen“, das Tag setze ich jedenfalls schon gar nicht mehr ein, seitdem es gemissbrauchsfiltert wird. Das haben die Schweizer nun davon. Ebenso setze ich keine Gestorben-Kat mehr irgendwo ein, seit ich feststellte, dass auch dies gemissbrauchsfiltert wird. Man kann Leuten durch so einen Sch… nämlich auch völlig korrekte Edits ganz abgewöhnen. :-( Übrigens auch über eine tatsächliche Verwendung eines solchen Filters hinaus, da man ja genauso wenig mitbekommt, wann ein solcher Filter abgeschafft wird, wie man es auch nicht mitbekommen hat, wann er eingerichtet wurde. Das ist grundsätzlich anders bei Seitenschutzen, bei denen man es sofort sehen kann, wann man eine Seite bearbeiten darf/kann und wann nicht. --Geitost 22:16, 19. Sep. 2012 (CEST)Beantworten
Ja, ok, mit dem Missbrauchsfilter wird schon viel getrieben und da es erst nach dem speichern ersichtlich ist, gibt es auch unschöne Logbucheinträge. Wenn eine Sperre wirklich notwendig ist, sollte man dann nur überlegen, ob das editprotected für diese Seiten gilt oder ob man es freigibt (genauso, wie man es bei den andere Rechten überlegen muss). SG-Benutzergruppe-MB-Ersteller (Diskussion) 11:27, 22. Sep. 2012 (CEST)Beantworten
Ich denke, man sollte einfach mal die Rechte durchgehen und überlegen, welche davon SGler unbedingt benötigen, welche eventuell und welche unkritischeren nicht unbedingt, aber potenziell auch mit ins Paket könnten. Welche Rechte auch immer am Ende mit im Paket sein sollten, die sollten dann aber auch allesamt überall uneingeschränkt verwendbar sein, also so wie normale Admins auch, die ja beispielsweise auch nicht mal eben so vollgeschützte Seiten normal weiter editieren sollen. Es sollten dann die normalen Regeln für die explizit vergebenen Rechte gelten. Das hätte den absolut großen Vorteil, dass niemand mehr sich irgendwie freiwillig oder sonstwie auf die Verwendung innerhalb des SG-Bereichs beschränken müsste und es auch keine Missverständnisse geben kann, wann es verwendet werden darf und wann nicht. Es kann höchstens noch Beschwerden geben, wenn sich wie normale Admins nicht an irgendeine andere allgemeingültige Regelung gehalten wird. Das wäre ein absoluter Fortschritt, den das MB leisten könnte, und das ist auch das, was für sämtliche anderen Benutzergruppen gilt, die auch nicht irgendwelche Rechte nur eingeschränkt benutzen dürfen. Wenn schon eigene Benutzergruppe, denn sonst hat die ganze Sache ja gar keinen Sinn.
Beispiele:
  • gelöschte Versionen einsehen können → so weit rechtlich usw. möglich, darüber Auskunft erteilen können, was dort steht, wie jeder normale Admin auch
  • geschützte Seiten editieren können → nach den normalen Seitenschutzregeln alle möglichen geschützten Seiten editieren dürfen
  • Seiten schützen können (war ja bisher im SG-Bereich möglich) → auch Adminanfragen und VMs(!) zu Seitenschutzen bearbeiten dürfen → Damit fiele ganz klar das aktive Recht, Seiten schützen zu können, automatisch aus dem Paket heraus, da es nicht so gedacht sein kann, dass SGler VMs zu Artikeln abarbeiten können sollen, und es auch keinen Sinn macht, weil ja beim einen Mal Benutzer gesperrt und ein anderes Mal die Seite geschützt wird, also müsste man eine andere Lösung dafür finden, entweder SG-Seiten ungeschützt belassen oder es schützen sie nur die regulären Admins im SG, ginge ja auch.
  • als privat markierten Einträge im Missbrauchsfilter einsehen → wird normalerweise nicht an andere Personen weitergegeben, also auch hier nicht
Dasselbe gälte für jedes weitere potenzielle Recht wie zum Beispiel „Seiten ohne Weiterleitung verschieben“ können oder ähnliche. Für das Rechtepaket sollte man einen neuen Abschnitt hier machen und die einzelnen potenziell möglichen Rechte dabei durchgehen, so was wie „Benutzer sperren können“ oder „Seiten löschen können“ kann man dabei gleich auslassen. Hauptsächlich geht es ja auch mehr um die passiven Rechte dabei. --Geitost 00:16, 23. Sep. 2012 (CEST)Beantworten

Verständnisfrage: "SG-Adminrechte werden zur Arbeit im SG gewährt"

Bearbeiten

Das Verständnis der SG-Adminrechte scheint sehr unterschiedlich zu sein. Ich dachte immer, die SG-Adminrechte werden für die Arbeit im Schiedsgericht gewährt und sind somit nur im Rahmen der eigenen SG-Tätigkeit zu benutzen. Andere scheinen aber zu denken, das die (passiven) SG-Adminrechte immer eingesetzt werden dürfen. Das ist meiner Meinung nach aber falsch, daher darf ein SG-Admin beispielsweise keine Auskunft über gelöschte Versionen auf WP:AA geben und auch nicht für seine Mentorenarbeit nutzen (oder ähnliches).

Ein Serveradmin der Wikimedia Foundation kann technisch auch E-Mail-Adressen nachschauen, darf dies aber Aufgrund von Arbeitsauflagen/Arbeitsbestimmungen nicht tuen. Gleiches gilt auch für die SG-Admins oder sollte zumindestens gelten.

Habe ich da das falsche Verständnis? Mit dem Meinungsbild sollte man dann auch wohl klären, ob die Rechte der neuen Benutzergruppe für die Wikipedia-Arbeit eingesetzt werden oder nur für die Arbeit im Schiedsgericht. Einfacher wird es wohl sein, wenn man die Rechte dann komplett für alle Arbeiten frei gibt, das wird dann nachträgliche Diskussionen vermeiden. SG-Benutzergruppe-MB-Ersteller (Diskussion) 18:37, 19. Sep. 2012 (CEST)Beantworten

Ich wollte hier nicht mehr reagieren, aber da dein neues Kapitel auf meine Bearbeitung zurückgeht, dann doch. Ja, dein Verständnis ist recht verkehrt. Das MB 2007 besagt, die Adminrechte werden erteilt, um die Aufgabe als SG bewältigen zu können. Dazu gehört auch der Umgang und Verwaltung der SG-Seiten. Und der Gedanke, die SGler dürfen nur gelöschte Versionen lesen (!!!), die mit einem laufenden Fall zu tun haben, andere aber nicht, ist schon obstrus. Überlege mal, warum. Basta. Von jemanden, der ein MB seit etwa anderthalb Jahren vorbereitet, hätte ich etwas profundere Einarbeitung in die Materie erwartet. Mit gruß -jkb- 18:54, 19. Sep. 2012 (CEST)Beantworten
Ich verstehe die Frage von SG-undsoweiter so, dass der Sinn bezweifelt wird, bei einer neuen Definition der SG-Benutzergruppenrechte wiederum Regelungsbedarf zu schaffen, was nun mit diesen Rechten jeweils geht und was nicht. Das hielte ich persönlich auch für unsinnig, denn dann könnte man ja alles lassen wie's ist und jedesmal wieder neu verhandeln, was der SGler nun mit seinen Adminrechten soll und darf und was nicht. Genau diese Unbeständigkeit - so verstehe ich die Intention dieses MBs - will der Vorschlag vermeiden: er avisiert eine neue SG-Benutzergruppe, die dann - alles andere wäre mMn unlogisch - mit ihren Rechten in der ganzen WP agiert. Oder sehe ich das falsch? --Felistoria (Diskussion) 19:06, 19. Sep. 2012 (CEST)Beantworten
Unter Wikipedia:Meinungsbilder/Schiedsgericht April 2007#Wer kann kandidieren? lese ich "erhalten alle gewählten Mitglieder zur Ausführung ihrer Aufgaben Adminrechte", was für mich deutlich danach klingt, dass Sie die Adminrechte zur Ausführung ihrer Aufgaben im Schiedsgericht erhalten. Unter Wikipedia Diskussion:Meinungsbilder/Schiedsgericht April 2007#Adminfragen klingt es ähnlich. SG-Benutzergruppe-MB-Ersteller (Diskussion) 19:57, 19. Sep. 2012 (CEST)Beantworten
Einfach falsch gelesen. Die SChiedsrichter nehmen ihre Aufgabe nicht irgendwo abgeschlossen im SG-Wiki wahr, sondern in der Wikipedia. Sonst hätten sie hier nichts zu suchen. -jkb- 20:05, 19. Sep. 2012 (CEST)Beantworten
reinquetsch: das sehe ich wie -jkb-; und ich hab' dann wohl auch die Intention dieses MB falsch verstanden. Sorry for disturbing. --Felistoria (Diskussion) 20:14, 19. Sep. 2012 (CEST)Beantworten
Da scheine ich aber nicht alleine falsch gelesen zu haben. Natürlich machen die Schiedsrichter ihre Arbeit in der Wikipedia, weil sie auch hier anfällt, aber wenn sie gerade mal nicht als Schiedsrichter arbeiten, dann sollen Sie die Adminrechte ruhen lassen. Und dazu gehört auch die Verschiebung ohne Unterdrückung. Was verschoben ist, ist verschoben. Ich wollte nur vorbeugen, dass die SG-Admins in Zukunft diesen Unterschied wissen und beachten können. Das andere sofort Missbrauch rufen, konnte ich nicht abschätzen und war auch nicht das Ziel meines Abschnitts gewesen. SG-Benutzergruppe-MB-Ersteller (Diskussion) 20:18, 19. Sep. 2012 (CEST)Beantworten

Leider eskaliert das Problem aktuell unnötigerweise. Es geht letztendlich um 10-15 Rechte, von denen Otto-Normaluser teilweise nichtmal weiß, daß sie existieren. Darum ist die Frage, über was 2007 tatsächlich abgestimmt wurde. Es lässt sich in der täglichen Arbeit sicher nicht vermeiden, die Rechte zu nutzen, weil sie bei den Ansichten sicher nichtmal extra gekennzeichnet sind. Ich würde gern an die Seriosität der gewählten SG-Mitglieder glauben, leider hat sich aber einer davon gestern dahin verrannt, den ungeplanten Gebrauch als "Recht" zu begreifen, dessen Entzug/Untersagung zum Rücktritt führen würde. Die Lösung kann nicht in einem MB gelöst werden, denn es gibt keine Kontrollinstanz. Man sollte eher darüber nachdenken, ob wirklich alle Rechte ausschließlich für Admins eingeräumt werden sollten. Denn wenn 400 Leute solche verdeckten Versionen sehen können, ist die Ausnahme längst zur Regel geworden, und man kann sie den anderen 300 "Seniors" unter den Benutzern auch einräumen. Und aus diesem Kreis kommen ja für gewöhnlich die erfolgreichen Kandidaten des SGs.Oliver S.Y. (Diskussion) 19:37, 19. Sep. 2012 (CEST)Beantworten

Die Diskussion um eine Benutzergruppe zwischen Sichter und Admin oder um die Aufweitung der Gruppe Administratoren gab es schon an vielen Stellen mit unterschiedlichen Ausgängen. Das sollte aber nicht Thema dieses Meinungsbildes werden. SG-Benutzergruppe-MB-Ersteller (Diskussion) 19:57, 19. Sep. 2012 (CEST)Beantworten
@ Oliver: Es geht nicht um 10–15 Rechte, sondern um 4 passive und 26 aktive, also insgesamt 30 Adminrechte, die allesamt nicht von Normalbenutzern (bis einschließlich Sichtern und IP-Sperre-Ausnahme-Benutzern) verwendet werden können (denn die sind bereits alle oben gesondert gelistet), sondern nur von Admins und die allesamt normalerweise für die SG-Arbeit nicht benötigt werden bis auf vielleicht editprotected/protect oder auch apihighlimits bzw. die Einsicht der auf privat eingestellten Missbrauchsfilterlogs (abusefilter-log-private, s. auch hier). Darunter befinden sich auch richtig sensible Rechte wie zum Beispiel nuke, mit dem eine Massenlöschung von Seiten möglich wäre. Na, so etwas würde zumindest direkt auffallen, die Vergabe von Rechten (IP-Sperren-Ausgenommene, Sichter und Passive Sichter) an andere Leute ganz offensichtlich eher weniger, sonst wäre so was ja zeitnah aufgefallen statt erst jetzt. --Geitost 22:55, 19. Sep. 2012 (CEST)Beantworten
Meiner Meinung nach könnte eine Differenzierung der Benutzerrechtegruppe durchaus dazu führen, die Funktion des SG präziser zu formulieren; denn die ist wohl insgesamt unklar, so etwa wie irgendwo zwischen eingeschlafenem VA und - pardon: - Herbergsvater. Ganz anders hier z. B. die en-WP, die ihr ArbCom als Endstation eines genau vorgegebenen Weges benennt (während in der de-WP anscheinend überall hin- und her-, wie auch vor- und zurückgelaufen werden kann ohne jede Einschränkung und immer wieder aufs Neue). Das MB hat diesbezüglich keinen klaren Kontext formuliert, sondern lediglich - bislang - einen rein formalen. Das prägt auch mMn die Diskussion: es geht eher um Beschränkungen (z. B. "richtig sensibler" Rechte, worin ich Misstrauen mitschwingen sehe), denn um ausdrückliche Kompetenzen (im Sinne von Zuständigleiten). --Felistoria (Diskussion) 23:17, 19. Sep. 2012 (CEST)Beantworten
Na ja, selbst Massenlöschungen von Seiten können ja rückgängig gemacht werden, auch wenn das halt dann aufwändiger sein dürfte. Aber wenn das mal jemand einfach so machen täte, hätte Derjenige aber direkt ein richtiges Problem am Hals, also wird das wohl eher nicht geschehen. Die Probleme sind dann schon eher im unauffälligeren Bereich zu suchen, wo solche Sachen eben nicht ins Auge fallen. Darunter fallen auf jeden Fall irgendwelche Seiten-, aber auch Versionslöschungen, und zwar mehr als Benutzersperrungen, die transparent einsehbar sind und der betreffende Benutzer auch sofort merkt, denn gelöschte Seiten(versionen) können Normalbenutzer eben nicht mehr einsehen. Da weiß man einfach nicht, was da nun tatsächlich gelöscht worden ist. Und Seitenlöschungen sind mMn auch nicht durch die MBs legitimiert.
Wenn hier nun ausdrückliche Kompetenzen und Präzisierungen festgelegt werden, wäre das sehr wünschenswert. Wenn man darüber hinaus auch noch andere transparente Rechte vergeben möchte, die nicht hauptsächlich für die SG-Arbeit nötig sind, wäre das doch auch nix Schlimmes und würde einer anderen möglichen Benutzergruppe zwischen Sichter und Admin nicht im Weg stehen. Aber es wäre doch ganz schön, wenn es auch um die Aufwertung der SG-Rechte ginge. --Geitost 00:03, 20. Sep. 2012 (CEST)Beantworten
@Felistoria: Es gibt durchaus eine Art „Instanzenzug“, in der Konflikte in Wikipedia durchlaufen werden sollen (das Wort „Rechtszug“ habe ich dort entfernt…). Insoweit ist auch die Rolle des SG durch die bisherigen Meinungsbilder klar umschrieben: Letzte Instanz. Auch die Zuständigkeiten sind ziemlich klar festgelegt.
Was die Rechte angeht, die für die Arbeit im SG erforderlich sind, so wäre zu bedenken, daß alle Mitglieder des SG gleiche Arbeitsmöglichkeiten haben sollten. Gewählte Admins dürfen keinen Informationsvorsprung vor anderen SG-Mitgliedern haben, denn jedes SG-Mitglied ist für seine Entscheidungen selbst verantwortlich, muß selbst entscheiden und deshalb auch selbst bei Anfragen in Wikipedia ermitteln können. Sonst ist eine eigenverantwortliche Arbeit als Schiedsrichter nicht möglich.
Weniger Schreibrechte fände ich persönlich ganz grundsätzlich eine enorme Entlastung, weil ich akribisch darauf achte, keine aktiven Sonderrechte einzusetzen, was mitunter im Interface schwer zu erkennen ist. Falls das MB aber dazu führen würde, daß wir als SG-Mitglieder weniger lesen könnten als gewählte Admins, würde ich mich Codc's Ankündigung anschließen und ebenfalls als Admin kandidieren, um weiterhin voll im SG mitarbeiten zu können. Im Ergebnis würde das dazu führen, daß eine vollwertige Mitarbeit im SG Adminrechte beim Kandidaten schon voraussetzt; dadurch verringert sich die Zahl der Kandidaten, die für das SG in Frage kommen, natürlich erheblich. Ich glaube, diese Folgen hier bisher noch nicht ausreichend durchdacht worden.--Aschmidt (Diskussion) 17:47, 20. Sep. 2012 (CEST)Beantworten
Aschmidt, natürlich muss mit der Benutzergruppe gewährleistet sein, dass weiterhin alle nötigen Informationen erhalten und selbst gelesen/eingesehen werden können. Es kann nicht Sinn der Sache sein, dass SGler regulär als Admin kandidieren müssten. Dann müsste man die Rechte der Benutzergruppe anpassen. Aber an welcher Stelle siehst du das denn überhaupt? Es ist doch so, dass alle Rechte, mit denen irgendetwas gelesen/eingesehen werden kann, bereits im Paket enthalten sind oder fehlt irgendwas? Dann sag doch einfach was. Macht doch keinen Sinn, eine AK anzukündigen stattdessen. Besser das MB mitsamt den nötigen bzw. sinnvollen Rechten verbessern, damit dann auch nix fehlt. --Geitost 18:25, 20. Sep. 2012 (CEST)Beantworten

Logbuchrechte (erl.)

Bearbeiten

Wenn ich das richtig sehe, sieht man ohne deletelogentry keine versteckten Logbucheinträge und hat auch keine Möglichkeit zur Ermittlung des Grundes. Unter dem Deckmäntelchen der vorauseilenden Gefahrenabwehr durch Verhinderung des Rechtemissbrauchs wird hier der Schiedsrichter in seinen Möglichkeiten der Nachvollziehbarkeit behindert. Bravo.

Die Festlegung der Rechte durch ein Meinungsbild sorgt dafür, dass bei neuen Entwicklungen mit neuen Rechten die standardmäßig damit ausgestattete Admingruppe diese auch nutzt, während Schiedsrichter das Nachsehen haben und eventuell erst ein neues Meinungsbild an den Start bringen müssten – das durchaus abgelehnt werden kann. --32XAutorenngilde № 1 15:41, 20. Sep. 2012 (CEST)Beantworten

Sag mal, 32X, hast du eigentlich immer so wenig AGF intus? Nimm doch mal ein bissel mehr davon zu dir. ;-)
Also: Mit deletelogentry kann man „Einzelne Logbuch-Einträge löschen und wiederherstellen“, das ist also ein aktives Benutzerrecht und kein passives, das ist somit für SGler überhaupt nicht geeignet. Mit deletedhistory, also dem Recht, das sie ja weiterhin behalten sollen, können sie dann auch weiterhin „Gelöschte Versionen in der Versionsgeschichte ansehen, ohne zugehörigen Text“. Und der hier fehlende zugehörige Text ist dann mit deletedtext weiterhin sichtbar, denn damit kann man ja „Gelöschte Texte und Versionsunterschiede zwischen gelöschten Versionen ansehen“. Wo also ist nun das Problem? Dein 2. Link sagt ja auch klar aus, dass zum Sehen der Version das Recht deletedhistory fehlt. --Geitost 16:56, 20. Sep. 2012 (CEST) PS: Warum rennen die Autoren bei dir eigentlich immer? Ach nee, sind ja die rennenden Autos, nicht die rennenden Autoren.Beantworten
Zum 2. Part könnte man auch mal nachsehen, wie das die Niederländer und Finnen mit den Benutzergruppen schon lange handhaben. Im Normalfall ist es aber auch nicht so, dass Sichter diese zusätzlichen oder neu aufgeteilten Adminrechte bekommen und auch andere Benutzergruppen nicht, warum also sollten SGler standardmäßig die neuen Adminrechte mit dazu bekommen? Wenn es dafür sinnvoll benutzbar ist, glaube ich kaum, dass man extra ein MB braucht, um ihnen solche sinnvollen und nötigen neuen Rechte auch geben zu können. --Geitost 17:03, 20. Sep. 2012 (CEST)Beantworten
Keine Angst 32X, das Benutzerrechte "deletedhistory" erlaubt auch das ansehen von gelöschten Logbucheinträgen (sofern diese nicht durch einen Oversighter versteckt wurden), daher kann jedes Mitglied weiterhin seiner Arbeit nachkommen und sich versteckten Teile der Logbucheinträge anschauen, wobei dies wohl nicht so häufig vorzukommen scheint.SG-Benutzergruppe-MB-Ersteller (Diskussion) 11:18, 22. Sep. 2012 (CEST)Beantworten

Klarstellung (Übertrag)

Bearbeiten

- - - - - die folgende Diskussion wurde hierher aus Wikipedia Diskussion:Adminkandidaturen/Hosse#Klarstellung übertragen, weil sie die Vorbereitung dieses MB mehr betrifft als die AK Hosse. -jkb- 17:39, 20. Sep. 2012 (CEST)Beantworten

... ... ...

Könntet Ihr mir die Stelle zeigen an der steht, dass SG-Mitglieder die Rechte nicht benutzen dürfen? Beim nicht sollen bin ich ja bei Euch, vor allem wen es um die ureigensten Adminaktionen geht - aber Weiterleitungen unterdrücken? Ich bitte Euch... --Hosse Talk 19:33, 19. Sep. 2012 (CEST)Beantworten
Also hier steht jedenfalls (wurde von SG-Mitglied Aschmidt am 22. Juli so dort eingefügt):
  • „Die Mitglieder des SG erhielten Adminrechte, um ihre Aufgaben erfüllen zu können, sie dürften hiervon aber darüber hinaus keinen Gebrauch machen.“
--Geitost 19:51, 19. Sep. 2012 (CEST)Beantworten
Und hier steht:
  • „Adminstatus ist für die Wahl zum Schiedsgericht nicht notwendig, allerdings erhalten alle gewählten Mitglieder zur Ausführung ihrer Aufgaben Adminrechte.“
Was besagt, dass die Rechte allein zur Ausführung der Aufgaben vergeben wurden, damit diese überhaupt möglich wurden, nicht jedoch für irgendwelche anderen Dinge. Das müsste erst anderweitig legitimiert werden, zum Beispiel durch ein neues explizites MB, das dies regeln würde. --Geitost 19:58, 19. Sep. 2012 (CEST)Beantworten
Derselbe Satz ist auch im Folge-MB zu finden unter Wikipedia:Meinungsbilder/Schiedsgericht Oktober 2007#Wer kann kandidieren?. --Geitost 20:01, 19. Sep. 2012 (CEST)Beantworten
Deine erste Stelle hab ich ehrlich gesagt noch gar nicht gelesen. :-) Ist auch noch ziemlich neu. Die zweite Fundstelle verstehe ich anders. Aber das scheint ja offensichtlich zu sein. Ich bin ehrlich gesagt immer eher für WP:Gesunder Menschenverstand als für WP:Wie kann ich mich an alle bürokratischen Regeln halten. Aber da ich ja sowieso nicht der große Verschieber bin, denke ich dass es auch egal ist, ob ich die Weiterleitungen nicht mehr unterdrücke. Oh mann...das muss echt wichtig sein... Ich möchte hinzufügen, dass ich bis dato noch nicht marodierend mit den Adminknöpfen durch die WP gezogen bin. --Hosse Talk 20:33, 19. Sep. 2012 (CEST)Beantworten
Siehe dazu auch WP:IAR, insbesondere WP:IAR#Auslegbarkeit. Interessant wäre eher die Frage, wie damit umgegangen sollte, wenn ein hypothetischer Benutzer, der zur Ausübung seiner Funktion (z.b. SG) Adminrechte bekommen hat, diese tatsächlich missbräuchlich einsetzen würde und etwa eine LD oder VM entscheidet. Das Unterdrücken offensichtlich unerwünschter Weiterleitungen oder das Löschen eigener BNR-Unterseiten ist damit aber nicht zu vergleichen - Hosse hätte alternativ jeweils einen SLA stellen können, der zwingend umzusetzen gewesen wäre. Einen Ermessensspielraum für den abarbeitenden Admin hätte es nicht gegeben! Deshalb halte ich es für eine reine Arbeitsbeschaffungsmaßnahme, die SG-Mitglieder in solchen Fällen zu verpflichten, Weiterleitungen anzulegen, die dann von Admins gelöscht werden sollen. --Theghaz Disk / Bew 20:46, 19. Sep. 2012 (CEST)Beantworten
(BK) @ Hosse: Die erste Stelle hab ich auch eben gefunden, nachdem du danach fragtest (und deshalb dann auch gleich mal nachgesehen, von wann die Passage nun eigentlich ist). ;-) Es ist zudem auch so, da eben die Meisten es auch genauso verstanden haben und weil es wohl so gemeint bzw. gedacht war, aber ein wenig missverständlich formuliert wurde, dass es deshalb zusätzlich auch immer noch diese Selbstverpflichtungen der SGler nach den jeweiligen Neuwahlen gab bzw. gibt (in den Protokollen zu finden), dass die Rechte nur so verwendet werden, deshalb hat es wahrscheinlich auch Aschmidt so reingeschrieben, aber frag ihn halt auch selbst.
Das Letzte glaub ich dir ja sofort und ich vermute ja auch keine bösen Absichten oder so. Also, dann fang ich noch mal ganz von vorne mit dem Nachdenken an und streiche den ganzen Kladderadatsch von bis dato einfach wieder raus. Vielleicht bringt ja das nächste MB zum Thema endlich mal ein ordentliches Ergebnis dazu. Würde mich freuen, wenn du dich dran beteiligen und Vorschläge machen tätest, welche Rechte als SGler sinnvoll zu gebrauchen sind. Dann noch mal denHexer fragen, was dabei evtl. kritisch werden könnte und dann mal sehen. :-) --Geitost 20:53, 19. Sep. 2012 (CEST)Beantworten

@ Theghaz: Das Problem, wo Probleme damit geklärt werden können, hat man auch nach einem entsprechenden erfolgreichen MB zur neuen Benutzergruppe weiterhin. Bei Fehlnutzungen von Sichtungsknöppen ist VM zuständig, bei Admins AP. Also irgendwo dazwischen. Zurzeit würde ich schon meinen, AP wäre dann richtig, da es ja die Adminrechte betrifft, auch wenn sie nicht explizit als aktive vergeben wurden. Jedenfalls wäre es für alle das Beste, wenn man die Sache endlich mal ordentlich klären müsste, denn eine Ausnahmesituation ist das ja nun wirklich schon lange nicht mehr. Am Anfang (2007) hat sich das Problem auch noch gar nicht so ergeben, weil damals tatsächlich noch alle SGler auch normale Admins waren. [nachträgliche Korrektur: nicht alle, grad mal nachgeschaut; auch im Mai 2007 gab es offensichtlich doch schon eine SG-Admina. --Geitost 00:46, 20. Sep. 2012 (CEST)] Deshalb hatte man sich wohl nicht so viele Gedanken um eine unmissverständliche Formulierung gemacht.Beantworten

Das mit dem SLA ist natürlich richtig, weshalb das mit dem fehlenden Ermessensspielraum schon stimmt. Aber was, wenn man einen Artikel mal aus dem ANR in den BNR verschiebt, wo verschiedene Leute dran gearbeitet hatten und der dann dort schnellgelöscht wird? Ist das dann immer noch eindeutig? Und was mit Löschungen in einem fremden BNR, was ja auch schon mal vorgekommen ist oder mit der Vergabe von IP-Sperre-Ausnahme? Nein, das beides nicht von Hosse, aber beides von 2 (Ex-)SGlern, die das ganz offensichtlich ebenfalls nur als Lappalie betrachten; es soll also nur verdeutlichen, dass die Grenzen wohl dann so schwammig werden, wenn man erst mal damit anfängt, die Aktionen als nebensächlich zu betrachten, dass das Verwenden der Funktionen sich allmählich auf weitere Dinge auszuweiten scheint. Ich finde, man muss es endlich mal ordentlich klären. --Geitost 21:04, 19. Sep. 2012 (CEST)Beantworten


Hab dazu aber auch noch mal ins Protokollarchiv geschaut, wie das dort so gehandhabt wurde in den letzten Jahren:

Nach Mai 2011 hab ich nix mehr gefunden zum Thema. Da stellt sich mir nun allerdings unwillkürlich die Frage: Hosse und -jkb-, was für eine Art der „freiwillige[n] Selbstbeschränkung bzgl. der Adminrechte“ hattet ihr denn da überhaupt protokolliert? Wurde ja offensichtlich dann schon direkt danach nicht mehr von allen auch eingehalten. Und warum ist das eigentlich nach Mai 2011 nicht mehr fortgeführt worden? Kapier ich jetzt aber auch gar nicht. --Geitost 21:37, 19. Sep. 2012 (CEST)Beantworten

Geitost, dieser Formalismus bringt mich noch um. Irgendwann keine Ahnung wann - wohl 2007 nach der Errichtung des SG - hat im SG jemand - keine Ahnung wer - eingeführt, dass die SG-Mitglieder im Sinne des MB freiwillig bestätigen, dass sie ihre Adminrechte außer zur Verwaltung von SG-Seiten wie im MB steht nur passiv benutzen werden. Dies ist, da im Mai 2011 eine Wahl stattfand, die du mitorganisiert hast, dann durch die neuen Mitglieder, u.a. durch mich und Hosse - keine Ahnung wer da sonst noch dazu gehörte - geschehen, und wg. der Transparrenz erschien dies auch im Protokoll. Mein Gott, wie lange wird man hier sonst noch herumstechen? Hat Hosse, ich oder sonstwer aus dem SG jemanden für zweimal unbeschränkt gesperrt und dann auch noch die Hauptseite gelöscht? Nein. Worum geht es denn? Gruß -jkb- 21:59, 19. Sep. 2012 (CEST)Beantworten
Hoffentlich nicht (erster Satz). ;-) Ob ich da was bei der Wahl mitorganisiert hab (was ich grad auswendig gar nicht mehr genau weiß), ;-) hat ja nu nix mit dieser Frage zu tun, denn darum ging es doch dabei gar nicht. Und was von den SGlern dann nun genau per Protokoll beschlossen wurde, kann ich ja nicht ahnen, nur sehen, was da steht. Und die Verwendung von SG-Rechten für andere Dinge als die SG-Tätigkeiten fängt ja nun nicht erst beim unbeschränkten Sperren von Benutzern oder dem Löschen der Hauptseite an. Das sind übrigens Dinge, die auch direkt auffallen und rückgängig gemacht werden können, somit wäre das mMn eher unproblematischer als Anderes, was eben nicht sofort ins Auge fällt.
Es geht nur darum, dass man einfach nur das einhält, was man irgendwann mal – tw. sogar selbst noch mal explizit – so beschlossen hat, nicht mehr und nicht weniger. Und wenn man nun zu der Erkenntnis kommen sollte, dass man es lieber anders hätte, dann kann man ja auch was Neues anders beschließen, dazu scheint mir doch das MB zum Thema erstellt worden zu sein. Ich halte das Anliegen jedenfalls für sinnvoll. Schreib doch auch du mal auf, welche der 30 Adminrechte, die alle nicht von Sichtern oder IP-Sperre-Ausnahme-Benutzern verwendet werden können, du für eine solche Benutzergruppe für unproblematisch verwendbar hältst. Fände ich gut. :-) --Geitost 23:13, 19. Sep. 2012 (CEST)Beantworten

(BK) Frage mich (rhetorisch, bitte nicht antworten) sowieso, wieso Verschieben mit Weiterleitungsunterdrückung nur Admins dürfen. Zumindest fortgeschrittenen Benutzern (sagen wir der Einfachheit halber, Sichtern) sollte das erlaubt sein, erst recht *aus dem eigenen BNR in den ANR*. Wenn's schief geht, kann ja immer noch revertiert werden. So ein Kinderkram. Hosses Aktionen haben der WP (im Kleinen, aber immerhin) genutzt, und nützliche Aktionen als negativ anzusehen, ist megaabsurd. Wenn Letzteres aus den Formalien folgt, sind die Formalien falsch. --AMGA (d) 23:17, 19. Sep. 2012 (CEST)Beantworten

PS: das wäre dann eines der allerersten der 30 Adminrechte, nach denen du fragst. --AMGA (d) 23:18, 19. Sep. 2012 (CEST)Beantworten
Bei diesem speziellen Recht (Seiten ohne WL verschieben), das gar nicht soooo unproblematisch ist, wie es aussieht, da man damit einiges an Chaos verursachen kann (gerade auch im ANR und so), ist es wirklich nicht sinnvoll, das an jeden Sichter zu vergeben (frag mal denHexer, der hatte das auch mal abgelehnt). Sichterrechte sind so schnell zu bekommen und der Unsinn, der potenziell mit dem Recht angefangen werden kann, ist nicht so klein, wie es auf den ersten Blick aussieht. Ich bin aber auch der Meinung, dass man das Recht gerne einer neuen, deutlich begrenzten SG-Benutzergruppe zuordnen könnte (dann auch normal zur Verwendung in allen Namensräumen), denn wo diese das Recht potenziell nicht sinnvoll verwenden würden, tun dies auch jetzt schon viele normale Admins auch nicht, insofern wäre das auch kein Weltuntergang. Man kann eine solche fehlende WL ja normalerweise schnell nachträglich anlegen. ;-) Und den größeren Unsinn mit der Funktion wird man den gewählten SGlern wohl eher nicht zutrauen (Dreiecksverschiebung zum Vertausch von Artikeln oder so), das würde aber auch alles öffentlich geloggt und wäre weiter für alle einsehbar (im Gegensatz zu Seitenlöschungen, die nicht mehr nachvollziehbar sind). --Geitost 23:45, 19. Sep. 2012 (CEST)Beantworten
/@ Geitost/ keine Angst, so schnell springe ich nicht die Brücke runter :-)... Ernst: Mir Gedanken zu machen will ich nicht unbedingt, weil ich das Anliegen etwas daneben finde (also nicht AK Hosse sondern das neue MB). Da wählt man 10 Leute, man vertraut ihnen als der letzten Instanz (!!) die schwerwiegenden Entschediungen wie infinite Sperren und ähnliches, und man hat Probleme sie gelöschte Versionen lesen zu lassen. Sie sollen wie bislang die Adminrechte bekommen, incl. der Verpflichtung, diese und jene nicht in Anspruch zu nehmen, und damit hat es sich. Wenn da jemand ein Mist baut (Benutzersperre etc.), so hat er sofort ein Problem. Eine Verschiebung ohne Redirect verzapft? Na gut, lass uns etwas anderes lösen. -jkb- 23:34, 19. Sep. 2012 (CEST)Beantworten
Nö, wo hat jemand Probleme, die gelöschten Versionen lesen zu lassen? Das ist doch genau das, wozu die Adminrechte den SGlern gegeben wurden. Genau dafür war das Ganze ja überhaupt da.
Tja, du magst das Anliegen daneben finden, andere Sprachversionen (nl:, fl:) haben aber seit Jahren eine solche Benutzergruppe, wo ist das Problem damit? Das gäbe mehr Klarheit für alle und weniger Probleme damit, was man nun damit machen darf und was nicht? Das MB hat mMn allerdings tatsächlich nur dann einen Sinn, wenn die dadurch vergebenen Rechte dann auch wirklich überall uneingeschränkt ganz normal (wie alle Admins auch) verwendet werden dürfen. Denn andernfalls hätte man nichts dabei gewonnen. --Geitost 23:45, 19. Sep. 2012 (CEST)Beantworten
Ein Problem mit Lesen gelöshter Versionen scheint der Kollege SG usw. zu haben (s. hier), und wie da gesagt, es gab eine Beschwerde über mich, da ich so etwas gelesen habe. Aber Geitost, außer nl und fi gibt es auch noch en, und da läuft der Hase in ganz entgegengesetzter Richtung - die SG-Jungs dort entscheiden bspw. über die Vergabe von CU- und OS-Rechten (was das deutsche SG entschieden ablehnte, übrigens). Also lassen iwr die fi's und nl's machen, hier ist offenbar kein Bedarf. Und, BTW, wir diskutieren auf der falschen Seite. -jkb- 23:54, 19. Sep. 2012 (CEST)Beantworten
Das Problem hat er wohl eher damit, was dann mit dem Gelesenen gemacht wird – hab ich zumindest so verstanden. Was jemand liest, kann ja ansonsten eh keiner wissen. Aber das wäre ja auch eine mögliche Aufwertung der jeweiligen vergebenen Rechte, dass man damit dann dasselbe machen könnte wie jeder Admin auch (also alles innerhalb der sonstigen normalen Regeln). Auskunft zu Nicht-SG-Themen erteilen und so. Was ja tatsächlich bislang nicht so vorgesehen war. Somit könnten dann auch derartige Adminanfragen bearbeitet werden und die Rechte wären nicht mehr ausschließlich zur Verwendung für das SG da. Auch eine Mitarbeit im OTRS-Team (mit der jeweiligen Einsicht in die Themen inkl. Auskunft erteilen zu können) wäre zusätzlich leichter möglich, wenn man das denn möchte. Aber wir diskutieren tatsächlich auf der verkehrten Seite, hast Recht. Also dann besser beim MB weiter, dann hat das Rumgeswitche zwischen den Seiten auch mal ein Ende. ;-) --Geitost 00:28, 20. Sep. 2012 (CEST)Beantworten
- - - - ende Übertrag -jkb- 17:39, 20. Sep. 2012 (CEST)Beantworten
Sehr schön. :-) --Geitost 18:54, 20. Sep. 2012 (CEST)Beantworten
Geitost hat Recht, es geht eher darum, was mit dem gelesenden passiert, weil du das ganze ja nur gelesen hast, um die Anfrage zu beantworten und es dich sonst (vermutlich) nicht interessiert hätte, was in der angefragten Version/Seite steht. SG-Benutzergruppe-MB-Ersteller (Diskussion) 11:22, 22. Sep. 2012 (CEST)Beantworten

Rechtepaket für SG-Benutzergruppe

Bearbeiten

Nachfolgend werden alle Adminrechte gelistet, die nicht bereits in Benutzergruppen vom normalen Leser bis hin zum aktiven Sichter enthalten sind, die also Sichter nicht haben (bis auf evtl. ipblock-exempt im Falle von Benutzergruppe IP-Sperre-Ausnahme), bei Admins aber im Paket mit drin sind. Die Rechte werden sortiert nach 1. denjenigen, die im MB bereits für SG-Mitglieder zukünftig vorgesehen sind, 2. denjenigen, die evtl. zusätzlich fürs SG verwendbar sein könnten (passiv oder aktiv), 3. denjenigen, die möglicherweise mit ins neue Rechtepaket kommen könnten und 4. denjenigen, die nicht für das Rechtepaket in Frage kommen. Es kann dann einfach umsortiert werden, falls die Diskussion beispielsweise ergibt, dass ein Recht doch nicht für das Paket in Frage kommt. Die Rechte sollten uneingeschränkt verwendbar sein, sonst sind sie ungeeignet. --Geitost 01:56, 23. Sep. 2012 (CEST)Beantworten

bisherige im Paket enthaltene Adminrechte, die normale Sichter nicht haben

Bearbeiten
(1) bislang im MB für SGler zukünftig vorgesehene Rechte
  • deletedhistory: Gelöschte Versionen in der Versionsgeschichte ansehen, ohne zugehörigen Text
  • deletedtext: Gelöschte Texte und Versionsunterschiede zwischen gelöschten Versionen ansehen
  • browsearchive: Nach gelöschten Seiten suchen
Sie geben alle Einblick in gelöschte Versionen. Auch einzelne durch Administratoren versteckte Versionen können damit eingesehen werden, nicht aber solche durch Oversighter.
  • abusefilter-log-private: Als privat markierten Einträge im Bearbeitungsfilter einsehen
Dieses Recht ermöglicht die Einsicht der aus privaten Missbrauchsfiltern resultierenden Logbucheinträge. Seit MediaWiki 1.19 werden auch die Logbucheinträge zu privaten Filtern als privat markiert. Schiedsrichtern sollte es ermöglicht werden, diese Logbucheinträge einzusehen.
  • editprotected: Seiten bearbeiten, die als „Nur Administratoren“ geschützt sind
(2) weitere möglicherweise fürs Schiedsgericht verwendbare passive Rechte
  • ipblock-exempt: Umgehung von IP-Sperren, automatischen Sperren und Bereichssperren
  • proxyunbannable: ⧼right-proxyunbannable⧽
  • apihighlimits: Höhere Limits in API-Abfragen
  • noratelimit: Keine Beschränkung durch Limits

Es gäbe sicher für die 4 weiteren passiven Rechte theoretisch denkbare Fälle (wie bei den Admins auch), wo sie wegen der SG-Arbeit nötig werden könnten.

(3) weitere möglicherweise fürs Schiedsgericht verwendbare aktive Rechte (mit theoretisch denkbarem Verwendungsbedarf im SG-Bereich)
  • suppressredirect: Beim Verschieben die Erstellung einer Weiterleitung unterdrücken (falls neu angelegte SG-Seiten ohne Weiterleitung auf einen aussagekräftigeren, präziseren Namen verschoben werden sollen – und dabei nur wenige Links auf den alten Namen umgebogen werden müssen)
  • tboverride: Die Negativliste unerwünschter Seiten- oder Benutzernamen außer Kraft setzen (falls eine SG-Seite einen solchen Namen erhalten soll oder Ähnliches)
  • move-subpages: Seiten inklusive Unterseiten verschieben (Verschieben eines SG-Antrags mitsamt Unterseiten auf einen neuen Namen)
(4) nicht fürs Schiedsgericht benötigte, eher unkritischere Rechte
  • movefile: Dateien verschieben
  • override-antispoof: Die Benutzernamens-Ähnlichkeitsprüfung außer Kraft setzen
  • reupload-shared: Lokales Überschreiben einer in einem gemeinsam genutzten Repositorium vorhandenen Datei
  • import: Seiten aus anderen Wikis importieren (versehentliche Fehlimporte könnten aber nicht gelöscht werden, dafür bräuchte es dann einen Admin)
  • unblockself: Sich entsperren (soll sowieso nur in Ausnahmefällen verwendet werden und wäre auch bei Admins Missbrauch, wenn sie regulär gesperrt wurden)
  • unwatchedpages: Liste der unbeobachteten Seiten ansehen (eigentlich ein überflüssiges, unsinniges und ungenutztes Benutzerrecht, könnte aber nach einem Bugfix wieder etwas sinnvoller verwendbar werden)
  • Benutzer zu diesen Gruppen hinzufügen: IP-Sperren-Ausgenommene
(5) nicht sinnvolle, ganz wegfallende aktive Adminrechte für SGler (löschen, sperren, schützen, Konfigurationen ändern, usw.)

Erläuterung hierzu: Die hier folgenden Rechte sind nicht sinnvoll uneingeschränkt verwendbar. Es kann möglicherweise das eine oder andere Recht teilweise sinnvoll für die SG-Arbeit nutzbar sein und wurde möglicherweise auch bereits dafür in der Vergangenheit verwendet, aber es uneingeschränkt normal wie Admins zu verwenden, wäre nicht sinnvoll, da es dann grundlegende Adminaufgaben einschließen würde, die sicher bei SGlern umstritten wären. --Geitost 15:52, 23. Sep. 2012 (CEST)Beantworten

  • blockemail: Sperren oder Entsperren eines Benutzers für das Senden von E-Mails
  • block: Sperren oder Entsperren von Benutzern für die Bearbeitung
  • deletelogentry: Einzelne Logbuch-Einträge löschen und wiederherstellen
  • deleterevision: Einzelne Versionen einer Seite löschen und wiederherstellen
  • patrol: Fremde Bearbeitungen als kontrolliert markieren (das Markieren von Bearbeitungen als kontrolliert spielt sowieso keine Rolle und wird auch von Admins schon nicht aktiv genutzt, ist somit auch völlig überflüssig und unsinnig)
  • autopatrol: Eigene Bearbeitungen automatisch als kontrolliert markieren (eigentlich ein überflüssiges, unsinniges und ungenutztes Benutzerrecht)
  • globalblock-whitelist: Globale Sperren lokal aufheben
  • stablesettings: Konfigurieren, wie die stabile Version ausgewählt und angezeigt werden soll
  • nuke: Massenlöschungen von Seiten
  • right-abusefilter-modify: Bearbeitungsfilter bearbeiten (oben diskutiert, aber SGler sollen ja keine neuen Missbrauchsfilter einrichten können, wäre also nicht uneingeschränkt verwendbar)
  • markbotedits: Schnell zurückgesetzte Bearbeitungen als Bot-Bearbeitung markieren
  • delete: Seiten löschen
  • undelete: Seiten wiederherstellen
  • protect: Schutzeinstellungen ändern und kaskadengeschützte Seiten bearbeiten
  • editusercss: Fremde CSS-Dateien bearbeiten
  • edituserjs: Fremde JavaScript-Dateien bearbeiten
  • editinterface: Mediawiki-Namensraum bearbeiten
  • Benutzer zu diesen Gruppen hinzufügen: Sichter und Passive Sichter
  • Benutzer aus diesen Gruppen entfernen: Sichter und Passive Sichter

Diskussion zum Rechtepaket

Bearbeiten

So, nun kann diskutiert werden, welche der Rechte ganz normal uneingeschränkt verwendbar sein können sollen und welche nicht. Und bei Bedarf umsortiert werden. --Geitost 01:56, 23. Sep. 2012 (CEST)Beantworten

protect wird derzeit von den SG-A in einer sinnvollen Weise zur Verwaltung und Moderation von SG-Anfragen genutzt (Stichwort Akalipsia). Du solltest es fairerweise unter einem anderen Punkt als dem Punkt "nicht sinnvoll" aufführen. Am ehesten die Community selbst befragen und es als Abstimmpunkt einführen – es ist mir nicht sofort ersichtlich, warum der m.E. voreingenommene Benutzer:SG-Benutzergruppe-MB-Ersteller diese Entscheidung unter Radar treffen möchte. Ich sehe da auch ein gewisses Desinteresse an der konkreten Arbeit des SG, es wird eine technisch-ästhetische Lösung favorisiert. Technisch-ästhetisch deswegen, weil tatsächlicher Missbrauch hauptsächlich von passiven Rechten denkbar ist: ein SG-A kann wie andere Admins theoretisch über einen längeren Zeitraum Dritten Zugang zu beispielsweise wegen WP:ANON gelöschten Version verschaffen. Das wäre schlimm, aber das Risiko wird durch dieses Meinungsbild nicht berührt. Rechte, die Spuren in Log-Büchern hinterlassen, lassen sich dagegen eher schlecht missbrauchen.

Wenn jetzt das Meinungsbild von der Community adoptiert wird, dann wuerde ich mich freuen, wenn es sich etwas aus der Umklammerung von SG-Benutzergruppe-MB-Ersteller lösen würde. --Erzbischof 10:49, 23. Sep. 2012 (CEST)Beantworten

<quetsch>Ich würde mich ja als Initiator wohl (mit) eintragen, weiß nur nicht, ob das nicht als Übernahme angesehen würde, da der Initiator ja die Rechte eher auf ein Minimum beschränken wollte. Also, mal sehen. Somit hab ich es vorgezogen, hier einfach erst mal einen allgemeinen Diskussionsabschnitt dazu zu erstellen. Dann kann man ja sehen, wie dies diskutiert wird.
Wegen protect und möglicherweise noch anderen, ähnlichen bisher vom SG verwendeten Rechten hab ich noch eine Erläuterung dazu eingefügt. Würde man das Recht uneingeschränkt freigeben, könnten SGler auch normale VMs zu Artikelseitenschutzen bearbeiten, das wäre wohl sicher nicht so gewollt. Und mir ging es hier nun ausschließlich um ganz normal uneingeschränkt verwendbare Rechte, sonst hat das Ganze mMn wenig Sinn, wenn man sich dann nach dem MB doch wieder bei einem Recht auf einen Verwendungsbereich beschränken müsste. Das gibt nur wieder ähnliche Schwierigkeiten, find ich keine gute Idee. Insbesondere geht es bei VMs zu Benutzern oder Artikeln immer auch um Benutzersperren und Seitenschutze, somit sind mMn die Funktionen block und protect einzeln nicht uneingeschränkt zu vergeben. Dann müsste man block auch mit ins Paket mit aufnehmen, das kann aber sicher nicht so gewünscht sein, deshalb braucht man darüber auch gar nicht erst gesondert abstimmen zu lassen. Das hat also gar nix mit dem Initiator zu tun, mal davon lösen und freies Brainstorming machen. :-)
Das Einsichtsrecht in gelöschte Versionen hingegen ist ein Basisrecht des Schiedsgerichts, ohne das hätte es wohl nie die Adminrechte überhaupt bekommen. Es ist die Grundlage für die SG-Arbeit und muss mit enthalten sein, egal wie viel Missbrauch damit möglich wäre. Dafür gibt es ja die SG-Wahl, um auszuschließen, dass Leute gewählt werden, denen man nicht zutraut, mit dem Recht sensibel genug umzugehen. --Geitost 16:01, 23. Sep. 2012 (CEST)Beantworten
auch quetsch: den Zustand allerdings, dass man die rechte fein und sauber nach dem Kriterium, was benutzt werden darf und nicht, zuteilt, wird man ohnehin nicht erreichen. So müsste man die Rechte block und protect beispielsweise bei SG-Mitgliedern, die auch gewählte Admins sind, in solchen Fällen in Frage stellen, wenn sie infolge von SG-Entscheidungen verwendet werden sollten. Dass ist nämlich ausdrücklich nicht vorgesehen, auch wenn die gewählten Admins dieses Recht haben. Die Umsetzung von SG-Entscheidungen soll ja von Nicht-SG-Admins durchgeführt werden (was ja auch eine gewisse Rückkopplungskontrolle darsrtellt). -jkb- 16:13, 23. Sep. 2012 (CEST)Beantworten
Stimmt, aber das ist ja wieder ein anderer Fall, der ja nicht die Nur-SGler/Nicht-Admins betrifft, sondern die SGler-auch-Admins. ;-) Es gibt insofern immer Einschränkungen für Leute, die Admins sind und zusätzlich eine so genannte höhere Funktion innehaben. Das ist aber auch bei CUlern (insbesondere dort!, denn sie sollen ja auch ihre CU-Entscheidungen nicht selbst umsetzen) oder OSlern so, das muss hier nicht geklärt werden. Im Zweifel wäre dafür entweder AP oder die näxte Funktionswahl der richtige Ort, um so was im Einzelfall zu klären.
Der entscheidende Unterschied dabei ist auch Einschluss gegenüber Ausschluss: Beim SG sollen die Rechte nur dort verwendet werden und woanders überhaupt nicht, bei CU und SG-Normaladmins die Rechte normalerweise überall, nur gerade nicht bei der Ausführung der eigenen Entscheidungen im jeweiligen Gremium – und möglichst auch nicht bei normalen Entscheidungen (insb. VM/SP), die voraussichtlich zu einer späteren Befangenheit für einen Fall im Gremium führen könnten. --Geitost 16:24, 23. Sep. 2012 (CEST)Beantworten
@Geitost Dankeschön; sehr hilfreich.
Erstaunlich, dass dies offenbar bislang nie präzisiert worden war und es keine nachlesbare Unterlage dazu zu geben scheint. Ich habe zur einfacheren Referenzierbarkeit die Gruppen mal durchnummeriert.
  • (2) weitere passive
    Ich kenne zwar keinen Anwendungsfall, aber auch nicht die Arbeitsabläufe bei SG-Fällen. Wenn man sie haben mag, problemlos.
  • (3) weitere aktive
    Die Verwaltungsaktionen von SG-Seiten mögen ohnehin in die Fälle involvierte als solche gewählte SG-Admins erledigen; ansonsten wird jede AA durch SG sicher promptest bearbeitet. Jedem normalen Autor einer 100000-fach eingebundenen Vorlage geht es auch nicht anders; muss sich für erforderliche Anpassung auch um Entsperrung bemühen.
    Dies eröffnet den undurchsichtigen Graubereich, wenn Aktionen technisch ausgeführt werden können, aber nicht sollen. Sollen sie eigentlich nicht? Bekommt das jemand mit, wenn ich für meine eigenen Artikel mal so schnell eben?
    Nein. Nicht zuordnen.
  • (4) eher unkritischere aktive
    Das führt genau zu dem falschen Rollenverständnis von nur mit einfacher Mehrheit gewählten, aber trotzdem mit mehr Macht ausgestatteten Super-Administratoren. SG-Mitglieder sollen im Kollektiv Streitfälle entscheiden. Sie müssen glaubwürdig sein und dazu vorbildlich handeln, insbesondere selbst die Spielregeln einhalten. Außerhalb des SG sind sie ganz normale Benutzer. Mehr nicht. Die Verlockung, technisch mögliche aber so eigentlich ja nicht ganz so erlaubte, naja, das merkt ja sowieso keiner, ach was soll’s, ich mach das jetzt einfach, und für einen guten Kumpel dann auch gelegentlich, dann habe ich bei dem was gut … solche hintenrum-Aktionen scheinen grade einem selbsternannten Behelfs-Admin das Genick zu brechen. Genau so fängt Korruption an. Es ist auch völlig unerheblich, ob irgend jemand ein Schaden zugefügt wird. Schon die Nicht-Zuständigkeitserklärung unter Admin-Probleme (die Aktionen wurde nicht von einem richtigen Admin vorgenommen, also ist es kein Admin-Problem: „Hier falsch, Hosse ist kein Admin“) zeigt das angerichtete Durcheinander. Das SG mit 7/10 Betroffener ist selbst befangen und kann als höchste Instanz damit auch nicht mehr entscheiden. Das nennt man Interessenkollision. Die SG-Mitglieder agieren ohne eine Beschwerde- und Kontrollinstanz als Pseudo-Admins.
    Das SG hat seine Konfliktbeendigungsaufgaben wahrzunehmen. Die Wahl in das SG ist nicht gedacht als Billiglösung, um mit einfacher Mehrheit an die Admin-Knöpfe zu kommen. Ganz klar: Nicht zuordnen.
  • (5) nicht sinnvolle
    @protect @Erzbischof: Wäre ggf. unter (3) einzusortieren. Solange es die eigenen SG-Seiten sind, mögen die A/SG dies im Regelfall verwalten; ansonsten kurzer Hinweis auf AA. So furchtbar viele Seiten sind wohl nicht dauernd zu schützen und danach trotzdem weiter zu bearbeiten.
  • Ansonsten hätte ich auch gern mal eben so ein paar erweiterte Rechte, um mir das Leben einfacher zu machen. Kein SG-Mitglied hat zur Wahrnehmung seiner Aufgaben das JavaScript eines anderen Benutzers zu bearbeiten. Schon Admins sollten ohne triftigen Grund und akute Notwendigkeit kein fremdes JS bearbeiten, allenfalls in direkter Rückkopplung mit dem verantwortlichen Benutzer. Ich könnte das sicher besser als die meisten SG-Mitglieder; warum bekomme ich edituserjs eigentlich nicht?
  • Im Übrigen sehe ich mich von niemand umklammert und hätte als Projektmanager ähnliche Systeme von Benutzerrechten und Gruppen eingeführt, wie ich das schon vor 15 Jahren mit BSCW konfiguriert hatte und regelmäßig bei der Ausgestaltung von Netzwerken mache.
VG --PerfektesChaos 12:21, 23. Sep. 2012 (CEST)Beantworten
unwatchedpages und die zugehörige Spezialseite sind in der deutschsprachigen WP etwa so sinnvoll wie ein Eis das nach Scheiße schmeckt. Im 3-Tagesrhythmus werden alphabetisch die ersten 2000 Seiten (und nur die) ausgegeben, die kein Benutzer auf der Beobachtungsliste hat. Schon ein einziger Beobachter, der zuletzt vor fünf Jahren angemeldet war, sorgt dafür, dass die Seite nicht mehr in der Spezialseite erscheint. Bei 1,5 Millionen angemeldeten Benutzern gibt es hinreichend viele Karteileichen mit noch beobachteten Seiten. Es bleiben bei 1,5 Millionen Artikeln jedoch auch so viele unbeobachtet, dass die von einer kleinen Gruppe ohne Fachkenntnisse gar nicht überwacht werden könnten. Seit bald fünf jahren weise ich auf diesen Umstand hin, aber somehow übt diese Spezialseite noch immer eine magische Anziehungskraft aus. Nicht einmal der Umstand, dass man beim Sichten daürber informiert wird, dass die seit 10 Tagen nicht gesichtete Seite von 15 Leuten beobachtet wird, tat dieser Magie einen Abbruch. Würde diese Spezialseite von heute auf morgen verschwinden, es würde absolut *nichts* fehlen … --32XAutorenngilde № 1 15:35, 23. Sep. 2012 (CEST)Beantworten
Hihi, ja so ähnlich wird es wohl sein. ;-) Wenn das Recht also nicht sinnvoll verwendbar ist, kann das auch gerne unter 4.) landen, da es ja auch nix schadet. Ist ja egal dann, hehe. ;-) Den Rest damit kann man dann ja irgendwo sonst klären, aber frag mich nicht wo. --Geitost 16:17, 23. Sep. 2012 (CEST)Beantworten
Hab’s mal nach unten verschoben. :-) --Geitost 16:19, 23. Sep. 2012 (CEST)Beantworten

@ PerfektesChaos: So, dazu Folgendes: Der Vorschlag zu den oben aufgelisteten Benutzerrechten war nicht, wieder einen neuen Graubereich zu schaffen, wo die vergebenen Rechte wieder nur eingeschränkt verwendet werden können sollen, sondern gerade eben der, dass die dann vergebenen Rechte allesamt uneingeschränkt verwendet werden können, also bei protect dann auch Artikel oder auch eigene bzw. fremde Benutzerseiten geschützt werden können müssten, sonst wäre das Recht im Paket einfach falsch. Ich finde es nicht sinnvoll, eine neue Benutzergruppe dafür zu erstellen, wenn man auch dort wieder die Rechte nur eingeschränkt vergeben will. Dann kann man auch genauso gut alles so belassen, wie es ist. Insofern ist protect einfach falsch in einem solchen denkbaren Paket. Die anderen Rechte könnten auch nicht im Graubereich verwendet werden, da sie ja allesamt normal verwendet werden können sollen. Wenn das bei diesem oder jenem Recht eher nicht gewünscht sein sollte, dann käme es eben nicht mit ins Paket und fertig.

Die Rechte, die ich nach unten gesetzt habe unter (5), fielen einfach aus dem jetzigen Paket ganz heraus, weil sie absolut nicht uneingeschränkt zu verwenden wären. Dazu kämen diejenigen aus den obigen Bereichen, bei denen das ähnlich gesehen würde, zum Beispiel das bereits von einem SGler verwendete Recht zur Vergabe von IP-Sperre-Ausnahme, das nicht zu einem Aufschrei geführt hatte und weswegen ich es mal nach oben gesetzt habe, um überhaupt darüber zu diskutieren. Denn im Normalfall ist IP-Sperre-Ausnahme keine kritische Benutzergruppe, wie ich meine. Wenn das andere anders sehen, könnte man die Benutzergruppe nicht so einfach vergeben lassen und müsste das Recht dazu aus dem Paket rausnehmen.

Aus deiner Antwort lese ich jedenfalls heraus, dass man dann keins der weiteren Rechte mit ins Paket packen dürfte, das nicht auch irgendwie mit der SG-Arbeit zu tun haben und dort verwendet werden könnte. Damit fielen sämtliche Rechte aus (4) sofort heraus, selbst wenn sie völlig problemlos sind wie unwatchedpages oder autopatrol. Ich verstehe allerdings allgemein nicht das Problem dabei, nur weil es keine spezifischen im SG verwendbaren Benutzerrechte sind. Über die einzelnen Rechte wie edituserjs oder editusercss kann man dann ja noch gesondert reden und sie bei Bedarf in Abschnitt (5) verschieben, wenn sie einzeln nicht als sinnvoll angesehen werden. Aber nur weil ein Recht nicht zwingend im SG verwendet werden kann und nur weil es nicht auch jeder Sichter bekommen soll, ist das doch alleine noch kein Ausschlussgrund, oder? Schließlich wird ja auch nicht jeder Sichter in irgendeiner Wahl gewählt, somit kann da nicht grundsätzlich genügend Vertrauen in alle Sichter da sein, dass sie allesamt keinen Unsinn mit diesen Rechten machen würden. Dafür kann man viel zu schnell Sichter werden. --Geitost 19:22, 23. Sep. 2012 (CEST)Beantworten

Zusammengefasst: Es ist eigentlich ganz einfach:

  • Alle Benutzerrechte, die man uneingeschränkt nur den mit 2/3-Mehrheit gewählten Admins, aber nicht in die Hände von mit nunmehr neuerdings einfacher Mehrheit gewählten Funktionsträgern geben möchte, kommen in die untere Gruppe (5).
  • Alles, was man uneingeschränkt entsprechend der für alle hier gültigen Regelungen auch Funktionsträgern zutraut, die mit einfacher Mehrheit in dieses Gremium gewählt wurden, könnte mit in diese denkbare Benutzergruppe.
  • Und wenn man nur Rechte dort sehen möchte, die auch überhaupt in irgendeiner Weise fürs SG potenziell verwendbar sind, dann müsste man noch alle Rechte aus Gruppe (4) ganz herauslassen, egal wie unkritisch oder unbrauchbar jene Rechte sein mögen.
  • Die aus Gruppe (1) kämen auf jeden Fall in ein solches Paket herein,
  • und die aus den Gruppen (2) und (3) nur, wenn man entweder nur weitere passive oder auch weitere aktive Rechte dort sehen möchte, die ab und zu mal im SG, auf jeden Fall dann aber auch woanders uneingeschränkt gebraucht werden könnten. --Geitost 19:33, 23. Sep. 2012 (CEST)Beantworten

Es geht also einerseits darum, welches Recht in welche der 5 Gruppen hereingehört und andererseits darum, welche der 5 Gruppen mit in ein solches Paket kommen sollen und welche nicht. Sind also 2 Diskussionsteile eigentlich. --Geitost 19:36, 23. Sep. 2012 (CEST)Beantworten


Dann nochmal zu Klarstellung. Mein Ansatz ist:
  1. Die Aufgliederung geht nach Erfordernis für die Aufgabe und nicht danach, was man welchen zukünftig gewählten Unbekannten zutraut.
  2. Rechte, die für die Tätigkeit im SG erforderlich sind, werden aufgenommen.
  3. Rechte, die nichts mit dem SG zu tun haben, gibt es auch nicht.
  4. Das SG ist kein Exekutivorgan, sondern liest sich durch zig Seiten durch, kommuniziert untereinander und verkündet eine Entscheidung.
  5. SG-Mitglieder sind normale Benutzer und keine Admins mit besonderen Machtbefugnissen.
  6. Zur Verwaltung der eigenen SG-Projektseiten gibt es ausreichende Mittel und Wege.
  7. Wenn man allgemein für vertrauenswürdige erfahrene Benutzer gegenüber Sichtern erweiterte Rechte einführen möchte, ist dies eine völlig andere Diskussion und hat nichts mit dem SG zu tun.
  • Zu 2.: Es wird sich in erster Linie um Leserechte handeln. Soweit unter (1), kein Thema. In (2) steht was von IP-Adress- und Proxyblockaden; das mag erforderlich sein, wenn ein Verfahrensbeteiligter samt IP-Range gesperrt ist und man zur Ermöglichung einer Kommunikation kurzfristig für 48 Stunden oder was immer die Blockade aufhebt. Die Befreiung von Limits mag Recherchen und Kategorienabgleich erleichtern; gerne.
  • Zu 3.: Das ist kein Wünsch-Dir-Was. Darf es noch ein bisserl mehr sein? Wir packen einfach mal noch ein paar Rechte dazu, die zwar nichts mit der Aufgabe zu tun haben, aber ihr werdet schon irgendwie sensibel damit umgehen, obwohl es keinerlei Legitimation oder Zweck gibt, und niemand sagen kann was das soll.
    Im Übrigen sind die unter (4) benannten Rechte mitnichten alle unkritisch. Wer mit editusercss spielen mag, kann sich mal ein *{display:none} in sein Benutzer-CSS schreiben und danach als IP auf AA um Revert bitten. (Was man mit CSS machen kann, sah man heute nachmittag, als das line-height ja auch gern übernommen wurde.)
  • Zu 6.: Um die eigenen Seiten des SG administrativ zu bewirtschaften, gibt es -zig Möglichkeiten: Die ohnehin involvierten SG+Admin, AA, Entsperrwünsche, Disku von befreundetem Admin etc. (Wenn Bergi die von ihm selbst maßgeblich gebaute Vorlage:Coordinate bearbeiten möchte, spricht er sich ggf. mit dem Umherirrenden ab und die beiden wuppen das gemeinsam.)
  • Zu 7.: Man kann gern für Benutzer mit 1000 oder 5000 oder 10000 Edits einen Status als „senior editor“ oder sonstwas einführen; aber das hat nichts mit dem SG zu tun. Irgendwelche zusätzlichen Rechte bekämen dann alle, die diese Kriterien erfüllen, und mögen dann einer entsprechenden Benutzergruppe zugeführt werden. Da kann dann autopatrol oder auch das sinnfreie unwatchedpages mit beigegeben werden.
Liebe Grüße --PerfektesChaos 20:48, 23. Sep. 2012 (CEST)Beantworten
Ich fang mal einfach irgendwo an. ;-) Zu 7.: Eine eigene zusätzliche Benutzergruppe zwischen Sichter und Admin ist hier nicht das Thema, so viel ist ja klar. Kann man irgendwo anders machen oder nicht, egal. Jene neue Benutzergruppe würde nicht von irgendwem gewählt, die Rechte würden entweder automatisch oder auf Anfrage hin vergeben. Deshalb kann man dort nicht irgendwelche Rechte vergeben, für die eine Wahl sinnvoll ist, um beurteilen zu können, ob nur vertrauenswürdige Benutzer solche Rechte bekämen. Hat also alles nix hiermit zu tun. Ein solches Rechtepaket müsste gänzlich anders aussehen. Ob man da die unnützen Rechte unwatchedpages, autopatrol oder patrol mit hineingäbe oder nicht, wäre völlig egal. Offensichtlich wäre es auch egal, wenn man sie jedem passiven Sichter gäbe und es wäre auch egal, wenn man sie aus dem normalen Adminpaket entfernen würde, weil sie alle 3 rein überhaupt gar nichts bewirken und nicht genutzt werden können. Man könnte sie einfach alle 3 ersatzlos abschaffen und es würde niemanden stören.
Zu 3. Wünsch dir was, Gruppe (4), andere weitere Rechte: Wenn editusercss nicht unkritisch ist, kommt es eben in das Paket (5) und gut ist. Dazu ist die Diskussion ja da, um das zu klären. Ich werd’s gleich umsortieren. Wenn dasselbe auch für edituserjs gilt, was ich nicht weiß, wird auch das umsortiert. Bei (4) sollen nur welche landen, die tatsächlich für erfahrene Benutzer, die ins SG gewählt werden, auf jeden Fall auch unkritisch genug sind und kein großer Blödsinn passieren kann. Gut, dasselbe ginge mit editinterface auch, also müsste das auch nach unten. Man stelle sich vor, jemand editiert die commons.js (oder war’s .css?) so wie in der ital. oder engl. oder russ. WP und dann ist die gesamte WP schwarz und nicht mehr zu bearbeiten. Also raus damit. Ich nehm mal edituserjs dann auch gleich mit raus, wird wohl ähnlich sein, oder? Dann sehen wir halt, was übrig bleibt. Ganz abgesehen davon, ob man es dann mit aufnehmen wollen würde oder halt auch nicht.
Legitimation gäbe es dafür aber auf jeden Fall, denn durch eine Annahme des MBs wären sie ja automatisch dazu legitimiert, die Rechte auch verwenden zu können. Und der Zweck wäre eine Vereinfachung der allgemeinen Tätigkeiten, unabhängig davon, ob noch eine andere neue Benutzergruppe eingeführt würde oder nicht.
Zu 6., also zu Gruppe (3), zusätzliche aktive fürs SG verwendbare Rechte): Natürlich gibt es dazu ausreichend Mittel und Wege. Aber die Frage ist ja nicht, ob es auch anders geht, sondern ob man es sie auch selbst machen lassen würde und zugleich auch die Rechte allgemein uneingeschränkt vergeben wollen würde. Momentan ist es ja so, dass ein Großteil der Benutzer überhaupt kein Problem darin sieht, dass die Rechte sogar dann verwendet werden, wenn es sogar per MB explizit so nicht vorgesehen war. Warum sollte man es dann nicht auch gleich per MB so festhalten, wie eine große Mehrheit es sowieso jetzt bereits sieht entgegen der bisherigen Regeln? Das ist doch auch nicht ganz schlüssig. Ein MB, das hauptsächlich dazu da wäre, Rechte zu nehmen, die bislang unkritisch eingesetzt wurden, würde sicher auch nicht angenommen werden, so groß wie der Widerstand gegen die Einhaltung der bisher per MB festgelegten Regeln bereits merkwürdigerweise ist. (Ich meine, erst legt man per MB explizit fest, dass die Rechte für die Aufgaben im SG da sein sollen und dann hält man sich nicht mehr dran, weil man es unsinnig findet und anschließend halten es die Meisten auch noch für bescheuert, überhaupt eine selbst per MB festgesetzte Regel überhaupt nur einhalten zu sollen bzw. überhaupt nur darüber diskutieren zu dürfen, ob man das einhalten muss oder nicht; das geht echt nicht mehr in meinen Kopf hinein.) Wenn also nun diese Einschränkung der Verwendung der Rechte auf das SG als so unsinnig angesehen wird, dass selbst eine Diskussion darüber schon direkt abgeblockt wird, dann kann es nur Sinn machen, eine Situation mit einem MB so zu ändern, dass es einem mehrheitlichen Willen auch entspricht. Sonst ist es klar, dass man damit Scheitern wird, wenn man ein MB entgegen der Mehrheit durchführen will. Sieht man doch am gerade erst archivierten Klarnamens-MB für Admins. MBs sind nicht dazu da, einen Minderheitswillen zur Abstimmung zu stellen. Es soll ein Mehrheitswille gefunden und festgelegt und dann umgesetzt werden. Den sehe ich nicht in einer restriktiven Festlegung der Rechte.
So, und nun werd ich oben etwas umsortieren gehen, damit die Zuordnungen besser passen, soll ja eine sinnvolle Zuordnung werden. --Geitost 23:11, 23. Sep. 2012 (CEST)Beantworten


  • Das MB in Ausarbeitung ist ja eine gute Gelegenheit, präzise umrissene Alternativen zur Abstimmung zu stellen. Eine könnte lauten, dass die SG-Mitglieder genau das und das so und so dürfen und dies und jenes ausdrücklich nicht, dafür jedoch keine technische Benutzergruppe eingeführt wird.
  • Die Protokolle aus 2008/2009, MB usw. lese ich so, dass die Rechtewahrnehmung nur darauf bezogen ist, die SG-Arbeit zu ermöglichen (also primär Lesezugriff). Dies scheint Intention und Tenor zu sein und dieses gemeinsame Verständnis ergibt sich auch aus den damaligen Beiträgen. Sonst hätten auch diese Selbstbeschränkungen keinen Sinn. jkb bestreitet das aber anscheinend jetzt?
  • Das Verständnis von einer SG-Mitgliedschaft kann sich aber im Lauf der Jahre wandeln und die Rolle mag neu definiert werden. Vorschläge:
    • SG-Mitglieder sind Halb-Administratoren und nehmen für die ganze Community (nur für die eigenen Artikel; auch für Mentees und gute Kumpel) administrative Aufgaben außerhalb des SG wahr. Beschwerdeinstanz hierfür ist WP:Adminprobleme. (So lese ich die oben gefallenene „Vereinfachung der allgemeinen Tätigkeiten“)
    • SG-Mitglieder sind übergeordnete Administratoren der höchsten Instanz. Sie unterliegen nicht der Kontrolle durch WP:Adminprobleme und nur einstimmigen Beschlüssen aller Mitglieder des SG. Sie werden mit einfacher Mehrheit gewählt.
  • Auffallend ist, dass es von Seiten des SG aktuell keinerlei konkrete Feststellungen gibt. (Mit einer folgenlosen Klarstellung in der Causa Hosse wäre die ganze Angelegenheit erledigt gewesen, sofern dann kein Wiederholungsfall.) Eigentlich müsste es eine Handreichung für neu gewählte SG-Mitglieder irgendwo öffentlich nachlesbar geben. Anscheinend weiß man im SG selbst nicht mehr so genau, was man eigentlich darf und soll, solange das halt keiner mitbekommt. Statt dessen müssen mir zwoa Außenstehende jetzt die SG-Arbeit in Formen gießen?
  • Technische Randnotizen: unwatchedpages hätte in erster Linie Missbrauchspotential; Trolle könnten daraus entnehmen, auf welchen Seiten abgesehen von RClern Dummfug unentdeckt bleiben würde. Vertrauenswürdige Benutzer könnten die generierte Spezialseite durchsehen und einige interessante Seiten auf die Beo nehmen; dazu war diese Möglichkeit ursprünglich geschaffen worden. Wenn bei derzeitiger Größe der deWP und Beschränkung auf 2000 Einträge das irgendwo im Buchstaben A verendet, ist es allerdings recht gaga. Was in der aktuellen Fassung von (4) übrigbleibt, ist ein ziemlich esoterisches Gebräu, hat wenig mit der täglichen Arbeit zu tun und definitiv nichts mit dem SG: override-antispoof, reupload-shared, unblockself; import ist ein Verwaltungsvorgang für Routinierte und movefile sollten die Bilder-Experten sachgerecht handhaben (auf Commons beschäftigt man sich praktisch nur mit Dateien, so wie eine WP mit Artikeln); dazu die bereits thematisierten. Was soll das?
LG --PerfektesChaos 10:41, 24. Sep. 2012 (CEST)Beantworten
Ob ich es bestreite... Hm. das ist meine Meinung nach die richtige Auslegung. Der Teilsatz "... erhalten alle gewählten Mitglieder zur Ausführung ihrer Aufgaben Adminrechte ..." lese ich nicht als Einschränkung, sondern als Grund für die Gewährung der Adminrecht, ohne als Admin gewählt zu werden. Eine Einschränkung hätte wirklich expliziter formuliert werden müssen. Und, wäre dies in der Tat eine Einschränkung, so gäbe es keinen Grund für den seit Jahren praktizierten freiwilligen Verzicht auf die aktiven Rechte außerhalb des SG-Bereichs (übrigens, kurz nach der Wahl im Mai 2011 hat Ca$e ein Script im SG-Wiki zur Verfügung gebastelt, mit dem man die meisten nicht gebrauchten Rechte eliminieren kann, um nicht per unbekannten Button Unheil anzurichten).
Wie dem auch sei: nachdem die Stoßrichtung, auch dank Geitost, in etwas andere Bahnen gelnkt wurde und keinen so inquisitorischen Eindruck macht, kann man all diese Probleme hier sicher und zufriedenstellend klären, sei es durch (s.o. PerfektesChaos) eine SG-Benutzergruppe oder die Aufzählung dessen, was erlaubt ist und was nicht. Jetzt sieht es besser aus. -jkb- 10:57, 24. Sep. 2012 (CEST)Beantworten
Der Grund für die freiwillige Selbstbeschränkung der „zur Ausführung ihrer Aufgaben“ erhaltenen Adminrechte war ja in den ersten beiden Selbstbeschränkungen die Einschränkung auf die passiven Rechte ohne beispielsweise Seitenschutze innerhalb des SG-Bereichs, also auf die reinen Leserechte. Das ist erst später verwässert worden, weshalb es dann gar keine Einschränkung mehr war; dies war aber im 2011er-Protokoll gar nicht für Außenstehende ersichtlich, da es dort nicht spezifiziert wurde. Im Übrigen wurden selbst diese so genannten Einschränkungen ja auch nicht eingehalten.
Aber vielleicht schauen wir besser hier in die Zukunft, wie es zukünftig sein soll? Der MB-Ersteller ist ja zurzeit hier gar nicht aktiv und somit ist unklar, was er nun von der Entwicklung hier hält. Aber wir können ja einfach weiter überlegen, dann wird man ja sehen. Vielleicht will er ja auch erst mal die Sache ihren Lauf gehen lassen. Da es in MBs eh um eine Ermittlung einer mehrheitlichen Meinung gehen soll, kann man ja versuchen, diese herauszufinden und ihr einen Guss zu geben.
Ich denke aber, man sollte nicht zu viele Optionen am Ende zur Auswahl stellen, denn dann wird das Ganze unübersichtlich, es versteht keiner mehr auf Anhieb und das MB würde dann deshalb formal abgelehnt. Alles schon da gewesen, öfters.
Ob es sinnvoll ist, eine Alternative abseits des bisherigen Status quos zur Auswahl zu stellen, wo keine Benutzergruppe eingeführt wird – tja, nur dann, wenn das, was die SGler dann dürfen sollen, Rechte enthält, die nur eingeschränkt benutzbar sein sollen, wie zum Beispiel protect. Wenn man das also einfach so ohne Benutzergruppe festlegen will.
Ansonsten scheinen mir das jetzt hier recht viele differierende Vorschläge zu sein, und ich weiß grad gar nicht recht, wie man da am besten weiterkommt oder wo man ansetzen soll. Mal schauen. Vielleicht muss man auch die Diskussion in einzelne mit einzelnen Abschnitten aufsplitten, um es übersichtlicher zu bekommen. --Geitost 02:56, 26. Sep. 2012 (CEST)Beantworten

(nach vorne rutsch) Da ich gerade nicht recht weiß, wie weiter und wo ansetzen, mal einfach was nur zu den Rechten der obigen Gruppe (4): Dass diese nichts mit dem SG an sich zu tun hat (bei unblockself bin ich nicht ganz sicher, s. u., evtl. umsortieren oder auch nicht), ist logisch, so ist sie ja eben definiert. Wenn ein Recht etwas mit dem SG zu tun hätte, wäre es in der Gruppe auch falsch. Also scheint es ja zumindest so zu stimmen. :-)

  • Wobei unblockself wohl noch am ehesten was mit dem SG zu tun haben könnte, falls mal jemand im SG aus welchen Gründen auch immer gesperrt worden wäre und eine Frist abläuft, beispielsweise die zum Ende einer Amtszeit, dass noch ein Fall abgeschlossen werden könnte und etwas dort geschrieben werden soll, aber nicht schnell genug ein Admin gefunden würde, um eine Entscheidung zu einem Fall noch posten zu können, sollte eine solche Sperre einen SGler nicht an so etwas hindern können. Aber das wäre wohl recht theoretisch und selten. Bei eindeutigen Fehlsperren/Verklickern, die ja öfters mal durch Admins vorkommen, könnte sich ein SGler wieder entsperren und wäre nicht darauf angewiesen, dass es sofort bemerkt und rückgängig gemacht würde. Ob man das will oder potenzieller Missbrauch bei einer normalen, regulären Sperre eher zu erwarten wäre und somit die Sache eher nach hinten losgehen könnte, müsste man halt wissen. Würde wohl gar nicht unbedingt benötigt (insbesondere können sie sich ja auch nicht selbst fehlerhaft sperren), insofern könnte man es wohl auch weglassen.
  • unwatchedpages und autopatrol sind unproblematisch, insbesondere das Erstere, beide aber nutzlos. Zurzeit ist es allerdings so, dass das Recht autopatrol stört, da es im Logbuch mitsamt allen Löschungen, Sperren, Seitenschutzen usw. aufgeführt wird, wenn man auf alle Logs klickt und den Hauptanteil der Logs ausmacht. Das spricht auch für eine eigene Benutzergruppe, denn solange man den Admins nicht dieses störende Recht auch ganz wegnimmt, werden diese Logs auch zukünftig weiterhin in der Übersicht nur stören, wenn man andere Logs sucht. Nützen tut das Recht aber überhaupt niemandem. Sollte man wohl besser weglassen, wenn es eher stört, vielleicht auch in Gruppe (5) packen wie patrol. Ich sortier es einfach mal um.
  • reupload-shared und movefile, die Dateirechte: Was das erste Recht bedeutet, wird mir nicht ganz klar, das zweite ist nur nützlich und würde Admins beim Verschieben von Dateien entlasten. Warum also nicht? Wer sagt, dass ein SGler sich nicht mit Dateien auskennen kann? Oder ist das etwas, wozu man zwingend eine 2/3-Mehrheit bräuchte, um sicherzustellen, dass man sich genügend im Bilderbereich auskennt? Falls ja, wäre es halt in Gruppe (5) einzusortieren. Ich sehe das nicht als kritisches Recht an.
  • Bei import ist es so, dass jeder Neuadmin auch irgendwann mal zum ersten Mal importiert und damit noch keine Routine hat. Muss es sein, dass man für derartige Verwaltungsaufgaben Adminrechte mit 2/3-Mehrheit hat?
  • override-antispoof: Wann könnte man ein solches Recht überhaupt sinnvoll gebrauchen? Wird es irgendwofür gebraucht? Keine Ahnung. Wenn’s gar nicht irgendwofür sinnvoll ist, packt man es eben in Gruppe (5) und gut ist.

Wie gesagt, wenn man grundsätzlich die Rechte in Gruppe (4) nicht für sinnvoll hier zu vergeben hält, nur weil sie nix mit dem SG zu tun hat, müsste man halt die ganze Gruppe rausnehmen. Das ist aber keine Frage der einzelnen Rechte in der Gruppe. Letztere Frage sollte sich nur darauf beziehen, ob es irgendwie kritische Rechte darin gibt. Die seh ich so nicht mehr. Man kann sich in die Verwendung reinarbeiten, das macht jeder Neuadmin ja auch so, der sich nicht vorher damit genau auskennen kann. Was man gucken kann, ist, wie entlastend es für die allgemeinen Admintätigkeiten ist, diese Rechte weiteren Leuten zu geben. Wie oft werden sie genutzt. Dateien werden wohl öfters verschoben und Importe finden ständig statt, da kann man immer weitere Leute gebrauchen, die das machen wollen. Dann können die regulären Admins sich um was anderes kümmern, wenn mal jemand anders einfachere dieser Aufgaben übernimmt. Aber hilft es tatsächlich oder wären das eher nur Nebensächlichkeiten? Vielleicht werden die Importe (die ja normal gut abgearbeitet werden) ja sowieso nebenher ausgeführt und stören nicht weiter. Bei einigen wären auch Löschungen/Versionslöschungen nötig, dann könnte das eh nur ein Admin machen. Vielleicht ist das Recht tatsächlich nicht so sinnvoll, ich weiß nicht. --Geitost 03:39, 26. Sep. 2012 (CEST)Beantworten

  • Ich mache die Rechte von den Aufgaben abhängig. SG-Mitglieder haben ein Votum in Streitfällen abzugeben, weiter nix. Geschworene werden auch nicht automatisch Hilfsgefängniswärter; Gewaltenteilung und so. Die Wahlen zum SG sind auch nie unter der Prämisse erfolgt, das seien damit vertrauenswürdige Leut’, die ab sofort auf ewig allerlei dürften, und würden das schon irgendwie richtig machen. movefile und import sind definitiv sachfremd für die SG-Tätigkeit. unblockself könnte zur Aufhebung eines eigenen Fehlklicks (selbst ausgesperrt) nur brauchen, wer sich selbst irrtümlich gesperrt hat, und müsste auch block haben. Vielleicht wollte sich ein Admin eine Wikipause gönnen. Würde ein SG-Mitglied oder Admin aus guten Gründen durch Andere gesperrt worden sein, wäre unblockself Missbrauch.
  • Dem senior editor, wie er seit einer Weile umhergeistert, stehe ich offen gegenüber. Hier mag man movefile und import und dergleichen reinpacken. Wer (als Richtwerte) x Jahre und y Edits und in letzter Zeit keine allzu fleckige Weste hat, möge den Status beantragen. Mit Ermessensspielraum, wenn x oder y knapp verfehlt werden und das Pendant deutlich übererfüllt wird. SG-Mitglieder können sich auf eigenen Wunsch melden und bekämen das wohl routinemäßig zugeordnet; würden es auch nach Ablauf der Amtszeit behalten. Automatisch hätten alle Admin nach ehrenhafter Beendigung der Tätigkeit diesen Status, auch rückwirkend. Neben einem gewissen Vertrauen (Aktionen lassen sich notfalls immer rückgängig machen, wenn es auffällt) gehören in erster Linie technisch-organisatorische Kenntnisse und Erfahrung zu diesen Rechten. – Wer damit Mist baut, ist spätestens im Wiederholungsfall wieder Junior.
  • Mir geht es um Transparenz und Klarheit; zur Vermeidung dieses schwammigen Wirrwarrs um Exekutivrechte, Befugnisse und Beschwerdeinstanz, das da offensichtlich eingerissen ist. SG-Mitglieder sollen Konflikte beenden, nicht Ursache für Streit sein. Die Version „nur (1) und (2)“ muss also eine der Abstimmungsoptionen sein.
  • Wenn du es für erfolgversprechend hältst, magst du gern weitere Abstimmungsoptionen zusammenstellen mit einer glasklaren und unmissverständlichen Definition, etwa „alle SG-Mitglieder sind gleichzeitig Halb-Administratoren mit diesen und jenen Zuständigkeiten und Verantwortlichkeiten“ oder „dürfen die Rechte gemäß (3) ausüben, jedoch ausschließlich auf Seiten mit dem Präfix WP/WD:Schiedsgericht“.
  • Wie sich zeigt, muss jede Option die Klausel enthalten „Diese zusätzlichen Rechte erlöschen mit dem Ende der Mitgliedschaft im SG und dem Abschluss des letzten noch aufgenommenen Falls.“
Sonnigen Tag --PerfektesChaos 09:55, 26. Sep. 2012 (CEST)Beantworten
Das Recht reupload-shared erlaubt es dir, eine Datei lokal unter einem Namen hochzuladen, der bereits auf Commons vorhanden ist. Damit kannst du also eine Commonsdatei überdecken (ShaddowCommons), was zum Beispiel sinnvoll ist, wenn eine Datei auf Commons zur Löschung steht, nach unseren Regeln jedoch unproblematisch ist. (Z.B. 1924 veröffentlichtes Werk eines gemeinfreien Künstlers, bei dem in den USA jedoch die seltsame Urheberrechtsverlängerung greift.) Ist eher ein Recht für Dateileute und hiesige Commonsadmins. --32XAutorenngilde № 1 12:08, 26. Sep. 2012 (CEST)Beantworten
Ja, mmh, also insgesamt scheint es wohl eher darauf hinauszulaufen, dass man dann doch nur die Rechtegruppen mit hineinnimmt, die zumindest irgendwas mit dem SG zu tun haben können, wenn man Rechte wie import, movefile oder reupload-shared hier eher nicht drinhaben möchte. Und für den Rest in einem potenziellen anderen MB eine neue Benutzergruppe andenkt. Ja gut. Noch ne Frage zur Gruppe (4): Ist es – als reines Leserecht – bei unwatchedpages nach Fixen dieses seltsamen Bugs (wär ja mal irgendwann denkbar) theoretisch möglich, dass das Recht doch mal sinnvoll genutzt werden kann und somit in die Gruppe (2) hineinkommen könnte oder lassen wir es trotzdem mit raus?
Das mit dem „diese speziellen Rechte dürfen nur auf folgenden Seiten benutzt werden“ (SG-Seiten), kann man mit zur Abstimmung stellen, wenn man will, für sinnvoll halte ich so was aber überhaupt nicht, denn damit hat man dann wieder keine genau umgrenzte Benutzergruppe, wo man die dort vorhandenen Rechte auch tatsächlich endlich mal alle normal benutzen kann. Dann könnte man sich die gesonderte Benutzergruppe auch schenken und einfach nur Rechte definieren oder so. Oder wie stellst du dir das sinnvoll vor, PerfektesChaos? Deine Schlussklausel nimmt man am besten mit auf.
Bleiben also die Gruppen (1) (= auf jeden Fall), (2) (= auch mit reinnehmen) und (3) (= noch unklar, evtl. gesondert abstimmen lassen, inwiefern). Muss man sich also speziell um die 3. Gruppe noch Gedanken machen. Und um sinnvolle Abstimmoptionen. Das dann wohl besser in einem gesonderten Abschnitt auf dieser Seite.
Interessant wäre für die 3. Gruppe die Frage, inwiefern die 3 Rechte in Gruppe (3) überhaupt bislang im SG-Bereich verwendet wurden, ob das also wirklich auch Rechte sind, die man häufiger mal dafür brauchen könnte, ob sie also dort auch nützlich verwendbar sind, sodass sich eine Abstimmung über diese 3 Rechte lohnt.
  • suppressredirect: könnte ich mir dort jedenfalls immer wieder gut verwendbar vorstellen.
  • move-subpages: So viele Seiten mit Unterseiten gibt es im SG-Bereich auch nicht, aber auch in anderen Namensräumen wird das nicht so oft benötigt. Wenn es doch eher einen Ausnahmefall darstellt, könnte man es evtl. auch verlustfrei rauslassen.
  • tboverride: Ob dieses Recht im SG-Bereich tatsächlich gut einsetzbar ist oder überhaupt mal verwendet wurde, wäre ebenfalls noch die Frage.
Vielleicht liefe es darauf hinaus, dass nur suppressredirect im SG-Bereich auch wirklich öfters gut genutzt werden kann und die anderen beiden eher exotischer sind? Das wissen wohl nur die SGler selbst. Damit kämen wir der Sache näher, wo die Entscheidungslinien eigentlich verlaufen. --Geitost 02:45, 27. Sep. 2012 (CEST)Beantworten
unwatchedpages – mehr schaffe ich heute morgen nicht.
  • Ausschließlich den sysop zuordnen (5), wobei weder die noch jemand anders in der deWP etwas damit anfangen könnten.
  • Wenn man ein privates Wiki mit einigen 100 Artikeln und drei aktiven Autoren hat, kann man damit sicherstellen, dass jede Seite bei wenigstens einem Autor auf der Beo steht. Insofern ist es kein Bug.
  • Die Performance-Bremse schaltet nach 2000 Treffern ab. Würde sie das nicht tun, liefert deWP vielleicht 70.000 Artikel, gar zusätzlich aus anderen NR unbeobachtete Benutzer-Unterseiten und Dateibeschreibungsseiten – welche arme Sau soll sich denn durch diese Liste durcharbeiten und das alles auf die Beo nehmen?
  • Wäre das eine interessante Zusatz-Aufgabe für das SG?
Bald mehr --PerfektesChaos 09:49, 27. Sep. 2012 (CEST)Beantworten
Vielleicht können die SGler selbst etwas dazu sagen, ob sie sich vorstellen könnten, sich darum etwas zu kümmern? Können ja dann schon mal bei A anfangen. ;-) Aber wie dem auch sei: Wenn sich überhaupt niemand darum kümmert, würde es hier in der de-WP auch nicht schaden, denn dafür gibt es ja die gesichteten Versionen, damit Änderungen von neuen Leuten auf jeden Fall noch mal angesehen werden. Insofern wäre es wohl auch ohne den „Bug“ recht egal. Lassen wir es also damit bewenden, hat ja keenen Zweck. --Geitost 14:09, 27. Sep. 2012 (CEST) PS: Wahrscheinlich sind auch eher andersherum die gesichteten Versionen einer der Gründe, dass die Spezialseite damit völlig überflüssig und unsinnig geworden ist und das Recht dazu auch. --Geitost 14:16, 27. Sep. 2012 (CEST)Beantworten
Zumal: Wenn der Erstautor sein Kind auf die Beo nahm, aber inzwischen seit fünf Jahren inaktiv ist, gilt für die Datenbank die Seite immer noch als beobachtet. Dieses Feature ist also wirklich nur etwas für Miniwikis. --PerfektesChaos 10:09, 28. Sep. 2012 (CEST)Beantworten

Ort für Diskussion zu Problemen mit den erweiterten Benutzerrechten

Bearbeiten

Zur einen Abschnitt höher von PerfektesChaos aufgeworfenen zusätzlichen Frage: Wo oder wie ein möglicher Missbrauch der Rechte diskutiert werden soll, müsste auch geklärt werden. Dazu mach ich mal direkt einen neuen Abschnitt, da es erst mal nix mit dem Paket an sich zu tun hat, denn der Ort ist ja auch bislang schon nicht klar ersichtlich; das würde sich also erst mal nicht ändern, wenn man es nicht festlegt.

Am besten klärt man explizit, ob AP dafür der richtige Ort sein soll oder ein anderer, evtl. neu zu definierender Ort und vor allem auch, wer dann darüber befinden soll: die normalen Admins oder jemand anders? Bei CU/OS sind es die Ombudsleute, bei den Bürokraten wüsste ich aber jetzt auch nicht, ob AP dafür richtig wäre, wenn es dort zu Beschwerden käme über falsch bzw. missbräuchlich vergebene Bot- oder Adminrechte oder dergleichen. Insofern gibt es wohl nicht einen klar definierten Ort oder auch zuständige Leute für solche Probleme. Oder der normal für Adminrechte zuständige Ort AP ist nur nicht klar genug dafür definiert, sodass er nicht als solcher angesehen wird, obwohl er es eigentlich bisher doch wäre, und fälschlich richtig platzierte Anfragen deshalb abgeschmettert werden können. --Geitost 19:50, 23. Sep. 2012 (CEST)Beantworten