Wikipedia:Café/Archivo/Propuestas/Actual

Café: Propuestas

Taza En esta sección del Café de Wikipedia introducimos y discutimos nuevas propuestas en temas tales como wikiproyectos nuevos, plantillas, herramientas, páginas de discusión y archivos multimedia. Para responder en un tema ya abierto, usa el enlace [editar] que se encuentra junto al título del apartado. Puedes iniciar un nuevo tema, o vigilar esta página para enterarte de sus cambios. Trata a los demás con respeto, especialmente a los recién llegados, y recuerda siempre presumir buena fe. Por favor, recuerda firmar usando cuatro virgulillas, así: ~~~~. Archivo del Café · Archivo temático del Café · Archivo de Propuestas

Café
Noticias	[+]
Políticas	[+]
Técnica	[+]
Propuestas	[+]
Ayuda	[+]
Miscelánea	[+]
Ver todos
Temático

Creación de permisos para borrar artículos

Buenas tardes, es la primera vez que escribo aquí y no sé si este tema ya ha sido tratado; pero de todos modos quisiera conocer los puntos de vista en la discusión pasada si la hubiera habido y las de ahora si alguien tiene algo más para aportar.

Como podrán ver en mi página de usuarios y mi historial de ediciones una de mis actividades es la revisión de artículos nuevos, lo que me lleva a colocar varias plantillas de borrado rápido. Por mucho tiempo estos artículos se borraban en pocos minutos, pero últimamente veo que la Categoría respectiva acumula varias decenas de ellos durante varios días. Mi primera idea al respecto es que los bibliotecarios no dan abasto con todas las tareas de mantenimiento (entiendo que borrar artículos es potestad exclusiva de los biblios) y entonces se acumulan allí hasta que son atendidos. Me parece que como comunidad tenemos una madurez suficiente como para hacer bueno uso del criterio de borrado rápido y que una vez que un artículo recibe esta plantilla lo mejor es proceder cuanto antes dado que se incluyen en esta consideración contenido que degrada el nivel y la imagen de la enciclopedia.

Por supuesto que soy consciente de que esta propuesta no es trivial ni puede tomarse a la ligera, por lo que quisiera agregar algunas consideraciones:

1. Este muevo permiso (provisionalmente, asistente de borrado o ADB) debería elegirse por votación con criterios estrictos de cuórum en la votación y antigüedad y experiencia por parte del candidato.
2. El ADB no debe borrar artículos a su solo criterio sino únicamente aquellos que fueron considerados por otro usuario.

Menciono estos temas para que quede claro que soy consciente de que este permiso puede tener conflicto pero considero que la posibilidad de incorporar usuarios experimentados como asistentes en una tarea delicada y en una herramienta que es muy usada por comunidad (la de revisar artículos y colocarlos para borrar), la cual además cuenta con un amplio conocimiento y un consenso establecido mejoraría el tiempo de respuesta en estos casos y la calidad general del proyecto.

A la espera de sus comentarios, Mr. Moonlight (Tiene la palabra) 18:56 1 jun 2023 (UTC)

Sugiero escoger más bibliotecarios, muchos más bibliotecarios. El permiso para borrar es delicado, pero creo que cientos de editores deberían tenerlo. En quienes confío para borrar también confío en general para bloquear y viceversa. Pero la comunidad lo ve de otro modo, pareciera preferir la concentración de capacidades y permisos. Saludos. Lin linao ¿dime? 19:11 1 jun 2023 (UTC)

El problema que veo con esta postura es que el rol de bibliotecario reúne muchas atribuciones por lo que su atención (es decir la consideración para otorgar el permiso) es mucho más farragosa que si sólamente se permitiese una única acción. Mr. Moonlight (Tiene la palabra) 19:35 1 jun 2023 (UTC)

 En contra. Entiendo que a veces nos desespere que las plantillas tomen tiempo en atenderse, pero darle un permiso como éste a alguien que no es bibliotecario, sería muy problemático. No solo es el problema de hacerlo apresuradamente y al criterio de una sola persona, los bibliotecarios no podrían darse cuenta de las CPP y recreaciones constantes para poder tomar medidas complementarias como el bloqueo de espacios y usuarios. MexTDT (discusión) 19:25 1 jun 2023 (UTC)

Justamente estoy proponiendo que no sea "a criterio de una sola persona". No entiendo bien lo de CPP, porque esas cuestiones son notorias incluso para usuarios sin ningún rol especial. Del mismo modo el registro de creaciones es público y puede ser visto por cualquier usuario. Mr. Moonlight (Tiene la palabra) 19:35 1 jun 2023 (UTC)

El registro de contribuciones borradas no es público. Saludos. Lin linao ¿dime? 19:37 1 jun 2023 (UTC)

Perdón, lo confundí con el registro de borrados. Error mío. Mr. Moonlight (Tiene la palabra) 19:41 1 jun 2023 (UTC)

Lin linao: ¿En que te basas para decir que "...la comunidad lo ve de otro modo, pareciera preferir la concentración de capacidades y permisos."? Yo creo que la idea no es tan descabellada. Tendría que contar con el apoyo de la comunidad mediante votación, obviamente, otorgar el permiso también mediante votación a usuarios con una cierta experiencia (no siempre sinónimo de antigüedad), cuyo historial demuestre una trayectoria óptima y que fuera exclusivamente para borrar artículos o retirar la plantilla de borrado si este no procediera, no para bloquear/expulsar a usuarios, proteger artículos, ni otras funciones de bibliotecarios. También podría limitarse la acción a determinados casos (p.ej. las plantillas que otorgan 30 días para solventar el problema y que no ha sido solucionado). Por supuesto, sería removible en caso de hacer mal uso de él. Yo estoy  A favor de la idea. Manolo (Desfógate) 22:39 1 jun 2023 (UTC)

Em que cada pocos meses surgen propuestas para restringir la creación de artículos, la edición, la participación o el acceso a ciertas herramientas y se busca crear niveles especiales. Y no leo propuestas en el sentido contrario. Muchos usuarios experimentados y normales (es decir, ni de conducta errática ni con antecedentes para preocuparse en serio) son rechazados en las CAB porque no cumplen X tiempo de antigüedad o Y número de ediciones o porque en la prehistoria en escala wikipédica le respondieron mal a alguien o usaron la plantilla que no era. ¿Por qué alguien que puede borrar no puede proteger o bloquear? Las políticas centrales de Wikipedia son iguales para estas tres cosas. O tienes el criterio para hacerlo y la confianza de la comunidad o no los tienes. Saludos. Lin linao ¿dime? 23:27 1 jun 2023 (UTC)

Podríamos activar a partir de una votación el permiso de Wikipedia:Page mover (¿Trasladador/Movedor de páginas?) que existe en algunas Wikipedias. Algo similar como lo que se hizo con el permiso de Editor de plantillas. En la Wikipedia en inglés tienen 396 usuarios con el permiso de Page Mover. Este permiso permite a los usuarios mover páginas sin dejar atrás una redirección. Esto ahorraría tiempo al patrullero (que tiene que colocar una plantilla:Destruir y luego buscar identificar cuál es el bendito código pertinente a colocar en la plantilla ^{R3. Redirecciones automáticas innecesarias}) y obviamente también ahorraría tiempo a los bibliotecarios. El permiso se solicitaría en el tablón y un bibliotecario evaluaría el caso, como con los permisos de verificador, reversor y autoverificado. Saludos, Cbrescia (discusión) 00:41 2 jun 2023 (UTC)

@Cbrescia: No entiendo como este permiso se relaciona con mi propuesta, el traslado sin redirección no cubre la cuestión que señalo. Mr. Moonlight (Tiene la palabra) 13:06 2 jun 2023 (UTC)

@Mr. Moonlight Entiendo el problema:

• los bibliotecarios no se dan abasto con todas las labores de mantenimiento. Dados los desafíos de incrementar el número de bibliotecarios (me parece que necesitamos por lo menos unos 20 más), se hace necesario aliviar la carga de ellos. Lo que propones -un nuevo permiso que ayude a descentralizar la función del borrado y aliviar la carga- es una solución pero pasa por un proceso de reflexión, diseño y consenso que puede acabar a medias o en nada. Asimismo, el proceso debe ser liderado por alguien de la comunidad. ¿Lo harías tú? Luego de esta discusión, ¿sistematizarías las ideas, desarrollarías y abrirías una votación?
• lo que propongo se relaciona con tu propuesta ya que estoy abordando el borrado rápido también, pero solo me enfoco a algunos de los criterios de borrado. ¿Por qué traigo esto?
  1. el permiso ya existe en Wikipedia, Wikipedia:Page mover, no hay mucho que diseñar
  2. cada diez días, se trasladan alrededor de 1000 páginas
  3. de estas, cada diez días, se envían a borrado rápido unas 100 redirecciones (deberían ser más ya que muchas personas que trasladan no envían las redirecciones innecesarias a borrado y muchas otras desarrollan sus entradas en un taller y luego trasladan sin eliminar la redirección)
  4. 100 acciones de borrado menos por parte de los bibliotecarios aligera su carga y pueden avanzar en otras tareas, también aligera la carga de los patrulleros y editores
  5. lograr el consenso para esto es mucho más fácil en comparación a lo que propones
  6. el proceso para activar el permiso es más simple: proponer una política para este permiso (en base a la de la Wiki en inglés) y votar la política, como se hizo con el permiso de Editor de plantillas (política, votación) este año.

