Política | Técnico | Propuestas | Laboratorio de ideas | WMF | Diverso |
- Primera discusión
- Nueva publicación
La sección de laboratorio de ideas de la bomba de la aldea es un lugar donde se pueden incubar nuevas ideas o sugerencias sobre temas generales de Wikipedia, para su posterior presentación para una discusión de consenso en la bomba de la aldea (propuestas) . Trate de ser creativo y positivo al comentar ideas. Antes de crear una nueva sección, tenga en cuenta :
Antes de comentar, tenga en cuenta :
Las discusiones se archivan automáticamente después de permanecer inactivas durante dos semanas. |
«Archivos , 16 , 17 , 18 , 19 , 20 , 21 , 22 , 23 , 24 , 25 , 26 , 27 , 28 , 29 , 30 , 31 , 32 , 33 , 34 , 35 , 36 |
Modificar la 3RR para garantizar que se mantenga el statu quo
Si el editor A hace una edición en negrita y el editor B revierte esto hasta que llegan a 3RR , la edición en negrita impugnada se mantiene. ¿Cómo se puede modificar el 3RR para que el WP: STATUSQUO no se vea perjudicado? ¿Debería permitirse al editor B una edición adicional para asegurarse de que se mantenga el status quo, o hay una mejor manera? ~ HAL 333 15:53, 29 de junio de 2021 (UTC)
- Por lo general, hay más de dos editores trabajando en una página, y si solo hay dos puedes ir a un tablón de anuncios y pedir una tercera opinión.
- Además, en el mundo real, si para su última edición en lugar de revertir, va a una versión anterior que fue estable por mucho tiempo y la restaura con un comentario como "Por WP: STATUSQUO restaurando la última versión estable de antes de la guerra de edición" , es poco probable que su edición lo bloquee por una guerra de edición, mientras que revertirla probablemente resulte en un bloqueo. Tal vez deberíamos documentar eso en alguna parte: Guy Macon ( charla ) 16:37, 29 de junio de 2021 (UTC)
- @ HAL333 es posible que desee leer m: The Wrong Version - RoySmith (charla) 16:49, 29 de junio de 2021 (UTC)
- Ésta es una pregunta realmente complicada. Hay sustancialmente más soporte de facto para WP: STATUSQUO que soporte basado en orientación (se encuentra con WP: Reverting , que es uno de esos ensayos que probablemente debería convertirse en una guía pero nunca llegó allí). Nuestro consejo basado en la guía es WP: BURDEN , pero eso no funciona cuando la pregunta no es tanto una adición / eliminación como elegir entre A o B, o cuando la inclusión es el status quo de larga data y es poco probable que un intento de eliminación tenga éxito. pero tenemos que esperar la duración de un RfC. Creo que ayudaría a reducir bastante las guerras de edición dar un estatus de pauta de statu quo y definir mejor qué es exactamente lo que se requiere para constituir el estatus de statu quo. Sugeriría que 3RR podría ser el ángulo incorrecto para abordar esto, ya que idealmente los buenos editores no deberían alcanzar 3RR de todos modos (rara vez llego a 2RR); en cambio, la pregunta es directamente "cuando se discute algo, ¿qué versión debería mantenerse mientras se produce el debate?" Elevar el estado de WP: Revertir podría ser más complicado que agregar algo sobre el status quo a la política de WP: Editar guerra , como mencioné en julio pasado . Buena suerte si decides aceptar esto. {{u | Sdkb }} charla 18:44, 29 de junio de 2021 (UTC)
- El punto es que las cosas no deberían llegar a un 3rr. Detenga la reversión y la reversión del contador antes de llegar a esa etapa. Hay otras opciones. Usalos, usalos a ellos. Marque la sección como "en disputa", vaya a la página de discusión y discuta. Llame a otros editores para obtener una tercera opinión. Presenta una RFC si es necesario. Etc.
- Sí, es posible que el artículo esté en "la versión incorrecta" durante un breve período de tiempo mientras soluciona la disputa ... ese no es el fin del mundo (especialmente si lo ha marcado para que los lectores sepan que la versión visible actualmente ESTÁ en disputa ). Blueboar ( charla ) 19:40, 29 de junio de 2021 (UTC)
- No hay una forma satisfactoria de lidiar con esto: 3rr (o 2rr o 1rr, o cualquier procedimiento similar) siempre favorecerá la versión original o el cambio, y algunas veces será lo correcto y otras no. No me gustan las ambigüedades presentes, ya que muchas disputas nunca se resuelven, pero no veo una alternativa fácil y satisfactoria. DGG ( charla ) 01:10, 3 de julio de 2021 (UTC)
¿Colocar banners en páginas que signifiquen recuentos de visitas trascendentales?
La página alcanza un número de cientos de miles de visitas, o llega a 1 millón de visitas, ¿agregar un banner para el día en que "Esta página alcanzó 1 millón de visitas"? E incrementos similares, 2 millones, 5 millones, 10, 20, 50, etc. ¿Es eso algo que haríamos o podríamos hacer? Hyperbolick ( charla ) 09:02, 29 de junio de 2021 (UTC)
- No hay razón para que no sea posible desde un punto de vista técnico, pero no veo cuál sería el propósito. Ya tenemos el informe WP: Top 25 para las páginas vistas semanales y el WP: Top 50 Report para las páginas vistas anuales. No creo que "Este artículo ha recibido X páginas vistas" sea información útil para los lectores, parece más una celebración en las redes sociales o una autocomplacencia que información enciclopédica útil. Además, la herramienta de vista de página actual solo tiene datos que se remontan a 2015, la anterior solo se remonta a 2011 y la implementación original se rompió por completo cuando el sitio comenzó a usar varios servidores, por lo que no tenemos idea de cuántas vistas tienen realmente muchas de estas páginas. . 192.76.8.91 ( conversación ) 14:04, 29 de junio de 2021 (UTC)
- Hyperbolick ,
- Este es un buen ejemplo de una sugerencia que sería mejor comenzar en el laboratorio de ideas que fue diseñado específicamente para discutir y debatir alternativas antes de decidirse por una propuesta específica que debería ser votada a favor o en contra. Creo que hay algo de mérito en el concepto, pero me encantaría que se intercambiaran ideas antes de decidirme por una propuesta específica. S Philbrick (Discusión) 18:13, 29 de junio de 2021 (UTC)
- @ Hyperbolick , ¿crees que esto interesaría a los lectores o editores? WhatamIdoing ( charla ) 20:33, 29 de junio de 2021 (UTC)
- Pensaría que los lectores lo encontrarían genial. De hecho, quizás ambos. ¿Los editores suelen tener alguna idea de cuándo las páginas que han creado o en las que han trabajado han alcanzado hitos? Hyperbolick ( charla ) 01:52, 30 de junio de 2021 (UTC)
- Simplemente no veo el uso de esto. @ Hyperbolick : ¿Qué problema resuelve esto? De todos modos, si desea ver las páginas vistas de una página, todo lo que tiene que hacer es ir a Estadísticas de páginas vistas de XTools. Para ver las vistas de esta página, por ejemplo, está aquí . 🏳️🌈 ¡ Chicdat Bawk para mí! 10:00, 30 de junio de 2021 (UTC)
- Resolvería casi el mismo problema que tomarse un descanso para ver cómo se resuelve la puesta de sol, o hacer una pausa en un trote para oler un rosal. Hyperbolick ( charla ) 08:32, 2 de julio de 2021 (UTC)
- No veo ninguna similitud. 🐔 ¡ Chicdat Bawk para mí! 10:33, 2 de julio de 2021 (UTC)
- Resolvería casi el mismo problema que tomarse un descanso para ver cómo se resuelve la puesta de sol, o hacer una pausa en un trote para oler un rosal. Hyperbolick ( charla ) 08:32, 2 de julio de 2021 (UTC)
- Simplemente no veo el uso de esto. @ Hyperbolick : ¿Qué problema resuelve esto? De todos modos, si desea ver las páginas vistas de una página, todo lo que tiene que hacer es ir a Estadísticas de páginas vistas de XTools. Para ver las vistas de esta página, por ejemplo, está aquí . 🏳️🌈 ¡ Chicdat Bawk para mí! 10:00, 30 de junio de 2021 (UTC)
- Pensaría que los lectores lo encontrarían genial. De hecho, quizás ambos. ¿Los editores suelen tener alguna idea de cuándo las páginas que han creado o en las que han trabajado han alcanzado hitos? Hyperbolick ( charla ) 01:52, 30 de junio de 2021 (UTC)
- @ Hyperbolick , ¿crees que esto interesaría a los lectores o editores? WhatamIdoing ( charla ) 20:33, 29 de junio de 2021 (UTC)
- baike tiene esto, muestra vistas, cuenta de páginas de discusión, https://baike.baidu.com/item/%E9%BB%84%E5%AE%B6%E9%A9%B9/77734
- el contador superior muestra el número de "flores enviadas" al artículo similar Token de atención básica automática contribución bi ( charla ) 05:26, 30 de junio de 2021 (UTC)
- No sería difícil hacerlo aquí, ¿verdad? Hyperbolick ( charla ) 08:25, 30 de junio de 2021 (UTC)
- No somos Baidu Baike. 🏳️🌈 ¡ Chicdat Bawk para mí! 11:14, 30 de junio de 2021 (UTC)
- No sería difícil hacerlo aquí, ¿verdad? Hyperbolick ( charla ) 08:25, 30 de junio de 2021 (UTC)
- No creo que debamos destacar las visitas a la página. Un artículo de mierda con muchas visitas es peor que un buen artículo con pocas visitas. Blueboar ( charla ) 12:56, 30 de junio de 2021 (UTC)
- Ya hacemos esto en las páginas de discusión: {{ Informe de los 25 principales }} por ejemplo. A menos que un artículo en particular establezca que sus páginas vistas son un tema notable (según la cobertura de las páginas vistas de ese artículo en fuentes confiables), agregar esta información a los artículos es un buen ejemplo de WP: NAVELGAZING . Ivanvector ( Talk / ediciones ) 12:01, 11 de Julio 2021 (UTC)
Familiares de wikidata
Noté que wikidata tiene propiedades para las relaciones, ¿es mejor mostrarlas en una plantilla de barra de navegación como baike https://baike.baidu.com/item/%E5%94%90%E7%BA%B3%E5%BE% B7% C2% B7% E7% 89% B9% E6% 9C% 97% E6% 99% AE? Fromtitle = Donald + Trump & fromid = 7895491 bi ( charla ) 05:49, 30 de junio de 2021 (UTC)
- Oponerse No somos Baidu Baike. - 🏳️🌈 ¡ Chicdat Bawk para mí! 10:42, 30 de junio de 2021 (UTC)
- Chicdat , el laboratorio de ideas no es el lugar para votar. 15 ( conversación ) 15:22, 4 de julio de 2021 (UTC)
- Este no es un lugar apropiado para el laboratorio de ideas de Wikipedia en inglés . En su lugar, pruebe con un lugar de discusión centralizado para Wikidata. 🐶 EpicPupper (él / él | charla , preguntas frecuentes , contribuciones | utilice {{ ping }} en la respuesta) 18:30, 7 de julio de 2021 (UTC)
Los marcadores de notas al pie no deben copiarse al copiar de un artículo.
Cuando pegas texto en aplicaciones de mensajería y algunos procesadores de texto, los marcadores de notas al pie dejan de ser superíndices y aparecen con una línea de base normal, lo que "hace que el [1] texto sea algo [2] ilegible [3]".
Es bueno que los pasajes pegados se refieran a sus fuentes, pero la mayoría de las veces, el medio en el que se está pegando el pasaje de Wikipedia omite el enlace (por ejemplo, mensajes de texto donde los hipervínculos se convierten en texto normal, o papel impreso donde los hipervínculos son inútiles).
Los marcadores de notas al pie que se copian son más a menudo una molestia que una cosa útil, por lo que propongo que no se puedan copiar en circunstancias normales (tal vez un atajo de teclado o un interruptor podría hacerlos copiables). - Comentario anterior sin firmar agregado por 207.172.131.14 ( charla ) 03:05, 2 de julio de 2021 (UTC)
- Dudo mucho que sea posible. Graham 87 08:09, 2 de julio de 2021 (UTC)
- Graham87 tiene razón. No hay forma de hacer esto. 🐔 ¡ Chicdat Bawk para mí! 10:31, 2 de julio de 2021 (UTC)
- Casualmente, es útil para identificar plagiarios particularmente perezosos. Nosebagbear ( charla ) 12:34, 2 de julio de 2021 (UTC)
- Es posible, aplicando el CSS
sup.reference { user-select: none; }
. Sin embargo, dudo que sea realmente deseable: como dice Nosebagbear, no queremos ponérselo demasiado fácil a los plagiarios. el wub "?!" 14:16, 2 de julio de 2021 (UTC)- ¿Por qué nos importa si la gente comete plagio en Wikipedia? 207.172.131.14 ( conversación ) 16:53, 3 de julio de 2021 (UTC)
- Uh ... veamos, ¡¿porque está EN CONTRA DE LA LEY ?! 🐔 ¡ Chicdat Bawk para mí! 10:14, 4 de julio de 2021 (UTC)
- ? en general, el "plagio" no está en contra de la ley, aunque las violaciones de derechos de autor pueden serlo. - Charla xaosflux 10:56, 6 de julio de 2021 (UTC)
- Oh. Quizás estaba confundiendo a los dos. Son similares. 🐔 ¡ Chicdat Bawk para mí! 12:48, 6 de julio de 2021 (UTC)
- ¿Por qué nos importa si la gente comete plagio en Wikipedia? 207.172.131.14 ( conversación ) 16:53, 3 de julio de 2021 (UTC)
- Nosebagbear , Buen punto. S Philbrick (Discusión) 16:10, 3 de julio de 2021 (UTC)
- Es posible, aplicando el CSS
- Casualmente, es útil para identificar plagiarios particularmente perezosos. Nosebagbear ( charla ) 12:34, 2 de julio de 2021 (UTC)
Un problema en el flujo de trabajo de AfC
En Wikipedia: Teahouse # etiquette_about_comments_on_draft , DGG planteó un problema con respecto al flujo de trabajo de WP: AfC : le resulta perturbador cuando los borradores que están en la cola de revisión de AfC se mueven al espacio principal:
- AfC es un proceso difícil, engorroso y muy sobrecargado, y solo es manejable porque hay un procedimiento estandarizado. Por lo tanto, personalmente, me molesta un poco cuando la gente mueve sus propios borradores al espacio principal. Hay una serie de categorías de seguimiento, y para hacerlas bien, es necesario seguir el antiguo proceso manual como se describe en la página afc, que es una molestia total. Es muy difícil mantenerse al día con los nuevos borradores y aquellos que necesitan revisión o eliminación, o rescatar de la eliminación; Yo y el resto de las personas que trabajamos en AFC tenemos nuestras propias rutinas establecidas, y salir del proceso habitual tiende a confundir las cosas.
Esto parece un problema muy técnico. Se me ocurre que puede haber una solución técnica. No estoy muy familiarizado con el flujo de trabajo de AfC, por lo que no estoy proponiendo exactamente nada concreto, pero me pregunto si este es un problema que merece atención. - Charles Stewart (charla) 18:16, 2 de julio de 2021 (UTC)
- Encuentro que interrumpe mi rutina, pero otros revisores lo consideran permisible. También sucede (rara vez, pero sucede) que algo se estropea tanto en el proceso de AFC que esta es la única forma de aceptar un artículo. No tenía la intención de sugerir que elimináramos la posibilidad. Hay una variación en la forma en la revisión los colaboradores dvarious - aunque espero que convergen hacia un cierto estándar para lo que de aceptar o rechazar, no estaría a favor de que todos usamos un procedimiento exactamente uniforme - sobre todo porque Alcedo punto no es procedimiento de no completamente satisfactoria a estandarizar. Hay muchas correcciones técnicas en AfC que ayudarían, pero lo que realmente necesitamos son más revisores. DGG ( charla ) 01:04, 3 de julio de 2021 (UTC)
- Más uno para DGG. No quisiera restringir esto, sobre todo porque, dada la acumulación actual, un editor que no debería usar el espacio principal directo al enviar el contenido podría ser lo suficientemente bueno para hacerlo 4 meses después. Nosebagbear ( charla ) 11:13, 3 de julio de 2021 (UTC)
- @ DGG y Nosebagbear : - Lo que me preguntaba es posible, perdón por no haber sido claro, es si sería posible seguir teniendo esta libertad, pero tener herramientas que nos permitan ver dónde no se está haciendo lo más esperado.
- Por ejemplo, a DGG no le agradó que las suposiciones de comportamiento hechas por las categorías de seguimiento puedan violarse si los borradores se mueven al espacio principal. Sin embargo, las plantillas se pueden escribir para que se comporten de manera diferente en diferentes espacios de nombres: podríamos hacer que las plantillas coloquen esas páginas movidas en una nueva categoría de seguimiento, digamos Categoría: Borradores con seguimiento fuera del espacio de borrador en lugar de la categoría de seguimiento habitual. Esto solo sería bueno si las nuevas categorías de seguimiento se vieran realmente. - Charles Stewart (charla) 07:24, 5 de julio de 2021 (UTC)
- Más uno para DGG. No quisiera restringir esto, sobre todo porque, dada la acumulación actual, un editor que no debería usar el espacio principal directo al enviar el contenido podría ser lo suficientemente bueno para hacerlo 4 meses después. Nosebagbear ( charla ) 11:13, 3 de julio de 2021 (UTC)
- Encuentro que interrumpe mi rutina, pero otros revisores lo consideran permisible. También sucede (rara vez, pero sucede) que algo se estropea tanto en el proceso de AFC que esta es la única forma de aceptar un artículo. No tenía la intención de sugerir que elimináramos la posibilidad. Hay una variación en la forma en la revisión los colaboradores dvarious - aunque espero que convergen hacia un cierto estándar para lo que de aceptar o rechazar, no estaría a favor de que todos usamos un procedimiento exactamente uniforme - sobre todo porque Alcedo punto no es procedimiento de no completamente satisfactoria a estandarizar. Hay muchas correcciones técnicas en AfC que ayudarían, pero lo que realmente necesitamos son más revisores. DGG ( charla ) 01:04, 3 de julio de 2021 (UTC)
El futuro de los cambios pendientes
Los cambios pendientes se han discutido recientemente en este RfC y este RfC . Específicamente, hay algunos temas que creo que pueden valer la pena discutir:
- ¿Deberían seguir utilizándose los cambios pendientes en la Wikipedia en inglés en su forma actual?
- La extensión no tiene mantenedor; es antiguo y técnicamente complejo. Todavía hay pocas personas que estén familiarizadas con el código base, y la mayoría de los desarrolladores no quieren tocarlo. T233561 , T234743 y T256296 todavía están abiertos, y varios errores aleatorios siguen apareciendo [1] [2] [3] [4] [5] [6] [7] . La corrección de un error provoca con frecuencia otro error inexplicable. Presuntamente debido a su inestabilidad, la WMF ha mantenido una política de no permitir su implementación en nuevas wikis. T185664 (desde 2018) analiza el futuro a largo plazo de la extensión, pero la revisión de la administración del código está estancada ya que ningún equipo de WMF desea asumir la responsabilidad de la extensión. Cuando hablé con algunos desarrolladores al respecto el año pasado, dijeron que habían perdido la fe en el proceso de revisión de la administración del código y supusieron que la eventualidad de la extensión sería la cancelación del despliegue. Desde hace unos meses, un voluntario está tratando de eliminar el código y la funcionalidad para hacerlo más fácil de mantener, sin embargo, WMF todavía no parece tener interés en mantenerlo. A veces, las correcciones ascendentes para las regresiones no ocurren o toman un tiempo; Recientemente, el bot dejó de revisar automáticamente las revisiones y tuvimos que crear y aprobar un bot enwiki para solucionar el error localmente.
- Incluso si funcionó correctamente, la extensión posiblemente no proporciona una gran interfaz de usuario y es potencialmente redundante para editar solicitudes. La interfaz de la PC necesita mejoras, pero (volviendo a la viñeta uno) apenas se mantiene para la corrección de errores, sin importar la nueva funcionalidad. Algunos de los problemas se pueden mitigar al no usarlo en artículos de gran volumen, pero incluso en muchas de esas páginas, podría decirse que el tiempo invertido en revertir puede ser una pérdida de tiempo.
- Dados los problemas anteriores, me pregunto si debería realizarse un RfC para discutir el futuro de los cambios pendientes. Si es necesario actuar, algunas opciones válidas podrían ser: desaprobar su uso solo para protecciones futuras (dejando las existentes en su lugar), o mover todos los cambios pendientes a semiprotección y luego eliminar la extensión.
- Incluso si la extensión se mantiene, el derecho de usuario de cambios pendientes no tiene sentido para mí. La PC supuestamente se considera una 'alternativa menos restrictiva' a la semiprotección (en realidad, la única diferencia es que la semiprotección requiere que hagas una solicitud al hablar; la PC te permite usar la interfaz de edición y enviar la solicitud de esa manera). Pero cualquier editor autoconfirmado (10 ediciones, 4 días registrados) puede implementar una solicitud de edición semiprotejada. Dado esto, no tiene sentido tener un derecho de usuario especial que los usuarios deben solicitar para poder aceptar los cambios pendientes. ¿Debería eliminarse el derecho de usuario de la PC y su permiso agrupado en autoconfirmado o extendidoconfirmado?
Se agradecen los pensamientos para refinar las ideas anteriores y decidir si hay un problema aquí, antes de llevarlo a RfC. ProcrastinationReader ( charla ) 19:46, 3 de julio de 2021 (UTC)
- Específicamente con respecto a la diferencia entre hacer una solicitud de edición y editar un artículo directamente, es una simplificación significativa del flujo de trabajo de colaboración poder editar un artículo directamente, recogiendo todos los cambios pendientes en el proceso. Por supuesto, esto depende de que la mayoría de los cambios pendientes sean productivos. isaacl ( charla ) 20:12, 3 de julio de 2021 (UTC)
- ProcrastinationReader , desde una perspectiva técnica, no creo que debamos ejecutar código en enwiki que no tenga un mantenedor / que no obtenga correcciones de errores rápidas y, por lo tanto, apoyaría eliminarlo por completo como objetivo final. Me doy cuenta de que puede ser controvertido, pero realmente no veo muchas otras opciones si no se encuentra un administrador de código para la extensión. luciérnaga ( t · c ) 06:27, 4 de julio de 2021 (UTC)
- Admito que podría estar un poco sesgado porque yo mismo soy un revisor de cambios pendientes, así como un habitual en VPI, pero
¿Debería eliminarse el derecho de usuario de la PC y su permiso incluido en autoconfirmado o extendidoconfirmado?
me confunde. Algunos vándalos y muchos editores disruptivos logran que se autoconfirmen antes de ser bloqueados. Esto supondría muchas horas de discusión en ANI; hilos con títulos como "El usuario que acepta actos de vandalismo en cambios pendientes protege los artículos. Yo apoyaría que la barra sea un poco más alta, como 365/5000 en lugar de 30/500 o 4/10, sin embargo. La mayoría de los editores deliberadamente disruptivos no hacen que lejos. 🐔 Chicdat Bawk to me! 10:30, 4 de julio de 2021 (UTC)- No hay una buena razón para restringir la aprobación de cambios pendientes a un nivel más alto que la aceptación de solicitudes de edición semiprotegidas. Si el vandalismo fuera una preocupación, también debería elevarse el listón de la semiprotección. El vandalismo en artículos semiprotegidos es mucho menos frecuente según mi experiencia en la gestión de filtros de edición (la confirmación automática previene la mayoría) y es coherente con nuestras otras prácticas. El principio general es hacer que la edición sea lo más abierta posible sin sobrecargar nuestra capacidad de voluntariado. Francamente, la mayor limitación en nuestra capacidad de voluntariado con PC es requerir la aprobación de WP: PERM . ProcrastinationReader ( charla ) 12:14, 4 de julio de 2021 (UTC)
- ¿Alguien puede proporcionar cifras sobre la frecuencia con la que se utiliza la protección de cambios pendientes y algún ejemplo en el que cualquier otra forma de protección no hubiera sido tan buena? Rara vez me encuentro con artículos con protección para PC, pero prefiero estadísticas sólidas a mi instinto. Si esto es realmente necesario (algo de lo que aún no estoy convencido), entonces deberíamos incrementar nuestros esfuerzos para asegurarnos de que se mantenga el código. Phil Bridger ( charla ) 13:14, 4 de julio de 2021 (UTC)
- @ Phil Bridger : Como anécdota, estoy de acuerdo, con poca frecuencia veo páginas de PC en comparación con semi (supongo que 1 de cada 25 o menos). Los datos sugieren que tenemos alrededor de 4.000 , en comparación con 50.000 semiprotecciones. ProcrastinationReader ( charla ) 13:14, 11 de julio de 2021 (UTC)
- @ ProcrastinationReader : dice que no está seguro de por qué podría usarse, ya que cualquier editor de CA podría manejar una solicitud de edición de SP, a diferencia del grupo más pequeño que puede manejar pendientes. Acepte el hecho de que un vistazo rápido a la gran longitud de la lista de solicitudes de edición muestra que eso no está sucediendo. Mientras que la cola pendiente es mucho más corta, su caso de uso es "cualquier artículo que estaría semiprotegido pero tiene una tasa de ediciones lo suficientemente baja como para que PCR no se obstruya con ediciones apiladas". Es mucho menos trabajo revisar una única edición pendiente que evaluar y luego agregar una única solicitud de edición. Entonces, hay aspectos negativos de eliminarlo. Nosebagbear ( charla ) 16:05, 4 de julio de 2021 (UTC)
- Bueno, hay ~ 13 veces más páginas semiprotejadas que páginas protegidas por PC. Actualmente hay 2 solicitudes en la cola de PC, lo que AFAIK es atípico y la pequeña muestra hace que la comparación sea deficiente. Pero en ese número * 13, hay menos solicitudes de PC que semi. Si hubiera 4 solicitudes en la cola, que probablemente habrá en unas pocas horas, habría más solicitudes en comparación con la semi cola. Una pequeña diferencia en el número de solicitudes marcó una gran diferencia en esta comparación. No puede hacer una comparación significativa sin conocer el número promedio de solicitudes semi y solicitudes de PC. Y esto sin considerar si los artículos semiprotegidos tienden a tener solicitudes de edición más complejas, en promedio, que los artículos aptos para PC. Me gusta el concepto de poder editar en el editor, pero su implementación en forma de FlaggedRevs es de mala calidad y la extensión no se mantiene en absoluto. Preferiría ver a la WMF trabajar en algo mejor. ProcrastinationReader ( charla ) 16:29, 4 de julio de 2021 (UTC)
- @ ProcrastinationReader : el número de ediciones en las colas no es lo que realmente debería compararse. El "tiempo promedio de una solicitud en la cola" debe ser el punto de comparación. Y observa que cualquier usuario de AC puede procesar solicitudes de SP, y definitivamente hay más de 13 veces más usuarios con AC que con PCR además de eso. Nosebagbear ( charla ) 17:28, 4 de julio de 2021 (UTC)
- Bueno, hay ~ 13 veces más páginas semiprotejadas que páginas protegidas por PC. Actualmente hay 2 solicitudes en la cola de PC, lo que AFAIK es atípico y la pequeña muestra hace que la comparación sea deficiente. Pero en ese número * 13, hay menos solicitudes de PC que semi. Si hubiera 4 solicitudes en la cola, que probablemente habrá en unas pocas horas, habría más solicitudes en comparación con la semi cola. Una pequeña diferencia en el número de solicitudes marcó una gran diferencia en esta comparación. No puede hacer una comparación significativa sin conocer el número promedio de solicitudes semi y solicitudes de PC. Y esto sin considerar si los artículos semiprotegidos tienden a tener solicitudes de edición más complejas, en promedio, que los artículos aptos para PC. Me gusta el concepto de poder editar en el editor, pero su implementación en forma de FlaggedRevs es de mala calidad y la extensión no se mantiene en absoluto. Preferiría ver a la WMF trabajar en algo mejor. ProcrastinationReader ( charla ) 16:29, 4 de julio de 2021 (UTC)
- No tengo mucha experiencia con cambios pendientes, pero quiero responder a la afirmación de que
La extensión no tiene mantenedor; es antiguo y técnicamente complejo. Todavía hay pocas personas que estén familiarizadas con el código base, y la mayoría de los desarrolladores no quieren tocarlo.
Como ingeniero de software, eso es una gran señal de alerta. Realmente no desea que un sistema tan grande y ampliamente utilizado como wikipedia dependa de algo así. El escenario aterrador no es que deje de funcionar y nadie pueda descubrir cómo solucionarlo. El escenario aterrador es que se rompe de alguna manera que afecta el funcionamiento del sitio (tal vez una exposición de seguridad) y nadie puede descubrir cómo deshabilitarlo limpiamente porque hay una dependencia que nadie sabía que existía. Realmente desea descubrir cosas así durante una eliminación planificada, no cuando está apagando un incendio.
- Como administrador, no veo que la PC proporcione un valor significativo. No puedo hablar por todos los administradores, pero personalmente nunca considero usarlo; Encuentro que la semiprotección y ECP proporcionan un conjunto de herramientas lo suficientemente rico como para que la opción adicional de PC no sea necesaria. No estoy diciendo que no valga la pena ( Nosebagbear , por ejemplo, describe un caso de uso válido arriba), solo que el riesgo / recompensa no me parece que valga la pena. - RoySmith
(charla) 17:18, 4 de julio de 2021 (UTC)
- +1 en ambos casos. firmado, charla de Rosguill 22:49, 8 de julio de 2021 (UTC)
- Me gustaría poner mi granito de arena en esto, ya que recientemente, tuve una idea relacionada con los cambios pendientes que creo que podrían ser notables aquí. ¿Qué tal si fusionamos PC con los otros tipos de protección (fullprot, templateprot, semiprot, etc.) con una nueva extensión? Me di cuenta de que varios otros, incluido ProcrastinationReader, han comentado varios pequeños fragmentos de mis ideas aquí, por lo que pueden parecer un poco duplicados, lo siento. Aquí están mis pensamientos, repetidos en niveles de dificultad para llegar a un consenso / construir:
Nivel 1
- Agrupe el usuario de PCR directamente en autoconfirmado
Nivel 2
- Elimine el sistema de PC actual tal como está y proteja todas las páginas actualmente protegidas por PC con semiprotección
Nivel 3
- Haga que los miembros de la comunidad / WMF escriban una nueva extensión para los cambios pendientes y revisen el sistema. Creo que un sistema de Cambios Pendientes donde los niveles de protección actualmente existentes (semiprotección, protección total, etc.) podrían convertirse en un tipo de Cambios Pendientes, donde los usuarios que no cumplan con los permisos requeridos para editar ciertas páginas (digamos, un editor confirmado extendido que intenta editar una página protegida por plantilla) obtendría acceso directo a la interfaz de usuario de edición, y sus cambios tendrían que ser aprobados por una persona con los permisos pertinentes (editor de plantillas). Mi propuesta pretende ser extremadamente similar al sistema actual. Nosebagbear dice
su caso de uso es "cualquier artículo que estaría semiprotegido pero que tiene una tasa de ediciones lo suficientemente baja como para que PCR no se obstruya con ediciones apiladas". Es mucho menos trabajo revisar una única edición pendiente que evaluar y luego agregar una única solicitud de edición
. Al leer la oración anterior, me pareció una obviedad fusionar los dos niveles de protección y hacer que las páginas semiprotegidas tengan herramientas de revisión más fáciles para las solicitudes de edición (a través de una interfaz de usuario en lugar de una plantilla). Me imagino que si hubiera un nuevo sistema para PC que esencialmente combine PC y semiprot, la mecánica de visibilidad (¿ven los editores no registrados cambios pendientes?) Sería la misma que la del PC "normal", que es el sistema actualmente. En cuanto a cómo se podría escribir algo como esto, y por quién, no estoy del todo seguro. Si un miembro de la comunidad quiere solicitar una subvención de WMF a cambio de construir una nueva extensión, eso podría funcionar. Esto podría plantearse en la próxima Encuesta de Deseos de la Comunidad o en los Deseos Técnicos de m: WMDE . No estoy seguro de si esto es apropiado para una tarea de Phab, pero si se agotan todos los demás métodos, una tarea de solicitud de función de Phabricator podría archivarse como último recurso. Me refiero a esto como último recurso, ya que en mi experiencia, Phab es bastante lento para las solicitudes de funciones, especialmente las bastante grandes (lo cual es completamente justo).
Lo siento, me acabo de dar cuenta de que se trata de una enorme confusión de palabras. Intentaré limpiarlo más tarde, pero lo voy a publicar ahora para guardarlo. 🐶 EpicPupper (él / él | charla , preguntas frecuentes , contribuciones | utilice {{ ping }} en la respuesta) 04:40, 7 de julio de 2021 (UTC)
- Me gusta tu idea de nivel 3. Sería especialmente bueno si los cambios se pudieran "fusionar" sin retrasar el resto del artículo, un poco como las ramas de git . Sin embargo, no estoy seguro de la probabilidad de que podamos solicitar una nueva extensión. Probablemente sería sustancialmente más fácil de construir que FlaggedRevs, que tiene mucho más propósito que solo los 'cambios pendientes' para los que lo usamos. Pero no conozco a nadie que quiera buscar una subvención para construirlo, y pedirle a la WMF parece ser un éxito o un error. Quizás los comentarios de algunos usuarios técnicos ( @ Legoktm , DannyS712 y MusikAnimal ) ayudarían. ProcrastinationReader ( charla ) 10:28, 7 de julio de 2021 (UTC)
- Parece un gran proyecto. Antes de que se pueda realizar cualquier trabajo formal, debe mostrar un apoyo generalizado a la idea. La Encuesta de Lista de Deseos es un buen lugar para eso. En cuanto a la idea, no estoy de acuerdo con que una interfaz de usuario para solicitudes de edición sea suficiente. Los cambios pendientes permiten a los usuarios editar el artículo directamente, tal como lo harían con cualquier otro artículo (usando VisualEditor, por ejemplo). Como nuevo usuario de buena fe, idealmente no debería tener que aprender sobre solicitudes de edición o cualquier proceso interno para poder contribuir. Debería ser audaz y editar, en línea con el espíritu de la wiki. - MusikAnimal talk 17:49, 7 de julio de 2021 (UTC)
- No estoy de acuerdo con la afirmación de que los cambios pendientes permiten a las personas editar artículos directamente. El objetivo de editar artículos directamente es que los cambios sean visibles para otros lectores, lo que no ocurre con los cambios pendientes. Phil Bridger ( charla ) 18:04, 7 de julio de 2021 (UTC)
- @ MusikAnimal , @ Phil Bridger , disculpas, parece que tropecé un poco con la redacción. MusikAnimal, estoy totalmente de acuerdo en que
Como nuevo usuario de buena fe, idealmente no debería tener que aprender sobre solicitudes de edición o cualquier proceso interno para poder contribuir. Debería ser audaz y editar
. Eso es exactamente lo que quise decir, los cambios pendientes son una barrera mucho menor para que los nuevos usuarios pasen (solo haga clic en editar) que las solicitudes de edición, y si se reemplaza semi prot por PC, PC sería el reemplazo de nuestro sistema actual de solicitudes de edición. Phil Bridger, quise decir "editar artículos directamente" como tener una interfaz de usuario más fácil para que los nuevos editores editen exactamente lo que hay dentro del artículo en lugar de tener que jugar con el uso de una plantilla, ir a la página de discusión, describir los cambios, etc. con solicitudes de edición. 🐶 EpicPupper (él / él | charla , preguntas frecuentes , contribuciones | utilice {{ ping }} en la respuesta) 18:21, 7 de julio de 2021 (UTC) - La capacidad de cambios pendientes desacopla la versión del artículo que ven los espectadores que no han iniciado sesión del artículo actual que se está editando. Aún se realizan ediciones en la última versión consolidada. isaacl ( charla ) 14:45, 8 de julio de 2021 (UTC)
- @ MusikAnimal , @ Phil Bridger , disculpas, parece que tropecé un poco con la redacción. MusikAnimal, estoy totalmente de acuerdo en que
- No estoy de acuerdo con la afirmación de que los cambios pendientes permiten a las personas editar artículos directamente. El objetivo de editar artículos directamente es que los cambios sean visibles para otros lectores, lo que no ocurre con los cambios pendientes. Phil Bridger ( charla ) 18:04, 7 de julio de 2021 (UTC)
- El soporte de bifurcación adecuado ( T113004: Facilite la bifurcación, bifurcación y combinación de páginas (o más) ), así como sugerir ediciones en Google Docs (no puedo encontrar la tarea phab, estoy seguro de que algo existe) es definitivamente algo que MediaWiki necesita y haría que la edición de Wikipedia sea una experiencia más agradable.
- Los cambios técnicamente pendientes son efectivamente una segunda versión de la página que condicionalmente se debe mostrar a los usuarios, lo que significa que necesita fragmentar y duplicar mucho código para lograr ese objetivo, ¡ya que MediaWiki no espera eso! Evitar eso en cualquier solución lo haría mucho más simple.
- Mientras estoy en la tribuna, me gustaría señalar que los cambios pendientes son anti-wiki, ya que ya no es instantáneo para que aparezca su edición. Creo que eso contribuye a la renuencia de los desarrolladores, incluido yo mismo, a trabajar en él (y luego agregar toda la deuda técnica y la complejidad ...). Si fuera trivial ramificar una página wiki y sugerir una edición con una buena experiencia de usuario, ¿los administradores serían más agresivos al proteger las páginas semi sabiendo que no está (teóricamente) bloqueando las ediciones? Fácilmente podría volverse más anti-wiki, imponiendo un proceso de revisión previa.
- Creo que el problema de BLP es real y necesita ayuda técnica, pero no estoy seguro de adónde ir. Me preocupa que a veces estemos atrapados en el problema XY en el sentido de que las únicas dos soluciones que conocemos son la protección de la página y los cambios pendientes, por lo que todas las propuestas se basan en esos dos modelos. Legoktm ( charla ) 08:09, 8 de julio de 2021 (UTC)
- Legoktm , es interesante que diga que los cambios pendientes son "anti-wiki" y, sin embargo, MusikAnimal dice anteriormente que la PC es una alternativa más parecida a una wiki que la semiprotección y las solicitudes de edición. De cualquier manera, ¿no deberían los desarrolladores de MW implementar ampliamente características que existe un deseo generalizado entre las comunidades de MW / WMF, en lugar de reprimirse de tales implementaciones sobre la base de, a falta de una frase mejor, "ideología wiki"?
- Sin embargo, en un nivel puramente técnico, estoy completamente de acuerdo en que la
flaggedrevs
extensión es un lío impío que es técnicamente incongruente con el funcionamiento de MediaWiki. Bifurcar como Git o ediciones sugeridas / 'realizar un seguimiento de los cambios' como en MS Word sería una mejora masiva y, sin embargo, también una tarea masiva de implementar como usted dice. Mientras tanto, mantengo mis comentarios anteriores de que la extensión debería dejar de usarse gradualmente aquí en enwiki. luciérnaga ( t · c ) 08:44, 8 de julio de 2021 (UTC)- @ Firefly , pude ver por qué la gente considera que la PC es menos anti-wiki que semiprotección, pero no veo mucha diferencia, ambos requieren la aprobación previa de las ediciones. Personalmente, como administrador, prefiero la semiprotección a la PC porque es mucho más obvio que el proceso de wiki se está deteniendo y debería estar en su lugar durante el menor tiempo posible. En cuanto a qué implementar ... Realmente no veo por qué los desarrolladores de Media Wiki implementarían características que van en contra de la "ideología wiki" solo porque los usuarios de Wiki Pedia se lo pidieron. Los desarrolladores no son necesariamente los mejores guardianes, pero en ausencia de un grupo diferente de personas, ahí es donde ha caído la pelota. No creo que la administración de WMF haya hecho un buen trabajo al priorizar las funciones que los editores necesitan, pero esa es una conversación diferente (tampoco trabajo mucho en las cosas de MediaWiki directamente).
- Creo que la implementación de bifurcaciones / ediciones sugeridas se podría hacer con una solución del 75% usando un gadget y tal vez una herramienta Toolforge. ("No dejes que lo perfecto sea enemigo de lo bueno") Tal vez alguien deba intentar demostrar que el concepto es viable, ya que parece haber funcionado con las mejoras de la página de discusión / DiscussionTools con un enlace de respuesta y ConvenientDiscussions. Legoktm ( charla ) 00:51, 11 de julio de 2021 (UTC)
- Sí, mi comentario fue comparar semi-protección y PC. Con semi, debe solicitar a otros que realicen modificaciones por usted. Es engorroso, más propenso a editar conflictos (es decir, alguien más cambió el contenido desde que solicitó los cambios), y pierde la atribución de quién fue el autor del contenido. Con la PC, puede realizar cambios en tiempo real en el artículo tal como lo haría, como si estuviera desprotegido. A todos los efectos, es idéntico a la edición normal en el sentido de que una revisión se guarda de hecho, visible para el autor, con la atribución intacta. Dejando a un lado las complejidades técnicas, creo que un mundo sin PC y solo una protección de página normal es mucho, mucho más anti-wiki. Creo que está bien entendido que la PC es un desastre técnico, pero es la mejor herramienta que tenemos para páginas de baja tasa de edición sujetas a vandalismo persistente. Siempre que funcione lo suficientemente bien, debe conservarse. - MusikAnimal talk 22:21, 11 de julio de 2021 (UTC)
- @ Legoktm : ¿Es cierto "Los cambios técnicamente pendientes son efectivamente una segunda versión de la página"? Si mal no recuerdo, no crea ninguna versión independiente de la página. Solo muestra una revisión anterior "buena conocida" de la página para ciertos editores, en lugar de la revisión actual. Toda la "revisión" consiste en observar la diferencia entre la última revisión en buen estado y la revisión actual para realizar las ediciones necesarias y luego marcar una nueva revisión en buen estado. Pero reinventa una tonelada de código para hacer eso, probablemente mucho más de lo que realmente necesitaría. Yo diría que la complejidad es lo que desalienta a los desarrolladores en lugar de una opinión filosófica que otros ni siquiera pueden compartir. Anomie
⚔ 11:55, 8 de julio de 2021 (UTC)
- Bien, en mi cabeza, la revisión de "bien conocido" es una segunda versión que está en el caché del analizador y en el caché de barniz / HTML y todo el manejo especial que conlleva. Y justo, es posible que estuviera proyectando en el frente filosófico. Legoktm ( charla ) 01:03, 11 de julio de 2021 (UTC)
- La ramificación es una característica inmensamente poderosa de los sistemas de control de versiones de control de código fuente, y también una que puede resultar confusa incluso para los usuarios experimentados. Para simplificar el trabajo con ellos, es útil tener puntos de integración regulares en una rama y puntos de rebase en las ramas de trabajo. De lo contrario, la integración de ramas de trabajo se vuelve laboriosa. Incluso entonces, es difícil de administrar cuando varias personas están trabajando en el mismo pasaje de texto, y cuando la coordinación es posible, ahorra mucho tiempo dividir el trabajo entre editores para minimizar la superposición.
- Los cambios pendientes no introducen la ramificación: desacopla el proceso de "liberación para los espectadores que no han iniciado sesión" del proceso de envío de la edición. Las solicitudes de edición son similares a que alguien crea una rama / diferencia de trabajo y le asigna la responsabilidad a alguien para que vuelva a basar y fusionar el cambio. Los cambios pendientes hacen que otra persona tenga la responsabilidad de eliminar un cambio si no es deseable, que es lo mismo que las ediciones normales.
- Dadas las dificultades de tratar de coordinar las ediciones entre editores de Wikipedia de diferentes niveles de experiencia en general, que podrían aparecer en cualquier momento y dejar una edición en cualquier lugar, desconfío de convertir un modelo de múltiples ramificaciones en el modo de operación estándar. . Tener una herramienta o herramientas adicionales para ayudar a los editores avanzados a renovar los artículos en el lateral podría ser útil, como una herramienta para ayudar a fusionar los cambios de un punto dado en el historial del artículo. Sin embargo, no tengo claro cuánta prioridad se le debe dar a esto frente a otras mejoras que se pueden hacer. isaacl ( charla ) 15:12, 8 de julio de 2021 (UTC)
- Parece un gran proyecto. Antes de que se pueda realizar cualquier trabajo formal, debe mostrar un apoyo generalizado a la idea. La Encuesta de Lista de Deseos es un buen lugar para eso. En cuanto a la idea, no estoy de acuerdo con que una interfaz de usuario para solicitudes de edición sea suficiente. Los cambios pendientes permiten a los usuarios editar el artículo directamente, tal como lo harían con cualquier otro artículo (usando VisualEditor, por ejemplo). Como nuevo usuario de buena fe, idealmente no debería tener que aprender sobre solicitudes de edición o cualquier proceso interno para poder contribuir. Debería ser audaz y editar, en línea con el espíritu de la wiki. - MusikAnimal talk 17:49, 7 de julio de 2021 (UTC)
- Dudo que mejore el proyecto eliminar los cambios pendientes hoy, pero es necesario rediseñar todo el sistema desde cero. No estoy seguro de que haya una ruta hacia un historial de revisión similar a Git en un nivel por página, pero ese sería el sistema ideal. Si se va a agrupar PCR, sugeriría agruparlo con Extended-Confirmed, simplemente para ayudar con la curva de aprendizaje. Usuario: 力(power ~ enwiki, π , ν ) 21:24, 8 de julio de 2021 (UTC)
- @力: Creo que el historial de revisiones similar a git sería terriblemente confuso para la mayoría de las personas. Combinar la resolución de conflictos es complicado. Realmente es algo que debe evitarse si es posible. - RoySmith (charla) 22:41, 11 de julio de 2021 (UTC)
- Desaste de eso. Según recuerdo, logró entrar a pesar de que la comunidad no lo quería. La lista de opciones anterior sin una opción de "simplemente deshacerse de ella" es el tipo de cosa que puede hacer que eso suceda. Demasiado complicado. Lo que hace se hace mejor mediante la patrulla antivandálica humana y antivandálica y la protección parcial. North8000 ( conversación ) 01:03, 11 de julio de 2021 (UTC)
- Tenga en cuenta que modifiqué ligeramente mi comentario de apertura, específicamente para agregar enlaces y referencias a problemas técnicos. Dif . ProcrastinationReader ( charla ) 12:43, 11 de julio de 2021 (UTC)
WP: BIBLIOTECA, fuentes de investigación y recaudación de fondos
La biblioteca de Wikipedia tiene una horrenda acumulación de fuentes sugeridas . Así que tengo curiosidad sobre la idea de la recaudación de fondos (a través de alguna plataforma externa) para que los editores / wiki puedan comprar acceso de tipo institucional a varias revistas científicas y bases de datos para la Biblioteca. El acceso a publicaciones y recursos académicos es absolutamente crítico para desarrollar contenido de buena fuente en una cantidad significativa de temas que no se tratan en los medios de comunicación pero sí en esas publicaciones. Además, algunas citas de noticias de alta calidad también están ahora bajo un muro de pago y, si se pueden recaudar fondos, la Biblioteca también podría ofrecer acceso a estas fuentes muy importantes.
Tengo curiosidad por implementar esto de dos maneras:
- Crowdfunding centralizado para bases de datos de origen específicas
- Donaciones independientes de editores / organizaciones que luego se utilizan para adquirir acceso a esas bases de datos fuente
- Posible solicitud de la comunidad a WMF para asignar fondos para bases de datos de fuentes específicas
Si alguien tiene su opinión sobre esto, por favor hágalo. ~ Gwennie 🐈⦅💬 📋⦆ 23:46, 4 de julio de 2021 (UTC)
- Un buen primer paso sería obtener algunos costos de acceso institucional para, digamos, los 10 más buscados que no tenemos. Estoy seguro de que se puede encontrar a alguien que sea experto en preparar solicitudes de subvenciones de WMF que sepa cómo enhebrar la aguja; el caso de uso es obvio, pero queremos dejar claro que vamos a necesitar el dinero cada vez. año. Sería una pena tener que dividir nuestra propia recaudación de fondos para esto, por lo que es bueno al menos probar la ruta de financiamiento central, pero si no funciona, se utilizará un esquema elaborado para "crowdfunding para obtener x número de espacios acceso a los siguientes y proyectos, funcionando en orden ". ¿Quizás hacer una recaudación de fondos inicial, que dure, digamos, un mes, luego 10 meses después, volver a hacerlo (luego cada 11/12 meses a partir de ese momento)? Nosebagbear ( charla ) 00:38, 5 de julio de 2021 (UTC)
- Creo que es más probable que esto tenga éxito si pasamos por los canales existentes que si intentamos establecer algo nuevo. Estoy de acuerdo en que la acumulación de fuentes sugeridas es un problema importante. La WMF tiene muchos recursos financieros / de personal a su disposición, y creo que sería un buen uso de ellos negociar el acceso a más fuentes o pagar por ellas si las fuentes no están dispuestas a donar. {{u | Sdkb }} charla 02:48, 7 de julio de 2021 (UTC)
- Sdkb , Nosebagbear Estoy empezando a catalogar todas las fuentes actualmente en la lista de trabajos pendientes (menos los duplicados) y categorizarlas, enviar correos electrónicos a los contactos de la fuente y adjuntar información y precios a lo que puedo encontrar. Cualquiera es libre de contribuir a la lista en User: Gwennie-nyan / Costos de acceso a WikiLibrary . ~ Gwennie 🐈⦅ 💬 📋⦆ 04:16, 7 de julio de 2021 (UTC)
- Creo que es más probable que esto tenga éxito si pasamos por los canales existentes que si intentamos establecer algo nuevo. Estoy de acuerdo en que la acumulación de fuentes sugeridas es un problema importante. La WMF tiene muchos recursos financieros / de personal a su disposición, y creo que sería un buen uso de ellos negociar el acceso a más fuentes o pagar por ellas si las fuentes no están dispuestas a donar. {{u | Sdkb }} charla 02:48, 7 de julio de 2021 (UTC)
- Vaya, ha sido un día salvaje leyendo en el Laboratorio de ideas. Tengo una idea que podría complementar cualquier acción que resulte en esta discusión. Como le mencioné a la gente de WP: Discord , en el futuro, planeo proponer una especie de "intercambio de recursos de pago", probablemente en todos los proyectos de WMF, que complementaría a REX al tener un "último recurso ”Lugar donde los editores, después de pedir ayuda en los lugares apropiados (por ejemplo, REX), pagan sus recursos (con suerte a través de una subvención de WMF). 🐶 EpicPupper (él / él | charla , preguntas frecuentes , contribuciones | utilice {{ ping }} en la respuesta) 18:28, 7 de julio de 2021 (UTC)
Biblioteca de usuario
Recientemente me di cuenta de que algunos usuarios tienen una subpágina de biblioteca donde tienen una lista de los libros y documentos que tienen, me he encontrado con User: Peacemaker67 / library y User: Tomobe03 / Library, pero es probable que no sean los únicos. Pensé en la creación de una página especial con tales bibliotecas de usuario, los encabezados de la página serían los nombres de los wikipedistas y debajo del encabezado, habría una oración sobre lo que dicho wikipedista puede / está dispuesto a hacer (escaneos, verificación, buscar información, etc.) y, por supuesto, una lista de libros y / o artículos que tiene el usuario. Alguien que esté buscando una fuente o quiera verificar algo podría simplemente presionar ctrl + f en esa página y ver si algún wikipedista tiene un libro / papel que está buscando y si alguien lo hace, dejaría un mensaje en su página de discusión. Esta página serviría como un lugar al que irían antes de WP: RX , si encuentran lo que están buscando en esa página, lo más probable es que esperen menos que en WP: RX. No he estado en WP durante mucho tiempo, por lo que es posible que ya exista algo como esto y, si lo hace, estaría agradecido si alguien me proporcionara un enlace. Si no es así, me encantaría saber qué piensan todos sobre esta idea y, si es buena, cómo podría implementarse. OakMapping ( charla ) 12:52, 5 de julio de 2021 (UTC)
- ¿Ha visto Wikipedia: Intercambio de recursos de WikiProject / Recursos compartidos (hay un enlace en la página de Wikipedia: Intercambio de recursos de WikiProject / Solicitud de recursos a la que hizo referencia)? ¿Es lo que tienes en mente? isaacl ( charla ) 15:17, 5 de julio de 2021 (UTC)
- Sí, eso es más o menos lo que tenía en mente. No puedo creer que me perdí ese enlace. Gracias, OakMapping ( charla ) 17:35, 5 de julio de 2021 (UTC)
Evite forzar el tamaño de los píxeles en varias plantillas de imágenes
No estoy seguro de dónde más publicar esto, pero en un FAC reciente [8] se mencionó que se deben evitar varias plantillas de imagen, que he usado mucho recientemente, porque requieren que fuerces un cierto tamaño de píxel, que es problemático. ¿Es técnicamente posible agregar algo como el parámetro "vertical" que ya se usa en imágenes individuales, que escala las imágenes en relación con pantallas particulares? De lo contrario, será difícil utilizar varias plantillas de imágenes para artículos destinados a la promoción. FunkMonk ( charla ) 11:22, 10 de julio de 2021 (UTC)
- FunkMonk , este es un punto interesante que vale la pena explorar. He usado galerías y varias plantillas de imágenes en ocasiones. Obviamente, esas plantillas se diseñaron mucho antes de que el uso de teléfonos inteligentes se volviera omnipresente, y tenía mucho sentido distribuir imágenes horizontalmente en lo que se esperaba que fuera una página bastante amplia. Dado el uso de dispositivos móviles, deberíamos investigar si esas plantillas deberían quedar obsoletas o reescritas. S Philbrick (Discusión) 13:20, 10 de julio de 2021 (UTC)
Por lo general, no se debe agregar una galería o un grupo de imágenes siempre que haya espacio para que las imágenes se presenten de manera efectiva junto al texto;
consulte WP: GALLERY - GhostInTheMachine talk to me 19:02, 10 de julio de 2021 (UTC)- No creo que eso se aplique a la plantilla de imágenes múltiples, que se puede usar para agrupar varias imágenes relacionadas de manera que solo ocupen el espacio de una sola imagen. Ver por ejemplo en Podokesaurus . FunkMonk ( charla ) 23:46, 10 de julio de 2021 (UTC)
- En cualquier caso, las galerías regulares se utilizan en algunos FA recientes, como la miniatura de boj gótico , por lo que realmente no importa que generalmente estén destinadas a evitarse, cuando hay casos en los que son completamente aceptadas. No hay ninguna razón por la que no debamos adaptar su uso a estándares más nuevos, en lugar de fingir que no existen. Si estuvieran completamente desanimados, sus plantillas se habrían eliminado hace mucho tiempo, pero ese no es el caso. FunkMonk ( charla ) 00:33, 15 de julio de 2021 (UTC)
- No creo que eso se aplique a la plantilla de imágenes múltiples, que se puede usar para agrupar varias imágenes relacionadas de manera que solo ocupen el espacio de una sola imagen. Ver por ejemplo en Podokesaurus . FunkMonk ( charla ) 23:46, 10 de julio de 2021 (UTC)
¿Debería mencionarse la propiedad de esclavos en la primera oración de los artículos sobre dueños de esclavos?
Wikipedia: Manual_of_Style / Biography # Opening_paragraph dice que la primera oración debe incluir "Contexto (ubicación, nacionalidad, etc.) para las actividades que hicieron a la persona notable". Si el sujeto era un dueño de esclavos, ¿debería incluirse este contexto en la primera oración? ♥ L'Origine du monde ♥ ♥ Charla ♥ 02:07, 13 de julio de 2021 (UTC)
- Depende, ¿son más notables por ser poseedores de esclavos? Entonces tal vez. De lo contrario, es probable que no sea apropiado para la primera oración. PackMecEng ( charla ) 02:09, 13 de julio de 2021 (UTC)
- Aflojaría el pensamiento de PackMecEng como "son los
másnotables ...". Fácilmente podría haber una gran notoriedad por algo que hicieron históricamente significativo ("la notabilidad no es transitoria" y todo eso), pero también un mayor interés más tarde específicamente en su propiedad de esclavos (peso de las referencias recientes). No nos corresponde a nosotros, como editores, decidir qué tipos ortogonales de notabilidad son "más". Pero este aspecto definitivamente debería demostrarse que es altamente significativo por el contenido del artículo que tiene referencias secundarias ( WP: estándar LEDE ). DMacks ( charla ) 02:45, 13 de julio de 2021 (UTC)- Si fuera el presidente de los Estados Unidos, la respuesta obviamente es no. Los presidentes no derivaron su notoriedad de la propiedad de esclavos. Esto se le explicó repetidamente en la RfC unánime en Washington iniciada por usted. Se revertía cada vez que intentaba insertar "dueño de esclavos" en la primera oración de cada biografía presidencial: [9] , [10] , [11] , etc. Por favor suelte el palo
Dr. Swag Lord ( charla ) 02:57, 13 de julio de 2021 (UTC)
- Supongo que el "usted" del Dr. Swag Lord se refiere a L'Origine du monde (no a mí, como sugiere el flujo de sangría). No he estado involucrado en el RfC ni en este aspecto de los artículos de los presidentes en general. Pero mirando estos detalles (ahora que los conozco, no solo una lluvia de ideas de VPIL inesperada), WPIL no es el lugar para esto. La página de conversación de MOS sería un lugar razonable, pero dada la NIEVE en el RfC, estoy de acuerdo con el consejo de STICK. DMacks ( charla ) 03:00, 13 de julio de 2021 (UTC)
- DMacks , sí, mis disculpas. Me refería al OP. Dr. Swag Lord ( charla ) 03:08, 13 de julio de 2021 (UTC)
- Sin preocupaciones. DMacks ( charla ) 03:29, 13 de julio de 2021 (UTC)
- DMacks , sí, mis disculpas. Me refería al OP. Dr. Swag Lord ( charla ) 03:08, 13 de julio de 2021 (UTC)
- Supongo que el "usted" del Dr. Swag Lord se refiere a L'Origine du monde (no a mí, como sugiere el flujo de sangría). No he estado involucrado en el RfC ni en este aspecto de los artículos de los presidentes en general. Pero mirando estos detalles (ahora que los conozco, no solo una lluvia de ideas de VPIL inesperada), WPIL no es el lugar para esto. La página de conversación de MOS sería un lugar razonable, pero dada la NIEVE en el RfC, estoy de acuerdo con el consejo de STICK. DMacks ( charla ) 03:00, 13 de julio de 2021 (UTC)
- Si fuera el presidente de los Estados Unidos, la respuesta obviamente es no. Los presidentes no derivaron su notoriedad de la propiedad de esclavos. Esto se le explicó repetidamente en la RfC unánime en Washington iniciada por usted. Se revertía cada vez que intentaba insertar "dueño de esclavos" en la primera oración de cada biografía presidencial: [9] , [10] , [11] , etc. Por favor suelte el palo
Dr. Swag Lord ( charla ) 02:57, 13 de julio de 2021 (UTC)
- Aflojaría el pensamiento de PackMecEng como "son los
Se debe marcar el alcance de la cobertura de una referencia
Muchas veces, cuando tengo dudas sobre la información de un artículo y hay una cita cercana, me pregunto si la referencia cubre la parte de la información sobre la que tengo dudas. Cuando la referencia se puede buscar fácilmente en línea, puedo verificar, lo que lleva tiempo, algunas veces un poco más. Y cuando la referencia es un libro que no se puede buscar en línea, entonces la duda persiste y me pregunto, ¿qué información cubre la referencia? ¿Es solo una palabra? ¿Es una frase, es una oración? ¿Un párrafo? Por ejemplo, en el artículo de Jacobo Árbenz se puede encontrar lo siguiente : "En una de sus visitas a México, Árbenz contrajo una enfermedad grave, ya fines de 1970 estaba muy enfermo. Murió poco después. Los historiadores no están de acuerdo en la forma de su muerte: Roberto García Ferreira afirmó que murió de un infarto mientras se bañaba [140] ”. ¿Qué información cubre la cita 140? ¿Que murió de un infarto mientras se bañaba? ¿O incluye el reclamo de desacuerdo? ¿O incluye que murió poco después? Puede pensar que es evidente que solo cubre el ataque cardíaco o no, pero esto es solo para ilustrar mi punto.
Creo que para ahorrar tiempo a los editores y tener más certeza sobre la información en una página, debería haber un sistema para marcar el alcance de la cobertura de cualquier referencia específica dada. Podría haber una pestaña junto a la pestaña "Ver historial", donde se podría ver la página con el texto de la información en diferentes colores, marcando el alcance de la cobertura de cada referencia. La información que no esté respaldada por ninguna referencia permanecerá sin color. Thinker78 ( charla ) 18:06, 13 de julio de 2021 (UTC)
- Por cierto, por ejemplo, de algo relacionado que ya está implementado, consulte Plantilla: intervalo necesario de citas . - A D Monroe III ( charla ) 19:02, 13 de julio de 2021 (UTC)
- Pensador78 , sé que este tema surgió hace unos años, aunque no tengo ni idea de cómo rastrear esa discusión. Mi vago recuerdo es que alguien propuso algo muy similar a lo que sugieres: una forma de resaltar la palabra, frase, oración o párrafo que está respaldado por la referencia, probablemente de una manera que no sea inmediatamente visible para el lector pero que se mostraría en modo de edición. El desafío, si mal no recuerdo, es que esto podría funcionar razonablemente bien cuando el texto y la referencia de apoyo se agreguen por primera vez, pero ¿qué sucede si los editores posteriores deciden reformular el texto? El ejemplo que daré no es el ideal, pero intentaré apoyarme en tu ejemplo. ¿Qué pasa si la referencia apoya el término ataque cardíaco y algún editor bien intencionado decide modificar el término y reemplazarlo con infarto de miocardio? Es muy posible que el reemplazo deshaga el resaltado. Si otro editor decidió que el término era apropiado y lo cambió de nuevo a ataque cardíaco, ¿restablecerá el vínculo o no? Solo un ejemplo simple, pero uno puede imaginar situaciones en las que a lo largo de los años, se vuelve cada vez más difícil saber qué es exactamente lo que respalda la fuente. Esto no significa que no valga la pena considerarlo, pero sí significa que es un poco más complicado de lo sugerido.
- Lo que trato de hacer no es tan bueno como lo que sugieres, pero es mucho más fácil de implementar. Intento aprovechar el hecho de que las plantillas de citas pueden tener un campo para "cita" que se puede utilizar para incluir la declaración relevante de la fuente que respalda la afirmación. Habiendo dicho eso, me acabo de dar cuenta de que agregué algunas referencias en la última semana y no las usé, así que volví e incluí las citas. Un desafío con este método es que los campos predeterminados cuando uno crea una referencia no incluyen automáticamente la cotización, debe agregarla manualmente. Creo que intenté cambiar eso para que el campo de cotización fuera uno de los campos predeterminados, pero para ser honesto, no presioné tanto y no parece haber sucedido.
- Todo lo que sugiero es probablemente bastante obvio, pero esta diferencia es un ejemplo específico. S Philbrick (Discusión) 19:33, 13 de julio de 2021 (UTC)
- También tengo recuerdos bastante vagos de algo similar que existió hace muchos años (al menos en términos de Wikipedia), pero que fue abandonado por las razones declaradas por el Usuario: Sphilbrick . Es una de esas cosas que sería genial si todos la siguieran, pero solo se necesitan unas pocas personas para que no la sigan para que se vuelva bastante inútil. Phil Bridger ( charla ) 19:57, 13 de julio de 2021 (UTC)
- Como implementación de ejemplo, podríamos crear una nueva plantilla {{Citation span}}, similar a la plantilla {{Citation required span}}, donde el texto respaldado por la cita se incluye dentro de la plantilla. (A diferencia de la plantilla de extensión necesaria para la cita, el texto citado no debe resaltarse de ninguna manera en el modo de visualización normal). Por lo tanto, los editores posteriores podrían ver dónde el texto fuera de la plantilla no usa esta cita, o dónde puede ser necesario modificar el texto citado. volver a verificar la cita, en lugar de tener que hacer suposiciones.
- Por supuesto, el uso de la plantilla cite span sería opcional. Las nuevas ediciones podrían usarlo o no según el editor lo considere oportuno, y los editores posteriores podrían disfrutar de los beneficios o no. - A D Monroe III ( charla ) 18:21, 14 de julio de 2021 (UTC)
- También tengo recuerdos bastante vagos de algo similar que existió hace muchos años (al menos en términos de Wikipedia), pero que fue abandonado por las razones declaradas por el Usuario: Sphilbrick . Es una de esas cosas que sería genial si todos la siguieran, pero solo se necesitan unas pocas personas para que no la sigan para que se vuelva bastante inútil. Phil Bridger ( charla ) 19:57, 13 de julio de 2021 (UTC)
¿Más coherencia en la redirección / eliminación de ambigüedades de términos que tienen un significado gramaticalizado en inglés?
Pauta relevante (creo): Wikipedia: desambiguación § Definiciones de diccionario : una breve descripción del significado general común de una palabra puede ser apropiada para ayudar al lector a determinar el contexto.
Mi impresión es que esto es generalmente suficiente orientación cuando se trata de palabras de contenido , y lo mismo cuando se trata de la minoría de las palabras de función que tienen sus propios artículos - i , que , que , que , que , que , que , por ejemplo. Con la previsible excepción de la "I" de una sola letra, cada uno de ellos conduce al artículo sobre el pronombre oa una página de desambiguación, ya sea directamente o mediante un redireccionamiento. Y si se trata de una página de desambiguación, el pronombre se trata como el tema principal y se coloca encima de la introducción "también puede referirse a", o bien la primera entrada debajo de ella. Además, por supuesto, siempre hay un enlace a la entrada del wikcionario correspondiente a través de la plantilla de interwiki. Entonces, claramente no hay problemas de coherencia aquí.
Sin embargo, es bastante diferente para la mayoría de las palabras funcionales que no tienen artículos separados: am , are , is , por ejemplo. En cada caso, el camino relevante para el uso de la palabra funcional conduce finalmente al mismo lugar, Copula (lingüística) § Inglés , que es bueno, pero que es también donde termina la coherencia. "Soy" y "son" redireccionan a páginas de desambiguación. El primero lo coloca al final de § Otros usos , convirtiéndolo, por accidente o diseño, en la última entrada regular de desambiguación en la página. Este último lo coloca en la parte superior de la página, al igual que en el caso de los pronombres. Y "es" redirige directamente a la sección de destino, que tiene el requisito "Para otros usos", enlace de nota a la página de desambiguación ... que a su vez incluye un enlace a la sección de destino en la mitad de la página, en § Idioma . No hay nada más inconsistente que eso, ¿verdad?
Supongo que esto se debe a que ambos factores, que no son léxicos ni "dignos" de un artículo, hacen que sea más probable que las personas tengan ideas muy diferentes sobre si ese uso es "apropiado para ayudar al lector y cómo lo hace". determinar el contexto ", en palabras de la directriz. Entonces, tal vez este constituya un caso especial y deba tratarse como tal.
Por otro lado, tal vez esto no sea un problema: "la coherencia tonta [siendo] el duende de las mentes pequeñas ", y todo eso. ·· 2A02 : charla ·· 13:56, 17 de julio de 2021 (UTC)
Ilustraciones en Wikipedia
Una cosa que Wikipedia se queda corta en enciclopedias comerciales como Encyclopædia Britannica son sus ilustraciones. Casi todo el mundo puede escribir un artículo, utilizar citas y comprender las fuentes, pero a menudo las ilustraciones, especialmente en áreas temáticas más específicas y complejas, requieren habilidad para crear. Veamos el mapa de la Encyclopædia Britannica del West End de Londres ; vs el único mapa que tenemos . El foro dedicado para solicitar mapas es realmente impredecible, muchas solicitudes quedan sin respuesta. No se trata solo de mapas, especialmente en temas como geografía y ciencias, obtenemos malas ilustraciones. Nuestro diagrama para el ciclo del agua (que ni siquiera fue creado por un wikimediano) y el de Britannica . Especialmente a escalas más pequeñas, el diagrama anterior es demasiado detallado y contiene demasiado texto para leer.
Otro problema es la coherencia. En Wikipedia, los mapas están relativamente estandarizados (de ninguna manera al 100%), pero básicamente no hay pautas sobre otras ilustraciones. No hay pautas sobre las fuentes que deben usarse, los colores, las claves, lo que significa que casi todas las ilustraciones en Wikipedia no comparten convenciones, lo que significa que un lector tiene que adaptarse repetidamente de un estilo a otro.
Realmente no conozco una solución sólida para esto, creo que probablemente lo mejor sería que WMF contratara ilustradores profesionales, lo que significa que se podrían solicitar ilustraciones, similar al equipo de arte en WikiHow . Sin embargo, no sé si esto es económicamente viable. Sin embargo, creo que un buen paso para comenzar sería establecer convenciones sobre las ilustraciones y el estilo general que deben seguir (incluso entonces, esto no garantiza que las personas realmente sigan estas pautas). La estandarización de fuentes, colores y niveles de detalle sin duda beneficiaría al proyecto en su conjunto.
Puede que esté hablando tonterías, o tal vez no haya ningún problema en absoluto. Solo pensé que sería útil conocer las opiniones de los demás sobre este asunto. - Berrely • Talk ∕ Contribs 14:40, 17 de julio de 2021 (UTC)
- Si va a estandarizar, entonces internacionalice también. Cree un mecanismo para que una ilustración tenga una lista de subtítulos traducible separada (vinculada a posiciones en la ilustración), de modo que pueda reutilizarse fácilmente en Wikipedias de diferentes idiomas. Eso también compartiría el costo de creación en cada Wikipedia y les daría a los más pequeños acceso a un recurso fantástico. También podría permitir ajustes locales o individuales de tamaños de texto y fuentes .-- Verbarson ( charla ) 19:51, 17 de julio de 2021 (UTC)