stringtranslate.com

Wikipedia: reversión para no administradores

Atajo
  • WP: NAR

La siguiente discusión está cerrada. Por favor no lo modifique. Los comentarios posteriores deben realizarse en la página de discusión correspondiente. No se deben realizar más ediciones en 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 manera más rápida y eficiente que con otros métodos. (Se han escrito scripts de usuario que imitan la funcionalidad de 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 creada por el último editor. Se proporciona un resumen de edición automático y la edición se marca como menor. (Se devuelve un mensaje de error si no hay un último editor al que volver).

Actualmente, la reversión sólo está disponible para administradores . Sin embargo, muchos no administradores se enfrentan ahora al vandalismo con regularidad, pero no tienen acceso a esta herramienta y, o no desean ser administradores o no cumplen con los estándares esperados, pero sin duda tienen experiencia y son dignos de confianza. Esta propuesta implementaría un proceso mediante el cual la función de reversión podría otorgarse y revocarse a personas que no sean administradores.

Ha llegado el punto en el que tenemos un consenso aproximado sobre cuáles deberían ser las restricciones, y ahora se le pide a la comunidad que busque formar un consenso sobre su implementación. Consulte la discusión anterior en la charla de Wikipedia: propuesta de reversión para no administradores y Wikipedia: reversión para no administradores . Es posible que sus preguntas o inquietudes ya hayan sido consideradas allí.

La forma en que funciona

Los usuarios pueden solicitar el botón de reversión si cumplen con los requisitos mínimos que se detallan a continuación.

  1. Primero deben presentar una solicitud en la sección siguiente.
    (¿En qué sección a continuación? Todo lo que veo aquí son votos y discusiones, lo que esperaría ver en una página de discusión. -- Stéphane Charette ( discusión ) 19:42, 4 de enero de 2008 (UTC))[ responder ]
  2. Los administradores deben verificar el historial del colaborador para ver si se les puede confiar la herramienta.
    (¿Qué están comprobando exactamente los administradores? Me preocupa que la falta de cualquier declaración o consenso sobre esto cause confusión. - DragonHawk ( charla | hist ) 21:02, 4 de enero de 2008 (UTC) ) [ respuesta ]
    ¿No es así como empezó RFA? Revisamos las contribuciones de los usuarios para comprobar si se puede confiar en ellos. ¿En qué se diferenciará este proceso? ¿Qué sucede cuando dos administradores no están de acuerdo? Por ejemplo, si le doy derechos al usuario:foo pero el administrador z no cree que sean dignos de confianza. ¿Tenemos entonces una discusión y luego reinventamos RFA, esta vez como RFR? - Ocultar T 12:53, 8 de enero de 2008 (UTC) [ respuesta ]
  3. Si el administrador está satisfecho, puede ir a Especial:Derechos de usuario (consulte $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 de los administradores antes de implementar esto, ya que alterará radicalmente su papel? - Ocultar T 22:28, 8 de enero de 2008 (UTC) [ respuesta ]

Requisitos para que los usuarios tengan rollback

No existen requisitos previos per se para obtener las herramientas, aunque un usuario no debe tener un historial de conflictos de edición y debe mostrar la necesidad de permiso de reversión (es decir, mucha reversión de vandalismo). Aunque puede que no sea fácil determinar esto, los administradores deben evaluar las solicitudes de reversión según el mérito individual y revisar el historial de edición de un usuario antes de otorgarle el permiso.

Uso

Esta herramienta se proporciona a editores cualificados para luchar contra el vandalismo. El uso se limita a revertir el vandalismo y revertir las propias ediciones. Los editores que utilicen la herramienta de reversión para otros fines o que cometan errores repetidos estarán sujetos a que se elimine la herramienta de reversión.

Eliminación del permiso

En caso de abuso, cualquier administrador puede eliminar la herramienta yendo a Especial:Derechos de usuario . Los no administradores pueden denunciar abusos en Wikipedia: tablón de anuncios de administradores/Incidentes . Los administradores deben tener cuidado de brindar a dicha acción el mismo cuidado y atención que a un bloque, y se aplican las expectativas habituales con respecto a las acciones administrativas. Si solo se eliminan debido a abuso, entrégueselos a todos los editores. - Ocultar T 22:59, 8 de enero de 2008 (UTC) [ respuesta ]

Preguntas más frecuentes

¿Qué es la reversión?
Rollback es un método para revertir ediciones con un solo clic. Los usuarios con el privilegio de revertir ven aparecer un enlace "[revertir]" en las diferencias y junto a las ediciones en las páginas Especial: Contribuciones y en los historiales de páginas, siempre que la edición sea la edición más reciente realizada en la página relevante. La reversión volverá a la versión más reciente de la página no 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 será reemplazado por el contenido de la revisión anterior. Revertir con la función deshacer implica cargar una diferencia y hacer clic en el enlace "deshacer"; Los cambios realizados en la diferencia se desharán, siempre que no haya conflictos con revisiones posteriores de la página. Hay varios scripts de usuario disponibles para revertir, que normalmente implican la automatización del método de reversión tradicional.
Por el contrario, revertir una edición no implica ningún paso intermedio. Como tal, ofrece una ligera ventaja de rendimiento tanto para el servidor como para el cliente. Debido a que se puede hacer directamente desde una página Especial: Contribuciones , hace que revertir todas las ediciones realizadas por una cuenta o dirección IP determinada sea relativamente simple.
¿Cuáles son las limitaciones de la reversión?
La reversión se limita a revertir solo las ediciones más recientes realizadas en una página. Los usuarios aún deberán aprender y utilizar otro método para poder revertir cualquier otra edición.
Debido a que la reversión no requiere que el usuario vea realmente las ediciones que está revirtiendo en ningún momento, existe un mayor riesgo de que los usuarios puedan realizar reversiones por error. La función deshacer, por el contrario, muestra al usuario los cambios que está a punto de realizar para su confirmación.
La función de reversión proporciona un resumen de edición automático al revertir una edición, que el usuario no puede cambiar ni complementar. Tanto la reversión como la deshacer tradicionales permiten proporcionar un resumen de edición, al igual que la mayoría de los scripts de usuario para revertir.
La velocidad de reversión también puede ser una desventaja si se usa mal, ya que puede acelerar enormemente las guerras de edición .
¿Cómo se relacionan estos pros y contras con dar reversión a los no administradores?
Muchas personas que no son administradores participan regularmente en la reversión del vandalismo, y la función de reversión puede hacer que esta tarea sea mucho más eficiente, ya que es una operación con 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 uso indebido accidental, y debido a que es una operación con un solo clic que permite todas las contribuciones de Si un usuario o una dirección IP se revierten rápidamente, existe el riesgo de un uso indebido intencional. Estos riesgos aumentan naturalmente en una base de usuarios que es más grande y/o menos experimentada en identificar y lidiar con el vandalismo.
¿Estos problemas son exclusivos de la herramienta de reversión?
No; Otros métodos de reversión pueden usarse de manera similar. Sin embargo, siempre que la reversión se utilice para el fin previsto (revertir un simple vandalismo) no debería haber problemas. El problema es asegurarse de que un posible usuario de reversión pueda distinguir de manera confiable el vandalismo simple de otras ediciones y se pueda confiar en que use la reversión solo en el primero.

Revisión histórica

Los cambios significativos a esta propuesta se registran a continuación. El número total de comentarios de apoyo/oposición de nivel superior en el momento del cambio se indica entre paréntesis.

Encuesta de opinión

Cerrado y archivado. Consulte Wikipedia: reversión/encuesta para no administradores para obtener resultados.

Propuestas alternativas

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

Cuenta los equivocados

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

Scripts y otras herramientas

propuesta originalmente hecha por Gracenotes

Casi todos aquí no tienen objeciones a que herramientas como Twinkle se utilicen ampliamente, pero muchos tienen objeciones a agregar el botón [retroceder] a la interfaz de usuario. Por lo tanto, brinde a los usuarios confirmados automáticamente la capacidad técnica de revertir, una acción que requiere un token único, pero no incluya el botón de revertir en las páginas de diferencias, historial o contribución del usuario (es decir, no lo incluya en absoluto). En este caso, solo se puede acceder a la reversión con una herramienta de terceros como Twinkle, que todos parecen estar de acuerdo en que está bien. Los problemas de velocidad de E/S y ancho de banda se resuelven y, dado que es posible realizar resúmenes personalizados con el permiso de reversión, no se pierde la funcionalidad de Twinkle (u otras herramientas antivandalismo).

Herramientas de apoyo)

  1. Según mis comentarios en la charla de Wikipedia: Reversión para no administradores # Otra idea . - Ned Scott 08:58, 9 de enero de 2008 (UTC) [ respuesta ]
  2. Según mi respuesta en la charla de Wikipedia: Reversión para no administradores # 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) [ respuesta ]
  3. Como he dicho antes, el requisito de que los usuarios "enciendan" la herramienta por sí mismos y tengan algunos conocimientos técnicos al respecto de antemano es una buena protección. Ecuación • ✗ / C • 11:35, 9 de enero de 2008 (UTC)
    ¿Proteger contra qué exactamente? No los vándalos, seguramente... Миша 13 23:32, 9 de enero de 2008 (UTC) [ respuesta ]
    Las personas que deseen realizar intencionalmente ediciones disruptivas masivas podrían utilizar fácilmente un script o un bot. - Ned Scott 00:18, 10 de enero de 2008 (UTC) [ respuesta ]
  4. Fuerte soporte pendiente de la viabilidad de dicha función (¿puede un script "desbloquear" o acceder a una función del servidor?). Bien hecho. Creo que esta propuesta tendrá más posibilidades de ser aprobada. Al final, nada cambia, excepto la eficiencia. Como TWINKLE no requiere autorización, esta propuesta no creará ninguna burocracia nueva y no otorgará ningún poder adicional a los administradores. De hecho, me sorprendería que esta función reciba más de unos pocos votos selectos a favor. Esto también resolvería la propuesta de Bot, que parece tener un gran consenso (ver más abajo). Cubriría la necesidad de credenciales, ya que el usuario tendría que tener suficiente experiencia para saber cómo utilizar los scripts de usuario y para qué se pueden utilizar. Mientras exista TWINKLE et al, el abuso de reversión nunca desaparecerá, por lo que el argumento del abuso de reversión es nulo. En mi opinión, esto es lo que estábamos 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 de enero de 2008 (UTC) [ respuesta ]
  5. ¿No hay nueva burocracia? Tienes mi (inesperado) apoyo. Es posible que hayas cortado el nudo gordiano.-- Doc g 20:10, 9 de enero de 2008 (UTC) [ respuesta ]
  6. Apoyo . Realmente este es un cambio profundo en la elaboración de salchichas. Es una mejora técnica, no realmente un cambio de política. Quizás sería mejor aceptar que las personas malas pueden ser disruptivas con o sin ellas y simplemente dejarlo claro... pero si la gente no acepta eso, al menos este es un paso adelante. - Gmaxwell ( discusión ) 20:21, 9 de enero de 2008 (UTC) [ respuesta ]
  7. Admitir esto o una opción en las preferencias del usuario que el usuario debe activar (pensé que amidaniel estaba trabajando en eso...) Sr. Z- man 20:34, 9 de enero de 2008 (UTC) [ respuesta ]
  8. Soporte Buena idea, principalmente ( discusión ) 20:39, 9 de enero de 2008 (UTC) [ respuesta ]
  9. El soporte aborda mis inquietudes con la propuesta original. Las preocupaciones de que esto podría facilitar el vandalismo son exageradas. - Haemo ( discusión ) 23:10, 9 de enero de 2008 (UTC) [ respuesta ]
  10. Pomte 13:33, 13 de enero de 2008 (UTC) [ respuesta ]
  11. Oh sí ! Como dije antes, necesitamos herramientas como estas. Dos Uno Seis Cinco Cinco discuten mi grandeza 15:13, 17 de enero de 2008 (UTC) [ respuesta ]
  12. Fuerte soporte por la sencilla razón de que facilita a todos la edición. No es una amenaza para la seguridad porque, aunque también facilita la edición para posibles vándalos, los vándalos aún pueden hacer lo que hace la función de reversión, solo que les lleva más tiempo. Y no son sólo ellos los que malgastan su tiempo, sino también los que luchan contra el vándalo. -- Felipe Aira 08:46, 30 de enero de 2008 (UTC) [ respuesta ]

Oponerse (herramientas)

  1. ¡Diablos, no! Independientemente de si es factible o no (consulte mi pregunta en la sección de discusión), es "seguridad" a través de la oscuridad en su forma más pura, lo que detesto por definición. No, gracias: si es posible con Twinkle, entonces es igual de factible con Greasemonkey (que no se puede cerrar para un usuario) y luego bienvenido a Wikipedia, donde cada vándalo tiene acceso a revertir si lo desea. Oye, ¿por qué molestarse con los guiones? Simplemente cree el enlace class="rollback-hidden" que por defecto es .rollback-hidden { display: none; } en CSS para todo el sitio. Entonces es solo una línea en su .css para habilitarlo; llame a piratear su monobook "credenciales" si lo desea. Миша 13 21:01, 9 de enero de 2008 (UTC) [ respuesta ]
    Aún sería posible eliminarlo si se abusa de él, por lo que en realidad es mejor que esos scripts por sí solos. - Ned Scott 22:11, 9 de enero de 2008 (UTC) [ respuesta ]
    ¿Disculpe? CSS también se puede anular 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 por el estilo (o simplemente podría desactivar CSS en mi navegador por completo). Lo sentimos, ¡pero ocultar funciones! = deshabilitarlas. Todo lo que está oculto puede descubrirse y usted no tiene control sobre lo que hace el cliente. Миша 13 22:34, 9 de enero de 2008 (UTC) [ respuesta ]
    La reversión se puede eliminar completamente de una cuenta específica . Si alguien está abusando de él, ya sea a través de TWINKLE o su propia modificación de CSS, podemos desactivarlo. - Ned Scott 00:14, 10 de enero de 2008 (UTC) [ respuesta ]
    Entiendo su preocupación por la "seguridad a través de la oscuridad" y creo que es válida. Sin embargo, dado que los scripts de usuario ya tienen reversión, todos los vándalos podrían tener acceso a la reversión de todos modos. Lo único que hace esta propuesta es hacerlo más eficiente. Además, ¿tenemos algún caso reportado de vándalos por parte del usuario TWINKLE et al por vandalismo? Mi experiencia es que la mayoría de los vándalos son direcciones IP, y aquellos que crean cuentas rara vez caen en algún tipo de vandalismo inteligente (del tipo que hace mucho daño, como movimientos masivos de páginas, etc.). Además, suponiendo que un vándalo ponga sus manos en esto, será más fácil para las personas revertirlo, porque otros también tendrán reversión. Ahora, asumiendo las declaraciones anteriores, esta característica nos traería un número muy pequeño de vándalos de élite armados con una reversión ligeramente más eficiente, contra una gran cantidad de patrulleros RC, con una reversión ligeramente más eficiente. En cifras puras, 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 scripts de usuario de reversión en el pasado, lo cual, aunque (obviamente) no puedo estar seguro, en mi experiencia no he visto que se haga algo así. - Vox Rationis ( Discusión | contribuciones ) 22:19, 9 de enero de 2008 (UTC) [ respuesta ]
    No, tales brotes no han ocurrido en el pasado (al menos no que yo sepa) simplemente porque, como dicen algunos, los métodos similares a Twinkle tardan años en realizar una sola reversión, lo que, junto con la latencia del servidor, hace que una interrupción tan masiva sea inviable. . Sin embargo, lo que propone esta propuesta es básicamente hacer posible que un vándalo realice reversiones a velocidades de cientos por minuto (simplemente abra las contribuciones de alguien, obtenga tokens de reversión y comience a presionar Ctrl y haga clic en los enlaces de reversión). Y no digamos que podemos permitírnoslo porque tenemos más patrulleros: cuando decenas de ellos de repente comiencen a pelear y a entrar en conflicto para revertir al vándalo, no será agradable para los servidores. Миша 13 22:34, 9 de enero de 2008 (UTC) [ respuesta ]
    Simplemente limpié mi zona de pruebas y luego la revertí. Tomó 1,8 segundos (lo cronometré en mi cronómetro, por lo que hay cierta 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, y ya hicieron 500 (número máximo de artículos vistos a la vez en la página de contribuciones del usuario). 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 pocas palabras: 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é pasa si (dado que los tokens de reversión están precargados) la reversión puede ejecutarse a, digamos, 5000 por minuto? ¿Le importaría verificar eso? ¿Tienes en cuenta también que los resúmenes revertidos son editables? ¿Se puede 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á alguna travesura? Oh, espera, podría ejecutar eso en 10 nombres de usuario diferentes para combinar aún más la interrupción. Sí, estamos hablando de vandalismo bastante "elitista", pero si yo soy capaz de esto, también puede serlo cualquier vándalo decidido y con inclinaciones técnicas. Mi punto principal es: no demos a los vándalos nuestras propias armas contra ellos. En absoluto. Миша 13 23:26, 9 de enero de 2008 (UTC) [ respuesta ]
    La reversión solo se puede ejecutar a cinco por minuto para los que no son administradores y a cinco por dos minutos para los usuarios no 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 involuntario 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) [ respuesta ]
    No hay comentarios sobre el resto, pero para empezar, los vándalos han usado el centelleo en el pasado para destrozar de manera más rápida y eficiente. La primera vez que lo vi fue Entrañas  ( charla  · contribuciones ) quien usó centelleo para volver a su página vandalizada y luego advertir a quienes lo revirtieron.[1] - charla piloto de Auburn 00:30, 10 de enero de 2008 (UTC) [ respuesta ]
    Mi principal preocupación acerca de dar la reversión a todos los usuarios confirmados automáticamente es que no muchos editores nuevos saben que existe twinkle. La mayoría de los usuarios que lo usarían con fines disruptivos son bloqueados y han abandonado o pasado a otro 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 homosexual gay con una polla pequeña" 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 debajo de las narices de los vándalos. Es como dejar el coche abierto en una calle concurrida y dejar la cartera y el Rolex en el asiento. Es en gran medida un sistema de seguridad a través de oscuridad como Misza mencionó anteriormente. Es por eso que me opuse a propuestas similares a ésta, y probablemente me opondré a ésta a menos que alguien pueda explicarme cómo es probable que no se abuse de ella. - Nn123645 ( discusión ) 05:52, 10 de enero de 2008 (UTC) [ respuesta ]

Neutral (herramientas)

Discusión (herramientas)

Disculpe mi ignorancia con respecto al funcionamiento interno de MediaWiki, pero ¿el token de reversión es realmente computable en el lado del cliente (dada una URL de diferencia, por ejemplo)? Estuve profundizando en este problema (y en el código de MediaWiki) hace bastante tiempo y llegué a la conclusión de que se basa en una sal que solo se almacena en el lado del servidor. ¿Fue esa conclusión incorrecta? Francamente, si fuera computable en el lado del cliente, no veo el propósito del token en absoluto. Миша 13 20:29, 9 de enero de 2008 (UTC) [ respuesta ]

Supongo que significa que esto funcionaría únicamente en el nivel de API. Supongo que eso requerirí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). Esto ya funciona, por cierto, compruébalo... Te dará un token de reversión válido :) SQL ¡Consúltame! 20:51, 9 de enero de 2008 (UTC) [ respuesta ]
Hmm, básicamente estamos hablando de usar la reversión para reducir las solicitudes del servidor de 3 (obtener diferencias, obtener formulario de edición usando &action=undo , publicar contenido revertido) a 3 (obtener diferencias, obtener token de reversión, "hacer clic" en la URL de reversión) )? :) Oh, espera, estamos ahorrando algo de ancho de banda al no tener que publicar el contenido revertido. Sí, ¿me perdí algo? </sarcasm> Ah, y todavía estoy esperando una respuesta definitiva sobre si el token es computable en el lado del cliente. Миша 13 21:10, 9 de enero de 2008 (UTC) [ respuesta ]

