stringtranslate.com

Wikipedia:Reversión por parte de no administradores

Atajo
  • WP:NAR

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

Introducción

Fondo

Eventos recientes

Esta página

Propuesta original

La función de reversión permite revertir contribuciones intencionalmente no constructivas de forma rápida y más eficiente que con otros métodos. (Se han escrito scripts de usuario que imitan la funcionalidad de la reversión, pero simplemente ocultan detalles al usuario y son mucho menos eficientes, tanto en términos de ancho de banda como de tiempo). Los enlaces de reversión se muestran en los historiales de páginas , las páginas de contribuciones de los usuarios y las páginas de diferencias.

Al hacer clic en el enlace, se vuelve a la edición anterior que no fue realizada por el último editor. Se proporciona un resumen automático de la edición y la edición se marca como menor. (Se muestra un mensaje de error si no hay un último editor al que volver).

Actualmente, la función de reversión solo está disponible para los administradores . Sin embargo, muchos usuarios que no son administradores se enfrentan ahora a actos de vandalismo con regularidad, pero no tienen acceso a esta herramienta (y no desean ser administradores o no cumplen con los estándares esperados, pero son indudablemente experimentados y confiables). Esta propuesta implementaría un proceso mediante el cual la función de reversión podría otorgarse y revocarse a usuarios que no son administradores.

Ahora hemos llegado al punto en que tenemos un consenso aproximado sobre cuáles deberían ser las restricciones y ahora se le pide a la comunidad que busque un consenso sobre su implementación. Vea la discusión anterior en Wikipedia talk:Rollback for non-administrators proposal y Wikipedia:Rollback for non-administrators . Es posible que sus preguntas o inquietudes ya se hayan considerado allí.

La forma en que funciona

Los usuarios pueden solicitar el botón de reversión si son suficientes para cumplir con el requisito mínimo que se detalla a continuación.

  1. Primero deben presentar una solicitud en la sección a continuación.
    (¿En qué sección de abajo? Lo único que veo aquí son votaciones y discusiones, lo que esperaría ver en una página de discusión. -- Stéphane Charette ( discusión ) 19:42 4 ene 2008 (UTC))[ responder ]
  2. Los administradores deben verificar el historial del colaborador para ver si es confiable en el uso de la herramienta.
    (¿Qué es exactamente lo que están comprobando los administradores? Me preocupa que la falta de una declaración o consenso al respecto pueda causar confusión. — DragonHawk ( discusión | hist ) 21:02, 4 de enero de 2008 (UTC) ) [ responder ]
    ¿No es así como empezó RFA? ¿Comprobamos las contribuciones de los usuarios para comprobar si se podía confiar en ellos? ¿En qué se diferenciará este proceso? ¿Qué ocurre cuando dos administradores no están de acuerdo? Por ejemplo, si le doy derechos a user:foo pero el administrador z no cree que sea de confianza. ¿Tenemos entonces una discusión y luego reinventamos RFA, esta vez como RFR? - Hiding T 12:53, 8 de enero de 2008 (UTC) [ responder ]
  3. Si el administrador está satisfecho, puede ir a Especial: Derechos de usuario (ver $wgAddGroups y $wgRemoveGroups) y esto agregará al usuario al grupo de usuarios de reversión, brindándole la herramienta de reversión.
  4. La herramienta será la misma que la herramienta de reversión del administrador, sin limitaciones.
    ¿Debería haber un consenso entre los administradores antes de implementar esto, ya que alteraría radicalmente su papel? - Hiding T 22:28, 8 de enero de 2008 (UTC) [ responder ]

Requisitos para que los usuarios puedan tener rollback

No existen requisitos previos para obtener las herramientas, aunque el usuario no debe tener un historial de conflictos de edición y debe demostrar la necesidad de obtener el permiso de reversión (es decir, reversión de muchos actos de vandalismo). Aunque puede que no sea fácil determinar esto, los administradores deben evaluar las solicitudes de reversión en función de los méritos individuales y revisar el historial de edición de un usuario antes de otorgarle el permiso.

Uso

Esta herramienta está disponible para editores calificados para combatir el vandalismo. Su uso está limitado a la reversión de vandalismo y de ediciones propias. Los editores que utilicen la herramienta de reversión para otros fines o que cometan errores reiterados estarán sujetos a la eliminación de la herramienta de reversión.

Retirada del permiso

En caso de abuso, cualquier administrador puede eliminar la herramienta accediendo a Special:Userrights . Los usuarios no administradores pueden informar de abusos en Wikipedia:Administrators' noticeboard/Incidents . Los administradores deben tener cuidado de dar a esta acción el mismo cuidado y atención que a un bloqueo, y se aplican las expectativas habituales con respecto a las acciones administrativas. Si se eliminan solo debido a un abuso, simplemente entréguelas a todos los editores. - Hiding T 22:59, 8 de enero de 2008 (UTC) [ responder ]

Preguntas frecuentes

¿Qué es la reversión?
La reversión es un método para revertir ediciones con un solo clic. Los usuarios con el privilegio de reversión ven un enlace "[rollback]" que aparece en las diferencias y junto a las ediciones en las páginas Special:Contributions y en los historiales de páginas, siempre que la edición sea la más reciente realizada en la página relevante. La reversión revertirá a la versión más reciente de la página que no haya sido aportada por el editor más reciente.
¿En qué se diferencia la reversión de otros métodos de reversión?
La reversión tradicional implica cargar la revisión de la página a la que se desea volver, abrir la pestaña de edición y luego guardar inmediatamente la página. El contenido de la página se reemplazará con el contenido de la revisión anterior. La reversión con la función de deshacer implica cargar una comparación y hacer clic en el enlace "deshacer"; los cambios realizados en la comparación se desharán, siempre que no haya conflictos con revisiones posteriores de la página. Hay una serie de scripts de usuario disponibles para la reversión, que generalmente implican la automatización del método de reversión tradicional.
Por el contrario, revertir una edición no implica ningún paso intermedio, por lo que ofrece una ligera ventaja en el rendimiento tanto para el servidor como para el cliente. Como se puede hacer directamente desde la página Special:Contributions , revertir todas las ediciones realizadas por una cuenta o dirección IP determinada resulta relativamente sencillo.
¿Cuáles son las limitaciones de la reversión?
La reversión se limita a revertir únicamente las modificaciones más recientes realizadas en una página. Los usuarios deberán aprender y utilizar otro método para revertir cualquier otra modificación.
Dado que la reversión no requiere que el usuario vea en ningún momento las modificaciones que está revirtiendo, existe un mayor riesgo de que los usuarios puedan realizar reversiones por error. La función de deshacer, por el contrario, muestra al usuario los cambios que está a punto de realizar para confirmarlos.
La función de reversión proporciona un resumen automático de la edición cuando se revierte una edición, que no puede ser modificada ni complementada por el usuario. Tanto la reversión tradicional como la deshacer permiten que se proporcione un resumen de la edición, al igual que la mayoría de los scripts de usuario para revertir.
La velocidad de Rollback también puede ser una desventaja si se usa incorrectamente, ya que puede acelerar enormemente las guerras de edición .
¿Cómo se relacionan estos pros y contras con la concesión de una reversión a usuarios que no son administradores?
Muchos usuarios no administradores participan regularmente en la reversión de errores vandálicos, y la función de reversión puede hacer que esta tarea sea mucho más eficiente, ya que es una operación de un solo clic, a diferencia de los métodos que requieren la carga de páginas intermedias.
Sin embargo, debido a que la reversión no permite a los usuarios verificar lo que están revirtiendo (no es cierto; consulte las ventanas emergentes ) ni proporcionar un resumen de la edición, presenta el riesgo de un mal uso accidental, y debido a que es una operación de un solo clic que permite revertir rápidamente todas las contribuciones de un usuario o dirección IP, presenta el riesgo de un mal uso intencional. Estos riesgos aumentan naturalmente en una base de usuarios que es más grande y/o menos experimentada en la identificación y el manejo del vandalismo.
¿Estos problemas son exclusivos de la herramienta de reversión?
No; otros métodos de reversión pueden utilizarse de forma similar. Sin embargo, siempre que la reversión se utilice para el fin previsto (revertir un vandalismo simple), no debería haber problemas. La cuestión es asegurarse de que un posible usuario de la reversión pueda distinguir de forma fiable el vandalismo simple de otras ediciones y que se pueda confiar en que utilice la reversión solo en las primeras.

Historial de revisiones

A continuación se indican los cambios significativos de esta propuesta. El número total de comentarios de alto nivel a favor o en contra en el momento del cambio se indica entre paréntesis.

Encuesta de paja

Cerrado y archivado. Ver Wikipedia:Reversión de usuarios no administradores/Encuesta para ver los resultados.

Propuestas alternativas

Estas discusiones sobre propuestas alternativas se han trasladado a un archivo y se pueden encontrar aquí .

Cuente los equivocados

Esta discusión se ha movido a la página de discusión y se puede encontrar aquí .

Scripts y otras herramientas

propuesta hecha originalmente por Gracenotes

Casi todos los que están aquí no tienen objeción a que se utilicen ampliamente herramientas como Twinkle, pero muchos tienen objeciones a añadir el botón [rollback] a la interfaz de usuario. Por lo tanto, hay que dar a los usuarios autoconfirmados la capacidad técnica de hacer una reversión, una acción que requiere un token único, pero no incluir el botón de reversión en las páginas de diferencias, historial o contribución de los usuarios (es decir, no incluirlo en absoluto). En este caso, solo se puede acceder a la reversión con una herramienta de terceros como Twinkle, con la que todo el mundo parece estar de acuerdo. Los problemas de velocidad de E/S y ancho de banda se resuelven, y dado que es posible crear resúmenes personalizados con el permiso de reversión, no se pierde la funcionalidad de Twinkle (ni de otras herramientas antivandálicas).

