Discusión de Wikipedia:Política de bots

RFC: ServidorWP:CREAR MASIVOdeWP:BOTPOL

La siguiente discusión es un registro archivado de una solicitud de comentarios . No la modifique. No se deben realizar más modificaciones a esta discusión. A continuación se incluye un resumen de las conclusiones a las que se llegó.

El apoyo parece lo suficientemente abrumador como para que no me preocupe por WP:INVOLVED . Pero si alguien realmente no está de acuerdo por alguna razón, supongo que lo revertiré. Anomie ⚔ 23:38, 13 de agosto de 2024 (UTC) [ responder ]

En 2009 , la comunidad promulgó por primera vez una restricción a la creación masiva de artículos. La política resultante se incluyó en la política de WP:Bot, ya que el impulso era la creación masiva mediante herramientas automatizadas. Incluso entonces, surgió la preocupación sobre si WP:BRFA era el foro adecuado para esto, pero en ese momento prevaleció la idea de que "lo suficientemente bueno".

En los años transcurridos desde entonces, hemos tenido varias discusiones en las que esto se ha convertido en un problema. Posiblemente, la más destacada fue Wikipedia:Comité de arbitraje/Solicitudes de comentarios/Creación de artículos a gran escala/Declaración final n.° Pregunta 17: Enmendar WP:MASSCREATE , donde tres de los siete puntos de "oposición" se basan en que WP:BOTPOL es el lugar equivocado.

Personalmente, estoy cansado de ver a WP:BOTPOL y WP:MEATBOT desquiciarse en las discusiones sobre qué tipos de creaciones en masa que no son completamente bots están o pueden estar "cubiertas" por WP:MASSCREATE . Por lo tanto, propongo la pregunta:

¿Debería WP:MASSCREATE separarse de la política de WP:Bot ?

En caso de que la respuesta sea afirmativa, se realizarán los siguientes cambios en el texto de la política. La intención es mantener el significado actual en la medida de lo posible, eliminando las partes específicas de WP:BOTPOL :

Cualquier tarea de creación de páginas de contenido automatizadas o semiautomatizadas a gran escala debe ser aprobada~~en Wikipedia:Bots/Solicitudes de aprobación~~ Por la comunidadEste requisito se aplicó inicialmente a los artículos , pero desde entonces se ha ampliado para incluir todas las "páginas de contenido" , es decir, en sentido amplio, las páginas diseñadas para que los lectores las vean a través del espacio principal . Entre ellas se incluyen los artículos , las categorías más visibles , los archivos alojados en Wikipedia, los avisos de edición del espacio principal y los portales . Aunque no se decidió ninguna definición específica de "gran escala", no se opuso a la sugerencia de "cualquier cosa que supere las 25 o 50" .~~También se recomienda encarecidamente (y BAG puede exigirlo) que~~ dodoAporte de la comunidadpuedeSe solicitarán en WP:Village pump (propuestas) y en las páginas de discusión de cualquier WikiProject relevante.~~Operadores de bots~~ CreadoresDebe garantizar que todas las creaciones estén estrictamente dentro de los términos de su aprobación.

Según una RfC de 2022 , todos los artículos creados en masa (excepto aquellos que no están obligados a cumplir con WP:GNG ) deben citar al menos una fuente que contribuya de manera plausible a GNG, es decir, que constituya una cobertura significativa en una fuente secundaria independiente y confiable.

Las alternativas a la creación de grandes cantidades de páginas de contenido incluyen la creación de las páginas en lotes pequeños o la creación de las páginas de contenido como subpáginas de un WikiProject relevante para ser trasladadas individualmente al espacio público después de que cada una haya sido revisada por editores humanos. Si bien el uso de estas alternativas no elimina la necesidad de~~una BRFA~~ aprobación, podría obtener más apoyo de la comunidad en general.

La creación masiva por medios automatizados puede requerir además la aprobación, tal como se especifica en Wikipedia:Política de bots . La aprobación de un bot para la creación masiva no anula la necesidad de consenso de la comunidad para la creación en sí, ni el consenso de la comunidad para una creación anula la necesidad de aprobación del bot en sí.

Tenga en cuenta que mientras~~El tipo WP: MEATBOT~~No se permite la creación de páginas sin contenido (como redirecciones desde nombres sistemáticos o categorías de mantenimiento).Obligado a pasar por un BRFA formal de forma predeterminada Cubierto por esta política de creación masiva,~~WP:BOT DE CARNE~~ otras políticas, como Wikipedia:Política sobre bots ,Todavía aplicay~~sis~~.

Si la respuesta es sí, no me importa mucho si el destino es una nueva página de política independiente, WP:Editing policy o alguna otra política existente. Para evitar que esto falle debido a la falta de consenso sobre dónde colocarlo, si no hay consenso sobre un destino específico, utilizaremos por defecto "una nueva página de política independiente" en Wikipedia:Mass page creation y las personas pueden iniciar una discusión de fusión por separado más adelante si lo desean.

La política del bot conservará un código que haga referencia a la nueva política. Las redirecciones existentes, como WP:MASSCREATE, se redireccionarán.

La creación masiva de páginas puede requerir la aprobación de la comunidad, además de una BRFA si el método de esa creación se encuentra dentro de esta política de Bots. BAG puede requerir que exista la aprobación de la comunidad para cualquier creación masiva de contenido antes de considerar la aprobación de un bot.

La aprobación de un bot para su creación en masa no anula la necesidad de un consenso de la comunidad para la creación en sí, ni el consenso de la comunidad para una creación anula la necesidad de aprobación del bot en sí. Los operadores de bots deben asegurarse de que todas las creaciones cumplan estrictamente con los términos de sus aprobaciones.

Encuesta (separar MASSCREATE de BOTPOL)

Apoyo Como proponente. Anomie ⚔ 23:15, 9 de julio de 2024 (UTC) [ responder ]
No estoy en contra , pero personalmente no le veo el sentido. Headbomb { t · c · p · b } 23:34, 9 de julio de 2024 (UTC) [ responder ]
Soporte . La ubicación actual de esta política está causando problemas y esta parece una forma muy sencilla de solucionarlo. Thryduulf ( discusión ) 23:38 9 jul 2024 (UTC) [ responder ]
Apoyo porque creo que Anomie da tres razones prácticas a continuación. Me inclino ligeramente por agregarlo como una nueva sección en Wikipedia:Política de edición , tal vez una que llame ==Creación de artículos== que contenga principalmente una oración sobre Wikipedia:Notabilidad , y luego la redacción actual (con estos pequeños ajustes) como una subsección. WhatamIdoing ( discusión ) 04:02, 10 de julio de 2024 (UTC) [ responder ]
Apoyo su traslado a Wikipedia: política de edición , según WAID, Anome y lo que he dicho anteriormente. –  Joe ( discusión ) 12:21, 10 de julio de 2024 (UTC) [ responder ]
Apoyo como paso para dejar esto más claro.Las rododendritas ^hablan\\ 13:53, 10 de julio de 2024 (UTC) [ responder ]
Soporte Me pregunto si mover la mitad superior de MEATBOT debería hacerse al mismo tiempo, ambos tienen que ver con la edición en lugar de la política de bots. -- LCU A ctively D isinterested « @ » ° ∆t ° 18:24, 10 de julio de 2024 (UTC) [ responder ]
No recomiendo hacer esto al mismo tiempo. (Además, creo que tendría que ser algo así como la primera y la tercera oración del primer párrafo, que es un nivel de complejidad que probablemente debería discutirse por separado). WhatamIdoing ( discusión ) 04:44 15 jul 2024 (UTC) [ responder ]
Soporte Ahora viene la parte difícil... escribirlo. North8000 ( discusión ) 20:18 15 jul 2024 (UTC) [ responder ]
Esta propuesta ya incluye una versión escrita de la política de división. –  Joe ( discusión ) 11:09, 18 de julio de 2024 (UTC) [ responder ]
Apoyo las tres razones que Anomie expuso a continuación. La situación actual siempre me pareció un compromiso extraño. Pinguinn 🐧 06:59, 16 de julio de 2024 (UTC) [ responder ]
Apoyo a Anomie, aunque no estoy seguro de estar de acuerdo con la redacción del borrador, pero se puede modificar más adelante. Sohom ( discusión ) 20:08 21 jul 2024 (UTC) [ responder ]
Apoyo per nom. Tiene más sentido. El status quo no siempre tiene que permanecer así solo porque técnicamente funciona. C F A 💬 22:18, 28 de julio de 2024 (UTC) [ responder ]

