99" en lugar del precedente 99? —usernamekiran (discusión) 17:40 7 sep 2024 (UTC) [ responder ]
">
Discusión de Wikipedia:Solicitudes de administración
La hora actual es 03:02, 17 octubre 2024 (UTC) . — Limpiar esta página
porcentaje en el recuento
¿Por qué el recuento de Asilvering muestra ">99" en lugar del precedente 99? —usernamekiran (discusión) 17:40 7 sep 2024 (UTC) [ responder ]
Parece que así es como está codificada la plantilla:Recent RfX . En términos sencillos, creo que significa "Si el porcentaje de apoyo se redondea a 100 pero hay un oponente, se muestra >99". Creo que esto tiene sentido lógico... no es realmente un 100% de RFA si hay oponentes. Así que creo que estaría a favor de mantenerlo. – Novem Linguae ( discusión ) 19:40, 7 de septiembre de 2024 (UTC) [ responder ]{{#ifexpr:{{#expr:100*{{{5|0}}}/({{{5|0}}}+{{{6|0}}}) round 0}} = 100 and {{{6}}} > 0 | >99 |{{#expr:100*{{{5|0}}}/({{{5|0}}}+{{{6|0}}}) round 0}}
Me encuentro sorprendentemente opuesto a este cambio reciente (y por "reciente" me refiero a " hace dos meses "); si queremos decimales, deberíamos codificar en decimales, no poner una excepción para un caso específico en el que queremos que alguien se sienta mejor al recibir una o dos protestas . Primefac ( discusión ) 12:32 11 sep 2024 (UTC) [ responder ]
Estoy de acuerdo con Primefac. Que sea lo que sea. —usernamekiran (discusión) 20:06 11 sep 2024 (UTC) [ responder ]
Solo como nota, leí (después de publicar aquí) las publicaciones relevantes donde se propuso por primera vez este problema; la intención no era generar sentimientos agradables como publiqué cínicamente antes (por lo que lo he eliminado), sino más bien porque el módulo solía redondear >99,5% a 100%, lo que no es necesariamente correcto. Creo que simplemente agregar un solo punto decimal será más que suficiente. Primefac ( discusión ) 12:09, 12 de septiembre de 2024 (UTC) [ responder ]
Me gusta más como está, pero no quiero que la gente analice los decimales en las solicitudes de asilo difíciles. Es algo menor, pero creo que solo acentúa la importancia del porcentaje. theleekycauldron ( discusión • ella/ella) 01:12 13 sep 2024 (UTC) [ responder ]
Estoy de acuerdo con leeky. >99 es bueno para "redondear a 100, pero no exactamente", y en general, realmente no queremos lidiar con decimales en un !vote. -- SarekOfVulcan (discusión) 16:03 19 sep 2024 (UTC) [ responder ]
Para ser honesto, no creo que el [[>]] sea particularmente útil; es demasiado vago para ser preciso. El status quo ante era suficiente y lo suficientemente fácil para que cualquiera lo entendiera: si alguien pasa sin oposición, eso es 100%. Cualquier otra cosa siempre estará por encima y por debajo de algo más. SerialNumber 54129 18:17, 19 de septiembre de 2024 (UTC) [ responder ]
Bueno, digamos que tenemos una RFA con 249 apoyos y uno en contra. 249/250 = .996, que se redondea al 100%, lo cual es incorrecto. ">99" es una buena forma de indicar la falta de unanimidad sin redondear mal el resultado o usar fracciones de un porcentaje que, como dije antes, no son demasiado útiles en una discusión que no se supone que sea una votación. -- SarekOfVulcan (discusión) 19:10 19 sep 2024 (UTC) [ responder ]
Exactamente. Por lo tanto, cualquier cosa que no sea unanimidad = 99 %. Sin errores de redondeo, sin fracciones, sin problemas. Número de serie 54129 19:16, 19 de septiembre de 2024 (UTC) [ responder ]
Bueno, no, redondear 99,6 hacia abajo a 99 mientras que redondear 98,9 hacia arriba a 99 es un redondeo incorrecto. -- SarekOfVulcan (discusión) 19:42 19 sep 2024 (UTC) [ responder ]
Eso suena más como si debiéramos redondear hacia abajo. Primefac ( discusión ) 19:55 19 sep 2024 (UTC) [ responder ]
Aquí hay un chiste sobre el sesgo intrínseco de los números enteros, pero no se me ocurre ninguno. Levivich ( discusión ) 05:11 1 oct 2024 (UTC) [ responder ]
Propuestas de Bikeshed #9487209 y #9487210
Se trata, por supuesto, de asuntos muy importantes que deben ser objeto de la atención de la comunidad:
Propuesta nº 9487209 de Bikeshed: Todas las páginas de RFA dicen que las preguntas de varias partes disfrazadas de una sola pregunta, con la intención de evadir el límite, no están permitidas. Siempre me reí de eso, imaginando a alguien poniendo dos preguntas en una sola gabardina para disfrazarlas como una sola pregunta con la intención de evadir el límite. ¿Alguien además de mí piensa que esta es una forma extrañamente hostil de decir "las preguntas de varias partes no están permitidas"? ¿O las preguntas de varias partes realmente tienen que estar disfrazadas para que no se permitan? ¿Están permitidas las preguntas de varias partes descaradamente obvias?
Propuesta de Bikeshed n.° 9487210: el aviso de edición de esta página dice que este NO es el lugar para pedir consejos sobre sus posibilidades de convertirse en administrador; para eso realmente hay una gran cantidad de páginas de consejos. Si realmente hay una gran cantidad, ¿quizás deberíamos incluir enlaces a algunas? Parece un poco estúpido decir "¡esta NO es la página correcta! ¡Realmente hay muchas otras páginas! Sin embargo, no vamos a mencionar ninguna específicamente". Esto es particularmente gracioso dado que el último punto del aviso de edición es "Por favor, mantenga la calma y sea civilizado..." sí, a diferencia de este aviso de edición.
De todos modos, como es habitual, tendremos un proceso de RFC de tres etapas para responder a estas preguntas, seguido de una votación confirmatoria de SecurePoll, momento en el que se enviará al Consejo de Administración para su aprobación. Levivich ( discusión ) 01:56 15 sep 2024 (UTC) [ responder ]
He cortado el nudo gordiano y he añadido un enlace a WP:RFAADVICE , que enlaza a otros consejos y a WP:ORCP . Creo que el punto original es que si no sabes qué es ORCP, es casi seguro que no estás preparado para ir allí. En cuanto a 9487209, lo intenté . House Blaster ( discusión • él/ellos) 03:08, 15 de septiembre de 2024 (UTC) [ responder ]
Buena idea la de hacer que el texto de la pregunta de dos partes sea menos agresivo y más conciso. He cambiado el texto en Template:RfA/readyToSubmit a No se permiten preguntas de varias partes, pero se permite hacer preguntas de seguimiento relacionadas con preguntas anteriores. —Femke 🐦 ( discusión ) 08:12 15 sep 2024 (UTC) [ responder ]
He limpiado WP:RFAADVICE , ya que sorprendentemente estaba lleno de WP:ABF y comentarios desagradables. Podría ser beneficioso volver a leerlo. —Femke 🐦 ( discusión ) 20:11, 15 de septiembre de 2024 (UTC) [ responder ]
Se lo he llevado a User:Houseblaster/Advice for RfA candidates con la esperanza de que pueda ser corregido. Si otros desean ayudar, por favor háganlo. Hicimos algo similar para renovar Help:Your first article y fue (en mi opinión muy parcial) muy exitoso. Después de unos momentos de observación, definitivamente parece que fue escrito pieza por pieza, con pequeñas partes que se actualizan a medida que pasan los años. Hay mucho WP:BITE que puede transformarse en una redacción suave del tipo "esto probablemente no sea para ti". House Blaster ( discusión • él/ellos) 20:41, 15 de septiembre de 2024 (UTC) [ responder ]
Fue escrito en gran parte por un solo editor, por lo que los cambios se han ceñido a ese punto de vista y estilo de escritura originales. Pero como ese editor se ha retirado de la edición, hay más oportunidades de incorporar otras perspectivas y alterar el estilo de escritura. isaacl ( discusión ) 21:30 15 sep 2024 (UTC) [ responder ]
Es posible que desees modificar WP:RFAADVICE directamente en lugar de bifurcarlo. Las ventajas incluyen evitar conflictos de fusión, no tener que copiar y pegar / WP:HISTMERGE más tarde y permitir que más personas participen en el proceso. – Novem Linguae ( discusión ) 22:08, 15 de septiembre de 2024 (UTC) [ responder ]
El problema con eso es que cuando hay muchos editores involucrados en la edición de una página de consejos, pueden llegar con diferentes puntos de vista y mensajes diferentes que pueden entrar en conflicto entre sí. Creo que páginas como esta realmente deben ser ensayos de espacio de usuario para empezar. Debidamente firmado, ⛵ WaltClipper - ( discusión ) 12:51, 7 de octubre de 2024 (UTC) [ responder ]
Aunque también puede ser bueno que muchas personas editen una página. Así es como funciona nuestro proceso de edición iterativa habitual. Muchos editores pueden lograr que una página termine con un buen equilibrio que refleje el consenso. – Novem Linguae ( discusión ) 16:04, 7 de octubre de 2024 (UTC) [ responder ]
No funciona tan bien en las páginas de consejos, porque a menudo, para lograr claridad, es más efectivo no cambiar entre varios puntos de vista en una página, por lo que los partidarios de cada lado preferirán páginas separadas. Dicho esto, para este caso específico, no creo que Wikipedia:Advice for RfA candidates deba ser un ensayo de espacio de usuario, ya que creo que existe consenso para una cantidad suficiente de consejos comunes. isaacl ( discusión ) 16:16, 7 de octubre de 2024 (UTC) [ responder ]
Wikipedia:Revocación del mandato del administrador
¿Deberíamos crear una página sobre el nuevo proceso de destitución de administradores? Un wikipedista cualquiera ( discusión ) 08:39, 16 de septiembre de 2024 (UTC) [ responder ]
Discusión relevante aquí , podría haber sido mejor si hubiera más personas presentes. Fue una propuesta interesante, aunque más bien plantea la pregunta de cuándo usar < :) Número de serie 54129 13:51, 19 de septiembre de 2024 (UTC) [ responder ]
Quiero sugerir una nueva regla para todo el sitio: durante los próximos 3 meses, no se permitirán hilos nuevos en ningún lugar del espacio del proyecto sobre temas que no sean uno de los, digamos, 500 problemas más importantes que enfrentamos. -- Floquenbeam ( discusión ) 14:02, 19 de septiembre de 2024 (UTC) [ responder ]
Nadie te lo impide, aunque, como bien sabes, este no es el lugar para semejante propuesta. SerialNumber 54129 14:14 19 sep 2024 (UTC) [ responder ]
Solo quiero señalar que esto ya se está discutiendo en el porcentaje de recuento anterior. Primefac ( discusión ) 15:27 19 sep 2024 (UTC) [ responder ]
Gracias por eso, Primefac , no me había dado cuenta. Número de serie 54129 18:10, 19 de septiembre de 2024 (UTC) [ responder ]
Elecciones de Administradores: Convocatoria de Candidatos
Elecciones de administradores| Convocatoria de candidatos
Se recomienda a los candidatos potenciales que se familiaricen con las expectativas que la comunidad tiene de los administradores, que son mucho más altas que el requisito mínimo de tener un estatus de confirmación extendido. Esto incluye revisar las solicitudes de propuestas aprobadas y rechazadas , leer el ensayo Wikipedia:Advice for RfA candidates y posiblemente solicitar una encuesta opcional sobre sus posibilidades de aprobar .
El proceso tendrá una fase de convocatoria de candidatos de una semana, una pausa de una semana para configurar SecurePoll, un período de tres días de discusión pública, seguido de 7 días sin discusión pública y una votación privada utilizando SecurePoll.
Los resultados de este proceso son idénticos a los de la solicitud de administración. No existe ninguna diferencia oficial entre un administrador designado mediante una solicitud de admisión o una elección de administrador.
Haga cualquier pregunta sobre el proceso en la página de discusión . Se enviará un mensaje de discusión por separado a los candidatos oficiales con información adicional sobre el proceso.
Para evitar enviar demasiados mensajes, este será el último mensaje masivo que se envíe sobre las elecciones de administrador. Si está interesado en el proceso, asegúrese de incluir en la lista de seguimiento las páginas correspondientes. Se agregará un aviso de lista de seguimiento cuando se abra la fase de discusión y nuevamente cuando se abra la fase de votación.
Recibes este mensaje porque te suscribiste a la lista de correo. Para dejar de recibir correos en el futuro, elimínate de la lista .
Bueno, ciertamente parece que está funcionando para conseguir que los candidatos potenciales participen . Es interesante que hasta ahora todos los candidatos se hayan autoproclamado. Valereee ( discusión ) 22:24 8 oct 2024 (UTC) [ responder ]
Es cierto, pero si la votación es confidencial y se pulsan botones de opción, entonces me temo que habrá muchos votos en contra sin fundamento. —usernamekiran (discusión) 00:27 9 oct 2024 (UTC) [ responder ]
Si no recuerdo mal, esa es una de las razones por las que algunas personas apoyan esta idea: permite la oposición sin represalias. Primefac ( discusión ) 11:48 9 oct 2024 (UTC) [ responder ]
Esto puede indicar un par de cosas. Podría significar que los candidatos potenciales típicos contactados por el grupo habitual de nominadores no se sienten atraídos por el proceso electoral, y que una elección es menos desalentadora para los editores que no están inclinados a buscar un nominador. Al juntar todo eso, el ensayo está eligiendo entre un grupo más amplio de candidatos. isaacl ( discusión ) 04:13, 9 de octubre de 2024 (UTC) [ responder ]
Creo que el hecho de que todas las demás elecciones en Wikimedia (ArbCom, Steward, U4C, BoT) funcionen únicamente con autonominaciones probablemente también tenga algo que ver. Giraffer ( discusión ) 14:07 9 oct 2024 (UTC) [ responder ]
Esto es absurdo . Ya tenemos 19 candidatos. ¿Alguien piensa de manera realista que alguien tiene tiempo para revisar a 19 candidatos en 10 días para determinar si todos estos candidatos están listos para la administración? Yo seguro que no. Votaré en contra de todos los que no tenga la oportunidad de revisar. Como mínimo, el número de candidatos para una elección debería limitarse a 5 por elección, y no más. Esto es abrumador. -- Hammersoft ( discusión ) 20:38, 13 de octubre de 2024 (UTC) [ responder ]
Es una votación secreta, por lo que se puede votar en contra por cualquier motivo, incluso uno que sea absurdo y no relacionado con el candidato, como "No he evaluado al candidato". La esperanza es que una cantidad suficiente de votantes evalúe una cantidad suficiente de candidatos para que el resultado sea significativo. — Kusma ( discusión ) 20:46 13 oct 2024 (UTC) [ responder ]
Gracias por el comentario lateral. Mi oposición a los candidatos que no tengo tiempo de revisar es tanto una oposición a un candidato no revisado como una oposición a este sistema en primer lugar. Nadie consideró las implicaciones de este sistema, incluyendo la posibilidad de que se presenten decenas de candidatos a la vez. Nadie tiene tanto tiempo. Eso significa que se presentarán candidatos que no están listos, que no han sido examinados. Oponerse a esos candidatos es una necesidad, no es algo ajeno al candidato. Gracias. -- Hammersoft ( discusión ) 20:51, 13 de octubre de 2024 (UTC) [ responder ]
Esta última ronda de reformas de la RFA hace lo que las reformas anteriores no hicieron: arrojar muchas cosas a la pared y ver qué se pega. Si sus predicciones resultan ser ciertas (es decir, demasiados candidatos, poco tiempo y editores no calificados recibiendo la mopa como resultado), entonces eso se confirmará en el proceso de retroalimentación al final. Si suficientes personas piensan como usted, entonces sospecho que el número de candidatos exitosos en esta parte de la revisión será bajo, y no volverá a suceder. Primefac ( discusión ) 21:08, 13 de octubre de 2024 (UTC) [ responder ]
Cuando me convertí en administrador, se publicaban alrededor de dos o tres nuevas solicitudes de participación por día. No todos los votantes potenciales evaluaban a todos los candidatos (solo había ochenta y un votantes en total en mi caso), pero los candidatos eran examinados de todos modos (según los estándares más bajos de la época). — Kusma ( discusión ) 21:10 13 oct 2024 (UTC) [ responder ]
Afortunadamente, no tienes que revisarlos todos, ya que existe la opción de abstenerte en aquellos que no pudiste revisar. Es mucho más justo para los candidatos. Creo que un límite (de 12/15) sería bueno para futuras elecciones, aunque sospecho que habrá menos candidatos en una segunda elección. —Femke 🐦 ( discusión ) 20:52 13 oct 2024 (UTC) [ responder ]
1) “Neutral” podría ser un mejor voto predeterminado que “oponerse”.
2) No es demasiado tarde para proponer que cada candidato tenga un número mínimo de votos a favor y en contra para garantizar que reciba el escrutinio suficiente. Esto evitaría una situación en la que un candidato que se encuentra al final de la lista tuviera unos 20 votos a favor y ninguno en contra y fuera elegido con un quórum muy bajo. Podrías proponer esto en WT:AELECT y podríamos implementarlo antes del final de las elecciones, si hay un consenso lo suficientemente fuerte.
3) Las guías para votantes pueden ser una herramienta para investigar adecuadamente a un gran número de candidatos. – Novem Linguae ( discusión ) 21:55 13 oct 2024 (UTC) [ responder ]
Me interesará ver cómo resulta esto. Y estoy de acuerdo con Primefac, es mejor probar algo y ver si funciona que no probar nada (la estrategia de los últimos 15 años). Si yo estuviera a cargo, habría hecho algunos cambios, pero vale la pena experimentar. Para su información, NL, las guías para votantes están explícitamente mal vistas en las instrucciones. Y sospecho (aunque no estoy seguro) que es demasiado tarde para cambiar el valor predeterminado a neutral. Pregunta: ¿el orden de los candidatos se aleatorizará cada vez que alguien vote? Floquenbeam ( discusión ) 22:03 13 oct 2024 (UTC) [ responder ]
Y sospecho (aunque no estoy seguro) que es demasiado tarde para cambiar la opción predeterminada a neutral. Parece que las opciones de voto para cada candidato serán apoyar, abstenerse y oponerse. He propuesto que todas las opciones predeterminadas sean abstenerse o dejar el voto en blanco, sin objeciones hasta ahora. Hay más discusión en la discusión de Wikipedia:Elecciones de administradores#Opciones de voto y opciones predeterminadas .
SecurePoll no permite aleatorizar el orden de los candidatos. Propuse que la tercera opción fuera "Abstenerse" en abril, para reflejar con precisión el efecto de esa elección. La configuración de SecurePoll se realizará después de que se cierren las nominaciones y se finalice la lista de candidatos. isaacl ( discusión ) 01:29, 14 de octubre de 2024 (UTC) [ responder ]
Creo que SecurePoll admite la aleatorización del orden. Veo la opción en Special:SecurePoll/create. – Novem Linguae ( discusión ) 03:58, 14 de octubre de 2024 (UTC) [ responder ]
Mis disculpas; leí mal otra conversación sobre este tema (debería haberlo pensado un poco más, ya que mi recuerdo de discusiones anteriores era que se admitía el orden aleatorio). isaacl ( discusión ) 05:20, 14 de octubre de 2024 (UTC) [ responder ]
Creo que el orden debería ser aleatorio, no alfabético. Hay efectos de sesgo en el orden de las papeletas y preferiría que se neutralizaran lo más posible. theleekycauldron ( discusión • ella/ella) 18:05 14 oct 2024 (UTC) [ responder ]
Y ahora estamos en 31. Esto es completamente imposible. <smdh> -- Hammersoft ( discusión ) 17:28 14 oct 2024 (UTC) [ responder ]
Considero que esto es una victoria absoluta. Deberíamos querer que haya más candidatos dispuestos a considerar la RFA. Ningún votante tiene que evaluar personalmente a cada candidato, sólo suficientes votantes para evaluarlos a todos colectivamente. Independientemente de cuántas personas resulten elegidas en este ciclo, este proceso está funcionando exactamente como se prometió. Soni ( discusión ) 17:44 14 oct 2024 (UTC) [ responder ]
Esto es un desastre en ciernes. Tienes razón. Ningún votante tiene por qué evaluar personalmente a todos los candidatos. Pero, con 31 candidatos, ningún candidato va a ser examinado adecuadamente por suficientes personas. Esto es una locura. Absolutamente una locura. -- Hammersoft ( discusión ) 18:00, 14 de octubre de 2024 (UTC) [ responder ]
¿Es una locura suponer que la gente examinará a tantos candidatos como sea posible y luego dejará el resto de su papeleta en blanco/neutral, y por lo tanto no permitirá/bloqueará a candidatos malos/buenos? Teniendo en cuenta que el orden probablemente será aleatorio, dudo que esto lleve a problemas como que el último candidato obtenga 1 apoyo y 0 oposiciones y luego se convierta en administrador. Creo que debería haber un límite en la cantidad de candidatos en el futuro (¿quizás 10?), pero dudo que tengamos tantos nuevamente. Creo que es una tontería oponerse y posiblemente rechazar a alguien que podría ser un buen administrador sin ninguna razón real, pero supongo que uno de los beneficios propuestos de este sistema es que puedes oponerte por cualquier razón sin molestar a nadie, jajaja. De todos modos, como dijo Primefac, todos reconocen que RfA tiene problemas, pero nadie quiere hacer nada al respecto. ¿Por qué no arrojar cosas a la pared y ver qué se pega? ULPS ( discusión • contribuciones ) 18:23, 14 de octubre de 2024 (UTC) [ responder ]
(para permitir la inserción de la tabla) No voy a votar a favor de alguien a quien no he examinado. No voy a votar de manera neutral cuando el sistema está tan obviamente roto. Dado el cronograma absurdo y la falta de controles sobre esto, la opción predeterminada tiene que ser oponerse hasta que un candidato pueda demostrar su valía. Comparemos esto con las elecciones de ArbCom:
([1] promedio de los últimos tres ciclos para ArbCom)
Como puede ver, tenemos 3 VECES más candidatos , con la MITAD de la etapa de discusión y la MITAD de la etapa de votación. Es decir, la carga de trabajo es esencialmente seis veces la carga para las elecciones de ArbCom. Peor aún, no se permiten guías para votantes , por lo que no puede recurrir al análisis de otra persona para que lo guíe en su revisión. Entonces, aquí, tiene la mitad del tiempo, el triple de candidatos y no se permite ninguna asistencia. Y esto, para poner a las personas en una posición que posiblemente tenga más poder e impacto en el proyecto en el día a día que un miembro de ArbCom. Este montón de cosas se podría haber evitado si alguien hubiera pensado... aunque sea por un momento... en el impacto de este sistema y dónde podrían estar los puntos de falla. Qué desastre absoluto. -- Hammersoft ( discusión ) 19:20, 14 de octubre de 2024 (UTC) [ responder ]
¡Ven a hablar con fuerza! Si tu objetivo es desahogarte, espero que te sientas mejor. Si el objetivo es persuadir, entonces tal vez quieras bajar un poco el tono. No estás dando la impresión de ser persuasivo. Creo que no es la primera vez que utilizas un enfoque del tipo "todos son idiotas excepto yo". Floquenbeam ( discusión ) 19:43 14 oct 2024 (UTC) [ responder ]
Si tu objetivo es insultarme, no está funcionando. Si tu objetivo es persuadirme para que piense de otra manera sobre este sistema fallido, no está funcionando. Estás dando la impresión de que me estás atacando. Que tengas un buen día. -- Hammersoft ( discusión ) 19:54 14 oct 2024 (UTC) [ responder ]
¿Qué, entonces lograron atacarte sin insultarte? Esta parece una habilidad excelente. ¿Dónde puedo aprenderla? ~~ AirshipJungleman29 ( discusión ) 20:17 14 oct 2024 (UTC) [ responder ]
También podrías tomar ejemplo de Floq y preguntarte: "¿Este comentario es productivo o simplemente estoy haciendo algo?" Se agradecerían intentos de bajar la temperatura. Parabolist ( discusión ) 21:40 14 oct 2024 (UTC) [ responder ]
Me viene a la mente una canción de Billy Joel. No, esto no es el arenero, pero esperar silencio como respuesta no es razonable. -- Hammersoft ( discusión ) 13:36 15 oct 2024 (UTC) [ responder ]
Por cierto, mientras intentaba abrirme paso entre el último grupo de candidatos, Xtools de repente me dijo que había cerrado la sesión y que necesitaba acceder a mis cuentas para permitirme ver los recuentos. ¿Está bien? Nunca había visto este mensaje antes. Espresso Addict ( discusión ) 19:47, 14 de octubre de 2024 (UTC) [ responder ]
Si intentas acceder a demasiadas páginas de XTools en un corto período de tiempo, te pedirá que inicies sesión para asegurarte de que no eres un bot. Charlotte ( Queen of Hearts • discusión ) 19:50, 14 de octubre de 2024 (UTC) [ responder ]
También pregunta esto si estás viendo a alguien con un recuento de ediciones realmente alto. Creo que la barra está en 100 000 ediciones. Clovermoss 🍀 (discusión) 19:52 14 oct 2024 (UTC) [ responder ]
150k; xtools:ec/enwiki/The Bushranger (149,950 ediciones) funciona, pero xtools:ec/enwiki/IronGargoyle (150,140 ediciones) no. Charlotte ( Queen of Hearts • discusión ) 19:59, 14 de octubre de 2024 (UTC) [ responder ]
Estaba intentando evaluar a Robert McClenon, así que el problema podría ser que haya más de 100 000 ediciones. Supongo que no es un riesgo de seguridad permitirle acceder a mis cuentas. Espresso Addict ( discusión ) 20:07 14 oct 2024 (UTC) [ responder ]
No, no hay ningún riesgo de seguridad. XTools solo quiere ver que estás conectado a Wikimedia, de modo que solo realiza cálculos costosos para humanos en lugar de bots. – Novem Linguae ( discusión ) 20:15, 14 de octubre de 2024 (UTC) [ responder ]
Creo que va a ser difícil tener algún tipo de debate significativo sobre 33 candidatos en tres días. Sería injusto cambiar el proceso a mitad de camino, por lo que estamos en cierto modo atrapados en eso ahora, pero tal vez la próxima vez podamos limitar el número de candidatos, escalonar más las elecciones y/o permitir más tiempo para el debate. – Joe ( discusión ) 20:08, 14 de octubre de 2024 (UTC) [ responder ]
Estoy de acuerdo con esto. Un límite de 10 a la vez parece una buena idea. Clovermoss 🍀 (discusión) 20:19 14 oct 2024 (UTC) [ responder ]
Sí, seguramente este será el punto número 1 en el informe de "lecciones aprendidas" que se realizará después. Floquenbeam ( discusión ) 20:22 14 oct 2024 (UTC) [ responder ]
Sí, es una locura que tengamos más de 30 candidatos cuando no podríamos conseguir ni uno al mes con una convocatoria de propuestas tradicional. No creo que nadie hubiera predicho eso. Está claro que si queremos animar a la gente a que se presente, esta es una forma de hacerlo. Valereee ( discusión ) 20:25 14 oct 2024 (UTC) [ responder ]
¿Valdría la pena preguntar si alguien está dispuesto a posponer su candidatura? ScottishFinnishRadish ( discusión ) 21:48 14 oct 2024 (UTC) [ responder ]
¿Aplazar para qué? Según tengo entendido, no hay acuerdo para volver a hacerlo y veo que la saturación del campo puede llevar a una oposición a hacerlo de nuevo. Sospecho que tendremos que esperar a ver cómo se resuelven las cosas. Wehwalt ( discusión ) 22:00 14 oct 2024 (UTC) [ responder ]
En realidad, es una gran idea. ¿Podríamos hacer una por mes durante los próximos cuatro meses, tal vez? Aunque tal vez nos salteemos diciembre debido a las elecciones de ArbCom... ¿quizás una cada octubre, noviembre, enero y febrero? Si los escrutadores y Secure Poll no se ven afectados negativamente. Valereee ( discusión ) 22:01 14 oct 2024 (UTC) [ responder ]
¿Dónde vais a encontrar tiempo y consenso para cambiar el formato? Wehwalt ( discusión ) 22:04 14 oct 2024 (UTC) [ responder ]
Si piensas a largo plazo, si el proceso electoral obtiene un apoyo consensuado para su uso continuo, seguro, las diversas propuestas recientes (incluida la original propuesta en las discusiones de reforma de 2024) prevén la celebración de elecciones programadas regularmente. Sin embargo, realizarlas regularmente supone un coste para el personal de soporte de la WMF, además de requerir escrutadores. Los planes para que SecurePoll se ejecute en servidores wiki locales y sea configurable por administradores locales ayudarían a aliviar el primer problema, aunque seguiría habiendo un coste (y no está claro cuándo podría suceder). Los recursos de escrutadores podrían convertirse en un cuello de botella (ya sea que el papel lo ocupen administradores como en el ensayo actual o editores de Wikipedia en inglés). isaacl ( discusión ) 22:12, 14 de octubre de 2024 (UTC) [ responder ]
¿Si pudiéramos hacer una por mes durante los próximos cuatro meses, tal vez? Lograr que WMF T&S configure SecurePoll y que los administradores lo examinen es un proceso costoso. No creo que podamos convencer a esas partes interesadas de que lo hagan cuatro veces. – Novem Linguae ( discusión ) 02:47, 15 de octubre de 2024 (UTC) [ responder ]
El proceso se puede ajustar más si queremos tener un uso más regular de SecurePoll. En zhwiki, la Fundación les exige que utilicen SecurePoll para votar sobre los nombramientos de CheckUsers de RfAs y, después de una RfC, que utilicen SecurePoll para las RfAs (incluidos los administradores de interfaz y los burócratas) , y lo hacen con regularidad. Pero en lugar de que solo los administradores examinen, los administradores de sistemas operativos locales también pueden ayudar. Además, tal vez se pueda ajustar más la duración de la discusión y/o la votación. Si la preocupación es que hay demasiados solicitantes, se puede extender la discusión a dos semanas (también como en zhwiki). – robertsky ( discusión ) 22:40, 15 de octubre de 2024 (UTC) [ responder ]
Se modificó el comentario anterior para aclarar lo que se exigía. Enlaces de zhwiki: archivo de la página de discusión 8, RfC para usar SecurePoll para las elecciones de administradores. – robertsky ( discusión ) 09:15, 16 de octubre de 2024 (UTC)[ responder ]
Tal vez un aspecto más preocupante de esto es que algunos de los votantes simplemente van a votar de manera neutral o incluso en contra de todos los candidatos que no tuvieron tiempo de examinar, y luego algunos de esos candidatos van a pensar "espera, ¿por qué estas 100 personas piensan que no estoy listo para ser un administrador?", y podríamos volver al punto de partida con candidatos tímidos, porque ese resultado bien podría deprimir el volumen de candidaturas más adelante. -- Joy ( discusión ) 11:38, 15 de octubre de 2024 (UTC) [ responder ]
En lo que respecta a la "neutralidad de las masas", los votos neutrales o de abstención no tienen ningún impacto en el resultado. Es posible que haya oposiciones masivas, pero los candidatos podrían considerar que algunos de ellos pueden ser editores que se oponen al proceso, no ellos personalmente. — xaosflux Discusión 13:09, 16 de octubre de 2024 (UTC) [ responder ]
</smdh>Conozco a algunos candidatos que dicen "sí" de manera obvia y a algunos que dicen "no" de manera obvia. Es decir, candidatos de los que tengo plena confianza en que podría predecir los resultados desequilibrados de una RFA tradicional. Será interesante ver cuánto apoyo recibe un candidato que dice "no" de manera obvia (un sustituto razonable de una falta general de investigación) y cuánta oposición recibe un candidato que dice "sí" de manera obvia (un sustituto razonable de una decisión general por defecto de "no"). -- Floquenbeam ( discusión ) 20:18 14 oct 2024 (UTC) [ responder ]
No me preocupa tanto la viabilidad de la evaluación de los candidatos como a otros editores. Sí, hay muchos menos días y muchos más candidatos que en las elecciones de ArbCom, pero aún faltan 10 días desde el final de las nominaciones hasta el final del período de votación (y 17 días desde que se presentaron al menos algunos de los candidatos). Y hay menos de 33 candidatos que necesitan una investigación exhaustiva, dado que algunos de ellos pueden ser "obviamente no". -- Tryptofish ( discusión ) 23:01, 14 de octubre de 2024 (UTC) [ responder ]
En realidad, me olvidé del período de configuración de SecurePoll cuando escribí eso, por lo que 10 días son en realidad 17 días, y 17 días son en realidad 24. Con más de 30 candidatos, uno podría, si lo desea, investigar un promedio de aproximadamente dos candidatos por día, lo que no es necesariamente tan abrumador. -- Tryptofish ( discusión ) 22:11, 15 de octubre de 2024 (UTC) [ responder ]
En cuanto a los "puntos de falla" de este proceso, no creo que nadie pudiera haber previsto que tendríamos un problema con un número tan alto de candidatos, especialmente considerando que las elecciones tenían como objetivo resolver el problema opuesto. 36 candidatos es una cifra descabellada : el último *año* en el que hubo 36 candidatos (en RfA) fue 2017, y mucho menos todos a la vez. Solo 14 personas se han presentado a RfA este año, y solo 19 el año anterior. Tener tantas personas presentándose a la vez no tiene precedentes, y no puedo culpar a nadie por no prepararse para ello. Giraffer ( discusión ) 23:05 14 oct 2024 (UTC) [ responder ]
Exactamente lo que pienso. Es como sufrir una inundación repentina en una zona de sequía (¡spoilers del final de Holes !). theleekycauldron ( discusión • ella/ella) 02:48, 15 de octubre de 2024 (UTC) [ responder ]
Por lo que puedo ver, los análisis/tablas que se incluirían en una guía al estilo Arbcom se pueden dividir y colocar en la sección de discusión para candidatos individuales (¡por favor!). Dado que no hay cuotas ni prioridades que cubrir, las declaraciones explícitas asociadas de intenciones de voto y la estructura consolidada son menos útiles. ~ Hydronium ~ Hydroxide ~ (Discusión) ~ 04:39, 15 de octubre de 2024 (UTC) [ responder ]
Hablando como candidato, no me ofenden particularmente algunos de los comentarios de "¡Dios mío! Qué horror", porque si sirvo o no, sigo aquí; hablando como miembro del grupo de candidatos, me parece bastante ofensivo que algunos de mis colegas aparentemente estén siendo atacados ~ "Hay demasiados de ustedes, váyanse" ~ después de que respondieron a una convocatoria abierta a la comunidad; hablando como miembro de la comunidad, esto es genial, queríamos probar si un cambio en el proceso conduciría a un cambio en el resultado, aparentemente la respuesta es Sí. Quizás un poco menos de horror y un poco más de respuestas reflexivas (como definitivamente lo hacen algunos aquí) sería más apropiado. Felices días, ~ Lindsay Hola 05:55 , 15 de octubre de 2024 (UTC) [ responder ]
Algunas personas parecen decididas a llevar la cultura de RFA a las elecciones administrativas. Lo siento y gracias a todos los candidatos por tener suficiente fe en la comunidad para participar en este ensayo. Levivich ( discusión ) 06:20 15 oct 2024 (UTC) [ responder ]
Es realmente alentador ver que hay tanto interés, aunque tal vez haya mejores formas de manejar esto logísticamente en el futuro. Clovermoss 🍀 (discusión) 06:33 15 oct 2024 (UTC) [ responder ]
Lo siento, @ LindsayH y otros, no pretendía que mi propio comentario transmitiera "Vete". Me alegra mucho ver este nivel de interés. Valereee ( discusión ) 10:54 15 oct 2024 (UTC) [ responder ]
Con respecto a la cuestión de "oponerse a todos los candidatos que no puedo examinar": recuerden que la ley de los grandes números todavía existe. Examinen a quienes puedan, confíen en otros editores para que llenen los vacíos. Es casi seguro que en estas elecciones votarán muchos más editores que en una convocatoria de propuestas típica. Mientras cada votante examine a quienes pueda (aunque sean solo 5 candidatos), incluso durante el período de discusión, y el orden de votación sea aleatorio, creo que el escrutinio que recibirá cada candidato no será muy diferente al de una convocatoria de propuestas.Existe una oportunidad real de llevar a cabo una reforma significativa de la RfA en forma de elecciones. Es evidente que el proceso electoral necesita cambios en futuras iteraciones (si continuamos con él), pero espero que no desperdiciemos esta iteración (y potencialmente todo el concepto) haciendo algo como una votación masiva en contra. ProcrastinatingReader ( discusión ) 12:06 16 oct 2024 (UTC) [ responder ]
Puede que tengamos un problema con eso, ya que no es tan obvio quién está examinando a qué candidatos. Con el formato normal, es fácil mirar una convocatoria de propuestas de hace tres días y ver cuántas personas han opinado sobre ese candidato. Dicho esto, esta no es la convocatoria de propuestas más concurrida de la historia: en diciembre de 2005 tuvimos 68 candidatos que tuvieron éxito y 33 que no, así que, si encontramos una forma de distribuir a los votantes de la convocatoria de propuestas entre los candidatos, deberíamos poder hacerlo con 31. Si terminamos con un montón de candidatos rechazados porque un pequeño número de votantes se opone a alguien que no han tenido tiempo de evaluar, entonces espero que esos candidatos consideren una convocatoria de propuestas convencional. Por el contrario, si tenemos casi 30 nuevos administradores y un par de ellos resultan no haber sido examinados lo suficiente, entonces espero que encontremos formas de reducir el número de candidatos en el futuro. Aunque, dada la cantidad de tiempo que muchos de estos candidatos llevan en el mercado, sospecho que una repetición en 12 meses traerá bastantes menos candidatos. Hay Spiel Checkers 12:58, 16 de octubre de 2024 (UTC) [ respuesta ]
No estoy muy familiarizado con este proceso, pero pensé que lo entendía hasta ahora. ¿Por qué es necesario que el usuario anterior examine a cada candidato? Hasta donde yo sé, ninguno de nosotros tiene un estatus especial en términos de derecho a voto o poder de veto. Saludos, ForksForks ( discusión ) 13:36 16 oct 2024 (UTC) [ responder ]
Creo que la idea es que cada votante investigue a un candidato antes de votar por él. – Joe ( discusión ) 16:24 16 oct 2024 (UTC) [ responder ]
Eso es ciertamente apropiado, por lo que pueden omitir a todos los candidatos que no hayan investigado también. — xaosflux Talk 17:42, 16 de octubre de 2024 (UTC) [ responder ]
Esa podría ser la "idea", pero la realidad siempre ha sido que los votantes perezosos como yo dependen en gran medida de la sensación de que otros editores competentes han hecho la debida diligencia, y se han dado cuenta de ello, como dice WSC (algo relativamente fácil cuando las nominaciones se estaban volviendo poco frecuentes). Como dije en un comentario que se trasladó de esta página a un lugar más oscuro (ver justo debajo), si no tengo esa sensación, estoy perfectamente dispuesto a oponerme a este grupo en masa . Johnbod ( discusión ) 17:43, 16 de octubre de 2024 (UTC) [ responder ]
Sí, a mí también me preocupa eso. La única solución que se me ocurre son las guías para votantes, pero al parecer están "desaconsejadas". – Joe ( discusión ) 18:16 16 oct 2024 (UTC) [ responder ]
Cada vez tengo más la sensación de que los sentimientos de quienes debaten sobre las elecciones están desconectados de los de otros editores. He intentado ampliar el alcance de la discusión, pero el intento que se muestra a continuación fue reubicado audazmente por un candidato. Espresso Addict ( discusión ) 18:22 16 oct 2024 (UTC) [ responder ]
@ Espresso Addict : He revertido la acción. Creo que fue un poco grosera, ya que se trataba de una discusión en curso y relevante. Número de serie 54129 19:18, 16 de octubre de 2024 (UTC) [ responder ]
No estoy seguro de si esta era tu intención, pero este cambio ha hecho que la sección ahora aparezca tanto aquí como en WT:AELECT#Notice no está en la lista de seguimiento , pero con la versión en RFA que falta la gran mayoría de las respuestas y sin un enlace a la discusión más amplia. Bug Ghost 🦗👻 19:57, 16 de octubre de 2024 (UTC) [ responder ]
No debería haber sido movido en primer lugar: puro bandidaje. Número de serie 54129 20:09, 16 de octubre de 2024 (UTC) [ responder ]
Además, la mayoría de los candidatos a la RfA en los últimos años han tenido uno o más nominadores, por lo que se puede confiar en su diligencia y criterio, mientras que la gran mayoría de los candidatos a las elecciones son autonominados. Espresso Addict ( discusión ) 18:18 16 oct 2024 (UTC) [ responder ]
Aviso no incluido en la lista de vigilancia
El aviso y el enlace a la página ya no están en mi lista de seguimiento (mientras que el de la comisión zzzzArbcom sigue estando ahí). Dado que creo que todos estamos de acuerdo en que el escrutinio adecuado será un gran problema en este caso, eso debería solucionarse. Johnbod ( discusión ) 21:42 15 oct 2024 (UTC) [ responder ]
@Johnbod ¿Para las elecciones? Actualmente es un período de inactividad, no hay un llamado a la acción porque la comunidad no tiene nada que hacer en este momento, el cronograma tiene un período de discusión muy abreviado y no se pueden ingresar preguntas hasta entonces. — xaosflux Discusión 21:54 , 15 de octubre de 2024 (UTC) [ responder ]
¿Será posible replantearse esta situación? Nadie puede evaluar adecuadamente a 37 candidatos en unos pocos días, y esto es mucho más importante que el material habitual de la lista de vigilancia. Espresso Addict ( discusión ) 22:58 15 oct 2024 (UTC) [ responder ]
Tenga en cuenta : debido a la pedantería, esta sección de discusión está duplicada tanto aquí en RFA como en WT:AELECT#Notice no está en la lista de seguimiento , donde hay mucha más discusión. Bug Ghost 🦗👻 20:25, 16 de octubre de 2024 (UTC) [ responder ]
Por pedantería, léase 'meta vigilancia/refactorización que nunca debería haber ocurrido'... SerialNumber 54129 21:06, 16 de octubre de 2024 (UTC)[ responder ]