Soporte (herramientas)

  1. Según mis comentarios en Wikipedia talk:Reversión sin permiso del administrador#Otra idea . -- Ned Scott 08:58, 9 enero 2008 (UTC) [ responder ]
  2. Según mi respuesta en Wikipedia talk:Non-administrator rollback#Otra idea y los comentarios de Amidaniel y míos en #wikimedia-tech en freenode. -- Cobi ( t | c | b ) 10:58, 9 de enero de 2008 (UTC) [ responder ]
  3. Como ya he dicho antes, el requisito de que los usuarios "activen" la herramienta por sí mismos y tengan algunos conocimientos técnicos sobre ella de antemano es una buena medida de seguridad. Equazcion • ✗ / C • 11:35, 9 de enero de 2008 (UTC)
    ¿Protección contra qué, exactamente? Seguramente no contra los vándalos... Miércoles 13 23:32, 9 enero 2008 (UTC) [ responder ]
    Las personas que deseen realizar modificaciones masivas e intencionadas podrían utilizar con la misma facilidad un script o un bot. -- Ned Scott 00:18, 10 de enero de 2008 (UTC) [ responder ]
  4. Fuerte apoyo a la espera de la viabilidad de una característica de este tipo (¿puede un script "desbloquear" o acceder a una característica del servidor?). Bien hecho. Creo que esta propuesta tendrá más posibilidades de aprobarse. En última instancia, nada cambia, excepto la eficiencia. Como TWINKLE no requiere autorización, esta propuesta no creará ninguna burocracia nueva y no dará ningún poder adicional a los administradores. De hecho, me sorprendería si esta característica recibe más de unos pocos votos selectos en contra. Esto también resolvería la propuesta de Bot, que parece tener un amplio consenso (ver más abajo). Cubriría la necesidad de credenciales, en el sentido de que el usuario tendría que tener suficiente experiencia para saber cómo usar scripts de usuario y para qué se pueden usar. Mientras TWINKLE y demás existan, el abuso de la reversión nunca desaparecerá, por lo que el argumento del abuso de la reversión es nulo. En mi opinión, esto es lo que hemos estado buscando, la solución a todos los problemas. (Perdón si parezco tan entusiasta, pero parece tan simple y, sin embargo, tan brillante).-- Vox Rationis ( Discusión | contribuciones ) 14:41 9 ene 2008 (UTC) [ responder ]
  5. ¿No habrá nueva burocracia? Tienes mi (inesperado) apoyo. Quizá hayas cortado el nudo gordiano. -- Doc g 20:10, 9 enero 2008 (UTC) [ responder ]
  6. Apoyo . En realidad, este es un cambio profundo en la fabricación de salchichas. Es una mejora técnica, no realmente un cambio de política. Tal vez sería mejor simplemente aceptar que las personas malas pueden ser disruptivas con o sin ella y simplemente dejarlo pasar... pero si la gente no lo acepta, al menos esto es un paso adelante. -- Gmaxwell ( discusión ) 20:21, 9 de enero de 2008 (UTC) [ responder ]
  7. Apoye esto o una opción en las preferencias del usuario que debe ser activada por el usuario (creí que amidaniel estaba trabajando en eso...) Sr. Z- man 20:34, 9 de enero de 2008 (UTC) [ responder ]
  8. Apoyo Buena idea, Majorly ( discusión ) 20:39 9 ene 2008 (UTC) [ responder ]
  9. El apoyo responde a mis inquietudes sobre la propuesta original. Las preocupaciones de que esto podría facilitar el vandalismo son exageradas. -- Haemo ( discusión ) 23:10 9 ene 2008 (UTC) [ responder ]
  10. Pomte 13:33 13 enero 2008 (UTC) [ responder ]
  11. ¡Claro que sí ! Como ya he dicho antes, necesitamos herramientas como estas. Dos Uno Seis Cinco Cinco Comenta mi grandeza 15:13, 17 de enero de 2008 (UTC) [ responder ]
  12. Fuerte apoyo por la sencilla razón de que facilita la edición a todo el mundo. No es una amenaza para la seguridad porque, aunque también facilita la edición a los posibles vándalos, estos pueden seguir haciendo lo que hace la función de reversión, sólo que les lleva más tiempo. Y no sólo se está utilizando su tiempo de forma ineficiente, sino también el de quienes luchan contra los vándalos. -- Felipe Aira 08:46, 30 de enero de 2008 (UTC) [ responder ]

Oponerse (herramientas)

  1. ¡Por supuesto que no! Independientemente de si se puede hacer o no (ver mi pregunta en la sección de discusión), es "seguridad" a través de la oscuridad en su forma más pura, algo que detesto por definición. No, gracias. Si se puede hacer con Twinkle, se puede hacer igual con Greasemonkey (que no se puede cerrar para un usuario) y, luego, bienvenido a Wikipedia, donde cada vándalo tiene acceso a la reversión si le place. ¿Por qué molestarse con scripts? Simplemente haga el enlace class="rollback-hidden" que por defecto es .rollback-hidden { display: none; } en el CSS de todo el sitio. Luego, es solo una línea en su .css para habilitarlo; llame al hackeo de su monobook "credenciales", si lo desea. Miércoles 13 21:01, 9 enero 2008 (UTC) [ responder ]
    Aún sería posible eliminarlo en caso de abuso, por lo que en realidad es mejor que esos scripts solos. -- Ned Scott 22:11, 9 de enero de 2008 (UTC) [ responder ]
    Um, ¿perdón? El CSS también se puede reemplazar con un script GM de una sola línea que haga (aproximadamente) document.write('<style type="text/css">.rollback-hidden { display: inline; }</style>') o algo similar (o podría simplemente desactivar el CSS en mi navegador por completo). Lo siento, pero ocultar funciones no significa desactivarlas. Todo lo que está oculto se puede descubrir y no tienes control sobre lo que hace el cliente. Miércoles 13 22:34, 9 enero 2008 (UTC) [ responder ]
    La función Rollback se puede eliminar por completo de una cuenta específica . Si alguien está abusando de ella, ya sea a través de TWINKLE o de su propia modificación CSS, podemos desactivarla. -- Ned Scott 00:14, 10 de enero de 2008 (UTC) [ responder ]
    Entiendo tu preocupación sobre la "seguridad a través de la oscuridad", y creo que es válida. Sin embargo, dado que los scripts de usuario ya tienen rollback, cada vándalo podría potencialmente tener acceso a rollback de todos modos. Todo lo que hace esta propuesta es hacerlo más eficiente. Además, ¿tenemos algún caso reportado de vándalos que usen TWINKLE y otros por vandalismo? Mi experiencia es que la mayoría de los vándalos son direcciones IP, y aquellos que crean cuentas rara vez se involucran en algún tipo de vandalismo inteligente (el tipo que hace mucho daño, como movimientos masivos de páginas, etc.). Además, suponiendo que un vándalo consiga esto, será más fácil para la gente revertirlo, porque otros también tendrán rollback. Ahora, suponiendo las declaraciones anteriores, esta característica nos traería una cantidad muy pequeña de vándalos de élite armados con un rollback ligeramente más eficiente, contra una gran cantidad de patrulleros RC, con un rollback ligeramente más eficiente. En términos numéricos, esta eficiencia tiene un gran multiplicador, en comparación con el pequeño multiplicador del vándalo. Nuevamente, esto supone que alguna vez hemos tenido un caso de vandalismo asistido por script de usuario de reversión en el pasado, lo cual, si bien (obviamente) no puedo saber con seguridad, en mi experiencia no he visto que se haga algo así. -- Vox Rationis ( Discusión | contribuciones ) 22:19, 9 de enero de 2008 (UTC) [ responder ]
    No, este tipo de brotes no han ocurrido en el pasado (al menos no que yo sepa) simplemente porque, como dicen algunos, los métodos tipo Twinkle tardan mucho en hacer una sola reversión, lo que unido a la latencia del servidor hace que una interrupción tan masiva sea inviable. Sin embargo, lo que esta propuesta plantea es básicamente hacer que sea totalmente posible para un vándalo hacer reversiones a un ritmo de cientos por minuto (simplemente abra las contribuciones de alguien, obtenga los tokens de reversión y comience a hacer clic con Ctrl en los enlaces de reversión). Y no digan que podemos permitirnos eso porque tenemos más patrulleros: cuando decenas de ellos de repente comiencen a pelearse y a entrar en conflicto por revertir al vándalo, no será agradable para los servidores. Miércoles 13 22:34, 9 de enero de 2008 (UTC) [ responder ]
    Simplemente borré mi sandbox y luego lo revertí. Me tomó 1,8 segundos (lo cronometré, así que hay alguna imprecisión, teniendo en cuenta el tiempo de reacción, probablemente 1,5 segundos). Suponiendo que usan un complemento de Firefox como Linky, que puede abrir todos los enlaces de una página en una nueva pestaña a la vez, listo, crearon una reversión masiva, ya haciendo 500 (número máximo de artículos vistos a la vez en la página de contribuciones del usuario) en menos de un minuto (suponiendo que su conexión a Internet se mantenga, los servidores de WP se mantengan y su RAM se mantenga). En resumen: TWINKLE no es tan lento, por lo que el aumento de rendimiento no sería tan notable como para afectar la cantidad de vandalismo de WP. -- Vox Rationis ( Discusión | contribuciones ) 23:07, 9 de enero de 2008 (UTC) [ responder ]
    Gracias por esas estimaciones. Desafortunadamente, esto solo empeora las cosas. ¿Qué sucedería si (dado que los tokens de reversión se obtienen previamente) la reversión se pudiera ejecutar a, digamos, 5000 por minuto? ¿Te importaría verificarlo? ¿También tienes en cuenta que los resúmenes de reversión son editables? ¿Se pueden falsificar? "Ediciones revertidas por <insertar IP> a la última versión por <insertar administrador>": ¡parece que estoy revirtiendo IP molestas a versiones aprobadas por el administrador! ¿Quién sospecharía alguna travesura? Oh, espera, podría ejecutar eso en 10 nombres de usuario diferentes para mezclar aún más la interrupción. Sí, estamos hablando de un vandalismo bastante "de élite", pero si yo soy capaz de esto, también lo puede ser cualquier vándalo decidido y con inclinaciones técnicas. Mi punto principal es que no les demos a los vándalos nuestras propias armas contra ellos. En absoluto. Miércoles 13 23:26, 9 de enero de 2008 (UTC) [ responder ]
    La reversión sólo puede ejecutarse a razón de cinco por minuto para usuarios que no sean administradores y cinco cada dos minutos para usuarios que no hayan sido confirmados automáticamente. Esta tasa la impone el software y no se puede anular. La seguridad a través de la oscuridad no es el objetivo de esta propuesta; el uso indebido no intencional de la reversión por parte de los recién llegados sí lo es. Notas de gracia T § 16:14, 11 de enero de 2008 (UTC) [ responder ]
    No hago comentarios sobre el resto, pero para empezar, los vándalos han usado Twinkle en el pasado para vandalizar de manera más rápida y eficiente. La primera vez que lo vi fue Undercity  ( discusión  · contribuciones ) que usó Twinkle para volver a su página vandalizada y luego advertir a quienes lo habían revertido. [1] - auburn pilot talk 00:30, 10 de enero de 2008 (UTC) [ responder ]
    Mi principal preocupación sobre la posibilidad de dar la reversión a todos los usuarios autoconfirmados es que no muchos editores nuevos saben que Twinkle existe. La mayoría de los usuarios que lo usarían con fines disruptivos están bloqueados y se han ido o se han ido a otro sitio títere antes de tener la oportunidad de saber que Twinkle existe. Los vándalos están demasiado ocupados reemplazando páginas con "él es un gay homo con un pene pequeño" como para molestarse en aprender cómo contribuir de manera constructiva y las herramientas que pueden ayudar en ese proceso. Al incluirlo como parte de la cuenta predeterminada, lo haces visible, directamente bajo la nariz de un vándalo. Es como dejar tu auto sin llave en una calle transitada y dejar tu billetera y tu rolex en el asiento. Es en gran medida un sistema de seguridad por oscuridad como mencionó Misza anteriormente. Es por eso que me opuse a las dos propuestas similares a esta, y probablemente me opondré a esta a menos que alguien pueda explicarme cómo es probable que no se abuse de esto. -- Nn123645 ( discusión ) 05:52 10 ene 2008 (UTC) [ responder ]

Neutral (herramientas)

Discusión (herramientas)

Disculpen mi ignorancia sobre el funcionamiento interno de MediaWiki, pero ¿el token de reversión es realmente computable en el lado del cliente (dada una URL diferente, por ejemplo)? Hace algún tiempo estuve investigando este tema (y el código de MediaWiki) y llegué a la conclusión de que se basa en una sal que solo se almacena en el lado del servidor. ¿Esa conclusión era incorrecta? Francamente, si fuera computable en el lado del cliente, no veo en absoluto el propósito del token. Miércoles 13 20:29, 9 enero 2008 (UTC) [ responder ]