Discusión (separar MASSCREATE de BOTPOL)

Por favor, no intenten discutir más cambios radicales aquí. Guárdenlos para una RFC separada que puedan realizar después de que esto pase. Les pido a los editores no involucrados que eviten cualquier discusión de este tipo si alguien intenta iniciarla aquí, y a los que cierran el tema que ignoren cualquier voto de apoyo que solicite tales cambios. Anomie ⚔ 23:15, 9 de julio de 2024 (UTC) [ responder ]

Al leer esto nuevamente, mi preocupación es que la redacción que usas, y la eliminación de BOTPOL, significarán que WP:MEATBOT ya no se aplica, y por lo tanto no habrá restricciones en la creación masiva de artículos por métodos tales como boilerplates, que algunos editores argumentan que no están cubiertos por semiautomatizados.

Para evitar que esta propuesta cambie el significado de esta sección, ¿podemos insertar "como un bot" en la primera oración? BilledMammal ( discusión ) 23:20 9 jul 2024 (UTC) [ responder ]

@BilledMammal ¿Dónde propones agregarlo específicamente? Thryduulf ( discusión ) 23:36 9 jul 2024 (UTC) [ responder ]

Cualquier tarea de creación de contenido a gran escala automatizada o ~~semiautomatizada~~ , o de tipo bot. BilledMammal ( discusión ) 00:17 10 jul 2024 (UTC) [ responder ]

( editar conflicto ) No estoy de acuerdo con que esta propuesta cambie el significado de esa manera. La primera oración ya mantiene la redacción existente sobre cualquier tarea de creación de páginas de contenido automatizada o semiautomatizada a gran escala .

Además, WP:MEATBOT es en realidad solo una prueba de patos ; se supone que evita que la gente alegue que una política sobre ediciones automáticas no se aplica porque sus ediciones son manuales para rellenar texto estándar o lo que sea, diciendo que si parece automatizado, podemos tratarlo como tal de todos modos. En realidad, no hace nada para que las ediciones manuales impulsadas por texto estándar caigan bajo WP:MASSCREATE cuando no estén ya en contra del consenso o sean disruptivas de alguna otra manera.

Además, en mi opinión, probablemente sería mejor que apoyaras esto, porque si se aprueba, "La política de bots no puede regular el comportamiento humano" y "no tiene sentido que las ediciones humanas se aprueben a través de BRFA" ya no serán objeciones válidas a una propuesta de eliminar "automatizado o semiautomatizado" de la primera oración (porque ya no será parte de la política de bots), y si puedes lograr que se apruebe, entonces no tendrás que abusar de WP:MEATBOT en absoluto. Anomie ⚔ 23:43, 9 de julio de 2024 (UTC) [ responder ]

Por el momento, tenemos una política que se aplica a la creación masiva manual de bots, mientras que el cambio propuesto elimina ese aspecto.

Teniendo en cuenta que la intención es mantener el significado actual en la medida de lo posible mientras se eliminan los bits específicos de WP:BOTPOL , tendría más sentido eliminar automated o semi-automated . Estos son bits específicos de BOTPOL y al eliminarlos se asegura de que la sección que está eliminando de BOTPOL realmente tenga aplicabilidad fuera de BOTPOL. BilledMammal ( discusión ) 00:32 10 jul 2024 (UTC) [ responder ]

Creo que estás intentando introducir un cambio de redacción que intenta hacer que tus argumentos existentes sean más fáciles de respaldar. Como te pedí anteriormente, hagamos primero esta RFC simple, luego puedes intentar convencer a la comunidad en general para que acepte tus cambios. Anomie ⚔ 01:18, 10 de julio de 2024 (UTC) [ responder ]

En este momento, estás intentando introducir un cambio de redacción que hace que el argumento sea más difícil de sustentar. Por eso, esta no es la RfC simple que pensé que era. BilledMammal ( discusión ) 01:19, 10 de julio de 2024 (UTC) [ responder ]

Bueno, tú también eres libre de creer lo que quieras, por muy equivocado que sea. Anomie ⚔ 01:22, 10 de julio de 2024 (UTC) [ responder ]

No creo que en realidad estés intentando colar nada, pero me molestó un poco que sugieras que lo estaba haciendo.

Lo que sí creo es que esto supone un cambio respecto del status quo. Creo que el lenguaje que propuse a Thryduulf mantendría el status quo, mientras que el lenguaje que le propuse a usted lo cambiaría en la dirección opuesta. BilledMammal ( discusión ) 01:32 10 jul 2024 (UTC) [ responder ]

Te has convencido de que WP:MEATBOT significa que si puedes entrecerrar los ojos lo suficiente para convencerte de que algo es "similar a un robot", entonces puedes expandir el alcance de WP:BOTPOL para cubrir claramente las acciones humanas, por lo que quieres agregar "similar a un robot" para intentar reforzar eso. Eso no es más correcto que WhatamIdoing insistiendo anteriormente en que WP:MEATBOT trata sobre evitar la edición de alta velocidad y nada más; ella podría decir hipotéticamente que eliminar WP:MASSCREATE de WP:BOTPOL elimina una implicación de que solo se aplica a la edición de alta velocidad (ya que solo la edición rápida, en su opinión, es "similar a un robot") y, por lo tanto, quiere que diga Cualquieraalta velocidadTarea de creación de páginas de contenido automatizada o semiautomatizada a gran escala para "preservar" esa interpretación. Anomie ⚔ 02:00, 10 de julio de 2024 (UTC) [ responder ]

@BilledMammal, no creo que tengas que preocuparte por esto. MEATBOT se aplica a todas las ediciones que sean "ediciones de alta velocidad o a gran escala que a) sean contrarias al consenso o b) causen errores que un humano atento no cometería". Incluso si MASSCREATE termina en otra página, o incluso si MASSCREATE no existiera en absoluto, MEATBOT se aplicaría a las mismas ediciones que aplica ahora.

Una forma de verlo es que, si se aprueba, habría dos políticas oficiales™ que se podrían considerar violadas. WhatamIdoing ( discusión ) 03:57 10 jul 2024 (UTC) [ responder ]

@ Headbomb : Veo al menos tres puntos en esto:

Poner fin a la ficción de que BAG aprueba las creaciones en masa. La mayoría de las veces ya decimos "busquen el consenso en WP:VPR primero", y luego le damos el visto bueno si el bot pasa las pruebas.
Obteniendo argumentos sobre cómo WP:MASSCREATE debería aplicarse a los no bots a partir de esta página, que se supone que trata sobre la política de bots .
Evitar que BilledMammal tenga que abusar de WP:MEATBOT para argumentar que WP:MASSCREATE debería cubrir las creaciones masivas que no sean de bots, permitiéndoles argumentar a favor de cambiar la política para decir eso directamente.

HTH. Anomie ⚔ 23:55, 9 de julio de 2024 (UTC) [ responder ]

La discusión anterior está cerrada. No la modifique. Los comentarios posteriores deben realizarse en la página de discusión correspondiente. No se deben realizar más modificaciones a esta discusión.

