Wikipedia:Café/Archivo/Propuestas/Actual

De Wikipedia, la enciclopedia libre



Esta página es archivada automáticamente.

Parámetros del archivado:

Lugar: Wikipedia:Café/Portal/Archivo/Propuestas/AAAA/MM
Días a mantener: 14
Avisar al archivar: Sí
Estrategia: Firma más reciente en la sección
Mantener caja de archivos: No


Emergencia: uso masivo de proxys - Propuesta de bots con permiso de administrador[editar]

Este hilo no se archivará. (info)

Hola a todos. Quienes hayan revisado el registro de bloqueos de las últimas 48 horas podrán ver que está en curso un uso masivo y descontrolado de proxys abiertos para cometer vandalismo, difamación, ataques personales, entre otros. Antier pasé hasta las 4 am hora local bloqueando cuentas y proxys. La situación creo que ya ha llegado a un límite intolerable y no manejable para esta Wikipedia así que es hora de que discutamos los "bots con permisos de administrador".

Hay varias situaciones que hacen necesario que la comunidad dé este paso:

  1. Hay bots rutinarios como Internet Archive, Commons Delinker, etc. que hacen tareas útiles y necesarias como rescatar referencias o desvincular de los artículos o páginas archivos borrados o renombrados en Commons por diversas razones. Esos bots, al no tener permisos de administrador, no pueden editar en las páginas que estén bajo el nivel de protección de "solo bibliotecarios".
  2. El uso de proxys está prohibido como política global de Wikimedia. Si vemos un proxy, debemos bloquearlo. Hoy no hay herramientas que hagan bloqueos automáticos de proxys, como sí lo ha instaurado la Fundación a los nodos Tor, es decir, el cumplimiento de la política global de no usar proxys recae en las comunidades y en ejercicios de detección, denuncia, verificación y posterior bloqueo. Por esa razón, varios meses atrás empleé un script para exportar los bloqueos de proxys impuestos en la Wikipedia en Inglés para aplicarlos localmente (por eso ven que tengo la astronómica cifra de +3.8 millones de bloqueos aplicados como admin. en esta cuenta), ello también se estuvo haciendo durante algún tiempo a nivel global, ahora no se hace y yo he perdido el script que tenía así que no puedo ejecutarlo. Considero, además, que no debería ser yo con mi cuenta principal quien haga esos bloqueos: al ser una enorme cantidad, puede entorpecer el ejercicio de transparencia de revisar mis bloqueos rutinarios al tener que scrollear ante decenas de miles de bloqueos a proxys para encontrar algún registro en específico de ser el caso. A eso le sumo que, al ejecutar el script con mi cuenta, debo ponerme el flag de pseudobot de modo que mientras el script esté corriendo, todas mis ediciones y acciones se marcarán bajo ese flag, ello significa que yo quedo impedido de realizar cualquier otra wiki-acción, pues quedaría marcada bajo hecha con ese flag, oculta de la lista de cambios recientes o listas de seguimiento, y por ende, no considero que sea correcto en términos de transparencia y rendición de cuentas.

Puedo dar innumerable cantidad de ejemplos de uso masivo e inadecuado de proxys para cometer ataques masivos en esta Wikipedia, además del que lleva en curso desde por lo menos el mes de abril y que me motiva a abrir esta propuesta, o de usuarios con ban de la Fundación que los usan para seguir sus fechorías, etc.

En la Wikipedia en Inglés el proceso para dar permisos de admin. a un bot está regulado en la política de bots; los requisitos son: aprobación comunitaria bajo el mismo proceso para autorizar un bot común, y que su controlador tenga los permisos de administrador. Ese último requisito supone un problema para el primer punto que esgrimí, los bots cross-wiki o bots globales que hacen tareas como recuperar referencias o desvincular archivos borrados de Commons, por lo que si esta comunidad 1- opta por habilitar los admin-bots, y 2- que uno de los requisitos sea que el controlador sea un biblio local, se agregue una exclusión para permitir otorgar el permiso a ese tipo de bots globales, aunque siempre requiriendo el consenso comunitario.

Comentar además que tras conversarlo con @-jem-: en el canal IRC de biblios, él está dispuesto a usar uno de sus bots para implementar los bloqueos a los proxys. Estoy seguro que los controladores de los bots para esos fines que ya existen nos pueden ceder el código respectivo (ST47ProxyBot ha aplicado 9.6 millones de bloqueos y 5.5 millones de re-bloqueos). Para quienes no lo sepan y sin revelar muchos detalles, se emplea una combinación de inteligencia de código abierto, una API de lista de bloqueo y escaneo de puertos/huellas digitales para determinar si se está o no ante un proxy abierto. Además, se hacen revisiones periódicas para determinar si un proxy ya no está abierto y por ende no bloquearlo de nuevo, entre otros.

Atento a sus preguntas, comentarios o sugerencias. Ping a @MarioGom: quien estoy seguro también tiene conocimiento del tema y puede ayudarnos acá. — Lucho Problem? 15:46 11 jul 2023 (UTC)Responder[responder]