Supongo que se entiende que esto funcionaría solo en el nivel de API. Supongo que se necesitaría al menos una búsqueda previa para el token de reversión (es decir, algo como http://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvtoken=rollback&titles=User:SQL ). Por cierto, esto ya funciona, compruébalo... Te dará un token de reversión válido :) ¡ Consulta SQL ! 20:51, 9 de enero de 2008 (UTC) [ responder ]
Hmm, entonces básicamente estamos hablando de usar la función de reversión para reducir las solicitudes de servidor de 3 (obtener la diferencia, obtener el formulario de edición usando &action=undo , publicar el contenido revertido) a 3 (obtener la diferencia, obtener el token de reversión, "hacer clic" en la URL de reversión)? :) Oh, esperen, estamos ahorrando algo de ancho de banda al no tener que publicar el contenido revertido. Yay, ¿me perdí algo? </sarcasm> Ah, y todavía estoy esperando una respuesta definitiva sobre si el token es computable del lado del cliente. Miércoles 13 21:10, 9 enero 2008 (UTC) [ responder ]

Presentar los pasos a seguir para revertir (digamos... WP:ACC , al azar).

  1. Obtener diferencia (45956 bytes)
  2. URL de deshacer captura (81946 bytes)
  3. Enviar texto de la página anterior (4643 bytes)

Para un total de: 132545 bytes

Pasos propuestos (si te sigo correctamente, misma página)

  1. Obtener diferencia (45956 bytes)
  2. Obtener token de reversión (372 bytes)
  3. Enviar URL de reversión (151 bytes)

Para un total de: 46479 bytes

Eso supone un ahorro del 65% en ancho de banda, suponiendo que las cookies y demás sean las mismas entre solicitudes, suponiendo que todo esto esté correcto. ¡ Consulta SQL ! 21:51, 9 de enero de 2008 (UTC) [ responder ]

Bots antivandálicos

Cierro esto, porque ya se ha actuado al respecto: [2] [3] . — Random832 19:49, 10 de enero de 2008 (UTC) [ responder ]

Independientemente de si se aprueba o no la propuesta original (espero que así sea):

Propongo que demos la reversión a los bots antivandálicos ( ClueBot , VoABot II , CounterVandalismBot y el actualmente inactivo MartinBot ). No hay posibilidad de abuso y nadie podría notar la diferencia porque los bots darían su propio resumen de edición al solicitar la reversión (actualmente una característica poco conocida de la reversión). Simplemente sería más fácil para los bots y los servidores (tanto los servidores WMF como los servidores en los que se ejecutan los bots) ya que estos bots hacen miles de reversiones cada día . -- Cobi ( t | c | b ) 02:38, 7 de enero de 2008 (UTC) [ responder ]