Bots de código abierto

Me gustaría hacer una verificación de temperatura (explícitamente no una RfC) como seguimiento a la discusión en este BRFA , sobre cómo se sienten las personas acerca de cambiar los requisitos del código fuente. Actualmente, el lenguaje en la política de bots es:

Se recomienda, pero no se exige, que los autores de procesos de bots publiquen el código fuente de sus bots. y para los bots de administración: se recomienda que el código fuente de los bots de administración esté abierto, pero si el operador decide mantener todo o parte del código no visible públicamente, debe presentar dicho código para su revisión a pedido de cualquier miembro o administrador de BAG.

Me gustaría reemplazarlo con algo como: "Se espera que los autores de procesos de bots publiquen el código fuente de su bot de manera pública bajo una licencia de código abierto para facilitar la colaboración y la bifurcación. Si un autor desea mantener el código fuente privado, debe solicitar una exención de BAG durante el proceso de aprobación del bot. Los miembros de BAG pueden rechazar solicitudes únicamente sobre la base de que el código fuente no sea de código abierto". Y algún tipo de cláusula de derechos adquiridos para los bots de código cerrado actuales.

La lógica es 1) permitir que la gente sugiera mejoras para los bots o señale posibles errores como un paso de revisión técnica, y 2) cuando los bots o los encargados de su mantenimiento desaparezcan inevitablemente, exigir que exista un camino para que alguien más se haga cargo del bot sin tener que empezar desde cero. Creo que el movimiento Wikimedia ha avanzado en esta dirección, al exigir licencias de código abierto para los bots que se ejecutan en Toolforge (la gran mayoría de nuestros bots) y hay una gran cantidad de lugares donde publicar su código. O en otras palabras, el código abierto debería ser la norma, el código privado debería ser la excepción.

Algunas excepciones: estoy seguro de que la gente puede pensar en casos extremos en los que no se desee publicar código; si esos casos se convierten en BRFA reales, con gusto dejaré en manos de BAG la decisión sobre si la excepción está justificada o no. En la práctica, creo que estaría bien que la gente hiciera cambios, probara su código y luego lo publicara poco después. No creo que necesitemos un requisito estricto de que el código debe ser de código abierto antes de ejecutarlo en Wikipedia.

Entonces, ¿qué opina la gente sobre esto? ¿Es una propuesta razonable? O si no apoyarías que se formalice algo como esto, ¿por qué no? Legoktm ( discusión ) 03:54 5 sep 2024 (UTC) [ responder ]

Me parece bien. Espero que también haya códigos de fuente abierta para los bots. Ayudó a hacerse cargo de la tarea AdminStats (aunque terminamos buscando una copia de los códigos en Toolforge). Sin embargo, ¿se puede extender la cláusula de exención a las nuevas solicitudes de tareas de los bots actuales, ya que las nuevas tareas aún pueden utilizar los códigos de fuente cerrada? – robertsky ( discusión ) 04:03, 5 de septiembre de 2024 (UTC) [ responder ]

No veo por qué deberíamos incluir en la política el lema "deben ser abiertos, a menos que pidas una excepción, que podemos denegar", en lugar del actual "incentivamos, pero no obligamos, a los bots de código abierto". Headbomb { t · c · p · b } 10:00, 5 de septiembre de 2024 (UTC) [ responder ]

@ Headbomb : ¿Podrías explicarnos por qué crees que no debería hacerse? (Personalmente, no creo que necesitemos una excepción, solo esperaba que la gente se opusiera sin una) Legoktm ( discusión ) 15:35, 5 de septiembre de 2024 (UTC) [ responder ]

También siento curiosidad por esto, pero creo que permitir excepciones es algo razonable. Imaginemos que alguien viniera a nosotros y nos dijera: "La empresa para la que trabajo tiene un sistema de detección de abusos que es diez veces mejor que el que estáis utilizando ahora. Estamos dispuestos a dejaros usarlo sin coste alguno, pero lamentablemente no puedo poner el código a vuestra disposición". Tener esa excepción nos da la posibilidad de aceptar o rechazar esa oferta como nos parezca adecuado en ese momento. No tener esa excepción nos obliga a actuar. Creo que es razonable.

Ya tenemos acuerdos de ese tipo con algunos proveedores de detección de proxy IP (soy cauteloso con los nombres de los proveedores solo porque no estoy seguro del estado de estas relaciones). Debido a que solo se utilizan (hasta donde yo sé) como back-end para algunas herramientas interactivas, no son competencia de BAG. Pero ciertamente podría imaginar a alguien que quisiera construir una herramienta BAGgy que use uno de esos servicios como back-end. Por mucho que crea en el software libre en todas partes, tampoco quisiera que nos disparemos en el pie para defender nuestros principios. RoySmith (discusión) 16:04 5 sep 2024 (UTC) [ responder ]

Es posible que no quieras publicar tu código porque es burdo o poco elegante. También podrías estar haciendo cosas que están "bien" con el código privado, pero no con el código público, como tener "si la contraseña = sw0rdf!sh continúa, de lo contrario falla" en lugar de lo que deberías estar haciendo con las contraseñas y los inicios de sesión. O podrías estar usando código de otra persona para el que tienes permiso de uso, pero no tienes permiso para distribuir. O podrías estar usando código de fuente cerrada que compraste, pero no tienes derechos para distribuir.

Estoy de acuerdo en que es inequívocamente mejor que las cosas sean de código abierto. Por eso se debería fomentar. Pero los programadores voluntarios son un recurso extremadamente limitado, así que, cuantas menos barreras de entrada/participación tengamos, mejor, en mi opinión. Headbomb { t · c · p · b } 19:12, 5 de septiembre de 2024 (UTC) [ responder ]