El impacto no sería igual a lo que propones, pero se avanzaría un poco en el alivio de la carga en las tareas de mantenimiento. Igual, estoy  A favor de tu propuesta. Cbrescia (discusión) 16:59 2 jun 2023 (UTC)

@Cbrescia En relación a tu primer punto la respuesta es que estoy dispuesta desarrollar y encabezar (si fuese necesario) las sucesivas etapas de este proceso, pero solamente si veo que hay condiciones de hacerlas. El siguiente paso, luego de esta conversación sería una encuesta antes de una redacción formal de la propuesta. En relación al segundo punto ahora entiendo la relación entre las cosas, menos redirecciones innecesarias son menos páginas a borrar. Sin embargo me parece que es una solución que toca el tema de una manera tangencial y no resuelve la cuestión de fondo, aunque llegado el caso también apoyaría esa propuesta porque no hace ningún daño y hace un aporte. Mr. Moonlight (Tiene la palabra) 17:27 2 jun 2023 (UTC)

Sobre las redirecciones: sugiero que sea una facultad de los autoverificados. ¡Hoy son menos de 600! Saludos. Lin linao ¿dime? 17:43 2 jun 2023 (UTC)

@Lin linao:Justamente por esto es que planteo esto. Dado que el acceso al rol de bibliotecario es complejo por la cantidad de atribuciones que tiene mi idea es descentralizar algunas de sus funciones clave. ¿Por qué esta y no otra? Porque desde mi punto de vista esta es la más utilizada y donde más se percibe el cuello de botella, más allá de lo delicado que pueda ser (bloquear usuarios también es delicado) me parece que esta función es la mejor relación entre necesidad y sensibilidad. Además del hecho de que percibo que existe un mayor consenso sobre el borrado rápido que sobre los bloqueos. Mr. Moonlight (Tiene la palabra) 13:11 2 jun 2023 (UTC)

No creo que prospere la propuesta, teniendo en cuenta que parece que cada vez hay más discusiones y conflictos entre inclusionistas y deletionistas. Habilitar un permiso como ese beneficiaría al punto de vista de los segundos, por lo que tendría bastante oposición de los primeros. Y creo que generaría una crispación mayor entre ambos grupos, mientras que hasta ahora se van resolviendo sus diferencias por la diligencia de los bibliotecarios. -- Leoncastro (discusión) 13:33 2 jun 2023 (UTC)

Leoncastro: ¿Podrías aclararme un poco más tu intervención? ¿Qué diferencia hay entre un artículo borrado por un bibliotecario (previo marcaje para WP:BR) o el borrado por un "asistente de borrado" (como lo llama Mr. Moonlight)? ¿Qué diligencia puede aplicar un bibliotecario, que no aplique un "asistente de borrado"? Manolo (Desfógate) 13:47 2 jun 2023 (UTC)

@J. Manolo G. P., observa que no trato del borrado en sí mismo. El problema no estaría tanto en ese eventual borrado, sino en el nombramiento del asistente. Los inclusionistas recelarán de nombrar a los deletionistas y los deletionistas promulgarán el nombramiento de cualquiera. En ese punto se aumentarán las diferencias entre los grupos y su crispación entre ellos. La diligencia de los bibliotecarios que menciono no es sobre los borrados, sino sobre las diferencias entre ambos grupos (acusaciones de plantillismo, guerras de ediciones, consultas de borrado discutidas, denuncias entre usuarios, etc.). Será casi tan difícil nombrar a alguien asistente de borrado como nombrarlo bibliotecario. Y ya puestos, será preferible que tenga todos los permisos. -- Leoncastro (discusión) 13:59 2 jun 2023 (UTC)

@Leoncastro Si la hipótesis de que será tan difícil nombrar ADBs como biblios entonces toda la propuesta pierde sentido porque una de sus motivaciones principales es agilizar esta atribución. Lo que no me queda claro es el tema de los "dos bandos" en el terreno práctico. Por ejemplo, ¿es muy común que se revierta el colocado de una plantilla de borrado rápido o que ningún biblio borre un artículo marcado por no estar de acuerdo con el criterio de quien lo marcó? Mr. Moonlight (Tiene la palabra) 15:25 2 jun 2023 (UTC)

@J. Manolo G. P., ando bastante inactivo y no sé qué tan común sea (supongo que los bibliotecarios activos lo sabrán mejor que yo), pero sí veo que existen esos casos y cada vez veo más discusiones por culpa de los borrados. -- Leoncastro (discusión) 15:37 2 jun 2023 (UTC)

Hubo una vez una propuesta de crear un permiso similar al de bibliotecario, pero no se llegó a ningún acuerdo. --Леон Поланко говорит вам и слушает вас 03:00 4 jun 2023 (UTC)

•  Muy en contra el otorgamiento de botones se da a usuarios de mucha confianza de la comunidad, y este permiso requiere la misma confianza que se la damos a quienes se postulan a bibliotecarios, y sí, necesitamos más bibliotecarios comprometidos. Este permiso sería redundante. --Amitie 10g (discusión) 22:58 18 jun 2023 (UTC)

  Todos los permisos son redundantes respecto a alguien con permisos mayores, por eso acoto la propuesta a borrados específicos. Es decir, atender la lista de la categoría de borrados rápidos. La propuesta tiene que ver con la creación de un grupo específico que tenga esta responsabilidad reducida y por lo tanto también un nivel de confianza menor. Mr. Moonlight (Tiene la palabra) 16:21 23 jun 2023 (UTC)

  En vez de crear un permiso adicional, mejor añadir esa faculta a un flag existente, por ejemplo el de verificador. El cual tendría mayor utilidad, como artículos de borrado rápido. El resto es historia. Claro, es una idea, tiene su pro y contra, una revisión de los verificadores actúales si están capacitados, en fin en fin. Seria muy chungo fraccional las facultades. Anibal Maysonet (discusión) 16:41 23 jun 2023 (UTC)

  Como criterio me parece bien, pero no veo cómo sería posible revisar a todos los verificadores actuales para darle el nuevo permiso. Además que me parece que habría que cambiar la forma de acceso al rol de verificador que no debería ser por una solicitud como es ahora. Mr. Moonlight (Tiene la palabra) 22:40 23 jun 2023 (UTC)

Sigo defendiendo mi primera postura: nombrar "asistentes" exclusivamente para borrar artículos marcados con plantillas de 30 días. Ese permiso lo concedería un bibliotecario mediante solicitud en el TAB. Nos quejamos algunas veces de la falta de bibliotecarios, verificadores y reversores, ¿Por qué cerrar la puerta a la creación de esta nueva figura que vendría para complementar y aliviar de trabajo a los otros tres?
Los bibliotecarios gozan de nuestra confianza para nombrar verificadores, reversores y, recientemente se aprobó, mediante votación, elevar a política el nombramiento de editores de plantillas, todas ellas, personas que, a su vez, gozan de la confianza de los bibliotecarios.
Más recientemente hemos dado nuestra confianza a un nuevo bibliotecario (al que aprovecho, desde aquí, para felicitar), ¿Qué hace que hayamos confiado en él para que, entre otras muchas funciones, pueda nombrar reversores, verificadores y editores de plantillas y, sin embargo, no confiemos en su capacidad para conceder permisos de "asistentes de borrado"? Al fin y al cabo, este permiso, igual que los otros, sería revocable. Si alguien hace un mal uso o abuso de él, se le retira. Manolo (Desfógate) 10:47 24 jun 2023 (UTC)

┌─────────────┘
 Muy en contra Si bien hay funciones como la edición de plantillas, reversión, verificación, etc, que no requieren hacer tanto lío con una candidatura. Para el borrado de páginas se necesita mucha confianza, básicamente igual a la que se requiere para ser bibliotecario. No confiaría a no bibliotecarios para hacer eso. Se necesitaría una candidatura, y si vamos a hacer lío con una candidatura, mejor que sea una CAB, ya que se supone que tiene la confianza.--SRuizR 15:24 24 jun 2023 (UTC)

Me parece que se está perdiendo el foco de la propuesta que no es permitir "borrar páginas" sino definir un permiso para que determinados usuarios experimentados puedan hacerlo en determinadas circunstancias expuestas taxativamente. Por esa forma acotada de este permiso, la intención es que se puede procesar de forma más veloz que una CAB y de esa manera se supere el cuello de botella en este punto. Mr. Moonlight (Tiene la palabra) 15:36 24 jun 2023 (UTC)

SRuizR, en tu intervención dices que «No confiaría a no bibliotecarios para hacer eso.» ¿Tampoco confiarías en la confianza (valga la redundancia) que un bibliotecario depositara en un "asistente", igual que la que pone en un verificador o reversor? No veo la necesidad de una candidatura y su votación correspondiente. Manolo (Desfógate) 16:14 24 jun 2023 (UTC)

Para una función delicada como lo es el borrado de páginas, me parece que no es suficiente la confianza de un único usuario, por más que la comunidad confíe en este. Se necesita confianza de la comunidad. Es diferente para las funciones de reversión y verificación, ya que no son funciones tan delicadas; para esos dos permisos el juicio de un bibliotecario me parece suficiente.--SRuizR 16:21 24 jun 2023 (UTC)

