Wikipedia:Bomba de agua de pueblo (laboratorio de ideas)

La draftificación ha sido criticada durante mucho tiempo como una puerta trasera para la eliminación. En New Pages Patrol (NPP), es común mover artículos nuevos que no están listos para el espacio principal al espacio de borradores. De esta manera, se conservan los artículos que podrían ser aptos para Wikipedia, pero que aún no lo son. El creador del artículo tiene entonces la oportunidad de mejorar su artículo sin que los NPPers le respiren en la nuca o que lo lleven a Artículos para eliminar . Si alguien, incluido el creador del artículo, se opone a la draftificación, el artículo debe ser devuelto al espacio principal (la draftificación debe revertirse). Esto se explica en DRAFTNO #6 y #7 . No se requiere ninguna razón para la objeción.

Problema: Sin embargo, también tenemos una regla según la cual los borradores que no se han editado durante seis meses se eliminan automáticamente, según el Criterio para la eliminación rápida G13 . Por lo tanto, los New Page Patrollers bien intencionados redactarán unilateralmente nuevos artículos que aún no están listos para la enciclopedia. Los nuevos editores que crearon el artículo pueden estar en desacuerdo con la medida, sin saber que pueden objetar. Los nuevos usuarios pueden desanimarse y abandonar Wikipedia por completo, y después de seis meses el borrador se elimina según el Criterio para la eliminación rápida G13. Como este proceso ocurre sin debates de la comunidad, el resultado es que la redacción se denomina "puerta trasera a la eliminación".

Solución: Este problema se puede resolver sin cambiar la política o la práctica actual . Solo necesitamos hacer que sea muy obvio para los nuevos usuarios que pueden objetar la conversión en borrador. También podemos hacer que sea fácil revertir la conversión en borrador (asumiendo que el nuevo usuario está autoconfirmado ). Sugiero que hagamos esto agregando una plantilla a todos los artículos que se convierten en borradores . La plantilla incluiría un gran botón azul , similar al botón "¡Enviar el borrador para revisión!" en Template:AfC submission/draft , que dice "Objetar este movimiento". Al hacer clic en este botón: 1. Deja un mensaje en la página de discusión del editor que realizó la conversión en borrador, notificándole que ha habido una objeción al movimiento y solicitando que se revierta inmediatamente. 2. Mueve la página de regreso al espacio principal automáticamente, o si la cuenta del editor no puede realizar esta tarea, crea una entrada en Movimientos solicitados/Movimientos técnicos a tal efecto. Esto último es mejor, pero también más complejo técnicamente. También sería útil agregar un botón similar a Template:Uw-articletodraft , la advertencia que normalmente aparece durante la redacción del borrador.

Implementación: Una vez que la nueva plantilla esté lista, se puede agregar al script de usuario MoveToDraft de MPGuy , que es la forma más común en que los miembros de NPP redactan borradores de artículos. Debe colocarse sobre la plantilla AfC en todos los borradores de artículos.

Agradecería los comentarios de editores con habilidades técnicas que puedan crear esta plantilla (o decirme que es imposible), de miembros del NPP que redactan artículos y de editores no involucrados que tengan opiniones sobre el proceso de redacción. Toadspike [Discusión] 10:37 26 sep 2024 (UTC) [ responder ]

Esta idea no es realmente mía, obviamente surgió a raíz de la convocatoria de propuestas más reciente. Una idea similar se discutió anteriormente aquí , pero esa discusión propuso un requisito que todos los editores deben seguir (política), no una solución técnica, y terminó en un desastre. Para evitar algo similar, pido a todos los participantes que se concentren en mejorar la situación actual en lugar de debatir la moralidad de la redacción de borradores en su conjunto. Toadspike [Discusión] 11:03, 26 de septiembre de 2024 (UTC) [ responder ]

Notificar a los usuarios que comentaron más directamente sobre este tema en la RfA: @ Alalch E. @ Usuario:Onel5969 @ Usuario:Hobit @ Usuario:Fangz @ Usuario:Nsk92 . También notifiqué a la página de discusión de NPP y publiqué un mensaje en Discord. No estoy seguro de cómo notificar a todos los participantes de la discusión anterior (aparte de hacerlo manualmente) y no estoy seguro de que sea productivo considerando cuántas personas estuvieron involucradas y cuán fuera de tema se volvió, así que no lo haré por ahora. Toadspike [Discusión] 11:07 26 sep 2024 (UTC) [ responder ]

¿Estás seguro de que quieres convertir esto en una RfC? ¿Hay un ANTES en alguna parte? Aaron Liu ( discusión ) 11:32 26 sep 2024 (UTC) [ responder ]

Buen punto, no estoy seguro de si la etiqueta RfC se aplica, así que eliminaré las plantillas. Estaba buscando formas de notificar a las personas y leí mal RFCBEFORE. Toadspike [Discusión] 11:34, 26 de septiembre de 2024 (UTC) [ responder ]

• Oposición : El mensaje de redacción de borradores podría modificarse, pero un gran botón para revertir la medida conducirá a más AfD, mayor presión sobre NPP, más comportamiento BITEY y peor retención de editores. El espacio de redacción de borradores es increíblemente valioso y la gente tiene algunas opiniones increíblemente distorsionadas sobre el espacio. Si hiciéramos algo así, terminaríamos ahuyentando a nuevos editores porque aprender cómo hacer que su artículo cumpla con nuestras complicadas pautas en menos de 7 días (etiqueta AfD) no es fácil para mucha gente. El espacio de redacción de borradores les da la oportunidad de trabajar en el contenido, recibir consejos y hacer artículos que realmente sobrevivirán en AfD y les permitirán quedarse. Realmente necesitamos redactar más borradores, y me he tomado la responsabilidad de comenzar a hacerlo de nuevo y alentar a otros a que lo hagan. Soy un gran defensor de la retención de editores. Esta no es la forma de hacerlo. Hola, soy josh ( discusión ) 12:15, 26 de septiembre de 2024 (UTC) [ responder ]

  El problema con la redacción unilateral de borradores es que también puede ser increíblemente mordaz, especialmente cuando se hace por razones arbitrarias que no tienen nada que ver con ninguna de las razones por las que algo podría ser eliminado en AfD (aunque esto es menos frecuente que las razones triviales por las que se rechazan cosas en AfC). Deberíamos redactar menos artículos y no enviarlos a AfD, sino dejarlos en el espacio principal (con las etiquetas apropiadas cuando esté justificado) para que se puedan encontrar y mejorar en lugar de pretender que no existen durante seis meses y luego eliminarlos. Thryduulf ( discusión ) 12:34, 26 de septiembre de 2024 (UTC) [ responder ]

  No estoy realmente convencido de que la draftificación sea peor que las alternativas: el etiquetado también es mordaz, y un usuario que etiquete un artículo y lo deje en el espacio principal podría hacer que otro usuario lo vea y decida abandonarlo. La draftificación podría ser una forma de proteger un artículo hasta que llegue a un mejor estado. Pero creo que la otra parte con la que tengo un problema es la falta de pautas claras. Claramente, algunas personas tienen un problema con la draftificación y otras no, y la gente tiene diferentes ideas sobre para qué sirve. Eso necesita ser más concreto. De lo contrario, simplemente decir "deberíamos usar menos la draftificación" no conducirá a ningún cambio positivo. Fangz ( discusión ) 12:43, 26 de septiembre de 2024 (UTC) [ responder ]

  Estoy de acuerdo con el sentimiento general: defender una mayor o menor redacción no resuelve el problema de que los nuevos usuarios básicamente no pueden oponerse a ello. Toadspike [Discusión] 12:47, 26 de septiembre de 2024 (UTC) [ responder ]

  Me imagino una plantilla (¿quizás una específica para usuarios relativamente nuevos?) que sea algo como esto:

  1. Hola, este artículo ha sido trasladado a formato borrador porque otro usuario cree que tiene potencial, pero aún no está listo para la enciclopedia. MOTIVO:

  2. Puedes seguir trabajando en él mientras no se publique, aunque ten en cuenta que si no lo editas durante 6 meses, se eliminará. Aquí tienes algunos recursos útiles.

  3. Cuando considere que el artículo está listo, puede enviarlo a revisión, lo que puede brindarle comentarios útiles. []

  4. Alternativamente, puede devolver el artículo a la enciclopedia principal en cualquier momento y hacer que se edite mientras forma parte de la enciclopedia principal. Consulte WP: Borrador de objeto. Sin embargo, tenga en cuenta que si otros usuarios piensan que hay problemas que no se pueden solucionar con el artículo, este puede presentarse como candidato para su eliminación. Fangz ( discusión ) 12:54, 26 de septiembre de 2024 (UTC) [ responder ]

  Me gusta la idea de la advertencia para el usuario. Aaron Liu ( discusión ) 12:59 26 sep 2024 (UTC) [ responder ]

  El etiquetado nunca da como resultado que un artículo se elimine automáticamente. –  Joe  ( discusión ) 18:43, 26 de septiembre de 2024 (UTC) [ responder ]

  En mi opinión, los artículos que se han convertido en borradores deberían volver (¿semi?) automáticamente al espacio principal después de un tiempo de espera en lugar de eliminarse. O al menos, deberían volver a evaluarse para determinar su relevancia. Realmente no veo la razón para la eliminación rápida y automática, excepto como eliminación por puerta trasera. Fangz ( discusión ) 18:59, 26 de septiembre de 2024 (UTC) [ responder ]

  Me gusta esa idea. Pero a ellos no les gusta, así que es un punto discutible en términos de la política actual. –  Joe  ( discusión ) 06:16, 27 de septiembre de 2024 (UTC) [ responder ]

  ¿Por qué no pueden mejorarlo en el espacio principal, sin tener que soportar el dolor de un rechazo inicial y una cuenta regresiva de seis meses para eliminarlo? No entiendo por qué sigues presentando esto como una elección entre el espacio de borradores y AfD. –  Joe  ( discusión ) 18:46, 26 de septiembre de 2024 (UTC) [ responder ]

  La razón es que "mejorarlo en el espacio principal" tiene sus propios problemas. Un artículo en el espacio principal tiene que hacer malabarismos entre ser útil al lector y ser útil al editor. Esto implica procesos formales y jerga wiki para lograr coherencia, plantillas unificadas para los problemas del artículo, etiquetado claro y despiadado de los problemas, etc. Existe una fuerte tendencia a que la primera experiencia de un editor sea una pelea muy pública y humillante contra editores establecidos que tienen una mejor comprensión de los procesos de Wikipedia, lo que rápidamente aleja al editor o lo bloquea. También es muy difícil mejorar esta experiencia, ya que implicaría cambios fundamentales que afectarían a todo tipo de cosas. Mientras tanto, mejorar un artículo en modo borrador permite un proceso de comunicación más informal para guiar un artículo hacia un estado aceptable. Fangz ( discusión ) 19:10, 26 de septiembre de 2024 (UTC) [ responder ]

  Recientemente trabajé un poco sobre las estadísticas de visitas a la página . El artículo promedio recibe aproximadamente una visita a la página por semana. Por lo tanto, si el artículo nuevo es típico, no tiene por qué "ser útil para el lector", porque en realidad no hay lectores. Los editores (especialmente los de NPP y RecentChanges) pueden revisar un artículo nuevo unas cuantas docenas de veces el primer día, pero una vez que los revisores lo dejan en paz, la mayoría de los artículos simplemente no tienen mucho tráfico.

  Creo que la razón por la que no estamos dispuestos a "mejorarlo en el espacio principal" es porque tenemos miedo de olvidar que estaba allí y, años después, alguien se avergonzará de descubrir que un artículo de WP:UGLY ha sido descuidado desde entonces. Estamos usando la redacción de borradores y otras amenazas como una forma de hacer que otros WP:VOLUNTEERS mejoren el artículo según nuestra idea de calidad aceptable. WhatamIdoing ( discusión ) 20:40 26 sep 2024 (UTC) [ responder ]

  No sé si estamos considerando diferentes espacios de nombres de borradores, pero un "proceso informal de comunicación para guiar un artículo hacia un estado aceptable" suena como exactamente lo opuesto a nuestro proceso actual de AfC. –  Joe  ( discusión ) 06:19, 27 de septiembre de 2024 (UTC) [ responder ]

No me gusta la idea de un botón, pero creo que se debería cambiar la plantilla. Creo que tener un botón sugiere que es una opción predeterminada, pero creo que un enlace está bien. Fangz ( discusión ) 12:37 26 sep 2024 (UTC) [ responder ]

• Esto es más o menos lo que hace {{subst: draft article }}, pero MoveToDraft usa {{subst: AfC submission/draft }} por alguna razón. C F A 💬 12:41, 26 de septiembre de 2024 (UTC) [ responder ]

  Para que conste, yo apoyaría el uso de {{ borrador del artículo }} o la creación de una nueva plantilla con los cambios propuestos. C F A 💬 12:44, 26 de septiembre de 2024 (UTC) [ responder ]

  Se supone que todos los borradores de AfC deben usar la plantilla de AfC. Si estás hablando del botón "publicar ahora", es solo para los que se confirman automáticamente. Aaron Liu ( discusión ) 12:45 26 sep 2024 (UTC) [ responder ]

  Pero los artículos no son inherentemente "borradores de AfC" una vez redactados. Las personas pueden devolverlos al espacio principal por sí mismas, sin que se hagan preguntas, o enviarlos opcionalmente a AfC. La plantilla de borrador de AfC no menciona la primera opción. C F A 💬 12:48, 26 de septiembre de 2024 (UTC) [ responder ]

  Por cierto, ayer se cambió el script de MTD para usar {{ borrador de artículo }} . - MPGuy2824 ( discusión ) 12:48 26 sep 2024 (UTC) [ responder ]

  Ah, no me había dado cuenta. Al menos así está mejor. C F A 💬 12:49, 26 de septiembre de 2024 (UTC) [ responder ]

  Me pregunto si alguna vez dejaremos de usar el lenguaje de "publicación" inapropiado y legalmente incorrecto en esa plantilla. En esta wiki, es el autor, no el revisor de AFC, quien la "publica". WhatamIdoing ( discusión ) 20:43 26 sep 2024 (UTC) [ responder ]

  @WhatamIdoing : ¿ Se te ocurre una palabra mejor? (En serio, llevo años intentándolo y no se me ocurre nada). –  Joe  ( discusión ) 07:33, 27 de septiembre de 2024 (UTC) [ responder ]

  Sí: WP:MOVE . WhatamIdoing ( discusión ) 20:28 27 sep 2024 (UTC) [ responder ]

  Sí, pero entonces tienes que especificar "mover al espacio principal" o algo así y eso suena a jerga. "¿Mover fuera del borrador", tal vez? –  Joe  ( discusión ) 04:49, 1 de octubre de 2024 (UTC) [ responder ]

  Eso funcionaría. WhatamIdoing ( discusión ) 05:19 1 oct 2024 (UTC) [ responder ]

  Bueno, eso podría resolver el problema. No le explico a los nuevos usuarios cómo su artículo se convirtió en borrador, pero al menos hay una manera fácil de revertirlo. No lo retiraré por ahora, tal vez otros tengan ideas. (PD: tal vez quieras actualizar Usuario:MPGuy2824/MoveToDraft ) Toadspike [Discusión] 12:51, 26 de septiembre de 2024 (UTC) [ responder ]

• Este es el laboratorio de ideas, así que no voy a hacer comentarios en negrita, pero tengo sentimientos encontrados. Estoy a favor de suavizar la experiencia para los recién llegados, pero me opongo al concepto de que la conversión en borrador sea automáticamente reversible. Si un nuevo supervisor de páginas revisa un artículo nuevo y lo pasa al borrador porque claramente no es adecuado para el espacio principal, el creador debería hacer algo más que decir "Me opongo" para poder volver a mover su artículo claramente inadecuado. Recientemente propuse que todo el espacio de borradores debería estar protegido contra cambios en el nivel semi (la propuesta no fue bien recibida, lo cual es justo). Esta es probablemente la regla que más ignoro en Wikipedia, principalmente porque se trata de granjas de spam que intentan abusar de la regla para promover su basura. Además, un usuario nuevo cuyo envío se pone en cuarentena en el espacio de borradores y se le dejan instrucciones y una lista de sugerencias con enlaces útiles ya está recibiendo un mejor trato que el que la mayoría de los editores han tenido o tendrán, y si su reacción a eso es abandonar furiosamente, entonces probablemente no sea una buena opción para el entorno colaborativo de Wikipedia de todos modos. Ivanvector ( ^Discusión / _Ediciones ) 12:57 26 sep 2024 (UTC) [ responder ]

  @ Ivanvector , ¿conoces el chiste de "Si le preguntas a tres personas, obtendrás cuatro opiniones"? Me pregunto si le preguntamos a tres miembros del NPP qué significa "listo para el espacio principal", si obtendríamos cuatro opiniones. Por lo que sé, "listo para el espacio principal" suele significar "contiene al menos tantas referencias como el artículo promedio, pero de mayor calidad". Todos los niños en Lake Wobegon están por encima del promedio, y todos los nuevos artículos de Wikipedia también deben estarlo. WhatamIdoing ( discusión ) 20:12 26 sep 2024 (UTC) [ responder ]

  Me parece que recuerdo vagamente una discusión sobre ese tema en algún momento de un pasado no muy lejano. Folly Mox ( discusión ) 22:55 26 sep 2024 (UTC) [ responder ]

  176 comentarios de 22 editores, y probablemente yo solo tenía 22 opiniones. ;-) WhatamIdoing ( discusión ) 22:23 27 sep 2024 (UTC) [ responder ]

  Todas las páginas ya están protegidas contra el traslado en el nivel semiautomático . Para trasladarlas se necesita una cuenta (auto)confirmada. SilverLocust  💬 07:17, 5 de octubre de 2024 (UTC) [ responder ]

• En mi opinión, la redacción de borradores nunca debería utilizarse para temas que aprueben la GNG, y solo debería ser estándar para cosas como películas, series de televisión y juegos que están en proceso pero que aún no han comenzado la producción. Los temas con una importancia discutible deberían enviarse a la AFD para que se pueda resolver el problema. ★Trekker ( discusión ) 13:00, 26 de septiembre de 2024 (UTC) [ responder ]

  Los temas que pasan la prueba WP:GNG nunca deberían ser incluidos en la lista de borradores, sino que deberían ser etiquetados y tratados mediante los procedimientos normales de la comunidad. Estoy de acuerdo en que las películas, las series de televisión, los juegos y los eventos políticos probablemente sean los más adecuados para la lista de borradores, pero también lo son los artículos potencialmente notables pero poco desarrollados. Sohom ( discusión ) 13:33 26 sep 2024 (UTC) [ responder ]

  Esto no se corresponde con la forma actual de Wikipedia:DRAFTIFY y, de todos modos, no creo que tenga sentido. Los artículos que no pasan la prueba GNG no deberían ser borradores, sino que deberían ser aprobados por AfD. Las películas, etc., que están en proceso no deberían ser borradores simplemente porque no están en producción, y no es realmente un gran uso para el espacio de borrador porque no hay garantía de que haya un cambio de situación que establezca la notoriedad dentro de los 6 meses. Los artículos deberían ser borradores solo si el revisor cree que el artículo puede ser editado hasta un estado aceptable dentro del plazo establecido. Esto implica un pase de prueba GNG, es decir, la creencia de que potencialmente existen fuentes confiables. Recuerde que GNG se trata del *tema*, no del estado del artículo. Fangz ( discusión ) 14:09, 26 de septiembre de 2024 (UTC) [ responder ]

  En mi opinión, el uso correcto de la redacción de borradores es una especie de versión alternativa de la plantilla WIP. Un reconocimiento de que el artículo no está listo y que se debería seguir trabajando en él y que probablemente tendrá múltiples problemas, pero en un entorno protegido y aislado para evitar una moderación excesivamente celosa y la promoción de malentendidos para los lectores ocasionales, y sin dar a entender que el editor original es el que está trabajando en él. Para los nuevos usuarios, debería ofrecer un proceso menos formal y menos jergístico para aprender a mejorar un artículo que los métodos basados ​​en etiquetas, porque este último tiene que equilibrar la necesidad de informar a los *lectores* así como a los editores. Fangz ( discusión ) 14:23, 26 de septiembre de 2024 (UTC) [ responder ]

  Si evalúa que un artículo pasa la prueba WP:GNG , entonces no tiene sentido redactarlo, puede simplemente agregar una plantilla {{ sources exist }} , revisar y continuar. Alternativamente, si evalúa que un artículo no pasa la prueba WP:GNG , no tiene sentido perder el tiempo del creador del artículo y debe WP:AFD /PROD.

  El único caso en el que redactarías un artículo sería si vieras un artículo que a) tuviera una pretensión creíble de importancia/notabilidad b) no cumpliera/demuestre que es notabilidad en su estado actual c) hubiera sido creado en la última semana o algo así por un creador de artículos sin experiencia. Sohom ( discusión ) 14:43 26 sep 2024 (UTC) [ responder ]

  No estoy seguro de si estamos en desacuerdo o tenemos algún problema semántico sobre lo que significa "pasa GNG".

  Pero de todos modos, hay cuestiones que van más allá de la notoriedad, en mi opinión, eso es probablemente más útil. Fangz ( discusión ) 15:08 26 sep 2024 (UTC) [ responder ]

  Si hay posibilidades creíbles de que un artículo se conserve o se fusione en AfD, no debería redactarse.

  Si un artículo definitivamente no es aprobado por AfD y no hay edición que pueda solucionarlo, debe enviarse a AfD. Thryduulf ( discusión ) 15:57 26 sep 2024 (UTC) [ responder ]

  Creo que entonces estás argumentando que el proceso de elaboración de borradores debería eliminarse por completo, y no estoy de acuerdo con eso. Tiene sus ventajas. No debería convertirse en un proceso obligatorio de ninguna manera, pero así como algunos usuarios prefieren trabajar en artículos como borrador y luego subirlos a la wiki pública, puede ser una mejor resolución para ciertos problemas que las alternativas. Fangz ( discusión ) 17:44, 26 de septiembre de 2024 (UTC) [ responder ]

  No estoy seguro de que el espacio de nombres Draft: tenga alguna ventaja sobre un entorno aislado de usuario, y los procesos y la productividad de creación de artículos de m:Research:Wikipedia y m:Research:AfC indican que el espacio de nombres Draft: es donde los artículos van a morir.

  Creo que hemos caído en una falsa dicotomía. Las opciones no son "basura en el espacio principal" frente a "eliminación automática como en el espacio de borradores". Hay otras opciones (por ejemplo, avisos fijos para artículos no citados, userificación, negritas, fusión de negritas, desarrollo de un estándar más consistente y predecible para evaluar artículos, etc.). WhatamIdoing ( discusión ) 20:20 26 sep 2024 (UTC) [ responder ]

  Creo que se puede argumentar que este panorama podría haber cambiado bastante desde que se realizó esta investigación. Los últimos datos que estos proyectos consideran son de 2014 a 2017. WP:ACTRIAL se produjo después de que se realizó esa investigación, y las políticas de Wikipedia han cambiado desde entonces. Sohom ( discusión ) 20:48 26 sep 2024 (UTC) [ responder ]

  Es posible que las cosas hayan cambiado, y yo nunca rechazo un nuevo proyecto de investigación si te ofreces a hacerlo (creo que todos los datos necesarios son públicos), pero si observamos la tasa general de eliminación en ese espacio de nombres, parece poco probable que el resultado sea materialmente diferente. WhatamIdoing ( discusión ) 20:31 27 sep 2024 (UTC) [ responder ]

  Creo que entonces estás argumentando que el proceso de draftificación debería eliminarse por completo, y no estoy de acuerdo con eso. Lamento meterme contigo, pero este es el ejemplo más claro hasta ahora del razonamiento circular que nos ha metido en este lío: la draftificación debe ser buena porque lo hacemos, así que debemos seguir haciéndolo porque es bueno. Literalmente, desde el momento en que se creó el espacio de borradores y la gente comenzó a hacer esto (antes de eso, el proceso equivalente de userfication estaba expresamente prohibido sin discusión previa), otros han estado señalando que la lógica subyacente no tiene sentido. La draftificación es solo para artículos que no deben eliminarse, pero también es solo para artículos que no pueden estar en el espacio principal. Pero como arreglar el contenido bueno en su lugar es parte de la política de edición y casi todas las razones aceptadas por la comunidad para la eliminación involucran el potencial del artículo, no su estado actual, la intersección de esos dos conjuntos es funcionalmente cero (aparte de algunos casos extremos establecidos por consenso como creaciones pagadas o películas próximas a estrenarse).

  Por eso los intentos de aclarar y mejorar las políticas en torno a la elaboración de borradores (y he estado muy involucrado en muchos de ellos) siguen fracasando. Se intenta encontrar una base sólida para las directrices y simplemente no la hay. Realmente tenemos que dejar de intentar cuadrar el círculo de justificar la elaboración de borradores tal como se practica ahora y empezar a preguntarnos qué queremos conseguir realmente la comunidad con ella y si lo que estamos haciendo ahora cumple ese objetivo. Hasta ahora, la situación no pinta bien para el bando de los que dicen que hay que enviarlos a todos al espacio de borradores y el dios de la notabilidad reconocerá a los suyos, porque no hay ni una pizca de evidencia de que ayude a mejorar el contenido, retener a los editores o gestionar la carga de trabajo de la NPP, y como dice WAID por encima de los estudios empíricos que hemos realizado, hemos concluido exactamente lo contrario. Pero ese panorama podría cambiar con más investigaciones: ¡alguien solo tiene que dar un paso adelante y hacerlo! –  Joe  ( discusión ) 07:01, 27 de septiembre de 2024 (UTC) [ responder ]

  @ Joe Roe Draftification es solo para artículos que no deberían eliminarse, pero también es solo para artículos que no pueden estar en el espacio principal. Esa es la razón exacta por la que existe draftspace en primer lugar. Imagina que ves un artículo con el siguiente contenido: Nicholas Carlini es un investigador increíble en Google que trabaja en aprendizaje automático adversarial . creado en la última semana o así y proveniente de la página web personal de una persona. Al hacer una búsqueda rápida en Google, ves que la persona existe y es un investigador en dicha empresa, sin embargo, debido a tu falta de familiaridad con el área temática de aprendizaje automático adversarial, no puedes identificar inmediatamente el impacto de la persona en el campo. ¿1) Nominas el artículo para su eliminación mediante WP:BITEly 2) dejas el contenido para que alguien se ocupe de él (y esperas que la otra persona no elija la opción 1) o 3) redactas el artículo con una nota que indique que se requieren más fuentes para demostrar su notoriedad? Sohom ( discusión ) 11:25, 27 de septiembre de 2024 (UTC) [ respuesta ]

  @ Sohom Datta Ninguno de ellos. Lo que haces es agregar una plantilla al artículo indicando la falta de fuentes, dejar un mensaje amistoso en la página de discusión del creador explicando los problemas en un lenguaje sencillo y dejar una nota al respecto en Wikipedia talk:WikiProject Computer science . Dependiendo de lo que hayas encontrado en tu investigación, podrías agregar más información, agregar algunas fuentes que podrían o no demostrar notabilidad, eliminar los términos pavo real, etc. Sí, esto requiere más esfuerzo que redactar a ciegas o hacer AfDing, pero es mucho más importante que las cosas se hagan bien que que se hagan rápidamente. Thryduulf ( discusión ) 12:37, 27 de septiembre de 2024 (UTC) [ responder ]

  @ Sohom Datta , gracias por crear a Nicholas Carlini , cuya primera versión no contiene la oración hipotética que mencionaste en tu comentario anterior. En tu ejemplo anterior, ¿por qué no puede permanecer en el espacio principal? Francamente, no me encanta, y eliminaría inmediatamente la palabra "increíble", pero ¿cuál es la base política para decir "ese artículo realmente no puede estar en el espacio principal"? WhatamIdoing ( discusión ) 21:10, 27 de septiembre de 2024 (UTC) [ responder ]

  @ Fangz No estoy defendiendo la eliminación del espacio de borradores, tiene sus usos como un espacio opcional donde los artículos se pueden desarrollar con el tiempo para que no tengan que cumplir con todas las políticas de contenido relevantes desde la primera edición. Tampoco estoy defendiendo la eliminación de toda la redacción de borradores, solo la mayoría de la redacción unilateral porque, como Joe ha dicho mejor que yo, no es un beneficio neto para el proyecto tal como se practica actualmente. Thryduulf ( discusión ) 12:46, 27 de septiembre de 2024 (UTC) [ responder ]

  Existe un punto intermedio entre los artículos que cumplen con la revisión de GNG y los que no cumplen con la revisión de GNG: artículos creados recientemente en los que las fuentes del artículo no validan GNG, pero en los que el revisor de la nueva página no ha realizado una búsqueda ANTES. Creo que es perfectamente justo (y está permitido dentro del proceso de redacción actual) decir "este artículo creado recientemente aún no demuestra GNG, pero se lo devolveré al creador en forma de borrador para que incluya más fuentes". Dclemens1971 ( discusión ) 04:43 29 sep 2024 (UTC) [ responder ]

  Enviarlo a draftspace sin hacer un ANTES es definitivamente algo que no deberíamos tolerar. Thryduulf ( discusión ) 10:21 29 sep 2024 (UTC) [ responder ]

  Esto significaría que o bien dejaríamos estos artículos sin supervisar (lo que obviamente no es deseable), o bien daríamos a los nuevos supervisores de páginas la tarea de encontrar fuentes en cada artículo en el que el autor original no las haya encontrado, lo que sería ideal en condiciones ideales, pero pone la carga de buscar las fuentes de la enciclopedia en un grupo muy pequeño de editores. En mi opinión, debería haber una manera de pedirle al autor original que agregue fuentes para demostrar que cumple con GNG, más allá de simplemente poner una etiqueta de "notabilidad" y listo. Chaotic Enby ( discusión · contribuciones ) 19:53, 1 de octubre de 2024 (UTC) [ responder ]

  Estoy de acuerdo con Chaotic Enby. La redacción es una buena solución porque alienta fuertemente al autor a mejorar el artículo y, lo más importante, lo saca del espacio principal para que no sea un problema para los lectores inocentes, sin obligar a los NPPers a limpiar los desastres de otras personas. Cremastra ( discusión ) 20:06 1 octubre 2024 (UTC) [ responder ]

  Drafticiation [...] alienta encarecidamente al autor a mejorar el artículo . Esa es la teoría, pero la evidencia es que en la práctica rara vez lo hace. También hay poca o ninguna evidencia de que la mayoría de las páginas movidas al espacio de borradores sean en realidad un problema para los lectores inocentes en lugar de ser un problema para aquellos que quieren la perfección inmediata. Thryduulf ( discusión ) 20:47 1 octubre 2024 (UTC) [ responder ]

  En cuanto a pedirle al autor original que agregue fuentes para demostrar que cumple con GNG, más allá de simplemente poner una etiqueta de "notabilidad" y listo , me pregunto si realmente es posible hacerlo de una manera no coercitiva. Las opciones en este momento son:

  • Simplemente pregunte (qué hace la etiqueta {{ notability }} ).
  • Preguntar bajo amenaza de eliminación ( WP:BLPPROD y WP:PROD ).
  • Mover el artículo a Borrador: espacio (básicamente, mantiene el artículo como rehén y lo eliminará si usted se da por vencido o no sabe cómo hacerlo).
  • Envíe a AFD hoy.

  Por lo que sé, un método para la opción de "obligar a otro WP:VOLUNTEER a mejorar el artículo según mis estándares" ha resultado bastante difícil de alcanzar. Pero si quieres llegar a ese punto, te sugiero que des un pequeño paso hacia ello en forma de conseguir una política (cualquier política, en realidad) que diga de manera directa e inequívoca que cada artículo debe citar al menos una fuente. Hasta que la comunidad esté de acuerdo en que esto es realmente un requisito, no tenemos ninguna esperanza de conseguir que aumenten el requisito hasta "mostrar que cumple con GNG". WhatamIdoing ( discusión ) 00:20 2 oct 2024 (UTC) [ responder ]

