Wikipedia Diskussion:Checkuser/Wahl/September 2012/Rax

Nachrücker

Hei Rax, du sollst auch mal was gefragt werden, damit diese Seite nicht am Wahlende noch rot ist. ;-) Was hältst du als einziger CU-Kandidat mit CU(B)-Erfahrung von meinem Vorschlag, ab der näxten Wahl im September 2013 Nachrücker bei CU-Wahlen einzuführen, die bis zu 9 Monate nach der letzten Wahl nachrücken könnten und für das Nachrücken bei der letzten Wahl mindestens 75 % Prostimmenanteil erhalten haben müssten. In den letzten 3 Monaten vor der näxten Wahl würde man dann stattdessen einfach auf die Wahl warten. Genaueres zum Vorschlag ist hier zu finden. Viele Grüße --Geitost 01:20, 26. Sep. 2012 (CEST)

Hej Geitost, schönen Dank auch fürs Einbläuen ;) Zur Nachfrage: Wir sind in den letzten Monaten zwar auch ohne Nachrücker für die beiden inaktiven CUs ganz leidlich klar gekommen, von mir aus könnten aber bei zukünftigen Wahlen (nicht bei dieser, das hätte zuvor bekannt sein müssen) auch gern alle Kandidaten, die mehr als die (durch die Policy-Vorgaben geforderten) 70% (sic!) Zustimmung erreicht haben, als potentielle Nachrücker gelten - in der Reihenfolge, die das Ergebnis der jeweils vorangegangenen Wahl vorgibt. Sie haben den für CU erforderlichen Rückhalt der Community. Gruß --Rax post 23:02, 26. Sep. 2012 (CEST)

Ja, das stimmt natürlich, dass sie den dafür erforderlichen Rückhalt haben. Der Vorteil wäre, dass man sicher auch Nachrücker hätte (das wäre bei 75 % in der Vergangenheit einfach noch gar nicht der Fall gewesen), 2009 wären es mit Seewolf und DaB. (in der Reihenfolge) gleich 2 Nachrücker gewesen und letztes Jahr hätte es mit Kriddl zumindest einen Nachrücker gegeben, den man hätte fragen können, ob er einspringt. Allerdings wäre das auch in diesem Inaktivitätsfall gar nicht gegangen, weil ja niemand zurückgetreten ist, dafür bräuchte es dann doch noch das Inaktivitäts-MB von Theghaz zusätzlich (evtl. etwas vereinfacht und abgewandelt), sonst könnte auch mit Nachrückern niemand nachrücken, so wie das bei den Bürokraten ja gerade auch gar nicht geht. Alles etwas kompliziert. Nachrücker wären ja auch bei den Bürokraten zurzeit nur möglich, wenn jemand auch explizit zurückträte, so wie bei Raymonds Rücktritt.

Das mit den 70 % hätte tatsächlich noch nen weiteren Vorteil: Es würde die Wahl vereinfachen, sonst würde es wohl mit der Auswertung noch komplizierter, wenn man eine 2. Hürde berücksichtigen müsste.

Allerdings weiß ich nicht, inwiefern nur knapp gewählte Nachrücker bei CU konsensfähig wären (als Nachrücker wohlgemerkt), denn da gibt bzw. gab es ja so einige Bedenken, allerdings auch Zustimmung zum Nachrücken. Mal gucken, was wir da so haben an Bedenken:

• [1]: Der Job sei „zu sensibel“, um „bei vorzeitigem Ausscheiden eines Checkusers ein[en] Wahlverlierer nachrück[en]“ zu lassen. Man sollte besser „nach erneuter Kandidatensuche etwas später eine Neuwahl für den fünften ansetzen“, da ging es auch um Rücktritte, Inaktivität geht ja eh für das Nachrücken nicht, solange die Knöpfe bleiben.
• In WD:Checkuser/Wahl/September 2012#Nachrücker (Überschrift nachträglich dort eingefügt) stellte Elop die Vermutung auf, dass Kriddl, der im letzten Jahr genau die 70 % (und auch nicht mehr als das) erreicht hatte, vermutlich genau so inaktiv gewesen sei wie Hei_ber. Spekulationen um Nachrücker mit weniger als 70 % der Stimmen sind ja eh ohne Grundlage, da man dann gar nicht erst als gewählt gälte. Und dass nicht genügend konsensfähige Kandidaten da wären, wird ja durch die Wahl selbst widerlegt, wenn man sich die Entwicklung bei den Zwischenständen so ansieht. Insofern hat die Argumentation sich auch etwas überholt in den letzten Wochen.
• In WD:Checkuser/Wahl/Archiv/2011#Nachrücken teilte Rosenkohl aber auch deine Meinung, dass bei 70 % und mind. 25 Prostimmen das Vertrauen ausreichend wäre, um nachrücken zu können. Ansonsten wurde dort vor der letzten Wahl weniger über Nachrücker, sondern mehr über Nachwahlen diskutiert. Während dieser und der letzten Wahl kam aber jeweils wieder das Bedürfnis nach Nachrückern auf.