@Mr. Moonlight y J. Manolo G. P.:podeis preparar otra encuesta para después pode abrir una nueva votación. Ontzak (Jota Ke Irabazi Arte) 23:12 25 jun 2023 (UTC)

 En contra. No veo posible técnicamente que se pueda delimitar el ámbito de aplicación del permiso que se propone crear, entiéndase, no veo cómo impedir que un usuario con ese permiso borre algo que no se supone que deba borrar. Si el problema es contenido nuevo de mala calidad, sería mejor retomar la propuesta de instaurar el espacio de nombres "Draft". — Lucho Problem? 15:38 27 jun 2023 (UTC)

Yo la verdad que había visto este hilo al principio de mi CAB y no quería comentar por considerarlo de algún modo conflicto, así que lo voy a hacer ahora. Tanto ahora como antes considero que el borrado de artículos en el espacio principal es una de las tareas que debe seguir de la mano de los admins. Lo mismo que los bloqueos, creo que son acciones más delicadas que las reversiones o verificaciones, y que para realizarlas se requiere contar con la confianza máxima de la comunidad. También considero que a diferencia de las otras dos, son acciones del todo administrativas (a veces se nos olvida que los bibliotecarios, por usar este nombre en la eswiki, son de hecho administradores en cualquier otra wiki; su tarea es administrar). Aunque por aquí hay muy buena gente y de toda confianza (al menos para mí), creo que hay acciones que los admins no deben relegar (lo creía antes y lo creo ahora). Si hace falta votar más admins para ocuparse de ciertas tareas, perfecto. Siempre hacen faltan manos (como creo haber expresado en mi CAB).

Si bien lo cierto es que en este tema concreto, este cuello de botella del que se habla, antes fue el caso, sí, pero ahora no es así. Ahora mismo (a la hora de escribir) tenemos en la categoría de borrado rápido cinco artículos, no un centenar. A veces se acumulan un poco, pero luego se resuelven - y tampoco es una tarea de tanta urgencia (quizá salvo los plagios que lo son), como lo pueden ser los bloqueos de vandalismo en curso. Y los artículos con plantilla de 30 días, pues también se van resolviendo poco a poco.

Con respecto al borrado de páginas en el espacio de usuario, ahí ya sí le veo más sentido y apoyaría el uso de la herramienta por el grupo de usuarios que se decida (ya lo había ofrecido antes, idea antaño debatida en otra wiki, desconozco la conclusión alcanzada). Porque es cuando un/a usuario/a borra muchas páginas en su espacio personal cuando la cosa se puede atascar un poco (aunque en la actualidad tampoco por tano tiempo). Lo sabré yo, que en su día les di tanto trabajo a los pobres que les tardó bastante deshacerse de todo. También creo positivo hacer más uso del traslado a los talleres de artículos que pueden tener potencial pero no llegan ni para una plantilla de 30 días, y sin dejar redirección en el espacio principal (borrado de hecho). Y el espacio de nombres "Draft" que menciona Lucho, también debatido antes sin llegar a una conclusión (que yo sepa) también es una buena idea. En fin, opino que el borrado es una herramienta administrativa, que no es una acción urgente, que en la situación actual no resulta en cuellos de botella y que hay mejores opciones para agilizar el proceso. Un saludo.  𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦  DIALOG   11:00 29 jun 2023 (UTC)

Nada más quiero aclarar la duda planteada por LuchoCR, respecto a la posibilidad técnica de delimitar el permiso. Esto sí es posible hacerlo por medio del filtro antiabusos. En todo caso, mantengo mi postura de no crear el permiso.--SRuizR 21:09 29 jun 2023 (UTC)

Actualizo. El filtro antiabusos, al evaluar la acción "delete", no toma en cuenta el texto de la página, por lo que no es posible saber si lo que el eliminador está borrando tiene o no la plantilla.--SRuizR 22:28 8 jul 2023 (UTC)

Borrador de posible encuesta

A pesar de lo controvertida que es esta propuesta (o quizás por eso), me he permitido confeccionar un borrador de encuesta en mi taller, que os invito a leer. Por favor, dedicad unos minutos para estudiarla y sentíos libres de modificarla o comentarla. Mi intención sería (según los resultados) realizar posteriormente una votación para la creación de este nuevo permiso, definiendo sus términos. Gracias. Manolo (Desfógate) 10:30 29 jun 2023 (UTC)

Hola @J. Manolo G. P.. Me parece que va a ser díficil lograr el consenso para este permiso según lo discutido hasta ahora aquí. Existe una encuesta del 2017 y una votación del 2014. A partir de lo que escribí arriba, pienso que sería bueno reformular la encuesta dirigiéndola hacia la activación del siguiente permiso, u otros que se podrían proponer:

• suppressredirect (trasladar una página sin crear una redirección)

Virum Mundi y Lin Linao se han manifestado a favor de un cambio en ese sentido. La encuesta podría ir hacia preguntar a la comunidad si el permiso se le añade al grupo de :

1. Autoverificados, o a
2. Verificadores

Sí la comunidad está de acuerdo, se hace la votación y si se aprueba, se avanzaría hacia reducir la carga de los biblios, que ya no tendrían que dedicarse a borrar páginas que son redirecciones automáticas innecesarias y subpáginas de talleres de usuario trasladadas al espacio principal. Y también ahorraría tiempo a todas las editores y patrulleros envian a borrado estas páginas. El tiempo de los voluntarios y voluntarias (editores, patrulleros, biblios) es algo que tiene que mucho valor aquí, ¿por qué no avanzar un poco en hacer los procesos más eficientes?

Otra parte de la encuesta puede dirigirse hacia sondear cuál es el problema que los participantes piensan que es el más crítico actualmente. Se pueden proponer opciones a marcar como falta de referencias en entradas, falta de bibliotecarios, vandalismos, etc. Y a partir de las respuestas podríamos luego pensar cómo abordar soluciones al problema considerado como principal. Saludos, Cbrescia (discusión) 15:44 29 jun 2023 (UTC)

Cbrescia: en aquella encuesta y votación de 2014 y 2017 me he basado, pero he limitado más las atribuciones que se les podría conceder a este "nuevo grupo de eliminadores" (como allí se les llamaba): entre otras, la de cerrar CdB, proteger y desproteger artículos o restaurarlos y bloquear cuentas vandálicas. Manolo (Desfógate) 21:00 29 jun 2023 (UTC)

┌─────────────────────────────┘
Si hay una palabra que es imprescindible en las diversas discusiones y se repite muchas veces a lo largo de ellas (aunque no siempre se cumpla), es consenso. Pues bien, aquí parece que existe el suficiente consenso como para hacerme desistir en mi idea de abrir una encuesta para crear esta nueva figura de "eliminadores". Retiro la plantilla de "no archivar" que yo mismo coloqué en este hilo. Así mismo, voy a solicitar que un bibliotecario elimine el borrador que desarrollé en mi taller y la página de discusión correspondiente. Doy las gracias a todos los que habéis participado. Manolo (Desfógate) 14:04 3 jul 2023 (UTC)

De todo lo hablado en el hilo y el subhilo me quedo con la idea de identificar mejor el problema para proponer las soluciones más adecuadas, que seguramente no empezarán por la creación de nuevos permisos, sino por generalizar el suppressredirect (como ya se ha apuntado aquí), restringir las creaciones a los nuevos usuarios (como he ido comentando en otros hilos), delegar en usuarios de confianza tareas que no requieran permisos (por ejemplo, el cierre de consultas de borrado o la mediación y resolución en conflictos menores), mejorar los filtros antiabusos, y optimizar, simplificar y semiautomatizar los procesos de borrado. - José Emilio –jem– Tú dirás... 13:17 11 jul 2023 (UTC)

Cómo es posible que siga este error

Por favor, eliminar los caracteres Unicode (² ³, etc.) y remplazarlos por el marcado HTML (la plantilla ^{2 3}) por las siguientes razones:

• https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Superscripts_and_subscripts

Graña 'n' Montero (discusión) 00:25 25 jun 2023 (UTC)

De esto se habló en este hilo hace unos meses, pero no veo que se haya llegado a algún acuerdo. –FlyingAce^✈hola 00:47 25 jun 2023 (UTC)

Es una diferencia de visibilidad abismal ² y ². Espero que lleguen al acuerdo muy pronto. Graña 'n' Montero (discusión) 03:15 25 jun 2023 (UTC)

Mira, copio y pego parte de tu memsaje: "Por favor, eliminar los caracteres Unicode (² ³, etc.) y remplazarlos por el marcado HTML (la plantilla 2 3) por las siguientes razones:" ¿Qué te parece? Saludos. Lin linao ¿dime? 01:27 25 jun 2023 (UTC)

(?)

Graña 'n' Montero (discusión) 03:13 25 jun 2023 (UTC)

¿No notas algo distinto en el caso en que tú usaste html? ¿algo que altera el signficado del texto? Saludos. Lin linao ¿dime? 03:22 25 jun 2023 (UTC)

Por un lado está la usabilidad, principalmente en visualizacion desde dispositivos móviles, y por el otro está la reutilización de contenido mediante copiar y pegar. Hay que considerar que al copiar y pegar texto en el formato de etiquetas HTML en lugar de los caracteres unicode, los superíndices y subíndices se pierden si se pega en algo que no sea una wiki. Por lo cual, estoy  A favor de usar caracteres unicode, y ajustar el software para que se muestren mejor. --Amitie 10g (discusión) 03:45 25 jun 2023 (UTC)