Presente los pasos para revertir (digamos... WP:ACC , al azar).

  1. Grabar diferencia (45956 bytes)
  2. Grap deshacer URL (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. Grabar diferencia (45956 bytes)
  2. Tomar token de reversión (372 bytes)
  3. Enviar URL de reversión (151 bytes)

Para un total de: 46479 bytes

Eso es un ahorro del 65% en ancho de banda, suponiendo que las cookies y demás sean las mismas entre solicitudes, suponiendo que haya hecho todo esto bien. SQL Consultame! 21:51, 9 de enero de 2008 (UTC) [ respuesta ]

Bots antivandalismo

Estoy cerrando esto porque ya se ha actuado sobre ello: [2] [3]. - Random832 19:49, 10 de enero de 2008 (UTC) [ respuesta ]

Si se aprueba o no la propuesta original (espero que se apruebe):

Propongo que demos marcha atrás a los robots antivandálicos ( ClueBot , VoABot II , CounterVandalismBot y el actualmente desaparecido 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 oscura 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 realizan miles de reversiones cada día . - Cobi ( t | c | b ) 02:38, 7 de enero de 2008 (UTC) [ respuesta ]

Soporte (robots)

  1. Como nominador. - Cobi ( t | c | b ) 02:38, 7 de enero de 2008 (UTC) [ respuesta ]
  2. Soporte si solo los bots obtienen reversión Alex fusco 5 02:45, 7 de enero de 2008 (UTC) [ respuesta ]
  3. Apoye en ambos sentidos. Portia1780 ( discusión ) 02:53, 7 de enero de 2008 (UTC) [ respuesta ]
  4. Soporte Si alguien necesita la herramienta de reversión para mejorar la tensión del servidor, entonces estos bots ciertamente la necesitan... sólo piense en cuánto más trabajo tendríamos que hacer si no estuvieran trabajando todas las horas del día y de la noche. - Geoff Riley ( discusión ) 02:55, 7 de enero de 2008 (UTC) [ respuesta ]
  5. Los robots van a hacer la reversión, tengan esto o no, por lo que parte de la oposición basada en los errores de los bots no tiene mucho sentido. Sr. Z- man 04:09, 7 de enero de 2008 (UTC) [ respuesta ]
  6. Support Bots necesita 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) [ respuesta ]
  7. Soporte completo como parte del comando WP:BAG β 04:31, 7 de enero de 2008 (UTC) [ respuesta ]
  8. Apoye a los robots de verificación RC que necesitan toda la ayuda que puedan obtener. BJ Talk 04:44, 7 de enero de 2008 (UTC) [ respuesta ]
  9. Fuerte soporte: cualquier cosa que haga que el todopoderoso ClueBot funcione mejor es algo que debería implementarse. - Nn123645 ( discusión ) 05:37, 7 de enero de 2008 (UTC) [ respuesta ]
  10. ( miembro de BAG ) Apoyo condicional . Apoyo otorgar este privilegio a estas cuentas si existe un sistema para otorgar y revocar este privilegio. No apoyo la creación de un nuevo método solo para acomodar estas cuentas en este momento. (Tampoco apoyo simplemente hacerlos +sysop en este momento tampoco). - Charla de xaosflux 06:06, 7 de enero de 2008 (UTC) [ respuesta ]
  11. Apoyo. No se me ocurre ningún posible inconveniente. Si hubiera alguno, sería bastante fácil revocar los privilegios de un total de tres bots. Rivertorch ( discusión ) 06:48, 7 de enero de 2008 (UTC) [ respuesta ]
  12. Fuerte apoyo independientemente de si se implementa la propuesta principal (que debería ser así, en mi opinión): esta es una idea brillante y debería implementarse lo más rápido posible. Ashdog137 ( discusión ) 08:32, 7 de enero de 2008 (UTC) [ respuesta ]
  13. Soporte condicional , solo en caso de que se indique en los resúmenes de edición, las reversiones fueron realizadas por bots y no por usuarios comunes. - Angelo ( discusión ) 09:30, 7 de enero de 2008 (UTC) [ respuesta ]
    El resumen de edición será exactamente el mismo que es ahora (Revirtiendo posible vandalismo por parte de Special:Contributions/USER_REVERTED a la versión de USER_PREVIOUS. ¿Falso positivo? Infórmalo . Gracias, ClueBot . (MySQL-ID) (Bot)) , usando el oscuro función de reversión para proporcionar el resumen de edición propio del bot. -- Cobi ( t | c | b ) 10:00, 7 de enero de 2008 (UTC) [ respuesta ]
  14. Soporte Si hay un grupo que definitivamente merece la reversión, son estos robots antivandálicos. No hay razón para no darles un impulso extra de rendimiento. Spellcast ( charla ) 13:40, 7 de enero de 2008 (UTC) [ respuesta ]
  15. Soporte : no veo ningún problema con esto. Burzmali ( discusión ) 13:41, 7 de enero de 2008 (UTC) [ respuesta ]
  16. Soporte - Quintote ( discusión ) 14:16, 7 de enero de 2008 (UTC)[ responder ]
  17. Soporte , me parece obvio... ¡ Consultame SQL ! 16:37, 7 de enero de 2008 (UTC) [ respuesta ]
  18. Los argumentos de apoyo en contra de esto son tontos. - Random832 16:42, 7 de enero de 2008 (UTC) [ respuesta ]
  19. Comentario Presumiblemente, cualquier administrador puede hacer esto. Es decir, esta propuesta es discutible, a menos que exista alguna disposición que no permita otorgar permiso a los bots, en cuyo caso apoyo eliminar esa restricción. Es una decisión del administrador y el administrador es responsable de ello. - Abd ( discusión ) 16:46, 7 de enero de 2008 (UTC) [ respuesta ]
  20. Soporte Creo que esto es un hecho, si un administrador puede proporcionarle la herramienta a cualquier usuario normal, entonces un bot confiable también lo sería. 1! = 2 16:50, 7 de enero de 2008 (UTC) [ respuesta ]
  21. Soporte obvio. Los robots antivandalismo ya están utilizando su propio sistema de reversión: proporcionar una API ya utilizada no causará ningún daño adicional. Los beneficios incluyen reversiones más rápidas sin los efectos negativos de tener que calcular los conflictos de edición. - Sigma 7 ( discusión ) 19:11, 7 de enero de 2008 (UTC) [ respuesta ]
  22. Soporte No hay motivo para no hacerlo. Ya confiamos en que harán muchísimos retrocesos cada minuto. También podría dejarles hacerlo de forma más eficiente. No habría cambios en cuanto a qué artículos se revocarán, cuándo o bajo qué condiciones. En cuanto a la preocupación por la piratería que se plantea a continuación, no creo que el acceso de reversión vaya a incitar más interés en piratear estos bots. La utilidad para un hacker para controlar un bot sigue ahí, incluso sin acceso de reversión. Como nota al margen, Franamax necesita ver menos películas. Ecuación • ✗ / 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 cause problemas de contenido importantes, así que esto me parece algo bueno. Charla de MBisanz 21:39, 7 de enero de 2008 (UTC) [ respuesta ]
  24. Apoyo . Spebi 22:05, 7 de enero de 2008 (UTC) [ respuesta ]
  25. Soporte 99of9 ( discusión ) 23:10, 7 de enero de 2008 (UTC) [ respuesta ]
  26. Soporte , pero ¿por qué dárselo a MartinBot? Marlith T / C 23:13, 7 de enero de 2008 (UTC) [ respuesta ]
  27. Soporte Los bots necesitan las herramientas más que nadie aquí. Capitán panda 23:15, 7 de enero de 2008 (UTC) [ respuesta ]
  28. Soporte Ahora esto, puedo verlo. Los bots no deben ejecutarse sin la aprobación de BAG . y los bots son los que pueden atascar 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 si surge algún problema. (con una resolución que conducirá a una posible reactivación en el futuro). - hijo maestro T - C 23:26, 7 de enero de 2008 (UTC) [ respuesta ]
  29. Soporte SJMNY ( discusión ) 00:14, 8 de enero de 2008 (UTC) [ respuesta ]
  30. Excelente idea. Acalamari 00:17, 8 de enero de 2008 (UTC) [ respuesta ]
  31. Apoyo . Puedo apoyar esto a pesar de oponerme a los 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 pueden bloquear si entran en conflicto. Apoyaría que la bandera de reversión se otorgue automáticamente cuando se obtenga la bandera del bot. Royal broil 01:05, 8 de enero de 2008 (UTC) [ respuesta ]
    El único problema con la asignación de reversión a la bandera del bot es que los bots antivandálicos no están marcados. Esto se hace para que sus ediciones no queden ocultas ("ocultar ediciones del bot") en cambios recientes. - Cobi ( t | c | b ) 01:31, 8 de enero de 2008 (UTC) [ respuesta ]
  32. slakr pregunta a continuación si lo necesitan. Nadie lo necesita, pero es útil. – thedemonhog talk • ediciones 01:40, 8 de enero de 2008 (UTC) [ respuesta ]
  33. También se necesitan robots de soporte para ayudar con los vadals. SuperGodzilla2090 4 TACOZ! 01:45, 8 de enero de 2008 (UTC) [ respuesta ]
  34. Soporte : Es posible que los bots no necesiten esta herramienta, pero seguro que servirá de algo, incluso si ClueBot fuera prácticamente imbatible con la reversión del administrador.- Animum ( discusión ) 02:17, 8 de enero de 2008 (UTC) [ respuesta ]
    COMENTARIO: ¿cómo puedes justificar darle tanto poder a robots incontrolados e irresponsables sobre el funcionamiento de Wikipedia si admites que no es necesario? Smith Jones ( discusión ) 02:31, 8 de enero de 2008 (UTC) [ respuesta ]
    Smith Jones, esto no cambiará en absoluto lo que hacen los robots . Actualmente funcionan de la misma manera, pero esto les permite decirle a los servidores de Wikipedia "Por favor, revierta las ediciones realizadas por el 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." "Bien, ahora dame el formulario de edición del artículo yyyyyy". "Bien, aquí está el texto (que el servidor le dio al robot anteriormente) para la publicación del 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) [ respuesta ]
    Gracias, creo que ahora entiendo mejor el problema. Sin embargo, me opondré a esto, porque a través de experiencias recientes con bots he aprendido que no se puede razonar con ellos sin la ayuda de un administrador. Smith Jones ( discusión ) 02:52, 8 de enero de 2008 (UTC) [ respuesta ]
    ... Sin embargo, nunca has tenido un encontronazo con ClueBot  ;) - Cobi ( t | c | b ) 03:10, 8 de enero de 2008 (UTC) [ respuesta ]
  35. Soporte Lo único que cambia aquí es la forma en que revierte las ediciones. Sólo puedo ver esto como positivo. Mayormente ( discusión ) 03:45, 8 de enero de 2008 (UTC) [ respuesta ]
  36. Soporte Como antes, mi opinión no ha cambiado. -- Charitwo charla 05:16, 8 de enero de 2008 (UTC) [ respuesta ]
  37. Apoyar esto parece razonable. Mientras continúen brindando los resúmenes de edición y las notificaciones de las páginas de discusión que brindan, estos bots deben ser lo más eficientes posible. Eluchil404 ( discusión ) 05:30, 8 de enero de 2008 (UTC) [ respuesta ]
  38. Soporte - C l a n CC ( Discusión ) 05:36, 8 de enero de 2008 (UTC) [ respuesta ]
  39. Apoyo . ¡Por supuesto, a los robots antivandálicos se les debe conceder la reversión! Los robots no editan la guerra, es muy poco probable que "se vuelvan rebeldes" o destrocen, y eso no cambiará su comportamiento en lo más mínimo. Dar marcha atrás a los bots simplemente los hará más eficientes y más fáciles de usar en los servidores. Pyrospirit  ( discusión  · contribuciones ) 05:53, 8 de enero de 2008 (UTC) [ respuesta ]
  40. Soporte sólido : muéstrame una razón por la que los bots no deberían retroceder y lo reconsideraré. No afecta mucho la velocidad de los robots, por lo que si van a cometer un error, de todos modos lo harían a la misma velocidad. La única diferencia que hará este cambio es la reducción de la carga del servidor, lo cual cuenta con mi aprobación. James086 Charla | Correo electrónico 06:00, 8 de enero de 2008 (UTC) [ respuesta ]
  41. -- Rschen7754 ( T C ) 06:05, 8 de enero de 2008 (UTC) [ respuesta ]
  42. Apoyo Un grupo muy pequeño que puede ser fácilmente monitoreado y dado que hacen un gran número de contribuciones, esto proporcionará una mayor ventaja. - Falcorian  (discusión) 06:27, 8 de enero de 2008 (UTC) [ respuesta ]
  43. Soporte : el consenso general ha sido que los bots proporcionan un recurso invaluable contra el vandalismo y otros procedimientos de limpieza en WP, y la función de reversión puede potencialmente brindarles otra herramienta para ayudarlos en sus esfuerzos. Sin embargo, algunos bots ya tienen una función de reversión en vigor. Seicer ( discusión ) ( contribuciones ) 07:01, 8 de enero de 2008 (UTC) [ respuesta ]
  44. Ya retroceden por el camino lento. En cuanto a llenarse más rápido, el factor limitante en 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) [ respuesta ]
  45. Apoyo , pero, francamente, se puede hacer dentro de las políticas existentes: permiso otorgado por los 'cratos' mediante recomendación positiva del BAG . Миша 13 11:26, 8 de enero de 2008 (UTC) [ respuesta ]
  46. Fuerte soporte : esto no les dará ningún poder que no tengan ya, solo reducirá la carga del servidor cuando lo hagan. עוד מישהו Od Mishehu 12:12, 8 de enero de 2008 (UTC) [ respuesta ]
  47. Apoyo - según Od Mishehu. -- Charla disidente anónima 12:38, 8 de enero de 2008 (UTC) [ respuesta ]
  48. Apoyo . Tiene sentido, ya hacen lo mismo. Coemgenus 13:46, 8 de enero de 2008 (UTC) [ respuesta ]
  49. Apoye especialmente a ClueBot. —Comentario anterior sin firmar agregado por Dolive21 ( charla • contribuciones ) 16:00, 8 de enero de 2008 (UTC)[ responder ]
  50. Apoyo . No se me ocurre ninguna razón plausible por la que se deba impedir 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 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) [ respuesta ]
  52. Apoyo . No veo ninguna razón para no permitir que los robots antivandalismo 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, será el mismo). -  AWeenieMan  ( discusión ) 19:39, 8 de enero de 2008 (UTC) [ respuesta ]
  53. Apoye el sentido común. el wub "?!" 21:37, 8 de enero de 2008 (UTC) [ respuesta ]
  54. apoyo . No hay ningún inconveniente tangible en esta solicitud. - JamesTeterenko ( discusión ) 21:58, 8 de enero de 2008 (UTC) [ respuesta ]
  55. Apoyo. , según el nombre y según Od Mishehu  ( discusión  · contribuciones ). Cirt ( discusión ) 23:29, 8 de enero de 2008 (UTC). [ responder ]
  56. Soporte , bajo la condición de que las aprobaciones sean mantenidas por BAG, no por esta página de políticas, ya que tienen un mejor conocimiento técnico para abordar adecuadamente si dicho bot lo necesita. Se ha demostrado aquí que un aumento del rendimiento sería significativo. Algunos argumentan que esto permitiría más ediciones y, por lo tanto, más tensión en el servidor, pero como estos bots verifican cada diferencia (hasta donde yo sé, corríjanme si me equivoco), no habría ningún cambio en el número de reversiones. simplemente haga que dichas acciones sean más fáciles, limpias, etc. Además, el argumento de que esto daría a los bots demasiado poder es, a mi modo de ver, inválido. Estos bots ya son capaces de editar a velocidades inhumanas y probablemente podrían hacerlo más rápido, suponiendo que la página RC vaya más rápido (en otras palabras, el tráfico de WP aumenta 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) [ respuesta ]
  57. Pomte 00:57, 9 de enero de 2008 (UTC) [ respuesta ]
  58. Apoyo . 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. Voz de todos 06:48, 9 de enero de 2008 (UTC) [ respuesta ]
  59. Broma en contra, porque ClueBot me gana en demasiadas reversiones. Es broma, apoyo . sho y 16:01, 9 de enero de 2008 (UTC) [ respuesta ]
  60. Apoyo . Siempre que puedas hacer el mismo trabajo usando menos recursos, es algo bueno. Los bots seguirán haciendo su trabajo de una manera que requiera menos recursos limitados (grandes, pero limitados). Xymmax ( discusión ) 17:49, 9 de enero de 2008 (UTC) [ respuesta ]
  61. Soporte : los robots ya son capaces de causar grandes cantidades de daño, por lo que esto no debería ser gran cosa. - Ashley Y 21:09, 9 de enero de 2008 (UTC) [ respuesta ]
  62. Soporte por comando Beta.-- Phoenix - wiki 21:48, 9 de enero de 2008 (UTC) [ respuesta ]
  63. Soporte : van a revertir de todos modos; ¿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 de enero de 2008 (UTC) [ respuesta ]
  64. El soporte tiene sentido. - Ned Scott 03:21, 10 de enero de 2008 (UTC) [ respuesta ]
  65. Fuerte apoyo : ¡por qué no! Hay muchas razones por las que deberían hacerlo, la mayoría de las cuales se mencionan anteriormente. Tiddly - Tom 18:56, 10 de enero de 2008 (UTC) [ respuesta ]