Die Nachrücker wurden auch von KaiMartin auf der hiesigen allgemeinen Wahldisk. befürwortet. Alles in allem sehe ich etliche Leute pro Nachrückerfrage und auch einige dagegen, allerdings mit tw. gar nicht zutreffenden Begründungen (z. B. Befürchtungen bezüglich Kandidaten mit weniger als 50 % Prostimmenanteil).

Wie schätzt du denn die Begründungen bzw. Befürchtungen von Grip99 bezüglich der Sensibilität der Aufgabe (und lieber nachwählen zu lassen) bzw. Elop zu nur knapp Gewählten, die potenziell ebenfalls inaktiv würden, ein? Sämtliche bisherigen Kommentare fanden jedenfalls vor Beginn dieser Wahl statt. Ich glaube, ich habe damit auch die wesentlichen Einwände widergegeben, andere fallen mir auch nicht ein. Von mir aus kann man auch die 70%igen Kandidaten nachrücken lassen, wenn ein Platz frei wird und wenn das sonst Konsens sein bzw. werden sollte und es die ganze Chose vereinfacht. Ganz ohne Nachrücker auch zukünftig fände ich jedenfalls die schlechtere Variante.

Ein weiterer Vorteil beim Nachrücken wäre auch, dass Kandidaten vielleicht noch mehr Motivation hätten, überhaupt zu kandidieren, auch wenn schon genügend geeignete Leute antreten, wenn man doch später noch evtl. nachrücken kann. Das könnte auch die Auswahl bei den Wahlen noch mal weiter erhöhen oder die Abstimmenden anders abstimmen lassen als „es werden ja nur 3 gesucht, also gebe ich auch nur 3 Kandidaten ein Pro“. So weit mal einige weitere allgemeine Gedanken dazu. --Geitost 01:07, 27. Sep. 2012 (CEST)

Übrigens war ich selbst eine Zeitlang der Meinung, dass CU für Nachrücker eine zu sensible Aufgabe sei. Da geht es dann halt um Dateneinsicht und dergleichen. Nur bekommt man ja als CUB nur die Daten zu Gesicht, die man selbst abgerufen hat und nicht wie bei OS auch die ganzen bereits vorher oversighteten Daten, die dort alle eingesehen werden können. Deshalb gibt es da schon einen entscheidenden Unterschied zwischen diesen beiden Funktionen. Und deshalb wäre es mMn auch nicht schlimm, wenn jemand nach 8–9 Monaten nachrücken würde und eine verkürzte Amtszeit von nur 1 Jahr und ein paar Monaten hätte (du hattest ja nun auch erst mal kein volles Jahr). Meist wird dann ja auch noch klar wiedergewählt. Und selbst wenn nicht, gäbe es nicht mehr Einsicht in persönliche Daten als die, die man selbst abgerufen hat. Insofern denke ich nicht, dass das dabei irgendein Problem ist. Dazu wäre es auch gut, wenn du deine Einschätzung mitteilen könntest, dann hat man weniger Spekulatives und mehr Konkretes an zugehörigen Infos zur Aufgabe/Funktion. ;-) --Geitost 01:25, 27. Sep. 2012 (CEST)

kleine Ergänzung: Über den Austausch der CU untereinander bei der Diskussion von Abfrageergebnissen sowie über die Einsichtmöglichkeit in die CU-Logs haben uU auch jene CU Zugriff auf persönliche Daten, die nicht selbst die Abfrage durchgeführt haben. Gruß --Rax post 05:43, 27. Sep. 2012 (CEST)

Nur, um es mal klarzustellen:

Sofern der Wähler wüßte, daß nächstplazierte mit über 70 % u. U. nachrücken würden, sähe ich da keine großen Probleme. Hätte ja sogar sein können, daß im Falle Seewolf und DaB damals einer von beiden ebendeshalb die eine oder Kontrastimme mehr bekommen hätte, die es nicht gab, da Kulac vorne lag und man es sich ja auch nicht unnötig mit Admins verderben möchte.