Fue una lección que aprendí hace tiempo, de la mano del mismo Lin linao, en una consulta igual que esta, y que no se me olvidará jamás (¿Cuántas veces habrá repetido esa lección?). Igualmente estoy  A favor de Unicode. Manolo (Desfógate) 07:02 25 jun 2023 (UTC)

No entiendo, es decir, ¿prefiere la usabilidad sobre la accesibilidad?

Sería bueno ajustar el software, pero la solución HTML es más rápida.

Graña 'n' Montero (discusión) 13:51 25 jun 2023 (UTC)

La opción Unicode tiene la ventaja adicional frente a la de la plantilla ésa (exp) que sus números no se confunden (por tamaño) con los superíndices numéricos generados por las citas en línea de las referencias.²²​

Un saludo. strakhov (discusión) 17:50 25 jun 2023 (UTC)

El argumento del copipegado me parece pobre, la verdad. A nadie le importa que copipegar “H₂O” dé “H2O”, o al menos no les importa tanto como para proponer que se escriba “H₂O” (también hay Unicode para los subíndices). Y no creo que a muchos les importe que copipegando “km²” quede “km2”, todos lo entienden.

Los superíndices (Unicode o HTML) se usan más que nada en unidades y fórmulas matemáticas simples y cortitas (para las otras usamos <math>). Como dudo que el editor medio vaya a poner otros superíndices Unicode que “²” o “³”, y para el resto probablemente use <sup>, apoyo el reclamo de Graña de usar <sup> para todo. Saludos. --angus (msjs) 19:21 25 jun 2023 (UTC)

El argumento de "A nadie le importa que copipegar" es más pobre aún. Si a nadie le importará, no habría nadie comentando acerca de esto. Amitie 10g (discusión) 19:54 25 jun 2023 (UTC)

Nadie comentó acerca de los subíndices, Amitie 10g. Saludos. --angus (msjs) 21:26 25 jun 2023 (UTC)

Corríjanme si me equivoco, pero, este código HTML fue creado hace más de 15 años, ¿cierto?

Como alguien que ha usado Windows desde el 3.1, entiendo porque existen estas plantillas, eran necesarias para visualizar caracteres y formato que de otra forma necesitarían la instalación de paquetes de compatibilidad de idioma o hasta el extremo de tener una instalación del SO del idioma que se necesite. Desde WinXP S2 en adelante, esto pasó a segundo plano. Se mantiene por compatibilidad pero a estas alturas, alguien viendo Wikipedia en Win2000, Java o Symbian sería sólo por hobby, así que pregunto: ¿Es necesario imponer algo para que unos cuantos entusiastas de la computación sigan visualizando Wikipedia en sus dispositivos «vintage»? No creo que se deba favorecer a uno o al otro, el Unicode no impide la accesibilidad en pleno 2023, no creo que existan dispositivos modernos o SS.OO. que tengan problemas con Unicode, ¡hasta mi iPod de 2007 puede visualizarlos! Creo que el dispositivo más reciente que no soporta Unicode es el 3DS y ya está más que descontinuado. MexTDT (discusión) 20:00 25 jun 2023 (UTC)

No tiene nada que ver con eso, MexTDT. Saludos. --angus (msjs) 21:26 25 jun 2023 (UTC)

A ver si entiendo, ¿crees que trato de imponer algo por las razones que mecionas? No soy ningún entusiasta de la informática (uso Windows 8.1). Simplemente compara la diferencia abismal entre, por ejemplo, m² y m². Graña 'n' Montero (discusión) 22:38 25 jun 2023 (UTC)

A ver, Graña 'n' Montero: como te explicó Lin linao, si yo pretendo copiar tu texto para pegarlo en otro sitio, quedaría así: "Simplemente compara la diferencia abismal entre, por ejemplo, m² y m2." ¿Aprecias el detalle? Otra cosa es que, para angus, ese detalle carezca de importancia. Manolo (Desfógate) 22:53 25 jun 2023 (UTC)

Entonces, ¿primaremos la usabilidad sobre la accesibilidad? :Graña 'n' Montero (discusión) 22:54 25 jun 2023 (UTC)

En mi opinión, sí, porque (p.ej.) en matemáticas no es lo mismo r² que r2. -- Manolo (Desfógate) 23:05 25 jun 2023 (UTC)

No se si entiendo bien eso de la «accesibilidad». ¿Es una cuestión sobre compatibilidad con HTML anticuado contra el Unicode o de que se trata? Tanto el HTML como los caracteres dan la misma función para el texto y, como lo mostró Lin linao, el Unicode tiene ventajas. ¿Es una cosa de uniformidad con el uso del código HTML propio de la enciclopedia? Porque si es por ahí, tendríamos que hacerlo con muchos caracteres como símbolos y hasta acentos. Creo que no entiendo a dónde quiere llegar con la propuesta. MexTDT (discusión) 23:10 25 jun 2023 (UTC)

Lo de la «accesibilidad» es que se ve demasiado pequeño para quienes tienen problemas de visión. Pero claro, los mismos que se quejan que no se ve, son los que falsean el tamaño para que se vea mucho menos. -- Leoncastro (discusión) 23:28 25 jun 2023 (UTC)

@Leoncastro ¿Falsear el tamaño? Eso fue intencional. La diferencia entre m² y m² (cuando se reduce el tamaño pred. de 100%).

Graña 'n' Montero (discusión) 23:57 25 jun 2023 (UTC)

@Graña 'n' Montero, sí, falsear, con todas sus letras. Estabas comparando m<small>²</small> con m<sup>2</sup>. Al diff me remito. Si fue intencional tuvo unas intenciones bastante inapropiadas, engañando al lector que no revisase el código (es decir, a la gran mayoría). Porque lo único que habías reducido era precisamente el caracter Unicode. Si quieres comparar lo diferentes que se aprecian, debes hacerlo en las mismas condiciones. O bien a tamaño normal: «m²» frente a «m²»; o bien a tamaño de texto reducido (reduciendo todo, evidentemente): «m²» frente a «m²». Porque cuando se reduce el tamaño no se hace a una letra en concreto. -- Leoncastro (discusión) 08:46 26 jun 2023 (UTC)

Tomemos como ejemplo las definiciones en Sistema Internacional de Unidades y lo horrible que quedan cuando combinan Unicode y <sup>:

kg·m²·s⁻¹

1.380 649·10⁻²³ kg·m²/s²/K

cd·sr·kg⁻¹·m⁻²·s³

m² kg s⁻²

m² kg s⁻³

etcétera.

A propósito, Unicode también tiene letras en cursiva (o 𝑐𝑢𝑟𝑠𝑖𝑣𝑎). ¿Deberíamos usarlas en vez de código wiki? Así la cursiva se mantiene al copiar y pegar, digo. :) --angus (msjs) 08:00 26 jun 2023 (UTC)

Ciertamente queda horrible cuando se mezclan, Angus. Aunque no entiendo por qué se deberían mezclar.

kg·m²·s⁻¹ → kg·m²·s⁻¹ ó kg·m²·s^–1

1.380 649·10⁻²³ kg·m²/s²/K → 1.380 649·10⁻²³ kg·m²/s²/K ó 1.380 649·10⁻²³ kg·m²/s²/K

cd·sr·kg⁻¹·m⁻²·s³ → cd·sr·kg⁻¹·m⁻²·s³ ó cd·sr·kg⁻¹·m⁻²·s³

etc.

Por cierto, se habló la última vez, que la versión en inglés usa una opción intermedia entre el tamaño del Unicode y el tamaño del <sup> a través de la plantilla {{exp}}. Es decir, que ni usan «m²» (m²) ni tampoco «m²» (m<sup>2</sup>), sino «m²». Por orden de tamaño: «m²» «m²» «m²». -- Leoncastro (discusión) 08:55 26 jun 2023 (UTC)

No es que se deban mezclar, pero siempre hay uno que por discusiones como esta se pone a cambiar ciegamente y las fórmulas quedan así. Lo mejor sería decidirse por una opción y ponerla en el manual de estilo. Los ejemplos con superíndices Unicode que das se ven desalineados y es más difícil escribirlos, por lo que me inclino por el <sup>, al porcentaje que sea.

Agrego que me acabo de fijar, y si se copia texto de Wikipedia y se pega en alguna aplicación que soporte texto formateado (como MS Word o Libre Office), el formato no se pierde. Saludos. --angus (msjs) 09:29 26 jun 2023 (UTC)

@Angus, bueno, pero de esos que cambian ciegamente los hay de todo tipo. Me preocupa menos que suceda por un bot con el cual no se han contemplado todas las posibilidades (se podrá revisar su programación), que por unos usuarios que no se fijan en lo que hacen y trabajan peor que un bot. Como sea, ese tipo de cambios no deberían ser un argumento a considerar, ya que se pueden automatizar por igual con cualquiera de las medidas que se adopten. -- Leoncastro (discusión) 17:45 26 jun 2023 (UTC)

Estoy de acuerdo. Mi argumento original iba por el lado de que si preferimos Unicode, el editor medio sabrá como poner un par de superíndices y si necesita algo más raro probablemente tenga que mezclar con <sup> o {{Exp}} (hasta que pase el hipotético bot, al menos). --angus (msjs) 20:20 26 jun 2023 (UTC)