~~Fuerte apoyo~~ Exigir que los bots sean de código abierto me parece una buena idea por razones que van desde las culturales ( ~~apoyar los objetivos~~ que promueven los ideales del movimiento Wikimedia) hasta la seguridad (revisión de código) y la recuperación ante desastres (poder continuar con el funcionamiento de servicios críticos en caso de que el desarrollador original desaparezca). RoySmith (discusión) 12:15 5 sep 2024 (UTC) [ responder ]
Principalmente me opuse a esto en el BRFA anterior porque sentí que violaba las normas actuales. Pero no me opongo a ello en general si hacemos un cambio en BOTPOL. Hay importantes ventajas de mantenimiento al tener el código de bot de código abierto. Los voluntarios que escriben código crítico pierden interés o se vuelven inactivos todo el tiempo. Honestamente, tal vez una propuesta para requerir Toolforge para bots que no sean AWB también podría valer la pena considerar. La combinación de código de código abierto más Toolforge sería la situación ideal para rescatar bots abandonados. Finalmente, también tuvimos una situación recientemente en la que un operador falleció y su bot fue bloqueado inmediatamente y bloqueado globalmente. Evitar bloquear bots en funcionamiento lo antes posible, dándonos tiempo para que los bifurquemos y reemplacemos adecuadamente, también podría valer la pena agregar a BOTPOL. – Novem Linguae ( discusión ) 16:18, 5 de septiembre de 2024 (UTC) [ responder ]
Este es un buen punto; como cualquiera que haya intentado portar algo sabe, tener el código fuente es solo la mitad de la batalla. Mover cosas a un nuevo entorno operativo también puede ser un dolor de cabeza; exigir que todo se ejecute en Toolforge (o Cloud VPS) sería algo bueno en mi humilde opinión. Sin embargo, no estoy seguro de dónde trazas el límite. Algunas personas insistirían en que todo se ejecute en un contenedor Docker. Eso me volvería loco. Algunas personas insistirían en que solo usemos phab, gitlab, etc. Eso también me volvería loco. RoySmith (discusión) 17:01 5 sep 2024 (UTC) [ responder ]
Creo que estás subestimando cómo los requisitos adicionales sucesivos dificultan la atracción de nuevos voluntarios. No es un gran problema para los desarrolladores experimentados, pero ya hay mucho que abordar como desarrollador nuevo. Por supuesto, si el objetivo es reducir la cantidad de bots abandonados, desalentar la creación de nuevos bots definitivamente ayudará. Creo que sería mejor fomentar prácticas como la disponibilidad del código fuente, los planes de sucesión, etc. con un panel de control, reconocimiento y otros enfoques. Daniel Quinlan ( discusión ) 20:14, 5 de septiembre de 2024 (UTC) [ responder ]
Me opongo firmemente al cambio propuesto. La política actual fomenta el código abierto sin ser demasiado restrictiva ni desalentar a las personas a enviar solicitudes. Como desarrollador de código abierto, creo que eso es algo bueno. Pero exigir que todos los bots sean de código abierto podría desalentar algunos proyectos potenciales, especialmente si usan código propietario o necesitan usar componentes que no son libres. Para algunos proyectos, también hay razones relacionadas con la seguridad para no abrir el código fuente por las mismas razones por las que tenemos filtros de edición privados. Finalmente, si hay bots específicos que son realmente críticos y no son de código abierto, deberíamos identificar esos bots y solicitar bots de reemplazo que serían de código abierto, o pedirle a la WMF que escriba, mantenga y opere bots de reemplazo para esas funciones. La política actual está bien escrita. Daniel Quinlan ( discusión ) 21:04, 5 de septiembre de 2024 (UTC) [ responder ]
Parte de mi preocupación es que si es necesario mantener los bots existentes, esto implicaría fuertemente que habría un efecto desalentador en las propuestas futuras, tanto para los bots existentes como para los nuevos. Preferiría comenzar con una revisión de los bots existentes para evaluar su criticidad y los planes de sucesión, y luego considerar mejoras basadas en la evaluación. Los cambios de política pueden ser un enfoque, pero creo que brindar estímulos que no desalienten proyectos futuros y que se puedan aplicar a todos los bots sería más efectivo. Daniel Quinlan ( discusión ) 22:25, 5 de septiembre de 2024 (UTC) [ responder ]
Agradezco los comentarios que me han dado las personas y responderé un poco más tarde, después de analizarlos, pero, por favor, ¿podemos evitar los votos en negrita? Me gustaría centrarme en la discusión y los fundamentos, no en las votaciones. Legoktm ( discusión ) 21:39 5 sep 2024 (UTC) [ responder ]
Perdón si el texto en negrita pareció duro, estaba siguiendo el formato de un comentario anterior. Agradezco que hayas hecho un seguimiento de la discusión para discutirla abiertamente, lo que reducirá las probabilidades de que se vuelva a discutir en futuras BRFA aleatorias. Daniel Quinlan ( discusión ) 22:10, 5 de septiembre de 2024 (UTC) [ responder ]
Creo que hay que tener en cuenta las circunstancias. Si el bot va a ser una tarea simple que se realizará una sola vez, probablemente sea menos crítico tener un plan de sucesión en marcha. Si se trata de un bot que va a respaldar procesos clave del flujo de trabajo, entonces es más importante tener un plan para garantizar que la tarea se pueda transferir. Estoy de acuerdo en que, idealmente, todo el código sería de código abierto (manteniendo cerrada cualquier configuración privada necesaria) y con un entorno de desarrollo y ejecución relativamente uniforme, pero, en términos prácticos, no creo que la Wikipedia en inglés pueda permitirse limitar su grupo potencial de desarrolladores a ese grado. isaacl ( discusión ) 23:48, 5 de septiembre de 2024 (UTC) [ responder ]
Apoyaría inequívocamente algo más fuerte para los bots que se espera que sigan funcionando, ya que "necesitamos código abierto" y definitivamente alentaría algo como el OP incluso para ejecuciones más cortas. Lo siento, pero no podemos seguir dependiendo de bots de código cerrado y código privado. (Ya lo he dicho varias veces). Y lo siento, si tu código es una mierda, así es como funciona el código abierto. O puedes superar tu miedo a publicar algo que está hackeado (como si nadie más hubiera hackeado código para producción, ¿sabes cómo comenzó MediaWiki moderno?) o puedes hacer otra cosa con tu tiempo (que estoy seguro que también será productivo para los objetivos de la wiki). Izno ( discusión ) 18:00, 29 de septiembre de 2024 (UTC) [ responder ]
Si bien tener el código disponible es un buen comienzo, si vamos a introducir algunos requisitos para la planificación de la sucesión, no creo que debamos detenernos allí. Demasiadas personas piensan que si el código fuente está disponible, todo está bien. Pero si se trata de código Haskell, por ejemplo, el grupo de posibles contribuyentes es significativamente menor. Entonces, si comenzamos por esta ruta, creo que también debemos incluir cosas como que el bot debe ejecutarse en los servidores de Toolforge, se recomienda encarecidamente que el lenguaje sea de una lista de lenguajes compatibles y que haya al menos otro mantenedor involucrado activamente. isaacl ( discusión ) 21:34, 29 de septiembre de 2024 (UTC) [ responder ]
Antes de considerar una política más estricta para algunos casos, debemos ser específicos sobre qué bots son realmente críticos . Exigir a las personas que codifiquen en lenguajes específicos o que se pongan al día con Toolforge además de aprender las API de MediaWiki para un bot que hace lo suyo silenciosamente, que no es de misión crítica, etc., será contraproducente. Necesitamos que más personas, especialmente los recién llegados a la codificación de Wikipedia, escriban bots más útiles, y deberíamos esforzarnos por mantener el costo de entrada lo más bajo posible. El caso ideal siempre será un código fácilmente portable y bien mantenido, pero ningún requisito nos impedirá evitar algunas realidades inevitables del ciclo de vida del software y lo perfecto es enemigo de lo bueno . Daniel Quinlan ( discusión ) 00:13, 30 de septiembre de 2024 (UTC) [ responder ]
Abordemos una cosa a la vez. Coincido en que tiene sentido establecer una mayor expectativa respecto de estas otras cualidades, pero creo que tenemos que empezar por el principio de que "alguien podría, incluso en teoría, retomar esto y seguir adelante". Izno ( discusión ) 00:52 30 sep 2024 (UTC) [ responder ]
Creo que se necesita un poco más para sentar las bases que permitan a otra persona operar teóricamente un bot determinado. Podría ser una de las siguientes: la herramienta se ejecuta en toolforge, hay varios mantenedores activos o hay suficiente documentación escrita actualizada que describe la pila de software y el entorno de ejecución. Y, desafortunadamente para los aficionados a los lenguajes más oscuros, creo que debería haber una lista de lenguajes altamente recomendados. isaacl ( discusión ) 01:28, 30 de septiembre de 2024 (UTC) [ responder ]
Por un lado, apoyo todas estas cosas como buenas obvias. Y a eso añadiría que el código fuente tiene que estar disponible públicamente en un sistema de control de código fuente estándar (que hoy en día significa básicamente git). Una cosa es decir que el código está bajo una licencia FOSS, pero si el mecanismo de distribución es descargar un archivo shar con ROT-13 desde un servidor gopher, bien podría no existir. Y debería tener un conjunto de pruebas completo. Y un sistema de seguimiento de problemas. Y revisiones de código. Bueno, ya ves a dónde va esto. Todas estas cosas son buenas prácticas esenciales de ingeniería de software, pero cada una de ellas también es una barrera de entrada para mucha gente, y en algún momento tenemos que tomar una decisión inteligente sobre dónde queremos trazar la línea. Si ahuyentamos a todos los posibles contribuyentes de código con requisitos onerosos, sin duda resolveríamos el problema de la migración de herramientas porque no tendríamos ninguna herramienta. RoySmith (discusión) 01:58, 30 de septiembre de 2024 (UTC) [ responder ]
Sí, ya dije que no creo que Wikipedia en inglés pueda permitirse limitar su grupo de desarrolladores potenciales para todas sus herramientas. Creo que cuando se planea implementar una herramienta o un bot, debemos decidir qué tan importante es tener algún tipo de plan de sucesión en marcha. En muchos casos, podemos simplemente vivir con el riesgo. Para algunos procesos clave, es posible que queramos planificar una transición futura a diferentes mantenedores. isaacl ( discusión ) 02:33, 30 de septiembre de 2024 (UTC) [ responder ]
No tengo nada en contra de publicar mi código. Reconozco que la calidad del código está lejos de ser ideal, ya que no tengo mucho tiempo para trabajar en él, y mi decisión de usar C# puede no haber sido la mejor. Los bots se han abierto camino en algunos de nuestros procesos, por lo que podría ser bueno si alguien pudiera al menos ver lo que hacen en caso de que me pase algo. Tendría que revisar los archivos y agregar los avisos de derechos de autor correspondientes. No estoy seguro de qué se considera una licencia abierta; mi intención siempre fue usar GPLv3. Sin embargo, una vez que se aplica una licencia, será difícil cambiarla, por lo que sería necesaria una cláusula de exención. Y sí, mover cosas a un nuevo entorno operativo es un verdadero dolor de cabeza; Toolforge ahora insiste en que todo se ejecute en un contenedor Docker. Hacer que eso funcione ha sido agotador y habría sido imposible sin mucha ayuda de los administradores de Toolforge. Hawkeye7 (discutir) 20:25, 29 de septiembre de 2024 (UTC) [ responder ]
Actualmente, Toolforge requiere una licencia aprobada por OSI. Me parece que es la expectativa correcta. La comparación de licencias de software libre y de código abierto puede ser útil para su propia revisión de cómo podría licenciar su código. Izno ( discusión ) 00:54, 30 de septiembre de 2024 (UTC) [ responder ]
Encontré la política en Ayuda:Toolforge/Política de derecho a bifurcar. En realidad, todavía no la he implementado. Hawkeye7 (discutir) 04:56, 2 de octubre de 2024 (UTC) [ responder ]
Creo que la parte del contenedor de Docker consiste simplemente en elegir una imagen en Toolforge. No necesitas instalar Docker en tu computadora local, ni tampoco necesitas saber mucho sobre Docker, excepto el comando CLI que se debe ejecutar y qué imagen vas a elegir de la lista de imágenes. Mis bots están escritos en PHP y uso xampp localmente para ejecutarlos cuando estoy haciendo codificación y pruebas manuales. – Novem Linguae ( discusión ) 15:59, 30 de septiembre de 2024 (UTC) [ responder ]
No es una imagen, sino un paquete de compilación nativo de la nube. El paquete de compilación crea la imagen del contenedor. Tuve que conseguir que me instalaran un paquete de compilación de dotnet. Ejecutar Docker localmente no fue un problema; lograr que la aplicación funcione correctamente en ese entorno operativo requirió más esfuerzo. Hawkeye7 (discutir) 21:30, 30 de septiembre de 2024 (UTC) [ responder ]
Anteriormente, había pensado en conseguir que una aplicación .NET se ejecutara en Toolforge, pero no tenían ningún soporte "oficial", así que no me molesté en averiguarlo y concluí que tendría que ponerme en contacto con ellos para añadir este soporte. Esto se suma a todos los obstáculos que uno tiene que superar para averiguar cómo hacer las cosas allí. Nada de esto es fácil de usar, eso es seguro, hablando de barreras de entrada y todo eso. De todos modos, esto [1][2] no existía en ese momento. Es posible que te llame en algún momento para preguntarte cómo lo hiciste exactamente si no puedo averiguar cosas a partir de la documentación. Supongo que no registraste los pasos que seguiste para que funcionara. — HELL KNOWZ ∣ TALK 22:27, 30 de septiembre de 2024 (UTC) [ responder ]
Sí, registré los pasos que seguí. Hawkeye7 (discutir) 04:53, 2 de octubre de 2024 (UTC) [ responder ]