Si un nuevo editor cree que su artículo está listo para el espacio principal, lo colocará allí. También estará encantado de revertir la decisión. Si un nuevo editor no está seguro, probablemente pedirá ayuda primero o utilizará el espacio de borradores. Cremastra ( discusión ) 19:35 26 sep 2024 (UTC) [ responder ]

Creo que la preocupación expresada por Joe y otros que apoyan la teoría de la "puerta trasera" es que los nuevos usuarios no saben cómo revertir el traslado al espacio de borradores. ¿No estás de acuerdo con esa suposición? Toadspike [Discusión] 19:53, 26 de septiembre de 2024 (UTC) [ responder ]

Creo que la mayoría de los usuarios no saben cómo revertir el cambio, sí. También creo que no deberíamos entregárselo en bandeja de plata, porque eso probablemente anule en gran medida el objetivo de la draftificación. ¿Cuál es la solución a esto? No podría decirte. Cremastra ( discusión ) 20:09 26 sep 2024 (UTC) [ responder ]

¿El objetivo de la elaboración de borradores es hacer que mi visión del valor del tema sea más poderosa que la de los novatos? La seguridad a través de la oscuridad funciona para eso, pero no de manera confiable. WhatamIdoing ( discusión ) 20:22 26 sep 2024 (UTC) [ responder ]

Tal vez no sepan cómo hacerlo, pero lo que es más importante, no saben que se les permite hacerlo. Tenemos que recordar lo inusual que es nuestro proceso colaborativo . Si un editor inexperto contribuye con un artículo a Wikipedia y luego lo despublican rápidamente con un mensaje que dice que hay algo incorrecto en él, no pensarán: "Hmm, no estoy seguro de estar de acuerdo con eso, voy a revertirlo y/o discutirlo con mis colegas editores para encontrar un consenso". Pensarán que alguien con la autoridad para decidir qué sucede con los artículos ha rechazado mi contribución y que soy un simple novato. En ese punto, o bien se darán por vencidos (la mayoría) o perseverarán y entrarán en un ciclo de intentar satisfacer primero al revisor de NPP y luego a una sucesión de revisores de AfC hasta que finalmente se rindan o logren escribir una GA, que parece ser aproximadamente el estándar que AfC está aplicando estos días. Incluso los editores con mucha experiencia caen en esta trampa porque, aunque los mensajes con plantillas intentan comunicar la gama completa de opciones que tiene el usuario (ahora al menos, después de que yo y otros hemos pasado varios años luchando por ello), es realmente difícil comunicar que todos somos iguales y todos tenemos voz aquí dentro de una estructura de borrador-revisión que implícitamente eleva las opiniones de los revisores sobre los demás. –  Joe  ( discusión ) 07:31, 27 de septiembre de 2024 (UTC) [ responder ]

He extraído los 10 artículos más recientes que se trasladaron al espacio principal con el script AFCH. Son los siguientes:

• 607th Air Control Squadron – 80 palabras según Wikipedia:Prosesize , 2 referencias: Stub según mw:Calificación de calidad del artículo ORES.
• Will Putnam – 296 palabras, 15 referencias: Inicio.
• Escudo de armas de Saskatoon – 380 palabras, 4 referencias: Inicio.
• Realismo urbano – 304 palabras, 4 referencias: Inicio.
• Devara: Parte 1 (banda sonora) – 547 palabras, 29 referencias: clase C.
• Honra a tu padre y a tu madre: La verdadera historia de los asesinatos de Menéndez – 562 palabras, 8 referencias: clase C.
• XP-21279 – 200 palabras, 11 referencias: Inicio.
• Sistema de aborto de lanzamiento de Crew Dragon – 641 palabras, 23 referencias: Clase B.
• Vince Zampella – 536 palabras, 18 referencias: clase C.
• Jeffrey Kahn – 179 palabras, 14 referencias: Comienza la clase.

Eso es un promedio de 372,5 palabras y 12,6 referencias. El artículo promedio tiene 338 palabras y 4 referencias. En comparación con los artículos existentes, el 53 % de nuestros artículos existentes tienen menos de 372,5 palabras y el 83 % tiene menos de 12,6 referencias. Uno de cada seis artículos tiene menos palabras que el más corto de esta lista. Uno de cada tres artículos es más corto que el segundo más corto de esta lista.

Creo que estos números dejan claro que la AFC espera más referencias que las que se encuentran en la práctica comunitaria actual, y que están tratando de aceptar solo artículos que sean tan largos como aquellos en los que los editores han estado trabajando en el espacio principal durante años.

Por cierto, durante el mismo período de tiempo, se eliminaron más de 100 páginas del espacio de nombres Draft:. No deberías asumir que esto significa que se eliminan más del 90% de los borradores, porque las eliminaciones son intermitentes y este es un tamaño de muestra relativamente pequeño, pero eso es más o menos lo que esperaba. WhatamIdoing ( discusión ) 20:56 27 sep 2024 (UTC) [ responder ]

• Una conclusión: Lamentablemente, no me sorprende el estado actual de esta discusión. Algunos de los acalorados argumentos fuera de tema rayan en la NADA . Me desilusiona mucho ver esto por parte de editores experimentados. A aquellos de ustedes que simplemente comentaron sobre la propuesta: los aprecio mucho.

Dado que la plantilla de borrador predeterminada del NPP se cambió a Template:Draft article un día antes de que comenzara esta discusión, creo que mi propuesta es discutible. No veo cómo podríamos mejorar mucho esa plantilla, pero puedo plantear algunos cambios menores de redacción en la Template Talk. Si alguien quiere cerrar esta discusión, está bien; si otros desean continuar discutiendo otras cosas aquí, les deseo lo mejor. Toadspike [Discusión] 21:16 27 sep 2024 (UTC) [ responder ]

También vale la pena hablar de la notificación de usertalk que deja MTD, que solo ofrece una opción: enviar para revisión. En principio, estamos de acuerdo en que no deberíamos engañar a la gente para que piense que la redacción de borradores o la revisión de contenido son obligatorias para un creador de artículos típico.Las rododendritas ^hablan\\ 13:29, 28 de septiembre de 2024 (UTC) [ responder ]

• Fuerte oposición Lo único que conseguirá es destruir el sistema de borradores tal como está y, en última instancia, destruir Wikipedia. Esto casi ocurrió entre 2008 y 2012, antes de que el proceso de borradores estuviera disponible, cuando Wikipedia se vio inundada de editores pagos/coi y no había un sistema efectivo para lidiar con ellos. ¿La gente no entiende qué es la draftificación? Cada editor tiene un proceso de borradores. NO es una vía para la eliminación. Eso es lo que dicen los detractores del sistema, muchos de los cuales reciben pagos para oponerse a él y destruirlo. Es una de las principales salvaguardas que tenemos contra la destrucción completa de Wikipedia. scope_creep ^Talk 11:46, 29 de septiembre de 2024 (UTC) [ responder ]

  Ese comentario es casi en su totalidad una suposición de mala fe sin pruebas. Por favor, trate de participar en la discusión en lugar de oponerse de manera impulsiva a cambiar el status quo porque eso cambiaría el status quo. Thryduulf ( discusión ) 12:56 29 sep 2024 (UTC) [ responder ]

  No está libre de pruebas y me molesta el hecho de que hayas dicho mi comentario de mala fe. ¿Por qué haría el comentario si no supiera de qué estaba hablando? He trabajado en NPP/AFC desde que se creó y participé en algunas de las primeras discusiones. Sé exactamente cómo se comportan los editores pagos de UPE. Llevaría a un éxodo de editores después de que el lugar se inundara de anuncios. Sería una batalla campal. La realidad es que el editor que publicó no lo ha pensado bien y no ha buscado en los archivos para ver cómo era la situación en ese momento. scope_creep ^Talk 16:05, 29 de septiembre de 2024 (UTC) [ responder ]

  "Créeme, yo estuve allí" no es una prueba. Tu comentario presupone la mala fe de quienes no están de acuerdo contigo y de todos los que envían nuevos artículos. No todos los editores reciben un pago (y la edición pagada revelada está explícitamente permitida), no todas las ediciones pagadas (reveladas o no) son malas, no todos los editores pagados (revelados o no) intentan dañar la enciclopedia, no todas las ediciones pagadas (incluso las no reveladas) dañan la enciclopedia. Thryduulf ( discusión ) 16:19 29 sep 2024 (UTC) [ responder ]

  Eso es cierto hasta cierto punto, pero la mayoría de los editores que crean artículos biográficos, organizativos y de productos modernos, que constituyen la mayoría, son editores pagos no declarados. No tienen nuestros mejores intereses en el corazón y nunca lo han tenido. scope_creep ^Talk 16:53, 29 de septiembre de 2024 (UTC) [ responder ]

  Incluso si eso es cierto (y no has aportado ninguna prueba, ni de tu afirmación ni de las implicaciones de la misma, de que estos artículos dañan a Wikipedia y/o de que la redacción tal como se implementa y practica actualmente previene ese daño), eso no significa que la redacción tal como se implementa actualmente no pueda mejorarse y que cualquier cambio en el status quo signifique la muerte de Wikipedia. Thryduulf ( discusión ) 17:02 29 sep 2024 (UTC) [ responder ]

  @ Scope creep , ¿qué porcentaje de artículos en el espacio de borradores crees que se eliminan? WhatamIdoing ( discusión ) 18:51, 29 de septiembre de 2024 (UTC) [ responder ]

  Si se eliminan borradores, es porque sus creadores los han abandonado. Eso es lo que es G13. Tal vez se debería dedicar más esfuerzo a alentar a los escritores de artículos a mejorar sus artículos después de que se hayan movido a borrador (donde se pueden mejorar sin interferencias), pero la "borrificación" no es una eliminación deliberada y maliciosa por la puerta trasera, y me molesta que se la caracterice como tal. Cremastra ( discusión ) 19:47, 29 de septiembre de 2024 (UTC) [ responder ]

  ¿Es esta una pregunta con doble filo ? El comentario al que estás respondiendo solo decía "ruta de eliminación", y lo has dividido en cuatro partes independientes:

  • adrede
  • malicioso
  • Puerta trasera
  • supresión.

  Personalmente, no caracterizaría a ninguno de ellos como malicioso, pero creo que una fracción de ellos son deliberados. En mi opinión, afirmar que nadie ha enviado nunca a un sujeto en situación límite a la AFC en lugar de a la AFD (que tiene estándares más bajos en la práctica) sería bastante extraordinario. Francamente, no creo que todos seamos tan estúpidos como para no poder averiguar qué ruta es la que tiene más probabilidades de terminar con el resultado que preferimos.

  Si caracterizamos a la AFD como la "puerta principal" para la eliminación, entonces parece justo describir el hecho de dejar que los artículos caduquen en el espacio Draft: como la "puerta trasera".

  Pero el comentario original es simplemente que no es una vía para la eliminación. Pero si el 90-95% de los artículos que se colocan en esa vía terminan siendo eliminados, ¿no es básicamente justo decir que es una de nuestras vías para la eliminación? WhatamIdoing ( discusión ) 20:22 29 sep 2024 (UTC) [ responder ]

• Oponerse . La redacción actual de la etiqueta deja en claro a cualquiera con un poco de sentido común que el artículo tiene potencial, pero en su forma actual no está listo para el espacio principal. Algunos de los comentarios aquí de la gente indican claramente una falta de comprensión de para qué sirve el proceso de borrador. Si un artículo, en su forma actual, pasa GNG, entonces solo hay ciertas circunstancias en las que debería ser borrador (por ejemplo, edición paga), pero si un artículo probablemente pasaría GNG, pero no lo hace en su forma actual (por ejemplo, no hay suficientes fuentes en profundidad de fuentes independientes y confiables para cumplir con el estándar), entonces eso es un ejemplo de borrador. Cuando era más activo en la revisión de artículos, creé varias respuestas personalizadas, que tomaban el mensaje estándar y lo modificaban un poco dependiendo del motivo de la borradorización (por ejemplo, UPE, falta de GNG) o un tema específico (por ejemplo, NFOOTY, lugares poblados). En algunos casos, esos mensajes contenían una oferta para avisarme directamente cuando sintieran que el artículo estaba listo para el espacio principal. Estoy totalmente a favor de la creación de artículos, pero también me preocupa la calidad y la reputación de Wikipedia, que a menudo se considera el chiste de los chistes sobre información basura en Internet. Y estoy completamente en desacuerdo con aquellos que dicen que la creación de borradores no es un beneficio neto. De hecho, creo que es una de las herramientas más útiles para ayudar a mejorar la calidad en WP. ¿Se usa siempre correctamente? No. Pero ese es un problema de educación con los usuarios individuales, no un problema primordial con el proceso en sí. Onel 5969 ^{TT me} 14:34, 29 de septiembre de 2024 (UTC) [ responder ]

  Estoy de acuerdo con Onel5969. (Pero recuerda también no dejar votos, ya que este es un laboratorio de ideas, no una propuesta formal). Cremastra ( discusión ) 14:36 ​​29 sep 2024 (UTC) [ responder ]

  Disculpas, Cremastra. Onel 5969 ^{TT me} 19:38, 29 de septiembre de 2024 (UTC) [ respuesta ]

  Eso podría estar bien en teoría, pero no coincide con lo que está sucediendo en la práctica. Especialmente considerando que los artículos se están moviendo a draftspace por no ser de la calidad suficiente para ser de clase C o incluso B. Si un artículo está escrito de manera neutral y cumple con los GNG, entonces no hay justificación para moverlo a draftspace solo porque alguien podría (o no) haber recibido un pago por editarlo. Thryduulf ( discusión ) 15:21, 29 de septiembre de 2024 (UTC) [ responder ]

  @ Thryduulf : ¿Tienes un ejemplo específico en mente cuando mencionas artículos de clase C o B? scope_creep ^Talk 16:13, 29 de septiembre de 2024 (UTC) [ responder ]

  Ver el comentario de @WhatamIdoing en esta discusión. Thryduulf ( discusión ) 16:15 29 sep 2024 (UTC) [ responder ]

  Esta lista muestra el estado de los artículos cuando salen del espacio Borrador:. Para los artículos que ingresan al espacio Borrador:, aquí hay una lista actualizada:

  • Borrador: Campos Satélite de Sargodha – 376 palabras, 5 referencias (razón: "se necesitan más fuentes")
  • Borrador: Näsir Zaman – 20 palabras, 10 referencias (razón: "se necesitan más fuentes")
  • Borrador: Ahsan Khalil – 48 palabras, 15 referencias (razón: "se necesitan más fuentes")
  • Borrador: Martin-J. Sepulveda – 232 palabras, 9 referencias (razón: "probable publicidad encubierta")
  • Borrador: Gregory Bortz – 270 palabras, 22 referencias (razón: "probable publicidad encubierta")
  • Borrador: Yury Yuriyovich Shikula – 40 palabras, 3 referencias (en realidad ~150 palabras; motivo: "se necesitan más fuentes")
  • Borrador: Dwight Carlton Harris – 151 palabras, 3 referencias (el autor lo movió por no tener fuentes; el mismo editor agregó las fuentes media hora después)
  • Borrador: Ferrocarriles de Rhodesia, clase 19 : 4 palabras (es una lista), 0 <ref>, pero se mencionan dos fuentes (razón: "sin fuentes, razón personalizada")
  • Borrador: De Zandbak – 107 palabras, 5 referencias (razón: "se necesitan más fuentes")
  • Draft: Kian Breckin (futbolista) – 316 palabras, 15 referencias (movido por el autor sin dar ninguna razón, pero fue eliminado en la AFD el año pasado)

  Me he saltado redirecciones, algunos intercambios de páginas por turnos y un par de editores movieron envíos de AFC del espacio Usuario: al espacio Borrador: e intenté incluir solo artículos que se movieron del espacio principal al espacio Borrador:. No puedo obtener las calificaciones de ORES para estos artículos, pero a simple vista, creo que Start y C-class no es una descripción poco razonable. WhatamIdoing ( discusión ) 19:31 29 sep 2024 (UTC) [ responder ]

  En primer lugar, gracias por proporcionar la lista. El problema es que, al revisar esos borradores, la mayoría son borradores sólidos, y no "especialmente teniendo en cuenta que se están moviendo artículos a la sección de borradores por no ser de la calidad suficiente que son de clase C o incluso B". Aunque creo que se podría haber hecho una explicación más cuidadosa. Por ejemplo, el primero habría sido mejor con un "se necesitan referencias más detalladas de fuentes independientes y confiables", en lugar de decir simplemente "se necesitan más fuentes", ya que no hay una sola referencia detallada de una fuente independiente y confiable en el borrador. El segundo y tercer ejemplo tienen exactamente el mismo problema. El cuarto y quinto ejemplos están etiquetados correctamente como publicidad encubierta (ambos editores han sido bloqueados por ello; además, el cuarto tampoco tenía una sola referencia detallada de una fuente independiente). El sexto ejemplo, si bien tiene 3 fuentes, ninguna es exhaustiva y, si bien puede tratarse de una diferencia ortográfica en las traducciones de la segunda y la tercera referencia, no parece que el tema del artículo se mencione en ninguna de ellas. El séptimo artículo no es un verdadero ejemplo de borradorización, ya que fue movido por el autor. El octavo y el noveno artículo no tienen ninguna fuente confiable independiente (en el caso del noveno, el periódico al que se hace referencia no tiene un número de página y el enlace no parece mencionar nada en profundidad sobre el laboratorio de piratería). No estoy seguro del décimo, ya que la historia es un poco rara, pero, nuevamente, no parece un ejemplo de borradorización.

Creo que esto ilustra algunos de los malentendidos que cometen las personas a las que no les gusta la elaboración de borradores. Observas la lista proporcionada y piensas: "Vaya, muchas referencias, la mayoría no son borradores ni microborradores, ¿por qué diablos se han elaborado?". Yo mismo lo hice, preguntándome si las 10 fueron realizadas por un solo editor, que tal vez no tenía un conocimiento sólido de la elaboración de borradores. Pero luego te sumerges en los méritos de las fuentes o en los problemas de la UPE, y parece que las 8 elaboraciones de borradores parecen justificadas. Onel 5969 ^{TT me} 20:32, 29 de septiembre de 2024 (UTC) [ responder ]

@ Onel5969 , me pregunto si podrías explicar un poco mejor "el periódico" en el artículo 9. Dices que el artículo tiene "cero fuentes independientes confiables", pero los periódicos impresos tradicionales son fuentes independientes confiables. Luego dices que no tiene un número de página, pero el enlace te lleva directamente a una copia escaneada de la página correcta; el artículo citado [título dado en la cita] está en las últimas dos columnas. Nada de eso hace que el periódico sea menos independiente. ¿Te preocupa que el artículo parezca ser anterior al uso del nombre en el título del artículo ("De Zanbak" significa "El arenero")? WhatamIdoing ( discusión ) 20:51 29 sep 2024 (UTC) [ responder ]

Podría ser la traducción, pero no parece haber nada que conecte al grupo mencionado en ese artículo con De Zanbak. Pero incluso si lo hubiera, agf, esa sigue siendo la única fuente independiente y exhaustiva. Onel 5969 ^{TT me} 01:15, 30 de septiembre de 2024 (UTC) [ responder ]

Me alegra que estemos de acuerdo en que un periódico es una fuente independiente. WhatamIdoing ( discusión ) 01:20 30 sep 2024 (UTC) [ responder ]

Si un nuevo editor incluye 5 fuentes en su artículo y lo trasladan a [un lugar que no puse] porque "se necesitan más fuentes" o "no hay fuentes", ¿cuántos de ellos se tomarán el tiempo de aprender que el editor experimentado en realidad quiso decir que ninguna de estas fuentes contiene lo que creo que es una cobertura significativa y profunda en fuentes independientes confiables y luego tendrán la confianza de decir "en realidad, esta persona experimentada con el poder de eliminar mi artículo de Wikipedia está equivocada y yo tengo razón, aprenderé a desafiarlos y cómo y dónde expresar mi punto de vista de una manera que las personas poderosas me escuchen" en lugar de simplemente rendirse en algún punto de ese camino? Y antes de que alguien lo diga, no, el hecho de que algunos editores de mala fe puedan estar entre los disuadidos no justifica la pérdida de editores de buena fe. Thryduulf ( discusión ) 21:29, 29 de septiembre de 2024 (UTC) [ responder ]

Supongo que esa es la diferencia entre los editores a los que les importa la calidad en WP y los que se preocupan por la cantidad. Pero por eso dije que la justificación dada podría haber sido mejor. Onel 5969 ^{TT me} 01:17, 30 de septiembre de 2024 (UTC) [ responder ]

¿Es realmente una cuestión de calidad versus cantidad?

¿O es esta la diferencia entre editores que prefieren ver una página publicada en Wikipedia:Artículos para su eliminación o Wikipedia:Fusiones de artículos propuestas en lugar de ocultarla unilateralmente hasta que se elimine sin el nivel de supervisión de la comunidad que esperamos de la AFD? Por ejemplo, no estoy convencido de que "De Zanbak" sea un tema viable para un artículo, pero creo que hay varias formas de abordar esa preocupación, y no creo que el espacio Borrador: ayude. De hecho, lo único que hace que mover esa página al espacio Borrador: sea diferente a moverla al espacio Usuario: es que es mucho más probable que se elimine durante el próximo año si está en el espacio Borrador: que si está en el espacio Usuario:. WhatamIdoing ( discusión ) 01:26, 30 de septiembre de 2024 (UTC) [ responder ]

Bueno, dado que la redacción de borradores no es una "puerta trasera para borrar", ni es "ocultar un artículo", es definitivamente una cuestión de calidad versus cantidad. La redacción de borradores, en resumen, es una medida de control de calidad. Estos son artículos que pueden ser lo suficientemente notables para el espacio principal, pero simplemente no están en buenas condiciones para estar allí. Pero, como otros vehículos en WP, los editores de buena fe pueden estar en desacuerdo sobre la notoriedad de un artículo, por lo que, por ejemplo, en el artículo de De Zandbak, Jay8g (que lo etiquetó para notoriedad) y Jonathan Deamer (que lo redactó) pueden considerarlo potencialmente notable, mientras que tú, WhatamIdoing, podrías simplemente haberlo enviado a AfD, porque no lo sientes notable. Pero eso no significa que el sistema no esté funcionando. Tal vez podamos ajustar la redacción actual en la plantilla para incluir dónde se pueden agregar recursos sobre dónde un editor puede pedir ayuda (por ejemplo, AFC o Teahouse). Onel 5969 ^{TT me} 09:20, 30 de septiembre de 2024 (UTC) [ respuesta ]

Bueno, dado que la redacción de borradores no es una "puerta trasera para la eliminación" ni tampoco es "ocultar un artículo", dices eso como si no hubiera forma posible de que editores de buena fe pudieran estar en desacuerdo, pero eso simplemente no es cierto. Si alguna de esas cosas es cierta es una cuestión de opinión (y, en mi opinión, una que es consistente con la evidencia presentada). Thryduulf ( discusión ) 10:07 30 sep 2024 (UTC) [ responder ]

Hola. No, los editores pueden tener diferentes interpretaciones y estar en desacuerdo sobre ciertos temas. Sin embargo, en este caso, no se trata de un desacuerdo. Mantener esos puntos de vista indica una falta de comprensión de lo que es el proceso de elaboración de borradores. Eso no es lo que es la elaboración de borradores, es, como he dicho, simplemente una medida de control de calidad. Sería como decir que es una cuestión de opinión si esta persona escribió o no un artículo sobre sí misma, eso puede interpretarse como que no es una edición de COI. O si un artículo simplemente copia y pega la información de la Enciclopedia Británica, no puedes decir que es tu opinión que eso no es una copia. Quiero decir, tengo el máximo respeto por ti, Thryduulf, y haces un gran trabajo en WP. Hay cosas en WP que son subjetivas (por ejemplo, qué constituye exactamente SIGCOV), mientras que otras son objetivas (por ejemplo, la edición de UPE/COI, la copia). Lo que es la elaboración de borradores cae en la última categoría. Dicho todo esto, podemos estar en desacuerdo sobre si un artículo en particular debería o no haber sido redactado. Usted dice que la evidencia presentada muestra que no estaba justificado que esos artículos fueran enviados a redacción. Sin embargo, al revisar las fuentes, parece que la redacción estaba justificada. Esa es una diferencia de opinión. Onel 5969 ^{TT me} 14:20, 30 de septiembre de 2024 (UTC) [ responder ]

En su opinión, mover un artículo al espacio Borrador es simplemente una medida de control de calidad .

En mi opinión, mover un artículo al espacio Borrador: es también simplemente una medida de control de calidad que, comparada con las alternativas disponibles de dejarlo en el espacio principal, enviarlo a AFD o moverlo al espacio Usuario:, disminuye sustancialmente la probabilidad de que se mejore la calidad y aumenta sustancialmente la probabilidad de que el artículo sea eliminado.

Ah, cierto: esos dos últimos puntos ( «disminuye sustancialmente la probabilidad de que se mejore la calidad» y «aumenta sustancialmente la probabilidad de que se elimine el artículo» ) no son «opiniones». Son hechos objetivos. WhatamIdoing ( discusión ) 22:17 30 sep 2024 (UTC) [ responder ]

La clase 19 de Rhodesia Railways no es una lista; es un tren que estuvo en funcionamiento durante varios períodos de tiempo. Incluso si fuera una lista, los encabezados vacíos y el hecho de que solo haya una tabla de contenido no se acercan en nada a la clase inicial, tal vez ni siquiera a un substub. Aaron Liu ( discusión ) 20:47 29 sep 2024 (UTC) [ responder ]

El contenido existente en el artículo es un cuadro de información y una tabla. Las tablas son el formato preferido por Wikipedia:Listas destacadas . Las secciones vacías no están prohibidas y las calificaciones se basan en lo que ya está allí. Lo calificaría como |class=Listhoy. WhatamIdoing ( discusión ) 20:53 29 sep 2024 (UTC) [ responder ]

El único contenido es una tabla . ¿Has leído la página? Ese cuadro de información está lleno de contenido, hay dos fuentes aparentemente confiables y la tabla en sí tiene alrededor de 20 filas de contenido. Thryduulf ( discusión ) 21:33 29 sep 2024 (UTC) [ responder ]

Lo siento, sí, también el cuadro de información. De todas formas, no lo consideraría un comienzo. Aaron Liu ( discusión ) 22:03 29 sep 2024 (UTC) [ responder ]

Esta es solo una idea y quiero trabajarla un poco más, pero creo que sería útil tener cambios pendientes en el nivel de confirmación extendida. Esto podría llamarse "PC2" nuevamente (no confundirse con el PC2 original) o "PCECP". La idea sería ayudar a hacer cumplir WP:ARBECR y restricciones similares donde los usuarios no confirmados por la extensión tienen prohibido el acceso a ciertas áreas temáticas. En este nivel, las ediciones de editores no confirmados por la extensión se retendrían para su revisión, mientras que los usuarios confirmados por la extensión pueden aprobar estas ediciones y, por lo tanto, asumir la responsabilidad en WP:PROXYING .