Por lo visto hay mucha gente que no ha pasado del block de notas y solo pueden utilizar los superíndices de Unicode. Si realmente quieres hacer la modificación en el manual, deberías pasar por una votación primero. R2d21024 (discusión) 22:43 2 jul 2023 (UTC)

Revisión de políticas sobre anexos

En los últimos 2 años, me encontrado con la creación de decenas de anexos relacionados a este tipo de programas, en especial los de corte musical, siendo la mayoría realizados por IPs como este ejemplo reciente. Muchos de estos permanecen porque logran llenarlos de referencias, pero estas referencias, si acaso sirven para la introducción o para una de las secciones que apenas tienen algo que podría ser información relevante, como este ejemplo larguísimo que sólo prueba la tabla de rating/audiencias con ¡mensajes de una cuenta de Twitter!

Por años he intentado traer al café este problema de tener decenas, sino es que cientos, de anexos con información redundante, irrelevante, de investigación original, etc., pero sin una sola participación por parte de la comunidad.

Decidí dejarlo por la paz y dedicarme a tratar el problema de uno a uno patrullando tanto artículos viejos como nuevos, en especial nuevos. Tan sólo hoy, he tenido que aplantillar 13 ([1], [2], [3], [4], [5], [6], [7], [8], [9], [10], [11]) de los cuales se han borrado hasta este momento, 2 ([12], [13]) y no parecen tener fin; siempre que encuentro una IP que recrea uno de los que patrullo, veo su historial y me encuentro con por lo menos 2 nuevos anexos que no conocía su existencia o que cambiaron el título para evitar que vuelva a ser borrado.

Los usuarios que se dedican casi exclusivamente a inflar estos artículos y anexos con datos sin fuentes más que el programa y sus episodios (fuente primaria) son demasiado apasionados y pueden llegar a iniciar guerras de ediciones y pasar rápidamente a los insultos, incluso a los bibliotecarios.([14], [15], [16], [17], [18], [19], [20])

Y es por esos motivos y los incidentes recientes que he decido traer nuevamente este tema y una propuesta que tal vez es muy extrema pero en este caso, tal vez sea lo mejor.

Este tipo de programas son relevantes, no hay duda que muchos deben tener artículos en Wikipedia y que estos pueden ser neutrales, bien referenciados e informativos sin hacerle promoción a los programas. Sin embargo, hay que ser honestos, estos programas no son Eurovisión, no son eventos serios realizados con la participación de varios países o naciones y vistos por estos al mismo tiempo, son programas locales emanados de franquicias que son desechables y siguen un guión aunque lo traten de negar u ocultar con algo de "realidad", demasiado efímeros, rara vez se llegan a retransmitir, fuera de sus regiones rara vez son vistos por otras audiencias y, esto no se puede negar, fuera de los famosos que logran crear en sus primeras temporadas, todos los participantes, incluso los ganadores, sn olvidados rápidamente y ni siquiera siguen en esa carrera. Tan sólo en México, de Master Chef sólo tres han seguido con sus carreras, con apoyo de la misma televisora. Nadie recuerda a la mitad de los participantes que siguieron y la misma producción ha recurrido a las ediciones "celebrity" para retomar algo de relevancia. Y de La Voz o México Tiene Talento, no ha salido absolutamente nadie y si llegan a hacer algo, dificilemente alguien recordará que estuvieron ahí. Y bueno, vayamos a un ejemplo más que relevante: American Idol. Los primeros ganadores, Kelly Clarkson y Clay Aiken, llegaron a ser conocidos fuera de sus países pero han logrado relativamente poco. Aparte de ellos, el único participante de temporadas posteriores que sigue siendo recordado y se volvió relevante es William Hung, ¡alguién que audicionó y se convirtió en un chiste viral por su terrible audición y ni siquiera participó! Si esto pasó en México y Estados Unidos, otros países deben tener peores o más tristes ejemplos. Como dije, los programas y sus ediciones anuales en conjunto son relevantes, pero por su naturaleza desechable, telebasura si se quiere, como cuestionablemente lo apuntó Linuxmania [21], cada edición y los detalles más mínimos de estas resultan con una relevancia muy dudosa, más aún si para probar todas esas "estadísticas" se tiene que recurrir a notas de las mismas productoras y/o televisoras, notas de fuente primaria y que además son promocionales, en especial si se utilizan para ir rellenando tablas de resultados en el transcurso del desarrollo de las "temporadas".

Mis propuestas son:

1. La veda en la edición de los artículos principales de tablas de resultados con espacios en blanco a ser rellenados a medida que se transmiten los episodios y el uso de páginas de fuente primaria.
2. El borrado inmediato de nuevos anexos, aún si estos son saturados de referencias fiables con datos relevantes del programa. Salvo que una "temporada" en particular sea relevante (que en su caso no ameritaría la la creación de un anexo sino del artículo de la "temporada"), no hay motivos razonables que otorguen relevancia o (aunque no quiero usar esta palabra porque puede ser falacia) utilidad a las larguísimas tablas de datos que aparentan ser estadísticos como si se tratara de eventos deportivos.

• Los anexos que tengan años de ediciones con referencias fiables y participación significativa de la comunidad, tendrán que tratarse caso por caso con CDBs y otras plantillas de mantenimiento.

1. Prohibir el uso de tablas estadísticas en los artículos principales y/o limitarlas a una tabla simple de participantes y ganadores (que de hecho es el formato que tienen la mayoría de los artículos).
2. Únicamente permitir la creación de un anexo de participantes y resultados de todas las temporadas y descartando datos como el rating, canciones, platillos, retos, etc. por episodio y temporada; en el caso de que estas tablas hagan que los artículos principales se vean muy largos (lo cual es la razón de ser de los anexos en primer lugar).

Mi primer propuesta evitaría la evidente promoción a los programas por medio de sus artículos y la segunda evitaría la creación de más anexos con datos irrelevantes que hacen pensar a muchos que estos anexos son necesarios y que cumplen con las normas de Wikipedia y los invitan a crear y recrear más anexos. ¿Que importancia tendrá en el futuro saber que cantó el quinto participante eliminado de la trigésima temporada de La Voz de Mongolia en la quinta "gala"?

Hay que decidir ya sí, al menos en este rubro, queremos tener una buena enciclopedia neutral con datos relevantes o aceptar seguir siendo un espejo de Fandom. Los patrulleros no nos damos abasto detectando estos anexos y estos usuarios que las crean deben tener claro cuales son las normas y limites en Wikipedia en español para evitar más incidentes penosos, bloqueos y hasta expulsiones. MexTDT (discusión) 05:40 28 jun 2023 (UTC)

Wikipedia no tiene censura. Por basura que puedan ser, estos programas tienen cobertura significativa de fuentes independientes y las cosas que calificas de fuente primaria no lo son (salvo el programa). El patrullaje y mantenimiento es una pesadilla y tú y otros se merecen más reconocimiento y apoyi, pero a estos anexos qqno se les puede aplicar un criterio distinto que a cualquier otro. Solamente podemos exigir lo de siempre: verificabilidad, neutralidad, cumplir con WP:NO y demás. Seguramente hay que hacer cientos de consultas de borrado, como en todo lo demas. Saludos. Lin linao ¿dime? 15:06 28 jun 2023 (UTC)

No me refiero a aplicar censura, pero si que se refuercen nuestras normas, sobretodo la de no ser un repositorio de información sin criterio, y estos anexos son invariablemente eso. Creo que deberían ser tratados como las biografías, cuando estas son evidentemente promocionales o autobiográficos, son inviables por defecto; así, estos deberían serlo también por ser colecciones de datos, enlaces e imágenes sin criterio y de investigación original o fuente primaria. En mi experiencia, estos anexos no tienen redención ante nuestras normas. Creo que este tipo de anexos no deberían gozar del beneficio de la duda cuando cuentan con referencias, un caso muy claro es el de Anexo:The Voice of Greece (primera temporada), creado ayer por una IP y hoy sigue publicado y mantenido por más IPs. Intuyo que no se ha borrado porque cuenta con referencias pero la relevancia es muy cuestionable (un anexo para la primer temporada de la versión griega en la enciclopedia en español) y también una necesidad de existir muy dudosa cuando el arttículo principal necesita mucho trabajo. Aún con referencias, al igual que las autobiografías y otros artículos que se desaconseja crearlos, estos violan de manera inherente muchas normas y por lo tanto no se les debería tener consideración, como aparentemente está pasando con este anexo.--MexTDT (discusión) 19:22 28 jun 2023 (UTC)

Poniéndonos utópicos, es una enciclopedia universal para que la lean hispanohablantes, no para leer cosas de hispanohablantes. La tercera división de básquetbol de Chad vale tanto o tan poco como la de Paraguay y un reality show de poca monta de Grecia o de Costa Rica son iguales para estos efectos. Saludos. Lin linao ¿dime? 20:09 28 jun 2023 (UTC)

@Lin linao: Una disculpa por el comentario, de acuerdo que no es correcto pensar que la enciclopedia debe ser exclusiva de cosas que puedan importarle a los hispanoparlantes. Pero es que además de que el artículo tiene esta apariencia de estar fuera de lugar, el pobre trabajo que se ha hecho en el artículo hace pensar que ni en su país de origen fue relevante.--MexTDT (discusión) 06:33 29 jun 2023 (UTC)