Oponerse (robots)

  1. Hay dudas de que los humanos reales deberían tener la capacidad, pero ¿se debería otorgar la autoridad a un proceso automatizado? El objetivo de los bots es que se examinan rigurosamente por su capacidad para hacer juicios mecanizados caso por caso. ¿Esto ahora propone permitir que el bot juzgue una edición y, en función de esos resultados, revertir más ediciones sin evaluación? Hombre cortacésped o Terminator , elige. Además, ¿no están ya codificados los bots para una carga mínima del servidor? ¿Podemos tener alguna opinión oficial de BAG sobre esto? (Sin ofender a los BAG-er que ya están presentes) Franamax ( discusión ) 03:49, 7 de enero de 2008 (UTC) [ respuesta ]
    Pensando 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 aún 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 solicitarla? Considerándolo bien, este puede ser un tema completamente separado que necesita aportes de la comunidad completamente separados. :( Franamax ( discusión ) 04:11, 7 de enero de 2008 (UTC) [ respuesta ]
    Como miembro del grupo de aprobación de bots, permítanme señalar algunos puntos. Los AVB (bots antivandálicos) requieren una gran cantidad de recursos para ejecutarse, tanto en los servidores de wikimedia como en el sistema host. El método estándar de reversión requiere 3 llamadas al servidor. obtener la diferencia. obtenga el cuadro de edición y luego envíe 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, eso suma una gran cantidad de transferencia de datos (en el rango de gigabytes) semanalmente. La reversión, por otro lado, es muy agradable para los servidores. con reversión, obtener diferenciación, enviar token de reversión. reversión realizada. no es necesario volver a cargar la página ni 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, deberían revertirse todas. En cuanto al juicio de edición pasa lo mismo, igual revisan la diferencia. Muy pocos vándalos realizan ediciones cercanas a constructivas y todas las ediciones que realizan seguidas deben revertirse. La reversión de AVB es una muy, muy buena idea. es mejor en los servidores y mejor en el bot. No hay necesidad de temer al terminador, tipo bots. no existen. Comando β 04:19, 7 de enero de 2008 (UTC) [ respuesta ]
    Si bien no estoy seguro, creo que así es esencialmente como funcionan. Eso es sólo una reversión manual realizada automáticamente. Sr. Z- man 04:15, 7 de enero de 2008 (UTC) [ respuesta ]
  2. Oponerse a— ...pero ¿lo necesitan ? Esa es nuevamente la pregunta que hago, y nuevamente, no se preocupe por el rendimiento . Estamos hablando de un cambio de permisos bastante grande para dar cabida a un total de 3 bots activos. Y recuerde, tenemos un servidor de herramientas exactamente por esta razón: para que los bots puedan ejecutarse en él y no consumir exceso de ancho de banda/accesos SQL. Además, los robots basados ​​en heurística se equivocan, y la reversión les permitiría hacerlo mucho más rápido. Además, no estoy seguro de sentirme cómodo dándole a cada bot en el grupo de bots la capacidad de revertir, particularmente considerando que sus ediciones están ocultas de manera predeterminada tanto de RC como de vandalismo en primer lugar. Presente una razón sólida por la que es necesario y lo reconsideraré. -- slakr \  talk  / 03:57, 7 de enero de 2008 (UTC) [ respuesta ]
    ¿Quiere una razón sólida para utilizar la reversión? WP:PERFORMANCE está destinado al 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 en la base de datos porque estaba ejecutando mi bot demasiado rápido y causando demasiada tensión en los servidores. Brion y los demás desarrolladores son buenos, pero como operadores de bots nos damos cuenta de que tenemos problemas adicionales de los que los usuarios habituales no tienen que preocuparse. Además, como operador de bot, es nuestro trabajo descubrir los mejores y menos intensivos métodos que podamos. la reversión 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 un espejo en vivo de la misma que no contiene texto de página. Comando β 04:34, 7 de enero de 2008 (UTC) [ respuesta ]
    Los PS AVB no están marcados y, por lo tanto, sus ediciones aparecen en la fuente RC y en los cambios recientes. Comando β 04:40, 7 de enero de 2008 (UTC) [ respuesta ]
    Existe una diferencia fundamental entre su bot y los bots antivandálicos en la carga de su servidor. La causa del bloqueo de su base de datos probablemente se debió a demasiadas ediciones a la vez, lo que provoca un retraso en la replicación. Entonces, según esa lógica, retroceder a los bots en realidad aumentaría el retraso en la replicación, ya que pueden enviar ACTUALIZACIONES e INSERTACIONES mucho más rápido. En segundo lugar, me gustaría ver de dónde proviene el aumento de rendimiento del 66%, ¿o es un número arbitrario? Finalmente, independientemente de la disponibilidad del contenido, el servidor de herramientas todavía está ubicado en la intranet de wikimedia, por lo que aún reduce el consumo de ancho de banda externo. Este último debería ser el primer curso de acción que se debe intentar con un bot como ClueBot (antes de algo tan drástico como revertirlo a él y a otros bots). -- slakr \  talk  / 05:11, 7 de enero de 2008 (UTC) [ respuesta ]
    ¿De dónde saqué el 66%? diff GET() 30Kb, versión antigua GET() 30Kb, POST() de texto revertido 30Kb, transferencia total de servidor/bot 90Kb. con reversión: diff GET() 30 KB, envía token de reversión 1 KB. transferencia total de datos de servidor/bot 31 KB. es decir, 59 KB menos o una mejora del 65,555555 %. En cuanto a su 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 Amsterdam y los servidores de wikimedia están en Tampa Bay, Florida. El servidor de herramientas es realmente útil 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? mierda. La reversión y la codificación adecuada del bot lo impiden. La reversión es como dije, al menos un aumento del 66% (para una reversión de una sola edición) para una reversión de múltiples ediciones es aún mejor en los servidores. Por favor, deja de hablar de cosas de las que no tienes ni idea. Simplemente te hace quedar mal. Comando β 12:52, 7 de enero de 2008 (UTC) [ respuesta ]

    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

    Yo descanso mi caso. - Cobi ( t | c | b ) 05:26, 7 de enero de 2008 (UTC) [ respuesta ]
    Espera, esto se está saliendo de control aquí. 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 esa no sea la mejor estrategia. Ahora estás entrando en un área completamente diferente, es mucho mejor dejar que esas personas comenten directamente. Franamax ( discusión ) 05:52, 7 de enero de 2008 (UTC) [ respuesta ]
    En realidad, prefiero la opinión de Brion y otros sobre el asunto. Por supuesto, el problema es que nunca he argumentado un punto tan simple como "la reversión requiere más recursos que la reversión manual", por lo que, si bien es posible que hayan dicho eso, es posible que lo hayan sacado de contexto; porque mi punto no era que la reversión requiera más recursos, sino que los bots que tienen reversión posiblemente consumirían más recursos según la lógica de betacommand. Preferiría que simplemente los vincules a mis comentarios y luego continuaremos desde allí en lugar de jugar al Messenger; o, alternativamente, pueden simplemente publicar aquí sus comentarios personalmente. -- slakr \  talk  / 06:21, 7 de enero de 2008 (UTC) [ respuesta ]
    Slakr, este es un consejo gratuito, por lo que vale lo que pagaste por él, pero te sugiero que lo dejes; la reversión manual es menos intensiva que la reversión automática; en mi opinión, vas a perder eso a lo grande :) Dejemos de citar del IRC. si quieren comentar aquí, lo harán, si quieres contactarlos para una discusión directa, estoy seguro de que tú también puedes hacerlo. Franamax ( discusión ) 06:33, 7 de enero de 2008 (UTC) [ respuesta ]
    En realidad, la razón principal por la que respondí es que mi punto fue sacado de contexto, tal como lo has hecho tú accidentalmente. :P Mi punto original fue una simple respuesta a la afirmación de Betacommand de que el uso de recursos del Bot X refleja el uso de recursos del Bot Y, lo cual no es necesariamente el caso. Sé que la reversión es el 99,9% de las veces más amigable con los recursos que la reversión manual; sin embargo, en la situación que afirmó, podría constituir el 0,1%, es decir, la excepción a la regla , porque en el único caso de bloqueos de bases de datos debido a retrasos en la replicación, en teoría podrían producirse más reversiones mediante scripts automatizados (es decir, bots). exacerbar el problema debido a que la naturaleza de muchas ACTUALIZACIONES e INSERCIONES al mismo tiempo es más un cuello de botella debido a la velocidad a la que se pueden ejecutar en un período de tiempo finito. Aunque agradezco tu consejo. -- slakr \  talk  / 06:49, 7 de enero de 2008 (UTC) [ respuesta ]
    No importa cuántas maneras lo hagas, 864 administradores que usan la reversión causarán mucho más estrés (y potencial de retraso en la replicación) que 3 bots. Ciertamente, si se llevara a cabo la propuesta anterior, incluso suponiendo que el 20% de todos los editores utilicen 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, se hacen demasiadas suposiciones, pero la más notable es fundamental (aún falta): simplemente porque los bots tendrán la herramienta de reversión, resultará en un aumento en las consultas de mutadores contra los servidores. Consultas más eficientes (en tiempo y carga) no necesariamente se traducen en más consultas (en cantidad). Creo que su afirmación original es errónea por diversas razones, pero esta parece la más relevante. Justin chat 04:10, 8 de enero de 2008 (UTC) [ respuesta ]
  3. Oponerse a. Estoy de acuerdo con la afirmación número 1 anterior. Los bots no son tan buenos como podrías pensar. A veces pueden resultar molestos. Y algunas veces, el robot de pista ha borrado lo anterior. Si esto es erróneo, infórmelo al Comité de Adoctrinamiento para que podamos borrarlo también.  :-) es una broma. Bromas aparte, me opongo a esta idea. gracias. -- Steve, Sm8900 ( discusión ) 04:00, 7 de enero de 2008 (UTC) [ respuesta ]
    1. Comenta que sentido tiene eso? Si los bots no tienen reversión, simplemente usarán más recursos y no dejarán de ejecutarse. BJ Talk 04:44, 7 de enero de 2008 (UTC) [ respuesta ]
    (ec) Te das cuenta de que, independientemente de si se da reversión a los bots , los bots operarán exactamente de la misma manera a casi las mismas velocidades. La reversión simplemente aliviará un poco el estrés de los bots y los servidores. En este momento, cuando ClueBot decide revertir, toma el metahistorial de la página, encuentra la última edición realizada por un usuario distinto del usuario al que está revirtiendo, solicita los datos para esa entrada, solicita el formulario de edición y publica esos datos. al 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 al mismo tiempo que revierte 1, solo estamos hablando de acelerar esa 1 y hacer Es más fácil en los servidores. - Cobi ( t | c | b ) 04:51, 7 de enero de 2008 (UTC) [ respuesta ]
  4. ¡¡¡OPONERSE A!!! ¡NO! La intolerancia automatizada NUNCA debería convertirse en una característica de Wikipedia. Smith Jones ( discusión ) 00:18, 8 de enero de 2008 (UTC) [ respuesta ]
    • ¿Te das cuenta de que no se trata de si debería haber bots en Wikipedia o no? Se trata simplemente de una cuestión de si se les debería permitir tener una versión más eficiente de una herramienta que ya tienen y utilizan a diario. - Nn123645 ( discusión ) 06:48, 8 de enero de 2008 (UTC) [ respuesta ]
  5. Oponerse No, punto. Por las mismas razones que se enumeran en la RFA para bots y en la reciente discusión en el vicepresidente. (No lo voy a sacar de los archivos, si no lo has leído entonces ve a buscarlo) No, no, no. ¿Cómo diablos pasó esto de una "encuesta" para otorgar la reversión a los usuarios confiables a incluir los robots antivandálicos en esto? (No responda que es retórico; el punto es, ¿no nos estamos diversificando un poco?) Conocimiento de uno mismo | charla 11:34, 8 de enero de 2008 (UTC) [ respuesta ]
  6. Oponerse por KOS. m ir y a 00:42, 9 de enero de 2008 (UTC) [ respuesta ]