Soporte (bots)

  1. Como nominador. -- Cobi ( t | c | b ) 02:38, 7 de enero de 2008 (UTC) [ responder ]
  2. Apoyo si solo los bots obtienen el rollback Alex fusco 5 02:45, 7 enero 2008 (UTC) [ responder ]
  3. Apoyo a ambos bandos. Portia1780 ( discusión ) 02:53 7 ene 2008 (UTC) [ responder ]
  4. Soporte Si alguien necesita la herramienta de reversión para mejorar la carga del servidor, entonces estos bots sin duda la necesitan... sólo piensen en cuánto más trabajo tendríamos que hacer si no estuvieran trabajando duro todas las horas del día y de la noche. -- Geoff Riley ( discusión ) 02:55, 7 de enero de 2008 (UTC) [ responder ]
  5. Los bots van a hacer la reversión ya sea que tengan esto o no, por lo que parte de la oposición basada en que los bots cometen errores no tiene mucho sentido. Sr. Z- man 04:09, 7 de enero de 2008 (UTC) [ responder ]
  6. Los robots de soporte necesitan esta función para reducir el uso de ancho de banda del servidor. Carlosguitar (listo y dispuesto) 04:23, 7 de enero de 2008 (UTC) [ responder ]
  7. Soporte completo como parte del comando WP:BAG β 04:31, 7 enero 2008 (UTC) [ responder ]
  8. Los robots de control de RC necesitan toda la ayuda que puedan conseguir. BJ Talk 04:44, 7 enero 2008 (UTC) [ responder ]
  9. Fuerte apoyo Cualquier cosa que haga que el todopoderoso ClueBot funcione mejor es algo que debería implementarse. -- Nn123645 ( discusión ) 05:37 7 ene 2008 (UTC) [ responder ]
  10. ( Miembro de BAG ) Apoyo condicional . Apoyo la concesión de este privilegio a estas cuentas si existe un sistema para concederlo y revocarlo. No apoyo la creación de un nuevo método sólo para dar cabida a estas cuentas en este momento. (Tampoco apoyo simplemente convertirlas en +sysop en este momento). — xaosflux Discusión 06:06, 7 enero 2008 (UTC) [ responder ]
  11. Apoyo. No se me ocurre ningún inconveniente probable. Si los hubiera, sería bastante fácil revocar los privilegios de un total de tres bots. Rivertorch ( discusión ) 06:48 7 ene 2008 (UTC) [ responder ]
  12. Fuerte apoyo, independientemente de si se implementa o no la propuesta principal (que debería implementarse, en mi opinión): es una idea brillante y debería implementarse lo más rápidamente posible. Ashdog137 ( discusión ) 08:32 7 ene 2008 (UTC) [ responder ]
  13. Soporte condicional , sólo en caso de que se indique en los resúmenes de edición que las reversiones fueron realizadas por bots y no por usuarios comunes. -- Angelo ( discusión ) 09:30 7 ene 2008 (UTC) [ responder ]
    El resumen de la edición será exactamente el mismo que ahora (Revirtiendo el posible vandalismo por Special:Contributions/USER_REVERTED a la versión por USER_PREVIOUS. ¿Falso positivo? Repórtelo . Gracias, ClueBot . (MySQL-ID) (Bot)) , utilizando la característica poco conocida de reversión para proporcionar el resumen de edición del propio bot. -- Cobi ( t | c | b ) 10:00, 7 enero 2008 (UTC) [ responder ]
  14. Soporte Si hay un grupo que sin duda merece la reducción, son estos bots antivandálicos. No hay razón para no darles un impulso de rendimiento adicional. Spellcast ( discusión ) 13:40 7 ene 2008 (UTC) [ responder ]
  15. Soporte - No veo ningún problema con esto. Burzmali ( discusión ) 13:41 7 ene 2008 (UTC) [ responder ]
  16. Soporte -- Quintote ( discusión ) 14:16 7 ene 2008 (UTC)[ responder ]
  17. Soporte , me parece obvio... ¡Consultame SQL ! 16:37, 7 enero 2008 (UTC) [ responder ]
  18. Los argumentos en contra son tontos. — Random832 16:42, 7 enero 2008 (UTC) [ responder ]
  19. Comentario Es de suponer que cualquier administrador puede hacer esto. Es decir, esta propuesta es discutible, a menos que exista alguna disposición que no permita conceder permiso a los bots, en cuyo caso, apoyo la eliminación de esa restricción. Es una decisión del administrador, y el administrador es responsable de ella. -- Abd ( discusión ) 16:46 7 ene 2008 (UTC) [ responder ]
  20. Soporte Creo que esto es un hecho, si un administrador puede darle la herramienta a un usuario regular, entonces un bot confiable también lo sería. 1 != 2 16:50, 7 enero 2008 (UTC) [ responder ]
  21. Apoyo Obvio. Los robots anti-vandalismo ya están usando su propio sistema de reversión: proporcionar una API ya utilizada no causará más daño. Los beneficios incluyen reversiones más rápidas sin los efectos negativos de tener que calcular conflictos de edición. -- Sigma 7 ( discusión ) 19:11, 7 enero 2008 (UTC) [ responder ]
  22. No hay razón para no hacerlo. Ya confiamos en que harán una gran cantidad de reversiones cada minuto. Bien podríamos dejar que lo hagan de manera más eficiente. No habría cambios en cuanto a qué artículos se revierten, o cuándo, o bajo qué condiciones. En cuanto a la preocupación por los hackers que se plantea a continuación, no creo que el acceso a la reversión vaya a incitar más interés en hackear estos bots. La utilidad para un hacker de controlar un bot sigue estando prácticamente ahí incluso sin el acceso a la reversión. Como nota al margen, Franamax necesita ver menos películas. Equazcion • ✗ / C • 20:17, 7 de enero de 2008 (UTC)
  23. Apoyo Independientemente del debate general sobre la reversión. Como le dije a Cobi, nunca he visto que AVB causara problemas de contenido significativos, por lo que esto parece algo bueno. MBisanz talk 21:39, 7 enero 2008 (UTC) [ responder ]
  24. Soporte . Spebi 22:05, 7 enero 2008 (UTC) [ responder ]
  25. Soporte 99of9 ( discusión ) 23:10 7 ene 2008 (UTC) [ responder ]
  26. Apoyo , pero ¿por qué dárselo a MartinBot? Marlith T / C 23:13, 7 enero 2008 (UTC) [ responder ]
  27. Los robots necesitan las herramientas más que nadie aquí. Capitán Panda 23:15, 7 de enero de 2008 (UTC ) [ responder ]
  28. Soporte Ahora esto - lo puedo ver. Los bots no deben ejecutarse sin la aprobación de BAG . y los bots son los que pueden saturar los recursos del servidor a su velocidad. ¿Agujeros de seguridad? Sí, hay algunos. En última instancia, los bots son vigilados (por el propietario o el administrador) y deben desactivarse cuando surge un problema. (La resolución conduce a una posible reactivación en el futuro). — master son T - C 23:26, 7 de enero de 2008 (UTC) [ responder ]
  29. Apoya a SJMNY ( discusión ) 00:14 8 ene 2008 (UTC) [ responder ]
  30. Excelente idea. Acalamari 00:17 8 enero 2008 (UTC) [ responder ]
  31. Apoyo . Puedo apoyar esto a pesar de oponerme a ello con humanos. Master_son expresó bien todos mis puntos. Esas cuentas tienen una de las mayores cantidades de reversión, por lo que su eficiencia afectaría más a los servidores. Siempre se las puede bloquear si entran en conflicto. Apoyaría que la bandera de reversión se otorgara automáticamente cuando se obtiene la bandera de bot. Royal broil 01:05, 8 de enero de 2008 (UTC) [ responder ]
    El único problema con la asignación de la función de reversión a la bandera de bot es que los bots antivandálicos no están marcados. Esto se hace para que sus ediciones no queden ocultas ("ocultar ediciones de bots") en los cambios recientes. -- Cobi ( t | c | b ) 01:31, 8 enero 2008 (UTC) [ responder ]
  32. slakr pregunta a continuación si lo necesitan. Nadie lo necesita, pero es útil. – thedemonhog discusión • ediciones 01:40, 8 enero 2008 (UTC) [ responder ]
  33. También se necesitan robots de soporte para ayudar con los vándalos. SuperGodzilla2090 4 TACOZ! 01:45, 8 de enero de 2008 (UTC) [ responder ]
  34. Soporte : Es posible que los bots no necesiten esta herramienta, pero seguro que sería útil, incluso si ClueBot fuera prácticamente imbatible con la reversión de administrador.— Animum ( discusión ) 02:17 8 ene 2008 (UTC) [ responder ]
    COMENTARIO -- ¿Cómo puedes justificar que se le dé a robots incontrolados e irresponsables tanto poder sobre el funcionamiento de Wikipedia si admites que no es necesario? Smith Jones ( discusión ) 02:31 8 ene 2008 (UTC) [ responder ]
    Smith Jones, esto no cambiará en absoluto lo que hacen los bots . Actualmente funcionan de la misma manera, pero esto les permite decirles a los servidores de Wikipedia "Por favor, revierta las ediciones del usuario: xxxxxx en el artículo yyyyyy" en lugar de "Dame la lista de cambios para el artículo yyyyyy.", "Ok, ahora dame los datos para la revisión zzzzzzzz del artículo yyyyyy." "Ok, ahora dame el formulario de edición para el artículo yyyyyy." "Ok, aquí está el texto (que el servidor le dio al bot anteriormente) para la publicación en el artículo yyyyyy." Como puedes ver, el primero es mucho mejor que el segundo. -- Cobi ( t | c | b ) 02:48, 8 de enero de 2008 (UTC) [ responder ]
    Gracias, creo que ahora entiendo mejor el tema. Sin embargo, me opongo a esto, porque a través de mis recientes experiencias con los bots aprendí que no se puede manipularlos ni razonar con ellos sin la ayuda de un administrador. Smith Jones ( discusión ) 02:52 8 ene 2008 (UTC) [ responder ]
    ... Sin embargo, nunca has tenido un encontronazo con ClueBot  ;) -- Cobi ( t | c | b ) 03:10, 8 de enero de 2008 (UTC) [ responder ]
  35. Soporte Lo único que cambia aquí es la forma en que se revierten las ediciones. Solo puedo ver esto como algo positivo. Majorly ( discusión ) 03:45, 8 de enero de 2008 (UTC) [ responder ]
  36. Apoyo Como antes, mi opinión no ha cambiado. -- Charitwo talk 05:16, 8 enero 2008 (UTC) [ responder ]
  37. Parece razonable apoyar esto. Mientras sigan brindando resúmenes de ediciones y notificaciones en las páginas de discusión, estos bots deberían ser lo más eficientes posible. Eluchil404 ( discusión ) 05:30 8 ene 2008 (UTC) [ responder ]
  38. Soporte -- C l a n CC ( Discusión ) 05:36 8 ene 2008 (UTC) [ responder ]
  39. Soporte . ¡Por supuesto que se les debería dar una reversión a los bots antivandálicos! Los bots no editan la guerra, es extremadamente improbable que se vuelvan "rebeldes" o cometan actos de vandalismo, y eso no cambiará su comportamiento en lo más mínimo. Darles una reversión a los bots simplemente los hará más eficientes y más fáciles de usar en los servidores. Pyrospirit  ( discusión  · contribs ) 05:53, 8 de enero de 2008 (UTC) [ responder ]
  40. Apoyo fuerte : muéstrenme una razón por la que los bots no deberían ser revertidos y lo reconsideraré. No afecta mucho la velocidad de los bots, así que si van a cometer errores, lo harán de todos modos a la misma velocidad. La única diferencia que se logrará con este cambio es una carga reducida del servidor, lo cual cuenta con mi aprobación. James086 Discusión | Correo electrónico 06:00, 8 enero 2008 (UTC) [ responder ]
  41. -- Rschen7754 ( T C ) 06:05, 8 enero 2008 (UTC) [ responder ]
  42. Soporte Un grupo muy pequeño que puede ser monitoreado fácilmente, y dado que hacen una gran cantidad de contribuciones, esto proporcionará una mayor ventaja. -- Falcorian  (discusión) 06:27 8 ene 2008 (UTC) [ responder ]
  43. Soporte : El consenso general ha sido que los bots proporcionan un recurso invaluable para combatir el vandalismo y otros procedimientos de limpieza en WP, y la función de reversión puede potencialmente darles otra herramienta para ayudarlos en sus esfuerzos. Algunos bots ya tienen una función de reversión en vigencia, sin embargo. Seicer ( discusión ) ( contribuciones ) 07:01, 8 de enero de 2008 (UTC) [ responder ]
  44. Ya están haciendo la reversión a la vía lenta. En cuanto a la rapidez con la que se pueden hacer los errores, el factor limitante de las ediciones de los bots es la cantidad de vandalismo, no la velocidad a la que pueden revertirlo. MER-C 10:55, 8 de enero de 2008 (UTC) [ responder ]
  45. Apoyo , pero francamente, se puede hacer dentro de la política existente: permiso otorgado por los burócratas por recomendación positiva del BAG . Miércoles 13 11:26, 8 enero 2008 (UTC) [ responder ]
  46. Fuerte apoyo - Esto no les dará ningún poder que no tengan ya, sólo reducirá la carga del servidor cuando lo hagan. עוד מישהו Od Mishehu 12:12, 8 enero 2008 (UTC) [ responder ]
  47. Apoyo - por Od Mishehu. -- Disidente anónimo Discusión 12:38, 8 enero 2008 (UTC) [ responder ]
  48. Apoyo . Tiene sentido, ya hacen lo mismo. Coemgenus 13:46, 8 enero 2008 (UTC) [ responder ]
  49. Apoyo especialmente a ClueBot. —Comentario anterior sin firmar añadido por Dolive21 ( discusión • contribs ) 16:00, 8 enero 2008 (UTC)[ responder ]
  50. Soporte . No se me ocurre ninguna razón plausible por la que se deba evitar que los bots operen en los servidores de una manera más eficiente cuando realizan exactamente la misma tarea que antes. -- ais523 16:19, 8 de enero de 2008 ( U T C )
  51. El soporte se ofrece como una solicitud de operación similar a la forma en que se aprueban los bots ahora, simplemente se convierte en una de las cosas habituales que se pueden aprobar. -- Rocksanddirt ( discusión ) 17:32, 8 de enero de 2008 (UTC) [ responder ]
  52. Apoyo . No veo ninguna razón para no permitir que los robots antivandálicos operen de manera más eficiente, siempre que el resultado final de sus acciones siga siendo el mismo (lo cual, según todos los indicios, ocurrirá). -  AWeenieMan  ( discusión ) 19:39, 8 de enero de 2008 (UTC) [ responder ]
  53. Apoya el sentido común. el wub "?!" 21:37, 8 de enero de 2008 (UTC) [ responder ]
  54. Apoyo . No hay ningún inconveniente tangible para esta solicitud. -- JamesTeterenko ( discusión ) 21:58 8 ene 2008 (UTC) [ responder ]
  55. Apoyo. , por el nombre y por Od Mishehu  ( discusión  · contribs ). Cirt ( discusión ) 23:29 8 ene 2008 (UTC). [ responder ]
  56. Soporte , bajo la condición de que las aprobaciones sean mantenidas por el BAG, no por esta página de políticas, ya que ellos tienen un mejor conocimiento técnico para abordar adecuadamente si un bot de este tipo lo necesita. Se ha demostrado aquí que un aumento de rendimiento sería significativo. Algunos argumentan que esto permitiría más ediciones, y por lo tanto más presión sobre el servidor, pero como estos bots comprueban cada diferencia (hasta donde yo sé, corrígeme si me equivoco) no habría ningún cambio en el número de reversiones, sólo haría dichas acciones más fáciles, más limpias, etc. Además, el argumento de que esto daría a los bots demasiado poder, es, como yo lo veo, inválido. Estos bots ya pueden editar a velocidades inhumanas, y probablemente podrían ir más rápido, suponiendo que la página RC vaya más rápido (en otras palabras, el tráfico de WP se incrementa significativamente). Por lo tanto, esto no cambiaría la cantidad de poder que ya tienen. -- Vox Rationis ( Discusión | contribuciones ) 00:01, 9 de enero de 2008 (UTC) [ responder ]
  57. Pomte 00:57 9 enero 2008 (UTC) [ responder ]
  58. Soporte . No es tan subjetivo, lento y burocrático como la propuesta anterior. Esto simplemente agrega una opción a las aprobaciones de bots para hacer que algunos servidores sean más eficientes. Aunque no veo un gran aumento de rendimiento neto como el anterior, no hay mucho que perder con la forma actual de hacer las cosas, por lo que vale la pena. Voice -of- All 06:48, 9 de enero de 2008 (UTC) [ responder ]
  59. Me opongo a la broma, porque ClueBot me gana en demasiadas reversiones. Es broma, apoyenme . sho y 16:01, 9 de enero de 2008 (UTC) [ responder ]
  60. Soporte . Siempre que se pueda hacer el mismo trabajo utilizando menos recursos es algo bueno. Los bots seguirán haciendo su trabajo de una manera que demande menos recursos limitados (grandes, pero limitados). Xymmax ( discusión ) 17:49 9 ene 2008 (UTC) [ responder ]
  61. Soporte : los bots ya son capaces de causar grandes cantidades de daño, por lo que esto no debería ser un gran problema. — Ashley Y 21:09, 9 de enero de 2008 (UTC) [ responder ]
  62. Soporte para Betacommand.-- Phoenix - wiki 21:48, 9 enero 2008 (UTC) [ responder ]
  63. Soporte : van a revertir el problema de todas formas; ¿por qué no reducir la carga del servidor mientras lo hacen? Las restricciones de edición previenen el síndrome del "bot fugitivo" con bastante facilidad. -- Haemo ( discusión ) 23:07 9 ene 2008 (UTC) [ responder ]
  64. El apoyo tiene sentido. -- Ned Scott 03:21, 10 de enero de 2008 (UTC) [ responder ]
  65. Fuerte apoyo . ¿Por qué no? Hay muchas razones por las que deberían hacerlo. La mayoría de ellas se mencionan arriba. Tiddly - Tom 18:56, 10 de enero de 2008 (UTC) [ responder ]