Creo que sería útil para páginas en las que (1) partes del artículo se cruzan con un tema polémico, o (2) el artículo en su totalidad se cruza con un tema polémico, pero no se edita con frecuencia. Awesome Aasim 16:54, 27 de septiembre de 2024 (UTC) [ responder ]

Parece que esto podría ser útil. Debería restringirse a páginas que se editan con poca frecuencia (probablemente excluyendo todos los artículos de eventos actuales) para no sobrecargar Cambios pendientes cada vez que Reuters publica una nueva historia o estalla una guerra de ediciones. La gran pregunta es: ¿qué problema estás tratando de resolver? Toadspike [Discusión] 20:39, 27 de septiembre de 2024 (UTC) [ responder ]

Existen algunos temas polémicos designados por ArbCom o la comunidad en los que solo se permite la participación de usuarios confirmados. Sin embargo, los administradores se niegan a proteger páginas en las que no hay suficientes interrupciones como para justificar la protección. Sin embargo, se debe tener en cuenta que la restricción XCON se aplica independientemente de si una página está protegida o no.

Lo que haría PCECP es básicamente eliminar los temores de que "no haya suficiente interrupción para justificar la protección" mientras se almacenan en búfer todas las contribuciones no confirmadas por extensión para que tengan que ser aprobadas, de acuerdo con "las no confirmadas por extensión solo pueden realizar solicitudes de edición". Las plantillas que son específicamente para este caso, como {{ edit protected }}, se rompen cuando la página no está protegida. Awesome Aasim 22:00, 27 de septiembre de 2024 (UTC) [ responder ]

El problema es que la regla 500/30 está diseñada específicamente para mantener a los editores más nuevos fuera debido a las cantidades extremas de interrupciones como regla. Hay una buena razón por la que las dos principales guerras candentes del mundo ( el conflicto árabe-israelí y la guerra ruso-ucraniana ) están bajo la regla 500/30. Y, como se ha mencionado repetidamente y vale la pena repetirlo nuevamente, los altos volúmenes de ediciones en un artículo determinado contraindican el bloqueo CRASH.

Pero el mayor obstáculo aquí es que todavía no existe un consenso para un CRASHlock confirmado de forma extendida. La última discusión sobre la expansión de CRASHlock a niveles de protección más altos es anterior a XCP por completo. Tendría que haber una RfC formal para esto, no una mera especulación del vicepresidente. — Jéské Couriano v^_^v ^{hilos críticas} 15:37, 28 de septiembre de 2024 (UTC) [ responder ]

La protección XCON tiene sentido para artículos con mucho tráfico, pero ¿para artículos con poco tráfico? Si la edición es menor, como corregir errores ortográficos o gramaticales, no debería haber ningún problema. De todos modos, corregir la ortografía y la gramática generalmente está fuera de las áreas temáticas polémicas. De WP:ARBECR : En cualquier página donde la restricción no se aplique a través de la protección confirmada extendida, esta restricción puede aplicarse mediante otros métodos, incluido... el uso de cambios pendientes.

Probablemente también establecería filtros de abuso para ver si una página está en una categoría que trata principalmente sobre un tema polémico y luego advertir y etiquetar la edición en cuestión. Awesome Aasim 16:22, 28 de septiembre de 2024 (UTC) [ responder ]

La mayoría de los artículos de CT con poco tráfico no tienen ninguna protección, ya que nunca han sufrido cantidades de vandalismo que la requieran. Las solicitudes de protección que dependen únicamente de la aplicación de arbitraje y de poca o ninguna evidencia de vandalismo son rechazadas. Aaron Liu ( discusión ) 23:26 28 sep 2024 (UTC) [ responder ]

Sí, lo veo, pero el problema es que una edición que no sea de XCON se aprobará en páginas que no estén viendo muchas personas. Los cambios pendientes aún permiten que los usuarios que no sean de XCON realicen estas ediciones, pero sus ediciones deberán ser aprobadas y se pueden revertir si infringen WP:ARBECR . Esto también está en línea con la forma en que se utilizan los cambios pendientes en artículos de poco tráfico para monitorear (no prevenir) las interrupciones. Awesome Aasim 18:26, 29 de septiembre de 2024 (UTC) [ responder ]

@ Aaron Liu La mayoría de los artículos de CT con poco tráfico no tienen ninguna protección, ya que nunca vieron cantidades de vandalismo que requirieran protección. Las solicitudes de protección que dependen únicamente de la aplicación del arbitraje y poca o ninguna evidencia de vandalismo se rechazan. No es cierto, los artículos en temas de ECR pueden y son bloqueados de forma preventiva. Lo que realmente sucede es que los artículos con una interrupción mínima generalmente no se llevan a WP:RFPP ni son detectados por un administrador desobediente. Mach61 19:53, 29 de septiembre de 2024 (UTC) [ responder ]

No es cierto. Los artículos en los temas de ECR pueden bloquearse preventivamente.

¿Podrías añadir un ejemplo? Hay una larga lista de solicitudes de RFPP rechazadas para la ejecución del arbitraje. Aaron Liu ( discusión ) 20:42 29 sep 2024 (UTC) [ responder ]

Vea este intercambio entre un administrador que se negó a brindar protección en base a ECR debido a la falta de interrupciones y un (ex) administrador que les explicó lo contrario. Mach61 19:46, 1 de octubre de 2024 (UTC) [ responder ]

Gracias, ahora entiendo el "puedo". Aaron Liu ( discusión ) 20:59 1 oct 2024 (UTC) [ responder ]

Parece razonable. Siempre me he preguntado por qué los cambios pendientes no se implementan con más frecuencia. Parece una herramienta útil y hay muchos revisores de cambios pendientes, por lo que hay muy poca acumulación de trabajo. Cremastra ( discusión ) 14:18, 28 de septiembre de 2024 (UTC) [ responder ]

Porque hay suficientes personas a las que les desagradan o desconfían de los cambios pendientes, por lo que es difícil llegar a un consenso para utilizarlos. Véase, por ejemplo, Wikipedia:Village pump (propuestas)/Archivo 183#RFC: Pending-changes protection of Today's featured article . Anomie ⚔ 14:41, 28 de septiembre de 2024 (UTC) [ responder ]

Bueno, caray, me pregunto por qué, carajo. — Jéské Couriano v^_^v ^{hilos críticas} 15:39, 28 de septiembre de 2024 (UTC) [ responder ]

¿Te importaría explicarme más sobre tu punto? No lo veo. Anomie ⚔ 17:04, 28 de septiembre de 2024 (UTC) [ responder ]

@ Anomie : Lee la sección "Propuesta" en la página vinculada. El hecho de que exista RfC debería darte una pista de por qué una minoría significativa de editores desconfía tanto de CRASHlock. — Jéské Couriano v^_^v ^{hilos críticas} 18:01, 9 octubre 2024 (UTC) [ responder ]

Todavía no lo veo. La gente supuestamente desconfía de él porque hubo una prueba hace 14 años y los administradores de enwiki no dejaron de usarlo inmediatamente después del período de prueba a la espera de un consenso sobre el futuro de la función. Anomie ⚔ 18:43, 9 de octubre de 2024 (UTC) [ responder ]

¿Conoces el idioma de la nariz del camello ? — Jéské Couriano v^_^v ^{hilos críticas} 18:47, 9 de octubre de 2024 (UTC) [ responder ]

El resumen que saco de esta discusión es que todavía estás resentido porque el consenso no te favoreció hace 12 o 13 años, y suponiendo que cualquiera que se oponga a la corrección política comparta esa razón y ninguna otra. Creo que es poco probable que continuar con esta conversación vaya a llevar a algún lado útil. Anomie ⚔ 18:59, 9 de octubre de 2024 (UTC) [ responder ]

El consenso tampoco funciona así. El consenso puede determinarse mediante una convocatoria de propuestas, sí, pero también puede desarrollarse simplemente por la forma en que se hacen las cosas, independientemente de si se ha discutido formalmente o no.

Pienso en el ejemplo dado por Technology Connections sobre "el peligro de pero a veces". El semáforo LED es superior en ahorro de energía y mucho más, pero a veces se acumula nieve y hielo sobre ellos, por lo que son malos. Del mismo modo, los cambios pendientes de XCON ayudarán con la aplicación de WP:ARBECR , pero a veces los administradores pueden aplicar esto a páginas fuera de la política, por lo que no debería usarse nuevamente. La respuesta correcta sería colocar barandillas de protección en la política para que los administradores no lo hagan. Awesome Aasim 19:00, 9 de octubre de 2024 (UTC) [ responder ]

¿Cómo es posible que una convocatoria de propuestas de hace más de 13 años siga reflejando el consenso actual? Estoy bastante seguro de que, si bien algunas opiniones podrían no haber cambiado, otras definitivamente lo harán. Nadie está diciendo que debería haber cambios pendientes completos. Impresionante Aasim 18:16, 9 de octubre de 2024 (UTC) [ responder ]

@ Awesome Aasim : El RfC se vinculó específicamente para señalar una de las razones de la desconfianza en el sistema de PC. El RfC más reciente sobre CRASHlock , como dije, es anterior a XCP como concepto. — Jéské Couriano v^_^v ^{hilos críticas} 18:20, 9 octubre 2024 (UTC) [ responder ]

Además, explica qué quieres decir con "crashlock". No encuentro ninguna discusión ni entrada en el glosario sobre "crashlock". Genial Aasim 18:21, 9 de octubre de 2024 (UTC) [ responder ]

@ Awesome Aasim : Debería ser MUY obvio a partir del contexto. — Jéské Couriano v^_^v ^{hilos críticas} 18:26, 9 de octubre de 2024 (UTC) [ responder ]

Supongo que quizás seas el único que utiliza esta terminología, ya que no aparece en WP:GLOSSARY ni en ningún otro lugar.

No obstante, este es el Laboratorio de Ideas; es el lugar para desarrollar ideas, no para mostrar una oposición tajante a las ideas. Para eso están los otros foros de discusión; para sondear el consenso. Cabe señalar que WP:ECP se creó originalmente con el propósito de hacer cumplir las decisiones de arbitraje y las sanciones de la comunidad. Nunca estuvo destinado a nada más; simplemente se utilizó para otras cosas de facto . Impresionante Aasim 18:40, 9 de octubre de 2024 (UTC) [ responder ]

( editar conflicto ) Todas esas cosas que crees que son obvias en realidad no lo son. Deberías intentar explicarte mejor en lugar de mover las manos con énfasis ante algo al azar. Anomie ⚔ 18:43, 9 de octubre de 2024 (UTC) [ responder ]

Tal vez sea obvio, pero aún así no tiene mucho sentido. No estoy seguro de cómo el uso de tus propios términos especiales de implicaciones poco claras para menospreciar cosas que no te gustan ayuda a la comunicación o a la comprensión de la comunidad aquí. Cremastra ( discusión ) 19:37 9 oct 2024 (UTC) [ responder ]

No lo entiendo. ¿La gente desconfía de la PC debido a una mala implementación burocrática de un experimento hace más de 10 años? (¿En una burocracia no centralizada donde pasan estupideces todo el tiempo?) La RfC es explícita al decir que no hace ningún juicio normativo sobre la PC, y parece que los votantes de ! tampoco lo están haciendo. SamuelRiv ( discusión ) 18:37 9 oct 2024 (UTC) [ responder ]

Es una de las razones, y probablemente la más importante para algunos (que vieron el mal manejo de la prueba como un intento de imponernos CRASHlock/FlaggedRevisions ). Otra razón es que, desde 2010 hasta 2014, se convocaban RfC de CRASHlock al menos una vez al año , y la mayoría de ellas eran escritas por editores pro-CRASHlock . — Jéské Couriano v^_^v ^{hilos críticas} 18:42, 9 octubre 2024 (UTC) [ responder ]

Bueno, para aquellos que no están interesados ​​en la política de WP, hay un artículo de opinión general del WSP de agosto de 2011 que parece capturar la actitud y las consecuencias. Parece que los resultados del cierre de las RfC dejaron a los administradores en un estado indeterminado en cuanto a si la PC se puede aplicar o eliminar. SamuelRiv ( discusión ) 18:47, 9 de octubre de 2024 (UTC) [ responder ]

En cuanto a si la PC puede aplicarse o eliminarse alguna vez. Cierto en 2011 cuando se escribió eso, pero los RFC posteriores lo resolvieron. Anomie ⚔ 19:02, 9 de octubre de 2024 (UTC) [ responder ]

¿Podrías incluir un enlace a dichas RfC? Todo lo demás que se haya incluido anteriormente se refiere a la página principal. SamuelRiv ( discusión ) 19:56 9 oct 2024 (UTC) [ responder ]

Wikipedia:Pending changes/Request for Comment 2012 estableció un consenso básico para usar PC, con Wikipedia:PC2012/RfC 2 y Wikipedia:PC2012/RfC 3 aclarando algunos detalles. El nivel 2 de PC , por otro lado, nunca obtuvo consenso para su uso y finalmente en 2017 hubo consenso para eliminarlo de la configuración. Plantilla:Pending changes discussions tiene muchos enlaces. Anomie ⚔ 22:14, 9 de octubre de 2024 (UTC) [ responder ]

Vale la pena señalar que, hasta donde yo sé, la RfC de 2017 es la última sobre cualquier aspecto de CRASHlock. Como dije anteriormente, sería necesario que haya una nueva RfC para obtener un consenso sobre CRASHlock con confirmación extendida, ya que PC2 originalmente era de nivel de protección total y no se hizo ninguna pregunta sobre ECP!CRASHlock en las RfC de 2016 , ninguna de las cuales fue particularmente exhaustiva. (La última RfC exhaustiva fue la de 2014 ). — Jéské Couriano v^_^v ^{hilos críticas} 06:47, 10 de octubre de 2024 (UTC) [ responder ]

Creo que las principales razones por las que los editores no quieren ampliar el uso de los cambios pendientes son prácticas: no hay soporte técnico para correcciones (o desarrollo de características adicionales) en el horizonte, a pesar de los errores documentados; y hay incertidumbre en la capacidad de la comunidad para gestionar un uso ampliado. Sin duda, hay editores que se muestran cautelosos debido a la historia pasada, pero esto ya ha sido un factor en otras decisiones y, en consecuencia, se han visto influenciados para ser más definitivos sobre cómo procederán los ensayos. isaacl ( discusión ) 18:55, 9 de octubre de 2024 (UTC) [ responder ]

Bien, como ya puedes ver arriba, hay mucha historia aquí y nadie ha llegado a discutir la pequeña desventura de Phillipe todavía. A pesar de todo eso, creo que la idea general aquí es sólida. Y como estamos discutiendo la historia, vale la pena señalar que, en la práctica, esto en realidad se acerca más a lo que la restricción de la CE pretendía hacer en su primera encarnación, donde funcionaba como una versión más suave de 1RR originalmente aplicada como un remedio AE a medida en un artículo específico: las reversiones de cuentas no calificadas no contaban para 1RR .

Los tiempos han cambiado, ahora el ECR tiende a implementarse en el espacio principal junto con el ECP y se aplica de manera mucho más amplia de lo que cualquiera de entonces hubiera imaginado, para bien o para mal.

El mejor caso de uso aquí es para páginas tranquilas donde el historial de edición no EC es en gran medida uno de correcciones y mejoras menores no polémicas, pero que han llamado la atención debido a ediciones polémicas esporádicas, donde puede ofrecer un camino intermedio entre dejar la aplicación a las reversiones posteriores a la edición y prevenir toda edición no EC.

En la práctica, las limitaciones de la extensión hacen que solo funcione bien en páginas con poco tráfico y, siendo realistas, no se prevén mejoras en la extensión en un futuro próximo. Por lo tanto, el caso de uso (2) tiene sentido, pero el (1) es más difícil de vender. Puede que no sea un caso de uso lo suficientemente bueno como para justificar la molestia. Personalmente, tendría que investigar un poco y pensar un poco sobre esto, pero la idea básica es sólida.

Disculpas por la respuesta escrita apresuradamente, tengo un poco de prisa; espero que haya habido algo útil allí. 184.152.68.190 ( discusión ) 16:06, 22 de octubre de 2024 (UTC) [ responder ]

Una RfC de varias partes que pregunta cómo se debe aplicar el ECR para las páginas existentes, incluso en función de la actividad. Las páginas con mucho tráfico necesitarán protección extendida de forma retroactiva, ya que tienden a sufrir la mayor cantidad de interrupciones debido a las violaciones del ECR. Las páginas con poco tráfico, no tanto, pero podemos usar filtros de abuso y cambios pendientes del ECP del taller para esto. Las correcciones de ortografía y gramática, hasta donde yo sé, están excluidas de WP:ARBECR . Awesome Aasim 19:52, 1 de octubre de 2024 (UTC) [ responder ]

Considero que el ECR en el área de PIA es absoluto (no se permite la edición por parte de aquellos que no cumplen con el requisito 500/30), por lo que CRASHlock quedaría descartado en cualquier caso. No estoy seguro de si esto también se aplica a WP:GS/RUSUKR (que cae dentro del área de EE). — Jéské Couriano v^_^v ^{hilos críticas} 18:57, 9 octubre 2024 (UTC) [ responder ]

A continuación se incluye un texto inicial que quizás sirva para empezar:

• ¿Cuál es la mejor manera de aplicar WP:ARBECR en los artículos?
  • Opción 1: Protección preventiva XCON
  • Opción 2: XCON preventivo pendiente de cambios
  • Opción 3: Editar filtros
  • ¿algo más?

Probablemente esto esté incompleto. ¿Alguien más tiene ideas para esta propuesta? Impresionante Aasim 19:41, 16 de octubre de 2024 (UTC) [ responder ]

Yo diría que eliminen "preemptive", ya que a veces se coloca solo en respuesta a la actividad disruptiva de los no EC. Aaron Liu ( discusión ) 11:31 17 oct 2024 (UTC) [ responder ]

¿Debería entonces ser también una opción la reactivación? Impresionante Aasim 17:32, 17 de octubre de 2024 (UTC) [ responder ]

Creo que sí. Eso es lo que apoyo. Cremastra — discusión — c 19:29, 17 de octubre de 2024 (UTC) [ responder ]

¿Entonces deberíamos tenerlo así?:

• ¿Cuál es la mejor manera de aplicar WP:ARBECR en los artículos? Califique si estas opciones deberían ser preventivas, reactivas o no utilizarse.
  • Opción 1: Protección XCON
  • Opción 2: XCON pendientes de cambios
  • Opción 3: Editar filtros/Revertir filtros
  • ¿algo más?

Impresionante Aasim 19:39 17 octubre 2024 (UTC) [ responder ]

Seguro. Cremastra — discusión — c 19:42 17 oct 2024 (UTC) [ responder ]

¿Deberían incluirse enlaces en los artículos sobre años en temas? Por ejemplo, el primer enlace de The Little Girl Lost es a 1794 en poesía . El enlace parece una violación de Wikipedia:OLINK , pero no se indica específicamente. Los enlaces a solo años ya desaparecieron, pero ¿por qué no se eliminan activamente los que tratan sobre temas? Roasted ( discusión ) 22:56, 28 de septiembre de 2024 (UTC) [ responder ]

Todo empezó en un año, y vincular ese año a un artículo sobre un montón de información irrelevante no es de ayuda. Pero en un artículo sobre un poema escrito en 1794, es bastante razonable vincular a un artículo sobre otras cosas muy relacionadas de ese año. Esa no es una regla, pero es una visión defendible, particularmente para poemas de hace 230 años, donde es un milagro que tengamos algún registro del poema. Johnuniq ( discusión ) 01:04 29 sep 2024 (UTC) [ responder ]

Creo que es una visión defendible, en especial para los temas que se analizan o enlazan en el artículo. Es similar a nuestro principio WP:BIDIRECTIONAL para los cuadros de navegación: si puedes llegar desde 1794 en poesía hasta La niña perdida , entonces sería ideal que pudieras regresar.

Creo que es más defendible para temas más breves y específicos que para páginas extensas. 1794 en poesía está bien. 2023 en cine tal vez no. WhatamIdoing ( discusión ) 01:23 29 sep 2024 (UTC) [ responder ]

La lista de películas alemanas de 2023 , de las que se puede llegar con derecho a 2023 en el cine , podría ser una historia diferente. Thryduulf ( discusión ) 10:19 29 septiembre 2024 (UTC) [ responder ]

Dejaría eso al criterio de los editores y no me opondría a lo que decidieran.

Otra cosa a tener en cuenta es el formato. Compara estas oraciones:

• La niña perdida es un poema de 1794 publicado por William Blake en su colección Canciones de inocencia y de experiencia .
• Esta es una lista de películas alemanas cuyo estreno está previsto para 2023 .

Para el primero, la etiqueta del enlace es "poema de 1794", y si te sorprende que al hacer clic en "poema de 1794" te lleve a 1794 en poesía , entonces quizás no estabas prestando atención a lo que estabas haciendo clic.

En el segundo, la etiqueta del enlace es "2023", y se podría esperar que aparezca 2023 en lugar de películas de 2023. Sugeriría cambiar ese enlace para que incluya las palabras "en 2023" en lugar del año solamente. WhatamIdoing ( discusión ) 19:37 29 sep 2024 (UTC) [ responder ]

Mis 2¢: eliminen los enlaces directos, pero coloquen los artículos "AÑO en TEMA" en la sección "ver también". Esto elimina cualquier problema con MOS:EGG y, en todo caso, es más coherente con una analogía con los cuadros de navegación bidireccionales. Mach61 03:35, 30 de septiembre de 2024 (UTC) [ responder ]

Me gusta esto.