Neutral (robots)

  1. Este tiene ventajas y desventajas. En primer lugar, todas mis objeciones con respecto al proceso de investigación y la inevitabilidad (¿es esa una palabra?) de que un usuario examinado se vuelva vandálico se van por la ventana cuando hablamos de bots. Eso es bueno. Pero, por otro lado, el hecho de que los bots sean creados por los usuarios los hace susceptibles al sesgo 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 prejuicios personales. Lo que realmente me preocupa es la posibilidad de una reversión masiva y automatizada por parte de los bots . Todos sabemos que los bots no son perfectos (a veces, molestos), y debido a esto, a veces (rara vez, pero a veces) los bots cometen errores o identifican erróneamente una edición legítima o lo que sea como algo inapropiado. Si bien esto es poco probable, un error en el bot o una falla en su diseño podría hacer que identifique incorrectamente una gran cantidad de ediciones (ya sea vandalismo como ediciones válidas o legítimas como vandalismo) y revertir automáticamente una gran cantidad de ediciones (incluidas aquellas que estaban tratando de corregir el vandalismo incorrectamente clasificado), 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 los bots fueran probados y demostraran que no son susceptibles a este tipo de errores. Ecthelion83 ( discusión ) 06:24, 7 de enero de 2008 (UTC) [ respuesta ]
    ¿Leíste mi respuesta para oponerme al punto 3 justo encima de tu comentario? Específicamente sobre hacer cosas en paralelo. - Cobi ( t | c | b ) 06:46, 7 de enero de 2008 (UTC) [ respuesta ]
    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 podía hacer todas estas ediciones/reversiones en conjunto o simultáneamente, que es lo que yo estoy asumiendo ; Su comentario al que se hace referencia no aborda la objeción que me impide apoyar esta idea. Básicamente, lo que estás diciendo en ese comentario es que los bots revierten 1 edición al mismo tiempo que les lleva 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 ponerse al día con los vándalos (porque no tendrían ningún problema para hacerlo), sino la posibilidad de que los propios bots puedan estar clasificando erróneamente la información y, por lo tanto, revertir muchas ediciones legítimas a la vez. a un ritmo mucho más rápido de lo que podría corregirse humanamente , o podrían revertir las ediciones de vandalismo que los robots identificaron (incorrectamente) como legítimos. Ecthelion83 ( discusión ) 07:37, 7 de enero de 2008 (UTC) [ respuesta ]
    La tasa de error no cambiaría con respecto a la actual. El único cambio de programación será utilizar la reversión en lugar del método actual. Sr. Z- man 08:23, 7 de enero de 2008 (UTC) [ respuesta ]
    Correcto, pero todavía hay una tasa de error . Poder utilizar la reversión, especialmente cuando un bot (sé que esto no es frecuente) comete un error o una serie de errores relacionados, sigue siendo una reserva que yo y otros seguiremos teniendo. Ecthelion83 ( discusión ) 08:51, 7 de enero de 2008 (UTC) [ respuesta ]
    Entonces, ¿se debería obligar a un robot a utilizar un método más lento y menos eficiente porque no es completamente preciso? ¿Qué pasaría si te 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 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 1 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 el la base de datos está bloqueada). - Cobi ( t | c | b ) 09:18, 7 de enero de 2008 (UTC) [ respuesta ]
    Entonces, ¿puede aclarar: ClueBot actualmente analiza el cambio más reciente, decide que es vandalismo y luego revierte ciegamente todos los cambios inmediatamente anteriores realizados por el mismo editor? ¿O analiza cada cambio realizado por ese editor y decide si cada uno es vandalismo? Tratando de resolver esto... Franamax ( discusión ) 10:06, 7 de enero de 2008 (UTC) [ respuesta ]
    Lo hace. Como cualquier otro script de reversión. Esto se hace para no encerrar un vandalismo sutil. Esto sucede con mucha frecuencia : Vandal edita una página, cambia un número o inserta actos vandálicos muy sutiles que el bot no detecta. Luego, Vandal vuelve a editar la página y hace algo muy radical, y ClueBot se revierte en cuestión de segundos. Si ClueBot revirtiera una edición, entonces alguien diría "Oh, ClueBot ya la revirtió" y no la miraría, asumiendo que está libre de vandalismo. - Cobi ( t | c | b ) 10:17, 7 de enero de 2008 (UTC) [ respuesta ]
    Gracias, eso tiene mucho sentido cuando veo una RVV. Supongo que el revertidor lo ha comprobado correctamente, aunque si veo "ediciones revertidas de 1.2.3.4 a la versión anterior de 1.2.3.4", casi siempre voy a buscar de todos modos. Por supuesto, si estuviera tratando de hacer vandalismo, haría el cambio grande primero y luego el segundo cambio más pequeño. 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 desorden, luego haría un segundo cambio inofensivo y guarda esa versión también. Entonces, en la situación inversa al escenario que usted describe anteriormente, ¿ClueBot detectaría mi primer mal cambio? Franamax ( discusión ) 10:30, 7 de enero de 2008 (UTC) [ respuesta ]
  2. Se trata de una medida técnica que debe decidirse por motivos técnicos. No veo ninguna razón por la que la comunidad deba involucrarse en esto. - Carnildo ( discusión ) 09:32, 7 de enero de 2008 (UTC) [ respuesta ]
  3. Neutral según Carnildo arriba. Dado que esto no agregaría más funcionalidad a los bots, pero simplemente quitará (¿o puede ?) algo de carga a los servidores, se lo dejaría al grupo técnico. Artyom  ( discusión  •  contribuciones ) 14:26, 7 de enero de 2008 (UTC) [ respuesta ]
