El sistema actual es muy complicado. Estar en una subpágina de cuarto nivel en una wiki diferente con el 90% de los comentarios sin firmar, y usar un sistema de emojis para distinguir los problemas resueltos de los no resueltos hace que sea una pesadilla a) encontrar problemas, b) responder y c) pedir más detalles. Sería más fácil tener una página como Wikipedia:Informes en modo oscuro para que más editores puedan ayudar a solucionar problemas. Deberíamos importar la página aquí y archivar la página wiki de MediaWiki. ¿Opiniones? @ SCP-2000 , FeRDNYC y I Am Andumé : como editores involucrados allí en la solución de problemas (si me he olvidado de alguien, no duden en avisarle). — Matrix(!) { usuario - discusión? - contribuciones inútiles } 14:42, 5 de octubre de 2024 (UTC) [ responder ]
Nota: Cuando vayas a "Informar un problema con el modo oscuro", deberías dirigirte aquí: https://www.mediawiki.org/wiki//Reading/Web/Accessibility_for_reading/Reporting/en.wikipedia.org?section=new&action=submit&preloadtitle=PAGEYOUAREON%20dark%20mode%20error&preload=MediaWiki:vector-night-mode-issue-reporting-preload-content . El flujo de trabajo del usuario/dispositivo móvil que ha cerrado sesión puede ser diferente. — xaosflux Talk 20:30, 5 de octubre de 2024 (UTC) [ responder ]
Estos pueden localizarse modificando estos mensajes de interfaz. Sin embargo, si no lo informamos en la página a la que se informa en mediawikiwiki, no debemos esperar que los desarrolladores de software y el equipo del proyecto controlen los informes. — xaosflux Talk 23:28, 5 de octubre de 2024 (UTC) [ responder ]
^ Esto. Piensa si es más importante para ti tener la página estructurada a tu manera o si es más importante que el equipo de desarrollo revise los comentarios. Las compensaciones son un hecho de la vida. En mi opinión, es probable que aprecien algunas mejoras en el formato, pero también es posible que esto sea lo que mejor les funcione (por ejemplo, ¿quizás omitir las firmas les resuelva un problema de privacidad si importan los comentarios a un sistema diferente? Lo dudo, pero la valla de Chesterton sugiere que no deberíamos asumir que no hay ninguna razón para el formato inusual). WhatamIdoing ( discusión ) 00:48, 6 de octubre de 2024 (UTC) [ responder ]
@ Xaosflux : No creo que el equipo de software haya revisado ninguno de los informes en un tiempo. Parece que la mayor parte de la tarea se la dejó a la comunidad. Hicieron algunas al comienzo de la versión beta del modo oscuro, pero como las características más importantes se habían solucionado, las plantillas y páginas más pequeñas se dejaron en manos de la comunidad. — Matrix(!) { usuario - discusión? - contribuciones inútiles } 09:35, 6 de octubre de 2024 (UTC) [ responder ]
Estoy de acuerdo en que los informes de todas las wikis deberían terminar en un lugar centralizado para que los desarrolladores solo tengan que consultar una wiki, pero no estoy tan seguro sobre los íconos de estado. Los desarrolladores deben poder leer inglés para entender los informes, así que ¿no puede estar su estado también en inglés? Phil Bridger ( discusión ) 11:07 6 oct 2024 (UTC) [ responder ]
El modo oscuro no es solo para Wikipedia en inglés, por lo que archivar la página en la wiki de Mediawiki y hacer que las comunidades de todas las demás wikis vengan a Wikipedia en inglés para realizar informes no es lo ideal. isaacl ( discusión ) 01:37, 6 de octubre de 2024 (UTC) [ responder ]
@Isaacl si cambiamos el enlace del informe aquí, solo sería para los usuarios de enwiki: cualquiera en los cientos de otros proyectos seguiría yendo a mediawikiwiki a menos que su proyecto también anule el valor predeterminado. — xaosflux Talk 02:33, 6 de octubre de 2024 (UTC) [ responder ]
Estaba respondiendo a la sugerencia de archivar la página wiki de Mediawiki. isaacl ( discusión ) 02:44, 6 de octubre de 2024 (UTC) [ respuesta ]
Ah, vale, bueno, esa no es una decisión que se pueda tomar aquí. — xaosflux Talk 11:36, 6 de octubre de 2024 (UTC) [ responder ]
@Isaacl: Parece que no has entendido bien la propuesta. Podemos archivar solo esta página, no necesitamos archivar todo para cada sitio. — Matrix(!) { usuario - discusión? - contribuciones inútiles } 09:37, 6 de octubre de 2024 (UTC) [ responder ]
Eso es realmente secundario, pero seguro que si van a otro lugar se podrían copiar y dejar una nota allí. — xaosflux Talk 11:44, 6 de octubre de 2024 (UTC) [ responder ]
Gracias por la aclaración. Estoy de acuerdo con los demás que han expresado su preferencia por una ubicación centralizada para los informes de errores. isaacl ( discusión ) 16:33, 6 de octubre de 2024 (UTC) [ responder ]
cc @ Jon (WMF) y SGrabarczuk (WMF) : quiénes son los miembros del equipo web de WMF. SCP -20 00 10:38, 6 octubre 2024 (UTC) [ responder ]
Un ejemplo de un proyecto que hace algo así es dewiki, véase w:de:Wikipedia:Dark Mode/Probleme para su página. — xaosflux Talk 11:44, 6 de octubre de 2024 (UTC) [ responder ]
Recuerdo la implementación inicial del editor visual, donde algunos editores (incluido al menos un empleado de WMF) dedicaron mucho tiempo y esfuerzo a traducir los informes de los usuarios que se dejaban en una página de en.wp en tickets de phabricator, a menudo después de más pruebas para verificar los informes y brindar detalles más útiles a los desarrolladores. No estoy involucrado en absoluto en el modo oscuro (y personalmente no lo uso), pero si hay voluntarios para hacer algo similar, entonces dar a las personas la opción de informar localmente y copiar esos informes podría funcionar. Thryduulf ( discusión ) 17:12, 6 de octubre de 2024 (UTC) [ responder ]
Esta es una situación fundamentalmente diferente en el sentido de que, mientras que cualquier problema con el Editor visual generalmente se manifestaría en todas partes, sin importar qué instalación informó el problema, con los problemas del modo oscuro la abrumadora mayoría de los casos se solucionan haciendo cambios de contenido local (a un artículo o plantilla específicos). Un porcentaje minúsculo de los problemas informados son de alguna manera generalizables más allá del contexto inmediato del informe inicial. (Por lo tanto, estoy de acuerdo, es un poco extraño exfiltrar los informes a una wiki diferente en primer lugar; los problemas con el contenido local, que son estos, deben ser, y en última instancia terminarán siendo, manejados localmente). FeRDNYC ( discusión ) 20:38, 6 de octubre de 2024 (UTC) [ responder ]
Hola a todos. Quería dar una respuesta rápida desde la perspectiva del equipo. En resumen, esto depende totalmente de lo que la comunidad considere más fácil o más cómodo. Inicialmente, habíamos configurado el sistema para que fuera más centralizado, ya que no queríamos presumir qué página local le resultaría más cómoda a cada wiki. Dicho esto, no tenemos problemas con que los wikis realicen el cambio a una página local si así lo prefieren, y hasta ahora algunos wikis han optado por hacerlo con buenos resultados. Hay más información sobre cómo hacer esto disponible en la parte superior de nuestra página de informes generales. ¡Espero que esto sea útil! OVasileva (WMF) ( discusión ) 19:47, 8 de octubre de 2024 (UTC) [ responder ]
Gracias por aclarar que esto está bien para el equipo de desarrollo, comenzaré una sección de encuesta ahora para verificar el consenso de la comunidad. — Matrix(!) ping uno al responder { usuario - ¿discusión? - contribuciones inútiles } 16:19, 9 de octubre de 2024 (UTC) [ responder ]
Encuesta (informes en modo oscuro)
Tras la respuesta de WMF, creo que sería una buena idea hacer una encuesta para comprobar si queremos seguir adelante. @ Xaosflux , FeRDNYC , SCP-2000 , Isaacl, Phil Bridger , WhatamIdoing y Thryduulf : y cualquier otra persona, por favor indiquen brevemente su posición:
Apoyo como proponente: La mayoría de las personas que actualmente se ocupan de los problemas del modo oscuro no son desarrolladores de WMF, sino voluntarios. Los problemas del modo oscuro son un problema local según FeRDNYC y, por lo tanto, se deben manejar localmente en esta wiki para obtener mejores resultados. También podemos cambiar el sistema a algo mejor en el proceso (incluidas las firmas, el uso de plantillas de archivo en lugar de emojis, etc.). — Matrix(!) ping one when replying { user - talk? - useless contributes } 16:28, 9 de octubre de 2024 (UTC) [ reply ]
@Matrix , ¿tienes pensado mirar la página y resolver los problemas? Yo no. WhatamIdoing ( discusión ) 17:02 9 oct 2024 (UTC ) [ responder ]
En ese caso, me remito a lo que creas que será funcional para ti o para cualquier otra persona que haga el trabajo. Si el volumen es lo suficientemente bajo (¿una nota por semana?), entonces volver a señalar el enlace a Wikipedia:Bomba de agua (técnica) podría ser mejor que crear una página nueva. WhatamIdoing ( discusión ) 17:24 9 oct 2024 (UTC) [ responder ]
Son más bien 3 o 4 por día. Suena como si diferirlo a VPT causara problemas. — Matrix(!) ping one when replying { usuario - ¿ discusión? - contribuciones inútiles } 20:38, 9 de octubre de 2024 (UTC) [ responder ]
Soy completamente neutral en este tema, comento aquí solo porque me hicieron ping. Thryduulf ( discusión ) 17:04, 9 de octubre de 2024 (UTC) [ responder ]
Oponerme No le veo el sentido: esto implica dedicar mucho esfuerzo a arreglar algo que en realidad no está roto. *Pppery* ya ha empezado... 15:11, 12 de octubre de 2024 (UTC) [ responder ]
@ Pppery : Sin embargo, está roto: la página no tiene archivo, no hay firmas, por lo que responder es lento, el sistema actual de emojis para responder a los problemas es deficiente y está oculto en una ubicación oscura, por lo que nadie puede encontrarlo para ayudar a solucionar los problemas. Además, como no hay firmas, es una pesadilla perseguir a la gente para obtener más detalles de los problemas. ¿Qué parte de eso no está rota? — Matrix(!) ping one when replying { user - talk? - useless contributes } 11:35, 13 de octubre de 2024 (UTC) [ reply ]
No estoy convencido de que valga la pena inventar una nueva rueda por ninguno de ellos: el sistema no está roto en el sentido de que se estén informando y solucionando los problemas. *Pppery* ha comenzado... 16:19, 17 de octubre de 2024 (UTC) [ responder ]
El hecho de que los problemas se estén solucionando no significa que se esté haciendo de manera eficiente. El sistema actual es muy ineficiente, incluso si se están solucionando los problemas. Sigue generando mucha fricción que impide que los nuevos usuarios solucionen los problemas. — Matrix(!) ping one when replying { user - talk? - useless contributes } 18:19, 17 de octubre de 2024 (UTC) [ reply ]
Implementación
De acuerdo, el consenso es que las personas que solucionan los problemas del modo oscuro pueden decidir la ubicación , y FeRDNYC también ha expresado los problemas actuales con el sistema actual. Los problemas del modo oscuro suelen ser, en última instancia, un problema local, y WMF también ha dicho que esto es técnicamente posible. Tendríamos que hacer algunas cosas:
Importar la página de MediaWiki a enwiki con las opciones "Copiar todas las revisiones de esta página" y "Asignar ediciones a usuarios locales donde el usuario mencionado existe localmente" (esto es importante para archivar más tarde).
Creo que podemos empezar a trabajar en esto.
— Matrix(!) ping uno al responder { usuario - ¿ discusión? - contribuciones inútiles } 08:57, 12 de octubre de 2024 (UTC) [ responder ]
Estoy bien con hacer la importación de transwiki para esto cuando esté listo, pero no veo un consenso en la discusión anterior todavía. La parte de "asignar local" no es necesaria; dudo que a alguien en mwwiki le importe esa página, no vamos a eliminar nada allí, pero podemos simplemente ponerle una redirección entre wikis. ¿Y ahora qué? Alguien que no haya votado en esto debería eventualmente cerrar esta discusión con un resultado. Para la parte de xmlimport, no dudes en avisarme en ese momento. — xaosflux Talk 11:43, 13 de octubre de 2024 (UTC) [ responder ]
Está bien. Esperaré a que se llegue a un consenso (me puse impaciente porque nadie participó). — Matrix(!) ping one when replying { usuario - ¿discusión? - contribuciones inútiles } 11:49, 13 de octubre de 2024 (UTC) [ responder ]
Sorteo para permisos elevados
Propuesta de prueba: asignación a un pequeño grupo aleatorio de editores de permisos elevados por un período corto fijo mediante sorteo .
Prueba 1: los editores confirmados con extensión seleccionados , que han editado en los últimos 100 días, obtienen AfC y/o un revisor de página nueva, que tienen trabajos atrasados. Aún tienen que leer las instrucciones. (La PCR es demasiado débil para un experimento práctico en mi opinión).
Prueba 2: Los editores auto/confirmados seleccionados , que editaron recientemente, pasan a la versión con confirmación extendida.
Reglas: Cualquier administrador puede hacer un strike por cualquier comportamiento en cualquier momento; un strike y estás fuera; no hay extensión de plazo; sin excepciones. Además: no puedes rechazar permisos, y tu historial de edición o sanciones (pero no el historial de bloqueos) no tiene ninguna influencia en si obtienes o no permisos. Cada administrador y editor con los mismos permisos capaces de supervisar tendrá una lista de editores de prueba a la que podrá acceder fácilmente. (No es difícil deducir lo contrario).
Números: Como estimación conservadora para un primer experimento, quizás 200 editores en ambas pruebas simultáneamente durante 6 meses, dependiendo del nivel de actividad de aquellos en la muestra; si 20 editores aumentan sustancialmente su actividad en respuesta, eso es medible y manejable.
El objetivo es aumentar la participación de editores activos en todo el espectro y quizás incluso motivar solicitudes de permisos permanentes y administración en el futuro. En ese sentido, si un editor de prueba pierde permisos en la regla de un solo intento, esto debería tener una influencia mínima o nula en la solicitud de permisos en el futuro. Esta es una experiencia de aprendizaje y motivación. El hecho de que los permisos aquí sean en última instancia reversibles y estén sujetos a supervisión significa que, en general, si un editor mal portado ahora termina siendo capaz de solicitar permisos de manera creíble en el futuro, este modelo, en caso de que sea causal, fue de hecho un éxito.
Investigación, beneficios y precauciones
La literatura sobre el sorteo aborda tanto cuestiones que no tienen ninguna relación con la gobernanza de la WP como cuestiones que son bastante importantes. Además, creo que existen cuestiones exclusivas de la WP que el sorteo puede abordar y que la literatura aún no ha abordado. Reseña: (TG Bouricius 2013 "Democracia a través del sorteo multicuerpo: lecciones atenienses para la época moderna").
Lo que se propone se denomina gobernanza parcial por sorteo con rotación y mandato (Owen y Smith 2018 "Sorteo, rotación y mandato"). Beneficios conocidos y posibles y precauciones:
Es más probable que la selección aleatoria proporcione representación demográfica e ideológica (Ebadian et al 2022 "¿El sorteo es representativo y justo?"). Si bien los editores de WP no son representativos de la población general, nuestra administración es aún menos representativa (en Corple 2016 "Más allá de la brecha de género", pág. 25: 6 % frente a 15 %+).
Una alta barrera de entrada para la administración de WP y algunos permisos, combinada con la ingratitud de las tareas y un prestigio social relativamente bajo, significa que probablemente estemos por debajo de la tasa de reemplazo en la administración, y hay retrasos en las áreas que necesitan permisos. El sorteo, si resulta en participación, alivia esta carga. También aumenta la equidad representativa y la diversidad ideológica para aquellos que se encargarían de los retrasos en el contenido y administrativos. (Hasta donde yo sé, este es un problema exclusivo de WP). En la Wikipedia en polaco se estudió el efecto de exclusión en los nuevos candidatos de conocimiento entre los administradores (Spychała et al 2014 "¿La comunidad de administradores ... relación de conocimiento?"); por lo que si existe un fenómeno similar en todos los permisos, entonces el sorteo ayudaría a interrumpirlo.
Si hay corrupción administrativa (y algunos editores así lo han afirmado), se sugiere el sorteo para reducirla (Bagg 2024 "El sorteo como anticorrupción"). También es potencialmente un control contra la subversión administrativa (Sutherland 2011 "Lo que el sorteo puede y no puede hacer") por parte de camarillas de editores, como se expuso recientemente en la Wikipedia en croata .
Sobre los efectos de conceder privilegios/poder: En (Sassenberg et al 2014 "El poder corrompe: revisitado"), la relación entre el poder elevado y un sentido de responsabilidad comunitaria frente a la corrupción individual (ya sea que uno sea elevado en oposición al otro) es compleja con resultados contradictorios en la literatura. En general, si las personas están en un entorno y objetivos orientados socialmente, lo que yo sugeriría que ejemplifica la edición de WP, entonces el poder las orientaría hacia lo primero. Sin embargo, la revisión también sugiere que la percepción del poder como un aumento de oportunidades o promoción, en lugar de solo una mayor responsabilidad, es una gran parte de los mayores efectos motivacionales, lo que sugeriría que, dado que el sorteo puede reducir el prestigio de los privilegios elevados, tendría un efecto negativo en la motivación; pero esto parece nuevamente muy dependiente del contexto social y de los objetivos en la literatura.
Mi breve paseo por la literatura sugirió posibles rutas para futuras investigaciones sobre WP; para más información sobre poder y motivación, Pappas APA 2021; y en particular, podríamos esforzarnos por aumentar el prestigio social de los privilegios elevados en WP, así como sus responsabilidades sociales asociadas, según documentos de gestión como (Friedrichs 2023 "Los beneficios de la motivación de poder prosocial en el liderazgo"). Además, si bien es tentador considerar, si este experimento tiene éxito, una propuesta radical de sorteo futuro de administradores, similar al administrador por un día propuesto en 2012 , pero según WMF esto no es legalmente factible , ya que los privilegios prohibitivos son la reversión y el material eliminado . SamuelRiv ( discusión ) 22:39, 7 de octubre de 2024 (UTC) [ responder ]
Me cuesta imaginar que nosotros (es decir, aquellos de nosotros que hemos alcanzado cierto grado de poder y control en el sistema actual) estemos dispuestos a ceder el control sobre los permisos, por mínimos que estos puedan ser.
Dicho esto, creo que tanto la Prueba 1 como la Prueba 2 serían experimentos que valdrían la pena, y sugiero específicamente considerar seleccionar candidatos para la Prueba 2 entre aquellos que de todos modos están casi en EXTCONF (por ejemplo, tienen el tiempo pero les faltan 100 a 200 ediciones, o tienen las ediciones, pero les faltan 1 a 2 meses).
En cuanto al tamaño del experimento, eso realmente debería determinarse mediante un análisis de potencia (estadística) . WhatamIdoing ( discusión ) 17:22 9 oct 2024 (UTC) [ responder ]
Aunque tengan un elemento de poder y estatus, la gran mayoría de lo que hacen las personas con permisos avanzados es simplemente trabajo pesado. Me parece muy improbable que alguien asignado aleatoriamente como NPP o incluso como administrador realmente quiera usarlos. Y una de las principales funciones del sistema de permisos es reducir la superficie de ataque que ofrecen estos derechos al otorgarlos únicamente a personas lo suficientemente motivadas como para solicitarlos.
Además, sí, AfC y NPP tienen retrasos, pero "revisar a los revisores" también es trabajo y hay muy pocos administradores que lo hagan. Esto aumentaría enormemente esa carga de trabajo: ¿quién va a hacerse cargo de los revisores? – Joe ( discusión ) 17:58, 9 de octubre de 2024 (UTC) [ responder ]
Me imagino que un editor que recibe una nota que dice algo como "Se le ha otorgado este permiso temporalmente. Por favor, léalo y úselo si lo desea" podría usarlo algunas veces, al menos para probarlo. Si tiene una experiencia positiva, podría solicitar el permiso más adelante a través de los canales habituales.
Dar permiso solo a aquellos que están lo suficientemente motivados para pedirlo significa que un porcentaje mayor de los solicitantes están motivados indebidamente. Los editores pagos no declarados estarán más motivados a pedir permiso que un voluntario común. WhatamIdoing ( discusión ) 18:20 9 oct 2024 (UTC) [ responder ]
Creo que "verificar si la gente hizo lo correcto" y "hacer lo que se debe hacer" son acciones realmente diferentes. Por lo tanto, si bien creo que es obvio que esto aumentaría la cantidad de trabajo de "verificarse mutuamente", no estoy seguro de que sean los administradores de AfC y NPP los que asuman ese trabajo, aunque estoy seguro de que probablemente lo haríamos de manera un tanto desproporcionada. -- asilvering ( discusión ) 21:44, 25 de octubre de 2024 (UTC) [ responder ]
Soy un gran partidario del sorteo para cubrir puestos en el mundo real, tanto en los países en los que se utiliza (principalmente para seleccionar jurados) como para otros puestos. Algunas reflexiones sobre su aplicabilidad en Wikipedia:
Dudo que mucha gente dedique mucho tiempo a esa tarea, porque tienen que ganarse la vida y pagar a las personas seleccionadas causaría muchos otros problemas.
Muchas personas probarían sus nuevos permisos, pero la mayoría los abandonarían.
Deben existir criterios claros de éxito o fracaso. Se prueban demasiadas cosas y luego fracasan claramente, pero se siguen usando debido a la falacia del costo hundido (sé que esto es controvertido, pero yo clasificaría el espacio de draft como uno de ellos).
Estoy seguro de que podría aportar muchos más argumentos, tanto a favor como en contra, pero ya me tengo que ir. Phil Bridger ( discusión ) 19:49 9 oct 2024 (UTC) [ responder ]
Es muy conveniente contar con criterios claros. Lamentablemente, no estoy seguro de que una única métrica funcione (por ejemplo, no queremos perder a estos editores seleccionados al azar y no queremos artículos de WP:UGLY en el espacio principal), y es totalmente posible que hacer el trabajo correctamente dé como resultado que los editores seleccionados abandonen el sitio. Por ejemplo:
Las promociones actuales de AFC tienen una tasa de eliminación muy baja en AFD. (Creo que la tasa normal es de alrededor del 75%). Dado que se supone que deben promover artículos que tienen probabilidades (es decir, el 51 %, no el 90 %) de sobrevivir a AFD, esto significa que están promoviendo poco y restringiendo demasiado.
Si los nuevos miembros de AFC promueven colectivamente artículos que se eliminan solo el 40 % de las veces, eso es una señal de que lo están haciendo correctamente (de hecho, siguen haciendo una promoción insuficiente), aunque los suyos se eliminen con más frecuencia que los miembros antiguos de AFC. Esta métrica de AFD mostraría el éxito.
Pero si cada AFD, o el período previo a esa AFD, viene acompañado de recriminaciones y quejas sobre lo "indulgentes" que son, entonces los editores a los que se les grita podría renunciar. La métrica de retención de editores mostraría un fracaso.
Si obtenemos resultados mixtos, ¿qué debemos hacer? WhatamIdoing ( discusión ) 21:50 9 oct 2024 (UTC) [ responder ]
Si la nueva gente de AFC promueve colectivamente artículos que se eliminan solo el 40% de las veces, eso es una señal de que lo están haciendo correctamente (en realidad, siguen haciendo una promoción insuficiente).No necesariamente. Si promocionan artículos con una probabilidad de sobrevivir a AfD superior al 50%, y suponemos que están distribuidos uniformemente en probabilidad, el artículo promocionado promedio tendría un 75% de probabilidad de sobrevivir a AfD, o en otras palabras, sería eliminado el 25% de las veces. Si se elimina el 40% de las veces, podría haber un nivel de sobrepromoción en curso. Chaotic Enby ( discusión · contribs ) 16:38, 16 de octubre de 2024 (UTC) [ responder ]
(Me encanta la gente que sabe matemáticas.)
Creo que depende de tus suposiciones subyacentes sobre la distribución. Si tienes 10 artículos, cada uno con un 51% de posibilidades de sobrevivir a la AFD, y los promocionas todos, y los 10 se envían a la AFD, entonces esperarías que se eliminaran cinco, y todas seguían siendo promociones correctas. WhatamIdoing ( discusión ) 16:55 16 oct 2024 (UTC) [ responder ]
Eso depende definitivamente de nuestras hipótesis sobre la distribución, de hecho. Si los 10 artículos varían entre el 51%, 56%, ... hasta el 96%, entonces tendrías una expectativa menor de artículos eliminados (2,65 si no me equivoqué). Pero también hay una suposición oculta aquí, en el sentido de que un artículo con un 96% de posibilidades de sobrevivir a una AfD probablemente no será enviado allí para empezar, lo que significa que la tasa de eliminación de artículos enviados a AfD será naturalmente mayor que la tasa de eliminación total.En general, sería interesante tener más estadísticas sobre la probabilidad de eliminación de artículos de AfC en AfD y sobre la cantidad de artículos de AfC que están subrepresentados en AfD. Chaotic Enby ( discusión · contribuciones ) 18:18, 16 de octubre de 2024 (UTC) [ responder ]
Las estadísticas de eliminación son difíciles de medir retrospectivamente. Podría ser algo que debamos estudiar prospectivamente. También está la complicación de la experiencia: las personas que envían artículos a través de AFC no van a tener la misma tasa de eliminación que personas como tú y yo. WhatamIdoing ( discusión ) 18:51 16 oct 2024 (UTC) [ responder ]
Para complicar las cosas, no creo que la mayoría de los revisores de AfC se decidan por "50% de probabilidad de supervivencia de AfD" sino por "estoy más del 50% seguro de que esto sobreviviría a AfD" - no es exactamente lo mismo. Creo que soy uno de los revisores de AfC más indulgentes (bueno, de aquellos entre nosotros que no somos unos idiotas), y si el 25% de mis aceptaciones fueran para AfD me sorprendería. Además creo que la gente me estaría diciendo que renuncie. -- asilvering ( discusión ) 21:42, 25 de octubre de 2024 (UTC) [ responder ]
Sospecho que tienes razón. El simple hecho de enviar a la AFD más de un pequeño número de artículos, incluso si al final se los conservara todos, levantaría algunas sospechas. WhatamIdoing ( discusión ) 22:26 25 oct 2024 (UTC) [ responder ]
También, si bien es tentador considerar, si este experimento tiene éxito, una propuesta radical de sorteo de administradores en el futuro, similar al administrador por un día propuesto en 2012, pero según la WMF esto no es legalmente factible, los privilegios prohibitivos son la reversión y el material eliminado. Eso no necesariamente tiene que impedirlo; la WMF no establece un límite real para la revisión de la comunidad. Por lo tanto, podríamos tener una revisión de la comunidad con mucha menos presión y menos riesgos de cada editor que cumpla con un cierto umbral de ediciones y edad para determinar la elegibilidad para un día para obtener esos derechos a través del sorteo, con el único enfoque en "¿es probable que esta persona abuse de la reversión o el acceso al material eliminado?" (lo que casi siempre se inclinaría hacia la aceptación, ya que es automático, se hace para todos y no otorga directamente la administración). Solo se permitirían y considerarían los argumentos y fundamentos específicamente relacionados con esa pregunta al cerrar dichas discusiones, no discusiones generales sobre si serían buenos administradores de otras maneras; y no requerirían cierres de bcrat ni nada por el estilo. Esto permitiría que se otorgara el estado de administrador a esos editores mediante sorteo porque previamente habían pasado una revisión de la comunidad sobre los aspectos que le interesan a la WMF. -- Aquillion ( discusión ) 19:12, 16 de octubre de 2024 (UTC) [ responder ]
Los privilegios prohibitivos son rollback y . Rollback no parece muy peligroso. Dudo que WMF se ponga firme a la hora de conceder ese privilegio con demasiada facilidad. Estoy de acuerdo en que WMF se opondría a conceder view removed por razones legales. Esto ya se ha discutido antes. – Novem Linguae ( discusión ) 19:19, 16 de octubre de 2024 (UTC) [ responder ]
No creo que a la WMF le importe Wikipedia:Rollback (que ni siquiera se usa mucho, porque Twinkle y otros scripts pueden imitar el mismo efecto). El problema legal es que viewdeletedsiempre han dicho que quieren pruebas de que la comunidad confía en las personas que tienen ese derecho en particular (por ejemplo, confiamos en que no restaurarán los copyvios ni volverán a publicar pornografía vengativa subida a otro sitio). El proceso de verificación de la comunidad puede cambiar, pero debe haber un proceso de verificación de la comunidad. WhatamIdoing ( discusión ) 19:43, 16 de octubre de 2024 (UTC) [ responder ]
(por ejemplo, confiamos en que no restaurarán los copyvios ni volverán a publicar pornografía de venganza subida a otro sitio) . Nunca he oído eso. La razón declarada por WMF para que viewdeleted sea sensible es que quieren poder decir en la corte que cuando se elimina algo, está bien y verdaderamente eliminado, y que solo las personas investigadas tendrán acceso a él, en lugar de que sea fácilmente accesible. La sensación que me da es que hay que asegurarse de que BLP, difamación y calumnia, etc. permanezcan eliminados y que puedan argumentar que realmente se eliminaron en la corte. – Novem Linguae ( discusión ) 20:40, 16 de octubre de 2024 (UTC) [ responder ]
Si alguien restaura contenido inapropiado aquí o lo publica en otros sitios web, eso no se considera "borrado", y nadie podría negarlo, ni siquiera en la mesa. Debemos poder confiar en que los administradores no lo harán. WhatamIdoing ( discusión ) 21:59 16 oct 2024 (UTC) [ responder ]
De cualquier manera, sin embargo, mi punto es que podemos tener un proceso de investigación más ligero enfocado específica y exclusivamente en si alguien es propenso a abusar de las herramientas específicas que preocupan a la WMF. Siempre que surgen enfoques alternativos a la administración, la gente plantea esa preocupación de la WMF, y se aborda fácilmente. La WMF no está preocupada por la gente que abusa de los bloqueos, o desbloqueos, o que interviene en WP:AE , o acciones de cumplimiento de AE; y el alto riesgo (percibido, al menos) asociado con esas cosas bajo el sistema actual es lo que realmente hace que la gente sea reacia a promover a los administradores y lo que, por lo tanto, dificulta las RFA . Esto también se perpetúa a sí mismo en el sentido de que cuantos menos administradores haya, más impacto tendrá cada uno, lo que aumenta las apuestas de la RFA de una manera que corre el riesgo de romperla. La comunidad y la WMF están preocupadas por diferentes cosas. -- Aquillion ( discusión ) 22:34, 16 de octubre de 2024 (UTC) [ responder ]
Estoy de acuerdo. Este es un problema solucionable. Además, no tiene por qué resolverse en la primera iteración. Podríamos probar el sistema con un par de derechos de usuario más y volver a probar otros más tarde. WhatamIdoing ( discusión ) 23:09 16 oct 2024 (UTC) [ responder ]
¿No se debería pasar por alto la pornografía vengativa y demás , y no solo eliminarla? jlwoodwa ( discusión ) 04:57 17 oct 2024 (UTC) [ responder ]
Sí, pero los administradores suelen revelar los problemas graves primero, antes de informar a los supervisores. (Además, eso no suele cargarse localmente). WhatamIdoing ( discusión ) 05:02, 17 de octubre de 2024 (UTC) [ responder ]
A WMF no le importan las reversiones. Incluso podríamos promocionar automáticamente a los usuarios a un grupo de "que ya lleva tiempo en activo" que incluya a todos los que han sido controlados automáticamente, los revisores de páginas nuevas, los que han movido páginas, los revisores de cambios pendientes y los que han realizado reversiones, y no les importaría. — xaosflux Talk 13:53, 17 de octubre de 2024 (UTC) [ responder ]
Honestamente, al menos cuando se trata de NPP/AfC, estoy de acuerdo. -- asilvering ( discusión ) 21:46, 25 de octubre de 2024 (UTC) [ responder ]
En el caso de esos dos en particular, creo que una métrica que vale la pena verificar es si alguien solicita el permiso de forma permanente después. WhatamIdoing ( discusión ) 22:27 25 oct 2024 (UTC) [ responder ]
Me sentiría tentado a hacerlo un poco al revés: ir a preguntarles a los editores cuyos permisos de sorteo están a punto de expirar si quieren que se los quiten, y dejarlo en caso contrario, siempre y cuando lo usen sin interrumpir el orden. -- asilvering ( discusión ) 22:32, 25 de octubre de 2024 (UTC) [ responder ]
Creo que la idea de los permisos temporales es que no se puede construir un feudo. Se hace el trabajo durante un período de tiempo determinado y luego llega el turno de otra persona, que se encarga de hacer lo mejor que puede. WhatamIdoing ( discusión ) 02:13 26 oct 2024 (UTC) [ responder ]
Rediseño de grilletes y otros iconos
Retomando esta propuesta , quiero que los íconos se vean más claros y elegantes; eventualmente agregaré más a los íconos (como buenos artículos, artículos de audio, etc.) También quiero agregar grilletes de letras basados en la región, por lo que, por ejemplo, 拡 (拡張, Kakuchō) sería el ícono de protección extendida japonés, lo mismo con 満 (満杯, Manpai) para protección completa.
Petición de nuevos iconos para Wikipedia. (Disponible para todos)
por 2I3I3 ( discusión ) 16:25 16 oct 2024 (UTC) [ responder ]
Estoy de acuerdo con otros en que estos nuevos íconos parecen anticuados. Sin embargo, si estamos hablando de cambios en los íconos de bloqueo, entonces debo decir que el morado para carga protegida es incongruentemente llamativo. Cremastra — discusión — c 20:23, 17 de octubre de 2024 (UTC) [ responder ]
Oposición. Creo que los degradados o biseles hacen que estos íconos sean menos claros y elegantes, al menos en su versión actual. Los íconos también se vuelven menos legibles en resoluciones más pequeñas, ya que la parte del grillete de los candados ocupa más espacio, lo que hace que el símbolo real en el interior sea más pequeño.
Quién sabe, parece que el diseño gráfico se está alejando poco a poco del diseño plano, así que tal vez en unos años... quidama talk 22:19, 23 de octubre de 2024 (UTC) [ responder ]
Me opongo firmemente a intentar ejecutar un script de geolocalización en cada carga para intentar crear etiquetas dinámicas aquí. En todo caso (lo cual tampoco me gusta), las etiquetas deberían seguir el lenguaje de la interfaz de usuario. — xaosflux Talk 17:39, 16 de octubre de 2024 (UTC) [ responder ]
Entiendo las diferencias, solo estaba sugiriendo (porque realmente no hablo ningún otro idioma, podrías proponer una versión específica). Además, más adelante agregaré las letras en los grilletes.
por 2I3I3 ( discusión ) 19:16 16 oct 2024 (UTC) [ responder ]
y los iconos* 2I3I3 ( discusión ) 19:16 16 oct 2024 (UTC) [ responder ]
Los formatos de archivo SVG se pueden traducir. Consulte c:Commons:Translation possible/Learn more. WhatamIdoing ( discusión ) 23:33 16 oct 2024 (UTC) [ responder ]
Opóngase a que la diferenciación primaria (única) sea el color, ya que eso brinda menos información que el esquema actual y es inútil para quienes no tienen habilidades para ver el color. — xaosflux Talk 17:41, 16 de octubre de 2024 (UTC) [ responder ]
Estoy de acuerdo con Xaosflux en este punto. Además, los dos problemas del antiguo esquema de iconos (color y sombreado "realista" que no se ve muy bien en iconos pequeños), que fueron las razones del cambio inicial, también están presentes en este.En cuanto a los símbolos basados en regiones, tendría más sentido mostrarlos en función de la edición del idioma y, dado que cada edición del idioma ya establece sus propios estándares para este tema, no hay mucho más que podamos hacer. Chaotic Enby ( discusión · contribuciones ) 18:13, 16 de octubre de 2024 (UTC) [ responder ]
Estoy de acuerdo , pero solo un poco. Si agregaras las letras, sería mejor. Además, una solución para tu clasificación por regiones podría ser hacer una clasificación por idioma (como "O" de "Oficina" se convertiría en "S" de "Escuela" en un "inglés invertido" teórico). The Master of Hedgehogs ( converse ) ( erizos ) 14:33, 17 de octubre de 2024 (UTC) [ responder ]
¿Esos iconos/colores funcionarán con el modo oscuro? También estoy de acuerdo en que las letras son esenciales. Thryduulf ( discusión ) 14:44 17 oct 2024 (UTC) [ responder ]
Véase también Grillete . Son candados y la parte superior en forma de U es el grillete. WhatamIdoing ( discusión ) 20:22 17 oct 2024 (UTC) [ responder ]
Otra solución más en busca de un problema. *Pppery* ha comenzado... 16:18, 17 de octubre de 2024 (UTC) [ responder ]
Según WP:WIKICLICHE, nos han pedido que no digamos esto tanto, debido a problemas con la cadena de suministro: si los usamos demasiado, podríamos ver una gran escasez en el futuro. Pero espero podernoGenerar más calor que luz con este comentario, o tirar al bebé junto con el agua de la bañera. Cremastra — discusión — c 20:22, 17 de octubre de 2024 (UTC) [ responder ]
Nunca tires al bebé junto con el agua del baño. Esto contaminará tu sistema de recolección de aguas grises. Al igual que otras carnes, los bebés no son compostables, por lo que deben clasificarse en el flujo de desechos del vertedero a menos que la autoridad de gestión de residuos municipal indique lo contrario. Folly Mox ( discusión ) Folly Mox ( discusión ) 20:46 17 oct 2024 (UTC) [ responder ]
¿El agua del baño es la misma a la que se supone que debo llevar a este caballo? Remsense ‥ 论21:40, 17 de octubre de 2024 (UTC) [ responder ]
Tal vez esté debajo de un puente, eso explicaría todo este problema. jlwoodwa ( discusión ) 01:14 19 oct 2024 (UTC) [ responder ]
El sombreado pseudo-3D parece anticuado en comparación con los iconos planos actuales. La mayoría de los sistemas de diseño modernos (incluido Codex, que es el nuevo sistema de diseño para los wikis de Wikimedia) se basan en iconos planos. -- Ahecht ( PAGINA DE DISCUSION) 18:36, 17 de octubre de 2024 (UTC) [ responder ]
¿Qué pasa con los íconos como destacado, bueno y de audio? 2I3I3 ( discusión ) 18:55 17 oct 2024 (UTC) [ responder ]
Sólo para travesuraAún parece un paso atrás. El icono actual de "Buen artículo", además de tener un sombreado que distraiga menos y ser más legible, tiene un estilo coherente con muchos de nuestros otros iconos. El icono actual de "Artículo destacado", aunque no es coherente con los demás, es bastante único y reconocible en diseño, mientras que este parece una estrella genérica.Solo por diversión, una vez hice una estrella de "Buen artículo" al estilo de la de FA; no estaba destinada a ninguna implementación oficial más allá de mi script personal , por supuesto, pero es interesante ver cómo se vería. Chaotic Enby ( discusión · contribuciones ) 22:14, 17 de octubre de 2024 (UTC) [ responder ]
Lamentablemente, no se trata de mejoras visuales en absoluto. Son claras regresiones en el diseño, y los íconos actuales están bien. Nuestro sistema es específico para la Wikipedia en inglés, por lo que es perfectamente apropiado que su diseño sea relativo al idioma inglés. Remsense ‥ 论19:29, 17 de octubre de 2024 (UTC) [ responder ]
Estoy desconcertado. Al empezar con Reinstalar esta propuesta , me haces pensar que quieres revitalizar alguna propuesta fallida. Pero luego sigo tu enlace y veo que la propuesta llevó a la implementación de nuevos íconos de candado, lo que; supongo, quieres decir revertir . Tampoco entiendo qué quieres decir con grilletes de letras basados en regiones ; ¿te refieres a artículos sobre , por ejemplo, Japón? ¿O artículos vistos por alguien que se supone que hemos adivinado que podría estar en Japón? ¿O alguien con el idioma japonés listado en un cuadro de usuario en su página de Usuario? Es Wikipedia en inglés, así que no puedo ver que las dos últimas sean opciones útiles, y la primera solo conducirá a discusiones y confusión y eso ya lo tenemos . Los íconos actuales me parecen bastante claros, aunque no sé cómo medir "elegante", supongo. En resumen: desconcertado . — JohnFromPinckney ( discusión / ediciones ) 12:15, 18 de octubre de 2024 (UTC) [ responder ]
Me refiero a que los grilletes de letras basados en regiones son básicamente como las letras de los grilletes pero con diferentes traducciones regionales. (Esto probablemente no funcionará debido a la publicación de @Chaotic Enby ).
por 2I3I3 ( discusión ) 18:36 18 oct 2024 (UTC) [ responder ]
Entonces (solo para ver si lo entiendo finalmente), estás proponiendo en la Wikipedia en inglés que la Wikipedia en japonés use íconos con simbología japonesa, y que la Wikipedia en español use algún indicador en español en el candado, etc. ¿Sí? — JohnFromPinckney ( discusión / ediciones ) 22:30 18 oct 2024 (UTC) [ responder ]
Por ahora, opónte. El status quo está bien. Sin embargo, es realmente genial que estés contribuyendo con tus habilidades gráficas al movimiento. Estoy seguro de que hay algunas áreas menos destacadas que realmente podrían beneficiarse de tus habilidades. – Novem Linguae ( discusión ) 03:55, 23 de octubre de 2024 (UTC) [ responder ]
Oposición : Las nuevas propuestas son agradables, pero a mí personalmente me gusta más el estilo de las antiguas, y los iconos planos también me parecen más actuales. Las cadenas regionales parecen una buena idea, pero no parecen estar en esta propuesta, así que diré que las apoyo (quizás en el estilo de diseño antiguo, según mi preferencia). Mrfoogles ( discusión ) 20:22 23 oct 2024 (UTC) [ responder ]
Me opongo a Remsense. Los nuevos íconos 3D parecen sacados de los primeros tiempos de Internet. Además, el sombreado hace que los íconos parezcan innecesariamente "voluminosos" (no estoy seguro de cómo decirlo). Nythar ( 💬 - 🍀 ) 22:33, 25 de octubre de 2024 (UTC) [ responder ]
También me opongo aquí. No se trata de un status quo ni de resistencia al cambio, prefiero ampliamente los íconos actuales a los reemplazos propuestos. (Admito que son subjetivos) Puntos a favor de los íconos actuales sobre los nuevos:
El aspecto más plano se verá mejor en tamaños pequeños (ya que estos íconos en realidad se muestran en una fracción del tamaño en que se muestran en este hilo).
Lo mismo ocurre con la fuente más cuadrada.
Lo mismo ocurre con los arcos de grillete más gruesos.
Los grilletes delgados y el cuerpo rectangular dan a los reemplazos propuestos la apariencia de bolsos, no de candados.
La colocación de las letras es más uniforme y precisa en los íconos actuales; los reemplazos propuestos parecen haber sido "elaborados a ojo". En mi humilde opinión, es mejor codificar a mano el arte SVG de este tipo (si no desde cero, al menos como una pasada de finalización para limpiar el código), con todas las dimensiones precisas y uniformes.
Aprecio el esfuerzo y lamento ser crítico, pero no me gustan en absoluto. El conjunto actual, por otra parte, está bastante bien diseñado y optimizado para su propósito, lo cual es una consideración importante al diseñar obras de arte funcionales de este tipo. Me resulta desconcertante que alguien quiera reemplazarlos, ya que, sorprendentemente, hay poco margen de mejora en mi humilde opinión. FeRDNYC ( discusión ) 13:19 26 oct 2024 (UTC) [ responder ]
Habilitar elecciones de SecurePoll con el derecho electionadmin
Seguimiento en la tarea T301180 de Phabricator
¡Hola! Mi nombre es Joe Sutherland y soy parte del equipo de Confianza y Seguridad de la Fundación Wikimedia. En el pasado, su comunidad ha mostrado interés en realizar elecciones con SecurePoll (quizás ya lo haya hecho a través de votewiki). Ahora estamos estudiando la posibilidad de poner esta opción a disposición de las comunidades locales para que realicen sus propias elecciones. Para ello, será necesario habilitar el derecho "electionadmin" en su proyecto, que es un derecho que permite el acceso a información confidencial.
Por lo tanto, es probable que deba realizar una solicitud de comentarios (o un proceso similar) para determinar el consenso sobre la implementación de esta función. Para ayudar a guiar dicho debate, hemos creado una página Meta-Wiki con más información sobre lo que significará para su comunidad habilitar este derecho.
Si su comunidad decide seguir adelante con este tema, T&S quisiera brindarle su apoyo. Por favor, infórmenos por correo electrónico ([email protected]) si se llega a un consenso. ¡Gracias!
PD: esto podría ser más adecuado para la bomba de la aldea técnica, así que siéntete libre de moverla allí si lo deseas. Joe Sutherland (WMF) ( discusión ) 20:07 17 oct 2024 (UTC) [ responder ]
Habilitación de soporte . Parece un paso superficial necesario para facilitar las elecciones de administrador que hemos llegado a un consenso para llevar a cabo . Es discutible si esta convocatoria de propuestas independiente es necesaria, pero creo que será más fácil simplemente llegar a un consenso que debatir si es necesaria. Sdkb talk 20:17, 17 de octubre de 2024 (UTC) [ responder ]
Lo siento, no fui del todo claro: esto sería para futuras elecciones (administración/ArbCom) que la comunidad quisiera llevar a cabo. Las elecciones programadas para comenzar pronto utilizarán el sistema de votación existente. Joe Sutherland (WMF) ( discusión ) 19:43 18 oct 2024 (UTC) [ responder ]
Apoyo . Este no es un requisito para las elecciones de administración, elecciones de arbcom (o cualquier otro tipo de elecciones) pero (si he entendido bien) reducirá la cantidad de apoyo que necesitamos de la WMF cuando las celebremos. Estoy completamente de acuerdo con la última frase de Sdkb. Thryduulf ( discusión ) 20:35 17 oct 2024 (UTC) [ responder ]
Soporte . Esto nos ayudaría a organizar elecciones de administradores locales y elecciones de comités de arbitraje que no dependan tanto del ancho de banda limitado de los administradores (escrutadores) y de WMF T&S (para la configuración de vote.wikimedia.org). Por cierto, ¿los administradores electorales son básicamente usuarios de verificación dentro de la herramienta SecurePoll (pudiendo ver la información de IP de los votantes)? Entonces, ¿deberíamos asegurarnos de que las personas que reciben ese permiso sean funcionarios y/o firmen un acuerdo de confidencialidad? – Novem Linguae ( discusión ) 20:35, 17 de octubre de 2024 (UTC) [ responder ]
PD: ¿Hay algún ticket en Phab para separar las capacidades de verificación de elecciones de las capacidades de creación y edición de elecciones? Podría valer la pena investigar esto. La persona que configura las encuestas no necesariamente tiene que ser la misma persona que verifica a todos los votantes. Y podría tener sentido tener una división aquí. Por ejemplo, alguien técnico puede configurar SecurePoll y los usuarios de verificación existentes podrían realizar el escrutinio. – Novem Linguae ( discusión ) 20:39, 17 de octubre de 2024 (UTC) [ responder ]
Investigué un poco y parece que cualquier administrador puede crear una encuesta, pero solo los administradores electorales (escrutadores) pueden editar una encuesta o ver datos similares a los de checkuser sobre los votantes. Esta división es un poco extraña, ya que creo que sería mejor si los administradores también pudieran editar las encuestas a las que se agregaron cuando se crearon, por lo que presenté phab:T377531 para explorar esa idea un poco más. – Novem Linguae ( discusión ) 23:56, 17 de octubre de 2024 (UTC) [ responder ]
Apoyo para ayudarnos a implementar las elecciones de administradores de una manera más práctica tanto para nosotros como para la WMF. Sin embargo, ¿los electionadmins serán un nuevo grupo de usuarios? Parecen combinar características de checkusers y burócratas, y no estoy seguro de si funcionaría agrupar el derecho en cualquiera de ellos de forma predeterminada. Por otro lado, la propuesta de Novem Linguae de dividir el derecho de usuario podría funcionar mejor, con un crat con mentalidad técnica configurando la encuesta, mientras que los checkusers realizan el derecho de escrutinio. Chaotic Enby ( discusión · contribs ) 22:20, 17 de octubre de 2024 (UTC) [ responder ]
Si leo bien el código... sí, electionadmin tendría que ser un nuevo grupo de usuarios o los permisos correspondientes (securepoll-create-poll, securepoll-view-voter-pii) se tendrían que agregar a un grupo de usuarios existente, como checkusers. Esto último podría ser más simple que crear un proceso de designación completamente nuevo para electionadmins.
A primera vista, no veo una relación entre burócratas y administradores electorales. Los administradores electorales no pueden otorgar ningún grupo de usuarios, a diferencia de los burócratas. Nuevamente, si leo bien el código, cualquier administrador puede crear una encuesta. – Novem Linguae ( discusión ) 00:01, 18 de octubre de 2024 (UTC) [ responder ]
En cuanto a la relación entre burócratas y administradores electorales, lo mejor es que el mismo grupo esté a cargo de las convocatorias de propuestas y las elecciones administrativas habituales, y que los usuarios de verificación no tengan esta responsabilidad adicional. Pero eso podría ser demasiado redundante y podría ser suficiente que cualquier administrador con conocimientos técnicos lo hiciera, aunque sería una responsabilidad importante para cualquier administrador y podría dificultar que los candidatos potenciales se ganen la confianza de los votantes. Chaotic Enby ( discusión · contribuciones ) 13:14, 18 de octubre de 2024 (UTC) [ responder ]
La bomba de la aldea técnica es para preguntas sobre cómo hacer X, mientras que la forma de otorgar el derecho electionadmin requiere una propuesta de política, por lo que esta página es el lugar apropiado. Dado que el derecho proporciona acceso a la información de los votantes (según meta: SecurePoll/Elecciones locales § ¿Qué hace el derecho electionadmin?), se necesita un proceso para establecer en quién se confía este acceso. Las opciones que se me ocurren son por consenso, por elección o por designación (lo que elevaría la pregunta a un nivel superior sobre cómo decidir qué grupo realiza la designación). Ser parte de un grupo de confianza existente, como aquellos con el derecho de supervisión o el derecho de verificación de usuario, podría ser un requisito para convertirse en administrador de elecciones. isaacl ( discusión ) 23:35, 17 de octubre de 2024 (UTC) [ responder ]
Tal vez lo más sencillo sea otorgar los permisos securepoll-create-poll y securepoll-view-voter-pii a los checkusers. De esa manera, no necesitamos la sobrecarga de un grupo de usuarios independiente o un proceso de designación independiente. Creo que el creador de la encuesta debe agregarte específicamente a una encuesta para ver su información de identificación personal, por lo que no debería haber ningún riesgo de seguridad al darles a todos los checkusers la capacidad de ser agregados a las encuestas por el creador de la encuesta. – Novem Linguae ( discusión ) 00:03, 18 de octubre de 2024 (UTC) [ responder ]
Esto parece un descuido importante. Las elecciones de administración se basan en WP:ACE , pero aparentemente nadie pensó en los escrutadores que deben ser aprobados y preparados cada año para ACE. Supongo que esto significa que las elecciones están en espera hasta que aclaremos esto. Solo aléjate de este mundo... hoy 00:15, 18 de octubre de 2024 (UTC) [ responder ]
No, creo que las elecciones de administración se llevarán a cabo utilizando el proceso antiguo (la votación se realizará en VoteWiki) y esto es solo una cuestión de futuro. * Pppery * ya comenzó... 00:20, 18 de octubre de 2024 (UTC) [ responder ]
Bueno, eso es un alivio. Ha sido un proceso tan prolongado para llegar hasta aquí que no puedo decir que haya seguido cada parte de él. Solo da un paso al costado y sal de este mundo... hoy 06:56, 18 de octubre de 2024 (UTC) [ responder ]
Soporte Si vamos a realizar elecciones administrativas periódicas, tiene sentido que la infraestructura sea local. Pinguinn 🐧 00:24, 18 de octubre de 2024 (UTC) [ responder ]
Localmente, tenemos algunas opciones que podríamos considerar si decidimos hacer encuestas. Primero, no TENEMOS que cifrar la base de datos, no hace que los votos estén disponibles fácilmente, pero un desarrollador podría acceder a ellos, por lo que es algo a considerar (también significa no tener que lidiar con el depósito de claves para finalizar la elección). Además, no tenemos que dejar que SP recopile información privada. Todavía tendríamos los nombres de usuario, solo evitaría el uso de la información de checkuser en las votaciones de securepoll. Todas estas son solo cosas a considerar si configuramos encuestas; el punto es que hay opciones. — xaosflux Talk 13:41, 18 de octubre de 2024 (UTC) [ responder ]
Las comunidades locales deberían tener autonomía para realizar elecciones cuando lo consideren oportuno y no depender tanto de un determinado equipo de la Fundación Mundial de la Música que tiene un calendario estricto. Además, la imposibilidad de realizar elecciones separadas en varios sitios al mismo tiempo es una gran limitación del sistema actual que se solucionaría con esto. – SD0001 ( discusión ) 08:55, 19 de octubre de 2024 (UTC) [ responder ]
Apoyo - Según SD y Xaos, creo que implementar SecurePoll localmente para que las comunidades individuales puedan llevar a cabo elecciones de manera autónoma y descentralizada a cambio de cierta confidencialidad es una buena idea en general. Sohom ( discusión ) 14:26 19 oct 2024 (UTC) [ responder ]
Apoyo Ya que le da a la comunidad una opción para futuras encuestas. Cómo se debe usar se puede explicar más adelante. -- LCU A ctivamente desinteresado « @ » ° ∆t ° 20:28, 19 de octubre de 2024 (UTC) [ responder ]
Apoyo Esto ayudará a que las elecciones se celebren con mayor frecuencia, lo que reducirá los gastos del personal de la WMF. Bunnypranav ( discusión ) 11:52 22 oct 2024 (UTC) [ responder ]
Apoyo Definitivamente será necesario un RFC para determinar quién puede ejercer de escrutador. Me imagino que tenemos algunas opciones, las dos primeras que se me ocurren son asignar al grupo CheckUser (¿o quizás a un conjunto diferente de usuarios?) el derecho electionadmin, o simplemente crear un nuevo grupo de usuarios y hacer que los Stewards se encarguen de asignarlo a los escrutadores pertinentes una semana antes de que se programe una SP, y luego eliminarlo después. EggRoll97 ( discusión ) 03:33, 23 de octubre de 2024 (UTC) [ responder ]
Apoyo He organizado elecciones de Wikimedia para organizaciones afiliadas y, después de probar procesos abiertos, he descubierto que el software comercial es la única opción práctica. La comunidad de Wikimedia ama los procesos democráticos y las elecciones, pero nunca ha tenido herramientas para respaldarlos. Hacer una opción para SecurePoll ha sido una solicitud de la comunidad desde al menos 2016, cuando se creó meta:SecurePoll. Bluerasberry (discusión) 15:05 26 oct 2024 (UTC) [ responder ]
Verificar error de Wiki que corrige el bot AWB
¡Hola a todos!
Yo, Bunnypranav , deseo crear un bot que intente corregir los errores de Check Wiki en las páginas afectadas. Por ahora, considero centrarme solo en el error n.° 3 de CW : falta la lista de referencias , pero más adelante estoy dispuesto a ampliar el tema a otros errores, especialmente los errores de alta prioridad que se pueden corregir automáticamente con AWB. La mayoría de mis ediciones de AWB corrigieron este error y no encontré ni una sola sugerencia incorrecta de AWB.
Tengo la intención de mantener activados el etiquetado automático y la corrección de errores en Regex, pero estoy dispuesto a desactivarlos si el consenso así lo dice.
Sé que hay un par de bots más que solucionan errores de Check Wiki ( Yobot , MenoBot ), pero creo que el proyecto podría funcionar con otro bot. Solicito a todos que den su opinión sobre mi propuesta y estoy dispuesto a aceptar cualquier comentario (incluso sobre mi disposición a ser operador de bot). Bunnypranav ( discusión ) 11:59 22 oct 2024 (UTC) [ responder ]
Creo que esto debería estar en WP:BRFA ? Thryduulf ( discusión ) 12:24 22 oct 2024 (UTC) [ responder ]
Sí. Además, existe una necesidad más amplia de distinguir mejor entre las tareas AWB GENFIX que son cosméticas y aquellas que vale la pena activar en cualquier momento. Sdkb talk 12:37, 22 de octubre de 2024 (UTC) [ responder ]
@ Thryduulf He publicado esto aquí para lograr un consenso sobre mi propuesta. Además, como algunos podrían verme, se puede considerar que no estoy listo para ser un bot op . Personalmente creo que soy capaz, pero por favor, den sus opiniones.
@ Sdkb Planeo habilitar la opción Saltar si solo es cosmético en AWB, para así omitir cualquier edición que sea solo cosmética, ya que se agregó la lista de referencias, pero CheckWiki informa que no se ha solucionado. Bunnypranav ( discusión ) 13:07, 22 de octubre de 2024 (UTC) [ responder ]
Revisé algunas de sus contribuciones para ver si existía un riesgo significativo de que "falta de referencia" significara "el vandalismo borra la mitad inferior del artículo", y no encontré evidencia de eso. Lo que encontré principalmente fue que los editores más nuevos agregaron la primera cita de Wikipedia:Inline a esos artículos. Es bastante alentador verlo, en realidad. WhatamIdoing ( discusión ) 17:40 23 oct 2024 (UTC) [ responder ]
Discusión enWikipedia:Editar filtro/Solicitado § Advertir sobre el uso de imágenes en línea
Tarea : Cuando una edición agrega un enlace de archivo sin "|(\s*)?frameless" o "|(\s*)?thumb" dentro, advertir al usuario y decirle que probablemente quería poner un |thumb. De todas formas, permitirle guardar la edición. También puede buscar todos los formatos admitidos si lo desea.
Necesita una discusión más amplia , pero hasta entonces, {{ EFR }} . La base de esta solicitud es la eliminación accidental de dos puntos. Esto parece más bien algo que podría plantearse en Phab, aunque sea por lo menos, pero no creo que necesitemos un filtro para advertir a la gente que use thumb. EggRoll97 ( discusión ) 23:52, 23 de octubre de 2024 (UTC) [ responder ]
Esto se creó como resultado de un tema de VPI y se vinculó a él, pero, por supuesto, ya lo notifiqué a VPR. Aaron Liu ( discusión ) 00:55, 24 de octubre de 2024 (UTC) [ responder ]
Desde VPR no estoy lo suficientemente seguro de cuáles son nuestros estándares para los filtros de edición como para poder opinar sobre la idoneidad de uno para esto, pero puedo decir que ciertamente he sido culpable de olvidarme de agregar thumby no previsualizar, lo que ha dado lugar a situaciones exactamente como la diferencia vinculada.
Si no se considera que esto sea apropiado para un filtro, sin duda deberíamos agregarlo a mw:Edit check/Ideas para que PPelberg (WMF) y otros puedan retomarlo. Saludos, Sdkb talk 01:17, 24 de octubre de 2024 (UTC) [ responder ]
Creo que la verificación de edición es un lugar mucho mejor para esto que los filtros de abuso que impiden que se guarde toda la edición. * Pppery * ha comenzado... 01:33, 24 de octubre de 2024 (UTC) [ responder ]
Los filtros de edición pueden advertir en el primer envío y permitir que se guarde en el segundo envío. Aaron Liu ( discusión ) 02:09, 24 de octubre de 2024 (UTC) [ responder ]
¡Parece una buena idea! Aaron Liu ( discusión ) 02:09 24 oct 2024 (UTC) [ responder ]
En realidad, no, no estoy seguro de si se aplica la comprobación de edición. Su página de proyecto lo define como un conjunto de mejoras para el editor visual , donde dudo mucho que los editores cometan este error. Aaron Liu ( discusión ) 02:19, 24 de octubre de 2024 (UTC) [ responder ]
Ah, es cierto, lo olvidé. En ese caso, sería conveniente un tipo de advertencia diferente, tal vez similar al enlace de desambiguación añadido. Sdkb talk 02:24, 24 de octubre de 2024 (UTC) [ responder ]
Eso requiere mucho más desarrollo que una expresión regular. Aaron Liu ( discusión ) 11:41 24 oct 2024 (UTC) [ responder ]
Podría ser una buena idea para la lista de deseos de la comunidad más que cualquier otra cosa. No creo que un filtro de edición sea realmente la mejor manera de proceder en este caso. Incluso en un sistema de advertencia, detectará ediciones de buena fe y ralentizará (temporalmente) estas contribuciones. Esto no quiere decir que no sea un problema, solo que los filtros de edición pueden no ser la mejor manera de resolverlo. EggRoll97 ( discusión ) 04:39, 25 de octubre de 2024 (UTC) [ responder ]
No veo ninguna razón de buena fe por la que alguien pueda querer usar una imagen en línea. Aaron Liu ( discusión ) 11:27 25 oct 2024 (UTC) [ responder ]
Técnicamente, muchas de las fórmulas de los artículos de matemáticas son imágenes en línea (véase, por ejemplo, series (matemáticas) ). Estas se generan en lugar de transcluirse, pero no me sorprendería que existiera algún caso extremo en el que una imagen se transcluya en línea con un propósito similar. Thryduulf ( discusión ) 11:39, 25 de octubre de 2024 (UTC) [ responder ]
Los casos en los que no se puede usar MathJAX son probablemente increíblemente raros y menos frecuentes que la cantidad de veces que la gente se conecta a Internet por accidente. Aaron Liu ( discusión ) 11:53, 25 de octubre de 2024 (UTC) [ responder ]
Ciertamente, hay artículos que contienen imágenes en línea para hablar de símbolos (que pueden no tener representaciones directas de caracteres Unicode), por ejemplo, glifos de letras históricas raras o elementos de notación musical (ver Alfabetos griegos arcaicos o Notación mensual , por nombrar solo dos en los que he trabajado). Sí, supongo que hay pocos artículos como estos, pero si un artículo los requiere, los requerirá numerosas veces. Fut.Perf. ☼ 11:59, 25 de octubre de 2024 (UTC) [ responder ]
Podríamos incluirlo en la lista blanca, tal vez Aaron Liu ( discusión ) 12:02 25 oct 2024 (UTC) [ responder ]
No creo que sea escalable, dada la cantidad de artículos potenciales y la cantidad de imágenes potenciales. Lo que podría funcionar sería algo en la sintaxis que diga "Estoy usando esta imagen en línea intencionalmente" Thryduulf ( discusión ) 12:05, 25 de octubre de 2024 (UTC) [ responder ]
... ¿Podría funcionar agregar una tubería vacía adicional? Podríamos hacer que la expresión regular se anule si la incrustación del archivo en línea relevante termina en |]] Aaron Liu ( discusión ) 19:54, 25 de octubre de 2024 (UTC) [ responder ]
Sin embargo, cuando tabulé los resultados ( Special:Permalink/1253409176 ), cualquier barra vertical doble se interpretó como sintaxis de tabla, incluso dentro del enlace del archivo, por lo que se rompió todo. Lo que complica las cosas. También me gustaría saber si esto rompe algo para los usuarios de lectores de pantalla.
Un parámetro inline=yes explícito (que AIUI ignoraría el analizador) podría funcionar, pero me he quedado sin tiempo para probarlo. Thryduulf ( discusión ) 20:58, 25 de octubre de 2024 (UTC) [ responder ]
También podríamos hacerlo para el caso 1 (sin título) y el caso 2 (con título). Regex buscaría |inline|. Aaron Liu ( discusión ) 21:04 25 oct 2024 (UTC) [ responder ][[File:Slinky shrewsbury.jpg|inline|]][[File:Slinky shrewsbury.jpg|inline|caption]]
Siempre que no se interprete como texto alternativo ni confunda a los lectores de pantalla, podría funcionar. Thryduulf ( discusión ) 21:09 25 oct 2024 (UTC) [ responder ]
Además, tendríamos que asegurarnos de que no entre en conflicto con ningún bot (o humano) que corrija la sintaxis. Thryduulf ( discusión ) 21:10 25 oct 2024 (UTC) [ responder ]
Otra idea es que tendríamos que conseguir que VE también inserte este parámetro, de lo contrario, se activaría la advertencia para la próxima persona que edite la fuente, con el potencial de generar confusión y perder ediciones. Thryduulf ( discusión ) 01:19, 26 de octubre de 2024 (UTC) [ responder ]
Tengo la impresión de que los filtros de edición se pueden configurar para verificar únicamente los párrafos modificados. Aaron Liu ( discusión ) 18:06 26 oct 2024 (UTC) [ responder ]
( editar conflicto ) Estoy de acuerdo con ambas suposiciones, pero no sé si existen otros usos además de los artículos de matemáticas. Sin embargo, mi punto principal era que las razones de buena fe para usar una imagen en línea, por raras que sean, casi con certeza existen y, por lo tanto, es necesario que haya alguna disposición que las permita. Thryduulf ( discusión ) 12:00, 25 de octubre de 2024 (UTC) [ responder ]
Hay muchas plantillas que usan imágenes en línea, así que ten cuidado. En general, diría que no hagas demasiadas suposiciones sobre cómo la gente NO debería usar el código wiki. La gente es más inventiva con la sintaxis de lo que esperas :) — The DJ ( discusión • contribuciones ) 12:05 , 25 de octubre de 2024 (UTC) [ responder ]
Sí, cualquier cosa que restrinja las imágenes en línea tendría que aplicarse solo al espacio de nombres del artículo (¿y borrador?) Thryduulf ( discusión ) 12:06, 25 de octubre de 2024 (UTC) [ responder ]
Gracias por los ejemplos. Sin embargo, creo que todos deberíamos volver a centrar la conversación en la idea de anulación |inline| propuesta anteriormente. Con la idea de anulación, los editores que añadan nuevas imágenes en línea podrán ver cómo evitar que el mensaje vuelva a aparecer y seguir con su camino. Aaron Liu ( discusión ) 00:52 26 oct 2024 (UTC) [ responder ]
Si bien estoy de acuerdo con @ Aaron Liu en pensar que este problema en particular parece específico de las personas que trabajan en wikitexto y, como resultado, fuera del alcance de Edit Check, ¡gracias @ Sdkb por hacer la conexión entre esta solicitud y Edit Check!
Lo que estás modelando aquí –pensar en cómo una política/convención podría programarse en experiencias de edición– es precisamente el tipo de práctica que pretendemos inspirar con Edit Check.
Espero que todos sigan enviándome sus comentarios a medida que surjan ideas de este tipo... PPelberg (WMF) ( discusión ) 19:47 25 oct 2024 (UTC) [ responder ]
Estoy de acuerdo , pero solo un poco. Si agregaras las letras, sería mejor. Además, una solución para tu clasificación por regiones podría ser hacer una clasificación por idioma (como "O" de "Oficina" se convertiría en "S" de "Escuela" en un "inglés invertido" teórico). The Master of Hedgehogs ( converse ) ( erizos ) 14:33, 17 de octubre de 2024 (UTC) 
Estás invitado a participar en la discusión en Wikipedia:Editar filtro/Solicitado § Advertencia sobre el uso de imágenes en línea . Aaron Liu ( discusión ) 00:54 24 oct 2024 (UTC) 
Movido desde Wikipedia:Editar filtro/Solicitado/Archivo 21 § Advertir sobre el uso de imágenes en línea
Necesita una discusión más amplia , pero hasta entonces, {{ EFR }} . La base de esta solicitud es la eliminación accidental de dos puntos. Esto parece más bien algo que podría plantearse en Phab, aunque sea por lo menos, pero no creo que necesitemos un filtro para advertir a la gente que use 