Oponerse (a los bots)

  1. Hay dudas de que los humanos reales deberían tener la capacidad, pero ¿se debería dar la autoridad a un proceso automatizado? El objetivo de los bots es que se los examine rigurosamente para determinar su capacidad de hacer juicios mecanizados caso por caso. ¿Ahora se propone permitir que el bot juzgue una edición y, basándose en esos resultados, deshaga más ediciones sin evaluación? Lawnmower Man o Terminator , elijan. Además, ¿los bots ya no están codificados para una carga mínima del servidor? ¿Podemos tener alguna opinión oficial de BAG sobre esto? (Sin ofender a los BAG-ers que ya están presentes) Franamax ( discusión ) 03:49, 7 de enero de 2008 (UTC) [ responder ]
    Pensándolo un poco más, los bots ya pueden solicitar con bastante facilidad el historial de la página y elegir cualquier edición a la que deseen volver una vez que hayan identificado el vandalismo, pero todavía no lo están haciendo. Parece una cuestión de ampliar y validar el código. Si BAG quiere ampliar la funcionalidad, ¿es este el lugar adecuado para solicitarlo? Después de pensarlo, puede que sea un problema completamente independiente que requiera la participación de la comunidad por separado. :( Franamax ( discusión ) 04:11, 7 de enero de 2008 (UTC) [ responder ]
    Como miembro del grupo de aprobación de bots, permítanme señalar algunos puntos. Los AVB (bots antivandálicos) requieren una enorme cantidad de recursos para funcionar, tanto en los servidores de Wikimedia como en el sistema anfitrión. El método estándar de reversión requiere tres llamadas al servidor: obtener la diferencia, obtener el cuadro de edición y luego enviar el texto actualizado. A pequeña escala, eso no significa mucho. Pero cuando tienes un bot que verifica cada diferencia y revierte una gran cantidad de datos que se suman a una gran cantidad de transferencia de datos (en el rango de gigabytes) semanalmente. La reversión, por otro lado, es muy buena para los servidores. Con la reversión, se obtiene la diferencia y se envía el token de reversión. La reversión está hecha. No hay necesidad de volver a cargar la página o volver a enviar el contenido de la página. En cuanto a cómo funcionan los bots, si un vándalo realiza más de una edición, todas deberían revertirse. En cuanto al juicio de edición, sucede lo mismo, siguen verificando la diferencia. Hay muy pocos vándalos que hagan algo parecido a ediciones constructivas y todas las ediciones que hagan seguidas deberían revertirse. La reversión de los AVB es una muy, muy buena idea. Es mejor para los servidores y para los bots. No hay necesidad de temer a los bots del tipo Terminator. No existen. β command 04:19, 7 enero 2008 (UTC) [ responder ]
    Aunque no estoy seguro, creo que así es básicamente como funcionan. Es simplemente una reversión manual que se realiza automáticamente. Sr. Z- man 04:15, 7 de enero de 2008 (UTC) [ responder ]
  2. Oponerse a— ...pero ¿ lo necesitan ? Es otra pregunta que hago, y de nuevo, no te preocupes por el rendimiento . Estamos hablando de un cambio de permisos bastante grande para dar cabida a un total de 3 bots activos. Y, recuerda, tenemos un servidor de herramientas por esta razón exacta: para que los bots puedan ejecutarse en él y no consumir un exceso de ancho de banda/accesos SQL. Además, los bots basados ​​en heurísticas cometen errores, y la reversión les permitiría cometer errores mucho más rápido. Además, no estoy seguro de si me siento cómodo dándole a cada bot en el grupo de bots la capacidad de revertir, particularmente considerando que sus ediciones están ocultas por defecto tanto de los feeds de RC como de vandalismo en primer lugar. Presenta una razón sólida de por qué existe una necesidad para ello y lo reconsideraré. -- slakr \  talk  / 03:57, 7 de enero de 2008 (UTC) [ responder ]
    ¿Quieres una razón sólida para usar la función rollback? WP:PERFORMANCE está pensado para el usuario medio. Los operadores de bots tienen que ser mucho más cuidadosos y elegir cuándo ejecutar el bot, para no afectar tanto a los servidores. Antes de perfeccionar algunos de mis métodos actuales, causé algunos bloqueos de la base de datos porque estaba ejecutando mi bot demasiado rápido y causando demasiado estrés en los servidores. Brion y los otros desarrolladores son buenos, pero como operadores de bots nos damos cuenta de que tenemos problemas adicionales de los que los usuarios normales no tienen que preocuparse. Además, como operadores de bots, es nuestro trabajo descubrir los mejores métodos y menos intensivos que podamos. La función rollback reducirá la cantidad de estrés causado por los AVB en un 66 %. Desde casi cualquier perspectiva, una mejora del rendimiento del 66 % es algo bueno. Como nota adicional, el servidor de herramientas es inútil para luchar contra los vándalos, y los usuarios no tienen acceso a la base de datos, solo a un espejo en vivo de esta que no contiene texto de página. Comando β 04:34 7 enero 2008 (UTC) [ responder ]
    Los AVB de PS no están marcados y, por lo tanto, sus ediciones aparecen en el feed RC y en los cambios recientes. β command 04:40, 7 enero 2008 (UTC) [ responder ]
    Hay una diferencia fundamental entre tu bot y los bots antivandálicos en la carga de su servidor. La causa del bloqueo de tu base de datos probablemente se debió a demasiadas ediciones a la vez, lo que causa un retraso en la replicación. Por lo tanto, según esa lógica, dar a los bots una reversión en realidad aumentaría el retraso en la replicación, ya que pueden realizar actualizaciones e inserciones mucho más rápido. En segundo lugar, me gustaría ver de dónde proviene la ganancia de rendimiento del 66%, ¿o es un número arbitrario? Finalmente, independientemente de la disponibilidad de contenido, el servidor de herramientas aún está ubicado en la intranet de Wikimedia, por lo que aún reduce el consumo de ancho de banda externo. Esto último debería ser el primer curso de acción a intentar para un bot como ClueBot (antes de algo tan drástico como darle a él y a otros bots una reversión). -- slakr \  talk  / 05:11, 7 enero 2008 (UTC) [ responder ]
    ¿De dónde saqué el 66%? diff GET() 30Kb, versión anterior GET() 30Kb, POST() del texto revertido 30Kb, transferencia total de servidor/bot 90Kb. con reversión: diff GET() 30Kb, enviar token de reversión 1KB. transferencia total de datos de servidor/bot 31KB. eso es 59KB menos o 65,555555% de mejora. En cuanto a tu idea de que el servidor de herramientas y el ancho de banda son una tontería. (Tengo una cuenta de servidor de herramientas), los servidores reales del TS están en Ámsterdam y los servidores de Wikimedia están en Tampa Bay, Florida. El servidor de herramientas es realmente útil para todo lo que hace es como servidor estable y seguro. y para ejecutar consultas básicas en la base de datos. ¿En cuanto al riesgo de que con la reversión los bots sean más dañinos? Tonterías. La reversión y la codificación adecuada de los bots lo evitan. La reversión es como dije, al menos un 66% más (para una reversión de una sola edición), y para una reversión de varias ediciones es incluso mejor en los servidores. Por favor, deja de hablar de cosas de las que no tienes ni la menor idea. Solo te hace quedar mal. β command 12:52, 7 enero 2008 (UTC) [ responder ]

    Cobi: La idea de que la reversión requiere más recursos que la reversión manual es una locura — amidanial, IRC

    Cobi: Me suena bastante tonto — brion, IRC

    Doy por terminado mi caso. -- Cobi ( t | c | b ) 05:26, 7 enero 2008 (UTC) [ responder ]
    Espera, esto se está saliendo de control. Cobi, ¿estás copiando de los chats de IRC a Wikipedia? No estoy de acuerdo con nada de lo que ha dicho slakr, pero puede que no sea la mejor estrategia. Ahora estás entrando en un terreno totalmente diferente, es mucho mejor dejar que esa gente comente directamente. Franamax ( discusión ) 05:52 7 ene 2008 (UTC) [ responder ]
    En realidad, preferiría mucho más la opinión de Brion y otros sobre el tema. Por supuesto, el problema es que nunca he defendido un punto tan simple como "la reversión requiere más recursos que la reversión manual", por lo que, aunque es posible que hayan dicho eso, es posible que lo hayan sacado de contexto; porque mi punto no era que la reversión requiere más recursos, sino que los bots que tienen reversión posiblemente requieran más recursos según la lógica de betacommand. Preferiría que simplemente los vincularas a mis comentarios y luego continuaríamos desde allí en lugar de jugar al mensajero; o, alternativamente, que simplemente publiquen sus comentarios aquí personalmente. -- slakr \  talk  / 06:21, 7 de enero de 2008 (UTC) [ responder ]
    Slakr, este es un consejo gratuito, por lo que vale lo que pagaste por él, pero te sugiero que lo dejes de lado: la reversión manual es menos intensiva que la reversión automática; en mi opinión, vas a perder esa a lo grande :) Dejemos de citar de IRC, si quieren comentar aquí, lo harán, si quieres contactarlos para una discusión directa, estoy seguro de que también puedes hacerlo. Franamax ( discusión ) 06:33, 7 de enero de 2008 (UTC) [ responder ]
    En realidad, la razón principal por la que comenté de nuevo es que mi punto fue sacado de contexto, tal como lo has hecho ahora accidentalmente. :P Mi punto original era una respuesta simple a la afirmación de Betacommand de que el uso de recursos de Bot X refleja el uso de recursos de Bot Y, lo que no es necesariamente el caso. Sé que la reversión es el 99,9% del tiempo más amigable con los recursos que la reversión manual; sin embargo, en la situación que indicó, podría constituir el 0,1% por ciento, es decir, la excepción a la regla , porque en el único caso de bloqueos de base de datos debido al retraso de replicación, en teoría más reversiones por scripts automatizados (es decir, bots) podrían exacerbar el problema debido a la naturaleza de muchas ACTUALIZACIONES e INSERCIONES a la vez, lo que es más un cuello de botella debido a la velocidad a la que se pueden ejecutar en un período de tiempo finito. Sin embargo, aprecio tu consejo. -- slakr \  talk  / 06:49, 7 enero 2008 (UTC) [ responder ]
    No importa de cuántas maneras lo expliques, 854 administradores que usan la función de reversión van a causar considerablemente más estrés (y potencial de retraso en la replicación) que 3 bots. Ciertamente, si la propuesta anterior se lleva a cabo, incluso suponiendo que el 20% de todos los editores usen la función de reversión, las posibilidades son casi infinitas en lo que respecta a la carga de la base de datos. Dicho esto, haces demasiadas suposiciones, pero la más notable es fundamental (pero falta): simplemente porque los bots tendrán la herramienta de reversión, esto resultará en un aumento en las consultas de mutadores contra los servidores. Consultas más eficientes (en tiempo y carga) no se traducen necesariamente en más consultas (en cantidad). Creo que tu afirmación original es errónea por una variedad de razones, pero esta parece ser la más relevante. Justin chat 04:10, 8 de enero de 2008 (UTC) [ responder ]
  3. Estoy en contra. Estoy de acuerdo con la afirmación nº 1, arriba. Los bots no son tan buenos como se podría pensar. A veces pueden ser molestos. Y algunas veces... Cluebot ha borrado lo anterior. Si esto es erróneo, por favor, infórmelo al Comité de Adoctrinamiento para que podamos borrarlo a usted también.  :-) Sólo bromeaba. Bromas aparte, me opongo a esta idea. Gracias. -- Steve, Sm8900 ( discusión ) 04:00, 7 enero 2008 (UTC) [ responder ]
    1. ¿ Qué sentido tiene eso? Si los bots no tienen la función de revertir, simplemente utilizarán más recursos y no dejarán de funcionar. BJ Talk 04:44, 7 de enero de 2008 (UTC) [ responder ]
    (ec) Te das cuenta de que, independientemente de si se da la reversión a los bots , estos funcionarán exactamente de la misma manera a velocidades cercanas a las mismas. La reversión solo aliviará un poco el estrés de los bots y los servidores. En este momento, cuando ClueBot decide revertir, toma el historial meta de la página, encuentra la última edición de un usuario distinto del usuario al que está revirtiendo, solicita los datos de esa entrada, solicita el formulario de edición y publica esos datos de nuevo en el servidor. Esto es exactamente lo mismo que hace la reversión, excepto que la reversión se realiza completamente en el servidor sin la negociación de 4 vías, por lo que requiere muchos menos recursos en ambos extremos. ClueBot también revertirá en paralelo si es necesario, por lo que el argumento de que "pero lo ralentiza" no es válido, ClueBot revertirá 10 ediciones de vandalismo en el mismo tiempo que revierte 1, solo estamos hablando de acelerar esa 1 y hacerlo más fácil para los servidores. - Cobi ( t | c | b ) 04:51, 7 de enero de 2008 (UTC) [ respuesta ]
  4. ¡¡¡NO HAY QUE OPONERSE!!! ¡ ¡¡NO!!! La intolerancia automatizada NUNCA debería convertirse en una característica de Wikipedia. Smith Jones ( discusión ) 00:18 8 ene 2008 (UTC) [ responder ]
    • ¿Te das cuenta de que no se trata de si debería haber o no bots en Wikipedia? Se trata simplemente de si se les debería permitir tener una versión más eficiente de una herramienta que ya tienen y usan a diario. -- Nn123645 ( discusión ) 06:48 8 ene 2008 (UTC) [ responder ]
  5. No, no , no. Por las mismas razones que se enumeran en la convocatoria de propuestas para los bots y en la reciente discusión en el VP. (No lo voy a desenterrar de los archivos, si no lo has leído, ve a buscarlo) No, no, no. ¿Cómo diablos pasó esto de ser una "encuesta" para conceder a los usuarios de confianza la reversión a incluir a los bots antivandálicos en esto? (No respondas que es retórico; el punto es que ¿no nos estamos diversificando un poco?) Knowledge Of Self | talk 11:34, 8 de enero de 2008 (UTC) [ responder ]
  6. Oponerse por KOS. m ir y a 00:42 , 9 enero 2008 (UTC) [ responder ]