Neutral ; fuertemente inclinado hacia oponerse . Reconsideraría si fuera posible proporcionar un resumen de edición no estándar (el robot no debería simplemente decir "No me gustan tus feas ediciones"), codificado en URL o PUBLICADO en la solicitud. Pero no lo es. Миша 13 22:39, 7 de enero de 2008 (UTC) [ respuesta ]
  1. De hecho, el resumen de reversión predeterminado se puede cambiar caso por caso. Si alguien toma la URL de reversión y agrega &summary= seguido del resumen de edición, se utiliza en lugar del resumen de edición de reversión predeterminado. Y, por supuesto, ClueBot aprovechará al máximo esta capacidad, como he dicho antes en esta sección. Gracias. - Cobi ( t | c | b ) 23:32, 7 de enero de 2008 (UTC) [ respuesta ]
    Es bueno saberlo: una característica realmente oscura. Cambiando a soporte. Миша 13 11:26, 8 de enero de 2008 (UTC) [ respuesta ]
En caso de que esta horrible idea se lleve a cabo, ¿quién está a cargo de ClueBot y será responsable de cualquier error/fallo accidental que PUEDA ocurrir después de que los bots estén radicalmente empoderados? ¡¡¡Solo solicito referencias futuras?!!! Smith Jones ( discusión ) 03:33, 8 de enero de 2008 (UTC) [ respuesta ]
Cobi está a cargo de ClueBot. Pero estos robots ya están funcionando, Wikipedia no ha implosionado y no se han vuelto inteligentes ni han impulsado un punto de vista. Esto simplemente está cambiando el método técnico utilizado para revertir el vandalismo, no las razones por las que lo revierte. Sr. Z- man 03:50, 8 de enero de 2008 (UTC) [ respuesta ]
gracias por aclararme eso. Es tan sorprendente obtener una respuesta sobre ella en lugar de que le pidan que lea mil páginas de texto en bloque. Smith Jones ( discusión ) 03:54, 8 de enero de 2008 (UTC) [ respuesta ]