Bots con código fuente disponible

Lista

Ver: Wikipedia:Bots básicos

Discusión

En base a lo anterior, parece haber un consenso razonable de que la mayoría (si no todos) de los bots que realizan "funciones básicas" (mi frase) deberían tener su código publicado de modo que si el operador desaparece (intencionadamente o no), la funcionalidad se pueda trasladar de manera rápida/fácil/eficiente a un nuevo bot/operador que pueda hacerse cargo de la tarea. He comenzado una lista (actualmente vacía) arriba e invitaría a los editores a agregar y discutir la lista para que podamos comenzar a pedirles a los operadores que proporcionen el código si se considera necesario. Personalmente, creo que esta lista debería centrarse en las tareas de aprobación abierta (es decir, no en las ejecuciones únicas) para comenzar, pero si alguien quiere el código para las OTR, no dude en preguntar. Primefac ( discusión ) 19:30, 29 de septiembre de 2024 (UTC) [ responder ]

Creo que existe una tendencia entre la población de editores en general a pensar que, si el código está disponible, debería ser fácil para cualquiera entrar en el vacío y poner en funcionamiento rápidamente un bot, pero eso es una falacia. Creo que si vamos a introducir requisitos para la planificación de la sucesión, deberían abarcar un poco más (como comenté en un comentario anterior). isaacl ( discusión ) 21:37, 29 de septiembre de 2024 (UTC) [ responder ]

No veo ese consenso. Todos estamos de acuerdo en que es preferible. Pero la obligatoriedad es diferente. Headbomb { t · c · p · b } 00:51, 30 de septiembre de 2024 (UTC) [ responder ]

Creo que el consenso es que hay que adoptar una política más estricta que decir que es "preferible" (cosa que ya hacemos). Podríamos hacer algunas excepciones para los bots que llevan mucho tiempo en funcionamiento, como AAlertBot, que creo que es lo que más te preocupa. – SD0001 ( discusión ) 12:04 30 sep 2024 (UTC) [ responder ]

No veo tal consenso en absoluto. Headbomb { t · c · p · b } 15:21, 30 de septiembre de 2024 (UTC) [ responder ]

Una política obligatoria es una receta para el "consenso" para apagar bots o peor aún, eliminar los privilegios de los bots por ser un operador rebelde. ¿Qué otra cosa podría significar "obligatorio"? Es como ese dicho de la guerra de Vietnam: "Tuvimos que destruir un pueblo para salvarlo" (variaciones de esta cita). Isaacl tiene toda la razón en que descargar un montón de código fuente en GitHub no tiene sentido para cualquiera que intente instalarlo y operarlo. Y el funcionamiento de algunos bots requiere mucho entrenamiento que no es fácil de documentar. -- Green C 23:47, 30 de septiembre de 2024 (UTC) [ responder ]

Apaguen los bots . Imagino que cualquier nuevo requisito tendría una excepción para los bots aprobados antes del nuevo requisito. – Novem Linguae ( discusión ) 00:44 1 oct 2024 (UTC) [ responder ]

¿En qué parte de mi publicación dije que era obligatorio? No lo dije, por lo que no estar de acuerdo con algo que no dije es un poco extraño. Este subproceso trata sobre dar los primeros pasos: ahora mismo ni siquiera sabemos qué bots tienen bases de código abiertas o de libre acceso, o dónde están alojados, etc. Primefac ( discusión ) 12:38, 5 de octubre de 2024 (UTC) [ responder ]

Entiendo lo que todos quieren decir sobre el deseo de asegurarse de que los bots sigan funcionando sin problemas, pero no tengo claro que haya consenso para hacer obligatorio el código abierto. Me preocupa que:

El enfoque está en el código abierto y en agregar requisitos adicionales en lugar de tener planes de sucesión.
No hay definiciones claras para términos como "crítico" o "principal" y no tenemos una lista de los bots que se verían afectados.
Si dejamos en suspenso algunos bots, podríamos acabar con todas las desventajas que desalentarán el desarrollo futuro sin mejorar significativamente la continuidad.

Hasta ahora solo he escrito un bot, uno que es fácil de configurar y también de código abierto, pero probablemente no existiría si tuviera que producir código de código abierto antes de obtener la aprobación del proyecto o se me hubiera exigido usar Toolforge para mi primer proyecto. El problema que resuelve Protection Helper Bot ha sido un ticket de Phabricator desde 2012 y se propuso varias veces antes y desde entonces (como esta discusión en 2017 ). Deberíamos alentar a los nuevos desarrolladores a ayudar a resolver problemas de larga data en lugar de poner obstáculos, incluso si parecen obstáculos bajos para la mayoría de los desarrolladores de Wikipedia con experiencia. Daniel Quinlan ( discusión ) 01:03, 1 de octubre de 2024 (UTC) [ responder ]

Nunca dije nada sobre que algo fuera obligatorio. Primefac ( discusión ) 12:38 5 oct 2024 (UTC) [ responder ]

Tienes razón, otro comentarista utilizó "obligatorio". Sin embargo, creo que establecer la expectativa de que las funciones principales deben poner a disposición su código probablemente convertiría esa expectativa en un requisito en la práctica. La política ya lo recomienda y eso parece interpretarse de manera agresiva a veces en las discusiones de BRFA. También me gustaría entender la situación actual antes de cambiar la política. Daniel Quinlan ( discusión ) 01:21, 6 de octubre de 2024 (UTC) [ responder ]

Tu bot fue la excepción, ya que es un robot de administración que se encarga de la protección de los artículos. La mayoría de los BRFA no tienen ningún requisito ni solicitud para publicar su fuente y, en la práctica, no lo hacen. ProcrastinatingReader ( discusión ) 21:13, 14 de octubre de 2024 (UTC) [ responder ]

Estoy de acuerdo con la política de bots que establece que el código fuente de los bots de administración debe ser abierto o el desarrollador debe presentar dicho código para su revisión a pedido de cualquier miembro o administrador de BAG . Mis comentarios anteriores no deben interpretarse como una contradicción con eso. Diseñé mi bot para que cualquiera pudiera ejecutarlo fácilmente, publicando el código como código abierto y asegurándome de que fuera fácil de configurar. Sin embargo, creo que es justo decir que algunos de los requisitos adicionales que se han discutido probablemente me habrían disuadido de enviar un BRFA. Daniel Quinlan ( discusión ) 23:11, 14 de octubre de 2024 (UTC) [ responder ]

Dejando de lado la obligatoriedad o lo que sea, creo que tiene sentido que tengamos una lista de lo que consideramos bots "esenciales", junto con alguna idea de cuál es la estrategia de sucesión para estos bots. (¿Hay alguna de estas opciones? ¿Está disponible el código fuente? ¿Están alojados en Toolforge con varios mantenedores?) ProcrastinatingReader ( discusión ) 21:12, 14 de octubre de 2024 (UTC) [ responder ]

Agregué un par de bots a la lista que empecé anteriormente. También incluí lo esotérica que se consideraría su pila tecnológica en estos días (es decir: con qué facilidad alguien podría hacerse cargo de su mantenimiento con actualizaciones/correcciones). Los bots que usan pywikibot o mwbot-rs, por ejemplo, creo que son bastante accesibles. El código C++ personalizado o incluso el código Perl, diría que no es particularmente fácil de tomar el control. Siendo realistas, no hay nada que podamos hacer al respecto, pero vale la pena permanecer conscientes de nuestro factor bus .

Estoy definiendo vagamente "core" como el bot que desaparece y causa una interrupción notable en la enciclopedia, algún proceso significativo o que de otra manera impacta significativamente en la calidad de los artículos. ProcrastinatingReader ( discusión ) 21:46 14 oct 2024 (UTC) [ responder ]

Sugiero crear una lista principal de los procesos clave de Wikipedia en inglés/elementos de trabajo en curso, y debajo de ellos enumerar las tareas automatizadas esenciales para esos procesos/elementos de trabajo. (Entiendo que algunos bots pueden estar agrupados bajo múltiples procesos/elementos de trabajo). Como mínimo, sería útil para aquellos que no están familiarizados con todos los bots si la lista pudiera incluir un breve resumen de sus tareas esenciales. isaacl ( discusión ) 21:54, 14 de octubre de 2024 (UTC) [ responder ]

¿Te refieres a algo así? Usuario:ProcrastinatingReader/Core bots ProcrastinatingReader ( discusión ) 22:04 14 oct 2024 (UTC) [ responder ]

Sí. Básicamente, un desglose por flujo de trabajo: aquí hay un proceso importante (que podría estar realizando un conjunto de elementos de trabajo en curso) y aquí están los elementos clave que se automatizan para que esto sea sostenible. Estaba pensando que, dependiendo del tamaño de las listas o de la cantidad de bots que admiten múltiples flujos de trabajo, podría valer la pena mantener la lista de bots con sus detalles por separado y simplemente hacer que la lista de flujo de trabajo apunte a los bots en la lista de bots. Siento que esto hace que sea más fácil pensar en qué flujos de trabajo son absolutamente necesarios para seguir ejecutándose (y pensar en los que faltan en la lista) y saber en qué se basan. isaacl ( discusión ) 22:23, 14 de octubre de 2024 (UTC) [ responder ]

Gracias isaacl, creo que es una buena idea. Me gustaría sugerir una única lista por ahora, a menos que resulte que es común que las cuentas de un solo bot realicen múltiples tareas principales. Creo que es más fácil que correlacionar entradas en dos listas, si podemos evitarlo.

Creo que hay algunas cosas que deberíamos entender sobre cada bot, en lugar de simplemente preguntarnos "¿está disponible el código fuente?". He intentado resumirlas en el artículo de Wikipedia:Bots básicos . Allí pongo el ejemplo de ClueBot NG. Creo que el hecho de que sea un modelo de red neuronal artificial que utiliza C++ y un marco de trabajo de C++ poco común significa que es poco probable que alguien fuera del equipo de desarrollo principal pueda adoptar ese bot tal como está y mantenerlo de manera realista, en lugar de simplemente ejecutarlo.

Con eso en mente, me pregunto si no sería bueno desarrollar un criterio simple para evaluar a un bot, que sirva como una estadística resumida decente en comparación con los comentarios en texto sin formato. Por ejemplo, categorías como: "¿fuente disponible y ejecutable?" / "¿múltiples mantenedores?" / "¿pila tecnológica mantenible?", en las que un bot puede obtener una puntuación binaria (buena/mala). Estas categorías son principalmente para ilustrar la idea. No estoy seguro de qué tipo de marco deberíamos utilizar para evaluar a los bots para una estrategia realista de "resiliencia operativa". ProcrastinatingReader ( discusión ) 11:06, 16 de octubre de 2024 (UTC) [ responder ]

También se podría hacer una escala del 1 al 5. El hecho de que el código fuente esté alojado en Toolforge podría sumar un punto, el código fuente publicado podría sumar un punto, los mantenedores activos podrían sumar un punto, etc. – Novem Linguae ( discusión ) 13:25, 16 de octubre de 2024 (UTC) [ responder ]

Los sistemas de puntos no tienen sentido (el juego de palabras no es intencionado). No utilicemos una métrica que no tenga ningún propósito práctico sólo por tenerla.