(Hombre, me gustaría que los cuadros de navegación estuvieran en esa sección. Aaron Liu ( discusión ) 11:43 30 sep 2024 (UTC) [ responder ]

Creo que la cuestión clave aquí (que justifica esta posición) es que si bien "2023 en poesía" puede estar relacionado en el sentido de que es el mismo año y no se publicó demasiada poesía en ese momento, eso no significa que sea relevante o útil en relación con ese poema saber qué otros 100 poemas aleatorios se publicaron el mismo año. Mrfoogles ( discusión ) 06:21 13 oct 2024 (UTC) [ responder ]

Estoy de acuerdo en que las URL cortas no son deseables. Sin embargo, ¿no sería mejor si un bot expandiera automáticamente esas URL en lugar de incluirlas en la lista negra? Por ejemplo, youtu.be en youtube.com/watch?v= , tinyurl.com/example en example.com (ese es su objetivo real). Elominius ( criticar | contribuciones ) 09:19, 30 de septiembre de 2024 (UTC) [ responder ]

El motivo por el que están en la lista negra no es porque sean "indeseables", sino porque pueden usarse (y se han usado) para eludir la lista negra de spam y otras medidas antispam. Si el enlace es legítimo, no hay motivo por el que el usuario que intenta agregarlo no pueda expandirlo. Anomie ⚔ 11:25, 30 de septiembre de 2024 (UTC) [ responder ]

@ Anomie : no hay ninguna razón por la que el usuario que intenta agregarlo no pueda expandirlo. La razón es que el usuario final no sabe que tiene que hacer eso, y el mensaje no explica que eso es lo que se debe hacer (o cómo). Y varios sitios usan URL más cortas cuando usas el botón Compartir, que es un tipo de acortador de URL que solo va a un dominio, como un alias de dominio y, por lo tanto, no se puede abusar de él con fines maliciosos. Polygnotus ( discusión ) 23:00, 7 de octubre de 2024 (UTC) [ responder ]

Ciertamente, puedo ver una justificación para tratar los acortadores vinculados a un solo dominio (como youtu.be) de manera diferente a los genéricos como tinyurl. Thryduulf ( discusión ) 23:22, 7 de octubre de 2024 (UTC) [ responder ]

@ Thryduulf : Ver meta:Talk:Spam_blacklist#youtu.be. Polygnotus ( discusión ) 23:43 7 oct 2024 (UTC) [ responder ]

Para ese caso, como había escrito en VPT, el bot podría hacer una comprobación de la lista negra y revertirla si el enlace expandido llega a la lista negra; o simplemente integramos el mecanismo de expansión automática en MediaWiki. Milky Defer 08:34, 10 de octubre de 2024 (UTC) [ responder ]

Esto pasa por alto el hecho de que las personas podrían usar un acortador de URL para vincular a spam o malware incluso si el objetivo no está bloqueado. Una comprobación rápida de una comparación de alguien que hace eso muestra el enlace del acortador y la persona que lo verifica debería estar completamente motivada para examinar qué sucede si hace clic en él. Si la edición original agrega un enlace a un mercado o un sitio dudoso, es mucho más fácil revertirlo. No queremos un bot que bendiga los enlaces externos expandiéndolos. Johnuniq ( discusión ) 01:32, 11 de octubre de 2024 (UTC) [ responder ]

Es posible que el bot descubra quién agregó el enlace. Si la cuenta pasa algunas pruebas heurísticas de confiabilidad, se la consideraría lo suficientemente confiable para la expansión. Sin embargo, es mucho trabajo. ¿Qué tan problemáticos son los URL cortos? -- Green C 02:50, 11 de octubre de 2024 (UTC) [ responder ]

Depende del problema al que te refieras. Según la discusión de Meta, se utilizan para publicar enlaces spam, pero también impiden la adición de buenos enlaces y pueden (no conozco ninguna estadística) desalentar la inclusión de fuentes y/o provocar que se abandonen ediciones, lo que podría afectar negativamente la retención de editores (directa o indirectamente). Todos estos son problemas, pero diferentes.

Creo que lo ideal sería que MediaWiki realice una transformación previa al guardado para expandir las URI cortas a su forma completa, luego verificarlas con la lista negra, luego guardar la forma larga o rechazar la edición según corresponda (el mensaje de error para una edición rechazada debe mostrar las URI cortas y largas para que los editores sepan qué enlace activó la lista negra y por qué). Supongo que esto es algo que tendría que suceder a nivel de software, ¿no? También me pregunto si hay algún medio para detectar automáticamente qué URI se acortan o si eso tendría que curarse manualmente. (por ejemplo, ¿sabría que http://sucs.org/uri/as es una URI corta (lo que lleva al acortamiento de la URL ) sin que se lo digan?) Thryduulf ( discusión ) 03:18, 11 de octubre de 2024 (UTC) [ responder ]

No he leído el hilo de metadatos, pero sospecho que la mayoría de los casos son de buena fe y los malos casos están al límite. Es fácil comprobarlo: revisa manualmente un par de docenas y mira cómo se ve.

Para expandirlo a un formato largo es necesario consultar un encabezado, un sitio externo o una API, lo que puede no ser práctico en la capa interactiva de MediaWiki.

Las URL abreviadas se pueden documentar; hice una página que documenta las URL de los archivos: Wikipedia:Lista de archivos web en Wikipedia (incluyendo algunos que son URL abreviadas). Es fácil comenzar un documento técnico Wikipedia:Lista de sitios de acortamiento de URL en Wikipedia, y esperar que con el tiempo la gente lo encuentre y agregue conocimiento. -- Green C 04:06, 11 de octubre de 2024 (UTC) [ responder ]

Nunca deberíamos confiar en nadie para hacer una edición futura. — xaosflux ^Talk 13:56, 17 de octubre de 2024 (UTC) [ responder ]

Hola, propongo crear una plantilla llamada Plantilla: Wikidata Infobox que crea un cuadro de información a partir de la información que existe en Wikidata. La misma idea se implementa en WikiCommons. Consulte https://commons.wikimedia.org/wiki/Category:Quantum_computing y el cuadro de información de la sección que usa {{Wikidata Infobox}}. Salud. Hooman Mallahzadeh ( discusión ) 13:33, 1 de octubre de 2024 (UTC) [ respuesta ]

El uso de Wikidata para los infoboxes se ha discutido muchas veces aquí y es sorprendentemente (para mí) controvertido. Algunos infoboxes específicos incorporan información de Wikidata (si no recuerdo mal, Mike Peel ha trabajado un poco en esto), pero no creo que un único infobox genérico, ya sea que extraiga información de Wikidata o de otra manera, logre un consenso. Dejaré una nota sobre esta discusión en Wikipedia talk:WikiProject Infoboxes y Wikipedia talk:WikiProject Wikidata . Thryduulf ( discusión ) 13:42 1 oct 2024 (UTC) [ responder ]

Sí... hay MUCHA resistencia a la hora de importar datos de Wikidata a nuestras casillas de información. Las dos principales preocupaciones son la verificabilidad/fiabilidad (aunque WD ha mejorado en este aspecto, todavía no se ajusta a nuestras políticas) y la facilidad de edición (tener que ir a WD para editar la información que aparece en WP puede resultar confuso).

Compartiré una experiencia personal de confusión... la estructura centrada en los datos de WD a menudo me resulta incomprensible como editor centrado en texto aquí en WP. Cuando intento corregir errores en WD, tengo una dificultad extrema para hacerlo. Simplemente localizar la información que necesito editar es difícil. La forma en que se organizan y estructuran las páginas de WD es un galimatías extraño para mí. Blueboar ( discusión ) 14:18, 1 de octubre de 2024 (UTC) [ responder ]

Wikidata es una buena idea a falta de una interfaz utilizable. Su uso se vería enormemente facilitado si se pudieran editar los datos aquí y se volcaran a Wikidata. -- LCU A ctivamente desinteresada « @ » ° ∆t ° 14:39, 2 de octubre de 2024 (UTC) [ responder ]

Así es como se configuran la mayoría de Wikivoyages. No es automático (excepto posiblemente en alemán), por lo que tienes control total sobre qué partes importas localmente y qué partes de tu contenido envías de vuelta a Wikidata. El control es importante porque algunos contenidos son diferentes. Por ejemplo, Wikivoyage normalmente quiere poner la ubicación de latitud y longitud en la entrada de una ubicación, y Wikidata normalmente quiere el centro. No hay necesidad de anular las ubicaciones de cada uno si resultan ser significativamente diferentes (por ejemplo, entrada a Disney World vs. centro de Disney World). Cuando son las mismas, entonces puedes compartirlas de ida y vuelta. WhatamIdoing ( discusión ) 04:23, 3 de octubre de 2024 (UTC) [ responder ]

Commons solo tiene un tipo de cuadro de información. Tenemos muchos de ellos que muestran datos muy diferentes. Personalmente, me encantaría incorporar Wikidata en casi todos los cuadros de información, pero es imposible que un cuadro de información genérico se adapte a nuestras necesidades. Aaron Liu ( discusión ) 14:14 1 oct 2024 (UTC) [ responder ]

Realmente creo que este tipo de infobox (quizás en forma de colapso) es el mejor reemplazo para el infobox de artículos para los que no podemos crear ningún infobox como Computación cuántica . Estos datos incluyen enlaces a WikiQuote y su id de biblioteca, etc., lo que los hace accesibles y a mano. Propongo usar este tipo de infobox en otras secciones como la sección "Ver también", en lugar de la parte superior, reemplazando muchas plantillas existentes como {{Categoría Commons}}. Hooman Mallahzadeh ( discusión ) 14:32, 1 octubre 2024 (UTC) [ responder ]

Um, ¿qué valor se podría derivar del uso de d:Q17995793 para completar un cuadro de información para el artículo Computación cuántica ? ¿Realmente necesitamos un cuadro de información para ese artículo para aclarar que el tema es una instancia de "disciplina académica", subclase de "computación", y es el estudio de la "computadora cuántica" y/o la "supremacía cuántica"? Este es un excelente ejemplo de un artículo que no necesita un cuadro de información. Folly Mox ( discusión ) 02:31 2 oct 2024 (UTC) [ responder ]

Ah, veo que quieres usar el cuadro de información que se encuentra al final de un artículo como un cuadro de navegación. Eso es menos objetable y también es un tipo diferente de cuadro en nuestra jerga. Folly Mox ( discusión ) 02:44 2 oct 2024 (UTC) [ responder ]

@ Hooman Mallahzadeh , no todos los artículos se benefician de un cuadro de información. En mi opinión, la computación cuántica es uno de ellos. Remsense  ‥ 论06:14, 2 de octubre de 2024 (UTC) [ responder ]

@ Remsense Hay buenos enlaces a WikiQuote, Wikiversity, Wikidata, WikiCommons, Library of Congress Authority ID, que se adjuntan al artículo principal simplemente transcluyendo esta plantilla. Esto es un gran beneficio para Wikidata-Infobox de la computación cuántica . Pero colapsar este Wikidata Infobox por defecto parece razonable. Hooman Mallahzadeh ( discusión ) 06:26 2 oct 2024 (UTC) [ responder ]

Ya podemos hacerlo enlazando a los que son importantes en la parte inferior. ¡Esto es extremadamente común y ya se hace en ese artículo! Sin embargo, eso plantea un punto clave de resistencia a esto. No queremos subcontratar mucho a Wikidata porque no podemos decidir tan fácilmente qué no mostrar, para no contaminar los artículos con metadatos que pueden ser útiles en una base de datos pero que son basura funcionalmente inútil en un artículo de enciclopedia. Fundamentalmente, nunca deberíamos esperar que los editores tengan que usar también Wikidata. Remsense  ‥ 论06:28, 2 octubre 2024 (UTC) [ responder ]

Este método es un poco complicado, pero me parece más razonable insertar enlaces acumulativos «por plantilla». Hooman Mallahzadeh ( discusión ) 06:31 2 oct 2024 (UTC) [ responder ]

No, porque la decisión de si vale la pena vincular a Wikiquote en un artículo determinado debería recaer en los editores de ese artículo. Remsense  ‥ 论06:32, 2 de octubre de 2024 (UTC) [ responder ]

No estoy de acuerdo. Según el efecto Zeigarnik , colocar un enlace de Wikiquote que está vacío en este momento motiva a los usuarios a completar esa página y poner alguna cita sobre ese concepto. Hooman Mallahzadeh ( discusión ) 06:38 2 oct 2024 (UTC) [ responder ]

No es nuestro trabajo construir Wikiquote, pero sí es nuestro trabajo no atiborrar indiscriminadamente los artículos de nuestra enciclopedia con basura inútil. Tu postura sería molesta por casi cualquier editor al que le importe el aspecto de los artículos que escribe y qué es exactamente lo que presenta a los lectores. Remsense  ‥ 论06:59, 2 de octubre de 2024 (UTC) [ responder ]

A la mayoría de los lectores no les importan. Los pocos que se preocupan se conforman con que esté en la parte inferior. Aaron Liu ( discusión ) 11:34 2 oct 2024 (UTC) [ responder ]

Hooman Mallahzadeh , tu idea de una única plantilla de uso general para crear enlaces de proyectos hermanos a partir del elemento Wikidata asociado para su uso en la ==External links==sección suena como una buena idea, pero la gente de este subproceso se ha sentido confundida por tu uso del término infobox (que se encuentra en la parte superior del artículo). Sin embargo, esto suena idéntico a la plantilla existente {{ Sister project auto }} . ¿En qué se diferencia tu idea? Folly Mox ( discusión ) 12:35 2 oct 2024 (UTC) [ responder ]

Si la idea es mostrar alguna información de origen, también puede ser similar en concepto a la plantilla más utilizada {{ Control de autoridad }} . SamuelRiv ( discusión ) 15:07 2 oct 2024 (UTC) [ responder ]

Correcto, {{ authority control }} ya es omnipresente (~2.131.000 inclusiones de 6.901.010 artículos, incluidas las redirecciones), incluso está incluido en la salida predeterminada de Wikipedia:ArticleWizard y {{ authority control }} ya extrae de Wikidata. Folly Mox ( discusión ) 17:54, 2 octubre 2024 (UTC) [ responder ]

Teniendo en cuenta todo esto, @Hooman Mallahzadeh , te sugiero que simplemente hagas/bifurques una plantilla en esa línea (o que edites la plantilla existente en su entorno de pruebas), ya que este concepto básico no generaría controversia. El resto de la discusión aquí es un desorden hipotético hasta que la gente vea exactamente lo que tienes en mente, que puede ser radicalmente diferente de lo que ya se usa en estas plantillas anteriores. SamuelRiv ( discusión ) 18:41, 2 de octubre de 2024 (UTC) [ responder ]

Algo como Categoría:Tierra muestra lo difícil que es obtener un cuadro de información automático y bueno, y no un montón de entradas extrañas. "Instancia de: "planeta interior del Sistema Solar (Marte, Venus)" ¿Y Mercurio? Si por alguna razón enumeras los demás aquí, enumeralos todos... "Nombrado por: *suelo (Tierra) *tierra (1, 地, 地球) *esfera (2, 球, 地球)" Er, ¿qué? No tengo idea de por qué se muestra el japonés aquí. "Origen: 4.541.º milenio a. C. (datación de plomo-plomo, edad de la Tierra, creacionismo de la Tierra joven)" Sí, seguro que queremos un enlace al creacionismo de la Tierra joven aquí... "Fecha de disolución, abolición o demolición: valor desconocido (futuro de la Tierra)" Ni siquiera un enlace, solo el texto, como si esto fuera de alguna manera útil. Y esto no es un ejemplo oscuro. Fram ( discusión ) 14:30, 1 de octubre de 2024 (UTC) [ responder ]

{{ Persona del cuadro de información/Wikidata }} , ¿alguien? -  Charla Qwerfjkl 18:42, 1 de octubre de 2024 (UTC)[ responder ]

Qué gran manera de introducir información no verificada (errores) y tonterías en los artículos de Wikipedia. -- Ssilvers ( discusión ) 20:46 1 oct 2024 (UTC) [ responder ]

La información no verificada y la información incorrecta (lo que supongo que quieres decir con "errores") no son sinónimos. No todo en WikiData es información no verificada, incorrecta o sin sentido. Thryduulf ( discusión ) 20:51 1 oct 2024 (UTC) [ responder ]

@ Ssilvers Hay un parámetro fácil para incluir solo información con referencias. Existen referencias incorrectas y se pueden corregir fácilmente utilizando los mismos métodos en ambos sitios. Aaron Liu ( discusión ) 21:01, 1 de octubre de 2024 (UTC) [ responder ]

Wikidata tiene diferentes estándares de fuentes que enwiki: los sitios que se consideran poco fiables según el consenso de enwiki se consideran bastante buenos en Wikidata. Las entradas de Wikidata también se excluyen de los mecanismos de limpieza existentes en enwiki. Por lo tanto, no es tan sencillo como sugieres aplicar los mismos métodos a ambos sitios: los dos sitios no tienen ni los mismos métodos ni una comprensión compartida de lo que es una "mala referencia". Nikkimaria ( discusión ) 00:22 2 oct 2024 (UTC) [ responder ]

¿ Alguien está intentando desarrollar un entendimiento compartido o todo el mundo piensa que está bien que el sitio esté desconectado de esa manera, aunque podrían ayudarse mucho más entre sí? Si tienes enlaces a discusiones, me encantaría leerlas. Amir E. Aharoni ( discusión ) 00:46 2 oct 2024 (UTC) [ responder ]

Mi percepción es que hay una apatía mutua en ambas bases de usuarios: la gente que escribe una enciclopedia no es coherente con la gente que quiere construir una base de datos universal. Si bien los resultados son desafortunados, realmente sería poco razonable esperar que un grupo de voluntarios opere de acuerdo con los estándares del otro. Remsense  ‥ 论06:07, 2 de octubre de 2024 (UTC) [ responder ]

Entonces deberíamos informar a Wikidata por qué y cuáles fuentes son malas y a menudo falsas. No veo ninguna fuente que se considere muy válida en Wikidata y que se elimine sin previo aviso en Wikipedia. Aaron Liu ( discusión ) 01:10 2 oct 2024 (UTC) [ responder ]

[1]. Nikkimaria ( discusión ) 01:25 2 oct 2024 (UTC) [ responder ]

@ Nikkimaria , ¿fue esto una respuesta para mí? ¿Solo un comentario de una persona? Amir E. Aharoni ( discusión ) 02:15 2 oct 2024 (UTC) [ responder ]

No era una respuesta para ti. Este sería un mejor lugar para comenzar con tu pregunta, aunque esa perspectiva también es relevante. Nikkimaria ( discusión ) 02:32 2 oct 2024 (UTC) [ responder ]

Gracias, punto tomado. En ese caso, necesitamos tener al menos anulaciones específicas de parámetros. Aaron Liu ( discusión ) 02:43, 2 octubre 2024 (UTC) [ responder ]

Curiosamente, uno de los argumentos de esa RfC es "Find a Grave se obtiene de las lápidas". ¿No sería mejor en ese caso citar la lápida? Aunque me estoy desviando del tema. Aaron Liu ( discusión ) 02:46 2 oct 2024 (UTC) [ responder ]

La afirmación de que Wikidata está equivocada es sólo una afirmación. Es una wiki, está estrechamente integrada con Wikipedia y puede ser tan correcta o tan incorrecta como la propia Wikipedia. Amir E. Aharoni ( discusión ) 21:06 1 oct 2024 (UTC) [ responder ]

Sí, sabemos que Wikipedia tiene fallas… Por eso NO consideramos que Wikipedia sea una fuente confiable y NO usamos una parte de Wikipedia para verificar otras partes de Wikipedia. Blueboar ( discusión ) 21:18 1 oct 2024 (UTC) [ responder ]

Pero, ¿qué hay de malo en eso si podemos verificar por máquina que la parte reutilizada tiene una fuente? No se trata de buscar fuentes en Wikidata, se trata de reutilizar contenido fuente de Wikidata, por todas las razones por las que {{ extracto }} es bueno. Aaron Liu ( discusión ) 21:20 1 oct 2024 (UTC) [ responder ]

¿Alguien está sugiriendo que se use Wikidata para verificar cosas en Wikipedia? No lo creo. Desde luego que no.

En algunos casos, la gente sugiere insertar cosas escritas en Wikidata en la Wikipedia en inglés cuando es más eficiente hacerlo. Se pueden verificar como la propia Wikipedia. Amir E. Aharoni ( discusión ) 21:32 1 oct 2024 (UTC) [ responder ]

No creo que Wikipedia deba priorizar la eficiencia. Deberíamos priorizar el cuidado. Si la gente quiere reutilizar contenido de Wikidata, puede añadir el contenido y la fuente. No deberíamos simplemente invitarlo a que entre sin editar. Folly Mox ( discusión ) 02:41 2 oct 2024 (UTC) [ responder ]

Parafraseando a Shrek: Pero está curado . ¿Cuál es la diferencia si está curado por un editor de Wikipedia o por un editor de Wikidata? Wikidata no es un sitio completamente separado. Los dos sitios siempre han estado estrechamente relacionados en términos de comunidad y tecnología, y con el mismo objetivo final de conocimiento libre editado como una wiki. Si hay diferencias entre ellos en la política de verificabilidad, pensaría en tratar de salvarlas en lugar de descartar la idea de la colaboración por completo. Amir E. Aharoni ( discusión ) 13:43, 2 de octubre de 2024 (UTC) [ responder ]

No deberíamos dejar la curaduría del contenido incluido en los artículos a personas que, por lo general, no miran ni editan directamente dichos artículos. Esto me parece muy obvio. Remsense  ‥ 论13:51, 2 de octubre de 2024 (UTC) [ responder ]

Pero ¿por qué crees que no miran los artículos? Muy a menudo edito cosas en Wikidata porque noto que aparecieron incorrectamente en Wikipedia, y luego compruebo que la información se actualizó correctamente tanto en Wikidata como en Wikipedia. (Sucede más en otros idiomas, como hebreo, español o ruso, porque la Wikipedia en inglés usa Wikidata menos).

¿Y cuál es la diferencia entre cambiar algo en Wikidata que se incluirá en un artículo de Wikipedia y cambiar una plantilla dentro de Wikipedia que se incluirá en otras páginas? (Aparte de la URL diferente). O cambiar una imagen en Commons y Amir E. Aharoni ( discusión ) 14:00, 2 octubre 2024 (UTC) [ responder ]

Los procesos de curación entre los dos sitios son completamente diferentes. en.wiki se cura principalmente a nivel de página individual, mientras que wikidata parece curarse principalmente en secciones transversales donde se cruzan muchas páginas. (También vale la pena considerar cuánto de Wikidata es creado por bots que extraen de otras wikis). CMD ( discusión ) 14:03, 2 de octubre de 2024 (UTC) [ responder ]

¡Porque están editando una base de datos! Puede que ni siquiera hablen inglés, y mucho menos tengan en cuenta los matices de cómo la Wikipedia en inglés (o cualquier otro proyecto, para ser claros) puede verse afectada por lo que están haciendo directamente. Aunque pienses que no son sitios web totalmente diferentes, son sitios web diferentes. Realmente no creo que tenga que ponerme sociológico para discutir aquí un conjunto de hechos sociales que son bastante obvios para todos los que contribuyen a un proyecto Wikimedia. "Wikipedia es un sitio, Wikidata es otro" también debería responder a tu segunda pregunta: si alguien rompe una plantilla, no es un cambio de paradigma que yo la arregle o le pida a alguien más que lo haga, porque eso ocurre en el mismo sitio web . Eres un espíritu libre y eso está bien; cualquier decisión de diseño que asuma esta calidad de los contribuyentes en general sería terrible. Remsense  ‥ 论14:11, 2 de octubre de 2024 (UTC) [ responder ]

Otra forma de pensarlo es que son el mismo sitio web con diferentes URL.

Y no estoy seguro de a qué te refieres con "calidad de los colaboradores" y "espíritu libre" hacia el final. En mi opinión, un espíritu libre en una enciclopedia libre es algo bueno, pero sospecho que te refieres a algo diferente. Amir E. Aharoni ( discusión ) 19:08 2 oct 2024 (UTC) [ responder ]

Wikidata es, sin duda, un sitio muy diferente, omnipresente en sus bajos estándares de inclusión. Aaron Liu ( discusión ) 19:29 2 oct 2024 (UTC) [ responder ]

Eso, en sí mismo, no es un problema. Puedes incluir algunas cosas de Wikipedia y excluir otras. Eso es más o menos lo que ocurre en la Wikipedia en inglés, pero ocurre más en otros idiomas y funciona bastante bien allí. No entiendo la resistencia que tienen algunos wikipedistas ingleses a incluir algo de Wikidata. Amir E. Aharoni ( discusión ) 16:14 3 oct 2024 (UTC) [ responder ]

Estoy de acuerdo en que no es un problema. No estoy de acuerdo con lo que dijiste sobre que son el mismo sitio y están estrechamente relacionados. Aaron Liu ( discusión ) 17:11 3 oct 2024 (UTC) [ responder ]

Ellos:

• Son mantenidos por la misma organización.
• Están construidos desde el principio para estar conectados, de manera similar a los Bienes Comunes.
• Compartir cuentas de usuario.
• Comparten una gran parte de la comunidad de edición. No tengo cifras precisas y, por supuesto, hay algunos editores de Wikipedia que no hacen nada en Wikidata y viceversa, pero hay mucha superposición.

¿Qué te hace pensar entonces que no están estrechamente relacionados? Amir E. Aharoni ( discusión ) 22:06 3 oct 2024 (UTC) [ responder ]

El hecho de que estén estrechamente relacionados en términos de infraestructura subyacente y objetivos superpuestos no equivale a que sean el mismo sitio web con diferentes URL. Por diseño, cada wiki de Wikimedia tiene su propia comunidad, con su propia cultura, que define sus propias pautas y procedimientos operativos. isaacl ( discusión ) 22:14 3 oct 2024 (UTC) [ responder ]

Lo único que intento decir es que no es muy diferente de Commons. Es independiente en algunos aspectos y es igual en otros. Algunos datos de Commons y Wikidata son útiles en la Wikipedia en inglés, otros no. Enfatizar solo las diferencias, como hacen algunos wikipedistas ingleses, no es correcto ni útil. Amir E. Aharoni ( discusión ) 22:22 3 oct 2024 (UTC) [ responder ]

En esencia, en.wiki solo toma de Commons las direcciones URL de los archivos. Es un lugar muy diferente a en.wiki y sus normas son muy diferentes. CMD ( discusión ) 23:24 3 oct 2024 (UTC) [ responder ]

Y, eh, los archivos, no sólo las URL, ¿verdad?

Independientemente de las normas internas que tenga Commons, la Wikipedia en inglés toma muchos archivos de ella. Y puede ocurrir lo mismo con Wikidata. La Wikipedia en inglés ya toma algunos datos de ella, y puede tomar más.

En realidad, no apoyo específicamente el uso del cuadro de información genérico de Wikidata en la Wikipedia en inglés. Solo intento comprender la resistencia que tienen algunos editores de la Wikipedia en inglés a incluir cualquier cosa de Wikidata. Amir E. Aharoni ( discusión ) 03:12 4 oct 2024 (UTC) [ responder ]

Los elementos clave de la resistencia se han explicado en otras partes de este hilo. Están relacionados con una menor calidad de las fuentes, una mayor vulnerabilidad al vandalismo y la dificultad para editar Wikidata. Los problemas de fuentes no se aplican a Commons, y las modificaciones de archivos allí están restringidas a aquellos con permisos avanzados. En.wiki no importa archivos de Commons, aunque sí aloja archivos por separado cuando no son elegibles para su inclusión en Commons. CMD ( discusión ) 04:17, 4 de octubre de 2024 (UTC) [ responder ]

Commons se beneficia de los requisitos compartidos establecidos por la Fundación Wikimedia sobre el uso de los medios, por lo que los archivos se pueden usar fácilmente en cualquier wiki de Wikimedia. (Por supuesto, los medios que incorporan información, como las estadísticas anuales, sufren problemas similares a los de Wikidata: su precisión depende de quien los sube). Para aquellos preocupados por los estándares de verificación en Wikidata, desafortunadamente no tengo una buena sugerencia para crear mejores procesos para validar ediciones manteniendo el enfoque de "cualquiera puede editar, todos verifican". Por su naturaleza, los datos son muy densos, por lo que creo que intentar verificar dos veces todas las ediciones entrantes es un trabajo más tedioso y oneroso del que se puede esperar de los voluntarios. isaacl ( discusión ) 06:35, 4 de octubre de 2024 (UTC) [ responder ]

Sin embargo, los editores de Wikidata no seleccionan el contenido de los artículos: lo hacen los editores de las wikis que utilizan Wikidata. Wikidata es la información de origen y los editores deciden cuáles incluir. Por eso también creo que las plantillas deberían incluir modificaciones por parámetro antes de cambiar a Wikidata de forma predeterminada. Aaron Liu ( discusión ) 19:30, 2 de octubre de 2024 (UTC) [ responder ]

Hasta donde yo sé, las modificaciones por parámetro son lo que se hace en Wikipedia en todos los idiomas en los que las plantillas extraen información de Wikidata, y tiene todo el sentido. Si esta no es la situación en ningún lado, me sorprendería mucho. Amir E. Aharoni ( discusión ) 16:17 3 oct 2024 (UTC) [ responder ]

El Infobox de Wikidata en Commons surgió del trabajo inicial que estaba haciendo aquí en enwiki: es la misma base de código que {{ Infobox person/Wikidata }} y similares, pero evolucionó mucho más debido a una gran cantidad de aportes constructivos en Commons. Tiene dos vistas: una para las personas, otra para todo lo demás, y se ha demostrado que funciona muy bien en general, y es mucho más escalable y fácil de mantener que miles de plantillas más especializadas. Técnicamente, los infoboxes de Wikidata son bastante maduros ahora, y se usan mucho similares a este en Wikipedias de diferentes idiomas. Wikidata también está bastante bien integrado en diferentes flujos de trabajo en Wikimedia en la actualidad (incluso aquí con las listas rojas de WiR ). La pregunta principal es social: si la comunidad enwp está interesada en seguir con los infoboxes de Wikidata y dedicar el tiempo y la energía para contribuir de manera constructiva a mejorar los datos y refinar la lógica de las plantillas, como lo han hecho la comunidad de Commons y otras comunidades de Wikipedia en otros idiomas. Gracias. Mike Peel ( discusión ) 21:00 1 oct 2024 (UTC) [ responder ]

Creo que, a estas alturas, todavía tenemos demasiado miedo a lo desconocido y el síndrome de "no inventado aquí" como para aceptar mucha ayuda de Wikidata. Otras wikis se beneficiarán (y lo hacen), pero tendremos que ir mordisqueando los bordes durante otra década.

Es posible que debamos explorar algo más cercano a la sincronización manual pero bidireccional que utilizan los Wikiviajes (por ejemplo, para los sitios web oficiales y la latitud/longitud de lugares notables). Si no lo has visto, entonces ve a tu destino de vacaciones favorito en voy: (por ejemplo, voy:en:Paris/7th_arrondissement#See) y desplázate hacia abajo hasta que encuentres una sección que tenga [add listing]junto a los botones de edición de sección habituales. Haz clic en él y aparecerá un gran cuadro de diálogo. A la derecha, busca el espacio en blanco para Wikidata y escribe un monumento famoso (por ejemplo, "Torre Eiffel"; no guardará la edición hasta que se lo indiques manualmente). Haz clic en "búsqueda rápida" para ver lo que ofrece Wikidata (y luego en "Cancelar" hasta el final, para no realizar ningún cambio en el artículo o en Wikidata). También hay un cuadro de diálogo que te permite elegir partes individuales (por ejemplo, quiero mi URL pero la latitud/longitud de Wikidata, o reemplazar de forma remota la información antigua en Wikidata con información más reciente). Se podría hacer algo así, e incluso se podría configurar para que se requieran las fuentes. Agregar fuentes a Wikidata suele ser bastante fácil, ya que solo hay que elegir el tipo (por ejemplo, ISBN, DOI, URL...) y agregar el número de identificación/URL sin procesar directamente. WhatamIdoing ( discusión ) 05:49 2 oct 2024 (UTC) [ responder ]

Aunque estoy de acuerdo con tu evaluación de los procesos de decisión de WP, y realmente creo que lo ideal sería que hiciéramos más con los datos estructurados de WD en este caso, WD no facilita nada (haciéndome eco de lo que dijo Blueboar más arriba) y, francamente (según mis intentos de plantearles este problema), no parece tener ninguna preocupación con el concepto de UX en absoluto. La interfaz de Commons funciona bien, pero tan pronto como te migra para editar los campos de Wikidata directamente, te ves obligado a utilizar su interfaz desconcertante y confusa, donde algo que debería ser tan básico como la diferencia entre una "propiedad" y una "referencia" (y dónde agregar una cita, lo cual se recomienda, pero que no es una "referencia") está por debajo de varios minutos de documentación. (Lo más extraño de todo esto es que en el Discord de WD parece que la gente coloca mal o no agrega datos es su tarea de mantenimiento número uno).

El proyecto (en su estado actual) es utilizable si podemos limitar la interacción del usuario tanto como sea posible, pero ni siquiera Commons ha podido hacerlo por completo. (Nota: me siento libre de quejarme de algunas de las modificaciones de WD aquí porque ya he planteado estos mismos problemas a los editores de WD directamente muchas veces, a menudo con respuestas deficientes). SamuelRiv ( discusión ) 15:03, 2 de octubre de 2024 (UTC) [ responder ]

Las principales cosas que me gustaría tener en su lugar antes de poder respaldar una integración más profunda de Wikidata en los artículos de Wikipedia son:

1. un marcador obvio en el código wiki de dónde se extrae un parámetro de Wikidata (como o algo así), con la capacidad de sobrescribirlo localmente simplemente sobrescribiéndolo o borrándolo|parameter=:wd
2. mensajes de error más claros que hagan evidente a las personas sin experiencia en Wikidata qué dato falta en la plantilla o no puede entenderlo, que enlace directamente a la propiedad en el elemento de Wikidata que está causando el problema o, si no está presente, un enlace a la descripción de la propiedad y un enlace al elemento de origen

Me he encontrado con algunos errores de plantilla que surgieron en Wikidata, y en ningún caso pude resolverlos por mí mismo. Si los editores que están a favor de la integración con Wikidata están dispuestos a trabajar para que sus plantillas sean compatibles con los editores de Wikipedia con aptitud técnica moderada o inferior, entonces podría considerar sumarme, pero en la actualidad actúan como cajas negras inescrutables, y su efecto en la práctica es quitarle poder a un gran subconjunto de editores en esta comunidad. Folly Mox ( discusión ) 12:47 2 oct 2024 (UTC) [ responder ]

Estoy de acuerdo con esto. Recuerdo los fiascos cuando {{ fecha de inicio y edad }} gritaba cuando los datos wiki incorrectos devolvían varias fechas para un solo selector. Debería haber una manera de que estas plantillas se equivoquen sin que el error se sobrescriba con plantillas externas. Aaron Liu ( discusión ) 13:05, 2 de octubre de 2024 (UTC) [ responder ]

"Agregar fuentes a Wikidata suele ser bastante fácil, ya que simplemente eliges el tipo (por ejemplo, ISBN, DOI, URL...) y agregas directamente el número de identificación/URL sin procesar".

Elemento aleatorio [2], primera entrada sin fuente: "taxón". "Añadir referencia" abre el campo "propiedad", que da un menú desplegable con 5 posibilidades. Quiero usar un libro, así que supongo que "enunciado en" sería la opción correcta. Se abre un nuevo menú desplegable, con infinitas opciones, empezando por "¿humano"???, "¿asentamiento humano"???, pintura, aldea, apellido... ¿De qué diablos se trata esto? ¿Quizás deba introducir "libro" y puedo continuar? Ah, no, se queda ahí. Wikidata es extremadamente poco intuitiva y aleatoria. Fram ( discusión ) 08:32 2 oct 2024 (UTC) [ responder ]

Quiero usar un libro, así que supongo que "establecido en" sería la elección correcta.

Sí, solo tienes que introducir el nombre del libro... Esperar que pueda adivinar qué libro quieres citar es bastante poco razonable.
También puedes elegir simplemente "ISBN-13" en lugar de "indicado en". Aaron Liu ( discusión ) 11:38 2 oct 2024 (UTC) [ responder ]

Al igual que la sintaxis "no intuitiva y aleatoria" de MediaWiki para incluir una referencia, Wikidata también tiene páginas de ayuda como wikidata:Help:Sources que explican exactamente esto. Aaron Liu ( discusión ) 11:43 2 oct 2024 (UTC) [ responder ]

Aunque es posible aprender leyendo el manual (¡eso espero!), creo que su desafío a la caracterización de que es simplemente "fácil" fue bastante justo. Remsense  ‥ 论11:54, 2 de octubre de 2024 (UTC) [ responder ]

Añadir una referencia en Wikidata es al menos tan fácil como en Wikipedia. El hecho de que los métodos no sean los mismos no cambia esto. Thryduulf ( discusión ) 11:58 2 oct 2024 (UTC) [ responder ]

No lo discuto. Remsense  ‥ 论11:59, 2 de octubre de 2024 (UTC) [ responder ]

Lo hago. Fram ( discusión ) 12:21 2 oct 2024 (UTC) [ responder ]

Una diferencia que vale la pena señalar es que en en.wiki alguien puede buscar Ayuda:Cita y encontrar algo, mientras que en Wikidata la mayoría de las páginas Ayuda: son elementos de Wikidata. Hay una guía en Wikidata:Ayuda:Fuentes, pero solo guía hacia fuentes que son elementos de Wikidata o URL. CMD ( discusión ) 12:31 2 oct 2024 (UTC) [ responder ]

Buen punto sobre la búsqueda fallida, pero hay un botón de "Ayuda" en el menú principal.
Parece que te perdiste la sección "Diferentes tipos de fuentes". Aaron Liu ( discusión ) 12:44 2 oct 2024 (UTC) [ responder ]

No estoy seguro de cómo llegas a esa extraña conclusión. La sección de diferentes tipos de fuentes es una guía para crear elementos de Wikidata, no para obtener sus fuentes. CMD ( discusión ) 13:05 2 oct 2024 (UTC) [ responder ]

Te guía sobre cómo puedes citar una base de datos con un ID de elemento (la base de datos es, de hecho, un elemento de Wikidata, pero, por lo general, el elemento para la base de datos que utilizas ya ha sido creado), una lápida, Wikisource y registros de archivo. Aaron Liu ( discusión ) 13:11 2 oct 2024 (UTC) [ responder ]

Esta conversación en cadena trata sobre la afirmación de que añadir una referencia a Wikidata es "normalmente bastante fácil", en el contexto de comparaciones con en.wiki. Si dijera que es fácil hacer referencia a algo en en.wiki, solo hay que crear un nuevo artículo para ello, sospecho que la gente no lo consideraría un argumento convincente ni una contribución útil. CMD ( discusión ) 13:16 2 oct 2024 (UTC) [ responder ]

Los nuevos elementos de Wikidata no son artículos. Su dificultad dista mucho de la de los nuevos artículos. Dicho esto, los elementos de referencia generados automáticamente a partir de, por ejemplo, una URL serían de gran ayuda. Aaron Liu ( discusión ) 16:21 2 oct 2024 (UTC) [ responder ]

Creo que subestimas la dificultad que puede tener la gente para crear elementos de Wikidata. CMD ( discusión ) 03:02 3 oct 2024 (UTC) [ responder ]

Es realmente fácil. Si bien el botón "Crear un nuevo elemento" en el menú principal no es muy visible, los pasos a partir de ahí son casi tan fáciles como completar {{ cite book }} . Aaron Liu ( discusión ) 17:12 3 oct 2024 (UTC) [ responder ]

Una vez creados los elementos, no es tan fácil como el agradable creador de citas en.wiki, pero, aparte de eso, no veo qué valor tiene ignorar a las múltiples personas que han manifestado que les resulta difícil analizar Wikidata. CMD ( discusión ) 23:28 3 oct 2024 (UTC) [ responder ]

Se prevé que Wikidata genere automáticamente elementos de referencia a partir de URL y, dado que se utilizará Citoid para generarlos, serán tan erróneos y absurdos como lo son aquí. Folly Mox ( discusión ) 16:14 3 oct 2024 (UTC) [ responder ]

Y eso significaría que los datos wiki incluidos en Wikipedia tendrían el mismo nivel de calidad que la wiki. Aaron Liu ( discusión ) 17:13 3 oct 2024 (UTC) [ responder ]

Eso no tiene sentido en absoluto. Wikidata con una referencia generada por la herramienta tendría referencias similares a las generadas por esa herramienta si los editores involucrados son los mismos, y si el escrutinio posterior es el mismo. Pero como Wikidata tiene, por ejemplo, bots pobres que crean artículos o agregan referencias problemáticas, y no tiene el mismo nivel de control del vandalismo que Wikipedia (aunque también en este caso se escapan demasiadas cosas), el resultado final es que la calidad de Wikidata está con demasiada frecuencia muy por debajo de la calidad de Wikipedia. Fram ( discusión ) 18:07 3 oct 2024 (UTC) [ responder ]

Los elementos incluidos en las wikis serán examinados al igual que la wiki principal, y no estoy seguro de a qué contribuciones problemáticas de bots te refieres. Aaron Liu ( discusión ) 20:12 3 oct 2024 (UTC) [ responder ]

Como ejemplo, CJMbot[3]. Las últimas ediciones incluyen la creación de un elemento sobre un autor muy desconocido del siglo XVII[4], y luego, una semana después, la adición de los mismos elementos y referencias a él. Luego aparece otro bot y elimina los elementos duplicados, pero agrega las referencias duplicadas a los elementos anteriores. Bien hecho... Me di cuenta de este bot porque en John Cage agregó una segunda fecha de nacimiento[5] con origen en el Museo Dhondt-Dhaenens. Completamente inverificable, el museo existe, pero ¿qué significa? ¿Alguna base de datos, un catálogo, información dentro del museo? El resultado es que, por ejemplo, el cuadro de información en Commons, desde hace casi dos años, muestra la fecha de nacimiento correcta y una incorrecta. Fram ( discusión ) 07:56, 4 de octubre de 2024 (UTC) [ responder ]

Parece que ese bot ha destrozado incontables elementos de Wikidata, muchos de ellos de forma sutil, algunos de forma extremadamente flagrante. Se plantearon algunas preocupaciones en su página de discusión, pero a pesar de las garantías de que el propietario del bot lo investigaría, aparentemente no se hizo nada y nadie se dio cuenta de la enorme cantidad de interrupciones. Lo que, una vez más, me demuestra que deberíamos usar Wikidata lo menos posible y no confiar en que sea lo suficientemente bueno como para agregar contenido a enwiki. Véase [6], un compuesto químico que, gracias a este bot, también es un humano con una fecha de nacimiento, etc. No es un caso aislado, véase [7][8][9][10]... Fram ( discusión ) 10:12, 4 de octubre de 2024 (UTC) [ responder ]

Vale, eso es problemático. Si nos fijamos en su solicitud de permisos para bots, toma bases de datos CSV enviadas por museos e intenta hacer coincidirlas con personas, de ahí los comentarios sobre "esto sí que fue un problema en los datos". De alguna manera, todavía no ha habido ninguna discusión sobre el bot que vincula a personas con compuestos químicos. Con suerte, esta vez iniciaré una discusión en una página de discusión y alguien se dará cuenta.
Sin embargo, cuando se incluyan esos datos en Wikipedia, estoy seguro de que la gente notará cualquier dato incorrecto que haya, como hiciste tú, y lo solucionará. Los cambios recientes también tienen muchas ediciones que se muestran como revisadas manualmente, por lo que no es como si su control del vandalismo fuera tan bajo. Aaron Liu ( discusión ) 13:54, 4 de octubre de 2024 (UTC) [ responder ]

Lamento decepcionarte, pero sí, su control del vandalismo es realmente muy, muy bajo. Todavía estoy esperando que alguien revierta al menos una de las 5 ediciones vandálicas que marqué como favorita hace más de 2 días, y hoy tomó casi 4 horas para que alguien se diera cuenta de que "Succcca ahahhaha" (descripción en inglés: "TUA MADRE STR")[11] no es la etiqueta en inglés correcta de El Señor de los Anillos . Si incluso artículos de tan alto perfil y un vandalismo tan descarado tardan tanto en ser revertidos... (Y sí, esto significa que el cuadro de información de Commons también mostró esto durante 4 horas). Fram ( discusión ) 15:04 4 oct 2024 (UTC) [ responder ]

¿Has considerado que todos los que vieron eso están haciendo lo mismo que tú y miden el tiempo que tarda alguien más en arreglarlo? ¿Se te ha ocurrido arreglar las cosas en lugar de interrumpir pasivamente la wiki para dejar en claro algo? 15:59, 4 de octubre de 2024 (UTC) Thryduulf ( discusión ) 15:59, 4 de octubre de 2024 (UTC) [ responder ]

Sí, falta. Digo que no es demasiado bajo. Aaron Liu ( discusión ) 16:29 4 oct 2024 (UTC) [ responder ]

"Sí, solo tienes que introducir el nombre del libro": ¿dónde? ¿Después del cuadro "indicado en"? "Indicado en" viene con una explicación extensa, que incluso en mi pantalla panorámica termina con "en el que se hace una afirmación..." sin ninguna posibilidad de acceder al resto de ese texto. ¿Qué sentido tiene el menú desplegable después de elegir "indicado en" si ninguna de estas opciones tiene sentido aquí? Pero bueno, agrego el título de un libro después de "indicado en". Vaya, quiero incluir un libro que no tiene una entrada en Wikidata: imposible (¿o qué otra cosa significa el cuadro rojo rosado?). Ah, claro, según tu página de ayuda, si quieres usar una referencia que no existe ya como elemento en Wikidata, primero tienes que crear un elemento para ella. ¡Tan fácil! Si realmente no tienes suerte, es una referencia con diferentes ediciones, y luego tienes que crear dos nuevos elementos de Wikidata antes de poder usarlo como fuente. ¿Quieres usar un artículo de periódico como referencia? Primero crea un elemento de Wikidata para el artículo de periódico. En Wikipedia, utilizo el menú desplegable para el tipo de referencia que quiero añadir (solo se muestran cosas que realmente puedo usar, no "humanas"), me muestra cuáles son los campos estándar y no necesito crear otras cosas solo para poder obtener algo. Intentar editar Wikidata es simplemente una fuente interminable de frustración que evito felizmente y no quiero infligir a los demás en absoluto. Aún así, es agradable ver cómo el número de ediciones humanas en Wikidata se infla constantemente de forma artificial, por ejemplo, afirmando que he realizado 951 ediciones en Wikidata en lugar de una docena o más. Bueno, he marcado como favoritos 5 fragmentos de vandalismo de Wikidata para ver qué tan rápido se revierten, ¿me ha divertido esa visita a Wikidata después de todo? Fram ( discusión ) 12:21, 2 de octubre de 2024 (UTC) [ responder ]

¿Dónde? ¿Después del recuadro "indicado en"?

Sí, hay una razón por la que el parámetro se llama "indicado en". Es más intuitivo que el ícono del libro en la barra de herramientas del editor de código fuente.

que incluso en mi pantalla panorámica termina con "en el que se hace una reclamación..." sin posibilidad de acceder al resto de ese texto

Se muestra completamente en mi resolución estándar de 1080p.

¿Qué sentido tiene el menú desplegable después de seleccionar "establecido en" si ninguna de estas opciones tiene sentido aquí?

Es igual que ocurre con el parámetro "enlace al autor", TemplateWizard (la forma visual de insertar plantillas) sugiere automáticamente todos los artículos que comiencen con lo que hayas escrito. Sin embargo, estoy de acuerdo en que, al igual que TemplateWizard, Wikidata no debería sugerir automáticamente cosas cuando no has escrito nada.

Primero tienes que crear un elemento para ello. ¡Así de fácil!

Es realmente fácil. Si bien el botón "Crear un nuevo elemento" en el menú principal no es muy visible, los pasos a partir de ahí son tan fáciles como completar {{ cite book }} .
Es un buen punto lo de tener que completarlo dos veces para el elemento de edición.

Me muestra cuáles son los campos estándar

Wikidata también lo hace. Cada clase de objetos (indicada por lo que escribas en "instancia de") tiene un conjunto recomendado de declaraciones que debes completar; estas se sugerirán automáticamente cuando hagas clic en el botón "agregar declaración". Aaron Liu ( discusión ) 12:58 2 oct 2024 (UTC) [ responder ]

Debes estar viendo una Wikidata (y Wikipedia) completamente diferente a la mía. Si el Editor Visual es tan malo como Wikidata, entonces esa es otra buena razón para no usarlo. No obtengo un ícono de "libro", obtengo un lindo menú desplegable de texto con "citar libro", "citar web", "citar noticias", etc. Campos estándar: dices "Wikidata también lo hace". No, no lo hace. Después de haber agregado un título de libro después de "se indica en", no sucede nada. No obtengo, por ejemplo, el parámetro de páginas, o "capítulo", ni nada. Solo tengo que saber cuáles son los esperados. Fram ( discusión ) 13:15, 2 de octubre de 2024 (UTC) [ responder ]

Si aprender a editar Wikipedia puede ser un poco complicado, aprender a usar Wikidata es como chocar contra una pared de ladrillos. Especialmente en dispositivos móviles, lo encuentro simplemente inutilizable. Sinceramente, creo que sería fácil de usar si tuvieras que escribir comandos SQL. Eso no es un ataque al concepto de Wikidata, sino más bien una crítica a su implementación. -- LCU A ctively D isinterested « @ » ° ∆t ° 14:49, 2 de octubre de 2024 (UTC) [ responder ]

Básicamente puedes SQL CMD ( discusión ) 14:57 2 octubre 2024 (UTC) [ responder ]

Pero no es exactamente fácil de usar. -- LCU A ctivimente desinteresado « @ » ° ∆t ° 15:25, 6 de octubre de 2024 (UTC) [ responder ]

Son puntos muy buenos. Aaron Liu ( discusión ) 16:22 2 oct 2024 (UTC) [ responder ]

Creo que el gadget Arrastrar y soltar está activado de forma predeterminada, y este video de 22 segundos de duración: https://www.youtube.com/watch?v=jP-qJIkjPf0 muestra que solo lleva un par de segundos importar una fuente directamente desde Wikipedia al campo de referencia en Wikidata.

Agregar manualmente una referencia como la que agregué aquí requiere muy pocos pasos:

1. Haga clic en el botón "editar" de ese elemento (si aún no lo está editando).
2. Haga clic en "+ agregar referencia".
3. Seleccione un tipo de referencia de la lista desplegable. Esto puede requerir un poco de conocimiento previo (equivalente a saber cuál de las muchas plantillas de citas utilizar), pero generalmente sugiere algo sensato, como "URL de referencia".
4. Pegue la URL (u otra información de referencia) en el cuadro.
5. Haga clic en "publicar".

Estoy seguro de que todas las personas que participan en esta discusión son capaces de aprender a hacer esto, y estoy bastante seguro de que la mayoría de nosotros descubriría que solo lleva unos segundos después de haber aprendido los sencillos pasos del proceso. Esto requiere, como máximo, cuatro clics, pegar la fuente y, a veces, escribir el nombre de un tipo de referencia adecuado (si el tipo que desea no aparece ya en la lista).

El método de arrastrar y soltar no requiere tanto esfuerzo. Simplemente desplácese hasta la lista de Wikipedias al final del elemento Wikidata y haga clic en [ref] para el idioma del que desea copiar la referencia. Se abrirá una copia del artículo de Wikipedia. Busque la referencia que desea reutilizar y arrástrela. Copiar y pegar con la ayuda de un script no me parece una tarea difícil. WhatamIdoing ( discusión ) 04:18, 3 de octubre de 2024 (UTC) [ responder ]

Entonces, primero agrego la fuente a Wikipedia y luego la copio a Wikidata para poder, eh, usarla en Wikipedia. ¿Cómo hace esto la vida más fácil? El video usa el Jardín Botánico Mabery Gelvin [12] y agrega una segunda referencia al estado en el que se encuentra, Illinois. Entonces, si tuviéramos un cuadro de información generado a partir de Wikidata, habría mostrado que se encuentra en Illinois, tal como lo hace ahora. Aparte del hecho de que el estado ya no se menciona en Wikidata por alguna razón... Se agregó en 2016 (con una fecha de recuperación de 2012, no es bueno) y se eliminó hace más de un año. Menos mal que no dependemos de ese sitio. Teniendo en cuenta que ninguno de los 5 ejemplos de vandalismo que grabé ayer se han revertido, parece que las peleas por vandalismo en Wikidata siguen siendo problemáticas de todos modos. Fram ( discusión ) 07:38, 3 de octubre de 2024 (UTC) [ responder ]

La herramienta sirve para importar fácilmente citas existentes. Aún falta crear una herramienta que ayude a crear nuevas citas.
Además, el elemento de Wikidata se modificó para que se encuentre en el condado de Champaign, lo que parece correcto. Aaron Liu ( discusión ) 13:57 3 oct 2024 (UTC) [ responder ]

Como dijo Chipmunkdavis más abajo, la herramienta ni siquiera es visible para los simples mortales, ¿es un interruptor en las preferencias? Y no dije que el condado de Champaign sea incorrecto, sino que si el cuadro de información estuviera lleno de Wikidata, habría cambiado de "Illinois" (bueno, informativo para la mayoría de la gente, deseado) a "condado de Champaign" (no informativo para la mayoría de la gente, ciertamente sin "Illinois"). O, para ser aún más exactos, habría quitado "Illinois" del cuadro de información pero ni siquiera habría agregado "condado de Champaign" en su lugar, ya que en Wikidata, el condado de Champaign ni siquiera se menciona... EE. UU. tampoco se mostraría, ya que se "referencia" a enwiki. Las únicas referencias en el artículo son errores 404. No es un ejemplo que elegí deliberadamente, es uno dado por WhatamIdoing (aunque involuntariamente, supongo), pero es típico de Wikidata, incluso después de más de 10 años. Incluso cuando se consulta un artículo básico, como Illinois[13], no se encuentran fuentes fiables. Fram ( discusión ) 14:57 3 oct 2024 (UTC) [ responder ]

Sí, el gadget no está habilitado de manera predeterminada y debe activarse.
Nombrar ubicaciones como si estuvieran dentro de sus provincias es una convención de estilo independiente de los datos. Los cuadros de información podrían realizar fácilmente dos llamadas a Wikidata para obtener la ubicación. Aaron Liu ( discusión ) 15:29, 3 de octubre de 2024 (UTC) [ responder ]

No parece ser la opción predeterminada. Mi interfaz de Wikidata (incluida la de Mabery Gelvin Botanical Garden (Q5477670)) tiene los distintos enlaces wiki en la parte inferior de la página y sin los íconos [ref]. CMD ( discusión ) 09:30 3 oct 2024 (UTC) [ responder ]

Otra diferencia clave (en mi experiencia) entre WP y WD: en WP se reconoce que existe una curva de aprendizaje y barreras de entrada a la edición, y en prácticamente todas las conversaciones con VP se plantea la noción de cómo mitigar esto; en WD, las conversaciones que he tenido parecen indicar que los editores creen que es completamente intuitivo en su núcleo: o no creen que puedan hacerlo más fácil para los usuarios, o que las dificultades de los usuarios son su propia culpa (esta es solo la impresión que he tenido de las conversaciones; admito que soy muy directo a la hora de informar sobre los problemas de interfaz). Además, cuando se les preguntó, los editores de WD no parecían interesados ​​en realizar experimentos de interacción con el usuario o examinar los datos de UX existentes.

Nuevamente, esto no es para criticar a WD sin ningún motivo. Creo en el propósito principal del proyecto, pero en este punto siento que tengo que gritarle a cualquier dirección para que se despierten. SamuelRiv ( discusión ) 14:58 3 oct 2024 (UTC) [ responder ]

Este problema definitivamente existe en Wikidata, pero también existe en Wikipedia. Amir E. Aharoni ( discusión ) 16:06, 3 de octubre de 2024 (UTC) [ respuesta ]

En cuanto al trabajo que requiere actualizar Wikidata: cuando hice un cambio por última vez, lo cual, admito, fue hace mucho tiempo, tuve que recorrer un largo camino creando elementos de Wikidata para cada valor de propiedad que añadí a la cita que no existía ya, lo que dio lugar a la creación en cascada de más elementos de Wikidata para los valores de propiedad de los elementos creados inicialmente, y así sucesivamente. Si este sigue siendo el caso, estaría mucho más inclinado a actualizar Wikidata si hubiera una herramienta que me ayudara a generar el árbol completo de elementos de Wikidata en cascada para que yo los aprobara para su envío. isaacl ( discusión ) 16:35 2 oct 2024 (UTC) [ responder ]

Aunque la premisa inicial de este hilo es desafiante, creo que vale la pena reagruparse para deliberar específicamente sobre algunos otros conceptos y potencialidades con respecto a la integración de Wikidata que otros han planteado hasta ahora. En particular, creo que se acepta en general que una variedad de características son potencialmente viables siempre que sean transparentes de forma bidireccional, es decir, que los usuarios de Wikipedia no tengan que aprender a usar Wikidata o abandonar Wikipedia para obtener o actualizar información. Estamos bastante familiarizados con que esto es en parte la forma en que funcionan las descripciones breves, ¿no? Remsense  ‥ 论03:46, 3 de octubre de 2024 (UTC) [ responder ]

Creo que Wikidata extrae descripciones breves de en.wiki (¿y otros idiomas?) para su campo relevante solo cuando no existe una en Wikidata, y de manera similar, en.wiki solo muestra Wikidata si no hay una descripción breve de en.wiki (a menos que ya se haya deshabilitado). Wikidata también extrae coordenadas y otros elementos, pero no sé si gran parte de esto vuelve de forma bidireccional a en.wiki. CMD ( discusión ) 14:07 3 oct 2024 (UTC) [ responder ]

Puede encontrar más información sobre el uso de Wikidata en la Wikipedia en inglés en Wikipedia:Wikidata . Más de 100 Infoboxes utilizan Wikidata de alguna manera. Consulte Categoría:Plantillas de Infoboxes que utilizan Wikidata .

La otra dimensión que esta conversación deja de lado es que los editores de Wikipedia en inglés tendrían la oportunidad de dar soporte a ediciones en otros idiomas, si mantenemos la interoperabilidad entre Wikidata y Wikipedia; con todas las ediciones de Wikipedia en otros idiomas. Existen preocupaciones legítimas sobre la complejidad de la interfaz (para todos los proyectos Wiki) y los estándares de obtención de fuentes, pero abordémoslas en lugar de rechazar con carta blanca cualquier sinergia. ~ 🦝 Shushugah  (él/él •  discusión ) 23:24, 3 de octubre de 2024 (UTC) [ responder ]

Estoy familiarizado con nuestros cuadros de información que utilizan Wikidata. Sin embargo, los usos que conozco no son bidireccionalmente transparentes en la forma en que Remsense menciona, ya que es muy necesario ingresar a Wikidata para editarlos. CMD ( discusión ) 23:31 3 oct 2024 (UTC) [ responder ]

Probablemente me vuelvan a acusar de "alterar pasivamente la wiki para hacer hincapié en un punto"[14], pero para cualquiera que crea que Wikidata tiene un sistema de patrullaje antivandálico que funciona bien, aquí están los 5 fragmentos aleatorios de vandalismo que marqué como favoritos la semana pasada; sorpresa, ninguno de ellos ha sido corregido. Son un grupo variado, desde alguien que crea un artículo sin fuentes que viola la BLP sobre una persona no notable[15] hasta alguien que vandaliza aleatoriamente algunas etiquetas[16] (lo que también afecta, por ejemplo, a Commons), desde lo oscuro pero obvio[17] hasta un editor que vandaliza 4 artículos diferentes sin ningún problema[18], y terminando con un editor de Wikipedia con un artículo enwiki, que murió luchando por Ucrania contra Rusia, que fue vandalizado e insultado descaradamente[19]. Fram ( discusión ) 09:47, 9 de octubre de 2024 (UTC) [ responder ]

Para hacer una breve acotación que tenía intención de publicar antes de que esto generara un subproceso, creo que la disrupción pasiva es un tema un poco difícil de vender. Folly Mox ( discusión ) 12:49, 9 de octubre de 2024 (UTC)[ responder ]

Dejando de lado los detalles, ¿la semiprotección de todos los elementos utilizados en enwp sería suficiente para calmar los temores de vandalismo? Se habrían evitado todos los ejemplos anteriores. Ya es cierto que los elementos de uso frecuente están semiprotegidos, pero no conozco realmente la cultura de la semiprotección en Wikidata como para predecir si un umbral más bajo es realista. Parece que vale la pena reconocerlo como una posible condición de apoyo en medio de los debates que se han prolongado durante años sobre "es basura" frente a "es útil".Las rododendritas ^hablan\\ 12:04, 9 de octubre de 2024 (UTC) [ responder ]

Si transcluyéramos ese contenido a Wikidata, las selecciones de contenido que realmente utilizamos se verían sometidas a la misma lente antivandálica de calidad que ha funcionado durante años. Aaron Liu ( discusión ) 12:10 9 oct 2024 (UTC) [ responder ]

¿Te refieres a "de" Wikidata? De lo contrario, no entiendo muy bien tu comentario. Y no, en el sistema actual esto no funcionaría, el vandalismo en Wikidata que tiene un impacto aquí no se detecta tan rápidamente como el vandalismo aquí (en general, también tenemos vandalismo que permanece durante meses o años). Podemos incluir cambios de Wikidata en, por ejemplo, "cambios recientes", pero entonces obtenemos cosas como esta incluida (como "Dm Antón Losada Diéguez (Q3393880); 12:37 . . Estevoaei (discusión | contribuciones) (‎Reclamo creado: Propiedad:P1344: Q12390563)", que no tiene ninguna relación con Enwiki. Lo cual es típico, la mayoría de los cambios de Wikidata que vemos son enlaces interwiki, descripciones en inglés (que no mostramos de todos modos), o cosas como esta que nunca se mostrarán aquí. Fram ( discusión ) 12:46, 9 de octubre de 2024 (UTC) [ responder ]

Sí, quise decir de, lo siento. De hecho, no hay patrullaje de RC, pero creo que la principal razón por la que el vandalismo de WD no se detecta es que no se muestra de forma destacada. Cualquier vandalismo que escape al patrullaje inicial de RC tendría pocas posibilidades de detección a menos que el vándalo tenga arrogancia (por ejemplo, cualquiera que haya eliminado las contribuciones de alguien) o la gente realmente lea el artículo, lo cual hacen, y lo arreglen. Si aumentamos la prominencia de dichos datos al usarlos realmente, también aumentaremos sustancialmente el contravandalismo. Casi no veo vandalismo en los datos wiki que ya incluimos en los artículos. Aaron Liu ( discusión ) 17:23, 9 de octubre de 2024 (UTC) [ responder ]

Al menos algunos de los ejemplos que he dado ya han tenido un impacto, por ejemplo, en Commons, y nadie lo ha detectado desde allí tampoco. Cuando las descripciones de Wikidata se mostraron en enwiki, el vandalismo de estas descripciones no se detectó de forma significativa ni rápida en enwiki y se revirtió en Wikidata. Esta discusión de RfC de 2017 ofrece muchos ejemplos de lo que sale mal cuando enwiki depende de Wikidata para sus datos, y también ofrece (cerca del final) ejemplos de vandalismo destacado de Wikidata que duró horas y afectó a varios artículos de enwiki, durante esa RfC. Sucede todo el tiempo. Fram ( discusión ) 18:02, 9 de octubre de 2024 (UTC) [ responder ]

Los comunes no son muy destacados.

que dura horas

¿Entonces? Eso no es anormal en el vandalismo, incluso en Wikipedia. La cantidad de ediciones que se eliminan con la eliminación de las reversiones significa que probablemente todavía existan muchos casos de vandalismo. Hay un boxeador famoso cuyo nombre olvidé y al que le vandalizaron descaradamente su infobox y le cambiaron el apodo por algo así como "imbécil"; solo se revirtió después de cuatro días. Mira special:Diff/1241738467 , que cerró el servicio de solicitud de comentarios durante meses. Sin tener en cuenta la fácil solución de protección, ¿eso significa que todas las RfC deben ejecutarse manualmente? No. Aaron Liu ( discusión ) 18:35, 9 de octubre de 2024 (UTC) [ responder ]

Dudo que el vandalismo que está llevando a Rumanía a Moldavia se prolongue durante horas en enwiki. No se trata de un vandalismo furtivo, sino de un vandalismo descarado. En cuanto al vandalismo de Wikidata que se perpetúa en los recuadros de información de muchos idiomas (y que no es detectado ni corregido por la gente de esos idiomas), ahora tenemos (desde hace más de una hora) una fecha de nacimiento imposible para Johan Cruijff , uno de los mejores jugadores de fútbol de todos los tiempos y, por lo tanto, un artículo de cierta importancia. El vandalismo de Wikidata es visible en catalán[20], asturiano[21], gallego[22], "ha"[23], noruego[24], galés[25], etc. El uso de enwiki como un grupo de editores para realizar un control del vandalismo en Wikidata (que es a lo que se reduciría la propuesta anterior) no parece ser una forma productiva de avanzar para enwiki. Fram ( discusión ) 12:35 14 oct 2024 (UTC) [ responder ]

El vandalismo que traslada Rumanía a Moldavia tampoco duraría horas en Wikidata. La fecha de nacimiento de Johan fue revertida 7 minutos después de tu comentario, y por lo tanto la fecha de nacimiento incorrecta solo se mantuvo durante 1 hora y 15 minutos. Y no, eso no es por tu comentario, ya que el revertidor es un frecuente patrullero de RC. Podemos ver que Wikidata tiene contravandalismo. En cuanto a que los wikis no lo detecten, no olviden que es un día laborable en Europa, y no olviden al boxeador. Aaron Liu ( discusión ) 12:56 14 oct 2024 (UTC) [ responder ]

Encontré la edición de boxeador de la que estaba hablando: Special:Diff/1249398659 . Aaron Liu ( discusión ) 13:04 14 oct 2024 (UTC) [ responder ]

Si empiezas a negar la realidad, no sirve de nada continuar con esta discusión. Y no, no creo en esas coincidencias. Cuando publiqué los 5 actos vandálicos anteriores (una semana después de que ocurrieran), uno fue eliminado 2 horas después[26], y los otros se revirtieron unos minutos después de mi publicación (y una repetición solo duró 3 horas, hurra, supongo[27]). Mientras tanto, un editor hace solo una reversión vandálica, que casualmente ocurre directamente después de mi publicación aquí, pero no le importan otros actos vandálicos flagrantes como las 18 ediciones aquí[28], que nuevamente vandalizan la Wikipedia en catalán[29] e incluso la Wikipedia en español[30]. ¿Artículos menos oscuros? Stromae , la gran cantante belga: imagen preferida vandalizada en Wikidata, por lo que el cuadro de información en, por ejemplo, la Wikipedia en catalán o en noruego[31] muestra una imagen incorrecta durante horas (ah, cierto, durante las horas de trabajo, cuando nadie usa Wikipedia...), al igual que Commons[32]. No importa que desde mayo de 2012 , la Wikipedia en noruego muestre orgullosamente en la parte superior de su cuadro de información, gracias a Wikidata: "Gary Lineker Golden Bollocks".[33] Claramente, usar Wikidata para publicar sus cuadros de información es estúpido e imprudente, y solo les da a los vándalos una salida adicional con la que jugar. Fram ( discusión ) 14:36 ​​14 oct 2024 (UTC) [ responder ]

Alternativamente, el vandalismo incluido aquí se detectará y se solucionará mucho más rápido, lo que significa que, con la misma cantidad de esfuerzo, los combatientes del vandalismo solucionarán el vandalismo en varios idiomas/proyectos en lugar de solo en uno. Thryduulf ( discusión ) 14:41 14 oct 2024 (UTC) [ responder ]

Para citarme a mí mismo justo arriba: "Usar enwiki como un grupo de editores para hacer el control de vandalismo en Wikidata (que es a lo que se reduciría la propuesta anterior) no parece ser una forma productiva de avanzar para enwiki". Wikidata se promociona como buena para los datos multiwiki, algunos idiomas cayeron en esta afirmación, y ahora enwiki debería hacer el control de vandalismo por ellos? Aquí todos son libres de ir a Wikidata y hacer patrullaje de vandalismo, nadie te lo impide. Algunos incluso argumentarían que si alguien como Thryduulf sabe que el vandalismo está afectando a Wikidata y a las Wikipedias de otros idiomas, y no hace ningún esfuerzo por hacer patrullaje allí, en realidad está "alterando pasivamente" el panorama de WMF, no, el conocimiento del mundo. Y como explicaron anteriormente muchos editores, no, no es "por la misma cantidad exacta de esfuerzo". No importa, por ejemplo, el problema aún no mencionado del esfuerzo administrativo duplicado, con bloqueos, protección, ... necesarios en ambos lados. Fram ( discusión ) 15:13 14 oct 2024 (UTC) [ responder ]

Ya estamos dando vueltas en círculos, así que solo voy a abordar tu única afirmación nueva:

Sólo les da a los vándalos una salida adicional para jugar.

No, elimina los puntos de venta. Antes, los vándalos podían vandalizar un cuadro de información de un artículo en cualquier edición de Wikipedia. Ahora, cuando vandalizan, tienen que vandalizar todos a la vez y se les puede revertir el vandalismo más rápidamente. Simplificado: antes, los vándalos tenían alrededor de 80 lugares para vandalizar. Ahora, solo tienen alrededor de 20. El sentido común muestra que el vandalismo que se ve en la Wikipedia en español se revierte más rápido que el de la Wikipedia en catalán. Wikidata centraliza la información y, por lo tanto, el control del vandalismo se puede duplicar menos.

Dado que has estado enumerando con acritud los actos de vandalismo en Wikidata que se reflejan en la edición catalana, ¿por qué no echas un vistazo a esta lista gigante de actos de vandalismo en la Wikipedia en catalán? Aaron Liu ( discusión ) 15:21 14 oct 2024 (UTC) [ responder ]

Esas matemáticas no cuadran. Si hay una versión de un artículo en 80 Wikipedias y todas ellas obtienen sus infoboxes de Wikidata, entonces todavía quedan 80+1 lugares que potencialmente pueden ser objeto de vandalismo, porque todavía queda el resto del artículo; esta propuesta no lo elimina. Un vándalo que quiera escribir "caca" en la parte superior del artículo en la Wikipedia en catalán ahora puede hacerlo tanto en la Wikipedia en catalán como en Wikidata, y alguien que quiera evitar que aparezcan actos de vandalismo en ese artículo en la Wikipedia en catalán debe controlar ambos. Nikkimaria ( discusión ) 15:36 14 oct 2024 (UTC) [ responder ]

Ah, entonces eso es lo que significa. Buen punto. Pero la información en el cuadro de información es posiblemente (¿una de?) la parte más importante de un artículo, y las matemáticas se calcularían allí. Aaron Liu ( discusión ) 16:44 14 oct 2024 (UTC) [ responder ]

No, si permites anulaciones. Nikkimaria ( discusión ) 16:50 14 oct 2024 (UTC) [ responder ]

¿Un día laborable en Europa? Pero hoy es el día de Santa Angadrisma . -- Red rose64 🌹 ( discusión ) 14:53 14 oct 2024 (UTC) [ responder ]

¿Se quitan días festivos cristianos en Europa? Aaron Liu ( discusión ) 15:07 14 oct 2024 (UTC) [ responder ]

¿Has estado en Cardiff el 1 de marzo o en Dublín el 17 de marzo? -- Red rose64 🌹 ( discusión ) 17:36 14 oct 2024 (UTC) [ responder ]

Sé que hay grandes santos, pero no creo que Angadrisma sea uno de los santos por los que ningún país se tome un descanso. Aaron Liu ( discusión ) 17:47 14 oct 2024 (UTC) [ responder ]

Es posible pensar en ello como un control antivandálico en la Wikipedia en inglés que también es un control antivandálico en Wikidata y Wikipedia en otros idiomas. Amir E. Aharoni ( discusión ) 13:34 14 oct 2024 (UTC) [ responder ]

Hay implementaciones simples, que quizás sea necesario codificar a nivel de WMF, que podríamos implementar para monitorear el vandalismo entre wikis desde nuestras listas de seguimiento aquí, que parece ser básicamente de lo que estás hablando: cualquier cambio de un material transcluido de wikidata (o commons, etc.) a un artículo en la lista de seguimiento debería resultar en una notificación en la lista de seguimiento de WP de ese editor (o una herramienta implementada de manera similar).

Por supuesto, si, por ejemplo, cada cita de un artículo se vincula a Wikidata (y esto está más allá del alcance de OP), esto es una gran cantidad de elementos para colocar en una lista de seguimiento, pero no sé si importa ya que la cantidad de cambios esperados en los elementos de WD y Commons es muy pequeña (suponiendo que uno puede poner en la lista de seguimiento propiedades individuales y no elementos completos). Pero automatizar el proceso no debería ser un problema, y ​​la notificación entre wikis ya es factible hasta cierto punto.

Por supuesto, no aborda lo que se mencionó anteriormente: que editar WD es terrible, algo que realmente se puede solucionar si los editores lo reconocen. SamuelRiv ( discusión ) 15:50, 14 de octubre de 2024 (UTC) [ responder ]

Wikidata es WMDE, no WMF. WhatamIdoing ( discusión ) 23:57 16 oct 2024 (UTC) [ responder ]

¿En serio? No hay nada en d:Wikidata:Introduction que diga que, de hecho, al final de cada página hay el mismo pequeño cuadro "un proyecto WIKIMEDIA" que también tenemos, que si haces clic te lleva a https://wikimediafoundation.org/ - es cierto que no es lo mismo que wmf: pero no está del todo claro cuál es la distinción. -- Red rose64 🌹 ( discusión ) 07:20 17 oct 2024 (UTC) [ responder ]

La WMF lo aloja, pero WMDE se encarga del software. Véase mw:Wikibase: "Wikibase es un software libre y de código abierto creado y mantenido por Wikimedia Deutschland y una gran comunidad de colaboradores". El proyecto Wikidata Change Dispatching & Watchlists (el material que coloca los cambios de Wikidata en su lista de seguimiento) es uno de los proyectos de WMDE. WhatamIdoing ( discusión ) 19:36 17 oct 2024 (UTC) [ responder ]

La URL del archivo tiene este formato: www.web.achive.org/web/aaaammdd/https:www.placeholder.com

La fecha se puede introducir automáticamente al introducir la URL, en lugar de tener que añadir la fecha. ¿Quién soy yo? / ¡ Háblame! / ¿Qué he hecho? 05:03, 7 de octubre de 2024 (UTC) [ responder ]

Sé que esto es cierto en el caso de Internet Archive, pero me parece recordar que otros servicios de archivo tienen formatos de URL diferentes. Alt.Donald Albury ( discusión ) 12:00, 7 de octubre de 2024 (UTC) [ responder ]

Tal vez podamos detectar el enlace (que comienza con web.archive.org) y, si se trata del archivo de Internet, se puede utilizar el formato. Los demás archivos no se utilizan de forma significativa, por lo que esto no afectará mucho al proceso. ¿Quién soy yo? / ¡ Háblame! / ¿Qué he hecho? 12:43, 7 de octubre de 2024 (UTC) [ responder ]

Esta es una idea excelente. Archive.org no utiliza aaaammdd sino, por ejemplo, 20031224105129. Debo insertar manualmente guiones en los puntos apropiados 2003-12-24105129 y eliminar la marca de tiempo para que termine con 2003-12-24. Parece muy probable que un bot ya esté haciendo esta tarea, pero para estar seguro puedes preguntar en Meta o WP:VPT . Polygnotus ( discusión ) 23:08, 7 de octubre de 2024 (UTC) [ responder ]

Bien, entonces solo se necesita la URL del archivo para completar la plantilla de cita. La fecha se puede completar automáticamente.

¿Quién soy yo? / ¡Háblame! / ¿Qué he hecho? 02:47 8 oct 2024 (UTC) [ responder ]

Haciendo ping a @GreenC para el formato de fecha de archive.org WhatamIdoing ( discusión ) 17:43 9 oct 2024 (UTC) [ responder ]

Como idea, apoyo totalmente esta. También me preguntaba por qué la plantilla se quejaba de la falta de fecha cuando está disponible en la URL, y me molestaba especialmente el mensaje de que la marca de tiempo no coincidía. Sin embargo, desde entonces he aprendido que esto no es tan fácil de implementar como parece.

• Las plantillas {{ cite }} literalmente no pueden agregar el parámetro faltante ni modificarlo, porque las plantillas solo pueden modificar su salida (es decir, el HTML que se muestra), no pueden cambiar la entrada del wikitexto. Supongo que, estrictamente hablando, esto sería posible con subst:-ing, pero obligar a todos a hacerlo con {{ cite }} no va a funcionar.
• El editor (software) ciertamente podría hacer que esto suceda automáticamente, pero estoy bastante seguro de que los desarrolladores (comprensiblemente) no estarían dispuestos a introducir un tratamiento especial para plantillas específicas en una wiki específica. Además, mientras que el editor visual podría ocultar el cambio de wikitexto necesario detrás de escena, para el editor de código fuente esto tendría que significar corregir automáticamente el wikitexto enviado después del hecho, y que yo sepa, esto actualmente no se hace por ningún motivo.
• Dado que {{ cite }} generalmente se coloca dentro de <ref>...</ref>, mw:Extension:Cite posiblemente podría manejar esto, pero nuevamente, buena suerte intentando convencer a los desarrolladores.

Por lo tanto, creo que probablemente sea difícil vender la idea de "completar el |archive-date=formulario |archive-url= mientras el usuario está editando ". Sin embargo, hay otras consideraciones que tener en cuenta.

• Dado que una falta o una falta de coincidencia |archive-date=lleva automáticamente la página a la categoría: Errores CS1: URL de archivo , ¿es necesario insistirles a los editores al respecto (y, especialmente , poner mensajes de error en rojo en la página que se muestra)? Las funciones fixemptyarchive y fixdatemismatch de WP:WAYBACKMEDIC pueden solucionar fácilmente estos errores, así que ¿por qué no hacer que el bot se ejecute con más frecuencia que la actual, cada 2 o 3 meses ? No necesariamente con toda su funcionalidad, solo contra esta categoría en particular. Realmente no veo por qué esto no podría suceder a diario.
• Y para decirlo de forma más radical: ¿es |archive-date=necesario un separate cuando su contenido simplemente duplica el de otro parámetro? Dado que el código Lua de CS1 ya tiene un manejo especial para archive.org , ¿por qué no añadir también la toma de la fecha de la URL? CS1 es anterior a la disponibilidad de Lua, por lo que quizás esto era demasiado inconveniente de implementar con la antigua funcionalidad de plantilla y era inevitable exigir a los editores que siempre incluyeran este parámetro. Sin embargo, este ya no parece ser el caso. La información de archivo no parece ser necesaria para COinS (que de todos modos no se tomaría directamente del wikitexto), ni conozco ninguna otra razón para mantenerla obligatoria para los enlaces de archive.org (o cualquier otro que incluya la fecha).

Es muy posible que me esté perdiendo algo importante con respecto al status quo , por lo que espero que personas como @Trappist el monje y @GreenC puedan dar su opinión.

Gamapamani ( discusión ) 12:29 12 oct 2024 (UTC) [ responder ]

Muchas gracias por refinar la propuesta. La segunda consideración tiene mucho sentido. Añadir una URL de archivo siempre es manual, incluso si se utiliza la herramienta automática, por lo que creo que tiene sentido eliminar el parámetro y, utilizando Lua, buscar la fecha a partir de la URL. ¿Quién soy yo? / ¡Háblame! / ¿Qué he hecho? 14:23, 12 de octubre de 2024 (UTC) [ responder ]

--> Categoría:Errores de CS1: archive-url tiene actualmente 33 páginas. Lo borro cada 15 días. La última vez que lo borro fue alrededor del 1 de octubre. No es un gran problema. -- Green C 19:47, 12 de octubre de 2024 (UTC) [ responder ]

Claro, no quise decir que debería limpiarse con más frecuencia tal como están las cosas ahora. Lo que estaba tratando de decir era que si se |archive-date=eliminara el problema de insistir en el editor y en la página resultante para archive.org , la categoría presumiblemente se llenaría un poco más rápido, pero el bot aún podría manejarlo. Gamapamani ( discusión ) 02:59, 13 de octubre de 2024 (UTC) [ responder ]

Sí, no es necesario mostrar el error CS1. ¿Quién soy? / ¡Háblame! / ¿Qué he hecho? 03:53, 17 de octubre de 2024 (UTC) [ responder ]

Hola. Me gustaría proponer un proyecto sobre fotos en los recuadros de información de los artículos relacionados con ejecutivos y otras figuras públicas. Creo que hay demasiada inconsistencia en Wikipedia, con fotos que van desde retratos oficiales y profesionales hasta fotos tomadas de ellos en la naturaleza, como en un escenario o durante una transmisión en vivo. Para mantener la coherencia y hacer que los artículos de Wikipedia se vean más presentables, me gustaría que avanzáramos hacia la inclusión de retratos de dichas personas siempre que sea posible para evitar infracciones de derechos de autor. La mayoría de los artículos de políticos siguen esta tendencia; por lo tanto, me gustaría ampliar esto a todas las figuras públicas, especialmente a aquellas que ocupan o han ocupado puestos de nivel C. Espero con interés las opiniones de todos y, por favor, háganme saber si este tipo de discusión debería trasladarse a otro lugar. MikeM2011 ( discusión ) 21:29, 7 de octubre de 2024 (UTC) [ responder ]

No estoy seguro de qué quieres hacer que no se haya hecho ya. La razón por la que hay tanta inconsistencia en los retratos es que simplemente no tenemos suficientes fotógrafos para tomar fotografías de sujetos en lugares públicos (o conseguir el consentimiento para tomar fotografías de sujetos en lugares privados). Aaron Liu ( discusión ) 21:36 7 oct 2024 (UTC) [ responder ]

Hay muchos retratos profesionales disponibles en línea que podríamos usar. No estoy seguro de por qué no podemos utilizarlos con las citas correspondientes según el acuerdo de uso justo. MikeM2011 ( discusión ) 02:12 10 oct 2024 (UTC) [ responder ]

No puedes porque cualquiera debería poder tomar una imagen de ellos mismos de forma gratuita en un lugar público y no podemos permitirnos subir contenido en masa y que luego nos demanden un montón. Aaron Liu ( discusión ) 02:34 10 oct 2024 (UTC) [ responder ]

Desafortunadamente, las reglas sobre contenido que no es libre no permiten usar reclamos de uso legítimo en fotos de personas vivas, y esa política es demasiado estricta como para siquiera considerar cambiarla (ni siquiera estoy seguro de si podemos hacerlo, o si fue una decisión de la Fundación Wikimedia). Eso significa que, en muchas cosas relacionadas con las imágenes, no usamos ni hacemos lo que quisiéramos , sino solo lo que podemos con las imágenes limitadas que tenemos disponibles. Sospecho que por "artículos de políticos" te refieres a políticos estadounidenses, y tenemos muchas buenas imágenes e incluso retratos porque muchos sitios oficiales publican sus contenidos bajo licencias libres. Pero intenta escribir sobre políticos de otros lugares y probablemente tendrás que lidiar con la misma escasez de buenas fotos de muchos otros temas. Cambalachero ( discusión ) 03:58, 10 de octubre de 2024 (UTC) [ responder ]

Creo que ese requisito es puramente local. Lo creamos nosotros y podemos cambiarlo. Pero comparto tu escepticismo sobre si optaríamos por cambiarlo. WhatamIdoing ( discusión ) 18:13 11 oct 2024 (UTC) [ responder ]

Fundación:Resolución:La política de licencias dice que un EDP no puede permitir material en el que se pueda esperar razonablemente que alguien cargue un archivo con licencia libre para el mismo propósito, como es el caso de casi todos los retratos de personas notables vivas. Anomie ⚔ 20:39, 11 de octubre de 2024 (UTC) [ responder ]

Siempre quise ver otras fuentes en Wikipedia (excepto Comic Sans MS, que es muy mala). Prueba a añadir otras fuentes. Electrou (anteriormente Susbush) ( discusión ) 16:09 11 oct 2024 (UTC) [ responder ]

Agregue esto a su Special:MyPage/common.css :

cuerpo { font-family : "nombre de la familia de fuentes" ; }  

, con la parte entre las comillas dobles reemplazada por la familia de fuentes real, por supuesto. Aaron Liu ( discusión ) 16:32 11 oct 2024 (UTC) [ responder ]

Ok. Electrou (anteriormente Susbush) ( discusión ) 16:54 11 oct 2024 (UTC) [ responder ]

Quiero la fuente de Ubuntu, ¿puedo obtener el código? Electrou (anteriormente Susbush) ( discusión ) 17:04 11 oct 2024 (UTC) [ responder ]

¿Es compatible con las fuentes de Ubuntu? Electrou (anteriormente Susbush) ( discusión ) 17:13 11 oct 2024 (UTC) [ responder ]

No funciona (probé la fuente de Ubuntu) Electrou (antes Susbush) ( discusión ) 17:17 11 oct 2024 (UTC) [ responder ]

@ Electrou , ¿qué navegador web y sistema operativo estás usando? WhatamIdoing ( discusión ) 18:56 11 oct 2024 (UTC) [ responder ]

Estoy usando la última versión de Google Chrome y estoy en el móvil (uso la vista de escritorio cuando es necesario) Electrou (anteriormente Susbush) ( discusión ) 20:30 11 oct 2024 (UTC) [ responder ]

Como sugiere Chaotic Enby, no puedes mostrar Wikipedia en ninguna fuente que no esté en el dispositivo que estás usando. Si abres Google Chrome y vas a la configuración/preferencias, hay un elemento (en mi portátil, está en "Apariencia") que dice algo así como "Personalizar fuentes". Debería tener un menú desplegable que enumere todas las fuentes. Si "Ubuntu" no está en esa lista, entonces tu dispositivo no puede mostrar esa fuente. WhatamIdoing ( discusión ) 20:43, 11 de octubre de 2024 (UTC) [ responder ]

Si no puede instalarlo en ese dispositivo, ¡puede usar fuentes de respaldo! Son útiles sobre todo si la misma página se puede ver desde distintos dispositivos con distintos conjuntos de fuentes instalados y se muestran si la fuente preferida no está instalada.

cuerpo { font-family : "fuente preferida" , "fuente de reserva" , "fuente de reserva de reserva" ; }    

Por ejemplo, mi página de usuario se ve mejor en Josefin Sans, pero también tiene una serie de fuentes alternativas, ya que no está disponible en todos los dispositivos. Chaotic Enby ( discusión · contribuciones ) 21:38, 11 de octubre de 2024 (UTC) [ responder ]

En teoría, también puedes descargar las fuentes automáticamente. Sin embargo, no creo que funcione, ya que MediaWiki:Common.css es la hoja de estilos principal y no estoy seguro de si la hoja de estilos del usuario se carga individualmente. Aaron Liu ( discusión ) 21:47, 11 de octubre de 2024 (UTC) @import url('https://fonts.googleapis.com/css2?family=Ubuntu:ital,wght@0,300;0,400;0,500;0,700;1,300;1,400;1,500;1,700&display=swap');[ responder ]

Puedes cargar fuentes desde otros servidores, como el servidor de fuentes de Google, o el proxy de Toolforge para el servidor de fuentes de Google, si así lo deseas. Ten en cuenta que la información de referencia de la página se enviará al servidor de fuentes cada vez que se cargue la fuente (normalmente se almacenará en caché, por lo que se cargará con poca frecuencia), por lo que algunas personas desconfían de hacer esto. También ten en cuenta que el espejo de Toolforge no se recomienda para uso general. isaacl ( discusión ) 22:00, 11 de octubre de 2024 (UTC) [ responder ]

La hoja de estilos del usuario también se carga individualmente, precisamente para que @importfuncione. – SD0001 ( discusión ) 19:42, 17 de octubre de 2024 (UTC) [ responder ]

He instalado la fuente, pero no la muestra. Electrou (anteriormente Susbush) ( discusión ) 07:55 12 oct 2024 (UTC) [ responder ]

¿Lo has instalado en tu móvil? Chaotic Enby ( discusión · contribs ) 20:36 11 oct 2024 (UTC) [ responder ]

Sería una gran idea tener una aplicación que permita a las personas descargar o guardar Wikipedia para poder usarla sin conexión. De esta manera, quienes no tienen acceso a Wi-Fi (como yo) pueden investigar y editar cosas fácilmente. HippieGirl09 ( discusión ) 14:13 12 oct 2024 (UTC) [ responder ]

Mira la pestaña Herramientas en la página del artículo. En mi sistema, una de las opciones es "Descargar como PDF". Otra opción es "Versión imprimible". Puedes usarla para imprimir en un archivo. En realidad, puedes descargar toda la Wikipedia en inglés, pero necesitarás mucho espacio de almacenamiento. Sin embargo, tendrás que realizar todas las modificaciones en línea. Donald Albury 18:58, 12 de octubre de 2024 (UTC) Editado 19:01, 12 de octubre de 2024 (UTC) [ responder ]

@HippieGirl09 Las aplicaciones oficiales de Wikipedia para Android e iOS te permiten guardar artículos individuales para leerlos sin conexión. Si te interesa tener toda la Wikipedia disponible sin conexión, entonces quizás quieras echarle un vistazo a Kiwix. the wub "?!" 22:35, 12 de octubre de 2024 (UTC) [ responder ]

Creo que sería una característica interesante poder ver el historial de artículos que has visto en el pasado en la versión web de Wikipedia (creo que esto podría existir ya en la versión de la aplicación). Paso por muchas madrigueras de conejo de Wikilink y me gustaría poder ver una lista de todos los artículos que he leído. ¿Es esta una adición concebible al software de Wikipedia? Cleebadee ( discusión ) 21:10 12 oct 2024 (UTC) [ responder ]

Sugiero que utilices el historial de tu navegador (lo que puede significar encontrar un navegador con una forma conveniente de buscar en tu historial). Creo que muchos usuarios se sentirían incómodos si nuestro historial de lectura de Wikipedia estuviera fácilmente disponible para que cualquiera pudiera acceder a él en el servidor de Wikipedia. (Por supuesto, la información se puede determinar a partir de los registros del servidor web, pero eso es menos conveniente para que los actores maliciosos se aprovechen de ello). isaacl ( discusión ) 21:32, 12 de octubre de 2024 (UTC) [ responder ]

Como analogía, mi biblioteca local utiliza un software que tiene una opción para conservar un registro de los libros que he sacado prestados, que está desactivada de forma predeterminada. Con la opción predeterminada, el registro de un libro que he sacado prestado se borra cuando devuelvo el libro. De esa manera, si una agencia gubernamental exige un registro de los libros que he sacado prestados, y he dejado la opción configurada para no conservar un registro, la biblioteca no tiene información para entregar. Las agencias gubernamentales y otras partes no pueden obtener registros que no existen. Por cierto, puede que sea paranoico, pero me lo he ganado. Tengo copias de dos informes del FBI sobre mí (a través de la Ley de Libertad de Información de EE. UU.), uno de aproximadamente 200 páginas y el otro de 22 páginas. Donald Albury 22:05, 12 de octubre de 2024 (UTC) [ responder ]

¿Estás diciendo que Wikipedia debería permitir esto como una opción? Parece que sería una buena manera de hacerlo posible sin obligar a la gente a usarlo. ¿Quizás podría ser una herramienta que esté desactivada de forma predeterminada? Cleebadee ( discusión ) 03:28, 13 de octubre de 2024 (UTC) [ responder ]

Estoy diciendo que una de las consideraciones sobre si se debe mantener un registro de lo que se ha visto en Wikipedia es que si existe un registro, puede ser requerido judicialmente o pirateado. Otra consideración es que si dichos registros no existen, entonces la Fundación Wikimedia no tiene que gastar tiempo y dinero respondiendo a/resistiendo las solicitudes gubernamentales de acceso a esos registros. Si pudiera opinar sobre si se debe tener esa opción, me opondría. Creo que los usuarios merecen el derecho a leer lo que quieran en Wikipedia sin preocuparse de que alguien esté mirando por encima de su hombro. No podemos impedir que alguien controle lo que un lector mira desde su lado, pero podemos hacer lo que podamos para preservar la privacidad dentro de Wikipedia. Donald Albury 13:54, 13 de octubre de 2024 (UTC) [ responder ]

¿El hecho de que el registro esté disponible en la propia Wikipedia facilitaría su piratería en comparación con el hecho de que esté disponible indirectamente a través del historial de búsqueda de un motor de búsqueda? Cleebadee ( discusión ) 14:31 13 oct 2024 (UTC) [ responder ]

Puedes filtrar el historial de tu navegador por sitios web. En el peor de los casos, puedes buscar "Wikipedia" en el historial. Aaron Liu ( discusión ) 22:11 13 oct 2024 (UTC) [ responder ]

Siento que usar un historial de visitas hipotético de Wikipedia y buscar en Wikipedia en el historial de un motor de búsqueda son cosas fáciles de hacer para un malhechor. Por eso no entiendo la idea de que agregar el de Wikipedia facilitaría las cosas a los malhechores. ¿Es más fácil para ellos hackear Wikipedia en comparación con los motores de búsqueda? Cleebadee ( discusión ) 20:12 14 oct 2024 (UTC) [ responder ]

Si quieres que los datos se sincronicen entre dispositivos, tendrás que subir la información a los servidores de Wikipedia; mientras tanto, el historial no suele estar sincronizado de forma predeterminada. También supone una complejidad adicional para el software con muy pocos beneficios. Aaron Liu ( discusión ) 20:49 14 oct 2024 (UTC) [ responder ]

Creo que Zotero Connector tiene esta opción que puedes activar para el dominio de Wikipedia. Es decir, si te interesa rastrear tu historial de Wikipedia (y de otros sitios web y lecturas, y de fuentes para la edición de WP y la investigación y redacción en general) más allá de tu historial de navegación, Zotero es una buena opción. SamuelRiv ( discusión ) 22:23, 12 de octubre de 2024 (UTC) [ responder ]

Genial, no había oído hablar de este sitio web antes. Uso un iPad, así que no creo que pueda usarlo. Cleebadee ( discusión ) 14:29 13 oct 2024 (UTC) [ responder ]

Movido desde WP:VPT

Creo que la página principal de Wikipedia sería más educativa y tendría una sección de acertijos, proverbios, modismos, dichos sabios. Ya sabes, una colección de muchos idiomas, sus orígenes, significados pasados, reformas, significados actuales, ejemplos de su uso en la historia (pasado y presente), sus significados literales, traducción palabra por palabra en inglés, etc. No sé, ¿quién tiene mejores ideas? Que Wikipedia sea también un lugar divertido para que los visitantes y lectores aprendan siempre más. Espero ver esto a principios del año que viene y en otras wikis de idiomas. Se aceptan todas y cada una de las contribuciones. elias_fdafs ( discusión ) 20:02, 13 de octubre de 2024 (UTC) [ responder ]

@ Elías Fortaleza de la Fuerza Sánchez : Moví tu idea al laboratorio de ideas aquí, no fue un problema técnico. - ^Charla de xaosflux 20:09, 13 de octubre de 2024 (UTC) [ respuesta ]

Si bien esto suena más como algo de Wikcionario o Wikiquote, siento que podría haber una discusión fructífera sobre la posibilidad de mostrar contenido destacado de proyectos hermanos en el caso general. Folly Mox ( discusión ) 20:32, 13 de octubre de 2024 (UTC) [ responder ]

Oh, Dios mío, otra sugerencia para rediseñar la página principal. Buena suerte con eso . -- Red rose64 🌹 ( discusión ) 20:51 13 oct 2024 (UTC) [ responder ]

El problema es que lo que para una persona es un "sabio dicho", para otra es una " profundidad ". No creo que tenerlos en la página principal, especialmente en una sección dedicada a ellos, sea realmente muy enciclopédico. Sin embargo, como dice Folly Mox, ¡un concepto más general de mostrar el contenido de proyectos hermanos (la etimología de una palabra, una cita, etc.) podría ser interesante! Chaotic Enby ( discusión · contribs ) 21:03 13 oct 2024 (UTC) [ responder ]

¿Qué tal una pequeña sección con lo que sea que tenga el proyecto hermano? Podría circular diariamente. Cremastra ( discusión ) 22:57 13 oct 2024 (UTC) [ responder ]

¡Eso podría funcionar perfectamente! Chaotic Enby ( discusión · contribuciones ) 17:22 14 oct 2024 (UTC) [ responder ]

Lo complicado es, en realidad, incluir algo de otro proyecto, lo cual no creo que sea posible conafueramw:Transclusión aterradora. Cremastra ( discusión ) 17:25 14 oct 2024 (UTC) [ responder ]

Supongo que te refieres a conafuera¿Transclusión aterradora? jlwoodwa ( discusión ) 18:54 14 oct 2024 (UTC) [ responder ]

Arreglado. Gracias, Cremastra ( discusión ) 18:58 14 oct 2024 (UTC) [ responder ]

El problema con los modismos y los proverbios es que, por lo general, son regionales. Se usan ampliamente en alguna zona, pero apenas se mencionan o incluso son desconocidos en otras. Por cada usuario que ve una sección de este tipo y dice "ah, ese es el origen de ese proverbio", tendremos varios que dirán "qué, ¿eso era un proverbio? Nunca había oído hablar de él". Además, explicar su origen es simplemente imposible con el texto limitado en los cuadros de la página principal. Tal vez DYK sea un mejor lugar para mostrar esos artículos en la página principal. Cambalachero ( discusión ) 13:18, 15 de octubre de 2024 (UTC) [ responder ]

Sería útil contar con artículos sobre modismos, especialmente si mencionaran los problemas que se presentan al traducir entre idiomas. Sin embargo, no creo que la página principal sea un lugar apropiado. -- Shmuel (Seymour J.) Metz Nombre de usuario:Chatul ( discusión ) 13:58, 15 de octubre de 2024 (UTC) [ responder ]

Como comenté en Wikipedia:Bomba de agua para la aldea (propuestas)/Archivo 213 § Propuesta: Crear cuestionarios en Wikipedia , sugiero encontrar personas interesadas en crear ese tipo de contenido, crear una página de proyecto y producir el contenido regularmente según el cronograma que puedas administrar. A partir de esa experiencia, puedes intentar averiguar cómo hacer que el proceso sea sostenible. isaacl ( discusión ) 15:59 15 oct 2024 (UTC) [ responder ]

Creo que se podría poner en Portal:Actualidad , en el lateral, debajo del recuadro "2024 en los proyectos hermanos de Wikipedia". Hay mucho espacio y un "____ del día" podría ser divertido. WhatamIdoing ( discusión ) 00:03 17 oct 2024 (UTC) [ responder ]

Mi último período de edición importante fue en 2017, y en ese momento la interfaz de edición en la aplicación para iPad era bastante básica, pero ahora las aplicaciones móviles tienen un soporte realmente bueno para tipos básicos de edición. Especialmente la aplicación para iPad, que tiene una interfaz personalizada que no es exactamente la misma que los editores visuales o de código fuente en la web. En realidad, me gustaría mucho que esa interfaz fuera compatible con la aplicación para iPhone, que parece usar una versión menos completa de la interfaz web para la edición por alguna razón, pero ese no es el punto.

Edito aproximadamente el 50 % en un iPad y, en esos casos, la aplicación ofrece una mejor experiencia que usar Safari para iPad, que presenta algunos problemas persistentes con la edición para mí. Sin embargo, es difícil encontrar información sobre cómo contribuir a Wikipedia en la aplicación para iPad o acceder a elementos como paneles de la comunidad, propuestas y listas de tareas.

Sería bueno que hubiera una sección en la pantalla principal del iPad que contuviera los mismos enlaces que la sección "Contribuir" del menú de la web, o que de alguna otra manera alentara y apoyara a los nuevos colaboradores. No solo ayudaría a los editores como yo que solo quieren acceder a esas cosas más fácilmente, sino que también podría atraer a los lectores actuales que usan la aplicación para iPad y, por lo tanto, no reciben recordatorios regulares sobre las oportunidades de contribuir en la pantalla principal como la mayoría de los usuarios de la web. La aplicación para iPad es lo suficientemente buena ahora como para brindar una experiencia de edición realmente agradable, y creo que podría funcionar como la interfaz principal para los nuevos editores. Alternativamente, esos enlaces se podrían agregar al menú principal de la aplicación, lo que resolvería el problema de la conveniencia, pero no atraería ni alentaría a los nuevos editores.

No conozco el procedimiento para cambiar lo que se muestra en la pantalla principal de la aplicación, o si es algo sobre lo que la comunidad tiene influencia. Mis disculpas si esto ya se mencionó, o si hay razones que desconozco en términos de por qué esto no puede funcionar, o si lo estoy discutiendo en el lugar equivocado, solo sé que la edición móvil es menos común y se menciona con menos frecuencia en las discusiones sobre el apoyo a nuevos colaboradores, por lo que, como editor móvil desde hace mucho tiempo, pensé que valdría la pena mencionar un camino para brindar un mejor apoyo y alentar la edición móvil. penultimate_supper 🚀 ( discusión ) 14:09, 17 de octubre de 2024 (UTC) [ responder ]

Hacer ping a ARamadan-WMF , que ha trabajado con los equipos de la aplicación. WhatamIdoing ( discusión ) 19:38 17 oct 2024 (UTC) [ responder ]

Hola @ Penultimate supper ,

Soy Amal Ramadan, especialista sénior en comunicaciones del equipo de aplicaciones de la Fundación Wikimedia. Gracias por tu atenta sugerencia y por compartir tu experiencia de edición con nosotros. ¡Es fantástico saber que consideras que la aplicación para iPad es una herramienta valiosa para contribuir a Wikipedia!

Agradecemos sus comentarios sobre la incorporación de una sección "Contribuir" a la pantalla principal o al menú de la aplicación para iPad. Su sugerencia se alinea con nuestro objetivo de mejorar la participación de los usuarios y apoyar a los nuevos colaboradores. Ya estamos trabajando en una actualización de la navegación para la aplicación para iOS y puede seguir el progreso del proyecto aquí:

https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Navigation_Refresh

Para mejoras específicas del iPad, también tenemos un ticket épico enfocado en mejorar la experiencia del iPad. Puedes mantenerte actualizado a través de este enlace:

https://phabricator.wikimedia.org/T377283

He agregado sus sugerencias al ticket para asegurar que el equipo las considere durante las mejoras del iPad.

Mientras tanto, si encuentra más problemas o tiene sugerencias adicionales, no dude en comunicarse a través del correo electrónico de soporte dentro de la aplicación o enviarme un mensaje en cualquier momento.

-------------------------------

¡Gracias, @WhatamIdoing , por la mención! ARamadan-WMF ( discusión ) 17:16 18 oct 2024 (UTC) [ responder ]

¡Gracias! Y gracias por tu trabajo, las aplicaciones son experiencias fantásticas, honestamente mi experiencia de lectura favorita de la enciclopedia y una forma realmente sólida de editar. ¡Aprecio todo el trabajo que haces! penultimate_supper 🚀 ( discusión ) 17:32 18 oct 2024 (UTC) [ responder ]

Descripción general: Esta propuesta sugiere un bloqueo parcial de Wikipedia para los usuarios que acceden al sitio desde el Reino Unido, implementado como una medida temporal para resaltar las preocupaciones con respecto a la Ley de Seguridad en Línea de 2023. La ley requiere que los servicios adopten tecnologías de verificación o estimación y medidas más estrictas para gestionar contenido dañino pero legal, especialmente contenido accesible para niños, y se espera que OFCOM lo implemente por completo en 2026.

¿Por qué considerar una censura? El primer pilar de Wikipedia es que es una enciclopedia en línea con una misión educativa. Como tal, una censura, incluso cuando tiene como objetivo educar al público sobre una legislación potencialmente dañina, solo debería utilizarse en las circunstancias más graves. Debe ejecutarse de manera cuidadosa para alinearse con nuestra misión y evitar dañar nuestra credibilidad y reputación como un recurso educativo confiable.

Detalles del apagón propuesto:

• Implementación de la página de aviso : el apagón no será un cierre total, sino que mostrará una "página de aviso" cuando los usuarios del Reino Unido intenten acceder a Wikipedia. Esta página de aviso:
  • Mostrar información sobre la Ley de Seguridad en Línea de 2023 y sus posibles implicaciones para el libre acceso a la información.
  • Recopilar información del usuario (como la ubicación) para mostrar el alcance de la preocupación, pero lo más importante es que estos datos no se procesarán ni utilizarán más, respetando la privacidad del usuario.
  • Proporcionar una opción para que los usuarios continúen accediendo al contenido de la enciclopedia después de ver la información, garantizando así que aún tengan acceso si así lo desean.
• Sin fecha fija : esta propuesta aún no sugiere una fecha de implementación fija. Su objetivo es recopilar comentarios de la comunidad y observar las acciones de OFCOM a medida que define los requisitos específicos de la ley hasta 2026.

Fundamento: La misión de Wikipedia de proporcionar información gratuita y fiable podría verse afectada significativamente si se aplican medidas estrictas y potencialmente restrictivas sin una reflexión cuidadosa. Al adoptar un enfoque de bloqueo limitado (página de aviso), aumentamos la conciencia pública y al mismo tiempo garantizamos una interrupción mínima del acceso. Tal medida enfatizaría nuestro papel como defensores del conocimiento abierto y los derechos de los usuarios, al tiempo que equilibramos nuestros objetivos educativos.

Requisito de consenso: Dado el posible impacto en la reputación y la misión de Wikipedia, esta propuesta busca lograr el mayor consenso posible antes de tomar cualquier medida. La censura debe seguir siendo una herramienta excepcional reservada para cuestiones críticas, a fin de garantizar que conserve su eficacia y credibilidad.

Comentarios y sugerencias: comparta sus opiniones, ideas y sugerencias para perfeccionar esta propuesta. Nuestro objetivo es garantizar que cualquier acción que se tome sea bien pensada, esté alineada con nuestra misión educativa y maximice el impacto positivo tanto para Wikipedia como para sus usuarios.

El verdadero elfo (discusión) 22:29 17 oct 2024 (UTC) [ responder ]

Con el debido respeto, ¿qué quieres decir con "nuestro"? Esta es tu primera edición. Si se trata de una cuenta alternativa, los títeres de calcetín no pueden participar en el espacio del proyecto, así que si tienes una cuenta principal, inicia sesión en ella. Seraphimblade ^Háblame 23:27, 17 de octubre de 2024 (UTC) [ responder ]

Sí, esta es mi primera edición. Me equivoqué un poco. Aunque no he editado nada directamente, he hecho sugerencias en

Además, he realizado modificaciones en los datos de Wiki y tengo un artículo de Wikipedia por el que me arrepiento. Estoy trabajando en él sin conexión y lo subiré en algún momento. 2A00:23C6:C780:4901:D52A:AFC2:3B4C:1F47 (discusión) 05:42 18 oct 2024 (UTC) [ responder ]

WP:PROJSOCK no es una regla absoluta y clara según la RFC de 2021. Pero vuelva a iniciar sesión. WhatamIdoing ( discusión ) 02:10 19 oct 2024 (UTC) [ responder ]

Ah, no importa, lo escribiste con una IA, ahora que lo leo de nuevo. Palabras propias, por favor, no un chatbot. Seraphimblade ^Háblame 23:29, 17 de octubre de 2024 (UTC) [ responder ]

Lo siento por esto de la IA, solo la estaba usando como una herramienta útil para ordenar mis ideas y darles un buen formato. Tengo una dislexia severa y a veces es un salvavidas. Sin embargo, he leído todo y mantengo lo que dice. No editaría artículos de Wikipedia sin usar IA de esta manera. 2A00:23C6:C780:4901:D52A:AFC2:3B4C:1F47 (discusión) 05:53 18 oct 2024 (UTC) [ responder ]

Bueno, no edites Wikipedia de esa manera, especialmente si estás haciendo una propuesta importante. Si tienes una discapacidad, simplemente dilo, como lo hiciste. Nadie te culparía por eso, pero nos gustaría escuchar lo que tú , no un robot, tienes que decir. Seraphimblade ^Háblame 08:02, 18 de octubre de 2024 (UTC) [ responder ]

Estoy de acuerdo con el sentimiento que hay detrás de esa observación, pero el problema es que hay algunas personas que critican a las personas con discapacidad, aunque no puedan hacer nada al respecto. Puede que esas personas sean una pequeña minoría, pero la mayoría de las personas con discapacidad han estado en contacto con alguna, especialmente en Internet. Eso nos hace estar un poco alertas. Ah, y estoy totalmente en contra de todos los apagones: nadie debería presumir de hablar en nombre de los demás. Phil Bridger ( discusión ) 16:37 18 oct 2024 (UTC) [ responder ]

Esto no suena como un apagón real. Suena como una solicitud de un banner (grande) para el sitio.

(Estoy de acuerdo contigo en que revelar discapacidades puede generar quejas. También puede generar respuestas útiles). WhatamIdoing ( discusión ) 02:13 19 oct 2024 (UTC) [ responder ]

Como esto me pasó ayer por accidente, ¿por qué no lo traemos aquí? Cuando agregas una imagen a un artículo (específicamente usando el código fuente), es posible que no sepas qué tan grande será esa imagen cuando hagas clic en "publicar". Es por eso que sugiero que cuando agregues imágenes de un tamaño determinado (digamos... 7000 x 7000 px o más), antes de poder publicarlas, te dará una advertencia de que estás cargando imágenes de un tamaño que puede no cargarse correctamente en ciertos dispositivos, de modo que tal vez puedas volver atrás y cambiar la imagen o algo más. Esta diferencia es un muy buen ejemplo de por qué esto puede ser necesario. Sir MemeGod  15:59 18 octubre 2024 (UTC) [ responder ]

Puedo entender por qué esa imagen en particular podría causar un problema, pero ¿cuántas otras lo harían? ¿Tenemos cifras de cuántas imágenes desencadenarían una advertencia de ese tipo? Estas son preguntas genuinas, no retóricas. Phil Bridger ( discusión ) 16:20 18 oct 2024 (UTC) [ responder ]

No estoy seguro, pero puedo suponer que cualquier imagen que supere un cierto tamaño podría hacer que los navegadores se bloqueen, como la que he vinculado. Solo necesito averiguar cuál es ese tamaño. Señor MemeGod  16:26 18 octubre 2024 (UTC) [ responder ]

Prácticamente cualquier imagen que no esté en miniatura o sin marco no tiene ningún valor. Aaron Liu ( discusión ) 16:29 18 oct 2024 (UTC) [ responder ]

@ Sir MemeGod : No veo por qué querrías poner la imagen de tamaño completo en un artículo. Deberías usar el |thumbparámetro y, si la gente quiere ver una versión más grande, hace clic en la imagen en miniatura para llegar a la página de descripción del archivo, que no solo muestra una versión más grande, sino que también ofrece una selección de tamaños para ver. -- Red rose64 🌹 ( discusión ) 18:07 18 oct 2024 (UTC) [ responder ]

Se puede añadir una advertencia a la página de Commons, como se muestra en Archivo:Van Gogh - Starry Night - Google Art Project.jpg . CMD ( discusión ) 18:14 18 oct 2024 (UTC) [ responder ]

He iniciado una solicitud de filtro de edición. Aaron Liu ( discusión ) 04:12 19 oct 2024 (UTC) [ responder ]

Gracias, eso es exactamente de lo que estaba hablando, probablemente lo expresé mal. Señor MemeGod  23:45 19 octubre 2024 (UTC) [ responder ]

Cientos de los más de 2000 WikiProjects presentes en Wikipedia están inactivos o semiactivos. Muchos WikiProjects se superponen en su alcance, o son tan específicos que muy pocos usuarios tienen interés en participar. Incluso en el caso de los WikiProjects que abarcan una amplia red, algunos están inactivos o semiactivos. Históricamente hablando, los WikiProjects eran más activos cuando Wikipedia era mucho más joven, y hemos visto más WikiProjects volverse inactivos o semiactivos.

¿Por qué es esto un problema?

Tener WikiProyectos inactivos o semiactivos que se superponen en su alcance o que son increíblemente específicos genera confusión para los editores que buscan colaborar en un tema o buscar ayuda de otras personas familiarizadas con el tema. Además, los WikiProyectos inactivos ocupan un espacio valioso para atajos, atajos que podrían usarse para otros WikiProyectos o políticas.

Una idea para una solución

Aquí es donde me gustaría recibir la opinión de la comunidad. No está claro si la eliminación total de WikiProjects es ideal o si los WikiProjects más pequeños deberían fusionarse en otros más grandes. Tampoco está claro si se puede aplicar una solución única a todos los casos de WikiProjects inactivos.

Como ejemplo personal, existen WP:WikiProject Vancouver , WP:WikiProject British Columbia y WP:WikiProject Canada . Tanto Project Vancouver como Project British Columbia son proyectos relativamente inactivos, y Project Vancouver tiene un alcance relativamente limitado. En este caso, creo que lo ideal sería fusionar WikiProject Vancouver con WikiProject British Columbia, convirtiéndolo en un subproyecto o grupo de trabajo. — Tu Sink Cat local ( The Sink ). 20:09, 20 de octubre de 2024 (UTC) [ responder ]

La fusión en subproyectos o grupos de trabajo podría ser una buena idea, ya que de esa manera podemos mantener la estructura establecida y al mismo tiempo consolidarla en algo más fácil de seguir. En cuanto a los miembros de los WikiProyectos fusionados, ¿deberían ser agregados automáticamente al proyecto más amplio o simplemente recibir una alerta para que puedan elegir si se unen o no? La segunda opción me parece más natural.

También está la cuestión más amplia de por qué está disminuyendo la actividad de WikiProject. No soy un especialista en este tema y me pregunto si cambiaron cosas específicas que hicieron que unirse a WikiProjects fuera menos práctico o menos útil de lo que era antes. Chaotic Enby ( discusión · contribuciones ) 20:22 20 oct 2024 (UTC) [ responder ]

Bueno, los participantes del proyecto principal propuesto deberían decidir si se fusionan en los proyectos de nicho, si el proyecto está completamente inactivo. En la parte superior de la página del proyecto moribundo, se podría remitir a las personas al proyecto activo relevante. Y se podría eliminar el etiquetado de la página de discusión de proyectos muertos o reemplazarlo por el proyecto principal. Yo diría que simplemente se avise a los antiguos participantes que aún no forman parte del proyecto principal. Graeme Bartlett ( discusión ) 20:26, 20 de octubre de 2024 (UTC) [ responder ]

Las personas que están activas en las páginas no son sus dueñas. Es una cortesía invitarlas a la discusión, pero no creo que deban tener más voz y voto que cualquier otra persona. The big felly alien ( discusión ) 20:32 20 oct 2024 (UTC) [ responder ]

Los proyectos inactivos suelen marcarse como históricos y se les permite permanecer en su lugar. Ruslik _ Zero 20:39, 20 de octubre de 2024 (UTC) [ responder ]

Un WP:WikiProject no son páginas . Un WikiProject son personas . No puedes votar para que los editores se unan a un grupo diferente, como tampoco podías decirles a tus compañeros de clase con quiénes debían ser amigos cuando todos tenían 10 años.

La razón por la que las fusiones tienen que ser voluntarias es porque es la única forma en que funcionan. Podemos fusionar, redirigir y mover páginas todo el día, pero si los participantes individuales no eligen voluntariamente participar en el nuevo grupo "más grande", entonces en realidad no tendremos un grupo más grande: tendremos un montón de personas que se irán.

Hace muchos años escuché un chiste sobre la división de la Iglesia (no esperaba que fuera un enlace rojo) que decía así: La iglesia tuvo una pelea sobre si los nuevos libros de himnarios debían tener una cubierta roja o una cubierta azul. Al final, el 10% de ellos se separaron para formar una iglesia con libros rojos, el 10% formó una iglesia con libros azules y el 80% de ellos se disgustaron tanto que dejaron de ir a la iglesia. Tal vez esto solo parezca un resultado plausible si eres del Sur , pero no queremos que ningún participante de WikiProject se disguste tanto que abandone Wikipedia, o incluso que deje de ver las páginas de WikiProject.

En consecuencia, hemos establecido un procedimiento para fusiones voluntarias. Básicamente, se presenta una oferta y se espera un mes para ver si alguien se opone. Si alguien se opone, se detiene la operación. Si no, se procede a la fusión. Calculo que hemos tenido objeciones aproximadamente el 10% de las veces, por lo que rara vez interfieren en el resultado final. WhatamIdoing ( discusión ) 03:44 21 oct 2024 (UTC) [ responder ]

Creo que la razón por la que hay tantos Wikiproyectos inactivos es simplemente que nadie se ha molestado en hacer algo al respecto. Sin duda, yo, y probablemente la mayoría de los demás editores, lo consideramos una prioridad bastante baja. Phil Bridger ( discusión ) 20:50 20 oct 2024 (UTC) [ responder ]

He fusionado algunos proyectos en los que participé debido a la superposición de alcances, incluidos dos recientemente. Ni siquiera es tan difícil lograr un consenso, pero nadie quiere molestarse. Si hay un proyecto específico que te molesta, simplemente propónlo. PARAKANYAA ( discusión ) 21:46 20 oct 2024 (UTC) [ responder ]

La fusión de WikiProjects aparece en la página de discusión del Consejo de WikiProjects. La discusión más reciente se puede ver en Wikipedia discusión:Consejo de WikiProjects/Archivo 26 § Fusión sistemática de WikiProjects . Anteriormente, el único conjunto de instrucciones era para convertir un WikiProject en un grupo de trabajo , lo que podría estar preservando más infraestructura de la necesaria si el WikiProject está inactivo. WhatamIdoing inició Wikipedia:Consejo de WikiProjects/Guía/Fusión de WikiProjects como un primer paso en las instrucciones para fusionar un WikiProject sin convertirlo en un grupo de trabajo. Para bien o para mal, a menudo hay resistencia a implementar fusiones, como se puede ver al final de la discusión archivada a la que hice referencia. (Dé algunas de mis ideas sobre por qué los WikiProjects podrían no estar atrayendo participantes en esa discusión). isaacl ( discusión ) 21:55, 20 de octubre de 2024 (UTC) [ responder ]

Debería volver a esa página. @ Joe Roe estaba trabajando en una fusión y necesitamos más información sobre las plantillas. La gente de TFD ha sugerido que serán generosos con sus bots que reemplazan las plantillas, pero necesitamos escribir un procedimiento para ello, para que la gente sepa qué hacer.

@Sink Cat , por favor, considera poner Wikipedia talk:WikiProject Council en tu lista de seguimiento. Ahí es donde se discute mucho de esto. En términos del concepto general, creo que deberíamos aspirar a un mundo en el que haya muchos menos WikiProjects activos, pero mucho más grandes (en promedio), pero todo sucede paso a paso. El mayor desafío es que nadie está haciendo el trabajo. Simplemente revisar 2000 grupos para producir una recomendación sobre cómo fusionarlos podría ser un trabajo de tiempo completo durante un mes, y luego cada grupo debe ser contactado con mensajes personalizados para explicar la idea, nombrar los objetivos y preguntar si están dispuestos. Si alguien quiere pasar, digamos, 20 horas / semana durante el próximo año haciendo esto, entonces sería genial, pero esa es la escala de la que estamos hablando. WhatamIdoing ( discusión ) 03:55, 21 de octubre de 2024 (UTC) [ responder ]

¡Gracias por la respuesta! Me pondré en contacto con ellos para ver qué se puede hacer. — Tu Sink Cat local ( The Sink ). 04:11, 21 de octubre de 2024 (UTC) [ responder ]

¿No estás seguro a quién te refieres cuando dices "ellos"? Ten en cuenta que la palabra "consejo" es un poco engañosa: en esencia, se trata del WikiProject. isaacl ( discusión ) 05:12 21 oct 2024 (UTC) [ responder ]

Me hago eco de esto: es posible lograr un consenso para las fusiones, pero es un proceso lento y que requiere mucho tiempo. Sé que tengo algunas pendientes porque hay que esperar 30 días después de abrir una discusión para ponerla en práctica (con bastante sensatez) y, a menudo, descubro que 30 días después realmente no tengo tiempo para hacerlo. –  Joe  ( discusión ) 08:22, 21 de octubre de 2024 (UTC) [ responder ]

Por casualidad, mientras hacía otro trabajo en páginas anteriores a 2006, me di cuenta de Bernard Lee , que, debido a un editor de IP, parecía un borrador, a pesar de estar catalogado como GA. No estoy muy seguro de cuál era la intención de su edición, pero eliminaron parte del marcado de comentarios, lo que provocó que la mayor parte del artículo quedara oculto. ¿Hay alguna forma de etiquetar instancias en las que esto sucede mediante un filtro de edición o algo similar? Podría imaginarme a alguien tal vez más malintencionado haciendo esto intencionalmente que, de lo contrario, probablemente simplemente dejaría la página en blanco o eliminaría grandes partes, lo que ya está más o menos mitigado por las medidas actuales. Akaibu ( discusión ) 22:04, 20 de octubre de 2024 (UTC) [ responder ]

Creo que aquí hay dos cosas distintas: un filtro de edición para detectar nuevas ediciones que resulten en un comentario HTML sin cerrar. No sé si existe, pero Wikipedia:Edit filter/Requested es el lugar para solicitarlo si no existe.

Lo segundo es comprobar si existen páginas con comentarios sin cerrar, lo cual parece ser el tipo de cosas para las que sería útil un informe de Wikipedia:Base de datos. Wikipedia talk:Informes de bases de datos es el lugar donde solicitar uno.

En ambos casos, un comentario cerrado correctamente después de uno abierto podría causar falsos negativos, pero supongo que la detección <!-- […] <!-- […] -->los detectaría. Thryduulf ( discusión ) 22:30 20 oct 2024 (UTC) [ responder ]

También puede ser útil detectar comentarios muy grandes, pero es probable que muchos de ellos se inserten deliberadamente, por lo que la idea de Thryduulf suena mejor. Graeme Bartlett ( discusión ) 09:52 21 oct 2024 (UTC) [ responder ]

Tema relacionado en phab:T304222. — xaosflux ^Discusión 15:06, 21 de octubre de 2024 (UTC) [ responder ]

Por cierto, Markdown es un lenguaje de formato que no utilizamos. Usamos Wikitext. Aaron Liu ( discusión ) 16:30 21 oct 2024 (UTC) [ responder ]

Tengo una idea para construir un modelo de inteligencia artificial de código abierto entrenado en Wikipedia y disponible de forma gratuita en la plataforma Wikipedia, ya que las nuevas generaciones tienen menos capacidad de atención y necesitan hacer las cosas rápidamente. Quiero que sea de código abierto para que pueda ser utilizado por la comunidad y que los colaboradores se inspiren en él. Yassinsamirhegazy ( discusión ) 13:22, 21 de octubre de 2024 (UTC) [ responder ]

Hola, el contenido de Wikipedia está protegido por CC BY-SA 4.0 , por lo que puedes usar el corpus para entrenar un modelo de IA si lo deseas, siempre que lo publiques bajo una licencia compatible. En cuanto a tenerlo disponible en Wikipedia, esto podría no ser necesariamente una buena idea, ya que los modelos de IA son propensos a las alucinaciones, y un modelo entrenado con los contenidos de Wikipedia en un momento dado no será editable como la enciclopedia misma. Chaotic Enby ( discusión · contribuciones ) 13:48, 21 de octubre de 2024 (UTC) [ responder ]

Entiendo tu punto, pero este modelo de IA puede ser solo un comienzo para hacer frente a la nueva generación de audiencia 41.46.109.7 (discusión) 14:06, 21 de octubre de 2024 (UTC) [ responder ]

¿Has considerado que todos los principales LLM de chatbots ya han incluido Wikipedia en su corpus? Remsense  ‥ 论14:38, 21 de octubre de 2024 (UTC) [ responder ]

Tenga en cuenta que muchos wikipedistas desconfían más o menos de la IA, y algunos han estado abogando por la prohibición de cualquier uso de la IA en Wikipedia. Si bien considero que una prohibición no se puede hacer cumplir, me gustaría que los editores evitaran usar cualquier IA sin verificar y corregir con mucho cuidado todo el resultado de la IA, lo que bien podría suponer más trabajo que simplemente escribir contenido sin usar una IA. Donald Albury 14:44, 21 de octubre de 2024 (UTC) [ responder ]

Sí, lo he considerado, pero quiero agregar esta característica para que la gente pase más tiempo en Wikipedia. Yassinsamirhegazy ( discusión ) 17:23, 21 de octubre de 2024 (UTC) [ responder ]

Queremos que los lectores sean útiles, no que participen. Aaron Liu ( discusión ) 17:31 21 oct 2024 (UTC) [ responder ]

ChatGPT, Ollama y prácticamente todas las plataformas importantes ya lo hicieron. Aaron Liu ( discusión ) 14:44 21 oct 2024 (UTC) [ responder ]

<- Por si fuera poco, el modelo PaperQA2 de FutureHouse ya está igualando o superando a los expertos en la materia en la creación de artículos que resumen temas científicos en un dominio muy específico. Véase Los agentes del lenguaje logran una síntesis sobrehumana del conocimiento científico. Sean.hoyland ( discusión ) 14:53, 21 de octubre de 2024 (UTC) [ responder ]

Además, las personas (con menos capacidad de atención) ya pueden interactuar con el contenido de Wikipedia utilizando el experimento NotebookLM de labs.google. Sean.hoyland ( discusión ) 15:10 21 oct 2024 (UTC) [ responder ]

Sé que los editores deberían procurar mantenerse imparciales, pero parece que en temas polémicos podemos acabar con un bando que consiga inclinar el artículo hacia su punto de vista. Podemos acabar con la mitad de los editores diciendo "Este artículo está perfectamente bien" y la otra mitad diciendo "Hay grandes problemas de punto de vista, aquí están..."

La parte que esté satisfecha con el sesgo puede trabajar activamente para evitar cualquier corrección a la página para abordar el sesgo, mientras que simultáneamente bloquea la adición de una etiqueta NPOV a la página.

Parece que si la mitad de los editores dicen "está bien" y la otra mitad dice "hay grandes problemas", esto es extremadamente indicativo de un problema de punto de vista, incluso si no hay consenso de que exista uno.

Entonces, me pregunto si debería haber una exención a la restricción de consenso requerido y si algún tipo de masa crítica por debajo del consenso debería ser suficiente para permitir la etiqueta NPOV.

¿Qué opinas? Bob drobbs ( discusión ) 18:48 22 oct 2024 (UTC) [ responder ]

Poner el {{ POV }} nunca debería ser un objetivo final. El objetivo debería ser solucionar el problema, y ​​añadir el banner con frecuencia no proporciona ningún beneficio práctico. Imagine un artículo totalmente no neutral sobre un artículo bajo la restricción Wikipedia:Consenso requerido . Tal vez sea un artículo llamado 2+2 . El artículo dice que 2+2 se entiende generalmente como igual a cuatro, pero hay una minoría significativa de matemáticos respetables que dice que 2+2=5 . Esta es la historia que parece que quiere:

• Alice agrega una etiqueta {{ POV }} .
• Eva lo elimina porque no está de acuerdo.
• La discusión en la página de discusión sobre la etiqueta termina en un punto muerto. Debido a las reglas de "consenso requerido", la etiqueta normalmente no se agregaría, pero debido a la excepción recientemente creada, la etiqueta se puede agregar.
• Resultado final: el artículo está etiquetado, pero sigue estando tremendamente desequilibrado.

Aquí está la historia que necesitamos:

• Alice agrega una etiqueta {{ POV }} .
• Eva lo elimina porque no está de acuerdo.
• La discusión en la página de discusión sobre la etiqueta termina en un punto muerto. Debido a las reglas de "consenso requerido", la etiqueta no se agrega.
• Alice decide dejar de preocuparse por la etiqueta y empezar a preocuparse por el contenido del artículo. Los usuarios habituales de la página de discusión no pueden llegar a un acuerdo satisfactorio, por lo que lleva la disputa a un tablón de anuncios pertinente o inicia una RFC.

Recuerda: las etiquetas de mantenimiento no son insignias de vergüenza. No existen para "advertir al lector" ni para expresar formalmente tu desacuerdo con el artículo. Existen con la esperanza (en su mayoría vana) de que los editores arreglen el contenido del artículo. Si puedes arreglar el contenido del artículo sin una etiqueta, entonces todos ganan. Si no puedes arreglar un artículo (etiquetado o no), entonces lee Wikipedia:Resolución de disputas . WhatamIdoing ( discusión ) 19:05, 22 de octubre de 2024 (UTC) [ responder ]

Depende… ¿cuántos hay en cada “lado” del debate?

Si hay varios editores en cada “lado”, entonces no creo que podamos decir que realmente existe un consenso (en ninguna dirección). Sin embargo, si se trata de uno o dos editores descontentos contra muchos, entonces podemos decir que hay consenso, y que ese consenso no requiere unanimidad. Blueboar ( discusión ) 19:08 22 oct 2024 (UTC) [ responder ]

El nombre que utilizamos para Wikipedia:Notabilidad ha sido durante mucho tiempo una fuente de confusión. La gente puede adivinar el concepto básico de muchas políticas y pautas a partir del significado en inglés sencillo del título (por ejemplo, Wikipedia:Fuentes confiables son fuentes en las que se confía ; Wikipedia:Violaciones de derechos de autor trata sobre violaciones de derechos de autor, etc.), pero este tiene un significado bastante diferente. Puedes tener varias fuentes que digan directamente que ____ es un músico notable, y responderemos que no lo es. WP:Notable .

Me gustaría hacer una lluvia de ideas sobre algunas frases alternativas que podrían usarse en lugar de "notabilidad", o como complemento de ella, que serían menos confusas para las personas que no están familiarizadas con nuestra jerga interna.

De Wikipedia:Glosario :

NN, no notable

Abreviatura que se encuentra en los comentarios de Wikipedia:Artículos para eliminar y en los resúmenes de edición, que indica que el tema del artículo no es lo suficientemente importante como para incluirlo en una entrada de Wikipedia. Un tema no es importante si los editores acuerdan no incluir un artículo sobre él. Su decisión suele basarse en cuestiones como no encontrar suficientes fuentes fiables para escribir un artículo de enciclopedia decente, pero también puede basarse en cuestiones como el deseo de presentar un tema pequeño como parte de uno más grande.

Notabilidad , Notable

Característica que poseen los temas de los artículos y que califican para artículos independientes. Un tema notable es aquel que "es adecuado para un artículo o lista independiente cuando ha recibido una cobertura significativa en fuentes confiables que son independientes del tema". Tenga en cuenta que la "notabilidad" es una propiedad de un tema y no tiene nada que ver con la calidad de un artículo o con la existencia de un artículo sobre el tema.

De una discusión reciente :

• Palabras para el concepto: criterios, concepto, prueba, calidad, cualidades, requisitos, notabilidad, directriz, umbral, cuándo crear un artículo
• Palabras para el resultado: artículo independiente, artículo independiente, página independiente, tema independiente, tema nuevo, página propia, creación de artículo, idoneidad del artículo, inclusión
• Algunas ideas específicas:

Si quieres ver algunas de las ideas anteriores, puedes ampliar el cuadro. Está contraído porque algunas investigaciones sobre las ideas de lluvia de ideas sugieren que mirar las ideas de otras personas puede reducir la cantidad total de ideas compartidas. ¡No hay problema con las ideas duplicadas!

Por favor, comparte tus ideas aquí. Incluso una idea "mala" puede inspirar a la siguiente persona a pensar en otra opción. WhatamIdoing ( discusión ) 21:04 22 oct 2024 (UTC) [ responder ]

I had also been thinking about this. The core issue, in my opinion, is that we're trying to describe as "notability" something that is closer to "for someone/something to have an article, they should be well-documented in reliable sources". At its core, the term "notability" carries more of a connotation of relative importance, leading to a lot of newcomers, and sometimes even other users, being misled as to what makes a topic notable. On the other hand, the actual guidelines describing it focus on the existence of reliable sources about the topic, with importance only being used by some guidelines as a proxy for these sources being likely to exist.

A word like well-sourced or well-documented would carry this idea better, without the a priori of "importance/fame is what matters" that "notability" carries. Chaotic Enby (talk · contribs) 21:13, 22 October 2024 (UTC)[reply]

Lots of topics are documented by primarily primary sources (eg like many news event), but we require coverage by secondary sources, so those would worsen the situation. — Masem (t) 21:20, 22 October 2024 (UTC)[reply]

Good point, although it could still be a first start, and no word can fully convey our notability guidelines either. Maybe encyclopedically sourced could help convey the fact that not any source works? Or, as you employ the term "coverage", we could make the difference between (primary) documentation and (secondary) coverage and call it well-covered? Chaotic Enby (talk · contribs) 21:27, 22 October 2024 (UTC)[reply]

Chaotic Enby: I am still chewing over all this. I fear that encyclopedically sourced could be easily misunderstood and potentially lead to more newbies trying to cite Wikipedia itself. I really don't have a sense of how well people outside Wikipedia and academia understand the distinctions between primary, secondary, and tertiary sources. I think well-covered does capture the essence of what we're trying to convey without causing more confusion. — ClaudineChionh (she/her · talk · contribs · email) 23:42, 22 October 2024 (UTC)[reply]

I'd say that people outside the wiki-verse and academia understand primary/secondary/tertiary "not at all", and I'd say that people in the wiki-verse understand the distinction "poorly". Editors struggle with WP:PRIMARYNEWS, especially when it comes to the question of notability ("But event is obviously important, so obviously this breaking news article is secondary"), and most of them could not explain why Wikipedia:Secondary does not mean independent. WhatamIdoing (talk) 00:17, 23 October 2024 (UTC)[reply]

Masem, the GNG requires secondary sources, but NPROF does not. Both are still wiki-notable. We therefore need a handle for this concept that does not assume the GNG approach. WhatamIdoing (talk) 00:13, 23 October 2024 (UTC)[reply]

I like “When to create an article”. SmokeyJoe (talk) 21:22, 22 October 2024 (UTC)[reply]

I caution against this because as it is used now, notability is not used as a check at new page review, and primarily is a method used for evaluating whether to delete an article at AFD. We should have an advice page with that title about how to make sure you have a good topic and reviewing the notability of the topic is a good starting point as part of it. — Masem (t) 21:35, 22 October 2024 (UTC)[reply]

So "When to have an article"? WhatamIdoing (talk) 00:18, 23 October 2024 (UTC)[reply]

“When to have a separate article”?

A nod to WP:Structurism as an existing concept. Also a hint that newcomers should add content to existing article, and no be trying to add a new orphan topic as their first contribution.

- SmokeyJoe (talk) 02:12, 23 October 2024 (UTC)[reply]

• I'm inclined to something like "stand-alone topic criteria" (to clarify that the point is determining whether a topic warrants a stand-alone article) or, in a similar vein, "when to create an article" (or possibly "when it can be appropriate to create an article", since in occasional cases it can be appropriate to cover a small number of closely related topics that could be notable in the same article rather than separately). I do agree with the notion that notability isn't the best name for this guideline and that having a term that's more like plain English. Hydrangeans (she/her | talk | edits) 21:26, 22 October 2024 (UTC)[reply]
• I like "stand-alone article criteria" as it is focused on when to create an article. --Enos733 (talk) 21:28, 22 October 2024 (UTC)[reply]
• Maybe something like suitable topics or suitable article topics would work. That implies the existence of editorial judgement and that some topics simply aren't suitable. User:Chaotic Enby, this was inspired by your idea of "well-sourced", which has the potential to be confused with well-cited (i.e., the number of refs in the article right now, rather than the number of sources in the real world). WhatamIdoing (talk) 00:21, 23 October 2024 (UTC)[reply]

  From all the suggestions so far, this seems the most understandable so far. It's short, it communicates that some things are excluded and that there is 'judgement' involved. —TheDJ (talk • contribs) 09:46, 23 October 2024 (UTC)[reply]

  I really like this, because (1) it removes the emotional pain of being deemed "not notable", and (2) it avoids the confusion we currently have of subjects that are notable but about which we cannot have a meaningful article. To clarify: (1) AfD and Teahouse waste a lot of time trying to explain to upset people that Wikipedian notability has nothing to do with importance, creativity, or future value to humanity. We could save a lot of trouble by focusing on the objective need for sources rather than the subjective view of importance. (2) Notability is currently only half of the two tests we need to pass: We can't have an article unless the subject is notable and someone's written something about it for us to summarise. We have a lot of guidelines that say "XXX is generally considered notable", which result in unexpandable stubs because although it can be demonstrated from primary sources that two old ladies and a chicken once lived near a railway siding in Ohio (making it a genuine inhabited settlement), there is now nothing there, and no one has ever written anything about it, or ever will. Focusing on what is necessary to create an article would cut to what actually matters, practically, rather than getting tied up in legalistic debates about what constitutes a notable thing. Elemimele (talk) 16:14, 23 October 2024 (UTC)[reply]

  But all too often, we get the argument that we should have an article on XXX because sources exist, even though no one has demonstrated the existence of such sources. Attempts to add the requirement that reliable sources must be cited to create or keep an article have been repeatedly rejected. I would support replacing "notability" with something like "specific topics are suitable for articles if they are well-sourced, NPOV, and meet certain broad topic requirements (i.e., replacements for SNGs)". Donald Albury 17:32, 23 October 2024 (UTC)[reply]

  @Donald Albury, do you mean that topics are suitable/notable if they're neutral, or do you mean that articles are suitable/notable if they're neutral? I'm not sure if you mean that you want to repeal WP:NRVE and expand the deletion policy to say that a (deserved) {{POV}} tag is grounds for deletion, or if you mean that citing sources in a neutrally written article must be possible, even if it hasn't happened yet (including for many years). WhatamIdoing (talk) 17:44, 23 October 2024 (UTC)[reply]

  I was just trying to express that availability of reliable sources is required, but not sufficient, and that other policies and guidelines also must be met for an article to be suitable for inclusion in WP. Donald Albury 18:30, 23 October 2024 (UTC)[reply]

  I do like suitable much better than notable (and came here to suggest it). It's more accurate, but still gives some flexibility in definition, where something like well documented might be open to misinterpretation / lawyering. Folly Mox (talk) 17:50, 23 October 2024 (UTC)[reply]

  Suitable / Suitability is the first suggest I like, it helps show that this is a Wikipedia stand not a general idea. -- LCU ActivelyDisinterested «@» °∆t° 20:23, 23 October 2024 (UTC)[reply]

  Thanks a lot! I do very much like suitable topics (suitability?) too, as it is broad and flexible enough to cover our various policies on the topic. Chaotic Enby (talk · contribs) 19:26, 23 October 2024 (UTC)[reply]

  @Seraphimblade also deserves credit for this idea, since a comment from him is the source of "article suitability" in the list above.

  I'm leaning a bit towards "topics" (or "subjects"?), because "articles" could be argued to exclude lists, and because of the endless problem of "it's not notable because the article's quality is currently too low". WhatamIdoing (talk) 02:13, 24 October 2024 (UTC)[reply]

  I like that a lot. On Wikipedia, a suitable topic for an article is one where either sufficient reliable, independent sources can be found or which meets the criteria outlined in a subject-specific suitability guideline (SSG)... – sounds both more understandable and closer to how we actually decide whether or not to keep articles, in practice. – Joe (talk) 08:02, 25 October 2024 (UTC)[reply]

• Just to throw out an idea that I think can minimize disruption, is to consider a comparable situation to the relatively recent rename of of the old Naming Convention page to WP:Article Titles while specific advice of naming for various fields are still at "Naming Convention". In that same vein, if the GNG was moved to its own page (thus sitting alongside the sepearate SNG pages) and what's left at WP:N left there, then renaming that leftover to some of the suggestions above would still allow us to keep the principle of notability via the GNG and SNG while having a better landing page at a more familiar term and to explain the GNG and SNG functions within that. It would minimize a mass edit on p&g pages. The GNG and SNGs can be described as tests used on Wikipedia to measure how notable (real world definition) a topic is within the suitability on an encyclopedia. Masem (t) 18:11, 23 October 2024 (UTC)[reply]

  There might be some advantages to splitting the GNG out onto its own page, but I think that might need to be a separate discussion. WhatamIdoing (talk) 18:36, 23 October 2024 (UTC)[reply]

  Well, in terms of providing g a word that is closer to the real definition for our practice related to when a topic is suitable for it's own article, treating the existing idea of notability through the GNG and SNGs as is and focusing on a clear word for the broad concept is a clean solution. Masem (t) 19:39, 23 October 2024 (UTC)[reply]

  The issue is that GNG is about how well-documented the topic is in independent secondary sources, which doesn't necessarily map to real-world notability, and using the latter word for it has been just as much source of confusion. Chaotic Enby (talk · contribs) 19:45, 23 October 2024 (UTC)[reply]

  We can frame the GNG and SNGs as semi objective, source based tests to evaluate real-world notability, and establih in the top level guideline that one reason to allow a topic to have an article is via demonstrating real world notability using the GNG and SNGs tests. That moves us away from having notability take the wiki definition. We still need a clear understandable title for the top level guideline, and that would also discuss more that the GNG and SNGs, such as the current NLIST advice. — Masem (t) 16:55, 24 October 2024 (UTC)[reply]

  The issue is, basing article suitability on real-world notability is a very iffy definition. GNG (and to a lesser extent the SNGs) provide us with a better foundation for defining what is suitable for our encyclopedia, which is quality of independent secondary sourcing. "This person is important" is ultimately a less relevant criterion than "this person has enough secondary sources to write an article about them", if our goal is to write an encyclopedia (tertiary source, i.e. relying on secondary sourcing). Chaotic Enby (talk · contribs) 17:02, 24 October 2024 (UTC)[reply]

  Consider that several of the SNG do give measure of real world notability based on claims of importance which can be given by a single reliable primary source, the expectation they can be expanded. The key is that with a tiny bit of rewording of the GNG and SNGs are set as the evaluation of real world notability with the expectation of sourcing and coverage required for an encyclopedia, either which establishes one way a topic is suitable for a stand alone article. Masem (t) 17:35, 24 October 2024 (UTC)[reply]

The reality is that wp:notability is the operative word for "allowed to have a separate article" and the talisman for the fuzzy ecosystem/process which decides that. It incorporates with wp:notability guidelines, degree of compliance with WP:not (a measure of the degree of enclyclopedicness of the article) and a bit of influences from real world notability/importance. Any term needs to acknowledge this. If one tries to base it on summarizing just what the wp:notability guidelines say, IMO it won't work. Sincerely, North8000 (talk) 02:00, 24 October 2024 (UTC)[reply]

So WP:What topics are allowed to have a separate article? WhatamIdoing (talk) 02:10, 24 October 2024 (UTC)[reply]

Yes. And the strongest consideration in it would be wp:notability per the notability guidelines, but the above other factors described above are also a part of that consideration. North8000 (talk) 15:31, 24 October 2024 (UTC)[reply]

I prefer to see a more obvious name for the guideline for article creation. Something such as like "Guideline for article creation" would be more obvious. TFD (talk) 16:21, 24 October 2024 (UTC)[reply]

Agree. My point was agreeing with the structure/content. If we want this to have legs, we'll need something with an even shorter with a good acronym for it. North8000 (talk) 17:08, 24 October 2024 (UTC)[reply]

My concern about WP:Guideline for article creation is that I would expect the advice on a page with that name to overlap considerably with Help:Your first article. There's more to article creation than identifying whether this is a suitable/acceptable/appropriate/notable topic for an article. WhatamIdoing (talk) 17:17, 24 October 2024 (UTC)[reply]

• Procedural request I don't mean to gum up the process. But there's a risk of having 100 different ideas from 99 different editors, which can make it difficult to reach a consensus. Whenever this brainstorming step is over, I want to recommend compiling them into a list, sorted by some type of subcategory. That way we can slowly funnel our way towards something that can earn a consensus. I believe you'd probably find (at least) three or four types of names:

• Non-descriptive (compare WP:NOT or WP:SIZE): inclusion criteria, inclusion test, article creation threshold, etc.
• Type of outcome (compare WP:DISAMBIG or WP:STANDALONELIST): separate article, stand-alone article, separate page
• Standard of sources (compare WP:RELIABLE or WP:VERIFIABLE): independent sources, third party sources
• Standard of coverage (compare WP:OR or WP:COPYRIGHT): significant coverage, minimum coverage, coverage threshold

I lean towards something more descriptive, because "inclusion criteria" just shifts the complaints from "Wikipedia has an arbitrary definition of notability!" to "Wikipedia has an arbitrary list of inclusion criteria!" Newcomers and outsiders notoriously don't read passed the headline, or even twist ambiguity in bad faith to attack Wikipedia with misinformation campaigns. It would help the project much more if the guideline title summarized an uncontroversial standard for our encyclopedia. (Currently: if no reliable, independent sources can be found on a topic, then it should not have a separate article. or A topic is presumed to be suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject.) Shooterwalker (talk) 17:24, 24 October 2024 (UTC)[reply]

I agree that "inclusion criteria" could shift the complaints from "Wikipedia has an arbitrary definition of notability!" to "Wikipedia has an arbitrary list of inclusion criteria!" However, the current name has an additional problem, namely "I have three Wikipedia:Reliable sources that WP:Directly support a claim that this subject is 'notable', so why are you claiming that it's non-notable?" That problem would go away with a name like "inclusion criteria". WhatamIdoing (talk) 19:57, 24 October 2024 (UTC)[reply]

We do have arbitrary criteria, though. All the WP:SNGs are arbitrary. The WP:GNG is arbitrary in what it considers "significant", "reliable", and "independent". Individual decisions on articles are arbitrary in how these guidelines are interpreted and how strictly they are applied. It's better to be open about that than pretend, like too many 'notability theorists' do, that we've come up with a 350 word rubric that objectively divides all of human knowledge into worthy and unworthy. I think most people can understand that to make a large project like this manageable, you have to agree on some boundaries – and respect them, even if they don't agree with them. – Joe (talk) 08:18, 25 October 2024 (UTC)[reply]

Except we do also have rubrics, and we also have to work together, so we have found it necessary to define together. There's boundaries, you say? What are they? We have to go about answering that question together. -- Alanscottwalker (talk) 11:20, 25 October 2024 (UTC)[reply]

Yes, that's what I'm saying. WP:GNG and the WP:SNGs are the boundaries we've arrived upon. They aren't objective, they're arbitrary and subjective, but that's okay. – Joe (talk) 11:31, 25 October 2024 (UTC)[reply]

While many people have made contributions to history (many more than could fit in one timeline), it's undoubtable that some people's influence far exceeds that of others. 

Therefore, I think we should have a timeline of the significant figures in history. 

I completely understand that determining how significant some people are is a difficult task. It's expected to take struggle and effort to make this work. However, people deserve to know who made the greatest contributions to the advancement of humanity.

Also, many scholars themselves have written about who they believe are to be the most significant people.

I have created a sketch of this idea at User:Wikieditor662/sandbox. It's far from perfect, but you get the main idea. The people are colored based on the era they were in. The most significant people make it to the overview and those who are not as important but still nonetheless significant (as well as people born earlier so the overview doesn't get clumped) go to the individual timelines (below the overview) along with those in the overview.

I would again like to reiterate that this is something that is going to take effort, dedication, and much debate, but if we do this, then I think it could be worth it. What do you all think?

Wikieditor662 (talk) 20:34, 23 October 2024 (UTC)[reply]

Kindly, I'm experiencing philosophical opposition to this project. History has been a team effort, and further elevation of the already elevated is not likely to improve genuine understanding of historical processes. The Great man theory correctly fell out of fashion early last century.

Having said that, I don't mean to dissuade you from undertaking a project you're clearly interested in, and this seems like it could serve as some kind of subpage of WikiProject Vital Articles. Using the inclusion criterion "listed at WP:VA" is probably the only way you'd ever develop any kind of agreement as to which historical figures to include. That WikiProject has already done a lot of debating over which topics are more important than others.

The periodisation scheme is pretty parochial and Eurocentric, and would have to be converted to numeric year spans or whatever schema WP:VA uses (and the section headings would have to be delinked per MOS:NOSECTIONLINKS). You'll also want to consider how to handle cases where vital dates are approximate, unknown, disputed, etc. Folly Mox (talk) 00:12, 24 October 2024 (UTC)[reply]

I would tend to agree with Folly Mox on this. I'll add that it might be pretty much impossible to find an actual inclusion criteria, that is, any kind of consensus in reliable sources as to who is a significant enough figure – or even if we can compare the significance of historical figures across times, cultures, and domains. If anything, that page will inform more about our own selection than about any historical truth behind it.

However, having it as part of WP:VA, rather than as an encyclopedic article, could make it a pretty useful reference for articles about famous figures needing improvement, without claiming that these are necessarily the most significant ever. Chaotic Enby (talk · contribs) 01:07, 24 October 2024 (UTC)[reply]

That sounds like a giant pile of WP:OR – Joe (talk) 12:26, 24 October 2024 (UTC)[reply]

Is there any reason we aren't or can't scrape and extract basic cite template information (webpage title, domain, visited datetime) at submit-time from bare URL <ref>s? Personally, I use bare URLs all the time as I consider filling out the cite template the most emphatically tedious part of editing WP (as it is when writing scholarly manuscripts) and know that some robot editor will just come along and fix it for me anyway. Since the code already exists and could be done more efficiently server-side, why don't we just pull it into the WP core? Just a small and probably extant idea I had while feeling a little guilty for adding a bare <ref> to a nicely-formatted article with proper tag attributes and template use. Cheers, fellows. Elliott-AtomicInfinity (talk) 01:38, 24 October 2024 (UTC)[reply]

This is what mw:Edit check is getting to AFAIK. Aaron Liu (talk) 02:18, 24 October 2024 (UTC)[reply]

@Trizek (WMF) will know if they're going beyond "prompt to add a ref" to "try to format the ref". WhatamIdoing (talk) 20:03, 24 October 2024 (UTC)[reply]

Not quite what you are looking for, but there is reFill for bare URLs, and Wikipedia:Citation expander for when the URL is within <ref> ... /ref>. You can save your edit, and then immediately run those tools. As always, the output of any such tool must be reviewed and verified. Donald Albury 14:32, 24 October 2024 (UTC)[reply]

Or use the visual editor, or use the ref filler in the 2010 wikitext editor's toolbar. Or maybe even embrace the idea that everyone contributes in different ways, and that WP:CITE means what it says about doing your best to accurately communicate what your source is, and that editors can, do, and should work together on the formatting. WhatamIdoing (talk) 20:01, 24 October 2024 (UTC)[reply]

It took me far to long to realise you can auto-fill citations from the toolbar, I fear I'm not the only one as it's not well advertised. -- LCU ActivelyDisinterested «@» °∆t° 20:12, 24 October 2024 (UTC)[reply]

Nice, but it doesn't always work. It is particularly annoying when I'm trying to cite something that I have accessed through the Wikilibrary (with a long list of authors) and it doesn't work, and I am unable to go to the non-Wikilibrary page for the article. Donald Albury 20:26, 24 October 2024 (UTC)[reply]

It is indeed unfortunate that many websites do not properly mark up their pages so that the automated tools and Zotero etc are unable to extract the appropriate information from webpages. But that is a problem that we cannot really solve. —TheDJ (talk • contribs) 20:48, 24 October 2024 (UTC)[reply]

Recently (1-2 months back?) I saw a project to improve the automated tools (or maybe just one tool), iirc by adding local code for specific commonly cited websites it consistently gets wrong. Unfortunately I can't find the discussion now, but if someone remembers it (user:WhatamIdoing?) you may be interested. Thryduulf (talk) 22:48, 24 October 2024 (UTC)[reply]

Thryduulf, are you thinking of Wikipedia:Village pump (proposals)/Archive 213 § Deploying Edit Check on this wiki (August 2024)? Folly Mox (talk) 23:35, 24 October 2024 (UTC)[reply]

No, this was about better (more complete, more correct) automated filling of source metadata (author, publisher, title, etc) when a reference is added. Thryduulf (talk) 00:01, 25 October 2024 (UTC)[reply]

m:Web2cit? * Pppery * _{it has begun...} 00:41, 25 October 2024 (UTC)[reply]

Creo que esa era la herramienta, pero estoy seguro de que la discusión se centró en en lugar de en meta (la capitalización canónica, por cierto, es Web2Cit) . Thryduulf ( discusión ) 01:25, 25 de octubre de 2024 (UTC) [ responder ]

Realmente necesito mejorar en la verificación de mis enlaces. *Pppery* _{ya comenzó...} 03:09, 25 de octubre de 2024 (UTC) [ responder ]

La otra herramienta principal de enwiki que formatea citas es User:Citation bot . *Pppery* _{ha comenzado...} 03:09, 25 de octubre de 2024 (UTC) [ responder ]

¿Qué tal Wikipedia Talk:Citar fuentes § generador de citas? (septiembre de 2024)? Folly Mox ( discusión ) 11:51 25 oct 2024 (UTC) [ responder ]

Ah, cierto, y supongo que el hilo "Edit Check" tenía primero un subhilo tangencial sobre mejores metadatos, incluida la adición de una capa de traducción local a Citoid como se invoca desde la interfaz del Editor visual, pero nadie le dio al subhilo un encabezado para que yo lo vinculara. Creo que comienza por aquí. Folly Mox ( discusión ) 11:57, 25 de octubre de 2024 (UTC) [ responder ]

No fue la discusión sobre citar fuentes. Puede que haya sido el subproceso, pero no estoy seguro. Thryduulf ( discusión ) 12:24 25 oct 2024 (UTC) [ responder ]

O bien los marcan, pero bloquean nuestros servidores. Probablemente eso esté sucediendo con The New York Times . Las referencias con el formato correcto también les interesan, pero es probable que todo lo que vean sea algo automatizado u otro y lo bloqueen automáticamente. WhatamIdoing ( discusión ) 23:41 24 oct 2024 (UTC) [ responder ]

La automatización del lado del servidor tendría los mismos problemas, y preferiría que los editores verificaran lo que generan las herramientas automatizadas, ya que a veces producen tonterías. -- LCU A ctively D isinterested « @ » ° ∆t ° 20:50, 24 de octubre de 2024 (UTC) [ responder ]

@ Donald Albury , he tenido cierto éxito al utilizar un DOI en tales casos, suponiendo que lo tenga. WhatamIdoing ( discusión ) 23:42, 24 de octubre de 2024 (UTC) [ responder ]