El uso de un filtro con bloqueo automático también puede ayudar.--SRuizR ¡Pura vida! 15:51 11 jul 2023 (UTC)Responder[responder]
Tratándose de una situación de emergencia, A favor A favor de la propuesta de LuchoCR--SRuizR ¡Pura vida! 15:52 11 jul 2023 (UTC)Responder[responder]
Además tiene sentido lo que dice Lucho sobre que el uso de su cuenta para los bloqueos masivos puede entorpecer la transparencia, por lo que me parece razonable que una cuenta con flag de bot sea la que lleve el nombre de dichos bloqueos.--SRuizR ¡Pura vida! 15:55 11 jul 2023 (UTC)Responder[responder]
Yo estoy absolutamente A favor A favor de habilitar la posibilidad de crear bots con permiso de administrador. Sin embargo, creo que se está hablando de dos casos distintos:
1. El primero es la automatización de tareas administrativas. En este caso, me parece obvio que el controlador tiene que tener, al menos, los mismos permisos que el bot.
2. El segundo es dar administrados a bots para tareas no administrativas (véase el ejemplo de internetarchivebot). En este caso, estaría En contra En contra de otorgar permiso de administrador. De momento, solo se ha propuesto el ejemplo de páginas protegidas solo para bibliotecarios. En este caso, ¿no sería más lógico que la protección fuera solo para bibliotecarios y bots, en lugar de solo para biblios? si se ha aprobado la acción automatizada del bot y el artículo está protegido por vandalismo u otros problemas no relacionados con bots, no veo problema con que todos los bots puedan editar el artículo. WikiDasher 16:04 11 jul 2023 (UTC) P.D. Para la manera técnica de realizar esto, véase la respuesta de SRuizRResponder[responder]
Concuerdo con WikiDasher respecto a lo de InternetArchiveBot. En este caso, yo preferiría dar el permiso editprotected al grupo bot--SRuizR ¡Pura vida! 16:15 11 jul 2023 (UTC)Responder[responder]
Hay algunos proyectos que han implementado el grupo botadmin. ¿Creen que es más conveniente otorgar a la cuenta los permisos de sysop o crear el permiso de botadmin?--SRuizR ¡Pura vida! 16:17 11 jul 2023 (UTC)Responder[responder]
Buenas. Apoyo la propuesta. En su día participé en la implementación inicial del bloqueo de proxies P2P y he aprendido unas cuantas cosas sobre la mitigación del daño colateral. @LuchoCR: Antes de entrar en más detalles: ¿tienes ejemplos de IPs recientes que han sido bloqueadas? Me gustaría ver qué tipo de proxy están usando. Por otro lado, ¿el principal problema es el uso de proxies por parte de usuarios no registrados? ¿o el abuso de estos proxies con cuentas registradas es significativo? Dependiendo de estos factores, habrá que preparar algunas medidas para impedir que muchos usuarios se queden sin poder editar, ya que hay ciertos países en los que se bloquearía un gran número de IPs. MarioGom (discusión) 16:22 11 jul 2023 (UTC)Responder[responder]
Dado que lo principal en este hilo es el tema de permitir que un blot bloquee, podemos dispensar de discusión el tema de Internet Archive y Commons Delinker y dejarlo como tema a tratar en el futuro para centrarnos en el tema urgente por ahora.
@SRuizR: ¿Qué proyectos tienen el grupo botamin? Pregunté en en.wiki y dicen que allí otorgan el de sysop común. Si se crea un grupo de usuarios distinto me parece que puede haber más recepción además de limitar lo que eventualmente puedan hacer esos bots, dejándolo solo en bloqueos.
@MarioGom: Ya te he compartido por privado algunas para que puedas revisar. Según el patrullaje de los últimos meses, el abuso viene principalmente de cuentas registradas. — Lucho Problem? 16:29 11 jul 2023 (UTC)Responder[responder]
@LuchoCR: El grupo botadmin está presente en Wikipedia en kurdo, Wikipedia en persa, Wikcionario en frances, Wikipedia en italiano, y Wikipedia en malayo.--SRuizR ¡Pura vida! 16:45 11 jul 2023 (UTC)Responder[responder]
Gracias y para responder a un comentario previo, el tema con el filtro es que quedaría sujeto a que se intente hacer una edición y el filtro efectivamente lo detecte o lo bloquee, lo que lo hace sujeto a evasión. La lógica es bloquear los proxys tan pronto como sean detectados en cumplimiento de la política global, y que sean re-bloqueados o desbloqueados conforme sean cerrados. Siendo que efectivamente existe ese grupo de botadmin, mi propuesta sería instaurar ese grupo con los permisos, por ahora, de bloquear/re-bloquear/desbloquear. A futuro podemos discutir y consensuar según sea necesario añadir permisos adicionales a dicho grupo como lo puede ser proteger páginas (para, por ejemplo, automatizar la protección de páginas de usuarios expulsados, entre otros). — Lucho Problem? 17:01 11 jul 2023 (UTC)Responder[responder]
Gracias Lucho. Reitero el apoyo a la propuesta. Creo que los detalles de la implementación técnica se pueden resolver por separado a la discusión de aprobación del permiso en si. Dicho esto, habrá que tener en cuenta que se necesitarán algunas exenciones de bloqueo (difícil cuantificar a priori, pero seguro que más de las habituales), y es algo en lo que incluso biblios podrían ayudar en algunas ocasiones sin necesidad de checkuser. MarioGom (discusión) 18:00 11 jul 2023 (UTC)Responder[responder]
A favor A favor de todo lo que sea aliviar de tareas cansinas y automatizables a los patrulleros y a los biblios. Tú labor ha sido impecable, Lucho, y si a eso le sumamos que estará @-jem-:: cartón lleno, confianza total. Laura Fiorucci (discusión) 21:05 11 jul 2023 (UTC)Responder[responder]
Lo que yo no entiendo es por qué siendo una política global, no se hacen los bloqueos de forma global a través del sistema y es necesario hacerse cuatro millones de bloqueos por proyecto. Tampoco entiendo que con cuatro millones de direcciones bloqueadas el problema siga siendo de emergencia. -- Leoncastro (discusión) 21:31 11 jul 2023 (UTC)Responder[responder]
Leoncastro: Sencillo, el tema no es prioridad para la Fundación. Además notar que los 4 millones de bloqueos hechos por el bot en Wikipedia en inglés son temporales, y en todo caso, aplican únicamente para ese proyecto. El script se corrió unas cuantas veces en Meta y se aplicaron bloqueos globales, pero ya no se hace más y por ende las IPs, salvo contadas excepciones, no están bloqueadas a nivel global. Además hay que tomar en cuenta que en los últimos años aparecieron los proxys P2P, que son los que más dolores de cabeza han causado a nivel cross-wiki (haciéndole test al script que recuperé gracias a Mario, son más de 170 mil), pero también hay que sumar los colocation webhost y demás que, en lugar de IPs individuales, son rangos enteros de IPs que también hay que bloquear localmente. — Lucho Problem? 21:42 11 jul 2023 (UTC)Responder[responder]
Sí, es evidente que no se hace, pero eso no responde el por qué no se hace. Además, creo recordar que la intención de la Fundación es ocultar las direcciones IP y reemplazarlas por nombres automáticos, lo cual si no me equivoco dificultará el bloqueo de proxies y rangos. -- Leoncastro (discusión) 21:53 11 jul 2023 (UTC)Responder[responder]
Lo que demuestra también que esa propuesta de enmascaramiento solo viene a hacernos a los patrulleros el trabajo más complicado, mientras tanto, tenemos que abordar los problemas que tenemos ahora. — Lucho Problem? 21:55 11 jul 2023 (UTC)Responder[responder]
Leoncastro (disc. · contr. · bloq.): El enmascarado de IPs presentará muchos problemas, pero el bloqueo de proxies no debería ser uno de ellos. El bloqueo de proxies generalmente se lleva a cabo independientemente de la actividad de las IPs, y por lo tanto, no es necesario verificar ediciones. Es decir, las listas de IPs y rangos a bloquear normalmente vienen de fuentes externas.
En cuanto a por qué la Fundación no se hace cargo, creo que hay varias razones. Una de ellas es que el bloqueo global de IPs, excepto en el caso de Tor, se confía a los stewards y dudo que haya consenso de la comunidad para que la Fundación asuma esa tarea de forma directa. Lo que algunos llevamos unos 2 años pidiendo a la Fundación es que creen las herramientas adecuadas para que los stewards y los admins de cada proyecto puedan aplicar una política de bloqueo de proxies de forma fácil, sin que cada proyecto requiera su propio bot, su propia formación técnica, etc. Si no es una prioridad para la Fundación, sospecho que es porque no hay un número significativo de proyectos clamando por ello. MarioGom (discusión) 09:54 12 jul 2023 (UTC)Responder[responder]
@MarioGom, a día de hoy no existe un bloqueo como tal de proxies o incluso IPs. El bloqueo es a usuarios, y lo que se bloquea es la edición. Un usuario que acceda a través de un proxy puede consultar la wikipedia sin problema —yo habitualmente uso VPN—. Cuando se intenta bloquear una dirección IP, digamos la IP 127.0.0.1 —sí, ya sé que esto es localhost—, actualmente se está bloqueando realmente al usuario Usuario:127.0.0.1. Con el enmascaramiento previsto, cada usuario mantendrá un nombre temporal, digamos «Usuario:?1234», hasta que borre la caché de su navegador; este usuario puede usar diferentes direcciones IP y seguir manteniendo el mismo nombre temporal de usuario; no se podrán acceder a las direcciones IP de dicho usuario (salvo los Checkusers y Stewards); entonces previsiblemente tampoco se podrán bloquear usuarios según su dirección IP. -- Leoncastro (discusión) 14:43 12 jul 2023 (UTC)Responder[responder]
Leoncastro, claro que existe el bloqueo de IPs y rangos de IPs. De hecho, así es como se bloquean los proxies: bloqueando sus IPs o rangos. Un bloqueo a una IP o rango puede tener el flag anon. only (afecta sólo a usuarios no registrados usando esa IP) o no (afecta también a usuarios registrados). Un bloqueo hard a una IP o rango, afecta a todos los usuarios por igual, ya sea con un "usuario temporal" (IP enmascarada), un usuario registrado usando esa IP, o un usuario no registrado. Como comento: no es necesario checkuser para bloquear proxies, dado que generalmente lo que hacemos es encontrar los proxies (fuera de Wikipedia) y bloquear sus IPs o rangos independientemente de la actividad que hayan tenido en Wikipedia. MarioGom (discusión) 18:46 12 jul 2023 (UTC)Responder[responder]
Ok. Creo que veo por dónde viene tu comentario. Efectivamente bloquear la IP de un proxy no evita que un usuario siga editando desde otra dirección. En mi opinión, eso se trata de un problema diferente. Un problema al fin y al cabo, pero no tan relacionado con que las IPs de proxies estén bloqueados o no. MarioGom (discusión) 18:58 12 jul 2023 (UTC)Responder[responder]
A favor A favor de la propuesta de Lucho. Y de paso me adelanto a preguntar, ¿cuál sería el proceso para solicitar exención de bloqueo de IP de ser necesario? Pregunto porque casualmente la IP de mi internet residencial está bloqueada como proxy en la Wikipedia en inglés; la semana pasada lo escalé por medio de en:WP:UTRS pero no me han respondido. :(FlyingAce✈hola 21:58 11 jul 2023 (UTC)Responder[responder]
Te recomiendo pedirlo en el canal de desbloqueos de la Wikipedia en inglés en IRC. Si se aprueba la propuesta y los bloqueos empiezan a realizarse, habrá que desarrollar una página de ayuda que explique qué hay que hacer, en específico, colocar la plantilla {{Desbloquear}} y señalando que se está afectado ante un bloqueo de IP por proxy. Ya lo hacíamos así en el pasado cuando yo corrí el script. También las canalizábamos rápidamente cuando llegaban los reportes a los canales de ayuda en IRC o al de bibliotecarios. — Lucho Problem? 22:00 11 jul 2023 (UTC)Responder[responder]
Muy a favorMuy a favor Muy a favor Ontzak (Jota Ke Irabazi Arte) 22:04 11 jul 2023 (UTC)Responder[responder]
A favor A favor Se trata de una labor automática que debería hacer un bot, no tener que hacer a mano un bibliotecario. Platonides (discusión) 23:48 11 jul 2023 (UTC)Responder[responder]
Siendo que hasta ahora las opiniones son en general (casi unánimes) a favor de que pueda haber un bot que se encargue del bloqueo de proxys, si pasados siete días desde que abrí el hilo la tendencia continúa, pediré en Phabricator la creación del grupo "botadmin" sugerido por SRuizR, con el permiso 'block' y 'blockemail'. Si alguien sabe de otros requerimientos que sean necesarios, bienvenido a señalarlos. — Lucho Problem? 19:18 12 jul 2023 (UTC)Responder[responder]
@LuchoCR, como con el resto de grupos de usuarios esperaba que se hiciese una votación para aprobar la nueva política del nuevo permiso. Vamos, sería lo razonable. Incluso aunque todos parezcan de acuerdo con el permiso, será necesario redactar la letra pequeña. Yo por ejemplo solamente votaría a favor si el controlador del botadmin fuera bibliotecario. Y el botadmin debería tener, además de los permisos mencionados de block y blockemail, los demás permisos que ya tienen el resto de bots (bot, noratelimit, skipcaptcha, apihighlimits, etc.). -- Leoncastro (discusión) 19:32 12 jul 2023 (UTC)Responder[responder]
Siendo que se trata de un tema de emergencia y que el bot que correría los bloqueos sería uno de jem, previa aprobación comunitaria en el tablón de Bots, me parece que este caso justifica hacer lo mismo que hicimos con el permiso de editor de plantillas, sin embargo, trabajaré en las próximas horas un borrador de reforma a la política de Bots para incorporar una sección específica sobre ellos. — Lucho Problem? 19:39 12 jul 2023 (UTC)Responder[responder]
Tiene que hacerse una votación. Independientemente del consenso que puedan alcanzar 10 o 20 participantes en el Café, se trata de un cambio importante de políticas y habrá que afinar detalles y prever ciertas situaciones especiales. Saludos. Lin linao ¿dime? 19:42 12 jul 2023 (UTC)Responder[responder]
  • Muy a favorMuy a favor Muy a favor creo que sería más expedito atender solicitudes de desbloqueo y agregar cuentas a excento de bloqueo de IP que bloquear a mano tantos vándalos. Que el operador del bot sea un bibliotecario o un steward. --Amitie 10g (discusión) 19:28 12 jul 2023 (UTC)Responder[responder]
Yo solo digo que me llama la atención que al mismo tiempo se rechace de plano conceder permisos para borrar artículos a humanos y se pidan permisos de bibliotecario para bots. No tengo una postura definida, no pediría esos permisos ni aunque se aprobasen y no sé muy bien qué es eso de un proxi y a cuántos usuarios puede afectar el que un bot los bloquee, pero me llama la atención.--Enrique Cordero (discusión) 20:22 12 jul 2023 (UTC)Responder[responder]
Con esta propuesta tampoco se estarían otorgando permisos de borrar artículos, entiendo que es únicamente bloqueos para prevenir abuso. –FlyingAce✈hola 20:32 12 jul 2023 (UTC)Responder[responder]
El concepto en sí de un algoritmo bloqueador no es nuevo (aunque tratándose de otro supuesto), como el filtro de ediciones 114. Mientras sea una herramienta empleada por un administrador y que no tenga demasiados falsos positivos, un bot siempre puede agilizar el trabajo, que a veces puede resultar frustrante.  𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦  DIALOG   05:04 13 jul 2023 (UTC)Responder[responder]
Hola Enrique. Un proxy, en palabras sencillas, es -para estos efectos- una dirección IP que actúa como máscara de la IP real de la persona que está haciendo ediciones o creando cuentas en Wikipedia. Funciona en términos prácticos igual que una VPN. Debido a su uso generalizado abusivo y negativo, editar con proxys está prohibido como política global y deben ser bloqueados cuando son detectados. Los afectados serían quienes usen esos servicios anonimizantes (por lo general, los usuarios legítimos que los emplean son muuuy pocos). Mientras tanto, los alojamientos web (webhost) y el housing (colocation host), son a gran escala: implican rangos completos de IP que deben ser bloqueados, pero que impliquen grandes cantidades de IPs, no significa que aplique en igual cifra a usuarios legítimos. Por lo general el acceso a proxys es complejo y por ende no supone una afectación masiva a usuarios legítimos, en los últimos años se masificaron (dentro de lo que cabe) en especial por la gente que empleó servicios gratuitos para ver series o películas en plataformas como Netlix, que no están disponibles en su país o región. Al desactivarlas, el usuario "recupera" su IP real y puede editar sin problemas. Asimismo puede ocurrir que el ordenador o dispositivo de la persona esté infectado con un malware que reenvíe su conexión a un proxy, para usarlo entre otras cosas para hacer ataques de denegación de servicio, etc. Respecto al tema de permitir a más personas borrar páginas y su relación con esto, ten en cuenta que la propuesta para este caso implica que, el bot que aplique bloqueos, sea manejado por alguien que tenga permisos de administrador (es decir, que sea bibliotecario) y por ende, ya tenga la confianza de la comunidad. — Lucho Problem? 20:34 12 jul 2023 (UTC)Responder[responder]
@Enrique Cordero, por eso yo indiqué que solamente votaría a favor si el controlador fuera bibliotecario. Porque con esa condición no cambiaría prácticamente nada, salvo que el bibliotecario de turno podría usar una cuenta paralela de bot para bloquear proxies de forma automatizada; cosa que actualmente ya pueden hacer con la propia cuenta mediante el permiso de pseudobot. De forma similar algunos usuarios hemos pedido el permiso de bot, para separar nuestras ediciones manuales de las [semi]automáticas, lo cual me parece más transparente que, por ejemplo, inflarse a hacer ediciones automatizadas con Replacer. A no ser que se crean que se hacen manualmente cuatro mil o incluso seis mil ediciones al día (a un ritmo de 5 por minuto, 60 minutos por hora, 4000 ediciones son más de trece horas picopala sin descanso...). -- Leoncastro (discusión) 20:48 12 jul 2023 (UTC)Responder[responder]
En mi navegador del teléfono se puede activar una función para usar una VPN. La activé y entré a Wikipedia como anónimo y la IP está bloqueada de forma local por abuso a largo plazo (sic) y globalmente por ser un proxy abierto. Al iniciar sesión pude hacer una edición sin problemas, pero no lo entiendo, porque las condiciones del bloqueo dicen lo contrario. No sé cuánta gente navegará con VPN, pero si fuera un problema para los usuarios registrados, supongo que se pueden hacer bloqueos solo a IPs e impedir la creación de cuentas. Saludos. Lin linao ¿dime? 22:00 12 jul 2023 (UTC)Responder[responder]
Los bibliotecarios estamos automáticamente exentos de los bloqueos a direcciones IP pues uno de los permisos del flag sysop es el de ipblock-exempt y por ende pudiste realizar la edición (punto #28 en el cuadro Bibliotecarios (sysop)). No pasa así con quienes no son biblios, o no tengan el flag de exención de bloqueo a IP. — Lucho Problem? 22:36 12 jul 2023 (UTC)Responder[responder]
Sé que no tiene que ver con el tema del debate, pero esta es otra. Me parece del todo incorrecto que las ediciones automatizadas formen parte del historial de ediciones "normal" del usuario, ni mucho menos de la tabla de usuarios más activos.  𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦  DIALOG   04:57 13 jul 2023 (UTC)Responder[responder]
Es por eso mismo que la propuesta (al menos la que apoyo) incluye la realización de la tarea por parte de una cuenta separada con permisos de bot (a través del flag botadmin).--Amitie 10g (discusión) 11:59 14 jul 2023 (UTC)Responder[responder]
He redactado un borrador de reforma a la política de bots para incorporar los cambios que ameritaría este permiso. Tuve retroalimentación de varios usuarios en IRC previo a postearla por acá. Quedo atento a sus comentarios, observaciones o sugerencias: Usuario:LuchoCR/Wikipedia:Política de bots/Reforma --— Lucho Problem? 23:18 12 jul 2023 (UTC)Responder[responder]
Trasladé el taller a la página de discusión de la votación. Se puede consultar en Wikipedia:Votaciones/2023/Reforma a la política de bots para regular los bots con permisos administrativosLucho Problem? 04:11 19 jul 2023 (UTC)Responder[responder]
Muy a favorMuy a favor Muy a favor Solo confirmar mi apoyo a la propuesta y mi aportación mediante varias mejoras y simplificaciones a la redacción original. LuchoCR ya sabe que cuenta conmigo si resulta necesario o conveniente un acceso a Toolforge, el uso de alguna de mis cuentas bot, o ambas cosas. Espero que todo el proceso pueda agilizarse al máximo para que los bloqueos puedan empezar cuanto antes. - José Emilio –jem– Tú dirás... 11:05 19 jul 2023 (UTC)Responder[responder]

Una serie de consideraciones que se me quedaron en el tintero:

  • Que el bot sea operado única y exclusivamente por un bibliotecario, administrador global, reversor global o steward (si eso es materia de discusión, podría agregarse cono opción para la votación) (aunque eso no impediría que un no-bibliotecario con experiencia en desarrollo y de mucha confianza de la comunidad desarrolle el bot y apoye en su operación).
  • Que el bot corra desde algún servicio en la nube como Toolforge o alguna solución comercial (más que nada por seguridad y disponiblidad).
  • Leer sobre OAuth y ver si es una buena alternativa para autenticar. no es útil.
  • Ver si es apropiado que la autenticación expira cada cierto tiempo, y qué el operador la renueve cuando sea necesario. no es buena idea.
  • Si un usuario legítimo solicita el desbloqueo, que se le aplique el flag exento de bloqueo de IP por un tienpo determinado.

--Amitie 10g (discusión) 12:37 19 jul 2023 (UTC)Responder[responder]

Sobre tu punto #1 no me queda claro si estás objetando la propuesta de que un steward, que tiene confianza de la comunidad global, pueda operar un botadmin. Sobre lo segundo y tercero, no sé si son requisitos demasiado rígidos que puedan causar problemas a futuro; por ejemplo lo de Toolforge impediría usar una cuenta bot para correr el script de bloqueo de proxys, porque en tesis de principio no está en ese servicio aunque -jem- ha dicho estar dispuesto a correrlo desde ahí o a ceder el acceso; y sobre lo último, no parece prudente hacer mención a eso en la política de bots, pero naturalmente antes de que empiecen a bloquearse los proxys se desarrollarán páginas de ayuda y explicativas, además de las plantillas necesarias para que los eventuales afectados sepan qué hacer para obtener la exención de bloqueo. — Lucho Problem? 17:00 19 jul 2023 (UTC)Responder[responder]
LuchoCR, gracias por recordarme a los stewards. Agregué a mi comentario a estos y también a los reversores globales y administradores globales; eso también implicaría otros grupos de alta confianza, háganlo saber. --Amitie 10g (discusión) 18:06 19 jul 2023 (UTC)Responder[responder]
Punto a punto de lo indicado por Amitie:
  • Me parece bien la ampliación en los posibles operadores, y por supuesto que el programador principal podría no ser bibliotecario/steward/etc., ya que es una figura distinta al operador y que nunca se ha mencionado en la política.
  • Toolforge implica algo de burocracia para conseguir acceso, algunas limitaciones por ser un entorno compartido y pautas de trabajo que no lo hacen ideal para todos los casos, y tampoco es la única opción posible dentro del mundo Wikimedia. Asumiendo que sí son importantes la seguridad y la disponibilidad, opino que como alternativa bastaría con añadir la indicación de que el operador se asegurará de que otras personas de confianza de la comunidad puedan tener siempre acceso al servidor y/o al código para poder intervenir en caso de ausencia/emergencia, indicándolas en la solicitud, y restringirá el acceso al resto.
  • No se contempla el uso de cuentas distintas a la del propio bot para registrar las acciones, por lo que no veo ninguna necesidad de usar OAuth para posibilitarlas, salvo que haya alguna otra razón que se me escape.
  • Igualmente, no veo la necesidad de gestionar expiraciones y renovaciones dentro de un entorno seguro, sin interfaces públicos y que usa una única cuenta de usuario.
  • La cuestión de los daños colaterales por bloqueos a IP es independiente del uso o no de un bot, y entiendo que debe tratarse en otras páginas con instrucciones, como ya ha dicho LuchoCR; en todo caso, creo que bastaría con algún enlace al respecto en el «véase también».
- José Emilio –jem– Tú dirás... 09:56 20 jul 2023 (UTC)Responder[responder]
Notifico que he pedido la creación del grupo de usuarios en Phabricator por el evidente consenso en este hilo, y he programado el inicio de la votación para emitir la política al 15 de agosto de 2023. — Lucho Problem? 03:36 22 jul 2023 (UTC)Responder[responder]
En Phabricator piden que haya 'consenso' sobre los permisos a añadir al nuevo grupo de usuarios. Como lo planteó @Leoncastro, incluí los que ya tiene el grupo de usuarios 'bot', sumado a block y blockemail. ¿Algún comentario, sugerencia u objeción? (Tomen en cuenta que la propuesta de política señala que autorizado un bot con permisos administrativos cuya tarea aprobada no tiene el flag necesario, bastará la votación afirmativa en la solicitud para hacer la solicitud de los permisos requeridos en Phabricator) — Lucho Problem? 23:00 22 jul 2023 (UTC)Responder[responder]
A favor A favor de los permisos propuestos para el grupo de botadmin. –FlyingAce✈hola 00:19 24 jul 2023 (UTC)Responder[responder]
Sin objeciones. A favor A favor de implementar el grupo con todas las configuraciones especificadas. —Hasley (disc.) 12:45 24 jul 2023 (UTC)Responder[responder]
¿Nos mantendréis al corriente del desarrollo del bot?  Virum Mundi  LOG  23:07 30 jul 2023 (UTC)Responder[responder]
Informo a la comunidad que con el 87,88% de los votos emitidos, las enmiendas a la política de bots han sido aprobadas. Gracias a todos los que participaron. — Lucho Problem? 00:17 15 ago 2023 (UTC)Responder[responder]
Informo a la comunidad que he postulado a BlockBot-es como bot con permisos administrativos, dedicado al bloqueo de proxys. — Lucho Problem? 17:07 21 ago 2023 (UTC)Responder[responder]

Plantilla:Sucesión[editar]

Una discusión sobre {{Sucesión}} debido a anacronismos varios, me ha llamado la atención sobre debates inacabados en esta plantilla. Creo que técnicamente ha quedado bastante obsoleta por el desarrollo de {{Ficha de persona}}, que duplica toda la información de {{Sucesión}}, pero adicionalmente hay varios temas que han ido surgiendo y sobre los que ha habido conversaciones inconexas. Las que he visto principalmente datan de hace demasiados años y muchos de los usuarios que participaron en esos debates ya no editan.

El primer grupo de temas es que hay saturación en artículos donde que se listan múltiples cargos, sin criterio coherente sobre el valor para el lector del artículo. Creo pendiente un debate más amplio sobre qué cargos indicar con esta plantilla. Hay un consenso "histórico" en usarlo para monarcas o en general dignatarios donde hay un claro título principal o un grupo reducido de títulos con sucesores y predecesores. Sin embargo veo hay puntos de fricción:

  1. Es frecuente también ver la plantilla en artículos a borrar por ser meros CV de políticos modernos. ¿Es necesario listar hasta cuando un político fue concejal (Gerardo Conde Roa)? ¿Es necesario listar cargos de partido que conducen a listas como [1] o José_Manuel_Rey_Varela#Trayectoria? Por plantear un debate diferente a los políticos ¿Es relevante en Felipe_VI_de_España#Antepasados indicar que fue "abanderado"? Hay algunas reglas que podemos pensar en extrapolar (por ejemplo, ha habido consensos pasados de que cargos inferiores al máximo cargo municipal del país no son relevantes per se), que podrían usarse para plantear límites mínimos, pero sería interesante oír opiniones.
  2. Hay casos históricos donde cabría hacer debates similares. Por ejemplo, en Carlos I de España#Potestades, ¿Es relevante indicar el señorío de Salins (a su vez en teoría incluido en el Condado Palatino de Borgoña y solo listado aparte por anécdotas históricos? ¿Es necesario listar título nominales como el de Conde de Kyburgo que no ejercía realmente? Si los incluimos en personajes históricos, ¿por qué en Felipe VI no incluimos en la tabla Anexo:Títulos, honores y nombramientos de Felipe VI de España? Hay temas como el de rey de Jerusalén que terminan saliendo en el debate por reducción al absurdo. ¿Cuándo estamos sobre simplificando y cuando estamos añadiendo paja?

Otro conjunto de temas es como hacer el uso de la plantilla más amigable al lector

  1. Hay un hilo que tuvo muy poco seguimiento [2] sobre estandarizar un estilo compacto.
  2. Otro hilo que se planteó hace ya más de una década es sobre el uso de imágenes, aunque no se llegó a un consenso. Debates similares sobre el uso en infobox han tendido a pedir mesura en su uso (tamaños pequeños, sólo en campos relevantes, evitando banderas locales). Personalmente yo prefiero evitar los escudos y banderas en estos usos dado que suelen general múltiples guerras heráldicas y problemas anacrónicos.
  3. ¿Creéis alguno que hacer la tabla desplegable y oculta por defecto como la plantilla de antepasados sería recomendable?
  4. ¿Es preferible que haya una línea entera para (predecesor, titular sucesor) como en Pedro IV de Aragón aunque algunos se repitan? ¿O es mejor combinar columnas cuando se para una sucesión se compartan predecesores pero no sucesores (o al revés)? Es lo que por ejemplo hacen en Wikipedia en inglés ([3]) pero no he visto que ese uso tenga un empleo mayoritario en esta Wikipedia.
  5. En casos como Maximiliano_II_de_Habsburgo#Sucesión en los que la división de títulos afecte al numeral? ¿Eso es motivo para separar las filas?
  6. ¿Debe haber alguna regla de proporcionalidad entre el tamaño de la sección y el del artículo?

Otros temas a plantear incluirían:

  1. ¿Es la plantilla en sí necesaria ahora que {{Ficha de persona}} incluye su funcionalidad y tiene una integración mejor con Wikidata? ¿No es {{sucesión}} completamente redundante en la actualidad?
  2. Como en el caso de las secciones de antepasados ¿Se debería incluir esta información en una sección aparte? Si es así ¿Cómo debería titularse? Si no, ¿Al final del artículo caiga donde caiga? ¿En ficha de persona?

Finalmente, la plantilla fue pensada para biografías pero se ha usado de forma muy creativa:

  1. ¿Es su uso apropiado en artículos como Reconquista o Modelo atómico de Rutherford en los que no hay una sucesión objetiva (puede haber diferentes periodificaciones, etc)?
  2. Cuando la sucesión sí es objetiva pero se trata de casos como Real brasileño ¿Es enciclopédico su uso o es redundante con el propio texto?
  3. El uso para récords como en Gran Puente de Akashi Kaikyō o RMS Queen Mary 2 ¿Caen dentro del ámbito deseado de la plantilla?
  4. Su uso en sedes de eventos (olimpiadas, ciudad europea de la cultura), ¿Es correcto o debería restringirse a biografías?

En mi caso personal, creo que la plantilla ha quedado desfasada por el avance en otras plantillas y genera más problemas en su uso de lo que aportan. Pero al mismo tiempo sé que hay muchos otros que creen que la plantilla, usada razonablemente puede aún tener utilidad. Sin embargo, no he encontrado debates recientes al respecto. Sería bueno oír las opiniones de la comunidad al respecto.

Copio a @Jzh2074:, que ha originado el debate. @Strakhov:, @Alavense:, @Enrique Cordero:, @Leonprimer:, @Esp1986:, @Zigurat:, @Werthercito:, @Beta15: con los que me he cruzado a menudo en temas de biografías, y @Vanbasten 23: y @-jem-:, que han estado muy activos en plantillas. pueden estar interesados también en el debate. Seguro que me dejo a usuarios interesados en biografías, por si queréis dar avisos.

Saludos--FAR, (Libro de reclamaciones) 16:47 17 ago 2023 (UTC)Responder[responder]

A ver:
  • Los empleos y cargos poco relevantes molestan tanto en la parte de abajo del artículo como en la ficha (de hecho posiblemente más en esta última). Es un clásico en artículos sobre políticos españoles, donde sus fans listan en la ficha el cargo más chorras que ha tenido y sus respectivos sucesores y antecesores. Véase el estado actual del artículo de Borja Sémper (que ni siquiera es especialmente malo, los hay mucho peores), con su "Vicesecretaría de Cultura y Sociedad Abierta del Partido Popular", su "Portavocía del Grupo Municipal Popular en el Ayuntamiento de San Sebastián", con los nombres de Miren Albistur y Borja Corominas, su "Presidencia del Partido Popular de Guipúzcoa". No del País Vasco, no de Guipúzcoa, no del PP del País Vasco sino... del PP en Guipúzcoa (!!).
  • Las secciones de "antepasados" por lo general no deberían estar ocultas: cuando son relevantes (realeza y cosas así, principalmente) deberían estar desplegadas por defecto y cuando no tienen mucha importancia probablemente podría contemplarse la opción de no incluirlas y punto, pero bueno.
  • Los datos accesorios en las sucesiones deberían evitarse (esto ocurre en las fichas y no en las otras), donde con los políticos, además de su cargo, su "símbolo", su predecesor, su sucesor, su fecha de inicio, su ficha de fin, etc, se listan, también, muchas veces, el monarca reinante, el gabinete, el presidente del Gobierno, etc, creando fichas monstruosamente largas. Véase el caso de Soraya Sáenz de Santamaría.
  • Las sucesiones imaginativas deberían evitarse (en las fichas). Véase el caso de don Francisco Franco Parera. Caudillo de España por la gracia de dios, cuyo predecesor como caudillo fue Manuel Azaña y su sucesor en la Caudillería el señor Juan Carlos I (?). Que sí, que se incluye una acotación de "Presidente de la República" y "Rey de España" debajo, pero esto si bien esto intenta ofrecer contexto solo abunda en el barroquismo y el kitsch de la plantilla. Este caso medio se arregló en el pasado, pero volvieron a la carga. Con su pan se lo coman.
  • Otro clásico son los "predecesor = cargo inexistente", "sucesor = cargo desaparecido". ¿Hacen falta esas alforjas para ese viaje?
  • En las tablitas de "sucesiones" de ciudades... pues la mayor parte de las veces son sucesiones no muy trascendentes, que uno mucha veces deja en el artículo por no molestar a quien lo puso originalmente y no trabar la "navegación sucesoria" (porque o la quitas de toda la sucesión de artículos o... la dejas en todos, eliminándola parcialmente en algún artículo como que le cortas el rollo al hipotético lector aburrido que se entretiene cliqueando para navegar por toda la serie), pero que si de mí dependiera las borraría.
Y así una detrás de otra. Yo ya hace mucho tiempo que dejé de usar sucesiones tanto en fichas como en la parte final de los artículos. Muerto el perro... Al fin y al cabo, los pocos artículos en que podría uno pensar que sí es verdaderamente necesario mostrar una pomposa sección de "sucesión" ya existen; los que creo son de un perfil lo suficientemente bajo como para que no ocurra absolutamente nada por no detallar a quién sucedió en qué en una tabla o similar.
Así en general, entiendo que vendría bien consensuar unas buenas prácticas, pero supongo que es muy complicado por la diversidad de opiniones y circunstancias, las inercias de décadas, los vicios, etc, además de que el mejor y más práctico proceder que se me ocurre es, sencillamente, en la mayor parte de los casos, no usar sucesiones en ningún sitio. Suerte. strakhov (discusión) 20:22 18 ago 2023 (UTC)Responder[responder]
Strakhov: perdón por mi ignorancia ¿don Francisco Franco Parera? Manolo (Desfógate) 21:02 18 ago 2023 (UTC)Responder[responder]
Perdonado. Llamar a la gente de forma sarcástica con el segundo apellido del tenista español es un meme de internet. No puedo explicártelo más ni creo que merezca la pena. strakhov (discusión) 21:07 18 ago 2023 (UTC)Responder[responder]
Qué susto. Estaba plenamente convencido de que quien había regido mi infancia y parte de mi juventud era Bahamonde. Gracias por la aclaración. No conocía ese dato. Manolo (Desfógate) 21:13 18 ago 2023 (UTC)Responder[responder]
Bahamonde soy yo y no rijo a nadie, ¿él no era algo Blanco? A mí igual me sorprendió, pero di por hecho que era algún chiste de Strakhov que no afectaba el desarrollo de la conversación. Saludos. Lin linao ¿dime? 22:06 18 ago 2023 (UTC)Responder[responder]
Yo veo tres opciones:
  • A. Se quitan todas las sucesiones de la ficha y se trasladan al final del artículo. Esto acorta la longitud de la ficha.
  • B. Se ponen todas las sucesiones en la ficha y se quitan del final del artículo. Esto puede dar lugar a fichas de longitud interminable.
  • C. En la ficha se pone un máximo de dos o tres entradas relevantes de sucesiones. La lista completa de sucesiones se pone al final del artículo. Posiblemente un bot pueda hacer la traslación desde la ficha al final del artículo. Prefiero esta opción C.
Jzh2074 (discusión) 13:31 20 ago 2023 (UTC)Responder[responder]
Yo veo una opción más: se quitan todas (o casi todas) las sucesiones tanto de ficha como final del artículo y se mueven a anexos, donde el lector puede encontrar la sucesión completa. A dichos anexos redirigen los nombres de los cargos, que se enlazan en ficha y, cuando se considera conveniente, cuerpo de artículo. A lo sumo se conservan en fichas sucesiones de monarcas y, siendo generosos, presidentes. strakhov (discusión) 16:09 20 ago 2023 (UTC)Responder[responder]
En general, veo la opción de Strakhov como la mejor si hay que elegir alguna por defecto. Cuando se da el caso C donde hay claramente un grupo de dos o tres sucesiones principales, me da igual que estén en un lado u otro (incluso potencialmente duplicado), pero abrimos discusiones interminables sobre cuáles son los cargos "más importantes", sucesiones interrumpidas (¿ponemos sucesión en A, B y D pero no en C porque ese sí tenga 12 cargos?) la relevancia de escudos u otros temas estilísticos (separamos o compactamos las tablas...). Por poner otro ejemplo de cómo acaban algunos artículos: Conde de Romanones#Enlaces_externos. Tiene 17 sucesiones al final del artículo, en dos bloques diferentes (¿?), con 15 repeticiones consecutivas del mismo escudo, más otros 9 cargos en la infobox (de los cuales, tres no están no están listados abajo). Sin consensos detallados sobre implementar cargos en {{sucesión}} o {{ficha de persona}}, el tener un anexo cumple el mismo papel que las sucesiones en ficha o final del artículo y lo hace de forma más coherente y sistemática. Y es para lo que se pidió ese espacio de nombres específico a Wikimedia.
Adicionalmente, creo que evita mandar mensajes equivocados a los novatos. Para los que hacemos mantenimiento, vemos muchos artículos que se borran por ser CVs. Tener artículos como algunos de los que se han enlazado genera discusiones adicionales con novatos que preguntan por qué le borraron el artículo X, con su lista de concejalías y microcargos de partido, que básicamente imitaba lo indicado por Strakhov y yo. Tenemos artículos relevantes pero con secciones así de malas (4 cargos inferiores a alcalde, 4 cargos de partido... puestos en igualdad a dos legislaturas de presidente autonómico) que luego algún aficionado a la política bienintencionado duplica o triplica en infoboxes y tablas de sucesión. Eso lo imitan algunos cuando intentan escribir el artículo sobre el alcalde de su pueblo (que probablemente fue previamente concejal, secretario de la agrupación local del partido, parte de la comisión provincial del partido...). Luego eso es visto por algún patrullero, se lleva un {{destruir}} por redacción promocional/pruebas de edición/etc y el autor se queda sorprendido porque había seguido tal o cuál artículo usando las mismas plantillas, logos y escudos.--FAR, (Libro de reclamaciones) 08:24 21 ago 2023 (UTC)Responder[responder]

El "Manual de estilo" de Wikipedia en formato .pdf[editar]

Creo que debería prepararse una versión descargable del "Manual de Estilo" para los editores/usuarios de Wikipedia (pdf, p. ej.). Sería muy útil para colaboradores que trabajan en países con conectividad irregular e inestable, que necesitan asegurarse de los criterios para la edición, de modo que estos puedan consultar y estudiar offline las normas de edición del proyecto.

(Es mi caso). HM (discusión) 01:55 21 ago 2023 (UTC)Responder[responder]

@HM199: Se puede descargar en formato PDF. Anibal Maysonet (discusión) 01:57 21 ago 2023 (UTC)Responder[responder]
¡Gracias! HM (discusión) 02:10 21 ago 2023 (UTC)Responder[responder]