Neutral (bots)

  1. Este tiene sus ventajas y desventajas. En primer lugar, todas mis objeciones con respecto al proceso de verificación y la inevitabilidad (¿existe esa palabra?) de que un usuario verificado cometa actos vandálicos se van por la ventana cuando hablamos de bots. Eso es algo bueno. Pero, por otro lado, el hecho de que los bots sean creados por los usuarios los hace susceptibles a los sesgos de los usuarios. Sin embargo, eso no es realmente un gran problema: se supone que los creadores de bots han invertido lo suficiente en sus bots y en Wikipedia como para no abusar de sus creaciones basándose en sus sesgos personales. Lo que realmente me preocupa es la posibilidad de una reversión masiva y automática por parte de los bots . Todos sabemos que los bots no son perfectos (molestos, a veces), y debido a esto, a veces (raramente, pero a veces) los bots cometen errores o identifican erróneamente una edición legítima o lo que sea como algo inapropiado. Aunque esto es poco probable, un error en el bot o una falla en su diseño podría hacer que identifique una gran cantidad de ediciones incorrectamente (ya sea vandalismo como válido o ediciones legítimas como vandalismo) y revierta automáticamente una gran cantidad de ediciones (incluidas aquellas que intentaban corregir el vandalismo clasificado incorrectamente), a un ritmo mucho más rápido y con mucho más alcance que cualquier editor humano o vándalo . Esta es mi única objeción: se eliminaría (y luego lo aprobaría) si se probara que los bots no son susceptibles a este tipo de errores. Ecthelion83 ( discusión ) 06:24, 7 de enero de 2008 (UTC) [ responder ]
    ¿Leíste mi respuesta a la pregunta n.° 3 que se encuentra justo encima de tu comentario? Específicamente, sobre hacer cosas en paralelo. -- Cobi ( t | c | b ) 06:46, 7 de enero de 2008 (UTC) [ responder ]
    Sí, lo hice. No creo haber dicho nada sobre una reducción en la velocidad de las ediciones . Lo que dijiste sobre los bots fue que un bot podría hacer todas estas ediciones/reversiones en tándem o simultáneamente, que es lo que estoy asumiendo ; tu comentario al que haces referencia no aborda la objeción que me impide apoyar esta idea. Lo que estás diciendo esencialmente en ese comentario es que los bots revierten 1 edición en el mismo tiempo que les toma revertir 10 de ellas, y que esto también se aplica a la reversión. Esta no es mi preocupación . Mi preocupación aquí no es que el bot tenga problemas para alcanzar a los vándalos (porque no tendrían ningún problema en hacerlo), sino la posibilidad de que los propios bots puedan clasificar incorrectamente la información y, por lo tanto, revertir muchas ediciones legítimas a un ritmo mucho más rápido del que podría corregirse humanamente , o podrían revertir ediciones al vandalismo que los bots identificaron (incorrectamente) como legítimas. Ecthelion83 ( discusión ) 07:37 7 ene 2008 (UTC) [ responder ]
    La tasa de error no cambiaría con respecto a la actual. El único cambio de programación será utilizar la función de reversión en lugar del método actual. Sr. Z- man 08:23, 7 enero 2008 (UTC) [ responder ]
    Cierto, pero aún hay una tasa de error . Poder usar la función de reversión, especialmente cuando un bot comete un error (sé que no es frecuente) o una serie de errores relacionados, sigue siendo una reserva que yo y otros seguiremos teniendo. Ecthelion83 ( discusión ) 08:51 7 ene 2008 (UTC) [ responder ]
    Entonces, ¿un bot debería verse obligado a utilizar un método más lento y menos eficiente porque no es completamente preciso? ¿Qué sucedería si le dijera que la reversión reduciría los errores aleatorios? Hay una ventana de una fracción de segundo después de que ClueBot obtiene el texto de la revisión anterior y antes de que ClueBot obtenga el formulario de edición. Esta ventana existe porque se trata de dos interacciones diferentes. La reversión eliminaría esta ventana ya que es una transacción y puede crear un bloqueo de escritura en la base de datos durante los milisegundos necesarios para completar la transacción (este es el bloqueo estándar en cualquier operación de escritura en una base de datos, no el mensaje de error de MediaWiki que dice que la base de datos está bloqueada). -- Cobi ( t | c | b ) 09:18, 7 de enero de 2008 (UTC) [ responder ]
    ¿Podrías aclararme si ClueBot analiza actualmente el cambio más reciente, decide que es vandalismo y luego revierte a ciegas todos los cambios inmediatamente anteriores realizados por el mismo editor? ¿O analiza cada cambio realizado por ese editor y decide si cada uno de ellos es vandalismo? Estoy intentando averiguarlo... Franamax ( discusión ) 10:06 7 ene 2008 (UTC) [ responder ]
    Lo hace. Como cualquier otro script de reversión. Esto se hace para no encerrar vandalismo sutil. Esto sucede muy frecuentemente : Vandal edita una página, cambia un número o inserta vandalismo muy sutil que el bot no detecta. Luego, Vandal edita la página nuevamente y hace algo muy radical, y ClueBot revierte en cuestión de segundos. Si ClueBot revirtiera una edición, entonces alguien diría "Oh, ClueBot ya lo revirtió", y no lo miraría, asumiendo que está libre de vandalismo. -- Cobi ( t | c | b ) 10:17, 7 de enero de 2008 (UTC) [ responder ]
    Gracias, eso tiene mucho sentido cuando veo un rvv. Supongo que el reversor lo ha comprobado correctamente, aunque si veo "ediciones revertidas por 1.2.3.4 a la versión anterior por 1.2.3.4" casi siempre voy a mirar de todos modos. Por supuesto, si estuviera tratando de hacer vandalismo, haría el cambio grande primero, luego el segundo cambio más pequeño después. En realidad, haría el cambio grande en la primera edición más abajo en el artículo con un cambio más pequeño arriba donde el revisor que mira hacia atrás solo estaría mirando la primera pantalla del navegador, guardaría ese desastre, luego haría un segundo cambio inocuo y guardaría esa versión también. Entonces, en la situación inversa al escenario que describiste anteriormente, ¿ClueBot detectaría mi primer cambio incorrecto? Franamax ( discusión ) 10:30, 7 de enero de 2008 (UTC) [ responder ]
  2. Se trata de una medida técnica que debería decidirse sobre bases técnicas. No veo ninguna razón por la que la comunidad deba participar en ella. -- Carnildo ( discusión ) 09:32 7 ene 2008 (UTC) [ responder ]
  3. Neutral respecto a Carnildo. Dado que esto no agregaría más funcionalidad a los bots, sino que simplemente quitaría algo de carga a los servidores (¿o podría hacerlo ?), lo dejaría en manos del grupo técnico. Artyom  ( discusión  •  contribuciones ) 14:26, 7 de enero de 2008 (UTC) [ responder ]
Neutral ; me inclino fuertemente a oponerme . Lo reconsideraría si fuera posible proporcionar un resumen de edición no estándar (el bot no debería decir simplemente "No me gustan tus ediciones feas"), codificado en URL o publicado en la solicitud. Pero no lo es. Miércoles 13 22:39, 7 de enero de 2008 (UTC) [ responder ]
  1. El resumen de reversión predeterminado puede modificarse caso por caso. Si alguien toma la URL de reversión y añade &summary= seguido del resumen de edición, se utiliza ese en lugar del resumen de edición de reversión predeterminado. Y, por supuesto, ClueBot aprovechará al máximo esta capacidad, como ya he indicado en esta sección. Gracias. -- Cobi ( t | c | b ) 23:32, 7 de enero de 2008 (UTC) [ responder ]
    Es bueno saberlo, es una característica poco conocida. Se está cambiando para que sea compatible. Miércoles 13 11:26, 8 enero 2008 (UTC) [ responder ]
En caso de que esta horrible idea se lleve a cabo, ¿quién está a cargo de ClueBot y será responsable de cualquier error o falla accidental que PUEDA ocurrir después de que los bots sean potenciados radicalmente? ¡¡¡Sólo pido referencias futuras!!! Smith Jones ( discusión ) 03:33 8 ene 2008 (UTC) [ responder ]
Cobi está a cargo de ClueBot. Pero estos robots ya están en funcionamiento, Wikipedia no ha implosionado y no se han vuelto inteligentes ni han impulsado un punto de vista. Esto solo está cambiando el método técnico utilizado para revertir el vandalismo, no las razones por las que lo revierte. Mr. Z- man 03:50, 8 enero 2008 (UTC) [ responder ]
Gracias por aclararme eso. Es sorprendente que me respondan en lugar de tener que leer mil páginas de texto. Smith Jones ( discusión ) 03:54 8 ene 2008 (UTC) [ responder ]

Discusión (bots)

Preocupaciones de seguridad

La otra cosa realmente importante que olvidé mencionar: si los bots tienen rollback, corren un riesgo potencialmente mayor de ser el objetivo de los "hax0rs" debido al poder literalmente asombroso del rollback masivo. Es probable que la mayoría de las contraseñas de los bots se almacenen en texto sin formato, potencialmente legible para todo el mundo, y en un servidor compartido. Es solo cuestión de tiempo antes de que alguien aproveche eso, especialmente si a los bots se les dan capacidades de edición mejoradas como rollback. Quizás estoy siendo demasiado paranoico con esto, pero lo que sea. :P -- slakr \  talk  / 09:29, 7 de enero de 2008 (UTC) [ responder ]