Estoy de acuerdo con MexTDT. Estos y, por semejanza, los anexo:capítulos de la serie tal o anexo:personajes de la serie tal, si no todos (puede que alguno sea relevante por algún motivo puntual y concreto), sí la mayoría deberían ser borrados, trasladando la información importante (cuando la haya) al artículo principal (serie tal). Yo tampoco encuentro la razón de ser de tantos anexos que no son más que un contenedor de información sin criterio o un listado enorme, mal referenciados o sin referenciar. Manolo (Desfógate) 22:15 28 jun 2023 (UTC)

¿Qué tal si crear el artículo o anexo hasta que haya terminado una edición del reality y ya existan las referencias correspondientes? --Леон Поланко говорит вам и слушает вас 02:30 29 jun 2023 (UTC)

Es precisamente una de las cosas que propongo y lo que intento mantener en varios artículos que vigilo. Necesitamos que esto se mencione directamente en las páginas de políticas para evitar guerras de ediciones como las que ocurrieron en MasterChef (programa de televisión mexicano).

En cuanto a las referencias, el uso de estas son engañosas y ocultan los problemas. Aunque entiendo que ser bibliotecario no es fácil y no se tiene el tiempo para verificar con cuidado cada artículo, muchas veces cuando revisan los artículos aplantillados y ven que están llenos de "referencias", desestiman la plantilla y se hace difícil que se borren (a menos que vayamos a los procedimientos largos como plantillas menos críticas o CDBs).

En el caso de los artículos principales, si estoy de acuerdo con que se coloquen los datos relevantes como lo pueden ser una tabla de resultados o la del elenco cuando las temporadas terminen para evitar promoción; aún si se tiene que utilizar la fuente primaria para estos datos, es justificable. Son datos relevantes que, al final de estos eventos fugaces y muchas veces olvidados al poco tiempo, es lo poco relevante que podrían tener en el futuro. Pero en el caso de anexos por temporadas, invariablemente se llenarán con cada dato irrelevante y hasta rídiculo, desde la canción que cantaron, el platillo que prepararon, hasta quien recibio los comentarios chistosos de los jueces o las veces que se cayeron en un reto (no bromeo, lo he visto).

Un anexo único de resultados generales de las temporadas cuando sea necesario para que el artículo principal no sea muy grande y aparente que pierde objetividad, como lo puede ser ya el caso de MasterChef (programa de televisión mexicano), eso lo entendería y sería más fácil conseguir referencias para esos datos, inclusive independientes, pero uno por cada temporada, con tablas para cada episodio y tablas para cada cosa que se les ocurra como el rating o incluso repetir datos varias veces con tal de tener todos y cada uno de los detalles ocurridos en cada episodio, hasta los más mínimos, es lo que ya no quiero seguir viendo. Debido a que existen tantos artículos con estos problemas, muchos usuarios creen que es el "formato oficial" de Wikipedia aunque viole cosas tan básicas como la investigación original.[22], [23]

Lin linao mencionó algo que a mi se me escapó cuando puse las propuestas: no hay censura en Wikipedia. Sin embargo, sí tenemos normas y un manual de estilo, es ahí donde se podrían hacer unas enmiendas para desincentivar la creación de estos anexos. Tal vez algo como:

los programas de telerrealidad no son eventos deportivos importantes, las estadísticas que se puedan obtener de estos no son documentados por prensa o escritores especializados, por lo que los anexos para coleccionar este tipo de datos se consideran investigación original, información sin criterio y/o irrelevante e incluso promocional debido a que las fuentes suelen ser las mismas televisoras o notas pagadas pra promocionar a los programas, por lo que no se recomienda la creación de este tipo de anexos.

Es decir, se debe establecer que estos anexos tienen siempre la misma naturaleza y, como pasa con biografías promocionales que pueden llevar referencias válidas, deberían ser borrados sin mucha consideración cuando se solicita el borrado, y los patrulleros deberíamos tener argumentos respaldados por las páginas de politicas para que los novatos y fanáticos de estos programas no comiencen sus guerras de ediciones y sus comparaciones con otros artículos, y que de paso que los bibliotecarios tengan también las herramientas para dar argumentos cuando se soliciten las restauraciones, de nuevo, como pasa con las autobiografías. Si tenemos las políticas, pero necesitamos que estas mencionen directamente como ejemplos a este tipo de anexos, porque siempre son los mismos argumentos: "Hay otros artículos así" "Las políticas no lo mencionan". MexTDT (discusión) 06:09 29 jun 2023 (UTC)

Retomando lo que mencionó J. Manolo G. P. y a la luz de este Anexo:Lista de todas las canciones del Festival de la Canción de Eurovisión (un tanto irónico puesto que use al evento para probar mi punto sobre los reality shows), creo que se debe revisar y ampliar las políticas de anexos en base a estos problemas que presenta la creación de estos; hay que ser menos ambiguos en las políticas que los definen y no sigan siendo esos repositorios enormes de datos sin criterio. Para los «fans» de la cultura popular, si puede hacerse una tabla para una categoría o rubro con cualquier cosa, estas deben ser incluidas si o si en los artículos o justificar la creación de anexos enormes. Hace unos meses tuvimos el problema de un anexo extensísimo (no es exageración) del programa español, La que se avecina. Tenía toda clase de tablas y listas, muchas redundantes o evidentemente innecesarias, desde lo más «normal» como lo sería una de personajes y actores, hasta lo extremo como «entrada y salida de actores por año», otra igual pero por temporadas, personajes por piso en el edificio ficticio donde se lleva a cabo el programa, etc., etc. Por lo extenso, sus miles de ediciones, tanto de IPs como de usuarios registrados y sus años y años de degradación y aglomeración de fans, sólo con una CDB se pudo borrar y hasta esta por poco no resulta.[24]

Propongo algo más: la creación de criterios de borrado rápido específicos para anexos. Estos ayudarían a reforzar el cumplimiento de las políticas pertinentes a los anexos, como ocurre con las páginas de usuario. MexTDT (discusión) 20:57 29 jun 2023 (UTC)

Y bueno, aunque parece que me estoy quedando solo en la discusión una vez más, el problema no se limita a los reality show. Como lo mencioné, el razonamiento tras la creación de anexos se limita algo como: «si puede ir en una lista o tabla, se puede crear un anexo.»

• Anexo:Empresas emergentes unicornio en América Latina

En este ejemplo, hay referencias y no se nota que exista un propósito de promoción. Sin embargo, el criterio es cuestionable al ser considerado arbitrario y hasta especulativo y está plagado de logos. Aunque tal vez no sea la intención de los que mantienen el anexo, esta es una lista promocional, con logos y datos que podrían servir para «enganchar» a posibles inversionistas o dar una idea errónea sobre lo que son realmente esas empresas.

Vuelvo a insistir, necesitamos una revisión a las políticas, hacerlas más claras y menos ambiguas y la implementación de criterios de borrado específicos para anexos. No basta con considerarlos viables sólo con ver un montón de referencias, los anexos no son artículos, la relevancia probada con fuentes no debería lo principal a ser considerado para mantenerlos. A fin de cuentas, son principalmente listas, y deberían apegarse a las políticas que ya tenemos sobre lo que Wikipedia no es. MexTDT (discusión) 19:33 30 jun 2023 (UTC)

Para que no te quedes solo, MexTDT, y porque coincido en que el problema es importante, quiero subrayar algo que, como han pasado dieciséis años, parece que todo el mundo ha olvidado: la política de anexos jamás fue desarrollada; se aprobó con unas pautas iniciales muy generales seguidas de una propuesta con «redacción abierta» que precisamente debería delimitar los contenidos aceptables, los criterios de división o inclusión de filas/entradas, la variabilidad aceptable a medio/largo plazo, etc..., cuestiones que me parecen muy importantes y que aclararían esa ambigüedad que tenemos ahora. Personalmente no veo probable ni razonable que lleguemos a «purgar» sistemáticamente todos los anexos sobre este tipo de programas de gran audiencia, pero sí podríamos acotar mucho qué datos son relevantes y admisibles en ellos o no, la posibilidad de unificar todas las temporadas, la organización, los colores válidos, etc., e incluso evaluar formas de [semi]automatizarlos para mejorar su mantenimiento. Aparte de todo esto, mi idea sigue siendo que en algún momento tendremos que restringir las creaciones a los nuevos usuarios, y eso ayudará también a tener más control y menos trabajo. - José Emilio –jem– Tú dirás... 13:17 11 jul 2023 (UTC)

Propuesta para que un bot realice cambios masivos en enlaces a fechas

Según el manual de estilo, Cito: «Ni los días ni los años se enlazan a menos que sean fechas muy notables (como el nacimiento y la muerte en una biografía que llevan enlaces internos solamente al principio en la entradilla)...» entiendo que esto incluye todo tipo de fechas incluyendo meses sueltos y días de la semana. Si alguien no lo comparte este razonamiento, se puede aplicar «Crea enlaces solo donde sean relevantes para el contexto». Entiendo que un bot no puede eliminar todos los enlaces a fechas por haber enlaces que no solo son válidos sino que están recomendados, pero los de los tipos anteriores ver: Andalucía#Clima «...calurosos julio o agosto...», Andorra#Fiestas oficiales «...coincide con sábado...», Canarias#Fiestas «...Tercer sábado del mes de septiembre...», «...Lunes siguiente al primer sábado de octubre...» si sería factible eliminarlos con un bot en los artículos que no tiene que ver con fechas. Si no hay fallos en mi razonamiento ¿podría ocuparse un bot? quitaríamos miles de enlaces y evitaríamos malos ejemplos a los novatos. R2d21024 (discusión) 21:40 2 jul 2023 (UTC)