Discusión (robots)

Preocupaciones de seguridad

La otra cosa realmente importante que olvidé mencionar: si los bots tienen reversión, corren potencialmente un mayor riesgo de ser atacados por "teh hax0rs" debido al poder literalmente asombroso de la reversión masiva. Es probable que la mayoría de las contraseñas de los bots estén almacenadas en texto sin cifrar, potencialmente legibles en todo el mundo y en un servidor compartido. Es sólo cuestión de tiempo antes de que alguien aproveche esto, especialmente si los robots cuentan con capacidades de edición mejoradas, como la reversión. Posiblemente estoy siendo demasiado paranoico con esto, pero da igual. :P -- slakr \  talk  / 09:29, 7 de enero de 2008 (UTC) [ respuesta ]

cobi@Abscisa:~/wikibots$ ls -aslh Cluebot/cluebot.config.php4.0K -rw------- 1 usuarios de cobi g 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 dueño del servidor y algunos de mis amigos tienen una cuenta. La contraseña se almacena en texto sin cifrar en el disco, pero no existe una forma efectiva de evitarlo. No se puede aplicar hash porque ClueBot no podría enviarlo a Wikipedia. Cifrarlo 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 decodificarlo para enviarlo a Wikipedia. Además, la reversión no es un "poder literalmente asombroso de reversión masiva". Ese es el defecto en el resto de esta página. La reversión es simplemente una forma mejor y más rápida de revertir un artículo con menos posibilidades de error. ¿Qué tal 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 los bots. Preguntar aquí si se debe dar reversión a los bots no es productivo y genera preocupaciones sobre Skynet o el cortador de césped, y otras preocupaciones que no se basan en la realidad de lo que realmente son los bots. El hecho es que cualquiera que entienda cómo los bots 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 usando más recursos del servidor. Encuestar 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) [ respuesta ]
Esto se está volviendo una tontería. Estoy dispuesto a apostar un centavo brillante a que los tres AVB actuales se ejecutan en sistemas considerablemente más seguros que la inmensa mayoría de las cuentas de administrador, que tienen poderes increíbles para eliminar, bloquear, etc. Simplemente no entiendo por qué Hago 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 en todo el mundo" o que los servidores compartidos son inherentemente menos seguros que, por ejemplo, una cuenta de administrador, raya en insultar a cualquier escritor de bots. Si la seguridad es realmente una preocupación tan grande, hable 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. BAG debería encargarse de esto o escucharíamos un argumento ad metum tras otro. Justin chat 05:53, 8 de enero de 2008 (UTC) [ respuesta ]
En lugar de descartar las preocupaciones como si fueran tontas sembradoras de miedo y hablar de personas que simplemente no entienden, podría ser una mejor estrategia abordar con paciencia y cortesía las cuestiones planteadas, sin importar cuán triviales y repetitivas sean. Nunca se sabe cuándo podría ser una persona de TI de primera línea haciendo preguntas tontas tratando de comprender la situación; descartar las cosas que lo impacientan podría alejar a las personas que podrían convertirse en sus mejores partidarios y ciertamente no calmará al personas con el ceño realmente fruncido. Una de las principales preocupaciones que he visto en WP entre los bots y sus defensores es su nivel de habilidades de comunicación. ¿Podrías reformular esa publicación para expresar el mismo punto válido de una manera menos desdeñosa? Al fin y al cabo, todos perseguimos el mismo objetivo: una mejor enciclopedia. Franamax ( discusión ) 07:31, 8 de enero de 2008 (UTC) [ respuesta ]
Las preocupaciones de seguridad planteadas provienen de la paranoia. No puedo hablar por CVB , VoABot II o MartinBot , pero puedo hablar por ClueBot . ClueBot se ejecuta en los servidores de ClueNet, específicamente en Abscissa.ClueNet.Org, un servidor administrado por mí. Los dos principales administradores 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. Solo yo puedo leer el archivo de configuración privado de ClueBot (que contiene las contraseñas). Abscissa.ClueNet.Org no es un servidor muy público. Sólo las personas que han sido verificadas y aprobadas por uno de los dos principales administradores 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 en el bot como en los servidores WMF. Puede ser revertido por cualquier usuario con privilegios de edición (es decir, cualquiera que no esté bloqueado). Estoy de acuerdo con algunos de los demás en que esto debería ser manejado por BAG , pero los desarrolladores querían el consenso de la comunidad, así que aquí está. No tengo ninguna duda 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 tus preocupaciones. Gracias. - Cobi ( t | c | b ) 08:03, 8 de enero de 2008 (UTC) [ respuesta ]
ClueBot se ejecuta en los servidores de ClueNet, específicamente, Abscissa.ClueNet.Org . Ahora mira, de ahí viene mi paranoia: personas que literalmente piden ser hackeadas/dDOS publicando imprudentemente información de IP del servidor público. 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 saber de lo que estoy hablando cuando se trata de cosas como esta. No soy miembro de BAG (ni necesito serlo) para comprender que existen cuestiones fundamentales de seguridad cuando se trata de bots que se ejecutan en uno de los sitios más visibles y con mayor tráfico de Internet. Esta debería ser una discusión racional sobre los pros y los contras de dotar a los robots de una capacidad poderosa, no un foro para llamar a la gente paranoica simplemente porque expresan opiniones disidentes; y, le aseguro, la seguridad no es algo por lo que debamos ser presumidos, demasiado confiados, condescendientes o desdeñosos, independientemente del tamaño de un sitio o empresa.
Dicho esto, una comprobación de la realidad: ¿es probable que los bots sean pirateados? Probablemente no, al menos mientras la gente no ande publicando sus IP públicas. ¿Qué pasa si son pirateados? Un dolor de cabeza debido a la naturaleza no limitada de la reversión tal como está implementada actualmente en Mediawiki. Y sería ideal si la gente abandonara el hábito de llamar "infundir miedo" a la paranoia bien intencionada y bien fundada. Si prefiere que yo y otros no intentemos frenar el pensamiento grupal cuando se trata de decisiones que potencialmente afectan la seguridad de la comunidad, entonces estaré encantado de hacerlo, ya que siempre hay una considerable acumulación de otras cosas, ambas aquí. y en la vida real, eso estaré feliz de hacerlo. -- slakr \  talk  / 09:24, 8 de enero de 2008 (UTC) [ respuesta ]
Exactamente mi punto, en el primer párrafo lo hiciste parecer inevitable. Ahora "probablemente no es probable". Y la razón por la que fui un poco mordaz fue porque la página de usuario de Slackr indica que tiene conocimiento más que suficiente sobre las complejidades de la programación para no hacer afirmaciones descabelladas sobre el "inevitable" robot pirateado. Y la paranoia puede tener buenas intenciones, pero inventar los peores escenarios e insinuar que son inevitables no está bien fundamentado. Esto cae bajo la jurisdicción de exceso. Y sólo lo empeoras al dar a entender que dar información del servidor público es algo tan terrible. Entonces, hagamos algunos contrapuntos a su argumento:
(A) Una dirección IP no es "privada" de ninguna manera. Personalmente, no daría una IP a menos que hubiera una buena razón para hacerlo, pero eso en sí mismo no es ni remotamente un "preocupación de seguridad".
(B) un DDoS, en caso de ocurrir, no haría más que ralentizar (o potencialmente hacer que ClueBot detuviera) la edición. Usar eso como una "preocupación de seguridad" en relación con Wikipedia es absolutamente absurdo.
La opinión disidente es "algo bueno". Es por eso que aquellos que se han opuesto por una variedad de razones ni siquiera fueron reprendidos por su oposición. La falta de comprensión sobre el concepto de bots es esperable y natural. La gente teme a los procesos que se ejecutan "automáticamente". Dicho esto, alguien que afirme que él o ella es al menos competente (si no un profesional) no recibirá la misma consideración. Si quieres defender las preocupaciones de seguridad, eso es GENIAL... serás mi nuevo mejor amigo. Pero defenderlos mediante tácticas de miedo y el uso de palabras que realmente no se aplican (léase DDoS) va a DAÑAR el proceso más que ayudarlo. Chat de Justin 17:01, 8 de enero de 2008 (UTC) [ respuesta ]
Cobi, mientras defiendes la seguridad de tu bot, ya has revelado al menos tres rutas de ataque además de tu vulnerabilidad a la ingeniería social. Demuestre la seguridad del archivo específico que ha enumerado anteriormente mostrándonos el contenido de /etc/passwd y ls -al ~/wikibots - o mejor aún, ¿puede iniciar sesión y ejecutar un rápido "rm -r ../*"? y publicar la salida? Lo que pasa con 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 en nombre de tu robot, pero también mencionando los nombres de tus amigos, mientras los otros robots antivandálicos beben tranquilamente una cerveza en su mesa. Me referiré a mi publicación anterior; es mucho mejor simplemente explicarnos pacientemente a los idiotas por qué estamos equivocados, no es necesario que nos digas que somos idiotas, ya sabemos que lo somos, es por eso que ganamos tanto dinero. , porque preguntamos por todo. Refréscate y llegarás más lejos. :) Franamax ( charla ) 13:12, 8 de enero de 2008 (UTC) [ respuesta ]
La principal preocupación aquí parece ser la privacidad de la contraseña de texto sin formato almacenada en el archivo. Debido a que el archivo no es legible en todo el mundo, solo hay 3 posibles categorías de ataque. Una cuenta raíz 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 de forma estable y se actualiza periódicamente. Esto minimiza en gran medida cualquier posibilidad de que la cuenta raíz o la cuenta de usuario sean "pirateadas". En este caso, sólo 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 incluir /etc/passwd, eso no serviría de nada, ya que está asumiendo que el PAM del sistema está usando una configuración predeterminada, lo cual no es así. En realidad, la autenticación de la cuenta se realiza mediante 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 su pregunta sobre "rm -rf", o cuál es el cwd en el que desea que se ejecute. Si se ejecuta desde el directorio de inicio, solo eliminará el directorio de inicio de ese usuario y no se divulgará ninguna información privilegiada. Si la preocupación es sobre las contraseñas de administrador no cifradas en general, probablemente haya preocupaciones mayores en el mismo sentido. ¿Cuántos administradores tienen navegadores que almacenan contraseñas no cifradas para completarlas automáticamente? Claro, algunos probablemente usen 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 • contribuciones ) 01:07, 9 de enero de 2008 (UTC) [ respuesta ]
- contraseña en texto plano: ¿por qué no está cifrada y desbloqueada cuando se inicia el bot?
- no legible en 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, has sido diseñado socialmente. ¿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-space-minus-arr/space-dot-dot-slash-star" - es un chiste que rima, tal vez solo los empleados de soporte lo entiendan, lo 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 enorme vulnerabilidad social que nunca desaparecerá.
- Podemos seguir y seguir con esto, mi punto original antes era que NO deberíamos discutir la seguridad mediante la exposición de los puntos finos del sexto sitio web más popular del mundo. Y les aseguro que no seré yo quien demuestre el punto sobre las vulnerabilidades, solo me preocupan otras personas interesadas que están observando. No me disgustaría si detuviéramos la discusión técnica ahora :) Franamax ( discusión ) 08:16, 9 de enero de 2008 (UTC) [ respuesta ]
Las cuentas de administrador han sido pirateadas en el pasado. Se enfurecen durante unos minutos, reciben un análisis de emergencia y todo vuelve a la normalidad en una hora. Un bot pirateado haría aún menos trabajo porque solo sería necesario bloquearlo para detenerlo, no necesitaríamos contratar un administrador. Sr. Z- man 03:12, 9 de enero de 2008 (UTC) [ respuesta ]
La preocupación aquí no es la misma que con las cuentas de administrador. Una cuenta de bot tiene esa bandera +bot, por lo que pasa un poco más desapercibida. Se espera que una cuenta de bot realice ediciones de alta velocidad, cuando ustedes que miran la actividad ven la bandera del bot, se relajan un poco, ¿estoy en lo cierto? De todos modos, eso es lo que deduje de mis discusiones anteriores en T_RFBA. Entonces, aquí hay dos escenarios: un inicio de sesión de bot es secuestrado y se vuelve loco con una ola de reversión, bueno, se detectará un poco más tarde de lo habitual para las cuentas pirateadas y se puede revertir, pero, mientras tanto, hay una unos cuantos miles de personas más que intentan reparar el daño ellos mismos y unos cuantos miles de personas más que simplemente intentan agregar cosas, y todos se confunden porque, naturalmente, respetan "Bot" al final del nombre de usuario; y luego existe la posibilidad mucho peor de que un robot pwd comprometido esté 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 estaba listo para cambiar mi !oppose por !support, pero no vi el tipo de respuestas pacientes y tranquilas. desde el lado inferior que hubiera esperado. Por supuesto, no cuento para nada en el gran esquema :) ¡Salud! :) Franamax ( charla ) 08:38, 9 de enero de 2008 (UTC) [ respuesta ]
No creo que los robots antivandalismo estén marcados, por lo que sus ediciones aparecerán en los cambios recientes y en las 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 debido a la posibilidad de ofender al usuario bloqueado en el caso de un error innecesario. el bloque se minimiza. Sr. Z- man 20:47, 9 de enero de 2008 (UTC) [ respuesta ]
Veo la relevancia de que el procedimiento de reversión tenga un proceso de aprobación separado para los bots y para los usuarios, ya que si uno no es aprobado, el otro aún podría serlo. ¿Pero toda esta charla de que los bots son pirateados o se vuelven locos? No es que alguien tenga un control remoto mágico que pueda hacer que todos los robots rompan Wikipedia. Otorgar esta característica a los bots no los hace más "poderosos" o propensos a fallar. Cualquier discusión adicional de esa naturaleza debe tener lugar en otra parte; distrae la atención del tema relevante. Coreycubed ( charla ) 16:56, 8 de enero de 2008 (UTC) [ respuesta ]
Ummm: parecería que la reversión del bot se solicita aquí como una parte relacionada pero separada de la función de reversión para 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 robots obtienen un pase especial para hacer cosas y tienen un cierto visto bueno cuando los vemos realizar ediciones, así que sí, deberían recibir un escrutinio adicional. El argumento para otorgar reversión a los bots se basa en una mayor eficiencia, ya sea 66% o 10:1 según mi lectura. Hay dos formas de verlo: se nos pide que concedamos un derecho para ahorrar entre el 33% y el 90% de... ¿qué? No se ha presentado ningún caso sobre cuántos servidores menos necesitará WMF; y ahora existe el argumento concebible de que una mayor eficiencia permitirá que el robot funcione entre tres y diez veces más rápido; entonces, ¿no aumenta también al mismo ritmo el potencial de daño? En cualquier caso, la discusión sobre los bots está en su propio rincón y la seguridad está aún más eliminada, dudo que estemos distrayendo a nadie más que a nosotros mismos :) Franamax ( discusión ) 09:06, 9 de enero de 2008 (UTC) [ respuesta ]
El número de páginas que se "dañarán" sería mayor (simplemente se revierte, por lo que la página siempre se editará a alguna versión de su historial reciente), pero la tasa de error debería seguir siendo la misma y es menor que la tasa de error. para la mayoría de los usuarios que realizan la misma tarea. Sr. Z- man 20:47, 9 de enero de 2008 (UTC) [ respuesta ]

