La sección de políticas de la bomba de agua del pueblo se utiliza para discutir políticas y pautas ya propuestas y para discutir cambios en las políticas y pautas existentes . Los debates sobre cambios suelen comenzar en otras páginas y luego se trasladan o se mencionan aquí para obtener más visibilidad y una participación más amplia.
Si desea proponer algo nuevo que no sea una política o directriz, utilice la herramienta Village Pump (propuestas) . Para redactar un borrador con un grupo más específico, también puede comenzar en la página de discusión de un WikiProject, un Manual de estilo u otra página de proyecto relevante.
Si tiene alguna pregunta sobre cómo aplicar una política o directriz existente, pruebe uno de los muchos tablones de anuncios de Wikipedia .
Si desea preguntar cuál es la política sobre algo, pruebe con la mesa de ayuda o la casa de té .
Este no es el lugar para resolver disputas sobre cómo se debe implementar una política. Consulte Wikipedia:Resolución de disputas para saber cómo proceder en tales casos.
Consulta esta página de preguntas frecuentes para ver una lista de propuestas que se rechazan o ignoran con frecuencia. Las discusiones se archivan automáticamente después de permanecer inactivas durante dos semanas.
¿Podemos desalentar la adición automática indiscriminada de enlaces del archivo Wayback en todos los enlaces externos?
Hay un montón de robots wikipedistas que funcionan con una herramienta automatizada que agrega indiscriminadamente enlaces de Wayback Machine a cada enlace externo en cada referencia de un artículo de Wikipedia tras otro, ya sea como un parámetro de URL de archivo para las plantillas de citas CS1 o CS2, o usando la plantilla {{ Webarchive }} para enlaces de marcado wiki ordinarios.
Aunque Wayback Machine es un recurso maravilloso e invaluable que utilizo varias veces por semana, y estoy totalmente a favor de agregar archivos para enlaces muertos (como lo hace actualmente User:InternetArchiveBot ), agregar un enlace de Wayback para cada enlace externo en Wikipedia, incluidas todas las URL que aún están activas y son de acceso público, me parece extremadamente spam y moderadamente hostil para el lector. Desperdicia mucho espacio, es confuso para los lectores, desperdicia tiempo/atención y causa confusión para los editores que intentan verificar las afirmaciones en los artículos, y parece principalmente una forma de convertir a Wikipedia en un anuncio masivo para Internet Archive . Personalmente, creo que Internet Archive es maravilloso y que vale la pena apoyarlo con dinero y uso, pero este método me parece realmente asqueroso e injustificado, no muy diferente en espíritu de Wikipedia agregando anuncios de banner para organizaciones benéficas de terceros o wikipedistas individuales que envían spam indiscriminadamente con enlaces a sus propios artículos publicados. Me parece abusivo de Wikipedia como plataforma y de la comunidad de Wikipedia, y hasta donde sé, nunca hubo ningún consenso al respecto.
¿Podemos formalizar algún tipo de política que desincentive la adición automática e indiscriminada de enlaces de archivo? Si los editores humanos quieren agregar deliberadamente copias de seguridad específicas de Wayback para páginas que aún están activas por alguna buena razón (por ejemplo, un sitio web cambió su contenido, cambió sustancialmente su formato o puso un muro de pago, de manera que dificulta el uso del contenido original para verificar las afirmaciones del artículo), no tengo ningún problema con eso. Y nuevamente, como dije anteriormente, estoy completamente a favor de agregar copias de seguridad de Wayback (incluso automáticamente) a los enlaces inactivos.
Todo lo mejor, – jacobolus (t) 03:32, 8 de septiembre de 2024 (UTC) [ responder ]
Una cosa que sugerí anteriormente es que en lugar de desalentar la creación del enlace de archivo (lo cual es bastante comprensible al menos cuando la persona que originalmente construyó la referencia quiere que sea a prueba de balas), hagamos que las plantillas de citas solo muestren el archivo si el estado del enlace es "muerto" o algún estado similar que indique que el enlace original ya no es apropiado. (También me pregunto si necesitamos que la declaración archivada en Internet Archive se muestre en las referencias incluso cuando la URL original está muerta ; cualquiera que siga el archivo verá el sitio en el que se encuentra, realmente no informa al lector sobre la calidad del material de origen y, como dices, parece publicidad). -- Nat Gertler ( discusión ) 06:14, 8 de septiembre de 2024 (UTC) [ responder ]
No me parece una buena solución. Hay razones perfectamente legítimas para que los editores agreguen copias de seguridad de archivos de forma manual e intencional para páginas específicas que aún siguen activas, por ejemplo, si el sitio es inestable y se desconecta de forma rutinaria, es conocido por cambiar las URL con regularidad o ha cambiado sustancialmente el contenido de una página vinculada específica. Sin embargo, para otros enlaces, una copia de seguridad "por si acaso" en la fuente del artículo no sirve de nada.La acción que resulta útil, para las páginas que aún están activas, es pedirle explícitamente a la IA que rastree y archive el contenido de la página (por ejemplo, solicitándole que rastree todas las páginas vinculadas desde un artículo de Wikipedia en particular), de modo que haya una copia de seguridad en caso de que el enlace se estropee. Pero eso se puede hacer desde el sitio de la IA o desde algún script externo y no debería implicar cambiar el marcado de origen de un artículo de Wikipedia. – jacobolus (t) 06:30, 8 de septiembre de 2024 (UTC) [ responder ]
Se trata de NoMore404, que monitorea cada enlace agregado a cada proyecto Wiki, incluidos los más de 300 idiomas de la wiki, y lo guarda en Wayback Machine en un plazo de 24 horas. Por eso la cobertura de Wikipedia en Wayback Machine es tan buena. Hay varias razones por las que algunas URL podrían no guardarse, por lo que desearía que tuviéramos otro servicio que llenara los vacíos, es decir, que registrara las nuevas URL y verificara que existen en Wayback unos días después, o que las archivara en otro lugar (Ghost, ArchiveToday, etc.). -- Green C 00:37, 11 de septiembre de 2024 (UTC) [ responder ]
Soy consciente de que esto se hace, pero ¿puedes vincular un ejemplo de bot o script que lo haga? (Como señalas, IAbot no lo hace). Es posible que el código que la gente está usando simplemente se haya escrito a toda prisa y sin comprobaciones. Me opongo a añadir esos enlaces de archivo indiscriminadamente a cada cita:
Los enlaces de archivo agregados después del hecho, cuando no son para fines de rescate o RCP, deben tener una fecha lo más cercana posible al |access-date=parámetro de la cita y no a la fecha del rastreo (que puede o no ser el caso para un script de usuario determinado). Si el nuevo |archive-date=parámetro debe ser diferente, el texto citado debe verificarse manualmente.
Si no |access-date=se proporciona ningún parámetro, el texto citado debe comprobarse manualmente. (En la práctica, puede que no esté justificado fecharlo con el día en que se realizó la edición original, y dudo que sea computacionalmente factible rastrear una sección de wikitexto hasta su última edición en un bot).
Es posible que algunos enlaces de citas estén destinados explícitamente a hacer referencia a la versión en vivo de un sitio web, como una aplicación web o una nota al pie "estado actual de...".
Sin embargo, si el |access-date=parámetro se proporciona en la cita, no veo ningún problema con agregar un enlace de archivo con |url-status=liveel que corresponda. (Aunque podríamos considerar consultar más sitios de archivo que solo IA al hacer esto). SamuelRiv ( discusión ) 16:51, 8 de septiembre de 2024 (UTC) [ responder ]
Aquí hay un ejemplo de edición, special:diff/1243928783 , resumen de la edición "Rescatando 13 fuentes y etiquetando 0 como muertas.) #IABot (v2.0.9.5 Etiqueta: IABotManagementConsole [1.3]" . (Esta es una variante común particularmente molesta que agrega enlaces de wayback para cosas como páginas de Google Books, enlaces de bibcode, etc.) No estoy tratando de señalar a wikipedistas específicos ni avergonzar públicamente a nadie. Hay un montón de personas que hacen este tipo de edición usando la misma herramienta automatizada, a menudo en muchas páginas en rápida sucesión. Creo que este tipo de ediciones se hacen de buena fe, pero creo que deberíamos tener una página de políticas que las desaliente. – jacobolus (t) 17:46, 8 de septiembre de 2024 (UTC) [ responder ]
IABot ya no guarda enlaces en WaybackMachine porque NoMore404 mencionado anteriormente ya lo hace. -- Green C 00:39, 11 de septiembre de 2024 (UTC) [ responder ]
@Jacobolus ¿podrías aclarar si tu objeción es al uso per se de IA o al hecho de que la gente lo esté haciendo indiscriminadamente, como si fuera un bot? Yo suelo ejecutar IABot en mis propios artículos y le digo que añada enlaces a todo lo que archiva. Espero que no te opongas a eso. RoySmith ( discusión) 17:33 8 sep 2024 (UTC) [ responder ]
Sí, me opongo a agregar enlaces de archivo a "todo lo que archiva". Esto es, en mi opinión, un tipo de spam. Utilice enlaces de archivo (ya sea del archivo de Internet o de algún otro sitio) para enlaces en los que el original está inactivo, ha cambiado o no es confiable por alguna razón, no solo para rellenar la sección de citas con desorden innecesario y que distraiga. – jacobolus (t) 17:37, 8 de septiembre de 2024 (UTC) [ responder ]
¿Puedes darme un ejemplo? ¿Un bot, un script o un usuario que use un script AWB para hacer ping? SamuelRiv ( discusión ) 17:44 8 sep 2024 (UTC) [ responder ]
No se trata de una cuestión puramente retórica, pero uno podría buscar las URL de Google Books y rápidamente hacerse una idea de lo común que es este archivado indiscriminado y cómo se ve. Remsense ‥ 论20:18, 8 de septiembre de 2024 (UTC) [ responder ]
Vale, supongo que tendré que discrepar respetuosamente. El problema es que cuando un enlace deja de funcionar, ya es demasiado tarde para archivarlo y, luego, se pierde. No me importaría que las plantillas de citas trataran esto de una manera menos "difusa", pero odiaría ver que la información del archivo se omitiera por completo. RoySmith (discusión) 17:45, 8 de septiembre de 2024 (UTC) [ responder ]
He aquí un ejemplo de RoySmith: special:diff/1232611207 to Big Duck . La mayoría (¿todos?) de los enlaces de archivo que se añaden aquí llevan a páginas que aún siguen vivas y que son de acceso público en Internet, por lo que los enlaces de archivo no son más que basura. "Cuando un enlace deja de funcionar, ya es demasiado tarde para archivarlo" : las personas deberían pedirle directamente a la IA que rastree y haga copias de seguridad de las páginas enlazadas desde Wikipedia. Es completamente innecesario cambiar la fuente de marcado de los artículos de Wikipedia para realizar esta tarea.Pero, para ser sincero, no me importa demasiado si uno de los autores principales de un artículo quiere meterse con los enlaces de retroceso. La discusión sobre esa elección podría limitarse a las páginas de discusión de artículos individuales y resolverse localmente. Pero también hay gente que realiza una gran cantidad de estas ediciones en una página tras otra de forma similar a un bot, y a gran escala es imposible que alguien que no esté de acuerdo revierta o impugne esos cambios de manera significativa sin dedicar una cantidad de tiempo aún mayor. No creo que haya un consenso establecido sobre si dichos enlaces de archivo deberían agregarse en todo el sitio, por lo que agregarlos automáticamente a gran escala es una especie de hecho consumado . – jacobolus (t) 17:52, 8 de septiembre de 2024 (UTC) [ responder ]
Agregar el enlace de IA a la plantilla de citación hace que sea mucho más fácil encontrarlo más adelante si es necesario. Si le molesta ver eso, es bastante fácil agregar algo de CSS personalizado para ocultar esas secciones de la cita. Me encantaría que las plantillas agreguen algunas clases al marcado para que sea más fácil de implementar. RoySmith (discusión) 18:32, 8 de septiembre de 2024 (UTC) [ responder ]
Me molesta que estemos enviando spam a editores y lectores de una manera que parece abusiva de la plataforma y la comunidad de Wikipedia. Ocultar lo que veo personalmente no resuelve en absoluto mis inquietudes. "Es mucho más fácil encontrarlo más tarde si es necesario" - esto me parece una tontería. Estamos hablando del resultado de una herramienta completamente automatizada sin inspección o intervención humana más allá de hacer clic en un botón de envío; el IABot está actualmente "rescatando" automáticamente enlaces muertos en todo el sitio sin ninguna intervención humana, y presumiblemente seguirá haciéndolo. Hablando como un humano que usa constantemente Wayback Machine para encontrar páginas archivadas, es trivial ir a web.archive.org, escribir una URL en el cuadro y luego hacer clic para ver las distintas versiones archivadas de esa URL. – jacobolus (t) 18:47, 8 de septiembre de 2024 (UTC) [ responder ]
@Jacobolus : Sólo quiero expresar la posición exactamente opuesta a tu propuesta .
Hacer clic en un enlace en lugar de ir a la página de Wayback Machine, copiar y pegar la URL, posiblemente comparar copias de archivo alternativas... ¿pero dices que te preocupas por todos los demás en lugar de solo por ti mismo? Eso no tiene sentido para mí. Fabrickator ( discusión ) 19:13 8 sep 2024 (UTC) [ responder ]
@Fabrickator No estás entendiendo lo que quiero decir. Déjame intentar ser más claro. La afirmación es que necesitamos agregar enlaces de archivo a cada enlace externo de manera defensiva porque de lo contrario no es lo suficientemente "fácil" encontrar el enlace de archivo en caso de que el enlace se pudra y se vuelva "necesario". Mis respuestas son: (1) no es más difícil activar manualmente un bot/script de archivo años después en el posible caso de que algunos enlaces se pudran, (2) hay un proceso automatizado que se ejecuta continuamente escaneando la web en busca de enlaces muertos y "rescatando" citas de Wikipedia agregando enlaces de archivo de Wayback, sin requerir intervención humana en absoluto en el caso general, y (3) incluso si este bot de alguna manera no detecta un enlace muerto extraviado muy ocasional y un editor humano intenta verificar una afirmación pero termina en una página 404 o lo que sea, es bastante trivial para un editor humano usar la máquina Wayback desde su navegador (no toma más que unos pocos minutos encontrar manualmente el enlace Wayback y agregarlo a un artículo, y estamos hablando de una cantidad diminuta de enlaces en ese momento). Las personas que ejecutan este script ciertamente no están comparando varias versiones archivadas de cada enlace. No tengo ningún problema si los editores inspeccionan cuidadosamente de forma manual y piensan en la mejor manera de presentar cada enlace de cita a los lectores, a veces tomando la decisión individual específica de agregar un enlace de archivo. – jacobolus (t) 20:34, 8 de septiembre de 2024 (UTC) [ respuesta ]
@Jacobolus , si te entiendo bien, estás diciendo que el sistema actual, que es :
El bot hace todo automáticamente. Ventaja: dado que se ejecuta poco después de agregar la fuente, (casi) siempre se vinculará a la página archivada correcta.
es inferior, porque la alternativa:
Espere hasta que se rompa el enlace
Activar el bot manualmente.
Compruebe los resultados.
Ups, se vinculó a una copia archivada de la página rota.
Vaya a archive.org.
Pegue la URL muerta en el cuadro de búsqueda.
Revise manualmente varias versiones de la página para determinar cuál debe entregarse a los lectores.
Copia esa URL.
Pegue la URL del archivo en el artículo de Wikipedia.
Averigüe qué requiere la plantilla de citación para el sello de fecha (porque produce un mensaje de error rojo si no lo hace correctamente).
es "muy fácil" y "bastante trivial", ¿verdad? Hablando solo por mí, no creo que un proceso de 10 pasos sea "fácil" o "trivial", especialmente en comparación con la opción de "El bot hace todo automáticamente". WhatamIdoing ( discusión ) 05:32 9 sep 2024 (UTC) [ responder ]
No, esto es una caracterización errónea y dramática tanto de lo que estoy diciendo como del "sistema actual". No estoy seguro de qué es lo que falla en la comunicación aquí, pero intentaré aclarar brevemente las cosas antes de tener que irme.Las partes funcionales del "sistema actual" son (1) el Internet Archive (IA) comprueba automáticamente casi todos los enlaces externos añadidos a Wikipedia y los rastrea, añadiendo instantáneas de las páginas a las que apuntan a la Wayback Machine (de aquí en adelante WB), (2) cualquier persona en el mundo puede solicitar explícitamente que cualquier página web arbitraria y todos sus enlaces salientes sean rastreados y que se añada una nueva instantánea de cada una de ellas a WB, (3) el IA ejecuta algún tipo de proceso automático que comprueba los enlaces salientes de Wikipedia y los marca cuando ya no funcionan, (4) el Usuario:InternetArchiveBot ("IABot") "rescata" los enlaces muertos que aparecen en las páginas de Wiki añadiendo enlaces de instantáneas de WB a las citas de artículos de Wikipedia, sin mucha necesidad de intervención humana (aunque a veces el bot se equivoca de alguna manera, o el archivo contiene el contenido incorrecto, o el sitio web cambió su esquema de URL y todavía hay una página activa en una nueva URL, etc., en cuyo caso un humano puede arreglarlo). Todo lo anterior generalmente funciona muy bien. Previene muchos enlaces rotos en Wikipedia y no tengo ningún problema con ello.
Además, hay una parte del "sistema actual" que me parece spam, confusa, derrochadora de espacio y atención tanto en el marcado de salida como en el de origen, con una rotación innecesaria de los historiales de las páginas, sin ningún valor práctico obvio y sin el apoyo del consenso actual de la comunidad. A saber: (5) los "robots de carne" humanos ejecutan un script semiautomático, "IABotManagementConsole", que agrega indiscriminadamente un enlace de instantánea de WB a cada cita con un enlace externo en ella en un artículo en particular, casi todos los cuales son enlaces que funcionan a páginas que aún están vivas y a las que puede acceder cualquier persona en Internet abierta. Estos editores no verifican nada manualmente ni toman decisiones cuidadosas, sino que simplemente hacen clic en uno o dos botones, y su comportamiento no es fundamentalmente diferente al de los bots. Algunos de ellos hacen esto repetidamente una y otra vez en docenas o cientos de páginas diferentes con las que no tienen ninguna otra interacción.
Estas modificaciones son innecesarias, porque en caso de que un enlace se pudra, las otras partes del "sistema actual" ya se encargan de ello. Solo una proporción insignificante de enlaces se pudren y son seleccionados por editores humanos que intentan verificar una afirmación antes de que hayan sido "rescatados", y en estos casos, el editor humano tarda entre 1 y 2 minutos en realizar el rescate manualmente, o unos pocos clics para que un bot lo haga. No hay un "proceso de 10 pasos" involucrado. – jacobolus (t) 05:57, 9 de septiembre de 2024 (UTC) [ responder ]
Vale, la parte que cuestiono es tu afirmación de que "en caso de que un enlace se pudra, las otras partes del "sistema actual" ya se encargan de ello". Considero que los "rescates" posteriores a la putrefacción son de peor calidad (por ejemplo, páginas 404 no detectadas y redirecciones a la página principal del sitio) que los enlaces archivados añadidos antes de la putrefacción.
¿Por qué crees que 1 o 2 minutos de trabajo manual por enlace (y siendo realistas, tenemos que asumir que todos morirán algún día, por lo que para un artículo con ~15 fuentes, eso es media hora de tiempo manual) es mejor que hacer clic en un botón una vez y terminar para siempre con todas las referencias (actuales)? WhatamIdoing ( discusión ) 06:09, 9 de septiembre de 2024 (UTC) [ responder ]
Según mi experiencia, los enlaces del "archivo anterior a la descomposición" también tienen una proporción sustancial de errores y también requerirían atención manual de manera rutinaria (excepto que podemos evitarlo simplemente eliminando esos enlaces de instantáneas como spam hostil para los lectores). Mi propia expectativa es que la cantidad de trabajo manual requerido para esto va a ser casi idéntica en cualquier caso, excepto que exigir enlaces de respaldo en todas partes carga por adelantado ese esfuerzo manual y obliga a un humano a verificar dos veces un enlace de Wayback para cada enlace en el sitio en lugar de reservar las verificaciones manuales para los casos en que marca la diferencia.Imagino que la mayor parte de la diferencia que estás viendo es un sesgo de selección: es relativamente más probable que los enlaces que funcionan provengan de sitios web mejor administrados que no rompen sus URL con tanta frecuencia y, por lo tanto, también tienden a tener enlaces de instantáneas archivados que funcionan. Pero si esas páginas se rompen en algún momento, seguirán teniendo enlaces de instantáneas que funcionan. En comparación, es relativamente más probable que los enlaces rotos provengan de sitios web descuidados o mal administrados.Pero si encuentra que los enlaces de "rescate post-rot" a menudo muestran lo incorrecto, entonces eso parece un problema en el que los autores de bots deben trabajar: por ejemplo, el bot podría intentar verificar variantes de la página y evitar páginas 404 o versiones donde hay contenido visible limitado, o podría intentar elegir una fecha de instantánea cercana a la fecha de acceso descrita en una plantilla de cita, cuando presumiblemente un humano pudo ver el contenido. – jacobolus (t) 06:22, 9 de septiembre de 2024 (UTC) [ responder ]
En el código fuente de las páginas, este comportamiento arrogante de archivar se manifiesta como negligencia aparente o compulsión obsesiva con demasiada frecuencia en determinadas situaciones. "Indiscriminado" es la palabra clave aquí. Remsense ‥ 论20:20, 8 de septiembre de 2024 (UTC) [ responder ]
Internet Archive tiene una configuración de canalización que archiva todos los enlaces externos al pasar por todas las revisiones publicadas en EventStream. https://archive.org/details/wikipedia-eventstream?sort=-addeddate En realidad, ya no es necesario que activemos un archivo y mostremos que los enlaces están archivados, a menos que la fuente sea sensible al tiempo. – robertsky ( discusión ) 05:21, 9 de septiembre de 2024 (UTC) [ responder ]
Hmm. Aunque puedo ver algunos de los problemas, el problema es que a menudo las URL no están archivadas por IA. Véase "Il Naturalista Valtellinese" en Engadine Line , por ejemplo. Lo que encuentro más problemático (se ha señalado en WT:FAC#Google Books web archive links y también en IABot) es cuando archivan enlaces de Google Books, que no son visibles para todos de la misma manera. Jo-Jo Eumerus ( discusión ) 07:33 9 sep 2024 (UTC) [ responder ]
NO he leído (ni digerido a través de ChatGPT o agentes de resumen similares) todo este largo hilo, pero creo que tiene una relevancia significativa como punto de discusión y política. En el artículo OpenStreetMap , Cita n.° 1 que se relaciona con el primer conjunto de cambios indexado por el software OpenStreetMap, la cita contenía un enlace de archivo con fecha de 2018; la página web original estaba fechada en 2005. Sin embargo, la página almacenada más antigua de InternetArchive es de 2014. Cambié el enlace de archivo a la versión más antigua porque la página almacenada de 2018 contiene comentarios que se agregaron al conjunto de cambios después de que aparentemente se "descubrió" que era el primer conjunto de cambios, mientras que la página archivada de 2014 no contenía tales comentarios. Creo que este es un buen ejemplo (de un tipo específico) que contrarresta las adiciones indiscriminadas de enlaces de archivo... aunque no he podido determinar si esto era algo parecido a los robots de carne que se discutieron anteriormente. El cambio de la página se puede encontrar en https://en.wikipedia.org/w/index.php?title=OpenStreetMap&diff=1245279923&oldid=1245279698 . Espero que esto ayude un poco a la discusión. Saludos --Usuario:Ceyockey ( háblame ) 02:29, 12 de septiembre de 2024 (UTC) [ responder ]
Estoy muy de acuerdo con esto. Yo solía ser uno de esos editores que hacía clic en el botón y dejaba que IAbot se ejecutara porque pensaba que agregar los enlaces de archivo era una mejora para cualquier artículo. Ya no lo creo, especialmente desde que aprendí que Internet Archive archiva todos los enlaces externos en Wikipedia de todos modos , por lo que hacer que el bot se ejecute en realidad no archiva los enlaces, solo agrega enlaces de archivo a las citas, lo que generalmente no es útil, a menos que el enlace esté inactivo e IA tenga la versión completa (o para evitar un muro de pago, pero ese no es realmente un uso kosher). Los enlaces de archivo hacen que las citas sean más difíciles de leer y trabajar con ellas. Es aún peor cuando el enlace que se archiva es inútil, por ejemplo, archivar páginas de Google Books porque está vinculado en una cita al libro (¡lo que no archiva el libro!). En resumen: no creo que la adición automática de enlaces de archivo web a las citas sea algo bueno. Apoyaría un cambio en IABot para que solo agregue enlaces de archivo si |url-status=dead. Creo que soy una minoría en esto, sin embargo. Levivich ( discusión ) 19:27 8 sep 2024 (UTC) [ responder ]
Si lo que dices en tu primer fragmento en negrita es cierto (no tengo motivos para dudarlo, pero no tengo tiempo de comprobarlo ahora), entonces estoy en la misma minoría, si es que realmente es una minoría. Phil Bridger ( discusión ) 19:40 8 sep 2024 (UTC) [ responder ]
Como se trata de Wikipedia, debería citar mis fuentes :-) IA en 2018: Durante más de 5 años, Internet Archive ha estado archivando casi todas las URL a las que se hace referencia en cerca de 300 sitios de Wikipedia tan pronto como se agregan o cambian esos enlaces a un ritmo de aproximadamente 20 millones de URL por semana. WP:WAYBACK también dice que las nuevas URL agregadas a los artículos de Wikipedia (pero no a otras páginas) generalmente son archivadas automáticamente por un bot. También dice que se alienta a los editores a agregar un enlace de archivo como parte de cada cita , lo que creo que no debería decir. Por cierto, otra solución muy fácil para esto sería codificar las plantillas de citas para que no muestren enlaces de archivo a menos que |url-status=dead. Esto probablemente también podría hacerse como un truco de CSS, por lo que los editores que no quisieran ver esos enlaces para URL activas podrían desactivarlos por así decirlo. Levivich ( discusión ) 20:07, 8 de septiembre de 2024 (UTC) [ responder ]
Una de las razones para incluir un enlace a Wayback es que podemos seguir citando páginas web que ya no están disponibles o que han sufrido cambios significativos. Pero esto me genera dudas... Quiero saber POR QUÉ la fuente citada ya no está disponible o ha cambiado. Siempre debemos hacernos esta pregunta antes de incluir un enlace a Wayback. La respuesta puede requerir que reevaluemos si la información de nuestro artículo está desactualizada y, por lo tanto, ya no es precisa ni verificable. Blueboar ( discusión ) 21:19 8 sep 2024 (UTC) [ responder ]
@ Phil Bridger https://archive.org/details/wikipediaoutlinks?tab=about -- Ahecht ( PAGINA DE DISCUSION) 20:35, 9 de septiembre de 2024 (UTC) [ responder ]
En mi experiencia, los enlaces de archivo para enlaces que siguen activos pueden ser útiles, ya que el sitio puede estar temporalmente inactivo o bloqueado por región. Sin embargo, no tengo una opinión firme al respecto, porque para mí personalmente no es difícil abrir manualmente un enlace a través del Web Archive. La solución de Levivich me parece buena, pero también estoy de acuerdo con jacobolus en que debería haber una opción en IABot para archivar todos los enlaces pero no agregarlos al artículo. AstonishingTunesAdmirer 連絡21:10, 8 de septiembre de 2024 (UTC) [ responder ]
Debería haber una opción en IABot para archivar todos los enlaces pero no agregarlos al artículo . La hay. Cuando voy a https://iabot.wmcloud.org/index.php?page=runbotsingle&action=analyzepage, hay una casilla de verificación etiquetada como "Agregar archivos a todas las referencias no muertas (opcional)". La opción predeterminada no está marcada. RoySmith (discusión) 21:15 8 sep 2024 (UTC) [ responder ]
Acabo de probarlo, no es eso, todavía agrega enlaces de archivo al artículo. Por lo que entiendo, el bot hace una lista de todas las referencias en el artículo seleccionado, luego guarda cada enlace a través del Archivo Web y luego agrega enlaces a estas páginas archivadas al artículo. De lo que hablaba jacobolus es de omitir esa parte final, por lo que el bot guardaría todos los enlaces a través del Archivo Web, pero no los agregaría al artículo. AstonishingTunesAdmirer 連絡21:30, 8 de septiembre de 2024 (UTC) [ responder ]
@Jacobolus : Escribiste: "No estás entendiendo mi punto. Déjame tratar de ser más claro". Entiendo tu punto, pero creo que es malo. No tengo claro si te opones a que el enlace al archivo sea visible, que esté presente cuando editas el artículo o que se almacene en el wikitexto. Ciertamente no me opongo a que no aparezca cuando ves un artículo, y los detalles de cómo se almacena es algo que me gustaría ver mejorado (por ejemplo, en la línea de almacenar los datos en Wikidata y acceder a ellos usando ).{{cite q}}
Pero incluso la posibilidad de que la URL activa no funcione temporalmente (o de forma permanente) es razón suficiente para tener a mano el enlace del archivo. Es una ventaja que existan otros escenarios en los que es útil... por ejemplo, algunos artículos "de varias páginas" (que requieren una URL diferente para llegar a las páginas siguientes) también pueden tener un enlace que muestre todas las páginas con una única URL. Puede suponer que esto no viene al caso, pero como editor, tomo la decisión de qué es lo que prefiero. No me gusta la molestia que supone todo esto, pero me alegra que no estemos atascados con lo que los robots poco inteligentes deciden hacer.
Anhelaría un bot que fuera lo suficientemente inteligente como para tomar buenas decisiones, pero no veo evidencia de que tengamos la tecnología adecuada para desarrollar bots lo suficientemente inteligentes, por lo que tenemos un recurso de reserva que consiste en agregar o editar manualmente los enlaces de archivo, aunque el sistema existente es útil porque hace una selección aceptable al menos la mayor parte del tiempo, pero de alguna manera te molesta la presencia de esa selección. Me rindo. Fabrickator ( discusión ) 21:51 8 sep 2024 (UTC) [ responder ]
"No tengo claro si te opones a que el enlace del archivo sea visible, esté presente cuando editas el artículo o se almacene en el wikitexto". Me opongo firmemente a la primera opción, que parece spam y confunde a los lectores, y me opongo moderadamente a las otras dos, que aún añaden mucho desorden al marcado sin ningún beneficio práctico. "También puede tener un enlace que muestre todas las páginas con una sola URL". Si quieres vincular el título del artículo a una URL y también añadir una segunda URL a una versión consolidada del contenido, no hay nada que te lo impida. Sería extremadamente confuso utilizar el parámetro "archive-url" para esto, así que no lo hagas. "Como editor, tomo esa decisión" . De nuevo, no estoy muy contento con las herramientas automatizadas que imponen malas decisiones que no están respaldadas por el consenso del sitio, no por editores humanos que toman decisiones específicas sobre enlaces individuales en artículos individuales. Esto último es totalmente posible de discutir y resolver en las páginas de discusión locales. – jacobolus (t) 22:03, 8 de septiembre de 2024 (UTC) [ respuesta ]
Supongo que mi respuesta a esto sería "nunca se sabe cuándo una publicación o empresa puede dejar de funcionar". Como ejemplo reciente, Game Informer dejó de funcionar este año y hubo una locura por archivar todos los enlaces de su sitio web y asegurarse de que todo se guardara porque GameStop no se molestó en mantener actualizado el historial de GI. Prefiero ser preventivo y evitar que ocurran cosas así en lugar de reaccionar y tener que apresurarme a archivar una fuente si deja de funcionar. ♠ JCW555 (discusión) ♠ 22:22 8 sep 2024 (UTC) [ responder ]
"Nunca se sabe" simplemente no es un argumento lo suficientemente convincente como para aplicarlo literalmente el 100% del tiempo a favor de un desorden obvio que tiene claras desventajas concretas mientras tanto. ¿Cuál es la aversión que tienen los editores contra que se aplique literalmente cualquier tipo de discreción aquí? Remsense ‥ 论22:52, 8 de septiembre de 2024 (UTC) [ responder ]
"Un desorden evidente que, mientras tanto, tiene claras desventajas concretas". Esta es tu opinión, que está bien mantener, por supuesto, pero yo (y otros) no pensamos así, así que no intentes hablar por todos. "Discreción" en este caso sería "los editores deberían tener la misma opinión que yo". Prefiero ser proactivo en el archivo de fuentes que reactivo. ♠ JCW555 (discusión) ♠ 23:05 8 sep 2024 (UTC) [ responder ]
En mi opinión, se hace hincapié en los problemas demostrables y objetivos causados por la práctica. Se puede hacer un énfasis diferente, pero no pretendamos que el hecho de que los problemas existan (sobre lo que acabo de hablar más abajo) sea en sí mismo una cuestión de opinión. Remsense ‥ 论23:08, 8 de septiembre de 2024 (UTC) [ responder ]
"Cuáles son los problemas demostrables y objetivos causados por la práctica" de nuevo, según tú . Yo y otros en esta conversación no estamos de acuerdo contigo. Puedes pensar que es un problema, otros pueden pensar que no lo es. Eso no hace que ninguno de los dos tenga razón, por supuesto, pero no digo que mi opinión sea 100% verdadera y todos deben estar de acuerdo conmigo. Solo hablo por mí, no por todos los editores de la plataforma. Así que, de nuevo, no hables por mí ni por todos los que están aquí. ♠ JCW555 (discusión) ♠ 23:19 8 sep 2024 (UTC) [ responder ]
El hecho de que mi navegador se bloquee cuando intento activar el resaltado de sintaxis no es un producto de mi imaginación ni una mera preferencia estética que tenga. En general, es un problema para mí y para ti a todos los efectos, por lo que no me vas a obligar a andar con rodeos. Remsense ‥ 论23:20, 8 de septiembre de 2024 (UTC) [ responder ]
He leído toda esta discusión un par de veces y todavía no entiendo qué es lo problemático de incluir los enlaces de archivo para los enlaces activos. Son útiles para interrupciones temporales, bloqueo de regiones, verificación de páginas que han cambiado de contenido, dominios usurpados (que son difíciles de detectar automáticamente, por lo que los dominios WP:JUDI deben rastrearse manualmente, por ejemplo) y para otros usos también. Tampoco entiendo por qué algunas personas en la discusión encuentran confusa la presentación de enlaces activos y archivados: ¿es este un problema real que los lectores han notado o es solo una teoría de que alguien podría estar confundido? No estoy a favor de cambiar la presentación, pero me opongo a eliminarla sin evidencia de que la presentación actual es realmente problemática y que la alternativa propuesta es realmente una mejora. En todo caso, preferiría alentar la inclusión de enlaces de archivo con cada cita, porque son significativamente valiosos para mantener la integridad de la enciclopedia y permitir la verificación continua de nuestros artículos. Estoy completamente en desacuerdo con que sean un "desorden" y nadie ha presentado aquí ningún argumento que me convenza de que la inclusión tenga alguna desventaja, de hecho es todo lo contrario. Thryduulf ( discusión ) 22:57 8 sep 2024 (UTC) [ responder ]
Cuando se refieren claramente a uno de los problemas que planteas, por supuesto que son útiles. De lo contrario, la longitud del wikitexto en sí, más la complejidad visual y técnica asociada, simplemente no es gratis o esencialmente gratis: el conjunto adicional de parámetros añadidos indiscriminadamente a cada cita añade desorden visual para que los editores se desplacen, lo que hace que sea más difícil factorizar los artículos y entender su wikitexto, e incluso el artículo representado si el archivo no cumple ninguna función clara. No es polémico que también pueda retrasar al editor, especialmente cuando está habilitado el resaltado de sintaxis. Hablo muy en serio cuando digo que hay artículos que no puedo editar cómodamente en su estado actual, mientras que podría hacerlo si cada URL de Google Books no añadiera casi 1 kB al tamaño del artículo en lugar de 100 B. Si se supone que debemos tener archivos en literalmente cada URL externa, entonces eso debería añadirse al backend o algo así para que no tengamos que lidiar con ello de esta manera. No lo tratemos técnicamente como una cuestión de discreción cuando en realidad no lo es editorialmente. Remsense ‥ 论23:05, 8 de septiembre de 2024 (UTC) [ respuesta ]
Cuando abordan claramente uno de los problemas que usted mencionó, siempre abordan esos problemas, porque no es posible predecir cuándo un sitio estará inactivo (temporalmente o no), si algún editor estará geobloqueado (por ejemplo, muchos sitios de noticias de EE. UU. están bloqueados para los editores en Europa, pero es completamente invisible para los lectores de EE. UU. cuáles lo están y cuáles no), etc. Thryduulf ( discusión ) 23:15, 8 de septiembre de 2024 (UTC) [ responder ]
Pero es posible sopesar algunos de estos factores en función del contexto. Además, ¿por qué podemos suponer a priori que la IA es perfectamente fiable de esta manera, pero ningún otro sitio lo es? Remsense ‥ 论23:19, 8 de septiembre de 2024 (UTC) [ responder ]
Es posible que un humano sopese algunos de esos factores en contexto , lo que significa que, como los humanos no evalúan (y no pueden evaluar) cada enlace en contexto antes de que cada lector lea el artículo, los enlaces siempre abordan los problemas planteados. No asumimos que la IA sea perfectamente confiable, sabemos que la IA no realiza geobloqueos y es generalmente confiable, también sabemos que la combinación de un enlace y un archivo (la IA no es la única opción, a pesar de lo que implica este hilo) es más confiable que un enlace solo. Thryduulf ( discusión ) 00:03, 9 de septiembre de 2024 (UTC) [ responder ]
Correcto, lo único que estoy defendiendo es que la discreción es posible y que todavía se espera en el uso de herramientas automáticas, como en cualquier otra dimensión de la edición.
Como una tangente total, siempre me he preguntado por qué no es posible reducir el archivo CS1 a dos parámetros: fecha y estado de actividad. Seguramente es bastante factible derivarlo |archive_url=de los |url=y |archive_date=(etc.) ya dados. Remsense ‥ 论00:11, 9 de septiembre de 2024 (UTC) [ responder ]
En la mayoría de los casos, sí. Pero, en ocasiones, los sitios web cambian sus URL y no hay garantía de que dejen una redirección. AstonishingTunesAdmirer 連絡00:17, 9 de septiembre de 2024 (UTC) [ responder ]
Ah, eso tiene sentido. ¿Crees que sería viable que el "modo predeterminado" supusiera una IA sin redirección y que se pudieran especificar otras configuraciones si fuera necesario? Por más firme que sea mi opinión, reducir la huella de wikitexto del archivo haría que, en esencia, no fuera un problema. Remsense ‥ 论00:20, 9 de septiembre de 2024 (UTC) [ responder ]
En mi opinión, es una buena idea. Creo que, combinado con una opción para desactivar la representación de enlaces de archivo en sitios activos, debería resolver la mayoría de las quejas (el código wiki estaría menos desordenado, habría menos enlaces de archivo en la pantalla). Pero creo que esto es más una pregunta para las personas que trabajan en las plantillas de citas, si es difícil de implementar, etc. Preguntando a @Trappist the monk e Izno : ¿qué tan difícil sería generar un enlace de archivo para una URL, de modo que en lugar de que {{cite web|url=https://en.wikipedia.org|archive-url=https://web.archive.org/web/20240501005015/https://en.wikipedia.org|archive-date=May 1, 2024}}pudieras hacer solo {{cite web|url=https://en.wikipedia.org|archive-date=May 1, 2024}}, pero con una opción para proporcionar archive-urlsi difiere de url(o si necesitas una instantánea específica, supongo)? AstonishingTunesAdmirer 連絡00:49, 9 de septiembre de 2024 (UTC) [ responder ]
Necesitarías la marca de tiempo completa del archivo 20240501005015, por lo que necesitas un parámetro separado, independientemente |archive.org-id=20240501005015de lo que sea. No podrías hacerlo únicamente con un |archive-date=. Izno ( discusión ) 01:02, 9 de septiembre de 2024 (UTC) [ responder ]
¿No puedes reemplazar los últimos 6 dígitos por ceros? Parece que me redirige a la fecha más cercana. AstonishingTunesAdmirer 連絡01:06, 9 de septiembre de 2024 (UTC) [ responder ]
Eso no siempre será exacto, por ejemplo, la página de noticias puede actualizarse varias veces al día. Thryduulf ( discusión ) 01:13 9 sep 2024 (UTC) [ responder ]
Cierto. En ese caso, podrías usar el archive-url. La mayoría de los enlaces (al menos los que encuentro) solo tienen un par de instantáneas y no necesitan esa precisión. AstonishingTunesAdmirer 連絡01:20, 9 de septiembre de 2024 (UTC) [ responder ]
Seguro-Estaba imaginando un |archive_vendor=parámetro (o algo más conciso) en el caso excepcional de facto cuando usamos otra cosa, que por defecto sería IA.Remsense ‥ 论01:34, 9 de septiembre de 2024 (UTC)Olvídate de eso. Probablemente debería haberme dado cuenta antes de que esto puede seguir siendo mínimamente complicado simplemente asumiendo que la IA es predeterminada y especificando |archive-url=lo contrario. Remsense ‥ 论05:01, 9 de septiembre de 2024 (UTC)[ responder ]
No creo que realizar cambios en cs1|2 en un intento de frenar el comportamiento social molesto o malo sea una buena idea. Para la cuestión específica de ocultar la información de archivo en una cita renderizada, puedo imaginar que Module:Citation/CS1 envuelva el formulario en vivo (Archivado desde el original el < fecha de archivo >) en una clase CSS para que los editores individuales puedan ocultar esa parte de la cita renderizada con algo como esto:
Otra posibilidad es conseguir que alguien en WP:US/R escriba un script que oculte la información del archivo en vivo pero que también proporcione algo en lo que se pueda hacer clic para que los editores individuales puedan mostrar la información del archivo de una cita si desean verla.
@ Thryduulf , hace un tiempo hablé con la gente de IA sobre esto. El problema que tenemos es que lo que hace el bot viola nuestras pautas en WP:ELCITE . El problema que tienen es que el bot es demasiado simple de mente como para saber cómo mantenerse fuera de la sección ==Enlaces externos==. Adopta un enfoque de todo o nada para agregar enlaces de archivo en un artículo. (También ha tenido problemas al afirmar incorrectamente que los sitios están inactivos).
Para mayor claridad, en la sección ==Enlaces externos==, cualquiera de estos es bueno (dependiendo de si el enlace está activo):Y
[https://example.com Sitio web oficial]
[https://web.archive.org/web/20240908173056/http://example.com/ Sitio web oficial] (archivado)
pero estos son malos:N
[Sitio web oficial de https://example.com] {{webarchive | url=https://web.archive.org/web/20240908173056/http://example.com/ |date=32 de octubre de 2023}}
{{cite web |title=Dominio de ejemplo |url=https://example.com |access-date=2024-09-08 |website=example.com |access-date=32 de octubre de 2023 |url-status=dead |archive-url=https://web.archive.org/web/20240908173056/http://example.com/ |archive-date=32 de octubre de 2023}}
En mi opinión, salvo raras excepciones, los enlaces muertos deberían eliminarse por completo de las secciones de "enlaces externos". – jacobolus (t) 23:50, 8 de septiembre de 2024 (UTC) [ responder ]
WP:ELDEAD está de acuerdo contigo. Tendemos a mantener copias archivadas de enlaces oficiales y, ocasionalmente, de algo que un editor pensó que era particularmente valioso, pero, por lo demás, normalmente deberían eliminarse o reemplazarse por otra cosa. WhatamIdoing ( discusión ) 23:55 8 sep 2024 (UTC) [ responder ]
@WhatamIdoing ese es un problema con la implementación del bot específico, no con la adición de enlaces de archivo.
@ Jacobolus Algunos enlaces deberían permanecer archivados (por ejemplo, los sitios web oficiales), algunos pueden (y deberían) repararse reemplazándolos con un enlace actualizado del que el robot no esté al tanto, otros deberían eliminarse. Sin embargo, esa determinación debe ser tomada por un humano, y marcar un enlace como inactivo es una muy buena manera de hacerles saber a los humanos que se debe tomar una determinación. Thryduulf ( discusión ) 00:07 9 sep 2024 (UTC) [ responder ]
Agregar {{ enlace inactivo }} no suele ser una buena idea para la sección == Enlaces externos ==. Sin embargo, en el caso específico de los enlaces WP:ELOFFICIAL para los que cree que un sitio web en funcionamiento es razonable (por ejemplo, una empresa que aún existe), ocasionalmente puede ser apropiado como una medida temporal (por ejemplo, hasta que alguien pueda encontrar el nuevo sitio web corporativo). WhatamIdoing ( discusión ) 01:05 9 sep 2024 (UTC) [ responder ]
¿Por qué no es una buena idea? Significa que un humano debe tomar una decisión sobre si eliminar el enlace, reemplazarlo con una alternativa que funcione o reemplazarlo con una versión archivada. Thryduulf ( discusión ) 01:14 9 sep 2024 (UTC) [ responder ]
Puedo entender el impulso de dejarle el problema a un hipotético futuro editor. Sin embargo, WP:ELDEAD dice que, en lugar de hacer eso, normalmente deberías actualizar o eliminar los enlaces inactivos ahora mismo. No necesitamos que un humano le pida a otro humano que tome una decisión. Simplemente, toma la decisión tú mismo. WhatamIdoing ( discusión ) 01:49 9 sep 2024 (UTC) [ responder ]
No estamos hablando de que los humanos agreguen la plantilla (aunque sería apropiado mientras hay una discusión en curso o mientras se intenta localizar la nueva ubicación), estamos hablando de que la agrega un bot. Thryduulf ( discusión ) 02:00, 9 de septiembre de 2024 (UTC) [ responder ]
¿Lo somos? Pensé que este hilo trataba principalmente sobre ediciones como esta, que no afectan a nada más allá de las etiquetas de referencia, y que estaba hablando de mi deseo de evitar que el bot haga ediciones como esta, que agregó:
{{Archivo web|url=https://web.archive.org/web/20180101214652/https://www.irishfa.com/ifa-international/squads/senior-men/chris-brunt |fecha=1 de enero de 2018}}
en la sección ==Enlaces externos==. Lo que considero inapropiado es la ubicación de esta edición, más que su contenido. Si esta edición se hubiera realizado dentro de las etiquetas de referencia, nunca me quejaría.
Entiendo que ediciones como esta (agregar la plantilla de enlace inactivo) no se pueden mejorar fácilmente, porque todo lo que el bot puede hacer, cuando no puede averiguar cómo solucionarlo, es ignorarlo o etiquetarlo. Tal vez prefiera ignorarlo en ese caso (el dominio funciona y el lector podría buscar desde allí; además, este bot específico a veces se bloquea cuando la URL funciona correctamente para los humanos), pero los bots tienen capacidades limitadas. WhatamIdoing ( discusión ) 02:41, 9 de septiembre de 2024 (UTC) [ responder ]
Las tres ediciones a las que haces referencia son ediciones de bots, por lo que no entiendo lo que intentas decir. Thryduulf ( discusión ) 04:05 9 sep 2024 (UTC) [ responder ]
Todos son del mismo bot.
La primera es compatible con las políticas, pero irrita a algunos editores cuando trabajan en un editor de wikitexto. Esa primera edición es el problema que se describe al principio de este hilo. No sé cómo resolver ese problema, o incluso si deberíamos resolverlo.
El segundo es una violación de la directriz de Wikipedia sobre enlaces externos y debería eliminarse. Sin embargo, según se informa, eso requerirá algo más que un pequeño esfuerzo de codificación.
El tercero quizás no se recomienda en WP:EL, pero no creo que podamos esperar de manera realista que el bot lo haga mejor que eso.
"principalmente sobre ediciones como esta ( special:diff/1244763493 )" – No, este no es el tipo de ediciones que estamos discutiendo aquí. Creo que esta edición –que consiste en agregar copias de seguridad de instantáneas archivadas para enlaces inactivos– está bien, y mi impresión es que casi todos aprecian este tipo de ediciones. – jacobolus (t) 06:07, 9 de septiembre de 2024 (UTC) [ responder ]
Aquí está uno de los enlaces de archivo posteriores a la podredumbre que agregó en esa diferencia: https://web.archive.org/web/20230418064632/https://www.nwslsoccer.com/players/christen-press/stats
Creo que eso es inútil. ¿Qué opinas? WhatamIdoing ( discusión ) 06:15 9 sep 2024 (UTC) [ responder ]
Esta URL no tiene una instantánea de Wayback funcional, por lo que no se debe agregar la instantánea como respaldo. (Y si la instantánea de Wayback hubiera sido agregada por un humano mientras la página aún estaba activa, aún estaríamos viendo el mismo contenido vacío, porque este sitio web le mostró una página rota al rastreador de Wayback y todavía me muestra páginas rotas cuando navego allí ahora). Si este enlace no muestra el contenido deseado, simplemente se debe eliminar como una cita, y un humano tendrá que encontrar una fuente de reemplazo que funcione.Cualquier persona que agregue enlaces de instantáneas de Wayback debería verificar dos veces cada enlace de instantánea y asegurarse de nunca agregar nada como esto a Wikipedia. (Por ejemplo, nunca se deben agregar copias de seguridad de Wayback de páginas de Google Books, porque también están rotas). Sin embargo, eso no está sucediendo actualmente, porque se están agregando enlaces de Wayback indiscriminadamente, de lo que me estoy quejando aquí. – jacobolus (t) 06:33, 9 de septiembre de 2024 (UTC) [ responder ]
Las copias de seguridad de páginas de Google Books de Wayback Machine nunca deberían añadirse, porque también están dañadas . Esto no siempre es correcto. Antes de 2020, se archivaba sin problemas, pero es posible que la nueva interfaz de usuario de Google Books haya dañado algo. Una revista que citamos extensamente fue eliminada de Google Books en 2022, lo que dejó cientos de enlaces 404. Y yo personalmente he corregido muchos de ellos usando Web Archive. Consulta la referencia 5 en Respect (álbum de Shaquille O'Neal) para ver un ejemplo. AstonishingTunesAdmirer 連絡16:23, 9 de septiembre de 2024 (UTC) [ responder ]
Sería mucho mejor reemplazar ese enlace por este: https://archive.org/details/bub_gb_jisEAAAAMBAJ/page/n186/mode/1up – jacobolus (t) 17:58, 9 de septiembre de 2024 (UTC) [ responder ]
Lamentablemente, este enlace infringe WP:LINKVIO , ya que el editor no cargó el escaneo en Internet Archive. AstonishingTunesAdmirer 連絡17:59, 9 de septiembre de 2024 (UTC) [ responder ]
Esta es una vista diferente del mismo escaneo de Google de la misma revista alojada en el mismo sitio web (archive.org), solo que pasa por su interfaz en lugar de una instantánea de Google Books. Si cree que cualquiera de los dos enlaces es una violación inaceptable de los derechos de autor, entonces el otro enlace seguramente tiene el mismo estado, y debería simplemente eliminar el enlace externo y dejar que los lectores encuentren una copia de la revista por su cuenta. (No tengo idea de por qué se eliminó la revista de Google Books, o cuál es el estado de los derechos de autor del escaneo alojado en IA). – jacobolus (t) 18:42, 9 de septiembre de 2024 (UTC) [ responder ]
El otro enlace seguramente tiene el mismo estado , ¿no es así? La política permite explícitamente una captura de pantalla de una página web, pero no he visto ninguna mención de volver a cargar el contenido de la página web. Estoy de acuerdo contigo, el escaneo completo es infinitamente más útil, pero quiero vincular fuentes que: 1) otro editor no eliminará en algún momento en el futuro (ahora mismo, esta área es mucho más gris que lo que se permite explícitamente); 2) Internet Archive en sí no eliminará en algún momento en el futuro (absolutamente lo hará en el momento en que los titulares de los derechos de autor lo noten y/o decidan que enviar una solicitud DMCA vale la pena el esfuerzo, pero es extremadamente improbable que vayan tras la copia archivada de Google Books). AstonishingTunesAdmirer 連絡19:40, 9 de septiembre de 2024 (UTC) [ responder ]
Si quieres seguir el ejemplo de "Sin embargo, si sabes o sospechas razonablemente que un sitio web externo contiene una obra que infringe los derechos de autor, no incluyas un enlace a esa copia de la obra sin el permiso del titular de los derechos de autor" y no crees que el actual propietario de los derechos de autor de Vibe haya dado permiso para que un escaneo se aloje en terceros, entonces probablemente deberías eliminar los enlaces. No tengo ni idea de si este conglomerado de medios que compró y cerró la revista hace 10 años y ahora la llama "una marca líder de entretenimiento y estilo de vida que ofrece contenido en múltiples plataformas de medios a una audiencia diversa en todo el mundo" (es decir, un elegante blog/boletín informativo por correo electrónico) va a intentar eliminar de Internet escaneos de revistas de hace 15 años. ¿Quizás? Tal vez Internet Archive debería restringir el acceso a revistas similares que aún están protegidas por derechos de autor mediante su función de "préstamo". Personalmente, yo solo incluiría un enlace a la copia de la IA, asumiendo que el editor resolverá las cosas con la IA, y si el libro luego termina no disponible o se elimina de la IA, Wikipedia podría simplemente quitar el enlace externo en ese punto y dejar que los lectores encuentren la revista por su cuenta si quieren verificar la cita. Tu experiencia puede variar. – jacobolus (t) 19:54, 9 de septiembre de 2024 (UTC) [ responder ]
Sinceramente, me quedé igual de desconcertado cuando lo eliminaron de Google Books. Intenté enviarles un correo electrónico para preguntarles si se trataba de algún error de su parte y si tenían pensado solucionarlo, pero parece que solo aceptan direcciones de correo electrónico corporativas. Parece que también son dueños de la revista Billboard , que todavía está disponible en Google Books (será un problema aún mayor si la eliminan), así que quién sabe. Pero creo que tienes razón, con el tiempo todas estas dejarán de estar disponibles. Una pena, de verdad. AstonishingTunesAdmirer 連絡20:51, 9 de septiembre de 2024 (UTC) [ responder ]
Yo también estoy de acuerdo en que deberíamos desalentar el archivo generalizado de enlaces activos. Da la sensación de que estamos añadiendo texto extraño a las referencias (y wikitexto extraño. Como en el caso de jacobolus , mi navegador se bloquea cuando activo el resaltado de sintaxis en páginas grandes; desearía que no lo hiciera) que es poco probable que se lean o se haga clic en ellas intencionalmente. Internet Archive ya nos está haciendo a nosotros y a nuestros lectores el gran servicio de archivar páginas enlazadas desde nuestros artículos. Si esos enlaces dejan de funcionar, un bot ya está haciendo el gran servicio de enlazar a una instantánea de la página de IA. No creo que los otros casos de uso mucho menos comunes (me atrevo a suponer) merezcan tanto desorden de texto. Estoy de acuerdo con jacobolus en que la escala de los enlaces parece publicidad del servicio que proporciona la IA. Ajpolino ( discusión ) 00:10, 9 de septiembre de 2024 (UTC) [ responder ]
(Para que conste: no uso resaltado de sintaxis y mi navegador nunca se ha bloqueado debido a un artículo de Wiki). – jacobolus (t) 01:01, 9 de septiembre de 2024 (UTC) [ responder ]
No me importan los enlaces de IA en Wikipedia:Plantillas de citas . Simplemente no quiero que obstruyan visiblemente los enlaces externos desde el punto de vista de un lector que no edita. WhatamIdoing ( discusión ) 01:07 9 sep 2024 (UTC) [ responder ]
De la descripción no se desprende que la incorporación de dichos enlaces sea indiscriminada. Mientras sea razonable creer que los enlaces de IA persistirán, cosa que creo que todos esperamos que suceda, existen numerosas y buenas razones para tener siempre una copia de seguridad de cualquier enlace externo que pueda respaldarse. BD2412 T 03:43, 9 de septiembre de 2024 (UTC) [ responder ]
Pero en realidad no estás argumentando que "la situación tal como se describe no es indiscriminada", sino que "no necesitamos discriminar". Lo digo con tanta precisión porque eso es lo que todos estamos discutiendo retóricamente, grados de totalidad versus discreción. Remsense ‥ 论03:48, 9 de septiembre de 2024 (UTC) [ responder ]
Eso no es lo que significa "indiscriminado". Si alguien creara un artículo titulado Lista de artículos de noticias interesantes archivados en Internet Archive y llenara esa lista con una selección aleatoria de unos pocos cientos de enlaces a Internet Archive, eso sería indiscriminado. Si alguien vinculara cada palabra de un artículo y proporcionara una referencia de diccionario en línea para cada palabra con un enlace a Internet Archive consiguiente, eso sería indiscriminado. Sin embargo, si alguien creara un artículo sobre un tema discreto y notable, incluidas referencias a fuentes en línea confiables relevantes para ese tema, y luego proporcionara enlaces a Internet Archive como enlaces de respaldo para ese conjunto de fuentes, eso sería lo opuesto a indiscriminado. Eso sería proporcionar enlaces de respaldo para que coincidan exactamente con las fuentes relevantes y apropiadas para el artículo. BD2412 T 12:38, 9 de septiembre de 2024 (UTC) [ responder ]
Hacer algo sin discriminar, como por ejemplo añadir enlaces de archivo a cada enlace sin considerarlos individualmente, es precisamente lo que significa la palabra "indiscriminado": sería un buen ejemplo para un diccionario. Hacer algo indiscriminadamente no significa necesariamente que sea malo, inapropiado, irrelevante o que implique malas intenciones. Por ejemplo, un padre podría decirle indiscriminadamente e incondicionalmente a cada uno de sus hijos que los ama. (Aunque personalmente creo que añadir enlaces de archivo indiscriminadamente es malo e inapropiado, por eso planteé el tema aquí). – jacobolus (t) 14:36, 9 de septiembre de 2024 (UTC) [ responder ]
Bueno, eso es como decir "conduzco sin hacer distinción" en el sentido de "me detengo sin distinción en todas las señales de stop". BD2412 T 20:56, 9 de septiembre de 2024 (UTC) [ responder ]
Yo diría que, fundamentalmente, si en una publicación que se actualiza con frecuencia, como un periódico o una revista (o cualquier otra cosa que se espera razonablemente que tenga contenido actualizado dentro de un mes o dos), IABot usa una fecha de archivo que no coincide exactamente con la fecha de acceso, y el editor no verifica que el contenido fuente todavía esté verificado por esa copia archivada (o que el texto archivado todavía coincida), entonces se trata de una edición indiscriminada sujeta a preocupación.
Pero literalmente nadie más aquí parece tener la misma preocupación que yo en cuanto a lo que importa. ¯\_(ツ)_/¯ SamuelRiv ( discusión ) 21:07 9 sep 2024 (UTC) [ responder ]
Quiero decir, es simplemente un tema multifacético sobre el cual diferentes personas han articulado diferentes aspectos. Remsense ‥ 论21:15, 9 de septiembre de 2024 (UTC) [ responder ]
@ SamuelRiv : Estoy de acuerdo contigo, y más arriba, Blueboar planteó el mismo problema: si la fuente original se cae, es importante saber por qué, ¿es porque se retiró el artículo? Si es así, simplemente cambiar al enlace de archivo no es bueno. Si se actualizó el original, de manera similar, usar el enlace de archivo obsoleto no es bueno. Por lo tanto, la indiscriminación es un problema. (Y hay otros problemas indiscriminados, como archivar páginas que no tiene sentido archivar, como las páginas de YouTube [que no archivan el video] y las páginas de Google Books [que no archivan el libro]). Levivich ( discusión ) 17:15, 10 de septiembre de 2024 (UTC) [ responder ]
Si el contenido del artículo cita una fuente en una fecha específica, entonces un enlace de archivo también debería estar en esa fecha, independientemente de si esa fuente fue actualizada o retractada. Idealmente, la persona que agrega el enlace de archivo también verificaría si la fuente y el contenido aún coinciden (V), y en el proceso también verificaría el estado de la fuente (RS) y, en consecuencia, actualizaría la fecha de acceso. Pero las personas que realizan un trabajo de mantenimiento de marcado de amplio alcance casi por definición no se detienen cada vez para realizar un trabajo de mantenimiento de contenido de grano fino. Si el contenido del artículo coincide con la fuente en su fecha de acceso, entonces está correctamente citado. Si un editor agrega una versión actualizada del artículo sin cambiar el contenido , entonces esa es una forma en que ocurre la deriva de citas, y puede fallar muy pronto V. SamuelRiv ( discusión ) 17:27, 10 de septiembre de 2024 (UTC) [ responder ]
De hecho, el objetivo de las referencias es garantizar que nuestros artículos sean verificables, no que sean correctos. El hecho de que un artículo haya sido retractado no significa que lo que lo citábamos no sea correcto (depende de por qué lo estamos citando y por qué fue retractado) y, en algunos casos, aún querremos citarlo porque su retractación es notable. Thryduulf ( discusión ) 20:33 10 sep 2024 (UTC) [ responder ]
Si estuviéramos haciendo planificación civil, podríamos usar ese lenguaje y sonaría menos extraño en contexto, sí. Remsense ‥ 论21:13, 9 de septiembre de 2024 (UTC) [ responder ]
Levanto la mano para expresar mi acuerdo con Remsense en general. Mi objeción es que los enlaces de archivo innecesarios son una pérdida de tiempo para el lector. Si la IA fuera rápida, sería una cosa, pero no lo es en absoluto. --jpgordon 𝄢𝄆𝄐𝄇 04:39, 9 de septiembre de 2024 (UTC) [ responder ]
Ésta es una distinción que debemos tener clara.
Algunos editores se oponen a mostrar enlaces de archivo cuando el original funciona perfectamente.
Algunos editores se oponen a las cadenas enormes y largas de wikitexto, incluso si los lectores nunca las ven.
El primer grupo estaría perfectamente satisfecho si este wikitexto: {{cite book |url=https://example.com |title=Example Domain |website=example.com |access-date=2 September 2023 |archive-url=https://web.archive.org/web/20240908173056/http://example.com/ |archive-date=8 September 2024 |url-status=live}}estuviera en el artículo, siempre y cuando todo lo que vieran los lectores fuera un simple "Dominio de ejemplo". example.com . Consultado el 2 de septiembre de 2023 .
El segundo grupo no estaría contento con esa larga cadena de wikitexto sin importar lo que vieran los lectores. Discusión:Donald Trump/Consenso actual , por ejemplo, rechaza la inclusión de URL de archivo para fuentes activas actualmente (ítem 25). WhatamIdoing ( discusión ) 05:08 9 sep 2024 (UTC) [ responder ]
Thryduulf también ha destacado anteriormente que "trabajar para mí ahora mismo" no siempre es suficiente para "trabajar bien", como un punto adicional. Remsense ‥ 论05:25, 9 de septiembre de 2024 (UTC) [ responder ]
En general, apoyo el archivado de tantas URL de referencia como sea posible en Wikipedia. No creo que el "desorden" afecte mucho a los lectores, ya que la sección de referencias no está pensada para leerse como prosa. Creo que los lectores obtienen con facilidad toda la información útil de las citas que consultan, suponiendo que las citas estén formateadas correctamente. La presencia de texto como "Archivado desde el original el 26 de diciembre de 2021", que suele presentarse al final de la cita o cerca de él, no es excesivamente gravoso para los lectores a quienes no les importan los enlaces de archivo, y obviamente es útil para quienes sí lo hacen.Creo que el consenso local debería poder determinar que el estilo de cita de un artículo determinado no debe utilizar enlaces de archivo para URL activas. Actualmente, es el caso en Donald Trump , principalmente por razones de tamaño. Los creadores de artículos que prefieran un texto menos relacionado con el archivo deberían poder establecer ese estilo y no permitir que se anule a menos que haya una discusión que conduzca a un consenso para su inclusión. Firefangledfeathers ( discusión / contribuciones ) 12:23, 9 de septiembre de 2024 (UTC) [ responder ]
¿Cómo los eliminamos una vez que están dentro? ¿Manualmente? Me gustaría esta idea, pero en la práctica es un hecho consumado. Una vez que alguien presiona el botón, los enlaces quedan ahí para quedarse, a menos que otra persona elimine manualmente cada uno de ellos. Levivich ( discusión ) 14:49 9 sep 2024 (UTC) [ responder ]
Esta diferencia muestra que alguien simplemente revirtió la adición. WhatamIdoing ( discusión ) 16:05 9 sep 2024 (UTC) [ responder ]
Sí, pero revertir la adición no funcionará una vez que haya pasado el tiempo y haya ediciones intermedias. Levivich ( discusión ) 17:16 10 sep 2024 (UTC) [ responder ]
Creo que es generalmente cierto que los "estilos establecidos" necesitan cierta vigilancia para mantenerse y que el trabajo necesario es mínimo si las desviaciones se detectan a tiempo. Creo que la única excepción podría ser el estilo de fecha, ya que un script puede semiautomatizar los cambios entre estilos. Firefangledfeathers ( discusión / contribuciones ) 18:30, 10 de septiembre de 2024 (UTC) [ responder ]
Me resulta alucinante que la gente se obsesione con el formato de las fechas. Las fechas deberían almacenarse de alguna manera independiente del estilo y convertirse automáticamente al estilo de visualización preferido en el momento de la visualización. RoySmith (discusión) 18:41 10 sep 2024 (UTC) [ responder ]
Creo que convertir cada fecha en una plantilla podría echar por tierra el trabajo de limpieza que la gente espera que se haga aquí. Firefangledfeathers ( discusión / contribuciones ) 18:54, 10 de septiembre de 2024 (UTC) [ responder ]
Lo que es realmente alucinante es que ya funciona de esa manera. Si se guarda una fecha como 2024-09-10, se mostrará como 12 de septiembre de 2024 o 12 de septiembre de 2024, según el artículo y las preferencias del usuario. Aun así , la gente discute sobre el código subyacente y lo cambia. Levivich ( discusión ) 18:55 10 sep 2024 (UTC) [ responder ]
Ojalá pudiéramos estar de acuerdo en que los formatos de fecha compatibles con ISO que no sean ambiguos, como 2024-08, se puedan mostrar como "agosto de 2024" en lugar de mostrar un mensaje de error en rojo. (Sí, 2001-02 es ambiguo. Pero la mayoría no lo son, y los ambiguos son fáciles de predecir). WhatamIdoing ( discusión ) 19:06 10 sep 2024 (UTC) [ responder ]
Las personas deberían agregar, por ejemplo, al principio de un artículo y luego usar las fechas del formato dentro de las plantillas de citas; se formatearán automáticamente con el estilo correcto, incluso si alguien agrega una plantilla de cita con parámetros de fecha en otro formato. – jacobolus (t) 18:56, 10 de septiembre de 2024 (UTC) [ responder ] {{use dmy dates|cs1-dates=sy|date=October 2024}} 2024-10-01
Jeje. Siempre supuse que así era como funcionaba, pero luego comencé a asumir que mi comprensión era incorrecta cuando los revisores comenzaron a insistir en que necesitaba cambiar las fechas en mis plantillas en aras de la uniformidad. Dejé de discutir y simplemente los hice felices. Tal vez la próxima vez me oponga más. RoySmith (discusión) 19:36 10 sep 2024 (UTC) [ responder ]
He mencionado esto varias veces a lo largo de los años. Básicamente, IABot ya está creando enlaces de archivo para artículos añadidos a citas sin necesidad de ejecutar IAbot manualmente. Los almacena en una base de datos fuera de la wiki y los añade según sea necesario (no sé exactamente qué busca para hacer esto). Mi perspectiva es que, si bien hay una desventaja obvia de aumentar el tamaño de un artículo, hay algunas buenas razones para pecar de exceso de incluir los enlaces de archivo en los artículos. Es decir, porque lo que ocurre fuera de la wiki es opaco y los robots de la wiki tienen una tendencia a detenerse sin previo aviso, y también porque proporciona un enlace para que un lector experto evite un muro de pago (no es que esta razón deba documentarse en ningún lado, ojo: IA está teniendo suficientes problemas últimamente). De todos modos, este sistema de usuarios que "rescatan" fuentes que no necesitan ser rescatadas no es genial. Podríamos utilizar una RfC que simplemente pregunte "todos los enlaces deben tener un enlace de archivo por defecto". Si es así, debería hacerlo un bot en lugar de que usuarios aleatorios los agreguen de forma aleatoria. Si no, tendremos que decidir si se debe prohibir o dejarlo para cada caso particular. Si se trata de un caso particular, ¿cuáles son las consideraciones? También agregaré que lo que más me molesta de todo esto no es tanto el tamaño de la adición, sino cómo esa adición interfiere con las herramientas que tenemos para determinar rápidamente quiénes son los contribuyentes principales de un artículo.Las rododendritas hablan\\ 17:47, 9 de septiembre de 2024 (UTC) [ responder ]
Si hay un interés real, podríamos realizar un experimento interno sobre los clics en los enlaces de un par de artículos para ver si hay un aumento significativo en la cantidad de personas que ven las fuentes cuando el enlace del archivo está disponible en comparación con cuando no lo está. Eso brindaría el beneficio de mostrar los enlaces a URL activas, al menos.
Si hay que tener en cuenta un costo/beneficio del rendimiento del lado del cliente por página, no sé si se puede mitigar de forma razonable con algo como pasar un parámetro iarchive-id en lugar de las URL completas, o bien mostrar solo las partes activas de las citas en dispositivos móviles y conexiones limitadas, o mantener la sección de citas sin expandir excepto en los clics (como hacen varios editores académicos). No creo que detener algunos caracteres aquí y allá (que el tiempo impondrá en una página eventualmente) aborde el problema legítimo del rendimiento del lado del cliente que la gente está planteando.
en Rhododendrites (arriba): dado que los bots están marcados en las ediciones, sus herramientas deberían descontar las ediciones de bots, ¿no?
Estoy más preocupado por los ejemplos dado que parece que IABot está agregando enlaces de archivo que no cumplen con |access-date=. Parece que este debería ser el comportamiento predeterminado (en lugar de agregar el último enlace de archivo), pero no estoy seguro de si es así según la documentación de IABot. No estoy seguro de poder determinar a partir de la fuente de la API principal si ese ya es el valor predeterminado, sin usar la herramienta yo mismo. ¿Alguien puede confirmarlo? SamuelRiv ( discusión ) 19:21, 9 de septiembre de 2024 (UTC) [ responder ]
Entiendo que IABot utiliza el archivo más cercano en el tiempo a la fecha de acceso del artículo, si existe. El archivo más cercano puede ser bastante diferente a la fecha de acceso en algunos casos. Cuando no hay una fecha de acceso (por ejemplo, para las URL simples), creo que utiliza el archivo más reciente disponible. Thryduulf ( discusión ) 19:37, 9 de septiembre de 2024 (UTC) [ responder ]
Según el doi : 10.1145/3366423.3380300, el 99,7 % de los lectores no hace clic en ningún enlace de las referencias. Por ejemplo, en el informe de tráfico de The Signpost se muestran algunos ejemplos :
Es posible que Vinesh Phogat haya tenido alrededor de 5.500 personas que hicieron clic en un enlace de referencia durante el último año. Hay 90 referencias, de las cuales 66 tienen enlaces de archivo. Si asumimos condiciones similares a las del pollo esférico sin fricción , eso podría representar un promedio de 11 oportunidades por día para elegir entre un enlace archivado y un enlace actual.
Es posible que Noah Lyles haya tenido alrededor de 8000 personas haciendo clic en un enlace de referencia durante el último año. Hay 68 referencias, de las cuales 9 tienen enlaces de archivo. Eso podría representar alrededor de 3 oportunidades al día para que las personas elijan entre un enlace archivado y un enlace actual.
Armand Duplantis probablemente haya tenido alrededor de 7000 personas que hicieron clic en un enlace de referencia durante el último año. Hay 79 referencias, de las cuales 52 tienen enlaces de archivo. Eso significa que alguien tuvo que elegir entre un enlace archivado y un enlace actual unas 12 veces al día.
Se trata de páginas con un tráfico muy alto (sobre todo durante el último mes), y registrar tan solo 1000 eventos llevaría más de un mes. Aunque creo que, en última instancia, sería factible comprobar si los enlaces archivados animan a la gente a abrir una fuente, no quiero que nadie piense que esto sería rápido y fácil. Creo que es más probable que se trate de palabras como long-term , perseverance y (desafortunadamente) indeterminate results . WhatamIdoing ( discusión ) 20:27 9 sep 2024 (UTC) [ responder ]
Una captura de pantalla emergente de referencia que acabo de tomar para ilustrar estoHay un problema en el que me encantaría que alguien se pusiera manos a la obra con la UX. ¿Cómo podemos hacer que los usuarios lean las referencias? @ Valjean y algunos de los otros editores del artículo de Trump estaban experimentando con objetivos de referencia principales. Me pregunto si Wikipedia debería invertir más en gadgets de superposición de notas al pie y similares. Utilizo algún tipo de gadget o script de usuario que hace que aparezca una ventana emergente de vista previa al pasar el mouse por encima. Funciona para los enlaces de notas al pie, pero solo obtienes una superposición que te muestra el pie de página. Podría ser mucho más grande, más brillante y con más información sobre la referencia. Además, en teoría, podría mostrarte otras páginas que citan esa fuente o información general sobre su confiabilidad, etc. También hay un excelente script de usuario de @ Novem Linguae que agrega resaltado de color a las referencias. Andre 🚐 20:37, 9 de septiembre de 2024 (UTC) [ responder ]
Creo que una de las ideas consideradas en Vector 2022 fue tener las referencias mostradas en el lado derecho (en todo ese espacio en blanco "innecesario", si tienes una pantalla más ancha y no se expande al ancho completo).
Pero: ¿por qué "obligar a los usuarios a leer las referencias" debería ser uno de nuestros valores? Además, ¿impulsar eso alteraría el orden establecido en términos de WP:NONENG y WP:PAYWALL ?
Hoy he buscado un artículo de Wikipedia. Necesitaba recordarme que Bratislava estaba realmente en Eslovaquia y que no me había olvidado de ello. ¿Crees que hubiera sido mejor para mí leer las referencias? No creo. WhatamIdoing ( discusión ) 20:43 9 sep 2024 (UTC) [ responder ]
No me gusta el espacio en blanco adicional, me gusta más el enfoque emergente. El espacio en blanco vectorial era un desastre en mi monitor hasta que lo solucionaron y ofrecieron una opción ajustable para una vista más amplia. Usé Monobook durante un tiempo hasta que lo solucionaron.
Creo que hacer que los usuarios lean las referencias es fundamental para la misión de Wikipedia y la verificabilidad. Creo que la accesibilidad a los artículos de revistas de acceso abierto y la alfabetización de contenidos son clave para la misión de la educación y para inspirar el pensamiento crítico. Como todo el mundo sabe, Wikipedia NO es fiable. Como alguien que busca información un poco menos común, cada vez que miras un artículo no sabes si todo lo que hay en él es correcto, especialmente las afirmaciones controvertidas, a menos que compruebes las referencias. Los engaños y el vandalismo existen debido al modelo wiki, y la cadena de corroboración es clave para que todo funcione. Claro, buscar dónde está Bratislava no va a requerir mirar las referencias. He llegado a ver a Wikipedia básicamente como una fuente pública de información, mientras que una gran cantidad de material valioso está bloqueado detrás de muros de pago o archivos privados de difícil acceso. El objetivo de Wikipedia es desbloquear la información del mundo y ponerla a disposición. Andre 🚐 20:51, 9 de septiembre de 2024 (UTC) [ responder ]
No estoy de acuerdo en que hacer que los usuarios lean las referencias sea un objetivo clave. Si lo fuera, la mejor manera de lograrlo no sería crear artículos de enciclopedia, sino un índice de referencias. Y si bien ese puede ser un trabajo de referencia útil para un segmento de los lectores actuales de Wikipedia, no tendría el mismo atractivo general que una enciclopedia. isaacl ( discusión ) 19:07 10 sep 2024 (UTC) [ responder ]
WP:V significa que la gente debería comprobar las referencias. Está en la primera línea. La gente que usa la enciclopedia puede comprobar que la información proviene de una fuente fiable. Si nadie las lee ni las comprueba, ¿qué sentido tiene tenerlas? Un índice de referencias simples sería, supongo, Wikisource . Lo cual también es muy valioso. Hay algunos documentos ucranianos antiguos muy buenos allí. ¿O podríamos ser Nupedia o World Book y simplemente tener un grupo de magos expertos en los que confiamos implícitamente para crear artículos veraces? Pero yo diría que eres básicamente un analfabeto informativo si lees Wikipedia y confías en el texto implícitamente sin comprobar las referencias. De hecho, me sorprende que alguien se oponga a la importancia de las referencias. ¡Podría decirse que son más importantes que el texto en sí! Andre 🚐 19:34, 10 de septiembre de 2024 (UTC) [ responder ]
Te estás equivocando con la distinción básica entre "puede" y "se espera" . Recuerdo mi yo anterior a la edición y, literalmente, casi nunca revisaba las referencias. Remsense ‥ 论20:11, 10 de septiembre de 2024 (UTC) [ responder ]
En mi humilde opinión, estoy hilando un poco los detalles semánticos. No recuerdo haber leído y no haber sido editor, pero antes de serlo no había referencias y Wikipedia era un montón de basura de artículos de Pokémon e investigaciones originales según los estándares actuales. Aun así, consideraría que es un problema que vale la pena resolver el que no facilitemos a quienes no son editores la verificación de las cosas. Andre 🚐 21:53, 10 de septiembre de 2024 (UTC) [ responder ]
Insistir en que los lectores deben leer las referencias es una fantasía absurda. La gran variedad de lectores hará lo que quiera, lo que en su mayoría no implicará leer atentamente los detalles del artículo, y mucho menos buscar fuentes académicas de pago para verificar las referencias de cada afirmación. El trabajo de los artículos es satisfacer las necesidades de los lectores y responder a sus preguntas, lo que significa hacer afirmaciones que sean generalmente precisas, reflejen el consenso de los expertos y no hayan sido inventadas por un wikipedista seudónimo. "¿Qué sentido tiene tener [referencias]?" El propósito es que los lectores y otros editores puedan verificarlas si lo desean o lo necesitan por alguna razón, como se indica claramente en el texto que citaste. – jacobolus (t) 22:37, 10 de septiembre de 2024 (UTC) [ responder ]
Creo que hay algo entre " debe " y " debería ". Además, creo que estamos de acuerdo en que alguien debe comprobarlas, pero no todo el mundo. Ningún lector está obligado a comprobar las referencias, pero realmente debería hacerlo . Un muro de pago es un obstáculo, pero un lector motivado puede pagar. Afortunadamente, la mayoría de los artículos tienen al menos algunas referencias que no están sujetas a muro de pago. En cualquier caso, no insistía en que los lectores debieran leer las referencias, estaba abogando por mejorar la experiencia de usuario para que fuera más probable que lo hicieran. Andre 🚐 00:07, 11 de septiembre de 2024 (UTC) [ responder ]
Ningún lector está obligado a comprobar las referencias, pero realmente debería hacerlo . Eso es simplificar demasiado. Todo lector debería comprobar las referencias asociadas a cada afirmación para la que "probablemente correcto" no es lo suficientemente bueno para su caso de uso. Si necesita saber con certeza que el punto de fusión de una aleación determinada es mayor que 3000 K, entonces debería comprobar la referencia para eso, pero decir que "deberían comprobar la referencia" para saber que se inventó en Francia en la década de 1990 es incorrecto. Por el contrario, alguien que esté compilando un informe sobre la historia de la metalurgia europea debería comprobar la última referencia, pero "tiene un punto de fusión alto" es probablemente tanto detalle como sea relevante para ellos (si no más) y no necesitan verificar que sea 4112,88 K. Thryduulf ( discusión ) 00:22, 11 de septiembre de 2024 (UTC) [ responder ]
No iba a entrar aquí, pero no puedo resistirme más. Nuestra interfaz actual para presentar referencias apesta. Tomemos el caso de John Rolph (el TFA de hoy). Hago clic en la primera cita. Eso me lleva a una lista de referencias, resaltando "^ abc Johnson 1989, p 223". Así que supongamos que descubro que el resaltado significa "haga clic aquí" y lo hago. Esto me lleva a la sección "Obras citadas", con "Johnson, JK (1989). Becoming Prominent: Regional Leadership in Upper Canada, 1791–1841. Kingston: McGill-Queen's University Press. ISBN 0-7735-0641-1." resaltado. Así que, OK, hago clic en el primer enlace, que me lleva a McGill–Queen's University Press . En este punto, siento que estoy jugando a una búsqueda del tesoro y que me he equivocado de camino en alguna parte. ¿Por qué hacer clic en "[1]" no me llevó directamente a la fuente?
Sí, lo sé, resulta que [1] es una fuente que no está en línea, pero [2] sí lo está y se requiere el mismo proceso de tres clics. Al menos en ese caso, llego a una página de NCBI donde (con un cuarto clic) puedo acceder a un PDF de la fuente. Excepto que, en este momento, he perdido la noción del hecho de que una de las paradas intermedias en esta búsqueda del tesoro en particular decía "p. 17", así que tengo que volver atrás y encontrarla de nuevo. Seguro que no se lo ponemos fácil a nuestros lectores. RoySmith (discusión) 00:30 11 sep 2024 (UTC) [ responder ]
Exactamente, +1 Andre 🚐 00:40, 11 de septiembre de 2024 (UTC) [ responder ]
m:WMDE Technical Wishes/Sub-referenciación#La sub-referenciación, en pocas palabras, es una forma de reducir el primer paso. En lugar de ir a " abc Johnson 1989, p 223" y tener que hacer clic nuevamente para encontrar el nombre del libro, lo llevaría a una lista unificada que podría verse así:
Johnson, JK (1989). Deviniendo prominente: liderazgo regional en el Alto Canadá, 1791-1841. Kingston: McGill-Queen's University Press. ISBN 0-7735-0641-1.
a Página 223.
b Página 429.
Creo que será útil para algunos artículos que contengan muchos libros. WhatamIdoing ( discusión ) 01:21 11 sep 2024 (UTC) [ responder ]
Estoy de acuerdo en que sería útil, pero iría más allá. ¿Qué hay de mi idea de superponer la información sobre herramientas al pasar el mouse sobre la lista de referencias? Además, hay un error en el editor visual que acabo de reproducir. Si hace clic en la lista de referencias, se le ofrece la posibilidad de "reemplazar la referencia". Esto solo termina agregando una referencia al final de la página. [1] El enlace "reemplazar la referencia" solo funciona si hago clic en la nota al pie en la parte superior de la página, no en la línea de la lista de referencias. Avíseme si desea una captura de pantalla o si debo decírselo a alguien. ¿Aún le gusta recibir mis informes de errores? Andre 🚐 01:28, 11 de septiembre de 2024 (UTC) [ responder ]
Durante años, las citas se han abierto al pasar el cursor sobre una imagen o con el ratón, y no utilizo ninguna configuración personalizada. Cuando pasas el cursor sobre el texto azul en la ventana emergente de [1] sobre John Rolph , aparece una segunda ventana emergente con la cita completa, tal como se implementó en {{ harvc }} y las plantillas de referencias relacionadas.
No estoy seguro de qué tan fluido es esto para dispositivos móviles, pero el desplazamiento debería funcionar para cualquier persona que use una computadora de escritorio (a menos que las referencias en el artículo no hayan sido creadas con plantillas, lo que técnicamente todavía está permitido en MOS). SamuelRiv ( discusión ) 01:48, 11 de septiembre de 2024 (UTC) [ responder ]
Hmm, tienes razón, fue mi error. Debería desinstalar cualquier gadget que tenga, porque parece estar integrado en la apariencia actual de Vector. Buena idea. Sigo pensando que esas ventanas emergentes podrían ser más grandes y más útiles, pero ¡oye! (Por cierto, si alguien quiere saber, la antigua era Wikipedia:Tools/Navigation_popups , la nueva es "Habilitar vistas previas de página" y "Habilitar vistas previas de referencia" en "Preferencias de apariencia" en "Apariencia") Andre 🚐 01:57, 11 de septiembre de 2024 (UTC) [ responder ]
Envía un mensaje a @ Trizek (WMF) y a @ PPelberg (WMF) para obtener el informe de error de Andrevan, y también al resto de la discusión si están interesados. WhatamIdoing ( discusión ) 01:52 11 sep 2024 (UTC) [ responder ]
"Nuestra interfaz de usuario actual para presentar referencias es pésima. Tomemos el caso de John Rolph (el candidato a la presidencia de hoy). Hago clic en la primera cita. Eso me lleva a una lista de referencias, resaltando... Supongamos que descubro que el resaltado significa 'haga clic aquí' y lo hago. Esto me lleva a la sección 'Obras citadas', con... resaltado". Aquí, coloco el cursor sobre el superíndice de la nota al pie, lo que hace aparecer un pequeño cuadro, y luego coloco el cursor sobre el nombre del autor + año, lo que hace aparecer otro cuadro con los metadatos del libro. No hay ningún enlace externo involucrado porque se trata de un libro, no de un sitio web. Si hago clic en el enlace del ISBN, puedo llegar a una página que me ayuda a encontrar el libro en una biblioteca local. – jacobolus (t) 02:41, 11 de septiembre de 2024 (UTC) [ responder ]
No creo que funcione si tienes WP:NAVPOPS habilitado, que ningún lector que haya cerrado sesión puede usar, pero mucha gente en esta discusión sí lo hace. WhatamIdoing ( discusión ) 02:57, 11 de septiembre de 2024 (UTC) [ responder ]
No conozco los detalles, pero las ventanas emergentes de notas al pie funcionan bien cuando no estoy conectado. – jacobolus (t) 03:01, 11 de septiembre de 2024 (UTC) [ responder ]
Cuando no estás conectado, estás usando mw:Page Previews. Es una especie de versión simplificada (pero más bonita y compatible con WMF) de WP:NAVPOPS . WhatamIdoing ( discusión ) 03:03 11 sep 2024 (UTC) [ responder ]
No tengo habilitado el gadget de ventanas emergentes de navegación. Las ventanas emergentes de notas al pie siguen funcionando bien. – jacobolus (t) 03:11, 11 de septiembre de 2024 (UTC) [ responder ]
Eso es lo esperado. No funcionan en citas de tipo {{ sfn }} si tienes habilitado NAVPOPS. La herramienta de WMF hace el truco de pasar el cursor una y otra vez. NAVPOPS no lo hace. WhatamIdoing ( discusión ) 03:28 11 sep 2024 (UTC) [ responder ]
Sí, es una gran diferencia. Aunque estoy volviendo a habilitar NAVPOPS porque la herramienta WMF no usa una ventana emergente para las páginas de usuario y NAVPOPS tiene botones adicionales para acciones y otras cosas. Andre 🚐 03:41, 11 de septiembre de 2024 (UTC) [ responder ]
Yo tomé la misma decisión. Es una cuestión de compromiso. WhatamIdoing ( discusión ) 03:50 11 sep 2024 (UTC) [ responder ]
Existe una diferencia entre "puede comprobar" y "debe comprobar". Si debe comprobar o no depende del uso que le vaya a dar a la información. Si está haciendo algo crítico para la seguridad, o una investigación académica, o algo por el estilo, entonces definitivamente debería comprobar las referencias relevantes para su tema, pero incluso en ese caso no necesita comprobar todas las referencias. Por ejemplo, si está interesado en el punto de fusión de los elementos, debería comprobar las referencias para los puntos de fusión, pero comprobar las referencias para la fecha de descubrimiento solo le haría perder el tiempo.
Para muchos propósitos, se puede confiar en que Wikipedia es lo suficientemente buena. Por ejemplo, el otro día busqué información sobre cuándo Alun Michael representó a Swansea en el parlamento. Si Wikipedia estaba equivocada, entonces una pregunta en un cuestionario que responderán, como máximo, 5 personas también estará equivocada. Thryduulf ( discusión ) 20:26 10 sep 2024 (UTC) [ responder ]
Yo diría que simplemente por higiene intelectual y edificación epistemológica. La gente no debería confiar ciegamente en nada escrito en Wikipedia sin comprobar las referencias e incluso, a veces, el historial de la página. He encontrado errores muchas veces. Es la naturaleza de una wiki. En realidad, me sorprende un poco encontrar a tanta gente defendiendo la idea de que las referencias son solo una cuestión de información confidencial. Andre 🚐 21:56, 10 de septiembre de 2024 (UTC) [ responder ]
Nadie defiende la idea de que las referencias son solo una cuestión de información confidencial y, si crees que lo son, entonces has malinterpretado muy seriamente lo que la gente está diciendo. Las referencias son de vital importancia, pero eso no significa que todos deban verificar cada referencia cada vez. Hay más hechos en Wikipedia que son correctos que hechos en Wikipedia que son incorrectos. Eso significa que cualquier hecho dado en Wikipedia probablemente sea cierto. Para muchos propósitos, probablemente sea cierto es suficiente. Las referencias existen para aquellas situaciones en las que no lo son. Thryduulf ( discusión ) 23:17 10 sep 2024 (UTC) [ responder ]
Supongo que el "it" en "Las referencias existen para aquellas situaciones en las que no lo son" es "probablemente sea cierto". La primera vez que lo leí, pensé brevemente que querías decir que las referencias existen para cuando el artículo de Wikipedia está equivocado, y pensé que no era posible que dijeras eso. WhatamIdoing ( discusión ) 23:37 10 sep 2024 (UTC) [ responder ]
Perdón por la ambigüedad, quise decir "Existen referencias para aquellas situaciones en las que probablemente sea cierto no es suficiente". Thryduulf ( discusión ) 23:47 10 sep 2024 (UTC) [ responder ]
Supongo que es bastante probable que la mayoría de las afirmaciones en Wikipedia sean verdaderas, es decir, mucho más de la mitad, pero no está claro si eso significa que cualquier afirmación dada puede ser verdadera, especialmente en temas oscuros. Hay engaños, información incorrecta, fuentes mal caracterizadas, vandalismo, y si bien hay un aspecto eventual de esto, el vandalismo y los engaños no siempre se descubren de inmediato, y algunos duran años, y algunos artículos no se vigilan lo suficiente y se encuentran sutilmente vandalizados. Yo diría que probablemente esté más cerca del 80% que del 99% o más . Una declaración WP:BLUESKY es básicamente lo que he visto en el discurso de Wiki llamar una declaración obvia. Pero para cualquier declaración no obvia, como lector que lee el artículo, la probabilidad de que un hecho sea definitivamente cierto depende más de cuán recientemente se haya editado extensamente y cuán alto sea el tráfico del artículo. Esto también es algo que los usuarios deberían poder saber y verificar, y yo diría que es parte de una misión de alfabetización informativa alentar la aparición de este tipo de metadatos críticos. Por lo tanto, consultar el historial del artículo y las referencias debería ser, en mi humilde opinión, una actividad o un trabajo de primera clase que deben realizar incluso los usuarios que no hayan iniciado sesión. Andre 🚐 00:20, 11 de septiembre de 2024 (UTC) [ responder ]
Nuevamente, todo depende de qué nivel de precisión sea "suficientemente bueno" para el motivo por el que estás consultando Wikipedia, y eso varía enormemente. Un 51 % de probabilidades de ser correcto es suficiente para algunos usos, un 99 % es insuficiente para otros. Thryduulf ( discusión ) 00:28 11 sep 2024 (UTC) [ responder ]
No estoy discutiendo la importancia de las referencias (y probablemente soy más intransigente que muchos editores en cuanto a incluir las referencias de inmediato en lugar de dejar que alguien más lo haga). Solo digo que "hacer que los usuarios lean las referencias" no es un objetivo clave. La política de verificabilidad es para los editores; no significa que un objetivo clave de Wikipedia sea que todos sus lectores comprueben cada referencia. Por supuesto, deberían ser convenientes para todos los que quieran leerlas. isaacl ( discusión ) 22:05 10 sep 2024 (UTC) [ responder ]
No creo que nadie quiera dificultar deliberadamente que otros (lectores o editores) comprueben las fuentes, pero en términos de cómo se utilizan realmente los artículos, creo que es razonable estimar que es al menos 300 veces más importante que el contenido del artículo sea correcto que permitir que alguien acceda a una fuente.
En mi lista de cosas por hacer, quiero actualizar Sensibilidad química múltiple . Entre las opciones que tengo que tomar están: ¿elegir fuentes con Texto completo en la red o elegir un libro de texto de la facultad de medicina con una alta calificación? Elegí la segunda opción, aunque básicamente nadie podrá verificar la fuente (cuesta 120 dólares estadounidenses, o seguir mi ejemplo y utilizar el préstamo interbibliotecario ), y aunque pueda pasar los próximos años recibiendo solicitudes de citas de "solo un párrafo más" de editores a quienes no les gusta lo que dice. Pero es la mejor fuente para la mayor parte de la información del artículo. WhatamIdoing ( discusión ) 22:35 10 sep 2024 (UTC) [ responder ]
Claro, cuando digo "cómodo de usar" me refiero a que el sistema de citas de Wikipedia debería permitir ver las citas y seguir los enlaces proporcionados de manera cómoda. No me refería a cómo se deben seleccionar las referencias. isaacl ( discusión ) 23:55 10 sep 2024 (UTC) [ responder ]
Creo que si acordamos que conseguir que los lectores lean las fuentes citadas es un "objetivo clave", entonces sería lógico preferir fuentes que los lectores puedan leer con facilidad y libertad. WhatamIdoing ( discusión ) 01:17 11 sep 2024 (UTC) [ responder ]
Bueno, creo que sigue siendo mejor usar WP:BESTSOURCES . La gente puede pagar si realmente lo desea. También hay formas sencillas de sortear los muros de pago. Pero el punto es que es complicado y engorroso comprobar las referencias. Es mejor que nada, pero podría ser mejor. No estoy defendiendo en absoluto el uso de fuentes de pago o fuentes que no estén en inglés. Nuestra responsabilidad empieza y termina dentro de la experiencia de usuario de Wikipedia, y una vez que te llevamos a la puerta de pago, termina allí. Andre 🚐 01:22, 11 de septiembre de 2024 (UTC) [ responder ]
Eso no es del todo cierto. Si la misma fuente está disponible (legalmente) en varios lugares, deberíamos incluir el enlace a la más accesible. Si hay varias fuentes igualmente buenas que verifican el mismo contenido, deberíamos preferir la más accesible. Obviamente, si una fuente es mejor, deberíamos preferirla.
Si hay tres hechos que verificar y las fuentes A y B son de igual calidad; la fuente A está sujeta a un pago y verifica los tres hechos, la fuente B está disponible de forma gratuita para todos, pero solo verifica los hechos 1 y 2 (no dice nada sobre el hecho 3), ¿deberíamos citar solo la fuente A, o deberíamos citar la fuente B para los hechos 1 y 2 y la fuente B para el hecho 3? Mi intuición me dice que deberíamos hacer lo último, pero puedo ver argumentos a favor de lo primero. Thryduulf ( discusión ) 02:14 11 sep 2024 (UTC) [ responder ]
Los citaría a todos Andre 🚐 02:17, 11 de septiembre de 2024 (UTC) [ responder ]
Si te refieres a citar ambas fuentes para los hechos 1 y 2, eso podría fácilmente llevar a una sobrereferencia. Thryduulf ( discusión ) 02:19 11 sep 2024 (UTC) [ responder ]
Personalmente, prefiero incluir ambas referencias y WP:REFBUNDLE . Andre 🚐 02:26, 11 de septiembre de 2024 (UTC) [ responder ]
Estaba hablando de cómo las referencias deberían ser de fácil acceso, aunque hacer que los lectores lean las fuentes no sea un objetivo clave. (Ya dije que si lo fuera, los artículos de enciclopedia no serían el camino a seguir). isaacl ( discusión ) 06:28 12 sep 2024 (UTC) [ responder ]
Este es un caso de uso para tener un texto de plantilla invisible o un tipo de transclusión especial. Básicamente, los enlaces de archivo deberían estar en otro lugar, no en el artículo real. Andre 🚐 19:43, 9 de septiembre de 2024 (UTC) [ responder ]
La preocupación que se plantea aquí, y que se planteó repetidamente en CS1, es la interrupción del servicio del sitio y los bloqueos de regiones. La solución, que se ha dado una y otra vez , es simplemente utilizar el enlace de archivo. (Aparentemente, agregar opciones de parámetros explícitos para notificar a los bots no es viable, por lo que se recomiendan comentarios HTML no documentados en su lugar). SamuelRiv ( discusión ) 20:14, 9 de septiembre de 2024 (UTC) [ responder ]
Entonces sí, el enlace de archivo es útil, como un enlace permanente del artículo en ese momento, y resuelve un problema legítimo como dices, no me malinterpretes. Pero para artículos grandes, alguien que rescata ciegamente todos los enlaces, incluso aquellos que probablemente nunca desaparecerán, infla el artículo con una tonelada de tamaño adicional sin ninguna ganancia, y también crea un problema de usabilidad porque en muchos casos el enlace de archivo, aunque es preferible a un 404, es menos utilizable que el sitio web real, ya sea por falta de algunos recursos o imágenes, javascripts especiales o lo que sea. Todos hemos experimentado una gran cantidad de errores al navegar por enlaces de archivo, ¿verdad? Y no hay una razón real para que los enlaces de archivo en sí deban estar en el artículo para sitios con mucho tráfico, donde el resultado de ingresar esa URL en la API de archivo devolverá de manera determinista algo utilizable. Como dice Rhodo, en realidad hay un bot que almacenará un mapa de los enlaces, lo que parece una buena dirección, en lugar de que lo hagan humanos. Andre 🚐 20:19 9 sep 2024 (UTC) [ responder ]
Bloqueos y limitaciones regionales. Esto empeora en el caso de los artículos extensos sobre temas regionales, especialmente aquellos que se actualizan con noticias locales (que con frecuencia se limitan a determinadas regiones), como por ejemplo Trump y otros políticos estadounidenses. Tampoco logro entender cómo un aumento porcentual relativamente pequeño en la pequeña fracción de artículos que son enormes y altamente volátiles debería ser lo que hace o deshace a IABot (especialmente porque son esos artículos para los que el primer punto de mi párrafo aquí es más relevante). Seguramente existen otras formas de abordar los problemas de rendimiento en artículos de gran tamaño y con demasiadas noticias (incluidos, entre otros, los que ya están habilitados de forma predeterminada para dispositivos móviles). SamuelRiv ( discusión ) 20:54, 9 de septiembre de 2024 (UTC) [ responder ]
Si los artículos se vuelven tan grandes que editarlos es difícil, entonces deberían dividirse . Lamentablemente, esto llevará a tener que defender algunos artículos derivados contra los eliminadores de AfD, pero ese es un tema aparte. Thryduulf ( discusión ) 11:14 10 sep 2024 (UTC) [ responder ]
Algunos artículos también reciben más citas que otros, lo que no justifica simplemente equiparar la longitud del wikitexto con la longitud conceptual abstracta, sin tener en cuenta ciertos problemas técnicos. Remsense ‥ 论11:23, 10 de septiembre de 2024 (UTC) [ responder ]
No estoy seguro de entender del todo ese comentario, pero dividirlo porque no se puede editar sin problemas es una razón tan válida para dividirlo como que sea demasiado largo para leerlo cómodamente. Thryduulf ( discusión ) 12:04 10 sep 2024 (UTC) [ responder ]
Perdón por la confusión. Supongo que lo reformularía diciendo que no estoy de acuerdo con eso. Los artículos deberían dividirse por el bien de los lectores; si existe una clara tentación de dividirlos por el bien de los editores, primero deberíamos examinar críticamente si existen problemas técnicos que podamos solucionar para evitar esa solución. Remsense ‥ 论12:09, 10 de septiembre de 2024 (UTC) [ responder ]
Cualquiera que esté interesado en soluciones "técnicas" podría echar un vistazo a Talk:Lista de conceptos erróneos comunes#Propuesta dividida , donde se han propuesto múltiples soluciones técnicas y "demasiado largo para leer cómodamente" parece ser tratado como una cuestión relativamente poco importante de preferencia personal. WhatamIdoing ( discusión ) 16:09 10 sep 2024 (UTC) [ responder ]
No creo que Levivich sea una minoría y estoy de acuerdo con Ajpolino . Aquí hay un ejemplo de buena fe de Susmuffin que ha hecho que trabajar con el artículo sea una tortura. Después de agregar enlaces de archivo, el 12% del contenido de la página sigue siendo enlaces de archivo; no es necesario agregar enlaces de archivo en fuentes como The New York Times , la BBC, The Washington Post y muchas otras cuyos enlaces rara vez fallan, y la edición en torno a las plantillas de citas ahora excesivamente largas se vuelve más compleja. No siento que pueda revertir una edición de buena fe como esa, pero desearía poder hacerlo, ya que tener todo ese desorden de plantillas no es útil. Sandy Georgia ( Discusión ) 11:04, 10 de septiembre de 2024 (UTC) [ responder ]
Tanto el Washington Post como el New York Times limitan el acceso de diversas maneras. Ambos, a veces, también cambian el contenido de las páginas sin cambiar la URL. Si bien puede que no sea estrictamente necesario agregar archivos a dichas páginas, aún así agregan valor a la página y revertiría la eliminación de ellos por cualquier motivo que no sea que estén rotos (e incluso entonces sería mucho mejor reemplazarlos con otros que no estén rotos). El wikitexto adicional es desafortunado, pero nada más que eso, especialmente porque herramientas como el Editor visual y el resaltado de sintaxis reducen el impacto significativamente. Thryduulf ( discusión ) 11:12, 10 de septiembre de 2024 (UTC) [ responder ]
No podemos agregar enlaces de archivo si el propósito es eludir los muros de pago. Eso sería muy poco ético. Levivich ( discusión ) 14:58 10 sep 2024 (UTC) [ responder ]
Estoy de acuerdo en que usar IA como herramienta para eludir los muros de pago es poco ético, pero ¿cómo funciona exactamente? ¿IA mantiene suscripciones a sitios con muros de pago y luego expone las páginas que recupera? RoySmith (discusión) 15:04 10 sep 2024 (UTC) [ responder ]
Algunos muros de pago solo se activan después de una cierta cantidad de lecturas. Por lo general, los sitios web de noticias. Al usar la IA, puede acceder a un sitio web incluso cuando haya agotado todas sus lecturas gratuitas. Jo-Jo Eumerus ( discusión ) 15:53 10 sep 2024 (UTC) [ responder ]
Los sitios web a veces
ofrecer un artículo disponible abiertamente en un momento dado y luego (a veces muchos años) ponerlo retroactivamente detrás de un muro de pago, o
Ofrecer un artículo disponible abiertamente a rastreadores como Internet Archive o Google, pero presentar un muro de pago para los lectores humanos.
Personalmente, no tengo ningún problema con incluir capturas de pantalla archivadas de páginas con acceso de pago en los artículos de Wikipedia: estas proporcionan un servicio importante a los editores que intentan verificar las afirmaciones realizadas en los artículos, pero es poco probable que afecten significativamente los ingresos del sitio web. Si el propietario del sitio web tiene un problema, puede pedirle al sitio de archivo que elimine la captura de pantalla. – jacobolus (t) 15:53, 10 de septiembre de 2024 (UTC) [ responder ]
@ RoySmith : Además de las explicaciones anteriores, hay varias formas técnicas de sortear los muros de pago, y los diversos servicios de archivo a veces utilizan algunas de esas formas. Como ejemplo (disculpas al New York Times), aquí hay un artículo del NYT, está protegido por un muro de pago para mí, no estoy seguro de si para otros esto se puede mostrar como uno de los "artículos gratuitos por mes", que tal vez he usado. Aquí está el archivo de Internet Archive , verás que también está protegido por un muro de pago. Aquí hay otro archivo de Archive.today : voila, no hay muro de pago, puedes leerlo gratis. En mi opinión personal, esto es casi seguro una infracción de derechos de autor. (Divulgación: he utilizado ambos servicios de archivo en Wikipedia; creo que todos lo hemos hecho en un momento u otro). Ahora, prueba esto con el Wall Street Journal [2] y no funciona. Archive.today puede atravesar el muro de pago del NYT pero no del WSJ; No sé por qué, pero hay una explicación técnica que surge del hecho de que los dos periódicos utilicen una tecnología de pago diferente. No sé qué muros de pago respeta IA y cuáles respeta Archive.today (si es que respeta alguno). Y aunque Wikipedia no puede hacer nada con respecto a las prácticas de archivo de otros sitios web, lo que realmente no deberíamos hacer es agregar enlaces de archivo porque algunos sitios están protegidos por un muro de pago, como se sugirió anteriormente. Levivich ( discusión ) 16:59 10 sep 2024 (UTC) [ responder ]
@ SandyGeorgia Si los enlaces de archivo en las páginas activas no te resultan útiles, no dudes en revertir el cambio o eliminarlos. El hecho de que las modificaciones se realicen de buena fe no significa que nadie más pueda estar en desacuerdo. – jacobolus (t) 14:50, 10 de septiembre de 2024 (UTC) [ responder ]
Me opongo de nuevo a que añadir enlaces de archivo suponga añadir una funcionalidad importante. En los enlaces activos, evita los bloqueos y limitaciones regionales (especialmente en el caso de los medios de comunicación extranjeros, según la ubicación de cada uno; por ejemplo, varios sitios de periódicos estadounidenses siguen bloqueando las direcciones IP de la UE para cumplir con el RGPD). (En relación con lo anterior: la tasa de clics en la fuente del 99,7 % es, sinceramente, superior a la que esperaba, por cierto; si se tiene en cuenta la gran cantidad de tráfico que recibe WP y los fines para los que la gente lo utiliza, se trata de una cantidad enorme de personas que comprueban las fuentes). Una adición de 50 000 caracteres de wikisource en la expansión de la plantilla se convierte en 100 KB de HTML (UTF-8) para el cliente, que se representa como texto sin formato + hipervínculo. Soy comprensivo con los navegadores y las computadoras lentos, pero tenemos la Wikipedia móvil por esa razón, que mantendría la sección de citas colapsada de forma predeterminada. (Si este es un problema persistente más allá de lo que estoy calculando aquí, entonces se pueden buscar ajustes más precisos del rendimiento del cliente por página aquí). Realmente creo que se está suponiendo que esto crea un impacto significativo en el rendimiento, cuando creo que, en cambio, el impacto en el rendimiento es endémico dentro de la página. Los artículos que se utilizan como ejemplos, como Trump, son gigantescos para empezar, inflados por actualizaciones constantes de WP:Notnews y WP:Citekill . (Yo y otros hemos tratado de recortar esta hinchazón, solo para que se nos volviera a quitar RS; al discutir una división más arriba, una división por hinchazón generalmente no es controvertida, por lo que no se detalla en P&G, hasta que no lo es, y estos artículos son el resultado).
Tomando una página nueva en Chrome con las diferencias de las elecciones venezolanas citadas anteriormente (antes y después de la adición de 50k), el consumo de memoria al abrir es 92708k y 98388k respectivamente (reiniciando y limpiando el navegador cada vez).
tldr: ¿Hay evidencia de que agregar enlaces de archivo afecte significativamente el rendimiento del cliente en una página inflada, como afirma la gente? ¿O la página ya está retrasando su máquina? SamuelRiv ( discusión ) 16:59, 10 de septiembre de 2024 (UTC) [ responder ]
Se trata de una tasa de no clics del 99,7 %. Una de cada 300 visitas a una página hace que alguien haga clic en un enlace de una referencia. Es más probable que esto ocurra en artículos breves, por lo que se cree que las personas hacen clic en las fuentes cuando necesitan más información de la que podemos darles (por ejemplo, si desea ver una imagen del tema y el artículo de Wikipedia no la tiene). WhatamIdoing ( discusión ) 17:59 10 sep 2024 (UTC) [ responder ]
Sería interesante ver qué fracción de ese 0,3 % ocurre mientras el artículo está pasando por algún tipo de proceso de revisión (DYK, GAN, FAC, AfD, etc.). Mi intuición es que la mayoría. RoySmith (discusión) 18:08 10 sep 2024 (UTC) [ responder ]
No lo creo. Esos procesos afectan a muy pocas páginas o visitas a la página. El 50 % medio de los artículos tiene entre 2 y 9 referencias (no todas tienen enlaces). El artículo medio tiene 13 oraciones, lo que es lo suficientemente largo para satisfacer las necesidades de la mayoría de los lectores, pero lo suficientemente corto como para que alguien pueda estar buscando más detalles.
Habrá un cierto porcentaje de clics erróneos, y no me sorprendería que los clics erróneos superen a los clics de los editores. Hay muchos más lectores que editores. WhatamIdoing ( discusión ) 18:24 10 sep 2024 (UTC) [ responder ]
@ WhatamIdoing y RoySmith : A principios de este año, comencé a tomar notas sobre los datos sobre cómo la persona promedio lee Wikipedia ( Usuario:Rjjiii/¿Cómo lee la gente Wikipedia? ). Las personas tenían más probabilidades de hacer clic en un enlace de referencia si el artículo era inadecuado de alguna manera. Utilizándolo como un directorio en lugar de un punto final. Rjjiii (ii) ( discusión ) 01:08, 12 de septiembre de 2024 (UTC) [ responder ]
@ Rjjiii (ii) , es una gran recopilación de datos útiles (por ejemplo, se hace mucho clic en los sitios web oficiales en los cuadros de información) y te pido que los publiques en las páginas pertinentes. Por ejemplo, las personas que escriben Help:Your first article o los habituales de Wikipedia:WikiProject Guild of Copy Editors probablemente encuentren esa información útil. WhatamIdoing ( discusión ) 01:55, 12 de septiembre de 2024 (UTC) [ responder ]
Estoy de acuerdo, muy buenas ideas. ¿Se hace clic en las citas de PDF con más frecuencia que en un DOI o JSTOR? Eso es bastante mordaz. ¿Por qué no tenemos un bot que recopile un enlace de PDF sin procesar y lo coloque en iconos? Andre 🚐 02:02, 12 de septiembre de 2024 (UTC) [ responder ]
Creo que la solución para artículos como el de Donald Trump es que un editor sacrifique varias horas para reemplazar sistemáticamente las citas que solo se han usado una vez en el artículo con un libro reciente. Por ejemplo, hay un párrafo sobre que no sirvió en el ejército, en el que se citan cuatro fuentes. Es probable que las cuatro puedan reemplazarse por una cita a un solo libro. WhatamIdoing ( discusión ) 18:07 10 sep 2024 (UTC) [ responder ]
No creo que debamos elaborar políticas basadas en casos excepcionales como el de Donald Trump . Siempre habrá artículos como ese y siempre será complicado mantenerlos, sin importar las políticas y herramientas que tengamos. Deberíamos concentrarnos en el 99,999 % [ cita requerida ] de nuestros artículos que no tienen 834 referencias. RoySmith (discusión) 18:13 10 sep 2024 (UTC) [ responder ]
Donald Trump es la entrada número 267 en Special:LongPages y, si asumimos que el tamaño del wikitexto se correlaciona con la cantidad de referencias, podría tener aproximadamente la 267.ª mayor cantidad de referencias, lo que lo ubicaría en el 99,9961 %, muy cerca de su estimación improvisada. Estoy impresionado. WhatamIdoing ( discusión ) 19:12 10 sep 2024 (UTC) [ responder ]
Di mis números. ¿Alguien más desea probar el rendimiento de la página con y sin enlaces masivos de IA en sus máquinas/navegadores, como se indicó anteriormente?
Un par de personas han afirmado que el rendimiento se reduce, pero ¿pueden las personas publicar evidencia (yo solo di una medición) de que los enlaces de IA realmente afectan el rendimiento en el grado significativo que se afirma? Porque el rendimiento se puede demostrar objetivamente, de una forma u otra, a diferencia de la estética (a lo que se reduce todo este debate, si resulta que no hay una pérdida significativa de rendimiento). SamuelRiv ( discusión ) 02:16, 11 de septiembre de 2024 (UTC) [ responder ]
¿Ha llegado el momento de explorar WikiCite? Sé que a enwp no le gusta Wikidata, pero ese proyecto de tomar todas las fuentes que citamos e incluirlas en Wikidata lleva ya algún tiempo en marcha. Me imagino que ya existe una propiedad de enlace de archivo. ¿Ha llegado el momento de que un bot reemplace las citas con referencias de Wikidata y un bot que convierta las nuevas citas en elementos de Wikidata? No lo espero, pero al menos vale la pena mencionarlo.Las rododendritas hablan\\ 12:34, 10 de septiembre de 2024 (UTC) [ responder ]
¿Es posible tener un paso más pequeño, por ejemplo, uno en el que los enlaces de archivo para sitios activos (es decir, aquellos creados puramente como respaldo) se puedan almacenar en Wikidata? Eso mantendría pequeña la carga de wikitexto de las URL de archivo (supongo que solo un código Q), al mismo tiempo que se mantiene la funcionalidad de respaldo. CMD ( discusión ) 12:43, 10 de septiembre de 2024 (UTC) [ responder ]
Me pregunto si ya ha habido discusiones sobre la intersección entre IABot y WikiCite, es decir, al crear enlaces de archivo, agregarlos a Wikidata si hay un identificador disponible. @ Cyberpower678 y Harej : —Las rododendritas hablan\\ 14:59, 10 de septiembre de 2024 (UTC) [ responder ]
Definitivamente estamos trabajando para lograr una mejor integración con Wikidata, pero aún no hay detalles sobre plazos y características. Vamos paso a paso. :-) — CYBERPOWER ( Chat ) 16:29, 18 de septiembre de 2024 (UTC) [ responder ]
Sé que esto no soluciona todos los problemas planteados aquí, pero aparentemente la última versión de la extensión de coloración de sintaxis incluye el plegado de plantillas, lo que debería hacer que las plantillas de citas grandes sean menos intrusivas. RoySmith (discusión) 16:58, 10 de septiembre de 2024 (UTC) [ responder ]
El problema (o uno de los problemas) es que al editar una plantilla de cita, el enlace de archivo agrega un montón de información adicional a la plantilla que uno debe leer (y procesar, y en ocasiones eliminar).
De todos modos, ¡qué debate tan intenso! Creo que puede que sea el momento de hacer una RFC. Levivich ( discusión ) 17:18 10 sep 2024 (UTC) [ responder ]
¿Qué pregunta estás pensando hacer?
Agregar enlaces de archivo a las plantillas de citas para fuentes "activas" tiene ventajas y desventajas. ¿Debería aceptarse como una buena práctica?
¿Debería considerarse la inclusión de enlaces de archivo para enlaces "activos" una forma de WP:CITEVAR ? Si es así, los editores que ejecuten el script Wikipedia:IABotManagementConsole a veces tendrán que discutir la posibilidad de cambiar el estilo de cita del artículo para incluirlos antes de ejecutar el script.
No estaba pensando en hacer ninguna pregunta, pero no creo que ninguna de las dos deba ser una pregunta RFC, ya que son demasiado limitadas, especialmente la segunda, que es demasiado wikilawyer. Pensando en voz alta aquí, creo que una mejor pregunta RFC sería algo más abierto, como: "¿cuándo se deben agregar enlaces de archivo a los artículos?" O algo así. Levivich ( discusión ) 17:36 10 sep 2024 (UTC) [ responder ]
Esa pregunta parece tan amplia que podría ser más eficaz para recopilar información que para generar un consenso. Ya estamos recopilando información aquí (hasta ahora, 128 comentarios de 26 editores), por lo que no estoy seguro de qué valor adicional aportaría una RFC. WhatamIdoing ( discusión ) 17:50, 10 de septiembre de 2024 (UTC) [ responder ]
Tablón de anuncios de teorías marginales, temas religiosos yWP:LIENZO
Durante años, el tablón de anuncios de Fringe Theory ha sido el lugar de referencia para muchos editores cuando se trata de solicitar ayuda sobre temas religiosos. Esto ha causado… problemas. FTN parece inclinarse hacia un tipo particular de escepticismo que, aunque es saludable para Wikipedia en su conjunto, conduce a algunos problemas graves con WP:NPOV , WP:CIVILITY y, en ocasiones, WP:OUT sobre estos temas. El incidente más significativo que se me viene a la cabeza fue el de los administradores que criticaron a FTN por insistir en que los miembros de Falun Gong se declaren editores de COI sobre cualquier tema de Falun Gong. También ha habido algunos problemas bastante graves con los habituales de FTN que editan artículos religiosos sin darse cuenta de que algo es terminología técnica/académica cuando se trata de temas religiosos, lo que se está desarrollando ahora mismo en la discusión aquí y que comenzó en FTN.
Parece existir esta actitud de que las religiones deben ser tratadas como cualquier otra teoría marginal y hay llamados regulares a editar artículos religiosos de una manera que parece ser bastante abiertamente hostil. Esto definitivamente da la impresión de intentar corregir un gran error al no tratar a la religión con el desdén intelectual apropiado. Esto es especialmente el caso de los Nuevos Movimientos Religiosos como el mormonismo, Falun Gong, etc.
Mi preocupación es que traer estos temas exclusivamente a WP:FTN y no, digamos, al wikiproyecto de religión (o al wikiproyecto apropiado para una religión dada) termine sintiéndose como una decisión deliberada de excluir a personas que pueden ser menos hostiles a una religión específica y que se perciba como WP:CANVAS , especialmente a la luz de cuán dispuestos están los habituales de FTN a tirar WP:CIVILITY por la ventana en temas religiosos hasta el punto de múltiples advertencias de administración y cierres de hilos. Mi disposición a asumir buena fe es bastante baja aquí considerando la historia de hostilidad abierta a los temas religiosos/espirituales (convencionales) cuando aparecen en FTN.
Mi pregunta fundamental aquí en relación con la política es si los temas religiosos que se relacionan específicamente con la historia religiosa y la teología, en contraposición a una afirmación empírica específica, deberían caer bajo el paraguas de la “teoría marginal”. Si es así, ¿deberían notificarse al mismo tiempo a los wikiproyectos apropiados para no sondear básicamente a personas que tienen sesgos específicos pero no necesariamente un conocimiento práctico útil de un tema determinado? Warren ᚋᚐᚊᚔ 10:00, 11 de septiembre de 2024 (UTC) [ responder ]
Falun Gong es notablemente el único movimiento religioso que tiene una designación CTOP dedicada, es decir, Wikipedia:Temas contenciosos/Falun Gong , más allá de la Wikipedia más amplia:Temas contenciosos/Pseudociencia y ciencia marginal . En mi opinión, hacer campaña en wikiproyectos específicos o no realmente no significa mucho. Definitivamente hay editores de POV, pero la mayoría de los editores en WikiProjects sobre religión son heterogéneos. Creo que hay tensiones en términos de si Wikipedia existe para promover el punto de vista de un movimiento religioso sobre su religión, especialmente resúmenes teológicos, pero no estoy de acuerdo en que un cambio de política sea útil o esté justificado aquí. Si hay alguna política que analizar, es sobre los requisitos de obtención y la ponderación. ~ 🦝 Shushugah (él/él • hablar ) 10:21, 11 de septiembre de 2024 (UTC) [ responder ]
Falun Gong es notablemente el único movimiento religioso que tiene una designación CTOP dedicada.
Tengan en cuenta que el incidente al que me refería era cuando FTN exigía a los editores de Falun Gong que revelaran su afiliación religiosa al editar páginas, algo que los administradores en la discusión criticaron como un meteorito. No se trata solo de una cuestión de si esta religión es marginal o no, sino de que este tipo de ateísmo radical muestra una hostilidad abierta hacia los temas religiosos, especialmente cuando se trata de temas teológicos y no solo de algo que es claramente marginal. Warren ᚋᚐᚊᚔ 10:26, 11 de septiembre de 2024 (UTC) [ responder ]
Los administradores de la discusión cayeron como un meteorito en ← suena impresionante. ¿Qué sanciones se aplicaron? Bon courage ( discusión ) 11:14 11 sep 2024 (UTC) [ responder ]
También me gustaría saber más sobre esto. Es una novedad para mí. :bloodofox: ( discusión ) 06:43 12 sep 2024 (UTC) [ responder ]
Por otra parte, sí recuerdo mucha acción en relación con el altercado LDS/COI, como una enorme cantidad de actividad en ANI que terminó en sanciones.[3] y un WP:BUREAUCRAT que perdió sus piezas. Pero aquí nos dicen que el "ataque de meteorito" multiadministrador fue contra los participantes de FTN. Es curioso. Bon courage ( discusión ) 08:00, 12 de septiembre de 2024 (UTC) [ responder ]
Puede haber "teorías marginales" sobre todo, incluidas la historia religiosa y la teología. Es trivial para las páginas de wikiproyectos incluir FTN si así se desea para poder proporcionar notificaciones a los seguidores. Feoffer ( discusión ) 10:22 11 sep 2024 (UTC) [ responder ]
Pero el problema no es que otras personas incluyan FTN en la transposición, sino que los editores de FTN solo incluyen a FTN en temas religiosos cuando la edición se vuelve polémica, a diferencia de cualquier otra persona independientemente de su experiencia en el tema exacto en cuestión, por lo que parece bastante parecido a WP:CANVAS . Warren ᚋᚐᚊᚔ 10:29, 11 de septiembre de 2024 (UTC) [ responder ]
No otra vez esto. Esto es como un disco rayado del autor original, que sigue apareciendo en FTN para airear esta supuesta queja. La falta de ejemplos en su queja dice mucho y sugiero que se aplique la navaja de Hitchen . Pero, para repetir lo que se ha dicho a menudo allí: la religión no cae dentro de WP:FRINGE , pero cuando las afirmaciones de una religión se introducen en el mundo real (como afirmar que la Ciencia Cristiana puede curar enfermedades o que el E-metro tiene una función útil), entonces WP:FRINGE ciertamente puede aplicarse; el aspecto religioso no le da a las tonterías algún tipo de escudo sagrado de la política NPOV de Wikipedia por la que debe describirse con precisión dentro de un contexto racional basado en el conocimiento. Bon courage ( discusión ) 11:12, 11 de septiembre de 2024 (UTC) [ responder ]
Esto es como un disco rayado del OP, que sigue apareciendo en FTN para ventilar esta supuesta queja.
¿Qué? Me dijeron que trajera esto aquí durante el último gran escándalo al respecto y no lo había hecho. La actual oleada de temas mormones en FTN me hizo pensar que finalmente era hora de hacerlo. Más allá de eso, ¿soy un habitual de FTN? No estoy "apareciendo en FTN para ventilar esta supuesta queja", soy un colaborador habitual allí a quien le molesta el manejo de un tema específico en FTN y este es un problema recurrente y continuo, que solo lo menciona cuando ese problema sale a la luz, lo que ha sucedido en dos hilos separados y continuos.
La falta de ejemplos en su denuncia dice mucho.
No proporcioné ejemplos específicos porque la página de discusión principal de FTN está allí para que todos la vean y no quería que pareciera que estaba ventilando quejas con individuos específicos, o que la discusión fuera, por ejemplo, sobre las tradiciones populares de Cunning y el movimiento de los Santos de los Últimos Días en lugar del tema más amplio de FTN sobre temas religiosos.
La religión no cae dentro del ámbito de WP:FRINGE, pero cuando las afirmaciones de una religión se introducen en el mundo real (como afirmar que la Ciencia Cristiana puede curar enfermedades o que el E-metro tiene una función útil), entonces WP:FRINGE ciertamente puede aplicarse.
Abordé esto de inmediato en la publicación a la que estás respondiendo. El problema no es el contenido tipo E-meter, que es absolutamente marginal, sino más bien la gente que trata las afirmaciones centrales de la teología como un tema marginal, cuando puede ser un poco difuso en un diagrama de Venn entre un tema marginal y uno religioso, o incluso simplemente temas religiosos generales que se tratan como marginales a pesar de que son completamente artículos de fe. Has estado en FTN el tiempo suficiente para saber que hay un contingente que ve la religión como un enemigo inherente y estoy muy lejos de ser la única persona que ha mencionado esto recientemente . Warren ᚋᚐᚊᚔ 11:33, 11 de septiembre de 2024 (UTC) [ responder ]
No, creo que te estás imaginando cosas y sigues hablando de Reddit y el ateísmo. Si la gente quiere creer que un Douglas DC-8 pilotado por Xenu puso a los Thetans en un volcán (o lo que sea) como parte de su "teología central", está bien. Si dicen que realmente sucedió, eso es un problema. No hay nada que arreglar aquí. ¿O tienes una propuesta específica? Bon courage ( discusión ) 11:37, 11 de septiembre de 2024 (UTC) [ responder ]
No, creo que estás imaginando cosas y sigues hablando de Reddit y el ateísmo.
Como no soy el único que plantea esta inquietud específica, seguro que parece una alucinación colectiva. Yo (y otros) utilizamos "r/atheism" como abreviatura de una forma específica de personalidad "enojada con la religión" que aparece básicamente por todas partes en ráfagas. Es una abreviatura, y no soy el único que la utiliza.
Si la gente quiere creer que un Douglas DC-8 pilotado por Xenu puso a los Thetanes en un volcán (o lo que sea) como parte de su "teología central", está bien.
Lo que no está bien es que los usuarios no sientan que un tema está siendo tratado con la burla apropiada , en lugar de solo WP:NPOV y abordar WP:PROFRINGE . Esto surge muchísimo en temas religiosos en FTN, y si bien no es exactamente una postura mayoritaria, es una postura actual. A un contingente de FTN básicamente le gusta ver la Resurrección de Jesús y el monstruo del Lago Ness como retóricamente equivalentes y merecedores del mismo tipo de tratamiento. Independientemente de las creencias personales sobre cualquiera de los dos, Wikipedia no es el lugar para ventilar quejas personales sobre la religión.
No hay nada que arreglar aquí. ¿O tienes alguna propuesta concreta?
Bueno, dado que FTN maneja los temas religiosos de manera poco delicada, inexperta y con una actitud muy entusiasta, creo que asegurarse de que el proyecto wiki apropiado se involucre en los temas religiosos probablemente sería de gran ayuda. Creo que la discusión actual sobre la gente astuta es un gran ejemplo de cómo FTN se adelanta a los acontecimientos debido a la falta de familiaridad con la literatura sobre un tema determinado. Warren ᚋᚐᚊᚔ 11:45, 11 de septiembre de 2024 (UTC) [ responder ]
Los WikiProjects no crean o no deberían crear Wikipedia:Consenso local . Puedes añadir cualquier banner de WikiProject relevante en cualquier página de discusión y notificar a cualquier WikiProject que quieras para discusiones más amplias. No se consideraría como una campaña de sondeo, porque un WikiProject en sí mismo no representa ningún punto de vista particular (espero que sea cierto para los relacionados con WP:TERRORISM ). Seguro, {{ WikiProject Mormon }} probablemente tenga más seguidores de la fe mormona, pero también, lo que es más importante, gente con conocimiento académico, ya sea como seguidores, críticos y otros. Si un WikiProject específico está impulsando un punto de vista o tratando de crear consenso local, eso se puede solucionar, pero en sí mismo, notificar a cualquier WikiProject que quieras está bien. Es cierto que algunos proyectos como WP:ISRAEL y WP:PALESTINE PODRÍAN fusionarse, pero ninguno de los proyectos está en sí mismo "haciendo campaña" cuando se les notifica. ~ 🦝 Shushugah (él/lo • conversación ) 11:59 11 sep 2024 (UTC) [ responder ]
Si un WikiProyecto específico está impulsando el punto de vista o intentando crear un consenso local, eso se puede solucionar.
Esto es lo que creo que está pasando con FTN, aunque no necesariamente de forma muy explícita. La "antirreligión" no es un punto de vista neutral y puede parecer una forma de hacer campaña para ir a un lugar donde esa es la actitud predominante, mientras que simplemente se ignoran los otros wikiproyectos que pueden tener más capacidad para contribuir directamente a los temas en cuestión.
En esencia no siento eso
Un WikiProyecto en sí mismo no representa ningún PdV particular
Esto es válido para FTN en lo que respecta a la religión. Warren ᚋᚐᚊᚔ 12:03, 11 de septiembre de 2024 (UTC) [ responder ]
FTN es un tablón de anuncios, no un WikiProject. Bon courage ( discusión ) 12:07 11 sep 2024 (UTC) [ responder ]
Ups, lo siento, tienes razón, eso es lo que me pasa por leer demasiado rápido. Warren ᚋᚐᚊᚔ 12:07, 11 de septiembre de 2024 (UTC) [ responder ]
La última vez que miré, FTN tenía una gran cantidad de personas con diferentes opiniones sobre los temas. ¿Quizás irías a WP:SKEP para hablar sobre ateísmo? Bon courage ( discusión ) 12:10, 11 de septiembre de 2024 (UTC) [ responder ]
De todos modos, tu punto plantea qué se considera un estado neutral/predeterminado, y cuando se trata de religión, no es fácil. Encuentro útil este ensayo Wikipedia:Las críticas a la sociedad pueden ser consistentes con el punto de vista no verbal y la confiabilidad . Como alguien que fue criado extremadamente religioso y ahora ateo, aprecio que Wikipedia siempre haya sido una fuente decente para resumir el estado de la literatura que existe. En algunos casos, no fue tan "exhaustivo" como mi educación teológica religiosa específica, porque los requisitos de fuentes no estaban a la altura. Hay mejores recursos fuera de la wiki si el objetivo es brindar un seminario religioso. ~ 🦝 Shushugah (él/él • discusión ) 12:12, 11 de septiembre de 2024 (UTC) [ responder ]
Creo que el problema más importante es su relación con los nuevos movimientos religiosos como Falun Gong, el mormonismo, los Moonies, etc., que tienen mucha menos literatura establecida en torno a la teología y la gente tiende a ser mucho más abierta a la hora de tratarlos con desdén. Diablos, me han acusado de ser cripto-Falun Gong en FTN y soy un habitual de FTN... Warren ᚋᚐᚊᚔ 12:16, 11 de septiembre de 2024 (UTC) [ responder ]
Supongo que algunas nociones son risibles, y que el hecho de que se etiquete como "religión" no significa que un tema merezca respeto (aunque tal vez la gente religiosa crea esto). Por lo tanto, volar en yoga es tan tonto como tomar el sol en el perineo : el hecho de que uno tenga conexiones religiosas no significa que no sea una tontería sobre una tostada. Bon courage ( discusión ) 12:21 11 sep 2024 (UTC) [ responder ]
Creo que estás imaginando (o quizás proyectando) esta "ira". Quejarse sobre el supuesto estado mental de los editores no es útil. Los editores de Wikipedia suelen ser inexpertos; es la base de muchas discusiones sobre cada artículo que se publica. Si alguien quiere informar a algún WikiProject de que una discusión en cualquier tablón de anuncios puede ser de interés, puede hacerlo. De hecho, eso suele ser útil. Bon courage ( discusión ) 12:00, 11 de septiembre de 2024 (UTC) [ responder ]
Creo que estás imaginando (o quizás proyectando) este "enojo". Quejarse del supuesto estado mental de los colegas editores no sirve de nada.
¿Seguro que esto fue intencional? [ Humor ] Warren ᚋᚐᚊᚔ 12:11, 11 de septiembre de 2024 (UTC) [ responder ]
Las afirmaciones fundamentales de la teología pueden ser marginales, por ejemplo, los milagros. Horse Eye's Back ( discusión ) 14:33 11 sep 2024 (UTC) [ responder ]
No estoy seguro de qué tiene que ver el hilo de tradiciones populares de Cunning con nada. Solo hubo 4 publicaciones de 3 participantes (incluido usted y una IP). La publicación inicial de @ Feoffer : claramente estaba en el foro equivocado: una propuesta de este tipo, si hay muy pocas personas para el consenso (o si es demasiado polémica) en la página de discusión de un artículo, está destinada a una RfC en esa página de discusión, generalmente con notificación a los WikiProjects pertinentes. La falta de respuestas en FTN sugiere que otros observadores generalmente sabían que esto estaba fuera de lugar. SamuelRiv ( discusión ) 15:11, 11 de septiembre de 2024 (UTC) [ responder ]
Dado que el propósito declarado de este tablón de anuncios (parte superior de la página) es "discutir políticas y pautas ya propuestas y discutir cambios en las políticas y pautas existentes" y no hay evidencia de nada de eso, sugiero que este hilo se cierre por fuera de tema. Bon courage ( discusión ) 12:45 11 sep 2024 (UTC) [ responder ]
Entiendo que no estás de acuerdo con la tesis en lo más mínimo, pero literalmente me dijeron que trajera este tema exacto aquí. Warren ᚋᚐᚊᚔ 12:48, 11 de septiembre de 2024 (UTC) [ responder ]
Cualquiera que te diga que publiques algo así en WP:VPP necesita un WP:TROUT . Quizás WP:VPM o WP:VPI podrían haber sido apropiados. Bon courage ( discusión ) 12:59, 11 de septiembre de 2024 (UTC) [ responder ]
I agree that this should probably be on one of the other Village Pump boards, since there's not really a P&G change or problem suggested here. It's not a huge deal either way, and the thread is already going, but the procedure to move a discussion thread is easy enough and can be done by anyone. Warrenmck, if you like, you can use the {{Moved discussion to}} template set and simply cut-and-paste this thread to a different pump. (But again, not a big deal either way.) SamuelRiv (talk) 14:49, 11 September 2024 (UTC)[reply]
Be happy to, but I’m on my phone right now and it’d be a bit cumbersome. Warrenᚋᚐᚊᚔ 16:12, 11 September 2024 (UTC)[reply]
Putting aside the rest, the question is should religious topics which are specifically relating to religious history and theology, as opposed to a specific empirical claim, fall under the “fringe theory” umbrella. That's a fine policy question to ask here IMO as it's about WP:FRINGE. But the implied question here is actually "should religious topics be exempt from WP:FRINGE" and the answer is no. Not every aspect of religion has to do with WP:FRINGE, but some do. If someone is applying WP:FRINGE where it doesn't belong, that's the same as any user applying any other policy incorrectly and would have to be dealt with on the user level. If you think users are systematically misapplying policy at FTN, that's an issue for WP:AN and would need a lot of unambiguous diffs. — Rhododendritestalk \\ 13:06, 11 September 2024 (UTC)[reply]
I don’t think this could be done at WP:AN, because it’s more of a general attitude thing than a problem with specific users. Unambiguous diffs of FFN misapplying FTN are either easy or impossible, depending on what the remit of FTN is. I definitely agree that religion shouldn’t be exempt from fringe, but there’s a contingent that treat religion itself'’ as fringe.
looking at the threads I’ve been involved in recently on religion:
1. The LDS and Cunning Folk thread, which seems to heavilystem from a misunderstanding that “cunning folk” is the specific applicable academic term which exists well beyond Mormon topics.
2. The Joseph Smith Golden Plates thread. It’s rife with calls that Wikipedia should be outright calling Joseph Smith an active fraud, sources not fully agreeing with that conclusion (though leaving the possibility open) be damned.
3. The Tukdam thread, which did actually call out some issues with that page but also didn’t grasp the language used by researchers working with minority religious communities (and fair enough, that’s esoteric)
Of twenty threads on FTN right now, nine are directly about religion (discounting the tenth which mentions religion but which is really just about racism). Most of these do actually belong at FTN, but the substance of the threads really highlights that “religion is not inherently fringe” seems to be openly ignored by a decent chunk of the involved parties. If half the content on FTN is going to be religious in nature, then it’s not really just about fringe theories anymore, is it? And the lack of civility or ability to handle sensitive topics becomes a prominent issue that could use guidelines for handling so we reduce the amount of inexpert sledgehammers wielded in the direction of religious topics. Warrenᚋᚐᚊᚔ 13:32, 11 September 2024 (UTC)[reply]
So you're saying all the (what you term) 'religious' threads at FTN are there properly, but there is a problem with stuff being raised there improperly. Then there is the vague complaint that you think some people ignore the “religion is not inherently fringe” idea, but with not a diff in sight. This is bizarre. The supposed bombshell 'cunning folk' thread has only four mild-mannered posts (one of them yours) discussing a proposal.[4] Isn't that what noticeboards are for? Bon courage (talk) 13:42, 11 September 2024 (UTC)[reply]
If you're so convinced there's nothing of merit here, why the WP:TEND? I think we're all fairly clear on your perspective that this is a nothing sandwich, but hell even in this thread:
being labelled 'religion' doesn't mean a topic becomes deserving of respect (although maybe religious people believe this?)
Feels sort of like the problem in a nutshell? Wikipedia's policies around civility and bigotry (not necessarily articles, just to pre-address that) absolutely does distinguish "religious belief" among other categories as deserving respect when it comes to civility. The point isn't respecting the beliefs, it's respecting that they are beliefs and mean a heck of a lot to some people, and while "some people" in this equation aren't entitled to ignore wikipedia policies around verifiability and neutrality in favour of their argument, that doesn't mean that they deserve to have their beliefs mocked and ridiculed in talk pages (but let's be real, the more fringe-y it gets the more that'll happen to a degree).
That we seem to have exempted NRMs from a need to handle the same way we do world religions is a genuine systemic failing of WP:NPOV. I can't for a second imagine someone who is committed to WP:NPOV and was themselves a Mormon wouldn't take more than a passing glance at the current state of FTN and instantly nope out due to the behaviour of editors in talk pages and noticeboards, and we need those editors to better address fringe relating to those topics. Warrenᚋᚐᚊᚔ 14:02, 11 September 2024 (UTC)[reply]
From a glance, FTN seems to have a large number of useful Mormon participants. If there are civility problems, raise them at ANI, AE or appropriate venues (but again, you have provided zero evidence). To make the same point again: beliefs are beliefs, but reality is reality. There is no "respect" according to any claim in that latter realm, religious or not. Instead, Wikipedia relies on sources and concentrates on conveying accepted knowledge and if that upsets religious sensibilities, well: tough. So no, the Shroud of Turin is not Jesus' funeral shroud, the Earth is not 6,000 years old, Jesus did not visit America, and prayer does not cure cancer. NRMs and 'mainstream' religions are treated the same in this respect. Bon courage (talk) 14:19, 11 September 2024 (UTC)[reply]
Nothing in this discussion was a personal attack at you nor was it advocating for a diluting of Wikipedia’s stances around religion. I cannot begin to fathom the tone with which you’ve elected to engage here. Warrenᚋᚐᚊᚔ 14:25, 11 September 2024 (UTC)[reply]
Basically, you're casting WP:ASPERSIONS on a whole noticeboard (effectively hundreds of editors) saying things which are largely un-evidenced (no diffs given) or simply wrong (such as Mormons shunning FTN). You have attacked me with a "why the WP:TEND?" jibe. Bon courage (talk) 14:37, 11 September 2024 (UTC)[reply]
The part where you accuse Bon courage of disruptive editing (WP:TEND) without apparent grounds (or with really weak grounds that would equally apply to yourself) does appear to be a personal attack. Horse Eye's Back (talk) 14:41, 11 September 2024 (UTC)[reply]
I’m trying to act in good faith here, it genuinely seemed Bon Courage was basically misrepresenting the initial argument while saying any discussion should be procedurally shut down. It was not intended as a personal attack. Warrenᚋᚐᚊᚔ 14:47, 11 September 2024 (UTC)[reply]
From your opening post: "My willingness to assume good faith is pretty low". Bon courage (talk) 15:05, 12 September 2024 (UTC)[reply]
"was admins coming down on FTN for insisting that members of Falun Gong declare themselves as COI editors on any Falun Gong topics" did this actually happen? I remember we had a whole string of issues with Falun Gong members being disruptive but I don't remember admins sanctioning FTN or anything like that. Horse Eye's Back (talk) 14:26, 11 September 2024 (UTC)[reply]
Indeed it is baked into the WP:PAGs that religious belief can be a source of a WP:COI. There's a reason the entirety of Scientology church IP addresses are blocked from the Project. Bon courage (talk) 14:39, 11 September 2024 (UTC)[reply]
Not finding it, which admins and what did they say? A quick search says that the only editors on that page who mentioned COI are you, Bon Courage, and @ජපස:. Horse Eye's Back (talk) 14:53, 11 September 2024 (UTC)[reply]
The closest thing I can find is this related AE request where the filer was TBanned, another editor who was seen as broadly pro-Falun Gong was indeffed, and "editors in the Falun Gong topic area" (not FTN regulars) were "warned to not speculate about other editors' religious views, nor to attempt to disqualify others' comments based on actual or perceived religious views" (not against "insisting that members of Falun Gong declare themselves as COI editors on any Falun Gong topics").
In the FTN thread linked by Warren, there is a comment by ScottishFinnishRadish that WP:TPG is clear, Do not ask for another's personal details. It is inappropriate for a number of reasons, and adherents of a faith should in no way be expected to share that while editing. which isn't exactly "was admins coming down on FTN for insisting that members of Falun Gong declare themselves as COI editors on any Falun Gong topics". It's more "one admin saying that it isn't permitted to ask other editors whether they are Falun Gong adherents" which is... sort of close-ish? Caeciliusinhorto-public (talk) 08:46, 12 September 2024 (UTC)[reply]
Thats just an admin saying that you're supposed to say "Do you have a COI with topic X" without any prompting as to what the COI is believed to be not "Are you a member of topic X? If so you have a COI" which is a pretty common note that admins give. Its certainly not giving COI editors a free pass on COI as long as their COI is personal info (it almost always is)... Which appears to be what the OP was suggesting. COI is not an excuse for outing, but outing can't be used as a shield against legitimate COI concerns. Horse Eye's Back (talk) 17:49, 13 September 2024 (UTC)[reply]
If we were to take this idea to the extreme, then FTN wouldn't be able to discuss topics like faith healing which seem to me to be clearly within scope. Hemiauchenia (talk) 15:19, 11 September 2024 (UTC)[reply]
It'd be a lot easier if you refer us to specific example threads here. It's hardly throwing anyone under the bus to link to discussion threads instead of just implying them for us to find ourselves -- and people seem to be getting offended regardless.
Meanwhile, I believe what you have been referring to many times here is the Cargo cult thread (which is where the suggestion of canvassing and referral to VPP is made). I have two notes: first is that I agree that a P&G noticeboard should not be used for canvassing people back to an article Talk page or an RfC (per existing norms, RfC notifications are done on subject-matter WikiProjects, by subscription, etc). Generally with noticeboards like WP:RSN the scope is limited to resolving issues of the P&G, unless/until discussion goes into article content, at which point it is referred back to the article Talk page. The P&G noticeboards I've followed have been pretty disciplined about this, so I'm not sure whether that's one issue with FTN. On a similar note of scope, noticeboards can refer to superceding policy, and FT is pretty much made up entirely of superceding policies (it feels like it could be better as an explanatory essay more than a guideline imo). So if a post there is actually about a RS or OR dispute, maybe it should instead be referred to RSN or NORN? SamuelRiv (talk) 15:28, 11 September 2024 (UTC)[reply]
RfC notifications are done on subject-matter WikiProjects ← don't think so. WP:BLPN, WP:NORN and WP:NPOVN are for example ideal places to publicise RfCs where those P&Gs apply. Bon courage (talk) 15:45, 11 September 2024 (UTC)[reply]
and people seem to be getting offended regardless.
To the extent I regret raising this thread. I think this thread is itself a microcosm of my core issue: FTN is unable to handle some religious topics in good faith. Not "FTN needs to treat religious claims as non-fringe" which is a honestly strange read multiple people here have had considering that my initial post specifically was narrowly focused on matters of theology and, as an example:
To make the same point again: beliefs are beliefs, but reality is reality. There is no "respect" according to any claim in that latter realm, religious or not. Instead, Wikipedia relies on sources and concentrates on conveying accepted knowledge and if that upsets religious sensibilities, well: tough. So no, the Shroud of Turin is not Jesus' funeral shroud, the Earth is not 6,000 years old, Jesus did not visit America, and prayer does not cure cancer. NRMs and 'mainstream' religions are treated the same in this respect.
How in any chosen diety's name does any of this have anything to do with a concern raised here? Not once did I call for Wikipedia to treat religious topics as hyper-credible per internal logic, nor did I express any concern about articles "offending religious sensibilities", nor did I make any sort of argument that'd exclude faith healing from the remit of FTN:
should religious topics which are specifically relating to religious history and theology, as opposed to a specific empirical claim, fall under the “fringe theory” umbrella?
Faith healing and every single example from Bon Voyage's reply above make specific empirical claims. All of them, without exception. So what I'm left with here is an FTN regular who came in extremely hot for some reason ignoring the fact that I'm also an FTN regular while pretending that my argument was an axe to grind, when my core argument is that FTN handling these topics alone without involving editors familiar with them has lead to some problematic editing, in addition to FTN basically openly vilifying NRMs on FTN. Not once in this entire thread have I said that FTN should leave all religious topics alone, nor, as some seem to imply, have I argued that religious claims should be treated with credulity and handled with kid gloves.
At this point to even engage with this thread I feel like I have to dedicate a fair amount of time to addressing arguments I never made. It feels like people are trying to read some kind of apologetics into my comments which I never intended, and if that's coming across to multiple people then that's a communication problem on my end, but I think that this thread right here has become a perfect example of how complex, loaded, nuanced topics which invoke strong emotions on all sides are not necessarily best handled in a vacuum by a noticeboard which, as much as we'd all love the policy-backed
Neutrally worded notices to noticeboards or projects are not canvassing
to be true, it doesn't necessarily hold water in practice.
@ජපස's suggestion:
Maybe a resolution could be adding a request in the FTN boilerplate that when people start a thread that they notify relevant WikiProjects?
Would solve literally every single issue I have except for the open intolerance, which is a secondary issue. Warrenᚋᚐᚊᚔ 13:50, 12 September 2024 (UTC)[reply]
Done [5] jps (talk) 17:45, 12 September 2024 (UTC)[reply]
Meanwhile, I believe what you have been referring to many times here is the Cargo cult thread
Funny enough, I haven't even gotten around to reading that one. FTN is genuinely pushing majority-NRM focused some days. Warrenᚋᚐᚊᚔ 13:51, 12 September 2024 (UTC)[reply]
You made an erroneous distinction: "religious history and theology, as opposed to a specific empirical claim". These are not cleanly distinct things. Religious history and theology is rife with empirical claims (Lazarus e.g.), and these are not exempt from "fringe". Your argument is weirdly personifying a noticeboard of hundreds of people with statements as though it were an monolith, like "FTN is unable to handle some religious topics in good faith", with zero evidence. Perhaps the reason you get a "hot" response is because you write accusatory, wrong and confused statements about "problems" which, without any evidence, come across as borderline trolling.This is all seems track back to when FTN addressed your own muddle over panspermia where,[6] instead of grappling with the problems at hand, you perceived some kind of problem with the noticeboard that was solving those content problems. There you wrongly asserted It’s absolutely erroneous to say “panspermia is a fringe theory” which, ironically, shows the very lack of understanding of specialist terminology you are now attacking here in imagined others. Instead of taking on the chin, you insinuated there was some kind of issue with FTN ("I do think that there's something very problematic here going on"). As another user observed in that linked thread "Instead of trying to find a solution, you are making accusations while claiming you are not". And so we have this pattern here again. It is a time sink. (It should be noted, if this[7] is to believed, that the OP's editing has been to FTN and ANI hugely more than to anything else in the Project, which tells its own story. I'm thinking WP:NOTHERE.) Bon courage (talk) 14:56, 12 September 2024 (UTC)[reply]
There you wrongly asserted It’s absolutely erroneous to say “panspermia is a fringe theory” which, ironically, shows the very lack of understanding of specialist terminology you are now attacking here in imagined others
Well, seeing as I’m a research meteoriticist (essjay aside) I’m pretty comfortable pointing to that specific example as “strong options, little expertise” on the point of FTN. In fact, I’m far more comfortable pointing to that one as an example of FTN inexpertly handling nuanced topics than I am around any of the religious ones. Theres a reason it was very easy for me to cite a pile of papers which make the case that researchers are using “panspermia” in a way that Wikipedia insists is only pseudo-panspermia. The distinction on Wikipedia cannot pass WP:VERIFY, WP:IDIDNTHEARTHAT at FTN aside, which is why I think the best proposal was bifurcating it to Panspermia (Astrobiology) and Panspermia (Fringe theory). FTN is extremely slow to acknowledge there may be a fundamental misunderstanding on the part of the noticeboard around a fringe topic. Of course, trying to bring in a bit of nuance with citations didn’t stop people from accusations of being WP:PROFRINGE and possessing a
lack of understanding of specialist terminology
I’m going to be very honest, since your first post here commenting you’ve been fully on the offensive insisting this is some kind of misguided personal crusade. Between assuming motivations/incompetence on my part and some shall we go with routinely characterful reimagining of the posts you’re responding to I think I’m at least going to bow out of engaging with your replies here, and suggest we consider that mutual to avoid gunking up discussions more. Warrenᚋᚐᚊᚔ 10:34, 16 September 2024 (UTC)[reply]
I would expect an article on a religion to describe, e.g., the foundational documents, the liturgy, the rituals, the tenets. Excluding believers would exclude the editors most likely to be familiar with the literature. As long as an editor is neither attacking nor proselytizing, I don't see a COI. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:23, 11 September 2024 (UTC)[reply]
This just seems to be an argument against the entire concept of regulating COI editing... COI in general applies to the editors most likely to be familiar with a topic, for example the editors most familiar with Edward P. Exemplar are likely Edward himself, his friends, and his family... But we absolutely do not want Edward himself, his friends, and his family writing that article. Horse Eye's Back (talk) 16:44, 17 September 2024 (UTC)[reply]
I personally thrill when people who are less hostile than I to religions post at WP:FTN and I thrill when people who are more hostile than I to religions post at WP:FTN. Generally, I thrill at anyone posting at WP:FTN. Though I may object (sometimes strenuously) to others' positions, I welcome their positions being aired as it helps clarify Wikipedia editorial praxis. I may be singular in this, I understand. Someone with sage observational skills pointed out that I may simply enjoy having arguments more than others. But I have learned things from such arguments and I do think that these discussions have helped clarify matters. Can't there be different strokes for different folks?
Maybe a resolution could be adding a request in the FTN boilerplate that when people start a thread that they notify relevant WikiProjects?
jps (talk) 17:03, 11 September 2024 (UTC)[reply]
I enjoy having arguments more than you do. Phil Bridger (talk) 19:14, 11 September 2024 (UTC)[reply]
If they're notifying the WikiProjects, then it's a content dispute, and so it should be handled by the WikiProjects, or else RfC. If the intent is that FTN is a general-purpose board for fringe content, then that's the domain of a WikiProject, not a P&G noticeboard. (And just because FT has a separate guideline page, does not mean it automatically needs its own noticeboard; and in a separate point, I'd be interested if there's anything in FT that is not entirely redundant with the extensive RS and OR guidelines.) SamuelRiv (talk) 07:19, 12 September 2024 (UTC)[reply]
Eh? All noticeboards except ANI/AN are for content disputes. The stated purpose of FTN is to "help determine whether [a] topic is fringe and if so, whether it is treated accurately and impartially". There is quite a bit in WP:FRINGE which is distinct, for example WP:FRIND, WP:NFRINGE and WP:PARITY. Bon courage (talk) 07:36, 12 September 2024 (UTC)[reply]
You are free to propose FTN for deletion if you don't like the way it is set-up. Others have done so in the past.
I think the consensus has generally been that it's okay to have a centralized discussion board that brings together people who have a general interest in topics that are relevant to WP:FRINGE. WikiProjects have remits which go well beyond that sort of thing.
jps (talk) 15:39, 12 September 2024 (UTC)[reply]
Neutrally worded notices to noticeboards or projects are not canvassing, and it's always possible to post to different noticeboards and projects if you feel that greater participation would help. So if something is posted to FTN there is nothing stopping you ftom adding notifications to projects that you feel are involved. -- LCU ActivelyDisinterested«@» °∆t° 20:03, 11 September 2024 (UTC)[reply]
That would be both interesting and useful. It's no secret for example that Falun Gong-aligned accounts once maintained a chokehold on Falun Gong-related English Wikipedia articles like Shen Yun, Epoch times, and Li Hongzhi before a handful of editors finally broke it up. Today many of the responsible WP:SPA accounts have been zpped but new accounts constantly pop up trying at new angles to manipulate coverage. The matter has seen discussion in peer-reviewed material but it is poorly documented on Wikipedia itself. :bloodofox: (talk) 08:05, 12 September 2024 (UTC)[reply]
I think that Wikipedia:Arbitration/Requests/Case/GamerGate is also relevant, but in a very different way. That's the case in which being the target of something like Death by a thousand cuts results in the community blaming the victim for not being able to tolerate even more "minor" annoyances.
I feel like there is some of that going on above. People aren't reacting here, as if from a tabula rasa, to the exact statements being made. They're reacting to long histories and perhaps what sounds like coded meanings or Dog whistle (politics). So, e.g., maybe you didn't directly say "having a religious belief is automatically a COI" – or at least not in this discussion – but other editors have said this, and you said something that reminded them of the overall climate on wiki. And now you're mad at them for noticing the overall climate, or for assuming that you agree with it, and anyway, how dare they be upset about something that upsets them?
If you haven't personally seen editors claiming that being religious is a problem, then I point out that there are l-o-n-g discussions open at ANI and COIN right now about whether being a member of a particular Christian denomination is a formal COI. Note that I'm not linking them because I think that having anyone in this discussion join them would be a bad idea – too much risk of us providing more heat than light, and all that. WhatamIdoing (talk) 17:47, 12 September 2024 (UTC)[reply]
I've never seen anyone say that having a religious belief is automatically a COI, I've seen people say that religious belief or affiliation can be a COI and people say that it can't be. Nothing in policy or guideline seems to support the "can't" side while the "can" side is currently consensus. Horse Eye's Back (talk) 18:03, 13 September 2024 (UTC)[reply]
I don't remember seeing anyone claim that all religious beliefs are always a COI. I have seen editors say that having specific, uncommon religious beliefs (e.g., anyone who belongs to this or that 'cult') is a COI for any articles related to that subject area.
ArbCom disagreed in 2010: "For example, an editor who is a member of a particular organisation or holds a particular set of religious or other beliefs is not prohibited from editing articles about that organisation or those beliefs but should take care that his or her editing on that topic adheres to the neutrality policy and other key policies."
But editors are not required to agree with ArbCom. WhatamIdoing (talk) 18:34, 13 September 2024 (UTC)[reply]
Editors with a COI are not prohibited from editing pages regardless so not sure if there actually is any disagreement there. The catch-22 is that if it is possible to identify the editor's religious affiliation from their edits alone then their edits aren't NPOV. Horse Eye's Back (talk) 05:26, 14 September 2024 (UTC)[reply]
I don't think that's always true, but the case I worry about more is the incorrect "identification". WhatamIdoing (talk) 05:42, 14 September 2024 (UTC)[reply]
In what context is a COI editor actually prohibited from making edits? Incorrect identification is not an outing concern, so not sure why you would worry more about that than legit outing but OK. Horse Eye's Back (talk) 06:36, 14 September 2024 (UTC)[reply]
Incorrect identification is a Wikipedia:Harassment concern. Earlier this year, you made false COI accusations about an editor – based on off-wiki information that turned out to be incomplete in important ways – that resulted in that editor feeling strongly pressured to disclose the highly personal situation that led to them being kicked out of the religion they were raised in. This is bad for Wikipedia, and it is bad for the falsely accused editors. You shouldn't have done that. IMO editors should be strongly discouraged from following your example.
COI editors are officially not prohibited from making all edits, but COI editors are officially prohibited from making most types of contributions. However, in practice, WP:Nobody reads the directions, and many of them are told by well-meaning editors that they shouldn't make any edits at all, and some of them are also told that if they do, then they'll be dragged to ANI or COIN for a criticism and self-criticism session. See, e.g., fully disclosed paid editors being told that simple updates for outdated information should be handled through the edit request system because "it's best" if paid editors never touch the mainspace. It is best – if your personal values prioritize purity over up-to-date articles. WhatamIdoing (talk) 16:52, 14 September 2024 (UTC)[reply]
Well that suddenly took a person turn... These are serious aspersions and that is not my memory of what happened in what ways was the infomation incomplete? I would also note that those allegations turned out to be 100% valid, they were not in any way false. "COI editors are officially prohibited from making most types of contributions" doesn't appear to be true, as far as I can see they are not officially prohibited from making any type of contributions in particular. Horse Eye's Back (talk) 14:59, 15 September 2024 (UTC)[reply]
Casting wp:aspersions is "accus[ing an editor] of misbehavior without evidence". You were accused of misbehavior for a specific course of events. I was not a part of this, it was not linked, and I don't really care, but I found the narrative easy to enough to follow that it seems to me that if I asked you both to spell out in detail the factual series of events, you'd agree -- that's why it's not aspersions.
Since the topic of this sub-sub-thread is COI, and the editor brought up this sad tale because it directly relates to COI, I also see nothing personal or uncivil in it. You state there is a factual lie or inaccuracy in the narrative, so that probably should be hammered on your own respective talk pages. SamuelRiv (talk) 15:01, 16 September 2024 (UTC)[reply]
The catch-22 is that if it is possible to identify the editor's religious affiliation from their edits alone then their edits aren't NPOV.
okay, but I’ve been accused of being Falun Gong for my comments on FTN, so maybe nobody should be trying to divine the religion of editors on the basis of their edits?
like don’t get me wrong, if someone is editing a JW article with watchtower talking points that’s definitely an issue, but there’s little value I can imagine in trying to “gotcha” an editor’s faith and if their editing is a COI issue or otherwise problematic that can be addressed. Someone may simply have bad information and be editing on that basis. Warrenᚋᚐᚊᚔ 10:43, 16 September 2024 (UTC)[reply]
If people's affiliation can be inferred from NPOV edits, then I'd say that's working-as-intended. People can be TBanned for repeated or blatant NPOV on contentious/vulnerable articles without any reference to COI -- that's the whole premise for TBans on stuff like Israel-Palestine (nobody would say that being a national from one or the other is a COI to edit respective articles). Political fervor is quite the driver of disruptive editing -- if that is regulated without COI then why are some here calling for COI for religion?
(fwiw, I'd argue "religious affiliation" is not usually the same as affiliation/membership in a specific church bureaucracy/org that is affiliated with that religion -- so for example one could argue CoS is a church-organization that is affiliated with dianetics philosophy/religion; then an employee of CoS has COI by existing policy. I realize that definition would put a monolithic-monocephalous church in a grey zone, but I'd again say NPOV is sufficient.) SamuelRiv (talk) 15:21, 16 September 2024 (UTC)[reply]
To clarify, I am 100% not endorsing any sort of on-wiki assertion or accusation of another editor's religion or political beliefs based on their editing habits (agreeing Warren above). I am saying such blatant NPOV edits can be called out for what they are, as they have been in every contentious topic area. (It's common also to call out poor or undue sourcing, synth, cherrypicking, etc. -- blatant bad behavior be blatant.) SamuelRiv (talk) 18:14, 16 September 2024 (UTC)[reply]
The trouble with COI editing is it's often not "blatant", but like "dirt in the gauge" of the fine instrument in consensus forming. A !vote in a RfC here, a change of emphasis in an article there, and hey presto! POV achieved! The basic truth is that Wikipedia fails to deal with COIs because of its emphasis on the primacy of anonymity. The two are irreconcilable. Thus: the shit-show continues, and will continue for ever until Wikipedia gets a grip and turns into a serious Project. Bon courage (talk) 18:27, 16 September 2024 (UTC)[reply]
COI can be a subtle problem, but so can many other things. Someone attempting a subtle change in emphasis is not necessarily a bigger problem than editors who believe they're always right – and we have lots of those (including me, except that I really am always right!). If I have to choose between an editor who determines reliability on the basis of whether the source says the Right™ Thing and an editor with a secret COI who wants to slightly shift the emphasis of an article, I might not always think that the latter is the bigger problem. WhatamIdoing (talk) 18:54, 16 September 2024 (UTC)[reply]
That would be to misunderstand, fundamentally, the pernicious nature of COI. People may - on their own behalves - argue passionately in many directions. But when an external interest is exerting influence, the outcome of decision-making will depend of which interest has most sway. It is why serious consensus-making fora (i.e. not Wikipedia) tend to have stringent rules on COI transparency. Bon courage (talk) 19:03, 16 September 2024 (UTC)[reply]
I don't think I'm misunderstanding COI. I think I'm saying that I'd rather have a small problem in an article than a big one. WhatamIdoing (talk) 21:24, 16 September 2024 (UTC)[reply]
Well, you were choosing types of editors you'd maybe prefer. Bon courage (talk) 02:40, 17 September 2024 (UTC)[reply]
A subtle shift in article focus seems like a smaller problem than a big bias in source choice; ergo, I'd choose the editor who spends multiple years pushing for a small shift in focus over the editor who spends multiple years pushing to exclude good sources with the 'wrong' POV and include weak sources with the 'right' POV. WhatamIdoing (talk) 04:26, 17 September 2024 (UTC)[reply]
Hah! Editors are wrong all the time, and preferring weak sources to strong ones is of course a common fault particularly in newbies. But here's the thing: editors with a brain and good faith will generally change their mind, modify their position or gracefully concede a point if they are presented with cogent opposition but have no skin in the game. They learn and grow. The COI editor will forever press Wikipedia to follow the line that they've been assigned, without deviation. I'd rather have an editor corps of messy but correctable human beings than apparatchiks dedicated to shaping content in some particular way so as to advance an outside interest. Bon courage (talk) 04:46, 17 September 2024 (UTC)[reply]
But editors who do have skin in the game, but not of the sort that 'counts' as a COI, don't generally change their minds. They forever press Wikipedia to follow the line that they've personally adopted, without deviation, exactly like that irritating family member that you never want to hear talking about politics at any family gathering.
Also, paid editors are often temporary: eventually, either we come to a plausible compromise (and sometimes that 'subtle shift in article focus' is actually warranted, though not generally with the wording that the marketing department suggests), or the payer decides to quit throwing good money after bad.
People who feel aggrieved about something will argue for decades about their pet thing. I know one who is still upset that his mother had to pay inheritance taxes half a century ago. I don't know if he would agree that he's a "messy" human being, but I am convinced that if he were editing Wikipedia, he would not be a "correctable" one.
Perhaps putting it in WP:UPPERCASE will help: Given a choice between a WP:GREATWRONGS editor pushing bad sourcing and a WP:COI editor pushing a subtle shift in emphasis, I'm often going to prefer the COI editor. WhatamIdoing (talk) 05:26, 17 September 2024 (UTC)[reply]
Or we could just have neither editor... Thats clearly the best solution in terms of improving the encyclopedia. It doesn't have to be one or the other, both the tendentious editor and the COI editor who doesn't respect NPOV can be shown the door if they don't change. Horse Eye's Back (talk) 06:15, 17 September 2024 (UTC)[reply]
Don't spoil it HEB. WAID has chosen her beau and I have chosen mine. We shall both go to the dance and have a thoroughly miserable time. Bon courage (talk) 06:26, 17 September 2024 (UTC)[reply]
Neither would be lovely. However, for some unaccountable reason, the paperwork to declare me Queen of Everything seems to have gotten lost, and until that's resolved, I don't think it's feasible. WhatamIdoing (talk) 19:18, 17 September 2024 (UTC)[reply]
Not seeing why both would be any less feasible than one or the other... If both can be done individually then both can be done together. Horse Eye's Back (talk) 16:27, 18 September 2024 (UTC)[reply]
Neither can be done consistently or reliably. WhatamIdoing (talk) 17:39, 18 September 2024 (UTC)[reply]
If neither can be done then why is the choice either or? Horse Eye's Back (talk) 16:25, 19 September 2024 (UTC)[reply]
Because sometimes figuring out whether Bad Thing #1 is better or worse than Bad Thing #2 is helpful to people. It can help people develop perspective and prioritize their efforts. WhatamIdoing (talk) 21:04, 19 September 2024 (UTC)[reply]
The effect seems to be to excuse one of the bad things, why can't we just say that both are bad and should result in full or partial seperation from the project and which is badder is up to context and personal opinion? Horse Eye's Back (talk) 14:30, 20 September 2024 (UTC)[reply]
We did say that. WhatamIdoing (talk) 16:59, 20 September 2024 (UTC)[reply]
Then perhaps I do not understand the point you wished to make. Horse Eye's Back (talk) 17:17, 20 September 2024 (UTC)[reply]
While I also agree that neither is best if possible, I am also always going to prefer an editor editing in good faith to an editor editing in bad faith. Loki (talk) 19:53, 17 September 2024 (UTC)[reply]
Of course, but few people, except blatant vandals, think they are deliberately trying to make Wikipedia worse. A paid agent may think they're making Wikipedia more accurate or fairer. A personal POV pusher may believe they're making Wikipedia better by giving a little more respect for an idea they believe. Even the parents who show up at Talk:Santa Claus every December, to ask that we not "ruin" Christmas by telling their kids that Santa Claus isn't a living, breathing magical person think they're trying to make Wikipedia better.
That's why the rule is Wikipedia:Assume good faith: assume that the other person – no matter how stupid, misguided, or wrong they may actually be – is actually trying to do something that in their opinion will make Wikipedia better. To put it more bluntly, when the white supremacists show up with their racist garbage, we assume that they're trying to make Wikipedia better according to their own way of thinking, even though we don't agree that their garbage actually makes it any better. WhatamIdoing (talk) 00:44, 18 September 2024 (UTC)[reply]
Yes indeed, I think "bad faith" is one of the most misunderstood/misused phrases on Wikipedia. Bon courage (talk) 11:40, 18 September 2024 (UTC)[reply]
Maybe it would help if we re-wrote Wikipedia:Tendentious editing to say "Tendentious editing is a pattern of good-faith editing that is partisan, biased, skewed, and does not maintain an editorially neutral point of view." WhatamIdoing (talk) 17:41, 18 September 2024 (UTC)[reply]
I agree, which is why I think COI editing is so egregious, because it's one of the few kinds of editing that is actually in bad faith. Loki (talk) 18:41, 18 September 2024 (UTC)[reply]
@LokiTheLiar, imagine that someone works for a big company. In the actual marketing department, no less. This person notices that the number of employees in {{infobox company}} is several years out of date. Imagine that the employee corrects the error.
In your opinion, is that employee "trying to hurt Wikipedia" or "trying to help Wikipedia"? WhatamIdoing (talk) 19:43, 18 September 2024 (UTC)[reply]
You didn't provide the piece of information we would need to know in order to determine that... Their intention. It is most likely that their intention was to promote their company therefore their intention was to hurt wikipedia, but unless you provide that piece of the puzzle the question is (perhaps purposefully) unanswerable in a straight manner. Horse Eye's Back (talk) 14:26, 20 September 2024 (UTC)[reply]
This: their intention was to promote their company therefore their intention was to hurt wikipedia is a logical fallacy. WhatamIdoing (talk) 16:58, 20 September 2024 (UTC)[reply]
How so? The use of wikipedia for promotion unambigously hurts wikipedia, thats why we explicitly ban it (WP:PROMO). Anyone who intends to engage in promotion, advertising, or recruitment intends to hurt wikipedia. Horse Eye's Back (talk) 17:19, 20 September 2024 (UTC)[reply]
While I disagree with him on many COI things, I'm behind HEB here. Correcting an error in order to promote an organization that is paying you to promote them is a bad faith edit and harms Wikipedia.
To see why, imagine that article has three estimates in it for number of employees: one that is too low, one that is correct, and one that is too high. The COI editor only corrects the one that is too low despite being aware of all of them. Is that a good faith edit? Loki (talk) 19:22, 20 September 2024 (UTC)[reply]
@LokiTheLiar, see the comment where I've already addressed the biased assumption that more employees is better for a company. (Hint: Layoffs usually result in stock prices going up, not down.)
Also, what if there aren't three estimates? What if it's just one wrong number in an infobox, and the COI editor is merely correcting a simple factual error?
Just because a person with a COI could make an edit that is intended to harm Wikipedia – or, more likely, that is intended to help the company and doesn't care whether Wikipedia is helped or harmed – doesn't mean that every single edit made by that person is inherently harmful. WhatamIdoing (talk) 20:07, 20 September 2024 (UTC)[reply]
Thats true , but every promotional edit they made would be inherently harmful. They could also make other edits but thats not really the point. Horse Eye's Back (talk) 17:26, 25 September 2024 (UTC)[reply]
{outdent}
Two things:
Simply replacing inaccurate or outdated information with accurate, up-to-date information unambiguously helps Wikipedia.
"As of 2012, the company had 190 employees" → "As of 2024, the company had 165 employees".
"As of 2012, Alice Expert was the CEO" → "As of 2024, Bob Business was the CEO".
Correcting a factual error is not inherently promotional.
Whether more or fewer employees is better (and therefore potentially promotional) depends on how you interpret that. For example, is having slightly fewer employees a sign of good management leading to greater efficiency and productivity, or is it a sign of a shrinking, struggling company that can barely make payroll?
Have you ever heard of a win–win scenario? On those occasions when what's best for Wikipedia happens to match what's best for the company, then Wikipedia is not actually harmed by the company getting what they want.
There are many circumstances in which what's good for the company is bad for Wikipedia, but there are also circumstances in which what's good for the company is also best for Wikipedia. WhatamIdoing (talk) 18:26, 20 September 2024 (UTC)[reply]
In re Thats true , but every promotional edit they made would be inherently harmful. They could also make other edits but thats not really the point.
No, that really is the point. Exclusively promotional edits are harmful, no matter who makes them. A good edit made by a Bad™ person is still a good edit. A bad edit made by a Good™ person is still a bad edit. WhatamIdoing (talk) 19:25, 25 September 2024 (UTC)[reply]
The win-win scenario is when the COI editor makes an edit request like they're supposed to... If they make the edit directly thats a loss for wikipedia. We don't scrub the edits of confirmed COI editors, your argument would only make sense if we did. Horse Eye's Back (talk) 16:00, 27 September 2024 (UTC)[reply]
Break
the editor who spends multiple years pushing to exclude good sources with the 'wrong' POV
I've definitely seen this habit at FTN, and it was one of the impulses for this thread. If FTN has decided their specific understanding of a topic, collectively, is the "correct" one then attempts to address that are often met with accusations of POV-pushing, attempts to introduce FUD for WP:PROFRINGE purposes, etc.
The example raised above is a pretty good one for this. Wikipedia has a hard deliniation between Panspermia and Pseudo-panspermia, but this hard deliniation doesn't exist in the literature and "panspermia" is regularly and routinely used to refer to what Wikipedia calls "Pseudo-panspermia". Note that this isn't "the scientific literature is actually down with the fringe theory" but rather "the specific terminalogical bifurcation that Wikipedia is using is an artifice of Wikipedia and risks confusing readers who come to Wikipedia on this topic from credible sources."
No amount of academic, primary, secondary, etc. sources that show that "Panspermia" can and is regularly used to refer to it landed with anything other than a wet thud and accusations from some of the FTN core. Even in the Tukdam thread that's on FTN right now there's a "Well we can't consider that credible source" (which is, to be fair, actually arguable on the sourcing, but not cut-and-dry per WP:RS). There seems to be this attitude of absolute certainty that arises from FTN which outpaces the ability of people whose personal expertise is more rooted around fringe theories to evaluate.
See: above with me being accused of not understanding specialist terminology in my own field. Warrenᚋᚐᚊᚔ 08:47, 17 September 2024 (UTC)[reply]
You asserted, with the "absolute certainty" you are projecting onto others It’s absolutely erroneous to say “panspermia is a fringe theory”. You were shown the sources to show why this was wrong and had to concede "The Science Direct link you provided is certainly evidence that both terms are used". In such cases Wikipedia need to manage the terminology and use hatnotes to guide the reader, and this is what happened. Consensus was achieved and things improved thanks to FTN. Yet here you are rewriting history and somehow it's the fault of "FTN" that you were in a muddle. It's all very odd. Have you considered the problem isn't with FTN at all, but somewhere else? Bon courage (talk) 14:16, 17 September 2024 (UTC)[reply]
If you have an issue with me personally take it to WP:ANI.
Here is the thread which is being very creatively represented above for anyone who'd like to evaluate it for themselves. FTN's "consensus" on this topic was exactly what @WhatamIdoing seemed to be worried about.
This thread just feels like a huge waste of time at this point, and it really didn't have to. Warrenᚋᚐᚊᚔ 14:51, 17 September 2024 (UTC)[reply]
In fact the thread sprawled to here where the issue was resolved. If I took every editor that was wrong about something to ANI I'd never be out of the place (and would have to take myself there regularly!). I think we can all agree this thread has been a waste of time. It was always going to be since there was no evidence and no proposal. Perhaps this can - for all our sakes - be the last time this particular FTN complaint pony is taken round the park. Bon courage (talk) 14:58, 17 September 2024 (UTC)[reply]
I genuinely can't even begin to think of how to respond to this. Warrenᚋᚐᚊᚔ 15:15, 17 September 2024 (UTC)[reply]
Not all religions are fringe. Falun Gong is, though. It's more or less a blend of religion and the John Birch Society. Its publications have promoted inaccurate conspiracy theories. pbp 13:41, 14 September 2024 (UTC)[reply]
No. Religion is ubiquitous in most parts of the world. While many if not most of the various religions of the world hold beliefs that are not provable by science, they are just that beliefs. While all fringe theories could be categorized as beliefs, not all beliefs are fringe theories. Elmmapleoakpine (talk) 18:55, 25 September 2024 (UTC)[reply]
A religious belief that has no effect on the rest of scholarship is just that. For example, a claim that pure land exists is generally so far removed from physical reality as to be basically just worth documenting as a major belief in Buddhism. However, there are those Buddhists, some of which are more active than others, who claim that there exists a literal Mount Meru that one can actually discover here on Earth. That is a WP:FRINGE theory. jps (talk) 20:25, 26 September 2024 (UTC)[reply]
Not all beliefs are fringe... But all "beliefs that are not provable by science" are fringe. Horse Eye's Back (talk) 16:03, 27 September 2024 (UTC)[reply]
That's not true. Firstly, it's not true because the policy defines a fringe view as "an idea that departs significantly from the prevailing views or mainstream views in its particular field", not according to whether the view is provable by science.
Secondly, it's not true because it's goes against common sense. Views in non-scientific fields (e.g., art criticism, history) are never provable by science and can still be classified as mainstream or fringe. It's nonsense to say that since, e.g., fictional characters can't be scientifically proven to exist, then all views about them are fringe. WhatamIdoing (talk) 17:31, 27 September 2024 (UTC)[reply]
Religious views are never mainstream by definition, no single religion is that large and they don't generally agree on anything. The field of Religious Studies isn't some sort of free for all, even claims which are purely religious can be fringe. The belief that a fictional character was real would be fringe, the mainstream view is that fictional characters are not real. Horse Eye's Back (talk) 15:45, 28 September 2024 (UTC)[reply]
Religious views are certainly "prevailing views", since 85% of the world subscribes to some sort of religious views. Those religious views include ideas that are very widely held (e.g., that humans are different from other animals in some important way; that justice and peace are desirable values; that long-term happiness is something people should seek; that there are good ways and bad ways to relate to others). The belief that justice is better than injustice is absolutely "not provable by science", but it's definitely mainstream. Science might help us understand what actions could achieve specific forms of justice, but science (i.e., excluding the quasi-religion of scientism) can't tell is that justice is good.
When considering not just "the prevailing views" but specifically the "mainstream views in its particular field", we prioritize scholarly sources. For example, most of the world believes in ghosts. The scholars in the relevant fields, using the methods of that field don't. Therefore, "ghosts are real" is WP:FRINGE and "ghosts are not real" is mainstream. There is no limitation here about the relevant field needing to be a scientific one.
Also, let's go back to that fictional character. Othello (character) is a fictional character. What was this fictional character's racial/ethnic background intended to be? There are two mainstream views. Neither are provable by science. Neither of them are WP:FRINGE. A view that "departs significantly from the prevailing views or mainstream views in its particular field" might say that Othello was Irish, and this would be FRINGE. A view that aligns with the mainstream views in the field might say that Othello was a brown-skinned Muslim from the Mediterranean coast, and this would not be FRINGE. But the relevant fields are literary studies, theatre studies, and history, none of which are science. Each view on that question is declared FRINGE or not FRINGE without any reference whatsoever to whether the view is "provable by science". WhatamIdoing (talk) 23:47, 28 September 2024 (UTC)[reply]
There's been another exchange on FTN in the last few days that I think really highlights my issues here. A user (@ජපස:) removed the entire section on academic study from the Tukdam article. They removed a link to a UW-Madison research group publishing on this topic using brain scans and other methods. He dismissed their papers out of hand as not being justified in the article with
It's a bit misleading to claim it's been studied by "western academics". It's actually been studied by religious believers.
Which is obviously not how any of this works. We cannot just decide that the religion of an author is basis for us ignoring the fact that they're publishing in serious journals when research scientists with an American university (not just religious scholars playing with brain scans for fun without any idea what they're doing) and an even passing knowledge of the field of Buddhist Studies will make it very clear that scholar-practitioners are the norm in the field. And this is why FTN should tread cautiously with assuming they know the fields they're editing in. "Well the author is a Buddhist and can't be trusted to write about Buddhism" is not a reasonable take, especially in the context of an academic field that both routinely stands up to outside scrutiny of their scholarship and which is typically rife with people who both practice their faith and publish on it in critical, objective ways.
Why are FTN regulars deciding that the religion of authors is enough to justify the removal of entire sections when we're talking about accepted peer-review publications in Forensic Science International: Reports, Culture, Medicine, and Psychiatry, and Ethnos? Why are we tolerating the dismissal of credible, non-Bealles-list peer-reviewd sources on the grounds of the religion of the author when there's zero evidence whatseover of wrongdoing that could have implicated the study in question or its authors? Wikipedia is worse for this type of editing, incredulity and personal (ir-)religious philosophy shouldn't be dictating the content of articles.
I feel it's an important detail here that the results of the studies in question didn't particularly support wild, fantastical conclusions that warrant incredulity. The claim was "Meditating dead monks are still somewhat alive" and the paper's conclusion was "He's dead, Jim." It feels like the religion of the authors is the whole basis for the objection of inclusion here, which is not at all how WP:NPOV and WP:RS work, but on FTN it can. This is, to me, simply open bigotry, which is something I've been expressing some frustration at here.
Neutrally worded notices to noticeboards or projects are not canvassing
When a noticeboard starts having its own interpretation of the sites rules and it operates on those, and does so on obscure parts of Wikipeida that may not have many eyes on it, then yes, the official canvassing policy aside if can very much feel like "I want to bring this issue only to people who have the same interpretation of policy that I do." Warrenᚋᚐᚊᚔ 09:02, 28 September 2024 (UTC)[reply]
"I want to bring this issue only to people who have the same interpretation of policy that I do.", so about (insert project name here)... -- LCU ActivelyDisinterested«@» °∆t° 10:07, 28 September 2024 (UTC)[reply]
At this point it would appear to be you who holds heterodox interpretations of policy... Not the guys you keep ranting about. Horse Eye's Back (talk) 15:49, 28 September 2024 (UTC)[reply]
Based on community action earlier this year, Warrenmck is not the one with the heterodox interpretation. A thread at ANI a few months ago ended in a topic ban for a user who was rejecting citations to academically published material about Islam merely on the grounds that the academics were Muslims. Excluding content cited to academically published material about Buddhism merely because the academics were also Buddhists is the behavior and interpretation that's out of step with the community. Hydrangeans (she/her | talk | edits) 16:35, 28 September 2024 (UTC)[reply]
Thank you. I genuinely feel a little crazy with these exchanges here. Between this and the discussion above about how all religions are totally fringe I feel like some of FTN isn't engaging with, well, WP:FRINGE in good faith when it comes to topics of religion, which can result in article quality being reduced, which isn't what any of us want from noticeboards.
It's pretty clear that, while maybe not a huge systemic thing, several editors are using FTN to grind a particular axe. The is probably where things like attacking a credible scholar on the basis of their faith without any evidence whatsoever of impropriety comes from as far as I can tell, because it's certainly not coming from WP:FRINGE or WP:RS. Warrenᚋᚐᚊᚔ 14:36, 30 September 2024 (UTC)[reply]
Over the years, I have rejected a variety of publications about Isra' and Mi'raj on the basis of the apologetics of the author. The fact that academics who are arguing in favor of the literal truth of that story are Islamic is absolutely relevant. It is also the case that the research program Warren is whining about did not result in any solid publications. Not any that would pass WP:REDFLAG certainly. The article text just linked to their research group and press releases! The fact that this guy from UWisc is a devotee of Tibetan Buddhist approaches to meditation while claiming that Buddhists who are good at meditating continue to meditate after they are dead is WP:BOLLOCKS influenced by a blinkered religious devotion. It's the equivalent of Young Earth Creationism or Hindu astrology. jps (talk) 15:52, 30 September 2024 (UTC)[reply]
claiming that Buddhists who are good at meditating continue to meditate after they are dead: Except that apparently isn't what the source claimed, or at least it isn't what was in the article text. The article text that you twice removed (wholesale, with no attempt at just trimming) stated that the study did not detect any brain activity in clinically dead tukdam (italics added). As Warrenmck said that the conclusion was "He's dead, Jim." What's so 'bollocks' about that? And what's so un-solid about the source, a research center at a secular state university (University of Wisconsin-Madison)? You pay no apparent notice to the secular university setting of the source nor to the utterly plausible results of the research (that no, there is no detectable brain activity from the dead monks); all you offer is your apparent revulsion that the researcher was a Buddhist. It's frankly bigotry, and the way you let it influence your editing is disruptive. Hydrangeans (she/her | talk | edits) 18:59, 30 September 2024 (UTC)[reply]
The suggestion that jps has any "apparent revulsion" is unwarranted here. Are we reading the same source? This one appears problematic to me, and the article content being sourced to it should not have relied on such a source. Firefangledfeathers (talk / contribs) 19:07, 30 September 2024 (UTC)[reply]
I think that section should definitely be trimmed but obviously not removed. It's a real and secular study that didn't find anything WP:EXTRAORDINARY, so saying that it existed and didn't find any brain activity ought to be utterly uncontroversial. Loki (talk) 19:52, 30 September 2024 (UTC)[reply]
The EEG on a corpse was hardly the only thing they claimed to "test". The entire enterprise is an ideological juggernaut that includes things like asking the asinine question as to whether the corpses decay at different rates depending on their status as meditators -- claims which are so ridiculous as to be nearly impossible to operationalize. The lack of serious peer-reviewed work in serious journals on this attests to that. The attempt to argue that there is any legitimate research interest whatsoever into whether there might be measurable signs of this religious belief is belied by the fact that WP:FRIND sources are totally absent discussing this. jps (talk) 00:58, 1 October 2024 (UTC)[reply]
The lack of serious peer-reviewed work in serious journals on this attests to that.
From the research group you removed from the article as a "shit" source:
Delayed decompositional changes in indoor settings among Tibetan monastic communities in India: A case report - Forensic Science International: Reports (Elsevier)
Life in Suspension with Death: Biocultural Ontologies, Perceptual Cues, and Biomarkers for the Tibetan Tukdam Postmortem Meditative State - Culture, Medicine, and Psychiatry (Springer)
Death and Reincarnation in Tibetan Buddhism: In-Between Bodies - book (Routledge)
The Biographical Process of a Tibetan Lama - Ethnos (Taylor & Francis)
Re-Examining Death: Doors to Resilience and Wellbeing in Tibetan Buddhist Practice Religions (MDPI)
No Detectable Electroencephalographic Activity After Clinical Declaration of Death Among Tibetan Buddhist Meditators in Apparent Tukdam, a Putative Postmortem Meditation State - Frontiers in Psychology (Frontiers)
it certainly looks like It is also the case that the research program Warren is whining about did not result in any solid publications. may have been a bit off the mark? Thanks for accusing me of "whining" though.
C'mon. I see a list that includes predatory and pocket journals, FrotiersIn, MDPI, and moribund backdoors to avoid peer review by competent scholars. And you were already warned at WP:FTN about promoting Frontiers as a potential WP:RS. These are terrible sources for claims about corpses decaying. This is basically WP:PROFRINGE. jps (talk) 15:18, 1 October 2024 (UTC)[reply]
Or not. Frontiers in Psychology is a highly rated journal.[8] Their WP:Impact factor is more than twice the average for the field. Beall's List said that "Some of their journals have a very poor peer-review; some are fine." WP:CITEWATCH says that these journals should be evaluated "case by case", which is significantly different from "anything and everything from MDPI is a terrible source" or "anything in MDPI is basically PROFRINGE". WhatamIdoing (talk) 17:06, 1 October 2024 (UTC)[reply]
Culture, Medicine and Psychiatry is ranked 90th percentile by Scopus[10] and is indexed by MEDLINE.[11] Their impact factor is high for "culture" and low for "psychiatry".
Ethnos is rated 93rd percentile[12] and has an impact factor a bit above average for anthropology.
Religions is rated 90th percentile[13] with an impact factor that would be typical for sociology (I don't have numbers for religious studies specifically).
Frontiers in Psychology is ranked at the 78th percentile[14] and has an impact factor that's double the typical level for psychology.
I'm not seeing serious problems here. None of these journals are remove-on-sight predatory journals. Some of them are quite respectable. WhatamIdoing (talk) 17:29, 1 October 2024 (UTC)[reply]
Would you rate any of these journals highly for the evaluation of medical conditions or slowing decay? jps (talk) 18:30, 1 October 2024 (UTC)[reply]
A review article in Culture, Medicine and Psychiatry would tick all the boxes for the WP:MEDRS ideal: MEDLINE listed, reputable publisher, good metrics. Dhat syndrome would probably be improved by using their PMID 39136849. Wandering (dementia) would probably be improve by incorporating the POV presented in PMID 29368117. PMID 27142641 looks like it could be useful in Chronic condition or Terminal illness or even Spoon theory, as it presents the process of developing realistic expectations as being a form of healing/healthcare.
I would accept a recent review article, within the usual scope of their field, from any of these journals. I wonder if the problem here is less about the source and more about what the source is being used for. For example, the 1991(!) Cult Med Psy article might be more useful for "Some people have a different concept of death than modern medicine!" than for "It is a definite fact that even though his heart stopped beating last week and he hasn't moved or breathed since then, he's still alive". WhatamIdoing (talk) 19:12, 1 October 2024 (UTC)[reply]
Before I listed Tukdam at WP:FTN, it had been discussed at WT:DYK[15] and transcluded onto the talk page from Template:Did you know nominations/Tukdam. Two editors other than myself had supported the removal of the "Scientific research" section. The primary author of the article restored it.[16] Above, it was mentioned that FTN discussions should be linked from relevant notice boards. Issues about Tukdam had already been raised Wikipedia talk:WikiProject Buddhism weeks before hand.[17] I've added links to both this discussion and the one at FTN just now.[18] If I noticed a problem (a faith-based belief being misrepresented as an evidence-based hypothesis), but I "didn't grasp the language" used by a specialized field, I think posting to a relevant notice board was the correct thing to do. Despite conflicts, do you think that the changes made since the issue was raised improve or worsen the article, Warrenmck? Rjjiii (talk) 16:35, 28 September 2024 (UTC)[reply]
I think most of the changes made so far have been good, and was quick myself to question Tricycle as a source being... not great in the context of that article. None of this has any bearing whatsoever on an editorial decision being presented as based on the faith of the author. An identical conclusion could have been arrived at in any other way, but it's not on me or other editors to discern if just open bigotry is actually masking an in-depth discussion which warrants consideration. If those points exist, then editors should cite them and not the religion of a given academic.
Even if I wholly agreed with every change made (which for the most part, minus the removal of the scientific studies section which I'm still unclear why you and others are calling for its removal, we do agree on) nothing would change in that lines like
It's a bit misleading to claim it's been studied by "western academics". It's actually been studied by religious believers.
shouldn't be happening here. Warrenᚋᚐᚊᚔ 14:29, 30 September 2024 (UTC)[reply]
You're not going to stop my evaluations of religious nonsense by posting to village pump. I'm allowed to make judgement calls in the cause of protecting the encyclopedia from hyperbolic and farcical religious claims. jps (talk) 15:53, 30 September 2024 (UTC)[reply]
I agree with @Warrenmck here. Wikipedia isn't pro- or anti-anything, except pro-verifiability and neutrality. Everyone is allowed to make judgement calls within Wiki rules and consensus (which terms as hyperbolic and farcical do not imply). It's also worth examining what is actually notable about these beliefs; that they exist among a community, or that it wouldn't pass peer-review? A majority of the time with any movement/philosophy (religious or other), it's the former. We could do this about almost anything, like Jesus' resurrection or optimism/pessimism. AnandaBliss (talk) 17:33, 30 September 2024 (UTC)[reply]
I agree that often you want to say something like "Some of these people believe ____". Sometimes an article needs to say "____ is not factually true" (e.g., List of common misconceptions). And I would add a third category: "____ was sensationally claimed in the news/has become a common stereotype in popular culture/was a widespread internet meme in YYYY". WhatamIdoing (talk) 18:05, 30 September 2024 (UTC)[reply]
In this case, the imprimatur of a "research group" was being laundered as a way to claim that there was "serious investigation" into whether or not meditating champions would be able to continue meditating after death and thereby prevent their corpses from decaying. This is pretty WP:BLUESKY nonsense. I do not see how it is at all defensible. jps (talk) 00:51, 1 October 2024 (UTC)[reply]
You again removed the section in question, with the edit comment of
Get better sources if you think there is anything here. These sources are shit.
There's a content dispute here, but also a fundamental behaviour and WP:OWN issue. At no level is how you're engaging with this appropriate. It feels like you have far more of an issue with the fact that the research group exists at all, rather than any substantive issue with their findings. UW Madison and their research group focused on this are credible, and they've published their results in journals like Forensic Science International: Reports, Culture, Medicine, and Psychiatry, and Ethnos. They are a perfectly acceptable secondary source. Ideologically driven editing has no place here. Warrenᚋᚐᚊᚔ 08:22, 1 October 2024 (UTC)[reply]
If we're turning this into a conduct discussion forum, I'd say the bigger problem is that you're supporting poor content based on a poor source. I don't think of this as being a common issue with your work, and my good-faith guess is that maybe your involvement in this conduct dispute is putting up some content blinkers. You've repeatedly restored, for example, a wiki-voice claim that a named individual "remained in tukdam for 13 days". That's obviously not appropriate. If there's a systemic problem at FTN, can we pick cleaner examples? Firefangledfeathers (talk / contribs) 12:50, 1 October 2024 (UTC)[reply]
I have no strong opinions on the exact verbiage of the section before you changed it a lot recently. I have strong objections to the removal of the entire section on absurd grounds that the source isn't good. Not once have you actually raised a specific concern with the source other than what amounts to "C'mon, look at it" which several of us have and have seen no particular issue with.
If there's a systemic problem at FTN, can we pick cleaner examples?
I frankly think the issues around the sources being rejected due to what appears to just be personal incredulity is pretty much is the cleanest possible example, here. Warrenᚋᚐᚊᚔ 13:32, 1 October 2024 (UTC)[reply]
This "personal incredulity" mind-reading gambit is tough to take in good faith. WP:REDFLAG is part of WP:V, one of our core policies. Firefangledfeathers (talk / contribs) 14:14, 1 October 2024 (UTC)[reply]
FWIW, while I also don't think that line is worth including:
a) I think the idea that a whole long section should be blanked because of one bad line is obviously absurd.
b) The source in question I also agree seems fine. Notably it does not endorse that line.
Like a lot of FTN content disputes I'm not entirely sure why it's even happening. It feels like the "skeptic" side, huge airquotes, has dug their heels into an aesthetic commitment so hard they haven't even actually bothered to look at the source. Loki (talk) 19:16, 1 October 2024 (UTC)[reply]
The source explicitly endorses that line, saying "Ling Rinpoche remained in the state for 13 days, exhibiting a fresh life-like appearance in the humid subtropical climate of Dharamsala until the thirteenth day when initial decompositional signs appeared." In context, "the state" unambiguously refers to the tukdam state. As for "whole long section should be blanked because of one bad line": what a weird and untrue guess at the motivation for the removal. Which edit summary hinted at anything of the sort? Firefangledfeathers (talk / contribs) 19:27, 1 October 2024 (UTC)[reply]
I think that sentence would benefit from a re-write. For example, consider "This study began in 1995 after a discussion between neuroscientist Richard Davidson and the Dalai Lama about the meditative death of Kyabje Yongzin Ling Rinpoche, who was said to have remained in tukdam for 13 days because his body did not show visible signs of decomposition until then." WhatamIdoing (talk) 20:01, 1 October 2024 (UTC)[reply]
About They are a perfectly acceptable secondary source: Journals aren't primary/secondary/tertiary sources per se; they're publications in which multiple individual primary/secondary/tertiary sources are published.
All first-time reports of scientific research are primary sources for the results of that research. Wikipedia:Secondary does not mean good. An article that provides comments on the research would be a secondary source, even if those comments say something like "Look at this huge waste of research money" or "All the experts we contacted thought this was a huge joke" or "Here's more proof that peer review doesn't indicate importance, and journal editors aren't immune to clickbait fodder", and even if that commentary is in a popular/non-academic publication. WhatamIdoing (talk) 17:48, 1 October 2024 (UTC)[reply]
Deal with user talk pages that are way too long
According to WP:TPG, the purpose of the user talk pages is to provide space for editors to discuss editing that page. Also, this page specifies that archives over 512kB should not be used for accessibility reasons. There is a good reason for that, as for extremely long pages, browsing on mobile is basically impossible because the browser can't handle the RAM overload and simply breaks, forcing to delete all the other open tabs along the way. My phone stopped responding when trying to put a CCI notice to this guy, who had 1.5 MB of text - and I haven't gone into images yet. My phone isn't particularly old, was first produced in 2017 - there are definitely folks out there with much older hardware on their hands.
More examples: my PC stutters on this, this, this and this user talk subpages; and in the case of Bishonen, these are not mostly newsletter subscriptions but actual talk page, even if archived. So if anyone were to browse it for whatever reason, they may get problems actually loading it, let alone using it for any meaningful purpose. And imagine trying to edit the talk page if, like me, you are editing by default in source code but use syntax highlighters, which seem to be loading the browser pretty heavily. My PC is not that old, either.
For active users, the same issue arises from talkpages like those of AwfulReader. For Dr Sroy or Masao - no longer active, installing Lowercase sigmabot 3 didn't work at all, as their pages are still at over 1MB.
In any case, there are very clear accessibility issues involved, so this needs addressing. Something to the tune of a change to WP:TPG saying If an editor experiences accessibility issues with the editor's user talk page because it is too large to navigate comfortably, they may archive it themselves after notifying the editor of the changes and explaining their character. When doing that, they should use reasonable sorting criteria (e.g. sort by year, or by a smaller period if size concerns justify it), and use sorting criteria that would allow comfortable browsing of archives (e.g. 100 kB per page).
This is not an RfC, just airing my grievances for now. Szmenderowiecki (talk) 18:23, 11 September 2024 (UTC)[reply]
I have, on rare occassions, seen excessively long user talk pages forcibly archived. People are generally given wide latitude on how to manage their own user space, but that doesn't extend to breaking the ability of the project to function. RoySmith(talk) 19:10, 11 September 2024 (UTC)[reply]
Sorry, as the owner of this I didn't make the large page size deliberately. Maybe archive bots should have built-in overrides to not create such large pages? Stuartyeates (talk) 00:30, 12 September 2024 (UTC)[reply]
I wholeheartedly endorse some system of page size limitation and forced archiving in egregious cases. I have done this myself in the past. I would also note that in some instances editors have long abandoned the project while their talk pages continue to grow through various automated messages and through notices about their long-ago article creations being proposed or nominated for deletion. BD2412 T 19:14, 11 September 2024 (UTC)[reply]
Yeah, I tried to avoid listing these pages, as inactive editors are of little concern to me or to Wikipedia in most situations where you'd actually want to use the talk, but subscriptions do clutter a lot of user talk pages in at the top of the list by user length. Szmenderowiecki (talk) 23:48, 11 September 2024 (UTC)[reply]
I fully endorse a size limit on user talk pages, after which they are forcibly archived. This is a basic accessibility issue, and in my experience the editors with pages that are too long have usually been asked to trim them and haven't done so. Vanamonde93 (talk) 19:23, 11 September 2024 (UTC)[reply]
Good idea! But how would it work? Do the old posts get deleted? Will it Block you from puttibg in a New post? I think The smartest things to do would be that A: The old posts get archived OR B: The talk page gets split into two after a certain amount of posts. There would be a button at the top saying: "Older topics" or something like that. 87.95.81.141 (talk) 19:28, 11 September 2024 (UTC)[reply]
(by archived I mean put onto another page where they can be seen but not replied to) 87.95.81.141 (talk) 19:29, 11 September 2024 (UTC)[reply]
At the end of the day, if someone can't use a user talk page to talk to the user, it's fundamentally at odds with the principles of Wikipedia. I would support some restriction on page length. ~~ AirshipJungleman29 (talk) 19:30, 11 September 2024 (UTC)[reply]
Did you try just asking the editor to implement an archive bot? SamuelRiv (talk) 20:25, 11 September 2024 (UTC)[reply]
If the OP can't access their talk page how can they leave a note? Iggy pop goes the weasel (talk) 20:32, 11 September 2024 (UTC)[reply]
To clarify, per TPG we can edit a User's Talk page already in certain cases, and if the user is inactive and not responding to an email and message request and this is an accessibility issue, then that seems like a perfect reason to just go ahead and fix it. We don't need a new policy that says we can do a policy.
For existing archives, when it's not just newsletter subscriptions that can all be pruned or replaced into a separate archive, I'm not sure what the best solution is (maybe preserving section anchors and then redirecting the content into Archive 16.1, Archive 16.2, etc.?). SamuelRiv (talk) 21:08, 11 September 2024 (UTC)[reply]
I support this proposal to enforce talk page size limitations. Maybe the best way would be to have a bot post a talk page notice once it reaches 150k or so, and then a month later, if it is still at or over 150k the bot automatically applies the archive coding and {{archives}} box to the talk page. Iggy pop goes the weasel (talk) 20:31, 11 September 2024 (UTC)[reply]
That could work indeed Szmenderowiecki (talk) 00:25, 15 September 2024 (UTC)[reply]
A few comments:
Just for clarity, many of these pages are not user talk pages, they are user talk page archives.
I realize this isn't AN/ANI, but it still would have been classy to tell people you're posting about them, by name, here.
I'm not necessarily against some kind of page size limit, nor necessarily for it. I'd need someone to convince me that it affects more than, say a couple of people. At some point, it is your responsibility to upgrade your equipment. Where that point is, is a reasonable thing to discuss. We can't all be expected to limit our choices so a 15-year-old computer still works, though.
Editing on the mobile site is not fit for purpose. I'd be against anyone insisting that talk pages be accessible to people using old (or new) phones with the sucky mobile interface.
I am against the original proposal that anyone with an ancient computer gets to decide the size of other peoples' talk pages and/or talk page archives. There would need to be some agreed-upon size limit, and if one's computer is so bad that this limit is still too big, it's time for a new computer. --Floquenbeam (talk) 21:30, 11 September 2024 (UTC)[reply]
I use the desktop site on a reasonably modern mobile phone for a large portion of my editing, and enormous talk pages can cause issues. It's also a problem with large talk page sections. So it's not just the mobile interface that has issues. We should also keep in mind that a large and growing number of editors use a mobile device as their primary, or only, means of editing. ScottishFinnishRadish (talk) 21:40, 11 September 2024 (UTC)[reply]
WP:User talk pages are inaccessible for many reasons. Making the best of the current system, I agree that you should politely ask someone to archive (let them decide how first). Conversely, I find it disruptive when users archive their talk page with each and every single edit, making it difficult to peruse through older conversations without going through their entire page history. Reading and replying to longer convos on talk pages while on mobile is next to impossible even in relatively short conversations. ~ 🦝 Shushugah (he/him • talk) 21:47, 11 September 2024 (UTC)[reply]
It's also a problem with large talk page sections: I could definitely get behind a size limit for individual AN/ANI/AE/ArbCom/VP threads! If it isn't solved after X kB of text (X is TBD), then zot, into the archive it goes. Floquenbeam (talk) 21:58, 11 September 2024 (UTC)[reply]
I have generally found that if a discussion is difficult to edit on my phone that my input probably isn't needed. ScottishFinnishRadish (talk) 22:03, 11 September 2024 (UTC)[reply]
We have been trying this year to keep the Village pump pages at a reasonable size. This one is large because of the Wikipedia:Village pump (policy)#Can we discourage indiscriminate automatic addition of Wayback archive links on all external links? discussion (which might need to be split to its own page), but all the others are at a reasonable size right now.
Wikipedia:Administrators' noticeboard/Incidents is a chronic offender, despite aggressive archiving, and I've wondered whether we could split it into a rotating list by day of the week (all getting archived to the same place – that part would be easy). This would make it easier for people to find manageable ways to help out ("I'll can keep an eye on WP:ANI/Monday if you'll take care of WP:ANI/Tuesday, but I refuse to watch every single dispute all year long") and keep each individual page relatively short. WhatamIdoing (talk) 22:30, 11 September 2024 (UTC)[reply]
It's amusing that a discussion whose basic premise is "Adding all that stuff bloats the page" is responsible for bloating this page. RoySmith(talk) 22:33, 11 September 2024 (UTC)[reply]
Have you got something against EEng? You haven't even mentioned his talk page. He'll be disappointed. Martinevans123 (talk) 21:48, 11 September 2024 (UTC)[reply]
EEng is on board a spacecraft in low earth orbit, where he reads his talk page with a pair of binoculars. Cullen328 (talk) 22:20, 11 September 2024 (UTC)[reply]
I'm not opposed to a size limit on talk pages, but I agree with Floq here (sorry, Floq, I tried my best not to, but your post just made too much sense). I don't mean any disrespect here, but a 7-year-old phone is a really old phone, and I personally don't care whether people with obsolete hardware have a hard time accessing this website. It's the internet, backwards compatibility can only go so far (like 3 years). Beyond that, backwards compatibility is just not a priority in my view.
I remember having a similar discussion not long ago about "page weight" (the total size of everything that's downloaded on a webpage, images and text). It was in the context of thumbnail images. The average page weight now is 2MB IIRC. A rationale rule would be that no page on Wikipedia should have a page weight that is, say, larger than the average page weight on the internet (or 75% of that figure, or whatever).
But if your phone or PC is having a problem loading a 1MB page, you're using very obsolete hardware and probably have trouble surfing the rest of the web, too.
In general, Wikipedia should keep up with the times. Sure, let's not have greater-than-average page weight. But let's not worry about 2017 phones. Levivich (talk) 22:32, 11 September 2024 (UTC)[reply]
I think we actually should worry about 2017 hardware. Most people in the world can't afford to replace their devices every few years.
Also, page weight isn't the same as what the history page says. User talk:Stuartyeates/Archive 19 has a wikitext size of 2,096,064 bytes, but a page weight of 6.3 MB. If someone's having trouble loading that, it's because the page is actually larger than average. WhatamIdoing (talk) 22:57, 11 September 2024 (UTC)[reply]
I am posting this from my MacBook Pro (15-inch, 2017). Up until early this year, it was my daily driver. I still use it extensively when not at my desk. I agree we can't burden ourselves with supporting ancient hardware forever, but three years is way too soon and even seven years is rather aggressive. RoySmith(talk) 23:32, 11 September 2024 (UTC)[reply]
That's a MacBook Pro! That's one of the most expensive laptops on the market! Of course it'll last longer. Average PC lifespan is 3-4 years. Yes, Macs can last much longer, I've had MacBooks go 10 years before. But that's not typical. 84% of computer users do not use a Mac (16% market share). Levivich (talk) 23:37, 11 September 2024 (UTC)[reply]
Sorry, but if you are saying that to edit Wikipedia you need ultra-modern hardware then no, I don't agree with the premise.
Also, tell all the government agencies/school districts etc. to have their PCs go to waste every 3-4 years - I'd like to see taxpayers' reaction on that. It's fine if you want to upgrade it so often but we aren't speaking of playing AAA games or doing Photoshop or video rendering, it's just editing the text with a couple of images in a CSS envelope.
I'm not saying Wikipedia should be able to run on Nokia 3310 but I'm damn sure a lot of folks outside the western world just want a phone and not necessarily iPhone 16, and they will buy the cheapest Chinese stuff sold on the market, which will do the basic work of calling, texting and browsing/scrolling through memes/watching YT/listening to music/make some pictures. And even in my case I don't really see a point in high-end phones when budget options are just fine (my phone is a mid-range tier, and still works perfectly well after so much abuse I've inflicted on it).
Edit: actually, sorry, I was wrong: the phone I have was first produced in 2019, not 2017; my brother's is from 2017. So by no means "ancient hardware". Szmenderowiecki (talk) 00:07, 12 September 2024 (UTC)[reply]
Agree with this. I just checked to see my phone's age and it's pretty much seven years. I am looking into getting a new one, but I haven't treated the current one overly well. Seven years seems an aggressive cutoff for no backwards compatibility. CMD (talk) 05:38, 12 September 2024 (UTC)[reply]
To add to the anecdata, I am writing this reply from my seven-year-old phone which I sometimes use for simple editing. – Teratix ₵ 05:46, 12 September 2024 (UTC)[reply]
Anecdata isn't data.
Globally, the replacement cycle of smartphones was about 21 months in 2016, with apparently longer cycles in developed markets (Counterpoint Research, 2016; Kantar World Panel, 2017). Interestingly, the average replacement cycle is close to the smartphone service contract length typically signed by consumers in Germany (Prakash et al., 2020), as well as in other countries. As a comparison, it is calculated that the median lifespan of a (pre-smartphone era) mobile phone decreased from 4.8 to 4.6 years between 2000 and 2005 (Bakker et al., 2014). — journal article
More:
In 2016, American smartphone owners used their phones for 22.7 months on average before upgrading. By 2018, that number had increased to 24.7 ... The life cycle of a smartphone in China was relatively shorter at 20.2 months in 2016 and 21 months for both 2017 and 2018. CNBC
As a result, the average amount of time that people own a car before replacing it, about eight years, dwarfs the length of time before a phone upgrade, about three and a half years. NYT
Today, the average lifespan of smartphones is around 2.5 years. USAToday
Why the average lifespan of a smartphone is only three years El Pais
Levivich (talk) 20:14, 12 September 2024 (UTC)[reply]
I wonder how often changes are necessary (e.g., physically broken) vs voluntary/consumer choices (e.g., "but I want the new iPhone!"). WhatamIdoing (talk) 20:27, 12 September 2024 (UTC)[reply]
That first paper goes into some detail about those issues. It also distinguishes between "functional lifetime" (user preference) and "technical lifetime" (how long the phone will physically function). Levivich (talk) 20:33, 12 September 2024 (UTC)[reply]
@WhatamIdoing For my last three phones, I replaced two when they physically broke (one after about 4 years, one after about 8 years) the other I replaced after the 2½ year contract partly because it had a few annoying minor issues and partly because there was an excellent upgrade offer available. Thryduulf (talk) 20:47, 12 September 2024 (UTC)[reply]
I don't know why we're arguing about this in the first place. People have complained about the problem. Let's fix it—which costs us nothing—instead of arguing that "it doesn't affect me" or deciding whether the opinions of the people who want it fixed are worthwhile. Thebiguglyalien (talk) 20:51, 12 September 2024 (UTC)[reply]
Averages aren't very helpful here – we care quite a bit about how large the cohort of older-than-average smartphones is. So, yes, anecdata isn't data, but that doesn't mean the first statistic you pull out of a journal is automatically going to be more useful. – Teratix ₵ 15:20, 15 September 2024 (UTC)[reply]
Wikipedia users appear not to be from the same distribution as the average user in developed markets, considering some 32% (or 50% of mobile users) are using Android 10 according to WMF user agent data, which (the Android version I mean, not the data) was released in 2019. Alpha3031 (t • c) 16:39, 24 September 2024 (UTC)[reply]
Can we back up here? If page length alone in terms of wikitext is enough to break even a 20-year-old machine, then something is really wrong. The performance should not in principle scale disproportionately -- a Talk page is primarily, at scale, plaintext, with comparatively few templates. If the dynamic UX elements of Talk pages are scaling with, then that's a software problem to report to phabricator. (Also, on Talk page archives, already nicely templated, the dynamic UX should be disabled.)
You might have to manually disable the fancy discussion bells and whistles in your settings in the meantime, but for WMF default interface, 2017 hardware should be able to handle pages of this size, and if it can't that's a bug. SamuelRiv (talk) 05:10, 12 September 2024 (UTC)[reply]
First, when the problem is reading, then the "page length alone in terms of wikitext" is not a good predictor of the size of the HTML that's being delivered to you. A mere 51 characters of wikitext can put 1.6MB in your browser, if the 51 characters happen to be {{Wikipedia:Administrators' noticeboard/Incidents}}.
Second, even if the page weight is light (e.g., limited formatting, no photos), if a page has zillions of words on it, it's going to be difficult to find the part that you want to read. WhatamIdoing (talk) 05:43, 12 September 2024 (UTC)[reply]
I would support a maximum page length and also a ban on any formatting that breaks skin functionality and/or the reply tool. Garuda3 (talk) 22:58, 11 September 2024 (UTC)[reply]
Yes, it shouldn't be controversial to make pages more accessible at practically no cost. Just archive the page. It's super easy. If someone is inactive, then we can set up auto-archiving on their behalf. If someone is active but doesn't know this is an issue, then they can be notified (presumably by one of the people touting their performance above) or it can be done for them. If someone is active, knows this is an issue, and refuses to fix it after being asked, then they need to demonstrate that they can participate in a collaborative environment before anything else, because choosing to die on this hill fails to meet the very low bar of rational behavior we expect from each other. Thebiguglyalien (talk) 06:29, 12 September 2024 (UTC)[reply]
Maybe it's a script, but at the top of user talk pages I see "Latest comment:" with the time and date, easy to click on that and get to the bottom or close to it. Or just click the new topic button. Doug Weller talk 14:42, 12 September 2024 (UTC)[reply]
It is some sort of script, I just tried to go as a guest on a different browser on your talk page and the latest comment line doesn't appear - but I do have it when logged in. The PC version also has the "Add topic" button, but the issue is more with mobile than PC. On mobile you have the blue "Add topic" button, but because these pages load so slowly it is basically unclickable and can crash your browser in extreme loads (that is, if the browser doesn't crash before that because it thinks you are asking too much of it). Szmenderowiecki (talk) 15:23, 12 September 2024 (UTC)[reply]
Not a script if it shows logged in. Doug Weller talk 15:59, 12 September 2024 (UTC)[reply]
Floquenbeam, the old phone is a bit of a red herring; I'm currently on a state-of-the-art laptop and an ethernet connection, and there are user talk pages that have a noticeable load time. Vanamonde93 (talk) 15:50, 12 September 2024 (UTC)[reply]
It's not just going to be device age. It's also going to be internet connectivity/ bandwidth for a laptop and wifi 3G/4G/5G coverage for a phone? These are likely to be variable. Especially if people edit while moving around. Martinevans123 (talk) 17:02, 12 September 2024 (UTC)[reply]
That's even more of an issue where data isn't cheap. ScottishFinnishRadish (talk) 17:26, 12 September 2024 (UTC)[reply]
That's a very valid point. Martinevans123 (talk) 20:50, 12 September 2024 (UTC)[reply]
I just don't think "no noticeable load time" is a reasonable criterion. I have my own personal experience too; my 2450 page watchlist (that's not gigantic compared to others) takes about 6 seconds to load, and a certain editor (who is famous for a large talk page) has a talk page that currently takes me about 4 seconds to load. I realize watchlist sizes vary, and this probably depends on a dozen things I don't understand, scripts I have loaded, etc. But I don't think I have a right to insist that an editor ensure that their talk page loads quicker than my watchlist. What we really need - if this is currently an actual problem for a significnat number of editors - is some kind of methodology respectful to both extremes, and some kind of rational criteria, so that (a) the number of editors who have a hard time loading a page (esp. a talk page) using desktop mode is "reasonably" small, and (b) the number of editors forced to change the way they manage their talk page is "reasonably" small as well. If anyone can claim they can't load someone's talk page with no way of proving it, and force a change, then people will immediately weaponize that rule and try to piss off their perceived enemies. Floquenbeam (talk) 17:36, 12 September 2024 (UTC)[reply]
some kind of methodology, it's called "page weight". The median today for desktop is 2.7MB, for mobile it's 2.4MB [19]. You can test a page's page weight with tools like this one: [20]. I checked the ones mentioned here:
Some are larger than average, others are smaller than average. Levivich (talk) 20:20, 12 September 2024 (UTC)[reply]
Bish's archive 19 does take a hot minute for my work PC to load... and it's less than a year old.. but at the same time, how often are people looking back at archives? is a slower load a huge issue? -- Aunva6talk - contribs 19:17, 13 September 2024 (UTC)[reply]
The original link is for non-user talk pages, not Wikipedia:User pages. " User pages are for communication and collaboration. While considerable leeway is allowed in personalizing and managing your user pages, they are community project pages, not a personal website, blog, social networking medium, or a Wikipedia article. They should be used to better participate in the community, and not used to excess for unrelated purposes nor to bring the project into disrepute."Doug Weller talk 16:02, 12 September 2024 (UTC)[reply]
This is a technology problem and the WMF is responsible for providing the core technology. The core issue is that Wiki software is not a good tool for creating and managing a mailbox facility. And the widespread use of scripts and templates makes the problem worse by encouraging people to spam bloated messages with a single click.
My real email inbox is much better. With that, I can file or delete or tag messages easily. I can set up filters to route them automatically. There's a spam filter and sensible defaults which segregate the different types of messages – social media, promotional, newsletters – so that the primary inbox is comparatively uncluttered.
But, checking latest developments at mw:Talk pages project, I'm not seeing a lot of activity there. I'll try a little innovating in my own case....
Andrew🐉(talk) 18:01, 13 September 2024 (UTC)[reply]
That team is working on mw:Edit check now. I would not expect any significant new features to be added during the next year. Additionally, one of the community-imposed restraints on it was that it be compatible with wikitext, which means that filtering and tagging are not realistic. WhatamIdoing (talk) 18:44, 13 September 2024 (UTC)[reply]
Anybody who wishes can archive my talk page. I tried to do it once and I couldn't figure out how. The instructions were impenetrable for my technology level of pen and paper 1.0. Smallchief (talk) 19:49, 13 September 2024 (UTC)[reply]
Hi, I'll set up the archiver bot for you and add a talk header with link to your archives! It's pretty easy and will do the heavy lifting for you. Iggy pop goes the weasel (talk) 20:36, 13 September 2024 (UTC)[reply]
I think we would do well to have a bot which sets up talk page archiving for all new accounts. Maybe only after they pass some minimal activity bar like autoconfirmed. Pick a reasonable configuration and it'll be fine for 99.99% of users. RoySmith(talk) 22:42, 13 September 2024 (UTC)[reply]
A one-time pass on User_talk: pages above a certain size+staleness (say, >50kb and only affecting comments >90 days old) would probably also be fine for 99.99% of users.
A one-time pass has the advantage of not generating ongoing support requests ("It archives my page every day! How do I turn this thing off?!" as well as "I don't read the village pumps, participate in RFCs, or watch CENT, and I hate this, which is proof that you don't have consensus for this!"). WhatamIdoing (talk) 00:51, 14 September 2024 (UTC)[reply]
Rather than having a bot, can't you build that into the standard Welcome messages? I realize that wouldn't hit 100% of the new accounts, but likely a large percentage. -- Nat Gertler (talk) 14:40, 14 September 2024 (UTC)[reply]
I suspect it would be closer to nobody. People don't read instructions, and people certainly don't take the time to implement things that they have no immediate need for. RoySmith(talk) 14:49, 14 September 2024 (UTC)[reply]
I agree with Roy. Also, adding more things to a message makes everything in the message less effective. WhatamIdoing (talk) 16:15, 14 September 2024 (UTC)[reply]
Then, IDK, set up an archiver for new accounts by default? Szmenderowiecki (talk) 00:24, 15 September 2024 (UTC)[reply]
I think that'd be a waste of effort and edits. Even if you wait until after the person actually makes an edit (thereby ignoring 70% of new accounts), almost none of the people who make an edit actually need things archived. 99% of (successful) editors never make 500 edits. The odds of someone making less than 500 edits and needing an archiving system is very low. A few of them might need to be unsubscribed from various newsletters, or to have non-discussion test edits moved to a sandbox, but I wouldn't expect routine archiving to be useful for brand-new or low-volume accounts. I could imagine a bot that says "Congrats on your 1000th edit – I see you have a kind of long talk page, so I've installed a talk-page archiving system for you", but not for new accounts. WhatamIdoing (talk) 00:49, 15 September 2024 (UTC)[reply]
I'm not saying instruct them to set up archiving. I'm saying that the Welcome message is generally the first message on the talk page, and if we included the actual archiving code in the template, then it would be set up by default. -- Nat Gertler (talk) 00:53, 15 September 2024 (UTC)[reply]
New users are the ones least likely to be making excessively long talk pages, so it seems to me that this aims at the wrong cohort. Zerotalk 02:53, 15 September 2024 (UTC)[reply]
The last time I remember this being discussed (where was it?) it transpired that people who had the most trouble reading longish user talk pages were using some particular gadget. Sorry, I don't remember the details. My opinion then, as now, is that average users should not be forced to manage their user pages to compensate for the choice of a few users to make trouble for themselves. Of course there has to be some limit, but limits that are smaller than thousands of articles don't make sense to me. If someone can read a 300KB article just fine but they can't read a 300KB talk page, it isn't the talk page's owner who's at fault. Zerotalk 02:53, 15 September 2024 (UTC)[reply]
It's possible that the "particular gadget" was "a smartphone". WhatamIdoing (talk) 03:28, 15 September 2024 (UTC)[reply]
You know the answer. But are you saying that a smartphone can read long articles, but not talk pages of the same length? Zerotalk 03:56, 15 September 2024 (UTC)[reply]
No. We get complaints about long articles on smartphones, too. WhatamIdoing (talk) 04:04, 15 September 2024 (UTC)[reply]
Recently? Do you know of any examples?
Regardless, it makes sense to have a policy about page weight and load times (from multiple continents), which should be calibrated against the current internet average, and updated every few years, and applied to every page on the website, regardless of namespace. And the benchmark should be logged out users, not logged in (since by far most readers are logged out, and it'll avoid the gadget/script issue). Levivich (talk) 04:23, 15 September 2024 (UTC)[reply]
My iPhone with 4GB RAM loaded our longest article in about 3 seconds logged out. Zerotalk 04:44, 15 September 2024 (UTC)[reply]
It occurs to me it's not just page loading time, but also edit publishing time, that matters. We ought to have benchmarks for that, too, also logged out for the same reasons as above. Maybe we could run an RFC asking people to log out and edit EEng's talk page and report back how long it took for the edit to publish? After it runs the usual 30 days, we should have a good sample size. Levivich (talk) 05:18, 15 September 2024 (UTC)[reply]
That doesn't seem kind to EEng, who would get a lot of notifications from test edits.
I understand that there are professional services that measure website performance in a variety of different contexts. If we really need this to be done, we could do it properly. However, I don't think we need this to be done. I think we need to agree on a rule that allows generously large talk pages and requires action in response to certain types of complaints.
For example, we could adapt the principle in WP:RFD#KEEP that "Hint: If someone says they find a redirect useful, they probably do" to say "If someone says they find your talk page too large, they probably do", so you should archive it, but reject complaints below a certain size (User:MiszaBot/config gives | maxarchivesize = 150K as an example, and I suggest adopting that) and never require archiving content that is less than (e.g.,) six months or a year old. WhatamIdoing (talk) 16:22, 15 September 2024 (UTC)[reply]
The gadget referred to by Zero0000 was Wikipedia:Convenient Discussions, which is a javascript tool. Tools like this are a bad idea because they are not supported by the WMF. They tend to get broken by technical change and/or become orphaned and unsupported when the enthusiast that wrote them burns out. Andrew🐉(talk) 14:06, 16 September 2024 (UTC)[reply]
Isn't this something that is better addressed on the application side rather than the source side? It's obviously very common for the volume of data returned by some kind of request/query etc. to exceed some preferred limit and this is usually handled by returning the data in chunks/using pagination etc. Sean.hoyland (talk) 04:39, 15 September 2024 (UTC)[reply]
I think we want a "both/and" approach instead of an "either/or" approach.
Also, it's not just loading time. It's scrolling time, searching time, and editing time. Long pages are less manageable even after the page is on screen. WhatamIdoing (talk) 16:14, 15 September 2024 (UTC)[reply]
But the number of times someone wants to scroll through a long talk page or open the whole thing to edit is negligible. The relevant actions are reading the bottom of the page, opening the last section and starting a new section. The last two at least should not depend on the page length, and if they do there is a technical fault. Zerotalk 02:35, 16 September 2024 (UTC)[reply]
How do you read and edit the last section (or at least one of the sections at the bottom of the page; this section is the penultimate one at the moment) on a long page, without scrolling down to it? WhatamIdoing (talk) 03:24, 16 September 2024 (UTC)[reply]
The mobile site doesn't have a table of contents. WhatamIdoing (talk) 21:36, 16 September 2024 (UTC)[reply]
Touché. jlwoodwa (talk) 21:57, 16 September 2024 (UTC)[reply]
That depends on how busy the talk page is. Mine is very quiet so sure, most of the time, only the last section is active (if any). Talk pages with more interaction can have several active threads at once. isaacl (talk) 05:55, 16 September 2024 (UTC)[reply]
I get to the bottom like I got to this section, by clicking on the index. Anyway a simple solution would be for Talk pages to open by default at the bottom rather than the top. I'm sure the techs could do that and it could be an option. It would save a lot of time even on talk pages of moderate length. There could be a template that stops that behavior on noticeboard pages like this one, RSN, etc. Zerotalk 06:16, 16 September 2024 (UTC)[reply]
On a Windows machine you can just hit the End key. Sean.hoyland (talk) 06:41, 16 September 2024 (UTC)[reply]
The way HTML works, browsers have to render the whole page before they can scroll to the bottom. Thus for a solution like going to the bottom of the page to actually save rendering time, the page would have dynamically load via Javascript. Some users dislike this, as it causes the content to change its layout as new portions of the page are loaded. isaacl (talk) 06:43, 16 September 2024 (UTC)[reply]
I go to any user talk or other talk page on this website, there's a "+" button at the top to add a new section. No scrolling to the bottom is required. I think this is part of the discussion tools that were rolled out a few years ago. Levivich (talk) 16:35, 16 September 2024 (UTC)[reply]
That button doesn't exist on the mobile site, and even on the desktop site (=my own personal preference), it doesn't help you read existing comments. WhatamIdoing (talk) 21:38, 16 September 2024 (UTC)[reply]
Seriously? Don't we have bigger fish to fry than wasting valuable time worrying about an editor's UTP? Atsme 💬 📧 14:33, 23 September 2024 (UTC)[reply]
Well... maybe not? If a page is extremely large or awkward, it may impede communication between editors, which can lead to preventable drama.
Also, sometimes little problems really do need to be addressed. Individually, they may just be little "paper cuts", but paper cuts are irritating, and cumulative irritation drives people away. WhatamIdoing (talk) 16:08, 23 September 2024 (UTC)[reply]
For people who have problems accessing those pages this is an important issue. Iggy pop goes the weasel (talk) 20:57, 23 September 2024 (UTC)[reply]
This could have been solved in 15 minutes, but it wouldn't be a Wikipedia noticeboard without a 5,000 word discussion to decide whether solving problems is a good thing. Thebiguglyalien (talk) 21:27, 23 September 2024 (UTC)[reply]
I think this discussion is above 6,000 now... WhatamIdoing (talk) 22:19, 23 September 2024 (UTC)[reply]
Here's a solution for whoever is complaining about a UTP being too long: teach them how to click on the + tab in the top margin. No scrolling required. Problem resolved. (somebody already mentioned this resolution a earlier.) Atsme 💬 📧 00:31, 24 September 2024 (UTC)[reply]
That has been addressed above. There are load time issues, loading issues, and bandwidth/data use, among others. ScottishFinnishRadish (talk) 00:45, 24 September 2024 (UTC)[reply]
The catch-22 of non-binary categories
I can't put Keith Maillard in Category:Canadian poets because it's a diffusing category and someone will inevitably move them to Category:Canadian male poets based on Maillard's name and appearance. But I can't create Category:Canadian non-binary poets because it would be too small and get immediately deleted. I've been through this catch-22 many times (and tried both approaches). Is there any good solution? Nosferattus (talk) 19:54, 18 September 2024 (UTC)[reply]
That parent category specifically says that members should be moved to subcategories where applicable so if someone is making a bad edit (i.e. where it is not applicable), revert the edit with the reason. — xaosfluxTalk 20:37, 18 September 2024 (UTC)[reply]
@Xaosflux: I tried putting Keith Maillard in the top level of the diffusing categories and it took less than 1 day for it to be incorrectly "cleaned up" into the male category. The user who made the incorrect edit (and graciously admitted their mistake) wasn't a newbie, but an extended confirmed user with over 600,000 edits. This isn't just a one-off problem that can be solved by watchlisting a few pages, IMO. We now have approximately 1,000 articles about non-binary people (according to Wikidata) and keeping them correctly categorized has always been difficult. I really hope there is a better solution. Nosferattus (talk) 03:29, 24 September 2024 (UTC)[reply]
There is a related issue with nb subcategories being opposed at CfD as "trivial intersections" (even where the numbers clearly warrant a category) in a way that male/women subcategories are not. I think the answer is that if we are going to diffuse by gender, the nb category should be created and kept regardless of size. Having male and women subcategories with nb subjects thrown in the parent category makes it very counterintuitive for readers to find those articles, in addition to the persistent "cleanup" attempts you highlight above.--Trystan (talk) 20:40, 18 September 2024 (UTC)[reply]
Good point, Trystan. Lewisguile (talk) 07:57, 19 September 2024 (UTC)[reply]
Nicely put, @Trystan; thank you — OwenBlacker (he/him; Talk) 11:23, 19 September 2024 (UTC)[reply]
Why on earth are poets diffused by gender? DuncanHill (talk) 11:38, 19 September 2024 (UTC)[reply]
I think that is a good point! In modern society should we not forget gender and race when creating categories? Davidstewartharvey (talk) 12:09, 19 September 2024 (UTC)[reply]
I agree that diffusing poets by gender doesn't make a lot of sense. Actually, Category:Canadian male poets even says that it's a non-diffusing subcategory. But there doesn't seem to be another scheme for Category:Canadian male poets to be diffused by. CapitalSasha ~ talk 12:18, 19 September 2024 (UTC)[reply]
Probably because some wanted to increase the visibility of female poets by separating them from the male poets. Then whether we create "male" (and now "non-binary") categories too or not depends on whether someone decides that full diffusion is necessary or that having only a "female" category could be interpreted as implying that female poets somehow aren't "real" poets. Anomie⚔ 12:24, 19 September 2024 (UTC)[reply]
That is certainly my understanding of how gender-diffused categories came to exist. — OwenBlacker (he/him; Talk) 15:18, 19 September 2024 (UTC)[reply]
Makes sense to me. Lewisguile (talk) 11:34, 20 September 2024 (UTC)[reply]
agreed - this is a reasonable supposition User:Ceyockey (talk to me) 03:47, 22 September 2024 (UTC)[reply]
Dynamic categories (category intersection) would be very helpful in solving this issue. Gonnym (talk) 12:42, 19 September 2024 (UTC)[reply]
Yes. Our current depth-categorization paradigm is guaranteed to create a classic resource problem (regardless of whether you want to call it intersectionality in race and gender, the same concept applies to any intersecting categories -- it's fundamentally formally a problem of sets, sorting, and query/allocation).
In the meantime, indeterminate categorization of gender (not nonbinary) is always going to be necessary regardless, what with all the edit wars over historical and ambiguous figures. Shrugemoji on the topic I guess. SamuelRiv (talk) 19:46, 19 September 2024 (UTC)[reply]
Query - where does this leave us? What endpoint is being considered for consensus? User:Ceyockey (talk to me) 03:49, 22 September 2024 (UTC)[reply]
@Nosferattus_ Hi there! @Chaotic Enby reverted my recent edit to change from Category:Canadian novelists to Category:Canadian male novelists to the article and directed me here. Since Maillard is non-binary (a statement in the article that I hadn't read at the time I made the edit), it's fine with me to not add the article to any "male" categories.
That is a good question. In many of these cases, people are typically diffused into multiple subcategories under a diffusion category based on different schemes: gender, country of origin, time period, etc. If a person is already diffused into 1 of those schemes, and they don't fit into another scheme's subcategories, should they just be omitted? A literal reading of WP:PARENTCAT would suggest that, but this also seems problematic as it means non-binary people will be put into half as many categories as everyone else and thus be harder to find. Nosferattus (talk) 03:41, 24 September 2024 (UTC)[reply]
Is Category:West Virginia University appropriate? The only connection the article mentions is that one of his books was printed by the West Virginia University Press. Seems like there are stronger connections to University of British Columbia and Simon Fraser University in the article. GoingBatty (talk) 04:05, 24 September 2024 (UTC)[reply]
You're right, I meant half as many diffusing categories. He went to college at West Virginia University[22] although it isn't mentioned in the article. I actually don't know if he published any poetry in the 21st century or not. However he was a poet and he was alive during the 21st century. Does that make him a 21st century poet? Nosferattus (talk) 04:23, 24 September 2024 (UTC)[reply]
@Nosferattus Although he's not in male/female categories, he is included in LGBT(Q) categories. The article indicates his poetry was included in various 21st-century anthologies. I presume that being included in The Best of Canadian Poetry in English, 2008 means he wrote poetry in the 21st century, which makes me think Category:21st-century Canadian poets would be appropriate. GoingBatty (talk) 05:31, 24 September 2024 (UTC)[reply]
Perhaps a hidden note next to the category entry would help? Jo-Jo Eumerus (talk) 07:03, 24 September 2024 (UTC)[reply]
@Nosferattus: I have updated the categories. GoingBatty (talk) 16:15, 24 September 2024 (UTC)[reply]
@Jo-Jo Eumerus: Good idea - I added a comment in the Categories section. GoingBatty (talk) 16:14, 24 September 2024 (UTC)[reply]
Administrator Recall
Is there consensus to have administrator recall based on the consensus reached during Wikipedia:Requests for adminship/2024 review? 03:11, 22 September 2024 (UTC) The consensus reached there established recall with the following process:
Petition
Cannot be launched until 12 months have passed since the user has successfully requested adminship or bureaucratship, re-requested adminship, or become an arbitrator.
25 editors must support the petition to trigger the re-request for adminship process.
The format allows for discussion and reasoning to be explained.
To support a petition, you must meet the criteria to participate in a request for adminship. You must not support more than 5 open petitions. There is no limitation on how often someone can initiate a petition.
If a petition for a given admin fails to gain the required support, another petition for that admin cannot be launched for six months.
Support statements can be stricken based on the same criteria as for requests for adminship.
Re-request process
A bureaucrat will start a re-request for adminship by default. The admin can request a delay of up to 30 days. If the re-request does not start by then, the admin can have their privileges removed at the discretion of the bureaucrats.
The re-request can also take the form of participating in an admin election. (Not clear what the consensus is regarding the need for the election to fall within the 30-day window).
For either a re-request or an election, the following thresholds apply:
below 50%: fail
50–60%: Bureaucrats evaluate consensus
60% and above: pass
Background
During phase 1 of WP:RFA2024Joe Roe closed two proposals for recall with the following close (in part with emphasis in the original):
Considering § Proposal 16: Allow the community to initiate recall RfAs, § Proposal 16c: Community recall process based on dewiki, § Proposal 16d: Community recall process initiated by consensus (withdrawn), in parallel, there is a rough consensus that the community should be able to compel an administrator to make a re-request for adminship (RRFA) in order to retain their administrator rights. However, there is also a consensus that the process(es) for initiating an RRFA needs to be worked out in more detail before this is implemented. Phase II of this review should therefore consider specific proposals for RRFA initiation procedures and further consensus should be sought on which, if any, is to be adopted. The dewiki-inspired process suggested in Proposal 16c was well-supported and should be a starting point for these discussions.
When the second phase began the process was, after 3 days, structured in a way that took Proposal 16c and offered alternative options for certain criteria. This was done in good faith by Soni who had originally proposed 16c. Some editors objected to this structuring at the time and/or suggested that a 3rd RfC would be needed to confirm consensus; Joe Roe would later clarify well after the process was underway that the Phase 2 structure did not, in his opinion as closer, reflect the consensus of Phase 1. Others, including Voorts who closed most of Admin recall phase 2, suggest that there was adequate consensus to implement the process described above. Post-close discussion among editors has failed to achieve any kind of consensus (including whether there needs to be an RfC like this). As an editor uninvolved in the current discussions about Admin recall until now, it seemed to me that the clearest way to figure out if this recall process has consensus or not is to ask the community here rather than have this discussion in parallel with an attempt to recall someone. Barkeep49 (talk) 03:11, 22 September 2024 (UTC)[reply]
Survey (administrator recall)
(involved) The question here is simple: did a two-phase discussion that reached consensus in both phases also achieve an overall consensus to implement? The answer is equally simple: yes, it did. The current strongest argument against this idea seems to be that Phase II's formatting didn't give enough leeway for someone to propose a recall system distinct from the dewiki process (while still using that as a starting point). But there was an open discussion, and I don't recall seeing a different idea gain any significant amount of traction. If we really need to go through an entirely new RfC to double-confirm a proposal we've already accepted in principle and fine-tuned, fine, let's do it, but it seems like a waste of community time to me. theleekycauldron (talk • she/her) 11:10, 22 September 2024 (UTC)[reply]
The open discussion section was closed after three days though. – Joe (talk) 11:49, 24 September 2024 (UTC)[reply]
Despite this, people added additional proposals, and additional options to existing proposals, and nobody complained about the open discussion section being closed, for months thereafter. Levivich (talk) 18:24, 24 September 2024 (UTC)[reply]
(uninvolved) Yes consensus was reached. Naturally new tweaks/discussions will come along. Let's have specific RfCs on those. ~ 🦝 Shushugah (he/him • talk) 11:38, 22 September 2024 (UTC)[reply]
Yes there is a consensus (uninvolved). A legitimate objection is that the process of managing the second RfC may have stymied other possible outcomes beyond a de wiki style process, and this may have been the case. However, RfCs with perceived flaws tend to generate lots of comments pointing this out (as we can already see below) and I'm just not seeing that that in the 2nd phase RfC. The 1st phase confirmed that the community wanted a recall process, the 2nd phase asked for proposals to be developed for implementation and there was a consensus found within that discussion for a specific variant. In the interest of not letting the perfect being the enemy of the good, I believe there is sufficient support for the admin policy to be updated based in this outcome, with further adjustments being made as required (or indeed removing it entirely should a subsequent consensus determine that it should). Scribolt (talk) 15:42, 22 September 2024 (UTC)[reply]
Strangely-worded question. No, there isn't currently a consensus for this proposal; but yes, I think we should reach consensus for it at this RfC.—S Marshall T/C 16:45, 22 September 2024 (UTC)[reply]
A key challenge in trying to reach agreement by consensus is that interest tends to wane as discussion moves from higher-level concepts to more fine details. One way to address this is to get consensus for a general initiative, obtain consensus for key aspects to incorporate, then work on implementation details. For this specific situation, I think the phase 2 discussion did a sufficient job at taking the support shown during phase 1 and working out agreement on the broad-stroke steps for a recall process. As always, because it's hard to get people to pay enough attention to reconcile specific wording, part of working out the implementation means finding a working procedure that is the central object illuminated from different directions by people's statements. I feel the phase 2 results reveals enough scaffolding to proceed with implementation. isaacl (talk) 17:00, 22 September 2024 (UTC)[reply]
(involved) Yes. There is consensus per my comments in the post-close discussion, as well as per leeky and Scribolt above. Those editors raising objections to the idea of admin recall or the proposals that gained consensus, but who did not participate in the earlier RfCs, should have participated; phases I and II were both widely advertised (I remember them being posted at T:CENT, VPP, AN, AN/I, etc.). I worry that a third RfC will fatigue the community and disproportionately draw the most vocal opponents to the process, resulting in a small group of people overriding a consensus already twice-determined by the community. voorts (talk/contributions) 20:51, 22 September 2024 (UTC)[reply]
(I closed some of the proposals) I don't know why we need an RfC to say "yes, this RfC was correct", but yes. Charlotte (Queen of Hearts • talk) 22:40, 22 September 2024 (UTC)[reply]
I participated in both Phase I and Phase II. I believe the results of Phase II achieved consensus and should be implemented. I do not see how this contradicts the results of Phase I. As others have pointed out, an actual policy page is still being drafted and might have to go through yet another RfC. Having an RfC on the validity of each step seems like a waste of time. Toadspike[Talk] 07:34, 23 September 2024 (UTC)[reply]
I think your question answers itself. "Was there consensus for the consensus"? The answer is obviously yes. Now, if you want to ask a different question, open a different RFC. --130.111.220.19 (talk) 18:14, 23 September 2024 (UTC)[reply]
No, there isn't consensus for the recall process proposed at Wikipedia:Administrator recall. I'll reiterate a comment I made on the Phase II talk page: taking the mini-consensuses from that phase, then using them to cobble together a process, doesn't translate into a solid policy with broad community consensus. The fact that various aspects of the proposal, even now, are up in the air disproves the notion that "the consensus already exists". Those who are advocating for Wikipedia:Administrator recall need to finalise that page, then present it for a simple yes/no RfC, so that the consensus (or lack thereof) on the policy as a whole is beyond question. SuperMarioMan (Talk) 20:55, 23 September 2024 (UTC)[reply]
No, there is no consensus for this, and I've explained why on the pages where the proposal is being developed. But I think it's unfair to ask this question now, because the editors who support the proposal are still working on it. I therefore think this RfC should be closed as premature. --Tryptofish (talk) 21:51, 23 September 2024 (UTC)[reply]
I had hoped that this RfC would be withdrawn, but it appears that it won't, so I feel the need to say why this RfC cannot establish consensus for the policy change.
First, Barkeep49 gets the facts wrong in the statement of this RfC. He says: Joe Roe would later clarify well after the process was underway that the Phase 2 structure did not, in his opinion as closer, reflect the consensus of Phase 1. In fact, he said more than that: I'm really sorry to say this, but reading it all through now, I think Wikipedia:Requests for adminship/2024 review/Phase II/Administrator recall has trainwrecked... I just cannot see how a genuine consensus can be said to come from a process like this... The only way I can see of salvaging this is to take whatever precise version of 16C got the most support and present it as a straight support/oppose RfC. [23]. Barkeep49 goes on to quote Voorts as having determined that phase 2 established consensus: Others, including Voorts who closed most of Admin recall phase 2, suggest that there was adequate consensus to implement the process described above. But in fact, Voorts drew a clear distinction between his close of individual sections, as an uninvolved closer, and his personal opinions about overall consensus, which were separate from the close: [24], [25].
And the bullet-list summary differs in some substantive ways from what appears to be the proposed policy. 25 editors must support the petition. Isn't it 25 extended confirmed editors? Who closes the petition? In fact, this is still being discussed: [26].
Since when are policy pages simply a bullet-list? Are we being asked to establish the bullet-list as a policy page, or are we being asked about Wikipedia:Administrator recall? The latter is beyond any question a work-in-progress. So if it needs to be changed as the editing process there continues, are we establishing consensus for the current version, or for some indeterminate version that will emerge in the future? And if the real purpose of this RfC is to establish consensus against, is that a fair process?
Phase 1 established consensus for some form of process. Phase 2 established consensus for some particular forms of the process, but did not establish whether those forms are actually to be implemented as policy, or whether those forms are the best version to be submitted as a policy proposal. This RfC muddles two different questions: whether the process so far has already established consensus, or whether the proposal summarized in bullet points should now be adopted as policy. And some editors here have been answering the first question, whereas others have been answering the second.
No one has answered the question of what is inadequate with the status quo, with ArbCom handling desysop requests.
The bullet-list proposal would be a disaster for Wikipedia if enacted here. It can't even be launched within the first year after the successful RfA? What happens if an admin does objectional things before then? More importantly, we are in a time when many members of the community are deeply concerned that we do not have enough new admins emerging from RfA, and that we are starting to see backlogs. Many members of the community regard RfA as being unattractive to well-qualified candidates, too stressful, not worth the aggravation. So if any random group of 25 users can force a recall, and just a few can start the petition process, how will that affect administrator morale? Will even more qualified RfA candidates decide against applying? Will current admins become too fearful of angering 25 disruptive editors, and hold back from dealing with contentious tasks, such as AE?
At least we should have a fully-developed proposal for the community to evaluate. Given that there are editors who are working on just that, it seems foolish to demand an up-or-down RfC now, before they have finished, on the theory that this would save them the trouble of working on something that will fail. Plenty of editors want the proposal to succeed, so they are not being imposed upon by giving them the time to finish. And the proposal here isn't ready for prime time. --Tryptofish (talk) 22:56, 25 September 2024 (UTC)[reply]
Yes (uninvolved) - There is a super clear consensus to have an administrator recall. Still work to be done om the actual policy page. But to the question of this RFC, Is there consensus to have administrator recall based on the consensus reached during the last review? Yes clearly, otherwise the right next step would be to challenge that close. This is not the place to relitigate the RFC or how the policy page is being created. PackMecEng (talk) 13:13, 24 September 2024 (UTC)[reply]
No IMO the question is unclear but I think interpreted as "was it decided that the deWiki version be adopted?". In shorthand, the main close was a general consensus that there should be a recall process, with the related verbiage in essence implicitly saying that it needed to be developed and then approved. The close on adopting the deWiki version was that there was insufficient participation (in this context) to consider it to be a decision either way. So the next step is to develop a proposal that can get wide support and get it approved. While keeping in mind that the first close says that it's already decided that "we want something like this" and so that question should not be revisited, and "There should not be any such recall process" is not a valid argument at this point. North8000 (talk) 13:54, 24 September 2024 (UTC)[reply]
That next step is what Phase II was. Levivich (talk) 18:19, 24 September 2024 (UTC)[reply]
Yes. If this discussion is "Should Wikipedia:Administrator recall be implemented?", my answer is yes. That is effectively what the list of points above effectively are. If this question is "Is there consensus already to implement Wikipedia:Administrator recall?" then my answer is also Yes. I think there was consensus via Phase II to do this. If people believe there isn't, then I strongly prefer resolving the first question right now instead of bunting this entire thing to a second RFC further down the line. I also personally would have preferred a week while editors already discussing the matter at Wikipedia talk:Administrator recall could resolve this. But the cat's out of the bag, and nobody seems to actually close this as premature. So I would prefer going through with this RFC instead of alternatives that draw this out for everyone. Soni (talk) 05:06, 25 September 2024 (UTC)[reply]
Regarding Soni's first question, my answer is unreservedly Yes. Regarding Soni's second question, my answer is a Very Weak Yes. Also, this RfC is a premature mess. Tazerdadog (talk) 18:30, 25 September 2024 (UTC)[reply]
Yes.~ ToBeFree (talk) 22:02, 25 September 2024 (UTC)[reply]
Yes. We do not need an RfC to answer the question "Did the previous discussion, with a consensus close, actually close with a consensus?" Just get it done. Details will, as usual, be refined as we go along. If the entire thing turns out, after post-implmentation experience, to be a bad idea, then it can be undone later. PS: If there is doubt whether a close of an RfC or other discussion actually reached the consensus claimed by the closer, the place to hash that out is WP:AN (unless it's subject to a more specific review process like WP:MRV for move disputes, and WP:DRV for deletion ones). — SMcCandlish ☏ ¢ 😼 13:08, 27 September 2024 (UTC)[reply]
Involved yes there is consensus, yes this should be implemented, per those above and in particular leeky. HouseBlaster (talk • he/they) 18:12, 28 September 2024 (UTC)[reply]
No. The partial trainwreck of the discussion that happened at the Phase II RfC meant that consensus for several critical aspects of the recall proposal did not gain sufficient consensus to enact such a significant change to a core policy (WP:ADMIN). And for my own part I failed to see a consensus on some matters at all, though I suppose reasonable minds can disagree on the matter. JavaHurricane 10:31, 29 September 2024 (UTC)[reply]
Yes per S Marshall. The process should continue with the understanding that there is a consensus for recall on this basis though details remain to be finalized. Eluchil404 (talk) 21:45, 29 September 2024 (UTC)[reply]
I don't think the question here is whether there is consensus for some future version, in which the details will have been finalized. It's whether there is consensus for what it says at the top of this RfC. --Tryptofish (talk) 22:50, 29 September 2024 (UTC)[reply]
Right. And my position is that there is (or at least it should be established here) consensus for the form of recall described in the 14 bullet points listed above. Some people in this discussion have queried the precise interpretation of some of the points, so another round of workshopping precise language would not be amiss, but the proposal should continue to move forward on this basis without "going back to the drawing board" because of concerns about a previous RFC. Eluchil404 (talk) 23:43, 29 September 2024 (UTC)[reply]
Yes, there is consensus to adopt an administrator recall process that includes the characteristics that achieved consensus in RFA2024 Phase II. To my eye, the proposal here successfully reflects that consensus. ModernDayTrilobite (talk • contribs) 14:41, 30 September 2024 (UTC)[reply]
General discussion (Administrator Recall)
Close as the proposal is still being developed. A draft of a full proposal is being discussed at WP:Administrator recall that refines and adds clarification to the closes at WP:RFA2024. All editors are welcome to participate in the discussion. I do anticipate that this proposal will come back for community discussion. --Enos733 (talk) 03:35, 22 September 2024 (UTC)[reply]
As noted when this was raised on my talk page, the work there appears procedural. There is no agreement even there about whether or not this is already policy or not. Having editors spend time developing something in detail when the core policy doesn't have consensus is a poor use of time in my opinion. If it does have consensus the details can be worked out and will be made to happen. We have seen that happen with Admin elections coming out of the RFA2024 process. Best, Barkeep49 (talk) 03:49, 22 September 2024 (UTC)[reply]
I understand where you are coming from, but the detailed efforts identified a couple challenges with how to implement the close, and I wouldn't suggest that the policy described above is the exact proposal coming from those efforts (although it is in harmony with the closes in WP:RFA2024). While every policy could be further refined, I am of the belief that our community is best served by bringing forward a more complete proposal for community discussion. - Enos733 (talk) 04:28, 22 September 2024 (UTC)[reply]
This should be closed. For most people, whether they support admin recall depends very much on the details of the proposed mechanism. For a sensible RfC, the mechanism has to be spelled out (as above) but must not change for 30 days. That does not match reality at the moment. Johnuniq (talk) 04:48, 22 September 2024 (UTC)[reply]
@Johnuniq genuine question: what details do people need beyond which there is already RfC consensus for? Best, Barkeep49 (talk) 15:46, 22 September 2024 (UTC)[reply]
Barkeep49, I oppose the proposal, but I think you should withdraw this RfC for now. What people still need (or at least should be entitled to) is to see a full proposal, a proposed policy page, not the bullet list summary you posted here, and to see a rationale for adopting the proposal, prepared by its supporters. And editors are working on those things now. --Tryptofish (talk) 21:59, 23 September 2024 (UTC)[reply]
I long ago tuned this out as a TL;DR waste of my time. But curious, is there a consensus that the current Arbitration Committee-led "recall procedure" is not up to the task, and should be discontinued? Or, rather, is there a consensus that both procedures may be used. Can an admin be subject to both an Arbcom case *and* a "community recall procedure" at the same time? Is there a consensus for that? To be clear, I oppose the possibility of simultaneous, competing recall procedures. wbm1058 (talk) 09:53, 22 September 2024 (UTC)[reply]
@Wbm1058 Nothing in this above would prevent someone from becoming a party to an arbcom case, or from arbcom issuing any remedy. How would you like a blocking condition to work? Perhaps a prohibition on community recall rrfa launching while the admin is a party to an arbcom case? — xaosfluxTalk 10:42, 22 September 2024 (UTC)[reply]
If stripping the Arbitration Committee of the power to desysop isn't part of the package, this whole "recall procedure" strikes me as highly problematic. Imagine an Admin suffering through a month-long Arbitration Commmittee proceeding, ending with an "admonishment" to the administrator, followed hours later by the opening of a "community recall procedure". – wbm1058 (talk) 10:52, 22 September 2024 (UTC)[reply]
Bureaucrats evaluate consensus for 50-60% is invalid for the election option, that is strictly a vote - so needs a specific value. — xaosfluxTalk 10:38, 22 September 2024 (UTC)[reply]
There has been consensus for 60% threshold for Admin elections. The same has been summarised in Wikipedia:Administrator recall as well (which was intended as a summary of Phase II) but I don't see a link to it in the main proposal here Soni (talk) 10:54, 22 September 2024 (UTC)[reply]
So perhaps the description above just needs to be clarified. — xaosfluxTalk 14:41, 22 September 2024 (UTC)[reply]
Should be consensus for 55%. Option C stated the midpoint of whatever passed in the other discussion. Option C won there, which was 50-60%, so the midpoint is 55% which is explicitly called out in the first discussion. Pinging @Voorts: in case I'm completely misreading something here. Tazerdadog (talk) 18:51, 22 September 2024 (UTC)[reply]
55% is correct. voorts (talk/contributions) 20:31, 22 September 2024 (UTC)[reply]
@Xaosflux, @Soni, and @Tazerdadog: I've fixed the close to state that it's 55% without 'crat discretion; I think I added that bit by accident because that's nowhere in that discussion. voorts (talk/contributions) 20:45, 22 September 2024 (UTC)[reply]
Leaving aside everything else, this part is confusing: A bureaucrat will start a re-request for adminship by default. The admin can request a delay of up to 30 days. If the re-request does not start by then, the admin can have their privileges removed at the discretion of the bureaucrats. Is this implying that if the admin requests a delay then the admin is responsible for creating it? Why not have the 'crat create it after the delay, same as they would for no-delay? Anomie⚔ 14:39, 22 September 2024 (UTC)[reply]
I don't like that part at all. I'd rather see the admin start their own RRFA within some short deadline (7 days - with possibly the option for asking for the 30 day extension) -- and if they don't start it anyone can ask at BN to process the desysop. Crats never have to edit, so requiring the crats to create a pageto move the process forward gives them a pocket veto. — xaosfluxTalk 14:46, 22 September 2024 (UTC)[reply]
I disagree with this RFC's summary of that part of the proposal. As I read it, an admin chooses whether to start an RFA (or stand for election), which must be done within 30 days, and if it's not done within 30 days, crats desysop with discretion ("discretion" such as taking into account whether the petition was entirely signed by obvious sock puppets or had the requisite number of qualified signatories, or to extend the period to 32 or 33 days instead of 30 due to the admin's RL schedule, things of that nature). Levivich (talk) 15:06, 22 September 2024 (UTC)[reply]
Option E there is where it says the 'crat should open create the discussion. The other options had the admin being required to say "come attack me" within a certain period of time. The combination of E+A is where we got the confusion here, since E didn't explicitly say what should happen if a delay is requested. Anomie⚔ 15:11, 22 September 2024 (UTC)[reply]
Yeah, I think the closer got it wrong by finding consensus for E. Only 6 people (out of 30+) voted for E. It's A, not E. Levivich (talk) 15:20, 22 September 2024 (UTC)[reply]
OTOH, looks like only 9 of those 30+ voted after E was added. That part, at least, seems like it could use further discussion by people who care. Anomie⚔ 15:23, 22 September 2024 (UTC)[reply]
I just asked the closer to reconsider it. Levivich (talk) 15:30, 22 September 2024 (UTC)[reply]
This point is one of the pieces that has been ironed out at WP:Administrator recall. As I said above, and others have pointed out, this proposal is not completely ripe. - Enos733 (talk) 15:38, 22 September 2024 (UTC)[reply]
Yeah I guess the current language at WP:RRFA handles it just fine. @Anomie and Xaosflux: take a look at WP:RRFA, I think that addresses your concerns on this point? Levivich (talk) 16:06, 22 September 2024 (UTC)[reply]
🤷 Looks to me like they changed it from E+A to just A. That does resolve the confusion. Anomie⚔ 16:50, 22 September 2024 (UTC)[reply]
Close as premature. The page is a mess right now, as several people have posted above. It isn't anywhere near finalized so of course there will be holes and parts where it doesn't judge consensus. When I said "What we need is an RFC to decide whether or not we need another RFC", I didn't expect anyone to actually do it.Sincerely, Dilettante 15:48, 22 September 2024 (UTC)[reply]
I'm a little confused as to what is being asked here: is this a request for approval of a process? Or are we judging whether consensus was previously formed for it? The latter does not seem to me a good question to ask, as it is sending us further into the weeds of a proposal that has already gotten out of hand with respect to creation and approval procedure. But that's how I read my colleagues' !votes above. Vanamonde93 (talk) 16:16, 22 September 2024 (UTC)[reply]
Do we really need another bureaucratic mess that is another RfC? I think the last one had enough consensus. Ping me if there's anything in particular we're trying to work out and I'm not getting the point of this. I'm trying to take a step back from the more complicated aspects of the project right now but this is important. Clovermoss🍀(talk) 16:20, 22 September 2024 (UTC)[reply]
Close as a confusing, duplicative mess. The specific question in this RFC, as far as I can make out, is asking whether the previous discussion had consensus to implement something following discussion, or whether the outcome of that further discussion needs to be subject to an RFC. I don't think it's sensible to even ask that until that further discussion is complete and we can see the differences between it and the consensus outcome. However, above there appears to be discussion of things other than that question, and no clear agreement about what the consensus of the last RFC was (with the consensus as determined by the closer having changed at least once since the initial close) - other than more discussion of the details was needed (which seems to be happening in two places). I don't think it's possible for this discussion to be useful in any way so it should be closed before it creates even more confusion. Thryduulf (talk) 21:04, 22 September 2024 (UTC)[reply]
@Thryduulf: I think there might be some confusion about what this discussion is for – it would definitely be silly if it was trying to ask people to assess the consensus of the post-close discussion on talk. This RfC asks the same question the post-close discussion has been focused on: did the Phase I and Phase II RfCs result in a consensus to implement? That, I think, is worth discussing. theleekycauldron (talk • she/her) 23:23, 22 September 2024 (UTC)[reply]
The "25 editors" figure in the initial proposal was qualified as being extended confirmed. Definitely not supporting a process whereby any 25 editors, over the course of a full month, can start this process. — Rhododendritestalk \\ 13:13, 24 September 2024 (UTC)[reply]
I don't think there's a consensus ... but whether there is or isn't, "There is no limitation on how often someone can initiate a petition." needs to be clarified. You can't support more than five open petitions, but then the next sentence says you can initiate a petition without limit. Those two statements need to be harmonized. --B (talk) 13:34, 24 September 2024 (UTC)[reply]
I don't think "There is no limitation on how often someone can initiate a petition" is entirely accurate. There are limitations on how often someone can initiate a petition (there are cooling off periods, plus the 5-petitions-at-once limit), limitations that were decided in Phase II and are specified at WP:Administrator recall § Petition. Levivich (talk) 18:20, 24 September 2024 (UTC)[reply]
Re:Close as premature comments, I said my piece above and on my talk page about why I thought (and think) it appropriate. I also don't think I hold any particular status other than being UNINVOLVED in this process. So if some other UNINVOLVED editor wants to close this as premature, I'm certainly not going to push back. Best, Barkeep49 (talk) 20:18, 25 September 2024 (UTC)[reply]
WP:BRD, while an essay, is well established. It would require that a bold edit, once challenged should be discussed. It fairly clearly indicates that the discussion should be opened by the editor making the bold edit. WP:BRD fits well into our policies such as WP:CON and WP:VER (see also WP:ONUS and WP:BURDEN). It is my observation that very few editors making a change actually initiate a discussion when an edit is challenged. While WP:3RR (and variants such as 1RR) are meant to counter disruption, in practice, they act in a contrary way that encourages the bold editor to persevere in forcing their edit through reverts rather than gaining consensus or despite P&G (the broader community consensus). A remedy would be to consider the initial challenged edit as being a revert from the status quo. This would change the dynamic and should encourage good faith editors to initiate discussion rather than engaging in disruptive reverts. For discussion. Cinderella157 (talk) 11:24, 25 September 2024 (UTC)[reply]
It's still edit warring even if you don't hit 3RR. That could be made clearer. But making a change from the status quo is not disruptive and should not be considered a revert. voorts (talk/contributions) 13:07, 25 September 2024 (UTC)[reply]
@Cinderella157, have you read BRD recently? It says things like:
"The talk page is open to all editors, not just bold ones. The first person to start a discussion is the person who is best following BRD."
"Alternatively, start a discussion yourself [←the reverter] on the article talk page about the issue."
I'd say that it "fairly clearly" indicates that following BRD requires someone to start a discussion, but that someone doesn't have to be the bold editor. WhatamIdoing (talk) 19:31, 25 September 2024 (UTC)[reply]
It doesn’t matter who starts a discussion… what matters is that someone start it. So… if “the other guy” doesn’t, then “you” should. Blueboar (talk) 19:51, 25 September 2024 (UTC)[reply]
I agree.
The notion of "original" BRD is this:
There would be a known problem that people are having trouble resolving.
Instead of getting bogged down in (further) discussion, you would make a bold compromise edit.
You would wait to see who disliked your compromise enough to revert it.
You would talk to that one (1) person, until the two of you agreed on something, and implement that.
Repeat as many times as necessary if another editor dislikes the change that the first two editors agreed upon enough to revert it.
A lot of editors appear to think that BRD means "I reverted you and you can't ever revert me back so nyah nyah nyah". WhatamIdoing (talk) 20:40, 25 September 2024 (UTC)[reply]
Overall, I think the policy that you want to consider is WP:EPTALK.
Given our WP:UPPERCASE problems, and our telephone game approach to teaching people how to edit, I think that one of our problems is that WP:QUO is assumed to be a policy/requirement. It's an essay, and it doesn't say what many editors think it says. WhatamIdoing (talk) 19:51, 25 September 2024 (UTC)[reply]
I'm not sure what you're proposing. Are you suggesting that any new edit be considered a revert, and so someone contesting it should open a discussion, as per the bold, revert, discuss cycle, thus making it a bold, discuss cycle? Are you suggesting that since any new edit would be considered a revert, editors should discuss them first on the talk page to avoid getting into back-and-forth reversions? Are you suggesting that the 3-revert bright line be changed to a 2-revert bright line, so the new edit would remain in place during discussion? As the other commenters have stated, the ultimate goal is to get discussion going, no matter who starts it, rather than just churning the page. Individual situations differ a lot, making it hard to give blanket guidance, and so the guidance allows a degree of discretion. isaacl (talk) 21:27, 25 September 2024 (UTC)[reply]
The suggestion seems to be that any new edit be considered a revert for the purposes of 3RR, so the new edit would not remain in place during discussion. CMD (talk) 02:14, 26 September 2024 (UTC)[reply]
The scenario raised below is for an article with one-revert rule in place, so I'm not sure if the intent is to only cover that case. You're right; the only effect would be to turn the 3-revert bright line into a 2-revert bright line (using the current definition of revert, which doesn't include the new edit). isaacl (talk) 02:34, 26 September 2024 (UTC)[reply]
In the current policy, the system is bold(OP)->R1(P2)->R1(OP)->R2(P2)->R2(OP)->R3(P2)->R3(OP). This means the bold edit is edit warred in, as the next step, R4(P2) gets a brightline block. If you treat the initial bold edit as a revert, then the brightline block occurs at R3(OP), meaning policy does not facilitate the edit warring of changes into articles. This works for any stage of XRR where blocks occur at RX+1. CMD (talk) 02:49, 26 September 2024 (UTC)[reply]
This would be applicable to 3RR or 1RR. I used the 1RR example because there are less steps and therefore easier to follow. Also, the shortcomings of the rules are more evident in the 1RR scenario. It is not the same as converting the 3-revert bright line into a 2-revert bright line using the current definition of revert. It would change the current definition of a revert to include the new edit. Cinderella157 (talk)
Scenario 1 with 1RR protection.
Editor A adds a commander to a conflict infobox with a summary that they are important.
Editor B reverts with the edit summary: Per MOS:INFOBOXPURPOSE - not supported by body of article - ie there is no mention of the commander that would tell a reader why they are in the infobox.
Editor A re-adds commander with essentially the same previous edit summary and not addressing the reason the initial edit was reverted
The addition is unsourced (WP:BURDEN). There is no attempt to establish consensus for the addition (WP:ONUS). It is also contrary to MOS:INFOBOXPURPOSE. There are multiple points of P&G for the addition not to stand. Editor A has not reasonably engaged in consensus building. By just reinstating the same material for the same reason, they are effectively edit warring. 1RR is not being as effective as it could and probably should be. To effect, it is rewarding Editor A for edit warring. However, if Editor A's initial edit were considered a revert (from the status quo) the dynamic would be changed. They could not simply revert. At the very least, they would need to discuss and get clarification of the reason given in the edit summary by Editor A. Consequently, 1RR would be more effective in preventing edit warring/disruption, preventing changes contrary to P&G and, in building consensus and a better understanding of the broader community consensus. A similar scenario could be written around 3RR and material being edited in the body of the article but would be more complex because of the many additional steps.
There is nothing wrong with editing boldly. What is wrong is simply re-adding the same material with no attempt to build consensus or acknowledge P&G reasons why the edit might be considered inappropriate. BRD does not mean that the initial editor is the only one who can start a discussion but the initial editor should not just re-add the material without engagement. However, WP:ONUS does place a burden on the initial editor to establish consensus. Revert (in BRD) is not a get-out-of-jail-free card. Without reasonable reason, it is just stonewalling. Preserving the status quo is not of itself a good reason but there may be other factors such as the WP:CONLEVEL for the status quo or prevailing P&G. Cinderella157 (talk) 01:50, 26 September 2024 (UTC)[reply]
One of the problems is the 24-hour rule that experienced edit warriors are easily able to avoid.... that's causing a slow edit war that needs to be reported to the administrator notice board causing a great amount of time to file the report. Moxy🍁 02:27, 26 September 2024 (UTC)[reply]
Are you proposing that the one-revert rule be enforced more strictly when a one-revert rule has been enacted for an article (or category of articles), thus allowing step 3 to be undone to restore the state after one revert? Or are you proposing that instead of placing articles under a one-revert rule, articles should be placed under a prior agreement required rule for any new edit? There are some cases of prior agreement required rules, but so far it's quite rare. There is considerable overhead in managing all new edits through talk page discussions. isaacl
As above, the proposal is not just for 1RR. The 1RR scenario is just easier to follow because there are less steps. What does the proposal mean in terms of the scenario? Step 1 and step 2 are fine. Step 3 is not fine because it is just re-adding contested material and reasonably falls to edit warring. Under the proposal it would breach 1RR. Incidentally, this is a real scenario. In Step 4, Editor B has opened a discussion, restating the reason in the edit summary (albeit with a small amount of additional detail). Cinderella157 (talk) 02:58, 26 September 2024 (UTC)[reply]
OK, so you're proposing that an editor cannot re-insert a change once it has been reverted, until there has been a discussion establishing consensus? That sounds like mandating discussion after a change is reverted (basically similar to the bold, revert, discuss cycle). I prefer looking at the desired state of the article during discussion, rather than counting reverts, which just gets people distracted with arguing about what counts as a revert and whether the editors involved are unfairly resisting a change through joint action, when the focus should be on the content being changed. isaacl (talk) 03:19, 26 September 2024 (UTC)[reply]
No, one would expect BRD, but in practice, this might be something like BRRRDB. Regarless, it should not be BRRRRR ... Where the Rs stop before you get a block depends on whether it is 3RR or 1RR. No editor should just be re-inserting an unmodified change because they can. It is ipso facto edit warring as opposed collaborative iterative improvements. Good editors will initiate discussion. Bad editors will just keep pushing their preference even when it is contrary to P&G. The proposal doesn't change things that much except to draw the bar a bit closer for the editor making the change in respect to either 1RR or 3RR. It should discourage the editor making the initial change from edit warring because they have one more revert up their sleeve even though they have not achieved a consensus per WP:ONUS. Cinderella157 (talk) 03:58, 26 September 2024 (UTC)[reply]
The problem with counting reverts is that it focuses on a numbers game: who can get more people to revert on each side? We need to have a discussion, and get enough participants to form a consensus. So many content discussions wither because there aren't enough people available to engage. isaacl (talk) 04:13, 26 September 2024 (UTC)[reply]
As someone whose biggest point of self-critique is easily that they revert too much and explain not enough in certain moments, and who would like to revert twice or thrice less than they do, I think it's fairly clear to me that my less BRD-adhering, unhappy moments are almost entirely motivated by a thought process like "if I don't fix this, no one else will see it for hours or days, if ever, and what's more I have to be really assertive about it to make the point clear to the other editor"—and ultimately that can result in more bluntness than is required. I don't like when I end up acting less than zen to other editors, and I have admittedly allotted myself a lot of "turf" on my watchlist to patrol.
If reversion is not the end of a given situation, and communication is not immediately fruitful, the natural next resort are WikiProjects, the content noticeboards, or I suppose WP:3O. Something has occurred to me, though it seems a little silly on first blush: what if we had an AIV-style "rapid-response" board for certain disagreements—let's say specifically style disputes for now. That's not quite what 3O is: instead, it could serve as a possible pressure valve so that editors feel they don't have to handle a situation themselves in the here and now. Editors who are comfortable with the Manual of Style could monitor the board, and quickly clarify matters they feel they can help with that get requested. I like talking about the MOS, and I feel others might volunteer for this too. I imagine stale reports would be cleared on a regular basis like AIV, but by that point the posting would also have served its purpose if the posting editor waited for a response like you'd expect: they've now had time to cool down and assess other options for dispute resolution. Remsense ‥ 论 07:32, 26 September 2024 (UTC)[reply]
I don't think this would improve upon the MOS pit. We have so many noticeboards, sometimes editors just don't participate in discussions. CMD (talk) 08:23, 26 September 2024 (UTC)[reply]
It's hard, right? The MOS pit tends to invite general discussion, and I think people would hesitate to post at regular intervals like they would to AIV. Maybe it could be a part of 3O, but I do think there's something there in "people would benefit from a high-visibility, low-friction venue to help nip petty disputes in the bud" Remsense ‥ 论 08:30, 26 September 2024 (UTC)[reply]
But you see, my disputes are always serious and never petty. CMD (talk) 09:35, 26 September 2024 (UTC)[reply]
Heh ) Selfstudier (talk) 13:20, 26 September 2024 (UTC)[reply]
I've had issues with content matters unrelated to style, and the associated WikiProjects didn't respond, either because they were lacking in active participants watching the WikiProject talk page (which is the case for many of them), or apparently the issue wasn't sufficiently interesting for people to weigh in (which happens even with reasonably active WikiProjects, like those associated with popular sports). You can't generate consensus unless enough people engage in discussion. isaacl (talk) 15:45, 26 September 2024 (UTC)[reply]
Of course, and at that point the entire mechanism breaks down. Not sure what to systematically do about that other than "my best". Remsense ‥ 论 15:52, 26 September 2024 (UTC)[reply]
The point was that I think revert wars happen when there aren't enough people to generate consensus, or they aren't interested in having a discussion, and tweaking how reverts are counted won't change this. isaacl (talk) 16:05, 26 September 2024 (UTC)[reply]
@Remsense, I don't know what kinds of pages you're watching, so this might not help with your quest for a zen-like detachment, but you can calculate the average time between page views, and use that to estimate how long you have to act before the next reader will appear. 2 page views per day = 12 hours, 6 pages views per day = four hours, and so forth. Most articles get less than one page view per week. 90% get less than one page view per hour. So unless you tend to be on high-traffic articles, for the most part, instant reactions are not necessary to protect the reader from seeing m:The Wrong Version. WhatamIdoing (talk) 00:54, 29 September 2024 (UTC)[reply]
Hey, that is actually a nice structure to keep in mind, thank you! Remsense ‥ 论 00:56, 29 September 2024 (UTC)[reply]
This is currently happening right now [27] Moxy🍁 03:02, 26 September 2024 (UTC)[reply]
About this: What is wrong is simply re-adding the same material with no attempt to build consensus.
As a general principle, this sounds okay, but in specific instances, that's probably not the case. For example, years ago, I was part of this "edit war":
A removes a sentence (originally written by B) from an article (e.g., while copyediting the whole page).
B puts the sentence back.
A removes that sentence again.
I was "B", and I was really happy that it was removed the second time, without any time-wasting trips to the talk page. Why? Because the second edit summary stated more clearly that the specific sentence had been accidentally duplicated. Sometimes mistakes happen. Maybe not at the 3RR level, or even at the 2RR level, but sometimes simply reverting is the right thing to do. WhatamIdoing (talk) 00:49, 29 September 2024 (UTC)[reply]
What is a revert?
There is a long-simmering issue when dealing with 1RR, namely there is no policy that covers what a revert is. WP:REVERT which defines a revert as reversing a prior edit or undoing the effects of one or more edits, which typically results in the article being restored to a version that existed sometime previously. is an essay, and Help:Revert, which is an information page, uses undoing or otherwise negating the effects of one or more edits, which results in the page (or a part of it) being restored to a previous version.
First issue is that these two definitions contradict each other. ...typically results in the article being restored to a version that existed sometime previously and ...which results in the page (or a part of it) being restored to a previous version are mutually exclusive. Something can typically result or result, and there is a large space between them. Secondly, undoing the effects of one or more edits and otherwise negating the effects is a hole wide enough to drive an article about an 80s cartoon character through.
Normally, this type of ambiguity is par for the course, but we have multiple policies, bright-line rules, and arbitration sanctionsWP:3RR, WP:1RR, WP:CTOP#Standard_set that call out reverts, and can be grounds for immediate blocking and sanctioning.
So I ask, what is a revert? When does something become the WP:STATUSQUO so that changing or removing it is BOLD and not a revert? Where is the line on undoing the effects or negating the effects? If someone adds bananas are good to an article and someone changes that to bananas are not good has the previous edit been reverted, as the effect was negated, or should the banana-hater have the first mover advantage? Should we have an actual policy defining a revert if we're going to have arbitration sanctions and bright-line blocked if you break 'em rules about reverting? ScottishFinnishRadish (talk) 12:39, 26 September 2024 (UTC)[reply]
A revert is changing anything I don't want changed. Seriously tho, since changing anything is technically a revert, one is forced into examining the exact circumstances, how long since content was added, intent, etc. Selfstudier (talk) 13:36, 26 September 2024 (UTC)[reply]
I think rules should be interpretted according to their purpose, which isn't always clear from their literal wording. The purpose of classifying edits as reverts is to identify edit-warring in a semi-rigorous way. It isn't to catch editors out for cooperative editing. If Selfstudier writes "The population of XYZ is 10,000", and I remove it with the comment "I don't like that source", then that's a revert. However, if I remove it with the comment "That's a different place called XYZ, see page 23 for our XYZ", that's cooperative editing. The difference is that in the first instance I was opposing Selfstudier's intention, and in the second case I was assisting with it. Something likely to please the editor whose edit is being changed shouldn't be called edit-warring, ergo not a revert. Encoding this principle in a way that everyone can understand might be tall order, and in my current covid-ridden-and-sleep-deprived state I won't try. Zerotalk 15:15, 26 September 2024 (UTC)[reply]
SFR is correct to highlight the "restored to a previous version" aspect, which was always broken. Consider add A, add B, delete A, add C, delete B. Possibly two reverts in there but no two versions of the page are the same. Zerotalk 15:19, 26 September 2024 (UTC)[reply]
Should be able to point to an edit that was reversed. Removal is basically always a revert, restoring what was removed is almost always a revert, rewording? Depends, but in the case of "A is true" edited to "A is not true", one of those editors is doing something more important than reverting anyway. nableezy - 15:54, 26 September 2024 (UTC)[reply]
I don't think there can be a hard rule on when edit B negates the effects of edit A, because there are lots of ways to reword edits, all functionally equivalent to a revert. Unfortunately for the enforcement of the one-revert rule, I think it's also difficult to have blanket rules on when some content has achieved default consensus agreement status, as it's highly dependent on factors such as how many editors regularly review changes to an article. As per English Wikipedia's decision-making traditions, the way forward is to have a discussion about what is the current consensus, halting any changes on the contested content in the meantime. I appreciate, though, that has high overhead. The community has been unable to agree upon less costly ways to resolve disagreements. isaacl (talk) 15:59, 26 September 2024 (UTC)[reply]
An edit that deliberately reverses the changes of one or more previous edits, in whole or in part. Cremastra (talk) 19:39, 26 September 2024 (UTC)[reply]
New Page Reviewers
Hi. I thought I ask the question here regarding policy on New Page Reviewers. The current tutorial states "The purpose of new pages patrol is equally to identify pages which cannot meet this standard, and so should be deleted, and to support the improvement of those that can. Pages that pass new pages patrol don't have to be perfect, just not entirely unsuitable for inclusion." On several occasions I have noted that new page reviewers have marked pages as reviewed, but for other editors to then go in another as not meeting notability rules. If this is the case is there not a mechanism that the new page reviewers can be reported as not meeting the "just not entirely unsuitable for inclusion" criteria? Davidstewartharvey (talk) 12:22, 29 September 2024 (UTC)[reply]
The second part of your statement is unclear, could you rephrase? Remsense ‥ 论 12:31, 29 September 2024 (UTC)[reply]
I think they are saying that there are 2 editors A and B. A reviews the page, marks it as reviewed, then B marks it as not meeting notability rules. And the question is whether there is a way to report this inconsistency based on the premise that B is correct, and A made an error. Sean.hoyland (talk) 12:55, 29 September 2024 (UTC)[reply]
Or vice versa! Davidstewartharvey (talk) 13:23, 29 September 2024 (UTC)[reply]
It's common for editors to disagree on notability, as is clear in a number of AfD nominations, so a reviewer passing a new page that is subsequently nominated for deletion isn't necessarily a problem. If, however, you see it happening frequently with the same reviewer, you should discuss your concerns with that editor on their talk page. Schazjmd(talk) 14:07, 29 September 2024 (UTC)[reply]
Something doesn't have to be unquestionably notable to pass NPP patrol. It just needs to be "not entirely unsuitable". Some NPPers will only mark at patrolled when they're very, very sure a topic is notable; others will mark it as patrolled so long as it doesn't meet some of the WP:CSD criteria, most reviewers are somewhere in between the two. Also, many people use the notability tag not to mean "this isn't notable" (really, if you're sure, you should probably start a deletion discussion), but "I don't know if this is notable, can someone who knows more about this kind of thing come check?" So even if two different reviewers might both agree that a page should be marked as patrolled, that doesn't mean that one reviewer might want to leave a notability tag where the other wouldn't. -- asilvering (talk) 00:38, 30 September 2024 (UTC)[reply]
Wikipedia:New pages patrol § Notability explains that Opinions are divided on how important it is to consider notability during new page patrol. In my own opinion, notability issues don't always make an article entirely unsuitable for inclusion; as Joe Roe says in his excellent NPP tips essay, NPP is not the Notability Police.jlwoodwa (talk) 17:07, 30 September 2024 (UTC)[reply]
WikiPolicy / Recommended Practice question: "how many examples are enough?"
I have not seen this type of disagreement between two editors anywhere else on wikipedia, so I want to bring it up for a more general discussion. The question is about an appropriate number of examples to illustrate a non-controversial topic:
1) how many examples are sufficient/appropriate?
2) what constitutes a "clutter", when giving a list of examples?
3) is adding an example from a class, which is not present in the list, a clutter?
I would like to get opinion of 3rd parties instead of limiting the food-fight to the two original parties.
More specifically, I am talking about this article: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(policy)/Inflection .
I made a minor change to this article. More specifically, I added Russian language as an example of as highly inflectional language. I specifically wanted to add Russian there, because this list is missing Slavic languages completely, and because Russian is mostly widely spoken of the Slavic languages:
After my edit the paragraph reads:
Languages that have some degree of inflection are synthetic languages. These can be highly inflected (such as Latin, Greek, *Russian*, Biblical Hebrew, and Sanskrit), or slightly inflected (such as English, Dutch, Persian). https://en.wikipedia.org/w/index.php?title=Inflection&oldid=prev&diff=1248062111&markasread=327526085&markasreadwiki=enwiki
Editor "Remsense" objected to my edit with a comment:
https://en.wikipedia.org/w/index.php?title=Talk:Inflection&oldid=prev&diff=1248062439
@Walter Tau, please stop adding clutter to the article. I'm not required to give a reason specifically rooted in policy just as you don't
In addition I would like to ask:
4) Is there a wiki-policy about appropriate number of examples to illustrate a non-controversial topic?
5) How do you find if Wikipedia has a policy about something?
I have never brought up a deletionist to the front of a crowd, but this particular editor consistently shows questionable behavior (please search for "Remsense" on https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(policy)/Wikipedia:ANI),
and the topic of my POLICY question seems very important and timely. — Preceding unsigned comment added by Walter Tau (talk • contribs) 12:54, 29 September 2024 (UTC)[reply]
There's no policy or guideline specifying number of examples (and, IMO, there should not be). It's a matter of editorial judgement. In this case, it's a simple content dispute. It's unfortunate that you didn't engage in the talk page discussion that Remsense began on the issue and instead posted on three noticeboards (Teahouse, 3O, and here). Schazjmd(talk) 14:14, 29 September 2024 (UTC)[reply]
Also, labelling other editors (deletionist) is inflammatory and unproductive. Schazjmd(talk) 14:17, 29 September 2024 (UTC)[reply]
@Walter Tau Please do not cast WP:aspersions on Remsense, or any other editor. I cannot emphasize that enough. This is not treating other editors with respect and civility. Cremastra (talk) 20:21, 29 September 2024 (UTC)[reply]
In addition I want to mention, that editor "Remsense" has no expertise in Comparative Linguistics ( as can be judged from his profile and non-deletionist edits). — Preceding unsigned comment added by Walter Tau (talk • contribs) 12:56, 29 September 2024 (UTC)[reply]
The only reason this wasn't closed on the spot was you said you wanted to discuss the general case. Whining about other editors you're disputing with is not a matter for the village pump, it's a matter for WP:ANI, but you won't like the result if you go there, so I don't recommend it.
Are you satisfied with Schazjmd's answer that there is no standard, and it's a matter for editorial discretion? If so, we should close this. (But Schazjmd is correct, there's no simple rule. Acceding to requests like yours every time will make it impossible to list select examples, and will collapse into "here is the full list" for everything if everyone insists on their favorite example being included.) SnowFire (talk) 18:59, 29 September 2024 (UTC)[reply]
Dear @User:SnowFire, thank you for you input. This is the first time in my many years of wiki-editing, that I have engaged into a dispute with another editor. I am not familar with the available dispute resolution means, so this is my learning lesson. Unfortunately, I get different and conflicting suggestions from different editors of what is the most appropriate rout, so I cannot call this lesson a complete success. Nevertheless, I feel that the proposal by 3O for @[[User:Иованъ] on https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(policy)/Talk:Inflection is the most appropriate way to end this discussion.
Notably, his proposal suggests criteria for including specific examples, which was my original Village Pump question. To rephrase @User:Иованъ's suggestion :
when making a list of examples, limit it to the most common (or distinct in another way) examples of each class.
Is there any way to put this suggestion for a discussion to make it into a wiki-policy?
@User:Schazjmd Finally, on the term "deletionist". I proudly display on my wiki-profile https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(policy)/User:Walter_Tau an "anti-deletionist" userbox. I assumed, there must be a userbox for "deletionist", but it looks like I was wrong with this assumption. Walter Tau (talk) 21:46, 29 September 2024 (UTC)[reply]
Because "deletionist" is *usually* used pejoratively. Cremastra (talk) 22:09, 29 September 2024 (UTC)[reply]
I don't find it necessary to make the very basic principle that communication is equally about "what not to include" part of my wikıïdentity. Remsense ‥ 论 22:20, 29 September 2024 (UTC)[reply]
Template protection for DYK queues?
For those not familiar with the DYK workflow, its basically anybody can review a submission, anybody can promote a reviewed submission to a prep area, but then we need an admin to move that into a queue, because the queues are fully (i.e. admin only) protected. Once in a queue, an admin bot moves things to {{Did you know}} which is transcluded onto the main page. DYK is chronically short of admins to perform the last step. That's probably the single biggest roadblock to the smooth operation of DYK, and has been for a long time.
There are a number of DYK regulars who are highly skilled and trustworthy, but for all the usual reasons don't want to subject themselves to RfA hell. I started a conversation at WT:DYK#Giving queues template instead of full protection? about the possibility of changing the full protection of the queues to template protection, and making a limited number of DYK regulars template editors. This was met with positive response, so I'm coming here to find out how the broader community would feel about this.
I know it's policy that the main page is fully protected (but I don't know where that's written down). It's unclear to me how much of the DYK queues being fully protected is baked into policy. The Template Editor capability only goes back to 2013, much newer than DYK, so I suspect it's mostly a case of "we've always done it this way". Assuming DYK could agree on the implementation details, would I be within my remit as an admin to change the protection level on the DYK queues and start handing out template editor bits? Or does that require some community-wide approval process? RoySmith(talk) 17:57, 30 September 2024 (UTC)[reply]
I support the proposal (and suggest that DYK regular admins just hand out the bit as needed). In case anyone is wondering, the DYK template on the Main Page and the next DYK update would continue to be fully protected via cascading protection, so the proposal would not allow template editors to vandalise the Main Page. —Kusma (talk) 18:37, 30 September 2024 (UTC)[reply]
Doesn't template editor usually have a host of pre-requirements? As anyone with template editor can change templates transcluded to millions of articles. -- LCU ActivelyDisinterested«@» °∆t° 23:11, 30 September 2024 (UTC)[reply]
Personally, I don't favour expanding the role of template editors simply because the permission may be easier to grant. I would prefer creating a new permission tailored for the role, such as DYK-editor or main-page-editor, which can be assigned to a corresponding user group. isaacl (talk) 23:54, 30 September 2024 (UTC)[reply]
In theory, I agree that a finer-grained permission system would be a good thing. In practice, I suspect it would be near impossible to make that happen. In the meantime, we've got zero filled queues because no admins want to do the work, and the people who want to do the work aren't admins and don't want to be. RoySmith(talk) 00:37, 1 October 2024 (UTC)[reply]
I'm not sure that it would be impossible to gain consensus for a protection level for, say, main page maintenance. If I understand the documentation correctly, only configuration changes are needed. I just don't see template editor as a good fit: I think it requires a much higher degree of trust than editing main page components. isaacl (talk) 01:32, 1 October 2024 (UTC)[reply]
Well, I'm willing to explore other possibilities. Can you give me a link to where this is documented? RoySmith(talk) 01:37, 1 October 2024 (UTC)[reply]
mw:Help:Protected pages says additional protection levels can be defined by the $wgRestrictionLevels configuration setting. mw:Manual:$wgRestrictionLevels shows an example of defining a permission level, and then modifying $wgGroupPermissions to assign the permission level to a user group (also see mw:Manual:User rights § Creating a new group and assigning permissions to it). isaacl (talk) 04:16, 1 October 2024 (UTC)[reply]
Thanks for the link. As far as I can tell from that, what we'd need to do is not just create a new user group, but also create a new restriction level. That all seems excessively complicated. RoySmith(talk) 11:33, 1 October 2024 (UTC)[reply]
Yes, that's what I said. Creating the permission level is one line in the configuration, and is necessary to be able to designate which pages can be edited by the new role. Procedurally, it's the equivalent amount of work as designating a page that can only be edited by those with the template editor role, and then assigning users to the corresponding template editor group. isaacl (talk) 15:57, 1 October 2024 (UTC)[reply]
OK, I'm not seeing that. Perhaps you could write it all out in in detail a sandbox or something? RoySmith(talk) 16:10, 1 October 2024 (UTC)[reply]
As I understand it, the English Wikipedia configuration was modified to implement the template editor role. The change allowed admins to select the template editor permission level when protecting a page, created a template editor user group, and assigned the permission to the new template editor group and the sysop group. The same would have to be done to create a main page editor permission and a corresponding role. The new permission level is needed so specific pages can be designated as limited to main page editors. A corresponding group is needed so main page editors can be assigned to the group. The permission is also assigned to the sysop group so admins can also edit the pages in question. isaacl (talk) 16:55, 1 October 2024 (UTC)[reply]
I'm not opposed to going this route, but I'm not confident enough that I understand the details to tackle it myself. If you're willing to take on getting this created, I'll be happy to use it in lieu of my current plan. RoySmith(talk) 17:02, 1 October 2024 (UTC)[reply]
If it helps, Wikipedia talk:Requests for comment/Template editor user right/Archive 2 § Next steps is where the work to implement the template editor role was discussed. Roughly speaking, it seems to consist of configuration changes, MediaWiki message changes, English Wikipedia page protection process changes, and English Wikipedia icon changes. I'm only tangentially familiar with most of these, so I think a better bet would be to crowdsource volunteers to help out. Hopefully an RfC would find enough interested helpers (as seems to have been the case with the template editor role, but then again, by the nature of that role it was probably more likely to do so). I was mainly thinking of what it took to implement the role in the configuration, rather than how to update English Wikipedia's procedures, so I appreciate now that it's more upfront work than re-using an existing permission level. However I think it pays off by making it easier to replenish a pool of editors able to edit the main page, since they won't have to meet the higher requirements for the template editor role. isaacl (talk) 17:33, 1 October 2024 (UTC)[reply]
I don't think fine grained permissions are a good thing. Everybody who can be trusted to edit templates or to decide what should be on the Main Page should be made an admin. The only reason we need extra permissions at all is that we do not have a working method to make new admins. —Kusma (talk) 05:20, 1 October 2024 (UTC)[reply]
So in the interest of getting results, I would suggest to go ahead with changing the queue protection to "template protection" and assigning the template editor bit to a couple of people now. A separate permission could be a later second step that we should take if we need it. —Kusma (talk) 11:11, 1 October 2024 (UTC)[reply]
My read on this is that they may say they want to do the work, but they don't think they'd be trusted to. And in that case, why should we trust them to? RFA is still thataway, and we're not doing anybody - not the reluctant candidates, not the current admins, not the DYK process - any favors by bypassing it. —Cryptic 13:58, 1 October 2024 (UTC)[reply]
By bypassing RfA we do almost everyone a favour. The exception is future admins who will have higher workloads because we aren't promoting enough of them. But as long as RfA is so hurtful that failed RfAs have a high chance of putting off people from editing altogether (or at least from running ever again), we need to care for other processes like DYK by finding solutions for their problems without involving RfA. —Kusma (talk) 15:03, 1 October 2024 (UTC)[reply]
We have important work that isn't getting done. We have people with the skills and desire to do that work. The only reason we can't draw a line between point A and point B is because RFA is totally broken. RoySmith(talk) 15:22, 1 October 2024 (UTC)[reply]
We have the ability to draw a line between point A and point B without making it go through point C (whether that's the admin role or the template editor role). We bundle the lines together to try to avoid overhead in managing the lines. But in this case, where drawing the line would be easy given the existence of a pool of editors with the required skills and interest, I think it's less overhead to draw a direct line, rather than routing it through a different point that requires a larger set of skills. isaacl (talk) 16:09, 1 October 2024 (UTC)[reply]
DYK queue editors would likely not have the "real" template coding experience typically expected by WP:TPEGRANT. They basically are just editing text. But if given the right, they would then have access to other highly-sensitive templates and their actual code. —Bagumba (talk) 12:45, 1 October 2024 (UTC)[reply]
Just to be clear, what I'm seeking here is clarification on why the queues are fully protected. Is there some specific established policy which requires that because they feed into the main page?— Preceding unsigned comment added by RoySmith (talk • contribs) 11:24, 1 October 2024 (UTC)[reply]
Judging by the protected areas listed at WP:ERRORS, it looks like any page content that will imminently be on the MP is fully protected. —Bagumba (talk) 12:49, 1 October 2024 (UTC)[reply]