Übrinx wären die Stimmzahlen für Brummi und Fossa der SG-Wahl im Mai 2009 (bzw. die nicht ganz so hohen für Brummi und WS im folgenden November) u. U. auch anders ausgefallen, wäre nicht klar gewesen, daß man folgenlos Sympathiestimmen (oder gar Scherzstimmen) verteilen konnte.

Insofern war es wohl als ungewollter Scherz zu verstehen gewesen, als im September 09 jemand nach dem SG-Rücktritt vorschlug, die Nächstplazierten als "Nachrücker" einzusetzen.

Vorteil der von vornherein nominierten Nachrücker:

Die Hemmschwelle für plötzlich RL-belastete, gewählte CU wäre geringer, einfach den Stab weiter zu geben (wenn da einer sein sollte, der ihn legitimierterweise nähme). --Elop 11:52, 27. Sep. 2012 (CEST)

Stimmt, das mit dem Stab, man wäre nicht gar so sehr daran angebunden, die anderen im Team nicht vorzeitig „im Stich lassen“ zu müssen, wenn es wegen des RLs gar nicht mehr ginge. Das könnte noch ein paar zusätzliche geeignete Kandidaten anschwemmen, die sich sonst nicht gar so sehr festbinden lassen wollen. ;-) Außerdem könnte es ja auch sein, das sich dann tatsächlich ein ansonsten Inaktiver regulär verabschiedet, um dieses Nachrücken überhaupt zu ermöglichen. Das könnte die ganze Frustgeschichte auch weiter vermindern. (Man hätte das doch vor der Wahl mal diskutieren sollen, dann hätte man nicht wieder ein Jahr lang so weitermachen müssen wie bisher. ;-) )

Es kann das Wahlverhalten in mehrere Richtungen verändern, ja. Man vergibt nicht statt der 4. Prostimme eine Enthaltung, weil nur 3 gesucht werden. Oder man vergibt doch ein Kontra, was sonst nicht vergeben worden wäre. Deshalb muss es auch vorher klar sein, gerade weil die Ergebnisse ja nicht bei den Nachrückern bei 80% – 90 % liegen (so wie im Bürokratenbereich). ;-)

Beispiel: CU-Logbuch

CU-Logs: Das sind ja verschiedene, wird ja oft genug durcheinandergeworfen, da sollte man schon genau sein. Da gibt es doch die, die man selbst abfragt und wo die entscheidenden persönlichen Daten drinstecken und die kein anderer CUB zu Gesicht bekommt, weshalb ohne weitere Infos die liegen gebliebene Anfrage von Hei_ber niemand regulär abschließen konnte. Und andererseits die Logs, die für alle CUBs (dann auch dauerhaft nachträglich für die neuen im Team) einsehbar sind, wo meines Wissens nach aber nix anderes drinsteht als: Wer hat welches Konto oder welche IP-Adresse zu welchem Zeitpunkt abgefragt? Nicht aber, welche Ergebnisse die Abfragen ergeben haben. Man könnte also insbesondere dauerhaft nachträglich auch noch von 2006 (da wurden lokale CUBs eingeführt), 2007, 2008 oder wann immer einsehen, welche Konten und IPs irgendwann mal abgefragt wurden. Ja gut, insofern gibt es also nachträglich begrenzte Einsicht. Bei den Konten wäre die jeweilige Abfrage ja sowieso im Normalfall damals auch öffentlich mitgeteilt worden, sodass das auch in den Archiven öffentlich stünde. Bei den IPs evtl. eher nicht, da diese normal eher nicht bekannt gegeben werden.

Und die Diskussionen untereinander zu den Abfragen betreffen ja nur die aktuellen Abfragen, nicht aber irgendwas von anno dazumal. Dafür ist man ja gewählt worden, damit man das bearbeitet.

Alles in allem denke ich nicht, dass das genügend gegen Nachrücker sprechen würde, wenn diese immerhin noch eine übrig bleibende Amtsdauer von über einem Jahr hätten. Außerdem kann man jemanden mit 70 % bis 80 % Stimmenanteil auch nicht wirklich gut als „Wahlverlierer“ bezeichnen. --Geitost 14:52, 27. Sep. 2012 (CEST)