Pregunta del administrador, movida

¿Por qué son los administradores los encargados de otorgar los derechos? —Comentario anterior sin firmar agregado por Hiding ( charla • contribuciones ) 00:31, 9 de enero de 2008 (UTC)[ responder ]
Porque son administradores . Snowfire51 ( discusión ) 00:45, 9 de enero de 2008 (UTC) [ respuesta ]
Qué redundante. Al menos tenemos una respuesta que podemos agregar a las preguntas frecuentes. Ocultar T 02:15, 9 de enero de 2008 (UTC) [ respuesta ]
A los administradores se les ha confiado (o se les habría confiado) la concesión de derechos de reversión porque han demostrado que se les puede confiar ese poder durante su estancia 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 constructivamente" o crear artículos autobiográficos llenos de spam y material protegido por 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 alegrarse de que esta propuesta fuera rechazada, solo podría haber aumentado su ya larga lista de problemas. Phoenix - wiki 22:05, 9 de enero de 2008 (UTC) [ respuesta ]
Espero que nunca me pidan que sea administrador. ¡Ya tengo suficientes problemas para ser quien soy! Igor Berger ( discusión ) 09:14, 10 de enero de 2008 (UTC) [ respuesta ]
Nadie está obligado a ser administrador. Si cree que no quiere ser administrador, simplemente rechácelo si alguna vez lo nominan. Nil Einne ( discusión ) 18:12, 11 de enero de 2008 (UTC) [ respuesta ]
  • Aunque la intención era ser un poco humorística, es mucho más fácil confiar en los administradores con cosas como esta que en los no administradores. - Phoenix - wiki 20:04, 10 de enero de 2008 (UTC) [ respuesta ]
  • Además, según esto :
  • Los administradores de Wikipedia son miembros confiables de la comunidad y se espera que sigan 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 un juicio deficiente constante puede resultar en una nueva solicitud de administración a través del procedimiento de solicitud de administración o 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 presentar la solicitud.
  • 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 interrupciones en el sitio de Wikipedia y 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) [ respuesta ]
