Hola, he venido aquí porque ese SPI en particular probablemente no sea el mejor lugar para discutir cuestiones generales sobre datos cu; es mejor mantener el archivo ordenado.
La respuesta corta es que no hay manera de que las personas que no son miembros de una cooperativa de crédito sepan cuántos datos históricos están disponibles, si es que hay alguno. Ni siquiera los administradores y los empleados de SPI pueden verlos; se necesita la bandera de la cooperativa de crédito para tener acceso a los lugares donde están visibles. No entraré en demasiados detalles sobre los tipos de información que están disponibles, pero en términos generales casi siempre hay alguna información disponible sobre las cuentas que se han verificado en el pasado.
Si tienes sospechas sobre una cuenta, te insto a que no tengas en cuenta la probabilidad de que las cuentas antiguas estén obsoletas a la hora de tomar la decisión de denunciarla o no. Si tienes pruebas de comportamiento, denúncialas. Necesitaríamos esas pruebas de todos modos para justificar una comprobación si los datos están disponibles y, si no lo están, las pruebas de comportamiento pueden ser lo suficientemente sólidas como para bloquear una cuenta sin necesidad de un control de cuentas. Espero que te sea de ayuda. Girth Summit (blather) 13:48, 8 de noviembre de 2024 (UTC) [ responder ]
- Gracias, sí, es muy útil. Sean.hoyland (discusión) 14:27 8 nov 2024 (UTC) [ responder ]
- ¿Podemos convertir a Sean en administrador para que pueda explorar mejor las cosas de CU? BilledMammal ( discusión ) 14:58 8 nov 2024 (UTC) [ responder ]
- @BilledMammal: - Sean puede solicitar la administración de la manera habitual (o supongo que debería decir de una de las maneras habituales, ahora que estamos en la era de las elecciones de administradores), si está interesado, por supuesto. Sin embargo, como dije, los administradores tampoco pueden ver nada de esto a menos que tengan la información de CU. La forma más rápida para que alguien obtenga eso ahora mismo probablemente sería ser elegido para Arbcom, la lista de candidatos es bastante corta en este momento...
- @ Sean.hoyland : - como una reflexión posterior, me gustaría añadir que se me ocurrió la posibilidad de que tuvieran varias cuentas en paralelo. Siempre las busco, pero miré con más cuidado del que podría haber hecho de otra manera, a la luz de los casos anteriores. Todo lo que puedo decir es que parte de su edición (pero no la mayoría) proviene de una dirección IP compartida, y hay algunas otras cuentas en esa IP, cualquiera de las cuales podría ser la suya, pero en base a una combinación de observaciones técnicas y de comportamiento, creo que es poco probable. Ciertamente, ninguno de ellos está interesado en ninguno de los mismos temas, ninguno de ellos se involucra en discusiones o artículos en los que participan los demás, y me parece que todos están usando inocentemente una conexión a Internet institucional a la que tienen acceso varias personas. La mayor parte de su edición proviene de IP privadas, que no tienen ningún otro tráfico en ellas. Ahora bien, no hay forma de que CU pueda detectar a alguien que usa varias cuentas si tienen cuidado de usar diferentes dispositivos y conexiones a Internet para cada una; Todo lo que puedo decir es que, si lo están haciendo, ahora están siendo mucho más cuidadosos que en el pasado. Girth Summit (blather) 15:27, 8 de noviembre de 2024 (UTC) [ responder ]
- La forma en que lo veo es que si estoy dispuesto a renunciar al anonimato, debería tener acceso a la información privada que actualmente está censurada de las bases de datos de las otras 48 millones de cuentas. Puede que haya una falla en esta lógica, pero no la veo. Gracias por los detalles adicionales, es interesante. Sean.hoyland (discusión) 15:46 8 nov 2024 (UTC) [ responder ]
- ¡Yo también! Lamentablemente, no es un acceso sin restricciones. Cada vez que realizo una verificación en una cuenta o una IP, esa acción queda registrada de forma permanente y otras UC pueden ver lo que estoy haciendo. Incluso auditan mi actividad (¡qué descaro!). Si realizo verificaciones inapropiadas, algún molesto defensor o árbitro aparecerá y me quitará mis elegantes permisos. ¡Es tan irrazonable! Girth Summit (blather) 22:45, 8 de noviembre de 2024 (UTC) [ responder ]
Intersecciones de páginas
..que hace lo mismo que
- https://sigma.toolforge.org/editorinteract.py
pero también te da la cantidad de páginas que habéis editado en común. ¿Existe eso? (Solo estoy buscando una forma sencilla de saber cuántas páginas tenemos en común Icewhiz y yo ) Huldra ( discusión ) 23:18 16 nov 2024 (UTC) [ responder ]
- No que yo sepa, y no estoy seguro de la precisión de los recuentos de ediciones producidos por editorinteract.py. Por ejemplo, mira tú contra Galamore para 1929 Hebron massacre . Dice tú=2, Galamore=1. Pero hiciste 5 ediciones a ese artículo, y debería saberlo porque el enlace a sigma timeline.py lo dice, al igual que sigma usersearch.py.
- De todos modos, si simplemente buscas algo rápido para ver la cantidad de páginas en común, puedes hacer algo como lo siguiente.
seleccionar convertir ( reemplazar ( p . page_title , '_' , ' ' ) usando utf8mb4 ) page_title , p . page_namespace , p . page_is_redirect , p2 . rev_count 'Huldra+Icewhiz rev_count' de la página p unir ( seleccionar ru . rev_page , count ( ru . rev_id ) como rev_count de revision_userindex ru unir actor_revision ar en ar . actor_id = ru . rev_actor donde ar . actor_name en ( 'Huldra' , 'Icewhiz' ) agrupar por ru . rev_page que tiene count ( distinct ar . actor_id ) = 2 ) p2 en p2 . rev_page = p . page_id ordenar por 1 , 2 , 3
- Puedes usar Quarry - ver aquí -> Conjunto de resultados (598 filas) Sean.hoyland (discusión) 05:50, 17 de noviembre de 2024 (UTC) [ responder ]
- Para la editora Huldra : Introduce "enwiki_p" en el pequeño cuadro de la izquierda sobre la tabla, copia el código en el área negra y pulsa "Enviar consulta". Obviamente soy más malvado que tú porque tengo 639 filas en común con Icewhiz. Pero tú y yo tenemos 2719 en común. Zero talk 12:49, 17 de noviembre de 2024 (UTC) [ responder ]
- Estrictamente hablando, para las intersecciones con Icewhiz, necesitarías combinar los resultados de 48 cuentas, pero sigo postergando la idea de la información sobre intersecciones de artículos porque es otra madriguera de conejo. Sería bueno poder cuantificar la probabilidad de intersecciones.
- ['007Леони́д', '11Fox11', 'AnnieGrannyBunny', 'Astral Leap', 'AstuteRed', 'Bob no esnob', 'DoraExp', 'Pistola de dos cañones con ambas direcciones opuestas', 'EnfantDeLaVille', 'Eostrix', 'Free1Soul', 'Galamore', 'Geshem Bracha', 'Herpetogenesis', 'Hippeus', 'Sueño con Maple', 'Icewhiz', 'Jacinda01', 'JoeZ451', 'Just Prancing', 'KasiaNhersL', 'LeftDreams', 'ManoelWild', 'Minden500', 'Molave Quinta', 'Mrboondocks', 'Mvqr', 'O.maximov', 'OdNahlawi', 'PeleYoetz', 'Pikavoom', 'PRL Dreams', 'Proud Indian Arnab', 'Purski', 'RCatesby', 'SCNBAH', 'Seggallion', 'Semper honestus', 'Smoking Ethel', 'SunSun753457', 'Świst lodu', 'Szymon Frank', 'La segunda venida de Purski', 'UnspokenPassion', 'Uppagus', 'VikingDrummer', 'WhizICE', 'Терпение не ненавижу']
- Sean.hoyland (discusión) 13:10 17 nov 2024 (UTC) [ responder ]
- Ok, gracias, Sean, te lo agradezco mucho. Obviamente, tanto Zero como yo hemos estado conspirando con Icewhiz fuera de línea.
- Sin embargo, no estoy segura de confiar en esas cifras tampoco; ¿por qué algunos artículos se mencionan una vez y otros dos? Por ejemplo, la deportación de Jaffa en 1917 se menciona dos veces, mientras que la masacre de Hebrón en 1929 se menciona una vez. Saludos, Huldra ( discusión ) 20:41 17 nov 2024 (UTC) [ responder ]
- @ Huldra : Esto se debe a que los diferentes espacios de nombres se enumeran por separado (consulte la columna page_namespace). 0=artículo, 1=discusión, 2=usuario, 3=discusión de usuario, 4=WP, 5=WT, 10=plantilla, 11=discusión de plantilla, etc. Por lo tanto, los recuentos son de "páginas", no de "artículos". Zero talk 00:08, 18 de noviembre de 2024 (UTC) [ responder ]
- Huldra+11Fox11=153, Huldra+Galamore=98, Huldra+Geshem Bracha=100, Huldra+PeleYoetz=88, Huldra+Pikavoom=325(!), etc., pero hay superposiciones de páginas, por lo que no es correcto sumar estos números. Sean, ¿cómo probar esta lista de calcetines de una sola vez? Zero talk 02:13, 18 de noviembre de 2024 (UTC) [ responder ]
- Huldra, si prefieres los números de espacio de nombres como descripciones, puedes traducirlos así. Zero0000, no haría eso con SQL. Es más fácil manejar los datos usando Pandas o Polars. Le echaré un vistazo un poco más tarde. Es una pregunta que he estado evitando o dejando macerar durante meses por varias razones, por ejemplo, no me queda claro cómo extraer información útil, algo así como la importancia de una intersección, de las intersecciones de artículos. Para empezar, no sé cómo se ven las estadísticas de intersección para un gran conjunto de usuarios aleatorios con varias edades de cuenta, recuentos de ediciones, intereses, etc., las estadísticas de fondo, entonces, ¿cómo puedo saber si algo es significativo o no? Parece posible, al menos en principio, escribir una función que calcule la improbabilidad de una intersección en función de los recuentos de revisiones de página, los recuentos de editores únicos de página, los recuentos de ediciones del editor, la antigüedad de la cuenta y varias otras cosas que aún no he descubierto. Sean.hoyland (discusión) 04:41 18 nov 2024 (UTC) [ responder ]
- Huldra , lamentablemente, las pruebas sugieren que el alcance de tu conspiración con Icewhiz y sus calcetines es aún más preocupante, ya que abarca 1438 páginas, una cifra que, al parecer, es "extraordinariamente alta". Aquí hay 3 hojas de cálculo de Google.
- A. df_page_intersect: enumera los recuentos de ediciones de las intersecciones de páginas entre usted y cada una de las cuentas de Icewhiz.
- B. df_page_intersect_sum: igual que A pero con los recuentos de ediciones de Icewhiz+socks sumados.
- C. df_page_intersect_sock_sum_pivot: versión pivotada de B
- Zero, veré si hay una manera de hacer esto usando solo SQL que no sea terriblemente feo. Sean.hoyland (discusión) 10:40 18 nov 2024 (UTC) [ responder ]
- ¡1438 páginas! Estoy agarrando mis perlas, ¡esperando que nadie se entere! (Pensé en subir una foto mía, agarrando mis perlas, pero desafortunadamente mi teléfono Android no se comunica fácilmente con mi Mac). Afortunadamente, esas hojas de cálculo de Google a las que haces referencia son una prueba del trabajo de Selfstudier con Icewhiz, no mío. Saludos, Huldra ( discusión ) 22:08, 18 de noviembre de 2024 (UTC) [ responder ]
- Estaba pensando en seleccionar páginas con cualquiera de ('Huldra', 'Icewhiz', 'sock', ...), y luego seleccionar páginas con Huldra y distintas contar al menos 2. Pero no logré que funcionara. El propósito es disipar la idea de que tales intersecciones de páginas prueban algo más que intereses similares, y estoy de acuerdo en que es probablemente difícil o imposible encontrar una medida objetiva de cuán significativo es un número. Una medida más directa de trabajar juntos podría ser contar cuántas veces A restauró una edición de B que había sido revertida y viceversa. Pero eso parece complicado y difícil de calibrar. Zero talk 11:02, 18 de noviembre de 2024 (UTC) [ responder ]
- Para mí, el interés en las intersecciones es anterior a cosas como el disparate de Piratewires. Proviene de dos opuestos: 1) un caso de SPI hace años en el que una intersección altamente improbable jugó un papel exitoso, y 2) un caso de SPI en el que se rechazó una solicitud de checkuser porque se consideró que la gran cantidad de intersecciones no eran convincentes. El editor había realizado muchas ediciones y muchas de las páginas eran páginas de alto tráfico a pesar de muchas superposiciones improbables en páginas con pocas visitas a la página, recuentos de revisiones, etc. Parece una pista de que en algún lugar entre esos 2 resultados hay una mejor manera de extraer, integrar y presentar evidencia de intersección de páginas. En cuanto al SQL, incluso obtener todos los calcetines de una cuenta es complicado porque los gráficos de categorías para los maestros de calcetines casi siempre están incompletos, por ejemplo, las categorías solo obtienen 39 de las cuentas de calcetines de Icewhiz. Sean.hoyland (discusión) 12:54, 18 de noviembre de 2024 (UTC) [ responder ]
- ¿Cómo puedo saber el alcance de mi conspiración con Icewhiz y sus calcetines? :) Selfstudier ( discusión ) 10:48 18 nov 2024 (UTC) [ responder ]
- Al editor Selfstudier : Buen intento, todos sabemos que eres Icewhiz . Cero comentarios 11:04, 18 de noviembre de 2024 (UTC) [ responder ]
- Bueno, el primer paso probablemente sea arreglar la parte en la que olvidé agregar los nombres de usuario a la salida para que puedas saber quién se compara con quién (¿con quién?). Sean.hoyland (discusión) 11:07 18 nov 2024 (UTC) [ responder ]
- Paso dos, los resultados ya están ahí. Solo 542 páginas, una "increíble abundancia", obviamente, pero no "extraordinariamente alta"... probablemente. Sean.hoyland (discusión) 11:27 18 nov 2024 (UTC) [ responder ]
- Algunos recuerdos, gracias. Selfstudier ( discusión ) 11:32 18 nov 2024 (UTC) [ responder ]
<- Zero0000 , aquí hay 2 versiones de SQL que producen resultados de intersección pivoteada.
- La versión A hace trampas codificando las 48 cuentas de Icewhiz. Es rápida (9 s), pero creo que faltan algunos resultados y aún no sé por qué.
- La versión B lo hace correctamente seleccionando todas las cuentas. Parece producir un conjunto completo de resultados, pero es lento (650 s), aunque la parte de selección de calcetines está bien... buscar comentarios de bloques siempre lleva un tiempo. Supongo que algo en la estructura está haciendo que el servidor use un plan de ejecución ineficiente. No estoy seguro de qué hacer al respecto. Sean.hoyland (discusión) 18:19 18 nov 2024 (UTC) [ responder ]
- Estoy leyendo el artículo de SQL para entender lo que están haciendo. Desafortunadamente, parece un artículo científico típico de Wikipedia: difícil para cualquiera que no sepa de qué se trata. (Pero presumiblemente bastante claro para aquellos que ya conocen SQL;/), bueno, Huldra ( discusión ) 22:16 18 nov 2024 (UTC) [ responder ]
- SQL fue diseñado por un demonio malvado. Por cierto, Piotrus obtiene una puntuación de 1942, más malvado que cualquiera de nosotros. Zero talk 01:56, 19 de noviembre de 2024 (UTC) [ responder ]
- Aquí es donde todo ese material aparentemente inútil de la escuela sobre diagramas de Venn y símbolos de conjuntos finalmente tiene la oportunidad de ser útil. SQL simplemente construye conjuntos de cosas y luego las conecta como si hicieras tus propios ladrillos de Lego y construyeras algo. Pero esta es un área en la que los LLM como Claude y ChatGPT realmente brillan porque han analizado millones de líneas de SQL. Casi nunca documento ningún código que escribo en ningún lenguaje porque no soy ingeniero de software. Es aburrido. Y tengo "la eterna luz del sol de una mente sin recuerdos" cuando se trata del código que escribo. Una semana es tiempo suficiente para que me olvide por completo de casi todo sobre un fragmento de código y piense "¿quién escribió esta basura?". Ahora puedes subcontratar la explicación/documentación a las IA. Son muy buenas en eso, mucho mejor que su capacidad para escribir código. Intenta poner el SQL en Claude, por ejemplo, y pídele que lo explique. Sean.hoyland (discusión) 05:13, 19 de noviembre de 2024 (UTC) [ responder ]
Zero0000 , Huldra , he puesto una consulta bastante genérica en Quarry.
- Versión C: puede simplemente especificar un nombre de cuenta de referencia y una lista separada por comas de una o más cuentas para compararlo.
Sean.hoyland (discusión) 16:02 19 nov 2024 (UTC) [ responder ]
- Sean.hoyland : muchas gracias, Huldra ( discusión ) 21:06 19 nov 2024 (UTC) [ responder ]
El rendimiento lento del servidor para una consulta en la que solo se necesita especificar el sockmaster en lugar de codificar de forma tediosa la lista de calcetines era demasiado molesto para mí como para dejarlo pasar. He añadido otra versión que parece persuadir al servidor para que utilice un plan decente, por ejemplo, 120 frente a 650.
- versión D - 'Intersecciones de página entre un actor de referencia y una fuente de evasión de prohibición y sus calcetines' - solo es necesario especificar el actor de referencia, por ejemplo, Huldra y el maestro de calcetines, por ejemplo, Icewhiz.
Sean.hoyland (discusión) 11:23 20 nov 2024 (UTC) [ responder ]
Conteo de revisión
Pongo algunas cosas aquí . ¿Qué opinas de mi forma de adivinar la cantidad de reversiones que no son reversiones de ECR? Otra cosa: la cantidad de revisiones marcadas como "mw-reverted" es significativamente mayor que la cantidad marcada como "mw-undo o mw-rollback". Esto sugiere que la forma en que se detectan las reversiones tiene más casos. ¿Sabes dónde se describe? Zero talk 12:14, 20 de noviembre de 2024 (UTC) [ responder ]
- Echaré un vistazo y me pondré en contacto contigo. Pero en cuanto a la segunda pregunta, el otro día noté por primera vez una etiqueta de reversión manual en mi lista de seguimiento. Supongo que es ctd_name='mw-manual-revert', ctd_id=582. Special:Tags dice que son "Ediciones que restauran manualmente el código fuente de la página a un estado anterior exacto". Se han etiquetado 4 millones de revisiones, así que supongo que esa etiqueta podría explicar algunos de los casos. Sean.hoyland (discusión) 12:36 20 nov 2024 (UTC) [ responder ]
- La suposición de que no es ECR parece que podría ser propensa a errores. Los espacios de nombres PIA 0 y 1 probablemente tengan estadísticas de protección bastante diferentes, especialmente las páginas de alto tráfico (no lo he comprobado). Eso podría arruinar la suposición. Es posible buscar cadenas relacionadas con ECR en los comentarios de revisión, pero es probable que sea lento e incompleto. Podría valer la pena intentarlo. Veo lo que quieres decir sobre las estadísticas de etiquetas. No estoy seguro de qué está pasando allí. Puede que haya una explicación enterrada en alguna parte si empiezas en Wikipedia:Tags . También está 'app-undo' = Undo acciones realizadas desde las aplicaciones móviles. Pero solo hay 26 revisiones con esa etiqueta en los espacios de nombres PIA (0,1) entre 2020-10-07 y 2024-10-06. Sean.hoyland (discusión) 17:40, 20 de noviembre de 2024 (UTC) [ responder ]
- Zero0000 , los recuentos probablemente deberían excluir las revisiones de bots, ¿no es así? Si quieres hacer eso, puedes agregar algo como lo siguiente a la cláusula where o a la unión. Es tentador escribir 'x not in (...)', pero no funcionaría en este caso porque actor_user puede ser nulo (para IP), por lo que un 'not in' omitiría los actores no registrados/no usuarios y sus revisiones.
actor_revision . actor_user en ( seleccionar ug . ug_user de user_groups ug donde ug_group = 'bot' ) no es verdadero
- Del 7 de octubre de 2020 al 6 de octubre de 2021, eso cambiaría el recuento de ediciones de 96687 a 84775, por ejemplo.
- En cuanto al etiquetado misterioso, mirar una página podría ayudar, por ejemplo, la invasión israelí de la Franja de Gaza (desambiguación). El intercambio de ida y vuelta entre bots y humanos en las revisiones recientes es interesante, por ejemplo, esta edición del bot no fue etiquetada, aunque parece que debería tratarse como una reversión.
- 2024-06-09T10:02:38 Bot1058 talk contribuciones m 272 bytes (−296)
- Sean.hoyland (discusión) 07:14 21 nov 2024 (UTC) [ responder ]
- Añadir mw-manual-revert a la definición de "revertir" aumenta el recuento de reversiones de los últimos años. Sin embargo, todavía no llega al recuento de "revertidos". Estoy particularmente interesado en dividir el recuento de "revertidos" según si el actor fue confirmado por extensión en ese momento. Zero talk 11:20, 21 de noviembre de 2024 (UTC) [ responder ]
Etiquetado de revisiones basado en privilegios
- "...si el actor fue confirmado por extensión en ese momento" suena sencillo, pero en la práctica es una de las muchas cosas sobre el sistema wiki que no he descubierto cómo hacer de manera correcta y eficiente. También hay casos extremos y no sé cuántos hay. Su relato es un buen ejemplo de una de las trampas de asumir algo sobre el sistema/consultas basadas en registros. En teoría, puede buscar concesiones confirmadas por extensión y luego usar la función timestampdiff para etiquetar a los actores en función de una comparación de la marca de tiempo de la concesión de CE (o ausencia) con la marca de tiempo de la revisión en segundos. Podrían ser
- Negativo (actores a los que se les concedió la CE después de la revisión)
- null (actores que aún no cuentan con la subvención de la CE)
- Positivo (actores a los que se les concedió la CE antes de la revisión)
- Pero a veces la concesión no está en el registro, por ejemplo, para los sysops en algunos casos, al parecer. Por lo tanto, también puede buscar la concesión de sysop. Sin embargo, si mira su cuenta, la única entrada del registro es de 2022, por lo que una consulta asumiría que es cuando se convirtió en confirmado extendido. No estoy seguro de qué hacer al respecto. Tal vez establezca la fecha de registro como la fecha de EC para esos casos, pero luego debe unirse a la vista de usuario, lo que puede ralentizar las consultas grandes. Luego está todo el problema de la revocación de EC a veces, donde simplemente elegir la más antigua, que generalmente es una concesión de promoción automática, puede no ser la decisión correcta. De todos modos, la conclusión es que es posible etiquetar revisiones en función del estado de los privilegios en ese momento y contarlas, pero el rendimiento de las consultas es un problema sin resolver para mí.
- Publicaré un código de ejemplo más tarde. Estoy un poco ocupado hoy. Sean.hoyland (discusión) 04:36 22 nov 2024 (UTC) [ responder ]
- Es bueno que hayas hecho esta pregunta porque me recordó que debo buscar una forma de evitar mirar los registros. Sean.hoyland (discusión) 07:58, 22 de noviembre de 2024 (UTC) [ responder ]
- Parece que no hay registros de derechos anteriores a diciembre de 2004, pero yo me convertí en administrador del sistema antes de esa fecha. Además, creo que la revocación de la CE es lo suficientemente rara como para que podamos ignorarla. Zero talk 11:19, 22 de noviembre de 2024 (UTC) [ responder ]
<- He aquí un ejemplo para ilustrar algunas cosas.
- El ejemplo se limita a las ventanas '2023-10-07' y '2024-10-06' en PIA para cinco cuentas ('Ainty Painty', 'Pave Paws', '24.130.244.5', 'Canterbury Tail', 'Zero0000'), cada una de las cuales tiene propiedades diferentes.
- La expresión de tabla común grant_timestamp muestra una de las muchas maneras de obtener la marca de tiempo del registro. Utiliza la "vista alternativa" logging_userindex en lugar de la vista de registro para intentar acelerar las cosas. Lamentablemente, no parece que tenga los privilegios necesarios para mirar directamente los privilegios/roles de un usuario, lo que podría ser más rápido que buscar en los registros. Hay una manera de obtener información de concesión sin buscar en los registros, pero extrañamente esa vista no expone las marcas de tiempo.
- La parte de selección incluye líneas de timestampdiff y case para ilustrar el uso de la función y una forma de realizar el etiquetado de revisión booleano basado en privilegios.
- Cada usuario ilustra algo diferente.
- Ainty Painty fue confirmado y ampliado antes de las revisiones, por lo que las etiquetas ec_at_time_of_rev son Verdaderas.
- Pave Paws no es EC por lo que las etiquetas son falsas.
- 24.130.244.5 no es una cuenta registrada, por lo que no hay posibilidad de EC, por eso la etiqueta es Falso.
- Canterbury Tail comenzó sin EC y finalmente se le concedió el privilegio, las etiquetas cambian de Falso a Verdadero en las últimas 3 revisiones.
- Tu relato ilustra el problema que mencioné: la fecha y hora del registro es 2022-07-23. Todavía no estoy seguro de cuál es la mejor manera de solucionar ese problema.
- El rendimiento de la consulta parece correcto, pero es posible que no se escale de manera lineal. Aún no lo he comprobado. Para realizar pruebas, agregar un límite de 10 o algo similar ayudará.
- Supongo que puedes usar una consulta como esta para contar las revisiones, deshacerte de algunas de las columnas y usar agrupar para obtener los recuentos de etiquetas y espacios de nombres.
con pia_titles como ( seleccionar p . page_title de linktarget lt unirse templatelinks tl en tl . tl_target_id = lt . lt_id unirse a la página p en p . page_id = tl . tl_from donde lt . lt_namespace = 10 -- Plantilla y lt . lt_title en ( "ArbCom_Aplicación_árabe-israelí" , "Temas_contenciosos/Aviso_de_discusión_árabe-israelí" ) y page_namespace = 1 y page_is_redirect = 0 unión seleccionar page_title de página unirse categorylinks israel en page_id = israel . cl_from y israel . cl_to = "WikiProject_Israel_articles" unirse categorylinks palestina en page_id = palestina . cl_from y palestina . cl_to = "WikiProject_Palestine_articles" donde page_namespace = 1 y page_is_redirect = 0 ), pia como ( seleccionar p . page_id , p . page_title , p . page_namespace de pia_titles pt unir página p en p . page_title = pt . page_title y p . page_namespace en ( 0 , 1 ) y p . page_is_redirect = 0 ), grant_timestamp como ( seleccionar log_actor , min ( log_timestamp ) log_timestamp de logging_userindex donde log_type = 'rights' y log_params rlike ' ( sysop | extendedconfirmed ) ' agrupar por 1 ) seleccionar área ' PIA ' , ar.actor_id , convertir ( ar.actor_name usando utf8mb4 ) actor_name , gt.log_timestamp ec_timestamp , ru.rev_timestamp , timestampdiff ( segundo , gt.log_timestamp , ru.rev_timestamp ) seconds_ec_to_rev , caso cuando timestampdiff ( segundo , gt.log_timestamp , ru.rev_timestamp ) > 0 entonces Verdadero de lo contrario Falso fin ec_at_time_of_rev , pia.page_namespace de actor_revision como ar unirse revision_userindex ru en ru.rev_actor = ar.actor_id unirse pia en pia.page_id = ru . rev_page left join grant_timestamp gt on gt . log_actor = ar . actor_id donde ar . actor_user en ( select ug . ug_user from user_groups ug donde ug_group = 'bot' ) no es verdadero y la fecha ( ru . rev_timestamp ) entre '2023-10-07' y '2024-10-06' y ar . actor_name en ( 'Ainty Painty' , 'Pave Paws' , '24.130.244.5' , 'Canterbury Tail' , 'Zero0000' ) ordenar por 5 desc
Sean.hoyland (discusión) 11:37 22 nov 2024 (UTC) [ responder ]
El rendimiento parece sorprendentemente bueno, o tal vez tuve suerte. El rendimiento del servidor de la base de datos wiki varía enormemente. 106 segundos para la ventana '2020-10-07' y '2021-10-06' para contar las revisiones de PIA que no son de bots en el servidor de análisis de enwiki desde mi computadora portátil a través de un túnel SSH -> Conjunto de resultados (108808 filas). 258,48 segundos en Quarry, incluidos los datos de las filas, por lo que es mucho tiempo de red. Sean.hoyland (discusión) 13:27, 22 de noviembre de 2024 (UTC) [ responder ]
- ¡Ufff! (Quizás deberías dividir esta discusión en secciones). He descubierto que más de la mitad de las ediciones revertidas en el espacio principal entre el 7 de octubre de 2023 y el 6 de octubre de 2024 fueron realizadas por direcciones IP (sin nombre de usuario) o usuarios que todavía tienen menos de 500 ediciones ahora. Por lo tanto, la fracción será aún mayor si se incluyen aquellos que alcanzaron las 500 después de ser revertidos. Estudiaré tu código.
- Recuento de revisiones de PIA agrupadas para '2020-10-07' y '2021-10-06' excluyendo bots, en 121 segundos, obtengo...
Sean.hoyland (discusión) 13:58 22 nov 2024 (UTC) [ responder ]
La adición de la categoría "Artículos de la colaboración entre Israel y Palestina en WikiProject" aumentó un poco el grupo. Zero talk 02:38, 23 de noviembre de 2024 (UTC) [ responder ]
- Sí, creo que el conjunto de cosas "dentro" del área temática que un grupo de editores de PIA podría construir manualmente, si se le da suficiente tiempo, podría ser mucho mayor que la aproximación que se ha utilizado. Supongo que es posible construir un conjunto diferente a partir del gráfico de categorías a partir de algún lugar, pero nunca he descubierto cómo saber cuándo dejar de seguir los bordes. El conjunto crece bastante rápido y el límite entre el interior y el exterior parece ser bastante irregular y difícil de mapear. Si cambiar la aproximación es una opción, probablemente haya varias cosas que se puedan probar para completar el conjunto. Sean.hoyland (discusión) 03:01 23 nov 2024 (UTC) [ responder ]
Hacer la lista de bots solo una vez me ahorró unos 10 segundos (pero los tiempos varían tanto para el mismo script que es difícil estar seguro). Zero talk
Estoy pensando en la siguiente prueba para EC: un editor no era EC en el momento de una edición si al menos una de estas es verdadera: (1) actor.actor_user es NULL, (2) fecha de registro - fecha de edición < 30 días, (3) recuento de ediciones ahora < 500, (4) hay una concesión confirmada extendida en el registro posterior a la fecha de edición. Eso manejaría a personas como yo correctamente. ¿Quién sería juzgado mal además de aquellos a quienes se les revocó EC? Zero talk 04:40, 23 de noviembre de 2024 (UTC) [ responder ]
- Lo pensaré. Pero lo primero es que obtener la fecha de registro significa unirse a la vista de usuario, lo que puede o no afectar significativamente el rendimiento. Creo que tiene casi 50 millones de filas, por lo que el efecto en el rendimiento puede ser impredecible. El rendimiento parece depender en parte del estado de ánimo en el que se encuentre el optimizador.
- Dudo en mencionar esto porque es otra ubicación más en mi mapa de madriguera de conejo inexplorado. Un problema con el recuento de revisiones es que cuenta la presencia sin la ausencia. Es un recuento de revisiones en vivo. Está toda la materia oscura de las revisiones eliminadas y probablemente haya mucha en el área temática. Lo que se ha ido (con las eliminaciones de artículos, etc.) se ha ido, ¿o no? Aparentemente no. Todavía está allí. Puedes verlo, o al menos parte de ello, en la vista de archivo. Entonces, probablemente puedas obtener recuentos eliminados, pero no he intentado hacer nada con esos datos. Parecía muy lento cuando lo pinché (por ejemplo, 30-40 segundos solo para contar mis revisiones eliminadas). También hay un recuento de ediciones aproximado, el recuento de ediciones en las páginas de usuario, desde la vista de usuario, que puede ser una forma de evitar contar las revisiones si la precisión no es tan importante. No sé cómo se produce ese número exactamente porque no es vivo + eliminado, podría ser vivo más eliminado menos redactado, supongo. Sean.hoyland (discusión) 05:55 23 nov 2024 (UTC) [ responder ]
- + Por curiosidad, eché un vistazo a las revisiones eliminadas del archivo para ver si todavía se puede unir alguna a las cosas existentes en el área de temas para la ventana '2023-10-07' y '2024-10-06', y la respuesta es muy pocas, 533, tal vez copyvios en parte al menos... y tomó 6 minutos. Entonces, supongo que las revisiones eliminadas se pueden ignorar. Hay una forma rápida de contar las revisiones eliminadas para los actores que usan la vista archive_userindex en lugar del archivo, si alguna vez es necesario. Sean.hoyland (discusión) 10:38, 23 de noviembre de 2024 (UTC) [ responder ]
- Y pensándolo bien, esa materia oscura de la revisión eliminada presumiblemente afectaría el conteo de etiquetas. Sean.hoyland (discusión) 06:13 23 nov 2024 (UTC) [ responder ]
Ver [1]. 160 segundos no está tan mal y también cuenta las reversiones/reversiones. Zero talk 06:41, 23 de noviembre de 2024 (UTC) [ responder ]
- Bien. Sean.hoyland (discusión) 07:19 23 nov 2024 (UTC) [ responder ]
- Es interesante si agregas una columna de recuento de actores únicos. Al hacer eso, por supuesto, se realiza un recuento doble en los espacios de nombres, pero los números siguen siendo interesantes. Y si eliminas la columna de espacios de nombres para poder ver los recuentos de actores EC y no EC, siempre me sorprende cuántos hay. Sean.hoyland (discusión) 15:09, 23 de noviembre de 2024 (UTC) [ responder ]
La ausencia de etiquetado de reversión ARBECR
No sé cómo encontrar y contar revisiones en PIA que podrían describirse como aplicación de ARBECR de una manera vaga y vaga, pero si la lista de posibles subcadenas de resumen de edición se pareciera a la lista a continuación, solo toma unos segundos obtener las revisiones (junto con los falsos positivos probablemente y muchos faltantes sin duda) para la ventana PIA '2020-10-07' a '2024-10-06'.
- convert(comment_revision.comment_text using utf8mb4) rlike '(arbecr|wp:ecr|non ec|no es una solicitud de edición|no es una solicitud de edición|arbpia|notforum|500 ediciones|non ec|editxy|treinta días|30 días|no es una solicitud seria|solicitud de edición no realizada|solicitud poco clara)'
Sean.hoyland (discusión) 16:58 22 nov 2024 (UTC) [ responder ]
- Creo que estaría bien contar las reversiones de un editor que no pertenece a EC en el espacio principal como una "reversión permitida" independientemente del resumen de la edición. Zero talk 04:46, 23 de noviembre de 2024 (UTC) [ responder ]
Intersección de páginas en un agujero negro
Solo una nota: los editores que han estado aquí mucho tiempo o han editado muchas páginas diferentes, por supuesto, tendrán una mayor interacción que los "novatos". Lo que explicaría que Zero y yo somos aparentemente gemelos siameses, unidos por la cadera. En la medida en que estos números de interacción puedan tener algún significado, deben ajustarse de alguna manera en función del número de páginas que el editor o los editores han editado. ¿Alguna idea sobre cómo se podría hacer tal ajuste? Huldra ( discusión ) 21:21 20 nov 2024 (UTC) [ responder ]
- Tengo un montón de pensamientos desordenados sobre ese tipo de ajustes que se han acumulado durante los últimos meses, ninguno de los cuales es útil. Hacerlo correctamente parece bastante complicado. Puedes imaginar que la probabilidad de una intersección de páginas entre 2 actores es proporcional a varios números e inversamente proporcional a varios otros números, pero esos números, y probablemente hay muchos factores diferentes relacionados con la página, los editores, todos los demás editores, el estado de Wikipedia, cambian con el tiempo. Sean.hoyland (discusión) 05:08 21 nov 2024 (UTC) [ responder ]
- Correcto. Para definir una medida estadísticamente significativa, primero se necesita un modelo de edición independiente. He pensado en ello, pero es un problema bastante complicado. Por último, es imposible que los recuentos en bruto distingan entre amigos y enemigos. Para hacer la distinción, habría que tener en cuenta aspectos como la frecuencia con la que se revierten entre sí. Zero talk 11:20, 21 de noviembre de 2024 (UTC) [ responder ]