jo, sehe ich auch so (wobei ich die Bedenken dagegen durchaus verstehen kann). Logs: Jein, es gibt nur ein CU-Logbuch, welches die Vorgänge festhält, außerdem das von uns händisch geführte Pseudo-Log auf der Anfragen-Seite. Das, was nur ich bei einer Abfrage sehe (und in Zweifelsfällen Kollegen/innen mit CU-Flag zur Einsicht geben darf, s. 3. Absatz) sind die geloggten Daten ;) --Rax post 18:37, 27. Sep. 2012 (CEST)

Das Pseudolog meinte ich nun ja nicht. Ach, ich hab da jetzt wohl was durcheinandergeworfen bzw. war das ungenau. Es gibt also ein Log, aber 2 Spezialseiten für CU (eine für die Abfragen selbst und eine für das Logbuch), so richtig? Das hatte ich gemeint. Also die Abfrageergebnisse, aber die werden ja nicht geloggt, sondern nur, dass und was (Konto/IP) überhaupt abgefragt wurde, offensichtlich auch jeweils mit einer Begründung dazu; das war dann jetzt missverständlich. Deshalb kann die abgefragten Daten ja auch dann niemand anders einsehen, da sie gar nicht geloggt werden. Jetzt hammers, richtig? Also: Das erste Bild oben mit dem Logbuch, das wären dann die Daten, die neue CUBs über die alten bisher durchgeführten Abfragen zusätzlich erfahren würden, wenn sie in das Logbuch reinschauen.

Übrigens fehlen bei den fiktiven Beispielen noch Beispiele für die Abfragefunktionen Get edits from IP und Get account edits. --Geitost 19:52, 27. Sep. 2012 (CEST)

• 
  Beispiel: vor einer CU-Abfrage mittels Spezial:Checkuser
• 
  Beispiel: CU-Abfrage von Benutzerkonten
• 
  Beispiel: CU-Abfrage von IPs

Wenn eine CU-Abfrage wirklich nur so kontrolliert ablaufen kann und keine Lücken in der Software sind (??), die einem Checkuser ein Umgehen des Loggings erlauben, dann bin ich auch nicht mehr so skeptisch wie letztes Jahr gegenüber dem Nachrücken eingestellt (bin aber dann für Geitosts Variante). Denn immerhin ist mit der Erhöhung der Checkuserzahl von 3 auf 5 auch eher als früher gewährleistet, dass sie einander gegenseitig kontrollieren und ein eventueller Missbrauch durchsickert.

Frage am Rande, die eigentlich nicht direkt mit dem Thema zu tun hat (aber dieses Thema hat ja auch nichts mit Rax' Kandidatur zu tun): Gibt es außer den Serveradmins noch jemanden innerhalb des WP-Systems, der prinzipiell CU-Daten aus dewiki abfragen könnte, ohne hier eine durch die hiesigen Checkuser nachvollziehbare Spur zu hinterlassen? --Grip99 00:10, 30. Sep. 2012 (CEST)

Lücken in der Software gibt es nur solche, die wir nicht kennen ;) - maW: kann ich nicht ausschließen, aber ich weiß nichts davon. Zu deiner 2. Frage: So weit ich weiß (und überprüft habe), hinterlässt jede Abfrage durch Stewards (das sind die einzigen Nutzer (außer den Serveradmins und den lokalen CUs) die die CU-Rechte haben können) einen Logbucheintrag, wie ihn auch unsere eigenen Abfragen hinterlassen. Außerdem aber ist die Rechte-Annahme der Stewards öffentlich einsehbar dokumentiert in ihrem eigenen Logbch: Bsp. (auf 19.6. schauen), Zusammenhang: [2], [3]. Gruß --Rax post 00:36, 30. Sep. 2012 (CEST)

Man sollte da auch mal die Software verbessern, damit man in den Logs gezielt nach allen Rechteänderungen von Benutzern suchen kann, die auf „@dewiki“ enden. Warum wurde so was eigentlich noch nicht erfunden? :-/ --Geitost 01:51, 30. Sep. 2012 (CEST)

@Rax: Die Frage mit der Software ging eher an Leute, die Einblick in die Programmierung haben. Es gibt ja vielleicht manchmal Abschnitte im Programmcode, die erfahrungsgemäß unübersichtlicher und fehleranfälliger als andere sind, auch wenn man keinen konkreten ungefixten Fehler kennt. --Grip99 01:02, 3. Okt. 2012 (CEST)