Dicho esto, ¿qué es el bot RFC? Debería ir en la lista principal. Headbomb { t · c · p · b } 14:26, 16 de octubre de 2024 (UTC) [ responder ]

@ Headbomb : Hay dos bots RFC:

Legobot ( discusión · contribuciones ) una vez por hora (i) detecta transclusiones que carecen de un parámetro y agrega uno; (ii) se asegura de que la siguiente marca de tiempo válida después de cada etiqueta existente sea menor a treinta días en el pasado, y si no, elimina la etiqueta y también elimina la declaración RfC de todos los listados (como WP:RFC/BIO ); (iii) verifica los parámetros de categoría RfC para cada transclusión, como , y se asegura de que el RfC esté listado en las páginas correspondientes como WP:RFC/BIO{{rfc}}|rfcid={{rfc}}{{rfc}}{{rfc}}|bio
Yapperbot ( discusión · contribuciones ) (también una vez por hora, pero media hora después de Legobot) envía mensajes a las páginas de discusión de los usuarios sobre las RfC en las que Legobot ha añadido recientemente un |rfcid=parámetro, véase WP:FRS

HTH. -- Red rose64 🌹 ( discusión ) 15:27 16 oct 2024 (UTC) [ responder ]

Estaba pensando en Legobot. No estoy seguro de que el otro sea el núcleo, pero Legobot lo es en mi opinión. Headbomb { t · c · p · b } 15:30, 16 de octubre de 2024 (UTC) [ responder ]

No veo mucha utilidad en una única puntuación resumida. Creo que la cantidad de bots principales debería permanecer por debajo del umbral en el que un grupo de personas podría revisarlos y determinar las prioridades relativas a la atención. Además, en un entorno de voluntariado, quién trabaja para ayudar con qué bot va a estar muy influenciado por el interés personal en el flujo de trabajo asociado, en cualquier caso. Para una característica individual como "pila tecnológica mantenible", podría ser útil tener una puntuación, para ayudar a quienes no están familiarizados con los detalles de la tecnología relacionada a hacer comparaciones relativas. Sin embargo, lo consideraría más descriptivo que analítico, para evitar empantanarnos en su precisión. isaacl ( discusión ) 15:55, 16 de octubre de 2024 (UTC) [ responder ]

Reutilización para bots y herramientas

En un hilo algo ortogonal a ~~todo esto~~ , en un mundo ideal, me encantaría ver una mayor estandarización en los bots y las herramientas. He escrito algunas de mis propias herramientas, pero pasé mucho tiempo reinventando muchas ruedas para hacerlas funcionar. Sé que ha habido algún progreso en esta área (pywikibot es sin duda un paso en la dirección correcta), pero todavía hay mucho esfuerzo invertido por personas que van en direcciones diferentes. Lo que a su vez hace que sea más difícil que la gente retome los proyectos de otras personas. RoySmith (discusión) 16:35 16 oct 2024 (UTC) [ responder ]

@ RoySmith : como imagino que ya habrás oído, los frameworks son maravillosos: todo el mundo debería tener uno :-). Es un gran desafío crear uno que otros puedan usar, con suficiente documentación. Existe Help:Creating a bot § Programming language and library (Ayuda:Crear un bot § Lenguajes de programación y bibliotecas) , pero es principalmente una gran lista, sin mucha orientación para ayudar a alguien a decidir qué usar. Creo que debería haber un lugar para que los programadores compartan experiencias, pero no estoy seguro de dónde está. Wikipedia_talk:Bots redirecciona a Wikipedia:Bots/Noticeboard (Tablón de anuncios) , cuyo encabezado lo hace parecer más un lugar de coordinación que un lugar para colaborar en el desarrollo. isaacl ( discusión ) 21:31, 16 de octubre de 2024 (UTC) [ responder ]

Algunas estadísticas serían de gran ayuda. Ayuda:La creación de un bot incluye muchas opciones que nadie recomendaría hoy en día. Si bien no creo que debamos imponer ningún lenguaje o conjunto de herramientas, sería útil informar a los nuevos desarrolladores qué lenguajes y conjuntos de herramientas se utilizan en los bots en uso activo, especialmente en los bots más recientes. Al menos la mitad de los BRFA actuales son Python con Pywikibot. Daniel Quinlan ( discusión ) 22:18, 16 de octubre de 2024 (UTC) [ responder ]

Estoy de acuerdo en que sería útil conocer algo de información básica sobre su uso. Siempre que miro una biblioteca, un marco o una herramienta de terceros, quiero saber qué tan popular es y qué tan activamente se mantiene, para tener una idea de qué tan probable es que continúe manteniéndose en el futuro, qué tan fácil será encontrar respuestas a preguntas y qué tan útil lo han encontrado otros. Pero volviendo al problema de los gastos generales que ahuyentan a los desarrolladores, esto también se aplica a quienes crean código y herramientas para reutilizar. Hacer un seguimiento de esta información y mantenerla actualizada es un trabajo adicional, y puede ser menos interesante para un equipo de una sola persona que trabajar en su proyecto. isaacl ( discusión ) 22:55, 16 de octubre de 2024 (UTC) [ responder ]

Actualizar la sección de bots globales