Quizás (a lo anterior), excepto que si su postulación fuera cierta, no habría burócratas y sus habilidades 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é otorga un derecho de usuario. Me parecería una obviedad, pero supongo que a veces presumo demasiado ... - jc37 04:21, 11 de enero de 2008 (UTC) [ respuesta ]
Esta es una discusión inútil: se confía en que los administradores hagan esto ahora, así que sigamos adelante y editemos en algún lugar útil :-)-- Phoenix - wiki 22:17, 11 de enero de 2008 (UTC) [ respuesta ]
Ah, ya veo, toda la charla sobre probarlo y resolver problemas y tal vez tener una idea mejor fue solo franela. Gracias. Aquellos de nosotros que sentimos que estaba más en línea con nuestros principios, tradiciones, propósito y naturaleza que este premio fuera otorgado a través de medios tecnológicos en lugar de humanos, con la herramienta de bloqueo utilizada en caso de disrupción, deberíamos simplemente aceptar el hecho de que estábamos Nunca se dio tiempo para proponer y discutir esa opción. Gracias a Dios el consenso no puede cambiar. Escondiéndose T 20:36, 13 de enero de 2008 (UTC) [ respuesta ]
La discusión anterior está cerrada. Por favor no lo modifique. Los comentarios posteriores deben realizarse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.