R2d21024, realmente veo complicado que un bot pueda identificar claramente todos los posibles contextos para decidir dónde retirar enlaces, aunque siempre podría eliminarlos en casos muy claros y preguntar al usuario en los menos claros. En cualquier caso, esto deberías plantearlo en la página de solicitudes a bots, y allí lo comentaríamos e intentaríamos concretar entre los operadores. - José Emilio –jem– Tú dirás... 13:17 11 jul 2023 (UTC)

Gracias por tu comentario, estaba intentando buscar consenso, pues no entiendo porque no se ha hecho todavía. Como nadie se ha opuesto lo solicitaré. R2d21024 (discusión) 15:44 12 jul 2023 (UTC)

En cualquier caso, @R2d21024, esto quizás debería plantearse después de que salga la votación al respecto. Nacaru · Discusión ✉ · 18:15 12 jul 2023 (UTC)

Mi propuesta se basa en el manual de estilo actual y ni siquiera en su integridad, solo los más fáciles de automatizar. Independientemente del resultado de la votación. R2d21024 (discusión) 19:22 12 jul 2023 (UTC)

Creo que no tiene nada que ver este asunto con el que se está tratando en dicha votación. Una cosa es la fecha 11 de septiembre de 2001 (que todos sabemos lo que significa) y otra es "el primer domingo de cada mes" o "la canícula de julio y agosto" o incluso, como he visto en algunas biografías, "nació el martes 14 de enero de 1975". El nombre del mes o el día de la semana no tienen porqué enlazarse. Manolo (Desfógate) 21:58 12 jul 2023 (UTC)

Difundir información sobre artículos antiguos con plantilla de 30 días

Buenas. Quería comentar los artículos ya publicados cierto tiempo (a veces mucho tiempo, e incluso tienen traducciones en otras wikis) que reciben una plantilla de banda roja de 30 días pues no cumplen con ciertos requisitos. Lo que pasa, sobre todo en los artículos más antiguos, es que poner el aviso en la PD del usuario que creó el artículo no sirve mucho pues muchas veces ya había dejado de editar hace tiempo. Se llega al día 30 a veces sin que nadie (o casi nadie) haya aportado información sencillamente porque nadie se entera (pocos conozco que entran en las categorías de artículos con plantilla por fechas). Lo que se me ocurre (salvo en casos claros de promoción o hasta vandalismo) es publicar los títulos de artículos en esta situación en algún Café. Para no saturar, no hace falta hacerlo todos los días, se puede confeccionar una lista cada medio mes, por ejemplo en el Café de noticias o el que sea, porque la verdad es que a veces se ve que puede ser un artículo de relevancia, pero está mal escrito o faltan fuentes (a veces del todo, a veces hay muy pocas, o que no funcionan), y entonces la decisión del admin es bastante subjetiva, y en algunos casos es una pena. Otra cosa son las CdB, que son más ventajosos en este respecto, pero muchas veces se opta por la plantilla de 30 días (tampoco se puede abrir una CdB por cada uno de estos artículos). Bueno, ya me diréis lo que opináis. Un saludo.  𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦  DIALOG   08:22 3 jul 2023 (UTC)

Creo que este problema es parte de uno bastante más grande: las categorías son poco apetecibles y muy pocos las miran. Otro problema es plantillismo de banda roja en artículos nuevos. En mi opinión las plantillas de banda roja que les queden poco para terminar deberían ser listadas en una categoría, y que este enlace aparezca en mantenimiento, así quizá estos artículos se mejoren antes de borrarse. Es una pena, porque hay muchos artículos válidos que se borran por plantillismo de banda roja. Saludos. --Goodlucksil (¿Algo útil?) 09:07 3 jul 2023 (UTC)

@Goodlucksil: ya existen ese tipo de categorías, Categoría:Wikipedia:Mantenimiento:junio, Categoría:Wikipedia:Mantenimiento por mes. Ontzak (Jota Ke Irabazi Arte) 09:14 3 jul 2023 (UTC)

Entiendo que pueda ser frustrante en algunos casos, pero la verdad es que, si no ha habido interés en años, lo más seguro es que no lo seguirá habiendo por varios más. De hecho, es casi un milagro en muchos casos que alguien los haya encontrado y les coloque la plantilla por lo improbable que puede llegar a ser toparse con este tipo de artículos. Quizás el mensaje no le llegue al creador por estar retirado, pero si le llega a otros y los han llegado a salvar.

Los que han buscado cosas en Google y esté los manda a un "stub" de enwiki, sabrán lo frustrante que es pensar que ya se encontró la información y al abrirlo no hay técnicamente nada. Además, también en muchos casos, estos son remanentes de una Wikipedia en español con pocas políticas y otras ambiguas que permitían irrelevancia y hasta bulos; es una buena medida de limpieza en mi opinión.

Por mi experiencia, yo pienso que si hubiera una forma de informar de estos artículos "malos", sobretodo del "fandom", de una manera más eficiente, provocaría en gran parte de los casos que estos se llenen de enlaces usados como referencias que realmente no prueban nada o apenas mencionan algo del artículo y que casi nadie, incluso bibliotecarios, se tomarán la molestía de revisarlos y le darán relevancia al artículo por cantidad y no calidad de fuentes, lo que evitará que sean detectados en el futuro y seguirán desinformando.

Yo creo que es preferible que se borren artículos descuidados para que alguien que sepa editar y conozca las normas actuales, se dé cuenta que ahora no existen esos artículos y haga un trabajo mejor desde cero que no lleve a borrarlos en el futuro y que le sirva a otros con información buena.

Se que para muchos soy un patrullero que disfruta ver artículos borrados, pero no es eso. Se supone que tenemos normas para crear una buena enciclopedia y no sólo tener toda la información habida, por haber, conocida, desconocida, especulada o irrelevante. Si lo estoy entendiendo mal, entonces bien podríamos fusionarnos con Fandom o dejárselo todo a enwiki.

El plantillismo es real, pero también lo es la creación vandálica, promocional, irrelevante, de ramificación excesiva, de investigación original, etc. El plantillismo se detecta de inmediato y se para, pero los artículos con problemas graves que no son borrados por antigüedad y tienen descuido grave de años son más dificiles de detectar.

Quizas podría aumentarse el tiempo, 3 meses, medio año; pero como lo dije al inicio, si no ha habido interés en años, lo más seguro es que no lo seguirá habiendo por varios más. MexTDT (discusión) 09:20 3 jul 2023 (UTC)

Y, como propone Virum Mundi, ¿Por qué no hacerlos más "visibles" en un espacio como el café? Para facilitar la tarea, se podría encargar un bot para gestionar un listado que, incluso los podría ordenar por fechas o tipo de plantilla. Manolo (Desfógate) 09:52 3 jul 2023 (UTC)

Como lo dijo Ontzak, tenemos categorías, esos son los espacios. Virum Mundi propone que se cree otro tipo de lugar para anunciar los artículos aplantillados pero que también haga que se difunda de otra forma.

La idea es noble pero un tanto utópica. ¿Cómo saber a quien informar de estos artículos? ¿Cómo hacer que este nuevo café llegue a mucha gente cuando este mismo café lo atendemos casi los mismos siempre y muchas veces pasan propuestas sin pena ni gloria o completamente ignoradas? No veo como crear interés para salvar artículos que para empezar no se les ha dado interés. MexTDT (discusión) 10:50 3 jul 2023 (UTC)

┌─────────────────────────────┘
Gracias por vuestros aportes. En cuanto a las categorías, claro que existen (ahí es donde miramos para ir resolviendo los casos), pero sé por experiencia que una vez se ve un hilo en el café, con enlaces y formato, invita más. De hecho, yo antes casi no entraba en estas categorías concretas, mientras que el café si que visito regularmente. Aunque seamos unos cuantos que lo hacen (me da que hay más que lo visitan sin participar), ya es un avance. Otra cosa es que "los mismos de siempre" participen en la edición de artículos, pero creo que todo el mundo podría encontrar al menos un artículo que igual le parezca una pena que se borre (a mí me ha pasado), y con un par de referencias a fuentes fiables nos ayudarían a quitar como mínimo la plantilla del bot (falta de referencias) y puede que un par de artículos sin relevancia comprobada. Lo mismo que en los CdB participa más gente, porque cuando uno sabe que puede influir en el borrado de un artículo, se involucra más. Ahora, claro, es solo la teoría, pero por intentar... luego la cuestión del formato, el bot, se podría ver, y cómo hacerlo para que no sature el café. Ahora mismo el total de artículos que hay para la primera quincena de julio son 201. Son muchos, y en una tabla puede saturar la vista. Pero si esta tabla incluyera, por ejemplo, el motivo de la plantilla, sería más fácil decidir por dónde empezar. En fin, solo es una idea, porque ahora mismo el problema de los borrados no es que no haya suficiente admins que lo hagan (Geom, yo, algún que otro también), sino que se eliminan artículos que pueden considerarse interesantes (y no es que la plantilla no tenga mérito, que en la mayoría de casos lo tiene, pero tal y como está el artículo, es difícil que se quede). Bueno, tampoco es algo para decidir de hoy a mañana, pero se puede pensar. Un saludo.  𝔙𝔦𝔯𝔲𝔪 𝔐𝔲𝔫𝔡𝔦  DIALOG   13:16 3 jul 2023 (UTC)