Hola, actualmente la política global de bots dice que ( Wikipedia:Global_rights_policy#Global_bots ) los bots globales solo pueden ejecutarse en esta wiki con el propósito de corregir redireccionamientos dobles. Creo que eso está desactualizado, porque se vincula a una discusión de 2008 y las políticas de Meta han cambiado los bots globales en 2021 para permitir la ejecución de cualquier tarea que esté aprobada. Creo que esto también requiere un cambio en esta wiki, ya que de lo contrario puede ser bastante confuso. Propongo permitir que los bots globales se ejecuten aquí para cualquier tarea aprobada, especialmente porque en.wikipedia será notificado cuando alguien envíe una solicitud de bot global. Después de todo, esta wiki aún puede indicarle a cualquier bot que no se ejecute aquí, si es necesario. Si no, recomiendo agregar esta wiki al conjunto de opciones de exclusión para que los bots globales estén completamente deshabilitados (en lugar de habilitados para un solo propósito). Tabla de clasificación ( discusión ) 06:49, 12 de septiembre de 2024 (UTC) [ responder ]

Solicitar la aprobación de bots locales aquí debería seguir siendo obligatorio para los bots de aquí. Nuestra comunidad y nuestro proyecto son enormes y esperamos que nuestros operadores de bots participen aquí. En cuanto a si deberíamos expulsar a todos los bots globales que están realizando la tarea para la que ya están aprobados, eso no parece ser necesario. — xaosflux ^Talk 09:32, 12 de septiembre de 2024 (UTC) [ responder ]

Cualquier cambio en la política necesitaría un consenso para ese cambio, aquí en la Wikipedia en inglés. Esa discusión podría llevarse a cabo aquí, pero tendría que ser una RFC real u otra discusión ampliamente publicitada y con amplia participación. Personalmente, me gustaría ver más razones para cambiar la política de las que se han dado hasta ahora. Anomie ⚔ 12:07, 12 de septiembre de 2024 (UTC) [ responder ]

De acuerdo. Primefac ( discusión ) 13:16 12 sep 2024 (UTC) [ responder ]

¿Por qué es necesario este cambio y qué bots globales específicos ayudarían a mejorar la Wikipedia en inglés bajo una política más permisiva? Daniel Quinlan ( discusión ) 00:18 30 sep 2024 (UTC) [ responder ]

@ Daniel Quinlan Esto es más por coherencia, porque normalmente no solicitaría derechos de bots locales en una wiki que no esté en el conjunto de exclusión de bots globales a menos que sepa que no acepta todo tipo de bots globales. No tengo ningún bot global específico en mente por este motivo. Otras wikis de este grupo incluyen la Wikipedia rusa, donde se permiten bots globales pero parecen hacer referencia a políticas antiguas. Tabla de clasificación ( discusión ) 14:02, 2 de octubre de 2024 (UTC) [ responder ]

Normalmente no solicitaría derechos de bot local en una wiki que no esté en la opción de exclusión de bots globales . Buen punto. Tal vez deberíamos agregar nuestra wiki a meta:Bot policy/Implementation#Where is policy as "not allowed" para que los operadores de bots globales no ejecuten bots globales aquí por accidente. – Novem Linguae ( discusión ) 00:23, 3 de octubre de 2024 (UTC) [ responder ]

El único cambio relevante que veo a partir de 2021 es este, que no dice lo que dices que dice. ¿Hay algún otro cambio en otro lugar? Izno ( discusión ) 19:52 30 sep 2024 (UTC) [ responder ]

@ Izno De hecho, es esa. ¿Por qué crees que "no dice lo que dices"? Tabla de clasificación ( discusión ) 14:03 2 oct 2024 (UTC) [ responder ]

El cambio en meta cambió los requisitos para meta. No cambió los requisitos aquí, así que cuando dices que creo que esto requiere un cambio en esta wiki también , se lee como si pensaras que debemos ser consistentes con la política global. No es "confuso": simplemente tenemos requisitos diferentes. Izno ( discusión ) 17:21 2 oct 2024 (UTC) [ responder ]

@ Izno En realidad, eso es lo que estaba insinuando: "arreglar las redirecciones dobles" es solo una tarea única que no estoy convencido de que sea necesaria como una exención específica. Y también estaba diciendo que en-wiki no es la única wiki en este grupo, donde parece que las reglas se crearon cuando la política global de bots era más restrictiva. Además, el cambio de política en Meta cambió las reglas para cada wiki que permitía bots globales que no tenían una restricción explícita. Tabla de clasificación ( discusión ) 06:03, 3 de octubre de 2024 (UTC) [ responder ]

Si entiendo bien, meta tiene una política que permite bots globales, pero esa política no obliga a que los bots se puedan ejecutar en las wikis individuales sin su consentimiento. Cada wiki puede tomar sus propias decisiones sobre qué bots quiere aceptar. isaacl ( discusión ) 06:56, 3 de octubre de 2024 (UTC) [ responder ]

@Isaacl Sí y no. Las políticas globales son globales y las wikis individuales no pueden "optar por no participar" en ellas. Sin embargo, las wikis individuales pueden establecer preferencias en términos de cómo quieren que los bots globales utilicen su bandera de bot, pero he visto algunas wikis (por ejemplo, esta) que hacen referencia a antiguas políticas de Meta al hacerlo (que es lo que quiero corregir); no he visto una sola wiki que establezca explícitamente tales restricciones al hacer referencia a las reglas actualizadas de 2021; ni he visto ninguna wiki que tenga restricciones aparte de permitir corregir redirecciones dobles/enlaces de idioma entre wikis.

Y también, con respecto a "la política no obliga a que los bots se puedan ejecutar en las wikis individuales sin su consentimiento", sí, no es un "mandato", pero el objetivo de los bots globales es evitar que los operadores soliciten indicadores de bots en todas las wikis y, por lo tanto, si yo fuera un operador de bot global, no iría por ahí pidiendo permiso en wikis aprobadas por bots globales, a menos que ya sepa que dicha wiki no permite bots globales para ningún propósito aprobado. Y tampoco puedo hacer esto para todas las más de 800 wikis que permiten bots globales.

TLDR: sí, "la wiki puede tomar sus propias decisiones sobre qué bots quiere aceptar", pero hacerlo iría en contra del propósito de los bots globales. Tabla de clasificación ( discusión ) 07:31 3 oct 2024 (UTC) [ responder ]

Estás haciendo una distinción falsa en Yo no iría por ahí pidiendo permiso en wikis globales aprobados por bots, a menos que ya sepa que dicha wiki no permite bots globales para ningún propósito aprobado , lo que en mi opinión hace que tu argumento no sea convincente. Si tú (como operador de un bot global) sabes que enwiki solo permite bots globales que corrigen interwikis sin aprobación por separado, ¿por qué no pedirías permiso si quieres que tu bot que corrige redirecciones dobles se ejecute aquí? Si tu única queja es que meta:Bot policy/Implementation#Where it is policy no es lo suficientemente clara, una solución más fácil podría ser mejorar esa página. Las políticas globales son globales y las wikis individuales no pueden "optar por no participar" de ellas. Excepto esta, que sí pueden. Incluso si la política global de bots no lo dijera explícitamente, creo que encontrarías que no necesariamente aceptamos aquí cualquier "política" aleatoria que alguien en Meta declare que es "global". No he visto una sola wiki que establezca explícitamente tales restricciones al hacer referencia a las reglas actualizadas de 2021. Tú sí lo has hecho. Anomie ⚔ 12:12, 3 de octubre de 2024 (UTC) [ responder ]

@ Anomie La página del bot enlaza a una discusión de 2008, no de 2021. Digámoslo de esta manera: Sé que tengo que solicitar derechos de bot locales. ¿Alguien más que no esté familiarizado con en.wiki lo haría? Tabla de clasificación ( discusión ) 21:15, 3 de octubre de 2024 (UTC) [ responder ]

Deberían hacerlo si leen Wikipedia:Política de derechos globales#Bots globales . Anomie ⚔ 11:27, 4 de octubre de 2024 (UTC) [ responder ]

La política global dice que el operador debe asegurarse de cumplir con las preferencias de la wiki en relación con el uso de la bandera de bot. Permite explícitamente que cada wiki tome sus propias decisiones sobre qué bots quiere aceptar. isaacl ( discusión ) 15:58, 3 de octubre de 2024 (UTC) [ responder ]

@Isaacl No lo discuto, y tampoco discuto que en.wiki no esté haciendo nada malo per se. Sin embargo, creo que en.wiki creó esta exención en 2008 cuando las reglas de Meta eran diferentes, y creí que necesitaba al menos una revisión en 2024. Cómo y qué no me preocupa demasiado: los otros contribuyentes tienen mucha más experiencia que yo. Digámoslo de esta manera: preferiría que en.wiki se incluyera en el conjunto de exclusión voluntaria de bots globales para que quede claro para todos que debes solicitar una bandera de bot local, en lugar de esta extraña excepción de una sola tarea que no es obvia a menos que vayas a la política de bots (y no es como si fuera más difícil para los operadores de bots que corrigen redirecciones dobles presentar una solicitud de bandera de bot local que para un operador de bot global para cualquier otra tarea). Tabla de clasificación ( discusión ) 21:21, 3 de octubre de 2024 (UTC) [ responder ]

Como mencioné al principio, si desea una reevaluación, la mejor manera de hacerlo es crear una RFC. Si desea comenzar a redactar una (recomiendo un borrador para reducir la posibilidad de problemas de redacción confusos), no dude en hacerlo. Anomie ⚔ 11:27, 4 de octubre de 2024 (UTC) [ responder ]

No tengo la motivación suficiente para hacerlo; todos ustedes tienen más experiencia que yo. Solo publiqué aquí como una sugerencia para mejorar; me parece que la comunidad no cree que valga la pena. Tabla de clasificación ( discusión ) 19:37, 4 de octubre de 2024 (UTC) [ responder ]

"Política de bots" que aparece enRedirecciones para discusión

La política de redireccionamiento de Bots se ha incluido en redirecciones para discusión para determinar si su uso y función cumplen con las pautas de redireccionamiento . Los lectores de esta página pueden comentar sobre esta redirección en Wikipedia:Redirecciones para discusión/Registro/12 de octubre de 2024 § Política de Bots hasta que se llegue a un consenso. C F A 💬 20:40, 12 de octubre de 2024 (UTC) [ responder ]