cobi@Abscisa:~/wikibots$ ls -aslh Cluebot/cluebot.config.php4.0K -rw------- 1 cobi g-users 1.1K 2007-11-18 16:42 cluebot/cluebot.config.php
Además, la contraseña es una cadena alfanumérica completamente aleatoria. Está en un servidor relativamente privado. Es decir, soy el propietario del servidor y algunos de mis amigos tienen una cuenta. La contraseña se almacena en texto sin formato en el disco, pero no hay una forma efectiva de evitarlo. No se puede codificar porque entonces ClueBot no podría enviarla a Wikipedia. Cifrarla con un cifrado de clave simétrica o pública/privada sería de poca utilidad porque ClueBot todavía tiene que tener una forma de decodificarla para enviarla a Wikipedia. Además, la reversión no es un "poder literalmente asombroso de reversión masiva". Ese es el fallo del resto de esta página. La reversión es simplemente una forma más rápida y mejor de revertir un artículo con menos posibilidades de error. ¿Qué pasa con SineBot? ¿Está en un servidor compartido? ¿Y no fuiste tú quien sugirió que lo pusiera en el servidor de herramientas altamente compartido? ;) - Cobi ( t | c | b ) 09:53, 7 de enero de 2008 (UTC) [ respuesta ]
Tenemos un grupo de aprobación de bots por una razón, y esa razón es que la mayoría de la gente no entiende a los bots. Preguntar si se debe dar la reversión a los bots aquí no es productivo y conduce a preocupaciones sobre Skynet o el hombre del cortacésped, y otras preocupaciones que no se basan en la realidad de lo que son realmente los bots. El hecho es que cualquiera que entienda cómo los bots realmente editan Wikipedia sabrá que la única diferencia que hace la reversión para un bot es una reducción de la carga del servidor. Ni siquiera es para los bots sino para el servidor, ya que el bot puede hacer lo mismo sin ningún esfuerzo adicional sin la herramienta, simplemente utilizando más recursos del servidor. Consultar a personas no calificadas sobre el tema no conducirá a los resultados más precisos. 1 != 2 16:54, 7 de enero de 2008 (UTC) [ responder ]
Esto se está volviendo una tontería. Estoy dispuesto a apostar una moneda brillante a que los tres AVB actuales se ejecutan en sistemas considerablemente más seguros que la abrumadora mayoría de cuentas de administrador, que tienen poderes realmente asombrosos de eliminación, bloqueo, etc. Simplemente no entiendo por qué haces tantas suposiciones de seguridad sobre los bots, cuando siendo realistas, los humanos tienden a causar más problemas de seguridad que cualquier proceso automatizado que haya visto. Afirmar que las contraseñas son "potencialmente legibles para todo el mundo" o que los servidores compartidos son inherentemente menos seguros que, digamos, una cuenta de administrador raya en lo insultante para cualquier escritor de bots. Si la seguridad es realmente una preocupación tan grande, trátala con los desarrolladores, ya que las contraseñas se envían en texto plano a WP de todos modos. Estoy con 1 != 2 en este caso. BAG debería encargarse de esto o vamos a escuchar un argumento ad metum tras otro. Justin chat 05:53, 8 de enero de 2008 (UTC) [ responder ]
En lugar de descartar las preocupaciones como una tontería alarmista y hablar de gente que simplemente no entiende, podría ser una mejor estrategia tratar con paciencia y cortesía los problemas planteados, sin importar lo triviales y repetitivos que sean. Nunca se sabe cuándo puede ser una persona de TI de primera línea la que haga las preguntas tontas tratando de entender la situación; descartar las cosas que te hacen impaciente puede alejar a las personas que podrían resultar tus mejores partidarios y ciertamente no calmará a las personas con el ceño fruncido de verdad. Una de las principales preocupaciones que he visto en WP con los bots y los defensores de los bots es su nivel de habilidades de comunicación. ¿Podrías reformular esa publicación para plantear el mismo punto válido de una manera menos despectiva? Después de todo, todos estamos persiguiendo el mismo objetivo: una mejor enciclopedia. Franamax ( discusión ) 07:31, 8 de enero de 2008 (UTC) [ responder ]
Las preocupaciones de seguridad que se plantean provienen de la paranoia. No puedo hablar por CVB , VoABot II o MartinBot , pero sí por ClueBot . ClueBot se ejecuta en los servidores de ClueNet, específicamente, Abscissa.ClueNet.Org, un servidor que dirijo yo. Los dos administradores principales de ClueNet son lo que algunos llamarían "fanáticos de la seguridad". ClueBot nunca se ha visto comprometido a pesar de tener el código fuente disponible públicamente. El archivo de configuración privado de ClueBot (que contiene las contraseñas) solo lo puedo leer yo. Abscissa.ClueNet.Org no es un servidor muy público. Solo las personas que han sido verificadas y aprobadas por uno de los dos administradores principales de ClueNet tienen cuentas. La contraseña de ClueBot es muy larga y está compuesta de caracteres completamente aleatorios (imprimibles). En cuanto al argumento de que "la reversión es un poder asombroso"... bueno... no lo es. No puede hacer nada que la edición normal pueda hacer. Es más fácil tanto para el bot como para los servidores WMF. Cualquier usuario con privilegios de edición (es decir, cualquiera que no esté bloqueado) puede revertirlo. Estoy de acuerdo con algunos de los otros en que esto debería ser manejado por el BAG , pero los desarrolladores querían el consenso de la comunidad, así que aquí está. No tengo dudas de que el BAG no tendría ningún problema con esta solicitud. Pero los desarrolladores querían el consenso de la comunidad. Espero haber aliviado sus preocupaciones. Gracias. -- Cobi ( t | c | b ) 08:03, 8 de enero de 2008 (UTC) [ responder ]
ClueBot se ejecuta en los servidores de ClueNet, específicamente, Abscissa.ClueNet.Org . Ahora, vean, de ahí viene mi paranoia: la gente literalmente pide ser hackeada/dDOSe publicando descuidadamente información de IP de servidores públicos. Para que conste, en realidad soy un adicto a *nix/bsd/solaris y un autoproclamado nerd de la codificación, así que estoy bastante seguro de que sé de lo que estoy hablando cuando se trata de cosas como esta. No soy miembro de BAG (ni necesito serlo) para entender que hay problemas fundamentales de seguridad cuando se trata de bots que se ejecutan en uno de los sitios más visibles y con mayor tráfico en Internet. Esto debería ser una discusión racional sobre los pros y contras de darles a los bots una habilidad poderosa, no un foro para llamar paranoicos a las personas simplemente porque plantean opiniones disidentes; Y les aseguro que la seguridad no es algo que deba tomarse con presunción, confianza excesiva, condescendencia o desdén, independientemente del tamaño de un sitio o una empresa.
Dicho esto, una comprobación de la realidad: ¿es probable que los bots sean hackeados? Probablemente no, al menos, mientras la gente no vaya por ahí publicando sus direcciones IP públicas. ¿Qué pasa si son hackeados? Es un fastidio debido a la naturaleza no limitada de la reversión tal como está implementada actualmente en Mediawiki. Y sería ideal que la gente dejara de lado el hábito de llamar alarmismo a la paranoia bien intencionada y bien fundada. Si prefieres que yo y otros no intentemos frenar el pensamiento colectivo cuando se trata de decisiones que potencialmente afectan a la seguridad de la comunidad, entonces estaré encantado de complacerte, ya que siempre hay un considerable retraso en otras cosas, tanto aquí como en la vida real, que estaré encantado de hacer en su lugar. -- slakr \  talk  / 09:24, 8 de enero de 2008 (UTC) [ responder ]
Exactamente lo que quiero decir, en el primer párrafo lo hiciste parecer inevitable. Ahora es "probablemente no probable". Y la razón por la que me puse un poco quisquilloso fue porque la página de usuario de Slackr indica que tiene conocimiento más que suficiente sobre las complejidades de la programación como para no hacer afirmaciones descabelladas sobre el "inevitable" bot hackeado. Y la paranoia puede tener buenas intenciones, pero inventar escenarios absolutamente desastrosos e insinuar que son inevitables no está bien fundamentado. Eso cae dentro de la jurisdicción de la excesiva. Y solo lo empeoras al insinuar que dar información de servidores públicos es algo terrible. Entonces, hagamos algunos contrapuntos a tu argumento:
(A) Una dirección IP no es "privada" en ningún sentido. Personalmente, no daría una dirección IP a menos que hubiera una buena razón para hacerlo, pero eso en sí mismo no es ni remotamente un "problema de seguridad".
(B) Si se produjera un ataque DDoS, no haría más que ralentizar (o potencialmente hacer que ClueBot detuviera) la edición. Usar eso como un "problema de seguridad" en relación con Wikipedia es absolutamente absurdo.
La opinión disidente es algo "bueno". Por eso, a quienes se han opuesto por diversas razones ni siquiera se les ha pedido que respondan por su oposición. La falta de comprensión del concepto de bots es algo esperable y natural. La gente teme a los procesos que se ejecutan "automáticamente". Dicho esto, alguien que afirma que es, como mínimo, competente (si no un profesional) no va a recibir la misma consideración. Si quieres defender cuestiones de seguridad, eso es GENIAL... serás mi nuevo mejor amigo. Pero defenderlas mediante tácticas de miedo y el uso de palabras que realmente no se aplican (léase DDoS) va a PERJUDICAR el proceso más que ayudarlo. Justin chat 17:01, 8 enero 2008 (UTC) [ responder ]
Cobi, en el proceso de defender la seguridad de tu bot, ya has revelado al menos tres rutas de ataque además de tu vulnerabilidad a la ingeniería social. Prueba la seguridad del archivo específico que has enumerado anteriormente mostrándonos el contenido de /etc/passwd y ls -al ~/wikibots - o mejor aún, ¿puedes iniciar sesión y ejecutar rápidamente "rm -r ../*" y publicar el resultado? El problema de alardear de tu seguridad es que es como buscar pelea en un bar: tarde o temprano habrá un tipo más grande y más duro. Y estás hablando por tu bot, pero también estás mencionando los nombres de tus amigos, los otros bots antivandálicos que beben tranquilamente una cerveza en su mesa. Me referiré a mi publicación anterior: es mucho mejor explicarnos pacientemente a los idiotas por qué estamos equivocados, no tienes que decirnos que somos idiotas, ya sabemos que lo somos, es por eso que ganamos tanto dinero, porque preguntamos sobre todo. Tranquilízate y llegarás más lejos. :) Franamax ( discusión ) 13:12 8 ene 2008 (UTC) [ responder ]
La principal preocupación aquí parece ser la privacidad de la contraseña de texto simple almacenada en el archivo. Debido a que el archivo no es legible para todo el mundo, solo hay 3 categorías de ataque posibles. Una cuenta root pirateada en el servidor, esa cuenta de usuario pirateada en particular en el servidor e ingeniería social para obtener directamente la contraseña por otros medios. El sistema en cuestión ejecuta Debian estable y se actualiza regularmente. Esto minimiza en gran medida cualquier posibilidad de que la cuenta root o la cuenta de usuario sean "pirateadas". En este caso, solo una persona (Cobi) tendrá acceso a la contraseña, y nunca se la daría a nadie, ya que sabe lo suficiente como para no ser susceptible a la ingeniería social. En respuesta a su pregunta sobre la inclusión de /etc/passwd en la lista, eso no sería de ninguna ayuda, ya que está asumiendo que el PAM del sistema está utilizando una configuración predeterminada, lo cual no es así. En realidad, la autenticación de la cuenta se realiza a través de Kerberos5 (Heimdal). La información de la cuenta (con NSS) se almacena en un directorio LDAP y la configuración de PAM no permite la autenticación Kerberos (o autorización LDAP) para los UID del sistema. No estoy seguro de qué se supone que prueba tu pregunta sobre "rm -rf", o cuál es el cwd en el que quieres que se ejecute. Si se ejecuta desde el directorio de inicio, eliminará sólo el directorio de inicio de ese usuario y no se publicará ninguna información privilegiada. Si la preocupación es sobre las contraseñas de administrador no cifradas en general, probablemente haya preocupaciones más grandes en la misma línea. ¿Cuántos administradores tienen navegadores que almacenan contraseñas no cifradas para que se completen automáticamente? Seguro, algunos probablemente usan algún tipo de llavero protegido con contraseña, pero muchos sistemas no lo usan. ¿Qué pasa si una de sus máquinas es "hackeada"? —Comentario anterior sin firmar agregado por Crispy1989 ( discusión • contribs ) 01:07 , 9 de enero de 2008 (UTC) [ responder ]
- contraseña de texto sin formato: ¿por qué no está cifrada y desbloqueada cuando se inicia el bot?
- no legible por todo el mundo - depende de los permisos del directorio principal, que está a un chmod de distancia.
- El sistema ejecuta Debian. Gracias por el sistema operativo exacto. Te han engañado. ¿Cómo sé que es la versión actual? ¡Espera, no me digas el número de versión!
- /etc/passwd - para buscar otros unames con el mismo uid.
- método de autenticación - nuevamente, gracias por la descripción detallada publicada en línea.
- "arr-emm-espacio-menos-arr/espacio-punto-punto-barra-estrella" - es un chiste que rima, tal vez solo los que trabajan en el soporte técnico lo entiendan, me retractaré ahora. :)
- Sí, los administradores de todo el mundo tienen cookies y todo tipo de software espía del último sitio extraño en el que hicieron clic, esa es otra gran vulnerabilidad social que nunca desaparecerá.
- Podríamos seguir con esto, mi punto original antes era que NO deberíamos discutir sobre seguridad mediante la exposición de los puntos finos del sexto sitio web más popular del mundo. Y te aseguro que no seré yo quien demuestre el punto sobre las vulnerabilidades, sólo me preocupan otras personas interesadas que están mirando. No me disgustaría que detuviéramos la discusión técnica ahora :) Franamax ( discusión ) 08:16 9 ene 2008 (UTC) [ responder ]
Las cuentas de administrador han sido hackeadas en el pasado. Se descontrolan durante unos minutos, se les da un bloqueo de emergencia y todo vuelve a la normalidad en una hora. Un bot hackeado haría aún menos porque sólo sería necesario bloquearlo para detenerlo, no necesitaríamos contratar a un administrador. Mr. Z- man 03:12, 9 de enero de 2008 (UTC) [ responder ]
La preocupación aquí no es la misma que con las cuentas de administrador. Una cuenta de bot tiene esa bandera +bot, por lo tanto, pasa un poco más desapercibida. Se espera que una cuenta de bot haga ediciones de alta tasa, cuando ustedes que están mirando la actividad ven la bandera de bot, se relajan un poco, ¿estoy en lo cierto? Eso es lo que deduje de mis discusiones anteriores en T_RFBA de todos modos. Entonces, aquí hay dos escenarios: un inicio de sesión de bot es secuestrado y se vuelve loco con una ola de reversiones, bueno, está bien, se detectará un poco más tarde de lo habitual para las cuentas pirateadas y se puede revertir, pero vaya, mientras tanto hay unos pocos miles de personas más que intentan reparar el daño ellos mismos y unos pocos miles de personas más que solo intentan agregar cosas, y todos se están confundiendo porque naturalmente respetan "Bot" al final del nombre de usuario; y luego está la posibilidad mucho peor de una contraseña de bot comprometida en manos de un piloto experto, ahora es un bombardero furtivo. A propósito, no pregunté anteriormente con qué frecuencia se cambia la contraseña. SÍ, esto es una tontería apocalíptica... hasta que se convierte en realidad. Y sí, dado que al menos ClueBot ya hace lo mismo con estas vulnerabilidades existentes, esta propuesta de reversión no es directamente relevante. Ayer estuve dispuesto a cambiar mi !oppose por !support, pero no vi el tipo de respuestas pacientes y tranquilas por parte del bot que hubiera esperado. Por supuesto, no cuento para nada en el gran esquema :) ¡Saludos! :) Franamax ( discusión ) 08:38, 9 de enero de 2008 (UTC) [ responder ]
No creo que los bots anti-vandalismo estén marcados, por lo que sus ediciones aparecerán en cambios recientes y listas de seguimiento. Además, cuando alguien nota que un bot actúa de manera extraña (si ClueBot hizo algo más que revertir un vandalismo flagrante o algo que se le parezca), se lo bloquea mucho más rápido que a los usuarios porque se minimiza la posibilidad de ofender al usuario bloqueado en caso de un bloqueo innecesario. Mr. Z- man 20:47, 9 de enero de 2008 (UTC) [ responder ]
Veo la relevancia de que el procedimiento de reversión tenga un proceso de aprobación independiente para los bots y para los usuarios, ya que si uno no es aprobado, el otro podría serlo. Pero, ¿todo este discurso sobre bots que son hackeados o que se vuelven locos? No es como si alguien tuviera un control remoto mágico que pueda hacer que todos los bots rompan Wikipedia. Conceder esta característica a los bots no los hace efectivamente más "poderosos" o propensos a fallar. Cualquier discusión adicional de esa naturaleza debe realizarse en otro lugar; distrae del tema relevante. Coreycubed ( discusión ) 16:56, 8 de enero de 2008 (UTC) [ responder ]
Ummm... parecería que la reversión de bots se solicita aquí como una parte relacionada, pero separada, de la función de reversión de no administradores para editores seleccionados, precisamente porque los intentos anteriores de obtener esa capacidad a través de RFA han fallado. También parecería justo que se presenten las mismas preocupaciones aquí: los bots obtienen un pase especial para hacer cosas y tienen un cierto imprimatur cuando los vemos hacer ediciones, así que sí, deberían recibir un escrutinio adicional. El argumento para otorgar la reversión a los bots se basa en una mayor eficiencia, ya sea 66% o 10:1 según mi lectura. Dos formas de verlo: se nos pide que otorguemos un derecho para ahorrar entre un 33 y un 90% de... ¿qué? No se ha presentado ningún caso sobre cuántos servidores menos necesitará WMF; y ahora existe un argumento concebible de que la mayor eficiencia permitirá que el bot trabaje entre tres y diez veces más rápido, entonces, ¿no está aumentando también el potencial de daño al mismo ritmo? De todos modos, la discusión sobre los bots está en su propio rincón y la seguridad está aún más alejada, dudo que estemos distrayendo a alguien más que a nosotros mismos :) Franamax ( discusión ) 09:06, 9 de enero de 2008 (UTC) [ responder ]
El número de páginas que se "dañarán" será mayor (simplemente se realiza una reversión, por lo que la página siempre se editará a alguna versión de su historial reciente), pero la tasa de error debería permanecer igual y es menor que la tasa de error de la mayoría de los usuarios que realizan la misma tarea. Mr. Z- man 20:47, 9 de enero de 2008 (UTC) [ responder ]