¿Viendo este tema, qué hay de que Wikipedia no tiene fecha de entrega? --Amitie 10g (discusión) 17:06 3 jul 2023 (UTC)

Pues lo qué hay es un ensayo, no una política. No se debe tomar como excusa para empezar un artículo y que pueda quedarse ahí indefinidamente. Además, si sugiere no crear artículos pobres que puedan ser borrados y, cito:

crear un artículo cuando su relevancia sea clara o dejar que el proceso wiki lo mejore.

El proceso Wiki no solo es esperar que alguien, algún día tal vez, lo mejore, también es parte del proceso verificarlo y hacer notar sus deficiencias aunque esto lleve a su borrado. Si se tuviera que seguir a cabalidad, ya no digamos al ensayo, sino el título de éste como muchos han pretendido, entonces podríamos hacer esbozos de una app nueva que pensamos que es interesante y podría ser muy popular o mantener el artículo de las olimpiadas de 2048 o por el contrario, nunca hacer el artículo la crisis reciente de Rusia o el artículo de un programa de TV de estreno reciente pero que ya tiene notoriedad. MexTDT (discusión) 18:47 3 jul 2023 (UTC)

No hay fecha de entrega, pero no podemos tener artículos con calidad impresentable publicados en el espacio principal. Pues la imagen de Wikipedia también es importante. Si bien no tenemos por qué terminar un artículo en una fecha determinada, es de suma importancia que lo que tengamos publicado en el espacio principal cumpla con requisitos mínimos lo más pronto posible. Podemos tomarnos nuestro tiempo en los talleres de usuario. Respecto a lo que dice Virum Mundi, a mi me parece una excelente idea que estos artículos estén publicados en algún lugar más visible como el café para que haya más incentivo a mejorar dichos artículos, pues las categorías son raramente revisadas. Saludos.--SRuizR 20:37 3 jul 2023 (UTC)

¿Wikipedia no tiene fecha de entrega? ¿Cuánto tiempo es eso? ¿Un mes? ¿Un año? ¿Diez, como en algunos casos? No, vamos a aplicar el sentido común, que eso sí es una política. Manolo (Desfógate) 20:57 3 jul 2023 (UTC)

OK. Vamos a crear otro espacio para difundir artículos en peligro. Ahora, ¿cómo difundimos al espacio para difundir esos artículos cuando no se ha podido difundir ampliamente la existencia de las categorías que sirven para lo mismo y tampoco la de este café para llegar al consenso para crear ese nuevo espacio?

Tal vez lo que tenemos que acordar o crear es la forma para que más usuarios conozcan otros espacios que ya tenemos. MexTDT (discusión) 21:35 3 jul 2023 (UTC)

¿Qué tal avisar a los wikiproyectos relacionados con tales artículos? Hace días lo hice yo aquí. Así se avisa a un grupo de usuarios con conocimiento del tema y sin necesidad de saturar a toda la comunidad con un exceso de avisos. Al mismo tiempo serviría para darle más utilidad a los wikiproyectos. Grabado (discusión) 21:53 3 jul 2023 (UTC)

Una idea que se me ocurre: una plantilla similar a la que muestra las consultas de borrado actuales o las votaciones actuales. --Леон Поланко говорит вам и слушает вас 02:35 4 jul 2023 (UTC)

Yo no contaría para nada con los wikiproyectos mientras no estén bien regulados y podamos saber cuáles están realmente activos. Sí que estoy dispuesto a estudiar esta última idea de una plantilla análoga a {{Recordatorio CDB}} que destaque y/o resuma los casos marcados a 30 días que puedan ser más «salvables» debido a, por ejemplo, su antigüedad o su existencia en otras Wikipedias, dando las cifras de su actividad reciente o tiempo hasta la expiración. Igualmente se podría automatizar la extracción de un resumen de esa plantilla al Café, si vemos que esa visibilidad adicional es útil, y de hecho se podría hacer algo similar con la mencionada {{Recordatorio CDB}}. ¿Qué les parece? - José Emilio –jem– Tú dirás... 13:17 11 jul 2023 (UTC)

 A favor de lo que dice -jem- --SRuizR 13:24 11 jul 2023 (UTC)

Llamado a colaboración interproyecto

Un saludo

Buenas. Vengo de una comunidad pequeñita por acá al lado, y tengo una idea para un Wikiproyecto en que podríamos unir intereses. Quizás como saben, Wiksource es una de las comunidades "hermanas" de Wikipedia. En particular nos dedicamos a la transcripción de material impreso que esté en dominio público. Esto incluye por supuesto la literatura, pero también una enorme cantidad de libros científicos publicados en nuestra lengua. Por eso propongo (y les pido ayuda) el establecimiento de un sistema de colaboración. No tengo la idea realizada pero se me ocurren los siguientes elementos:

1. Solicitar a los Wikiproyectos que identifiquen algunas obras que puedan cumplir con los requisitos de admisión (básicamente libres de derechos de autor) y que puedan ser claves de alguna manera (icónicos, fundacionales). Pueden ser importantes por las razones que sea.
2. Buscar dichas obras en bibliotecas. Una parte del material más difundido está ya digitalizado en bibliotecas digitales de países de habla hispana o en las más grandes de otros países. Hay catálogos grandes donde buscar, como en HathiTrust o Internet Archive. Y para la parte que sólo está físicamente, es posible hacer campañas de digitalización trabajando con las instituciones directamente (intermedio de nuestros capítulos locales, x ejemplo).
3. Generar un portal con esta información, para facilitar el intercambio y la colaboración.

Eso. Evidentemente no tengo nada concreto en mente, pero si alguien se anima a ocupar parte de su tiempo de voluntariado a trabajar en conjunto, estoy muy atento a este Café, y a todos los medios de contacto que prefieran. Ignacio ( — Δ — ) 23:03 5 jul 2023 (UTC)

¡Gran idea! Creo que puede ser de mucha ayuda para quienes editan cosas de Literatura, Historia y Geografía. En áreas como deportes, artes contemporáneas o ciencia, no tanto. A mí ya me has ayudado mucho con libros clásicos del mapudungún y Chiloé y creo que otros podrían hallar obras equivalentes. En esto uno de los peligros es duplicar trabajo, p. ej.: porque ya lo tiene Archive o porque algún investigador o voluntario ya lo hizo. ¿Se pueden subir cosas seudoinéditas sacadas de sitios como http://jesuitas.archivonacional.cl/? Saludos y éxito. Lin linao ¿dime? 04:34 6 jul 2023 (UTC)

Depende de la ciencia! Hay muchas obras importantes en zoología y botánica, por ejemplo. Con respecto a duplicar trabajo: es verdad que hay muchas digitalizaciones (escaneos, fotos de cada página) pero hay muy pocas transcripciones (el texto mismo en formato digital). De todos modos hay mucho trabajo también en buscar esos textos en las miles de bibliotecas posibles, y sólo catalogar lo que hay ya es un montón. Y respecto a subir cosas a Commons, es absolutamente la idea! Recuerden si no saben que escanear una obra no le entrega derechos de copia adicionales, por lo que si la obra está en dominio público, los archivos PDF o DJVU del escaneo también lo están. Como norma general una obra de más de 100 años casi siempre está en dominio público, aunque hay que revisar caso a caso. Ignacio ( — Δ — ) 13:10 6 jul 2023 (UTC)

No obstante hay que recordar que la traducción sí genera copyright. Si la obra no está en el idioma original, no solo habría que fijarse en la fecha en que murió el autor, sino también el traductor. Platonides (discusión) 22:59 11 jul 2023 (UTC)

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

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)

El uso de un filtro con bloqueo automático también puede ayudar.--SRuizR 15:51 11 jul 2023 (UTC)

Tratándose de una situación de emergencia,  A favor de la propuesta de LuchoCR--SRuizR 15:52 11 jul 2023 (UTC)

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 15:55 11 jul 2023 (UTC)

Yo estoy absolutamente  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 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 SRuizR

Concuerdo con WikiDasher respecto a lo de InternetArchiveBot. En este caso, yo preferiría dar el permiso editprotected al grupo bot--SRuizR 16:15 11 jul 2023 (UTC)

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 16:17 11 jul 2023 (UTC)

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)

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)

@LuchoCR: El grupo botadmin está presente en Wikipedia en kurdo, Wikipedia en persa, Wikcionario en frances, Wikipedia en italiano, y Wikipedia en malayo.--SRuizR 16:45 11 jul 2023 (UTC)

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)

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)

 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)

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)

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)

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)

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)

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)

@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)

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)

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)

 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)

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)

 Muy a favor Ontzak (Jota Ke Irabazi Arte) 22:04 11 jul 2023 (UTC)

 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)

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)

@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)

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)

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)

•  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)

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)

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)

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)

@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)

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)