Pregunta de administrador, movida

¿Por qué son los administradores los encargados de conceder los derechos? —Comentario anterior sin firmar añadido por Hiding ( discusión • contribs ) 00:31, 9 de enero de 2008 (UTC)[ responder ]
Porque son administradores . Snowfire51 ( discusión ) 00:45 9 ene 2008 (UTC) [ responder ]
Qué redundante. Al menos tenemos una respuesta que podemos añadir a las preguntas frecuentes. Hiding T 02:15, 9 enero 2008 (UTC) [ responder ]
Los administradores tienen (o habrían tenido) la responsabilidad de otorgar derechos de reversión porque han demostrado que se puede confiar en ellos durante su tiempo aquí , y también han recibido la capacidad de proteger y eliminar páginas, bloquear editores y revertir sus ediciones. No son, como comúnmente se percibe, un grupo de editores arrogantes y egoístas que están aquí para infligir miseria a quienes vienen a Wikipedia para "contribuir de manera constructiva" o crear artículos autobiográficos llenos de spam y material con derechos de autor. El puesto de administrador en la Wikipedia en inglés no es envidiable: implica muchos gritos y drama , generalmente es difícil y ocasionalmente causa depresión . Muchos de ellos deben estar contentos de que esta propuesta haya sido rechazada, solo podría haber aumentado su ya larga lista de problemas. Phoenix - wiki 22:05, 9 de enero de 2008 (UTC) [ responder ]
Espero que nunca me pidan ser administrador. ¡Ya tengo suficientes problemas con ser quien soy! Igor Berger ( discusión ) 09:14 10 ene 2008 (UTC) [ responder ]
Nadie está obligado a ser administrador. Si sientes que no quieres ser administrador, entonces simplemente recházalo si alguna vez te nominan. Nil Einne ( discusión ) 18:12 11 ene 2008 (UTC) [ responder ]
  • Aunque esto tenía la intención de ser un poco humorístico, es mucho más fácil confiar en los administradores con respecto a este tipo de cosas que en los no administradores. -- Phoenix - wiki 20:04, 10 de enero de 2008 (UTC) [ responder ]
  • Además, según esto :
  • Los administradores de Wikipedia son miembros de confianza de la comunidad y se espera que cumplan todas las políticas y pautas de Wikipedia lo mejor que puedan. Los errores ocasionales son totalmente compatibles con esto (no se espera que los administradores sean perfectos), pero la falta de criterio constante puede dar lugar a una nueva solicitud de administración a través del procedimiento de solicitud de administración o a la suspensión o revocación de la administración. Si se revoca, el usuario puede tener una limitación temporal o permanente para volver a solicitar la administración.
  • A los administradores se les ha otorgado el poder de ejecutar ciertos comandos que los usuarios comunes no pueden ejecutar. Esto incluye el poder de bloquear usuarios, proteger páginas, editar páginas protegidas y eliminar y restaurar páginas. Todas estas capacidades deben usarse de acuerdo con la política (las políticas de bloqueo , protección de páginas y eliminación , respectivamente) y nunca deben usarse para "ganar" una disputa de contenido.
  • Un aspecto de las responsabilidades de un administrador es intentar evitar que se produzcan interrupciones en el sitio de Wikipedia y en sus usuarios. Los administradores están autorizados a utilizar su mejor criterio de acuerdo con los principios aceptados para lograrlo.
Phoenix - wiki 21:18, 10 de enero de 2008 (UTC) [ responder ]
Quizás (a lo anterior), excepto que si tu postulación fuera cierta, no habría burócratas y sus capacidades se otorgarían a todos los administradores. Sin embargo, ese no es el caso. Y la concesión de derechos de usuario (y tareas asociadas) es prácticamente todo lo que hay que hacer para ser un burócrata. ¿Y qué es esto? Por qué se trata de conceder un derecho de usuario. A mí me parecería una obviedad, pero supongo que a veces presumo demasiado ... - jc37 04:21, 11 de enero de 2008 (UTC) [ responder ]
Esta es una discusión sin sentido —ahora se confía en los administradores para hacer esto, así que sigamos adelante y editemos en algún lugar útil :-)-- Phoenix - wiki 22:17, 11 de enero de 2008 (UTC) [ responder ]
Ah, ya veo, todo lo que se ha dicho sobre probarlo y solucionar problemas y tal vez llegar a una mejor idea no era más que tonterías. Gracias. Aquellos de nosotros que sentimos que estaba más en línea con nuestros principios, tradiciones, propósito y naturaleza que esto fuera un premio destacado otorgado por medios tecnológicos en lugar de humanos, con la herramienta de bloqueo utilizada en caso de interrupción, deberíamos simplemente aceptar el hecho de que nunca se nos permitió el tiempo para proponer y discutir esa opción. Gracias a Dios, el consenso no puede cambiar. Hiding T 20:36, 13 de enero de 2008 (UTC) [ responder ]
La discusión anterior está cerrada. No la modifique. Los comentarios posteriores deben realizarse en la página de discusión correspondiente. No se deben realizar más modificaciones a esta discusión.