Wikipedia: Bomba de pueblo (todos)

Esta es la página de la bomba Village (todos) que enumera todos los temas para una fácil visualización. Vaya a la bomba de la aldea para ver una lista de las divisiones de la bomba de la aldea, o haga clic en el enlace de edición que se encuentra sobre la sección en la que le gustaría comentar. Para ver una lista de todas las revisiones recientes de esta página, haga clic en el enlace del historial de arriba y siga las instrucciones en pantalla.

Haga clic aquí para purgar el caché del servidor de esta página (para ver los cambios recientes en las subpáginas de la bomba Village)

Secciones de bomba de pueblo
Política mensaje , reloj , la búsqueda discutir las políticas existentes y propuestas	Técnica posterior , reloj , buscar examinar cuestiones técnicas sobre Wikipedia	Propuestas publicar , reloj , búsqueda discutir nuevas propuestas que no están relacionadas con las políticas	Publicar , ver y buscar en el laboratorio de ideas Incubar nuevas ideas antes de proponerlas formalmente	Publicar , ver , buscar en WMF Discutir temas relacionados con la Fundación Wikimedia	Publicar , mirar , buscar mensajes varios Publicar mensajes que no encajan en ninguna otra categoría
Ver todas las secciones de bombas de la aldea a la vez

Otras ubicaciones de ayuda y discusión

Quiero...	Dónde ir
... ayuda para usar o editar Wikipedia	Casa de té (para usuarios más nuevos) o mesa de ayuda (para usuarios experimentados)
... para encontrar mi camino en Wikipedia	Directorio de departamentos
... hechos específicos (p. ej., ¿Quién fue el primer Papa ? )	Escritorio de referencia
... críticas constructivas de otros por un artículo específico	Revisión por pares
... ayuda para resolver una disputa de edición de artículo específica	Solicitudes de comentarios
... comentar un artículo específico	Página de discusión del artículo
... para ver otros proyectos de Wikimedia	Wikimedia Meta-Wiki
... para aprender a citar Wikipedia en una bibliografía	Citando Wikipedia
... para informar de sitios que copian contenido de Wikipedia	Espejos y horquillas
... para hacer preguntas o hacer comentarios	Preguntas

Las discusiones de más de 7 días (fecha del último comentario realizado) se mueven a una subpágina de cada sección (llamada (nombre de la sección) / Archivo).

¿Por qué Wikipedia no requiere que los editores tengan 13 años o más?

La mayoría de los sitios web con interacción del usuario requieren que los usuarios tengan 13 años o más. Creo que tener una edad mínima reduciría algo la cantidad de vandalismo en el sitio web. ¿Por qué Wikipedia no tiene una edad mínima? Félix An ( charla ) 14:39, 11 de abril de 2021 (UTC)

Supongo que podría pedirle a la gente que diga que tiene 13 años o más, aunque es posible que esas afirmaciones no sean ciertas. Selfstudier ( charla ) 14:42, 11 de abril de 2021 (UTC)

Esto es imposible de hacer cumplir. Se puede agregar una cláusula de este tipo a los términos de uso, pero los vándalos no se preocupan por los términos de uso de todos modos .-- Ymblanter ( hablar ) 14:43, 11 de abril de 2021 (UTC)

"La mayoría de los sitios web ..." ^{[ cita requerida ]} La mayoría de los vándalos no inician sesión de todos modos. Y los lectores pueden usar las cuentas para otras cosas además de editar. PrimeHunter ( charla ) 14:56, 11 de abril de 2021 (UTC)

Los sitios web hacen eso porque la Ley de Protección de la Privacidad Infantil en Línea limita qué datos personales se pueden recopilar de menores de 13 años. Wikipedia no tiene el hábito de recopilar información, por lo que no tiene esa preocupación en particular por la edad. - Nat Gertler ( charla ) 15:02, 11 de abril de 2021 (UTC)

WP no solo no recopila activamente el tipo de información del usuario que preocupa a tales leyes y regulaciones, sino que también aconsejamos a los jóvenes wikipedistas que no revelen su edad u otra información privada. Roger (Dodger67) ( charla ) 16:06, 11 de abril de 2021 (UTC)

Wikipedia, la enciclopedia en línea que cualquiera puede editar , no tiene ninguna calificación sobre quién puede editar más allá de aceptar los términos de uso . Este es uno de nuestros principios fundacionales . Ivanvector ( ^Talk / _ediciones ) 15:05, 11 de Abril 2021 (UTC)

Nadie debe ser juzgado previamente como un vándalo simplemente por su edad. Y la mayoría de los actos de vandalismo cometidos por menores de 13 años no serían muy sutiles, por lo que se detectarían y revertirían fácilmente. Es el vandalismo sutil, más oculto, del que más debemos preocuparnos, y la mayor parte proviene de editores más antiguos. Si vamos a prohibir que las personas editen porque podrían ser un vándalo, tendremos que prohibir a todos (incluso a mí, de 63 años) editar. Phil Bridger ( charla ) 15:50, 11 de abril de 2021 (UTC)

De acuerdo exactamente, y veo este prejuicio en muchos de los comentarios aquí, que parecen asumir que las ediciones de menores de 13 años son de alguna manera más o en promedio perjudiciales para Wikipedia. Si cree que puede conseguir menores de 13 años de Wikipedia prohibidas cuando usted cita ni la teoría ni la evidencia para apoyar su hipótesis aparentes, por favor, cuestionar seriamente su superioridad adulto. ⠀ Trimton ⠀ 01:00, 30 de Mayo 2021 (UTC)

Como se señaló anteriormente, realmente no tenemos un mecanismo para hacer cumplir un requisito de verificación de edad para los editores de WP en la escala sugerida por el OP. Tenemos la directriz WP: CIR que en la práctica elimina a la mayoría de los editores muy jóvenes. Personalmente, creo que tendría sentido tener un requisito de edad mínima para los administradores, aunque solo sea por razones legales. Nsk92 ( conversación ) 16:14, 11 de abril de 2021 (UTC)

@ Nsk92 : existe tal requisito para los miembros de Checkusers, Oversighters y ArbCom. Elli ( charla | contribuciones ) 21:04, 11 de abril de 2021 (UTC)

@ Félix An : ¿por qué debería hacerlo? Una edad mínima no reduciría el vandalismo en lo más mínimo, por lo que puedo decir (estoy seguro de que los aspirantes a vándalos de 12 años simplemente mentirían). Elli ( charla | contribuciones ) 21:04, 11 de abril de 2021 (UTC)

La razón por la que muchos sitios web tienen un requisito de edad mínima (13) es debido a la COPPA , que no se aplica a Wikipedia, ya que no recopilamos, usamos ni divulgamos la edad de un usuario. Izno ( charla ) 23:02, 11 de abril de 2021 (UTC)

Por lo que vale (y esto es periférico), creo que en los primeros días de Wikipedia había administradores que eran incluso menores de 13 años y puedo pensar en un titular que tenía 13 años cuando aprobaron la RfA. Las preguntas sobre la edad, por supuesto, surgen en las RfA, y muchos votantes no están dispuestos a votar por menores. También está el caso de en Internet, nadie sabe que eres un perro . Sdrqaz ( charla ) 17:10, 11 de abril de 2021 (UTC)

@ Sdrqaz : Sí, vea mis comentarios en Charla del usuario: Iridiscente / Archivo 41 # desvío-dentro-a-desvío de la edad . Graham 87 10:10, 12 de abril de 2021 (UTC)

Ah, eso es un poco interesante de historia, Graham (con un poco de comentario sobre Malleus). ¿Conoce algún RpA exitoso para menores en la era "moderna"? Recuerdo este RfA de 2015 , con el que me topé hace una semana aproximadamente, donde aproximadamente la mitad de los opositores tenían aproximadamente la edad (y el candidato también era mayor que muchos de los ejemplos más extremos). Sdrqaz ( conversación ) 12:41, 12 de abril de 2021 (UTC)

@ Sdrqaz : No, no conozco ninguno. Graham 87 13:40, 12 de abril de 2021 (UTC)

No puedo pensar en una RFA reciente y exitosa de alguien que se cree que es menor de edad, no me sorprendería si nuestro administrador actual más joven fuera mayor que un adolescente. Hay dos cosas que han hecho que la comunidad esté menos abierta a los adolescentes en la última década, la expectativa de usar citas en línea y una plataforma móvil que hace que Wikipedia sea apta para editar en teléfonos inteligentes o tabletas. Esto no solo nos da un sesgo étnico serio, sino que no representamos a la generación de teléfonos inteligentes. Ϣere Spiel Checkers 08:34, 13 de abril de 2021 (UTC)

@ WereSpielChequers : La generación de editores dedicados de teléfonos inteligentes no existe. Si bien existen excepciones, los consumidores de medios utilizan los teléfonos inteligentes y, más allá de las fotos y los videos, no tanto los creadores. Wikipedia es un cerdo para editar en teléfonos inteligentes o tabletas porque esos dispositivos carecen de un teclado físico. Nadie escribe un libro en un teléfono inteligente. Pueden corregir un error tipográfico aquí y allá, agregar una categoría o incluso una referencia, pero es mucho menos probable que agreguen una sección completa. - Alexis Jazz ( charla o de ping mí) 16:23, 13 de Abril 2021 (UTC)

@ Alexis Jazz : Escribir en dispositivos móviles no es tan malo: he descubierto que la escritura deslizante lo acelera y cuando estás acostumbrado a escribir en dispositivos móviles, la mecanografía táctil es realmente posible. Sin embargo, el punto sobre los consumidores de medios parece correcto. Sdrqaz ( charla ) 16:31, 13 de abril de 2021 (UTC)

@ Sdrqaz : Supongo que podrías acostumbrarte a cualquier cosa, pero incluso en un teclado de netbook probablemente te ganaría tanto en velocidad como en precisión. El problema tampoco es solo el teclado: la pantalla en una tableta o un teléfono grande sería casi adecuada, y para el consumo de medios lo es esencialmente, pero cuando comienzas a escribir, el teclado ocupa una gran parte, si no todo eso. pantalla. Puede que no sea imposible escribir texto en un dispositivo móvil si está capacitado en eso, pero cualquiera que realmente quiera escribir algo más que un breve comentario en las redes sociales o corregir un error tipográfico en WP probablemente dejará su dispositivo móvil por algo con un teclado físico. Entonces, volviendo atrás, Wikipedia no subrepresenta la generación de teléfonos inteligentes, los usuarios de teléfonos inteligentes subrepresentan Wikipedia. Lo que tiene sentido. Los Fiat Pandas son buenos autos para todos los días, pero están subrepresentados en las carreras de autos stock y eso es poco probable que sorprenda a nadie. - Alexis Jazz ( charla o de ping mí) 22:37, 14 de Abril 2021 (UTC)

Tengo un Fiat Panda y tengo un teléfono inteligente. Prefiero editar Wikipedia con Panda que con la interfaz móvil de Wikipedia. DuncanHill ( charla ) 23:11, 14 de abril de 2021 (UTC)

WereSpielChequers , eso es interesante. Estaba pensando en ello más en el sentido de cambiar los estándares de RpA que en una falta de representación. Personalmente, como editor móvil "puro" frecuente (usando el sitio web móvil, no el sitio de escritorio en un móvil a la Cullen), la interfaz es adecuada ( tal vez un débil elogio ). No puedes usar Twinkle o RefToolbar sin el método Cullen y es difícil tener dos ventanas abiertas a la vez para escribir mejor, pero no es tan terrible como dicen otros (la aplicación, por otro lado, es una historia diferente ). Las citas en línea se pueden hacer haciendo que Template: Cite web se abra en otra pestaña y copie el esqueleto o escriba los parámetros manualmente una vez que lo haya recordado.

Pensé que, en igualdad de condiciones (si ignoramos los estándares cambiantes en RfA), el cuerpo administrativo tendría miembros más jóvenes que hace una década porque los editores más jóvenes no tendrían que esperar su turno en la computadora de la familia y podrían simplemente editar en cualquier momento y en cualquier lugar.

Damas, ¿fueron las candidaturas exitosas de menores porque a los votantes no les importaba su edad o no lo sabían? ¿O tal vez los que sabían no lo publicaron para que el resto de los votantes no lo supieran? Sdrqaz ( charla ) 16:27, 13 de abril de 2021 (UTC)

He mirado hacia atrás en dos RFA de mujeres que estoy bastante seguro de que eran jóvenes cuando aprobaron su RFA. Uno en 2010 fue una llamada cercana en números, en retrospectiva, mi propia oposición fue demasiado dura y desde entonces solo me he opuesto por etiquetado de eliminación defectuoso donde he encontrado múltiples errores. Uno de los opuestos en ese fue explícitamente porque ella era una niña de la escuela, pero ningún oponente posterior mencionó eso o la palabra de madurez, y bastantes opuestos fueron del tipo "ya casi estás, vuelve en unos meses", que Dudo que fueran mayores. En 2007 encontré uno en el que había un voto neutral "No puedo animarme a apoyar a alguien tan joven", pero la RFA pasó 90 a 1. Lo que se ajusta a mi memoria de que la comunidad no solía verlo como un problema para tener muy administradores jóvenes. Puedo recordar un par de casos que fracasaron por poco en 2009, uno de los cuales tuvo varios editores que citaron "preocupaciones sobre la madurez", pero en ambos casos hubo errores recientes. Entonces yo diría que la comunidad solía nombrar administradores adolescentes a sabiendas. Tengo vagos recuerdos de una RFA más reciente en la que la expectativa se había vuelto más común de que los administradores deberían ser legalmente adultos. Ϣere Spiel Checkers 20:50, 13 de abril de 2021 (UTC)

Cosas interesantes, WereSpielChequers , gracias. Creo que sé a qué RpA de 2007 se está refiriendo; inusualmente tuvo una reconfirmación poco después. Mirando a un candidato de 13 años en otro, navegaron con el 98% de apoyo sin que nadie mencionara la edad, por lo que no estoy seguro de si alguien más sabía de su edad en ese momento. ¿Quizás el que estás pensando que era más reciente fue este de 2015 ? Parece que alrededor de la mitad de los opositores se basaron en la edad. Sdrqaz ( conversación ) 21:53, 13 de abril de 2021 (UTC)

Es casi seguro que lo era, a los 15 años era mayor que al menos uno de los incontestables de unos años antes y la mayoría de los que se oponían a la edad se basaban en el principio de su edad; también hubo una gran cantidad de contragolpes en la columna de apoyo de personas que rechazaron la discriminación por edad en la columna opuesta. Estoy bastante seguro de que algo cambió dentro o fuera de la comunidad en los años intermedios para cambiar la visión de Eric Corbett de un valor atípico a una minoría lo suficientemente grande como para probablemente descarrilar una RFA. Lo único en lo que puedo pensar que podría explicar el cambio es el escándalo de abuso sexual católico y el papel de los administradores para mantener ciertas cosas fuera de la pedia y tener acceso a las ediciones eliminadas. Dejaré que algún investigador futuro averigüe si un grupo de editores cambió sus puntos de vista sobre los candidatos jóvenes o si se trataba de un cambio en el electorado de la RFA. O de hecho, que para 2015 la comunidad ya no tenía muchos adolescentes o al menos administradores adolescentes. Pero claramente las cosas cambiaron y dudo que hayan vuelto a cambiar. Creo que la multitud de la RFA ha sido capaz de detectar candidatos muy jóvenes desde hace mucho tiempo. Ϣere Spiel Checkers 07:25, 14 de abril de 2021 (UTC)

Recientemente me encontré con un artículo de BLP que estaba siendo vandalizado activamente por un IP que volvía a agregar repetidamente una imagen pornográfica obscena al artículo en la caja de información en lugar de la foto del sujeto. Mientras revertía la IP, vi que la IP se bloqueó y luego recibí un correo electrónico desagradable a través de mi correo electrónico de Wikipedia con una amenaza de violencia. Poco después vi que el administrador de bloqueo revocó la página de discusión de la IP y el acceso al correo electrónico (supongo que el administrador recibió un mensaje similar). Estoy bastante seguro de que el administrador que respondió en ese caso era un adulto, pero en general creo que no deberíamos poner a los menores (por ejemplo, jóvenes de 15 años que resultan ser administradores) en la posición de tener que abordar este tipo de situaciones. . Nsk92 ( conversación ) 13:22, 18 de abril de 2021 (UTC)

Una edad mínima realmente no reduciría el vandalismo debido a la capacidad de editar de forma anónima. Si se requiere que los usuarios hagan clic en un botón que indique que tienen 13 años o más, cualquiera podría simplemente hacer clic en el botón, independientemente de si tienen o no 13. Además, el problema con esto es que las leyes son diferentes en diferentes lugares. Por ejemplo, un lugar podría tener una ley que establezca que la edad mínima para tener una cuenta de foro es de 13 años, mientras que otro lugar podría establecer que es de 18. Wikipedia es accesible para personas de todo el mundo. Entonces, si lo configuramos en 13, causaría problemas a los usuarios que editan desde lugares donde la edad mínima es inferior a 13.

TL; DR Agregar una edad mínima a Wikipedia haría más daño que bien. Blaze The Wolf | Proud Furry y editor de Wikipedia ( charla ) 20:07, 20 de abril de 2021 (UTC)

Muchas de las explicaciones parecen incompletas, y tampoco estoy seguro ... Escuché que COPPA no se aplica de la misma manera a organizaciones sin fines de lucro como WMF, pero podría estar equivocado. Si Wikipedia fuera una empresa con fines de lucro, entonces sí, se aplicaría la COPPA. La COPPA se aplica a cualquier empresa que recopile datos de menores de 13 años a través de Internet sin el consentimiento de los padres. Es por eso que sitios como wikiHow y Fandom hacen cumplir la COPPA. Aasim ( charla ) 06:13, 16 de mayo de 2021 (UTC)

@ Nsk92 : Ese es un argumento interesante: gran parte de la oposición a los administradores adolescentes se basa en la inmadurez percibida / juicio deficiente en lugar de como una medida de protección infantil. Con respecto al correo electrónico, puede deshabilitar la capacidad de los nuevos editores para enviarle correos electrónicos, pero, por supuesto, la hostilidad también está en el wiki. Sdrqaz ( conversación ) 22:50, 18 de abril de 2021 (UTC)

• Creo recordar que un editor que hizo buenas ediciones en artículos sobre dinosaurios tenía menos de 13 años cuando empezaron, así que no estoy seguro de por qué tenemos que excluirlos sobre esa base. FunkMonk ( charla ) 14:00, 12 de abril de 2021 (UTC)
• Tengo nueve años, en años de perro. - Roxy el sicomoro . wooF 14:03, 12 de abril de 2021 (UTC)

  Entonces, admites haber realizado tu primera edición previa a la concepción. ¿Puedo prestarme su máquina del tiempo? - Red rose64 🌹 ( hablar ) 10:57, 13 de abril de 2021 (UTC)

• Excluir a los adolescentes que obedecen reglas como no edt hasta los 13 años no nos hará perder a ningún vándalo. Podría hacernos perder algunos editores de buena fe, e incluso podría atraer algo de vandalismo por parte de los adolescentes que quieren demostrar que pueden presionar el botón de editar aunque no deberían. Así que no veo ningún beneficio de esta propuesta, y hay un pequeño inconveniente. Ϣere Spiel Checkers 08:40, 13 de abril de 2021 (UTC)

  De acuerdo . Si esto fuera factible de hacer cumplir, valdría la pena discutirlo. No lo es, entonces no lo es. {{u | Sdkb }}   ^charla 18:21, 13 de abril de 2021 (UTC)

• En los EE. UU., COPPA se aplica a todos los datos personales, incluso si se publican voluntariamente (información de contacto en una página de usuario, por ejemplo), si el operador sabe que el usuario es menor de 13 años. Sin embargo, las organizaciones sin fines de lucro están exentas. Seguimos las mejores prácticas al supervisar dicha información personal cuando la encontramos. - dlthewave ☎ 20:23, 13 de abril de 2021 (UTC)

• Si. Además, a propósito de los administradores jóvenes, puedo pensar en un árbitro cuando tenía 14 años, o posiblemente 15. Un buen árbitro también. Bishonen | tålk 12:24, 23 de abril de 2021 (UTC). Razones de frijoles recortados. Primefac ( conversación ) 12:56, 23 de abril de 2021 (UTC)

• De acuerdo . RaptorLake ( conversación ) 21:14, 15 de abril de 2021 (UTC)

• En Europa, ¿no se aplicaría el artículo 8 del RGPD ? Se procesan datos personales (IP, direcciones de correo electrónico). Pero supongo que la WMF se ha dado cuenta de esto con sus abogados. ProcrastinationReader ( charla ) 12:37, 18 de abril de 2021 (UTC)

Los niños de 11 y 12 años no deberían leer Wikipedia. Y sería difícil editarlo sin leerlo. La razón es que Wikipedia es explícita y fundamentalmente una publicación para adultos ("adulto" en el sentido de "XXX" en lugar de "complicado"), porque WP: NOTCENSORED es una política fundamental. Siempre pensé que otros sitios tienen una casilla de verificación "Tengo 13 años" en parte por razones de responsabilidad legal (para que puedan decir en la corte "Pero su señoría, ella dijo que tenía 13 años" o el equivalente). Estoy bastante seguro de que Wikipedia, como Facebook y Twitter, no es responsable del contenido publicado en ella. Si lo estuviéramos, estaríamos enterrados bajo demandas, pensarías. (Los escritores individuales son responsables, creo, pero difíciles de encontrar y probablemente pobres de todos modos). Así que no necesitamos la casilla de verificación de edad kabuki. Herostratus ( charla ) 13:15, 5 de mayo de 2021 (UTC)

• Umm, sí deberían, al menos en mi parte del mundo. ¿Pones una puerta en tus bibliotecas para evitar que los adolescentes accedan a la sección de referencia? - ^Charla xaosflux 17:28, 13 de mayo de 2021 (UTC)
  • Sí, estoy de acuerdo, si siguiéramos la lógica de Herostratus, los menores de 13 años no podrían usar Internet en absoluto, porque Internet no está censurado. No estar censurado no convierte ninguna publicación en pornográfica. Ahora soy abuelo, y mis hijos estaban en la primera generación que se crió con Internet cuando realmente estaba en su fase del "salvaje oeste", pero los crié con bastante normalidad para que se les permitiera usar lo que estaba disponible y ellos han salido bien. Pensé en responder a este comentario cuando apareció por primera vez, pero luego pensé que era tan ridículo que no merecía una respuesta, pero ahora que ha tenido una respuesta, necesito agregar mis dos centavos. Phil Bridger ( charla ) 17:48, 13 de mayo de 2021 (UTC)

Muy bien Usuario: Phil Bridger . Si permitió que los niños de 11 a 12 años entraran en sus habitaciones, cerraran la puerta y fueran a donde quisieran en Internet, eso no es algo de lo que presumir, por el amor de Dios. Aunque no había tantos nazis, qanons y 4chans entonces, no sé nada del salvaje oeste. Tuviste suerte (por lo que sabes) y bien por ti, pero ¿qué tiene eso que ver con nada? Esperar suerte no es una buena política para la mayoría de las cosas.

Soooo ..... Bukkake está a tres clics de Anime (-> Idioma japonés -> Lista de palabras en inglés de origen japonés -> Bukkake ). El anime es de interés para los jóvenes. ¡Es! Y hay una imagen que vale más que mil palabras, recuerda. Echar un vistazo. Echar un vistazo. Las niñas de 11, 12 y 13 años están muy interesadas en la respuesta a preguntas que giran en torno a "¿qué significa ser mujer?" Cosas como esta les dicen: "carne". Créame, también es intencional; he trabajado con este artículo y similares. Hay gente que no es muy agradable y no le gustan mucho las mujeres, ya veces vienen aquí. Al menos, después de un poco de trabajo, pudimos mencionar que esto es un tropo de la pornografía en lugar de algo que los adultos hacen en números notables, y también que no fue un castigo realmente usado en la historia de Japón. Difícil de hacer porque algunas personas creen que lo que ven en el porno es real. Necesitan para.

Pero me refiero a la imagen. Las imágenes dicen mil palabras y pasan por alto el filtro de procesamiento del idioma. Y tienes a Gokkun , que aparentemente la información de que es principalmente un tropo de pornografía y (en su mayoría) no es real ha sido eliminada; mantenerse al día y tratar con estas personas es agotador después de todo. De nuevo, la imagen. ¿Qué le dice la imagen a una niña de 12 años? "Tal vez tu primer chico te traiga flores, pero aquí es donde te lleva; tal vez irás a la 'universidad' y tendrás una 'carrera', pero no olvides: las mujeres son cubos de esperma y siempre lo serán". Facial (acto sexual) . Felching . No es útil que se les muestre esto a los niños que están teniendo su despertar sexual. Simplemente no lo es. Es posible que ignore el desarrollo infantil o que no le importe, y estos niños no podrían preocuparse menos, de nuevo, no es algo de lo que estar orgulloso, en mi opinión, pero no todos somos así.

Ver estas cosas no va a destruir a un niño, en su mayoría. Básicamente, los niños estarán bien. Los niños son resilientes y, por lo general, pueden estar básicamente bien cuando les suceden cosas como estas, como ser acosados, crecer en la pobreza, crecer en una casa infeliz, etc. Pero cosas así no ayudan . ¿OK? Simplemente no lo hace.

Me criaron para creer que tenemos una responsabilidad con otras personas y, en particular, con los vulnerables. Y los niños son vulnerables. Ellos son. Es por eso que tampoco los enviamos a trabajar en las minas cuando tienen 12 años, y por eso se espera que cuidemos su tiempo de crecimiento en buenas direcciones. La libertad de ir a explorar el arroyo hasta que oscurezca es una buena libertad. La libertad de mirar imágenes sobre Snowballing (práctica sexual) no lo es. Otras personas piensan de manera diferente, supongo.

Entiendo que tal vez mucha gente no creería una palabra de lo que he dicho. No pueden. Está bien. Hacemos lo que podemos con lo que tenemos. Sé que la gente necesita encajar en su propia imagen, ya sea "Soy tan liberal, sí" o "Soy tan conservador, que se jodan a los niños" o lo que sea que se trate de esa persona. Todo el mundo necesita ser el héroe de su propia historia, y "Soy partidario de los pornógrafos ('Uno que está involucrado en la ... difusión de pornografía' --Wiktionary, el diccionario gratuito), y donde los niños pasan el rato boot "no suena tan heroico cuando lo pones de esa manera. Lo hace.

De todos modos ... el objetivo de Wikipedia es ser un activo neto para la humanidad. No es solo un pasatiempo. No existe fuera del mundo moral humano; no existe nada, lo siento. Para los niños, la mejor forma en que Wikipedia puede ser un activo es no atraerlos ni involucrarlos. La mejor manera de hablar con los niños sobre Wikipedia es simplemente decir "Manténgase alejado de Wikipedia. Hay demasiadas personas WP: NOTVERYNICE y no se preocupan por sus intereses. Manténgase alejado de esas personas". Herostratus ( charla ) 20:01, 16 de mayo de 2021 (UTC)

Desde la primera oración (¿dónde dije que permití que mis hijos fueran a sus habitaciones y cerraran la puerta?), Esa publicación solo consiste en tonterías completas completamente fuera de tema. Me alegro de que no seas mi padre. Phil Bridger ( charla ) 20:18, 16 de mayo de 2021 (UTC)

• Según recuerdo, 13 años es la edad mínima para los burócratas. - Kusma ( t · c ) 18:25, 13 de mayo de 2021 (UTC)
  • Dado que los burócratas no tienen que ser identificados con la Fundación (creo), seguramente eso no es ejecutable. Sdrqaz ( charla ) 18:35, 13 de mayo de 2021 (UTC)
  • ^{[ cita requerida ]} - xaosflux ^Talk 18:46, 13 de mayo de 2021 (UTC)
    • Nuestro crat más joven tenía 13 años y no rompió nada. Por supuesto, eso fue en 2004 ... - Kusma ( t · c ) 20:03, 13 de mayo de 2021 (UTC)
• Muchos aquí asumen implícitamente que las ediciones de menores de 13 años dañan a Wikipedia en general, que los niños son una fuerza constante de vandalismo. ¿Son ellos? 1) ¿Dónde está la evidencia? No puede haber ninguna evidencia, ya que, como leíste en respuestas anteriores, Wikipedia no conoce la edad de sus editores. ¿Cómo puede estar tan seguro de que cualquier forma de vandalismo proviene de los niños? 2) ¿Dónde está la teoría? La inmadurez no tiene edad, la incapacidad no tiene edad, el analfabetismo no tiene edad. La mayoría de los menores de 13 años están en la escuela, lo que significa que literalmente estudian todo el día. ¿Cómo crees que no pueden agregar valor a una enciclopedia? Los niños crecen con la tecnología: ¿por qué cometerían errores de formato o romperían un ? Considere cómo debe sentirse un editor menor de 13 años, leyendo que la mayoría de los colaboradores aquí los asocian con el vandalismo, e incluso podrían prohibirlos, en el momento en que sea técnicamente posible. ⠀ Trimton ⠀ doce y cuarenta y ocho, 30 de Mayo 2021 (UTC)

Cuentas alternativas no reveladas

Fondo

Desde los primeros días de la Wikipedia en inglés, ha existido una tradición o costumbre de que algunos usuarios tengan cuentas alternativas conocidas o no reveladas. Esto se ha mantenido hasta cierto punto en la era moderna del proyecto y está consagrado en la política de WP: VALIDALT . Las cuentas alternativas divulgadas públicamente se pueden editar con total libertad de cualquier forma con pocas restricciones; sin embargo, WP: PROJSOCK establece que las cuentas no reveladas no pueden editar el espacio de nombres de Wikipedia. Wikipedia en inglés es algo atípico en este sentido: muchos otros proyectos de WMF consideran las cuentas alternativas no reveladas como títeres de calcetines ilegítimos. Por lo tanto, un comportamiento que sea técnicamente aceptable en EN.WP puede tener graves consecuencias si se practica en muchas otras wikis de WMF. La política existente deja en claro que la divulgación privada a ArbCom o funcionarios individuales no permite infracciones de la política, pero esto a menudo es mal entendido por los usuarios y puede generar frustración tanto por parte de los usuarios como de CheckUsers.

Asuntos

• Una prohibición total de las cuentas alternativas no reveladas que editan el espacio del proyecto da como resultado una situación en la que el contenido creado por un alt podría estar en discusión, por ejemplo a través de WP: AFD , o el comportamiento del usuario puede estar en discusión en foros como WP: ANI y por el carta de la política actual, el usuario no puede participar en esas discusiones en absoluto.
• Solo el Comité de Arbitraje tiene acceso a la lista de cuentas alternativas conocidas no reveladas. Esta información se considera privada y, por lo general, no se puede compartir, ni siquiera con los usuarios de cheques. Esto significa que un usuario podría haber revelado su cuenta alternativa al comité, solo para ser bloqueado por socks y la conexión entre las cuentas revelada públicamente, en el curso de una investigación legítima de sockpuppet .
• En realidad, no existe una obligación estricta de revelar cuentas alternativas a nadie. Por lo tanto, es probable que las cuentas conocidas por el comité de arbitraje o los usuarios de cheques individuales sean en su mayoría aquellas que no abusarían de ellas de todos modos, y representan solo una pequeña parte del número total de tales cuentas.
• No existe una forma razonable de controlar todas las ediciones de todas las cuentas alternativas conocidas para garantizar que se ajusten a la política.

Remedios propuestos

• No es problema de nadie más Cambiar el lenguaje de la política para desalentar activamente el uso de alternativas de privacidad y dejar en claro que si se descubre la conexión, no es responsabilidad de la comunidad, los funcionarios o el Comité de Arbitraje ocultarla. Si la conexión se aclara por el comportamiento del alt de privacidad, es culpa del operador de la cuenta.
• Aclare WP: PROJSOCK: establezca exenciones limitadas a la prohibición de espacio del proyecto para las discusiones de eliminación relacionadas con el contenido creado o editado por la cuenta alternativa, o discusiones sobre el comportamiento de las cuentas alternativas. Las discusiones más amplias sobre la política del sitio, el comportamiento de otros usuarios, etc., todavía están estrictamente fuera de los límites.
• Ya no se permite en absoluto : el uso de alternativas de privacidad se considerará obsoleto y se eliminará de la política. Cualquier usuario que opere más de una cuenta sin vincularlas públicamente por ningún motivo estará sujeto a la política de sockpuppetry . Esto no se aplicaría a las cuentas legítimas de inicio limpio en las que una cuenta se abandonó antes de que la nueva cuenta comenzara a editar. (esta opción es mutuamente excluyente con las otras opciones propuestas)

Discusión de los remedios propuestos

• Abrí esta discusión porque algunos eventos recientes han revelado una serie de problemas, identificados anteriormente, con la política sobre cuentas alternativas privadas. El primer remedio en particular me preocupa mucho. Las alternativas de privacidad corren por su cuenta y riesgo. Si lo arruinas y te detectan, la persona a la que le revelaste puede verificar que les revelaste un alt, pero eso no obliga a ese usuario a encubrir todo el asunto. En general, las cuentas alternativas privadas son solo una mala idea, y probablemente deberíamos ser más estrictos al desalentarlas, y también dejar en claro que la divulgación no es un pase libre para violar la política de calcetería. En cuanto al segundo remedio, simplemente no es justo que permitamos estas cuentas por razones de privacidad, pero según la carta de política, no pueden contribuir a ninguna discusión sobre el espacio del proyecto, incluso si se trata de su propio comportamiento o del contenido que crearon. El tercer remedio, lo agregué en caso de que suceda que la comunidad solo quiere terminar con esta práctica por completo, como lo han hecho muchos otros proyectos. No he propuesto una redacción específica, se trata más de buscar un consenso sobre las ideas, los redactores de palabras pueden entrar allí y crear la redacción adecuada si se llega a ese consenso. Beeblebrox ( charla ) 22:15, 15 de abril de 2021 (UTC)

  Beeblebrox , Gracias por iniciar esta discusión. Sospecho que llamará la atención lo suficiente como para que desee dividirlo en su propia subpágina. - RoySmith (conversación) 22:23, 15 de abril de 2021 (UTC)

• Una cosa que me gustaría que se agregara a la opción 2 es permitir que los alts no revelados hagan preguntas en los lugares apropiados (Teahouse, Help Desk, ese tipo de cosas), ya que la letra de la ley dice que esos son espacios de proyectos pero no son exactamente espacios de formulación de políticas. La gente también hace preguntas legítimas en los surtidores de la aldea, pero no estoy seguro de si incluirlas en esta excepción, ya que son más lugares de "discusión interna de políticas de proyectos". GeneralNotability ( charla ) 22:17, 15 de abril de 2021 (UTC)
• Pregunta : Entiendo las razones de las cuentas alternativas públicas (como tener una alternativa para computadoras públicas o en el trabajo), pero ¿cuáles son las razones (en el pasado, al menos) para permitir cuentas alternativas privadas o no divulgadas? Schazjmd  (charla) 22:21, 15 de abril de 2021 (UTC)

Me gustaría saber esto también. No tengo ningún problema con las cuentas alternativas no reveladas que sacarían a alguien a quien no se le paga, pero si no desea conectarse potencialmente con su empleador, una solución simple es no editar sobre ellas. Nadie te está obligando a hacerlo y, a la inversa, nadie te está obligando a editar Wikipedia en absoluto. TAXIDICAE💰 22:27, 15 de abril de 2021 (UTC)

Consulte el comentario directamente a continuación para ver un ejemplo. A menudo se trata de no querer "revelar" algún aspecto específico de su vida, ya sea algo mundano como se menciona a continuación, o quizás editar temas controvertidos sobre religión o prácticas sexuales. Beeblebrox ( charla ) 22:32, 15 de abril de 2021 (UTC)

@ Schazjmd : esa es una buena pregunta. El ejemplo común de la vieja escuela de por qué alguien tendría un alt "secreto" es editar temas embarazosos, por ejemplo, ciertos temas de sexualidad. Otra posibilidad es editar un tema, cuya edición con la cuenta principal puede comprometer la privacidad del usuario. Otra posibilidad podría ser que un editor de Wikipedia existente haya asignado un trabajo de curso que implique la edición de Wikipedia, y no quiera que esté asociado con la cuenta principal, ya sea de cualquier lado, por así decirlo (en wiki en términos de una asociación con una universidad determinada, o tener colegas universitarios conocen la existencia de la cuenta principal). En algunos casos, existen implicaciones del mundo real en el sentido de que los editores de Wikipedia pueden experimentar problemas con las autoridades locales como resultado de ciertas ediciones.

Al fin y al cabo somos un proyecto que permite editores seudónimos. Aparte de ejecutar ciertos checkusers masivos, algo que no es un principio en lo que respecta a la política de privacidad, debemos aceptar que no hay mucho que se pueda hacer acerca de que alguien use dos cuentas para editar temas separados. Por supuesto, existen evidentes usos engañosos de múltiples cuentas; Piense en apilar votos en una AfD o en casos en los que un usuario prohibido utiliza varias cuentas para evadir la prohibición y continuar con la misma interrupción que llevó a la prohibición. Dicho esto, se debe considerar si el simple hecho de usar una cuenta alternativa es de alguna manera un problema. Maxim _(charla) 23:34, 15 de abril de 2021 (UTC)

Praxidicae , he editado con un alt no revelado en el pasado. No todo el mundo está de acuerdo con estar conectado a artículos sobre enfermedades, política, religión y sexualidad. También hay una foto por aquí en algún lugar del pene perforado de un wikipedista que ayudé a anonimizar. Hicieron una solicitud para desaparecer cuando encontraron clientes potenciales que buscaron en Google su nombre y encontraron un pene perforado como el mejor resultado. De hecho, tomó años, pero lo revisé nuevamente y parece que Google * finalmente * lo ha olvidado. - Alexis Jazz ( charla o de ping mí) 15:04, 30 de Abril 2021 (UTC)

Sí, recuerdo que usaste un alt no revelado en el pasado. AntiCompositeNumber ( conversación ) 23:48, 30 de abril de 2021 (UTC)

• Espero que la tercera sugerencia no se tome en serio. Tengo algunas fotos que he querido agregar a algunos artículos cuando llegue. Estas fotos se remontan a mi identidad en el mundo real. ¿Realmente debería tener que elegir entre agregar las fotos y salir yo mismo? Porque no veo otra forma de agregar las fotos que crear una "alternativa de privacidad". Suffusion of Yellow ( charla ) 22:24, 15 de abril de 2021 (UTC)
  • Asumí que alguien lo propondría durante el curso de la conversación, así que simplemente lo publiqué. Beeblebrox ( charla ) 22:32, 15 de abril de 2021 (UTC)

  Suffusion of Yellow , independientemente de los cambios anteriores, usar una cuenta separada solo para cargar imágenes no debería ponerlo en riesgo. Bloquear a alguien por usar varias cuentas requiere evidencia de comportamiento (con o sin evidencia técnica), por lo que la posibilidad de que alguien conecte esas dos cuentas es prácticamente nula. (Sí, ocurren errores, y los usuarios de cheques ocasionalmente ejecutan cheques que no deberían, pero esa es también la razón por la que existe la supervisión) - brad v 🍁 23:27, 15 de abril de 2021 (UTC)

  No importa si te atraparán por subir las imágenes. Importa que va en contra de las reglas. He estado en casos similares a Suffusion of Yellow y estoy de acuerdo en que la tercera sugerencia es ridícula. Si hay un caso de uso común de personas que eluden una regla sin causar daño, sin forma de detección y de una manera que nadie podría objetar, entonces es una mala regla. Aunque en mi caso, en realidad me impediría subir fotos por completo, porque seguiría la regla incluso si no tiene sentido y no se puede hacer cumplir (consecuencias demasiado altas por una recompensa demasiado baja). (Y aunque Commons no está bajo nuestro alcance, esta redirección suave y el hecho de que haya usado o usaría una cuenta en.wiki para agregar las imágenes cargadas a los artículos significa que esta es nuestra jurisdicción). - Bilorv ( hablar ) 12: 17, 16 de abril de 2021 (UTC)

• Realmente solo apoyaría 2 como está redactado, y podría apoyar 1 si se elimina el lenguaje sobre "desalentar activamente". Nunca he usado una cuenta alternativa, pero respeto que otros puedan considerarla necesaria. Estoy de acuerdo en que nadie tiene la obligación de mantener en secreto el conocimiento de la cuenta secundaria de otra persona, SIN EMBARGO, también puedo entender razones legítimas para usar una cuenta secundaria. Aún así, deberíamos desalentar las cuentas de buena mano / mala mano, o propósitos similares, como participar en discusiones de políticas mientras se oculta la actividad anterior en Wikipedia, pero estoy de acuerdo en que se deben permitir excepciones cuando la cuenta alternativa tenga un interés en la discusión. , como AFD para artículos en los que la cuenta es un colaborador. Sin embargo, Wikipedia no debe fomentar ni desalentar el uso de alternativas privadas con la única salvedad de que es probable que las violaciones reales de la confianza de la comunidad tengan consecuencias. - Jayron 32 22:35, 15 de abril de 2021 (UTC)
• (Este hilo se movió de su propia sección originalmente titulada Un ejemplo difícil ): Supongamos que soy miembro de la Sociedad Internacional de Investigación de la Tierra Plana y he realizado muchas ediciones de publicaciones desde mi cuenta personal (con un nombre de cuenta que no es PII) adoptando este punto de vista, incluida una participación vigorosa en AfD y otras páginas de espacios de nombres de WP. En mi trabajo diario, soy empleado de la NASA, donde mis responsabilidades laborales incluyen la computación de trayectorias para misiones espaciales. No le he dicho a mi empleador mis creencias sobre la tierra plana porque ese conocimiento afectaría mi avance profesional. Asuma por el momento que a pesar de mis opiniones privadas, soy bueno en mi trabajo. Un día, mi jefe se me acerca y me dice: "Necesitamos un WP: Wikipedian in Residence para curar artículos sobre la NASA, y ya está. Sus responsabilidades laborales incluirán participar activamente en las discusiones sobre qué artículos conservar o eliminar". La opción "Ya no se permite en absoluto" me pondría en un aprieto. No hay forma de que pueda realizar mi trabajo sin romper nuestra política de calcetines o sin hablar con mi empleador. Si no le gusta mi ejemplo de la NASA, estoy seguro de que puede pensar en situaciones similares. - Comentario anterior sin firmar agregado por RoySmith ( charla • contribuciones ) 22:41, 15 de abril de 2021 (UTC)

  Aparte del absoluto absurdo de este ejemplo, el avance de su carrera no es un problema de Wikipedia, ni debería serlo nunca. Puede rechazar un WIR o ser sincero: la transparencia es la clave aquí. No es necesario que lo haga usted mismo agregando su nombre completo o incluso su nombre de pila. La divulgación no requiere identificarse. WIR es otro asunto y no es realmente relevante para esta discusión. TAXIDICAE💰 22:47, 15 de abril de 2021 (UTC)

  Praxidicae , ¿Por qué es absurdo el ejemplo? Tenemos muchos ejemplos de personas que editan como requisito de su empleo. Un departamento en una universidad que desea que cada miembro de la facultad tenga una página de wikipedia y asigne ese trabajo a alguna persona de bajo nivel en la oficina del departamento. Hemos visto ese escenario varias veces. - RoySmith (conversación) 22:56, 15 de abril de 2021 (UTC)

  Y esa persona puede rechazar esa solicitud de su empleador si viola los términos de uso del sitio por la misma razón que un empleador que exige que un empleado infrinja una ley o política debería ser rechazado. Nadie te obliga a editar como voluntario o editor pagado y nuestra política ya es lo suficientemente clara al respecto. TAXIDICAE💰 23:25, 15 de abril de 2021 (UTC)

  RoySmith , en este caso, podría dejar de editar desde su cuenta anterior. El uso de cuentas en serie no constituye sockpuppetry, a menos que esté sujeto a un bloqueo o prohibición. - brad v 🍁 23:15, 15 de abril de 2021 (UTC)

  Pero, ¿qué pasa si están sujetos a bloqueo u otra restricción? Continuando con el ejemplo de la NASA, nuestro editor teórico (llamémosle Tarquin) es presumiblemente un buen colaborador y positivo neto para la enciclopedia, pero tal vez se les prohíba editar artículos sobre la hipótesis del tiempo fantasma o tienen una prohibición de interacción mutua con otro usuario. ? Si Tarquin simplemente se mantuviera alejado de esos temas / editores, probablemente no seríamos más sabios, pero sería una violación de la política y, obviamente, la otra parte de la prohibición de interacción no sabría que debe mantenerse alejada de la nueva cuenta. Thryduulf ( conversación ) 01:28, 16 de abril de 2021 (UTC)

  Si alguien está sujeto a una prohibición, no debería crear una nueva cuenta o aceptar un puesto de edición remunerado, especialmente si no es completamente transparente tanto con su empleador como con la comunidad de edición. Eso está prohibido actualmente tanto por nuestra política de sockpuppetry como por nuestra política de edición paga, y ninguno de los cambios propuestos anteriormente lo alteraría. - brad v 🍁 02:07, 16 de abril de 2021 (UTC)

  @ Thryduulf : Creo que podría haber elegido un mejor ejemplo para un nombre de usuario. :-) Ese usuario me es muy familiar por sus primeros trabajos en matemáticas y artículos de música clásica. Creo que nunca hablé personalmente con Tarquin, pero su nombre me resulta muy familiar en las historias de las páginas y en las páginas de conversación antiguas. Espero que esto le divierta tanto como a mí; Lo he mencionado en su página de discusión. Graham 87 08:46, 16 de abril de 2021 (UTC)

  En un rol de WiR pagado, ya tiene el mandato de divulgar sus cuentas alternativas según la política actual Wikipedia: divulgación de contribución pagada # Cómo divulgar : "los editores pagados deben proporcionar enlaces a la (s) página (s) de usuario de su (s) cuenta (s) de Wikipedia en cada sitio web en el que anuncian, solicitan u obtienen servicios de edición de pago, así como en las comunicaciones directas con cada cliente y cliente potencial (por ejemplo, a través del correo electrónico). Si el editor de pago ha utilizado o controlado más de una cuenta de Wikipedia, cada cuenta debe divulgarse." Esto se agregó en un RfC reciente. -  Finnusertop ( charla ⋅ contribuciones ) 23:17, 15 de abril de 2021 (UTC)

  No está del todo claro si esto se aplica a los wikipedistas residentes y en qué medida. También es total y absolutamente inaplicable porque nunca podemos (y debemos) conocer el contenido de toda comunicación privada, como se señaló repetidamente cuando se propuso. También tengo dudas de que estipular el contenido de la comunicación entre el empleador y el cliente (potencial) sea algo sobre lo que sea incluso legal que un tercero imponga restricciones. Thryduulf ( conversación ) 01:01, 16 de abril de 2021 (UTC)

• Expliqué mis preocupaciones con WP: PROJSOCK en otro lugar. Solo puedo ver lo que puedo leer del historial, por lo que tal vez alguien que estuvo allí conozca mejor el contexto y pueda señalar cualquier error, pero su aplicación actual no tiene sentido para mí. La mayoría de los usos ilegítimos son obvios por qué están prohibidos; no puede usar varias cuentas para pretender ser varias personas de una manera que refuerce su posición, evite el escrutinio o engañe a los editores. Pero PROJSOCK no es intuitivo de la misma manera. Se cita a un caso de ArbCom de 2007 donde la evidencia era un editor que abusaba de múltiples cuentas para participar en discusiones de políticas mientras evitaba el escrutinio. La comunidad parece haberlo redactado estrechamente a esto (y variantes similares) durante años después del caso, aclarando que Las cuentas alternativas no deben editar políticas, pautas o sus páginas de discusión; comentar en procedimientos de arbitraje; o votar en solicitudes de administración, debates de eliminación o elecciones. Todo eso tiene sentido y también se desprende directamente de la evidencia del caso. Luego, en 2014, alguien editó audazmente la página a la "cita [] de la decisión subyacente de Arbcom" más vaga que dice Las cuentas alternativas no divulgadas no deben usarse en discusiones internas del proyecto . Como lector, Las discusiones internas del proyecto son ambiguas, ya sea que signifique una prohibición del espacio de nombres o (de hecho, como parece haber sido la interpretación original) solo discusiones de consenso, y una prohibición del espacio de nombres de Wikipedia no se sigue lógicamente de la evidencia en ese caso. Hacer preguntas en los lugares (incluido WP: VPT , que si bien es una "bomba de pueblo", se usa para hacer preguntas, no discusiones de consenso sobre la elaboración de políticas) está totalmente bien, por ejemplo. Esa edición de 2014, al menos como se interpreta ahora, parece haber sido un cambio material. ¿Hubo una discusión que condujo a eso? ¿Por qué el espacio de nombres de WP es más problemático que cualquier otra NS? ProcrastinationReader ( charla ) 22:44, 15 de abril de 2021 (UTC)
  • Para ser explícito, votaría para comenzar eliminando PROJSOCK, ya que claramente se ha malinterpretado por la razón original por la que se escribió, ya que es redundante para los ejemplos existentes. Pero veo que esto no se excluye mutuamente con algunos otros remedios, que se extienden más allá del espacio del proyecto. ProcSock ( charla ) 12:49, 27 de mayo de 2021 (UTC)
• (Basado en su antiguo sandbox , supuse que la opción 1 incluye CU que revelan conexiones) Presumiblemente, los usuarios pueden estar sujetos a verificaciones discrecionales por varias razones, y la política de CU es bastante vaga en cuanto a los motivos para una verificación. Por lo tanto, al leer esa opción ahora, un cheque discrecional podría resultar en la salida de una cuenta de privacidad (posiblemente ya revelada a ArbCom de la que la CU no estaba al tanto, pero incluso si no, no tratamos la ignorancia de la política como intentos deliberados de violar política), por lo que la CU sigue adelante y vincula las dos cuentas públicamente. Entonces, básicamente, tendrías editores de salida de CU, con evidencia técnica sólida para disipar cualquier duda también. Lo cual no es justo a primera vista. ProcrastinationReader ( charla ) 22:57, 15 de abril de 2021 (UTC)
• Mi permanencia en el Comité de Arbitraje, y como usuario de control, me hizo consciente de muchas situaciones en las que el uso de una cuenta alternativa era la única forma legítima de continuar participando en el proyecto. También vi una serie de situaciones en las que el uso legítimo se convirtió en ilegítimo. A menudo, esto era por accidente, pero si alguien ve ese desliz, el gato no volverá a meterse en la bolsa. El conflicto entre las cuentas alternativas y el compromiso de Wikipedia con la transparencia es irresoluble. Me referiré al comité actual sobre si creen que el sistema actual es sostenible. Personalmente, no me gustaría que me confiaran esa información, y si estuviera tratando de evitar el escrutinio y aún así editar Wikipedia (una tarea difícil), sería reacio a revelar esa información a nadie. Mackensen (charla) 23:01, 15 de abril de 2021 (UTC)

  Mackensen , acabo de notar que usted fue parte del Comité que aprobó el principio que llevó a PROJSOCK ( Wikipedia: Solicitudes de arbitraje / Privatemusings § Sockpuppetry ). ¿Cuál fue el razonamiento detrás de esto? Las dos primeras oraciones son intuitivas, pero no entiendo esa restricción final. Haciendo ping a esos miembros del Comité. Sdrqaz ( conversación ) 21:57, 16 de abril de 2021 (UTC) ​ ​ ​ ​ ​ ​ ​

  Sdrqaz wow, qué cosa tan jodida {{ bcc }} es. ¿Cómo diablos se supone que un destinatario debe saber en qué parte de la página se ha colocado en CCO? De lo contrario, mi opinión sobre sockpuppetry (odio ese término) es la misma que tenía en ese entonces: "En general, debería estar prohibido. Wikipedia no es un juego de rol". Pero no iba a ganar ese argumento, por eso me he divorciado de toda participación en la política de Wikipedia; Soy un mal perdedor. --jpgordon ^{𝄢𝄆 𝄐𝄇} 00:56, 17 de abril de 2021 (UTC)

  Lo siento, jpgordon . Solo lo uso cuando siento que se hace ping a demasiadas personas. Gracias por compartir tu opinión sobre sockpuppetry. Sdrqaz ( charla ) 17:12, 17 de abril de 2021 (UTC)

  Sdrqaz , no creo que pensáramos que estábamos diciendo nada nuevo. Vea, por ejemplo, mis comentarios en Wikipedia: Solicitudes de arbitraje / Privatemusings / Workshop # Cuentas alternativas : El uso de una cuenta alternativa para suscitar debates políticos mientras la cuenta principal hace algo diferente nunca ha sido aceptable en Wikipedia . Se entendió que Sockpuppetry significaba el abuso de múltiples cuentas; El uso de varias cuentas de forma no abusiva estaba mal visto pero no prohibido. Mantener un mechero para agitar las cosas en las páginas de políticas eludía la responsabilidad. Mackensen (charla) 23:22, 16 de abril de 2021 (UTC)

  Sdrqaz , dicho eso, esta fue aparentemente una afirmación controvertida en ese momento (estoy seguro de que lo supe una vez, pero lo había olvidado). Consulte la charla de Wikipedia: Solicitudes de arbitraje / Privatusings / Decisión propuesta # Principio 3 sobre la política de sockpuppet . Mackensen (charla) 23:27, 16 de abril de 2021 (UTC)

  Me pincharon en esta discusión. El tema polémico parece ser la justicia natural de excluir las cuentas privadas no reveladas de Wikipedia: espacio de nombres. Mi reacción aquí es "muy mala". Mantendría el principio y solo señalaría que puede haber circunstancias atenuantes para dicha edición. En general, queremos saber que los usuarios editan de buena fe desde cuentas individuales en discusiones internas, y encuentro que dicha "restricción" es natural en el nivel de los principios de ArbCom. Charles Matthews ( charla ) 07:12, 17 de abril de 2021 (UTC)

  Gracias, Mackensen y Charles . Mackensen, ¿tal abuso no estaría incluido en la parte de la política de "evitar el escrutinio"? No creo que se deba alentar el PROJSOCKing (y el mantenimiento de cuentas en el caso de Privatemusings posiblemente cae dentro de esa evasión), pero una prohibición general no me sienta bien. Sdrqaz ( charla ) 17:12, 17 de abril de 2021 (UTC)

• Preferiría que se modificara PROJSOCK. Hay casos en los que una alternativa de privacidad es útil. El hecho de que no estemos censurados no significa que el mundo sea el mismo. Pueden ser particularmente útiles para mantener artículos sobre salud sexual. Un ejemplo reciente es el RfD para Tiny penis. Es razonable no querer eso en la parte superior de su historial de contribuciones, y siempre que el editor no sea engañoso o se comporte de una manera que los sepa, deberíamos permitir cambios de privacidad en discusiones de esa naturaleza y no desaliente activamente su uso. - Wug · a · po · des​ 23:24, 15 de abril de 2021 (UTC)
• Generalmente apoyo la propuesta 2. Hay razones para las cuentas privadas. Si bien los editores obviamente no pueden estar obligados a "encubrirlo", eso no significa que tengamos que elegir un enfoque de todo o nada. Por ejemplo, una investigación de marionetas podría tener los detalles revocados si se acordó que no se ha producido una infracción, pero se requiere una divulgación importante para demostrarlo. No estaríamos en peor situación, aparte de unos minutos de tiempo administrativo. Algunas enmiendas menores a la naturaleza de la propuesta 2 para incluir servicios de asistencia técnica, etc., en la exención también parecen razonables. Originalmente me había preguntado "por qué no volver a la cuenta principal para preguntar", pero me di cuenta de que ciertas preguntas requerirían la suficiente especificidad como para herir accidentalmente las cuentas. Un cambio adicional que propondría sería autorizar formalmente a ARBCOM a compartir detalles sobre alts privados con CUs Nosebagbear ( charla ) 23:52, 15 de abril de 2021 (UTC)
• Si nunca las dos cuentas se encontrarán, ¿por qué debería importarnos? En ausencia de la búsqueda de partes significativas, ¿es realmente un problema si un editor logra mantener con éxito dos personalidades wiki alternativas durante años y años? Los riesgos deben divulgarse por adelantado (opción 1) y, a partir de ahí, debe ser responsabilidad del editor asegurarse de que las dos personalidades nunca estén en el mismo lugar. Una vez que llaman la atención de un CU Y violan la política, entonces la revelación pública puede ser una consecuencia (aunque apuntando a cosas como WP: BLP, hemos expresado una aversión a la exposición que podría conducir a daños en el mundo real de los sujetos, aunque los editores adivinan no obtengas la misma cortesía). En resumen, parece que no deberíamos jugar un juego de gotcha hasta / a menos que el pseudoanonimato no sea una política central de en-wiki. Slywriter ( charla ) 00:07, 16 de abril de 2021 (UTC)
• Una opción 2 modificada (con las advertencias de la opción 1) es realmente la única opción práctica aquí, pero en lugar de enmiendas menores, debería reescribirse al por mayor para centrarse exclusivamente en detallar qué actividades y comportamientos están prohibidos. Por ejemplo, queremos que los editores puedan resaltar problemas y problemas potenciales con artículos / páginas de proyectos / problemas técnicos, queremos que puedan responder a consultas sobre su edición, queremos que puedan hacer preguntas destinadas a mejorar su edición, etc. No queremos que se tergiversen como más de una persona, no queremos que voten varias veces en una discusión, no queremos que eludan sanciones, etc. Todas estas cosas son igualmente deseables o no deseables, independientemente del espacio de nombres en el que se encuentren. Pedir ayuda en la página de discusión de un artículo no es diferente a pedir ayuda en una página de Wikiproject o en la casa de té, discutir la confiabilidad de una fuente en la página de discusión de un artículo es no es diferente a discutir la confiabilidad de una fuente en WP: RSN . Discutir los cambios en una plantilla utilizada en las páginas de los usuarios es sin duda una "discusión interna del proyecto", pero no veo ninguna justificación posible para excluir las alternativas de privacidad de dicha discusión, doblemente si se excluyen si la discusión ocurre en el espacio de nombres de Wikipedia pero no si sucede en el espacio de nombres de conversación de la plantilla. Si hay ciertas discusiones de las que es necesario excluir a dichos usuarios (y estoy teniendo dificultades para pensar en alguna), entonces debemos detallar cuáles son esas discusiones y, lo que es más importante, por qué excluyeron (es más probable que las personas cumplan con las reglas que entienden el propósito de esas reglas no lo hacen). Thryduulf ( conversación ) 01:17, 16 de abril de 2021 (UTC)
• Estaba escribiendo algo, luego Thryduulf lo expresó de una manera mucho más elegante. No tengo ninguna objeción a que las cuentas secundarias privadas editen el espacio del proyecto y eliminaría PROJSOCK por completo. Se aplicarían las disposiciones estándar de WP: BADSOCK , como votar dos veces en la misma AfD (aunque eso anularía el punto de una cuenta secundaria "privada"), votar dos veces en la misma discusión, editar los mismos artículos, etc. Sdrqaz ( hablar ) 01:24, 16 de abril de 2021 (UTC)

  Sdrqaz , estoy tratando de pensar en algún comportamiento verdaderamente problemático que esté prohibido por PROJSOCK pero que no esté cubierto por una de las otras disposiciones, y no puedo pensar en ninguno. Eliminar esa línea por completo puede, de hecho, ser la solución más sencilla. - brad v 🍁 02:09, 16 de abril de 2021 (UTC)

  Gracias, Bradv . Estoy dispuesto a cambiar de opinión si alguien presenta un buen argumento, pero estoy gratamente sorprendido de cómo lo ven los comentaristas hasta ahora; había pensado que la mía sería una opinión minoritaria debido al deseo de transparencia. Sdrqaz ( conversación ) 17:56, 16 de abril de 2021 (UTC)

• Desguace WP: PROJSOCK suena bien, dado que todas las áreas en las que la edición de espacio de proyectos crea problemas parecen ser tratados por otras restricciones. Tamwin ( charla ) 07:02, 16 de abril de 2021 (UTC)
• Estoy de acuerdo en que WP: PROJSOCK se elimine . Tal como está escrito, no tiene mucho sentido porque puede que no quede claro qué cuenta es la alternativa y cuál es la principal. Y no está claro qué significa "discusiones internas del proyecto" o por qué esto es importante. Andrew 🐉 ( charla ) 08:56, 16 de abril de 2021 (UTC)
• Desecho WP: PROJSOCK . Todo el asunto contradice a Wikipedia: un comienzo limpio durante años, a pesar de que lo último es una política (en lugar de un ensayo). Lo único que tenemos que hacer para evitar que las cuentas alternativas hagan es evadir el escrutinio, eludir las restricciones de edición y crear una falsa ilusión de apoyo para una acción (y cualquier otra cosa que no sea controvertida, me estoy olvidando de la parte superior de mi cabeza). Nuestras reglas aquí son ridículas. Digamos que alguien edita cuando era niño y regala demasiada información personal (no lo suficiente para dox, solo lo suficiente para que se preocupen de que combinado con el tema de sus ediciones o la zona horaria u otra cosa, es suficiente para no desear ser público). Digamos que alguien copia y pega el texto incorrecto sin darse cuenta, es información personal y, cuando se puede pasar por alto, tiene miedo de que alguien lo haya visto y guardado. O alguien escribe algo borracho con mucha información estúpidamente. Estas tres personas tienen la opción de perder todo el derecho a la privacidad o no volver a editar Wikipedia correctamente (solo las ediciones del espacio principal no son "correctamente"). La gente aquí está subestimando la cantidad de información que los editores pueden regalar involuntariamente en evidencia de comportamiento, como contribuciones de conocimiento del tema, marcas de tiempo de ediciones, ediciones sobre temas localizados, etc., y cuánto valoran la privacidad algunas personas. Si un editor experimentado quisiera una nueva cuenta solo para evitar que la evidencia de comportamiento se acumule lo suficiente como para que puedan ser atacados, entonces esa es una razón suficientemente buena.
  Si alguien inicia un SPI basado en una alternativa válida, entonces debe comunicarse con ellos por correo electrónico o comunicarse con un empleado de CU / SPI por correo electrónico y explicar la situación. Luego, se debe descartar el SPI, con el cierre escrito para crear la menor sospecha posible. Situación difícil sin una solución ideal, pero es mejor que nada. Si cree que su alt ahora no se puede utilizar debido a la conexión establecida, a pesar de que el SPI se descartó, inicie una nueva alt válida. - Bilorv ( conversación ) 12:17, 16 de abril de 2021 (UTC)

  Bilorv , la creación de una nueva cuenta, siempre y cuando la anterior no esté bajo algún tipo de sanción o bloqueo, no es y nunca ha sido sockpuppetry y no viola PROJSOCK. Es solo sockpuppetry (y eso incluye PROJSOCK) si opera varias cuentas simultáneamente. GeneralNotability ( charla ) 19:46, 16 de abril de 2021 (UTC)

  @ GeneralNotability : dice quién? WP: SOCK dice "La regla general es un editor, una cuenta", "sockpuppetry o socking, se refiere al uso indebido de varias cuentas de Wikipedia", "Los editores no deben usar cuentas alternativas para engañar, perturbar o socavar el consenso". etc. No se menciona si los está operando simultáneamente. PROJSOCK dice, en su totalidad, "Las cuentas alternativas no divulgadas no deben usarse en discusiones internas del proyecto", ¿correcto? La página no define "alternativa", pero siempre he entendido que significa "segunda cuenta o posterior creada" (con complicaciones en el caso de la edición de IP). Si ese no es el caso y no he pasado por alto una definición, entonces es necesario definirla adecuadamente. También me parece que un contraejemplo a su comentario es que WP: BADSOCK enumera explícitamente " Uso indebido de un inicio limpio", un término que se refiere específicamente a una nueva cuenta que nunca opera junto con una cuenta anterior, como una instancia de sockpuppetry sancionable. (Aunque esta viñeta es casi exactamente lo opuesto a CLEANSTART, ya que el uso principal de un comienzo limpio es cuando crees que te has equivocado y quieres tener la oportunidad de dejar ese equipaje atrás, es decir, evitar algunos tipos de escrutinio. para eliminar por completo.) Creo que necesitamos muchas discusiones sobre cómo rectificar las muchas contradicciones dentro de SOCK y él mismo, y SOCK y CLEANSTART, y eliminar PROJSOCK es una de las cosas que me gustaría que sucediera. - Bilorv ( conversación ) 20:42, 16 de abril de 2021 (UTC)

  Bilorv , más abajo en la página, en WP: SOCKLEGIT : Comienzo limpio con un nombre nuevo: Un comienzo limpio es cuando un usuario deja de usar una cuenta anterior para comenzar de nuevo con una nueva, generalmente debido a errores pasados ​​o para evitar el acoso. Se permite un comienzo limpio solo si no hay prohibiciones, bloqueos o sanciones activas contra la cuenta anterior. (algunos detalles adicionales siguen a esa cita, pero esa es la esencia). También, Si no puede acceder a su cuenta porque ha perdido la contraseña o porque alguien ha obtenido o adivinado su contraseña, puede crear una nueva cuenta con una contraseña limpia . Los SPI se rechazan de forma rutinaria porque las cuentas informadas operan de forma secuencial. Admito que ambos dicen que se supone que debe marcar la cuenta anterior como retirada o (para los casos de contraseña perdida) declarar públicamente la conexión entre las cuentas. Sin embargo, con los escenarios de contraseña perdida, es probable que el editor en cuestión no haya leído las reglas de sockpuppetry cuando se bloquearon y crearon una nueva cuenta, por lo que se aplica de manera bastante flexible. GeneralNotability ( charla ) 21:11, 16 de abril de 2021 (UTC)

  @ GeneralNotability : Estoy luchando por ver cuál de este texto respalda la afirmación crear una nueva cuenta, siempre y cuando la anterior no haya estado bajo algún tipo de sanción o bloqueo, no es ni ha sido nunca un títere de calcetines , o cuál de ellos refuta alguna de las declaraciones que hice. - Bilorv ( conversación ) 21:23, 16 de abril de 2021 (UTC)

  Bilorv , disculpas, en realidad es el contexto de esas oraciones (el hecho de que estén bajo WP: SOCKLEGIT , que es la sección "Usos legítimos") lo que respalda la afirmación. El título de esa sección, en parte, dice Las cuentas alternativas tienen usos legítimos. Por ejemplo, los editores que contribuyen con su nombre real pueden desear utilizar un seudónimo para las contribuciones con las que no quieren que se asocie su nombre real (...) Estas cuentas no se consideran sockpuppets. y luego pasa a enumerar ejemplos de cuentas alternativas legítimas, dos de las cuales cité en mi publicación anterior. Sin embargo, sí objeto la terminología de "relatos alternativos", ya que eso (para mí) implica el uso de más de un relato al mismo tiempo. GeneralNotability ( conversación ) 21:35, 16 de abril de 2021 (UTC)

  @ GeneralNotability : gracias, creo que entiendo mejor de dónde viene ahora, aunque no puedo estar de acuerdo en que la política tal como está escrita respalde su afirmación. Por otro lado, creo que estoy de acuerdo en que debe escribirse de una manera que haga que la afirmación sea inequívocamente cierta. Hay muchos problemas aquí: "Usos inapropiados de cuentas alternativas" incluye cosas que tal vez no se ajusten a la letra de esta definición de "sockpuppet", pero está etiquetado WP: BADSOCK y todo el mundo lo usa como una lista de comportamiento de sockpuppet. Esta definición de "Estas cuentas no se consideran sockpuppets" sigue a la sección, en lugar de precederla, y aún deja mucha especificación terminológica que desear. Este es el tipo de cosas a las que me refiero acerca de que SOCK se contradice a sí mismo. Supongo que el problema básico aquí es que he estado aquí 7 años y he leído la página decenas de veces y no siento que entiendo claramente dónde están los límites. están. En general, no me gusta la jerga legal y la burocracia, pero sí creo que le estamos haciendo un flaco favor a cualquiera que navegue por cuentas alternativas (o IP y edición con sesión iniciada) de buena fe porque necesitan poder decir: aquí está una justificación férrea para mis acciones y si alguna vez tengo que defenderlas, aquí hay una política inequívoca tal como estaba escrita en el momento en que tomé estas decisiones. O necesitan saber: en realidad, no puedo hacer esto, y aquí está la razón inequívoca del por qué. - Bilorv ( conversación ) 21:56, 16 de abril de 2021 (UTC)

  Cuanto más avanza esta discusión y cuanto más miro todas las políticas, más veo el desastre que son. Wikipedia: A Sockpuppetry le vendría bien una reescritura completa de arriba a abajo para aumentar la claridad, eliminar las contradicciones y presentar todo en un orden lógico. Por ejemplo, varias de las viñetas con usos inapropiados son ejemplos diferentes de aparecer como varias personas, solo debería haber una única prohibición para hacer eso con una lista no exhaustiva de ejemplos. Thryduulf ( conversación ) 21:44, 16 de abril de 2021 (UTC)

  Absolutamente, esto es parte del punto que estoy tratando de hacer (aunque creo que lo estoy confundiendo en parte porque ni siquiera entiendo cuáles son y cuáles no son las reglas, así que lucho por sugerir concretamente qué nueva versión cambiar a). - Bilorv ( conversación ) 21:56, 16 de abril de 2021 (UTC)

  @ GeneralNotability : Pregunta: Digamos que tienes a un chico de 14 años haciendo tonterías y se emborracha. Cuatro años después, deciden darle otra oportunidad a Wikipedia. Obviamente, no es ideal continuar con una cuenta en la que se agregan obscenidades a artículos o algo así. Entonces ... ¿se espera que obtengan un desbloqueo en su cuenta principal, y luego la marquen como retirada y luego creen una nueva? Si han perdido la contraseña original, se espera que la restablezcan. Si han perdido el correo electrónico, ¿entonces ...? ProcrastinationReader ( charla ) 09:24, 17 de abril de 2021 (UTC)

  Solo para aclarar un poco el punto: me opongo firmemente a los tres remedios propuestos y siento que son un paso atrás del ya inadecuado status quo, aunque (1) es el menos objetable. - Bilorv ( conversación ) 20:42, 16 de abril de 2021 (UTC)

• 1 o 3 son mis soluciones preferidas. - In actu (Guerillero) ^{Parlez Moi} 13:47, 16 de abril de 2021 (UTC)
• Desecho WP: PROJSOCK . No puedo pensar en ningún comportamiento que queramos rechazar que no esté ya cubierto por uno de los otros puntos en WP: ILLEGIT . - RoySmith (charla) 14:39, 16 de abril de 2021 (UTC)
• Elimine PROJSOCK según los demás. De lo contrario, oponga las tres opciones. Levivich  ^acoso / _sabueso 15:44, 16 de abril de 2021 (UTC)
• Mantenga PROJSOCK, pero puede aclarar; Se prefieren 1 y 3 Estoy de acuerdo en gran medida con Guerillero en esto (también ping de cortesía a Risker para un poco de historia sobre el tema). Estoy de acuerdo con la aclaración sobre PROJSOCK de que las personas pueden usarlo válidamente para comentar discusiones directamente relevantes para ellos, pero que no es motivo para tirar al bebé con el agua de la bañera.
  Hay varias razones detrás de PROJSOCK, pero una de las principales es que proporciona una línea clara para las personas en lugar de evitar la línea de escrutinio de forma bastante ambigua , que está abierta a la interpretación. Como ejemplo de dónde serían estos problemas:

1. Personas que comentan sobre casos de EA o ANI relacionados con personas con las que tienen una relación negativa conocida. Esto evita que el vendedor pondera los argumentos (los rencores son justos de considerar) y tiene el efecto de prevenir potencialmente sanciones en una cuenta principal (es decir, IBAN). Incluso si solo una cuenta comenta, esto es un problema.
2. Posibles preocupaciones de acoso que siguen a los usuarios en el espacio del proyecto que no les gustan de las disputas en otros lugares. Incluso si no hay doble voto, este sigue siendo un uso ilegítimo de múltiples cuentas. Sin embargo, es mucho más difícil de abordar si no hay una prohibición clara.
3. Ocultar comportamientos en discusiones internas que podrían no ser sancionables pero que tendrían un impacto negativo en la posición de alguien dentro de la comunidad, si eres un archinclusionista o archdelecionista con posiciones fuera de la norma de la comunidad y usas un "alt de privacidad" para comentar AfDs esto es un abuso de múltiples cuentas. Si solicita permisos en NPR y está claro que no comprende la política de notoriedad que está en línea con la de la comunidad, se le denegará. Si se postula para RfA y tiene posiciones sobre cualquier número de temas que muestran una clara desconexión con el consenso de la comunidad, no aprobará RfA. Todas estas son formas de evasión del escrutinio que erosionan la confianza de la comunidad y son abusos de múltiples cuentas, pero sin PROJSOCK sería mucho más difícil de manejar.

Somos una comunidad en línea y parte de eso se trata de confianza. Si no sabe que la persona con la que está hablando no está comentando de una manera completamente absurda y abusiva 10 minutos después, o al menos tiene garantías razonables de que no lo está, la confianza se irá cuesta abajo. Muchos otros proyectos de Wikimedia no permiten cuentas secundarias en absoluto . Actualizar nuestra política para permitir que las personas tengan esencialmente tantas personalidades como quieran en el espacio del proyecto y tener formas de salir de Wikilawyer, ya que la política no estaría clara es un claro negativo, y nos colocaría con Commons para ser uno de los proyectos más abiertos al abuso. TonyBallioni ( charla ) 01:32, 17 de abril de 2021 (UTC)

Hmm ... En el n. ° 2, seguramente acosar es acosar en cualquier lugar (¿por qué es mejor seguir a un editor en las charlas de artículos o en las páginas de charlas de plantillas?). En el # 3, seguramente no deberíamos hacer una política que afecte a muchos editores por el bien de la docena por año que quieren ejecutar RfA (¿a quién se le puede pedir que divulgue individualmente?). Además, nota general, ¿no 1/3 no es mutuamente excluyente con 2? Parece que Beeble ha señalado múltiples problemas, e incluso si PROJSOCK se ajusta (en cualquier dirección), los 'problemas' sobre las CU que no conocen las cuentas alt declaradas, o la inviabilidad de controlar las ediciones (ya sea en WP: o en cualquier otro espacio de nombres) permanecen. ProcrastinationReader ( charla ) 10:15, 17 de abril de 2021 (UTC)

TonyBallioni , El problema es que esto está combinando "discusiones internas que afectan la política del proyecto" con "espacio de nombres de Wikipedia". Dado que permitimos calcetines de privacidad, seguramente no está argumentando que WP: Teahouse debería estar fuera de los límites. ¿Está bien pedir ayuda en Help talk: Footnotes , pero no en Wikipedia talk: Citando fuentes ?

Si arrastran un calcetín de privacidad a WP: AN , ¿pueden defenderse allí? O si uno de sus artículos está nominado en WP: AfD , ¿pueden participar en esa discusión? ¿Estaría bien protestar contra un WP: PROD , porque eso sucede en el artículo Talk space, pero una vez que lo has hecho y alguien da el siguiente paso y lo lleva a AfD, estás atascado?

¿Y qué hay de WP: DYK , WP: GA , WP: FA ? ¿Son esos calcetines de juego limpio para la privacidad? Las revisiones de DYK se llevan a cabo principalmente en el espacio de plantillas, GA en el espacio de discusión del artículo y FA en el espacio de Wikipedia. ¿Significa eso que DYK y GA están bien, pero FA no?

¿Qué hay de participar en wikiprojects? Están en el espacio de Wikipedia. ¿Se le prohibiría a nuestro desafortunado empleado de la NASA de mi ejemplo anterior participar en WP: Wikiproject Flat Earth ? Tal vez eso esté fuera de los límites, pero Portal: Flat Earth está bien?

¿Qué pasa con los borradores? ¿Pueden revisar los envíos en el espacio Borrador, pero no agregar su nombre a Wikipedia: Artículos de WikiProject para creación / Participantes ?

Su objetivo es asegurarse de que los calcetines de privacidad no hablen con múltiples voces en las discusiones que impulsan la política del proyecto. Ese es un objetivo loable, pero prohibir el subconjunto de páginas que caen en el espacio de nombres de Wikipedia no promueve ese objetivo. Para cuando haya terminado de crear todas estas exenciones, la línea brillante que busca se habrá vuelto bastante borrosa. - RoySmith (charla) 12:47, 17 de abril de 2021 (UTC)

Su objetivo es asegurarse de que los calcetines de privacidad no hablen con múltiples voces en las discusiones que impulsan la política del proyecto. No. Ese no es mi objetivo, y toda mi respuesta anterior fue diciendo que no importa si las personas solo contribuyen una vez a cada discusión si lo hacen de una manera diseñada para evitar el escrutinio y engañar a la comunidad. Mi objetivo es evitar la evasión del escrutinio por parte de las personas que utilizan varias cuentas, porque la evasión del escrutinio destruye la confianza en un proyecto colaborativo, que es uno de los principios impulsores de nuestra política sobre el abuso de varias cuentas.

La razón por la que el espacio de Wikipedia en particular es importante es porque la única razón para usar una segunda cuenta en el espacio de nombres de Wikipedia fuera de las discusiones limitadas sobre el contenido (RSN, AfD y FA principalmente) es evitar el escrutinio. Es para separar personalidades y no hacer que asocie acciones de una con la otra. A menos que esté tratando con materiales sexualmente desviados u otros temas controvertidos similares, realmente no hay una razón válida para querer tener privacidad en las discusiones del espacio de su proyecto más que la evasión del escrutinio.

Lo que nos lleva al punto final: las líneas claras dirigidas con sentido común son más fáciles de hacer cumplir que las políticas ambiguas. Actualmente, no se está bloqueando a nadie por comentar en la Casa de té o en DYK o similares con una segunda cuenta. Los empleados de UC y SPI tienen cerebro y pueden determinar la intención. Si elimina una prohibición clara, eso se vuelve mucho más difícil de entender y las apelaciones se vuelven más difíciles. La ambigüedad sobre lo que constituye "Evitación del escrutinio" no es útil, y al mantener una línea que lo defina claramente para todos, ayuda a las personas a saber qué está y qué no está permitido y ayuda con la aplicación. Estamos tratando con hipótesis sobre los aspectos negativos, hay algunos bloqueos de mano dura, pero son bastante raros para esta violación. Sin embargo, los aspectos positivos de esta línea en lo que respecta a la aplicación de la ley son bastante importantes. TonyBallioni ( charla ) 17:18, 17 de abril de 2021 (UTC)

"manteniendo una línea que lo defina claramente para todos" Excepto que la línea única actual no lo define claramente para todos (de lo contrario, no estaríamos teniendo esta discusión). Además de RSN , FA , AfD , están las bombas de la aldea ( posiblemente esta excluida), la mesa de ayuda, las páginas de WikiProject, XfD (especialmente las relacionadas con las páginas en las que han contribuido con la cuenta alt), RFU , RFHM , ITNC , TALKPP y proyectos similares, AN (I) cuando se discute su comportamiento o es víctima de la mala conducta de otros, CCI , EFR , EFFP , EAR , Espacio de arbitraje para casos relevantes a las páginas que editan con el alt, RFA / RFB para alguien con quien han interactuado en temas que editan usando su alt, y probablemente muchos más de los que no he oído hablar. Sin embargo, la redacción actual no hace nada para evitar que alguien desarrolle múltiples personalidades de cuenta en discusiones que ocurren en lugares distintos a los espacios de nombres de Wikipedia y Wikipedia. Al decir "los empleados de UC y SPI tienen cerebro y son capaces de determinar la intención". parece que estás de acuerdo conmigo en que lo que importa es la intención de la persona, así que seguramente las reglas deberían estar escritas para indicar que lo que importa es la intención, no el lugar. "Los aspectos positivos de esta línea en lo que respecta a la aplicación, sin embargo, son bastante grandes". No he visto ni una sola buena aplicación de esta regla que no estuviera cubierta por otras disposiciones existentes, así que no estoy de acuerdo con usted en que "los aspectos positivos de esta línea en lo que respecta a la aplicación, sin embargo, son bastante enormes". Thryduulf ( conversación ) 18:19, 17 de abril de 2021 (UTC)

Las líneas claras dirigidas con sentido común son más fáciles de hacer cumplir que las políticas ambiguas . Más fácil para las CU . Pero para las personas que realmente usan estas cuentas, es mucho más difícil. Si usted será bloqueado y expulsado se basa en la buena voluntad de una UC o en su capricho de seguir el "sentido común" o la regla. No deberíamos establecer una regla más estricta que la forma en que queremos aplicarla; más bien, al contrario, porque la "edición disruptiva" no tiene ni necesita una definición rigurosa, ya que la comunidad siempre puede decidir gobernar algo como disruptivo en un caso por caso. - Bilorv ( conversación ) 18:01, 27 de abril de 2021 (UTC)

• Mantenga PROJSOCK, opción inclinada 1  - esencialmente por Tony. La abolición de PROJSOCK requeriría que lo reemplazáramos con una enorme pared de texto que explique qué constituye exactamente la evasión del escrutinio en el espacio del proyecto. Sí, existe un argumento razonable para dividir los historiales de contribución en el espacio de artículos en algunos casos. Pero el uso independiente de dos relatos para participar en los procesos comunitarios detrás de escena me imposibilita de manera inherente evaluar la conducta de alguien como editor en contexto, y eso es un veneno para el discurso comunitario. Si se necesitan exenciones y aclaraciones, está bien y podemos discutirlas, pero la desaprobación de PROJSOCK conduciría a una política inflada o un montón de golpes. En cuanto a mi opinión sobre la opción 1: el sistema actual de es subóptimo porque nos presenta consideraciones complicadas de OUTING; no me opongo a que las personas usen alts para editar temas controvertidos ( en el espacio de artículos ) per se, pero usarlos de una manera que sea que cumpla con las políticas y esté desconectado de su cuenta principal debe ser responsabilidad del operador. - Blablubbs | charla 09:39, 17 de abril de 2021 (UTC)

  @ Blablubbs y TonyBallioni : ¿Por qué Projectspace es especial? ¿Por qué evadir el escrutinio en una página en el espacio de nombres de Wikipedia es diferente a evadir el escrutinio en cualquier otro lugar? ¿Por qué, por ejemplo, Wikipedia: Mesa de ayuda es un "proceso comunitario entre bastidores" pero, por ejemplo, Help talk: Estilo de cita 1 no? ¿Por qué necesitaríamos un "enorme muro de texto que explique qué constituye exactamente la evasión del escrutinio"? Seguramente es mejor simplemente prohibir "evadir el escrutinio" y enumerar algunos ejemplos para que no tengamos que lidiar con wikilawyering. Thryduulf ( conversación ) 11:08, 17 de abril de 2021 (UTC)

  Thryduulf , la mesa de ayuda es uno de los lugares que yo consideraría digno de una carveout. Lo que es especial son lugares como AfD, AN (/ I), AE o RFAR. El problema de confiar solo en la cláusula de evasión del escrutinio es que conducirá a Wikilawyering de cualquier manera. Inevitablemente provoca situaciones en las que la gente dice "pero no fue uno de los ejemplos enumerados" y tenemos que tener discusiones de desbloqueo prolongadas e hilos AN sobre lo que es y no es una evasión del escrutinio. Yo diría que la mayoría de los escenarios en los que alguien usa una alternativa de privacidad en las discusiones de la comunidad son intrínsecamente evasión del escrutinio; es más factible una prohibición total del uso de PROJsocking con excepciones específicas y estrechas. Blablubbs | hablar 11:18, 17 de abril de 2021 (UTC)

  Incluso si decimos que se requiere algo como PROJSOCK, "discusiones de consenso y resolución de disputas" parece abarcar todos esos ejemplos y otros. La página de espacio de proyecto promedio simplemente no es problemática, desde las páginas de discusión de WikiProject hasta las solicitudes de bot / editfilter. Incluso el texto que cito es cuestionable, ya que preguntar si una fuente es confiable en RSN podría verse como una "discusión de consenso", pero simplemente no es problemático. ProcrastinationReader ( charla ) 11:25, 17 de abril de 2021 (UTC)

  Además, ¿qué pasa si se acosa a un alt de privacidad? No pueden publicar en ANI, entonces, ¿cuál es su recurso? ¿Deberían ponerse en contacto con un administrador de forma privada? (Si es así, ¿cómo les comunicas esto? ¿Usando el banner de ANI que la evidencia muestra que pocos realmente leen?) ProcrastinationsReader ( charla ) 11:34, 17 de abril de 2021 (UTC)

  @ Blablubbs : ¿Entonces un alt de privacidad no puede contribuir a una discusión en XfD sobre una página a la que contribuye significativamente? ¿Qué beneficio trae eso para el proyecto? Siempre que solo contribuyan con una de sus cuentas y no den la impresión de ser varias personas, no puedo ver cómo sus acciones son dañinas. En cuanto a "pero no fue uno de los ejemplos enumerados", es mucho más difícil trabajar en wikilawyer alrededor de una lista de ejemplos que explícitamente no es una lista completa de lo que es una lista que pretende ser completa. Thryduulf ( conversación ) 11:54, 17 de abril de 2021 (UTC)

  Responderé con dos citas del comentario de Tony con las que estoy totalmente de acuerdo. En cuanto a los tablones de anuncios y las discusiones de AfD:

  • Estoy bien con la aclaración sobre PROJSOCK de que la gente puede usarlo válidamente para comentar discusiones directamente relevantes para ellos, pero esa no es una razón para tirar al bebé con el agua de la bañera. Ya sea que queramos mantener la redacción como "espacio de proyectos" o ajustarla a "discusiones de consenso y resolución de disputas" es otro asunto.

  En cuanto al daño que ocasiona simplemente permitir la participación en tales discusiones:

  • ... si eres archinclusionista o archdelecionista con posiciones fuera de la norma de la comunidad y usas un "alt de privacidad" para comentar sobre AfD, esto es un abuso de múltiples cuentas.

  Si vemos una versión alternativa tan obvia que se utiliza para votar en las AfD ahora, la política actual nos da motivos para una investigación; una desaprobación de PROJSOCK complicaría gravemente eso, pero tal comportamiento es muy problemático y una grave violación de la confianza de la comunidad. Blablubbs | hablar 12:11, 17 de abril de 2021 (UTC)

  En primer lugar, ¿por qué es más problemático usar varias cuentas para expresar puntos de vista extremos que usar una sola cuenta para hacerlo si no se intenta manipular la discusión o aparecer como varias personas? En segundo lugar, ¿por qué el uso de varias cuentas para comunicar tales posiciones es problemático en el espacio de nombres de Wikipedia pero no en ningún otro espacio de nombres? En tercer lugar, si estamos de acuerdo en que el uso de una cuenta alternativa de una manera determinada es problemático, entonces seguramente la política debería prohibir explícitamente el uso de múltiples cuentas de esa manera en lugar de como parte de una prohibición muy amplia y muy vaga que requiere numerosas excepciones y excepciones para evitar atrapar cosas. no queremos prohibir y exigimos que las personas adivinen en qué comportamiento no queremos que se involucren. Thryduulf ( conversación ) 12:43, 17 de abril de 2021 (UTC)

  De todos modos, incluso si no hacemos nada más que eliminar "Las cuentas alternativas no reveladas no deben usarse en discusiones internas del proyecto". el comportamiento del que está hablando todavía estaría cubierto por "es una violación de esta política crear cuentas alternativas para confundir o engañar a los editores que puedan tener un interés legítimo en revisar sus contribuciones". Thryduulf ( conversación ) 12:47, 17 de abril de 2021 (UTC)

  Para responder a su pregunta de por qué es problemático que alguien use cuentas diferentes para segregar puntos de vista sobre asuntos internos: nuestro sistema se basa en la confianza de otros contribuyentes, y parte de esa confianza se basa en conocer su historial de vistas. Como ejemplo, sé que usted y yo estamos de acuerdo de manera significativa en la mayoría de las cosas relacionadas con la política de acoso y la salida, pero tenemos puntos de vista muy diferentes sobre la eliminación rápida. Si bien me involucraré con usted en el último tema, tampoco voy a dedicar una cantidad significativa de mi tiempo a tratar de persuadirlo de mi punto de vista porque en algún momento basado en discusiones pasadas, sé que estamos simplemente tendré que estar de acuerdo para estar en desacuerdo. Por otro lado, en las discusiones sobre el acoso y la privacidad, es mucho más probable que reconsidere mi posición y vea si consideré todo si te veo a ti oa alguien más que conozco que comparto pensamientos similares a discutir de una manera.

  Esto es lo que viene con ser una comunidad: tomas todas las acciones y posiciones de las personas, y estas afectan la forma en que lees lo que dicen e influyen en tus pensamientos. Eso no es malo, es la naturaleza humana y es una parte natural e importante de las comunidades, tanto en línea como de otra manera. La preocupación no es una cuenta que existe únicamente para segregar puntos de vista sobre las discusiones de políticas, son dos cuentas que nunca se superponen y son cuentas completamente desarrolladas con sus propias personalidades que contribuyen a las discusiones de la comunidad de una manera que si se descubre causaría una pérdida de confianza en el comunidad. Tener una política que prohíba claramente es algo bueno, ya que en mi experiencia es más fácil tratar con líneas claras con sentido común que con líneas ambiguas de manera similar. TonyBallioni ( charla ) 17:18, 17 de abril de 2021 (UTC)

• Las tres opciones originales me parecen razonables, según la propuesta. Sin embargo, eliminar WP: PROJSOCK de la política de sockpuppetry es una idea que surgió durante la discusión y que no me agrada. Imagínese a alguien que opera dos cuentas, una para espacio principal y otra para espacio de proyectos. Ambos están estrictamente separados: la cuenta del espacio principal nunca edita el espacio de nombres de Wikipedia, la cuenta del espacio de proyectos nunca edita los artículos. El resultado es una cuenta que no viola ninguna política y al mismo tiempo socava nuestra confianza en las discusiones de la comunidad. Uno de los aspectos principales de las discusiones internas de Wikipedia es que las llevan a cabo usuarios que también contribuyen a la enciclopedia de formas que se pueden buscar fácilmente. Permitir que los títeres de solo proyectos participen en voz alta en las discusiones internas sin haber hecho nunca contribuciones visibles a la enciclopedia sería un error: las políticas que afectan a todos los artículos se crean en discusiones internas, por lo que de repente estaríamos abiertos a cambios de política por parte de personas que han no tengo idea de lo que los cambios propuestos significan para los editores. La política debe ser redactada y el consenso debe estar a cargo de personas que contribuyan de manera verificable a la enciclopedia. Los calcetines de proyecto evitan esta verificación. ~ ToBeFree ( hablar ) 10:59, 17 de abril de 2021 (UTC)

  Una cuenta que edita solo en el espacio de proyectos es una situación muy, muy poco común y PROJOCK prohíbe mucho, mucho más que eso y en realidad no evita que una cuenta que no contribuye a la enciclopedia contribuya (en voz alta o de otra manera) en las discusiones internas. en, por ejemplo, páginas de plantilla (charlas), páginas de ayuda (charlas), páginas de charlas de artículos, páginas de categorías (charlas), etc. También diría que una cuenta que ha contribuido al desarrollo de herramientas de back-end y similares ha sido verificable contribuido a la enciclopedia. Thryduulf ( conversación ) 11:14, 17 de abril de 2021 (UTC)

• "La razón por la que el espacio de Wikipedia en particular es importante es porque la única razón para usar una segunda cuenta en el espacio de nombres de Wikipedia fuera de las discusiones limitadas sobre el contenido (RSN, AfD y FA principalmente) es evitar el escrutinio". No estoy de acuerdo con esto. Crearía una segunda cuenta bajo mi identidad real si pudiera, y usaría mi cuenta de nombre real para la edición no controvertida y todas las discusiones espaciales del proyecto no controvertidas, mientras uso mi cuenta anónima de Levivich para editar temas controvertidos (como la guerra, la política y la religión) y discusiones relacionadas con el espacio del proyecto. Si lo hiciera, no eludiría el escrutinio, lo aumentaría. En este momento podría tener una alternativa de privacidad que edite, digamos, temas sexuales (¿Usuario: Sexivich?), Y puedo usar esta cuenta de Levivich para editar RFC del espacio del proyecto sobre temas sexuales y nadie sabría que las ediciones de Sexivich en esas áreas son mías. Eso evita el escrutinio. Si, en cambio, pudiera usar la cuenta de Sexivich para discusiones espaciales de proyectos relacionados con el sexo, sería más transparente, no menos. Si vamos a permitir alts de privacidad (y lo hacemos, como deberíamos), deberíamos permitir que esos alts editen todos los espacios de nombres. Levivich  ^acoso / _sabueso 18:45, 17 de abril de 2021 (UTC)
• Muy de acuerdo con el primer remedio. Debemos desalentar los alts de privacidad no porque sean ilegítimos, sino porque no funcionan muy bien. Al igual que Beeblebrox, mi experiencia con esto en ArbCom fue un grupo de casos de personas que configuraron una alternativa de privacidad por buenas razones, que accidentalmente se salieron a la luz y / o bloquearon la CU porque no entendieron nuestra política bizantina de calcetines y luego nos pidieron que elimináramos campana. Probablemente haya un sesgo en el sentido de que solo escuchamos sobre los casos que salieron mal pero, con esta y otras políticas (supervisión, desaparición, inicio limpio), debemos ser más directos con el hecho de que la única forma confiable de mantener su La privacidad en Wikipedia es nunca revelar información privada en primer lugar.

Siempre pensé que PROJSOCK era una regla arbitraria, pero no conozco la historia detrás de ella, así que estoy indeciso al respecto. -  Joe   ( charla ) 19:05, 17 de abril de 2021 (UTC)

• Elimine PROJSOCK, segunda opción del remedio n. ° 2 Projectsock es realmente una guía obsoleta y demasiado amplia que debería eliminarse, pero si eso no tiene consenso, apoyaría aclararlo para que su alcance sea más estrecho. Jackattack1597 ( charla ) 00:59, 18 de abril de 2021 (UTC)
• Desaliente enérgicamente las cuentas de edición paralela no declaradas públicamente
  y simplifique las reglas para casos simples antes de atascarse en las complicadas reglas de LEGITSOCK.

WP: SOCK es confuso para un simple wikipedista novato obtener respuestas simples. Hay algunas cosas muy complicadas que se entremezclan con cosas simples, y creo que las cosas simples deben indicarse claramente y por adelantado, y con las cosas complicadas a continuación, bajo advertencias.

Lo simple es:

WP: SOCKING NO ES:

• El uso de varias cuentas que se declaran públicamente (declaradas en la página principal del usuario y todas esas cuentas conectadas). Ejemplos de esto incluyen computadoras seguras y no seguras. Segregación de ediciones de diferentes tipos. Mantenimiento de múltiples listas de seguimiento. Las plantillas para esto incluyen {{ Nombre de cuenta alternativo de usuario }}, y creo que pertenecen a la parte superior de la página principal de usuario.
• Cuentas sin editar. p.ej. Cuentas de lector; cuentas abandonadas hace mucho tiempo; cuentas de prevención de doppelganger.
• Edición cerrada para corregir errores en el espacio principal.

Las cosas se complican cuando se habla de varias cuentas de edición que no se declaran públicamente. Principalmente, la razón de esto parece ser la "privacidad". Hay buenas razones para no divulgar públicamente dos cuentas de edición. Es posible que tenga una buena razón para editar públicamente, frente a la familia, el trabajo o con fines educativos, y no desee revelar su cuenta principal anónima. Sin embargo, la sección que permite esto debe indicar de manera clara y contundente que NO SE RECOMIENDA hacerlo y, si se hace, hacerlo solo brevemente y con fines muy estrictamente definidos. Un pequeño error y la conexión puede ser detectada y luego puede ser pública para siempre. Se debe disuadir activamente a los recién llegados a Wikipedia de ejecutar cuentas de edición no declaradas en paralelo. Este material complicado debe escribirse y está escrito, pero debe separarse de lo simple en aras de la comprensión simple de una lectura simple de la política para preguntas simples.

Las reglas para las cuentas de edición paralela no declaradas públicamente deben ser claras y estrictas. Actualmente existe una regla que los tiene, solo la cuenta principal puede editar el espacio del proyecto. Esto es muy importante para la rendición de cuentas. Creo que se necesitan algunas palabras para aclarar qué es una "cuenta principal".

¿Debería permitirse que una cuenta no declarada participe en los debates de AfD sobre su propio contenido? Tuvimos discusiones sobre esto en WT: SOCK en marzo de 2010, y al final encontré al Usuario: SlimVirgin , 10:03, 19 de marzo de 2010 específicamente , convencido de que los legitsocks no deberían permitirse en AfD o en la resolución de disputas. También creo que es una extensión simple y necesaria de esto que los PI no deben poder contribuir a AfD, o proyectar discusiones espaciales en general.

- SmokeyJoe ( charla ) 08:36, 18 de abril de 2021 (UTC)

Usuario que responde : Preguntas de RoySmith de las 12:47, 17 de abril de 2021 (UTC). Para LEGITSOCKS, que no son la cuenta principal, estas deben ser cuentas de propósito específico, preferiblemente a corto plazo. WP: Teahouse debería estar fuera de los límites. Pidiendo ayuda en la charla de ayuda: notas al pie tal vez, pero no en la charla de Wikipedia: ¿Citando fuentes? No, se necesitan reglas estrictas y simples para esta práctica peligrosa. La cuenta principal puede hacer preguntas sobre la citación de fuentes. No veo por qué el LEGITSOCK no principal debería preguntar en Help talk: Footnotes.
Si se arrastra un calcetín de privacidad a WP: AN, no pueden defenderse. Si se arrastra un calcetín de privacidad a WP: AN, y el hilo está entretenido, algo anda mal y la persona no está calificada para ejecutar un calcetín de privacidad. Una cuenta que trata de estar callada y hacer algo específico debe ser callada y educada.
Si uno de sus artículos es nominado en WP: AfD, ¿pueden participar en esa discusión? No. Se debe confiar en la comunidad para que lleve a cabo una AfD justa.
¿Estaría bien protestar contra un WP: PROD, porque eso sucede en el artículo Talk space, OK. Pero una vez que ha hecho eso y alguien da el siguiente paso y lo lleva a AfD, ¿está atascado? Así es. Confíe en la comunidad de AfD.
¿Y qué hay de WP: DYK, WP: GA, WP: FA? Se trata de una edición de alto nivel, competitiva y algo asociada al drama. La reputación y la responsabilidad son importantes aquí. No es lugar para una marioneta.
No a WikiProjects. No a la revisión de AfC. No a los portales.
Básicamente, LEGITSOCKS debería ceñirse al espacio principal y responder las preguntas dirigidas a ellos en el espacio de conversación y user_talk. - SmokeyJoe ( charla ) 11:21, 18 de abril de 2021 (UTC)

• Apoyo firmemente el derecho a tener alternativas de privacidad. En consecuencia, se les debe permitir contribuir en el espacio de nombres del proyecto, en la medida en que sea práctico escribir una política que lo permita, sujeto a preocupaciones como las planteadas por TonyBallioni. Sin duda, se les debería permitir defender sus artículos contra la eliminación y otras actividades directamente relevantes. Benjamin ( charla ) 08:45, 18 de abril de 2021 (UTC)
• Elimine PROJSOCK y rechace las divulgaciones : PROJSOCK malinterpreta el caso de Arbcom que llevó a su adición a la póliza. El problema no era que el usuario estuviera usando cuentas alternativas no reveladas en el espacio del proyecto (en sí mismo), sino que las estaba usando de formas que ya estaban prohibidas por WP: SOCK (aparentemente WP: GHBH y WP: STRAWSOCK ). No le corresponde a Arbcom inventar políticas y no deberían haberlo hecho aquí. Si alguien usa diferentes cuentas para contribuir a diferentes discusiones (no las mismas discusiones) de manera legítima, ¿qué importa? PROJSOCK es una política "atrapada" que castiga a los usuarios sin ningún beneficio para el proyecto; simplemente deberíamos quitar la bala. En cuanto a las divulgaciones, probablemente deberíamos detenernos: es irresponsable y probablemente poco ético sugerir que divulgar una alternativa privada a Arbcom de alguna manera imparte una garantía de privacidad, lo cual no es en absoluto el caso. También está claro que los editores de todos los días no entienden que cada sitio de WMF es un proyecto separado con gobernanza separada, que nuestra coordinación entre proyectos es deliberadamente muy limitada y que lo que podría estar permitido aquí podría no estar permitido en otros proyectos de WMF. Lo que deberíamos hacer es más fuertemente editores aconsejan que consideran una alt privacidad de los peligros: si hacen uso de su alt en formas prohibidas luego nos vamos a conectar públicamente su principal al igual que hacemos para todas las cuentas sockpuppet, y aunque no recomendamos outing , Wikipedia es en el mundo real y realmente no tenemos control sobre otros editores que intentan "desenmascarar" una cuenta de privacidad, aunque yo digo que deberíamos hacer más para desalentar a los editores que hacen un hábito de la caza de brujas maliciosa. Si un usuario va a tratar de utilizar un alt privacidad, que necesitan para comprender los riesgos, y que ellos son responsables de mantener su privacidad, no Wikipedia . Sin embargo, estoy muy en contra de la creación de una política que prohíba los alts privados. Ivanvector ( ^Talk / _ediciones ) 13:30, 18 de Abril 2021 (UTC)
• Pregunta: He estado editando desde 2006, pero por lo general creo una nueva cuenta cada pocos meses porque no creo que el escrutinio sea justo. Es decir, si a alguien no le gusta lo que escribo sobre temas de sexualidad, no quiero que revise mi edición de temas ambientales para ensuciarme. ¿Mi comportamiento está fuera de las normas establecidas? Si me doy un WP: CLEANSTART cada tres meses y abandono todas mis cuentas anteriores, ¿está mal? 50.242.124.27 ( conversación ) 16:04, 18 de abril de 2021 (UTC)
  • Creo que esta bien. Soy más o menos lo opuesto a ti: solo he editado bajo una cuenta. Pero he pensado seriamente en hacerlo a tu manera (inicio limpio repetido), o simplemente decir lo mejor de tener una cuenta registrada y editar solo bajo una IP dinámica. La ironía de la edición de IP, especialmente de un gran rango dinámico como un proveedor de telefonía móvil, es que evita por completo todo el "escrutinio" del que otros hablan. Las IP dinámicas pueden editar (casi) todo y no hay forma de ver su historial de contribuciones (ya que los rangos se comparten). Y como el 90% + de la enciclopedia está escrita por IP de esta manera ... no hay escrutinio para la mayoría de los editores y, sin embargo, el sitio web no se desmorona. Es por eso que creo que hablar de escrutinio y comunidad está fuera de lugar: realmente la transparencia y el control que creemos que tenemos sobre las cuentas registradas es una broma: solo tenemos eso para aquellos que se molestan en registrar una cuenta y usarla, y usarla dentro de la política, que es una pequeña minoría de todos los editores. La transparencia y el escrutinio de este tipo son una ilusión. Levivich  ^acoso / _sabueso 17:44, 18 de abril de 2021 (UTC)
    • Nada de esto está dirigido a cuentas de inicio limpio. Tener dos cuentas a la vez es diferente a abandonar una cuenta y comenzar una nueva. Si la IP realmente ha estado haciendo eso durante tanto tiempo como dicen, lo están haciendo excepcionalmente bien y, por mi parte, no tengo ningún problema con eso. Beeblebrox ( charla ) 21:20, 18 de abril de 2021 (UTC)

      @ Beeblebrox : ¿No viola (estrictamente hablando) la letra de Wikipedia: Clean_start # Contentious_and_scrutinized_topics ? (Si es así, tal vez esa carta necesite una nueva redacción) ProcrastinationReader ( charla ) 21:48, 19 de abril de 2021 (UTC)

  • Este es exactamente el tipo de caso que SOCK / CLEANSTART necesita permitir. La privacidad es un asunto serio. No podemos simplemente hacer que nuestras reglas digan que no es una opción. Gracias por sus contribuciones y odiaría verlo obligado a cambiar su patrón de edición. - Bilorv ( conversación ) 18:01, 27 de abril de 2021 (UTC)
• Hay un punto interesante arriba. Postule esta situación:

  RoySmith decidió hacerlo al revés: Editar como identidad del mundo real Usuario: RoySmith , fácilmente identificado con la navegación como un nombre muy conocido en el mundo de la navegación, en temas relacionados con la navegación; y para ocultar la vergüenza de los compañeros de navegación de xyr de saber también sobre el K-Pop y las especies de escarabajos, editando todo lo demás excepto la navegación como Usuario: BigBubblyBoatingBob .

  Actualmente esto es tanto un proyecto: Sockpuppetry # usos legítimos e ilegítimos en virtud de las propuestas anteriores.

  ¿Es este el problema que hay que abordar? La gente menciona AFD, pero el tipo de marionetas que recibimos en gran medida en AFD son casi siempre del tipo que son ilegítimos de todos modos . Ciertamente, tampoco parece ser nada parecido al caso Privatemusings.

  Tío G ( conversación ) 22:48, 18 de abril de 2021 (UTC)

• Creo que la solución es alentar el títere de calcetines . Hay algunos usos comunes de sockpuppetry que son tan atroces que todo el concepto está prohibido: calcetín para evadir una prohibición / bloqueo / sanción (evasión de bloque), calcetín para crear la ilusión de consenso (acumulación de votos) y calcetín para evadir escrutinio ( WP: GHBH ). También existe la norma bien establecida de que ninguna persona puede tener más de una cuenta con permisos de administrador. Más allá de eso, creo que debemos reconsiderar por qué los calcetines son un problema. Usuario: 力(power ~ enwiki, π , ν ) 00:16, 20 de abril de 2021 (UTC)
• No apoyo ninguna opción, ya que creo que algunos editores pueden avergonzarse de que los usuarios sepan que editan en una categoría específica y si declaran que usaron un alt en esas categorías, podría aumentar aún más la vergüenza. Siento que, en cambio, debería haber una plantilla que diga "Esta es una alternativa de privacidad de un usuario que desea permanecer en el anonimato, que usa esta alternativa para editar en estas categorías:", de esa manera la alt todavía se declararía técnicamente, pero le ahorra al editor la vergüenza de tener que declarar específicamente que es el propietario del alt que edita en categorías en las que desearían no ser conocido como editor activo. Blaze The Wolf | Proud Furry y editor de Wikipedia ( charla ) 19:59, 20 de abril de 2021 (UTC)
• Solo para aclararme: no apoyo la eliminación de PROJSOCK por completo. Creo que hay que cambiarlo, pero creo que tiene un propósito. Las alternativas de privacidad están destinadas a ser utilizadas para editar contenido, si desea hablar sobre la política, debe usar su cuenta principal. Beeblebrox ( charla ) 20:04, 21 de abril de 2021 (UTC)
• Para tomar prestada la frase de Benjamin, apoyo firmemente el derecho a tener alternativas de privacidad . Para aquellas personas que dicen que necesitan juzgar la historia y el carácter de una persona para tener una comunidad de trabajo: un alt de privacidad es efectivamente una persona (o persona) separada. Sus contribuciones, discusiones y relaciones interpersonales pueden valerse por sí mismas. Tengo entendido que existe el temor de que pueda tener al Dr. Jekyll en alta estima mientras hay un Sr. Hyde acechando. ¿No sería raro que ocurriera? Mucho más común sería el caso de Rob, el experto en navegación, y Bob, que edita en otras áreas. Si ambas cuentas se comportan de manera respetuosa y constructiva, y no se unen para inducir a error, ambas deben tener voz en todas las partes del proyecto que se relacionan con sus respectivos intereses temáticos. Pelágicos (  mensajes  ) - (11:14 dom 25, AEDT) 00:14, 25 de abril de 2021 (UTC)
• Beeblebrox , es una tontería que no haya opción para "dejar las cosas como están". Después de todo, no tenemos la obligación de repetir como loros a otras wikis. No he leído toda la discusión (y no debería ser necesario para opinar aquí), pero una discusión para el cambio que no permite la opción de dejar el status quo es nula y sin valor, en mi humilde opinión, como puedes ' Evalúe la pregunta más básica "¿hay ganas de algún cambio?". No es propio de ti hacer una omisión tan flagrante como esa. Dennis Brown - 2 ¢ 18:03, 25 de abril de 2021 (UTC)

  No lo veo de esa manera. Propongo soluciones a los problemas percibidos. Si la comunidad siente que no hay problema o que estos no son los remedios que los resolverán, serán rechazados y se mantendrá el status quo. Pasa todo el tiempo. Beeblebrox ( charla ) 18:54, 25 de abril de 2021 (UTC)

• Yo apoyo el retirarse WP: PROJSOCK , que siempre he considerado como una política verdaderamente estúpida. No debería tener que iniciar sesión cada vez que quiera contribuir a una "discusión interna del proyecto", que, por cierto, podría entenderse como "cualquier discusión en cualquier lugar, no solo en el espacio del proyecto, que no No me ocupo exclusivamente del contenido del artículo, "y no hacerlo no debería ser una excusa válida para que un administrador remilgado me bloquee. Además, me opongo firmemente a la idea de restringir a todos a una sola cuenta; lo veo como un intento de colarse en una (casi) prohibición de la edición de IP. Iaritmioawp ( charla ) 14:52, 29 de abril de 2021 (UTC)
• Este sitio está discutiendo un problema frecuente en Reddit ; ¿Deberían permitirse las cuentas de quemador? Allí, la gente puede salirse con la suya con (casi) impunidad; pero, por lo que vale, esta es una cuenta nueva ya que mi cuenta anterior nunca tenía correo electrónico cuando la creé a fines de la década de 2000 aquí (alrededor de 2004-2005, IIRC). Yo diría que las personas hacen sockpuppets relacionados con la privacidad de necesidad, pero hay también las personas que vienen simplemente a los nombres de usuario de reclamación. Tal como están las cosas, incluso hubo una sugerencia aquí, allá por 2007, de que un vándalo ahora desaparecido (conocido por mover páginas, IIRC) que quería reformar debería reiniciar con una nueva cuenta y nunca revelar la antigua. Ésta es un área temática difícil. Pero permitir múltiples cuentas en plataformas siempre ha sido un tema delicado. Sin embargo, puedo ver ambos lados del argumento. Chelston-temp-1 ( conversación ) 13:20, 30 de abril de 2021 (UTC)
• Desecho WP: PROJSOCK. Hay muchas razones por las que un editor puede querer editar con su nombre real para sus ediciones principales, y una cuenta alternativa para los temas que no quieren que se asocien con su nombre real. Dice que apoyan a un candidato político impopular. Pero esa cuenta alternativa no puede participar en wikiprojects sobre ese tema o discutir cuestiones de política que afecten a ese tema. Eso es tonto. - GRuban ( conversación ) 17:51, 6 de mayo de 2021 (UTC)

Creo que la cláusula de política que se cuestiona aquí es una mala interpretación de ArbCom. La declaración proviene de Wikipedia: Solicitudes de arbitraje / Privatemusings # Sockpuppetry , que dice: Las cuentas de Sockpuppet no deben usarse en discusiones internas del proyecto, como debates de políticas. En primer lugar, esta cita no se refiere a discusiones sobre comportamiento ni a discusiones sobre eliminación. En segundo lugar, y lo que es más importante, la pregunta es si "sockpuppetry" significa usar múltiples cuentas en una sola discusión, o usar una cuenta no principal en cualquiera de las discusiones a las que se refiere esta declaración. Creo que deberíamos tomar el primer significado aquí, mientras que la declaración de política toma el segundo; si toma el segundo, debería aplicarse solo a las discusiones a las que se hace referencia en el primer número aquí. 147.161.8.37 ( conversación ) 12:57, 19 de mayo de 2021 (UTC)

La mejor manera de saberlo es preguntar a los árbitros que manejaron este caso, espero que algunos de ellos todavía estén presentes y recuerden este caso 14 años después. Los arbs son: Usuario: Kirill Lokshin , Usuario: UninvitedCompany , Usuario: FloNight , Usuario: Jpgordon , Usuario: Jdforrester , Usuario: Mackensen , Usuario: Morven y Usuario: Charles Matthews . 147.161.8.37 ( conversación ) 13:19, 19 de mayo de 2021 (UTC)

La edición anónima y los esfuerzos por mantener el anonimato se pensaba más ampliamente que eran cosas buenas en los primeros días del proyecto que en la actualidad. Los escenarios específicos que recuerdo que se discutieron durante esa época (posiblemente, pero no necesariamente, como parte de la decisión de Privatemusings) eran personas que se arriesgaban a represalias gubernamentales o institucionales por sus ediciones, sobre todo editores de China. Otro ejemplo serían los editores que divulgan detalles de sistemas criptográficos o DRM, que plantearon riesgos reales de enjuiciamiento en algunas jurisdicciones en el pasado. Otro más serían las contribuciones a áreas temáticas que revelarían opciones de estilo de vida (orientación sexual, uso de drogas recreativas) que podrían resultar en discriminación en el mundo real. Estas preocupaciones siguen siendo válidas hoy para los editores que contribuyen desde jurisdicciones particularmente conservadoras.

A medida que Wikipedia ha evolucionado, las restricciones muy onerosas sobre la edición anónima (especialmente en áreas temáticas difíciles) hacen que sea necesario tener una cuenta con nombre para hacer contribuciones significativas. En mi opinión, exigir a los usuarios que vinculen todas sus contribuciones utilizando la misma cuenta en todo momento silenciará las voces importantes que tienen un interés genuino y la capacidad de contribuir. También creo que el enfoque actual para lidiar con los calcetines es duro e insostenible, y que es mejor que evaluemos las ediciones en función de su mérito que de su fuente. Compañía no invitada 20:27, 21 de mayo de 2021 (UTC)

Mi estado de ánimo en ese momento era bastante específico: estaba realmente enojado con los calcetines de Privatemusando para "continuar y exacerbar el drama", como dije al rechazar una solicitud de desbloqueo de él, y probablemente solo lo estaba considerando a través de mi odio realmente intenso. de calcetines en general. Creo que ahora recomendaría eliminarlo; No necesitamos esta política general para lidiar con los calcetines perturbadores y / o deshonestos cuando son perturbadores y / o deshonestos. --jpgordon ^{𝄢𝄆 𝄐𝄇} 23:29, 4 de junio de 2021 (UTC)

• Eliminar WP: PROJSOCK . Dado que esta discusión aún no se ha cerrado, sumaré mi voz a aquellos que piensan que la solución más simple es deshacerse de PROJSOCK por completo. Pregunté anteriormente en esta conversación si había alguna interrupción causada por la edición de cuentas alternativas en el espacio del proyecto que no estaba también cubierta por una de las otras reglas, y que yo sepa, nadie ha ideado una. Pero lo que más me preocupa, como usuario de verificación y miembro del comité de arbitraje, es la cantidad de veces que las cuentas alternativas obvias se verifican únicamente porque editaron el espacio del proyecto, a pesar de que no hay ninguna interrupción o evidencia de abuso. No creo que tales cheques caigan dentro del espíritu de la política de CU , pero están justificados simplemente por esta redacción en la política de sockpuppetry. En el mejor de los casos, se trata de una lógica circular y ya es hora de que la arreglemos. - brad v 🍁 21:53, 27 de mayo de 2021 (UTC)
  • Usuario: Bradv , y muchos otros, ¿a qué te refieres con "Eliminar WP: PROJSOCK "? Parece que no ha leído el texto que enlaza. PROJSOCK dice que no debe utilizar cuentas alternativas para eludir la política. Creo que se podría referir a WP: SOCK # Legitimiate uses #Privacy ??? Observo que WP: SOCK es un desastre en términos de lógica estructural de presentación de información, y debatir por referencia a SHOUTYONEWORDSHORTCUTS no es útil. - SmokeyJoe ( charla ) 04:11, 30 de mayo de 2021 (UTC)

    SmokeyJoe , tienes razón, debo aclarar. Quiero decir que esta línea debería eliminarse: Discusiones internas : las cuentas alternativas no divulgadas no se deben utilizar en las discusiones internas del proyecto. Es redundante con el comportamiento problemáticoreal que sedescribe en las líneas siguientes. - brad v 🍁 04:29, 30 de mayo de 2021 (UTC)

    @ SmokeyJoe : Intenté resolver el problema creando un ancla para ese atajo; WP: PROJSOCK debería redirigir a esa oración específicamente. Sdrqaz ( conversación ) 11:57, 31 de mayo de 2021 (UTC)

    Usuario: Sdrqaz , creo que eso es contraproducente. Demasiados atajos no intuitivos no ayudan a comprender la política y los6 dificultan la mejora de la estructura y la presentación. Sería mejor citar el texto de forma explícita y no escribir eslóganes. - SmokeyJoe ( charla ) 12:14, 31 de mayo de 2021 (UTC)

    SmokeyJoe , estoy de acuerdo en que no deberíamos abusar de estos atajos (especialmente sin vincularlos cuando se mencionan por primera vez) porque crea barreras de entrada para los usuarios más nuevos, pero el problema inmediato en ese momento era que no estaba claro dónde WP: PROJSOCK refiriéndose. Ese era el problema (ciertamente superficial, a la luz de otras preocupaciones que ha planteado) que estaba tratando de resolver. Sdrqaz ( charla ) 12:25, 31 de mayo de 2021 (UTC)

• Creo que la política actual es suficientemente buena. Sin cambios significativos. Está bien tener una política diferente en inglés WP. Además, no hay que eliminar WP: PROJSOCK como un todo. Creo que las cuentas alternativas no divulgadas no deben usarse en discusiones internas del proyecto, solo deben aclararse. Supongo que significa editar en el espacio del proyecto, como los tablones de anuncios y AfD. Esto debe establecerse de manera más explícita. Mis mejores deseos ( charla ) 18:02, 8 de junio de 2021 (UTC)

Consolidar los lugares de ayuda

Movido a Wikipedia: Bomba de pueblo (propuestas) § Consolidación de lugares de ayuda

Relajar los requisitos para la herramienta de traducción de contenido

Soy editor en muchas otras Wikipedias y el Traductor de contenido no se limita a eso. Creo que hice una traducción al vietnamita de Babar y las aventuras de Badou con la herramienta. No necesito una cantidad determinada de ediciones para hacer eso allí. ¿Podemos hacer que 100 ediciones le permitan acceder a la herramienta? - Comentario anterior sin firmar agregado por Namethatisnotinuse ( charla • contribuciones ) 22:09, 5 de mayo de 2021 (UTC)

@ Namethatisnotinuse : si sigue las notas en Wikipedia_talk: Content_translation_tool # From_deWP podrá seguir adelante. - ^Charla xaosflux 15:49, 6 de mayo de 2021 (UTC)

• En lo que respecta a esta sugerencia de política, ya tenemos una solución alternativa como se señaló anteriormente, pero las discusiones anteriores no tuvieron consenso para publicitarlas realmente. Estoy a favor de agregar algunas instrucciones para guiar a los posibles traductores a su caja de arena o espacio de borrador. No estoy realmente a favor de cambiar el umbral, ya que el nivel de ECP parece haber logrado un buen equilibrio. - ^Charla xaosflux 15:49, 6 de mayo de 2021 (UTC)
  • Entonces, aparentemente, como CX ha tenido más desarrollo, los desarrolladores ya han insertado sugerencias sobre esto (por ejemplo, MediaWiki: Cx-tools-linter-can't-publish-message ), pero nuestra ayuda local no dice nada sobre esto, y no dice nada sobre cómo hacerlo. haciendo esto. Hace una mala experiencia de usuario de una forma u otra. ¿Alguna objeción a al menos actualizar la página de ayuda local con algunas instrucciones sobre esto? - xaosflux ^Talk 16:41, 17 de Mayo 2021 (UTC)

    Mi comprensión de la situación actual fue que permitimos que existiera esa puerta trasera porque si un traductor la encontraba y la utilizaba, probablemente también había encontrado, leído y comprendido la historia de la comunidad con la herramienta y, en particular, los problemas con las traducciones automáticas sin editar. . Encontrar esa puerta trasera también probablemente implicó una competencia razonable en el idioma inglés. No queríamos publicitarlo porque eso frustraría el propósito de asegurarnos de que las personas que usaban la puerta trasera conocieran el contexto en torno a la herramienta. Por defecto, me opondría a cualquier cambio en el status quo, pero si alguien revisara los datos y mostrara que el abuso del CXT es bajo, abrir más acceso a la herramienta es sensato. Tazerdadog ( charla ) 21:57, 27 de mayo de 2021 (UTC)

Editor experto imparcial

Quizás este sea el lugar equivocado para hacer esta pregunta. Sin embargo, en el Tablón de anuncios de resolución de disputas , hay una disputa en la que uno de los editores dice que necesita un editor experto imparcial para supervisar la reescritura de un grupo de artículos. Wikipedia no tiene designaciones de editores expertos o editores maestros. (Algunos editores nuevos pueden pensar que las diversas cintas de servicio en las páginas de los usuarios tienen más significado que ellos. Los editores que muestran las cintas de servicio saben que los premios son graciosos o divertidos, según el continente). No hay un grupo de editores expertos imparciales a los que se puede recurrir cuando se solicite. Mi pensamiento es que mejorar cualquier grupo de artículos es algo para lo que están los WikiProjects. ¿Hay algún consejo adicional que deba darle a un editor que dice que es necesario reescribir sustancialmente todo un grupo de artículos? Robert McClenon ( charla ) 04:23, 18 de mayo de 2021 (UTC)

• ¿No es aquí donde establecer los problemas en la página de discusión del artículo y luego solicitar comentarios utilizando el servicio de solicitud de comentarios puede proporcionar el beneficio de la opinión imparcial de editores experimentados que se han suscrito a ese servicio? Es posible que no aporten experiencia en el tema como tal, pero pueden asesorar sobre si realmente existe un problema y cuáles podrían ser los próximos pasos. AllyD ( charla ) 06:26, 18 de mayo de 2021 (UTC)
  • Usuario: AllyD - Sí, pero ... No creo que eso sea exactamente lo que quiere el editor en cuestión. El editor en cuestión quiere contratar a un editor experto imparcial para supervisar un largo proyecto de reescritura de un grupo de artículos. Según tengo entendido, el Servicio de solicitud de comentarios , se invoca a través del mecanismo de Solicitud de comentarios y, por lo tanto, se puede utilizar de dos maneras. La primera es hacer una pregunta específica y obtener un consenso vinculante, para lo cual se habrá invitado a otros editores a través de FRS. El segundo es hacer una pregunta abierta, que obtendrá comentarios (tal y como significa RFC). Creo que lo que se pide es algo más. Gracias por tus comentarios . Robert McClenon ( charla ) 17:01, 18 de mayo de 2021 (UTC)
    • @ Robert McClenon : Seguiría su corazonada inicial: WikiProjects. Si el WikiProject más relevante está inactivo, pruebe con su proyecto principal o algo relacionado. Los WikiProjects reciben muchas críticas, pero esto les parece una tarea perfecta. -  Finnusertop ( charla ⋅ contribuciones ) 00:33, 19 de mayo de 2021 (UTC)
      • Gracias. Creo que el editor que solicitó un editor experto imparcial tiene la idea de que hay rangos o grados de experiencia entre los editores de Wikipedia que pueden estar indicados por sus cintas de servicio en sus páginas de usuario. Sabemos que algunos editores muestran varios tipos de cintas de servicio en sus páginas de usuario. Siempre he tenido entendido que esas cintas de servicio son divertidas y no deben tomarse en serio. Creo que he visto al menos un caso de un editor que piensa que hay un grupo semioficial de tales editores a los que llamar. Robert McClenon ( charla ) 23:03, 30 de mayo de 2021 (UTC)

Necesita claridad sobre el papel de los cerradores de AfD

No es raro que los administradores que cierran las discusiones en WP: AfD ofrezcan su propia opinión sobre la notabilidad de un tema, es decir, si se cumple con WP: GNG y / o algún WP: SNG . Estos a menudo se llevarán a WP: DRV para su revisión. Hay un caso de este tipo en DRV ahora, y si bien ese caso fue lo que me llevó a comenzar este hilo, quiero centrarme en el problema más general, no solo en ese caso o en ese administrador.

Durante el tiempo que he estado involucrado en AfD (que es mucho tiempo), la regla ha sido que se supone que los cerradores destilan la discusión, no inyectan sus propias opiniones sobre la notabilidad. Desafortunadamente, no puedo encontrar ninguna declaración de política que salga directamente y diga eso. WP: CLOSE # La política se acerca y menciona excepciones específicas para WP: V , WP: OR , WP: CP y WP: NPOV , pero no dice explícitamente que esas son las únicas excepciones. En cualquier caso, es un WP: INFOPAGE , por lo que no se clasifica como política. Del mismo modo, WP: Supervote , aunque se cita ampliamente en las discusiones de DRV, es solo un ensayo.

Entonces, lo que estoy buscando es una declaración más oficial de que los cerradores de AfD deben confiar en la opinión de los comentaristas con respecto a la notabilidad. Si no hay una página de política real en la que tenga sentido agregar eso, entonces al menos un consenso cercano a este hilo y la actualización de WP: CLOSE # Policy para prohibir explícitamente a los cerradores aplicar sus propios juicios de notoriedad sería lo suficientemente bueno. - RoySmith (charla) 16:04, 24 de mayo de 2021 (UTC)

Gracias por sacar este tema. WP: DGFA podría ser un lugar para ponerlo también. Pero creo que el problema que está planteando es más amplio que las discusiones sobre la eliminación. Casi no tenemos políticas o pautas sobre las declaraciones de cierre y lo que es y no es apropiado incluir en ellas. Realmente no está escrito en WP: CONSENSUS , WP: CLOSE , WP: RFCEND , DGFA, WP: XFD , WP: DELPOL ... cómo escribir una declaración de cierre no parece estar en ninguna parte de nuestra sopa de letras. Me imagino que las reglas o al menos los principios para las declaraciones de cierre deberían ser las mismas para los XfD que para los RFC y otras discusiones. Deberíamos escribir algo, ya que ayudará a todo tipo de revisiones de cierre. Levivich   ^acoso / _sabueso 16:22, 24 de mayo de 2021 (UTC)

• Gracias RoySmith por plantear esto; Estoy de acuerdo en que el principio de no supervotación definitivamente goza del apoyo de la comunidad y debería estar codificado en alguna parte, junto con otra información sobre cierres según Levivich. La información sobre cierres que no son administradores también se puede mover allí. {{u | Sdkb }}  ^charla 16:52, 24 de mayo de 2021 (UTC)
• Creo que la mayoría de las prácticas en torno a los cierres son informales, divididas en varios consensos individuales ', y algunos buenos consejos en Wikipedia: Consejos sobre las discusiones de cierre . En general, se reconoce que no es tarea de los cerradores supervotar; muy pocos cierres lo son, y no creo que nadie haya hecho el argumento de WP: JUSTANESSAY cuando se cuestiona su supervoto, así que no veo por qué es necesaria una política (y no creo que sea una buena idea). Las decisiones las toma WP: CONSENSUS y supongo que el papel de los cerradores es simplemente alguien no involucrado que resume cuál fue el consenso en una discusión. Supongo que una nota en Wikipedia: ¿Se podría agregar consenso a este efecto? ProcrastinationReader ( charla ) 17:34, 24 de mayo de 2021 (UTC)
• Yo apoyaría esto. SportingFlyer T · C 17:52, 24 de mayo de 2021 (UTC)
• Mi sensación siempre ha sido que los argumentos presentados en las declaraciones finales nunca deben incluir (excepto quizás como información de fondo y solo si no afectan el cierre) ningún argumento que no haya sido presentado por los votantes participantes /! A menos que sean políticas primordiales, como cuando la gente quiere mantener un copyvio claro. Jo-Jo Eumerus ( charla ) 18:45, 24 de mayo de 2021 (UTC)
• Wikipedia: pautas de eliminación para administradores § Consenso general , que está vinculado desde Wikipedia: Discusiones finales § Consenso , analiza el examen de la fuerza del argumento y las políticas relevantes. Los argumentos que se hacen de mala fe, contradicen la política, se basan en opiniones personales sin fundamento o son ilógicos se dan como ejemplos de argumentos que pueden descartarse. No estoy seguro de que se requiera ninguna nueva guía oficial para determinar el consenso sobre este aspecto, pero quizás Wikipedia: los consejos sobre el cierre de las discusiones deberían publicitarse de manera más amplia a los posibles cerradores. La sección "Consideraciones adicionales" cubre, por ejemplo, no discutir argumentos que no fueron planteados en la discusión y no alcanzar un resultado que nadie discutió. isaacl ( charla ) 19:57, 24 de mayo de 2021 (UTC)
• No estoy seguro de que las respuestas hayan discutido de manera adecuada exactamente lo que propone RoySmith: últimamente ha habido un par de DRV en los que el vendedor parece estar de acuerdo con el lado que "gana" la discusión, especialmente cuando el más cercano mira las fuentes y hace su propia determinación de si algo es notable. No se trata de plantear argumentos que no se plantearon en las discusiones, se trata de si los cerradores deberían buscar fuentes para evaluar la notoriedad del artículo que están cerrando. SportingFlyer T · C 10:40, 25 de mayo de 2021 (UTC)
• Quizás sea necesario una mejor dirección sobre lo que debe buscar el vendedor, pero parece casi imposible que un vendedor cierre una disputa sobre afirmaciones basadas en las fuentes presentadas y si apoyan razonablemente a un lado o al otro, o ambos lados hasta cierto punto. , sin mirar las fuentes. (por ejemplo: '¡Fuente primaria!' '¡No, no lo es!' Mire la fuente, ¿quién hace la afirmación convincente o hay un desacuerdo razonable?). Alanscottwalker ( charla ) 11:29, 25 de mayo de 2021 (UTC)

  Sí, en tales casos uno a menudo terminaría con un "Ambas partes están presentando argumentos legítimos sobre si las fuentes satisfacen a WP: SIGCOV y ninguna de ellas es claramente más convincente que la otra, por lo que no hay consenso ". Jo-Jo Eumerus ( charla ) 13:40, 25 de mayo de 2021 (UTC)

• La declaración de cierre en una discusión de eliminación es en gran medida un enunciado performativo y hay expectativas de que no contaminemos el desempeño del cierre (que promulga consenso además de, con suerte, resumir la fuerza de los argumentos) con los argumentos que se supone que es. considerando. En la mayoría de los casos que he visto en los que la gente discrepa de que un más cercano exprese una opinión, se trataba de enmarcar más que de un supervoto real. Si alguien cambia "no cumple con GNG" por "consenso de que no cumple con GNG" o "los argumentos de que no cumple con GNG eran los más fuertes", eso lo cambia de un supervoto a un resumen. Mi preocupación por agregar un lenguaje más exacto y / o prescriptivo en las instrucciones para los cerradores es que ya es bastante difícil cerrar las discusiones en función de la fuerza del argumento frente a los números. La gente ya es acusada de supervotar solo por cerrar en contra de los números todo el tiempo. - ^{Hablar de las} rododendritas \\ 14:16, 25 de mayo de 2021 (UTC)

  Ese es un buen punto sobre no querer dificultar el cierre contra los números. {{u | Sdkb }}   ^charla 10:42, 29 de mayo de 2021 (UTC)

• Estoy de acuerdo en gran medida con lo que dijeron Jo-Jo, Alan y Rhododendrites. Los cerradores deben leer las fuentes para asegurarse de que las afirmaciones sean precisas, pero no deben ir más allá de lo que los participantes dijeron sobre las fuentes (a menos que se ignore alguna política importante como WP: BLP ). Las AfD son inusuales porque a menudo son un resultado binario --- eliminar o! Eliminar --- mientras que otras discusiones son mucho más abiertas. Debido a esto, resumir el debate y los puntos de vista principales puede parecer un supervoto, pero si el cierre se centra en cómo los participantes aplicaron las políticas en discusión (las cifras a veces pueden ser útiles aquí), creo que se pueden evitar la mayoría de los malentendidos. No cierro muchas AfD, pero así es como abordo los movimientos solicitados que tienen un resultado binario similar. - Wug · a · po · des​ 23:51, 29 de mayo de 2021 (UTC)

  Tengo que estar en desacuerdo sobre la lectura de las fuentes, esa es realmente la tarea de los participantes, no del cerrador. Además, las líneas se volverían borrosas entre cuál es la preferencia del cerrador y cuál es el consenso si los cerradores llegaran tan lejos. Jo-Jo Eumerus ( charla ) 14:47, 30 de mayo de 2021 (UTC)

• Como se señaló, ciertamente hay muchos casos en los que es más el cerrador simplemente no ha podido agregar "el consenso de las discusiones establece que" antes "no se cumple el GNG" (etc.). Claro, si plantean un argumento (que no sea copyvio, etc.) que no se menciona en absoluto, entonces eso es un poco problemático, pero nuevamente no he visto problemas en DRV en esos casos; por lo general, es bastante obvio si es muy cercano. En términos de "¿deberían verificar las fuentes para ver si el razonamiento sobre esos motivos está justificado?", Tengo que responder que no, que sería una forma diferente de supervoto. Si los votantes piensan que los argumentos de otros votantes de que sigcov et al son / no se cumplen son inválidos, ellos son responsables de disputar eso y tomar esa determinación, no los cerradores. Nosebagbear ( charla ) 13:10, 30 de mayo de 2021 (UTC)

  Entonces, si un AFD se inunda con calcetines que dicen que la fuente A dice XYZ, y de hecho no dice tal cosa, ¿un cerrador debería cerrar a favor de la afirmación demostrablemente falsa para evitar la supervotación? Esa es una conclusión absurda que no estoy de acuerdo con recomendar. Solo para ponerle algo de carne a esta hipótesis, digamos que 7 editores afirman que el artículo de The Example Daily cubre el tema Anex Ample y está escrito por un periodista independiente. Un solo editor dice "en realidad, la biografía del autor en la parte inferior dice que el autor es un empleado de Anex Ample y que le pagaron para escribir este artículo", y uno de los siete originales regresa para decir "no, no lo hace". . Bajo la teoría "no se ven en las fuentes", que debería cercano con los editores 7 incluso si la fuente lo hace decir que fue pagado por Anex Ample.

  Este no puede ser el resultado correcto, en parte porque incentiva la mentira. La ausencia de consenso suele ser una reserva predeterminada, por lo que si desea que se mantenga un artículo, simplemente mienta sobre las fuentes y refuerce la discusión; el más cercano no puede verificar y los participantes no tendrán tiempo suficiente para refutarlos todos (ver Gish galope ). Asegurarse de que los participantes se involucren en una disputa de buena fe y caracterizar con precisión el material externo es una diligencia debida básica; si no lo hace, es imposible cumplir con Wikipedia: Cerrar las discusiones # sin contar cabezas como un cerrador no sería capaz de averiguar qué afirmaciones son falsas y mucho menos descartarlas. Imagínese si los jueces en una sala del tribunal solo pudieran escuchar el testimonio pero nunca ver los documentos probatorios discutidos en ese testimonio porque podría comprometer su objetividad. Si ese es el miedo, entonces la solución no es la ignorancia forzada, sino prohibir que esa persona sea juez (el objetivo de las recusiones). Verificar afirmaciones y sacar sus propias conclusiones de una fuente son dos cosas muy diferentes, y si un vendedor no puede distinguir entre las dos, no debería cerrar discusiones. Si no puedo confiar en un cerrador para verificar objetivamente las afirmaciones hechas sobre material externo, ¿por qué debería confiar en ellos para evaluar objetivamente la discusión? No debemos confundir la ignorancia con la objetividad, y mucho menos recomendarla. - Wug · a · po · des​ 03:54, 31 de mayo de 2021 (UTC)

  De acuerdo con esto, en general. No creo que siempre sea necesario leer las fuentes, pero cuando la cuestión de qué argumento es realmente más fuerte se reduce a lo que realmente dicen las fuentes, el más cercano no debe abstenerse de mirar las fuentes por temor a ser etiquetado como un supervotante. - ^{Hablar de las} rododendritas \\ 05:17, 31 de mayo de 2021 (UTC)

Hay demasiada supervotación en los RfC y también con los WP: NAC , pero tal vez para otro momento. Xxanthippe ( charla ) 04:05, 31 de mayo de 2021 (UTC).

Heráldica de investigación original para universos ficticios

• 
• 
• 
• 
• 
• 
• 

¿Existe alguna política más específica para esto? Eliminé algunos: Special: Diff / 1026260344 y Special: Diff / 1026072768 . Estas imágenes son impresiones de artistas basadas en descripciones de texto. Me temo que puede haber muchos más por ahí. Según OTRS, la imagen de la derecha es una creación del Usuario: TTThom . Se usa en Heráldica de la Tierra Media , lo eliminaría, pero eliminar todo el quirófano dejará el artículo destruido y no estoy de humor para una guerra de edición. ¿Existe algún malentendido sobre WP: OR que haga que se agreguen sin que se reviertan en una década? - Alexis Jazz ( charla o de ping mí) 12:02, 1 de Junio 2021 (UTC)

Una cosa es inventar la heráldica para las casas de la realeza del mundo real basándose en el lenguaje, pero tendería a estar de acuerdo en que hacer esto por lo mismo para las de ficción es mucho menos apropiado. A diferencia de la heráldica real, que sigue un formato de lenguaje específico que permite recreaciones sin licencia sin participar en el quirófano, las ficticias rara vez se dan con la misma verborrea y, por lo tanto, arte hecho por fanáticos, aunque tal vez no sea estrictamente una violación de derechos de autor o un uso justo. es probablemente una investigación original. - M asem ( t ) 13:25, 1 de junio de 2021 (UTC)

• Si la representación realmente coincide con la descripción de las fuentes primarias (que siempre debe ser el propio autor o alguien autorizado explícitamente por el autor), y la representación se basa en dicha descripción y se presenta como una representación artística con un etiquetado claro de los mismos (no solo en el título, pero con, por ejemplo, un sombrero de sección), y no se usa en el cuadro de información principal de una página, entonces encontraría esas imágenes apropiadas y útiles. Cualquier cosa que no sea eso justifica la eliminación o la mejora de los estándares que describí.

Tenga en cuenta que no aplicaría este estándar a imágenes sobre bienes comunes, donde creo que los únicos estándares que deben cumplirse es una descripción clara de lo que es y una declaración clara de que es una representación artística. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 13:32, 1 de junio de 2021 (UTC)

• Bueno, incluso con un conocimiento limitado de heráldica, de hecho hay muy pocos colores heráldicos: solo un tipo de amarillo (gules), solo un tipo de verde (vert), y así sucesivamente, por lo que hay poco en lo que equivocarse si, como ha dicho correctamente el editor anterior, la descripción original es clara e inequívoca. Estoy seguro de que cualquier especialista en heráldica podrá confirmar que puede reconstruir fácilmente cualquier insignia, bandera o escudo de armas a partir de su descripción, por lo que si hay un león desenfrenado en un campo vertical o lo que sea, pueden dibujarlo exactamente a satisfacción. de otros especialistas en heráldica. Siempre que quede claro que se trata de una impresión de un artista o una reconstrucción heráldica o alguna frase similar, no hay problema aquí. No estoy de acuerdo con Masem, por lo tanto, en que haya algún problema en particular sobre la heráldica en la ficción; si el autor de un libro ha dado una descripción heráldica, entonces esa cuenta puede tomarse como una especificación de una insignia heráldica sin ninguna sugerencia de invención editorial. Todo lo mejor, Chiswick Chap ( charla ) 14:03, 1 de junio de 2021 (UTC)

  Chiswick Chap , de hecho, hay muy pocos colores heráldicos: solo un tipo de amarillo (gules), solo un tipo de verde (vert), y así sucesivamente, por lo que hay poco que equivocar si, como el editor anterior ha dicho correctamente, el original La descripción es clara e inequívoca. No es que sea un punto importante, pero me gustaría señalar que solo porque tenemos una paleta de colores limitada en la vida real aquí, eso no sugiere que la ficción aquí usaría la misma paleta, o incluso tendría límites.

  Pero, no debe leer eso como un desacuerdo con su punto general de que la heráldica está restringida a ciertas normas, y es muy probable que las representaciones que se ajustan a esas normas sean casi idénticas entre sí. Además, creo que es muy probable que Tolkien, al menos, se hubiera limitado a los estándares heráldicos del mundo real, debido a la descripción de la Tierra Media como la Europa pre-paleolítica. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 14:16, 1 de junio de 2021 (UTC)

  Si todos estos provienen de un lenguaje que se basa en la heráldica del mundo real (y estamos hablando de lo que parece ser principalmente YO y Wheel of Time, que creo que son obras que seguirían eso), entonces puedo ver el argumento de que no hay problema con estos. Lo que queremos evitar es cruzar una línea con el fan art completo en WP para universos ficticios (por ejemplo, la interpretación de un fanático de Battle of Helm's Deep sería inapropiada a pesar de lo descriptivo que el libro y los trabajos asociados lo dan). - M asem ( t ) 15:57, 1 de junio de 2021 (UTC)

  Masem , esto sigue exactamente con mi punto de vista. Esbocé cuáles serían mis estándares para dejarlo explícitamente claro, arriba. Soy un poco tonto sobre el tema de los mundos de fantasía como Westeros , que históricamente está menos ligado al mundo real, pero en general, diría un firme "no" a representar cualquier cosa que ya haya un oficial o semi -representación oficial de, como la batalla que mencionaste. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 17:24, 2 de junio de 2021 (UTC)

  También estoy pensando en casos en los que, por ejemplo, la portada original es una clara influencia en la obra de la que el fan art puede derivarse, lo que genera una pregunta. Este ejemplo se aleja del aspecto heráldico, pero como la versión de un fan de Harry Potter (sin cosplay) probablemente sería problemático dada la presentación "oficial" en la portada original , así como la impresión estadounidense en las películas. La heráldica, tal como se establece incluso para los casos del mundo real, es diferente y por qué podemos usar COArms y banderas creados por el usuario a pesar de que puede haber versiones preferidas existentes, pero cualquier cosa que no sea esto va a caer más en trabajos derivados que pueden ser en cuestión. - M asem ( t ) 19:06, 2 de junio de 2021 (UTC)

  Masem , exactamente.

  Ahora, si hay una buena razón por la que quisiéramos mostrar fan art, entonces está en discusión. Como hipotético, imagino una obra de ficción que se hizo conocida principalmente por el fan-art que inspiró. En ese caso, un par de ejemplos podrían estar bien. Y el cosplay puede ser útil para ayudar a demostrar la importancia de una obra en la cultura pop.

  Pero no hay forma, para robar tu ejemplo, de que usemos una de las pinturas de mi infancia como la imagen principal en Battle of Helm's Deep , o una de mis representaciones de Stryker, no importa lo cariñoso o orgulloso que esté, no importa. qué tipo de plantillas de "representación artística" le damos, porque si necesitamos un ejemplo, podemos tomar un fotograma de la película con un uso legítimo .

  En una nota al margen, el uso de imágenes en ese artículo es acertado. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 22:30, 2 de junio de 2021 (UTC)

  Nitpick: gules = rojo, o = amarillo. Dhtwiki ( charla ) 05:20, 2 de junio de 2021 (UTC)

• Realmente no tengo ningún problema en ilustrar la declaración "la bandera del dominio ficticio de Kusmaland es un pterodactylus rojo sobre un fondo verde" con una imagen creada por el usuario de un pterodactylus rojo sobre un fondo verde. De hecho, creo que esto debería fomentarse. Solo debe quedar absolutamente claro lo que se muestra, y no debe hacerse ninguna afirmación del estado "oficial" de la impresión de este artista sin que aparezca en otras fuentes. Algo como la galería de banderas en El mundo de la rueda no es apropiado sin una fuente explícita. - Kusma ( conversación ) 15:54, 1 de junio de 2021 (UTC)

BLPPROD y control de autoridad

¡Hola!

Me encontré con un par de artículos de BLP sin fuente (es decir, Kev Hopper ) y los propuse para su eliminación a través de Wikipedia: Eliminación propuesta de biografías de personas vivas . Noté que tenían plantillas de control de autoridad, pero eso fue todo. Las plantillas BLPPROD se eliminaron posteriormente con el argumento de que el control de autoridad cuenta como fuentes de la misma manera que lo harían los enlaces externos. Si bien este razonamiento tiene sentido, el control de autoridad está extrayendo enlaces de Wikidata. El código fuente de la página de Wikipedia solo muestra {control de autoridad} y nada más, así que en mi opinión, la página de Wikipedia en sí no contiene fuentes de ninguna forma. Esa es la desconexión para mí.

Si el control de autoridad hace que BLPPROD no sea elegible o no, creo que debería especificarse explícitamente en la política para evitar esta confusión nuevamente, como "agregar artículo no contiene fuentes de ninguna forma (como referencias, enlaces externos, identificadores de control de autoridad , etc.) ". Mbdfar ( charla ) 19:02, 2 de junio de 2021 (UTC)

• Esto es ridículo, el control de la autoridad no sustituye a las fuentes. En el caso del artículo en particular que mencionaste, la "fuente" en el control de autoridad no es confiable de todos modos (ver WP: UGC ). La plantilla BLPPROD indica claramente que una vez que el artículo tenga al menos una fuente confiable, puede eliminar esta etiqueta. , sin embargo, se eliminó a pesar de que no hay fuentes confiables en ninguna parte del artículo, incluida la plantilla de control de autoridad .-- Rusf10 ( hablar ) 19:07, 2 de junio de 2021 (UTC)

Para ser justos, el fan de GB habría tenido derecho a quitar la etiqueta si el control de autoridad cuenta para el abastecimiento. Según la política, "para colocar una etiqueta BLPPROD, el proceso requiere que el artículo no contenga fuentes de ningún tipo (como referencias, enlaces externos, etc.) que respalden las declaraciones hechas sobre la persona en la biografía. Tenga en cuenta que esto es un criterio diferente al utilizado para las fuentes agregadas después de la ubicación correcta de la etiqueta ". Entonces, si el control de autoridad cuenta para el abastecimiento (sin importar la confiabilidad), habría colocado BLPPROD incorrectamente ya que la página no habría sido elegible. Mbdfar ( charla ) 19:14, 2 de junio de 2021 (UTC)

• Acuerdo al 100% con Rusf10 aquí. El control de autoridad enumerado en Kev Hopper se vincula a una base de datos de contenido generado por el usuario, e incluso si el contenido estuviera controlado editorialmente, eso no establecería de ninguna manera la notoriedad, ya que no hay ningún obstáculo para la inclusión que se traduzca aproximadamente en GNG. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 22:22, 2 de junio de 2021 (UTC)

MPants en el trabajo , Rusf10 ; Bien, pero ustedes están perdiendo el punto de esta discusión. Mis disculpas por no ser claro. Este no es un argumento sobre la notabilidad del sujeto, ni sobre la confiabilidad de las fuentes. Se trata de WP: BLPPROD . BLPPROD establece que " para colocar una etiqueta BLPPROD, el proceso requiere que el artículo no contenga fuentes de ninguna forma (como referencias, enlaces externos, etc., confiables o no) ". Por ejemplo, BLPPROD no es válido en un artículo que tiene tanto como enlace a un tweet. Mi pregunta es si los identificadores de control de autoridad preexistentes califican como una fuente contenida en el artículo. En otras palabras, ¿es elegible un artículo BLPPROD si tiene un identificador de control de autoridad válido? La política debe quedar clara. Mbdfar ( charla ) 22:32, 2 de junio de 2021 (UTC)

No, no lo es, porque " Para ser elegible para una etiqueta BLPPROD, la entrada debe ser una biografía de una persona viva y no contener fuentes de ninguna forma (como referencias, enlaces externos, etc., confiables o no) que respalden las declaraciones. hecho sobre la persona en la biografía " . En el caso de Kev Hopper , el enlace AC (que es a MusicBrainz) no admite ninguna declaración en la prosa del artículo. E incluso si lo hiciera, no es una fuente confiable, lo que me hace preguntarme por qué nos molestamos con eso. Black Kite (charla) 22:38, 2 de junio de 2021 (UTC)

Black Kite , si puedo hacer una pregunta de seguimiento; Si un enlace de CA respalda una declaración hecha en la prosa del artículo, ¿la consideraría una "fuente" válida (por lo tanto, el artículo BLPPROD no es elegible)? Tome la página de Jorge Niosi, por ejemplo. Tiene muchos identificadores que respaldan su fecha de nacimiento, nacionalidad y publicaciones. ¿Consideraría esta página BLPPROD inmune? Mbdfar ( charla ) 22:52, 2 de junio de 2021 (UTC)

El enlace AC definitivamente respalda material en la biografía: verifica un elemento en su discografía y, al tener una discografía, verifica que es un músico. ¿Es una fuente confiable? Probablemente no, pero eso no es (y no debería ser) un requisito para prevenir BLPROD, que está destinado a borrar los casos más flagrantes. Si esta preocupación sobre AC y BLPROD es algo que surge con frecuencia, entonces sí, debe agregarse explícitamente al descriptor BLPROD. Si este es un caso raro, probablemente no valga la pena. - Nat Gertler ( charla ) 23:03, 2 de junio de 2021 (UTC)

El enlace de CA no verifica nada porque NO es confiable. ( WP: V se trata de usar fuentes confiables) Una fuente que no es confiable no cuenta. De lo contrario, alguien podría simplemente crear un artículo y un enlace a su propio blog para eludir BLPPROD .-- Rusf10 ( hablar ) 01:08, 3 de junio de 2021 (UTC)

Pero BLPPROD dice confiable o no , por lo que alguien podría eludirlo de esa manera. JoelleJay ( charla ) 02:39, 3 de junio de 2021 (UTC)

Una fuente que no es confiable en absoluto cuenta para hacer que el BLPROD sea ilegítimo. Según WP: BLPROD , "Los requisitos se pueden resumir como: solo agregue un BLPPROD si no hay fuentes de ninguna forma que respalden cualquier declaración hecha sobre la persona en el artículo, pero una vez colocada (correctamente), solo se puede eliminar si se agrega una fuente confiable . " Si desea cambiar el núcleo de BLPROD, esa es una discusión mucho más amplia. - Nat Gertler ( charla ) 03:08, 3 de junio de 2021 (UTC)

Existen alternativas para deshacerse de las páginas con solo fuentes poco confiables, como eliminación rápida, prod o AFD, por lo que no hay necesidad de preocuparse por jugar con el sistema. Las fuentes no confiables necesitan un examen más detenido para ver si lo son, por lo que no son ideales para la eliminación rápida de artículos basados ​​en eso. Graeme Bartlett ( charla ) 03:56, 3 de junio de 2021 (UTC)

El control de autoridad debe considerarse válido para enlaces externos, siempre que (por lo que sabemos, después del hecho) el enlace en cuestión estaba realmente allí cuando se agregó la etiqueta. 147.161.12.57 ( conversación ) 06:21, 3 de junio de 2021 (UTC)

Mbdfar , estoy totalmente de acuerdo con la respuesta de Black Kite a este comentario. La plantilla de CA no es ni debe considerarse una fuente. Es un índice que permite encontrar datos sobre el tema, pero no garantiza la existencia o relevancia de dichos datos. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 12:23, 3 de junio de 2021 (UTC)

• Estoy de acuerdo en que la plantilla de CA, por sí sola , no es suficiente para prevenir un PROD ... sin embargo ... nos vincula a un índice de fuentes potenciales que deben revisarse antes de un PROD (según WP: ANTES ) . Si es probable que una de esas fuentes potenciales pueda respaldar la información del artículo, entonces no insista ... vaya directamente a la AFD si desea cuestionar / desafiar la notoriedad. Blueboar ( charla ) 12:41, 3 de junio de 2021 (UTC)

La pregunta no es si la plantilla de CA es suficiente para prevenir un PROD. La pregunta se refiere a WP: BLPPROD . La política de BLPPROD dice que cualquier fuente, confiable o no, en el artículo que respalde cualquier información en el artículo lo hace inelegible para BLPROD. Si tenemos este escenario:

1. Tenemos un BLP.
2. El BLP tiene en su código fuente.{{authority control}}
3. En la plantilla de control de autoridad que se muestra en el artículo hay enlaces.
4. En al menos uno de los enlaces hay algún dato que también está en el artículo.

¿Es esto suficiente para que este BLP no sea elegible para BLPPROD? ~ Ventilador de GB 13:56, 3 de junio de 2021 (UTC)

Ventilador de GB , yo diría que depende completamente de si la información en ese enlace existe o no y cumple con nuestros estándares de confiabilidad. En el ejemplo mencionado anteriormente, claramente no hace lo último. Si hay un caso en el que sí ... Bueno, creo que esos casos deberían discutirse, lo que probablemente me pone de su lado en esos casos. Sin embargo, en general, la presencia o ausencia de una plantilla de control de autoridad en una página no debería ser un factor al tratar con BLPROD. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 15:37, 3 de junio de 2021 (UTC)

Exactamente ... Haga la debida diligencia ANTES de presionar. Primero verifique las fuentes potenciales vinculadas a través de la plantilla de CA. Si alguno de ellos podría ser citadas en el artículo, entonces PROD probablemente no es apropiado. Pero si ninguno es utilizable, continúe y pinche (y mencione que verificó AC y no encontró fuentes viables). Recuerde que PROD es para casos claros. Si tiene alguna duda, no PROD. Blueboar ( charla ) 15:35, 3 de junio de 2021 (UTC)

MPants en el trabajo : ¿Por qué un enlace de CA debe tratarse de manera diferente a cualquier otro enlace externo cuando se trata de BLPROD, es decir, si contiene información en el artículo, incluso si no es confiable , entonces BLPROD no está permitido? Si hay alguna razón, parecería una excepción que tendría que integrarse en BLPROD, que actualmente no lo es. - Nat Gertler ( charla ) 15:43, 3 de junio de 2021 (UTC)

NatGertler , porque no hay garantía de que contendrá información en absoluto , y mucho menos cualquier información que esté en el artículo. El hecho de que algo esté indexado en una base de datos no significa que haya datos adjuntos a ese índice. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 15:49, 3 de junio de 2021 (UTC)

MPants en el trabajo , por lo que parece que deberíamos tratarlo como cualquier otro enlace externo. El mero hecho de tener un enlace externo no anula un BLPROD. "Para ser elegible para una etiqueta BLPPROD, la entrada debe ser una biografía de una persona viva y no contener fuentes de ninguna forma (como referencias , enlaces externos , etc., confiables o de otro tipo) que respalden las declaraciones hechas sobre la persona en la biografía. . " Un enlace AC que admita declaraciones en la biografía parecería encajar bastante bien en el "etc." en eso, si no simplemente como un "enlace externo". Todavía no veo la excepción "pero no el control de autoridad" en esto. - Nat Gertler ( charla ) 16:09, 3 de junio de 2021 (UTC)

• risita * buena suerte con eso. La multitud de wikidata no quiere que se trate como un enlace externo porque entonces estaría sujeto a WP: EL y su contenido se eliminaría en muchos casos. La solución a esto es alterar BLPPROD para permitir BLPRODing de artículos que no contienen referencias / fuentes. Los enlaces externos o las plantillas no son una consideración si se puede presionar algo en función del abastecimiento, porque no son fuentes o referencias. Simplemente elimine la redacción que está causando esto. Solo en la muerte termina el deber ( conversación ) 16:17, 3 de junio de 2021 (UTC)

la excepción "pero no de control de autoridad" para mí (que me llevó a comenzar esta discusión) es que los enlaces AC están alojados en Wikidata, no en Wikipedia. Los enlaces en Wikidata se pueden cambiar o eliminar sin dejar un registro de cambios en Wikipedia. Creo que esto es importante en un contexto BLP. La página de Wikipedia en sí no alberga enlaces o fuentes externas, lo que me lleva a interpretar BLPPROD de esta manera. Mbdfar ( charla ) 16:24, 3 de junio de 2021 (UTC)

No creo que la distinción de si el contenido de datos / enlaces se almacena en Wikidata o en Wikipedia sea particularmente útil. Usamos imágenes de Commons en nuestros artículos todo el tiempo, aunque eso significa que no tenemos control local sobre los cambios. En el caso que nos ocupa, si alguien hubiera convertido la plantilla de CA en un enlace de MusicBrainz no habría mejorado ni empeorado la situación. - Kusma ( conversación ) 18:52, 3 de junio de 2021 (UTC)

• NatGertler , El mero hecho de tener un enlace externo no anula un BLPROD. Estoy de acuerdo y creo que el simple hecho de tener una plantilla de CA no debe anular un BLPROD.

Un enlace AC que admita declaraciones en la biografía parecería encajar bastante bien en el "etc." en eso, si no simplemente como un "enlace externo". Sí, por eso dije anteriormente que vale la pena discutirlo en esos casos. Estoy de acuerdo con Blueboar en que la verificación de los enlaces de CA debe ser la debida diligencia normal para BLPRODing de un artículo. También afirmo que la doble verificación de los enlaces de CA debería ser parte de la diligencia debida normal para eliminar un BLPROD. Finalmente, también estoy de acuerdo con Only in death a continuación en que los enlaces externos no deben incluirse en los criterios de WP: BLPROD . Debe haber fuentes reales para anularlo, no simplemente enlaces externos. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 16:26, 3 de junio de 2021 (UTC)

• Según tengo entendido, BLPPROD usa reglas de línea brillante. El enlace Musicbrainz estaba presente en el artículo (no importa si a través de AC o directamente), por lo que el artículo no era un candidato BLPPROD. Sin embargo, el enlace no verifica nada útil y no puedo encontrar fuentes que admitan mucho más que #REDIRECT [[Stump (band)]]. Apoyaría el fortalecimiento de BLPPROD para requerir la presencia de una fuente confiable / un enlace x confiable antes de su uso, lo que haría que agregar y eliminar BLPPROD siguieran las mismas reglas. - Kusma ( conversación ) 15:53, 3 de junio de 2021 (UTC)

  ¿Hay objeciones serias a la redirección? Todavía tenemos este BLP sin fuente del que ocuparnos ... - Kusma ( charla ) 18:54, 3 de junio de 2021 (UTC)

Si tan solo tuviéramos una política clara para encargarnos de los BLP sin fuente;)

Jk, creo que una redirección es racional. Mbdfar ( charla ) 04:06, 4 de junio de 2021 (UTC)

La versión actual de WP: BLPPROD es, si hay alguna fuente en el artículo, sea confiable o no, y esa fuente respalda cualquier declaración en el artículo, el artículo no puede ser BLPPROD. Por lo tanto, un enlace externo al sitio web personal publicado por el BLP que respalda alguna declaración en el artículo hace que el artículo no sea elegible para BLPPROD. Volviendo al artículo que se mencionó en la primera publicación de esta sección, Kev Hopper . Tiene una plantilla de control de autoridad con un enlace. Ese enlace va a musicbrainz.org . La página de musicbrainz dice que Kev Hopper lanzó un álbum llamado Stolen Jewels en 1990. La primera entrada en la lista de álbumes de Solo en el artículo de Kev Hopper dice que lanzó Stolen Jewels en 1990. Así que tenemos un enlace externo que respalda información en el artículo. Bajo la versión actual de BLPPROD, ¿es elegible para un BLPPROD? ~ Ventilador de GB 17:51, 3 de junio de 2021 (UTC)

• No elegible. - Kusma ( charla ) 18:04, 3 de junio de 2021 (UTC)

Ignorando por el momento, la falta de confiabilidad de esa base de datos, no creo que el nombre y el año de lanzamiento de un álbum realmente se eleve al nivel de ser considerado una fuente aquí, de lo contrario, uno podría apuntar válidamente al nombre del artículo como fuente. al enlace AC. Me gustaría ver algunos hechos sustanciales en el enlace AC, no solo un dato que no hace nada para decirnos realmente algo sobre el tema. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 18:22, 3 de junio de 2021 (UTC)

• Si determina que un tema no es notable, utilice un procedimiento diferente para proponerlo / nominarlo para su eliminación. El procedimiento BLPPROD es simplemente algo que se introdujo en medio de un pánico moral cuando algunos editores disruptivos, incitados por Jimmy Wales, pensaron que era más urgente eliminar los artículos sin fuentes que decían "Joe Bloggs es un futbolista que juega para Anytown United "que eliminar violaciones genuinas de BLP, que a menudo citan muchas fuentes. Por favor, pensemos en las cosas, en lugar de seguir ciegamente los procedimientos. Todavía estoy convencido de que la diferencia entre lo que es válido para colocar una etiqueta BLPPROD y lo que es válido para eliminarla fue un simple accidente de redacción causado por la prisa por poner algo en su lugar, en lugar del punto de conversación filosófico amado por Wikilawyers que parece haberse convertido. Phil Bridger ( charla ) 18:56, 3 de junio de 2021 (UTC)

Propuesta para ajustar la redacción de la política para incluir "control de autoridad"

Propongo que actualicemos la política para leer Para ser elegible para una etiqueta BLPPROD, la entrada debe ser una biografía de una persona viva y no contener fuentes de ningún tipo (como referencias, enlaces externos, enlaces de control de autoridad , etc., confiables o no) - Novem Linguae ( charla ) 03 : 45, 4 de junio de 2021 (UTC)

• Apoyo como proponente. Una de mis picanas BLP me ha sido rechazada por esto antes, y no fue intuitivo para mí. Creo que debe declararse explícitamente. No tengo una opinión sobre si el control de la autoridad debe contar o no, solo quiero asegurarme de que si este es el estándar de facto , se establece claramente en la política. - Novem Linguae ( charla ) 03:45, 4 de junio de 2021 (UTC)
• Apoyo , parece que hice una montaña de un grano de arena, ¿eh? Me hago eco de todo lo dicho anteriormente. Mbdfar ( charla ) 03:51, 4 de junio de 2021 (UTC)
• Hay buenos argumentos arriba para esto. Es decir, que BLPPROD es una circunstancia especial, PROD todavía está disponible y el control de autoridad implica potencial. Dicho esto, ¿qué tal un enlace a una búsqueda en Google del nombre del sujeto? La idea de una "fuente" me implica que de alguna manera podría haber sido pensada como una fuente para el texto del artículo. Es decir, se agregó para apoyar el material en el artículo, incluso si se agregó como un enlace externo, etc. Eso parece poco probable para el control de la autoridad ... - ^{Hablar de las} rododendritas \\ 04:49, 4 de junio de 2021 (UTC)

  Gracias por tu comentario. La política actualmente establece "fuentes en cualquier forma, confiable o no". Me parece que cualquier fuente o enlace invalida el uso de BLPPROD. Si quisiéramos discutir cómo hacer más amplia la aplicación de BLPPROD (tener algunos enlaces es "tan malo" que no cuentan como enlaces, esencialmente), tal vez podríamos comenzar una segunda propuesta. Tengo algunas opiniones al respecto, pero preferiría discutirlas en una sección diferente, ya que en el fondo es una propuesta diferente. - Novem Linguae ( charla ) 05:09, 4 de junio de 2021 (UTC)

  No estoy seguro de que "fuentes" se aplique a absolutamente ningún enlace de la página. Una vez más, ¿qué pasa con un enlace a una búsqueda de Google? Tiene más sentido interpretar esto como "si alguien usó una fuente pero solo la incluyó como un enlace externo en lugar de una cita, sigue siendo una fuente" en lugar de "cualquier enlace = fuente". - ^{Hablar de las} rododendritas \\ 15:07, 4 de junio de 2021 (UTC)

• Apoyar solo si un fortalecimiento de BLPPROD no pasa. Esta propuesta es una aclaración útil que puede ahorrarnos discusiones inútiles en el futuro, pero "los BLP deben tener una fuente confiable o ser elegibles para BLPPROD" podría ser un mejor enfoque en general. - Kusma ( charla ) 10:03, 4 de junio de 2021 (UTC)
• Soporte Tiene sentido. ¿Quizás tenga control de autoridad entre 'referencias' y 'enlaces externos'? Gracias. Mike Peel ( charla ) 10:12, 4 de junio de 2021 (UTC)
• Oponerse : una base de datos de fuentes potenciales no es en sí misma una fuente viable. Las fuentes vinculadas a través de CA pueden o no invalidar un BLPPROD ... pero no lo sabemos sin verificarlas antes de Prodding. También eliminaría el "o de otro modo" entre paréntesis, pero eso puede requerir una segunda RFC. Blueboar ( charla ) 11:42, 4 de junio de 2021 (UTC)
• Oponerse Un enlace de control de autoridad no es una fuente. El lenguaje con respecto a los enlaces externos es claramente para permitir fuentes que no se citan correctamente, un error común de los nuevos editores. Pero cualquier editor capaz de implementar una plantilla AC con el enlace, es capaz de hacer citas adecuadas. Dado que un enlace AC no garantiza que contenga información más allá del nombre de un tema ... No hay razón para tratarlo como una fuente. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 15:45, 4 de junio de 2021 (UTC)

Ni siquiera podemos suponer que la plantilla AC fue agregada por un editor humano. Es posible que lo haya agregado un bot, sin que nadie verifique si alguna de las fuentes potenciales es realmente viable. Blueboar ( charla ) 10:28, 5 de junio de 2021 (UTC)

Maldito buen punto, esto. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 19:03, 9 de junio de 2021 (UTC)

• Oponerse al control de autoridad en algunos casos (incluido el anterior) ni siquiera utiliza fuentes confiables. En todo caso, necesitamos mejorar la calidad de las fuentes que se utilizan para los BLP .-- Rusf10 ( hablar ) 01:25, 5 de junio de 2021 (UTC)
• Oponerse : el control de la autoridad no es unde confianzafuente. Levivich 15:04, 5 de junio de 2021 (UTC)

  TENGA EN CUENTA que BLPPROD no requiere (actualmente) que las fuentes sean confiables para negar el PROD. Incluso la presencia de fuentes poco fiables puede hacerlo. (Podemos cambiar ese requisito si queremos, pero esa es una pregunta diferente de la que se está haciendo).

  El problema más fundamental es que Authority Control no es una fuente , sino simplemente una lista generada de bases de datos en las que se pueden (o no) encontrar fuentes potenciales. Blueboar ( charla ) 15:20, 5 de junio de 2021 (UTC)

  Buen punto, gracias. Actualicé mi! Voto. Levivich 21:11, 5 de junio de 2021 (UTC)

• Me opongo. Creo que la redacción es confusa sobre lo que constituye una "fuente". Un control de autoridad no es una fuente. Que podría ser una fuente, pero se necesitaría el contenido de soporte en el artículo. Incluimos "enlace externo" porque tenemos varias formas diferentes de hacer referencia con las que los nuevos editores pueden no estar familiarizados y pueden usar enlaces directos como fuente; esas palabras existen para no castigar a esos usuarios. SportingFlyer T · C 21:26, 5 de junio de 2021 (UTC)
• Oponerse : una fuente, por definición, es algo en lo que el autor se basó al escribir el artículo. El control de autoridad, por definición , es una herramienta de navegación. Eso es realmente todo lo que hay que hacer. Las plantillas de control de autoridad son medios mediante los cuales alguien podría, hipotéticamente, encontrar fuentes confiables en el futuro. No son fuentes en sí mismas, como tampoco lo es una fuente porque contiene enlaces a motores de búsqueda que, hipotéticamente, podrían encontrar fuentes confiables. Auto extraordinario ( charla ) 22:01, 5 de junio de 2021 (UTC){{BLP unsourced}}
• Oppose AC es un enlace a fuentes potenciales, no es una fuente en sí misma y no satisface los requisitos de abastecimiento de artículos. - ^Charla xaosflux 18:51, 9 de junio de 2021 (UTC)

¿POV con desconocimiento admitido al respecto?

Hola, fui testigo de un administrador de WP: TAGTEAMed que advirtió a un usuario sobre un posible bloqueo y reconoció que no revisó el conflicto / ediciones / discusión relevante. ¿Existe un WP: REGLAS de que el administrador o el usuario no pueden tomar acciones consecuentes si no tienen conocimiento de dicho asunto? Me gustaría conocer tal regla para citarla. Yug (conversación) 11:24, 3 de junio de 2021 (UTC)

Es mejor preguntar esto en WP: AN , pero tal vez debería vincular la discusión relevante para que la gente pueda entender el contexto y asesorar en consecuencia, y también juzgar si su resumen es una representación justa de los eventos. ProcrastinationReader ( charla ) 11:28, 3 de junio de 2021 (UTC)

Mi idea era citar ese WP: Rule, si existe, cuando enviaré el mensaje WP: AN. Ya me topé con el concepto de editores / administradores "elevados" para los usuarios que se lanzan, dejan una opinión sin comprender la situación y luego se van, pero no puedo encontrar la página, si la hay. Yug (conversación) 12:24, 3 de junio de 2021 (UTC)

No creo que haya ninguna "regla" (a favor o en contra). Mucho depende de POR QUÉ los administradores en cuestión "intervinieron". Blueboar ( charla ) 12:50, 3 de junio de 2021 (UTC)

Lo más cercano que se me ocurre es WP: ADMINACCT , donde se supone que los administradores pueden explicar y justificar sus acciones como administradores. - Kyohyi ( charla ) 13:07, 3 de junio de 2021 (UTC)

Aviso de RfC sobre cómo deben mostrarse los nombres de usuario en firmas personalizadas

Vea la charla de Wikipedia: Firmas # RfC: nombres de usuario en firmas - ^{Hablar de las} rododendritas \\ 01:11, 4 de junio de 2021 (UTC)

Bienvenida sobre advertencia

Hola, ¿Qué tal tener una nueva política para los wikipedistas experimentados en relación con WP: Don't Bite Newcomers que promueva el envío de "Bienvenida" en lugar de "advertencia"? Varias ediciones poco constructivas realizadas por usuarios anónimos no resultan ser puro vandalismo. Son errores o ediciones de prueba. A veces, debido a la falta de conocimiento de Wikipedia, se equivocan en el formato. Tenemos herramientas de reversión como Redwarn que solo advierten a esos usuarios. Considerando que, la plantilla de bienvenida tiene enlaces más útiles para que ellos comprendan mejor Wikipedia y realicen ediciones constructivas en Wikipedia. De esta manera, podemos retener a más recién llegados felices. PD- Esto no necesita ser ejercido por aquellos que realmente vandalizan Wikipedia. Es mejor que estén advertidos que recibir una bienvenida. Lightbluerain ❄ ( Discusión | contribuciones ) 02:56, 5 de junio de 2021 (UTC)

Eso es una buena idea. Siempre uso {{Subst: Welcome to Wikipedia}} debido a su contenido agradable y completo. VV 06:21, 5 de junio de 2021 (UTC)

• Depende de POR QUÉ le advierte al nuevo usuario. Algunos comportamientos son tan inaceptables y atroces que deberían ser abofeteados (con fuerza)… sin importar quién sea el editor. Blueboar ( charla ) 15:30, 5 de junio de 2021 (UTC)

  Ciertamente ese es el caso en algunas situaciones. Pero no permitamos que eso se interponga en el debate más amplio sobre ser más acogedor para los nuevos editores en general. Estoy de acuerdo en que, con demasiada frecuencia, es más probable que pongamos una plantilla de advertencia en lugar de algo un poco más útil y acogedor. PackMecEng ( charla ) 15:37, 5 de junio de 2021 (UTC)

Estoy de acuerdo en que tenemos tales usuarios, pero no todos son como escribí en mi publicación. Lightbluerain ❄ ( Discusión | contribuciones ) 06:00, 6 de junio de 2021 (UTC)

Aunque estoy seguro de que se producen errores y sé por experiencia que algunos editores nuevos son demasiado rápidos para emitir advertencias de vandalismo, y que herramientas como Redwarn quizás faciliten demasiado la emisión de dichas advertencias, me gustaría ver datos sobre la frecuencia con la que se producen. los errores son generales. En mi experiencia, es bastante fácil en la mayoría de los casos distinguir entre la mala fe de los novatos y la mala intención. Estoy muy a favor de dar la bienvenida y ayudar a los novatos honestos, y también estoy a favor de expulsar a las personas maliciosas rápidamente. Se debe requerir evidencia convincente de un problema generalizado que no puede ser controlado por los mecanismos existentes para implementar un cambio de política. Cullen ³²⁸ Vamos a discutirlo 05:10, 8 de junio de 2021 (UTC)

Cullen328 , ¿Cómo recopilar los datos? No tengo ni idea de esto. Lightbluerain ❄ ( Discusión | contribuciones ) 03:34, 9 de junio de 2021 (UTC)

Lightbluerain , mis habilidades personales no están en la recopilación de datos en Wikipedia, pero evaluaré los datos que recopilan los editores con esas habilidades. Cullen ³²⁸ Vamos a discutirlo 05:07, 9 de junio de 2021 (UTC)

Bien. Lightbluerain ❄ ( Discusión | contribuciones ) 10:06, 9 de junio de 2021 (UTC)

Oponerse . Las advertencias de nivel uno tienen un tono bastante agradable y acogedor si lee sus textos desde la perspectiva de un recién llegado, y eso es intencional. También tienen la ventaja de ser breves y legibles, con instrucciones concisas y específicas que los recién llegados pueden implementar de inmediato. En mi opinión, esto es más útil para los recién llegados que un mensaje de bienvenida genérico que no aborde el problema con sus contribuciones. Charla JBchrch 11:16, 11 de junio de 2021 (UTC)

Wikiquote

Hola, mi pregunta es sobre el enlace a Wikiquote que se encuentra al final de algunos artículos de WP. En mi opinión, las citas insertadas en WQ suelen ser un complemento importante de la página de WP, por ejemplo cuando WP habla del pensamiento de un autor y WQ lo ilustra con las propias palabras del autor. Sin embargo, el enlace a WQ se encuentra en la parte inferior de la página de WP con otros enlaces externos y estoy seguro de que pasa desapercibido para la gran mayoría de lectores que podrían estar interesados ​​en tales citas. Para remediar esta falta de visibilidad, ¿se permite insertar el enlace a WQ en una de las secciones que tratan sobre los pensamientos del autor? En el WP francés se tolera. Saludos, - Hamza Alaoui ( charla ) 14:53, 5 de junio de 2021 (UTC)

En general, creo que la parte inferior del artículo es razonable, ya que WQ es WP: USERG y no debería recibir más "atención" que los enlaces externos. Puedo ser pesimista, pero me parece probable que una entrada de WQ pueda tener serios problemas de selección de algún tipo de punto de vista. Nunca he editado WQ, así que no sé qué tan "bueno" es. Gråbergs Gråa Sång ( charla ) 08:13, 6 de junio de 2021 (UTC)

Estoy de acuerdo con Hamza Alaoui, es casi imposible encontrar el enlace a Wikiquote en los artículos. ¿No se puede hacer algo para mejorar esto? - Mhorg ( conversación ) 11:29, 11 de junio de 2021 (UTC)

Revertir una reversión

La siguiente discusión es un registro archivado de una solicitud de comentarios . Por favor no lo modifique. No se deben realizar más ediciones en esta discusión. A continuación se presenta un resumen de las conclusiones alcanzadas.

Rechazado por cláusula de bola de nieve. La propuesta ha sido retirada por HAL333 . ( cierre de no administrador ) Sdrqaz ( charla ) 10:26, 8 de junio de 2021 (UTC)

---

El siguiente escenario es frustrantemente común: un editor cambia el antiguo status quo con una edición. Revierte la edición y los anima a discutir en la página de discusión. Luego revierten esa reversión. Debería haber repercusiones por este descuido de la discusión civil a través del ciclo BOLD, revertir, discutir . Propongo que lo siguiente se convierta en política:

Si se revierte la edición de un usuario que cambia el status quo, una reversión de esa reversión resultará en una advertencia en la página de discusión. Una segunda reversión de tal reversión genera un bloqueo de 24 horas.

Esto no se aplicaría a una edición que originalmente elimine alguna infracción grave de la política de Wikipedia, como una violación de BLP. Y, 3RR aún se mantendría, ya que las 3 reversiones no necesariamente tienen que ser sobre el mismo problema exacto. ~ HAL 333 18:36, 6 de junio de 2021 (UTC)

• Apoyar como nom. Fomentaría la discusión y ayudaría a sofocar las guerras de edición antes de que se intensifique. ~ HAL 333 18:46, 6 de junio de 2021 (UTC)
• Comentario : aclaremos esto porque la redacción es un poco confusa. User1 hace una edición WP: BOLD , User2 vuelve a WP: STATUSQUO y fomenta la discusión en la página de discusión. El usuario1 restablece la edición y recibe una advertencia en la página de discusión. User2 lo revierte nuevamente al STATUSQUO. El usuario1 vuelve a restablecer la edición y se bloquea. ¿Es eso lo que propones , HAL333 ? - El Millo ( charla ) 18:50, 6 de junio de 2021 (UTC)

  Facu-el Millo , sí. Perdón por cualquier confusión. ~ HAL 333 19:04, 6 de junio de 2021 (UTC)

• Soporte , no se debe permitir que permanezca ninguna edición impugnada antes de que se resuelva el problema solo por la persistencia del editor. - El Millo ( charla ) 23:50, 6 de junio de 2021 (UTC)
  • Presente mi apoyo en base a otros comentarios a continuación. Secundo la opinión de Number57: El problema para mí es más con 3RR dando una ventaja al editor yendo en contra del status quo. En mi opinión, esto debería modificarse para permitir a un editor una reversión libre para restaurar el status quo . - El Millo ( charla ) 17:22, 7 de junio de 2021 (UTC)
• Oponerse . Las personas no nacen con conocimiento de cómo funciona Wikipedia. ¿Una advertencia por hacer la misma edición dos veces? Y un bloqueo a la segunda infracción . Quizás pensaron que su edición no se guardó. O tal vez tienen razón y el "status quo" es incorrecto , pero aún no saben acerca de WP: CITE , WP: V , WP: BRD , WP: OMGWTFBBQ , etc. O no vieron la advertencia . O la primera persona en revertirlos fue presionando botones descuidadamente. O es un experto ocupado o anciano en su campo, y simplemente no tiene el tiempo o la paciencia para aprender nuestras pequeñas reglas insignificantes. O son un niño, haciendo todo lo posible. Un bloqueo en la segunda ofensa sería espectacularmente torpe. Dé tiempo a las personas para que aprendan cómo funciona este lugar.
  Y, me gustaría ver el "status quo" definido de una manera en la que todos los casos extremos complicados no funcionen simplemente en la "versión preferida por el editor con el mayor número de ediciones" en la práctica. Suffusion of Yellow ( charla ) 00:53, 7 de junio de 2021 (UTC)

  Sufusión de amarillo Punto válido: no deberíamos morder a los recién llegados. ¿Qué tal tres plantillas de advertencia de este tipo para editores de IP, nuevos y autoconfirmados y solo una para aquellos que están confirmados extendidos? ~ HAL 333 04:10, 7 de junio de 2021 (UTC)

  Realmente no creo que sea posible escribir un mensaje que no sea mordaz y deje en claro que el editor se bloqueará en la próxima edición. Suffusion of Yellow ( charla ) 20:21, 7 de junio de 2021 (UTC)

• Comentario Creo que tendríamos que definir claramente en qué momento algo se convierte en WP: STATUSQUO . ¿Es WP: STATUSQUO después de estar en el artículo un día, una semana, un mes, un año, etc? Saludos  Spy-cicle💥  ^{Talk ?} 01:02, 7 de junio de 2021 (UTC)

¿Qué tal 15 días o cualquier cosa presente en un artículo después de pasar por un GAN o FAC? No sería justo dar un trato igual a febrero y julio. ~ HAL 333 04:13, 7 de junio de 2021 (UTC)

15 días parece estar bien, aunque creo que es posible que tengamos que ajustarnos al contexto (es decir, el artículo de poco tráfico tiene un mayor tiempo de espera para el status quo). Probablemente en FAC tal vez en GAN, pero supongo que también tendríamos que ajustar WP: ONUS . Puede ser complicado formular la mejor manera de proponerlo, pero ciertamente entiendo la frustración. Recuerdo haber reescrito un artículo, lo envié a GAN, otro editor lo reescribió por completo, lo devolví al status quo, de un lado a otro y luego otro editor lo devolvió a la nueva versión forzándolo a salir del status quo, luego un editor diferente falló mi GAN debido a la guerra de edición. Es más fácil trabajar en artículos de menor tráfico ... ¿  Spy-cicle💥  ^{Talk ?} 07:02, 8 de junio de 2021 (UTC)

• [ec] Comentario : No hay nada especial en el status quo per se. No lo confunda con consenso como resultado de una discusión razonada y evidencia. Gran parte del statu quo es consecuencia de que nadie ha logrado mejorar todavía. · · · Peter Southwood ^(charla) : 04:16, 7 de junio de 2021 (UTC)
• Oponerse como se expresa actualmente. Demasiado vago, con lagunas para un mal uso. · · · Peter Southwood ^(charla) : 04:25, 7 de junio de 2021 (UTC)
• Oponerse . Esto debe agregarse a WP: PERENNIAL . Hacer de WP: BRD una directriz o política en lugar de un ensayo se ha propuesto muchas veces y siempre ha fallado. Si alguien insiste en participar en una guerra de edición, use WP: ANEW si infringe WP: 3RR . Si es más un patrón a largo plazo de evadir 3RR pero editar mucho de todos modos, pruebe WP: ANI ya que es más probable que produzca una restricción.  -  SMcCandlish ☏ ¢  😼  10:14, 7 de junio de 2021 (UTC)
• Oponerse a BRD vale la pena intentar seguirlo, pero no siempre es posible o incluso deseable. Ya hay suficientes formas de lidiar con esta situación. Selfstudier ( charla ) 10:29, 7 de junio de 2021 (UTC)
• Oponerse . Hay muchas situaciones en las que una regla tan clara conduciría a resultados perversos, como cuando se corrige un error de ortografía que nadie ha notado durante años. ¿De verdad estamos diciendo que alguien que restablece una corrección revertida debe ser advertido y luego bloqueado, incluso si la corrección es obviamente correcta? Como suele ocurrir, esta es un área en la que se necesita el juicio humano en lugar de la adherencia a reglas estrictas. Phil Bridger ( charla ) 10:33, 7 de junio de 2021 (UTC)
• Estoy completamente de acuerdo con el problema presentado, pero no puedo estar de acuerdo con esta implementación debido a las preocupaciones planteadas por Phil Bridger, entre otros. Estoy de acuerdo en que deberíamos usar más el sentido común cuando se trata de editar guerras. Elli ( charla | contribuciones ) 14:42, 7 de junio de 2021 (UTC)
• Apoyar en principio pero oponerse como está escrito actualmente. "No repita una edición sin consenso" es lo que debería ser nuestra regla (sería una 1RR eficaz en todo el sitio, que yo apoyaría, y es básicamente lo que se está proponiendo, pero tengo objeciones a la redacción propuesta). Levivich 14:48, 7 de junio de 2021 (UTC)

  Según tengo entendido, WP: 1RR permite al editor original hacer una reversión, mientras que esta propuesta prohíbe explícitamente esto. Realmente está haciendo obligatorio el ciclo audaz, revertir y discutir . isaacl ( charla ) 20:13, 7 de junio de 2021 (UTC)

• Oponerse Hay varias situaciones en las que la reversión de una reversión es perfectamente aceptable; por ejemplo, el resultado de una discusión que se está implementando y el reversor original no está al tanto de este resultado, o revertir una reversión a ciegas instintiva que no se hizo de buena fe. . El problema para mí es más con 3RR dando una ventaja al editor yendo en contra del status quo. En mi opinión, esto debería modificarse para permitir a un editor una reversión libre para restaurar el status quo. Número 5 7 15:10, 7 de junio de 2021 (UTC)

  Estoy totalmente de acuerdo contigo en 3RR. ~ HAL 333 16:33, 7 de junio de 2021 (UTC)

• Opongo y personalmente me gusta como 3rr ventajas de un editor que va en contra del status quo. Obliga a las personas a revertir a encontrar al menos una vez a otra persona que esté de acuerdo con ellos, lo que demuestra consenso. Ajedrez ( charla ) (utilícelo en la respuesta){{reply to|Chess}} 19:47, 7 de junio de 2021 (UTC)

  El problema es que entra en conflicto con WP: CONSENSUS. Según NOCON (parte del consenso), el cambio no debe realizarse a menos que haya un consenso para cambiarlo. A menudo, las guerras de edición ocurren porque los editores que intentan hacer un cambio no han mostrado consenso, pero tienen suficientes reversiones de su lado para ser la última reversión en pie. Mientras el CONSENSO sea una política, nuestras reglas de comportamiento deberían impulsar en esa dirección. Springee ( charla ) 21:28, 7 de junio de 2021 (UTC)

• Por mucho que creo que el ciclo audaz, revertir, discutir es un buen enfoque cuyo nivel de apoyo de la comunidad lo acerca a una política, creo que hacerlo obligatorio podría ser demasiado inflexible para todas las situaciones. Creo que también podría exacerbar los problemas de propiedad de los artículos, al facilitar que cada actualización se convierta en una discusión prolongada. isaacl ( charla ) 20:24, 7 de junio de 2021 (UTC)
• Oponerse como se ha dicho, pero ... Apoyo firmemente la preocupación aquí. Con mucha frecuencia, he visto una edición de mala calidad agregada a una página, se revierte (vuelve al status quo) y luego la persona que la agregó o incluso otro editor restaura el contenido en disputa. Una falla de 1RR o 3RR es cada vez que ambos editores agotan su "límite de edición", el resultado es que el cambio se mantiene y se revierte. Preferiría ver algo incluido en las reglas de 1RR que digan, 1RR, BRD obligatorio si se cuestiona una nueva edición. Esto permitiría a un editor realizar varias ediciones nuevas en una página, incluso si una de esas ediciones se revierte, sin alcanzar el límite de 1RR. Sin embargo, si se cuestiona alguna edición, no se puede restaurar sin el consenso de la página de discusión primero. La "reversión libre" del número 57 también podría funcionar, pero reducir el número de reversiones probablemente sea mejor que aumentar el número. De cualquier manera, es un problema que el sistema actual favorezca inadvertidamente un cambio frente al statu quo. Springee ( charla ) 21:24, 7 de junio de 2021 (UTC)
  • Una alternativa podría ser convertir 3RR en una regla de tres ediciones, es decir, un editor no puede realizar la misma edición más de tres veces en un período de 24 horas. Esto eliminaría la ventaja que tiene el editor de ir en contra del statu quo. Número 5 7
• Comentario del nominador Bueno, esto parece un WP: SNOWCLOSE . Pero como sugirieron varios editores anteriores, propondré un cambio (más pensado) a 3RR en unos días. Salud. ~ HAL 333 21:29, 7 de junio de 2021 (UTC)

La discusión anterior está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

¿Estoy haciendo campaña?

Hola, un usuario acaba de hacer este comentario. [1] ¿Estoy haciendo algo mal? No creo que esté sondeando ... Estoy exponiendo en esta discusión [2] con un usuario encontrado en una solicitud de AE, todos los eventos que considero injustos sobre otro usuario. Si es así, me detendré ahora. Gracias .-- Mhorg ( charla ) 18:57, 6 de junio de 2021 (UTC)

  Comentario: Esto parece que debería plantearse en WP: ANI , en lugar de aquí. 2601: 1C0: 4401: 24A0: 6463: 127E: E490: C360 ( conversación ) 16:30, 11 de junio de 2021 (UTC)

Listas de destinos de aeropuerto

No necesito citar ejemplos específicos, solo busque cualquier artículo sobre un aeropuerto de tamaño razonable y encontrará una sección #Airlines_and_destinations. No sé si hay un consenso explícito para esto (o, si lo hay, si es un WP: LOCALCONSENSUS ), pero parecen ser ejemplos flagrantes y obvios de WP: NOT (ambos porque no somos una guía de viajes y porque no somos una recopilación indiscriminada de información), además de ser un material de alto mantenimiento. ¿Habría alguna objeción a que inicie un RfC (aquí) para obtener un consenso explícito para su eliminación? RandomCanadian ( charla / contribuciones ) 01:52, 11 de junio de 2021 (UTC)

Parece ser parte del diseño estándar de contenido de página / aeropuertos de Wikipedia: WikiProject . Asegúrese de tener claro en su RfC si solo está hablando de los destinos frente a la lista completa de aerolíneas también. DMacks ( charla ) 02:01, 11 de junio de 2021 (UTC)

Entonces LOCALCONSENSUS, como estaba diciendo? RandomCanadian ( charla / contribuciones ) 02:24, 11 de junio de 2021 (UTC)

No todo lo que no tuvo la oportunidad de votar es una violación del "consenso local" y no todo el texto que aparece en Wikipedia requiere la aprobación previa de toda la comunidad. Cuando la comunidad ha decidido algún principio, el consenso local no debe anularlo, pero la comunidad no ha decidido este tema de manera significativa y nadie está haciendo nada malo aquí. - Jayron 32 14:40, 11 de junio de 2021 (UTC)

Definitivamente se siente como algo para ver si los estándares del proyecto son inconsistentes con las expectativas generales de en.wiki. Un RFC sería apropiado, pero definitivamente debe asegurarse de que el wikiproject de Aeropuertos esté informado al respecto. - M asem ( t ) 02:31, 11 de junio de 2021 (UTC)

Por otro lado, enumeramos todas las estaciones de servicio directo de las estaciones de tren, ¿por qué no los aeropuertos? - Golbez ( conversación ) 04:01, 11 de junio de 2021 (UTC)

Los trenes realmente no pueden cambiar de ruta con tanta libertad como los aviones, en los que todo depende de lo que las aerolíneas decidan hacer en su mayor parte. Hay razones para considerar, particularmente para los aeropuertos regionales / municipales más pequeños, para decir que generalmente sirven para proporcionar vuelos de conexión a un centro de aeropuerto importante, pero este razonamiento no tiene sentido para los aeropuertos de gran escala. - M asem ( t ) 04:14, 11 de junio de 2021 (UTC)

Los medios de comunicación mencionan la apertura y el cierre de nuevas rutas. La gente parece mantenerlos. La única razón por la que puedo ver para eliminarlos es que Wikipedia es el mejor lugar en Internet para esta información. Lo cual no es una buena razón para destruir este útil recurso. - Kusma ( charla ) 05:51, 11 de junio de 2021 (UTC)

Para un razonamiento un poco más enciclopédico, algo como la lista de destinos es necesario para comprender qué tipo de aeropuerto es un aeropuerto determinado. Desde una perspectiva europea, por ejemplo, es un rasgo característico si un aeropuerto tiene vuelos domésticos o no. El aeropuerto de Nuremberg está razonablemente conectado con centros y destinos de negocios (además de vacaciones), mientras que el aeropuerto de Dortmund sirve vacaciones y vuelos a casa para los europeos del este que trabajan en Alemania. Puede leer esto en la lista de destinos sin tener que juzgar en el artículo si considera que los vuelos a Barcelona y París son vuelos de negocios o de placer. Si explica el carácter de la lista de destinos en prosa, todavía tiene que dar algunos ejemplos, y luego ir a la lista completa no está muy lejos. - Kusma ( charla ) 06:34, 11 de junio de 2021 (UTC)

No hay razón para que el tipo de aeropuerto no se pueda describir en texto usando términos técnicos para describir los aeropuertos. Por ejemplo: como mencioné, es probable que un pequeño aeropuerto regional solo tenga vuelos a dos o tres centros principales, por lo que se puede mencionar brevemente. Pero no enumeraría todos los destinos posibles para un centro importante como JFK o LAX. En cambio, algo así como "El Aeropuerto Internacional de Atlanta es uno de los principales centros de Delta en los Estados Unidos, que sirve a sus rutas nacionales y viajes internacionales a Europa, Centroamérica y Sudamérica". Ese futuro prueba el artículo de cualquier cambio que pueda ocurrir en los planes de vuelo de Delta. - M asem ( t ) 15:02, 11 de junio de 2021 (UTC)

• Esto surge de vez en cuando y, en mi opinión, está bastante equivocado. Las tablas se han mantenido actualizadas y los destinos a los que sirve un aeropuerto reciben bastante cobertura de los medios. Además, WP: NOTTRAVEL realmente no se aplica aquí; al igual que con las estaciones de tren, una lista de destinos da una idea de la conectividad de un determinado aeropuerto. A menudo he usado Wikipedia como una fuente confiable para ver cómo los lugares se conectan con otros lugares. El mundo de los aviones de pasajeros a menudo tiene que lidiar con argumentos deficientes de WP: NOTTRAVEL ya que está relacionado con el transporte; esto puede ser un poco anticuado de una analogía ahora, pero está claro una tabla de aerolíneas que operan desde el aeropuerto con el número de teléfono de la aerolínea o el sitio web sin ningún tipo de destinos sería una infracción de NOTTRAVEL. Una lista de destinos tiene un valor enciclopédico, y yo me opondría firmemente a cualquier RfC. SportingFlyer T · C 09:50, 11 de junio de 2021 (UTC)
  • Este parece ser el RfC más reciente sobre el tema. SportingFlyer T · C 09:54, 11 de junio de 2021 (UTC)
  • Aquí hay otro RfC en una ubicación central que aclaró que las listas de transporte están bien. - Kusma ( conversación ) 10:16, 11 de junio de 2021 (UTC)
    • El primer RfC se llevó a cabo en la página del wikiproyecto relevante, probablemente atrajo una participación relativamente baja de editores externos, y fue hace 5 años. El segundo RfC trata sobre listas de artículos, no sobre este ejemplo específico, por lo que no estoy seguro de que sea particularmente relevante. La única razón para conservarlos es porque ya están allí (AFAICS), es decir, una apelación a la tradición y una falacia de costos hundidos. Este comentario también parece resaltar problemas de BIAS en los que no había pensado hasta ahora. Una descripción en prosa de los principales destinos a los que sirven las aerolíneas que operan desde un aeropuerto tendría mucho más valor enciclopédico que una lista WP: NOTDIR de todos ellos sin apenas anotaciones, y la mayoría de las veces solo se basa en la cobertura de rutina / fuentes primarias, si es que es significativa. . Las tablas pueden ir a Wikitravel , si lo desea, de verdad, pero está bastante claro que no son enciclopédicas aquí tal como están. Como se ha dicho, creo que Drmies (IIRC) u otra persona, las listas (a diferencia de la prosa real) son a menudo excusas para artículos basura, o en este caso, diría que para una parte no particularmente útil de un artículo. La opción 1 del RfC relevante parece ser realmente la única política justificable: los artículos de Wikipedia deben ser un "resumen de conocimientos" (como corresponde a una enciclopedia ), no una lista de todos ellos. WP: NOTNEWS también se aplicaría, ya que los cambios de ruta solo obtienen una cobertura rutinaria y no significativa. RandomCanadian ( charla / contribuciones ) 14:03, 11 de junio de 2021 (UTC)
      • En el ejemplo específico del aeropuerto de Dortmund , las secciones de destinos agregan detalles a lo que está escrito en la sección Historia. Ilustra el artículo, al igual que lo hacen las imágenes. Falta un "a partir de", al igual que las imágenes deben aclarar si son imágenes históricas o imágenes actuales. Me gustaría ver las listas más en un contexto histórico que siempre actualizadas (los destinos del aeropuerto de Shannon en las décadas de 1940 y 1950 son probablemente más emocionantes que la lista actual) pero realmente no entiendo cómo Wikipedia mejora si el nivel de los detalles proporcionados en estas listas está explícitamente prohibido. ¿También le gustaría eliminar la ruta actual de la ruta 406 de los autobuses de Londres o está bien porque no enumera todas las paradas, pero hace una selección con criterios desconocidos y posiblemente sesgados? - Kusma ( conversación ) 14:37, 11 de junio de 2021 (UTC)
        • ¿Qué agrega la sección de destino que no está ya en la sección de historial (ignorando que la sección de historial en sí se parece a OR, ya que no se citan fuentes)? Simplemente proporciona una lista sin anotaciones de todos los destinos servidos. No destaca el hecho de que el aeropuerto es servido principalmente por aerolíneas de bajo costo, ni dice nada sobre la frecuencia general de los vuelos o qué aeropuertos son atendidos con mayor frecuencia ... No veo por qué se está desviando hacia las rutas de autobús: estos, como los trenes, no son tan propensos a los cambios frecuentes como los aeropuertos, y como podemos ver, la ruta y sus destinos / trayectoria y los cambios propuestos para ellos obtienen suficiente cobertura como para que se pueda escribir una prosa enciclopédica al respecto. Y sí, las listas parciales que solo destacan la ruta general (los enlaces son a los barrios de Londres por los que pasa la ruta, no a paradas particulares) y los puntos de intercambio con otro tránsito (un criterio objetivo, fácil de evaluar) son mucho menos problemáticos que los que daría cada parada (compare lo que está en el artículo con https://tfl.gov.uk/bus/route/406/ ) - eso es lo que equivale a enumerar todos los aeropuertos servidos para una ruta de autobús. "Los destinos del aeropuerto de Shannon de los años 40 y 50 son probablemente más interesantes que la lista actual": probablemente, pero probablemente sea WP: O si no puede encontrar fuentes secundarias que informen sobre la importancia de estas rutas (por ejemplo, "Aeropuerto de Shannon) fue un importante punto de escala para los vuelos transatlánticos, bla, bla, etc.… [fuentes] "). Si las únicas fuentes son WP: PRIMARY (una lista de rutas similar a un directorio), es probable que no sea información enciclopédica. RandomCanadian ( charla / contribuciones ) 15:10, 11 de junio de 2021 (UTC)
          • Me gusta la analogía con las imágenes que ilustran el texto: enumerar los destinos en lugar de llamar a algo "pequeño aeropuerto regional" es una forma de mostrar en lugar de contar. Quizás agregar mapas en los que se puede hacer clic a los artículos quizás sea incluso mejor, pero es probable que eso sea una carga de mantenimiento mayor. C apital S asha ~ t alk 16:05, 11 de junio de 2021 (UTC)
            • De manera ilustrativa, al menos para los aeropuertos más pequeños (no los centros principales) que tienen solo un puñado de rutas entrantes / salientes, podría hacer fácilmente un mapa para mostrarlas como medio de ilustración sin la necesidad de una tabla. Tampoco me sorprendería que para los principales centros mundiales, LAX, JFX, SFO, etc., pueda encontrar RSes que documenten las rutas principales dentro y fuera de estas ciudades y las utilicen de manera ilustrativa (por ejemplo, mostrando como LAX se conecta a varias aeropuertos de Asia occidental y Hawái, además de sus vuelos que cruzan los EE. UU.). Aprecio plenamente la necesidad de señalar, relativamente, dónde se ubican estos aeropuertos en un esquema más amplio de redes de aeropuertos, que para mí es enciclopédico y algo, si pudiera ilustrarse visualmente, sería bueno, pero la información completa de la ruta (sujeto a corto plazo cambios) está más allá del alcance de WP. - M asem ( t ) 20:58, 11 de junio de 2021 (UTC)

          Oh, estoy seguro de que hay fuentes secundarias para eso. La mayoría de las cosas geek del transporte están bien documentadas. Mi fase geek del transporte personal fue hace más de 30 años, así que no iré a arreglar ninguno de estos artículos. Le sugiero que vaya a WT: AIRPORTS para discutir cómo se pueden mejorar los artículos sobre aeropuertos agregando contexto a estas listas y concentrándose quizás más en el texto que en los datos. - Kusma ( charla ) 17:03, 11 de junio de 2021 (UTC)

          • • Confío en la memoria para esto, pero Wikitravel no quiere las tablas, ya que no son realmente útiles para una guía de viajes. (Para ser justos, tampoco entiendo el argumento de la ruta del autobús). Tampoco creo que sea obvio en absoluto que no sean enciclopédicos, y eso es, en última instancia, por lo que se decidirá un RfC, ya que no hay una política clara. responde aquí. Probablemente también estemos llegando a esto desde perspectivas completamente diferentes: tengo un montón de libros antiguos de los días anteriores a Internet sobre aerolíneas, aviones y aeropuertos, etc. Los destinos y las rutas aparecen de manera destacada, y esperaría una lista de aerolíneas que operan al aeropuerto como mínimo. SportingFlyer T · C 20:28, 11 de junio de 2021 (UTC)

'Adquisición' de los servidores IRC de Freenode

Fondo

• https://www.kline.sh/
• https://www.vice.com/en/article/m7ev8y/freenode-open-source-korea-crown-prince-takeover
• https://boingboing.net/2021/05/19/freenode-irc-staff-quit-after-new-owner-seizes-control.html

Tradicionalmente, los proyectos y voluntarios de WMF se coordinaban en los servidores de IRC de Freenode . ¿Deberíamos migrar (o intentar migrar) estos proyectos a Libera Chat ? Headbomb { t · c · p · b } 20:13, 20 de mayo de 2021 (UTC)

Discusión

La pregunta aquí es abordar qué deberíamos intentar hacer en general. Soy consciente de que cada proyecto es independiente y puede configurar canales de IRC donde quiera. Sin embargo, podríamos decidir que alentamos servidores específicos y desalentamos a otros, e intentamos migrar los canales IRC 'oficiales' de Wikipedia / Wikimedia a Libera en lugar de Freenode. Headbomb { t · c · p · b } 20:17, 20 de mayo de 2021 (UTC)

¿No veo que esto necesite un RFC? Los contactos del grupo de Wikimedia ya han anunciado que migrarán a Libera en meta. Izno ( charla ) 20:22, 20 de mayo de 2021 (UTC)

Esto afecta mucho más de lo que hace la WMF. Por ejemplo, hay # wikipedia-bag, # wikipedia-en-afc en plantillas como {{ AfC welcome }} (incluida la versión subtitulada), etc., etc., etc. Headbomb { t · c · p · b } 20: 41, 20 de mayo de 2021 (UTC)

Entonces, ¿por qué iríamos a otro lugar? ¿Quién tiene el conocimiento en la comunidad para eso? ¿Quién quiere ser voluntario para eso? Izno ( charla ) 20:46, 20 de mayo de 2021 (UTC)

Consulte los artículos anteriores. En cuanto a quién tiene el conocimiento, aquí hay muchos usuarios técnicos que pueden ayudar con esto. Headbomb { t · c · p · b } 20:48, 20 de mayo de 2021 (UTC)

Bien, déjeme explicarlo entonces: A) No necesitamos un RFC. Un RFC es una pérdida de tiempo para la comunidad. B) El sentido común llano es "ir donde WMF dice que están tomando los canales principales". Izno ( charla ) 20:53, 20 de mayo de 2021 (UTC)

Vea también aquí . - RoySmith (charla) 21:04, 20 de mayo de 2021 (UTC)

Si entiendo correctamente, ¿los canales fueron configurados por los operadores de canales individuales? Así que les sugiero que propongan un plan y lo publiquen. Me imagino que la mayoría de la gente estará de acuerdo con eso, pero en el caso de que alguien se oponga, se puede discutir más a fondo. (Al igual que en meta, puede haber interés en otras herramientas de chat, pero eso no debería detener ningún plan de transición en estas circunstancias específicas). Isaacl ( charla ) 21:06, 20 de mayo de 2021 (UTC)

Wikimedia está migrando a Libera Chat, que ya fue anunciado por IRC Group Contacts . Consulte IRC / Migración a Libera Chat para obtener algunos de los detalles técnicos; por supuesto, llevará tiempo actualizar la documentación, los enlaces, etc. Legoktm ( charla ) 21:43, 20 de mayo de 2021 (UTC)

Etiqueta RfC eliminada según la discusión anterior; Si se trata de notificar a tantos usuarios como sea posible en lugar de invitar a recibir comentarios, Signpost y WP: AN son probablemente mejores lugares para una notificación. Hay uno en Wikipedia: Administrators'_noticeboard # IRC_security, _Oversight_notice . ~ ToBeFree ( hablar ) 22:49, 20 de mayo de 2021 (UTC)

@ ToBeFree : No lo eliminó, lo comentó. Hay una diferencia . - Red rose64 🌹 ( charla ) 19:25, 21 de mayo de 2021 (UTC)

... e incluso había mirado esa sección. Gracias por eliminarlo. ~ ToBeFree ( hablar ) 19:27, 21 de mayo de 2021 (UTC)

Conflicto entre Usuario: Awesome Aasim / addmylinks y Usuario: BrandonXLF / QuickEdit

Resuelto

@ Awesome Aasim y BrandonXLF : La ventana de edición de QuickEdit aparece en el editor de texto para addmylinks . - Qwerfjkl  | 𝕋𝔸𝕃𝕂 (utilizar en la respuesta) 18:50, 3 de junio de 2021 (UTC)   {{reply to|Qwerfjkl}}

@ Qwerfjkl : ¿Qué quiere decir con que aparece la ventana de edición en el editor de texto? ¿Qué pasos debe seguir para que esto suceda? addmylinks tiene algunos botones que se parecen a los de QuickEdit, pero ese es el editor de texto addmylinks y no QuickEdit.

¿Quiere decir que cuando guarda una página usando QuickEdit, la página aparece en la sección "Mis enlaces" en la barra lateral? - Brandon XLF ( charla ) 19:15, 3 de junio de 2021 (UTC)

@ Qwerfjkl Me parece muy normal. ¿Puede proporcionar información del navegador además de información sobre la piel? Aasim ( charla ) 05:11, 4 de junio de 2021 (UTC)

Al principio, las páginas aparecen normalmente, pero cuando hago clic en el botón "edición rápida", la sección "Mis enlaces" se reemplaza con el editor normal de "Edición rápida". (Estoy usando la máscara Vector, pero podría verse afectada por User: TheDJ / mobileVector.css .) - Qwerfjkl  | 𝕋𝔸𝕃𝕂 (utilice en la respuesta) 06:59, 4 de junio de 2021 (UTC)     {{reply to|Qwerfjkl}}

@ Awesome Aasim @ BrandonXLF Parece que esto solo sucede en dispositivos móviles. - Qwerfjkl  | 𝕋𝔸𝕃𝕂 (utilizar en la respuesta) 15:53, 6 de junio de 2021 (UTC)     {{reply to|Qwerfjkl}}

@ Aasim @ BrandonXLF He usado User: BrandonXLF / PortletLinks para reemplazar el script de Aasim. - Qwerfjkl  | 𝕋𝔸𝕃𝕂 (utilizar en la respuesta) 19:52, 8 de junio de 2021 (UTC)     {{reply to|Qwerfjkl}}

@ Qwerfjkl : Pude reproducir el problema en la nueva máscara de Vector, veré qué puedo hacer para solucionarlo. - Brandon XLF ( conversación ) 20:49, 8 de junio de 2021 (UTC)

@ Qwerfjkl : El problema debería solucionarse ahora. - Brandon XLF ( conversación ) 16:40, 9 de junio de 2021 (UTC)

¡Gracias! - Qwerfjkl  | 𝕋𝔸𝕃𝕂 (utilice en la respuesta) 17:11, 9 de junio de 2021 (UTC)     {{reply to|Qwerfjkl}}

@ BrandonXLF Por "nueva máscara de Vector", ¿te refieres al usuario: mobileVector de TheDJ? - Qwerfjkl  | 𝕋𝔸𝕃𝕂 (utilice en la respuesta) 17:17, 9 de junio de 2021 (UTC)     {{reply to|Qwerfjkl}}

@ Qwerfjkl : Me refiero a mw: Mejoras en lectura / web / escritorio . Si va a la configuración de apariencia con la máscara Vector seleccionada y desmarca "Usar vector heredado", verá la nueva versión de la máscara. - Brandon XLF ( charla ) 18:33, 9 de junio de 2021 (UTC)

¡Gracias! - Qwerfjkl  | 𝕋𝔸𝕃𝕂 (utilizar en la respuesta) 14:55, 11 de junio de 2021 (UTC)     {{reply to|Qwerfjkl}}

Wikipedia bienvenido

De vez en cuando, soy bienvenido en una Wikipedia en otro idioma (hasta ahora italiano y alemán). Esto parece suceder de forma espontánea. - Qwerfjkl  | 𝕋𝔸𝕃𝕂 (utilice en la respuesta) 14:40, 5 de junio de 2021 (UTC)   {{reply to|Qwerfjkl}}

@ Qwerfjkl : muchos de los otros proyectos tienen "bots de bienvenida" que dan la bienvenida a "nuevas cuentas" (que se crean automáticamente si cargas una página de ese proyecto). Vea sus cuentas globales aquí: meta: Special: CentralAuth / Qwerfjkl . - ^Charla xaosflux 14:55, 5 de junio de 2021 (UTC)

Esto es aceptable si realmente hizo una edición en el wiki en cuestión; es comprensible, aunque molesto, si visita la wiki sin hacer una edición. Pero hace unos días recibí una notificación de Tamil Wikisource , que estoy absolutamente 100% seguro de que nunca había visitado hasta que seguí esa notificación para averiguar de qué se trataba, solo para encontrar este aviso , que no puedo leer uno. un poco. Estoy bastante seguro de que la WMF ha decretado que los bots de bienvenida no deben enviar mensajes a personas que nunca hayan editado el wiki en cuestión, pero ¿la restricción también se aplica a los humanos? Notificación de cortesía a Sridhar G , que no es un bot. - Red rose64 🌹 ( charla ) 19:42, 5 de junio de 2021 (UTC)

WMF no ha decretado tal cosa. Esa es completamente una (o varias) decisión de la comunidad en particular.

Hay un gadget que puede hacer que "visite" cada wiki, de modo que reciba todas las bienvenidas al mismo tiempo. No lo tengo a mano. Izno ( charla ) 20:01, 5 de junio de 2021 (UTC)

(ec) No, hay docenas de wikis con bots de bienvenida que llegan a cada cuenta nueva. Si desea "terminar de una vez", habilite las cookies de terceros, luego intente meta: Usuario: Krinkle / Tools / Global SUL . Recibirá alrededor de 25 a 50 bienvenidas durante una semana o dos, y eso será todo. Si sabe cómo llamar más la atención sobre la meta propuesta : Política de bienvenida , hágalo. Suffusion of Yellow ( charla ) 20:02, 5 de junio de 2021 (UTC)

Creo que lo que sucedió con Tamil Wikisource es que las ediciones que realizó en Module: Protection banner / config se importaron a English Wikisource el 20 de agosto (como parte de una importación de Template: Category desambiguación con la casilla "incluir plantillas" marcada), y luego importado desde allí a Tamil Wikisource el 26 de mayo (como parte de una importación de s: Módulo: Lista con la casilla "incluir plantillas" marcada), que creaba automáticamente cuentas locales para todos los usuarios que habían editado la página. Me sucedió lo mismo a través del Módulo: Documentación (que se importó a Wikisource en inglés como parte de la misma importación por lotes el 20 de agosto y luego se importó a Wikisource en Tamil el 3 de febrero como parte de una importación de s: Template: Bad page scan ), excepto por alguna razón, nunca fui bienvenido. * Pppery * _{ha comenzado ...} 21:46, 5 de junio de 2021 (UTC)

Todos los usuarios que han editado una página que fue importada solo se asignan si el administrador hace clic para asignar las ediciones a los usuarios globales e incluir todas las ediciones de la página. Ambos están desactivados de forma predeterminada. Ese tipo de acción es deliberada. Observe el "w>" en la historia del módulo en.wikisource (Módulo: Documentación), (junto a MusikAnimal) indica que esa edición no está asignada a él .-- Snævar ( charla ) 23:26, 5 de junio de 2021 (UTC)

@ Redrose64 : aquí podemos ver los nuevos usuarios. para que te diera la bienvenida. Sridhar G ( charla ) 06:53, 6 de junio de 2021 (UTC)

Parece que estoy con un montón de otras personas cuyos nombres reconozco:

• 05:24, 26 de mayo de 2021 La cuenta de usuario Alex 21 talk contribs se creó automáticamente
• 05:24, 26 de mayo de 2021 La cuenta de usuario Erutuon talk contribs se creó automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario Trialpears talk contribs se creó automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario Black Falcon Talk contribs se creó automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario Mz7 talk contribs se creó automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario Galobtter talk contribs se creó automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario Timrollpickering Talk contribs se creó automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario Bellezzasolo talk contribs se creó automáticamente
• 05:22, 26 de mayo de 2021 Cuenta de usuario Las contribuciones de las charlas de Writ Keeper se crearon automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario SMcCandlish talk contribs se creó automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario Swarm talk contribs se creó automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario BrownHairedGirl talk contribs fue creada automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario Redrose64 talk contribs se creó automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario Jo-Jo Eumerus talk contribs se creó automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario Yaris678 talk contribs se creó automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario de Fayenatic london talk contribs se creó automáticamente
• 05:22, 26 de mayo de 2021 La cuenta de usuario Ymblanter talk contribs se creó automáticamente

Como yo, han existido durante absolutamente años . - Red rose64 🌹 ( charla ) 18:19, 6 de junio de 2021 (UTC)

Son colaboradores de una página importada en ese momento. [3] Ninguno de ellos había visitado la wiki. Si lo hubieran hecho, sus cuentas se habrían creado cuando lo hicieron. Es por eso que mi propuesta en meta: Política de bienvenida dice: "Un wiki solo puede publicar mensajes de bienvenida a los usuarios si su cuenta fue creada originalmente en el wiki, o si el usuario tiene al menos una edición no importada allí". PrimeHunter ( charla ) 22:02, 6 de junio de 2021 (UTC)

Páginas .js para dispositivos móviles / computadoras de escritorio

Resuelto

Cuando cargo cualquier página .js en la versión de escritorio de Wikipedia, no puedo pegar ni copiar texto, así que tengo que cambiar a la versión móvil. ¿Hay alguna manera de solucionar esto? (Creo que WikEd me permitió ver el texto con normalidad). - Qwerfjkl  | 𝕋𝔸𝕃𝕂 (utilizar en la respuesta) 16:52, 6 de junio de 2021 (UTC)   {{reply to|Qwerfjkl}}

Ciertamente, hay algo extraño en el cuadro de edición en algunas circunstancias. Si no obtiene un cursor de edición cuando hace clic en el cuadro de edición, haga clic en el cuadro de resumen de edición y luego use ⇧ Shift+ Tab ↹para acceder al cuadro de edición principal. A continuación, debería poder hacer clic con el ratón en el punto de edición deseado. - Red rose64 🌹 ( charla ) 18:22, 6 de junio de 2021 (UTC)

Esto funciona para mi. ¿Funciona si cierra la sesión? ¿ Funciona el modo seguro ? ¿Cuál es tu navegador? ¿Cuál es tu máscara en Special: Preferences # mw-prefsection-rendering ? PrimeHunter ( charla ) 18:28, 6 de junio de 2021 (UTC)

@ PrimeHunter @ Redrose64 Estoy usando un dispositivo móvil, por eso tengo que cambiar a la versión móvil para pegar cualquier cosa. - Qwerfjkl  | 𝕋𝔸𝕃𝕂 (utilizar en la respuesta) 19:55, 8 de junio de 2021 (UTC)     {{reply to|Qwerfjkl}}

@ PrimeHunter No funciona en modo seguro y estoy usando la máscara vectorial. No puedo probar si funciona cuando se cierra la sesión, ya que Usuario: Qwerfjkl / common.js no puede editarlo un administrador que no sea de interfaz. - Qwerfjkl  | 𝕋𝔸𝕃𝕂 (utilice en la respuesta) 06:25, 10 de junio de 2021 (UTC)     {{reply to|Qwerfjkl}}

¿Puede copiar y pegar cuando cierre la sesión? Safemode no carga ninguna página js de usuario. ¿Qué quieres decir con "cargar cualquier página .js" en "Cuando cargo una página .js en la versión de escritorio de Wikipedia, no puedo pegar ni copiar texto"? ¿Existen circunstancias en las que pueda copiar y pegar en el escritorio? PrimeHunter ( charla ) 09:17, 10 de junio de 2021 (UTC)

@ PrimeHunter Normalmente, cuando edito en un dispositivo móvil en modo de escritorio (o modo móvil), puedo tocar dos o tres veces una palabra para resaltarla, y aparece una opción para copiar o pegar encima del texto seleccionado. Sin embargo, en las páginas .js, esto no sucede; la selección de texto se comporta de manera extraña, y en lugar de que aparezcan opciones sobre el texto seleccionado, aparece un cuadro '...', con múltiples opciones que no funcionan. - Qwerfjkl  | 𝕋𝔸𝕃𝕂 (utilice en la respuesta) 21:28, 10 de junio de 2021 (UTC)     {{reply to|Qwerfjkl}}

Oh, estás hablando de editar páginas js. Cargar una página js generalmente significa un comando de carga para ejecutar el script en la página. Intente hacer clic en el <>icono a la izquierda de la barra de herramientas para cambiar entre el editor normal y el editor de código. PrimeHunter ( conversación ) 21:37, 10 de junio de 2021 (UTC)

¡Gracias! - Qwerfjkl  | 𝕋𝔸𝕃𝕂 (utilizar en la respuesta) 14:57, 11 de junio de 2021 (UTC)     {{reply to|Qwerfjkl}}

Problema con la intersección principal en un artículo sobre una carretera

Eche un vistazo al condado de Dillon en "Intersecciones principales" en la autopista 38 de Carolina del Sur . Hay dos lugares llamados Oak Grove, Carolina del Sur. El que tenía un artículo antes de que agregara el del condado de Dillon tiene más gente y es obviamente más notable.— Vchimpanzee  • charla  • contribuciones  • 17:43, 6 de junio de 2021 (UTC)

Plantilla: Jctint # Parámetros , location_special. MarMi wiki ( charla ) 02:10, 7 de junio de 2021 (UTC)

Eso funciona. Gracias.— Vchimpanzee  • charla  • contribuciones  • 20:11, 7 de junio de 2021 (UTC)

Fredddie hizo esto .— Vchimpanzee  • charla  • contribuciones  • 15:52, 8 de junio de 2021 (UTC)

Familia de idiomas de Infobox

En el cuadro de información de los idiomas bantúes , la rama bantú del sur no aparece, aunque está presente en el código. Descubrí que el número de ramas que se pueden mostrar tiene un límite de 20 (algo de lo que no me había dado cuenta hasta ahora), y el parámetro "child21 =" da como resultado un mensaje de error interno. ¿Cuál es la mejor manera de lidiar con esta situación incómoda? - Florian Blaschke ( charla ) 19:16, 6 de junio de 2021 (UTC)

Podría haber agregado más entradas separadas por
en child20. Pero la idea de mostrar una lista de parámetros numerados parecía inútil, así que la reemplacé por un parámetro largo que contenía la lista. [4] Quizás la documentación de la caja de información debería sugerir esto. La lista es bastante larga para un cuadro de información, pero no es mi campo. PrimeHunter ( conversación ) 21:51, 6 de junio de 2021 (UTC)

¡Gracias! Una solución rápida en la que pensé después fue simplemente eliminar la primera entrada, que ni siquiera es una rama real, sino un enlace a la clasificación geográfica de Guthrie. Pero su solución también funciona y tiene la flexibilidad que estaba buscando. Acabo de recordar la solución similar empleada en las lenguas tibeto-birmanas . - Florian Blaschke ( charla ) 15:01, 7 de junio de 2021 (UTC)

Un redireccionamiento que va al artículo correcto de Wikipedia, pero al lugar equivocado dentro del artículo.

Después de una discusión en la casa de té , las dos personas que me ayudaron sugirieron que preguntara aquí. (Para obtener un resumen rápido de esa discusión, consulte el comentario del usuario: Ganbaruby del 6 de junio de 2021 ).

Aquí hay dos ejemplos (cada uno va a una ubicación incorrecta dentro del artículo de Wikipedia objetivo, pandemia de COVID-19 en Illinois ):

• Nombre de la sección especificado: La respuesta de la Universidad de Illinois en Urbana-Champaign a la pandemia de COVID-19 es una redirección que no termina cerca de la sección titulada "Respuesta de la Universidad de Illinois en Urbana-Champaign".
• Nombre de anclaje especificado: la respuesta de UIUC a la pandemia de COVID-19 es un redireccionamiento que no termina cerca del ancla titulada "UIUCresponse".

Usuario: Ganbaruby informó que el redireccionamiento que probó se comportó mal en Safari, pero funcionó correctamente en Chrome. (Todas mis pruebas fueron en Safari; lo siento: no sé cómo determinar qué versión de Safari estaba usando). CWBoast ( hablar ) 02:16, 7 de junio de 2021 (UTC)

Creo que puedo reproducirlo (en Chrome). Lo que me sucede si hago clic en uno de esos enlaces es que primero se desplaza a la ubicación correcta. Sin embargo, el enorme gráfico de barras con el número de casos ({{ datos de la pandemia COVID-19 / gráfico de casos médicos de Estados Unidos / Illinois }}) todavía está ampliado. Luego, en algún momento, algunos javascript lo colapsan y eso reformatea el texto, lo que mueve la sección de destino hacia arriba. - rchard2scout ( charla ) 07:33, 7 de junio de 2021 (UTC)

Esto se espera con el colapso automático y los plegables personalizados como los utiliza ese gráfico. Es una de las razones por las que tendemos a evitar su uso. - Th e DJ ( hablar • contribuciones ) 10:25, 7 de junio de 2021 (UTC)

MFA

¿Puedo configurar mi cuenta de Wikipedia para usar MFA? Idealmente, funcionaría como GitHub o NPM, donde puedo usar una aplicación móvil de autenticación y tener algunos códigos de recuperación que puedo usar en caso de que me roben el teléfono. Grillofrances ( charla ) 02:25, 7 de junio de 2021 (UTC)

Ver Ayuda: Autenticación de dos factores * Pppery * _{ha comenzado ...} 02:43, 7 de junio de 2021 (UTC)

Gracias, parece que solo algunos grupos de usuarios tienen 2FA disponible, por lo que necesito solicitar dicho acceso. En mi opinión, cada usuario debería poder configurar un 2FA y para los usuarios más privilegiados, incluso debería ser necesario. Grillofrances ( charla ) 23:13, 7 de junio de 2021 (UTC)

Sabemos. Aunque no estoy de acuerdo con la opinión, existe una opinión generalizada de que WMF 2FA es demasiado difícil de manejar.

Dicho esto, la razón de WMF para no tenerlo para todas las personas hoy en día es que no es fácil de arreglar si pierde la contraseña de su cuenta y sus códigos de cero y, en particular, requiere recursos humanos que tengan trabajos mejor pagados que tratar con un usuario así. . Izno ( charla ) 01:30, 8 de junio de 2021 (UTC)

Buscando diferencias?

¿Alguna sugerencia sobre cómo buscar las diferencias de una página? Por ejemplo, quiero saber si hay ediciones anteriores del Parlamento de Singapur que sean similares a Special: Diff / 1027141563 . - RoySmith (charla) 12:12, 7 de junio de 2021 (UTC)

Esto no es posible a primera vista, aunque ocasionalmente se solicita. (¿Quizás alguien ha construido o identificado una herramienta en Toolforge desde la última vez?) Izno ( charla ) 12:41, 7 de junio de 2021 (UTC)

Podría intentar usar WikiBlame , que podría encontrar cosas que permanecieron en el artículo por un tiempo antes de ser eliminadas, pero honestamente dudo que haga un trabajo particularmente bueno. Sin embargo, puede valer la pena intentarlo. -  Rummskartoffel ( charla  • contribuciones ) 12:56, 7 de junio de 2021 (UTC)

• De hecho, comencé a trabajar en una herramienta de este tipo hace años. Me detuve debido a dificultades para analizar las páginas de diferencias, pero recientemente terminé de trabajar en una herramienta diferente que podría resolver ese problema. Si puedo hacerlo funcionar, me aseguraré de publicar un aviso aquí y en algunos otros lugares. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 13:21, 7 de junio de 2021 (UTC)

  MPants en el trabajo , Genial. Hazme ping si consigues que funcione. Escuché lo difícil que es analizar las diferencias. - RoySmith (charla) 13:30, 7 de junio de 2021 (UTC)

  RoySmith , lo haré con una condición: escríbeme un mensaje diciendo esto en mi página de discusión para que no lo olvide. ᛗᛁᛟᛚᚾᛁᚱ Pantalones Cuéntamelo todo. 13:45, 7 de junio de 2021 (UTC)

• @ RoySmith : el que son componentes similares va a ser un tramo muy largo. Si solo desea buscar una frase o cadena, puede usar Especial: Exportar para exportar todas las revisiones de la página, luego use una herramienta de búsqueda de texto en el archivo de salida. (Limitado a 1000 revisiones). - ^Charla xaosflux 14:14, 7 de junio de 2021 (UTC)

Redireccionamiento extraño

Seguimiento en Phabricator
Task T8151

¿Alguien sabe lo que está pasando aquí ? Parece un intento de crear una redirección a una página de conversación centralizada, pero el "../" no es algo que haya visto antes y no funciona actualmente. {{u | Sdkb }}  ^charla 17:58, 7 de junio de 2021 (UTC)

Mmm. Me está funcionando. Sin embargo, tampoco he visto este atajo antes. - Florian Blaschke ( charla ) 18:24, 7 de junio de 2021 (UTC)

Es un enlace de subpágina (o más bien un enlace de página principal en este caso). Debería funcionar, pero parece que se debe a un error, las redirecciones como si no hubieran funcionado desde al menos 2006, consulte phab: T8151 . - Brandon XLF ( charla ) 18:30, 7 de junio de 2021 (UTC)

Realmente me pregunto por qué me funciona entonces, tanto en Firefox como en Opera. - Florian Blaschke ( charla ) 01:38, 9 de junio de 2021 (UTC)

Se corrigió simplemente declarando explícitamente el objetivo. - ^Charla xaosflux 10:46, 8 de junio de 2021 (UTC)

Noticias tecnológicas: 2021-23

Últimas noticias tecnológicas de la comunidad técnica de Wikimedia. Informe a otros usuarios sobre estos cambios. No todos los cambios te afectarán. Hay traducciones disponibles.

Cambios a finales de esta semana

• La nueva versión de MediaWiki estará en wikis de prueba y MediaWiki.org a partir del 8 de junio. Estará en wikis que no sean de Wikipedia y en algunas Wikipedias a partir del 9 de junio. Estará en todas las wikis a partir del 10 de junio ( calendario ).

Cambios futuros

• El movimiento Wikimedia utiliza Phabricator para tareas técnicas. Aquí es donde recopilamos sugerencias técnicas, errores y en qué están trabajando los desarrolladores. La empresa detrás de Phabricator dejará de trabajar en ello. Esto no cambiará nada para el movimiento Wikimedia ahora. Podría dar lugar a cambios en el futuro. [5] [6] [7]
• Si busca en Wikipedia encontrará más resultados en algunos idiomas. Esto es cierto principalmente cuando quienes buscan no usan los signos diacríticos correctos porque no se los considera necesarios en ese idioma. Por ejemplo, al buscar Beduszno se encuentra Będuszen la Wikipedia en alemán. El carácter ęno se usa en alemán, por lo que muchos escribirían en su elugar. Esto funcionará mejor en el futuro en algunos idiomas. [8]
• Los parámetros del token CSRF en la API de acción se cambiaron en 2014. Los parámetros anteriores de antes de 2014 dejarán de funcionar pronto. Esto puede afectar a los bots, gadgets y scripts de usuario que aún usan los parámetros antiguos. [9] [10]

Noticias de tecnología preparadas por los redactores de Tech News y publicadas por bot  • Contribuir  • Traducir  • Obtener ayuda  • Dar comentarios  • Suscribirse o darse de baja .

20:01, 7 de junio de 2021 (UTC)

La mejor forma de monitorizar la herramienta Categoría: ¿Solicitudes de desbloqueo ?

Estoy haciendo una herramienta para monitorear Categoría: Solicitudes de desbloqueo . Miré el feed de IRC pero no parece monitorear las adiciones y eliminaciones de categorías.

En este momento estoy usando la API para preguntar por sus miembros cada pocos minutos, pero sería mejor si pudiera obtener un feed, ya que prefiero no molestar demasiado a la API. ¿Alguien conoce una mejor manera de monitorear las adiciones y eliminaciones de una categoría? HighInBC ¿ ^{Necesita ayuda? Solo pregunta.} 02:44, 8 de junio de 2021 (UTC)

Anomie probablemente hace cosas similares para las colas de solicitudes de edición protegidas. Izno ( charla ) 04:20, 8 de junio de 2021 (UTC)

AnomieBOT solo consulta periódicamente todas las páginas de las categorías. Anomie ⚔ 11:35, 8 de junio de 2021 (UTC)

¿ Podría ayudarlo mi CatChangesViewer ? También, obviamente, puede ver la categoría para monitorear adiciones / eliminaciones, aunque imperfecta (para lo cual escribí otro script ). Nardog ( charla ) 04:30, 8 de junio de 2021 (UTC)

MediaWiki en sí puede mostrarle adiciones de categorías, consulte mw: Manual: CategoryMembershipChanges . Está encendido en todos los sitios de WMF .-- Snævar ( charla ) 09:18, 8 de junio de 2021 (UTC)

@ HighInBC : entonces, si está "haciendo una herramienta", ¿no puede su herramienta simplemente consultar la categoría? La otra opción mencionada anteriormente involucra la lista de seguimiento. Una cosa que podría intentar sería crear otra cuenta, agregar esas categorías a la lista de seguimiento de esa cuenta y luego usar la fuente RSS de la lista de seguimiento para esa cuenta para ver los cambios. - ^Charla xaosflux 10:38, 8 de junio de 2021 (UTC)

Estoy consultando la categoría en este momento. Interesante idea sobre la lista de seguimiento. En este momento no está usando una cuenta, ya que es de solo lectura. Pero esa es una buena idea. Gracias. HighInBC ¿ ^{Necesita ayuda? Solo pregunta.} 10:48, 8 de junio de 2021 (UTC)

@ HighInBC : consulte Wikipedia: Syndication # Watchlist_feed_with_token para obtener más información al respecto, ya que no tendrá que preocuparse por las cosas de "autenticación" normales necesarias para iniciar sesión con una cuenta mediante programación para este caso. - ^Charla xaosflux a las 11:02, 8 de junio de 2021 (UTC)

Oh, eso es genial. Gracias por esa información. HighInBC ¿ ^{Necesita ayuda? Solo pregunta.} 11:05, 8 de junio de 2021 (UTC)

Sí, eso es perfecto. Puedo proporcionar ese token a la API y la marca de tiempo de mi último control y obtener una actualización completa en una sola llamada. Ya no tengo que almacenar el estado anterior para comparar y averiguar qué ha cambiado. Gracias y gracias a todos los que dieron sus consejos. HighInBC ¿ ^{Necesita ayuda? Solo pregunta.} 11:15, 8 de junio de 2021 (UTC)

@ Xaosflux : Pero como puede ver en la URL, ¿un feed no es esencialmente una llamada a la API devuelta en Atom XML en lugar de JSON? No puedo imaginar que sea menos costoso para el servidor que las llamadas API más simples que no requieren tokens. Nardog ( charla ) 13:43, 8 de junio de 2021 (UTC)

@ HighInBC : ¡Oh, estás haciendo una herramienta! Siento haberme ido. Puede que todavía esté predicando al coro, pero: AFAIK, hay dos formas básicas: list = Recentchanges pueden darle las ediciones específicas que causaron adiciones / eliminaciones, pero está limitado a los últimos 30 días y no detecta cambios por medio de transclusiones. ; list = categorymembers no tiene esas limitaciones, pero solo le brinda adiciones, no eliminaciones, y solo marcas de tiempo, no revisiones. Nardog ( charla ) 12:08, 8 de junio de 2021 (UTC)

@ HighInBC : La API de Wikimedia EventStream muestra tanto las adiciones como las eliminaciones de categorías. Es un flujo (por lo tanto, hace que su herramienta realmente funcione en tiempo real, en lugar de cada 10 minutos aproximadamente), y no requiere autenticación o análisis de XML atom. - SD0001 ( conversación ) 03:32, 9 de junio de 2021 (UTC)

Gracias, estaba buscando una solución en tiempo real en lugar de realizar una encuesta. Esto es muy útil. He aprendido mucho de este hilo. HighInBC ¿ ^{Necesita ayuda? Solo pregunta.} 04:04, 9 de junio de 2021 (UTC)

@ SD0001 : Perfecto, y solo 27 líneas de código: Usuario: HighInBC / Category unblock watcher.pl . HighInBC ¿ ^{Necesita ayuda? Solo pregunta.} 05:30, 9 de junio de 2021 (UTC)

Seguimiento de nuevas imágenes en un amplio árbol de categorías

Hola,

Soy un biólogo marino especializado en Echinodermata . Me gustaría estar informado de cualquier imagen nueva de estos animales para poder revisar la identificación y, cuando sea útil, agregarlos a los artículos relevantes de Wikipedia. Pero como hay más de 7000 especies de, por supuesto, no puedo comprobar todas las categorías todos los días. Solía ​​beneficiarme del suministro de noticias de Ogrebot durante un tiempo útil y prolongado, pero ya no funciona. ¿Saben de alguna otra manera en la que pueda obtener un suministro de noticias así? (sabiendo que no soy un hacker).

Gracias y un saludo,

FredD ( charla ) 07:22, 8 de junio de 2021 (UTC)

Esta es básicamente la misma pregunta que la "Mejor manera de monitorear la Categoría: Solicitudes de desbloqueo", por lo que se aplican las mismas respuestas .-- Snævar ( hablar ) 09:20, 8 de junio de 2021 (UTC)

Anular la sangría, ya que esto quiere un árbol de categorías recursivo completo. - ^Charla xaosflux 10:35, 8 de junio de 2021 (UTC)

@ FredD : ¿la mayoría de estos archivos nuevos no están realmente aquí, sino en los comunes? - ^Charla xaosflux 10:42, 8 de junio de 2021 (UTC)

No estoy seguro de entender lo que quieres decir, Snævar . Xaosflux , es para imágenes que aún no están en los comunes pero que se agregarán en el futuro. Quiero saber cuándo las personas las agregan, para poder revisarlas y usarlas. Gracias ! FredD ( charla ) 11:38, 8 de junio de 2021 (UTC)

@ FredD : si desea que alguien más cree un bot para hacer un informe de este tipo por usted, puede preguntar en WP: BOTREQ . Saludos cordiales, - xaosflux ^Talk 13:33, 8 de junio de 2021 (UTC)

Ok, intentaré esto. Gracias ! FredD ( charla ) 14:01, 8 de junio de 2021 (UTC)

action = proteger con campos precargados?

Resuelto  : información proporcionada. - ^Charla xaosflux 14:29, 9 de junio de 2021 (UTC)

¿Hay alguna forma de crear una URL que lo lleve a la pantalla "Cambiar protección", pero con campos precargados? Puede hacerlo con el usuario de bloqueo, a través de Special: Block , es decir, esto , pero por lo que puedo decir en el manual de wikimedia , no hay una versión de eso para la protección de la página. Lo que espero hacer es poder tener un script que cree un enlace en el que puede hacer clic para llevarlo a un formulario previamente completado, que solo tiene que revisar y hacer clic en el botón "Confirmar". Sé que puedo hacerlo directamente a través de la API, pero si puedo hacerlo con un enlace en el que se puede hacer clic, sería preferible. - RoySmith (charla) 14:00, 8 de junio de 2021 (UTC)

@ RoySmith Los parámetros de URL deben coincidir con el nameatributo de los campos de entrada. Puede inspeccionar el DOM para ver cuáles son. Esta técnica debería funcionar en la mayoría de los formularios de MediaWiki. Aquí hay un ejemplo que afecta a casi todos los campos: [11] . - MusikAnimal ^talk 16:24, 8 de junio de 2021 (UTC)

MusikAnimal , Ah, genial. Gracias. Supongo que eso es lo que los documentos quieren decir con "Esta página es una lista parcial de los parámetros" :-) - RoySmith (hablar) 16:41, 8 de junio de 2021 (UTC)

¿Error en "Buscar ediciones por usuario"?

¿Bicho? El enlace "500 resultados siguientes →" en https://sigma.toolforge.org/usersearch.py?name=50.201.195.170+&page=Talk%3AWuhan_Institute_of_Virology&server=enwiki&max= no funciona. Σ lo ejecuta? (Conduce a https://sigma.toolforge.org/usersearch.py?startdate=None&name=50.201.195.170+&page=Talk%3AWuhan_Institute_of_Virology&server=enwiki&max=500 que conduce a sí mismo. Comenzó aquí .) - 50.201.195.170 ( hablar ) 23:50, 8 de junio de 2021 (UTC)

Como señaló, esto no es parte de la Wikipedia en inglés, y puede hacer un seguimiento en Charla de usuario: Σ . - ^Charla xaosflux 00:08, 9 de junio de 2021 (UTC)

¿Alguien sabe por qué esto no es parte de la interfaz de usuario estándar? Es parte de la API, consulte https://en.wikipedia.org/w/api.php?action=query&titles=Talk%3AWuhan_Institute_of_Virology∝=revisions&rvuser=50.201.195.170&rvlimit=500 . Entonces, ¿por qué necesitamos una herramienta externa para producir resultados legibles por humanos? Suffusion of Yellow ( charla ) 00:33, 9 de junio de 2021 (UTC)

Interesante pregunta. El resultado de la API nativa sugiere que usersearch.py ​​está más dañado; encuentra 0 ediciones, en lugar de las muchas que la API encuentra en las últimas 500 revisiones. ¿También un error? (Es "parte de la Wikipedia en inglés", xaosflux, en el sentido de que la herramienta está vinculada desde cada página como esa donde dije que comencé, aunque en toolforge.org. ¿Entonces? Puedo seguir su charla si @ Σ : no responde al ping y / o otros pueden ayudar. Por ejemplo, si estoy confundido y estos no son errores.) - 50.201.195.170 ( hablar ) 02:12, 9 de junio de 2021 (UTC)

50, enlazamos a muchas herramientas externas, pero nosotros (los editores y administradores de wikipedia) no las mantenemos. Si está roto hasta el punto de ser inútil, podemos eliminar el enlace externo de la interfaz o cambiarlo a otra cosa, pero en realidad no podemos hacer nada para evitar que se rompa más que si el RIR se vincula en la parte inferior de su La página de discusión tuvo un error: no tenemos acceso al código base de esa herramienta, solo su responsable. La eliminación o reemplazo se puede discutir en el mensaje asociado aquí: Charla de MediaWiki: Histlegend . - ^Charla xaosflux 10:26, 9 de junio de 2021 (UTC)

Las personas que los mantienen a menudo miran esta página o saben cuál es el problema, cómo solucionarlo o ofrecen alternativas. Creo que este es un lugar perfectamente aceptable. Debido a que vi esta discusión, cambié MediaWiki: Histlegend para que apunte a lo que debería ser una herramienta completamente funcional (divulgación, escrita por el tuyo). - ^Charla MusikAnimal 22:57, 10 de junio de 2021 (UTC)

Usuario: Ale jrb / Scripts / userhist.js también proporciona esta función como un script de usuario integrado en special: contribs , aunque la interfaz de usuario está un poco desactualizada. - SD0001 ( conversación ) 03:33, 9 de junio de 2021 (UTC)

¿Alguien encontró los 2 errores reproducibles (o no reproducibles)? Supongo que sí, pero no veo a nadie mencionando una forma u otra. - 50.201.195.170 ( conversación ) 23:14, 9 de junio de 2021 (UTC)

Esta característica funciona bien en XTools: https://xtools.wmflabs.org/topedits/en.wikipedia.org/50.201.195.170/1/Wuhan_Institute_of_Virology . He cambiado MediaWiki: Histlegend para señalarlo por el momento. - ^Charla MusikAnimal 22:54, 10 de junio de 2021 (UTC)

Hasta hace poco, no había forma de buscar ediciones por direcciones IP. En algún momento esto se hizo posible, pero simplemente nunca pude implementarlo. → Σ σ ς . ( Sigma ) 10:00, 11 de junio de 2021 (UTC)

Las direcciones IP tienen ID de actor al igual que las cuentas, por lo que si lo hace, debería ser la misma consulta tanto para las direcciones IP como para las cuentas. Si desea consultar rangos de IP (para los que XTools agregó soporte recientemente, pero ha sido técnicamente posible desde fines de 2017), entonces eso requiere una consulta diferente. ¿El código fuente está publicado en algún lugar? Estoy feliz de poder ayudar. - ^Charla MusikAnimal 17:21, 11 de junio de 2021 (UTC)

¿Cambiar en "Buscar ediciones por usuario"?

Hoy, hacer clic en "Buscar ediciones por usuario" me lleva a una nueva interfaz de usuario en xtools.wmflabs.org. Era diferente hasta ayer. ¿Hay algún aviso o discusión sobre esto? ¿Cómo puedo eliminar los gráficos circulares que aparecen en esa página? No pude encontrar una manera de ver un resultado personalizado, incluso después de iniciar sesión en ese sitio. O, ¿cómo puedo volver a la interfaz anterior? - Jay ^Talk 13:02, 11 de junio de 2021 (UTC)

Véase más arriba. - Izno ( conversación ) 13:51, 11 de junio de 2021 (UTC)

Lo había visto antes y no sabía que estaba relacionado con mi consulta. ¿Cómo se relaciona con mi consulta? ¿Lo que ha sucedido? - Jay ^Talk 14:13, 11 de junio de 2021 (UTC)

Ok, entonces la herramienta anterior se llamaba WikiBlame y está rota, ¿y xtools es un reemplazo temporal? ¿Y esta discusión es el lugar donde podemos obtener actualizaciones sobre esto? - Jay ^Talk 14:30, 11 de junio de 2021 (UTC)

WikiBlame es una herramienta completamente diferente y todavía se puede acceder a través de "Buscar adición / eliminación". Nardog ( charla ) 14:42, 11 de junio de 2021 (UTC)

¿Qué le acaba de pasar a Watchlist?

Hace cinco minutos, mi lista de vigilancia se veía como siempre. ¿Es mi imaginación, o los cuadros verdes cuadrados a la izquierda son nuevos (parece que en los últimos 5 minutos)? Algunos son verdes. Algunos son del mismo color azul de siempre. Me acerqué y miré mi lista de seguimiento de Commons, y las pequeñas cajas a la izquierda son todas del mismo color azul. No estoy seguro de qué se supone que significa el color verde. Al hacer clic en cualquier color de ellos, no cambia el color. Entonces, ¿cuál es el propósito? - Maile ( conversación ) 23:08, 9 de junio de 2021 (UTC)

Los verdes no son leídos, los azules son los que ha mirado. -  JohnFromPinckney ( charla / ediciones ) 23:11, 9 de junio de 2021 (UTC)

Es posible que haya habilitado accidentalmente "Mostrar flechas verdes plegables y viñetas verdes para las páginas cambiadas en su lista de seguimiento, historial de páginas y cambios recientes (no disponible con la interfaz de usuario mejorada de la lista de seguimiento)" en las Preferencias. Nardog ( charla ) 23:15, 9 de junio de 2021 (UTC)

Sí, eso fue todo, comprobado en Preferencias. Gracias. - Maile ( conversación ) 23:24, 9 de junio de 2021 (UTC)

@ Maile66 : No es nuevo, ver por ejemplo Wikipedia: Bomba de pueblo (propuestas) / Archivo 103 # Marcadores de "Actualizado desde la última visita" de hace ocho años. - Red Rose64 🌹 ( talk ) 23:28, 9 de Junio 2021 (UTC)

Sí, vi en Preferencias que no era nuevo. Pero algo en el mío hizo que de repente se destacara, hasta el punto de ser molesto. Quizás una fuente o algo más actualizado en mi sistema para causarlo. Mis navegadores, Firefox y Chrome, lo mostraron de la misma manera. - Maile ( conversación ) 23:35, 9 de junio de 2021 (UTC)

@ Redrose64 y Nardog : Creo, quizás, por qué esto me llamó la atención de repente. Y tal vez esto cambió. He estado mirando mi lista de vigilancia en Commons y Wikisource. Ambos tienen las cajas cuadradas verde y azul, pero me parecen normales. La diferencia: ambos muestran el tiempo de edición a la derecha del nombre de la página editada. El que está aquí en Wikipedia lo muestra a la izquierda del nombre de la página, entre los cuadros y el nombre del artículo, creando lo que parece un espacio más amplio entre los cuadros y el resto. O tal vez sea mi imaginación, pero esa parece ser la diferencia para mí. - Maile ( conversación ) 00:52, 10 de junio de 2021 (UTC)

Gatos visibles en la vista móvil para usuarios móviles

Hola, probablemente solo mi dispositivo, o hay otros usuarios móviles que experimenten categorías visibles (en forma de bloque) mientras están en la vista móvil ? ¿Hay alguna manera de hacer yo mismo para remediar esto? Celestina007 ( charla ) 20:34, 10 de junio de 2021 (UTC)

WP: ES JUEVES , creo. Esto parece ser intencional y funciona según lo diseñado, como el primer paso de un cambio en la visualización de la categoría móvil. Consulte T246049 , que parece haber cambiado la vista móvil para mostrar categorías. Puede ir seguido de T152199 , que pretende hacerlos plegables.

Este cambio parece haber sido anunciado como parte de la lista, a menudo inescrutable, de actualizaciones vinculadas a las noticias tecnológicas anteriores (y siempre se publica mucho después de las noticias tecnológicas, por lo que debe recordar consultar el enlace en algún momento después de la publicación de las noticias tecnológicas). Consulte mw: MediaWiki 1.37 / wmf.9 # MinervaNeue para obtener la descripción de este cambio.

No siempre soy bueno para seguir las migas de pan de phab / gerrit / WMF, y nunca soy bueno para entender por qué trabajan en estas cosas complicadas en lugar de corregir errores reales, por lo que podría tener algo de esto mal. - Jonesey95 ( conversación ) 20:54, 10 de junio de 2021 (UTC)

Este cambio elimina el antiguo componente que solía hacer categorías en dispositivos móviles, que tenía media docena de errores abiertos asociados. Entonces ... sí, solucionó errores reales. Izno ( charla ) 21:09, 10 de junio de 2021 (UTC)

E incluso puede habilitar gadgets de categorías. Izno ( charla ) 21:09, 10 de junio de 2021 (UTC)

Puede ocultarlo completamente agregando a su minerva.css . -  Rummskartoffel ( charla  • contribuciones ) 21:02, 10 de junio de 2021 (UTC) #catlinks {display: none;}

Jonesey95 , Rummskartoffel , Izno gracias, creo que probablemente optaría por ocultarlo (si no se traduce en que también sea invisible en la vista de escritorio ). Los codificadores / creadores de scripts y todos los editores de plantillas en general están dotados. Este aspecto de la edición simplemente me abruma. Celestina007 ( charla ) 21:19, 10 de junio de 2021 (UTC)

minerva.css solo afecta la máscara del móvil, por lo que aún verá categorías en la versión de escritorio. -  Rummskartoffel ( charla  • contribuciones ) 21:26, 10 de junio de 2021 (UTC)

@ Rummskartoffel , mil millones de gracias amigo. Celestina007 ( charla ) 22:26, ​​10 de junio de 2021 (UTC)

¿Es la función global de Lua typeefectivamente anulable?

Así que hice una función en el Módulo: clase Lua (última función) que intenta anular / construir sobre el valor predeterminado typepara admitir nuevos "tipos". Lo estaba probando en Usuario: Alexiscoutinho / sandbox 1 y noté que se comporta de manera diferente si está obteniendo una vista previa. Cuando ve la caja de arena normalmente, debe contener "tabla tabla tabla". Sin embargo, si obtiene una vista previa de la página (sin modificaciones, por supuesto), ahora contendrá "instancia base de clase" (lo que se desea). Que esta pasando? ¿Por qué la typefunción se comporta de manera diferente? Alexiscoutinho ( charla ) 21:33, 10 de junio de 2021 (UTC)

Si bien OOP es genial, no estoy seguro de que valga la pena la confusión de otra capa. Sin embargo, purgué Usuario: Alexiscoutinho / sandbox 1 y ahora muestra "instancia de clase Base", lo mismo que en la vista previa. Johnuniq ( charla ) 00:21, 11 de junio de 2021 (UTC)

¡Muchas gracias! Olvidé por completo cómo purgar completamente una página. Además, pensé que la depuración era solo del lado del cliente, por lo que me sorprendí bastante cuando el problema persistió en una pestaña anónima. Alexiscoutinho ( charla ) 01:13, 11 de junio de 2021 (UTC)

Hacer que los enlaces entre proyectos se abran en una nueva pestaña

¿Hay alguna forma de hacer enlaces a wikipedias, commons, wiktionary, etc. de otros idiomas, abiertos en una nueva pestaña? A veces olvido que no se comportan como enlaces externos normales y es molesto. DuncanHill ( charla ) 00:59, 11 de junio de 2021 (UTC)

Debe haber habilitado "Abrir enlaces externos en una nueva pestaña o ventana" en Especial: Preferencias # mw-prefsection-gadgets . No es predeterminado. No sé cómo extenderlo a enlaces interwiki. PrimeHunter ( charla ) 01:19, 11 de junio de 2021 (UTC)

Requerirá un poco de javascript. @ DuncanHill Puede hacerlo agregando $(function() { $('.extiw').attr('target', '_blank'); });a special: mypage / common.js . - SD0001 ( conversación ) 04:20, 11 de junio de 2021 (UTC)

Mantenga presionada la tecla Comando (Mac) o Ctrl (Windows / Linux) mientras hace clic en el enlace. - Jonesey95 ( conversación ) 06:21, 11 de junio de 2021 (UTC)

exactamente, la forma más fácil de hacerlo y funciona en cualquier sitio web. - Th e DJ ( hablar • contribuciones ) 07:39 11 de Junio de 2021 (UTC)

de hecho, pero pensé que era obvio y DuncanHill estaba buscando una solución automatizada. - SD0001 ( conversación ) 10:39, 11 de junio de 2021 (UTC)

No son enlaces externos, son internos dentro de Wikimedia. Mike Peel ( charla ) 10:57, 11 de junio de 2021 (UTC)

google: no parece un enlace externo, pero lo es. Gran parte del mapa de m: Interwiki es realmente externo. - Kusma ( charla ) 12:07, 11 de junio de 2021 (UTC)

Extraño, no sabía que era posible (ni entiendo * por qué * es posible) pero ninguno de los ejemplos anteriores era externo. Mike Peel ( charla ) 12:47, 11 de junio de 2021 (UTC)

Tradicionalmente, la mayoría de los otros sitios web que tenían prefijos interwiki especiales eran otros wikis u otros sitios de contenido gratuito, con algunos otros sitios como Google incluidos por conveniencia. La principal diferencia entre los enlaces de mapas de interwiki y los enlaces externos normales (distintos del estilo) es que los enlaces de mapas de interwiki no tienen el atributo "nofollow". (Una vez me molestó tanto la publicidad de Wikia / Fandom que trabajé un poco para activar "nofollow" para los enlaces que van allí). - Kusma ( conversación ) 13:04, 11 de junio de 2021 (UTC)

@ SD0001 : Gracias, eso ciertamente funciona para commons, wikiquote, etc., no funciona para los enlaces entre idiomas en el lado izquierdo. @ Jonesey95 : y @ TheDJ : en realidad, lo que uso es hacer clic derecho y abrir en una nueva pestaña, pero como mencioné, a veces lo olvido, y @ Mike Peel : pueden o no ser externos, pero se comportan como enlaces externos en el sentido de que el las preferencias que establezco aquí no se aplican allí, y cosas como las plantillas que funcionan aquí no funcionan allí. De todos modos, gracias a todos. DuncanHill ( charla ) 16:30, 11 de junio de 2021 (UTC)

@ DuncanHill Cambie '.extiw'a '.extiw .interlanguage-link-target'para cubrirlos también. - SD0001 ( conversación ) 16:37, 11 de junio de 2021 (UTC)

@ SD0001 : Eso no parece hacer nada, y también impide que funcione para los bienes comunes, etc. DuncanHill ( charla ) 16:45, 11 de junio de 2021 (UTC)

@ DuncanHill oops, necesitaba una coma entre: '.extiw, .interlanguage-link-target'- SD0001 ( hablar ) 16:52, 11 de junio de 2021 (UTC)

¡Bingo! @ SD0001 :, esto será de gran ayuda para mí, muchas gracias. DuncanHill ( charla ) 16:55, 11 de junio de 2021 (UTC)

¿La imagen PNG de 2gb de la NASA es demasiado grande para Commons?

PREGUNTAS: Intenté cargar una imagen PNG reciente de 2gb de la NASA (en " https://photojournal.jpl.nasa.gov/archive/PIA24663_fullres.png " en NASA-page => " https://photojournal.jpl.nasa.gov/ catalog / PIA24663 ") (toma un tiempo - ~ 1 hora /?) - pero Commons no pareció aceptarlo por alguna razón - ¿el tamaño del archivo de imagen es demasiado grande para Wikipedia? - ¿Hay alguna solución? - la imagen parece relevante para varios artículos de la NASA (es decir, " Perseverance (rover) ", " Timeline of Mars 2020 " y posiblemente más) - el archivo de imagen descargado se abre correctamente en mi navegador Firefox (Wintel10 / Firefox / DellXPS8900) - iac - Gracias en avance para obtener una respuesta - ¡Manténgase sano y salvo! - Drbogdan ( conversación ) 11:41, 11 de junio de 2021 (UTC)

@ Drbogdan : c: Commons: el tamaño máximo de archivo puede ser útil. Elli ( charla | contribuciones ) 11:43, 11 de junio de 2021 (UTC)

"toma un tiempo" lol .. usted no dice .. 2 GB ... - Th ae DJ ( talk • contribuciones ) 12:58 11 de junio de 2021, (UTC)

@Drbogdan, a menos que alguien quiera contar la cantidad de granos de arena en Marte, no veo por qué las dimensiones de la imagen no se reducirían en 4 y la imagen se guardaría como jpg, como lo hicieron aquí https: // photojournal .jpl.nasa.gov / jpeg / PIA24663.jpg , tamaño de archivo 15 MB (enlace que se encuentra aquí ). Aquellos que realmente necesitan la imagen de 2.400 millones de píxeles siempre pueden volver a la NASA. Ponor ( charla ) 14:19, 11 de junio de 2021 (UTC)

FWIW - parece - * Perserverance at Van Zyl (AVideo360; 1:40; Spring 2021) en YouTube ( sitio relacionado ; imagen PNG de 2GB ) - agregado a " Timeline of Mars 2020 # External links " puede ser suficiente por ahora - Gracias por todos los comentarios anteriores - ¡Manténgase seguro y saludable! - Drbogdan ( conversación ) 14:58, 11 de junio de 2021 (UTC)

Consolidar los lugares de ayuda

Movido de Wikipedia: Bomba de pueblo (política)

AFAICS, tenemos algunos lugares de ayuda primaria para preguntas de naturaleza general:

• WP: Casa de té
• WP: mesa de ayuda
• Wikipedia: ayuda del editor (inactivo)
• Wikipedia: asistencia del editor / solicitudes

No sé exactamente cuál es la diferencia entre Teahouse y Help desk (en esta discusión de MP, otros editores plantearon este punto), posiblemente el primero se considere útil para los principiantes y el segundo para los editores experimentados. Aunque examiné la Casa de té y la HD, realmente no tengo la impresión de que sean realmente distintas en cuanto a las preguntas que se hacen. Más importante aún, mi sensación es que Wikipedia: la asistencia del editor probablemente debería redirigirse a algún lugar, ya que ese lugar está completamente inactivo y en su mayoría se remonta a antes de 2011, y WP: EAR probablemente debería redirigirse a Teahouse o al servicio de asistencia técnica, ya que no lo hace. No parece tener ninguna característica distintiva de ninguno de los dos. ProcrastinationReader ( charla ) 16:10, 20 de abril de 2021 (UTC)

• Los dos últimos son AFAIK en su mayoría o en su totalidad históricos. The Teahouse es para lo más nuevo de lo nuevo. La mesa de ayuda es generalmente para preguntas más complicadas, pero no desagradable para las personas que terminan allí en lugar de THQ. G M G ^talk 16:13, 20 de abril de 2021 (UTC)
• En términos generales, Teahouse está diseñado para nuevos usuarios, que no están familiarizados con Wikipedia, su cultura y su jerga, mientras que el Help Desk está diseñado para personas que están más familiarizadas con Wikipedia en general. Lo que no quiere decir que funcione el 100% del tiempo, pero en general así es como se supone que funciona. Como resultado, una persona que responda una pregunta en la mesa de ayuda se sentiría libre de usar atajos, remitir a las personas a documentos técnicos y usar wikijargon para responder preguntas allí; sin embargo, se supone que Teahouse presume que el OP no sabría nada de eso, y se esfuerza por tratar a los usuarios como si necesitaran que los sostuvieran de la mano durante el proceso, y los respondedores deben adoptar un tono en su respuesta de que están tratando con novatos de Wikipedia. ¿Quién no sabría cómo leer un documento de espacio de nombres de Wikipedia, qué es un diff, o qué significa cualquiera de los términos d'art que usamos en la conversación diaria en Wikipedia? Necesitamos estos dos servicios de ayuda para mantener esa distinción disponible. EAR ha estado moribundo durante mucho tiempo, y estoy realmente sorprendido de ver que desde entonces no se ha marcado como histórico. - Jayron 32 16:16, 20 de abril de 2021 (UTC)
• La página de asistencia del editor no es un lugar en sí mismo, sino un lugar para encontrar un ayudante dispuesto específico. Sin embargo, estoy de acuerdo en que las mesas de ayuda son un buen lugar para encontrar un editor útil y establecer una conexión personal. isaacl ( charla ) 16:54, 20 de abril de 2021 (UTC)
• Estoy de acuerdo en que los dos últimos parecen históricos. En cuanto a la diferencia entre los dos primeros, es algo que también me preguntaba cuando trabajaba en el usuario: Levivich / Help , que es mi intento prototipo de consolidar nuevas páginas de ayuda para usuarios. Levivich  ^acoso / _sabueso 17:25, 20 de abril de 2021 (UTC)

debate sobre el lugar resuelto
@ ProcrastinationReader : Me falta qué política o directriz busca crear o enmendar; tal vez un lugar diferente sería más apropiado para esto. - Charla xaosflux 17:34, 20 de abril de 2021 (UTC) Creo que tenía la intención de publicar esto en VPR (me acabo de dar cuenta de que está en la bomba de políticas). Me moveré. ProcrastinationReader ( charla ) 17:37, 20 de abril de 2021 (UTC)

• ¿Tenemos un buen mapeo de los ingresos a cada uno de estos procesos que pueden necesitar ajustes? - ^Charla xaosflux 19:08, 20 de abril de 2021 (UTC)
• Creo que nuestros ayudantes son más que capaces de determinar qué nivel de ayuda brindar a los usuarios. Creo que combinar la mesa de ayuda y la casa de té podría ser un giro útil de los acontecimientos. A los usuarios experimentados no les debería importar, y los nuevos usuarios estarán menos confundidos. Tenemos tantas páginas posibles para nuevos usuarios, la consolidación es clave para la accesibilidad. Realmente tenemos que pensar mucho en cómo facilitar la incorporación de nuevos usuarios. En una nota al margen, llamarlo Teahouse me resulta confuso. Ojalá se llamara simplemente "mesa de ayuda", que se explica por sí mismo, pero debería conservar las normas culturales de Teahouse. AdmiralEek ( charla ) 23:29, 20 de abril de 2021 (UTC)

  Además, anunció esto en las páginas de discusión de TH y HD. AdmiralEek ( charla ) 23:33, 20 de abril de 2021 (UTC)

• Planeando agregar algunos comentarios más sustantivos más adelante, pero la gente podría querer echar un vistazo a Morgan, Jonathan T .; Halfaker, Aaron (22 de agosto de 2018). "Evaluación del impacto de la casa de té de Wikipedia en la socialización y retención de recién llegados" . Actas del 14º Simposio Internacional sobre Colaboración Abierta : 1–7. doi : 10.1145 / 3233391.3233544 .. Tiene alguna evidencia empírica útil sobre lo que hace Teahouse, así como una explicación de sus objetivos en contraposición a Teahouse. Vahurzpu ( charla ) 05:54, 21 de abril de 2021 (UTC)
• Apoyo mantener la Casa de té y la mesa de ayuda separados, ya que tengo la mesa de ayuda en la lista de vigilancia y ocasionalmente contribuyo, pero me resultaría oneroso seguir la guía de la Casa de té y explicar cada proceso de Wikipedia en mis propias palabras en lugar de vincularlo al proceso y responder a cualquier seguimiento. hasta preguntas. La mesa de ayuda tiene un enlace destacado a la casa de té y la página de la casa de té probablemente debería tener un enlace similar a la mesa de ayuda. Probablemente, ambos enlaces deberían ir seguidos de una solicitud para publicar consultas en un lugar en lugar de en ambos. TSventon ( conversación ) 12:19, 21 de abril de 2021 (UTC)
• Según TSventon , la casa de té y la mesa de ayuda definitivamente deben mantenerse separadas y están destinadas a satisfacer las necesidades de diferentes tipos de editores, incluso si a menudo hay alguna superposición. En WP: TH nos esforzamos por comunicarnos en un inglés sencillo y en un tono amistoso, asumiendo poco o ningún conocimiento previo por parte del interlocutor. Como ya se ha dicho, WP: HD es más corto, más conciso y, a menudo, más técnico en el tono, tanto en términos de preguntas formuladas, pero especialmente en las respuestas dadas. Dar la bienvenida a los nuevos editores y responder a sus preguntas de una manera sencilla y amistosa en Teahouse hace que el compromiso con los recién llegados sea mucho más largo, pero, como ha señalado Vahurzpu anteriormente, la investigación de Jmorgan (WMF) y su colega demostró que Teahouse hace un importante contribución a la retención de nuevos editores, y eso es lo que todos queremos, ¿no es así? También continúa proporcionando un banco de pruebas para la investigación sobre la retención de editores (consulte esta publicación de Maximilianklein en WT: TH en enero de 2020).
  Observo que la pregunta de ProcrastATINGReader se vinculó a una discusión parcialmente acordada que cerraron con el acuerdo de agregar un enlace a Teahouse en la página principal , y es allí donde realmente se debe hacer la distinción entre las audiencias objetivo, aunque la redacción precisa sería necesita más atención. Ciertamente estaría a favor de que se agregara ese vínculo, y dejaron claro los diferentes lugares activos. Por supuesto, si una pregunta en WP: TH es demasiado técnica para que los anfitriones pobres de Teahouse también respondan, a veces recomendamos a las personas, aunque la mayoría de las veces sería a WP: VPT o WP: REFDESK para los que no están relacionados con el tema. . (Sin embargo, desearía que WP: TH tuviera un mejor sistema de nombres de archivos, más parecido al de WP: HD, ya que facilitaría mucho más a los recién llegados encontrar su publicación antigua archivada cuando están en un formato anticuado .) Con respecto a cualquier sugerencia para fusionar WP: TH / WP: HD , este comentario de Maineartists lo resume: "si no está roto, ¿por qué arreglarlo?". Pero, en cuanto a WP: Asistencia del editor , sí, esto probablemente necesite marcarlo como histórico, y observo que Kudpung sugirió precisamente eso en 2018. Pero como nunca he estado allí (¿quién lo ha hecho?), No puedo comentar más allá de cualquier experiencia personal sobre dónde sería la mejor redirección. Supongo que WP: TH podría tener más sentido. Nick Moyes ( charla ) 22:39, 21 de abril de 2021 (UTC)
• Estoy de acuerdo con Procrastination Reader en que los lugares de ayuda deben consolidarse, y estoy de acuerdo con marcar el foro de asistencia al editor como histórico. Una de las cosas que los recién llegados dicen con mayor frecuencia sobre Wikipedia es que la cantidad de páginas de back-end es abrumadora, por lo que no es bueno que los editores se encuentren con una posible confusión sobre dónde hacer su pregunta en primer lugar.
  Con respecto al punto sobre la diferencia pretendida entre el TH y el HD, todo está bien, pero la palabra clave es intencionada . Actualmente hay muchos recién llegados completos que terminan en el HD, y confiar en ellos para leer la nota de sombrero y cambiar a Teahouse si quieren una respuesta amistosa no está funcionando. Necesitamos hacer un mejor trabajo apuntando al TH en lugar de al HD en todas las áreas de cara a los recién llegados, y hacer de este último un lugar mucho más silencioso que solo reciba preguntas no obvias de editores establecidos. {{u | Sdkb }}  ^charla 01:41, 23 de abril de 2021 (UTC)
• Fui el usuario principal que respondió en WP: EAR durante algunos años. Fue uno de los principales lugares de ayuda hasta que abrió The Tea House. Mi comentario original sobre el cierre de EAR fue de hecho en 2013. Me sorprende que nadie haya tomado la iniciativa de desaprobarlo y cerrar todos los enlaces a él. Kudpung กุด ผึ้ง ( charla ) 05:12, 23 de abril de 2021 (UTC)
• En un entorno de voluntariado, creo que los grupos interesados ​​en una iniciativa deberían tener la libertad de decidir cómo organizarla, siempre que no imponga una carga indebida a los demás. En este contexto, creo que deberían examinarse las siguientes cuestiones con respecto a cualquier posible carga:
  1. ¿Se están formulando y respondiendo preguntas de manera eficaz?
  2. ¿Los respondedores pueden responder a las preguntas de manera eficaz?
• Con respecto a la primera pregunta, los diferentes tipos de lugares atraen a diferentes editores, por lo que puede ser útil tener un ambiente de casa de té metafórico, así como un formato de preguntas y respuestas más conciso. Con respecto a la segunda pregunta, como han señalado otros, diferentes respondedores pueden estar interesados ​​en responder con diferentes niveles de detalle. ¿Tener varios lugares es efectivo para respaldar esto, frente a la compensación de algunos socorristas que tienen que monitorear varios lugares? En relación con ambas preguntas, si alguien hace una pregunta en un lugar que, basado en el nivel de detalle que necesita el interrogador, es más adecuado para otro lugar, esa pregunta aún se maneja de manera efectiva (aún respondiendo al nivel deseado, sin problemas moverlo a otro lugar, o por otros medios)?
• En resumen, me gustaría escuchar a la gente sobre el terreno: ¿tener dos lugares obstaculiza su capacidad para obtener respuestas adecuadas o para responder adecuadamente a las preguntas? ¿Necesitamos tener una mezcla más amplia de personas observando la mesa de ayuda o la casa de té para poder lidiar con diferentes expectativas en el nivel de detalle? ¿Eliminar uno atraerá más espectadores al otro? No me entusiasma decirle a los voluntarios que dejen de contribuir a una iniciativa productiva, incluso si creo que podrían ayudar igualmente a otra iniciativa productiva. isaacl ( charla ) 19:46, 24 de abril de 2021 (UTC)
• De vez en cuando paso por Teahouse y Help Desk, e incluso respondo preguntas. No me llamaría muy experimentado en ninguno de los dos. Veo mucha superposición (pero también mucha diferencia). Si alguien hace una pregunta de novato en HD, es mejor responderle en el lugar en lugar de decirle que se vaya y vuelva a preguntar en Teahouse. Viceversa, tener algunas preguntas más acertadas en Teahouse ayuda a romper la monotonía allí. Si quisiéramos mantener una fuerte separación, en lugar de una intención, entonces podríamos mover las discusiones de un foro a otro, al igual que esta discusión se ha movido de VPP a VPR. Pero mover hilos en MediaWiki es un poco más engorroso que en otras plataformas de discusión. Creo que somos un poco bruscos con la gente que hace una pregunta en ambos lugares: tener dos foros es potencialmente confuso y pedir ayuda en más de un lugar no está en la misma liga que comprar en foros en DR – AN – ANI .
  Tanto HD como TH están limitados por el alto volumen y el archivado rápido, especialmente Teahouse. Recuerdo a un nuevo editor que estaba bastante molesto porque Teahouse se presenta como un lugar para tener una charla amistosa, pero en la práctica es principalmente una fuente de preguntas y respuestas rápida. Si fuéramos una comunidad más pequeña, podríamos tener todas las conversaciones en le Bistro o Beerhall, en lugar de dividirlo en varios silos (VP ​​* es un buen ejemplo). Esto nos lleva a una limitación práctica. La fusión de los dos agravaría la situación con un gran volumen de preguntas. Y también está la naturaleza de las preguntas: el lugar de la Ayuda fusionada podría verse abrumado con tantas preguntas repetidas: "¿Cómo hago un artículo nuevo para algo no notable?", "Lo mío no aparece en Google" y "¿Por qué AFC toma tanto ¿largo?".
  Hablando de diferencias prácticas en lugar de intencionadas, una gran diferencia entre Teahouse y Help Desk son los puntos de entrada. Los nuevos usuarios a menudo reciben un gran mensaje de bienvenida que los dirige al TH.

IIRC, incluso algunas de nuestras plantillas de advertencia de nivel uno los dirigen allí.
-  Pelágicos (  mensajes  ) - (12:45 dom 25, AEDT) 01:45, 25 de abril de 2021 (UTC)

• Para aquellos que se preguntan cuáles son las diferencias entre EA / EAR y Teahouse / Help Desk; Si observa de cerca, notará que muchas solicitudes de EAR están relacionadas con disputas / contenido, algo que creo que Teahouse / Help Desk no se ocupa o no promueve, ya que se promocionan principalmente como foros de preguntas y respuestas. Otras cosas que se promueven en gran medida en EA / EAR, pero no en Teahouse, son la capacidad de ponerse en contacto directamente con una lista de editores útiles y realizar solicitudes de edición. Si bien estas características pueden ser técnicamente posibles en Teahouse, no se promueven de ninguna manera que las haga funcionalmente útiles, como lo son en EA / EAR. Huggums537 ( charla ) 16:03, 1 de mayo de 2021 (UTC)
• Comentar . He estado respondiendo activamente solicitudes en WP: EAR últimamente. Me gusta porque tiene poco tráfico, pero no está completamente inactivo. Puedo mantenerlo en mi lista de observación sin que aumente a más de 100 revisiones al día, y tengo una posibilidad decente de poder responder (antes de que alguien más dé una buena respuesta, lo que hace que la necesidad de que yo responda sea innecesaria). - Novem Linguae ( charla ) 23:19, 1 de mayo de 2021 (UTC)
• Comentar . Poniéndome en la mentalidad de un novato, sé lo que es un servicio de asistencia técnica, no tengo idea de lo que es la casa de té, una instalación elegante para que los expertos tengan una charla, supongo. Sé a quién acudiría en busca de ayuda. Sin embargo, lo hacemos al revés; estamos tan acostumbrados a hacerlo al revés que ni siquiera nos damos cuenta de que lo estamos. Puedo ver sus respuestas ahora; "@steelpillow, la Ayuda: el contenido explica cuál y por qué", excepto que los novatos no leen letra pequeña, simplemente dicen "Genial, un bonito enlace azul al servicio de asistencia técnica> haga clic en <". Solo un consejo de un autor técnico y diseñador de UI de larga trayectoria en el negocio de TI; lo que sea que decidan, lo que los novatos quieren y esperan es un botón destacado de la mesa de ayuda. - Saludos, Steelpillow ( Discusión ) 15:40, 23 de mayo de 2021 (UTC)

Propuesta: desaprobar WP: EA / WP: EAR y cerrar todas las plantillas activas o páginas de ayuda vinculadas a él

Existe consenso para aprobar esta propuesta, para consolidar los espacios de ayuda, por lo que se cierra el menos activo. Se ha sugerido redirigir estas páginas, pero no hay consenso sobre dónde exactamente. nave estelar .paint ( exalt ) 04:01, 31 de mayo de 2021 (UTC)

La siguiente discusión está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

---

• Soporte No tiene sentido que los recién llegados sean dirigidos a un lugar inactivo. Las páginas también deben marcarse como "históricas". Haciendo ping a ProcrastinationsReader como OP. Nick Moyes ( charla ) 23:10, 23 de abril de 2021 (UTC)
  • Nick Moyes , ¿de dónde sacas la idea de que es un lugar inactivo? La solicitud más antigua fue la 16 y la más reciente el 30. Huggums537 ( charla ) 14:32, 1 de mayo de 2021 (UTC)

    @ Huggums537 : Aquí están las cifras:

    • Teahouse 2020 ediciones: 31,653
    • Teahouse 2021 ediciones: 18,347
    • Help Desk 2020 ediciones: 25,016
    • Help Desk 2021 ediciones: 9.039
    • Oído / Solicitudes 2020: 1,121
    • Oído / Solicitudes 2021: 434

    Espero que esto ayude, Nick Moyes ( charla ) 23:39, 1 de mayo de 2021 (UTC)

    Sí, esto ayuda porque puedo ver que la etiqueta "inactivo" se atribuyó incorrectamente a un foro que en realidad es "menos activo", una tergiversación que no me habría molestado tanto si se hubiera presentado correctamente como "casi". o "casi" inactivo. Huggums537 ( charla ) 10:57, 2 de mayo de 2021 (UTC)

    Ok, Nick Moyes , te debo una disculpa por insistir sobre la etiqueta "inactiva". Tras una investigación adicional, parece que la idea se originó en la publicación original de ProcrastinationsReader, quien dijo que el lugar estaba " completamente inactivo ", lo que llevó a otros como GreenMeansGo , Levivich y Sdkb a concluir que el lugar era de naturaleza "histórica". ProcrastATINGReader ¿ podría explicar por qué describió el lugar como "completamente inactivo"? Supongo de buena fe que estaba haciendo referencia a la página de registro de EA, no a la página del proyecto EAR, y no tenía la intención de desviar a nadie. También estoy de acuerdo en que la página no está muy activa. Sin embargo, creo que es muy similar a la página de registro de muchos otros proyectos, y que no pretende ser tan activa, ya que el único propósito real es que la gente se registre en el proyecto. Muchas de estas páginas de registro de proyectos no son realmente tan activas. Esto no es motivo para poner un proyecto en una condición "histórica", o llamarlo completamente inactivo cuando un editor se inscribió en el proyecto hace apenas un mes y medio . Huggums537 ( charla ) 12:31, 2 de mayo de 2021 (UTC)

    La declaración es bastante clara: Más importante aún, mi sensación es que Wikipedia: la asistencia del editor probablemente debería redirigirse a algún lugar, ya que ese lugar está completamente inactivo y en su mayoría se remonta a antes de 2011, y WP: EAR probablemente debería redirigirse a Teahouse o al servicio de asistencia técnica, ya que no lo hace. No parece tener ninguna característica distintiva de ninguno de los dos. No dice lo que parece pensar que dice. Los últimos 5 registros se remontan a 2018 y los últimos 10 se remontan a 2012, hace casi una década. Eso es "completamente inactivo". ProcrastinationReader ( charla ) 13:16, 2 de mayo de 2021 (UTC)

    @ Huggums537 : Si bien es posible que no estén del todo muertos, es probable que todavía haya que hacer algunos cálculos sobre si estamos confundiendo a los nuevos editores al tener una duplicación innecesaria de foros que tienen muy poca variación en el alcance. Como ya se mencionó, existe una región que no se superpone para TH y HD. Eso se debe en gran parte a esfuerzos como HostBot, que se dirigen específicamente a nuevos usuarios.

    Pero no nos estamos haciendo ningún favor si tenemos tanta redundancia que "dónde hago mi pregunta" termina siendo la primera pregunta de alguien. Alternativamente, si tiene enlaces a foros de ayuda a lo largo y ancho, y un nuevo usuario que no sabe cómo usar su historial de contribuciones y no puede encontrar la pregunta una vez que la ha formulado. G M G ^talk 16:05, 2 de mayo de 2021 (UTC)

    Estoy de acuerdo en que sería necesario realizar más cálculos porque dudo mucho que nos enfrentemos a algún problema de "dónde hago mi pregunta". Este es un argumento irracional basado en el miedo que no tiene base en la realidad ya que el status quo no ha producido una cantidad significativa de tales problemas que yo sepa. No hay razón para esperar que dejar el EA / EAR y el TH / HD intactos haga que las cosas cambien de esa manera. Sin embargo, la eliminación de EAR elimina las opciones disponibles para un usuario que no están disponibles en los otros foros de ayuda, como la capacidad de realizar ciertas solicitudes de disputa / contenido / edición. Esto es completamente útil para aquellos que no tienen interés en un lugar tan vil como la galería de maní . Recientemente descubrí la alegría de Wikipedia: solicitudes de resolución de disputas y encontré extremadamente útil tener opciones de disputas disponibles para poder encontrar una forma más amigable y adecuada de resolver una disputa. Más opciones son mejores. Vea mi argumento del baño a continuación. Huggums537 ( charla ) 16:47, 2 de mayo de 2021 (UTC)

    Tenemos muchos tablones de anuncios de temas específicos y lugares para preguntas generales. La división innecesaria de la conversación reduce los buenos resultados, tanto en términos de respuestas a la pregunta formulada como de confusión para el autor de la pregunta. Existe un argumento legítimo de que fusionar HD + TH haría que el volumen fuera tan alto que la fusión sería contraproducente (por lo tanto, no se ha propuesto). No ocurre lo mismo con EAR. Tenemos {{ solicitud de edición }} y WP: DR lugares como WP: DRN y WP: 3O . Si EAR está duplicando el trabajo de 4 sistemas diferentes, y lo está haciendo de una manera inferior, entonces ese no es un lugar productivo en absoluto. ProcrastinationReader ( charla ) 17:11, 2 de mayo de 2021 (UTC)

    La pregunta clave, como mencioné anteriormente, es si los solicitantes y los respondedores sienten que el sistema les funciona bien. No me gusta decirles a los voluntarios que deben dejar de trabajar de una manera que consideren productiva solo porque creo que podrían ser productivos en otros lugares. isaacl ( charla ) 17:20, 2 de mayo de 2021 (UTC)

    No es solo porque serán productivos en otros lugares, es porque tener un sistema demasiado complejo ahuyenta a los nuevos voluntarios. Existe un sesgo de supervivencia en cuanto a quién llega a publicar una pregunta, y muchos editores se sienten intimidados simplemente cuando se enfrentan a múltiples lugares para hacer una pregunta. Si bien nos gustaría que fueran audaces y eligieran uno, muchas personas tienen miedo de elegir mal y de que les griten, por lo que simplemente no publican. Duplicar el trabajo puede ser perjudicial, y si los flujos de trabajo de los voluntarios están dañando los esfuerzos para atraer más voluntarios, entonces sí, creo que deberíamos pedirles que aprendan un nuevo flujo de trabajo. - Wug · a · po · des​ 06:54, 3 de mayo de 2021 (UTC)

    Wugapodes , ¿dónde están sus datos o alguna evidencia que sugiera que tales daños han estado ocurriendo con los procesos actuales? Me canso de estos argumentos basados ​​en el miedo que abundan en Wikipedia sin ninguna evidencia racional que los respalde. Básicamente, esta propuesta pide que nos entrometamos en un grupo que realiza negocios felizmente y los obliguemos a empacar la tienda para hacer negocios en lugares que tal vez no quieran, y en formas que no son exactamente las mismas a las que están acostumbrados porque creemos que sabemos más, o no nos gusta lo que están haciendo, y todo en nombre de una menor actividad. Eso tiene tanto sentido como poner tablas en la habitación de invitados para que nadie pueda usarla, ya que de todos modos no se usa mucho. Huggums537 ( hablar ) 11:27, 3 de mayo de 2021 (UTC) Además, su argumento sugiere que deberíamos colocar un letrero sobre la puerta tapiada de la habitación que diga: "¡Dañino! ¡No entre!" En realidad, es algo cómico. Toda esta charla sobre "duplicar" el trabajo como si de alguna manera fuéramos a multiplicar las cosas simplemente dejándolas como felizmente han sido es realmente absurdo. La mentalidad lógica wikipedificada me desconcierta. Huggums537 ( charla ) 11:48, 3 de mayo de 2021 (UTC)

    Si hay un problema con la productividad de uno o más de los sistemas de ayuda desde el punto de vista de quienes preguntan o responden, entonces ciertamente deberíamos examinar los medios para mejorar las cosas. Sin embargo, aquí solo he visto ejemplos teóricos, por lo que creo que deberíamos hablar con los participantes sobre las diferentes iniciativas, ver qué piensan y darles una amplia libertad para decidir qué modos de operación funcionan bien para ellos. En cuanto a que le griten, creo que la solución ideal es no gritarle a nadie y asegurarle por adelantado que no importa dónde alguien pida ayuda, la solicitud se dirigirá a los socorristas que puedan ayudar. Como es un mundo imperfecto, eso podría significar trasladar la solicitud a un lugar más especializado (como la bomba de la aldea técnica para preguntas relacionadas con la implementación de MediaWiki, el tablón de anuncios de fuentes confiables para preguntas sobre fuentes apropiadas, etc.), que creo que es manejable. isaacl ( charla ) 20:13, 3 de mayo de 2021 (UTC)

    Estoy de acuerdo. Relacionando esto con la analogía de mi habitación de invitados anterior, tenemos que considerar que en este caso la habitación de invitados está actualmente ocupada. Creo que sería mucho más apropiado obtener las opiniones de los propios huéspedes sobre lo dañina que creen que es la habitación de invitados en lugar de tirarlos a todos repentinamente con el pretexto de que * pensamos * que podría ser dañino, y luego intentarlo. justifíquelo diciendo que no se usó mucho de todos modos, así que tápelo y le pondremos un letrero de "Peligro" para sentirnos mejor al respecto. Huggums537 ( charla ) 07:08, 4 de mayo de 2021 (UTC)

    Si las solicitudes de asistencia aún se están respondiendo adecuadamente, el lugar aún está activo. isaacl ( charla ) 17:18, 2 de mayo de 2021 (UTC)

    De acuerdo con los puntos hechos por Isaacl . Huggums537 ( charla ) 17:41, 2 de mayo de 2021 (UTC)

    Probablemente sería imposible saberlo. Supongo que podríamos buscar en las páginas de discusión de los usuarios de los editores enumerados allí para cualquier pregunta, pero sería imposible saber WP: EA es de donde vienen. Con ~ 150 páginas vistas por mes, no soy optimista. En cualquier caso, el formato es arcaico en mi opinión e inferior a los sistemas más nuevos. ProcrastinationReader ( charla ) 17:43, 2 de mayo de 2021 (UTC)

    Bueno, están las solicitudes en la página de solicitud para las que puede ver las respuestas y el tiempo de respuesta. Si está pensando en el contacto directo con los ayudantes, personalmente no lo llamaría un mecanismo inferior: la asistencia personalizada puede ser eficaz. En cualquier caso, no creo que se deba imponer un cierre. Siéntase libre de conversar con los editores involucrados y llegar a un consenso de que responder preguntas en la mesa de ayuda sería esencialmente equivalente. isaacl ( charla ) 18:45, 2 de mayo de 2021 (UTC)

• Soporte por comentarios en la sección anterior. {{u | Sdkb }}  ^charla 23:29, 23 de abril de 2021 (UTC)
• Soporte - ídem Levivich  ^acosar / _perro doce y cuarenta y seis, 24 de Abril 2021 (UTC)
• Soporte : propuesta muy sensata y sólida que, con suerte, comienza a abordar nuestros problemas con lugares de ayuda. Aza24 ( conversación ) 01:37, 24 de abril de 2021 (UTC)
• Soporte por Aza24. ProcrastinationReader ( charla ) 07:46, 24 de abril de 2021 (UTC)
• Apoyo de Nick Moyes. EpicPupper 23:21, 24 de abril de 2021 (UTC)
• Soporte Suponiendo que no nos hemos perdido nada, esto parece una obviedad. ElKevbo ( charla ) 02:56, 25 de abril de 2021 (UTC)
• Tiene sentido. ~ HAL 333 20:36, 28 de abril de 2021 (UTC)
• Oponerme porque me parece un lugar útil y no entiendo por qué alguien piensa que el lugar está inactivo, ya que actualmente hay 15 solicitudes abiertas. Tampoco entiendo por qué se notificó esta discusión en las páginas de discusión de Teahouse y Help Desk, pero no en las otras dos, así que lo haré ahora. Huggums537 ( charla ) 14:32, 1 de mayo de 2021 (UTC)
• El soporte puede haber sido útil históricamente, pero ahora parece ser una duplicación innecesaria de la mesa de ayuda. - Tera tix ₵ 14:38, 1 de mayo de 2021 (UTC)
  • Excepto que la mesa de ayuda no ofrece resolución de disputas ni acepta solicitudes de edición como lo hace EAR, aunque podrían hacerlo si se les solicita, pero no se ofrece como una función estándar, por lo que en realidad no es un duplicado. Huggums537 ( charla ) 10:57, 2 de mayo de 2021 (UTC)
    • Hay muchos otros foros que ofrecen resolución de disputas (tanto de contenido como de conducta ). No estoy seguro de lo que quiere decir con "aceptar solicitudes de edición ", ya que se publican en las páginas de discusión de los artículos. Si tiene la intención de transmitir el significado genérico de "ayudar a implementar una edición sugerida", la Mesa de ayuda ya los maneja fácilmente ( ejemplo de hoy ). - Tera tix ₵ 01:23, 4 de mayo de 2021 (UTC)
      • Teratix , ese no era el punto. Dijiste que EAR era una "duplicación" de Help Desk, y no es porque EAR resuelve disputas y Help Desk no. Teahouse tampoco. Por lo tanto, esta idea de que EAR es una "duplicación" es una evaluación incorrecta. Huggums537 ( charla ) 05:58, 4 de mayo de 2021 (UTC)
        • EAR no parece "hacer disputas"; una de sus primeras instrucciones para los posibles solicitantes es que Las discusiones relacionadas con disputas de contenido se podrían abordar mejor en el tablón de anuncios de resolución de disputas . Pero incluso si EAR hizo resolver disputas, me gustaría simplemente actualizar mi evaluación de "EAR duplica las funciones de Help Desk" a algo así como "EAR duplica las funciones de la Mesa de Ayuda y DRN". Mi argumento central no se vería afectado. - Tera tix ₵ 09:38, 4 de mayo de 2021 (UTC)
          • Excepto que no estamos discutiendo la fusión de DRN, estamos discutiendo la fusión de foros de ayuda. Entonces, creo que es una parte irrelevante de su argumento central. Además, solo mire parte del historial de solicitudes y podrá ver fácilmente que SÍ manejan las disputas. Huggums537 ( charla ) 14:56, 4 de mayo de 2021 (UTC)
            • No me importa tener una discusión, pero si no representa con precisión mis puntos de vista, no hará ningún progreso para cambiar de opinión. No estamos discutiendo la fusión de DRN . Nunca dije que DRN debería fusionarse. Puede ver fácilmente que SÍ manejan disputas . He explicado claramente que la cuestión de si EAR resuelve disputas es irrelevante para mi argumento central: EAR duplica las funciones de otros foros de Wikipedia. Ninguna de sus tres respuestas ha abordado realmente este punto. - Tera tix ₵ 02:13, 5 de mayo de 2021 (UTC)
              • He estado tratando de abordar el punto, pero no lo acepta o no lo estoy explicando lo suficientemente bien. EAR ofrece servicios que Teahouse y Help Desk no ofrecen , como los que también se encuentran en DRN y otros foros. Dado que estamos comparando y discutiendo la fusión de foros de ayuda , es una equivalencia inválida y falsa comparar los servicios de EAR con los otros foros de ayuda, por lo tanto, también es inválido decir que EAR es un "duplicado" de los otros foros de ayuda. No lo es. Es única. Toma prestado de varios foros. Del mismo modo, nunca afirmaría que EAR es un "duplicado" de DRN, ya que ofrece otros servicios que DRN no ofrece, como solicitudes de ayuda. DRN es estrictamente una resolución de disputas, por lo que sería una comparación injusta, no un "duplicado". El hecho de que algo tenga cualidades similares no lo hace "duplicado". No creo que la gente entienda lo que es un "duplicado", o simplemente están tirando el término de manera demasiado vaga. Cualquiera de estas dos cosas sería igualmente subóptima. En pocas palabras, creo que el argumento de la "duplicación" (de ayuda o cualquier otro foro de Wikipedia) sobre EAR no es válido. Huggums537 ( charla ) 03:46, 5 de mayo de 2021 (UTC)

                Una vez más, no está representando con precisión mis puntos de vista. No estoy afirmando que EAR sea un duplicado exacto de un foro alternativo en particular, estoy afirmando que duplica las funciones de otros foros . Tampoco es válido decir que EAR es un "duplicado" de los otros foros de ayuda. No lo es. Es única. Toma prestado de varios foros. Sí, ese es mi punto; ¡no tiene funciones que no se cumplan en otros lugares! En este punto, ha argumentado su punto de vista en unos 20 comentarios y respuestas a otros editores, sin hacer ningún avance. En mi opinión, eso se acerca a aplastar el proceso . Quizás sea el momento de dar un paso atrás en la discusión. - Tera tix ₵ 09:15, 5 de mayo de 2021 (UTC)

                Me alegro de que finalmente pudiéramos llegar al fondo de su punto real. Si solo hubiera dicho esto al principio en lugar de afirmar que era un duplicado de la mesa de ayuda, nos habría ahorrado mucha discusión para llegar a su punto. Sin embargo, existe una gran diferencia entre tener una discusión larga para llegar a su punto y "aporrear el proceso". Es muy pobre acusar a otros editores de una edición disruptiva debido a tu propia falta de poder explicar tu punto correctamente en primer lugar. Cualquier otro comentario que haya hecho en otro lugar solo se ha hecho en esos lugares específicos donde sentí que se necesitaba una respuesta para defender la idea de mantener EAR. De todos modos, sigo sintiendo que su punto está equivocado de todos modos porque [pasando por alto eso] EAR de hecho realiza una función que no se realiza en ningún otro lugar en virtud del hecho de que es el único foro de ayuda que también atiende disputas y otras solicitudes. El mero hecho de que "duplique las funciones de otros foros" es evidencia de que es un foro que cumple una función de una manera que ningún otro foro lo hace. Con eso, dejaré de comentar aquí antes de que alguien más decida hacer acusaciones de mala fe. Huggums537 ( charla ) 13:30, 5 de mayo de 2021 (UTC) En otras palabras, EAR es el único foro que conozco que cumple la función de combinar estos otros servicios. Huggums537 ( charla ) 15:41, 5 de mayo de 2021 (UTC)

                Sugiero que no nos quedemos estancados en la semántica y adoptemos una visión holística. No es esencial etiquetar la iniciativa de asistencia al editor como un foro de ayuda, ni es necesario mirar solo otros lugares etiquetados como foros de ayuda como posibles reemplazos. (Si todos los que participan en el proyecto de asistencia al editor estuvieran felices de trasladar la actividad a otras áreas, por ejemplo, no creo que importe si esas otras áreas son foros de ayuda). Isaacl ( charla ) 04:46, 5 de mayo de 2021 ( UTC)

                Isaacl , Bueno, sí, si estuvieran felices de ir a otros foros, simplemente elegirían ir a lo que prefieran, ya sea DRN o Teahouse, pero si les gustan ambos, entonces dividiríamos sus intereses en múltiples lugares y crearíamos el mismo problema que el usuario de IP 192.76.8.91 dijo que estaríamos resolviendo. Huggums537 ( charla ) 05:22, 5 de mayo de 2021 (UTC)

                Bueno, ya ha defendido los beneficios de tener varios lugares en los que los editores pueden obtener ayuda. Tenga en cuenta que no es necesario que me envíe un ping a esta discusión. isaacl ( charla ) 05:31, 5 de mayo de 2021 (UTC)

                Sí, defiendo que haya más opciones y opciones disponibles. Creo que EAR ofrece eso de una manera única que otros no. Puede hacer más que los foros de ayuda, y no es tan terrible como ANI. Sin embargo, parece estar insinuando que, dado que he abogado por más opciones, no debería argumentar sobre obligar a los contribuyentes a ir a más lugares. Bueno, en realidad son dos argumentos diferentes, ¿no? Me siento bien haciendo los dos. Perdón por el ping. El guión lo coloca y, a veces, me olvido de quitarlo. Huggums537 ( charla ) 06:13, 5 de mayo de 2021 (UTC) Por cierto, gracias por intentar señalar la aparente paradoja de mis argumentos, ya que la paradoja más grande de crear el mismo problema que estamos tratando de resolver al implementar la solución ha sido revelado ... Huggums537 ( charla ) 07:58, 5 de mayo de 2021 (UTC)

                No, solo estaba diciendo que no necesito discutir las ventajas de poder manejar preguntas en uno o más lugares, como ambas partes lo consideren oportuno, ya que usted ya lo ha hecho. Es normal que los procesos cambien a lo largo de los años, lo que puede significar crear otros nuevos o eliminar los antiguos. Si hay escasez de voluntarios para que un proceso funcione de manera eficaz, es posible que debamos consolidar los esfuerzos; A medida que crece el tamaño de la comunidad de Wikipedia en inglés, puede resultar más eficaz tener iniciativas más especializadas. isaacl ( charla ) 16:02, 5 de mayo de 2021 (UTC)

• Oponerse La afirmación del OP es falsa. Las estadísticas de la página indican que la actividad ha sido bastante constante y estable en los últimos años y está lejos de ser cero. Andrew 🐉 ( charla ) 15:00, 1 de mayo de 2021 (UTC)

  Vea las estadísticas de comparación arriba. Nick Moyes ( charla ) 07:15, 2 de mayo de 2021 (UTC)

  Eso también es solo la mitad del punto, el otro es que causa redundancia innecesaria y descentralización improductiva. Aza24 ( conversación ) 07:22, 2 de mayo de 2021 (UTC)

  Lo principal que noto de las estadísticas anteriores es que la persona que agrega más texto a Teahouse es un Nick Moyes. Entonces, lo que tenemos aquí es una oferta pública de adquisición en la que los rivales más pequeños son aplastados y destruidos. El problema es que no se obtienen economías de escala en Wikipedia. Más grande no es mejor porque las páginas wiki se vuelven inutilizables cuando crecen demasiado, se vuelven ilegibles y tienen problemas técnicos con la sobrecarga de la plantilla. Y, si obliga a las personas a hacer las cosas de la única manera verdadera, entonces los voluntarios a quienes no les importa esto tenderán a retirar su trabajo. Entonces, a menos voluntarios se les asigna una mayor carga de trabajo. Esto puede funcionar por un tiempo, pero luego se agota un solo punto de falla. Observe cómo el poste indicador está en crisis nuevamente porque su estructura centralizada está quemando al editor en jefe una vez más. Mi voto se mantiene. Andrew 🐉 ( charla ) 08:56, 2 de mayo de 2021 (UTC)

  Estoy de acuerdo con Andrew Davidson. Esta lógica de que ya tenemos un lugar que se está usando para recibir ayuda para que no necesitemos otro es similar a la familia que mejoró su casa de una habitación / 1 baño a una casa de cinco habitaciones y se dijo a sí misma; "No necesitamos otro baño, necesitamos un lugar centralizado para que todos orinen para facilitar las cosas". Es completamente absurdo. Además, no hay redundancia en mantener EAR cuando se comparan dos foros que ofrecen diferentes tipos de servicios y EAR ofrece servicios que los otros no. Sin embargo, incluso si fuera un servicio "redundante", creo que mi argumento de "más baños es mejor" todavía se aplica. Huggums537 ( charla ) 10:57, 2 de mayo de 2021 (UTC)

  Este argumento del baño no encaja; no puedo creer que esté diciendo esto, pero más baños, por supuesto, es útil porque solo una persona puede usarlo a la vez, pero ese no es el caso con estos lugares de ayuda. Tener múltiples ubicaciones para propósitos sin diferencias significativas simplemente no es útil, es confuso, divide los recursos y es repetitivo. ¿Y por qué actuamos como si hubiera alguna conspiración aquí? "Los rivales más pequeños son aplastados y destruidos" Quiero decir, ¿¿¿¿¿¿¿¿¿¿¿????? Los datos de visitas a la página han demostrado que la actividad en EAR es ciertamente menor, y al ritmo que está descendiendo, no veo ninguna razón para creer que el tráfico desviado pueda abrumar la casa de té o la mesa de ayuda, los cuales son extremadamente eficientes. De hecho, en todo caso, difícilmente tendrá un efecto en la "carga de trabajo" promedio en estos lugares. La centralización no es intrínsecamente negativa, es la práctica principal de WP: el letrero es completamente incomparable y tiene una serie de problemas propios. Aza24 ( charla ) 17:05, 3 de mayo de 2021 (UTC)

  En mi experiencia, dividir los tablones de anuncios solo funciona bien cuando cada uno de los sub-tablones de anuncios tiene un propósito específico y toma una sección específica del tráfico. Mire algunas de las divisiones exitosas, la bomba de la aldea, por ejemplo, tiene secciones separadas, tiene secciones separadas para la política, las relaciones de WMF, el material técnico, etc. ¿Se imagina el lío si en su lugar lo dividiéramos creando "Bomba de la aldea 1"? , "Bomba de pueblo 2", "Bomba de pueblo 3", etc., ¿y las reglas eran "Publicar en el tablero que te apetezca"? Si queremos dividir los tableros de ayuda en secciones más pequeñas, debería hacerlo dividiendo la mesa de ayuda en temas, por ejemplo, "ayuda con plantillas", "ayuda con el abastecimiento", "ayuda con políticas y directrices". Tampoco creo que la analogía del baño encaje realmente, creo que la situación es más parecida a comprar una casa de cinco habitaciones, luego comprar la casa idéntica de al lado, tratar de vivir en ambas al mismo tiempo y preguntarse por qué terminas con todos reunidos en la misma casa. 192.76.8.91 ( conversación ) 17:29, 3 de mayo de 2021 (UTC)

  En mi experiencia, veo muchos procesos en Wikipedia que funcionan bien sin estar centralizados. Un ejemplo que se me ocurre de inmediato son estos foros de ayuda que se están debatiendo. ¿Qué evidencia ha ofrecido alguien de que alguno de estos foros no ha funcionado bien, salvo el estado de poco tráfico? Eso no indica en absoluto si los foros han funcionado o no para las personas que los utilizan. En todo caso, es solo una indicación de que los foros con más tráfico se anunciaron más y los que tenían menos no obtuvieron tanta exposición. Huggums537 ( charla ) 06:19, 4 de mayo de 2021 (UTC)

  Tener poco tráfico es inherentemente malo para un tablero de ayuda: para brindar a las personas un consejo bueno y oportuno, necesita una gran base de ayudantes voluntarios con una variedad de experiencia en responder preguntas. Ayer, alguien en el foro pidió ayuda con una disputa sobre un artículo que involucraba el tamaño de una imagen en un cuadro de información; les tomó 8 horas obtener una respuesta, que básicamente se redujo a "Por lo general, dejamos el tamaño de la imagen por defecto". Hicieron una pregunta de seguimiento sobre cómo evitar futuras guerras de edición, que al momento de escribir este comentario, no ha recibido respuesta durante 14 horas. Al mirar los archivos de la página de discusión, esto no es raro. La gente ha planteado otros problemas al tener varios tableros de ayuda arriba y abajo, uno de los cuales es extremadamente confuso para los recién llegados que buscan hacer una pregunta para enfrentarse a varias páginas con nombres completamente diferentes que hacen lo mismo. 192.76.8.91 ( conversación ) 09:41, 4 de mayo de 2021 (UTC)

  Entonces, ¿cree que la consolidación masiva de los tres foros en un gran conglomerado realmente reducirá los tiempos de respuesta en lugar de alargarlos? Me replantearía seriamente esa posición si fuera usted. Huggums537 ( charla ) 14:56, 4 de mayo de 2021 (UTC) Además, su queja sobre los tiempos de respuesta es bastante ridícula. Los invito a ver algunos otros lugares consolidados y unificados que están demostrando que no funcionan, como Artículos para la creación, donde el retraso es superior a 5,000 y el tiempo de respuesta se mide en meses, no en horas, o podría ver algo como el desbloqueo. Solicite el sistema y vea cómo le gustan esos tiempos de respuesta. Los administradores deberían poder revisar un bloqueo con la misma facilidad con que se revisa una disputa en EAR, pero no lo hacen y eso es lo que obtienes por tu consolidación unificada. Huggums537 ( charla ) 15:55, 4 de mayo de 2021 (UTC)

  La comparación con AfC parece sólida. Simplemente eché un vistazo de cerca a Teahouse y descubrí que es solo un panel de preguntas y respuestas desenfocado: no parece haber nada de la socialización gentil que sugiere su nombre. Allí, Nick Moyes explica que " Lamentablemente, gran parte de nuestro trabajo aquí consiste en decirles a los editores esperanzados que no tienen ninguna posibilidad de que su artículo favorito se convierta en realidad ... " y, por lo tanto, vemos que se trata principalmente de una obstrucción hostil como AfC. Como coordinador de eventos que trata regularmente con nuevos editores en los maratones de edición, me aseguro de alejar a los nuevos editores de AfC y ahora trataré a Teahouse de la misma manera. Y esto también muestra el cuidado que hay que tener con las estadísticas. Si la casa de té en realidad está teniendo un efecto adverso al desanimar a los recién llegados y alejarlos en lugar de ayudarlos, entonces hacerla más concurrida puede empeorar las cosas. Lo que necesitamos son estadísticas sobre el efecto de estos distintos servicios de asistencia técnica. ¿Cuáles de ellos realmente aumentan la productividad y la retención y cuáles lo perjudican? Andrew 🐉 ( charla ) 08:38, 5 de mayo de 2021 (UTC)

• Apoyo Tiene sentido para mí. Afernand74 ( conversación ) 13:59, 2 de mayo de 2021 (UTC)
• Comentario - LOL, "oferta pública de adquisición". Qué tontería absoluta. Reyk _YO! 14:10, 2 de mayo de 2021 (UTC)
• Compatible con los datos de NickMoyes anteriores. No deberíamos dividir nuestros esfuerzos porque tener demasiados lugares confunde a los novatos. Es mejor dirigir a los nuevos editores a un solo lugar para hacer preguntas o hacer solicitudes, y Teahouse obtuvo 30 veces más tráfico que WP: EAR en 2020, así que creo que deberíamos ir con ese. Los editores activos en EARS aún pueden continuar cumpliendo con las solicitudes, solo mire la Casa de té en su lugar. - Wug · a · po · des​ 06:47, 3 de mayo de 2021 (UTC)
• Soporte . No veo el valor de tener varios lugares con un enfoque superpuesto, y creo que crea más problemas de los que resuelve:
  • Es confuso para los recién llegados, que ya se enfrentan a una gran cantidad de tablones de anuncios , páginas de ayuda y foros de discusión. Por ejemplo, si buscaba averiguar si una fuente es utilizable en un borrador que está escribiendo, podría dirigirse a WP: TEA , WP: RSN , WP: HD , WP: AFCHELP o WP: EAR , todos que podrían ser lugares adecuados para hacer su pregunta.
  • Divide a los colaboradores voluntarios en varias páginas, lo que significa que los ayudantes que son expertos en un aspecto de la edición pueden perder las preguntas publicadas en un foro de ayuda que no revisan con frecuencia, lo que da como resultado respuestas de menor calidad.
  • Las personas que soliciten ayuda en los tablones de anuncios de menor tráfico tendrán tiempos de espera innecesariamente más largos para recibir respuestas. Algunas de las preguntas de WP: EAR tardaron 3 horas o más en obtener una respuesta, lo que no es ideal para un recién llegado que está escribiendo su primera página. 192.76.8.91 ( conversación ) 16:45, 3 de mayo de 2021 (UTC)

    Dado que EAR ofrece múltiples servicios, como resolución de disputas y servicios de ayuda, aún está dividiendo a los contribuyentes voluntarios en múltiples foros. Por ejemplo, si a un voluntario de EAR le gusta revisar las disputas y ayudar a los nuevos editores en una ubicación centralizada, ahora tendrá que dividir sus esfuerzos en varios lugares porque ahora deberán ir tanto a Teahouse como a DRN. Huggums537 ( charla ) 05:29, 5 de mayo de 2021 (UTC)

• Support EAR es una página moribunda y tener demasiadas opciones es perjudicial para el funcionamiento eficiente de cualquiera de ellas. No tendríamos que hacerlo si fuera una parte muy utilizada de Wikipedia. Aunque puede haber sido en el pasado, no lo es ahora, y es mejor que lo apaguemos. - Jayron 32 16:06, 4 de mayo de 2021 (UTC)

  Nadie ha proporcionado prueba alguna de que esta página supuestamente "moribunda" haya perjudicado en modo alguno el funcionamiento de cualquiera de las demás. Huggums537 ( charla ) 05:00, 5 de mayo de 2021 (UTC)

• Soporte La lenta proliferación de foros entre bastidores de Wikipedia es inevitable, pero un jardín bien mantenido necesita podarse de vez en cuando. Esto parece sensato. Ganesha811 ( charla ) 01:08, 5 de mayo de 2021 (UTC)
• Soporte : haga que las páginas se redireccionen. - Ched ( charla ) 03:58, 5 de mayo de 2021 (UTC)
• Apoyo en lugar de unos pocos lugares grandes que muchos pequeños. CaptainEek ^{edita Ho Cap'n!} ⚓ 21:23, 8 de mayo de 2021 (UTC)
• Apoyo , cuando fundé el proyecto de Asistencia al Editor, fue principalmente como una reacción al cierre de la antigua "Asociación de Defensores de los Miembros", para que la gente tuviera un lugar al que acudir y pedir consejo. Además, parece bastante duplicado de lo que hace Teahouse, y tiene sentido tener un solo lugar para dirigir a las personas para que obtengan ayuda y consejos sobre la edición en lugar de varios. Seraphimblade ^Háblame 13:39, 14 de mayo de 2021 (UTC)
• Oponerse No hay daño en la diversidad siempre que los diferentes lugares tengan claro para qué sirven - GhostInTheMachine ^{habla conmigo} 15:34, 16 de mayo de 2021 (UTC)
• Soporte . Consolidación sensata, ya que esta página no es tan activa y no parece tener una identidad y un propósito distintos de la mesa de ayuda / salón de té / resolución de disputas. el wub "?!" 00:13, 19 de mayo de 2021 (UTC)
• Apoyar la consolidación con el Help Desk. -  John M Wolfson  ( charla  •  contribuciones ) 14:44, 23 de mayo de 2021 (UTC)
• Apoyo Creo que los argumentos a favor de la consolidación son convincentes. - Trialpears ( charla ) 15:27, 23 de mayo de 2021 (UTC)
• Oponerse . EAR y la mesa de ayuda tienen diferentes propósitos. En la mesa de ayuda, pregunta "¿cómo puedo hacer esto?" En EAR, dices "No puedo hacer esto, ¿puede alguien hacerlo por mí?" Es cierto que algunos usuarios preguntan cosas en EAR que deberían haberse preguntado en la mesa de ayuda o en la casa de té, pero esa no es una razón para deshacerse de ellas. Maproom ( charla ) 07:45, 29 de mayo de 2021 (UTC)

  Entonces ... ¿duplica las solicitudes de edición? ProcrastinationReader ( charla ) 09:11, 29 de mayo de 2021 (UTC)

La discusión anterior está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

Propuesta: Cerrar la mesa de ayuda y reemplazarla por Teahouse

Encuentro un claro consenso en contra de esta propuesta. Los editores sienten que la mesa de ayuda y la casa de té tienen diferentes propósitos, culturas y destinatarios. Escrito extraordinario ( charla ) 18:07, 25 de mayo de 2021 (UTC) ( cierre no administrativo )

La siguiente discusión está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

---

Antes de comenzar, sé que esto definitivamente va a ser muy constrovertido, y solo quiero publicarlo para obtener comentarios al respecto. La casa de té parece un gran reemplazo para la mesa de ayuda, el sistema de hosts funciona bien, hay un buen proceso de incorporación para nuevas preguntas y se ve bastante acogedor en general. Creo que la consolidación de la mesa de ayuda y la casa de té también ayudaría a generar cierta confusión sobre dónde hacer preguntas. ¿Pensamientos? EpicPupper ( charla ) 04:44, 9 de mayo de 2021 (UTC)

• Me opongo firmemente a esto. Ayudo en ambos lugares ocasionalmente y están destinados a diferentes situaciones (usuarios nuevos frente a usuarios experimentados). No hay necesidad de fusionarlos y hacerlo solo agregaría frustración. Elli ( charla | contribuciones ) 21:16, 12 de mayo de 2021 (UTC)
• Oponerse y no. Huggums537 ( charla ) 21:58, 12 de mayo de 2021 (UTC)
• Oponerme si quiero ayuda voy a un servicio de asistencia. Si quiero té, voy a una casa de té. DuncanHill ( charla ) 22:03, 12 de mayo de 2021 (UTC)
• Me opongo incluso ahora, si necesito ayuda en un tema en el que no sé nada sobre el campo en absoluto (las imágenes en 3D fueron un ejemplo), voy a la casa de té, porque los ayudantes allí saben comenzar desde los primeros principios. Pero para la mayoría de mis preguntas, solo necesito saber cómo manejar un caso límite específico; no sería deseable revisar todos los derechos de autor como un manual básico, así que lo pregunto en el servicio de asistencia, etc.Nosebagbear ( charla ) 12:31, 13 Mayo de 2021 (UTC)
• Oponerse . Las culturas de estos dos lugares de ayuda son distintas. Help Desk atiende a editores experimentados y novatos en Teahouse. Al responder en estos lugares, no necesito verificar las credenciales de los editores que preguntan y adaptar mi respuesta en consecuencia porque se supone. -  Finnusertop ( charla ⋅ contribuciones ) 12:48, 13 de mayo de 2021 (UTC)
• Opuesto por Nosebagbear y Finnusertop. MB 13:24, 13 de mayo de 2021 (UTC)
• Oponerse a. La mesa de ayuda está diseñada intrínsecamente y funciona como un lugar al que deben acudir todos los editores, incluidos los experimentados. Teahouse es específicamente para nuevos editores que necesitan ayuda básica. --- Sm8900 ( hablar ) 🌍 14:31, 13 de mayo de 2021 (UTC)
• Oponerse a lo anterior, tienen dominios claramente definidos y distintos, y ambos son muy activos. Tampoco es necesario apagarlo. - Jayron 32 14:32, 13 de mayo de 2021 (UTC)
• Oponerse Los dos lugares están destinados a ser de carácter diferente: GhostInTheMachine ^{habla conmigo} 15:36, 16 de mayo de 2021 (UTC)
• Oponerse . The Teahouse tiene una cultura e identidad distintas, cuya investigación ha demostrado ser eficaz para retener nuevos editores. La fusión en la mesa de ayuda diluiría esto y reduciría su efectividad. el wub "?!" 00:14, 19 de mayo de 2021 (UTC)

La discusión anterior está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

Propuesta: Reemplazar el enlace de la mesa de ayuda de la página principal por el enlace Teahouse

• Soporte Mientras estamos aquí: para dar seguimiento a esta discusión que se cerró con consenso para agregar un enlace Teahouse, pero no estaba seguro de qué forma debería tomar. Parece que probablemente haya un consenso para mantener TH y HD separados por ahora. Así que creo que sería mejor reemplazar el enlace de la mesa de ayuda en la página principal con un enlace a Teahouse. Los editores que vienen de allí probablemente sean recién llegados, y es demasiado confuso / abultado tener a ambos en la lista tratando de explicar las diferencias, en mi opinión. ProcrastinationReader ( charla ) 07:46, 24 de abril de 2021 (UTC)
• Comentario Aunque estoy feliz de apoyar esto, estoy un poco preocupado por eliminar por completo el enlace de la mesa de ayuda. ¿No funcionaría bien lo siguiente ?:

  • Portal de la comunidad : tablón de anuncios, proyectos, recursos y actividades que cubren una amplia gama de áreas de Wikipedia.
  • Mesa de ayuda : haga preguntas sobre el uso de Wikipedia.
  • Teahouse : una mesa de ayuda para editores novatos. Un espacio amigable para preguntar sobre la edición de Wikipedia.
  • Embajada local : para comunicaciones relacionadas con Wikipedia en idiomas distintos del inglés.
  • Escritorio de referencia : los voluntarios de Wikipedia, que actúan como bibliotecarios virtuales, abordan sus preguntas sobre una amplia gama de temas.
  • Noticias del sitio : anuncios, actualizaciones, artículos y comunicados de prensa en Wikipedia y la Fundación Wikimedia.
  • Bomba de aldea : para debates sobre Wikipedia en sí, incluidas áreas para cuestiones técnicas y políticas.

  No quisiera socavar ningún intento de lograr un consenso ofreciendo una contrapropuesta formal en esta etapa inicial, pero agregue una si ayuda. Nick Moyes ( charla ) 09:12, 24 de abril de 2021 (UTC)

  Esto funciona para mí, aunque diría que coloque Teahouse por encima de HD en orden y reemplace la descripción de la mesa de ayuda con algo como "Para que los editores más experimentados hagan preguntas sobre la edición de Wikipedia". Sigo pensando que prefiero reemplazar el enlace por completo, ya que creo que Teahouse hace un mejor trabajo para ayudar a los novatos y que dar opciones innecesarias es una mala experiencia de usuario y agrega un poco de fricción. ProcrastinationReader ( charla ) 09:44, 24 de abril de 2021 (UTC)

• Apoya un enlace. Oponerse a dos vínculos. No necesitamos ni deberíamos tener dos foros para hacer preguntas (por lo que la mesa de ayuda y la casa de té deberían fusionarse). Si tenemos dos foros, TH debería estar vinculado en la página principal (así que apoye esta propuesta). Bajo ninguna circunstancia deben vincularse ambos; eso solo confundirá a la gente. Levivich  ^acoso / _sabueso 13:24, 24 de abril de 2021 (UTC)
• Apoye el enlace Teahouse en la página principal y , si tenemos ambos enlaces, colóquelo encima de la mesa de ayuda. Si conservamos ambos, la línea de propaganda del Helpdesk debería incluir algo que sea para editores no novatos. Soy neutral a la hora de eliminar el Helpdesk de la página principal y tener Teahouse allí. Nosebagbear ( charla ) 14:02, 24 de abril de 2021 (UTC)
• No apoyo esta sugerencia de buena fe y bien intencionada. Apoyo la adición de un enlace adicional a la casa de té y no tengo ninguna objeción a colocar ese enlace encima del enlace de la mesa de ayuda. Pero siempre que la mesa de ayuda esté abierta y queramos que los editores la usen, entonces debemos vincularla. Recomiendo encarecidamente una discusión separada centrada únicamente en si podemos y debemos consolidar estos dos esfuerzos; Apoyaría firmemente tal moción, pero parece ser una propuesta mucho más amplia que la que se ha presentado aquí que amerita una discusión dedicada y separada con un encabezado claro para que otros editores puedan ver lo que se está proponiendo. ElKevbo ( charla ) 02:59, 25 de abril de 2021 (UTC)

  Tenemos enlaces a la mesa de ayuda, desde páginas internas como WP: Preguntas , Plantilla: páginas de ayuda de Wikipedia , Plantilla: Enlaces de tablón de anuncios , etc. La propuesta no es eliminar todos esos enlaces. Es solo para reemplazarlo en la página principal específicamente, desde donde es más probable que obtengamos clics de recién llegados en lugar de cualquier otra cosa. ProcrastinationReader ( charla ) 15:32, 25 de abril de 2021 (UTC)

• Enlace a ambos, pero coloque la Casa de té encima de la mesa de ayuda. Agregar otra línea no dañará el diseño, pero permitirá que más personas obtengan la asistencia que necesitan. - Naddruf ( talk ~ contribs ) 17:11, 25 de abril de 2021 (UTC)
• Más comentarios sobre la redacción de la página principal No estoy seguro de qué palabras son las mejores si la casa de té se ubica por encima del servicio de asistencia en los enlaces de la página principal. Me he devanado la cabeza y esto es lo mejor que se me ocurre:

  • Teahouse : una mesa de ayuda para editores novatos. Un espacio amigable para preguntar sobre la edición de Wikipedia.
  • Mesa de ayuda : haga preguntas sobre el uso de Wikipedia. Dirigido principalmente a aquellos que ya tienen algo de experiencia en edición.

  (o tal vez ... * Mesa de ayuda : haga preguntas sobre el uso de Wikipedia. ¡Menos amigable, más cortante y toneladas de abreviaturas!) Nick Moyes ( charla ) 00:19, 26 de abril de 2021 (UTC)

  ¿Puede la redacción de Teahouse ser simplemente "Un espacio amigable para que los nuevos editores pregunten sobre la edición de Wikipedia"? - Naddruf ( talk ~ contribs ) 16:21, 28 de abril de 2021 (UTC)

• Apoye la eliminación del enlace de la mesa de ayuda y su reemplazo por un enlace a la casa de té. Es probable que la página principal sea el lugar donde los nuevos editores buscarán información. Los editores experimentados aún pueden acudir manualmente a la mesa de ayuda. EpicPupper 20:26, 27 de abril de 2021 (UTC)
• Soporte por Epicpupper. Dos enlaces es confuso, y el mejor de los dos enlaces de la página principal es la casa de té. Calliopejen1 ( charla ) 04:21, 30 de abril de 2021 (UTC)
• Enlace de soporte para ambos según lo propuesto por Nick Moyes aquí . Mi lógica es que necesitamos dos lugares diferentes para obtener respuestas avanzadas o principiantes. Como nuevo usuario, me alegra saber que existe la mesa de ayuda. He estado yendo a la Casa de Té en busca de respuestas, y aunque aprecio la manera amistosa y servicial, apesta un poco ser tratado como un usuario de IP del primer día que recibe respuestas con cuchara. Ahora sé que tengo un lugar al que puedo ir para obtener respuestas que pueda manejar. Creo que a otros usuarios también les gustará saber esto. Huggums537 ( charla ) 14:48, 1 de mayo de 2021 (UTC)
  • Pero no aprendió esta información de un enlace en la página principal, y otros editores establecidos tampoco lo harán. - Bilorv ( conversación ) 23:18, 1 de mayo de 2021 (UTC)
    • Pero aún así, aprendí sobre Teahouse en mi página de discusión, y si hubiera habido un enlace descriptivo Teahouse en la página principal con un enlace descriptivo de Help Desk que contrasta justo debajo, lo más probable es que lo hubiera captado mucho antes. Huggums537 ( charla ) 12:31, 2 de mayo de 2021 (UTC)
• Soporte : es preferible solo un enlace a Teahouse (no confunda a las personas antes de que hayan hecho clic en un foro de ayuda, porque no saben cuál es el adecuado para ellos) pero un enlace a Teahouse y Help Desk sería una mejora, ya que la casa de té es más amigable. - Bilorv ( conversación ) 23:18, 1 de mayo de 2021 (UTC)
• Apoyaría el reemplazo con algo como {{tq | ¿Necesitas ayuda? Pruebe nuestro foro de ayuda para nuevos usuarios o nuestro foro de ayuda para usuarios más experimentados . G M G ^talk 22:39, 2 de mayo de 2021 (UTC)

  Creo que GreenMeansGo ofrece una solución interesante. Huggums537 ( charla ) 00:01, 3 de mayo de 2021 (UTC)

Admite el reemplazo del enlace ... solo se necesita uno y la casa de té es mejor en la contratación de nuevos editores. El año pasado ha visto un buen aumento en la cantidad de ediciones individuales pero una disminución en el registro ... quizás la Casa de Té pueda ayudarnos a solucionar este problema. Moxy - 23:08, 2 de mayo de 2021 (UTC)

• Soporte . La casa de té es prácticamente la casa de compensación ahora. Guy ( ¡ayuda! - ¿error tipográfico? ) 20:18, 3 de mayo de 2021 (UTC)
• Soporte , me sorprendería que los editores experimentados no supieran acerca de la mesa de ayuda, y más aún si estuvieran accediendo a ella desde la página principal. El acceso a los lugares de ayuda desde la página principal parece algo más dirigido a los usuarios más nuevos, de ahí el uso de un enlace a la casa de té. Aza24 ( charla ) 22:21, 3 de mayo de 2021 (UTC)
• Admite dos enlaces, con el enlace Teahouse arriba y el enlace de la mesa de ayuda que dice algo como "para preguntas más avanzadas". Ganesha811 ( charla ) 01:09, 5 de mayo de 2021 (UTC)
• Oponerse a The Teahouse tiene un nombre engañoso ya que no parece haber ninguna actividad social o grupal y ciertamente no hay té. Cuando asisto a maratones físicos, las pausas para el té y el café son lo mejor, ya que compartir refrigerios es una buena manera de establecer vínculos e interactuar con otros editores. The Teahouse en realidad parece ser solo una junta de preguntas y respuestas desenfocada. Ya tenemos muchos de aquellos con nombres más precisos, como Help Desk y Reference Desk. Andrew 🐉 ( charla ) 08:54, 5 de mayo de 2021 (UTC)

  La falta de té es realmente angustiosa. ¿Quizás debería cambiarse el nombre a Coffeehouse para que en su lugar podamos estar angustiados por la falta de café? - GhostInTheMachine ^{me habla a las} 18:01, 5 de mayo de 2021 (UTC)

• Oponerse Agregue un enlace a Teahouse a los 6 enlaces que ya se encuentran en la sección Otras áreas de Wikipedia en la página principal , como lo propuso Nick Moyes desde el principio, GhostInTheMachine ^{hable conmigo} 18:07, 5 de mayo de 2021 (UTC)
• Oponerse a eliminar el enlace de la mesa de ayuda. Apoyar la adición de un enlace adicional a la casa de té. - Jayron 32 14:33, 13 de mayo de 2021 (UTC)
• Fuerte oposición a la vinculación a ambos, débil apoyo para cambiar a Teahouse . Amigos, hemos pasado por esto antes, donde no podemos ponernos de acuerdo sobre el mejor enlace de ayuda para usar, por lo que terminamos incluyendo dos enlaces de ayuda muy similares, y muy pronto los recién llegados se sienten abrumados con opciones redundantes y sucumben a la parálisis de las opciones . Pase lo que pase aquí, no deje que ese sea el resultado: un solo enlace a TH o HD es muy superior a enlazar a ambos. En cuanto a qué lugar enlazar, no creo que los hayamos diferenciado lo suficientemente claramente como para poder decir con certeza cuál es el más apropiado. De jure, probablemente sea la mesa de ayuda, ya que teóricamente cualquiera podría estar buscando ayuda en la página principal, pero de facto, probablemente sea la casa de té, ya que en realidad son básicamente solo los recién llegados que usan ese enlace. {{u | Sdkb }}  ^charla 05:13, 14 de mayo de 2021 (UTC)
• Oponerse a Agregar el enlace Teahouse y actualizar las descripciones de los enlaces Helpdesk y Teahouse para aclarar la distinción - GhostInTheMachine ^{habla conmigo} 15:44, 16 de mayo de 2021 (UTC)
• Soporte usando el enlace Teahouse. Es más probable que los usuarios que vienen de la página principal sean novatos, por lo que tiene sentido dirigirlos al foro diseñado para ellos. La mesa de ayuda no va a desaparecer para usuarios más experimentados. el wub "?!" 00:15, 19 de mayo de 2021 (UTC)
• Comentario : parece haber un número aproximadamente igual de editores aquí que cuestionan qué enlaces usan o es probable que usen otras personas , y extraen conclusiones diametralmente opuestas. Prueba, si fuera necesario, de que ninguno de nosotros sabe realmente cuál es la mejor idea. Desde la perspectiva del diseño de un sitio web, podría ser una buena idea probar ambos enlaces e incluir algún tipo de datos de referencia . Tomando prestada la sugerencia de GreenMeansGo, podría verse así: diseño Need help? Try our [[WP:THQ#RefMain|Help forum for new users]] or our [[WP:HD#RefMain|Help forum for more experienced users]] nagual 19:47, 25 de mayo de 2021 (UTC)

nagualdesign La forma más fácil de rastrear los enlaces en los que las personas hacen clic sería canalizar los enlaces a través de algunas redirecciones estadísticas , como hicimos cuando queríamos ver si alguien estaba usando el banner COVID-19. 192.76.8.73 ( conversación ) 23:18, 25 de mayo de 2021 (UTC)

¡Gran idea! diseño nagual 23:23, 25 de mayo de 2021 (UTC)

• Soporte Como la casa de té es más útil para los editores más nuevos, debería reemplazar el enlace de la mesa de ayuda, mi segunda opción es agregar el enlace de la casa de té mientras mantengo el enlace de la mesa de ayuda. Jackattack1597 ( charla ) 10:58, 4 de junio de 2021 (UTC)
• El soporte funciona para mí. ~ HAL 333 04:39, 8 de junio de 2021 (UTC)

dejar las cosas hasta que el equipo de crecimiento presentado esté completamente implementado

WP: Las herramientas de tutoría brindan a los nuevos usuarios un camino mucho más fácil para obtener ayuda. Es posible que desee dejar que se estabilicen en la producción antes de realizar cambios importantes. - xeno ^talk 13:47, 30 de mayo de 2021 (UTC)

Como EpicPupper (él / él | charla , preguntas frecuentes , contribuciones ) 21:35, 9 de junio de 2021 (UTC)

RfC: mirada de control de autoridad

Hay suficiente apoyo (entre los votantes A / B) para usar el nuevo estilo propuesto como punto de partida, en espera de otras mejoras propuestas y discutidas en la página de discusión de la plantilla. Actualmente no hay consenso sobre el comportamiento de colapso predeterminado. - Martin ( MSGJ  ·  charla ) 10:03, 7 de junio de 2021 (UTC)

La siguiente discusión está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

---

¿Se puede utilizar el nuevo estilo de la Plantilla: control de autoridad , como se demuestra en los artículos de esta lista , en lugar del estilo actual (utilizado en estos )? Este es un seguimiento de este RfC , que tenía consenso sobre los principios generales detrás del rediseño, pero aún no tenía un diseño definitivo para acordar. Fram ( charla ) 07:36, 7 de mayo de 2021 (UTC)

• A : el nuevo estilo propuesto
• B : el nuevo estilo, pero colapsado automáticamente
• C : algo más

Discusión (aspecto de control de autoridad)

• Soporte A, segunda opción B, como iniciador RfC. Después del RfC, hubo discusiones y propuestas en la página de discusión de la plantilla, con la versión como ahora (temporal) implementada en la subplantilla "Arts" como un compromiso entre los resultados de RfC y algunos extras que se querían (como acomodar múltiples ID de una institución, o manteniendo el vínculo explicativo para algunos de los acrónimos más oscuros). Artículos como Pablo Picasso dan una idea de cómo sería el nuevo look: en muchos artículos, por supuesto, será más pequeño. Todavía hay desacuerdo sobre si la nueva versión puede implementarse ahora o si primero necesita un RfC, así que aquí estamos. Si no es compatible con el nuevo diseño, indique cómo mejorarlo respetando el resultado del RfC anterior. Por favor, no litigar RFC anterior, sin embargo, si es posible. Fram ( charla ) 07:42, 7 de mayo de 2021 (UTC)
• Oponerse : da, en el espacio principal, demasiada prominencia a un aspecto bastante técnico: el nuevo diseño le da aún más ancho de banda a esto que el diseño anterior. Sugerencias:
  1. En el control de #Autoridad anterior se planteó la pregunta de si deberíamos tener esta plantilla en absoluto. Ese ya era uno de los puntos siguientes del RfC anterior: sugeriría hacer esa pregunta en un RfC formal (que puede ir en otra dirección que la discusión informal actual), antes de que este segundo RfC sobre el diseño avance.
  2. En Andy Warhol # Enlaces externos (solo tomando el primer ejemplo de la lista propuesta en el OP ), el nuevo diseño se muestra * sin contraer * debajo de dos navboxes colapsados: para Wikipedia estos navboxes (internos) son mucho más importantes que los (externos) identificación única (que puede ser manejada por WikiData): * como mínimo * el nuevo diseño debe mostrarse colapsado, * como mínimo * siempre colapsando automáticamente cuando el artículo contiene un navbox interno de cualquier tipo.
  3. El esquema de color del cuadro de control de autoridad (diseño nuevo y antiguo) sigue el esquema de color estándar de los cuadros de navegación internos: el esquema de color debe ser * diferente * (como en: un esquema de color que normalmente no se usa en los cuadros de navegación internos) y * menos conspicuos * (colores que no llaman la atención en absoluto), proponiendo así usar solo colores de fondo en escala de grises en la plantilla (en lugar de los colores de fondo violáceos ahora). El control de autoridad es un aspecto bastante técnico (no es realmente contenido de enciclopedia como tal), y colores de fondo menos coloridos serían una mejor indicación para ello.

- Francis Schonken ( charla ) 08:49, 7 de mayo de 2021 (UTC)

• Oponerse , incluso dejando de lado que el punto de control de autoridad no son los enlaces a los sitios de AC, sino los valores de identificadores únicos , que este diseño propuesto oculta, el nuevo diseño ocupa demasiado espacio en demasiados casos, lo que hace que haya varias filas de tablas donde una se utiliza actualmente, a menudo con un solo identificador en cada uno; los proponentes de este cambio innecesario han reconocido que no han investigado cuántos casos de este tipo existen. También elimina enlaces a artículos de Wikipedia que explican los orígenes y el uso de esos identificadores (ejemplo en la página de discusión de la plantilla). El cierre de la RfC anterior declaró explícitamente que había "no hay consenso sobre la forma exacta que podría tomar una versión mejorada". La insistencia en que cualquiera que no apruebe el nuevo diseño debe proporcionar alternativas es falsa; a menos que se haga una propuesta mejor y se cumpla con la aprobación de la comunidad , el status quo se aplica. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 10:24, 7 de mayo de 2021 (UTC)
  • No creo que encuentre mucha gente que esté de acuerdo en que el objetivo de AC son los valores, no los vínculos. Los enlaces sin los valores (es decir, esta propuesta y la aceptada en el RfC) son o pueden ser útiles para obtener información adicional; los valores sin los enlaces simplemente llevarían a que esta plantilla se elimine (o en el mejor de los casos oculta a la vista, como persondata en los viejos tiempos) en un abrir y cerrar de ojos como un desorden completamente inútil. No se "reconoció" nada en la forma en que afirma, y ​​no menciona que "uno se usa actualmente" es una forma bastante unilateral de presentar la plantilla actual, donde a menudo tiene una "fila" que se muestra sobre varios " líneas "de todos modos (dependiendo del número de entradas, obviamente, y del ancho de la pantalla y el tamaño de la fuente).
  • Hay consenso, aprobación de la comunidad, para un nuevo diseño muy parecido al propuesto ahora, y hay aprobación de la comunidad para deshacerse de la versión actual. Oponerse al nuevo diseño sin proporcionar alternativas que respeten el resultado del RfC anterior es simplemente estancarse para obtener el resultado que desea, el status quo ya rechazado. Fram ( charla ) 10:40, 7 de mayo de 2021 (UTC)
    • "No creo que encuentre mucha gente que esté de acuerdo en que el objetivo de AC son los valores" Quizás; talvez no. Pero cualquiera que se haya tomado el tiempo de entender qué es AC sabrá que es así, y eso es lo importante.
    • No había consenso para una vaga propuesta para una nueva disposición no especificada, pero como todos sabemos, el consenso puede cambiar, y ahora lo que necesita para demostrar el consenso para una determinada propuesta. La gente puede elegir eso, o una alternativa si surge, o el status quo si se considera que es la mejor opción. Hasta ahora lo es. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 10:53, 7 de mayo de 2021 (UTC)
• Oponerse Los problemas discutidos en la página de discusión deben resolverse primero: en particular, la nueva plantilla tiene muchos más espacios en blanco que la anterior , y no incluye enlaces a los artículos relevantes (y la discusión en esa página de discusión ha sido innecesariamente dramático, lo cual no es una sorpresa dada la gente involucrada en esta reescritura). Mi preferencia sería volver a la versión anterior, que también mostraba los valores de ID (lo cual es útil), y simplemente cambiar las siglas a las palabras utilizadas por la nueva plantilla, que cumple con el consenso del RfC anterior. Gracias. Mike Peel ( charla ) 10:34, 7 de mayo de 2021 (UTC)
  • El colapso automático sería aún peor, ya que escondería el contenido. Hacerlo más pequeño, como la versión anterior, es una solución mucho mejor. Gracias. Mike Peel ( charla ) 10:55, 7 de mayo de 2021 (UTC)
• Nota : He agregado opciones arriba, ya que "es demasiado grande" parece ser el tema común aquí. @ Pigsonthewing , Mike Peel , y Francis Schonken : . Fram ( charla ) 10:51, 7 de mayo de 2021 (UTC)
  • Parece que se olvidó de agregar " D : sin cambios". Su RfC ya no es neutral, como se requiere. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 10:55, 7 de mayo de 2021 (UTC)
• ¿Y por qué se ha implementado este nuevo diseño, sin consenso sobre los 14K artículos que usan {{ Control de autoridad (artes) }}? Ese cambio descrito como una "prueba" debe revertirse de inmediato. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 11:06, 7 de mayo de 2021 (UTC)
  • He revertido esto ya que las cajas de arena * nunca * deben usarse en el espacio principal, particularmente en tantos artículos. Mike Peel ( charla ) 11:26, 7 de mayo de 2021 (UTC)
    • Tenga en cuenta que esto ahora usa una bifurcación de {{ Control de autoridad }}, en {{ Control de autoridad (artes) Maestro }}. Si eso no es temporal, probablemente Wikipedia: Templates_for_discussion / Log / 2021_February_26 # Template: ACArt debería revisarse . Mike Peel ( charla ) 12:34, 7 de mayo de 2021 (UTC)
      • Por supuesto que eso es temporal. Fram ( charla ) 12:42, 7 de mayo de 2021 (UTC)
        • Solo para tener en cuenta que esto está en Wikipedia: Templates_for_discussion / Log / 2021_May_7 # Template: Authority_control_ (arts) _Master . Mike Peel ( charla ) 13:14, 7 de mayo de 2021 (UTC)
• Tenga en cuenta que, habiendo aprendido de muchas experiencias anteriores, no responderé a los comentarios de Pigsonthewing y Mike Peel, ya que parecen incapaces o no quieren publicar sobre la plantilla sin agregar comentarios sarcásticos o ataques directos a las personas con las que no están de acuerdo ( solo lea sus respuestas arriba u otras discusiones relacionadas). Por favor, tome todo lo que escriban aquí con un gran grano de sal. Fram ( charla ) 11:10, 7 de mayo de 2021 (UTC)
  • Tenga en cuenta que esto no es cierto, sin embargo, Fram tiene una larga historia de hacer * exactamente lo que dicen de Andy y de mí * en cualquier discusión sobre Wikidata. Este acoso ha estado ocurriendo durante años. Generalmente es mejor concentrarse en los hechos que en el drama, pero desafortunadamente no pueden evitarlo. Mike Peel ( charla ) 11:21, 7 de mayo de 2021 (UTC)
  • Y solo 92 minutos después, Fram responde a Mike Peel . Menciono esto porque debe tenerse en cuenta que Fram responderá cuando así lo decidan; lo que significa que la falta de respuesta a otras publicaciones (como la mía señalando que su RfC, por lo tanto, ya no es neutral; o que el consenso específicamente para lo que ahora proponen debe demostrarse)) es selectiva, y no es para el (falso ) motivo indicado inmediatamente arriba. Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 13:01, 7 de mayo de 2021 (UTC)
• Fram, creo que hubiera sido mejor hacer el AC RfC en la parte superior primero. Si el aire acondicionado se va a desechar o cambiar a una forma completamente diferente, entonces perder tiempo tratando de rediseñarlo es en vano. Creo que se requiere este RfC (o eso se siente) es algo IDHT: la voluntad del RfC anterior sobre el diseño era bastante clara, por lo que realmente no veo por qué esto es necesario. ProcrastinationReader ( charla ) 11:16, 7 de mayo de 2021 (UTC)
• Oponerse a. Aún no se ha alcanzado el consenso, como se solicitó , @ Plantilla de charla: control de autoridad , entonces, ¿por qué estamos teniendo un RfC prematuro?
  • Oponerse a cualquier cambio que atraiga el colapso automático de un 1-QID AC (vea los atractivos comentarios ya recibidos).
  • Oponerse a wikilinks incompletos - en Claus Sluter # Enlaces externos , ¿por qué VIAF tiene wikilink, pero Integrated Authority File , WorldCat , etc., no? Integrated Authority File no menciona "Integrated Authority File", entonces, ¿qué es?
  • Oponerse a un aumento de tamaño espectacular y espacios en blanco gratuitos: en los enlaces externos de Claus Sluter # , {{ Control de autoridad (artes) / zona de pruebas }} es TRES VECES (~ 3,25x) del tamaño de {{ Control de autoridad (artes) }}:

   ~   Tom.Reding ( talk ⋅ dgaf )   11:52, 7 de mayo de 2021 (UTC)

• ¿Por qué debería haber consenso en la página de discusión de la plantilla antes de iniciar un RfC aquí? Era obvio que ese consenso no era posible allí, con las mismas pocas personas discutiendo entre sí. El RfC anterior (también comenzó sin consenso, y ustedes tres se han quejado de eso) mostró claramente que la opinión de ustedes tres no está sincronizada con la de muchos otros editores. Ha llegado el momento de recopilar aportaciones más amplias en lugar de chocar una y otra vez sobre los mismos problemas. Fram ( charla ) 12:15, 7 de mayo de 2021 (UTC)

• " Ha llegado el momento de recopilar aportaciones más amplias en lugar de chocar una y otra vez sobre los mismos problemas. "- AKA WP: FORUMSHOPPING .    ~  Tom.Reding ( talk ⋅ dgaf )   12:52, 7 de mayo de 2021 (UTC)

• Entonces, ¿eso es uno OPONENTE y tres SUBCONFERENCIAS? ¿Le gustaría papas fritas con eso? -  JohnFromPinckney ( charla ) 12:23, 7 de mayo de 2021 (UTC)

• COMENTARIO - creo que necesita este RFC para ser puesto en “espera” ... es contraproducente, dado que en la actualidad tenemos una abierta RFC (arriba) sobre si se debe tener ningún plantillas de AC en nuestros artículos. No importará cómo se vea la plantilla si el consenso en el RFC anterior es no tenerla en absoluto . Blueboar ( charla ) 12:49, 7 de mayo de 2021 (UTC)
  • No veo un RfC, pero obviamente si hay una propuesta para eliminar esto de 1 punto, sin embargo, un millón de páginas, debería haberlo (más CENT, yada yada). - ^{Hablar de las} rododendritas \\ 13:07, 7 de mayo de 2021 (UTC)

    No es un RFC todavía per se. Quería 'probar las aguas', porque sabía que se convertiría en lo que tiene, pero quería algo de tiempo para que algunas personas menos involucradas opinaran, particularmente sobre opciones viables. Supongo que, por definición, sería más adecuado en el laboratorio de ideas, pero no conozco ese lugar para tener éxito en lograr mucho, así que quería probar esto. No creo que un RfC normal (es decir, una encuesta / estilo de discusión) sea concluyente, en parte debido a las personalizaciones persistentes, por lo que todavía estoy pensando en qué forma debería tomar. También hay una lluvia de ideas por parte de las partes menos involucradas y tal vez eso podría ayudar a cerrar algunas brechas entre las diferentes opiniones sobre esta plantilla. En cualquier caso, obviamente quería llevar algún aspecto de la propuesta a un RfC ... ProcrastinationsReader ( charla ) 13:21, 7 de mayo de 2021 (UTC)

    • Lo siento, mi culpa ... Hay una discusión en curso (arriba) sobre si tener (o no tener) la plantilla, y asumí que era un RFC. Gracias por señalar que no lo es.

Entonces, cambiaré mi comentario a: "C" - algo más (mi preferencia sería proporcionar un enlace simple a Wikidata - similar a cómo enlazamos a los comunes para las imágenes - en lugar de alojar las cosas de AC directamente en nuestros artículos) Blueboar ( charla ) 14:20, 7 de mayo de 2021 (UTC)

• Un poco reacios A , supongo. No contraído de forma predeterminada, pero si debe o no contraerse se deja en una base artículo por artículo. Definitivamente abierto a C , también, si alguien tiene otras ideas. No estoy totalmente de acuerdo con la declaración final del último RfC. Hubo un claro apoyo para la declaración de RfC acerca de hacer que esta plantilla sea fácil de usar, pero la mayoría de las personas en realidad no hablaron específicamente sobre el ejemplo proporcionado (y muchos de los que lo hicieron destacaron problemas con él). Pero ese RfC es lo que tenemos, y nadie ha desafiado al AFAIK cercano. Entonces, tenemos la idea de que debemos hacerlo más fácil de usar y un ejemplo para usar como un punto de partida aproximado para la discusión de cómo debería verse. Al mismo tiempo, creo que hay muchas personas a las que les gusta la idea de la facilidad de uso, pero en realidad no pensaron en el tamaño que podrían tener algunas de estas plantillas. Si el diseño de la versión anterior de la plantilla tenía una virtud era ser compacto, por supuesto. Así que sospecho que la facilidad de uso puede hacer que, en última instancia, sea más fácil para aquellos que quieran eliminarlo de la página convencer a otros, irónicamente. Ya veremos, supongo. - ^{Hablar de las} rododendritas \\ 13:07, 7 de mayo de 2021 (UTC)
• Apoyo A Este RfC constituye un foro de compras (por parte de los opositores del RfC original, no de Fram) en un intento de anular el claro consenso del primer RfC. Como escribí en la página de discusión de la plantilla , el RfC [original] muestra un claro consenso de que la caja de arena es preferible al statu quo . Ese consenso no debe ser anulado por unos pocos objetores vociferantes en la página de discusión. También apoyo débilmente a B , sobre la base de que, citando nuevamente a mí mismo de la página de discusión de la plantilla , No [veo] ninguna razón para desviarme del comportamiento estándar del navbox (de auto-colapso cuando hay dos o más navbox y no colapsar cuando solo hay un navbox). * Pppery * _{ha comenzado ...} 13:55, 7 de mayo de 2021 (UTC)
  • Fram iniciar un RfC (ni tampoco cambiarlo más tarde para que no sea neutral) no soy yo ni nadie más comprando en el foro. Cuando escribiste eso en la página de discusión, respondí [énfasis en el original]: La carga recae en ti para mostrar consenso sobre el cambio que propones hacer (y no solo para un cambio ). Tenga en cuenta también que el RfC no habló en absoluto sobre la versión actualmente en el sandbox, que no se presentó allí; de hecho, declaró explícitamente que había "no hay consenso sobre la forma exacta que podría tomar una versión mejorada". . Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 15:54, 7 de mayo de 2021 (UTC)
• A , mirando los ejemplos a continuación. Es mucho más legible por humanos y yo lo llamaría una mejora incremental con respecto a la plantilla anterior. Creo que el comportamiento de colapso automático predeterminado está bien (colapsar cuando no es la única plantilla de pie de página). Sin embargo, también creo que deberíamos buscar un RFC basado en la discusión anterior aquí arriba, ya que hay algunas alternativas (como un enlace a wikidata o una página enwiki intermedia) que podrían hacer que el rediseño de CA sea discutible. Levivich  ^acoso / _sabueso 16:28, 7 de mayo de 2021 (UTC)
  • B también está bien para mí, según los demás a continuación. Personalmente, no creo que sea un gran problema para mí si siempre está colapsado o si tiene el comportamiento predeterminado. Levivich  ^acoso / _sabueso 21:13, 9 de mayo de 2021 (UTC)
• R : aunque me gustan las plantillas de control de autoridad, no me gusta el hecho de que sean tan crípticas. Esto sería un gran aumento en la usabilidad a un costo relativamente pequeño de más "basura" en la parte inferior de una página. Guettarda ( charla ) 16:44, 7 de mayo de 2021 (UTC)
• B No creo que nuestros lectores usen mucho esta plantilla, diablos, no puedo recordar la última vez que usé una plantilla de control de autoridad. Esta plantilla debe permanecer fuera de la vista y fuera de la mente; si la gente realmente lo quiere, puede abrirlo. Francamente, toda la idea de Control de autoridad parece algo principalmente para uso interno, tal vez sería mejor poner esas plantillas en las páginas de discusión. CaptainEek ^{edita Ho Cap'n!} ⚓ 21:30, 8 de mayo de 2021 (UTC)
• B en la medida en que estamos haciendo este RfC, según CaptainEek. Segunda opción opción A, porque algo un poco más largo y ... inglés ... es mejor que algo más corto y automático. ProcrastinationReader ( charla ) 12:24, 9 de mayo de 2021 (UTC)
• B Según los comentarios anteriores. Sea Ane ( charla ) 19:56, 9 de mayo de 2021 (UTC)
• B parece el compromiso ideal para proporcionar información adicional e inmediatamente disponible a los lectores, sin ponérsela en la cara. Por supuesto, el diseño más accesible es ciertamente deseable para nuestros lectores, quienes seguramente se confundirán de otra manera. Aza24 ( charla ) 20:12, 9 de mayo de 2021 (UTC)
• B con A como segundo cercano. Según ProcrastinationReader anterior. La nueva versión es (supongo) sustancialmente más comprensible para la inmensa mayoría de la gente. Ajpolino ( conversación ) 15:55, 14 de mayo de 2021 (UTC)
• B Todos los ejemplos nuevos son menos desconcertantes que cualquiera de los anteriores. Autocollapse permite formatear en grupos lógicos sin ser ofensivamente grande la mayor parte del tiempo. La información permanece disponible pero discreta. · · · Peter Southwood ^(charla) : 08:22, 15 de mayo de 2021 (UTC)
• A (o posiblemente C, pero yo mismo no tengo una sugerencia, ¡es un problema difícil!) Me opongo al colapso automático: como muchos han señalado, el término "control de autoridad" no se entiende bien fuera de los bibliotecarios, y apenas proporciona una explicación a la usuario promedio de por qué querrían expandir la plantilla. Si comienza a expandirse, al menos es muy claro "oh, estos son enlaces / referencias cruzadas a otros sitios". Wikipedia no es papel, ningún árbol morirá por el espacio extra que se ocupe, la gente solo necesitará desplazarse unos milímetros más para ver las categorías o la emocionante propaganda legal del pie de página. (Aprecio que hay más problemas con el tamaño en dispositivos móviles, pero la plantilla no se muestra allí y, por lo que puedo decir, no hay planes para hacerlo). El wub "?!" 16:52, 23 de mayo de 2021 (UTC)

Ejemplos de

Desde la página de casos de prueba de la plantilla:

Viejo:

nuevo:

viejo:

nuevo:

- Andy Mabbett ( Pigsonthewing ); Habla con Andy ; Ediciones de Andy 16:21, 7 de mayo de 2021 (UTC)

Nota: los ejemplos anteriores son ficticios, estos no aparecen en un artículo real. El RfC se aseguró de que, junto al millón de ejemplos de la plantilla anterior, hubiera 14000 ejemplos de la nueva plantilla para verificar en artículos reales (ya que se dijo que el ejemplo anterior de RfC fue "seleccionado"), pero el 3 principales opositores de todos estos cambios han revertido todos los esfuerzos para hacerlo, alegando "interrupción" (la nueva versión funcionó tan bien como la versión a la que volvieron, y mostró el mismo número de AC). Básicamente, los 3 defensores del status quo están haciendo todo lo que está a su alcance para interrumpir esto (y el RfC anterior, y las discusiones en la página de discusión de la plantilla). Una situación muy agotadora, sobre la que comencé Wikipedia: Tablón de anuncios de los administradores / Incidentes # Pigsonthewing et al. . Quizás este RfC simplemente debería detenerse y reiniciarse y luego bajo la supervisión de algunos administradores neutrales, para evitar más interrupciones. Tal como están las cosas, las posibilidades de que alguien se interese en participar en este desastre son escasas, lo que probablemente era la intención.

Los ejemplos anteriores también son, para usar la terminología utilizada contra el RfC anterior, escogido. Las páginas de prueba también contienen algunos ejemplos igualmente ficticios:

vs.

Y

vs.

Fram ( charla ) 16:35, 7 de mayo de 2021 (UTC)

Tenga en cuenta que el gran ejemplo que menciona no es ficticio, es la plantilla de control de autoridad real utilizada en Douglas Adams . * Pppery * _{ha comenzado ...} 16:43, 7 de mayo de 2021 (UTC)

La discusión anterior está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

Restricción de cargas con licencia GFDL

Por qué GFDL no es práctico para los medios visuales

Esta es una propuesta para hacer algunas restricciones sobre la carga de nuevos archivos con licencia {{ GFDL }}, únicamente. ^[12]

GFDL fue diseñado originalmente para manuales de software y no es bueno para los medios porque dificulta la reutilización del material (vea el cómic a la derecha). Motivado por el deseo de facilitar la reutilización de archivos de acuerdo con la visión wiki mundial, la Junta de la Fundación Wikimedia decidió en 2009 dejar de usar GFDL como licencia única y permitir la importación de texto sin la licencia GFDL . La Junta de la Fundación Wikimedia no prohibió GFDL para archivos multimedia, pero alienta a las personas a usar licencias que no sean GFDL , por ejemplo, licencias CC.

La Junta de la Fundación Wikimedia mencionó explícitamente que cada wiki podría restringir el uso de GFDL. La Wikipedia en inglés ha eliminado GFDL de MediaWiki: Licenses y MediaWiki: Licenses / en-ownwork, pero los usuarios aún pueden agregarlo manualmente.

En septiembre de 2018, se sugirió desaprobar la licencia GFDL, pero en ese momento no se pudo formar un consenso para limitar GFDL en la Wikipedia en inglés.

Algunos de los argumentos en contra de las restricciones fueron:

1. Tenemos muchos archivos que no son gratuitos, entonces, ¿por qué no deberíamos permitir GFDL?
2. Si encontramos medios con licencia GFDL, no podremos copiarlos en Wikipedia.

Re 1) La idea de una wiki es compartir conocimientos libremente. ¡Esa es la razón por la que tenemos Wikipedia! El contenido no gratuito es una excepción según la política de licencias . Es algo que una comunidad puede decidir tener (no debe ) pero el uso debe ser mínimo. Entonces, si bien tenemos archivos que no son gratuitos, eso no es una razón para permitir que nadie otorgue una licencia para sus cargas con una licencia que no está en el espíritu de compartir conocimiento gratuito. Tampoco permitimos CC BY-NC o CC BY-ND .

Re 2) Técnicamente cierto, pero el uso de GFDL para archivos multimedia es virtualmente (si no completamente) inexistente fuera de Wikimedia. Cuando los archivos se cargan como GFDL en 2021, es porque es una copia o un derivado de otro archivo de otro proyecto wiki o porque el cargador ha elegido específicamente usar GFDL.

Varios proyectos ya han restringido el uso de GFDL, por ejemplo, la Wikipedia japonesa , Commons y Wikivoyage . Es probable que otros proyectos estén esperando a ver qué hace Wikipedia en inglés.

La sugerencia es esta:

No se permite GFDL como la única licencia aceptable cuando se cumplen todas las condiciones siguientes:

• La licencia del contenido se obtuvo a partir del 1 de julio de 2021. Se considera la fecha de licencia, no la fecha de creación o carga.
• El contenido es principalmente una fotografía, pintura, dibujo, audio o video.
• El contenido no es un logotipo de software, diagrama o captura de pantalla que se extrae del software GFDL o ^[13] un manual del software GFDL.

Lo anterior no restringe el uso no gratuito del contenido. Si un trabajo que no es un trabajo derivado con una licencia GFDL se usa bajo una justificación no libre, no tiene que reducirse, pero se seguirán aplicando otras limitaciones no libres.

La posibilidad teórica de un futuro contenido con licencia GFDL que sería elegible para la inclusión no gratuita se ha planteado como un argumento en el pasado y este es un compromiso que, con suerte, mitigará eso.

No soy un hablante nativo de inglés, por lo que si hay errores tipográficos o una mala redacción, puede solucionarlo. ¡Gracias! - MGA73 ( conversación ) 16:37, 10 de mayo de 2021 (UTC)

^ El término "software GFDL" se basó en un malentendido. GFDLse creó hace dos décadas para acompañar a las licencias de software libre porque eluso de licencias de software libre para manuales se consideraba extraño. Algunos proyectos de software adoptaron GFDL para susmanuales, pero nunca para el software en sí. Dado que elsoftware conlicencia GFDLno existe, no es posible extraer nada de él. Los logotipos, diagramas o capturas de pantalla del software solo se pueden extraer de losmanuales desoftware con licencia GFDL, que existen. Esta nota fue agregada porAlexis Jazz, coautor de esta propuesta. Disculpas por cualquier confusión que pueda haber surgido de este error. -Alexis Jazz(charlao de ping mí) 15:17, 12 de Mayo 2021 (UTC)

^ Algunos votantes expresaron su deseo de restringir GFDL para wikimedianos pero no para fuentes externas. Dado que muchos wikimedianos están activos en otras fuentes autoeditadas como sitios para compartir fotos, redes sociales o blogs, esto sería muy difícil de hacer cumplir. Sin embargo, nos gustaría que supiera que si en el futuro se encuentra una fuente de contenido GFDL fresco fuera de Wikimedia (esto es puramente teórico, hoy no conocemos tal fuente), siempre es posible tener un nuevo voto para crear una excepción para esa fuente específica. -Alexis Jazz(charlao de ping mí) 16:42, 14 de Mayo 2021 (UTC)

• Oponerse . Somos la enciclopedia libre. Eso significa, en lo que respecta a los archivos, que cualquier licencia que sea lo suficientemente libre servirá. Lo que constituye una licencia suficientemente libre está definido por la fundación: Resolución: Política de licencias , refiriéndose a la Definición de Obras Culturales Libres (1.0), y GFDL cumple completamente con estos requisitos. El hecho de que Commons ya no permita archivos solo GFDL es una excelente razón para permitir que se carguen localmente aquí. El "libre" en el movimiento de la cultura libre incluye la libertad de elegir entre licencias igualmente libres. -  Finnusertop ( charla ⋅ contribuciones ) 17:03, 10 de mayo de 2021 (UTC)

  Gracias por tu comentario. Me gustaría señalar que fue la Junta de la Fundación Wikimedia la que decidió en 2009 que GFDL no debería usarse en proyectos wiki. Si alguien sabe lo que somos, debe ser la Junta de la Fundación Wikimedia. Commons continuó permitiendo GFDL durante 9 años antes de implementar completamente la resolución. No culpe a Commons por la resolución si no está de acuerdo con ella. - MGA73 ( conversación ) 17:59, 10 de mayo de 2021 (UTC)

  Decidió que dejaría de permitir las cargas como única licencia. En ningún momento decidió que 'no debería usarse en proyectos wiki'. Haría mejor su punto si no declarara mentiras descaradas. Solo en la muerte termina el deber ( conversación ) 18:15, 10 de mayo de 2021 (UTC)

  Lo siento, no quedó claro. Solo estoy hablando de cargas futuras. Por supuesto, los archivos ya cargados pueden permanecer. Gracias por hacérmelo saber. - MGA73 ( conversación ) 19:29, 10 de mayo de 2021 (UTC)

  @ MGA73 : La resolución de 2009 implementó la meta: Actualización de licencias , que cambió la licencia de contribuciones de texto de solo GFDL a GFDL + CC BY-SA. Continuó permitiendo archivos con cualquier licencia libre, pero se animó a otorgar una licencia doble a los archivos existentes solo GFDL bajo CC BY-SA siempre que sea posible. Tampoco dictaminó que los archivos GFDL ya cargados "no deben usarse en proyectos wiki" ni que las cargas futuras bajo esa única licencia no deben permitirse. La forma en que Wikipedia en inglés lo implementó es que "Todas las licencias de medios existentes antes de la transición siguen siendo válidas y aceptables para la Fundación. Sin embargo, la comunidad puede optar por modificar o restringir las licencias que alienta a las personas a usar. Por ejemplo, enfatizar las licencias CC en el cargar formulario y restar importancia a las licencias GFDL ". No estoy seguro de si incluso nos permite desaprobar por completo una licencia gratuita (eso es más que simplemente "quitarle énfasis" a una). Incluso si lo hace, soy de la opinión de que deberíamos permitir licencias gratuitas de archivos en la mayor medida posible. No se trata de qué licencias son mejores / más ideales, sino qué licencias son gratuitas, y eso ya se ha resuelto desde la resolución de 2007 que la de 2009 no anuló de ninguna manera. -  Finnusertop ( charla ⋅ contribuciones ) 13:38, 14 de mayo de 2021 (UTC)

• Soporte . El enlace Finnusertop proporciona enlaces a [14] desde donde termina en [15], que también señala el problema con GFDL. Finnusertop habla de permitir que "archivos solo GFDL" se carguen aquí para que no se queden sin hogar. La realidad es que sin Wikimedia, para empezar, las fotos con licencia exclusiva de GFDL no existirían. No todas las licencias gratuitas son iguales. Incluso se podría inventar una licencia casera completamente ridícula pero técnicamente gratuita, y solo puedo esperar que la rechacemos si eso sucediera. GFDL es una reliquia del pasado. Sirvió un propósito, una vez. Ya no lo hace, ha sido reemplazado por mejores licencias. GFDL no es una licencia práctica para medios visuales (como fotos) y, literalmente, no hay ninguna razón para que un fotógrafo otorgue una licencia a sus fotos como GFDL más que para molestar a los reutilizadores. No deberíamos permitir que los fotógrafos molesten a los reutilizadores. - Alexis Jazz ( charla o de ping mí) 18:01, 10 de Mayo 2021 (UTC)
• Soporte . El GFDL es gratuito y no creo que nadie lo esté cuestionando. GNU FDL es perfecto para la documentación de software libre, así como para cualquier otro texto donde la lista de contribuyentes no sea tan grande como la de Wikipedia. Pero este no es el caso de los medios (especialmente las fotografías), donde su uso es muy poco práctico. Se supone que debemos hacer que el conocimiento sea más fácil de difundir. La GFDL no permite eso para los medios. Incluso la FSF ha reconocido la impracticabilidad de las FDL en esos medios, razón por la cual lanzaron FDL 1.3 en primer lugar.

  Estoy de acuerdo con el compromiso que se ha puesto aquí. No veo ninguna razón para restringir la resolución de un medio con licencia exclusiva de GFDL. Pero ciertamente deberíamos desalentar el uso exclusivo de GFDL para medios que no sean de texto ni de software. pandakekok9 ( charla ) 05:24, 11 de mayo de 2021 (UTC)

• Estoy algo mal en esto. Por un lado, no deberíamos tener miedo de intentar limpiar las reliquias del pasado para simplificar la carga de mantenimiento, y GFDL es claramente una reliquia del pasado. Sin embargo, debido a los medios anteriores cargados con él, nunca podremos deshacernos de él por completo. Parece que ya hemos hecho todo lo posible para desalentar su uso haciéndolo muy lejos del predeterminado. Dado eso, la cantidad de archivos que se cargan a través de GFDL probablemente sea pequeña. Si alguien realmente quiere usarlo por alguna razón y no contribuiría con su trabajo de otra manera, entonces seguro, espero que decidamos tomar el trabajo. Pero con suerte, casi todos irán y lo pondrán en Commons bajo CC. {{u | Sdkb }}  ^charla 05:41, 11 de mayo de 2021 (UTC)
• Soporte . No veo inconvenientes e incluso el propio WMF dice que no es ideal para medios de imagen. SpartaN ( charla ) 05:52, 11 de mayo de 2021 (UTC)
• Demasiado pronto para prohibir GFDL, en lugar de desaprobarlo y desalentarlo durante un año, especialmente con una advertencia de filtro de edición. Después de un año podemos evaluar si todavía es necesario y prohibir si realmente es inútil. Graeme Bartlett ( charla ) 10:14, 11 de mayo de 2021 (UTC)

  @ Graeme Bartlett : Gracias. La licencia se eliminó como una licencia sugerida en 2009: Especial: Diff / 294994426 . Por lo que se ha desalentado durante casi 12 años. - MGA73 ( conversación ) 13:40, 11 de mayo de 2021 (UTC)

• Soporte Esto tiene años de retraso, ¿cómo se permiten todavía las licencias exclusivas de GFDL aquí? GFDL realmente no es adecuado para imágenes, ¡y las cargas solo GFDL no se han permitido en Commons desde 2018 ! Gracias. Mike Peel ( charla ) 10:50, 11 de mayo de 2021 (UTC)
• Meh apoyo inclinado , ¿cuántas cargas solo de GFDL hemos tenido en los últimos 12 años? - Kusma ( t · c ) 14:23, 11 de mayo de 2021 (UTC)

  @ Kusma : Gracias. Mi conjetura es de alrededor de 1380 archivos . - MGA73 ( conversación ) 19:34, 11 de mayo de 2021 (UTC)

  MGA73 , gracias. La gran mayoría de estos parecen bastante antiguos, con muy pocas excepciones como File: RitwikSanyal1.JPG (que es una nueva carga que sobrescribe una GFDL anterior con licencia de 2010). Por cierto, el cuadro de diálogo "Cargar una nueva versión de este archivo" no hace un buen trabajo al verificar que la licencia de los archivos nuevos y antiguos sea idéntica. - Kusma ( t · c ) 20:44, 11 de mayo de 2021 (UTC)

  MGA73 , en realidad mucho menos. Kusma preguntó sobre los últimos 12 años. (por lo tanto, desde 2009) Los archivos más antiguos que los que no eran elegibles para volver a obtener la licencia también se incluirían en su consulta. ¿Quién hopper.png era realmente PD-self (tal vez el cargador estaba confundido?), Archivo: Poktori-2.jpg es PD-self, Archivo: Chuck Close 1.jpg no es libre, Archivo: Paullusmagnus-logo.JPG proviene de m : Archivo: Paullusmagnus-logo (small) reloaded.png y se presume GFDL y sería elegible para volver a obtener la licencia como CC BY-SA 3.0 si aceptamos el presunto GFDL, ¿ esto no es un trabajo propio? , Archivo: Diagrama de préstamos de interés compartido.PNG se etiquetó incorrectamente como no elegible para la renovación de la licencia, Archivo: Tenka Qing.png es idéntico a w: ja: フ ァ イ ル: Tenka Qing.png, por lo que también se etiquetó incorrectamente como no elegible para la renovación de la licencia, Archivo : Pb0.9.2 (r86) Win7.PNG es GPL, supongo, Archivo: Fence Lake Monument.jpg también es PD-self . Y así. Excluyendo los falsos positivos, sobrescribe donde la carga original es elegible para volver a obtener la licencia, pero la sobrescritura no lo es y las cargas de 2009 y 2010, cuando algunos cargadores aún no estaban al tanto de la migración de la licencia, solo quedaría una pequeña fracción. - Alexis Jazz ( charla o de ping mí) 21:54, 11 de Mayo 2021 (UTC)

  @ Kusma y Alexis Jazz : Sé que se puede discutir el número. También hay archivos que se mueven a Commons, se eliminan o donde la persona que subió el video acordó volver a obtener la licencia. Espero que todos acepten si GFDL ya no se acepta para nuevas cargas y, por lo tanto, usan una licencia cc. - MGA73 ( conversación ) 07:30, 12 de mayo de 2021 (UTC)

• Por lo tanto, estoy a favor de no permitir nuevos trabajos originales solo en GFDL; pero no es tan partidario de relegar las cargas de trabajos existentes de GFDL que se encuentran en otros lugares a un estado no gratuito / de uso justo. - ^Charla xaosflux 14:41, 11 de mayo de 2021 (UTC)

  @ Xaosflux : Gracias. Si las obras existentes tienen licencia GFDL hoy, aún se pueden cargar como GFDL. También en 2 meses o 2 años a partir de ahora. - MGA73 ( conversación ) 19:21, 11 de mayo de 2021 (UTC)

  Xaosflux , si obtuvo la licencia antes del 1 de julio de 2021, aún puede cargarlo, incluso después del 1 de julio de 2021. Si tuvo la licencia después del 1 de julio de 2021 .. Intente encontrar algo que haya sido recientemente licenciado como GFDL fuera de Wikimedia. Me sorprenderé si encuentras algo. IIRC, hace algunos años, un wikipedista convenció a una organización que no quería publicar su trabajo con una licencia gratuita para publicar algún trabajo bajo la GFDL porque los términos complicarían / ​​inhibirían la reutilización de todos modos , por lo que no tendrían que preocuparse. mucho sobre esos molestos reutilizadores. Errr, sí. notafish abogó por esto desde 2005: Por qué los proyectos de Wikimedia no deberían usar GFDL como una licencia independiente para imágenes . - Alexis Jazz ( charla o de ping mí) 19:40, 11 de Mayo 2021 (UTC)

  @ Alexis Jazz : entonces, si no vamos a purgar los que tenemos o los consideramos no libres, y serían una rareza, ¿por qué tendríamos que prohibirlos? ¿Qué problema está resolviendo? Estoy totalmente a favor de que cualquier imagen creada por el editor sea CCBYA (y en realidad, debería cargarse en commons, no enwiki, a menos que exista alguna razón esotérica no relacionada con el artículo). - ^Charla xaosflux 19:57, 11 de mayo de 2021 (UTC)

  Xaosflux , no queremos nombrar y avergonzar, pero hay fotógrafos que otorgan múltiples licencias de su trabajo con GFDL + CC BY-NC sabiendo muy bien que GFDL es en gran medida inútil para el uso comercial de una sola imagen en una publicación impresa o que se aferrará a GFDL hasta que ya no se le permita señalar que GFDL es una mala licencia (algunos sabrán de quién estoy hablando) o por algún tipo de nostalgia fuera de lugar. No poder secar completamente la habitación no significa que no debamos evitar que las personas usen el grifo sobre el fregadero roto. El uso de imágenes exclusivas de GFDL en artículos solo puede declinar después de que hayamos sellado el grifo. - Alexis Jazz ( charla o de ping mí) 20:34, 11 de Mayo 2021 (UTC)

  No estoy convencido de que este sea un problema que deba resolverse, si ese fotógrafo es un editor, entonces claro, digamos que solo pueden cargar su propio trabajo en CCBYSA; Si encuentras una de sus fotos y crees que es útil incluirla, no creo que debamos evitar que la subas. - ^Charla xaosflux 20:57, 11 de mayo de 2021 (UTC)

  Xaosflux , supongo que no estaba claro. Todos los fotógrafos de los que hablo son wikimedianos. No se encuentran fotos con licencia GFDL fuera de Wikimedia. - Alexis Jazz ( charla o de ping mí) 21:59, 11 de Mayo 2021 (UTC)

  @ Alexis Jazz : bueno, podría, pero en cualquier caso, estaría bien con el siguiente paso que no permitimos que nadie cargue su propio trabajo aquí con solo una licencia GFDL. - ^Charla xaosflux 23:10, 11 de mayo de 2021 (UTC)

• Soporte GFDL siempre fue un mal ajuste para las imágenes. Está diseñado para manuales, libros de texto, otros materiales de referencia e instrucción, y la documentación que a menudo acompaña al software GNU ... se puede utilizar para cualquier trabajo basado en texto , independientemente del tema. (negrita mía). Se usó para imágenes en los primeros días de Wikipedia porque las licencias Creative Commons aún no existían. Una vez que CC se desarrolló por completo y quedó claro que CC era una mejor licencia para usar en imágenes, WMF comenzó sabiamente el proceso de migración de la política de licencias de imágenes para favorecer las licencias CC. Básicamente, el GFDL era una herramienta pobre para cumplir con el propósito, pero era todo lo que teníamos en 2001 cuando se fundó Wikipedia. Cuando aparecieron mejores herramientas, ya no se necesitaba como herramienta. Aparte de las imágenes heredadas que se han licenciado solo con GFDL antes de que cambiemos la política, debemos desaprobar cualquier uso futuro de la licencia. - Jayron 32 14:47, 11 de mayo de 2021 (UTC)
• Soporte . Flickr no ofrece licencias GFDL en imágenes cargadas. Google no muestra imágenes con licencia GFDL en sus herramientas de "solo imágenes gratuitas" en Google Imágenes. GFDL en sí está destinado a "manuales, libros de texto u otros documentos" . Por estas razones, no deberíamos permitir imágenes con licencia exclusiva de GFDL, porque no solo limitan la reutilización en Wikipedia, sino que también evita que otros sitios de alojamiento de imágenes reutilicen nuestras imágenes como parte de sus repositorios. Sin embargo, no creo que deba quedar obsoleto en su totalidad, siempre que alguien elija licenciar su imagen bajo otra licencia libre aceptable (o para el dominio público / CC0), también se le debería permitir seleccionar GFDL y licenciarlo camino. Además, las imágenes con licencia sólo bajo GFDL deberían seguir siendo descargables y no creo que deban considerarse totalmente "contenido no gratuito". Si una imagen GFDL es la única que se puede encontrar para un propósito, incluso si se pudiera crear una imagen más libre , creo que los criterios de contenido no libre deberían adaptarse al uso de una imagen con licencia GFDL en lugar de relegarla al rigor de esos criterios, pero no una relajación total de los mismos. Parte del movimiento de Wikimedia es fomentar el acceso libre a la información, y no lo estamos logrando considerando la GFDL, con sus términos onerosos y estrictos para cumplir con la atribución, lo mismo que una licencia CC. El GFDL es excelente para su propósito, especialmente cuando se considera documentación / medios digitales que pueden contener fácilmente una gran cantidad de elementos de atribución / copia requeridos sin que se vuelvan inutilizables, pero eso no es lo que consideramos "gratuito". -bɜ: ʳkənhɪmez ( Usuario / ¡saluda! ) 22:06, 11 de mayo de 2021 (UTC)
• Soporte , principalmente por Alexis Jazz. GFDL-only es una mala licencia para imágenes y ahora está obsoleta. No hay razón para continuar permitiéndolo, especialmente porque las únicas personas que usan GFDL solo para imágenes son los editores de Wikimedia. De hecho, continuamos perpetuando una mala práctica de derechos de autor que no existe en ningún otro lugar. Con respecto a las preocupaciones sobre el uso legítimo, creo que son en su mayoría teóricas, una vez más, ya que las únicas personas que podrían querer (y alguna vez lo harán) cargar una imagen solo GFDL en Wikipedia son los propios usuarios de Wikipedia y cargan su propio trabajo. La probabilidad de que encontremos una imagen en algún lugar de la web con licencia solo GFDL que queramos subir aquí (como uso legítimo o como imagen gratuita) es bastante pequeña. Pero para propósitos formales, estaría perfectamente bien especificando explícitamente que si alguien quiere cargar una imagen con licencia solo GFDL como imagen de uso justo, eso está permitido y que en esta situación, solo GFDL se tratará de la misma manera que una imagen no gratuita. licencia. Nsk92 ( conversación ) 23:57, 11 de mayo de 2021 (UTC)
• Oponerse según Finnusertop , y las preocupaciones planteadas por Xaosflux , aunque estoy de acuerdo en que Creative Commons es una mejor licencia para las fotos, tengo que ceñirme a mis creencias sobre la libertad de elegir. De lo contrario, podría necesitar esa opción mucho menos práctica algún día, así que estoy en contra de que alguien la elimine. Además, la idea de agregar este conjunto de instrucciones WP: CREEPy sobre si subiste antes o después de esta fecha solo agrega más confusión innecesaria al proceso que decimos que queremos eliminar al deshacernos de las "3 páginas" de licencias. Excepto que ya se ha determinado que las 3 páginas son "suficientemente libres" para que no haya confusión, pero la nueva política generaría mucha confusión mientras la gente intenta hacer "determinaciones" sobre los medios ya existentes. Puedo ver todas las disputas que ya están sucediendo ... Huggums537 ( hablar ) 01:47, 12 de mayo de 2021 (UTC)

  @ Huggums537 : Gracias por tu comentario. Estoy de acuerdo en que deberíamos simplificar las cosas al máximo. Pero creo que la única forma de hacerlo más simple es reducirlo a "¡GFDL no está permitido!". Sé que te opones, pero si tuvieras que elegir entre esas 2 alternativas, ¿cuál crees que es la mejor (o la menos mala)? - MGA73 ( conversación ) 07:43, 12 de mayo de 2021 (UTC)

  Perdóname, pero ¿exactamente cuáles 2 malas alternativas me estás pidiendo que elija? Huggums537 ( charla ) 10:10, 12 de mayo de 2021 (UTC)

  @ Huggums537 : La primera alternativa es mi original (la que llamas CREEPy) y la segunda alternativa es "GFDL no está permitido". - MGA73 ( conversación ) 10:22, 12 de mayo de 2021 (UTC)

  Está bien. Entiendo. Voto por una tercera alternativa, simplemente deje las cosas como están porque no se puede agregar fácilmente software gratuito con Creative Commons, pero sí con GFDL. Esta propuesta pasa por alto ese hecho. Huggums537 ( charla ) 10:28, 12 de mayo de 2021 (UTC)

  @ Huggums537 : Gracias. Pero la propuesta es que el software con licencia GFDL todavía se puede cargar en Wikipedia como GFDL. - MGA73 ( conversación ) 12:02, 12 de mayo de 2021 (UTC)

  Sí, entiendo su punto, pero leí su propuesta de manera diferente porque el software educativo y / o instructivo a menudo también puede clasificarse principalmente como video o audio, por lo que la propuesta tal como está escrita podría hacer que esos softwares sean excluidos. Estos son los tipos de software en los que estaba pensando que podrían pasarse por alto, pero es muy posible que haya otros factores que no se han tenido en cuenta. Huggums537 ( charla ) 14:29, 12 de mayo de 2021 (UTC)

  Huggums537 , De lo contrario, podría necesitar esa opción mucho menos práctica algún día. En realidad, no la necesitarás . Si de alguna manera en el futuro encuentra un problema con Creative Commons, puede cambiar a las plantillas básicas de {{ Attribution }} o {{ PD-self }}, tal vez {{ FAL }} u otra licencia gratuita o escribir una mejor licencia de rasga. Pero no GFDL. conjunto de instrucciones sobre si subiste antes o después de esta fecha. Eso en realidad no está allí. Hay una cláusula de abuelo estándar basada en la fecha de licencia. Entonces, si encuentra un archivo con licencia solo GFDL en, digamos, dewiki o itwiki, puede cargarlo aquí si estaba etiquetado como GFDL antes del 1 de julio de 2021. hacer "determinaciones" sobre los medios ya existentes Los medios ya existentes simplemente no se ven afectados por esta propuesta, por lo que no hay necesidad de preocuparse por disputas al respecto. Excepto que ya se ha determinado que las 3 páginas son "suficientemente gratuitas". El ejemplo del mundo real de notafish y el cómic explican por qué GFDL simplemente no es una licencia práctica para medios visuales. Parece haber cierta confusión sobre el "software GFDL", pero esto parece ser un error en la propuesta que pasé por alto (fui coautor de la propuesta): GFDL se creó hace dos décadas para acompañar las licencias de software libre existentes como la GPL . Antes de eso, el manual que venía con el software libre generalmente se licenciaba bajo la licencia de software libre, lo cual era extraño por varias razones . El software en sí no obtiene la licencia GFDL. - Alexis Jazz ( charla o de ping mí) 14:56, 12 de Mayo 2021 (UTC)

  Bien, eso aborda muchas de mis preocupaciones, y todavía creo que Creative Commons es una mejor licencia para fotos. Simplemente no estoy convencido de que sea mejor para audio o video o incluso dibujos, ya que pueden estar compuestos de ilustraciones como diagramas de flujo y planos, etc. Puede encontrar un buen ejemplo de la confusión de la que estoy hablando si hace una búsqueda en Google para el juego en DVD del mundo mágico de Harry Potter, luego intente tomar una determinación si debe clasificarse como un video en DVD, un videojuego de software o tal vez uno o ambos. Huggums537 ( charla ) 15:38, 12 de mayo de 2021 (UTC) Un ejemplo general aún mejor en el que puedo pensar es un documento llamado esquema eléctrico que podría interpretarse como un dibujo y / o un manual. Huggums537 ( charla ) 16:30, 12 de mayo de 2021 (UTC)

  Los aspectos distintivos de la GFDL es el requisito de mantener parte de la identidad del original (el texto de portada especificado, las secciones invariantes especificadas y las secciones de reconocimiento o dedicatoria), al tiempo que se requiere que la versión modificada se distinga del original con un título diferente. Para grabaciones de audio o video, francamente creo que sería preferible que alguien creara una nueva licencia gratuita que tenga en cuenta de manera apropiada los atributos de esos medios. En el caso de un esquema, seguro que lo emite dentro de un documento que ya cumple con la GFDL. isaacl ( charla ) 19:58, 12 de mayo de 2021 (UTC)

  Supongo que eso tiene sentido. Otro buen ejemplo son los planos porque son dibujos arquitectónicos, pero también manuales de construcción. Huggums537 ( charla ) 20:14, 12 de mayo de 2021 (UTC)

• GFDL solo tiene sentido para trabajos impresos que pueden contener dentro de sí las secciones que deben ser conservadas por versiones modificadas, ya que la licencia asume este contexto. Como mínimo, esto significa una página de título, una página de derechos de autor y licencias y una sección de historial. Creo que es razonable restringir su uso a archivos que ya contienen dentro de sí mismos una página de título, una página de derechos de autor y licencias, y si el archivo es una modificación de uno anterior, una sección de historial. Por lo tanto, incluso para una imagen extraída de un libro GFDL, creo que el trabajo cargado debe contener dentro de sí mismo un título, derechos de autor y licencias, y páginas de historial, ya sea dentro de la imagen o con todo incluido en un formato de archivo de documento. Esto facilitaría a los reutilizadores el cumplimiento de los términos de la licencia. isaacl ( charla ) 02:17, 12 de mayo de 2021 (UTC)

  Ese es un argumento muy razonable. Sin embargo, también se podría argumentar que el título de una foto constituye técnicamente una "página de título", y el historial de revisión de la foto una "página de historial", mientras que la licencia no tiene por qué estar dentro de la foto en sí, a diferencia de otros medios como como película o software. En la otra cara de este argumento, podríamos permitir medios como películas y software libre bajo una licencia GFDL porque tienen títulos, historiales de revisión (quizás no tanto en películas) y licencias dentro de ellos. Huggums537 ( charla ) 10:05, 12 de mayo de 2021 (UTC)

  @ Huggums537 : sí, podríamos. Pero la pregunta es ¿por qué deberíamos hacerlo? WMF concluyó en 2009 que GFDl no es bueno para Wikipedia, por lo que decidieron no usarlo como única licencia. Hay mejores alternativas, ¿por qué no utilizarlas? - MGA73 ( conversación ) 10:32, 12 de mayo de 2021 (UTC)

  Porque en el caso de dibujos, audio y video, esto podría ser de naturaleza instructiva o educativa, como un tipo de trabajo de curso que es más adecuado para una licencia GFDL que Creative Commons para los autores. Si bien somos un sitio de "conocimiento libre", incluso CC reconoce la autoría [mediante atribución]. Huggums537 ( charla ) 10:49, 12 de mayo de 2021 (UTC)

  Si entrecierra los ojos correctamente y gira la cabeza así, puede inventar formas para que otras formas de medios tengan equivalentes a las secciones descritas por la GFDL. (Para una foto distribuida como obra propia, las páginas web separadas no son una de ellas, ya que la licencia se refiere a secciones y páginas del documento en sí. También es obligatorio reproducir la licencia en su totalidad dentro del documento). Pero el hecho sigue siendo que la licencia se escribió asumiendo el contexto de una obra impresa con secciones específicas contenidas en el documento y, por lo tanto, tiene más sentido limitar el uso de la licencia a las obras dentro de este contexto. isaacl ( charla ) 14:42, 12 de mayo de 2021 (UTC)

• El soporte GFDL no es práctico para contenido nuevo, y si las personas prácticamente no pueden reutilizar nuestro contenido, entonces no es realmente gratis (como en la libertad). Es importante que tengamos una excepción para el contenido heredado, como lo ha hecho Commons, ya que hay una gran cantidad de contenido heredado de principios de la década de 2000 que se licenciaba como GFDL solo porque era la licencia popular en ese momento (subí algo a Commons a hace unos pocos meses). Legoktm ( charla ) 15:29, 12 de mayo de 2021 (UTC)
• Soporte . Ruslik _ Zero 20:47, 12 de mayo de 2021 (UTC)
• Oponerse . "¿Es útil? ¿Es necesario? ¿Es amable?" ¿Resuelve esto un problema real que tiene Wikipedia? ¿O solo uno imaginado, que hará que cargar (y volver a cargar) medios relevantes sea más difícil? ¿Mejora esto la enciclopedia o su usabilidad o su RE-usabilidad? Si no es así, vote NO. 71.62.227.79 ( conversación ) 02:52, 13 de mayo de 2021 (UTC)

  ¿Resuelve esto un problema real que tiene Wikipedia? No quería nombrar y avergonzar, pero supongo que no hay forma de evitarlo eventualmente. He aquí un ejemplo.que dificultará la carga (y la re-carga) de medios relevantes? GFDL no ha sido una opción predeterminada durante años. La fecha de la licencia cuenta, no la fecha de carga. ¿Es necesario? ¿Es simpatico? Si simplemente no le importa, ¿por qué requerir una licencia? Aún más fácil. Si, es necesario. o su RE-usabilidad? Si, ese. Vea este ejemplo del mundo real de notafish y el cómic de arriba. - Alexis Jazz ( charla o de ping mí) 04:27, 13 de Mayo 2021 (UTC)

• Oponerse firmemente . Utilizo GFDL porque con frecuencia he visto imágenes que subí bajo Creative Commons utilizadas fuera de Wikipedia sin atribución porque se supone que es equivalente al dominio público. Ya no subo mis fotos a Commons porque adoptaron una propuesta como esta. Jonathunder ( charla ) 16:41, 13 de mayo de 2021 (UTC)

  Mucha gente asume erróneamente que el texto de Wikipedia es PD y viola la licencia. No significa que debamos volver a GFDL solo por el texto. - Kusma ( t · c ) 16:51, 13 de mayo de 2021 (UTC)

  Gracias por tu comentario. Lamentablemente, siempre hay alguien a quien no le importan los derechos de autor. No creo que les haga mucha diferencia si agrega CC o GFDL. ¿Puedo preguntar si siempre hay una atribución para los archivos para los que tiene licencia GFDL? - MGA73 ( conversación ) 17:20, 13 de mayo de 2021 (UTC)

• Enérgicamente se oponen según Finnusertop, 71 y Jonathunder. No deberíamos restringir el uso de licencias gratuitas porque un proyecto hermano lo hace (y muchas personas tienen relaciones complicadas con ese proyecto hermano); prohibir las cargas de GFDL porque Commons tiene tanto sentido como cambiar a CC-BY porque Wikinews lo usa. Como editor activo en Wikivoyage, esa comparación es, a su vez, totalmente inapropiada, porque Wikivoyage tiene objetivos completamente diferentes a los de Wikipedia y las licencias de texto GFDL realmente no le sirven; Los artículos de Wikivoyage están pensados ​​para usarse en forma impresa con más frecuencia que los de Wikipedia (consulte nuestros objetivos y no objetivos y nuestra guía para wikipedistas que trabajan en proyectos cruzados ), donde imprimir la licencia GFDL es una preocupación mucho mayor. Sin embargo, los archivos cargados localmente en la Wikipedia en inglés están implícitamente pensados ​​para su uso en la Wikipedia en inglés, un proyecto que se centra muy poco en la impresión; se pueden usar en muchos lugares, incluso como imágenes impresas, como lo recomienda su licencia gratuita, pero la situación descrita por ese comentario o descrita por Wikivoyage se minimiza porque simplemente no es el caso de uso original. GFDL es una licencia gratuita y, aunque tal vez no la fomentemos tanto como nuestras preferidas, podemos usarla como cualquier otra. Prohibir las cargas de GFDL porque están 'desactualizadas', como algunos han alentado aquí, tiene tanto sentido como prohibir las CC-BY / CC-BY-SA 1.0 o 2.0 por la misma razón, y puedo decirles que hay muchas útiles archivos con esas licencias. Profeta Vaticidal 09:32, 14 de mayo de 2021 (UTC)

  @ Vaticidalprophet : Gracias por tu comentario. No debería restringir GFDL porque Commons lo hizo. Debe restringirlo porque la Junta de la Fundación Wikimedia y muchos otros están de acuerdo en que GFDL no es una buena licencia y no coincide con la visión de Wiki. También creo que te equivocas con las fotos subidas a Wikipedia en inglés. Muy a menudo se copian en otros proyectos y se utilizan allí. No existe tal cosa como "para Wikipedia". ¡El propósito de Wikipedia es compartir con todos!

  Creo que si la única razón para mantener GFDL es porque "Commons es estúpido", ¡entonces no es una buena razón! - MGA73 ( conversación ) 11:34, 14 de mayo de 2021 (UTC)

  No existe tal cosa como "para Wikipedia". ¡El propósito de Wikipedia es compartir con todos! Entonces es bueno que dije exactamente eso, entonces, ¿no es así? El contenido de Wikipedia está destinado a ser compartido bajo una licencia libre, no "una licencia libre excepto esta porque puede ser incómoda". Wikivoyage tiene un propósito completamente diferente a Wikipedia en lo que respecta al cumplimiento de GFDL, es decir, está destinado a ser utilizado en forma impresa, por lo que "GFDL podría ser incómodo en la impresión" es un argumento sólido real. Commons es un repositorio de imágenes dedicado previsto, y las imágenes alojadas en él se utilizan para ese propósito, mientras que Wikipedia no es un host de imágenes, y las imágenes alojadas en él están destinadas a artículos de Wikipedia; eso no quiere decir que no puedan / no deberían / ​​no se compartirán en otro lugar, porque son imágenes gratuitas con licencias gratuitas, pero sí significa que "esto podría ser incómodo de usar en una forma determinada, es mucho menos probable que ser utilizado en que estas otras cosas aleatorias "es un argumento singularmente poco convincente. Prohibir GFDL para nuevas cargas solo puede dañar la misión gratuita de Wikipedia, no puede evitarlo, porque solo serviría para evitar la carga de archivos con una licencia gratuita. No hay absolutamente ninguna circunstancia en la que prohibir una licencia gratuita por razones de "podría ser incómodo de usar de una manera específica" sea útil para una misión gratuita, nunca. Además, no hay necesidad de responder, y mucho menos hacer ping, a todos los oponentes . Profeta Vaticidal 11:42, 14 de mayo de 2021 (UTC)

  Lamento que lo vea de esa manera y anotó su punto. Intento no repetirme. Cuando comento o pregunto es porque me gustaría escuchar los argumentos. No siempre pretendo tener razón y si alguien presenta los argumentos correctos, incluso podría retirar mi sugerencia. Como puede ver, se ha modificado un poco porque no estaba claro. - MGA73 ( conversación ) 12:27, 14 de mayo de 2021 (UTC)

  tiene tanto sentido como prohibir CC-BY / CC-BY-SA 1.0 o 2.0 por la misma razón. Existe un mecanismo de compatibilidad para CC 2.0 con versiones más nuevas. No hay compatibilidad para la licencia 1.0, pero: CC-BY 1.0 incluye "crédito razonable para el medio" , por lo que, a diferencia de GFDL, es factible cumplir con los términos de la licencia. Además, nunca he visto ningún contenido no antiguo con una licencia CC 1.0. (a diferencia de 2.0, que todavía es un lugar común debido a Flickr) - Alexis Jazz ( charla o de ping mí) 17:16, 14 de Mayo 2021 (UTC)

• Me opongo , apoyaría una limitación en GFDL para contenido creado por Wikipedian, pero si estamos reutilizando el trabajo de un tercero que tiene licencia GFDL y cumple con todos los demás factores apropiados, no veo ninguna razón para limitar ese uso. No deberíamos cortar una fuente potencial simplemente porque de todas las licencias gratuitas que podrían haber usado, usaron una que no es la mejor opción para las imágenes, pero por lo demás es compatible con la "licencia libre". - M asem ( t ) 13:26, 14 de mayo de 2021 (UTC)
• Débil se oponga a lo anterior, módulo el hecho de que creo que la GFDL no es una licencia "libre" . Si alguien usa solo GFDL, simplemente pídale una licencia dual y explíquele las razones por las que es útil; no necesitamos crear reglas más complicadas que nadie leerá. Si algo tiene la licencia adecuada y mejora la enciclopedia, deberíamos poder usarlo. - Wug · a · po · des​ 23:42, 14 de mayo de 2021 (UTC)
• Apoyo , propuesta muy bien pensada que vale la pena promulgar. También es mejor tarde que nunca para seguir la guía de la WMF. Establecer la restricción en función de la fecha de la licencia, no de la fecha de carga, es una forma razonable de permitir material más antiguo mientras se limpian las cosas para el futuro. Estoy de acuerdo con Alexis Jazz en que esta restricción siempre se puede revisar si aparece una cantidad significativa de contenido GDFL nuevo en el futuro. - M.Nelson ( charla ) 14:12, 15 de mayo de 2021 (UTC)
• Oponerse débilmente, el GFDL es claramente subóptimo para las imágenes, por decirlo suavemente, y es bueno poder copiar cosas en comunes para que otros proyectos puedan aprovecharlas. Dicho esto, no me gusta la idea de que las reglas se arrastren aquí; siempre podemos solicitar licencias dobles, y si alguien realmente solo quiere contribuir con imágenes bajo la GFDL, eso no es ideal, pero aún está mejorando la enciclopedia y no veo ninguna razón para detenerlos. Saludos, 31.41.45.190 ( hablar ) 01:56, 16 de mayo de 2021 (UTC)
• Tenga en cuenta que la mayoría de las preocupaciones planteadas por los opositores aquí ya han sido resueltas por el compromiso presentado aquí. Déjame resaltar esa parte:

  La [propuesta] anterior no restringe el uso no gratuito del contenido . Si un trabajo que no es un trabajo derivado con una licencia GFDL se usa bajo una justificación no libre, no tiene que reducirse, pero se seguirán aplicando otras limitaciones no libres.

  La posibilidad teórica de un futuro contenido con licencia GFDL que sería elegible para la inclusión no gratuita se ha planteado como un argumento en el pasado y este es un compromiso que, con suerte, mitigará eso.

  El material que tiene licencia GFDL únicamente después de la fecha de corte del 1 de julio de 2021 aún se puede usar en la Wikipedia en inglés , solo bajo una justificación no libre. Y están exentos del límite de resolución . Entonces, antes de oponerse a esta propuesta, verifique primero si su inquietud ya ha sido resuelta por dicho compromiso . pandakekok9 ( charla ) 05:52, 16 de mayo de 2021 (UTC)

Su solución es utilizar un fundamento no libre para los medios con licencia gratuita. Eso es ridículo. Solo en la muerte termina el deber ( conversación ) 13:45, 16 de mayo de 2021 (UTC)

@ Pandakekok9 : Exactamente lo que dijo OID, vi tu propuesta, simplemente no tenía ningún sentido, lo siento. Saludos, 31.41.45.190 ( conversación ) 14:21, 16 de mayo de 2021 (UTC)

No tiene sentido exigir una justificación no libre para el contenido que comparte la misma licencia que nuestro texto. Más allá de eso, tenemos suficientes problemas para lograr que las personas usen correctamente los fundamentos no libres para cosas que no son completamente gratuitas, por lo que sospecho que expandir su uso a los medios copyleft hará algo más que confundir aún más a la gente. Es una idea inteligente y la preferiría a prohibirlos por completo, pero no resuelve mis preocupaciones. - Wug · a · po · des​ 22:06, 16 de mayo de 2021 (UTC)

Este es un malentendido de nuestra licencia. Las únicas contribuciones que en realidad tienen doble licencia son las que se realizaron antes de la fecha en que cambiamos a CC BY SA 3.0. Las contribuciones realizadas a continuación son únicamente CC por SA 3.0. (En general, de todos modos, algunas personas tienen doble licencia CC y otras después de esa fecha). Consulte nuestra página de reutilización . Siguiendo los recuentos en Wikipedia: Size_of_Wikipedia , eso significa que hay unos 3,5 millones de artículos que son CC BY SA 3.0 solamente. Izno ( charla ) 00:43, 17 de mayo de 2021 (UTC)

@ Izno : estaba saliendo del texto en la parte inferior de mi cuadro de edición que dice Al publicar los cambios, acepta los Términos de uso e irrevocablemente acepta liberar su contribución bajo la Licencia CC BY-SA 3.0 y la GFDL (énfasis agregado). Este texto parece basarse en nuestros términos de uso (legalmente vinculantes), específicamente en la base: Términos de uso / en # 7. Licencia de contenido que, según mi lectura, dice que todo nuestro contenido está disponible bajo la GFDL y Los reutilizadores pueden cumplir con cualquiera de las licencias o con ambas . No he revisado el historial de nuestros ToS, pero a menos que se haya cambiado recientemente, la enciclopedia completa (el texto de la) está disponible en la GFDL. - Wug · a · po · des​ 01:34, 17 de mayo de 2021 (UTC)

Oh, Dios mío, la inconsistencia. La Meta FAQ sobre el tema es interesante, al igual que la introducción a la actualización en sí . Quizás soy yo quien lo está leyendo mal. Izno ( charla ) 02:12, 17 de mayo de 2021 (UTC)

Ver meta: Actualización de licencias / Preguntas y respuestas # ¿Reemplazo de GFDL con CC-BY-SA? . Según GFDL, las modificaciones del contenido GFDL más antiguo deben seguir estando disponibles por GFDL. Para contenido completamente nuevo, digamos un artículo nuevo, las contribuciones de los editores individuales se realizan sobre la base de una licencia dual. Pero con la actualización de la licencia, existe la opción de importar un trabajo con licencia puramente CC-BY-SA desde una fuente externa. El contenido resultante solo tendría licencia CC-BY-SA, ya que incorporaría contenido no GFDL. isaacl ( charla ) 02:31, 17 de mayo de 2021 (UTC)

Isaacl , Según GFDL, las modificaciones del contenido GFDL más antiguo deben seguir estando disponibles por GFDL. Técnicamente, lo que dices es correcto, pero no se aplica aquí. Hablando del wikitexto, se ha vuelto a licenciar como CC BY-SA 3.0. Por lo tanto, las modificaciones de ese contenido se pueden publicar con una licencia BY-SA y / o GFDL. Simplemente podríamos abandonar GFDL por wikitext por completo sin repercusiones. - Alexis Jazz ( charla o de ping conmigo) 03:09 19 de mayo 2021 (UTC)

Estoy corregido: es cierto que la Fundación Wikimedia podría establecer una fecha de transición en la que la instantánea de Wikipedia en ese momento se convierta en un trabajo derivado siguiendo los términos de la licencia CC-BY-SA, y así, en el futuro, todo el contenido de texto sería relicenciado soley como CC-BY-SA. isaacl ( charla ) 05:11, 19 de mayo de 2021 (UTC)

• Soporte Las restricciones de GFDL, cuando se aplican a la mayoría de los archivos, son lo suficientemente restrictivas como para que la licencia sea menos gratuita de lo que esperaríamos. - AntiCompositeNumber ( conversación ) 01:49, 18 de mayo de 2021 (UTC)
• Fuerte apoyo . Los medios visuales que tienen licencia únicamente bajo la GFDL no cumplen con la definición de obra cultural libre . En particular, la libertad de copiar y redistribuir la obra debe ser "práctica" y "sin ningún riesgo". Este cambio está muy atrasado. Kaldari ( charla ) 20:08, 20 de mayo de 2021 (UTC)
• Fuerte soporte : no cumple con el estándar gratuito y no se puede usar en Commons y, por lo tanto, en otros wikiprojects. Esto decisivamente hace que el trabajo no sea gratuito para todos los efectos. Esto ni siquiera debería ser una decisión difícil. Magog el Ogro ( t • c ) 23:20, 24 de mayo de 2021 (UTC)
• Apoyo. GFDL es muy fácil de abusar. Por ejemplo, digamos que tengo esta foto de un cerdo fetal que tomé en la clase de medicina forense un día. Es mi trabajo, y quiero usarlo en nuestro artículo sobre fetos de cerdo, excepto que quiero castigar a los reutilizadores solo porque puedo. Además de obligar a las personas a proporcionar una copia de la licencia (solo por usar mi imagen singular de un cerdo fetal), esto es lo que puedo hacer:
  1. Utilice {{ GFDL-self-with-disclaimers }} para solicitar a los reutilizadores que proporcionen una copia de todas nuestras exenciones de responsabilidad . Ver Wikipedia: estandarización GFDL .
  2. Marcar mi página de usuario como "Texto de portada", lo que significa que también debe incluirse.
  3. Agrega un montón de secciones invariables. Se trata básicamente de apéndices que deben incluirse en cada reutilización para cumplir con la licencia. No tengo conocimiento de ninguna restricción con respecto al uso de secciones invariables.

  No creo que a nadie se le deba permitir hacer esto. - MJL  - Charla - ^☖ 01:16, 25 de mayo de 2021 (UTC)

  Puedo ver lo de las exenciones de responsabilidad, pero no estoy seguro de si se le permite usar las dos últimas en Wikipedia. ¿No haría eso que el trabajo sea indiscutiblemente no libre? Si estas cosas están permitidas en Wikipedia todo este tiempo, nos enfrentamos a un problema aún mayor que antes. pandakekok9 ( charla ) 10:37, 30 de mayo de 2021 (UTC)

• Ha habido preguntas sobre la cantidad de archivos y también algunos dijeron que no deberíamos decir que no a los archivos con licencia gratuita de fuentes externas. Así que revisé un poco para saber más sobre los archivos. Lamentablemente, no hay una manera fácil de encontrar información sobre archivos eliminados, por lo que los números a continuación no incluyen archivos eliminados (copyvios, archivos huérfanos que ya no se pueden usar y archivos movidos a Commons).

A día de hoy, hay 1.343 archivos en la categoría: migración de licencia de Wikipedia que no son elegibles y que no tienen licencia de creative commons. Es menos que el 1380 que mencioné anteriormente, pero algunos se han eliminado como copyvios, algunos tenían una licencia incorrecta y algunos usuarios volvieron a obtener la licencia.

999 archivos son obra propia (tienen las plantillas GFDL-self, GFDL-user o self) y 344 archivos no están marcados claramente como obra propia.

Después del cambio de licencia en 2009, todavía hubo muchas cargas con GFDL por parte de muchos usuarios diferentes. Hoy hay 331 archivos de 2010 y son subidos por 198 usuarios diferentes. El número disminuyó con el tiempo y solo hay 11 archivos de 2017 cargados por 9 usuarios diferentes.

Cuando Commons restringió el uso de GFDL el 15 de octubre de 2018, el número aumentó. Se cargan 394 archivos después de esa fecha (algunos son una versión editada de una carga anterior).

• Pero de los 394 archivos, 365 los carga 1 usuario y todas las cargas en 2021 las realiza ese usuario.
• Y de los 394 archivos, solo 2 no están marcados como obra propia. Los 2 archivos que se derivan de archivos en Commons con licencia GFDL y cc-by-sa-3.0, por lo que deben volver a tener licencia.

Entonces, los números concuerdan con que solo los wikipedistas todavía usan GFDL (un usuario principal). - MGA73 ( conversación ) 19:16, 25 de mayo de 2021 (UTC)

Para todo 2020, solo queda una imagen (que no es de Jona) que tal vez no sea copyvio: Archivo: MV Alta, Co. Cork, febrero de 2020.jpg . Y aquí está la razón fundamental para usar GFDL: " Gracias por tu consulta. Básicamente, desconfío de volver a otorgar la licencia a esta foto como CC, ya que ni yo ni el fotógrafo original queríamos que se usara fuera de Wikipedia, y GFDL parecía la mejor opción para eso " . Para eso se utiliza GFDL. - Alexis Jazz ( charla o de ping mí) 03:18, 26 de Mayo 2021 (UTC)

• Soporte por usuario: MGA73 , pero el segundo punto, "* El contenido es principalmente una fotografía, pintura, dibujo, audio o video" es demasiado limitado y debe incluir todo tipo de medios y archivos de imagen, incluidos gráficos por computadora tanto fijos como animados. así como archivos que representan objetos 3D. Mejor sería "* El contenido es un archivo multimedia que representa imágenes fijas o en movimiento, objetos 3D o audio" . MichaelMaggs ( charla ) 11:43, 1 de junio de 2021 (UTC)
• Soporte por arriba. En una nota al margen, no puedo decirles cuántas veces hice clic accidentalmente en GDFL al intentar publicar una edición. ~ HAL 333 04:41, 8 de junio de 2021 (UTC)
• Soporte por nominación y otros, aunque ¿no es esto realmente un problema para Commons? La mayoría de los medios gratuitos se cargarán allí, no en la Wikipedia en inglés. Básicamente, ya no hay una buena razón para usar GDFL para imágenes, por lo que esto excluirá el caso de "el usuario despistado selecciona una licencia al azar" y el caso mayoritariamente hipotético, pero aún malicioso, "trolly GDFL" en el que un usuario solo quiere bloquear su imagen de una manera no estándar. SnowFire ( charla ) 17:10, 11 de junio de 2021 (UTC)

El futuro del espacio de nombres del libro

¿Debería quedar obsoleto el espacio de nombres del libro y, de ser así, qué debería incluir la obsolescencia? - Trialpears ( charla ) 18:27, 15 de mayo de 2021 (UTC)

Este RfC implicará varias propuestas diferentes pero relacionadas. En primer lugar, daré algo de historia sobre el espacio de nombres del libro, ya que es probable que muchos editores desconozcan el espacio de nombres. También explicaré el estado actual y el enlace a algunas discusiones anteriores (no es necesario leerlo de ninguna manera). Luego, describiré algunas acciones posibles, cada una en su propia sección. Cuando se cierre el RfC, se evaluará el consenso para cada propuesta y, con suerte, habrá un consenso sobre cómo lidiar con este espacio de nombres zombi. - Trialpears ( charla ) 18:27, 15 de mayo de 2021 (UTC)

Historia (espacio de nombres del libro)

El espacio de nombres del libro se introdujo en 2009 como una forma de descargar o imprimir una colección de artículos. Para hacer esto, use Especial: Libro para seleccionar una colección de artículos que desee en el libro. divídalos en capítulos y elija algunas configuraciones de renderizado. También puede darle una imagen de portada, cambiar el color del libro, elegir la configuración de representación y dividir los artículos en capítulos.

Una vez hecho esto, puede comprar una copia impresa de PediaPress o descargarla en una amplia variedad de formatos, incluido PDF, utilizando el Generador de contenido sin conexión .

Con el tiempo, el Generador de contenido sin conexión quedó obsoleto y no se pudo mantener. Los errores y los problemas de seguridad ya no se pudieron solucionar, por lo que la Fundación Wikimedia desactivó el servicio de reproducción de libros en todas las wikis de Wikimedia en octubre de 2017 . Desde entonces, los libros de Wikipedia solo han estado disponibles en forma física en PediaPress o en MediaWiki2LaTeX ( de: b: Benutzer: Dirk Huenniger / wb2pdf / manual ). El problema con esto es que ahora requerimos que los lectores visiten un sitio de terceros para acceder a nuestro contenido y comprarlo o esperar una cantidad de tiempo significativa para obtener acceso al libro y reproducirlo si MediaWiki2LaTeX incluso funciona correctamente para usted. Una gran proporción de nuestros libros son demasiado largos para renderizar y una buena parte del resto tiene cosas como navboxes que rompen el renderizador e incluso si en teoría debería funcionar, he tenido momentos en los que se detiene aleatoriamente o no puedo descargar el libro. por razones inexplicables. Si desea hacerlo localmente (que he escuchado que funciona significativamente mejor) tendrá que hacerlo en Linux o configurar una máquina virtual. Después de invertir unas horas tratando de hacer esto, me di por vencido, así que no lo he probado personalmente. Si desea un PDF de un artículo, le sugiero que utilice la opción "Descargar como PDF" en la barra lateral, que puede proporcionarle una versión PDF de manera confiable en segundos.

Actualmente, el espacio de nombres tiene un total de páginas vistas en el orden de un portal popular como Portal: Sudáfrica . Esto se extiende a lo largo de un poco más de 6000 páginas. Durante un mes normal sin una actividad significativa del editor, la mayoría de los libros no obtienen una sola vista y solo el 1,5% de los libros obtienen una página visitada al día. El libro más popular : Estructuras de datos fundamentales obtiene solo 15. También vale la pena señalar que estas cifras están significativamente infladas por mi trabajo de mantenimiento reciente y el de otros, que ha dado como resultado miles de estas vistas.

Ha habido varias iniciativas anteriores para ocultar libros a los lectores, las tres más importantes son la eliminación en 2019 del creador de libros de la barra lateral y la eliminación de muchos enlaces , la eliminación en 2021 de los enlaces restantes y la eliminación en 2021 de algunas plantillas relacionadas con libros . Las dos últimas fueron básicamente decisiones unánimes.

Los libros todavía se consideran un espacio de nombres de cara a la comunidad y se encuentran en páginas de ayuda a las que a menudo se hace referencia como "libros comunitarios" y supuestamente se mantienen en la comunidad. Están indexados por motores de búsqueda. Puede crear libros en el espacio de nombres de libros usando Especial: Libro , pero también se pueden crear en el espacio de usuario como Categoría: Libros de Wikipedia (libros de usuario) . El espacio de nombres aparece como no utilizado en WP: Namespace .

PediaPress tiene enlaces a algunos de nuestros libros en el Catálogo , que pueden o no ser posibles de conservar si los libros se eliminan en Wikipedia. Seguiría siendo posible utilizar PediaPress siempre que no se elimine Special: Book . O no guardando el libro en wiki y guardándolo en PediaPress o guardándolo en espacio de usuario.

La pregunta ahora es cómo debemos manejar los libros en el futuro. Esto podría incluir alternativas a mantener el status quo ya que casi nadie lo ve a la eliminación completa del espacio de nombres, incluidos todos los libros que contiene. - Trialpears ( charla ) 18:27, 15 de mayo de 2021 (UTC)

En 2019, PediaPress implementó un nuevo renderizado de PDF , que se utiliza para el enlace "Descargar como PDF", pero está claro en phab: T186740 que el soporte de libros no sucederá .-- Snævar ( charla ) 19:32, 15 de mayo de 2021 ( UTC)

• Comentar . Me gustaría agregar algunos comentarios adicionales a eso. El acuerdo original fue entre la Fundación WikiMedia (WMF) y PediaPress. Ellos escribieron nuestro motor de renderizado original, el Offline Content Generator (OCG). También escribieron uno para ellos mismos y al principio podías descargar una copia software en PDF gratis en su formato si no querías pagar por un árbol muerto. Posteriormente retiraron la opción de copia en pantalla. Mientras tanto, OCG nunca funcionó bien. Los intentos de PediaPress de solucionarlo fueron superados constantemente por cambios en las plantillas y otros juegos tanto en el software como en los espacios de usuario. Además, Wikilibros ganó en funcionalidad y contenido. Así que el interés inicial en nuestros libros se desvaneció. Hemos intentado dos veces y no hemos podido desarrollar un reemplazo, MediaWiki2LaTeX está sufriendo de subdesarrollo y Collector, un reemplazo de OCG prometido por PediaPress, también se ha quedado en silencio desde que apareció su sitio de prueba alfa . Se ha vuelto imposible saber si un renderizador interno viable atraería realmente a los usuarios; Nunca hemos tenido algo así, el esfuerzo voluntario es insuficiente para lograrlo y WMF se ha negado sistemáticamente a financiar su desarrollo. Sugeriría que hemos llegado a la decisión decisiva: ¿tiene algún sentido tener tanto Wikipedia: libros aquí como Wikilibros? ¿No es suficiente con uno? Jugar con nuestro espacio de nombres agonizante es simplemente prolongar la agonía. Necesitamos resucitarlo o clavar una estaca en su corazón. Aunque prefiero lo primero, no me hago ilusiones de que el consenso mayoritario sea a favor de lo segundo. Solía ​​creer que le debíamos a PediaPress para que siguiera funcionando, pero pensándolo bien, sacaron las descargas gratuitas de su formato de debajo de nuestros pies por razones expresamente comerciales, y nos decepcionaron de nuevo por Collector; ya no les debemos nada. Siempre puedo mantener páginas de libros manualmente en mi espacio de usuario y subirlas a MediaWiki2LaTeX o lo que sea, no necesito nada más. - Saludos, Steelpillow ( Discusión ) 14:04, 16 de mayo de 2021 (UTC)

Propuestas (espacio de nombres del libro)

Desaprobar formalmente el espacio de nombres del libro

La siguiente discusión es un registro archivado de una solicitud de comentarios . Por favor no lo modifique. No se deben realizar más ediciones en esta discusión. A continuación se presenta un resumen de las conclusiones alcanzadas.

Existe un consenso para desaprobar formalmente el espacio de nombres del libro, describiendo las páginas dentro de él como históricas o no mantenidas. ( cierre no administrativo ) ( t · c ) buidhe 09:22, 24 de mayo de 2021 (UTC)

---

Esto incluiría cambiar el idioma utilizado en páginas como Wikipedia: Libros , Ayuda: Libros y {{ Libro guardado }}. Los libros en el espacio de nombres de libros ya no se describirían como mantenidos por la comunidad. - Trialpears ( charla ) 18:27, 15 de mayo de 2021 (UTC)

• Apoyar Esto debe hacerse como mínimo. El espacio de nombres no disfruta del mantenimiento de la comunidad y debemos dejarlo en claro. Llamarlo obsoleto dejará en claro para cualquiera que los libros no son realmente compatibles. - Trialpears ( charla ) 18:27, 15 de mayo de 2021 (UTC)
• Oppose Los libros siguen existiendo, arregle el software y los libros volverán a la vida. Headbomb { t · c · p · b } 18:42, 15 de mayo de 2021 (UTC)
• ¿ Oponerse a qué? Por Headbomb. Tirar al bebé con el agua del baño. ¡Arregle el software! Littleolive oil ( charla ) 18:47, 15 de mayo de 2021 (UTC)
• Comentario @ Headbomb y Littleolive oil : El estado de la reparación del software es que no ha sucedido nada desde 2017 y la extensión solo se mantiene con la corrección de errores . No puedo imaginar que un desarrollador esté dispuesto a pasar muchas semanas o meses de trabajo para poner esto en marcha de nuevo, especialmente cuando existe la función de descarga como PDF. La cantidad de páginas vistas (muchas de las cuales no querrían descargar un libro) es, como dije, comparable a un portal popular en el que no puedo imaginar que ningún desarrollador justifique dedicar ese tiempo a cientos de proyectos más importantes. Si el software es fijo, el uso puede volver a los niveles previos a la eliminación. En diciembre de 2016, el espacio de nombres obtuvo un poco más de 6000 páginas vistas diarias en promedio, lo que es comparable a una página como Perro . Si desea mantener la esperanza de que algún día se arregle, eso es razonable, pero pensé que al menos debería explicar por qué no puedo ver que eso suceda. - Trialpears ( charla ) 19:04, 15 de mayo de 2021 (UTC)

  Tu falta de imaginación no es motivo para borrar libros. Si el renderizador de PDF funciona, se podría utilizar para renderizar por lotes colecciones de artículos / libros, y esa sería una base perfectamente buena para la renderización de libros sobre la que construir. Headbomb { t · c · p · b } 19:12, 15 de mayo de 2021 (UTC)

  O ... ¿uno podría simplemente imprimir varios PDF con lo que tenemos ahora? Nadie usa libros, y parece que nunca lo hizo. TP difícilmente está especulando, si es fácil como dices, ¿por qué nadie lo ha hecho todavía? Aza24 ( charla ) 19:20, 15 de mayo de 2021 (UTC)

  Problema del huevo y la gallina. Nadie usa libros porque el software no funciona. Arregle el software, la gente volverá a usar los libros. Fueron decentemente populares cuando el renderizador funcionaba. En cuanto a "por qué nadie lo ha hecho todavía", pregunte a la WMF. Headbomb { t · c · p · b } 12:56, 16 de mayo de 2021 (UTC)

  Algunos datos sobre el uso se encuentran en Usuario: SD0001 / Libros . Muestra que la gran mayoría de este espacio de nombres tiene vistas de página mensuales de un solo dígito . La mayoría de los libros tienen muy pocos editores. El número máximo de editores distintos que han editado un libro es 36 para Book: The Beatles . Aproximadamente la mitad de todos los libros tienen 2 editores distintos (la segunda edición es en su mayoría AWB / HotCat). Esto no indica que hayan sido decentemente populares alguna vez. - SD0001 ( conversación ) 19:46, 16 de mayo de 2021 (UTC)

  Sí, eso es bastante normal después de que todos los enlaces a libros se eliminaron del espacio principal en 2020. Vea la caída clara en [16] y [17] , [18] para ver ejemplos. Headbomb { t · c · p · b } 21:33, 16 de mayo de 2021 (UTC)

• Soporte: acabo de hacer un libro sobre Gilbert Reaney con uno de los softwares externos y no veo nada útil. De hecho, las únicas diferencias que veo de las descargas de la versión PDF e imprimible son una tabla de contenido formal, una página de título y (por alguna razón) cada enlace de WP convertido en una URL a esa página de Wikipedia en una nota. Quiero decir, ¡qué tontería! No deberíamos apoyar algo tan inútil como esto, especialmente cuando a) hay alternativas de terceros b) Ya tenemos literalmente versiones en PDF e imprimibles c) ha permanecido sin arreglar durante 4 años d) Nadie los usó cuando estaban funcionando ! Aza24 ( charla ) 19:16, 15 de mayo de 2021 (UTC)
• Soporte : los libros son como portales: simplemente no tienen la suficiente demanda de los lectores como para que valga la pena invertir los recursos de la comunidad. Y existen servicios para crear archivos PDF. WikiBooks debe ser su propia wiki o herramienta interwiki, y puede crear libros desde cualquier idioma wiki, no solo enwiki; pero es una distracción como espacio de nombres enwiki o proyecto enwiki. Levivich  ^acoso / _sabueso 19:21, 15 de mayo de 2021 (UTC)
• Soporte por nom, Aza24 y Levivich. Los libros fueron un experimento que probamos, lo cual está bien. Falló, lo que también está bien. Reconozcamos el fracaso y sigamos adelante, no sigamos desperdiciando esfuerzos tratando de mantenerlo. {{u | Sdkb }}  ^charla 20:18, 15 de mayo de 2021 (UTC)
• Soporte como opción secundaria a la eliminación por las razones que se dan en el comentario a continuación. ƒirefly ( t · c ) 20:30, 15 de mayo de 2021 (UTC)
• Soporte Existe una tendencia real en WP de aferrarse a cosas que ya no funcionan, están inactivas, etc. Es una mala tendencia y el espacio de nombres del libro es un ejemplo perfecto de ello. Beeblebrox ( charla ) 20:50, 15 de mayo de 2021 (UTC)
• Soporte . Como lector de mucho tiempo y editor de IP intermitente, he tenido algunos intentos de usar el espacio de nombres del libro a lo largo de los años, pero cada vez ha sido una experiencia de usuario universalmente terrible. Es común encontrar libros que tienen problemas de diseño, peso y NPOV significativos, y no nos engañemos con que el espacio de nombres del libro es mantenido por la comunidad, no lo es. Es un vertedero para los proyectos de libros personales de las personas que ocasionalmente son arreglados por un wikignome que pasa. Para ilustrar esto, echemos un vistazo a la experiencia del usuario al encontrar un libro sobre un tema aleatorio que cualquier enciclopedia debería poder cubrir bien: "Historia europea".

Contenido extendido

Entonces, para comenzar Libro: la historia europea no existe, ni como un libro, ni como una redirección a algo relevante. No es un buen comienzo en términos de facilidad de búsqueda cuando el equivalente del espacio principal ( historia europea ) existe desde 2002 y tiene un promedio de más de 1000 páginas vistas al mes. El motor de búsqueda interno muestra 3 libros con un enfoque superpuesto: en un espacio de nombres mantenido por la comunidad, ¿seguramente las páginas duplicadas deberían fusionarse? El primer libro que apareció fue Book: EuropeHistory , que ilustra los peores problemas de los libros. Creado por un solo usuario en 2009 - 2011, las únicas ediciones desde entonces han sido un poco de wikignomery. Problemas masivos de peso debido: ¿por qué el imperio romano obtiene un total de 4 artículos, mientras que la unión europea obtiene 134? ¿Por qué no se menciona la Segunda Guerra Mundial? ¿Qué hace Cruft como Lista de los edificios más altos de la Unión Europea , Galileo (navegación por satélite) y las siglas, la jerga y las prácticas laborales de la Unión Europea en un libro de historia? Esto está enormemente desactualizado y ha sido abandonado desde que su usuario lo creó, a pesar de cubrir la unión europea con una cantidad excesiva de detalles, ¿no se menciona el Brexit? El segundo libro que apareció es Libro: Historia de Europa . Esto tiene un mejor enfoque en mi opinión, pero consiste solo en una lista cronológica de artículos sin ningún intento de clasificar el contenido en capítulos. Creado por un solo usuario en 2010, solo las ediciones desde entonces han sido wikignomery y un intento de fusión abortado, por lo que al libro le falta todo lo que sucedió en los últimos 10 años. El último libro que apareció es Libro: Europa1 . En mi opinión, este es el mejor del grupo: tiene una estructura de capítulos bien definida, una cantidad razonable de artículos y está relativamente actualizado (aunque eso es solo porque fue creado más recientemente, nuevamente fue creado por un solo autor en 2017 y solo ha visto ediciones geniales desde entonces). Incluso siendo el mejor de ellos, todavía no veo cómo ofrece una mejor experiencia de usuario que History of Europe , que clasifica los mismos artículos en los mismos períodos de tiempo básicos y es mucho más legible, y en este título no es nada que los lectores podrán encontrar fácilmente. Las dos últimas secciones de este libro están duplicadas (y lo han estado desde su creación hace 4 años) aparentemente sin que nadie se dé cuenta. Habiendo encontrado un libro razonable, tengo algunas opciones para leerlo: puedo hacer clic en cada uno de los artículos de la lista y usarlo como un mal sustituto de un artículo de estilo resumido o una lista. máquina para exportar las páginas a látex y luego compilarlas en un pdf, o puedo pagar a una empresa externa para que me imprima una copia en papel de una enciclopedia electrónica que estará desactualizada en un par de años. ¿A quién va dirigido? ¿Las personas que no pueden acceder al sitio web de manera confiable pero pueden descargar archivos PDF enormes de forma regular? ¿Personas que no pueden pagar el acceso a Internet pero que pueden gastar $$$ en libros impresos a pedido? ¿Personas que necesitan un asistente de creación de libros fácil de usar pero que saben cómo configurar Linux y usar latex? Simplemente no veo a qué grupo demográfico se dirige esto.

• En general, el espacio de nombres del libro simplemente no es una experiencia buena o útil para los lectores, y no hay señales de que ninguna comunidad esté curando activamente estos libros. Apoyaría la depreciación del espacio de nombres del libro de la comunidad y mover todos los libros al espacio de usuario del creador original, ya que en mi experiencia, en el 95% de los casos, será la única persona que haya agregado contenido al libro. 192.76.8.91 ( conversación ) 21:05, 15 de mayo de 2021 (UTC)
• Soporte y todos los de abajo también. Encuentro que el argumento "simplemente arréglalo" es débil. Si algo se ha roto durante tanto tiempo y nadie quiere arreglarlo, probablemente no valga la pena arreglarlo. Estoy luchando por ver el valor de este espacio de nombres incluso si funcionó correctamente. Air corn  (charla) 21:49, 15 de mayo de 2021 (UTC)
• Soporte . ¡Por favor! Gog the Mild ( charla ) 21:59, 15 de mayo de 2021 (UTC)
• Oponerse por falta de beneficio al hacerlo. Nemo 22:00, 15 de mayo de 2021 (UTC)

  El beneficio es que se dedica más tiempo editorial a los artículos, que es lo que importa a largo plazo. - SD0001 ( conversación ) 10:12, 16 de mayo de 2021 (UTC)

• Soporte : esto se ha roto durante años. No parece haber mucho impulso para solucionar esto, y según Aircorn, esto no parece ser algo que mucha gente quiera. Si algunos usuarios desean algo como esto, pueden hacerlo en su espacio de usuario, pero en general, el espacio de nombres del libro parece estar muerto. _{Charla sobre la} granja de _cerdos 23:01, 15 de mayo de 2021 (UTC)
• Soporte . Es una característica que nunca ganó mucha tracción y ahora está obsoleta. - RoySmith (charla) 00:20, 16 de mayo de 2021 (UTC)
• Apoyo. —¿Philoserf? ( charla ) 02:09, 16 de mayo de 2021 (UTC)
• Soporte . Nadie parece interesado en mantener nada de esto. Si los voluntarios se postulan, tal vez podría revivirse algún día. Por ahora, déjelo continuar en el espacio de usuario. - Alexis Jazz ( habla o hazme ping)
• Soporte por evidencia presentada así como por IP192. - Izno ( charla ) 03:27, 16 de mayo de 2021 (UTC)
• No Vote por un lado, se ha roto durante años y a nadie le ha importado arreglarlo. Además, esta función debería estar realmente en el espacio del usuario (para libros de usuarios individuales) o en el espacio del proyecto (para esfuerzos de colaboración sobre temas). Si bien debería ser una buena idea, no estoy seguro de que queramos animar a la gente a publicar "libros de contenido de Wikipedia" en plataformas de autoedición. Yo no voto, pero a menos que a alguien se le ocurra una idea para mejorar el uso del espacio de nombres, esto ciertamente pasará. Usuario: 力(power ~ enwiki, π , ν ) 03:31, 16 de mayo de 2021 (UTC)
• Admite la desaprobación del espacio de nombres. Como han dicho otros, el espacio de nombres es un experimento fallido, simplemente no entiendo la utilidad de mantenerlos como comunidad. Algunos usuarios todavía están interesados ​​en crear libros, claro, pueden hacerlo en el espacio de usuario; no hay necesidad de mantenimiento de la comunidad, lo cual es un desperdicio de recursos por algo que a los lectores no les importa. - SD0001 ( conversación ) 07:07, 16 de mayo de 2021 (UTC)
• Soporte Este es un espacio de nombres roto y una enorme pérdida de tiempo. - Comentario anterior sin firmar agregado por Jackattack1597 ( charla • contribuciones )
• Oponerme Me opongo a cualquier cosa que use la palabra "desaprobar" - GhostInTheMachine ^{habla conmigo} 14:07, 16 de mayo de 2021 (UTC)
• Apoyar , pero archivar el contenido. - Kusma ( t · c ) 14:13, 16 de mayo de 2021 (UTC)
• Oponerse Como esto parece ser un asunto técnico controlado por PediaPress y WMF / MediaWiki, regido por un contrato legal entre ellos, entonces esto no es asunto nuestro. Si los editores o lectores no encuentran útil la función, no es necesario que la utilicen. Andrew 🐉 ( charla ) 17:27, 16 de mayo de 2021 (UTC)
• Soporte . (1) Los libros están fuera de alcance. La función es periférica a nuestro propósito y no debe mantenerse como infraestructura crítica, ni técnica ni editorialmente. (2) re: "arreglarlo", cualquier voluntario intrépido o empresa puede hacerlo sin el espacio de nombres del libro. (3) Los libros ya están obsoletos, según el historial anterior. Que actualicemos nuestra documentación no debería ser controvertido. (4) Aparte de esta discusión, me gustaría saber qué impacto positivo (lectores o audiencia más amplia) ha tenido Books durante su existencia. zar 18:18, 16 de mayo de 2021 (UTC)
• Soporte : expondré mi razonamiento una vez y me referiré a él en cada comentario posterior. Apoyo toda progresión hacia deshacernos de la función del libro. Nadie ha dado un caso de uso convincente digno de todo el tiempo voluntario que todavía se dedica a él (que no es una gran proporción de lo que se hace en el sitio, pero sigue siendo una cantidad sustancial de horas sin procesar). 192.76.8.91 expone brillantemente algunos ejemplos de cómo no es ningún caso de uso convencer a por lo menos durante gran parte del contenido. Una pequeña proporción de lectores ocasionales ha oído hablar de él. No es bueno para las personas con un buen Internet o con un mal Internet. No se relaciona con la forma en que las personas navegan y leen los artículos. Y finalmente, no estamos impidiendo que nadie implemente esta funcionalidad correctamente, e incluso con fines de lucro, siempre y cuando se otorgue la atribución CC-BY-SA legalmente requerida. - Bilorv ( conversación ) 22:10, 16 de mayo de 2021 (UTC)
• Soporte Este es un tema nuevo para mí y he leído atentamente su razonamiento y todos los comentarios anteriores. No me convence "es un error, así que arréglalo". cerca de la cima. Claramente, en mi opinión, los hechos hablan por sí mismos. El formato de libro no funciona, pero además de eso, el formato de libro no es popular ni está bien utilizado. Creo que es hora de bajar el telón, vaciar el foso de la orquesta y apagar las luces del vestíbulo, porque el espectáculo ha terminado. doktorb _palabras ^hechos 22:18, 16 de mayo de 2021 (UTC)
• Apoyar esto es lo mínimo que se debe hacer. Pensé en esto durante algún tiempo y tu razonamiento parece sólido. Personalmente, los archivos PDF parecen una solución mucho mejor que los libros, y la única diferencia que veo es una tabla de contenido. Al observar las páginas vistas, los libros también parecen raramente utilizados. EpicPupper ( charla ) 04:14, 17 de mayo de 2021 (UTC)
• Soporte por 192.76.8.91 . En primer lugar, el software no funciona. Es decir, el software está roto y no funciona. Es decir, trabajar es algo que el software, en esta situación, no hace. Tenemos renderizado de PDF, que básicamente hace todo lo que se suponía que debían hacer los "libros", excepto que realmente funciona. Entonces nos quedamos con "el espacio de nombres del libro", que es ... ¿sólo un montón de listas de artículos aleatorias muy mal elaboradas ? El quid de la cuestión es que, el espacio de nombres no solo no recibe virtualmente vistas ni ediciones, el contenido en él está casi todo muy por debajo de lo que consideraríamos calidad de Wikipedia. La pregunta entonces es por qué estamos respaldando formalmente, en la voz de la comunidad, un espacio de nombres aleatorio donde personas al azar lanzan artículos al azar sin una revisión por pares o un procedimiento de consenso, y dándole la apariencia de respetabilidad. ¡Triste! jp × g 04:34, 17 de mayo de 2021 (UTC)

  Es totalmente incorrecto sugerir que "tenemos la renderización de PDF, que básicamente hace todo lo que se suponía que debían hacer los" libros ". Está muy por debajo de la funcionalidad de libro implementada por el antiguo OCG. Procesa solo un artículo (no es mucho peor que la opción de impresión estándar de página web a PDF de mi navegador web que maneja los artículos de Wikipedia). Un renderizador de libros también necesita extraer cada artículo de la lista de contenido y ajustar los títulos de los capítulos según la lista de contenido. Para cumplir con los requisitos legales de nuestra licencia, luego debe recopilar y adjuntar a los usuarios de las historias completas de todos los artículos en una sección masiva de derechos de autor. Luego de nuevo para las imágenes de los Comunes. Finalmente, debe renderizar a PDF, paginar y agregar los números de página a la lista de Contenidos. Por alguna razón, el falso meme de que "el creador de PDF lo hace todo" está bastante extendido y muchos se niegan a reconocer su total falsedad (de hecho, el hecho de no abordarlo fue la razón principal por la que nuestra propia comunidad de desarrolladores ha fallado constantemente, pero esa es otra historia). . - Saludos, Steelpillow ( Discusión ) 10:31, 17 de mayo de 2021 (UTC)

• Soporte según Levivich anterior y según el comentario de eliminación de BlueRaspberry a continuación. Debemos actuar para evitar perder valiosas horas de voluntariado en proyectos que no cuentan con el apoyo suficiente para sobrevivir. Ajpolino ( charla ) 05:53, 17 de mayo de 2021 (UTC)
• Soporte : he estado aquí durante seis años y nunca he editado el espacio de nombres del libro, ni siquiera en una capacidad administrativa. Anarchyte ( charla ) 10:45, 17 de mayo de 2021 (UTC)
• Apoye un experimento interesante que no tuvo éxito. No veo ningún sentido en gastar recursos en esto en esta etapa. Hut 8.5 19:50, 17 de mayo de 2021 (UTC)
• Soporte Esta es una enciclopedia, los libros pertenecen a Wikilibros. Entonces, ¿qué tal mover los libros a Wikilibros en lugar de eliminarlos? - Killarnee ( C • T • U ) 17:22, 18 de mayo de 2021 (UTC)
• Soporte Somos una enciclopedia, no una librería. Los libros no tienen una demanda lo suficientemente alta por parte de nuestra base de usuarios como para que valgan el enorme tiempo necesario para el editor. ¡AdmiralEek ^{Thar ella edita!} 17:53, 19 de mayo de 2021 (UTC)

  ¿Qué tiempo necesita nuestro editor de gran tamaño? - GhostInTheMachine ^{me habla a las} 18:10, 19 de mayo de 2021 (UTC)

• Apoyo. Deben eliminarse las funciones no mantenidas. Sandstein 07:09, 20 de mayo de 2021 (UTC)
• Oponerse a la depreciación es una tontería a medias, confundirá muchísimo a los visitantes y los entusiastas de los libros seguirán agregando libros de todos modos. Realmente no queremos un wiki "oculto" cosido en uno que cualquiera puede leer. - Saludos, Steelpillow ( Discusión ) 08:58, 20 de mayo de 2021 (UTC)
• Soporte . Esto es solo formalizar lo que actualmente es el caso: estos no son mantenidos por la comunidad, el software no funciona y casi nadie ve los libros. Siendo realistas, no parece que ninguna de estas cosas vaya a cambiar. el wub "?!" 13:56, 23 de mayo de 2021 (UTC)
• Soporte técnico Aunque no me alegra mucho decir esto, deberíamos haber desaprobado los portales y deberíamos desaprobar los libros para recortar el número de espacios de nombres. -  John M Wolfson  ( charla  •  contribuciones ) 14:37, 23 de mayo de 2021 (UTC)

La discusión anterior está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

No indexe el espacio de nombres del libro para ocultarlo de los motores de búsqueda.

La siguiente discusión es un registro archivado de una solicitud de comentarios . Por favor no lo modifique. No se deben realizar más ediciones en esta discusión. A continuación se presenta un resumen de las conclusiones alcanzadas.

Seguimiento en Phabricator
Task T283522

Existe un consenso claro de no indexar el espacio de nombres del libro para ocultarlo de las búsquedas. ( cierre no administrativo ) ( t · c ) buidhe 09:23, 24 de mayo de 2021 (UTC)

---

Esto ocurriría al cambiar las configuraciones de MediaWiki y evitar que los libros de Wikipedia aparezcan en los resultados de búsqueda. Los libros seguirían estando disponibles con la función de búsqueda interna de Wikipedia. - Trialpears ( charla ) 18:27, 15 de mayo de 2021 (UTC)

• Soporte Si vamos a ocultar los enlaces internamente, también deberíamos ocultarlos de los motores de búsqueda por las mismas razones. Este contenido no beneficia a los lectores y deja espacio para publicar algo en un espacio de nombres indexado sin supervisión. Es posible que los spammers o los editores de COI abusen de esto. - Trialpears ( charla ) 18:27, 15 de mayo de 2021 (UTC)
• Soporte de forma temporal. Con la reactivación de la indexación cuando / si los renderizadores de PDF están arreglados. Headbomb { t · c · p · b } 18:45, 15 de mayo de 2021 (UTC)
• Soporte : como mínimo, según mis comentarios en apoyo de la desaprobación. Levivich  ^acoso / _sabueso 19:22, 15 de mayo de 2021 (UTC)
• Soporte por nom; esto debería ir acompañado de la desaprobación. {{u | Sdkb }}  ^charla 20:19, 15 de mayo de 2021 (UTC)
• Soporte por todo lo anterior. Beeblebrox ( charla ) 20:51, 15 de mayo de 2021 (UTC)
• Soporte per nom si no hay consenso para depreciar el espacio de nombres por completo, ya que no tiene sentido dirigir a los lectores a un espacio de nombres para un servicio retirado que no está particularmente bien mantenido. 192.76.8.91 ( conversación ) 21:17, 15 de mayo de 2021 (UTC)
• Oponerse, ya que no hay indicios de que las personas que llegan a esas páginas desde un motor de búsqueda hayan causado daño a alguien. Nemo 22:00, 15 de mayo de 2021 (UTC)
• Soporte - Francamente, no veo que nadie que busque en Internet realmente encuentre esto útil. No parece útil hacer que las personas que buscan un tema sean enviadas al espacio de nombres del libro. Esto debería estar en gran parte enmascarado de los motores de búsqueda. _{Charla sobre la} granja de _cerdos 22:55, 15 de mayo de 2021 (UTC)
• Soporte Si nadie está mirando este espacio de nombres y está indexado, es solo una invitación abierta para los spammers y otros malhechores de SEO. - RoySmith (charla) 00:22, 16 de mayo de 2021 (UTC)
• Apoyo. —¿Philoserf? ( charla ) 02:10, 16 de mayo de 2021 (UTC)
• Soporte , también, deshacerse del espacio de nombres del libro. Nadie parece interesado en mantener nada de esto. Si los voluntarios se postulan, tal vez podría revivirse algún día. Por ahora, déjelo continuar en el espacio de usuario. - Alexis Jazz ( habla o hazme ping)
• Soporte por evidencia presentada. - Izno ( charla ) 03:27, 16 de mayo de 2021 (UTC)
• Soporte según lo anterior: no hay beneficio para los visitantes del motor de búsqueda al aterrizar aquí mientras esto esté roto. Usuario: 力(power ~ enwiki, π , ν ) 03:28, 16 de mayo de 2021 (UTC)
• Soporte por arriba. Creo que deberíamos ir más allá (ver comentarios en la sección de eliminación a continuación), pero esto sería un comienzo. ƒirefly ( t · c ) 06:49, 16 de mayo de 2021 (UTC)
• Oponerse Como esto parece ser un asunto técnico controlado por PediaPress y WMF / MediaWiki, regido por un contrato legal entre ellos, entonces esto no es asunto nuestro. Si los editores o lectores no encuentran útil la función, no es necesario que la utilicen. Andrew 🐉 ( charla ) 17:29, 16 de mayo de 2021 (UTC)
• Soporte : según mi razonamiento anterior. - Bilorv ( conversación ) 22:10, 16 de mayo de 2021 (UTC)
• Soporte por arriba. EpicPupper ( charla ) 04:15, 17 de mayo de 2021 (UTC)
• Apoyo , según los argumentos que hice (y cité) en mi apoyo a la sección anterior. Es decir, por una variedad de razones, el espacio de nombres del Libro está lleno de contenido de baja calidad (lo cual es lamentable y podría haberse evitado). Pero, tal como está, no hay razón para pensar que nos beneficiamos de tener el espacio de nombres del Libro abierto a todos. jp × g 06:20, 17 de mayo de 2021 (UTC)
• El soporte tiene sentido: GhostInTheMachine ^{me habla a las} 11:54, 17 de mayo de 2021 (UTC)
• Oponerse a ocultarlo es una tontería a medias, confundirá muchísimo a los usuarios que los busquen y los entusiastas de los libros seguirán agregando libros de todos modos. Realmente no queremos un wiki "oculto" cosido en uno que cualquiera puede leer. - Saludos, Steelpillow ( Discusión ) 08:58, 20 de mayo de 2021 (UTC)
• Soporte como paso inicial. Estas páginas no se mantienen, no deberíamos presentarlas a los motores de búsqueda con el nombre de Wikipedia como si lo fueran. el wub "?!" 13:56, 23 de mayo de 2021 (UTC)

La discusión anterior está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

Elimina la opción de guardar en el espacio de nombres del libro del creador del libro.

La siguiente discusión es un registro archivado de una solicitud de comentarios . Por favor no lo modifique. No se deben realizar más ediciones en esta discusión. A continuación se presenta un resumen de las conclusiones alcanzadas.

Seguimiento en Phabricator
Task T283523

Existe un consenso para eliminar la opción de usar esta herramienta para crear libros en el espacio de nombres de libros. ( cierre no administrativo ) ( t · c ) buidhe 09:31, 24 de mayo de 2021 (UTC)

---

Esto se implementaría cambiando una configuración simple de MediaWiki como se documenta en mw: Extensión: Colección # Derechos de usuario para guardar libros . El espacio de nombres del libro aún sería editable y sería posible mover libros desde el espacio de usuario allí o crear manualmente un libro usando texto wiki y luego usar el creador de libros. - Trialpears ( charla ) 18:27, 15 de mayo de 2021 (UTC)

• Soporte Esta sería una excelente manera de desalentar en gran medida la creación de nuevos libros mantenidos por la comunidad sin afectar la creación de libros de usuario o la edición de libros existentes. - Trialpears ( charla ) 18:27, 15 de mayo de 2021 (UTC)
• Soporte de forma temporal. Con la reactivación cuando / si los renderizadores de PDF son arreglados. Headbomb { t · c · p · b } 18:44, 15 de mayo de 2021 (UTC)
• Soporte : según mis comentarios en apoyo de la desaprobación. Levivich  ^acoso / _sabueso 19:23, 15 de mayo de 2021 (UTC)
• Soporte , como algo que debería ir junto con la desaprobación. {{u | Sdkb }}  ^charla 20:21, 15 de mayo de 2021 (UTC)
• Apoyo. —¿Philoserf? ( charla ) 02:14, 16 de mayo de 2021 (UTC)
• Soporte , también, deshacerse del espacio de nombres del libro. Nadie parece interesado en mantener nada de esto. Si los voluntarios se postulan, tal vez podría revivirse algún día. Por ahora, déjelo continuar en el espacio de usuario. - Alexis Jazz ( habla o hazme ping)
• Soporte por evidencia presentada. - Izno ( charla ) 03:26, 16 de mayo de 2021 (UTC)
• Soporte por arriba. Creo que deberíamos ir más allá (ver comentarios en la sección de eliminación a continuación), pero esto sería un comienzo. ƒirefly ( t · c ) 06:50, 16 de mayo de 2021 (UTC)
• Compatibilidad con la propuesta anterior de desactivación del espacio de nombres. - SD0001 ( conversación ) 07:11, 16 de mayo de 2021 (UTC)
• Soporte Tiene sentido limitar los libros al espacio del usuario - GhostInTheMachine ^{habla conmigo} 14:02, 16 de mayo de 2021 (UTC)
• Oponerse Como esto parece ser un asunto técnico controlado por PediaPress y WMF / MediaWiki, regido por un contrato legal entre ellos, entonces esto no es asunto nuestro. Si los editores o lectores no encuentran útil la función, no es necesario que la utilicen. Andrew 🐉 ( charla ) 17:29, 16 de mayo de 2021 (UTC)
• Soporte : según mi razonamiento anterior. - Bilorv ( conversación ) 22:10, 16 de mayo de 2021 (UTC)
• Soporte . Tiene sentido junto con la depreciación. EpicPupper ( charla ) 04:16, 17 de mayo de 2021 (UTC)
• Soporte como un paso para eliminar el espacio de nombres por completo. Ajpolino ( charla ) 05:53, 17 de mayo de 2021 (UTC)
• Oponerse si todavía creatable, aunque desalentado, la eliminación de la herramienta (que probablemente va gran parte no utilizada, y si estaba causando un problema, eso sería una cosa) que puede resultar útil en el caso improbable de un libro es muy útil es tonta. -  Godsy  ^{( TALK} _{CONT )} 07:06, 17 de mayo de 2021 (UTC)
• Oponerse a "Desalentar" a los demás es una ingeniería social desagradablemente orientada a sí misma: si una característica es indeseable, sea lo suficientemente honesto para deshacerse de ella. Y si no hay consenso para hacer eso, entonces no tienes absolutamente ninguna excusa para molestar a los demás. - Saludos, Steelpillow ( Discusión ) 09:03, 20 de mayo de 2021 (UTC)
• Soporte . el wub "?!" 13:56, 23 de mayo de 2021 (UTC)

La discusión anterior está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

Elimine el soporte para la clase de libros de la evaluación de WikiProject

Esto implicaría vaciar y eliminar las categorías en Categoría: artículos de clase de libro y editar las plantillas asociadas para que no admitan el espacio de nombres del libro. - Trialpears ( charla ) 18:27, 15 de mayo de 2021 (UTC)

• Soporte En este punto, estos no tienen ningún propósito y ya se han marcado como históricos. - Trialpears ( charla ) 18:27, 15 de mayo de 2021 (UTC)
• Los libros opuestos todavía existen, esto no es diferente a tener una clase de categoría. Headbomb { t · c · p · b } 18:42, 15 de mayo de 2021 (UTC)
• Soporte : según mis comentarios en apoyo de la desaprobación. Levivich  ^acoso / _sabueso 19:23, 15 de mayo de 2021 (UTC)
• Apoye que estos no son, y nunca fueron, artículos. Ya lleva un año marcado como histórico. Claramente no lo estamos haciendo ya, deberíamos reconocerlo. Beeblebrox ( charla ) 20:54, 15 de mayo de 2021 (UTC)
• Soporte : ya no tiene función. _{Charla sobre la} granja de _cerdos 21:01, 15 de mayo de 2021 (UTC)
• Apoyo. —¿Philoserf? ( charla ) 02:15, 16 de mayo de 2021 (UTC)
• Soporte , también, deshacerse del espacio de nombres del libro. Nadie parece interesado en mantener nada de esto. Si los voluntarios se postulan, tal vez podría revivirse algún día. Por ahora, déjelo continuar en el espacio de usuario. - Alexis Jazz ( habla o hazme ping)
• Soporte por evidencia presentada. - Izno ( charla ) 03:25, 16 de mayo de 2021 (UTC)
• Los libros de soporte son solo colecciones de artículos existentes. Los artículos son lo que hay que evaluar: GhostInTheMachine ^{me habla a las} 14:03, 16 de mayo de 2021 (UTC)
• Oponerse Como esto parece ser un asunto técnico controlado por PediaPress y WMF / MediaWiki, regido por un contrato legal entre ellos, entonces esto no es asunto nuestro. Si los editores o lectores no encuentran útil la función, no es necesario que la utilicen. Andrew 🐉 ( charla ) 17:30, 16 de mayo de 2021 (UTC)
• Oponerse , con la condición de que se mantenga el espacio de nombres del libro: no estoy seguro de qué beneficio real trae esto si no nos deshacemos de los libros por completo (lo cual sí apoyo). ¿Se dedica mucho tiempo a mantener estas transclusiones de clase Libro? ¿Y por qué es nuestra jurisdicción controlar cómo los WikiProjects individuales mantienen las cosas? Por lo que tengo entendido, a menos que la comunidad en general realmente establezca un consenso global para detenernos, un WikiProject del que soy parte puede iniciar una escala de evaluación con 64 calificaciones diferentes, a partir de 3 escalas independientes de 4 valores que miden qué tan "bien proporcionado", Cada página está "bien escrita", "bien ilustrada" (independientemente del espacio de nombres). - Bilorv ( conversación ) 22:10, 16 de mayo de 2021 (UTC)
• Soporte por arriba. EpicPupper ( charla ) 04:16, 17 de mayo de 2021 (UTC)
• Soporte como consecuencia de la eliminación del espacio de nombres de libros. No tiene sentido hacer esto de otra manera. Ajpolino ( charla ) 05:53, 17 de mayo de 2021 (UTC)
• Oponerse Estos son útiles para evaluar la puntuación total de los artículos en un tema determinado. Dobbyelf62 ( charla ) 23:25, 18 de mayo de 2021 (UTC)
• Oponerse . Muchos libros son cruft, algunos valen la pena sobre diferentes cosas. De hecho, es útil saber cuál es cuál. - Saludos, Steelpillow ( Discusión ) 09:11, 20 de mayo de 2021 (UTC)

  Steelpillow , esta "evaluación" no clasifica los libros por calidad, sino (aproximadamente) por tema. La evaluación de la calidad del libro (a través de User: Cyberbot I / Book Reports ) parece independiente de las evaluaciones de WikiProject. - Kusma ( t · c ) 10:26, 20 de mayo de 2021 (UTC)

  De acuerdo, he actualizado el detalle pero el principio no ha cambiado. - Saludos, Steelpillow ( Discusión ) 12:05, 20 de mayo de 2021 (UTC)

• Neutral en esto. Creo que los libros deberían desaparecer, pero si se guardan, entonces tiene sentido conservar las evaluaciones a menos que WikiProjects sienta lo contrario. Si se eliminan todos los libros, las categorías se vuelven elegibles para una eliminación rápida en C1 y se pueden realizar los ajustes necesarios en las plantillas. De cualquier manera, no se requiere ninguna acción ahora. el wub "?!" 13:56, 23 de mayo de 2021 (UTC)
• Oponerse por Headbomb, Dobbyelf62 y Steelpillow. Consulte también mi! Voto y comentarios en la sección siguiente. Cordialmente, History DMZ ^{( HQ ) † ( cable )} 16:17, 28 de mayo de 2021 (UTC)
• Soporte por arriba. - Fredddie ™ 19:05, 30 de mayo de 2021 (UTC)
• Soporte por todo lo anterior. UnitedStatesian ( conversación ) 01:30, 1 de junio de 2021 (UTC)
• Soporte como arriba. MichaelMaggs ( charla ) 09:04, 1 de junio de 2021 (UTC)
• Soporte No tiene sentido que todos los Wikiprojects rastreen un espacio de nombres depreciado. Terasail ^[✉] 10:59, 1 de junio de 2021 (UTC)
• Pregunta: ¿Quiere decir que deberían ser de clase N / A, o que los carteles de WikiProject en los libros deberían eliminarse por completo? - Jochem van Hees ( charla ) 12:12, 4 de junio de 2021 (UTC)
• El soporte ya que los libros ya no son funcionales ni útiles. - SilverTiger12 ( conversación ) 22:15, 5 de junio de 2021 (UTC)
• Apoya esto . Me gustaría señalar que, en la mayoría de los casos, esta clase se impuso a los WikiProjects individuales en 2010 sin consulta, agregando |Book=yesa la máscara de clase personalizada de cada proyecto. Técnicamente, esto requerirá que un bot lo elimine |Book=yesde cada subplantilla de clase. Agregaría que apoyaría una decisión local de cualquier WikiProject de seguir apoyando esta (o cualquier otra) clase, pero eso requeriría una discusión local por parte del proyecto. - Martin ( MSGJ  ·  charla ) 10:29, 10 de junio de 2021 (UTC)

Eliminar todos los libros dentro del espacio de nombres del libro

WP: REEMBOLSOS al espacio de usuario serían posibles. Si se eliminan todos los libros, el espacio de nombres debe desinstalarse si los desarrolladores lo consideran apropiado. Esto lo eliminaría de las listas de espacios de nombres en lugares como Special: Search y Special: RecentChanges y permitiría que páginas como Book - A Novel se ubicaran en el título correcto. Especial: el libro seguirá funcionando normalmente y aún es posible guardar libros en el espacio del usuario. PediaPress seguiría funcionando salvo posiblemente el catálogo en función de su implementación. - Trialpears ( charla ) 18:27, 15 de mayo de 2021 (UTC)

• Neutral Sería bueno no tener que preocuparse nunca más por el espacio de nombres y eliminar la posibilidad de que el vandalismo permanezca durante meses o que el espacio de nombres contenga un puerto seguro para páginas inadecuadas. Sin embargo, existe un valor distinto de cero en algunas de estas páginas para un pequeño número de usuarios. Dado que la ocultación del enlace anterior combinado con las propuestas aquí (en su mayoría sin indexación) evitaría que las personas ingresen accidentalmente al espacio de nombres, creo que está bien dejarlo así. Si bien todavía tendríamos una pequeña cantidad de vandalismo sin detectar durante meses, el vandalismo en una página con solo un puñado de visitas no es tan malo. - Trialpears ( charla ) 18:27, 15 de mayo de 2021 (UTC)
• Soporte Cada una de estas propuestas hace que el espacio de nombres se parezca cada vez más a un segundo espacio de nombres de usuario y cada vez menos a un espacio de nombres funcional (en la medida en que alguna vez lo fue). Una vez que se implementen cada uno de estos, no habrá una diferencia significativa entre los libros en el espacio de nombres de libros y los libros en el espacio de nombres de usuario y, por lo tanto, no habrá razón para mantenerlos separados. Sin embargo, sugeriría usar libros cuyo creador aún esté activo en lugar de eliminarlos. Esto hace que todas las propuestas anteriores sean discutibles, por lo que no voy a comentar en ninguna otra sección * Pppery * _{ha comenzado ...} 18:36, 15 de mayo de 2021 (UTC)
• Oponerse Esto es una reacción exagerada a un problema de software. La solución es arreglar el software, no tirar al bebé. Headbomb { t · c · p · b } 18:41, 15 de mayo de 2021 (UTC)
• Oponerse . Arréglelo en lugar de quitarlo. Littleolive oil ( charla ) 18:50, 15 de mayo de 2021 (UTC)
• Soporte por nom. Estoy convencido de que el 99,99% de nuestros lectores no conocen o nunca han utilizado libros. La mayoría de los que probablemente hayan hecho clic en ellos accidentalmente ... Ya tenemos opciones integradas (PDF y versión imprimible), así como opciones de terceros, para el 0.01% verdaderamente desesperado. Aza24 ( charla ) 19:24, 15 de mayo de 2021 (UTC)
• Soporte : según mis comentarios en apoyo de la desaprobación. La Userfication, cuando es práctico, tiene sentido como alternativa a la eliminación. Levivich  ^acoso / _sabueso 19:25, 15 de mayo de 2021 (UTC)
• Soporte por nom, Aza24 y Pppery. - Ched ( charla ) 20:06, 15 de mayo de 2021 (UTC)
• Soporte con userification , por Pppery. {{u | Sdkb }}  ^charla 20:25, 15 de mayo de 2021 (UTC)
• Soporte como primera opción : no veo que el software se vuelva funcional en el corto plazo, y personalmente creo que el tiempo del desarrollador podría invertirse mejor en otra parte. Como tal, no tiene sentido mantener el espacio de nombres alrededor. ƒirefly ( t · c ) 20:28, 15 de mayo de 2021 (UTC)
• Apoye la historia de este proyecto está plagado de ideas a las que se les dio una oportunidad justa y simplemente no funcionaron a largo plazo. Nadie vendrá y solucionará mágicamente todos los problemas de software de un proyecto en desuso que pocos encuentran útil. Hay cosas mucho más importantes y realmente útiles que pueden hacer tanto la comunidad como el personal. Admitamos lo obvio, esto se acabó. Aquellas personas que realmente los quieren, aún pueden tenerlos en el espacio de usuario. Beeblebrox ( conversación ) 21:01, 15 de mayo de 2021 (UTC)
• Oponerse - Wikipedia: candidatos a temas destacados y buenos / El procedimiento de nominación indica que se creen libros como parte del proceso de nominación de temas destacados y buenos. Algunos de los libros tendrán algún valor histórico a través de buenos temas destacados. No creo que la eliminación total de todos sea un paso particularmente bueno, aunque muchos son inútiles. _{Charla sobre la} granja de cerdos 21:04, 15 de mayo de 2021 (UTC)
• Una especie de apoyo: creo que sería mejor mover los libros al espacio de usuario del creador original, en lugar de eliminarlos por completo, pero estoy de acuerdo con eliminarlos de una sección pública "Mantenida por la comunidad" si la enciclopedia. 192.76.8.91 ( conversación ) 21:23, 15 de mayo de 2021 (UTC)
• Oponerse porque los "libros" son solo una colección de enlaces, que funcionan perfectamente bien con el software adecuado. Los usuarios todavía pueden usarlos ahora mismo para producir sus propios productos derivados, por ejemplo, para Kiwix o PediaPress. Nemo 22:00, 15 de mayo de 2021 (UTC)
• Soporte , por nom y Firefly. Gog the Mild ( charla ) 22:02, 15 de mayo de 2021 (UTC)
• Oponerse , no esconder la historia. Al menos consiga un bot que lo mueva todo a las subpáginas de Wikipedia: Libros / Antiguos / o algo para que la conexión con los Temas Destacados sea comprensible. - Kusma ( t · c ) 22:32, 15 de mayo de 2021 (UTC)
  • ?? Los temas destacados y buenos apenas están conectados con los libros; no brindan más conexión que el cuadro de temas en sí. Ni siquiera se muestran en los cuadros de temas. Aza24 ( conversación ) 22:44, 15 de mayo de 2021 (UTC)
    • Sigo pensando que algunos de estos pueden tener algún valor histórico. No una mayoría, pero sí algunos. No creo que destruir un espacio de nombres completo de forma indiscriminada vaya a ser útil aquí. Yo apoyo la eliminación de la mayor parte de éstos , pero no estoy convencido de que el enfoque general es la mejor ruta que algunos de estos pueden ser históricamente útil y necesitan más atención antes de la eliminación . _{Charla sobre la} granja de cerdos 22:58, 15 de mayo de 2021 (UTC)
    • Aza24 , estaban en un pasado no muy lejano: [19] Por supuesto , elimine los que hacen daño, pero no elimine todo solo porque ya no es "útil". - Kusma ( t · c ) 23:03, 15 de mayo de 2021 (UTC)
  • Supongo que vale la pena señalar que no todos los temas destacados tienen un libro asociado. Verificando ~ 20 temas aleatorios, solo un poco más de la mitad tenía uno. - Trialpears ( charla ) 23:30, 15 de mayo de 2021 (UTC)
• Soporte por arriba. ~ HAL 333 23:56, 15 de mayo de 2021 (UTC)
• Soporte . La función está muerta y lo ha estado durante mucho tiempo. Los desarrolladores de la fundación tienen una gran acumulación de otros errores que no están solucionando, y no hay razón para creer que van a comenzar con esto pronto. De todos modos, el tiempo de desarrollo se sirve mejor en otros lugares. - Gonnym ( conversación ) 00:00, 16 de mayo de 2021 (UTC)
• La función de eliminación de soporte no es compatible, nunca tuvo un soporte adecuado y no hay ningún plan para brindar soporte en términos de software o de organización comunitaria de voluntarios. Hice libros en el pasado y luego sentí que el proceso fue decepcionante. Como era una opción en Wikipedia, asumí que era útil, cuando de hecho, el proceso no tiene soporte, no es parte de un conjunto de herramientas de otras funciones útiles y no brinda los beneficios que esperaba. A menos que de alguna manera alguien muestre evidencia de una comunidad activa de desarrollo y mantenimiento de libros, y a menos que haya un plan para realizar una solicitud seria de la comunidad de Wikimedia para la inversión financiera de la Fundación Wikimedia en el desarrollo de esta herramienta, entonces digo que elimine lo que existe y elimine la opción para que para no distraer a nadie más de herramientas más útiles y compatibles. Mantener herramientas sin soporte cerca no es un beneficio. Los libros funcionan como sé que podrían recrearse como una especie de herramienta en Wikidata para compartir listas de artículos para ejecutar informes sobre ellos, imprimirlos como un libro o coordinar la traducción de artículos importantes en varios idiomas. Al poner esto en Wikipedia en lugar de Wikidata, los beneficios de legibilidad de la máquina no están ahí. Blue Rasberry (charla) 00:06, 16 de mayo de 2021 (UTC)
• Meh y una especie de inclinación se oponen, aunque la usificación masiva estaría bien. Estos ya son muy difíciles de encontrar, y si las propuestas anteriores muestran la tendencia actual, será esencialmente imposible hacerlo. Básicamente, no se enfrentan a ninguna parte, pero no es necesario ni se gana nada ocultando la historia. Si las personas sienten que las cosas de alguna manera estarán más ordenadas sin un espacio de nombres adicional, entonces asegúrese de usarlas, pero realmente una vez que estos sean imposibles de encontrar, cualquier paso adicional, ya sea su eliminación, uso, etc., suena como un trabajo adicional sin un beneficio discernible. Saludos, 31.41.45.190 ( hablar ) 01:38, 16 de mayo de 2021 (UTC)
• Meh , también, deshazte del espacio de nombres del libro. Nadie parece interesado en mantener nada de esto. Si los voluntarios se postulan, tal vez podría revivirse algún día. Por ahora, déjelo continuar en el espacio de usuario. La userfication masiva debería funcionar. Cualquier "libro" que sea claramente basura podría eliminarse. - Alexis Jazz ( habla o hazme ping)
• Oponerse por ahora: si el espacio de nombres está obsoleto, podría ser bueno hacerlo el próximo año. Hacerlo ahora mismo es demasiado pronto. Usuario: 力(power ~ enwiki, π , ν ) 03:21, 16 de mayo de 2021 (UTC)
• Apoye el objetivo final de eliminar el espacio de nombres dada la evidencia presentada. Creo que la eliminación de los libros debería ocurrir, pero quizás solo después de que se hayan movido fuera del espacio de nombres para que los REEMBOLSOS puedan tener lugar. - Izno ( charla ) 03:23, 16 de mayo de 2021 (UTC)
• Soporte : esta función no es compatible y nadie tiene una buena razón para dedicar el tiempo necesario para que funcione. No debemos dejar un desorden como este, como una ruina abandonada. Apoyo la eliminación, que simplemente será representativa de la realidad de que el espacio de nombres 'Libro' está y ha estado muerto durante mucho tiempo. RGloucester - ☎ 04:10, 16 de mayo de 2021 (UTC)
• Apoye el objetivo final de eliminar el espacio de nombres. Sin embargo, para preservar el historial según Hog ​​Farm y Kusma, preferiría "archivarlos" y moverlos a una ubicación como las subpáginas de "Wikipedia: Libros / Antiguo /" o algo así. - SD0001 ( conversación ) 07:44, 16 de mayo de 2021 (UTC)
• Nota: Antes de que se produzca una eliminación real, todas las páginas deben etiquetarse correctamente para que se notifique a las partes interesadas. El aviso de eliminación no debe estar en la parte inferior de un archivador cerrado atrapado en un baño en desuso con un letrero en la puerta que diga "Cuidado con el leopardo". (Me pregunto si debería escribir un ensayo de WP: LEOPARD ). - Kusma ( t · c ) 08:40, 16 de mayo de 2021 (UTC)

  Kusma Claro. Supongo que también querrás etiquetar los casi mil subcoches de artículos de Categoría: Libro-Clase . Vale la pena señalar que WP: CENT y las bombas de la aldea realmente no están en el fondo de un archivador cerrado y atrapado en un baño en desuso, mientras que los libros que no tienen una sola vista la mayoría de los meses sí. - Trialpears ( charla ) 09:23, 16 de mayo de 2021 (UTC)

  ¿Sería suficiente agregarlo a {{ Libro guardado }} con detección de espacio de nombres? Eso ahorraría como 12k ediciones innecesarias. - Trialpears ( charla ) 09:33, 16 de mayo de 2021 (UTC)

  Trialpears , lo ideal sería mover todo el espacio de nombres del libro al lugar de donde vino (solían ser subpáginas de Wikipedia: Libro), entonces podemos evitar notificar a las personas. (Para los usuarios ocasionales, creo que cualquier otra cosa que no sea su página de discusión y su lista de seguimiento podría estar en Alpha Centauri). - Kusma ( t · c ) 09:56, 16 de mayo de 2021 (UTC)

  Ahora agregué un aviso de eliminación personalizado a través de las plantillas {{ Libro guardado }} y {{ Clase de categoría }}. - Trialpears ( charla ) 19:48, 16 de mayo de 2021 (UTC)

• Soporte , con las advertencias adecuadas para las partes interesadas (por ejemplo, el creador del libro). Acabemos con este experimento fallido. Remagoxer ( charla ) 11:45, 16 de mayo de 2021 (UTC)
• Oponerse Esto es un poco extremo, apoyo la desaprobación del espacio de nombres, pero no la eliminación de todo lo que contiene. Jackattack1597 ( charla ) 13:04, 16 de mayo de 2021 (UTC)
• Admite, pero preferiría si pudiéramos archivarlos todos de forma proactiva en un lugar accesible para los usuarios habituales antes de eliminar el espacio de nombres, en lugar de requerir que los libros pasen individualmente por el proceso WP: REFUND después de la eliminación. No veo mucho valor en preservarlos, pero en igualdad de condiciones, es mejor no borrar la historia. Colin M ( charla ) 13:50, 16 de mayo de 2021 (UTC)
• Comentario Esta es la única decisión importante en este RfC, es el punto final de la muerte por mil cortes que los demás están perpetuando. Sigamos con esto, de una forma u otra. Sea cual sea la forma en que esto suceda, tenemos que aceptar que estamos votando sobre si revivir o anular la iniciativa. - Saludos, Steelpillow ( Discusión ) 14:20, 16 de mayo de 2021 (UTC)

  Posteriormente te opones porque "es útil" aunque no funcione. "Sigamos con esto", de hecho. Izno ( charla ) 15:47, 16 de mayo de 2021 (UTC)

  @ Izno : ¿Por qué tan sarcástico? ¿Te he molestado o algo así? Maldita sea, ¿dónde está la plantilla de la taza de té cuando la necesitas? - Saludos, Steelpillow ( Discusión ) 15:13, 18 de mayo de 2021 (UTC)

  ¿No es sarcástico decir "sigamos adelante"? :) Izno ( charla ) 19:52, 18 de mayo de 2021 (UTC)

• Me opongo , encuentro útil la función de Libros; Lo usaría más si aún funcionara tan bien como solía hacerlo. Me entristecerá perderlo. - Saludos, Steelpillow ( Discusión ) 14:20, 16 de mayo de 2021 (UTC)
• Oponerse demasiado por ahora. Vuelva a visitar cuando el futuro de la tecnología esté claro. Actualmente tenemos 51,546 libros en el espacio del usuario y solo 6,198 en el espacio del libro, así que "simplemente" mueva todos los libros en el espacio del libro a una subpágina del usuario que los creó. - Comentario anterior sin firmar agregado por GhostInTheMachine ( charla • contribuciones )

  El futuro es claro: la tecnología está muerta y no resucitará en este momento. - Izno ( conversación ) 15:46, 16 de mayo de 2021 (UTC)

  Probablemente estemos hablando de cosas diferentes. El dispositivo que recopila artículos funcionó cuando lo probé. El gadget que convierte estas listas de artículos en PDF funcionó cuando lo probé. La pregunta aquí es si deberíamos eliminar todos los libros dentro del espacio de nombres del libro y creo que deberíamos moverlos. Una vez que el espacio de nombres está vacío, tenemos la opción de apagarlo: GhostInTheMachine ^{me habla a las} 11:52, 17 de mayo de 2021 (UTC)

• Oponerse Como esto parece ser un asunto técnico controlado por PediaPress y WMF / MediaWiki, regido por un contrato legal entre ellos, entonces esto no es asunto nuestro. Si los editores o lectores no encuentran útil la función, no es necesario que la utilicen. Andrew 🐉 ( charla ) 17:30, 16 de mayo de 2021 (UTC)

  No creo que haya existido nunca ningún contrato legal; ambas partes se han comportado demasiado a la ligera para eso. Además, lo que sea que la WMF se haya suscrito o no sin avisarnos no tiene nada que ver con nosotros - no hay ninguna mención de tal cosa en el código de conducta, etc. Si la WMF tuviera un repentino "Oh, mierda * t! " despertar y cambiar su tono, ese sería su problema, no el nuestro. - Saludos, Steelpillow ( Discusión ) 17:43, 16 de mayo de 2021 (UTC)

  A menos que esté malinterpretando algo masivamente, cualquier contrato entre WMF y PediaPress no tiene absolutamente ninguna influencia sobre si tenemos un espacio de nombres específico en enwiki o no, ni sobre si optamos por desaprobar la función dado que no ha estado funcionando correctamente durante años. . ƒirefly ( t · c ) 17:44, 16 de mayo de 2021 (UTC)

• Soporte sin prisas: brinde una amplia ventana para que cualquier persona que desee reutilizar el contenido lo haga y elimine al final de ese generoso período. zar 18:27, 16 de mayo de 2021 (UTC)
• A raíz del comentario de Iznos anterior, analicé lo que sucedió cuando el espacio de nombres del programa educativo se desinstaló temporalmente. Mientras se desinstalaba el espacio de nombres, era imposible acceder o recuperar páginas (incluso para los administradores). Para evitar esto, todos los libros deben trasladarse a Wikipedia: espacio de nombres de libros antes de una posible eliminación para evitar este problema técnico en esta ocasión. - Trialpears ( charla ) 21:41, 16 de mayo de 2021 (UTC)
• Fuerte apoyo : según mi razonamiento anterior. Necesitamos resolver el problema de raíz. Se debe realizar un proceso de reembolso o un archivo del espacio de nombres (¿en otra wiki? ¿Incluso un simple guiño hacia una bifurcación de Wikipedia en una página de guía?) Para las personas que han estado usando el espacio de nombres para actividades personalmente útiles; no quiero elimine en lo que ha trabajado, pero no quiero transmitirlo como contenido para el lector. - Bilorv ( conversación ) 22:10, 16 de mayo de 2021 (UTC)
• Transwikilos a Wikilibros en inglés por m: Mantenga el historial . Muchos de estos son útiles y tenemos un proyecto WMF que puede albergarlos fácilmente. No debemos eliminarlos y esperar que alguien decida investigar nuestros espacios de nombres muertos antes de comenzar un nuevo esfuerzo. En cambio, deberíamos mover el contenido a un lugar apropiado: Wikilibros. - Wug · a · po · des​ 23:03, 16 de mayo de 2021 (UTC)

  Wugapodes Eso realmente no funcionará. Los libros en el espacio de nombres de libros no son el mismo tipo de libro en el que se enfocan los wikilibros. Si bien los Wikilibros también contienen algunos de este tipo de libros en wikilibros: Wikilibros: colecciones , no funcionarán ya que los Wikilibros no contienen los artículos de Wikipedia en los que se componen estos libros. Si se hiciera esto, literalmente serían listas inútiles de enlaces rojos. No puedo imaginar que Wikilibros quiera eso. - Trialpears ( charla ) 23:13, 16 de mayo de 2021 (UTC)

  Ah, estaba confundido acerca de cómo funcionaba el software. Pensé que el espacio de nombres de los libros contenía la salida del programa (puede decir cuánto uso el espacio de nombres) pero sí, mirarlos sería en gran medida inútil para los wikilibros a menos que copiemos todos los artículos también, lo cual sería una mala idea. Golpeé mi comentario. Estoy bien con lo que sea, siempre que el contenido sea recuperable en el futuro. - Wug · a · po · des​ 23:44, 16 de mayo de 2021 (UTC)

  Creo que el libro ns es y siempre será inútil. Pero, ¿por qué los artículos relacionados no pueden quedarse aquí y los enlaces se pueden cambiar fácilmente? - Killarnee ( C • T • U ) 17:35, 18 de mayo de 2021 (UTC)

  El creador de libros está diseñado para trabajar en páginas que están todas dentro de la misma wiki; cuando lo usa para crear o editar un libro, agrega un banner en la parte superior de la página que puede usar para agregar artículos a su libro mientras navega. . No sé si funcionaría con enlaces cruzados de wiki, pero realmente no está destinado a usarse de esa manera. También siendo franco por un minuto, el espacio de nombres del libro está lleno de basura y me opondría firmemente a tirar nuestra basura en otra wiki con la expectativa de que tendrán que preservarla y mantenerla para nosotros o convertirla en algo que valga la pena. ¿Los wikilibros van a querer el Libro: Blakfacts: Volumen 4.5 , que comienza con una sección sobre "Pequeños negros de baja estatura "? ¿Qué tal su compañero Book: Blakfacts Volumen 12:, que es literalmente solo la lista de algunos de los mejores africanos? ¿Alguien va a leer el Libro: Holocausto americano, que trata en un 50% sobre la extinción del bisonte americano y el 50% sobre la colonización y opresión de los nativos americanos? ¿Los wikilibros querrán que Book: Pirates1 sea una primicia mundial en el género cosmología / piratería / ciencia ficción? ¿Qué pasa con el Libro: Alternativas políticas , que enumera "alternativas válidas al sistema político actual", que consta de una gran cantidad de enlaces a artículos sobre el socialismo? ¿Alguien alguna vez va a leer Book: Gemology and Jewelry , un libro de 500 artículos sin clasificar que incluye todo lo relacionado vagamente con la joyería, o Book: Ancient Monuments In The UK , un libro de 350 artículos sobre monumentos antiguos en el Reino Unido? ¿Cuáles son los criterios de inclusión que se utilizaron para seleccionar artículos para Libro: Biografías principales (A – D) , es solo una lista de lectores de sus artículos favoritos? ¿Quiere un libro que contenga países que fueron artículos destacados en 2012? No se preocupe. Libro: Los artículos destacados de países lo tienen cubierto. Ya hablé de mi experiencia de buscar un libro de historia arriba, pero la gran mayoría del espacio de nombres son proyectos personales abandonados que no deberíamos presentar a los lectores como "mantenidos por la comunidad". Si se van a mantener, usarlos en el espacio de usuario del creador original es probablemente la mejor manera de lidiar con ellos, en mi opinión. 192.76.8.73 ( conversación ) 22:00, 18 de mayo de 2021 (UTC)

• Soporte por nominación y discusión extendida arriba. EpicPupper ( charla ) 04:17, 17 de mayo de 2021 (UTC)
• Soporte siempre que haya alguna forma de reembolsar el material solicitado. Ajpolino ( charla ) 05:53, 17 de mayo de 2021 (UTC)
• Oponerse . La razón por la que el espacio de nombres del Libro está lleno de basura no es porque los libros sean una mala idea, es un artefacto de factores históricos (principalmente el servicio de reproducción de libros está jodido). Si ya no hay una afluencia de libros de mierda (es decir, deshabilitar la función para hacerlos fácilmente), creo que sería fácil limpiarlos y escribir buenos. jp × g 06:30, 17 de mayo de 2021 (UTC)
• Oponerse : no hay razón para ocultarlos de la vista del público. No indexar y eliminar de ciertas formas del motor de búsqueda es más que adecuado. -  Godsy  ^{( TALK} _{CONT )} 07:02, 17 de mayo de 2021 (UTC)
• Soporte ¿O qué hay de mover las páginas a Wikilibros en lugar de eliminar todas las páginas? - Killarnee ( C • T • U ) 17:25, 18 de mayo de 2021 (UTC)

  Vea las respuestas a Wugapodes, quienes hicieron una sugerencia idéntica en algunos comentarios. * Pppery * _{ha comenzado ...} 17:28, 18 de mayo de 2021 (UTC)

• Oponerse A menudo uso la pestaña Libro para realizar un seguimiento de los cambios en temas específicos. Aprovecho mucho más esto que la lista de vigilancia. Dobbyelf62 ( charla ) 23:27, 18 de mayo de 2021 (UTC)

  Es de suponer que podría utilizar un libro de espacio de usuario (que no se verá afectado por esta propuesta) o Special: RecentChangesLinked para el mismo propósito. * Pppery * _{ha comenzado ...} 02:43, 19 de mayo de 2021 (UTC)

• Apoyo con el objetivo de eliminar el desorden del espacio de nombres. También está bien moverse a una ubicación de archivo en otro espacio de nombres, como algunos han sugerido, por ejemplo, Wikipedia: Libros / Antiguo. el wub "?!" 13:56, 23 de mayo de 2021 (UTC)
• Soporte si no pueden / no deben moverse a WikiBooks  -  John M Wolfson  ( charla  •  contribuciones ) 14:42, 23 de mayo de 2021 (UTC)
• Soporte ¿Qué otra wiki usa este espacio de nombres? Somos los únicos que lo usan y actualmente está desaprobado . Podemos descargar páginas en formato PDF y ya existe otra wiki para libros. ¿Por qué mantener un espacio de nombres que no se usa? Creo que una posibilidad sería eliminar todas las páginas del espacio de nombres del Libro y poner el espacio de nombres en la lista negra. Sería mucho más fácil que eliminar el espacio de nombres. Si se eliminan todas las páginas de este espacio de nombres, reembolse todas las páginas editadas en los libros ns y también en los libros talk ns si se eliminan. 54nd60x ( charla ) 03:03, 25 de mayo de 2021 (UTC)
• Oponerse a Wikipedia: los libros son muy útiles, agrupan y consolidan lógicamente artículos e información de una manera simplificada y * accesible * que no se puede hacer en ninguna otra parte de la enciclopedia. Ofrecen enlaces rápidos a servicios importantes para nuestros lectores, como la posibilidad de descargarlos como versiones PDF (consulte Libro: Jane Austen, por ejemplo). Además, las páginas de Book_talk vienen con algunas herramientas de seguimiento vitales como Plantilla: Informe del libro que nos brinda una buena descripción general de todos los estados (limpieza, medios no libres, etc.) de cada artículo dentro de cada libro. Haga clic en "mostrar" en la plantilla para ver la funcionalidad completa y consulte también Book talk: Jane Austen como ejemplo. Cualquiera que sea la acción técnica o la solución que elija aplicar, * no elimine * nuestros maravillosos libros de Wikipedia. Recuerde el WP: READER . Gracias, History DMZ ^{( HQ ) † ( cable )} 15:53, 28 de mayo de 2021 (UTC)

Oponerse por razones históricas. En cambio, los libros deberían quedar obsoletos y dejarse así. Tyrone Madera ( charla ) 20:13, 28 de mayo de 2021 (UTC)

• Apoyo a la eliminación Es hora de dejar de lado este experimento fallido. oknazevad ( conversación ) 22:20, 28 de mayo de 2021 (UTC)
• Apoyo después de darles a los creadores de libros la oportunidad de descargar sus libros. - Fredddie ™ 19:07, 30 de mayo de 2021 (UTC)
• Soporte : una solución mucho mejor se hará evidente en el futuro. Hasta entonces, elimine. Schierbecker ( charla ) 07:26, 1 de junio de 2021 (UTC)
• Soporte : no tiene mucho sentido mantener cosas que casi no se usan y que nunca se podrán usar. MichaelMaggs ( hablar )
• Soporte por arriba. - SilverTiger12 ( conversación ) 22:15, 5 de junio de 2021 (UTC)
• Soporte - Favre1fan93 ( charla ) 13:54, 8 de junio de 2021 (UTC)
• Soporte —¿philoserf? ( charla ) 00:34, 10 de junio de 2021 (UTC)
• Soporte Siempre que me encuentro con un elemento en el espacio de nombres del libro, no es ni mejor ni peor que exactamente lo mismo en el espacio principal. De vez en cuando, veo Libros que fueron claramente creados por un error con una plantilla mal ejecutada y, obviamente, no son utilizados por nadie, incluido su creador. Cuando el contenido se actualiza en el espacio principal, los cambios no se propagan necesariamente al espacio del Libro, lo que crea contenido duplicado y actualizado. Los libros han quedado obsoletos desde hace algún tiempo, por lo que el único seguimiento lógico es publicar advertencias sobre la eliminación futura para cualquier persona que todavía use Libros (ya sucedió) y luego eliminar todos los libros restantes. Además, existen otros equivalentes como lectores de Wiki fuera de línea y exportaciones de Wiki que pueden servir para el mismo propósito que los libros. Anton.bersh ( charla ) 18:33, 10 de junio de 2021 (UTC)

Ocultar avisos de TfD para usuarios no confirmados automáticamente

‹Se está considerando la eliminación de la siguiente plantilla ( ejemplo ). Consulte las plantillas de discusión para ayudar a llegar a un consenso. ›

Después de una discusión en WT: TFD, me gustaría proponer que se oculten los avisos de TfD (la apariencia predeterminada que se muestra arriba) de los usuarios que no están autoconfirmados. Esto ocultaría a los lectores el contenido que solo sea de interés para los editores. Es muy importante que los editores estén al tanto de las grandes discusiones sobre TfD, ya que pueden tener efectos de amplio alcance y, en ocasiones, hay IP o nuevas cuentas que hacen sus primeros comentarios en TfD. Siento que la compensación aquí entre la entrada de IP y los avisos innecesarios es aceptable, pero creo que esto es algo en lo que las personas que no son habituales de TfD también deberían opinar. - Trialpears ( charla ) 19:29, 15 de mayo de 2021 (UTC)

Encuesta (avisos TfD)

• OPONERSE - Si bien simpatizo con la intención, ignora el hecho de que tenemos editores a largo plazo que, por diversas razones, continúan editando como IP y no inician sesión con nombres de usuario. Es posible que deseen participar en las discusiones sobre TfD, por lo que deben ser informados de ellos. Blueboar ( charla ) 19:45, 15 de mayo de 2021 (UTC)
• Soporte: simpatizo con los usuarios de IP que están editando activamente, pero (según tengo entendido) en el gran esquema de Wikipedia prácticamente ninguno de nuestros lectores son usuarios registrados, y la cantidad de editores de IP que editan de manera regular y activa es igualmente minúsculo. Como tal, no tiene sentido empujar estos avisos en su cara y si realmente queremos priorizar las páginas orientadas al lector, debemos recordarlo. Aza24 ( conversación ) 19:57, 15 de mayo de 2021 (UTC)
• Soporte La mayoría de las veces, esto es una pérdida de espacio confusa. Cuando una plantilla grande (como un cuadro de información ampliamente utilizado) es nominada en TfD, a menudo se muestra un aviso en cientos de miles (a veces millones) de páginas, cada una con muchos lectores. Así que, básicamente, tenemos millones de lectores que ven un feo y confuso aviso de "plantillas para discusión" en la parte superior de las páginas. Como cliente habitual de TfD, puedo decir que la participación de la PI no es tan alta de todos modos. Y desafortunadamente, si uno toma la decisión de seguir usando una IP, debe aceptar los inconvenientes que se derivan, como limitaciones en la creación de artículos, captchas, estar más sujeto a editar, filtrar falsos positivos, no poder editar páginas por semiprotección, etc. Comparado con todos esos, este es un inconveniente menor. Es lo mismo que el hecho de que los usuarios demasiado paranoicos para habilitar JavaScript tienen que aceptar que, como resultado, muchos sitios web no funcionarán correctamente. ProcrastinationReader ( charla ) 19:59, 15 de mayo de 2021 (UTC)
• Soporte , como algo que logra un equilibrio mucho mejor entre las necesidades del lector y el editor que el status quo, que ( como muchas cosas ) está demasiado inclinado hacia las necesidades del editor. Aza24 y ProcrastinatingReader refutaron con éxito el argumento de oposición de Blueboar. {{u | Sdkb }}  ^charla 20:29, 15 de mayo de 2021 (UTC)
• Soporte - en gran parte por ProcrastinationsReader. Esto solo será una molestia para la mayoría de los lectores que no son editores registrados. El lector medio no registrado no se preocupa demasiado por los procesos en segundo plano, por lo que no deberíamos empujar los procesos en segundo plano en sus caras con avisos. _{Charla sobre la} granja de _cerdos 21:12, 15 de mayo de 2021 (UTC)
• Soporte Honestamente, probablemente también podríamos ocultar muchas de las otras notificaciones. Este es uno de los peores en términos de spam y uso para los lectores (y muchos editores). Air corn  (charla) 21:51, 15 de mayo de 2021 (UTC)
• Los usuarios opuestos no autoconfirmados también son humanos . La última vez que lo comprobé, hacer ediciones como esta no era un delito. A menos que se convierta en política semiproteger todas las páginas XfD, ¿por qué deberíamos negarles el derecho a ver los mensajes TfD? Si no ven los mensajes, ¿cómo sabrán que hay una discusión en curso, y mucho menos saber que pueden participar? La participación de TfD ya es lo suficientemente baja sin reducirla aún más. Además, estoy seguro de que esto ha sido propuesto y rechazado al menos dos veces antes. - Red rose64 🌹 ( hablar ) 22:13, 15 de mayo de 2021 (UTC)

  De hecho, lo ha sido . * Pppery * _{ha comenzado ...} 22:26, ​​15 de mayo de 2021 (UTC)

  re "¿por qué deberíamos negarles el derecho a ver los mensajes de TfD?", porque dar avisos irrelevantes a millones de lectores cada mes supera de manera abrumadora las necesidades de los pocos editores de IP activos. Estamos aquí ante todo para nuestros lectores. Aza24 ( conversación ) 22:58, 15 de mayo de 2021 (UTC)

  Sin mencionar que muy pocos o ningún editor de IP participan en TfD. Considere esto en 51k páginas (con un número de lectores combinado de probablemente 100k-1M durante el período de TfD), esto en cada caso SCOTUS de EE. UU., Esto en 1.956.845 transclusiones (luego se tuvo que deshabilitar), esto en 5k transclusiones, esto en toda la legislación de EE. UU. páginas. Ninguno de ellos tenía ninguna participación IP; esta es la norma en TfD. ProcrastinationReader ( charla ) 23:10, 15 de mayo de 2021 (UTC)

• Me opongo , no veo lo que ha cambiado significativamente desde las discusiones anteriores que vinculé anteriormente. * Pppery * _{ha comenzado ...} 22:26, ​​15 de mayo de 2021 (UTC)

  ¿Cuál es ... no una justificación opuesta? Porque WP: CCC . Y hay algunos argumentos deficientes de la OMI en esas discusiones, por ejemplo, que algunos editores de Wikipedia leen Wikipedia desconectados y, por lo tanto, deberíamos mostrar el aviso a millones de lectores (?). La idea de que fomente la participación del editor también es inestable. Las plantillas no son un área donde un novato puede ir y puede contribuir significativamente a un TfD. No, y lo que es más probable es que mucha más gente diga "¿Qué es esto? ¿Por qué la página se ve tan desordenada? ¿Qué es una" plantilla para eliminar "y por qué me muestran esto?" ProcrastinationReader ( charla ) 22:57, 15 de mayo de 2021 (UTC)

• Oponerse por todos los opositores anteriores.   ~  Tom.Reding ( talk ⋅ dgaf )   23:01, 15 de mayo de 2021 (UTC)
• Oponerse , lo que es interesante o útil para cualquiera no está definido por su estado autoconfirmado. Mostramos millones de otros mensajes de mantenimiento a todos nuestros usuarios (y muchos de ellos son irrelevantes para los lectores que no desean editar, como {{ huérfano }} o {{ escritura china necesaria }}), y TfD solo está activado para unos pocos. días, no muchos años como otros. (Y generalmente es bueno recordarle a la gente que Wikipedia no es un producto terminado y que no es necesario que haya una distinción entre "lectores" y "editores"). - Kusma ( t · c ) 23:14, 15 de mayo de 2021 (UTC)

  Acaba de presentar un buen argumento para no mostrar {{ Orphan }} a los lectores (y de hecho no se lo mostramos a nadie cuando tiene más de un mes o más), pero esa es una discusión para otro momento. En última instancia, sería bueno tener una preferencia del usuario para mostrar elementos centrados en el editor, como etiquetas huérfanas o avisos TfD, pero hasta que se implemente esa funcionalidad, autoconfirmed vs. not es el mejor proxy que tenemos. {{u | Sdkb }}   ^charla 06:47, 16 de mayo de 2021 (UTC)

• Soporte según los argumentos presentados por Aza24 y ProcrastinationsReader. ~ HAL 333 23:55, 15 de mayo de 2021 (UTC)
• Oponerse Hay algunos editores de IP por ahí. Y, a veces, la participación en xfds es el primer paso hacia una participación más activa en el proyecto. Podríamos suprimir fácilmente los avisos de AFD y las plantillas de mantenimiento, pero no lo hacemos, ¿por qué? Bueno, a veces son útiles para involucrar a la gente o simplemente para obtener una opinión externa, y estos son mucho menos intrusivos que cualquiera de los dos. Saludos, 31.41.45.190 ( conversación ) 01:30, 16 de mayo de 2021 (UTC)
  • Las plantillas son una de las áreas más complejas de Wikipedia; TfD no es el mejor lugar para principiantes. {{u | Sdkb }}  ^charla 06:40, 16 de mayo de 2021 (UTC)
    • Tengo que estar respetuosamente en desacuerdo con Sdkb , desde la perspectiva de la complejidad en términos de políticas / directrices, así como de normas no escritas, afd es mucho más abrumador. No me atrevo a comentar sobre eso sin revisar al menos algunas de las pautas, así que no estoy diciendo tonterías. OTOH He ingresado en tfds sin hacer más que volver a hojear la parte superior de la página y aún no me han acusado de ser un caso cir o de hacer evaluaciones basadas en pautas desactualizadas. Saludos, 31.41.45.190 ( conversación ) 14:11, 16 de mayo de 2021 (UTC)
• El soporte resuelve más problemas de los que crea. Headbomb { t · c · p · b } 03:16, 16 de mayo de 2021 (UTC)
• Oponerse a tener estas notificaciones para fusionar discusiones con plantillas muy comunes como {{ tl }}, {{ talk header }} y {{ infobox person }} son molestas para todos los editores. Para las plantillas menos comunes, me gustaría ver estas notificaciones si no estoy conectado y los editores de IP constructivos probablemente también quieran verlas. Ciertamente, hay algunas notificaciones que no son útiles para los lectores, pero no creo que sea un problema lo suficientemente amplio como para justificar esta solución. Usuario: 力(power ~ enwiki, π , ν ) 03:20, 16 de mayo de 2021 (UTC)
• Oponerse a la implicación de que los IP no son bienvenidos a participar. SpartaN ( charla ) 07:12, 16 de mayo de 2021 (UTC)
• Oponerse Mostrar cosas relacionadas con el editor a todo el mundo es una de las formas en que somos 'la enciclopedia libre que cualquiera puede editar'. Si comienza a ocultar cosas porque solo los editores deberían verlas, terminará con menos editores con el tiempo. Mike Peel ( charla ) 07:47, 16 de mayo de 2021 (UTC)
• Oponerse a estos avisos no hace daño a la vista. ¿Deberíamos ocultar también los avisos de AfD? Creo que es bueno darles a los lectores la oportunidad de conocer cualquier discusión que afecte el contenido de la página que están leyendo. Elli ( charla | contribuciones ) 10:28, 16 de mayo de 2021 (UTC)

  Elli La comparación con los avisos de AfD no es particularmente justa. Un aviso de AfD se coloca en una página donde el resultado afecta mucho al artículo, mientras que los avisos de TfD pueden estar presentes en decenas, cientos o miles de páginas con un impacto minúsculo en esa página. A continuación, se muestran algunos ejemplos: Eliminar una función que no ha funcionado durante años con alrededor de 100k avisos, cambiar las partes internas de las etiquetas en el idioma alrededor de 300k avisos y objetivos de fusión de infobox cuya apariencia o parámetros no se verán afectados en absoluto (30k para un discusión abierta sobre 500k cuando se trata de liquidación de infobox). - Trialpears ( charla ) 10:51, 16 de mayo de 2021 (UTC)

  @ Trialpears : Supongo que la otra razón de mi reacción en contra de esto es por la misma razón que ha dicho Kusma : En mi mundo de fantasía personal, "la enciclopedia libre que cualquiera puede editar" significa, entre otras cosas, que consideramos a cada lector como un editor potencial.

  ¿Es una fantasía que un alto porcentaje de nuestros lectores esté interesado en contribuir? Si. ¿Deberíamos ocultarles la parte de contribución del sitio? Para nada. Todavía está en la visión del sitio incluir a estas personas.

  Además, creo que muchos de los TFD no tiene un efecto apreciable sobre sus inclusiones (por ejemplo, plantillas de navegación). Elli ( charla | contribuciones ) 10:55, 16 de mayo de 2021 (UTC)

  Elli , incluimos avisos de AfD porque son de gran utilidad para los lectores que no editan. Les dicen a los lectores que la página puede tener problemas importantes, funcionando como una especie de versión más fuerte de {{ Notability }} u otras etiquetas de mantenimiento. También ayudan a los lectores que, de otro modo, intentarían volver a leer un artículo en una fecha posterior y se confundirían cuando no pudieran encontrarlo. Estos factores no se aplican a los TfD de plantillas utilizadas en una página. La situación aquí es más parecida a un RfC importante en la página de discusión de un artículo. No hay ningún aviso al respecto porque no es algo que los lectores deban saber para poder usar la página de manera efectiva. {{u | Sdkb }}   ^charla 22:01, 17 de mayo de 2021 (UTC)

  @ Sdkb : a veces sí tenemos un anuncio de este tipo de artículos, tales como avisos de combinación (que la mayoría de los lectores probablemente no se preocupan), RMS (de nuevo, y estos como para persistir en la parte superior de cualquier evento actual polémica), y las etiquetas como {{ disputado en línea }}. Elli ( charla | contribuciones ) 01:21, 18 de mayo de 2021 (UTC)

  El hecho de que los MR tengan una relevancia limitada para los lectores es lo que motivó toda esta propuesta . Creo que los avisos de fusión y los en línea en disputa tienen relevancia para los lectores: un aviso de fusión indica un posible cambio en el artículo que de otro modo podría ser confuso, y en línea en disputa advierte al lector de información potencialmente sesgada. {{u | Sdkb }}   ^charla 02:20, 18 de mayo de 2021 (UTC)

• Oponerse . Deberíamos ocultar estos avisos de TfD porque hay pocas IP que participan en TfD. Entonces, la solución es incluso disminuir la ya pequeña cantidad de IP que participan en TfD. Lo siento, pero esto suena como algo que haría Mozilla. No repita el mismo error que cometió Firefox, que es eliminar funciones porque "nadie las está usando".

  Sin embargo, estaría abierto a cualquier método que permita ocultar estos avisos. Entiendo que no todo el mundo está interesado en dicha discusión, pero esto también se aplica a los usuarios confirmados automáticamente. Así que creo que la mejor solución aquí sería permitir una opción para ocultar estos avisos sin discriminar a los editores de IP muy nuevos. pandakekok9 ( conversación ) 11:01, 16 de mayo de 2021 (UTC)

• Opónganse por Elli. No necesitamos dificultar que los lectores se conviertan en editores. (Me recuerda que la primera edición de cierto ex funcionario fue a un TfD que vio transcluido). Profeta Vaticidal 11:26, 16 de mayo de 2021 (UTC)

  Me dijeron que el ex funcionario fue acosado por supuestamente ser un títere de calcetines y ahora ha desaparecido. ProcrastinationReader ( charla ) 12:06, 16 de mayo de 2021 (UTC)

  En efecto. La primera edición en cuestión me parece muy "convincente" a la primera edición (¡me recuerda a mis primeros votos de XfD!). Irónicamente, muchas de las críticas que parecía ser la incredulidad un nuevo usuario podría posiblemente encontrar el reino bien escondido de TFD ... Vaticidal profeta 12:22, 16 de Mayo 2021 (UTC)

  Entonces, solo para asegurarme de que entendí bien, la oposición argumenta aquí que se debe alentar a los usuarios a ir a TfD porque esta es la enciclopedia que cualquiera puede editar. Pero cuando alguien lo hace de manera competente, nosotros (con impunidad) lo acusamos de ser una marioneta. Entonces, ¿básicamente el umbral aceptable son las contribuciones de PI incompetentes a TfD? ProcrastinationReader ( charla ) 12:33, 16 de mayo de 2021 (UTC)

  El umbral aceptable es que la forma de "culpables hasta que se demuestre su inocencia" en la que tratamos a los editores nuevos a nuevos como casos de CIR o calcetines es completamente extraña y espantosa, y tenemos que superarlo. No creo que esconder cada vez más el backstage de los lectores sea particularmente útil para resolver ese problema, ya que solo hace que la comunidad sea aún más cerrada. Profeta Vaticidal 12:36, 16 de mayo de 2021 (UTC)

• Oponerme porque la mayoría de los argumentos opuestos tienen sentido para mí, y estoy a favor de la igualdad de transparencia para todos los wikipedistas, incluidos los lectores / editores y los usuarios registrados / IP. Huggums537 ( charla ) 17:41, 16 de mayo de 2021 (UTC)
• Soporte , por Sdkb. La posible exclusión de un número comparativamente pequeño de editores de propiedad intelectual de las discusiones de TfD se ve superada por el leve inconveniente para potencialmente millones de lectores de tener un desorden confuso en la parte superior de una página. Recuerda nuestro WP: AIM : una enciclopedia accesible . Hacer que miles de artículos sean un poco menos accesibles para los lectores en beneficio de un pequeño subconjunto de editores es contrario a este propósito. 129.49.100.55 ( conversación ) 18:57, 17 de mayo de 2021 (UTC)

  No estoy seguro de por qué piensa que los avisos de TfD hacen que los artículos sean menos accesibles. Es molesto, claro, pero ¿hace que el artículo sea menos accesible? Literalmente, hay otros avisos peores que ese y posiblemente hacen que el artículo sea menos accesible. Los {{ cn }} en línea son una cosa. También está el aviso de talón. Ah, ¿y mencioné la plantilla {{se necesitan más fuentes }}? pandakekok9 ( charla ) 09:17, 18 de mayo de 2021 (UTC)

• Soporte por ProcrastinationReader. KevinL ( alt de L235 · t · c ) 07:02, 18 de mayo de 2021 (UTC)
• Oponerse : si bien es una gran idea, hay un defecto fundamental. Dado que "Internet en general" utiliza el registro, es extraño que Wikipedia luche tan duro contra él. Tengo que registrarme en cualquier lugar al que vaya en Internet y no puedo comprender cómo el registro supondría un obstáculo para "permitir que cualquiera pueda editar". No me hubieran golpeado con dos bloques de rango inexplicables (uno global) si todos estuvieran registrados. Sin embargo, a menos o hasta que haya un cambio en el registro obligatorio, no podemos pretender ser una enciclopedia que cualquiera puede editar y reclamar.Cualquier colaborador de esta enciclopedia, tanto registrado como no registrado, se denomina "wikipedista" y ofrece restricciones como esta. Actualmente, un editor no registrado (editor de IP) ocupa el mismo puesto que yo como editor registrado durante más de una docena de años. Algunos de nosotros preocupados por la política de Wikipedia todavía tenemos que considerar la posibilidad de que un lector vea un aviso de interés y se convierta en un "editor" involucrado o que actualmente, aunque con algunas restricciones, un editor de IP siga siendo miembro de la comunidad de edición y estoy seguro de que muchos se involucran en las discusiones de TfD. Otr500 ( conversación ) 12:40, 18 de mayo de 2021 (UTC)

  "Restricción" es un término bastante fuerte para usar aquí. No estamos hablando de WP: TfD semiprotector para evitar que los IP voten allí; cualquier IP que quiera podría ir allí y contribuir a las discusiones. Será menos probable que se enteren de una situación en particular, sí, pero vea los comentarios arriba y abajo sobre que es una compensación fácil de hacer. {{u | Sdkb }}   ^charla 23:50, 18 de mayo de 2021 (UTC)

• Oponerse a la idea de que la mayoría de los lectores no son editores registrados (o incluso no registrados) es difícil de reconocer. Todas las demás plantillas "para discusión" se publican en su artículo o página de discusión para aportar más información a la discusión, por lo que no tiene sentido intentar reducir esa entrada para las plantillas. Las plantillas TFD de ninguna manera reducen el acceso a los artículos. Están allí por un espacio de tiempo relativamente corto y son mucho más pequeños que la mayoría de los mensajes FD. El hecho de que algunos los encuentren estéticamente desagradables no es una razón para eliminarlos. MarnetteD | Charla 14:36, 18 de mayo de 2021 (UTC)
• Oponerse - Encuentro que la propuesta está redactada de forma confusa. ¿Qué significa la última oración ( Siento que la compensación aquí entre la entrada de IP y los avisos innecesarios es aceptable, pero creo que esto es algo en lo que las personas que no son habituales de TfD también deberían opinar. ? Los editores de IP a menudo son editores experimentados que han cerrado sesión y que pueden obtener una notificación más temprana de las plantillas que les interesan y que están calificados para comentar que si estuvieran excluidos de dichas notificaciones. Dhtwiki ( conversación ) 22:53, 18 de mayo de 2021 (UTC)

  Dhtwiki Si solo mostramos el aviso a los editores de IP , definitivamente estaría de acuerdo con su análisis, pero se lo mostramos a todas las IP. Una proporción muy pequeña de vistas proviene de editores. Obtenemos alrededor de 250,000,000 de visitas cada día, asumimos que la persona promedio visita 5 páginas y tenemos 50 millones de espectadores únicos cada día. Quizás hay 100 editores de IP que pueden estar interesados ​​en TfD si ven un aviso (creo que sería más que el número de IPs que contribuyeron el año pasado). Eso significa que con lo que creo que son estimaciones generosas obtendríamos un 0,0002% de lectores que podrían estar interesados. Es decir, varios 100.000 lectores a los que no les importa que TFD vean un aviso al respecto por cada persona que pueda interesarse. Hay muchas cosas que podría debatir en este cálculo aproximado, pero me cuesta ver que algún método razonable obtenga valores distintos de decenas de miles de avisos para cada uno de los relevantes.

  Mi analogía aquí sería colocar miles de carteles en todas partes en una gran ciudad con la esperanza de encontrar a un extraño que se cayó el sombrero. Claro, no es gran cosa ver un póster irrelevante, pero ¿sería sensato colocar miles de ellos? - Trialpears ( charla ) 00:30, 19 de mayo de 2021 (UTC)

  ¿Cuántos lectores que no son editores acceden a la página de discusión? ¿Cuánto cuesta publicar el mensaje en términos de E / S en lugar de publicar el mensaje * condicionalmente * con el procesamiento de asistente adicional (sé que se supone que no debemos preocuparnos por el rendimiento del lado del servidor, pero aún así)? Dhtwiki ( charla ) 02:56, 19 de mayo de 2021 (UTC)

• Soporte . ¿Alguien puede pensar en un solo ejemplo de un lector que convertimos en un editor prolífico como resultado de un aviso de TfD? El inconveniente que se les presenta a los lectores en millones de páginas supera con creces cualquier efecto en la edición. ¿Y quién puede decir que ese efecto es necesariamente positivo? Podría ser que ver una señal tan aterradora realmente desanime a los posibles editores, haciéndoles pensar que los procesos de Wikipedia son demasiado esotéricos para que los aprendan. - Rey de ♥ ♦ ♣ ♠ 03:51, 19 de mayo de 2021 (UTC)
• Oponerse , solución buscando un problema. Sofocar ( charla ) 09:15, 19 de mayo de 2021 (UTC)
• Oponerse a. Por estas razones, se podría suprimir la visualización de todas las plantillas de mantenimiento para los usuarios de IP. Pero cumplen una función importante incluso para los lectores: dejan en claro que Wikipedia es un trabajo en progreso, que se basa en la discusión comunitaria, el consenso y que todos son libres de participar en ella. Sandstein 13:19, 19 de mayo de 2021 (UTC)

  Para el registro, las plantillas de mantenimiento se aplican sobre una base específica de artículo, por lo general brindan tareas que no son técnicamente difíciles o requieren un amplio conocimiento de políticas, y probablemente tengan mejores tasas de conversión. Los avisos de TfD tienden a ser menores, a menudo de limpieza, fusiones, a menudo requieren conocimiento de políticas y plantillas, y se difunden a gran escala, y los programas de evidencia no invitan a la participación. Una comparación más adecuada serían las discusiones de WP: CENT y WT: MOS , que son mucho más impactantes a escala y no se anuncian ampliamente a nuestros lectores. ProcrastinationReader ( charla ) 12:46, 20 de mayo de 2021 (UTC)

• Oponerse No se debería exigir un nombre de usuario para participar en ninguna parte de Wikipedia. Los editores de PI deben tener la misma expectativa de ser notificados de los debates relevantes que puedan interesarles que los usuarios autoconfirmados. - Jayron 32 14:32, 19 de mayo de 2021 (UTC)
• Soporte : especialmente cuando la plantilla se basa completamente en texto, últimamente Plantilla: la prosa de Rotten Tomatoes fue nominada para su eliminación y, como resultado, cada transclusión de esta plantilla, que se supone que parece un texto normal, se etiquetó con un aviso de eliminación. Este es un gran inconveniente para nuestros lectores, que siempre debemos poner ante nuestros editores. versacespace deja un mensaje! 13:16, 20 de mayo de 2021 (UTC)
• Opónganse , oh, ustedes de poca fe en que los lectores tengan la capacidad de ignorar los mensajes irrelevantes de TfD. Es una plantilla mínimamente invasiva intencional que casi no requiere esfuerzo para descartarla mentalmente. Sospecho firmemente que esto no tiene casi nada que ver con la forma paternalista "proteger" a los usuarios, sino que el conductor real es el deseo de no tener que lidiar con el aporte de la plebe de los usuarios no registrados que se percibe como mal informado. Si no están informados, infórmeles. Si publican aportes irrelevantes, bríndeles las herramientas para que sean relevantes. Esto es algo bastante básico. AfD se ocupa de esto a diario y excluir a los usuarios no registrados es un último recurso absoluto en casos de interrupciones obvias. Esta propuesta haría que TfD tratara anómalamente a los usuarios no registrados como excluidos de forma predeterminada. Eggishorn (charla) (contrib) 15:30, 21 de mayo de 2021 (UTC)

  Dudo mucho de su especulación sin fundamento. Hablando como alguien que es un habitual en TfD y que busca interactuar regularmente con los recién llegados como anfitrión de Teahouse, la presencia de los recién llegados en TfD es tan pequeña que la "interrupción" de ella es esencialmente un problema. ¿Por qué es tan difícil que AGF crea que algunos editores se preocupan por la usabilidad y hacen propuestas relacionadas? {{u | Sdkb }}   ^charla 16:36, 23 de mayo de 2021 (UTC)

• Oponerse al elocuente comentario de Jayron32 a continuación: No existen los "no editores". Solo hay "editores que aún no han comenzado a editar" . el wub "?!" 13:32, 23 de mayo de 2021 (UTC)
• Los más fuertes se oponen a los perspicaces comentarios anteriores, y especialmente a la observación de edición centrada en el lector a continuación. EpicPupper ( charla ) 16:56, 25 de mayo de 2021 (UTC)
• Oponerse filosóficamente. Las IP también son humanas (lo fue en algún momento, puedo confirmarlo). A menos que uno pueda presentar evidencia significativa de abuso a largo plazo por parte de personas que no son AC en TfD, no veo lo que se ganaría con la propuesta, excepto la eliminación de algunas molestias visuales menores para algunos usuarios. En cuanto a la interrupción, si uno realmente tenía la intención de hacerlo, puede ir directamente a WP: TFD . No veo lo que la propuesta lograría, más allá de dar crédito a los sentimientos de algunos editores sobre las IP. AfD (y ocasionalmente MfD) son mucho más propensos al tipo esperado de interrupción, de todos modos, y cuando eso sucede, es una cuestión simple. Por lo tanto, no solución a un no problema. RandomCanadian ( charla / contribuciones ) 19:26, 25 de mayo de 2021 (UTC)
• Apoye cualquier medida que disminuya la monstruosidad de los avisos de TfD. Para todos nuestros lectores y el 99,9% de nuestros editores, estos avisos son un ruido irrelevante. Los avisos feos y confusos como estos tienen más probabilidades de disuadir a los nuevos editores de IP de involucrarse en primer lugar. gobonobo ^{+ c} 07:25, 30 de mayo de 2021 (UTC)
• Oponerse . Wikipedia es una zona en construcción y, a veces, los lectores verán un poco de polvo. Eso incluso puede generar curiosidad sobre cómo pueden unirse y participar. Por lo demás, los avisos no son comunes ni terriblemente intrusivos. (Si se discutiera una plantilla muy utilizada, un medio alternativo de notificar a la comunidad sobre la discusión puede ser razonable). Seraphimblade ^Háblame 03:54, 31 de mayo de 2021 (UTC)
• Oponerse . Muchas personas optan por editar sin registrarse, o se acaban de registrar, o prefieren no permanecer conectado a las cuentas, o se verían impulsadas a participar por un TfD. Hay plantillas para las que me habría activado antes de unirme; el proponente incluso menciona que esto ocurre. También miro a menudo a WP cuando no estoy conectado (por ejemplo, me podrían despedir por iniciar sesión en mi cuenta de WP en una computadora del trabajo), y en el pasado participé en un TfD después de ver un aviso. ¿Por qué debemos ocultar a los lectores que pueden participar? ¿Por qué deberían ignorar que WP no está en una forma final perfeccionada? No tenemos problemas para pedir donaciones o que la gente se una a los eventos de edición, pero una pequeña línea sobre un TfD es demasiado. ¿O simplemente no estamos interesados ​​en escuchar las opiniones de los lectores? Para las personas que apoyan eliminarlo porque es desordenado o ruidoso, estoy de acuerdo en que es estéticamente malo, pero podemos intentar hacerlo menos molesto primero en lugar de ralentizar el cierre de las puertas de WP. Ah, y recuerde que tenemos ese molesto problema de sesgo , esto seguro que no lo mejoraría. - Xurizuri ( charla ) 08:09, 31 de mayo de 2021 (UTC)
• Oponerse , es decir, conservar las notificaciones. La modificación de una plantilla modificará potencialmente lo que leerá el lector en el futuro. Por lo tanto, incluso los lectores puros tienen derecho a saber qué sucederá la próxima vez. Pldx1 ( conversación ) 07:59, 1 de junio de 2021 (UTC)
• Los avisos de compatibilidad con TfD no son relevantes para casi todos los lectores. Esta discusión parece preparada para continuar una tendencia decepcionante en la que se mantienen los deseos de una pequeña minoría de editores de élite , en detrimento de la gran pero silenciosa mayoría. - Tera tix ₵ 05:45, 2 de junio de 2021 (UTC)
• En contra , el efecto negativo de que los lectores normales vean las plantillas de TfD es menor que el efecto positivo de que los editores de IP desde hace mucho tiempo estén informados de las discusiones sobre TfD. Devonian Wombat ( charla ) 23:06, 2 de junio de 2021 (UTC)
• Oponerse Cada lector es un nuevo editor potencial. Además, hay muchos contribuyentes de propiedad intelectual buenos a largo plazo. Nguyentrongphu ( charla ) 12:59, 4 de junio de 2021 (UTC)
• Me opongo . Creo que es bueno ser transparente sobre cómo hacemos las cosas. SportingFlyer T · C 23:03, 9 de junio de 2021 (UTC)
• Oponerse . Los editores de IP y los editores no confirmados automáticamente pueden publicar comentarios en TfD. Es probable que no siempre sean buenos, pero no veo por qué la estructura existente no puede manejar malos votos y ganamos mucho más al hacer que la gente participe en Wikipedia. Sobre la idea de que sería "mejor" para la UX desde la perspectiva del lector, claro. Te estás enfocando más en el contenido al eliminar todas las etiquetas o avisos relacionados con el proyecto del artículo. Pero parte de nuestro objetivo en Wikipedia es difuminar la línea entre un lector y un editor para que las personas se conviertan en editores. Si bien dudo que haya mucha gente entrando en la edición de los avisos de TfD, también dudo que los inconvenientes aún más minúsculos que tienen que soportar los lectores que no se preocupan por TfD superen a los posibles nuevos editores. Ajedrez ( charla ) (utilícelo en la respuesta){{reply to|Chess}} 07:09, 11 de junio de 2021 (UTC)

Edición centrada en el lector

Ya puedo ver cómo va esto y es deprimente. El sesgo sistémico hacia las necesidades de los editores en comparación con los lectores es probablemente la forma más severa de sesgo sistémico en Wikipedia: ha enredado reformas de usabilidad en demasiadas ocasiones pasadas, y está asomando la cabeza una vez más en el principal argumento opuesto aquí. Sí, esta propuesta implica una compensación entre las preferencias de los lectores y las de (unos pocos) editores; es una operación ridículamente fácil de hacer, ya que la participación de IP en TfD es minúscula, mientras que la prevalencia de estos avisos es enorme. Muchos IP son buenos editores, pero un comentario de uno de ellos una vez a la semana no vale la pena interrumpir literalmente a millones de lectores. Por favor, amigos, cuando sopesen su voto, tengan en cuenta para quién estamos escribiendo Wikipedia. {{u | Sdkb }}  ^charla 06:34, 16 de mayo de 2021 (UTC)

• En mi mundo de fantasía personal, "la enciclopedia libre que cualquiera puede editar" significa, entre otras cosas, que consideramos a cada lector como un editor potencial. Los lectores que no estén editando no necesitan el botón "editar" o la caja de herramientas de la izquierda. Si realmente no quieren involucrarse con esto, pueden ir a Wikiwand. - Kusma ( t · c ) 10:04, 16 de mayo de 2021 (UTC)
  • Esto. Y los avisos de TfD recuerdan al lector que Wikipedia es un trabajo en progreso, y siempre lo será. Recuerde, lo perfecto es enemigo de lo bueno.

    Tampoco veo cómo mantener esos avisos hace que Wikipedia sea menos utilizable. Puede ser molesto, seguro, ¿pero inutilizable? Eso es un poco exagerado. pandakekok9 ( charla ) 11:05, 16 de mayo de 2021 (UTC)

Soy un gran fanático de la edición centrada en el lector. No creo que esto sea nada parecido a una edición centrada en el lector, es como una línea. Lo que pienso cuando pienso en "edición centrada en el lector" es en el hecho de que, literalmente, todos los que no son editores con los que he discutido el asunto piensan que soy un rabioso delecionista. Odio pensar lo que piensan del delecionismo real. (Es decir: las prioridades de los lectores no solo no son nuestras prioridades, sino que a menudo son totalmente diferentes a nuestras prioridades en formas que darían apoplejía al editor promedio). Profeta Vaticidal 11:29, 16 de mayo de 2021 (UTC)

Creo que es completamente justo decir que lo malo de tener un aviso innecesario y potencialmente confuso es muchas veces menor que el bien de que un aviso llegue a alguien que esté interesado. La pregunta es si está en algún lugar alrededor de 100,000 más bueno, que es el orden de magnitud de la relación entre las páginas vistas de los avisos y el número de editores no autoconfirmados que participan en TfD de acuerdo con mis cálculos del reverso del sobre. Entiendo que puede haber razones filosóficas para no ocultarlo, pero en términos puramente prácticos, me cuesta creer que sea justificable mostrar este aviso. - Trialpears ( charla ) 10:57, 16 de mayo de 2021 (UTC)

Me parece poco probable que la pequeña barra que aparece en esto sea lo que apaga las direcciones IP cuando, simultáneamente, tenemos grandes cuadrados en la parte superior de las páginas sobre citas y otros temas en un artículo. De hecho, apenas se nota en comparación. Siento que estamos actuando con demasiada certeza, tal vez sea feo y no les gustará que simplemente asumamos que ese es el caso. SpartaN ( charla ) 12:03, 16 de mayo de 2021 (UTC)

Así es como se construye toda esta interfaz, desde las suposiciones y la extensión de los principios generalmente aceptados hasta los aspectos de nuestra interfaz. No podemos encargar un estudio de investigación de WMF para cada propuesta que hacemos. Parece que los wikipedistas se sienten más cómodos confiando en suposiciones cuando significa agregar algo que eliminar algo. ProcrastinationReader ( charla ) 12:46, 16 de mayo de 2021 (UTC)

@ Sdkb : si el apoyo tiene que ver con la preferencia por los lectores, ¿de dónde viene la comprensión de las preferencias de los lectores? Si apoyo o me opongo depende de esto: ¿los lectores realmente se preocupan por estos avisos? No me importa si un millón de páginas están cargadas con un aviso de TfD si solo 1,000 lectores lo notan, 50 de ellos hacen clic y los 49.9 de los que no dejan un comentario dicen "eh, me pregunto cómo Wikipedia en realidad está escrito. Tal vez mire detrás de escena de alguna otra manera "o" Aburrido, esto no me sirve ". Yo hago cuidado si 10.000 lectores encuentran una monstruosidad y ninguno aprender nada de ella. ¿Cómo sé cuál es cuál? Nadie parece tener ninguna evidencia de cualquier manera. Pero si 10,000 lo encuentran una monstruosidad, seguramente algunos harían clic y dejarían comentarios de prueba como "¿por qué pusiste este aviso en la página del Imperio Romano ?" o "¿vas a borrar la página que estaba leyendo? No lo entiendo". - Bilorv ( conversación ) 22:24, 16 de mayo de 2021 (UTC)

Alguna evidencia: cada vez que se envía una plantilla ampliamente utilizada a TFD / TFM, las multitudes aparecen para decir "¡¿POR QUÉ ESTÁ AQUÍ ESTE AVISO?!?!?!?! PLX ELIMINE EL AVISO DE mayúsculas u otro). Izno ( charla ) 01:02, 17 de mayo de 2021 (UTC)

Sin embargo, esas multitudes tienden a ser editores, no lectores. Elli ( charla | contribuciones ) 12:53, 17 de mayo de 2021 (UTC)

¿Por qué este tipo de discusiones siempre se enmarcan en una forma de "pensar en los niños"? ¿Es un fragmento de evidencia empírica de que los lectores dejan de leer artículos debido al aviso TFD? O cualquiera de los otros avisos de discusión para el caso. Hasta que no se realicen estudios bien investigados sobre personas que solo son lectores, el único sesgo sistémico que estoy viendo es hacia las necesidades de los editores a quienes no les gusta el aviso TFD. MarnetteD | Charla 23:25, 18 de mayo de 2021 (UTC)

• No existen los "no editores". Solo hay "editores que aún no han comenzado a editar". No se puede hacer una distinción significativa entre "lectores" y "editores". Invitamos a todas las personas que leen artículos de Wikipedia a unirse para editarlos. No hay necesidad de crear tales clases imaginarias de personas. La idea en sí misma es la antítesis del espíritu mismo de Wikipedia. No es un producto terminado, no tiene un punto final y no pensamos en los usuarios de Wikipedia como lectores o editores. Se invita y se anima a todos los usuarios a que ayuden como mejor les parezca, y creo que la idea de que algunas personas deberían ser clasificadas como "lectores" y desalentarse activamente de ayudar es simplemente incorrecta. - Jayron 32 14:32, 19 de mayo de 2021 (UTC)

  Estoy muy de acuerdo con invitar a los lectores a que se conviertan en editores, pero es mucho más probable que las invitaciones funcionen si están hechas para tareas apropiadas para los recién llegados. Pedir a los lectores que intenten editar encontrando una cita faltante es bueno; pedirles que hagan su primera edición entrando en las guerras de consolidación de infobox (probablemente la forma más frecuente en la que alguien se encontraría con un aviso de TfD) no lo es. {{u | Sdkb }}   ^charla 16:42, 23 de mayo de 2021 (UTC)

• Sdkb da en el clavo como de costumbre. En mi opinión, la oposición a esta propuesta es el ejemplo perfecto del sesgo sistémico de Wikipedia hacia los editores sobre los lectores. - Tera tix ₵ 05:53, 2 de junio de 2021 (UTC)

¿Solución alternativa al problema subyacente?

El problema subyacente aquí es que los avisos de TfD en plantillas populares (por ejemplo, cuadros de información biográficos o geográficos) aparecen en cientos de miles de artículos. Es un poco molesto ver avisos sobre alguna propuesta de fusión oscura que no afecta a la gran mayoría de lectores (ya sea que editen o no) en cada página que miras. ¿Es técnicamente factible tener enlaces "descartar" en los avisos de TfD? Supongo que hay buenas razones para no tenerlos en cada TfD (y en plantillas con solo tres transclusiones, no son tan molestos de todos modos) pero ¿podría hacerse que algo como esto funcione para plantillas con más de 1000 transclusiones? - Kusma ( t · c ) 14:00, 16 de mayo de 2021 (UTC)

Claro, si inserta JavaScript para cargar en cada página para permitir descartar la funcionalidad. Algo parecido a las listas de seguimiento en MediaWiki: Gadget-watchlist-notice-core.js , pero imagino que los intadmins podrían tener problemas de rendimiento con esa propuesta. De todos modos, no creo que ese sea el problema subyacente; su sugerencia es útil para los editores, pero no soluciona el problema para los lectores. Quiero decir, sí, un cambio global en las plantillas puede alterar las páginas de los artículos. Pero también lo hacen las propuestas de CENT RfC y MOS y nosotros (con razón) no las publicitamos a nuestros lectores. Un aviso inútil descartable sigue siendo una molestia. Con todo, la ceguera de las pancartas en todas sus formas es un problema mayoritariamente insoluble, uno de la creación de la propia comunidad y, por lo tanto, ningún proceso de consenso puede solucionarlo. ProcrastinationReader ( charla ) 14:22, 16 de mayo de 2021 (UTC)

¿Por qué permitir que todos descarten los avisos no resuelve el problema de que la gente no quiere ver estos avisos repetidamente? Mi propuesta es tratar a los lectores editores y no editores exactamente igual. - Kusma ( t · c ) 14:43, 16 de mayo de 2021 (UTC)

Creo que la capacidad de descartarlos es una idea asombrosa . Entiendo la aprensión detrás de cargar javascript en cada página, pero esto me parece similar al javascript que usamos para hacer que los navboxes sean plegables: la implementación abre muchas opciones más allá de los avisos de TfD. Personalmente, me gustaría tener la capacidad de ocultar los avisos de TfD porque pueden prolongarse y normalmente no estoy interesado. Pero hay toneladas de avisos que los lectores (y yo) podríamos querer descartar, como los avisos de AfD o CSD. Ni siquiera se limita a los avisos de eliminación, tenemos plantillas como {{ Evento actual }} que son informativas pero rápidamente se vuelven redundantes --- el lector probablemente sepa que es un evento actual (ya que lo está buscando) e incluso si no lo hizo Una vez que ven la pancarta, probablemente no necesiten seguir viéndola si no quieren. También abre la puerta a nuevos casos de uso para plantillas existentes como la plantilla de candado {{ pp }}. He protegido páginas donde hay un alto nivel de interés público; Es posible que los lectores no entiendan por qué una página está protegida y saquen conclusiones equivocadas ("¡Wikipedia se pone del lado de FooBar!"), por lo que en lugar de usar lo que produce un icono de candado en la parte superior derecha, lo uso para mostrar un banner que explica la protección de la página. y la razón detrás de esto. Esto es raro (creo que lo he hecho tal vez dos veces) en parte porque es increíblemente intrusivo, pero si los lectores pueden descartar fácilmente el banner, el costo de colocarlo se reduce y podemos ser más directos con nuestros lectores sobre cuándo y por qué una página está protegida (no siempre, pero es útil para cosas como BLP de personas en las noticias, por ejemplo). Así que sí, creo que esta es una idea asombrosa independientemente de cómo vaya este RfC. - Wug · a · po · des 22:52, 16 de mayo de 2021 (UTC) {{pp|small=yes}}​

Nota del administrador Tener que administrar datos únicos del lado del cliente para cada elemento descartable puede salirse de control rápidamente, ya que cada uno necesitaría un identificador único, volver a listar necesitaría un nuevo identificador único, etc. - xaosflux ^Talk 22:05, 17 de mayo de 2021 (UTC)

Xaosflux , es por eso que me gustaría limitar esto a unas pocas discusiones por mes si se hace manualmente. O espero que algunos de nuestros increíbles codificadores de bots resuelvan algo :) - Kusma ( t · c ) 10:39, 18 de mayo de 2021 (UTC)

¿Tiene una estimación de cuántas plantillas para discusión por mes son para la plantilla con más de 1,000 transclusiones? Si se trata de 1-10, esta alternativa suena bien, pero si son docenas o incluso cientos, la carga para los desarrolladores / intadmins podría ser demasiado grande para que sea factible. Jackattack1597 ( charla ) 00:45, 20 de mayo de 2021 (UTC)

¿Visualización por tiempo limitado?

Otra posible solución, al menos parcial, sería acordar que el aviso de TfD se muestre durante un período determinado, pero luego se elimine. Por ejemplo, 24 o 48 horas de exhibición serían suficientes para alertar a la mayoría de las personas interesadas en tales cosas y eliminar el aviso después de eso eliminaría la mayor parte de la fealdad. Johnuniq ( charla ) 23:11, 16 de mayo de 2021 (UTC)

Esto supone que todos los que estén interesados ​​en una plantilla determinada lean una página en la que se transcluye al menos una vez cada 1-2 días. No creo que podamos hacer esa suposición de manera confiable. Si bien es probable que alguien que lea varios artículos de Wikipedia todos los días vea un aviso relacionado con todos / la mayoría de los cuadros de información dentro de ese período de tiempo, será mucho menos probable que ese mismo lector vea un aviso relacionado con {{ inflación }}, dejemos solo alguien que solo mira Wikipedia una vez a la semana. Como ejemplo del mundo real, miro muchos artículos de Wikipedia (en los últimos ~ 3 meses he visitado más de 7400 páginas en en.wikipedia.org solo en este navegador), {{ Use Commonwealth English }} / {{ Commonwealth English }} ha estado en TfD desde el 14 , sin embargo, he visto una pancarta sobre la discusión exactamente una vez (en Head of the Commonwealth ). En los últimos días, es poco probable que haya visto una plantilla relacionada con artículos sobre lingüística, paleontología o banderas, a pesar de leer a menudo sobre esos temas. Thryduulf ( charla ) 00:55, 17 de mayo de 2021 (UTC)

Mi edición se ejecuta en rachas de acuerdo con mi trabajo. Puedo trabajar 40 horas u 80 y nunca duermo mucho, por lo que mi tiempo de edición está por todas partes. Estaba molesto por haber sido golpeado con una prohibición global de IP (la segunda hasta ahora), así que me tomé un descanso. Cuando finalmente sea tan confiable como un editor de IP, intentaré nuevamente obtener una exención por bloque de IP. El punto es que no puedo seguir el ritmo de todas las cosas que me gustaría hacer, por lo que podría perderme algo en una ventana de 48 horas. Estoy seguro de que esto sería un problema para muchos. Otr500 ( conversación ) 14:27, 18 de mayo de 2021 (UTC)

Ya es una exhibición por tiempo limitado. Desaparece cuando el TFD está cerrado. Los editores llevan vidas en el mundo real que pueden mantenerlos alejados de la 'pedia' durante días. Esta propuesta parece decir que si no ha visto el TFD en las 48 horas posteriores a su inicio, no tiene suerte para conocer la discusión y no se desea su opinión. MarnetteD | Charla 23:13, 18 de mayo de 2021 (UTC)

Factibilidad

¿Existe siquiera una forma técnica de lograr esto? CaptainEek ^{edita Ho Cap'n!} ⚓ 01:06, 18 de mayo de 2021 (UTC)

Esto es técnicamente trivial: agregue la autoconfirmed-showclase a la salida de {{ tfm / fechado }} y {{ plantilla para discusión / fechado }} * Pppery * _{ha comenzado ...} 01:09, 18 de mayo de 2021 (UTC)

Usuarios móviles

• ¿Se muestra este aviso incluso para los usuarios de dispositivos móviles? Si no, entonces la mayor parte de esta conversación es prácticamente discutible. - MJL  - Charla - ^☖ 03:48, 23 de mayo de 2021 (UTC)

Lo hace. Gluons12 ^{t | c} 01:25, 24 de mayo de 2021 (UTC)

Sí, se muestra en el móvil .-- Vulp aquí 08:55, 27 de mayo de 2021 (UTC)

RFC sobre movimientos marcados como menores

Hay muchos editores autoconfirmados que no tienen idea de que su artículo no está listo para el espacio principal. La etiqueta #new user moving page out of userspace es un buen ejemplo de esto. Si navega por la lista de artículos en https://en.wikipedia.org/wiki/Special:RecentChanges?hidebots=1&hidecategorization=1&hideWikibase=1&tagfilter=de-userfying&limit=50&days=7&urlversion=2 , verá muchos artículos que definitivamente podrían ser eliminados rápidamente y otros que solo necesitan ser mejorados más. Y, por supuesto, hay algunos movimientos de página menores legítimos como este movimiento por WP: ENDASH . Así que aquí están las opciones que se me ocurrieron:

1. Status quo. Marca automáticamente los movimientos como menores.
2. Opcional. Deje la opción de marcar movimientos como menores o mayores.
3. Requerido. Todos los movimientos de página están marcados como importantes.

Sí, esto no es un problema importante, pero tenía que tocar el tema de todos modos para los editores que hacen ediciones ocultar menores. Sungodtemple ( charla ) 14:40, 22 de mayo de 2021 (UTC)

• Ningún cambio en el título del artículo nunca es menor. La sugerencia de que los artículos que se mueven al espacio de borrador deben considerarse una edición "menor" es demasiado errónea para siquiera involucrarla. Usuario: 力(power ~ enwiki, π , ν ) 16:20, 22 de mayo de 2021 (UTC)
  • Hmm ... aparentemente se están realizando ediciones menores junto con las entradas del registro. Supuse que esto estaba sugiriendo algo acerca de que las entradas del registro se consideraban ediciones "menores". Esto parece una "rareza del software" que nadie notó. Usuario: 力(power ~ enwiki, π , ν ) 18:24, 22 de mayo de 2021 (UTC)
• Debo estar de acuerdo con el comentario anterior. No puedo entender la razón detrás de marcar cualquier movimiento, especialmente uno entre espacios de nombres, como menor. ¿Alguien puede explicar por qué eso se hace automáticamente? No puedo creer que eso se haga sin una buena razón, pero, por mi vida, no puedo ver qué posible razón podría haber. Phil Bridger ( charla ) 16:48, 22 de mayo de 2021 (UTC)
• @ Sungodtemple : Tenga en cuenta que esto no es realmente algo en lo que tengamos una opción a menos que se convierta en una opción de software, por lo que un RfC local será un consejo en el mejor de los casos. Ver phab: T176053 y tareas vinculadas. - ^Charla xaosflux 19:54, 22 de mayo de 2021 (UTC)
• Un movimiento de página NUNCA debe marcarse como "menor". Sospecho que la intención era indicar que los movimientos son "rutinarios" y probablemente "no controvertidos" ... pero "rutinarios" y "no controvertidos" no son lo mismo que "menores". Blueboar ( charla ) 22:22, 22 de mayo de 2021 (UTC)

  Por WP: menor , una edición menor es uno que el editor cree que no requiere revisión y nunca podría ser objeto de una disputa . Así que "rutinario" y "no controvertido" son en realidad una forma bastante buena de describirlos. {{u | Sdkb }}   ^charla 20:30, 23 de mayo de 2021 (UTC)

  Tenga en cuenta que los movimientos no son "ediciones" en absoluto; que una edición nula se coloque en el historial es puramente por conveniencia - los movimientos se registran en el registro de movimientos que no tiene un indicador "menor". - xaosflux ^Talk 01:28, 24 de mayo de 2021 (UTC)

• No, desafortunadamente o no, los cambios en el título del artículo pueden ser controvertidos o simplemente vandalismo. No son menores, aunque en algunas circunstancias pueden aceptarse fácilmente. Chiswick Chap ( charla ) 10:39, 24 de mayo de 2021 (UTC)
• La función de marcar las ediciones como menores no es particularmente útil en su conjunto, por lo que no importa mucho. Pero dado que un movimiento desde el borrador o el espacio de usuario al espacio principal de repente hace que aparezca una gran cantidad de contenido, no es "menor" incluso desde el punto de vista de que las ediciones que no cambian el contenido son menores: si continuamos haciendo la distinción entre ediciones mayores y menores, los movimientos no deben marcarse como menores. - Kusma ( t · c ) 10:54, 24 de mayo de 2021 (UTC)
• Aquí se combinan dos cuestiones. Sacar nuevos artículos del borrador / sandbox y cambiar el nombre / mover de un artículo existente. Este último casi nunca será una edición menor. El primero casi siempre será menor según la definición que usemos (con la excepción de los artículos que ya se han movido del espacio de artículos). Los artículos completamente nuevos por su naturaleza no * requieren * revisión antes de ser publicados. Nuestras políticas y directrices son claras al respecto. Y hasta que el artículo esté en vivo, de manera realista no habrá mucha disputa a menos que sea un editor con un historial de creaciones de artículos problemáticos. El registro de movimientos ya los registra adecuadamente, entonces, ¿cuál es el propósito de que el historial de artículos no tenga la etiqueta menor adjunta a los movimientos del borrador / caja de arena? El único uso actual real de la bandera menor es dejar de abarrotar las listas de seguimiento. Y si tiene un artículo nuevo que no está en la lista de vigilancia del espacio de artículos, usted es el autor principal o alguien involucrado en su redacción, en cuyo caso lo sabrá de todos modos. Esto parece un proceso complicado por el simple hecho de hacerlo. Para los artículos existentes que se cambian de nombre o se mueven, ¿cuál es el propósito práctico de evitar que la mudanza se incluya como menor? ¿Qué problema resuelve eso? Solo en la muerte termina el deber ( conversación ) 11:56, 24 de mayo de 2021 (UTC)

Categorías de fecha de nacimiento de rango de dos años

Antes de embarcarme en una búsqueda quijotesca para crear un montón de categorías que podrían resultar controvertidas, pensé en tirarlo aquí para la aprobación de la comunidad.

Esta es la situación. Generalmente clasificamos a los sujetos biográficos por año de nacimiento (por ejemplo, Categoría: 1965 nacimientos ). Tenemos miles de sujetos para los que conocemos su edad en una fecha determinada, pero no sabemos cuál de los dos años potenciales fue su año real de nacimiento. Por ejemplo, Sheri Benson (nacida en 1962/1963), Helena Brunner (nacida en 1957/1958), Matt Galloway (nacido en 1970/1971). Actualmente, todos estos temas están categorizados por década de nacimiento (por ejemplo, Categoría: nacimientos de 1960 ), pero creo que podríamos ser más precisos creando categorías como Categoría: Nacimientos de 1962–1963 . Esto también separaría a los sujetos para los que tenemos ese tipo de ventana de dos años de los sujetos de los que tenemos un conocimiento mucho más vago de que nacieron en una determinada década, pero que podrían haber nacido en cualquier momento de esa década. BD2412 T 04:51, 29 de mayo de 2021 (UTC)

Eso me parece innecesario. Simplemente crearía un montón de categorías muy cortas, y las categorías muy cortas (sin mantenimiento) generalmente se desaconsejan. Chicdat ( charla ) 11:11, 29 de mayo de 2021 (UTC)

¿Por qué no categorizarlos en ambos años? No es que no precisa, es simplemente el mejor que podemos hacer sobre la base de la mejor información que tenemos. La categorización por década parece que no cubre a alguien nacido en 1959-60, o 1899-1900, y estoy de acuerdo en que crear una serie de categorías muy cortas para todos estos sucesos inusuales parece una categorización excesiva. Ivanvector ( ^Talk / _ediciones ) 11:31, 29 de Mayo 2021 (UTC)

Ponerlos en ambos también sería mi instinto, y estoy bastante seguro de que lo he visto antes para figuras históricas, aunque no puedo pensar en ejemplos en la parte superior de mi cabeza. - Nizolan ^{( charla · c. )} 22:33, 29 de mayo de 2021 (UTC)

Después de algunas búsquedas, puedo decir que Andrew Marcus es el único artículo sobre una sola persona en dos categorías de nacimiento de la década de 1980, por lo que básicamente no sucede actualmente. - Trialpears ( charla ) 22:37, 29 de mayo de 2021 (UTC)

Bien, por "histórico" me refiero a antes del siglo XX, pero reconozco que tampoco puedo encontrar ejemplos en este momento. - Nizolan ^{( charla · c. )} 22:46, 29 de mayo de 2021 (UTC)

El mismo resultado para la década de 1850, pero aquí Max Hirsch (economista) es el único artículo. - Trialpears ( charla ) 22:49, 29 de mayo de 2021 (UTC)

Realmente no estoy pensando en temas de artículos muy antiguos, ya que creo que la convención de decir 'fulano de tal, edad' es bastante reciente. Sin embargo, consideraría problemático enumerar, por ejemplo, a Sheri Benson anteriormente tanto en los nacimientos de 1962 como en los nacimientos de 1963 porque uno de ellos es fácticamente incorrecto, y lo sabemos. Hasta cierto punto, espero que tener categorías de rango como las propuestas lleve a algunos editores a profundizar y encontrar información más precisa sobre la fecha de nacimiento de los sujetos en esas categorías. BD2412 T 00:34, 30 de mayo de 2021 (UTC)

@ Trialpears : Me acabo de dar cuenta de que estaba recordando Wikisource, donde la categoría doble es la convención (automática), y no Wikipedia, por ejemplo, s: Autor: Thomas à Kempis . Confusión de mi parte, lo siento. - Nizolan ^{( charla · c. )} 14:23, 30 de mayo de 2021 (UTC)

Otra opción sería crear un conjunto de, por ejemplo, Categoría: Nacimientos Circa 1965 , que incluiría personas probablemente nacidas en (o alrededor de) 1965, pero no proyectaría afirmaciones inexactas de que sabemos que la persona nació en ese año específico. . BD2412 T 04:40, 30 de mayo de 2021 (UTC)

• Recuerde que el propósito de la categorización NO ES encasillar el tema ... es ayudar a la navegación entre artículos.

No tengo ningún problema en incluir a alguien en dos categorías de "año de nacimiento" si no estamos seguros de cuál corresponde. A los efectos de la navegación hacia y desde el artículo, es mejor ser demasiado inclusivo. Presumiblemente, el artículo biográfico relevante aclararía la incertidumbre sobre la fecha de nacimiento del sujeto en las primeras oraciones. Blueboar ( charla ) 15:24, 30 de mayo de 2021 (UTC)

He visto tales adiciones de categorías revertidas en el pasado, donde no había una fuente para el año específico. BD2412 T 16:55, 30 de mayo de 2021 (UTC)

• ¿Por qué Categoría: Año de nacimiento incierto es inapropiado en estos casos? - Jayron 32 15:25, 1 de junio de 2021 (UTC)
  • Es una consulta separada. Un año de nacimiento incierto puede ser cualquier año. Supongo que podríamos poner a alguien con, por ejemplo, un posible rango 1964/1965 tanto en Categoría: Nacimientos 1965 como Categoría: Año de nacimiento incierto , y dejar que los investigadores hagan la conexión. BD2412 T 23:26, 2 de junio de 2021 (UTC)
• Oponerse al uso de categorías que se sabe que son incorrectas. Si alguien nació en 1964 o 1965, sabe que una de las categorías no se aplica. - Kusma ( conversación ) 17:55, 3 de junio de 2021 (UTC)
• Si la categorización en ambas categorías está fuera de la mesa (y estoy de acuerdo con el fundamento) entonces probablemente no deberían categorizarse en ninguna. ¿Qué pasa con una categoría de mantenimiento para algo como Categoría: fecha de nacimiento extrapolada de la edad verificada a la fecha , y dejar que los editores la categoricen en una categoría de rango de fechas existente adecuada ? Ivanvector ( ^Talk / _ediciones ) 12:13 6 de junio 2021 (UTC)
• El truco de la categoría: los nacimientos de los sesenta, por supuesto, solo funciona cuando los dos años posibles en cuestión caen en la misma década. Creo que lo mejor sería ponerlos en ambas categorías de año, y también en Categoría: Año de nacimiento incierto . No es una solución perfecta, pero no existe una solución perfecta y esto es lo suficientemente bueno. Estoy viendo esto desde el punto de vista de alguien que quiere escribir código para realizar un procesamiento automatizado. Digamos que quería encontrar a todas las personas nacidas dentro de los 5 años posteriores al nacimiento de la Persona X. Con mi esquema, los encontraríamos y luego podríamos hacer un filtrado adicional si quisiéramos. Si los saca de la categoría de año y los coloca en una categoría de año dual, tendrá que buscar todas las categorías de año dual posibles, la mayoría de las cuales ni siquiera existirían. Lo mismo ocurre con consultas como "¿quién nació exactamente 100 años antes que la Persona X?". Además, el odioso pedante mocoso que hay en mí inmediatamente pensó en el caso de un artículo sobre un par de gemelos, uno de los cuales nació justo antes de la medianoche del 31 de diciembre, y el otro pocos minutos después, el 1 de enero de 2018. el próximo año. ¿Seguramente eso pertenecería a ambas categorías? - RoySmith (charla) 14:43, 6 de junio de 2021 (UTC)
  • Ni siquiera había pensado en personas que, según una edad en una fecha determinada, pudieran nacer en una de dos décadas. BD2412 T 02:31, 9 de junio de 2021 (UTC)

O dos siglos. O milenio. Luego están los problemas de la zona horaria, en relación con el lugar de nacimiento. En mi opinión, esta discusión es un artefacto de la arquitectura de la computadora que quiere 1 o 0, y tiene problemas con los gradientes y los matices. Tal vez elija una (mejor) versión de la verdad para las cosas en blanco y negro, como categorías, y explique los matices en el cuerpo del artículo. Crear duplicación en categorías es una rotura en mi opinión. - Green C 03:20, 9 de junio de 2021 (UTC)

La propuesta original es evitar la duplicación de categorías mediante la creación de un nuevo conjunto de categorías como Categoría: nacimientos 1962–1963 donde se sabe que el sujeto nació en algún momento durante ese período. Funcionaría igual de bien para una Categoría: 1959–1960 nacimientos o una Categoría: 1999–2000 nacimientos . Los artículos de esas categorías no se incluirían en ninguna otra categoría de fecha de nacimiento. Si se determinaba la fecha de nacimiento real del sujeto, se recategorizaría para el año específico. BD2412 T 04:38, 9 de junio de 2021 (UTC)

Cada hermano solo pertenecería en un año. No pude ver por qué tendrías un artículo combinado a menos que estuvieran unidos. Y tener gemelos unidos nacidos en diferentes años sería casi imposible .-- Khajidha ( charla ) 17:11, 7 de junio de 2021 (UTC)

Khajidha , con respecto No pude ver por qué tendría un artículo combinado a menos que estuvieran unidos , vea Quintillizos de Dionne , que está en todas las categorías: muertes de 1954 , categoría: muertes de 1970 , categoría: muertes de 2001 y categoría: personas vivas . - RoySmith (charla) 02:45, 9 de junio de 2021 (UTC)

Creo que lo que se debe hacer en tales casos sería crear redireccionamientos a partir de los nombres individuales y poner las categorías de año de muerte en los redireccionamientos. BD2412 T 03:09, 9 de junio de 2021 (UTC)

Lo sentimos, pero si no sabemos el año exacto de nacimiento, no deberíamos intentar ponerlos en categorías basadas en años exactos. No me importa cuánto "más fácil" haga algunas cosas. Esto me parece una mentira a nuestros lectores. No tiene sentido ser "fácil y equivocado". Si los dos años están en la misma década, podría ver una categoría como Categoría: nacimientos de 1960 con años inciertos . - Khajidha ( conversación ) 14:00, 7 de junio de 2021 (UTC)

Solicitud de proceso: una plantilla de edición solicitada y una cola para editores parcialmente bloqueados

Hoy bloqueé parcialmente a un editor del espacio de artículos por un historial de tres años de cambios sin referencia y categorizaciones inapropiadas de BLP. En mi consejo al usuario, comencé a sugerir que solicitaran ediciones en las páginas de discusión, y luego me di cuenta de que no tenemos un proceso de solicitud de edición específicamente para esto. Tenemos {{ solicitar edición }} para editores COI, y la serie {{ editar protegida }} para páginas que están protegidas, pero ninguna (que yo sepa) para editores bloqueados. Terminé sugiriendo que usaran {{ edit totalmente protegido }}, pero esa es una solución a medias, y las solicitudes con esas plantillas en artículos que no están protegidos se rechazan rutinariamente solo por esa razón.

Propongo crear una plantilla de solicitud de {{ editar parcialmente bloqueado }} (con instrucciones para que los revisores verifiquen el registro de bloqueo del solicitante, similar a cómo aconsejamos a los revisores que verifiquen el registro de protección para ver si hay cambios pendientes) que llenaría Categoría: Wikipedia solicitudes de edición parcialmente bloqueadas y agregar una sublista de páginas en esa categoría a Wikipedia: Tablero en la sección de ediciones solicitadas. Yo mismo podría hacer esto con valentía , pero la creación de una nueva cola podría tener implicaciones de gran alcance, por lo que primero me gustaría medir el consenso. Ivanvector ( ^Talk / _ediciones ) 11:27, 29 de Mayo 2021 (UTC)

@ Ivanvector : Me sorprende que no conozcas Plantilla: Editar parcialmente bloqueado . 🐔 ¡   Chicdat    ^{Bawk para mí!} 12:34, 29 de mayo de 2021 (UTC)

Dejando a un lado el tono algo innecesario de Chicdat, esa plantilla parece ser una buena solución. No se clasifica en una categoría específica, y estoy de acuerdo con Ivanvector en que debería permitir una revisión fácil. También he creado {{ editar parcialmente bloqueado }} como redireccionamiento para que coincida con las otras plantillas de solicitud de edición. luciérnaga ( t · c ) 14:28, 29 de mayo de 2021 (UTC)

No tengo claro que las solicitudes de edición de editores bloqueados para editar una página determinada deban tener una cola separada de todas las solicitudes de edición (y, por lo tanto, una priorización potencialmente mayor), dado que sus contribuciones se han considerado perjudiciales para esa página. isaacl ( charla ) 15:06, 29 de mayo de 2021 (UTC)

Personalmente, creo que se trata menos de darles una mayor prioridad y más de garantizar que obtengan el mayor escrutinio que sin duda requieren; con una cola separada, son fácilmente identificables como solicitudes que requieren un manejo más cuidadoso. luciérnaga ( t · c ) 15:15, 29 de mayo de 2021 (UTC)

También puede haber editores que estén dispuestos a manejar solicitudes de edición de COI pero no solicitudes de edición parcialmente bloqueadas o viceversa, lo que les facilita encontrar las que desean procesar. - Trialpears ( charla ) 15:21, 29 de mayo de 2021 (UTC)

Es bastante cierto que es probable que las solicitudes de edición de editores bloqueados en una página sean más polémicas, y sería bueno marcar esto sin poner la solicitud en una secuencia separada donde puede adelantarse a otras solicitudes. Sin embargo, no me queda claro si hay muchos administradores que no están dispuestos a lidiar con la cola habitual de solicitudes (generalmente situaciones de conflicto de intereses) que solo buscan solicitudes contenciosas para procesar. isaacl ( charla ) 15:44, 29 de mayo de 2021 (UTC)

Poner estas solicitudes en una secuencia separada también podría resultar en que salten detrás de otras solicitudes. Es solo un reconocimiento de que son diferentes a otros tipos de solicitud. Phil Bridger ( charla ) 17:45, 29 de mayo de 2021 (UTC)

Tengo dudas sobre cuán diferentes son realmente en esencia. Las solicitudes de edición que utilizan la plantilla son de editores cuyas ediciones requieren una revisión adicional para la página en cuestión. Ya sea que se deba a un conflicto de intereses o una disputa anterior, el editor que responde tendrá que examinar el historial pasado del solicitante y la página para establecer el contexto y los mejores pasos a seguir. isaacl ( charla ) 23:28, 29 de mayo de 2021 (UTC)

En cuanto a insinuar a nivel de escrutinio, creo que una vez que se lea la solicitud, incluso ignorando la plantilla diferente que se supone que se usa correctamente, el texto de la solicitud lo hará evidente. isaacl ( charla ) 15:44, 29 de mayo de 2021 (UTC)

¿Quién se ofrecerá como voluntario para cumplir con las solicitudes de edición de los editores parcialmente bloqueados? No puedo comprender la noción de que hay una persona que es lo suficientemente disruptiva como para que deba ser bloqueada del espacio principal, pero aún queremos que haga solicitudes de edición. Quiero decir, solo defínalos. Esta no es una guardería, ¿verdad? Levivich 17:00, 29 de mayo de 2021 (UTC)

Si solo están parcialmente bloqueados, entonces el administrador que bloquea parcialmente ha visto una chispa de posible redención. ¿Seguramente hacer solicitudes de edición es una forma de lograrlo? Phil Bridger ( charla ) 17:45, 29 de mayo de 2021 (UTC)

He usado p-blocks de esta manera y he respondido a las solicitudes de edición de ellos en mi charla de usuario. Algunas personas hacen un trabajo útil, parecido a un gnomo, pero por alguna razón no seguirán políticas particulares como WP: NOTBROKEN . Exigir la revisión de sus ediciones antes de publicarlas es un buen compromiso entre perder a un voluntario útil y dejar que los informes sobre ellos obstruyan el ANI. Las restricciones técnicas como los bloqueos y la protección deben ser moderadas y solo en la medida necesaria para evitar la interrupción (es decir, crear un resultado neto positivo). Los bloques son una forma de manejar los problemas de WP: CIR , pero la competencia es un espectro y prohibir completamente la edición no siempre es la mejor solución al problema. Creo que agregar una (sub) categoría para este tipo de solicitudes sería útil para clasificarlas por Trialpears. - Wug · a · po · des​ 23:04, 29 de mayo de 2021 (UTC)

De hecho, no sabía acerca de {{ editar parcialmente bloqueado }} (o no habría publicado esto en primer lugar, por supuesto) y agradezco que Chicdat lo haya señalado. Aún así, creo que este tipo de solicitud de edición debe clasificarse por separado de las solicitudes de COI y protegidas, ya que requieren un tipo diferente de escrutinio. No necesariamente más , solo diferente . Y si no están categorizados en absoluto, ¿quién les responde? Ivanvector ( ^Talk / _ediciones ) 23:27, 29 de Mayo 2021 (UTC)

La plantilla es un contenedor para la plantilla {{ Solicitar edición }} y, por lo tanto, se clasifica como una solicitud de edición. No me queda claro que el escrutinio sea sustancialmente diferente: el editor que responde debe familiarizarse con el contexto de fondo y determinar los mejores pasos siguientes para determinar si la edición puede obtener apoyo de consenso, o actuar como punto de partida para una edición que el las partes interesadas pueden ponerse de acuerdo. isaacl ( charla ) 23:36, 29 de mayo de 2021 (UTC)

Estoy de acuerdo, no creo que sea un escrutinio diferente sino tan solo el interés del editor. Lidiar con las ediciones de COI no me interesa (en parte porque no conozco esa área de la política lo suficientemente bien como para manejar las solicitudes), y creo que los observadores de la página de discusión responden mejor a las solicitudes de edición protegidas cuando es posible, ya que pueden revisar mejor el contenido. de lo que probablemente lo haría. Así que no respondo mucho a las solicitudes de edición, pero estaría interesado en responder solicitudes de p-block si hubiera una categoría. Si eso es útil para el proyecto en su conjunto, tal vez, pero me gusta . - Wug · a · po · des​ 00:06, 30 de mayo de 2021 (UTC)

No sé si estoy completamente de acuerdo con la categorización o si requiero el mismo escrutinio, pero en la medida en que la solicitud para crear una plantilla para que los editores bloqueados soliciten ediciones, esto se puede considerar resuelto. Gracias a todos. Ivanvector ( ^Talk / _ediciones ) 18:19, 2 de Junio 2021 (UTC)

Cambie el mensaje de bloqueo parcial para que sea naranja o amarillo en lugar de rojo

Esta propuesta es claramente un éxito y, en este momento, creo que deberíamos pasar a hablar sobre cómo vamos a implementar la propuesta. Mz7 ( conversación ) 19:12, 11 de junio de 2021 (UTC)

La siguiente discusión está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

---

Nota técnica: se trata de aplicar estilo al cuadro div secundario .mw-contributions-blocked-notice-partial .mw-warning-with-logexcerpten Especial: Contribuciones que muestra este texto cuando un usuario está parcialmente bloqueado.

Si es posible, creo que deberíamos cambiar el cuadro de notificación de bloqueo parcial de rojo a naranja o amarillo para diferenciar los bloques parciales de los completos. Esto sería útil para reducir la confusión, más obviamente para los administradores de sistemas que podrían no notar que el mensaje dice "parcialmente bloqueado" en lugar de "bloqueado" y no tomar medidas sobre los editores disruptivos, pero también para otros patrulleros que podrían abstenerse de informar sobre un editor problemático si parece a primera vista que ya han sido bloqueados. Esto se mencionó hace un par de meses , pero no hubo una gran cantidad de discusión más allá de determinar que puede ser técnicamente posible hacer algo como esto. Aspening ( charla ) 03:02, 1 de junio de 2021 (UTC)

Estoy de acuerdo, el presente aviso se parece demasiado a un bloqueo de sitio. Esto es particularmente confuso cuando se encuentra un bloqueo parcial en los rangos. Acroterion (charla) 03:10, 1 de junio de 2021 (UTC)

• También estoy de acuerdo, los bloques completos y los bloques parciales deberían poder distinguirse más rápida y fácilmente. - El Millo ( charla ) 03:39, 1 de junio de 2021 (UTC)
• Apoye esto también. - Ched ( charla ) 09:18, 1 de junio de 2021 (UTC)
• Seguro. ProcrastinationReader ( charla ) 09:25, 1 de junio de 2021 (UTC)
• Gran idea. ¡Un poco vergonzoso que nos haya tomado tanto tiempo darnos cuenta! —— S erial 09:44, 1 de junio de 2021 (UTC)

• Parece completamente razonable, no hay una razón real para no hacerlo y hay muchas buenas razones para hacerlo. firefly ( t · c ) 10:13, 1 de junio de 2021 (UTC)
• Yo apoyaría el naranja; El amarillo generalmente se considera más cauteloso. 331dot ( charla ) 10:15, 1 de junio de 2021 (UTC)
• ¿Estamos hablando de {{ uw-pblock }} o de algo más / más? - Trialpears ( charla ) 10:18, 1 de junio de 2021 (UTC)

  Eso no es muy rojo. ¿Asumí el aviso de registro cuando abres la página de un usuario para editar? ( [20] ) —— S erial 10:37, 1 de junio de 2021 (UTC)

• Parece completamente razonable. Apoyo. EpicPupper ( charla ) 18:06, 1 de junio de 2021 (UTC)

Algunas notas para nerds están aquí. Vea la mini-nota anterior para saber qué se discute el cuadro específico

@ Aspening : ¿ puede ser más específico, exactamente qué plantillas / mensajes / etc desea cambiar? (No tengo idea de que al que se refiere el cuadro de notificación de bloqueo parcial ). Por ejemplo, aquí hay un usuario recientemente bloqueado parcialmente: ¿qué desea cambiar específicamente? Es muy posible que esto no requiera una discusión completa de VPPR para hacer un ajuste de color. - Charla xaosflux 14:51, 1 de junio de 2021 (UTC) Xaosflux : Aspening probablemente se esté refiriendo al cuadro rojo en la parte superior de esta página: Especial: Contribuciones / Ioannesko Sungodtemple ( charla ) 14:53, 1 de junio de 2021 (UTC) @ Xaosflux : Me refiero al cuadro que aparece en la página de contribuciones especiales del usuario que dice "Este usuario está actualmente parcialmente bloqueado". Estoy sugiriendo que ese cuadro debe ser naranja o amarillo para bloques parciales para reducir la confusión por las razones enumeradas anteriormente por mí y otros usuarios. 331dot también trae a colación un buen punto de que el amarillo es más cauteloso, por lo que ahora me estoy inclinando más hacia que esta casilla sea naranja. Aspening ( charla ) 14:57, 1 de junio de 2021 (UTC) @ Aspening : OK, entonces ese cuadro está empaquetado en una clase, "mw-contribuciones-bloqueado-aviso-parcial", pero él mismo está en un div con clases "warningbox mw-warning-with-logexcerpt mw-content-ltr". La segunda de esas clases se usa para el estilo de common.css. El mensaje en sí es de MediaWiki: sp-contribuciones-bloqueadas-aviso-parcial . Por lo tanto, ajustar el estilo de color no es muy fácil, pero el marcado se puede agregar al mensaje muy fácilmente (vea el ejemplo en testwiki: Special: Contributions / Example ~ testwiki ). ¿Sería suficiente marcar algo así para abordar su inquietud? - Charla xaosflux 15:11, 1 de junio de 2021 (UTC) @ Xaosflux : Posiblemente, creo que sería preferible un cambio de color, pero si eso es difícil o imposible, creo que enfatizar el bloqueo parcial de esa manera podría ser satisfactorio. Aspening ( charla ) 15:17, 1 de junio de 2021 (UTC) @ Aspening : agregué el énfasis al texto al menos por ahora. La coloración puede bloquearse en un desafío técnico, ya que hay una colisión de clases mw-warning-with-logexcerptallí. Quizás alguien más tenga una idea técnica que no sea un truco feo. - Charla xaosflux 15:29, 1 de junio de 2021 (UTC) ¿Es un truco feo simplemente sobrescribirlo .mw-contributions-blocked-notice-partial .mw-warning-with-logexcerpt {border-color:#fc3;background-color:#fef6e7;}? No pensé que eso estuviera prohibido en la práctica de CSS, pero no soy un experto ... Writ Keeper   ⚇ ♔ 15:36, 1 de junio de 2021 (UTC) @ Writ Keeper : Solo dije "puede" :) Algo así podría funcionar, poner estilos hiperespecíficos en common.css no es ideal, pero no tenemos mucho más con lo que trabajar en este mensaje, por lo que puede ser el camino. - Charla xaosflux 15:47, 1 de junio de 2021 (UTC) El cuadro es amarillo según los valores predeterminados de MediaWiki. Nuestro código common.css lo hace rojo. Por lo tanto, tener otra regla para volver a ponerlo en amarillo puede que no sea irrazonable. - SD0001 ( conversación ) 15:52, 1 de junio de 2021 (UTC) @ SD0001 : No estoy en desacuerdo con las opciones de color, solo que aplicar capa tras capa de CSS superpuesto a través de common.css no es ideal (incluso cuando es la única opción tecnológica), esa implementación específica no es un bloqueador duro . Que actualmente estamos diseñando "warning-with-logexcerpt" tampoco es ideal, pero es lo que es. Si esta propuesta sigue tendiendo hacia el soporte, podemos simular algunas soluciones técnicas. - Charla xaosflux 16:04, 1 de junio de 2021 (UTC)

• Apoyo Parece razonable. - Jayron 32 15:22, 1 de junio de 2021 (UTC)
• Nota del administrador He agregado algo de énfasis a MediaWiki: Sp-contribuciones-bloqueado-aviso-parcial mientras se habla de esto. Si esta propuesta se implementa de manera ideal, ese mensaje se puede eliminar por defecto. - ^Charla xaosflux 18:12, 1 de junio de 2021 (UTC)
• Tiene sentido para mi. ~ HAL 333 01:04, 2 de junio de 2021 (UTC)
• Me apoyo de naranja porque generalmente es más fácil de leer que el amarillo. - codificador de Python  ( charla  |  contribuciones ) 20:16, 2 de junio de 2021 (UTC)
• Soporte Para reducir la confusión entre bloques parciales y completos. - Comentario anterior sin firmar agregado por Jackattack1597 ( charla • contribuciones ) 01:26, 4 de junio de 2021 (UTC)
• Admite cualquier color. Distinguir bloques completos y parciales reducirá la confusión y reducirá la probabilidad de malos entendidos desafortunados. Thryduulf ( conversación ) 20:34, 4 de junio de 2021 (UTC)
• Apoyo. La visualización actual es confusa. - SD0001 ( conversación ) 07:01, 6 de junio de 2021 (UTC)
• Soporte para todos. Distinguir los bloques parciales de los bloques del sitio es una mejora. Sin preferencia de color. Ivanvector ( ^Talk / _ediciones ) 12:08 6 de junio 2021 (UTC)
• Soporte por WP: SNOWPRO con preferencia por naranja. Huggums537 ( charla ) 17:46, 6 de junio de 2021 (UTC)
• Soporte Es más intuitivo, lo que ayuda a la 'pedia. Tyrone Madera ( charla ) 19:22, 7 de junio de 2021 (UTC)

Implementación técnica

@ Xaosflux , Aspening , Writ Keeper y SD0001 : Puedo ver en su conversación colapsada que existe un potencial hack de MediaWiki: Common.css que podría hacer esto (por ejemplo, para cambiar el rojo de nuevo al amarillo predeterminado), pero parece más Se necesita un debate sobre la implementación técnica. ¿Qué sería necesario para implementar esta propuesta? Mz7 ( conversación ) 19:12, 11 de junio de 2021 (UTC)

Probando en testwiki ( testwiki: MediaWiki: Common.css ) - esperando la actualización para completarlo. - ^Charla xaosflux 21:07, 11 de junio de 2021 (UTC)

Casos de prueba:

1. Bloque normal: testwiki: Especial: Contribuciones / Xaosflux2
2. Bloque parcial: testwiki: Especial: Contribuciones / Xaosflux2a

@ Mz7 : eso es lo que buscas? - ^Charla xaosflux 21:12, 11 de junio de 2021 (UTC)

@ Xaosflux : Oh , sí. Eso se ve muy bien. Mz7 ( conversación ) 21:27, 11 de junio de 2021 (UTC)

Haciendo ... - ^Charla xaosflux 21:49, 11 de junio de 2021 (UTC)

 Done @ Mz7 : vea el ejemplo en vivo en Special: Contributions / Example . Si hay algún problema, publique en MediaWiki_talk: Common.css # pblock-style . - ^Charla xaosflux 21:58, 11 de junio de 2021 (UTC)

La discusión anterior está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

Mostrar UTC con la hora UTC actual

Propongo que en lugar de mostrar la zona horaria como "UTC" más un desplazamiento, debería mostrarse como la UTC actual (en el momento de la carga de la página) además de un enlace de actualización.

- Actual: UTC + 05: 00- Propuesto: 04:33, 5 de junio de 2021 (UTC) + 05:00 [actualización]

Este formato permitirá al espectador calcular fácilmente la hora actual local evitando las complejidades de intentar mostrar dinámicamente la hora actual correcta en ese lugar. Nbardach ( conversación ) 04:44, 5 de junio de 2021 (UTC)

Por favor, capte la indirecta: no va a suceder. Alguien que mire la página el 1 de julio de 2021 estará totalmente confundido al ver una hora en caché como 04:33, 5 de junio de 2021. Wikipedia no admite pantallas dinámicas y mostrar texto confuso no es un buen reemplazo. Johnuniq ( charla ) 04:54, 5 de junio de 2021 (UTC)

@Johnuniq: Ya ocurre en todas las páginas de la zona horaria (por ejemplo: UTC-08: 00 ), cada una de las cuales muestra la hora actual en esa zona horaria más el enlace [actualizar]. ¿Por qué debería ser esto diferente? - Comentario anterior sin firmar agregado por Nbardach ( charla • contribuciones ) 06:08, 5 de junio de 2021 (UTC)

Hola, desarrollador de MediaWiki aquí. Creo que mostrar la hora actual es una propuesta (técnicamente) perfectamente razonable y trivialmente alcanzable para implementar en Wikipedia.
Estoy totalmente de acuerdo con las preocupaciones expuestas anteriormente en esta sección y en la anterior, en la medida en que sería absurdo implementar esto con wikitext en el lado del servidor. Sin embargo, tal pensamiento es exactamente la razón por la que las ideas y la implementación técnica deben estar más separadas entre sí. Hacer esto en el lado del servidor requeriría cambios de software para permitir el vencimiento de la caché del analizador de nivel de minuto (que no aprobaría), o un frágil bot de purga administrado por la comunidad (que probablemente bloquearía). Aparte de eso, todavía existiría el problema de castigar al menos a un visitante, cada minuto, con una carga de página inusualmente lenta debido a que el servidor tiene que analizar la página en su totalidad. (Digo al menos uno, ya que los visitantes se pondrán en cola uno detrás del otro; con una longitud de cola máxima después de la cual la copia anterior a la depuración se revivirá y servirá en su lugar). Y después de eso, es muy probable que el resultado siga siendo apagado por unos minutos debido a las diferencias de reloj entre el servidor y el cliente, y el tiempo que se tarda en transferir los datos a través de Internet. Después de eso, el texto permanecería estático mientras estaba en el navegador del lector y no se actualizaría. Por lo tanto, para cuando alguien realmente lo mire, le daría un 50% de probabilidad de estar apagado al menos dos minutos en comparación con su propio reloj, volviéndose más obsoleto con cada segundo / minuto que pasa mientras se desplazan hacia arriba y hacia abajo en la página. . Así que, aparte de cualquier problema de infraestructura, creo que esto ofrecería una experiencia lenta, confusa y poco profesional a los lectores; incluso si los servidores lo actualizan instantáneamente cada minuto (lo cual no harán).
La forma adecuada de implementar algo como esto sería con unas pocas líneas de JavaScript del lado del cliente (a través de MediaWiki: Common.js , o un gadget habilitado de forma predeterminada). Dicha secuencia de comandos sería muy trivial de escribir y no requeriría ninguna API moderna o compleja (veo que Intl.DateTimeFormatse mencionó anteriormente, pero esto no es necesario). Suponiendo que nuestro objetivo sea mostrar horas y minutos (no segundos), esto no incurriría en ningún costo de rendimiento notable en el navegador.
La forma en que me acercaría a esto:

• La caja de información reserva un lugar para el reloj. Si su estilo preferido da como resultado que el lugar sea notable si está vacío, entonces uno podría ocultar este lugar reservado en CSS a través de .client-nojs. Por lo tanto, lo oculta en contextos donde no se proporciona / habilita / admite JavaScript.
• El cuadro de información anota el lugar con un atributo de datos HTML, lo que indica el desplazamiento de una manera que es más fácil de captar para JavaScript. Ej

  Offset: -01:30

  .
• El JavaScript sería un pequeño puñado de declaraciones para encontrar este elemento, encontrar el desplazamiento, restarlo de los minutos actuales y luego simplemente representar la hora y los minutos. La antigua y ampliamente admitida función del navegador Date # setMinutes incluso se encarga automáticamente de pasar las horas y demás .

- Krinkle ( charla ) 23:48, 5 de junio de 2021 (UTC)

• Si alguien quiere un reloj UTC en su pantalla, ya puede habilitarlo a través de dispositivos , estará disponible en todas las pantallas en todo momento y también puede ser útil para cosas como ver las marcas de tiempo de las discusiones. - ^Charla xaosflux 03:19, 6 de junio de 2021 (UTC)
• Esto tampoco soluciona el problema del verano discutido anteriormente, ya que el objetivo de esto es calcular la hora local actual y el estado local de verano y también se necesitaría compensación para lograr eso. - ^Charla xaosflux 03:21, 6 de junio de 2021 (UTC)
• Agradecido a todos, especialmente al desarrollador Krinkle, por sumergirse más profundamente en la pantalla de la hora actual. No estoy seguro de cómo abordar las preocupaciones de Xaosflux sobre los estados locales de verano y las implementaciones de zonas horarias irregulares de la localidad, pero espero que Krinkle y otros tengan algunas buenas ideas. Nbardach ( conversación ) 06:15, 6 de junio de 2021 (UTC)
• @ Krinkle : Su sugerencia funcionaría para las compensaciones UTC estáticas, pero la discusión original fue sobre los tiempos en las ubicaciones. Muchas ubicaciones necesitan que se tenga en cuenta el horario de verano para mostrar la hora correcta. Anomie ⚔ 11:55, 6 de junio de 2021 (UTC)
  • @ Anomie : Lo entiendo, pero cosas como esa también afectan el desplazamiento que el cuadro de información mostraría hoy sin un tiempo en vivo. Supuse que esto ya se maneja de alguna manera. Esa información, esperaría, es preprocesada por la salida de la plantilla para informar el código JS de la misma manera que informaría a un humano hoy. No sé cuál es la forma preferida de codificar esta información hoy en día, pero donde sea / como sea que lo hagamos en otro lugar, supongo que podríamos hacer lo mismo aquí. Por ejemplo, agregue la marca de tiempo UTC del siguiente conmutador y codifíquela en otro atributo. Nuevamente, esto está motivado por querer mejorar la forma en que se presenta la información incluso sin un reloj en vivo. Creo que ahora entiendo mejor por qué optó por Intl.DateTimeFormathacerlo, y tal vez eso aún podría funcionar si la alternativa es ocultar el cuadro de destino. Sin embargo, la desventaja de ese enfoque es que me sugiere que en realidad no hemos descubierto una manera de explicar / presentar esta información a los lectores en general, que para mí es el problema más impactante a resolver, si no lo hemos hecho. t ya. - Krinkle ( charla ) 15:53, 6 de junio de 2021 (UTC)
    • Asumes incorrectamente. No hay ningún intento en los artículos de decir cuál es la compensación de zona horaria actual , los cuadros de información solo indican cuáles son las compensaciones normales y de verano. Lo cual está bien, las personas que aún no saben cómo funciona el DST pueden seguir los wikilinks incluidos para obtener más información. Pero decir "La hora actual es 13:20 o 14:20 dependiendo de si es horario de verano o no" no funcionaría muy bien. Codificar un cambio en wikitexto de alguna manera (probablemente a través de una plantilla o módulo, como lo hacemos con Plantilla: fecha de calendario para algunos días festivos) podría funcionar, pero aún necesitaría una purga masiva semestral. Anomie ⚔ 17:25, 6 de junio de 2021 (UTC)
  • ¿Podría un desarrollador explicar por qué JS del lado del cliente como este no funcionaría?

     function  calcTime ( ciudad ,  desplazamiento )  {  // crea el objeto Date para la ubicación actual  var  d  =  new  Date ();  // convertir a mseg  // restar el desplazamiento de la zona horaria local  // obtener la hora UTC en mseg  var  utc  =  d . getTime ()  +  ( d . getTimezoneOffset ()  *  60000 );  // crea un nuevo objeto de fecha para una ciudad diferente  // usando el offset  var  nd  =  new  Date ( utc  +  ( 3600000 * offset ));  // devuelve la hora como una cadena  return  "La hora local de la ciudad" +  ciudad  + "es" +  nd . toLocaleString ();  }  alerta ( calcTime ( 'Mumbai' ,  '+5.5' ));  }

    Nbardach ( charla ) 18:02, 6 de junio de 2021 (UTC)
    • @ Nbardach : Esa es la idea general de la sugerencia de Krinkle. Pero averiguar qué pasar offsetpor un lugar como Nueva York es problemático. Allí estaría -4desde mediados de marzo hasta principios de noviembre y -5durante el resto del año. Anomie ⚔ 00:22, 7 de junio de 2021 (UTC)

      Como ha indicado anteriormente, new Intl.DateTimeFormat('en', { timeZone: 'America/New_York', hour: 'numeric', minute: 'numeric' }).format(new Date())da la hora actual en Nueva York, teniendo en cuenta el horario de verano. No funciona en navegadores más antiguos, podrían recurrir a comportamientos que no sean JS. - SD0001 ( conversación ) 04:23, 7 de junio de 2021 (UTC)

    • Quizás pueda discutir sus ideas en mw: MediaWiki_talk: Gadget-UTCLiveClock.js , ya que podría ser un buen lugar para implementarlo. isaacl ( charla ) 04:49, 7 de junio de 2021 (UTC)

Wikipedia debería celebrar el Día del Orgullo Autista

Existe consenso en contra de esta propuesta. Cierre por WP: Cláusula de bola de nieve . - codificador de Python  ( charla  |  contribuciones ) 13:44, 9 de junio de 2021 (UTC)

La siguiente discusión está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

---

El próximo 18 de junio es el Día del Orgullo Autista . ¿Puede Wikipedia celebrar ese día, por ejemplo, mostrando una insignia de infinito en la portada? ¿Dónde está el foro adecuado para discutir esta propuesta? Saludos. RIT RAJARSHI ( charla ) 03:59, 7 de junio de 2021 (UTC)

@ RIT RAJARSHI : Generalmente no ha habido mucho apoyo para celebrar eventos individuales, y no creo que la comunidad apoye agregar una insignia infinita a la página principal. Creo que lo mejor que podría hacer sería leer las pautas para los aniversarios seleccionados y, si el evento / artículo cumple con los criterios, agregarlo a la página del 18 de junio . 192.76.8.73 ( conversación ) 11:25, 7 de junio de 2021 (UTC)

Este es un tema muy querido para mi corazón, ya que soy administrador de una pequeña organización benéfica cuya misión es representar obras de teatro que crean conciencia sobre el autismo (y me siento profundamente honrado de haber sido invitado a convertirme en el único administrador sin autismo), pero se opondría a esto. Creo que aquí es válido un argumento de pendiente resbaladiza. ¿Por qué no deberíamos hacer algo para el Mes de Concientización sobre la Salud Mental , la Semana de Concientización sobre el SIDA o el Día Internacional del Té , que estoy seguro de que son muy queridos por los corazones de algunos editores? El único día que deberíamos tomar nota, si es que existe, es uno para dar a conocer las enciclopedias abiertas que cualquiera puede editar. Phil Bridger ( charla ) 12:50, 7 de junio de 2021 (UTC)

No celebramos días individuales de manera formal, pero las presentaciones relevantes de artículos que siguen nuestras miles de millones de reglas se pueden destacar en la página principal en un día determinado. ¿Sabía que permite solicitudes de fechas especiales para un artículo nuevo determinado, y también lo hace el artículo destacado de hoy ? Si tiene un artículo que cumple con las reglas y es apropiado para el Día del Orgullo Autista, será recibido con los brazos (bastante) abiertos. (Sin embargo, el 18 de junio de este año podría estar demasiado cerca). - Kusma ( charla ) 13:09, 7 de junio de 2021 (UTC)

@ Phil Bridger : Una cosa debe quedar clara; La conciencia del autismo y el orgullo por el autismo no son lo mismo. El orgullo del autismo hace hincapié en que los individuos autistas tienen derecho a ser nosotros mismos y no tenemos que forzarnos a enmascararnos en una versión rota de los neurotípicos. Tenemos el potencial infinito pero para eso necesitamos el nicho que es accesible para nosotros. También decimos que el mundo necesita más de nosotros. Hablamos en contra de la eliminación eugenésica de la diversidad genética. Fomentamos la diversidad cognitiva . Creemos que la fuerza radica en la diversidad y no en la igualdad. Decimos " Nada sobre nosotros sin nosotros . Compartimos día a día nuestra experiencia sobre la discapacidad oculta y cómo la discapacidad no pertenece a la persona afectada, sino a un mundo inaccesible . Como persona en el espectro, siento estos mensajes se pierden u omiten en los programas de concienciación sobre el autismo y ambos son muy diferentes.

Ahora bien, ¿por qué difundir el orgullo por el autismo? Porque la conciencia es engañosa. La conciencia a menudo conduce al miedo al autismo. Lo que nos ayuda es la comprensión, la aceptación y la confianza. Sin embargo, la conciencia es una visión mayoritaria (neurotípica), financiada por agencias neurotípicas, gobernadas por organizaciones benéficas dirigidas principalmente por neurotípicos. Los programas de concienciación son algo sobre nosotros sin nosotros. En contraste, lo que realmente nos ayuda a florecer y expandir nuestro potencial, no es promovido por la autoridad neurotípica. Es promovido por nuestros pequeños esfuerzos.

Ahora estoy de acuerdo en que es principalmente una enciclopedia, pero dado que realiza varios aniversarios, un aniversario de 1 día no sería un gran problema. Saludos. RIT RAJARSHI ( charla ) 13:22, 7 de junio de 2021 (UTC)

Este artículo fue presentado varias veces en esta serie de días.

Por lo tanto, debería ser un aniversario regular. RIT RAJARSHI ( charla ) 13:30, 7 de junio de 2021 (UTC)

Estoy de acuerdo en que la conciencia y el orgullo son cosas diferentes, pero no estoy de acuerdo en que haya algo malo en la conciencia o que excluya de alguna manera el orgullo. Todo lo contrario. Mucho miedo proviene de la falta de conciencia y, como dije, soy el único administrador de la organización benéfica en la que estoy involucrado que no tiene autismo, por lo que no se le puede acusar de estar dirigida por neurotípicos o ser un organización "sin nosotros". De hecho, esa es una crítica que estaría mejor dirigida a Wikipedia si se aceptara esta propuesta. Pensemos en lo que es mejor en lugar de permitirnos peleas internas acerca de las palabras, sobre las cuales nos resultaría tan difícil llegar a un acuerdo entre diversas personas con autismo como entre diversos neurotípicos. Phil Bridger ( charla ) 16:26, 7 de junio de 2021 (UTC).

@ Phil Bridger : Gracias por todas sus aportaciones. "Pensemos qué es lo mejor" ... sí, definitivamente, todos merecen el nicho donde pueden funcionar de la mejor manera. En lugar de moldearse a uno mismo. Apreciamos toda la diversidad (no solo el autismo y el TEA), que incluye a los neurotípicos, y agradecemos al pequeño número de neurotípicos que intenta comprender en lugar de moldearnos. RIT RAJARSHI ( charla ) 02:06, 8 de junio de 2021 (UTC)

• OPUESTOS - No es nuestro trabajo promover los días del orgullo… no importa cuán digna sea la causa. Publicar un DYK o presentar un artículo relacionado está bien, pero colocar pancartas y emblemas en nuestra página principal no lo está. Blueboar ( charla ) 14:13, 7 de junio de 2021 (UTC)
• Oponerse a agregar cualquier tipo de logotipos especiales al MP para cualquiera de estos días de reconocimiento de condición; sin embargo, asumiendo que el artículo está en buena forma, siéntase libre de enviar una solicitud de edición en la charla de Wikipedia: Aniversarios seleccionados / 18 de junio para que aparezca nuevamente en OTD. - ^Charla xaosflux 14:36, 7 de junio de 2021 (UTC)
• Opónganse por los demás arriba. Me alegra que exista el Día del Orgullo Autista, y es una excelente manera de ayudar a combatir el estigma / discriminación, pero ese simplemente no es nuestro papel y esto abriría una lata de gusanos. {{u | Sdkb }}  ^charla 14:54, 7 de junio de 2021 (UTC)
• Oponerse . Problema importante de NPOV, junto con otras preocupaciones mencionadas anteriormente. Sungodtemple ( charla ) 15:27, 7 de junio de 2021 (UTC)
• Oponerse . Ya tenemos un proceso y un conjunto de pautas para determinar qué se incluye en la página principal; no deberíamos anular ese proceso para agregar eventos con artículos deficientes simplemente porque son para una causa digna, eso abrirá una enorme lata de gusanos. Si desea ver el evento en la página principal, debe pasar por el mismo proceso que todos los demás, lo que en este caso implicará arreglar la limpieza etiquetada en la sección de referencia que causó su eliminación en primer lugar. 192.76.8.73 ( conversación ) 16:01, 7 de junio de 2021 (UTC)
• Oponerse por todos los oponentes anteriores. Tyrone Madera ( charla ) 19:23, 7 de junio de 2021 (UTC)

La discusión anterior está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

Archivar informes RfPP (nuevamente)

En abril, propuse que se archivaran los informes de RfPP . Sin embargo, no se tomó ninguna medida al respecto y se archivó la discusión en sí. Me preguntaba si esto sucederá y, de ser así, cuándo. 🏳️‍🌈 ¡  Chicdat   ^{Bawk para mí!} 11:41, 7 de junio de 2021 (UTC)

Chicdat todavía no tengo claro por qué se necesita. Con frecuencia reviso RFPP y nunca sentí la necesidad de buscar en un archivo. También utilizo WP: Twinkle, que me dice si la página ha sido protegida antes y tiene enlaces a la página de protecciones. El bot etiquetará algunas solicitudes con "Comentario automatizado: se realizó recientemente una solicitud de protección / desprotección para una o más páginas de esta solicitud, y fue denegada en algún momento durante los últimos 8 días". Incluso entonces no vuelvo al archivo para ver. Voy a la página y veo si es necesario ahora. CambridgeBayWeather , Uqaqtuq (charla) , Huliva 00:51, 11 de junio de 2021 (UTC)

CambridgeBayWeather El hecho de que no le resulte útil no significa que otros no lo hagan. 🏳️‍🌈 ¡   Chicdat    ^{Bawk para mí!} 10:11, 11 de junio de 2021 (UTC)

Estoy haciendo ping a los editores involucrados en la última discusión. @ ProcrastinatingReader , PEIsquirrel , Jayron32 , Pppery , Xaosflux , Cyberpower678 , GenQuest , Malcolmxl5 , CaptainEek , Beeblebrox , Nosebagbear , Fastily y ToBeFree : 🏳️🌈  Chicdat   ^{Bawk a mí!} 10:11, 11 de junio de 2021 (UTC)

• El hecho de que una propuesta se archive sin ninguna acción suele ser un buen indicador de que hay poco interés en ella. No me entusiasma. No tengo claro cómo se usaría o cuáles serían los beneficios. - Malcolmxl5 ( charla ) 10:28, 11 de junio de 2021 (UTC)
• Explique claramente por qué debería hacerse esto. y, ¿cuáles son los beneficios de esta acción? Pensé que esto estaba hecho y acostado. En este momento, esto suena como si quisieras quitar el desorden de una pila de "allí" y comenzar una nueva pila de "aquí". Pero, ¿cuál es su razonamiento y cómo es eso un beneficio de alguna manera para WP? G en Q uest ^"scribble" 12:31, 11 de junio de 2021 (UTC)
• También estoy luchando por ver por qué deberíamos molestarnos con esto. parece un cambio que simplemente creará cientos de páginas de archivo inútiles que nadie va a mirar nunca. Estos no son como discusiones de eliminación o informes de ejecución de arbitraje en los que alguien podría necesitar volver a abrirlos en 10 años para una discusión de eliminación relacionada / caso de arbitraje / RFC, básicamente cada uno de estos informes es una plantilla estándar y una oración de una línea, con una plantilla de respuesta de un administrador. Si se responde a una solicitud en RFPP, habrá una entrada en el registro de protección para la página que ya sirve como un registro razonable de qué tipo de interrupción ha ocurrido históricamente, y si se rechaza una solicitud de protección de página, entonces no vea alguna razón por la que necesitaríamos acceder de nuevo. El hecho de que una página no estuviera protegida hace 6 meses no debería tener ninguna relevancia en un nuevo informe; una decisión sobre si una página debería protegerse o no debería basarse en la interrupción que se esté produciendo ahora. 192.76.8.73 ( conversación ) 13:30, 11 de junio de 2021 (UTC)
• Mi opinión no ha cambiado; Este proceso me parecería completamente inútil, pero no se interpondrá en el camino de nadie que haga el trabajo necesario para que esto suceda. No tiene ningún propósito para mí, como administrador, al hacer mi trabajo en RFPP, y no proporciona ningún beneficio en esa área. Tampoco soy lo suficientemente inteligente ni lo suficientemente imaginativo para ver cómo un administrador podría encontrar algún uso en un sistema de este tipo, pero soy un listón bastante bajo en ese sentido, por lo que no detendré a nadie ... - Jayron 32 13:42, 11 de junio de 2021 (UTC)
• De hecho, hubo consenso en la sección anterior ; 7 apoyado oponerse / no útil, 2 apoyo y 1 indiferente. Combinado con las respuestas únicas anteriores, eso es 9 en contra, 2 de apoyo, 1 neutral. ProcrastinationReader ( charla ) 13:45, 11 de junio de 2021 (UTC)
• Archivar las páginas las pone a disposición de Search y Whatlinkshere. Esto tiene ventajas y desventajas: a veces es mejor olvidar las cosas. Todavía no he visto un caso de uso convincente. - Kusma ( conversación ) 13:47, 11 de junio de 2021 (UTC)
• Meh, pero no creo que estos sean realmente necesarios. Realmente no sientan precedentes como lo hace un xFD. Si se concede, el registro de protección puede vincularse a lo que quiera vincular el administrador de protección; si se rechaza, eso no impedirá que una solicitud que no sea extremadamente breve en el futuro pueda ser revisada por sus propios méritos. - ^Charla xaosflux 15:22, 11 de junio de 2021 (UTC)
• ¿Por qué no automatizar la adición de un resumen que incluya el enlace permanente al ID de revisión de RfPP si el administrador que lo cumple está tomando medidas a partir de ahí? Así es como las solicitudes WP: RM / TR cumplidas ahora se rastrean sin crear un exceso de archivos. - 2pou ( conversación ) 15:49, 11 de junio de 2021 (UTC)
• Nuevamente, no estoy seguro de qué problema resolvería esto. Ya existe un registro de protección bastante útil para las páginas. CaptainEek ^{edita Ho Cap'n!} ⚓ 18:58, 11 de junio de 2021 (UTC)
• Estoy de acuerdo con todos los de arriba. No se ha articulado ninguna razón convincente (o, francamente, ninguna) de por qué esto es necesario. Mz7 ( conversación ) 19:03, 11 de junio de 2021 (UTC)

La prueba de funciones del equipo de crecimiento comienza mañana (8 de junio)

Hola a todos, soy Marshall Miller; Soy el gerente de producto del equipo de crecimiento de WMF . Estoy seguimiento de @ Nosebagbear 's después del 23 de abril sobre la prueba de características del equipo Crecimiento aquí en Inglés Wikipedia. En resumen, las características del equipo de crecimiento brindan a los nuevos titulares de cuentas herramientas importantes para comenzar: son artículos sugeridos que necesitan ediciones simples (basadas en plantillas de mantenimiento) y se les asigna un mentor a quien pueden hacer preguntas.

En las últimas semanas, muchos miembros de la comunidad inglesa han probado las funciones y hemos escuchado reacciones e ideas en gran medida positivas. También tenemos 16 mentores inscritos (no necesitamos más para esta prueba, ¡pero necesitaremos más en el futuro!) Después de discutirlo con los miembros de la comunidad más involucrados , fijamos una fecha para comenzar a probar las funciones en este wiki. . Nuestro plan es comenzar a otorgar las funciones de crecimiento al 2% de los recién llegados a partir de mañana, 8 de junio. Esto significa que para todas las cuentas nuevas creadas a partir de mañana, el 2% de ellas tendrá las funciones de crecimiento y el resto no. Debido a que Wikipedia en inglés obtiene alrededor de 130,000 cuentas nuevas por mes, esperamos que esto ascienda a 2,600 recién llegados con las funciones en el transcurso del mes. En su mayoría, serán visibles en los cambios recientes y en las listas de seguimiento al completar las ediciones sugeridas y hacer preguntas a sus mentores. Estas ediciones se pueden encontrar con las etiquetas # Tarea para recién llegados , # Pregunta del módulo de tutoría y # Pregunta del panel de tutoría .

Mientras se ejecuta la prueba, el equipo de Crecimiento monitoreará la actividad de los recién llegados para identificar si está ocurriendo algo negativo (como un aumento en el vandalismo); si algo sale mal, podremos hacer cambios rápidamente. Al final de unas cuatro semanas, reflexionaremos sobre los datos y preguntaremos a los mentores sobre sus experiencias para decidir cómo proceder, en términos de si aumentar el número de recién llegados que reciben las funciones.

Espero que esto les suene bien a todos aquí; creemos que lo hemos planeado cuidadosamente con la opinión de la comunidad, pero definitivamente quiero escuchar si alguien tiene preguntas o inquietudes. Planearé publicar de nuevo mañana para confirmar que la prueba ha comenzado. MMiller (WMF) ( charla ) 18:42, 7 de junio de 2021 (UTC)

También me gustaría mencionar, por favor, no sea un mentor, ya hay más de 15 de ellos. Oh, dispara, efecto Streisand . Sungodtemple ( charla ) 22:10, 8 de junio de 2021 (UTC)

Hola a todos: hoy comenzamos la prueba, otorgando las funciones de crecimiento al 2% de las cuentas nuevas que se están creando. ¡Siga el progreso en la página de discusión del proyecto ! MMiller (WMF) ( conversación ) 04:51, 9 de junio de 2021 (UTC)

Permitir enlaces a varios artículos en otros idiomas / a secciones de artículos

El método actual de permitir un solo enlace entre artículos de diferentes idiomas asume que un concepto que es suficiente para hacer un artículo en un idioma siempre será un artículo en otro idioma y nunca varios artículos. Sin embargo, hay muchos casos en los que este no es el caso. Por ejemplo, está el Changchun inglés que analiza su historia como Hsingking en el mismo artículo. Sin embargo, en la Wikipedia japonesa, Hsingking tiene un artículo, mientras que Changchun también tiene un artículo. Ambos artículos japoneses son lo suficientemente largos como para que parezca impracticable fusionarlos, y no parece correcto hacer que la Wikipedia japonesa cambie sus artículos basándose en la Wikipedia en inglés.

Mi solución sugerida sería permitir que artículos como el artículo japonés de Hsingking se vinculen a la sección del artículo en inglés de Changchun que trata sobre Hsingking. El artículo en inglés aún podría vincularse al artículo japonés de Changchun, ya que hay una desambiguación en la parte superior del artículo japonés de Changchun que permitiría a las personas dirigirse al artículo japonés de Hsingking. Erynamrod ( charla ) 16:16, 10 de junio de 2021 (UTC)

@ Erynamrod : Estás hablando de los enlaces entre idiomas que aparecen en la barra lateral, ¿no es así (solo para estar seguro de que estoy escribiendo sobre lo mismo)? Estos se completan actualmente con wikidata, que solo admite enlaces 1: 1 de artículos y no admite enlaces a secciones, pero hay una solución: aún puede usar los enlaces ingresados ​​manualmente al estilo antiguo. Solo puede tener un enlace para cada idioma en la barra lateral de cada artículo, pero puede tener varias páginas en otros wikis que enlacen al mismo artículo, por ejemplo, para agregar un enlace al artículo de Hsingking sobre el artículo japonés, simplemente agregue algo como [[ en: Changchun # Manchukuo y la Segunda Guerra Mundial]] en cualquier parte de la página. El artículo en inglés solo puede tener un enlace, por lo que, como puede notar, la única forma de tratarlo es tener desambiguación en el lado japonés. 192.76.8.73 ( conversación ) 18:03, 10 de junio de 2021 (UTC)

Hsinking es una redirección a Changchun . Si lo desea, puede vincular la página de redireccionamiento al japonés Hsingking en Wikidata y agregar un {{ Wikidata redirect }}. -  Finnusertop ( charla ⋅ contribuciones ) 18:44, 10 de junio de 2021 (UTC)

NOWIKI

Como autor de bot, protector de link-rot, texto sin formato -> convertidor CS1, etc. A menudo me horrorizan las formas creativas en que los editores implementan nowiki y en el proceso crean link rot, citas mal formadas y cables de conexión para bots y guiones para enganchar. Tal vez sea solo yo, pero rara vez veo razones legítimas para nowiki frente a las herramientas y plantillas de citas estándar. Sugiera que podríamos beneficiarnos del seguimiento de categorías y equipos de limpieza o herramientas para migrarlos cuando tenga sentido, lo que probablemente sea al menos el 80% del tiempo. - Green C 18:29, 29 de abril de 2021 (UTC)

De hecho, uso mucho nowiki cuando se combina con (también lo usé aquí) para que no se convierta en formato Wikitext. Blaze The Wolf | Proud Furry y editor de Wikipedia ( charla ) 20:12, 29 de abril de 2021 (UTC)

La plantilla {{ code }} también funciona, se escribe menos y es en sí misma un wikitexto puro - . El texto sin formato sin el fondo también es posible usando la plantilla {{ codett }} - - GhostInTheMachine habla conmigo 21:09, 29 de abril de 2021 (UTC)

Ejemplo de mal uso:

Último primero. Título. Editor.

(Tenga en cuenta el <> circundante que muchas herramientas recogen como parte de la URL, es decir http://example/com>). No quieren que la URL esté vinculada, pero que permanezca visible en su totalidad, una especie de papel. No es un estilo exactamente, que normalmente se encuentra en páginas mezcladas con otros estilos. Tal vez sea un dominio usurpado (la mayoría de los casos no); también existen mejores sistemas para eso |url-status=usurped. Rara vez es una buena idea hacer nowiki en las citas del espacio principal, hay mejores opciones. - Green C 21:21, 29 de abril de 2021 (UTC)

¿Por qué ... por qué la gente hace eso? Sí, por supuesto que no deberíamos. Elli ( charla | contribuciones ) 23:37, 29 de abril de 2021 (UTC)

Usuario: GreenC , algunas diferencias reales de esto serían útiles, para que podamos ver qué está pasando. Estoy familiarizado con las etiquetas nowiki, pero nunca las he visto relacionadas con las citas. ¿Es esto posiblemente algo hecho por el editor visual, que a menudo he visto introduciendo etiquetas innecesarias? Phil Bridger ( charla ) 21:47, 29 de abril de 2021 (UTC)

Tengo la impresión de que nowiki debería evitarse en los artículos de la misma manera que se debe invocar directamente a los módulos. ¿Es eso incorrecto? Creo que sería razonable rastrear eso, si no lo hacemos. Elli ( charla | contribuciones ) 23:37, 29 de abril de 2021 (UTC)

GreenC , como de costumbre, WP: Visual Editor tiene la culpa. [21] [22] [23] [24] - Alexis Jazz ( charla o de ping mí) 02:45, 30 de Abril 2021 (UTC)

Usuario: Alexis Jazz , Ack para el tipo 1. Esto parece un error activo ya que hay algunos tickets Phab cerrados antiguos de 2015 que abordan un problema similar. La solución puede ser convertir a " enlace " o simplemente a una URL de texto sin formato. Sería una búsqueda-reemplazo bastante fácil, podría ser AWB. Supongo que el primer paso es abrir un Phab y verificar que sea un error (conocido o no). ¿Conoces más información? - Green C 03:38, 30 de abril de 2021 (UTC)

GreenC , aquí está el tipo 2: [25] [26] [27] . Como de costumbre, VE tiene la culpa. Yo uso Wikiblame . Para el tipo 3, algunos usos son válidos (como ejemplos en páginas sobre HTML) y aproximadamente 290 tenían etiquetas nowiki vacías. (nowikitag se abrió y se cerró inmediatamente de nuevo) El único uso semi-válido de eso fue en McCune-Reischauer y una página relacionada donde t ' estaba escrito como ''t'''. - Alexis Jazz ( charla o de ping mí) 18:49, 30 de Abril 2021 (UTC)

Alexis Jazz . Esto fue interrumpido, acaba de abrir un Phab con sus diferencias: T282322 - Green C 19:40, 8 de mayo de 2021 (UTC)

4 tipos:

1. http = 6,432
2. ' = 8.715
3. < = 705
4. = 5,165

Más por descubrir. - Green C 00:56, 30 de abril de 2021 (UTC)

• Los registros de Filter 550 se pueden usar para ver todos los nowiki que se colocan constantemente en los artículos si alguien quiere ver qué es lo actual. - xaosflux ^Talk 01:00, 30 de abril de 2021 (UTC)
• Incluiré que {{ ' }}, {{ ' s }} y plantillas similares probablemente se puedan usar para resolver la mayoría de las instancias de Tipo 2, aunque creo que parte del problema puede ser simplemente que estas plantillas no son muy conocido (o al menos, no tenía ni idea de la existencia de las plantillas cuando cometí el mismo error hace un año y medio). -  TheHardestAspect - OfCreatingAnAccount - IsAlwaysTheUsername : publicado a las 17:19, 17 de Mayo 2021 (UTC)

GreenC , Alexis Jazz : Puedo replicar el tipo 1 en VE ingresando una URL y luego tocando el botón "eliminar enlace". Por lo tanto, http://example.com/ ... Cuando pego , inmediatamente ahora se encuentra dentro de <>, que es diferente del tipo 3. Si el tipo 1 se debe a que los usuarios desvinculan las URL en propósito , entonces ¿por qué están haciendo eso? ⁓ Pelágico (  mensajes  ) - (13:33 dom 30, AEST) 03:33, 30 de mayo de 2021 (UTC)

Haciendo que Wikipedia sea más acogedora para el usuario moderno

Puede que me equivoque, pero en 20 años, el diseño de Wikipedia no ha cambiado mucho. El diseño fue excelente para las innovaciones en línea de 2001, pero ... no tanto ahora. Hoy en día, los sitios web tienen botones simples y fáciles de usar, sistemas de cuentas que tienen listas de "leer más tarde" multiplataforma (o mejor aún, carpetas también), feeds personalizados, etc. Wikipedia todavía tiene una interfaz de usuario bastante limitada, mientras que el resto de Internet ha seguido adelante. La aplicación tiene algunas integraciones modernas, pero estas no se sincronizan con el sitio web, por lo que aún tiene un alcance limitado.

Ahora, obviamente, un feed "Para usted" incluiría innumerables preocupaciones sobre la privacidad y los datos, pero seguramente podría haber algún tipo de sistema opcional para una interfaz de usuario moderna basada en los datos del usuario. Como un feed personalizado que simplemente recomienda nuevos artículos basados ​​en los que ha leído, haría maravillas con esto. ¿Hay alguna razón por la que esto no pueda suceder? Squid45 ( charla ) 17:38, 17 de mayo de 2021 (UTC)

En sus preferencias de usuario, puede cambiar su máscara e incluso crear la suya propia. Incluso hay una lista de máscaras geniales . Las listas "Leer más tarde" se pueden marcar en el navegador. Y tenga en cuenta que Wikipedia es una enciclopedia, no un sitio web o diccionario de redes sociales. Un feed personalizado frustraría el propósito de Wikipedia. Sungodtemple ( charla ) 17:53, 17 de mayo de 2021 (UTC)

Uno de los atractivos de Wikipedia es que no hace sugerencias tontas de lo que nos podría gustar de la forma en que lo hacen muchos otros sitios web. Es una forma de venderte más o decirte lo que debes pensar en lugar de cualquier cosa que beneficie al lector. Si eso es moderno, entonces estoy orgulloso de ser anticuado. Phil Bridger ( charla ) 18:10, 17 de mayo de 2021 (UTC)

¿Puedo decir también que uno de los atributos positivos de Wikipedia es que, a diferencia de muchos otros sitios web, no nos pregunta si queremos aceptar cookies? Rollo August ( charla ) 20:12, 17 de mayo de 2021 (UTC)

Realmente no estoy muy entusiasmado con la idea de un feed "Para ti" o una navegación basada en datos del usuario. Para empezar, están los problemas de privacidad a los que se alude en la operación. El seguimiento y el almacenamiento del movimiento de los usuarios en el sitio para que un algoritmo pueda adivinar en qué podrían estar interesados ​​los lectores sería una divergencia masiva de la política actual en la que incluso cosas como verificar los datos del usuario solo se guardan durante 60 días para la privacidad del usuario, y si es una opción en el sistema, nunca obtendrá suficientes datos para producir resultados significativos (la mayoría de nuestros lectores no tienen cuentas, e imagino que solo una fracción de los usuarios registrados estaría contenta con el seguimiento de la lectura de WMF). ¿Cómo propone separar los datos de usuario de la lectura de los datos de usuario de la edición? Cualquier seguimiento de dónde van nuestros usuarios registrados se contaminará enormemente con saltos de página sin sentido de cosas como el navegador wiki automático, la nueva patrulla de páginas, el trabajo antivandálico, la clasificación por categorías de limpieza, etc.

Básicamente, aunque la idea de impulsar la navegación del usuario por visitas a la página debería ser innecesaria, la navegación debería estar integrada en los artículos. Si un párrafo menciona algo en lo que un lector podría estar interesado, debería ser un enlace wik, si hay una serie de artículos sobre un tema que tienen sentido para leer juntos, deberían presentarse juntos en un cuadro de navegación, si hay artículos que son un tema natural. a continuación del artículo que un lector acaba de leer, deben aparecer en la sección "ver también", y todos los artículos deben clasificarse en las categorías adecuadas para que los editores puedan encontrar fácilmente el contenido relacionado. También tenemos una gran cantidad de voluntarios trabajando para mantener la página principal como un escaparate de contenido de alta calidad de todo el sitio, que tiene suficiente variedad para servir \ así como una lista de recomendaciones sobre cosas que los lectores podrían estar interesados ​​en leer. 192.76.8.91 ( conversación ) 22:41, 17 de mayo de 2021 (UTC)

---

"	El término "moderno" tiene sentido desde una perspectiva descriptiva, por ejemplo, únicamente para distinguir los períodos y formas más nuevos de los más antiguos. Se convierte en un problema cuando se presupone que las formas antiguas son "anticuadas"; es decir, se presume que es peor. En los campos tecnológicos donde las empresas toman las decisiones y las imponen a los usuarios, a menudo ocurre lo contrario.	"
- Richard Stallman

Cuando el "usuario moderno" se acostumbra a algo que es "conveniente" pero que en realidad no le conviene y nos pide que lo implementemos también, nuestra mejor opción es decirle cortésmente "No te lo daremos, pero no negarse por malicia; aquí están las razones por las que este cambio en realidad no es de su interés ". Es una buena oportunidad para intentar enseñar a las personas a respetarse a sí mismas, de hecho. DesertPipeline ( charla ) 05:53, 18 de mayo de 2021 (UTC)

Me gusta la función de listas de lectura en la aplicación de iOS y desearía que estuviera disponible en la versión del navegador. ⁓ Pelágico (  mensajes  ) - (14:07 dom 30, AEST) 04:07, 30 de mayo de 2021 (UTC)

Las máscaras de Minerva y Timeless tienen un widget de "artículos relacionados" que funciona de manera misteriosa, pero no veo que "impulse la participación del usuario" como lo hacen las sugerencias de YouTube. Cuando leo artículos, tiendo a usar navboxes y la sección Ver también , aunque a veces Artículos relacionados muestra algo pertinente. ⁓ Pelágico (  mensajes  ) - (14:07 dom 30, AEST) 04:07, 30 de mayo de 2021 (UTC)

@ Pelagic , la función "Artículos relacionados" está disponible en el sitio de escritorio (pero no aquí, porque los editores no la querían). Son solo los tres primeros resultados de búsqueda, precargados para mayor comodidad. Ponlo morelike:Article_titleen el cuadro de búsqueda normal y obtendrás el mismo efecto. Haga clic aquí para ver los resultados de morelike:fish.

(Puede controlar manualmente los resultados de la búsqueda si los resultados son deficientes. Esto a veces sucede con artículos muy breves (p. Ej., "Joe Film es un actor conocido por interpretar una vez a un personaje de My Little Pony ", que puede tener una puntuación bastante alta en las búsquedas relacionadas con lo único vinculado en ese substub). Whatamidoing (WMF) ( charla ) 02:55, 3 de junio de 2021 (UTC)

Lista de observación de las contribuciones de un usuario específico

Seguimiento en Phabricator
Task T2470

Tengo una idea que me gustaría sugerir. Recientemente, InedibleHulk comentó en mi página de discusión. Me ENCANTA absolutamente el sentido del humor que usa con frecuencia durante las discusiones y en el resumen de la edición, sean cuales sean las circunstancias, de alguna manera me hace reírme todo el tiempo cada vez que lo encuentro. Me di cuenta de que si tengo un mal día, puedo ir a su anfitrión de contribuciones y ver sus publicaciones que están garantizadas para hacerme reír. Esto me hizo pensar, ¿por qué no hacer posible la lista de contribuciones? Principalmente, se puede usar para fines legítimos (como monitorear las contribuciones de un nuevo usuario con fines de tutoría o un usuario recientemente desbloqueado o examinado de otra manera para monitorear sus ediciones y comportamiento, o para realizar un seguimiento de las ediciones y mejoras de un tema en particular si el usuario se especializa en ese tema), pero también tiene el potencial de ser utilizado para el placer personal, como en el caso que proporcioné. ¿Sería una buena idea extender las aboliciones de la lista de vigilancia a las contribuciones de un usuario específico? DrewieStewie ( charla ) 03:17, 18 de mayo de 2021 (UTC)

DrewieStewie , m: Lista Encuesta sobre la Comunidad 2021 / Administradores y patrulleros / lista de usuarios - Alexis Jazz ( charla o de ping mí) 03:29, 18 de Mayo 2021 (UTC)

phab: ¡T2470 se ha abierto para esto desde 2004! - ^Charla xaosflux 15:36, 18 de mayo de 2021 (UTC)

Ver también phab: T33105 . - ^Charla xaosflux 15:37, 18 de mayo de 2021 (UTC)

No es exactamente lo que desea en esta situación particular , pero puede configurar fuentes RSS para contribuciones de usuarios individuales, así como para historiales de páginas. Ya no hay mucha gente que utilice lectores RSS con regularidad, pero creo que ya tenía un par de estos instalados cuando lo hice. Andrew Gray ( charla ) 16:47, 18 de mayo de 2021 (UTC)

Cualquiera que realmente haya escrito un script para esto tendría una probabilidad muy alta de ser SanFranBanned y tener el código fuente ignorado, a menos que la persona a la que quieras seguir tenga que aprobar que ejecutes un script de este tipo en ellos (y no puedo imaginar a muchas personas dando tal aprobación, excepto en unas pocas situaciones de capacitación / tutoría muy limitadas). Para citar a la WMF exactamente sobre esta propuesta:

Seguir y ser seguido debe ser de mutuo acuerdo. La idea sería tener una forma de llegar a un acuerdo sobre el hecho de que te pueden seguir. En la lista de seguimiento, cuando agrega un usuario, ese usuario recibirá una notificación para aceptar (o no). Esa notificación recopilaría un mensaje del seguidor y un enlace a la página de discusión del seguidor. Reanude que los siguientes pueden ser posibles en la lista de seguimiento o en la página de preferencias.

 -  Iridiscente 19:04, 18 de mayo de 2021 (UTC)

Esta declaración de WMF suena incompatible con la licencia CC-BY-SA que los escritores acuerdan aquí. El derecho a copiar el trabajo de alguien, seguramente también debe incluir el derecho a la conciencia de que el trabajo existe. Y el conocimiento de cada obra individual implica poder conocer todo lo que hace un usuario bajo esa licencia, desde el momento en que libera los derechos de autor, es decir, cuando lo guarda. Graeme Bartlett ( charla ) 23:12, 18 de mayo de 2021 (UTC)

La licencia no incluye el requisito de notificar a los autores de todas las copias o versiones derivadas, tener un registro central de todas las copias o versiones derivadas, u otros mecanismos integrales de conocimiento. Sería una carga significativa y una posible preocupación por la privacidad distribuir o modificar obras de manera gratuita. Dicho esto, el feed de cambios recientes y la lista de vigilancia son mecanismos de conocimiento de los cambios realizados en Wikipedia. Las contribuciones de los usuarios ya son completamente visibles, ya sea a través de la página de contribuciones especiales o mediante el feed de cambios recientes. Cualquiera puede crear una interfaz para mostrarlos como desee (puede crear un cliente que rastree las contribuciones en las que ya ha hecho clic para ver, por ejemplo) y utilizarlo en su propia computadora. isaacl ( charla ) 02:25, 19 de mayo de 2021 (UTC)

¿Mmm no? Pensé que desalentamos el acoso . Parece que esto solo proporcionaría una herramienta fácil para empeorar las cosas. 🐔 ¡   Chicdat    ^{Bawk para mí!} 10:41, 19 de mayo de 2021 (UTC)

• Es como fue el resultado de la lista de deseos de la comunidad: nadie pensó que se había solicitado de mala fe, o que los supuestos positivos no eran, de hecho, completamente posibles. Era solo que la facilidad de los negativos que pueden surgir de esto también es obvia y no lo suficientemente viable como para evitar que valga la pena hacerlo, o incluso habilitarlo. Sería un poco impropio para un SFB si alguien hiciera esto, a menos que haya evidencia de un mal uso grave o que hayan duplicado el trabajo después de haberlo eliminado una vez, pero ciertamente no sería deseable. No recomendaría crear un método para hacerlo. Nosebagbear ( charla ) 22:22, 30 de mayo de 2021 (UTC)

Sincronización de la lista de lectura en la aplicación y el sitio web

En las aplicaciones de Wikipedia para iOS y Android, hay una función de "Lista de lectura". ¿Sería posible que esto se sincronizara también con el sitio web y no solo con otras aplicaciones? ¡Un nuevo botón de "lista de lectura" en el sitio web sería muy útil! Squid45 ( charla ) 14:44, 22 de mayo de 2021 (UTC)

Hay algunas extensiones de navegador que le permiten guardar artículos en la lista de lectura de las aplicaciones. No sé qué tan bien funcionan, o si funcionan al revés (es decir, ver artículos en la lista de lectura de aplicaciones desde su navegador de escritorio). el wub "?!" 14:29, 23 de mayo de 2021 (UTC)

Jejeje, cuando dije lo mismo arriba , ¡no estaba al tanto de esta sección! Si ha iniciado sesión en la aplicación de iOS parece sincronizar la lista de lectura con su cuenta de Wikipedia, ¿debe estar en alguna parte de la base de datos de MediaWiki? ⁓  Pelágico (  mensajes  ) - (15:15 dom 30, AEST) 05:15, 30 de mayo de 2021 (UTC)

Cita necesaria etiquetado en VisualEditor

Trasladado de bomba Village (propuestas)  - Tol | Charla | Contribuciones 05:10, 25 de mayo de 2021 (UTC)

Creo que la capacidad de poder seleccionar y colocar la "cita necesaria" a través de la función de citar en el editor visual con un solo clic sería útil. No es necesario, pero ahorraría tiempo. TigerScientist Chat > contribuciones 21:05, 18 de mayo de 2021 (UTC)

Copie el siguiente texto y péguelo en cualquier artículo: {{cn}}esto simplemente funcionará con el editor visual de la manera que lo solicite. ~ ToBeFree ( hablar ) 21:09, 18 de mayo de 2021 (UTC)

ehh supongo que tal vez. TigerScientist Chat > contribuciones 15:10, 19 de mayo de 2021 (UTC)

Es posible que desee publicar esto en Phabricator si realmente lo desea, sin embargo, creo que usar la plantilla es bastante fácil personalmente. EpicPupper ( charla ) 19:00, 19 de mayo de 2021 (UTC)

@ TigerScientist : Si lo desea, puedo ver si puedo armar un script de usuario que podría agregar otro botón a esto. Tol | Charla | Contribuciones 05:28, 25 de mayo de 2021 (UTC)

Tol no es necesario, pero si no requiere mucho tiempo o esfuerzo, continúe. Gracias incluso por sugerir esto. TigerScientist Chat > contribuciones 05:30, 25 de mayo de 2021 (UTC)

@ TigerScientist : No hay problema. No he trabajado con VE antes, así que no sé cuánto tiempo me llevará, pero intentaré conseguirle algo en unas dos semanas. Tol | Charla | Contribuciones 18:24, 26 de mayo de 2021 (UTC)

Listo : la documentación del script se encuentra en Usuario: Tol / VECN , incluidas las instrucciones de instalación. ¡Hazme saber si tienes alguna pregunta! Agregar cosas a VE es muy simple. Tol | Charla | Contribuciones 20:36, 26 de mayo de 2021 (UTC)

WOAH gracias Tol ! TigerScientist Chat > contribuciones 16:01, 27 de mayo de 2021 (UTC)

@ TigerScientist : ¡De nada ! Tol | Charla | Contribuciones 20:19, 27 de mayo de 2021 (UTC)

@ Tol , eres la única persona a la que he oído decir que agregar un script a VisualEditor es fácil. ¿Podría poner mw: VisualEditor / Gadgets , mw: VisualEditor / Gadgets / Create a custom command , y mw: VisualEditor / Gadgets / Add a tool en su lista de seguimiento? Son páginas de muy poco tráfico, y Flow / Structured Discussions le enviará un ping en Echo / Notifications si alguien alguna vez publica algo en sus páginas de discusión. Además, podría estar interesado en mw: New Developers . Whatamidoing (WMF) ( charla ) 03:07, 3 de junio de 2021 (UTC)

@ Whatamidoing (WMF) : Guau; ¡bien! Todavía no entiendo completamente VisualEditor, pero estoy más que feliz de ver esas páginas en la lista. ¡Gracias por el recurso! Tol | hablar | contribuciones 05:48, 3 de junio de 2021 (UTC)

Cambiar el tipo de archivo de los PDF de una cara

Los PDF no son realmente el mejor formato de archivo. Son difíciles de recortar, difíciles de cambiar de tamaño, tienen ciertos problemas de privacidad, etc. Me preguntaba si hay soporte para un bot que extrae archivos PDF de un solo lado con solo una imagen contenida y guarda esa imagen en el tipo de archivo que es. Si el archivo dentro del PDF es JPEG, guárdelo como JPEG, si es TIF, guárdelo como TIF, etc. Hace unos años Usuario: 718 Bot mejoró miles de archivos GIF y los guardó como PNG, ya que este último es un formato mejor , puedes ver los resultados aquí . Estaba pensando que este bot haría lo mismo. ¡Explique más abajo si esta es una buena idea o no! Encontré esta excelente herramienta que extrae imágenes de archivos PDF automáticamente. Jonteemil ( charla ) 10:47, 27 de mayo de 2021 (UTC)

Yo ahora aprendí que las imágenes dentro de archivos PDF no son realmente almacenados como archivos JPEG, PNG o etc., sino más bien son los datos binarios de los píxeles, el espacio de color utilizado para la imagen, información sobre la imagen. La herramienta que encontré que extrae imágenes de archivos PDF solo parece encontrar archivos JPEG y PNG, pero no sé cómo determina cuál es uno u otro. Por ejemplo, puse File: Example.tif dentro de un PDF y la herramienta extrajo la imagen como PNG, no como TIFF. Jonteemil ( charla ) 23:24, 27 de mayo de 2021 (UTC)

Apoyo la propuesta. ¿Qué tal LaTex ? - NaBUru38 ( conversación ) 18:25, 29 de mayo de 2021 (UTC)

Informar una página

¿Puede crear un botón "Informar de esta página a los administradores" como en otros sitios? Fue muy difícil encontrar la página para llamar a los administradores. Tint Last ( talk ) 04:24, 28 de mayo de 2021 (UTC)

¿Podría darnos ejemplos de esos "otros sitios"? Nardog ( charla ) 04:27, 28 de mayo de 2021 (UTC)

En https://www.reddit.com/r/pics/comments/nmy9sd/at_the_salt_lake_city_farmers_market_a_few_years/ hay una pequeña bandera y la palabra "informe" para informar de la publicación. En Twitter puedo usar "Reportar Tweet". Tint Last ( talk ) 17:23, 28 de mayo de 2021 (UTC)

Si ve un error, simplemente corríjalo . Sungodtemple ( charla ) 17:24, 28 de mayo de 2021 (UTC)

La mayoría de las veces, los nuevos usuarios no saben cuál es la función de los administradores en Wikipedia. La regla general es que cualquier proceso normal comienza con editores que no son administradores, y solo cuando se toma una decisión se llama a los administradores para implementarla. Hay formas en que los administradores encuentran estas páginas y, por lo general, no es necesario que se les avise específicamente. Es bastante raro que se llame a los administradores para que actúen de inmediato sin que lo preceda algún proceso dirigido por un editor. -  Finnusertop ( charla ⋅ contribuciones ) 08:23, 28 de mayo de 2021 (UTC)

{{ sofixit }} o enviar a CSD son respuestas "esperadas" para las "páginas problemáticas" más obvias, pero no son necesariamente intuitivas para los nuevos editores. (consulte por qué los nuevos editores envían las solicitudes de edición a OTRS): las ideas para mejorar podrían ser útiles. - ^Charla xaosflux 12:43, 28 de mayo de 2021 (UTC)

Lo siento. Pensé que había encontrado la página para informar a los administradores: Wikipedia: el tablón de anuncios de los administradores y la disputa sobre Bob Coronato fue resuelta por los administradores. Pero el otro administrador me dijo que debería haber informado ¿Lista de canciones sobre Alabama por correo electrónico? Con un botón para informar de las páginas al tablón de anuncios, sería más fácil hacer un informe. Tint Last ( talk ) 17:35, 28 de mayo de 2021 (UTC)

@ Tint Last : comparativamente pocos de los problemas que podría querer informar son realmente "algo para los administradores"; a diferencia de la mayoría de los sitios, hay poco que los administradores puedan hacer unilateralmente que cualquier editor habitual no pueda hacer, y en el campo del contenido, Los administradores no tienen ninguna autoridad especial. La mayor parte de lo que hacemos es ejecutar lo que decide la comunidad en general (o la pequeña parte interesada en un artículo en particular), si eso necesita alguna de nuestras herramientas más amplias. Hay algunas partes en las que eso no es cierto, por ejemplo, puedo bloquear unilateralmente un vándalo obvio, mientras que un editor normal reportaría a la junta por vandalismo , si yo no estuviera "involucrado" . Nosebagbear ( charla ) 13:27, 30 de mayo de 2021 (UTC)

A veces, la AIV es demasiado lenta.

He denunciado muchos vándalos a la intervención del administrador contra el vandalismo , y aunque creo que AIV es excelente para la mayoría de los casos, creo que puede ser demasiado lento en algunos casos graves. Anoche fue una de esas — había un grupo de trolls atacando a Waiuku ; Los asumí con la ayuda de otros dos, pero las ediciones siguieron llegando. LizardJr8 los informó, pero sabía que pasaría un tiempo antes de que un administrador viniera a ayudar. Los vándalos estaban destruyendo la página más rápido de lo que podíamos arreglar. Entonces decidí cortar la línea AIV e ir directamente a Liz . Rápidamente se ocupó de ello. Lo que creo que deberíamos hacer es crear una nueva plantilla. Servirá como una especie de Bat-Señal para llamar rápidamente la atención de un administrador en casos de vandalismo que deben tratarse de inmediato, no a los caprichos de cualquiera que esté de paso. Por supuesto, reconozco que habría un problema con los nuevos usuarios pensando que sus casos de vandalismo superan a todos los demás casos en importancia, y los administradores se verían inundados de solicitudes. No estoy seguro de si esto es posible, pero tal vez podamos lograr que solo los editores más experimentados tengan acceso a la plantilla (¿tal vez como parte de Twinkle?). De esa manera, tienen suficiente experiencia en su haber para saber qué casos son de alta prioridad y cuáles no. Funcionaría así: una vez que un usuario encuentra un administrador, va a la página de discusión del administrador, abre el menú Twinkle y selecciona la plantilla. Tal vez haya una o dos casillas que deban completar, como el nombre / dirección IP del vándalo o la cantidad de ediciones disruptivas que hicieron. En resumen, esta función ayudaría a los usuarios en una crisis de vandalismo activo a contactar rápidamente a un administrador. Una plantilla Twinkle les permitiría obtener rápidamente la información transmitida en lugar de crear una petición de ayuda prolongada (como lo que hago, LOL). Me encantaría conocer tu opinión al respecto. 🐍 Helen 🐍 20:27, 28 de mayo de 2021 (UTC)

HelenDegenerate , consulte Wikipedia: Solicitudes de comentario / rol de Respondedor para una propuesta (que no parece estar progresando) de ProcrastinationsReader para ver una forma de lidiar con esto. - RoySmith (conversación) 21:46, 28 de mayo de 2021 (UTC)

Creo que teníamos algunas cosas más que resolver, pero hasta cierto punto no creo que pasaría si saliera en vivo ahora. Probablemente sea mejor intentarlo si / cuando una gran parte de la comunidad siente que hay un problema aquí. ProcrastinationReader ( charla ) 21:57, 28 de mayo de 2021 (UTC)

Oh sí, este problema. Creo que deberíamos tener una sala de chat (IRC, Matrix, Discord, lo que sea) donde pasan el rato algunos administradores, y podría haber un comando que haga ping a uno de ellos, rotando entre los administradores en la sala. Debería haber un botón Twinkle o un script de usuario separado que enviará el comando con un enlace a un caso AIV específico. Podemos averiguar el control de acceso más tarde. He tenido la intención de armar un prototipo por un tiempo, ni siquiera necesitamos hacer ping a nadie para comenzar, solo publicar un mensaje, y gracias por el recordatorio. Enterprisey  ( ¡habla! ) 03:22, 29 de mayo de 2021 (UTC)

¿Sabías que ... lo creas o no, necesitamos más administradores ? La solución es en realidad cosas como: a) hacer que la RpA sea más activa. b) hacer que el RfA sea menos tóxico. c) hacer que la RpA sea más alentadora. Si pudiéramos hacer eso, entonces este hilo nunca habría comenzado. 🐔 ¡   Chicdat    ^{Bawk para mí!} 12:16, 29 de mayo de 2021 (UTC)

¿Cuál es la diferencia entre (b) y (c), entre hacer que la RFA sea menos tóxica y hacer que la RFA sea más alentadora? Robert McClenon ( charla ) 22:53, 30 de mayo de 2021 (UTC)

Por lo que he escuchado, d) ser más prudente antes de informar las cosas a AIV también podría ayudar. Como anécdota, hay muchos informes cuestionables. Jo-Jo Eumerus ( charla ) 13:06, 29 de mayo de 2021 (UTC)

¿Qué hay de que el bot se mueva a los informes superiores donde el usuario tiene ediciones revertidas nuevas después de la marca de tiempo del informe? - xeno ^talk 13:15, 29 de mayo de 2021 (UTC)

Xeno , eso suena intrigante S Philbrick (Discusión) 19:17, 29 de mayo de 2021 (UTC)

@ Xeno :, me gusta esa idea. Me pregunto: ¿crearíamos un nuevo bot para hacer el trabajo o uno preexistente se encargaría de mover los informes? Si usamos uno preexistente, tal vez podamos hacer que ClueBot NG lo haga; después de todo , es un bot antivandálico. Y otra cosa: para llamar la atención sobre las graves crisis de vandalismo, tal vez el bot ponga algún tipo de símbolo de colores brillantes para mostrar que es un caso de alta prioridad. ¿Qué piensas? 🐍 Helen 🐍 23:56, 29 de mayo de 2021 (UTC)

HelenDegenerate : probablemente sería solo una nueva solicitud de función para el robot auxiliar de AIV, pero el primer paso sería confirmar con los clientes habituales de AIV para garantizar que sea un cambio deseable. - xeno ^talk 00:27, 30 de mayo de 2021 (UTC)

Esto es interesante. El bot necesitaría ejecutarse cada minuto o dos para ser útil, pero no tengo objeciones. No veo ninguna forma de evitar una gran proporción de los informes de vandalismo que desean utilizar la plantilla especial. El IRC obviamente tiene solicitudes para esto. Discord tiene informalmente: solo puede preguntar si alguien es libre de ayudar, pero no somos un adjunto semiformal como el IRC y nos gusta mantener las cosas en la wiki donde pertenece Nosebagbear ( charla ) 13:30, 30 de mayo de 2021 (UTC)

@ Nosebagbear :, creo que tengo la solución para eso: simplemente restrinja el uso de la función a los usuarios confirmados extendidos. O si estamos hablando de la idea de Xeno , no habrá ningún problema con eso, ya que solo una entidad podría usarlo: AIV Bot. 🐍 Helen 🐍 22:08, 30 de mayo de 2021 (UTC)

Si bien me gusta la idea de ordenar los informes, tengo un poco de miedo a los conflictos de edición. Las constantes ediciones de bots dificultarán la anotación de informes. - Kusma ( conversación ) 22:44, 30 de mayo de 2021 (UTC)

@ HelenDegenerate : la gran mayoría de las notificaciones de AIV ya las realizan los editores de EC. No es que crea que lo enviarán por correo no deseado para que sea molesto, solo creo que hasta un tercio de los informes AIV (dado que para cuando alguien lo hace, ya es el tercer (o más) número) "este es un caso rápido y malo, debería usar esto" o "han hecho actos de vandalismo después de ser denunciados a AIV, deberíamos usarlo ahora". Limitarlo de esa manera no evitará el problema. Nosebagbear ( charla ) 22:12, 30 de mayo de 2021 (UTC)

@ Nosebagbear : Cierto. Yo mismo estoy mirando para inclinarme hacia la idea de Xeno , porque depende del bot cuándo mover ciertos casos a la parte superior. Quizás podamos programarlo así: si un vándalo en particular edita x o más veces después del informe, o ha realizado más de x cantidad de ediciones disruptivas en las últimas 24 horas, entonces el programa se mueve a la parte superior y lo etiqueta como prioridad. 🐍 Helen 🐍 22:17, 30 de mayo de 2021 (UTC)

Sí, una subsección separada de que las cosas que se han subido a la cima una cierta cantidad de veces serían buenas. Sin embargo, esto (y, para ser justos, cualquier solución) aún depende de que alguien esté cerca para procesarlo. En ocasiones, las emergencias graves se eliminan en AN / ANI, pero sospecho que la mayoría de los administradores son como yo y están un poco descontentos si la solicitud no es un problema destacado, para que no se convierta en la norma. ¿También podría agregar una tarea de bot para colocar una notificación en ANI si algo había estado en el cuadro "supercrítico" durante, digamos, 3 horas? Nosebagbear ( charla ) 22:25, 30 de mayo de 2021 (UTC)

@ Nosebagbear : Eso podría solucionarse haciendo que el bot AIV averigüe qué administradores han realizado ediciones en el último minuto (por lo que probablemente todavía estarán en línea) y luego dejando un mensaje de ayuda urgente automatizado en su página de discusión. Se siguen aplicando los mismos criterios: el vándalo debe haber editado x veces o más después del informe, o ha realizado más de x ediciones revertidas en las últimas 24 horas. Si el administrador no responde a la solicitud dentro de, digamos, 10 minutos, el aviso se elimina de su página de discusión y el bot AIV elige al siguiente administrador que realiza una edición. Sé que esto suena complicado, pero podría resolver los dos problemas que mencionaste. 🐍 Helen 🐍 17:56, 31 de mayo de 2021 (UTC)

Entonces, necesitaría que esto sea aceptado por los administradores, y no estoy seguro de cuántos obtendría dado que el bit problemático es 0200-0800 UTC. También sospecho que este sistema no podría eliminar las notificaciones, y el equivalente wiki de los pings eliminados de Discord es realmente molesto, porque tengo que investigar el historial cada vez para averiguar qué era. Nosebagbear ( charla ) 18:21, 31 de mayo de 2021 (UTC)

Un concepto para una posible notificación. Anarchyte ( hablar )

Realmente me gusta esta idea en teoría, pero odiaría tener una docena de mensajes publicados en mi página de discusión cada día. Lo que sería perfecto es agregar una forma de enviar una notificación (ejemplo a la derecha) cuando varias páginas (AIV, RFPP, etc.) lleguen a n informes pendientes. Por supuesto, sería opt-in y solo haría ping a las personas que hayan realizado una edición en los últimos 30 minutos aproximadamente. Anarchyte ( charla ) 16:03, 7 de junio de 2021 (UTC)

@ Anarchyte : Sin ningún cambio de software, podría haber una plantilla de ping masivo como Template: @MILHIST que contiene una lista mantenida por bot de administradores actualmente activos que han optado por los pings de "atención a AIV". - Kusma ( conversación ) 16:10, 7 de junio de 2021 (UTC)

@ Kusma : Interesante. Sin embargo, espero que solo un bot pueda hacer ping en la lista, o obtendremos algunos administradores muy malhumorados. Anarchyte ( charla ) 16:14, 7 de junio de 2021 (UTC)

@ Enterprisey Los canales #cvn-wp-eny #wikipedia-en-helpya existen en IRC - Ahecht (
PÁGINA DE HABLAR) 16:35, 7 de junio de 2021 (UTC)

Páginas de discusión del artículo

La mayoría de las páginas de discusión de artículos son pueblos fantasmas, llenos solo de plantillas de evaluación. Mucha de la discusión relacionada con el artículo ocurre en las páginas de discusión de los usuarios, las páginas de discusión de wikiproject o en los resúmenes de edición en lugar de en la página de discusión del artículo. En el raro caso en el que la gente viene y trata de discutir el contenido real del artículo en las páginas de discusión del artículo, tienden a ser ignorados durante años, ya que nadie se da cuenta de su contribución a la página de discusión. ¿Deberíamos animar a las personas a que intenten averiguar quiénes son los autores reales de la página y hacerles ping cuando intenten escribir una nueva publicación en una página de discusión? La sugerencia para hacerlo debería estar en {{ encabezado de conversación }} y / o en el aviso de edición para tener alguna posibilidad de ser visto. ¿O deberíamos intentar animar a las personas a que vayan a un foro más visto cuando quieran decir algo sobre un artículo? - Kusma ( charla ) 10:12, 29 de mayo de 2021 (UTC)

@ Kusma : Si los usuarios nunca van a la página de discusión, entonces, si puedo preguntar, ¿cómo ayudaría un aviso en la página de discusión ? 🐔 ¡   Chicdat    ^{Bawk para mí!} 10:42, 29 de mayo de 2021 (UTC)

@ Chicdat : Estoy tratando de resolver el problema de que se ignora a las personas que han logrado usar la página de discusión. La alternativa es cambiar el encabezado de la página de discusión para disuadir a las personas que lo han encontrado de usar la página de discusión. - Kusma ( conversación ) 11:12, 29 de mayo de 2021 (UTC)

@ Kusma : ¿Puede darme algunos ejemplos de páginas de discusión con publicaciones de hace años que pasaron desapercibidas? 🐔 ¡   Chicdat    ^{Bawk para mí!} 11:15, 29 de mayo de 2021 (UTC)

@ Chicdat : De mis propias contribuciones: Charla: Leningrad Cowboys Go America , Charla: Ursula von der Leyen (aunque este es un artículo con 1.2 millones de visitas al año, ninguna de las publicaciones de la página de discusión tiene discusiones reales). Además, me he dado cuenta de que yo no voy a la página de discusión del artículo para discutir el artículo. Creo que debería haber publicado esto en Talk: Lynching of John Carter , con un ping a Drmies y al tío G. En cambio, publiqué en una charla de usuarios porque estoy acostumbrado a ignorar las páginas de discusión de artículos. Creo que es un mal hábito, pero es un hábito común. Estoy tratando de proponer que todos usemos más las páginas de discusión de artículos y usemos pings para asegurarnos de que las personas adecuadas sean notificadas de la discusión. - Kusma ( charla ) 12:05, 29 de mayo de 2021 (UTC)

@ Kusma : Vaya ... ¡tienes razón! Nunca había notado nada de esto antes. The Talk: el espacio de nombres realmente está bastante inactivo. Gracias por notar este problema. 🐔 ¡   Chicdat    ^{Bawk para mí!} 12:08, 29 de mayo de 2021 (UTC)

Bien, entonces TLDR: las páginas de discusión del artículo están muertas. ¿Deberíamos enterrarlos o revivirlos, y si queremos revivirlos, deberíamos intentar usar pings para hacerlo? - Kusma ( charla ) 13:07, 29 de mayo de 2021 (UTC)

Primero, sí, estoy de acuerdo en que es un problema. A menudo, si algo que escribí permanece más de uno o dos días, verifico el historial e iré a uno de los editores recientes para discutirlo. Me gusta la idea de notificar al autor original, pero también incluiría al editor con más ediciones. Además, ¿debería ser un "ping" en la charla del usuario, o simplemente un correo electrónico que alguien ha publicado en la charla del artículo y no ha sido respondido en x horas o x días? - Ched ( charla ) 13:25, 29 de mayo de 2021 (UTC) editado: revivido implícito en mi respuesta. - Ched ( charla ) 13:27, 29 de mayo de 2021 (UTC)

Para ampliar un poco el por qué, notifique también al editor más prolífico: hay una TONELADA de artículos en los que el autor original simplemente ya no está editando wiki. Incluso el editor más prolífico de ese artículo puede haber desaparecido hace mucho tiempo. En ese punto, supongo que solo mira el historial de la página y trata de encontrar a alguien que todavía esté activo. (lo que realmente no resuelve el problema, lo sé) - Ched ( hablar ) 13:33, 29 de mayo de 2021 (UTC)

La pregunta es si podemos / debemos tener cierta automatización para la tarea de "encontrar a las personas con más probabilidades de estar interesadas en una consulta de página de discusión". Podría ser algo así como "de las estadísticas del artículo, verifique quién ha estado activo en el último mes y luego tome los dos primeros". Una vez que tengo que mirar personalmente a través de la página del historial, es más fácil publicar en una página de discusión de usuario. - Kusma ( conversación ) 14:01, 29 de mayo de 2021 (UTC)

Ummm .. ok? "Sí"? - Estoy de acuerdo contigo Kusma. El "podemos" - no lo sé. Lo siento, no estoy familiarizado con la codificación real de tales cosas. El "deberíamos" - sí, eso creo. No estaba tratando de reafirmar nada, solo estaba de acuerdo contigo. Disculpas por la confusión si no pude expresarme con más claridad. - Ched ( charla ) 14:33, 29 de mayo de 2021 (UTC)

Oh, también pensé que estaba de acuerdo contigo, y solo traté de aclarar a quién se debería notificar. :) - Kusma ( charla ) 14:40, 29 de mayo de 2021 (UTC)

• Sospecho que la participación del editor en las discusiones de las páginas de discusión varía mucho de un artículo a otro. Ciertamente podría señalar artículos que actualmente tienen páginas de discusión muy activas y mucha gente mirando y respondiendo a nuevos comentarios. Otros (como ha notado) no tienen a nadie mirándolos. Blueboar ( charla ) 15:29, 29 de mayo de 2021 (UTC)
• Kusma ha identificado un problema genuino aquí. No creo que la solución sea usar páginas de discusión de usuarios, porque eso excluye a otros editores interesados ​​de cualquier discusión. Creo que debemos mejorar para decirle a las personas que publican artículos específicos en las páginas de discusión de los usuarios que ese es el lugar equivocado, y que la discusión debe tener lugar en la página de discusión del artículo, y para alentar a las personas a ver los artículos en los que contribuyen significativamente. (No sé cuál es el valor predeterminado de la preferencia "agregar páginas y archivos que edito a mi lista de seguimiento", pero ciertamente lo tengo configurado). Admito que tiendo a responder a las consultas en la página de discusión de mi usuario en lugar de decirle a la gente que vaya a la página de discusión del artículo. Intentaré no hacerlo en el futuro para fomentar las buenas prácticas, pero no puedo garantizar que sea perfecto. Phil Bridger ( charla ) 16:33, 29 de mayo de 2021 (UTC)

  Observo todos los artículos en los que tengo contribuciones significativas, pero a menudo no noto modificaciones en la página de discusión (hay demasiados dramas en mi lista de observación). El filtro de espacio de nombres ayuda un poco, pero todavía preferiría obtener un ping siempre que sea posible. - Kusma ( charla ) 17:18, 29 de mayo de 2021 (UTC)

  Estoy en desacuerdo. No creo que deba haber ningún "ping" u otras características que solo se hayan introducido en Wikipedia porque algunos desean emular sitios de "medios sociales". Entonces no habría ninguna expectativa de que la gente los usara. Recientemente seleccioné mi lista de seguimiento de muchos miles a unos pocos cientos. Le sugiero que haga lo mismo para no verse inundado de actualizaciones. Phil Bridger ( charla ) 18:02, 29 de mayo de 2021 (UTC)

  No entiendo este comentario sobre las redes sociales. Los pings son mucho más rápidos, fáciles y menos perturbadores para ambos lados que los mensajes de la página de conversación del usuario, y una de las mejores innovaciones que he visto aquí en mucho tiempo. - Kusma ( charla ) 18:29, 29 de mayo de 2021 (UTC)

  @ Kusma Una próxima función en MediaWiki le permitirá "suscribirse" a las secciones de la página de discusión para recibir notificaciones similares a ping sobre nuevos comentarios ( phab: T263820 - en progreso). También hay una función planificada para habilitar notificaciones cuando se agregan nuevas secciones ( phab: T263821 - aún no priorizado). El ticket de seguimiento es phab: T273920 . - SD0001 ( conversación ) 19:13, 29 de mayo de 2021 (UTC)

  Eso es genial, especialmente phab: T263821 . Si esto se implementa (y se usa ampliamente), proporcionaría otro enfoque para resolver el problema que describo. ¡Gracias por contarme sobre esto! - Kusma ( charla ) 19:27, 29 de mayo de 2021 (UTC)

  hola @ Kusma . @ Whatamidoing (WMF) me alertó de esta conversación. Que suena como que - el equipo de redacción y todos ustedes en esta conversación - comparten un interés en explorar los cambios que podrían animar a la gente para discutir ediciones en un artículo dado en lugares donde, como @ Phil Bridger se señaló anteriormente , aumentan la probabilidad de que otros editores interesados verá y potencialmente participará en.

  Con lo anterior en mente, un par de preguntas para todos ustedes:

  1. Como mencionó @ SD0001 , el equipo de edición está trabajando activamente en una nueva funcionalidad para ayudar a las personas a aumentar su conocimiento de la actividad en las conversaciones que consideran interesantes al permitirles elegir ser notificados cuando se publiquen nuevos comentarios en las secciones específicas a las que se suscriben. . ¿Estarían dispuestos a probar una versión inicial de esta función cuando esté disponible en las próximas semanas y compartir lo que piensan de ella?
  2. @ Kusma , en este comentario , ingresó la idea de que la interfaz hace más para sugerir a las personas que comienzan un nuevo tema de discusión en una página de discusión a quién podrían considerar hacer ping sobre dicho tema de discusión. Esto se cruza con la funcionalidad en la que hemos estado pensando y me lleva a preguntarme: ¿qué ve usted como los riesgos de asumir que las personas que han participado en una conversación en la página de discusión de un artículo de partículas en algún momento en el pasado estarían interesadas en saber? sobre una nueva conversación que se inicia en la página de discusión de dicho artículo?

  ¡Y por cierto, soy Peter! Trabajo como gerente de producto para el equipo de edición. En este momento, estamos enfocados en el proyecto de páginas de conversación . PPelberg (WMF) ( conversación ) 01:15, 11 de junio de 2021 (UTC)

  Hola Peter , ¡encantado de conocerte! Es una pregunta difícil, ya que debe asegurarse de que las personas no reciban tantos pings que comiencen a apagar Echo. Para las páginas de conversación activas (más de 10 personas editando en los últimos 6 meses, números sacados de un sombrero), me opondría a tal notificación, ya que creo que rápidamente podrían volverse abrumadoras para el sistema Echo. Para las páginas de discusión menos activas, el problema es si alguna de las personas relevantes ha usado la página de discusión. De mis propios artículos, veamos Story in Taipei . Puede que sea la única persona al tanto de este artículo con conocimiento de la materia, pero la página de discusión no da ninguna indicación de eso. Otras conversaciones pueden ser invisibles en el wikitexto. Considere Talk: A Voyage Round the World , que le dice que podría hacerme una pregunta a mí o posiblemente a mi revisor de GA, pero el wikitexto no lo muestra. O Charla: 1773 Expedición de Phipps hacia el Polo Norte . A veces, las personas que han utilizado la página de discusión son personas que hacen preguntas sobre el tema del artículo y no personas que pueden responder a tales preguntas. Estoy muy contento de que los desarrolladores estén analizando el problema, pero no veo ninguna solución súper fácil, especialmente no las técnicas fáciles; cualquier cosa buena tendría que combinarse con algún cambio social. - Kusma ( conversación ) 10:45, 11 de junio de 2021 (UTC)

  La existencia de tal característica lleva a las personas a creer que pueden ignorar todo lo que no la usa, con la consecuencia de que el problema que usted ha identificado. Y pensé que mi referencia a las redes sociales se explicaba por sí misma. Phil Bridger ( charla ) 19:46, 29 de mayo de 2021 (UTC)

Carpetas de listas de seguimiento

Seguimiento en Phabricator
Task T3492

He querido volver a hablar de esto durante algún tiempo, pero nunca pude hacerlo hasta ahora. La lista de seguimiento es una herramienta muy útil diseñada para ayudarnos a los usuarios a realizar un seguimiento de los cambios recientes, pero el sistema de listas AZ actual me resulta un poco tedioso. Mientras escribo esto, tengo 188 artículos en mi lista de seguimiento. No creo que sea un número tan grande en comparación con otros usuarios experimentados, pero es importante para mí y, a menudo, reviso mi lista y me pregunto: "¿Por qué este artículo todavía está aquí? No ha sido vandalizado por meses. Ya no necesito vigilarlo ". El problema es con una lista larga, a menudo me pierdo una página o me canso rápidamente de revisarla. Con las carpetas de listas de seguimiento, los usuarios como yo podrían tener más facilidad para localizar artículos.

Busqué en los archivos y encontré tres discusiones sobre temas como este ( 1 , 2 , 3 ), pero ninguno de ellos realmente despegó de la pasarela. Quiero mantener mi lista de seguimiento privada (por lo que no hay subpáginas), y marcar las páginas de la lista de seguimiento parece redundante. La última entrada es de 2013, por lo que tal vez hayamos llegado lo suficientemente lejos como para hacerlo posible. Quizás las carpetas de listas de seguimiento podrían ser parte de nuestras Preferencias como una función Beta. No soy un usuario muy técnico, por lo que no estoy seguro de si esto es posible, pero me gustaría recibir comentarios sobre la idea de las carpetas de listas de seguimiento. Ciertamente haría mi Wikilife más fácil si se utilizara, y la única razón por la que no estoy viendo más artículos de los que veo ahora es porque simplemente se perderán en la larga, larga lista. Saludos. ResPM ( T🔈 🎵C ) 01:32, 2 de junio de 2021 (UTC)

@ ResolutionsPerMinute : parece que quieres tener más de una lista de seguimiento para diferentes cosas (en este caso organizadas en "carpetas" de algún tipo) ¿correcto? Si es así, este es phab: T3492 (¡ahora celebra su 15 ° año de no implementarse!). - ^Charla xaosflux 01:49, 2 de junio de 2021 (UTC)

@ Xaosflux : Esto se parece a lo que estoy hablando, pero ¿15 años en el trabajo sin ser implementado? ¿Estoy escuchando eso bien? ResPM ( T🔈 🎵C ) 02:05, 2 de junio de 2021 (UTC)

@ ResolutionsPerMinute : sí , parece que hay un par de problemas: (a) nadie puede decidir qué debería ser exactamente, (b) ningún voluntario quiere hacerse cargo de la gestión real, incluido el desarrollo del software, hasta su finalización. - ^Charla xaosflux 02:10, 2 de junio de 2021 (UTC)

@ Xaosflux : Maldita sea. Bueno, me consuelo en el hecho de que existen sus cimientos. Ojalá pudiera ayudar, pero soy un citer, no un desarrollador. Yo lo haría si pudiera. Gracias por informarme . ResPM ( T🔈 🎵C ) 02:16, 2 de junio de 2021 (UTC)

Usuario: MusikAnimal / customWatchlists existe, pero las listas de seguimiento son visibles públicamente. También es posible implementar listas de seguimiento privadas en JavaScript (evitando así los obstáculos de phab) utilizando mw.user.options, aunque nadie parece haberlo hecho todavía. Se podría presentar una petición en WP: EUR / R . - SD0001 ( conversación ) 08:21, 4 de junio de 2021 (UTC)

ResolutionsPerMinute , estoy tratando desesperadamente de no comentar sobre qué tan grande es su lista de seguimiento (la mía es 12,929) y no comentaré sobre la propuesta de carpeta, pero quiero asegurarme de que sepa que ahora hay una opción cronometrada disponible. Haga clic en la estrella, observe el cuadro desplegable y elija una opción que no sea permanente. Trabajo en muchas situaciones de derechos de autor y quiero el artículo relacionado en mi lista de seguimiento por un tiempo, en caso de que no sepan que se pongan en contacto conmigo, pero no lo quiero para siempre, así que utilicé una de las opciones temporales. Lo crea o no, eso ha ayudado a evitar que mi lista de vigilancia se salga por completo de control. Parece que esa opción podría aplicarse cuando decide ver un artículo que ha sufrido algún tipo de vandalismo. S Philbrick (Discusión) 01:08, 11 de junio de 2021 (UTC)

@ Sphilbrick : Conozco las opciones cronometradas desde que se implementaron por primera vez y he decidido utilizar esta opción como sustituto por ahora. No soy mi solución ideal, pero funciona. ResPM ( T🔈 🎵C ) 01:17, 11 de junio de 2021 (UTC)

Reforma radical de DYK

Empiezo con la premisa de que, desde la perspectiva del lector, WP: DYK está fundamentalmente roto, en el sentido de que muchas de las entradas son simplemente aburridas. Estoy pensando en comenzar una propuesta para que llevemos a cabo una prueba en la que eliminemos todos los requisitos de elegibilidad y, en su lugar, permitamos que los hechos de cualquier página sean nominados, ¡pero exigimos! Votar todas las propuestas de modo que solo se seleccionen las que se consideren más interesantes.

Anticipo que esto generaría bastante oposición solo en virtud de ser una desviación tan radical del status quo. De acuerdo con las instrucciones del laboratorio de ideas, no estoy buscando apoyos / oponentes aquí, pero me gustaría tener una idea de cuán probable sería que esto se negara y si hay alguna forma en que pueda configurarlo. reducir las posibilidades de eso o, de manera más general, cualquier consideración importante que deba tener en mente. Saludos, {{u | Sdkb }}  ^charla 07:24, 4 de junio de 2021 (UTC)

La verdadera pregunta es cuál es y debería ser el objetivo de DYK. ¿Se supone que es divertido y emocionante leerlo? Entonces, ¿por qué limitarse a artículos nuevos, la gran mayoría de los cuales tratan sobre temas poco conocidos? Desde la perspectiva a corto plazo del lector, ¿por qué debería estar en la página principal?

Lo que me gusta de DYK es que fomenta que los nuevos artículos tengan un nivel decente. Lo cual es útil para los lectores, y más que leer los artículos mientras están en la página principal.

De todos modos, volviendo a tu idea: realmente no veo la votación como una salida viable a menos que haya una participación masiva. Y DYK ya es un proceso bastante pesado, por lo que quizás necesitemos reducir la complejidad en otros lugares. - Kusma ( conversación ) 07:59, 4 de junio de 2021 (UTC)

Para mí, el propósito siempre ha sido resaltar casualmente algunos de nuestros artículos más oscuros de calidad no FA para lectores y editores haciendo uso de un formulario de estilo específico (DYK) que podría despertar su interés. Nunca entendí por qué lo limitamos a artículos nuevos. - Th e DJ ( hablar • contribuciones ) 10:01, 4 de Junio 2021 (UTC)

No nos limitamos a los artículos nuevos: las expansiones 5x (es decir, el artículo real) y los artículos buenos recién promocionados también son elegibles. - Kusma ( conversación ) 15:38, 4 de junio de 2021 (UTC)

DYK en su forma actual definitivamente cumple un papel como incentivo para el editor. Es un poco difícil equilibrar eso con los lectores que pierden ganchos más interesantes. Parte de lo que me atrae de un juicio es que nos permitiría ser más claros sobre cuál es la compensación. Si vemos que los ganchos obtienen significativamente más páginas vistas, sabremos que es una posibilidad; lo mismo con lo contrario. {{u | Sdkb }}   ^charla 15:39, 4 de junio de 2021 (UTC)

Creo que deberíamos considerar claramente lo que queremos. ¿ Todos los ganchos deberían atraer a todos ? [Creo que eso descarta demasiadas áreas temáticas.] ¿O está bien que haya algunos artículos sobre temas de atractivo limitado (convenciones de bandas de mariachis de Letonia, amebas extintas, estaciones de radio peruanas) en la mezcla? Tenemos algunos criterios de diversidad para los constructores de preparativos que aseguran que no tengamos ocho edificios en Nueva York u ocho himnos católicos u ocho políticos al mismo tiempo. Si eso no es suficiente para encontrar dos o tres interesantes todos los días, tal vez necesitemos reclutar más nominadores con intereses más generales. - Kusma ( conversación ) 15:51, 4 de junio de 2021 (UTC)

No estoy seguro de creer que exista una relación inversa tan fuerte entre oscuridad e interés. Gran parte del atractivo de Wikipedia como lugar de entretenimiento proviene precisamente del hecho de que contiene mucho sobre temas oscuros, y varios de los mejores DYK de todos los tiempos tratan temas bastante oscuros. {{u | Sdkb }}   ^charla 16:40, 4 de junio de 2021 (UTC)

Estoy de acuerdo en que muchas entradas son aburridas. Mi reacción a la mayoría de los ganchos es "¿y qué?" La satisfacción de los editores debería ser crear algo que sea emocionante para los lectores, más que el mero hecho de que "su" creación esté en la página principal. Muchos temas son simplemente aburridos, por lo que, por muy bien escritos que estén los artículos, no deberían calificar para esta sección. Phil Bridger ( charla ) 08:27, 4 de junio de 2021 (UTC)

Si puedo decir por el gancho que un artículo trata sobre un tema aburrido como el béisbol o el cricket, simplemente lo ignoro, sin importar lo interesante que suene el gancho. Pero a mucha gente le importará y disfrutará el mismo artículo. Supongo que necesitamos algo de variedad. - Kusma ( charla ) 09:07, 4 de junio de 2021 (UTC)

Kusma , casi todos mis artículos han sido sobre edificios históricos en Escocia. Tal vez sea un nicho de interés, pero en su mayoría obtienen entre 5 y 10,000 visitas; me gusta pensar que algunos de los lectores deben haber encontrado algunos de ellos interesantes ... Girth Summit _(blether) 16:06, 4 de junio de 2021 (UTC)

La cuestión no es si el tema general interesa a una persona en particular, sino si el gancho es interesante. Por ejemplo, los ganchos de ayer incluían "... ¿ese concertista, compositor y libretista de ópera Leonard Liebling fue el editor en jefe del Musical Courier desde 1911 hasta 1945?" y "... que la directora de Big Tree Elementary leyó un libro desde un globo aerostático para honrar a sus estudiantes por haber leído colectivamente más de 2.5 millones de minutos en 2006?". ¿No es obvio cuál sería el gancho más interesante para más del 99% de nuestros lectores? Eso es cierto para mí, aunque resulta que estoy más interesado en leer sobre Leonard Liebling que sobre Big Tree Elementary. Seguramente alguien tenía que ser editor de una revista publicada, por lo que ese gancho es definitivamente un "¿y qué?". Phil Bridger ( charla ) 18:40, 4 de junio de 2021 (UTC)

Sí, esto. El hecho de que los ganchos como el de Liebling no sean rechazados instantáneamente ilustra cuán bajos son nuestros estándares. Ninguna otra lista de hechos divertidos en Internet se vería en el espejo después de publicar eso. Y los lectores pueden buscar cualquier otra lista que deseen. No podemos competir cuando nos atamos las manos a la espalda limitando nuestro alcance a contenido nuevo, por lo que creo que debemos considerar eliminar los requisitos de elegibilidad, incluso si cambia totalmente la forma en que DYK ha trabajado tradicionalmente. {{u | Sdkb }}   ^charla 19:20, 4 de junio de 2021 (UTC)

Hay dos cosas que me gustaría decir aquí: (a) DYK actualmente tiene más presentaciones de las que la gente está contenta (muchos preferirían que DYK se actualice solo una vez en 24 horas, no una vez en 12), por lo que es posible que no sea necesario ampliar la elegibilidad y (b) ¿Por qué deberíamos competir con listas de hechos divertidos en otros lugares? ¿En qué nos beneficiamos si intentamos hacer eso? - Kusma ( conversación ) 19:36, 4 de junio de 2021 (UTC)

Bueno, como wikipedistas, creo que queremos que la gente lea Wikipedia, que incluye nuestra página principal. Y si es así, eso significa que tenemos que competir por su atención, lo que significa competir con otros lugares a los que podrían ir en lugar de buscar datos triviales. En el sentido que lo digo en serio, no es realmente una elección, es algo que ya estamos haciendo y tenemos que hacer si seguimos teniendo DYK. {{u | Sdkb }}   ^charla 21:27, 4 de junio de 2021 (UTC)

Todo se reduce a cuáles son los objetivos principales que las personas creen que deben alcanzar ¿Sabía usted? Siguiendo lo que otros han dicho, es posible que el aprendizaje de trivialidades no cuente con el apoyo del consenso. En una nota relacionada, una vez participé en una discusión sobre haber presentado contenido en la página principal con un editor que no podía entender por qué estaba planteando metas desde la perspectiva de un lector. Para ellos, el objetivo principal era actuar como un incentivo para el editor. Sin embargo, estoy de acuerdo en que, además de pensar en los objetivos del editor, debemos considerar el valor para los lectores de los elementos de la página principal. isaacl ( charla ) 22:05, 4 de junio de 2021 (UTC)

Esto. Tiempos infinitos ESTE. Un gancho que combina "El tipo de la música hace cosas musicales" y "la revista publicada tiene editor" es aburrido. Si el editor de la revista musical fuera un mecánico de automóviles o si este destacado músico editara una revista de ciencia ficción, sería interesante. - Khajidha ( conversación ) 12:39, 7 de junio de 2021 (UTC)

"La enciclopedia de Internet se distingue de otros recursos web porque solo se esfuerza por incluir información de fuentes periodísticas confiables. Ese es el valor del proyecto: apegarse a sus propios procesos aburridos, incluso si eso significa que la versión de la enciclopedia es menos dramática que los tabloides". - Stephen Harrison, Slate Gråbergs Gråa Sång ( charla ) 09:53, 4 de junio de 2021 (UTC)

Tengo una visión similar a la de Kusma anterior: lo que me gusta de DYK en su forma actual es que celebra la creación de contenido. Anima a los editores a escribir nuevos artículos con un estándar decente, y hace que otros vengan y revisen, copien, editen y modifiquen esos artículos. Los editores más nuevos pueden aprender mucho al observar los cambios que realizan los revisores experimentados en el poco tiempo que su creación está en las preparaciones y las colas. Creo que ese tipo de estímulo solo puede ser algo bueno, tanto para los editores como para los lectores que se benefician de los nuevos artículos de calidad decente. Si los ganchos DYK en sí son de gran beneficio para el lector es una cuestión ligeramente diferente, pero la diferencia entre aburrido y fascinante es muy subjetiva. Hice clic en algunos DYK y pensé '¿y qué?', Pero probablemente hicieron que otras personas pensaran 'guau, ¿de verdad?' o 'genial, no lo sabía'. Decenas de miles de personas hacen clic en nuestros ganchos todos los días. ¿Están disminuyendo esos números, lo que indica que los lectores habituales están perdiendo interés en ellos porque encuentran que suelen ser aburridos? También me preocupa un poco que al elevar el listón de lo interesante / sorprendente que debe ser un gancho, podríamos estar fomentando la escritura sensacionalista, lo cual no queremos. (También: ¿Cambio? ¡Argh, temo que cambie!) Girth Summit _(blether) 10:21, 4 de junio de 2021 (UTC)

Ese es un buen punto sobre el fomento de la escritura sensacionalista. {{u | Sdkb }}   ^charla 15:40, 4 de junio de 2021 (UTC)

• Si la queja principal es el interés personal del OP en los ganchos (los describen como "aburridos"), entonces esto no es un problema para mí. No tenemos forma de saber qué es lo que entusiasma al OP y por qué una propaganda de DYK en particular puede o no aburrirlos, pero cambiar toda la sección solo para entretener a una persona parece algo poco inteligente. Además, "no ser aburrido" no parece ser un objetivo particular de DYK. Se supone que la sección resalta el hecho de que Wikipedia se actualiza y amplía constantemente al dirigir a los lectores a las expansiones más recientes. Si bien creo que deberíamos hacer todo lo posible para encontrar lo más interesante que decir sobre un artículo una vez que sea elegible para DYK, la propaganda en sí es una preocupación secundaria para mí. Me interesa más que el artículo sea nuevo o ampliado recientemente; la propaganda es completamente secundaria. Si puedes escribir un gancho interesante, hazlo. Pero si el texto expandido no contiene nada que a alguien le parezca interesante (nuevamente, donde "interesante" solo puede ser una preferencia personal, y que no hay nada objetivo o universal en lo que una persona puede o no puede encontrar interesante), entonces lo que sea , eso NO debería ser una cosa descalificante para aparecer en DYK. Si reformamos DYK, en mi opinión, es que ampliamos y permitimos que pasen más anuncios, no menos. - Jayron 32 16:02, 4 de junio de 2021 (UTC)

  El 99% de los lectores no tiene ni idea de que DYK se limita a artículos nuevos / ampliados recientemente, por lo que tengo que estar totalmente en desacuerdo con usted en que de alguna manera les destaca que Wikipedia se está ampliando / actualizando. También creo que el hecho de que los ganchos DYK tengan un grave problema de interés es absolutamente evidente; Goszei mencionó el otro día en WP: Discord que es algo que han escuchado decir a los no editores. A veces podemos estar tan hundidos en la maleza que nuestra vista se vuelve ciega; tratemos de superar eso. {{u | Sdkb }}   ^charla 16:19, 4 de junio de 2021 (UTC)

  Sdkb , ¿no sería la respuesta tener un pequeño fragmento de texto en la página principal que lo explique? "¿Sabías que ... algunos datos interesantes de artículos recientemente escritos o ampliados?". O algo así. Y FWIW, acabo de examinar el DYK de hoy y encontré cuatro ganchos en los que me gustaría hacer clic porque se ven interesantes, y cuatro en los que pensé que no me molestaría porque se ven aburridos. Esa no es una mala tasa de aciertos, en mi opinión; No veo cómo podríamos esperar que todos fueran interesantes para la misma persona, a menos que estuviéramos tratando de atender a una audiencia muy homogénea. Girth Summit _(blether) 16:27, 4 de junio de 2021 (UTC)

  Érase una vez, bajo "Sabías que ...". solía decir, " De los artículos más recientes de Wikipedia: ". Resolvería el problema que Sdkb señala anteriormente si reinstauramos ese lenguaje o un lenguaje similar, como " De los artículos nuevos y recientemente expandidos de Wikipedia: ". ~ ONUnicorn ^{( Charla | Contribuciones )} resolución de problemas 16:31, 4 de junio de 2021 (UTC)

  ¿Cuál fue el motivo para eliminarlo en primer lugar? En mi opinión, el "contenido más nuevo" puede ser más parsimonioso, incluyendo tanto artículos nuevos como contenido nuevo agregado a los antiguos. Y mi punto de vista sobre lo aburrido es sobre el mismo Girth Summit , en este momento solo hay 3 ganchos que personalmente no encuentro particularmente interesantes e incluso entonces ninguno de ellos me parece obviamente tedioso. - Nizolan ^{( charla · c. )} 18:39, 4 de junio de 2021 (UTC)

  En 2015, alguien mencionó que tener esa línea directamente debajo de "Sabías que ..." antes de que los ganchos interrumpieran el flujo de la oración. Querían moverlo al fondo. Una discusión en la página de discusión de DYK decidió reemplazar esa cláusula con un enlace en la parte inferior que decía "Artículos mejorados recientemente". No sé cuándo ni por qué se eliminó ese enlace, pero en la actualidad parece haber sido reemplazado por el enlace de archivo. ~ ONUnicorn ^{( Charla | Contribuciones )} resolución de problemas 22:48, 4 de junio de 2021 (UTC)

  Creo que restablecer esa línea definitivamente sería una mejora con respecto al status quo. No estoy seguro de que sirva para resolver el problema de interés que estamos considerando aquí, pero me encantaría ver una discusión separada que proponga traerlo de vuelta. {{u | Sdkb }}   ^charla 23:54, 4 de junio de 2021 (UTC)

  Absolutamente deberíamos restaurar el texto explicativo, de hecho mencioné este mismo tema en WT: DYK hace una semana o dos, creo que es esencial que los lectores entiendan lo que representa la sección DYK. Gatoclass ( charla ) 03:28, 8 de junio de 2021 (UTC)

• Otra idea a medias para hacer que DYK sea más interesante sería descartar los noms que son tan aburridos que nadie los ha revisado en un mes o que no han sido promovidos a la cola durante un mes. Pero no estoy seguro de cuán infeliz haría a la gente. - Kusma ( charla ) 16:04, 4 de junio de 2021 (UTC)

  Kusma , en realidad no creo que sea una mala idea. Si un nominado ha estado rondando por un mes y nadie lo ha revisado, probablemente sea porque (a) el gancho es aburrido, pero nadie quiere ser lo suficientemente malo como para decirlo, o (b) el artículo es largo y aburrido, y a nadie se le puede pedir que lo revise correctamente. De cualquier manera, probablemente debería permitirse que se caiga del borde de la cinta transportadora después de un cierto período, y un mes me parece el tipo de estadio correcto para mí. Girth Summit _(blether) 18:18, 4 de junio de 2021 (UTC)

  Eso es solo una suposición. Creo que es igualmente probable que muchos revisores busquen DYK que creen que serían los más fáciles / rápidos de revisar solo para obtener un crédito QPQ por su propio gancho. MB 17:09, 7 de junio de 2021 (UTC)

  También podríamos permitir que los noms revisados ​​se agoten, moviendo el veto de bolsillo de los revisores a los creadores de preparación. - Kusma ( conversación ) 17:40, 7 de junio de 2021 (UTC)

• Creo que estamos llegando lentamente a un punto en el que ya se ha escrito sobre la mayoría de los temas "interesantes". No estoy diciendo que nos estamos quedando sin temas en absoluto, baso esto en la nueva página / patrullaje de AfC. Realmente no he notado que DYK se vuelve "más aburrido", pero he notado que hay muchos ganchos que no describen adecuadamente por qué alguien es notable. Por ejemplo, hay uno en la portada en este momento: ... que Richard Hatherill sobrevivió a un motín y un naufragio, solo para morir de una enfermedad a la edad de 35 años? Eso está muy bien, pero ¿quién diablos es Richard Hatherill de todos modos? (No ayuda que el artículo tenga una sola fuente que parece parafrasear las tres oraciones a las que tengo acceso). He notado un par de estas recientemente, y creo que este es un problema solucionable. No estoy del todo seguro de que DYK necesite un replanteamiento, pero estaría dispuesto a escuchar una propuesta para cambiarlo. SportingFlyer T · C 18:34, 4 de junio de 2021 (UTC)

  No estoy seguro de que nos estemos quedando sin temas interesantes per se: Wikipedia todavía está muy sesgada con el tipo de cosas sobre las que los editores de Wikipedia escriben y hay grandes lagunas en la cobertura de ciertos campos con muchas cosas interesantes que decir sobre ellos. (mi campo de investigación IRL de historia del pensamiento político es uno de ellos), por no mencionar grandes extensiones de historia no occidental. Pero estoy de acuerdo en que los ganchos deberían dar un grado básico de detalle al presentar las cosas de las que están hablando donde de otra manera no es obvio. Eso fue algo que busqué en mis breves períodos de revisión en DYK en el pasado. - Nizolan ^{( charla · c. )} 18:49, 4 de junio de 2021 (UTC)

  Eso es cierto, hay muchos temas notables que aún no hemos tocado. Mi argumento es que se han hecho las fáciles. Pero todo esto es una tangente. SportingFlyer T · C 21:57, 4 de junio de 2021 (UTC)

  Todavía me sorprende constantemente la cantidad de cosas sobre las que aún no tenemos artículos (incluidas las razonablemente fáciles donde existen fuentes gratuitas en inglés). De todos modos, no estoy seguro de que la disponibilidad de temas realmente afecte mucho a DYK. Busque en los archivos de Wikipedia: Adiciones recientes . ¿Fue DYK más interesante hace 15 años, cuando no todo estaba escrito? - Kusma ( conversación ) 22:51, 4 de junio de 2021 (UTC)

• La función, según WP: DYK , es mostrar artículos nuevos o ampliados . Es, como dijo Jayron, se supone que resalta el hecho de que Wikipedia se actualiza y amplía constantemente al dirigir a los lectores a las expansiones más nuevas . También es, prácticamente hablando, un motivador para los contribuyentes. Cuando trabajo con un novato en un artículo nuevo, el proceso DYK siempre es intimidante, pero cuando finalmente llega a ser la página principal, esa sensación de "¡mira lo que hice!" es extremadamente poderoso. Para las personas que contribuyen porque quieren tener un impacto en el mundo al contribuir a un recurso de conocimiento gratuito, el aumento en el número de lectores les asegura que sí, la gente realmente está leyendo lo que estás escribiendo. Es muy importante estar en la página principal.
  ... Pero , creo que Sdkb tiene un buen punto de que al enmarcarlo simplemente como "¿Sabías?", Estamos preparando a los lectores para que esperen una lista de hechos extraños, salvajes, interesantes y emocionantes de toda Wikipedia. Quizás ayudaría agregar una línea contextualizando la sección, pero al menos parece que vale la pena hablar de otras opciones.
  Lo que creo que no va a funcionar bien es tratar de escribir reglas que busquen lograr los objetivos de DYK pero intentar calificar lo que es o no es interesante. Nos arriesgamos a marginar áreas temáticas enteras e invitamos a interminables debates culturalmente relativos sobre lo que es o no es "suficientemente interesante".
  Al final, creo que una sección de la página principal dedicada a contenido nuevo / recién expandido es importante, pero hay posibilidades de aclarar / contextualizar o incluso, no sé, dividir el espacio de la página principal en dos secciones o algo así. - ^{Hablar de las} rododendritas \\ 22:05, 4 de junio de 2021 (UTC)

• Las rododendritas lo clavaron. Soy ambivalente sobre la re-adición de un eslogan "de los artículos recientemente creados o ampliados de Wikipedia", pero tengo curiosidad por saber cuál es la posición de la comunidad. Ese lema en sí mismo puede ser un buen "gancho" para los demás, o incluso un meta interesante: "¿lo sabías?". - Goszei ( conversación ) 02:44, 7 de junio de 2021 (UTC)
• Creo que agregando un del eslogan de artículos recientemente creado o ampliado de Wikipedia para contextualizar DYK es una solución fantástica sin inconvenientes. luciérnaga ( t · c ) 10:51, 7 de junio de 2021 (UTC)

El último espacio en DYK siempre debe ser "... que los hechos anteriores fueron tomados de artículos recientemente creados o expandidos de Wikipedia?", Con "artículos recientemente creados o expandidos" enlazando a la descripción de cómo nominar un artículo para DYK. - Khajidha ( conversación ) 12:36, 7 de junio de 2021 (UTC)

@ Firefly : Aclarar el alcance de la sección DYK es genial. La desventaja es que un eslogan (o Khajidha idea 's de un DYK final) tendrán espacio principal espacio de la pantalla, lo que no es tan infinita como puede parecer. Pasar de 8 a 7 DYK podría ser parte de ese cambio. Supongo que vale la pena, pero es posible que otros no estén de acuerdo. - Kusma ( conversación ) 12:46, 7 de junio de 2021 (UTC)

El único problema con el "estado de la pantalla del espacio principal" es que hemos optado por darle a esta página un diseño de dos columnas diferente a cualquier otra página del sitio. Esto nos obliga a sumar y restar elementos de varias secciones para mantener el "equilibrio". De lo que todo el mundo se queja, pero parece que la mayoría de ellos encuentran la respuesta obvia de "hacer que la mierda sea una sola columna y el problema desaparece" aún más objetable. - Khajidha ( conversación ) 13:07, 7 de junio de 2021 (UTC)

@ Kusma : He intentado incluir la explicación sin afectar nada más. Es una primera aproximación burda, así que tómela solo como prueba de que es posible y nada más. :) luciérnaga ( t · c ) 13:15, 7 de junio de 2021 (UTC)

¡Gracias @ Firefly ! Es posible que el tamaño de fuente pequeño no vuele por razones de accesibilidad, pero tal vez podamos fusionarlo con algunos de los enlaces. Aquí hay una variación que integra los enlaces en lo que dijo @ Khajidha :

... que estos hechos provienen de artículos recientemente creados o expandidos , y que puede comenzar o nominar los suyos propios?

¿O algo así? - Kusma ( conversación ) 13:36, 7 de junio de 2021 (UTC)

@ Kusma : Eso es mucho mejor que mi intento desde el punto de vista de la accesibilidad, aunque es posible que tengamos un rechazo porque rompe la coherencia con otras secciones de la página principal. Agregué tu idea a mi caja de arena para que todos podamos ver cómo se vería en la práctica. luciérnaga ( t · c ) 13:44, 7 de junio de 2021 (UTC)

Es posible que aún necesite algunos ajustes (probé una alternativa, aún no estoy convencido), pero debería ser posible hacer que esto funcione. - Kusma ( charla ) 16:31, 7 de junio de 2021 (UTC)

FWIW Kusma , siéntase libre de usar la caja de arena que vinculé para experimentar si lo desea. firefly ( t · c ) 12:19, 8 de junio de 2021 (UTC)

• Oponerse Es la premisa la que está rota. DYK no es aburrido; es una de las secciones más interesantes de la página principal. Considere las alternativas:

1. FA: por lo general, se trata de un tema de nicho como la Interestatal 69 en Michigan , el freno de la conversación de hoy. DYK es mejor porque es más variado, más breve y más enfocado en ser novato.
2. ITN: por lo general, es bastante obsoleto con hasta una semana o más entre nuevos anuncios, mientras que DYK es mucho más productivo, ya que ejecuta de 8 a 16 elementos nuevos todos los días. Y los anuncios de ITN se centran en una pequeña porción de lo que realmente está en las noticias y parecen estar completamente obsesionados con la muerte.
3. OTD: un formato cansado con el mismo material reciclado año tras año
4. FL - la FA del pobre
5. FP: las imágenes suelen ser bastante buenas, pero los desenfoques adjuntos suelen ser nefastos

Y luego está todo el texto repetitivo de la página principal: docenas de enlaces y lemas que pueden ser útiles pero no son emocionantes.

Pero, en cualquier caso, Wikipedia es una enciclopedia, no una comedia, un drama o un thriller, por lo que nuestros lectores esperarán que el contenido tenga un tono comparativamente educativo: "digno pero aburrido". Si lo encuentra aburrido, entonces ha venido al lugar equivocado.

Andrew 🐉 ( charla ) 16:13, 7 de junio de 2021 (UTC)

@ Andrew Davidson , tanto por mi publicación inicial como por las reglas del laboratorio de ideas, ¡por favor no! Vote aquí. Con respecto a su comentario, las otras secciones de la página principal tienen sus propios problemas, la mayoría de los cuales se han discutido extensamente en otros lugares. Sin embargo, están más allá del alcance de esta discusión; tratemos de mantenernos algo concentrados. {{u | Sdkb }}   ^charla 18:09, 7 de junio de 2021 (UTC)

Entonces, el OP no quiere! Votos sobre su propuesta para presentar! Votos a DYK. WP: ¡ SALSA !

Y las otras secciones principales son relevantes porque demuestran lo que sucede cuando tienes una galería de votantes! ITN está bastante roto porque funciona de esa manera y, por lo tanto, la mayoría de las nominaciones son rechazadas. La única parte de ITN que es tan productiva como DYK es RD y eso se debe a que se reformó para eliminar los votos obstinados sobre la dignidad de los sujetos.

Andrew 🐉 ( charla ) 08:38, 9 de junio de 2021 (UTC)

No tengo idea de lo que estás hablando. El objetivo del laboratorio de ideas es discutir ideas, no votarlas, ¿cuánta más explicación necesita? Aza24 ( conversación ) 22:27, 9 de junio de 2021 (UTC)

Estoy de acuerdo con todos los puntos planteados por Andrew Davidson . DYK es para artículos nuevos que son accesibles para leer, lo que lo hace mejor que la mayoría del contenido de la página principal. Los "ganchos interesantes" son totalmente subjetivos, y si no le gustan un par de ganchos, no los lea. Parece que Sdkb está tratando de ignorar todos los puntos válidos mencionados anteriormente mediante wikilawyering sobre el uso de la palabra oponer, en lugar de responder a cualquiera de las comparaciones con un contenido de portada mucho peor. Por ejemplo, no puedo recordar la última vez que leí un FA / FL en la portada, ya que son temas demasiado largos y de nicho. Por otro lado, se alienta a los revisores de DYK a hacer que los ganchos sean accesibles a una amplia audiencia, lo que en su mayoría lo hacen. Joseph 2302 ( charla ) 08:42, 10 de junio de 2021 (UTC)

No creo que me guste esta propuesta. DYK es un lugar que motiva a los editores, especialmente a los nuevos que quieren que su trabajo sea visto por más lectores. Si los ganchos son aburridos, me gustaría que el revisor o el promotor sugirieran ganchos ALT. También estoy a favor de aumentar el recuento mínimo de 1500 palabras para los artículos de DYK, ya que esto generará más texto y posiblemente proporcionará mejores ganchos. Me preocupa que "Permitir que los hechos de cualquier página" sean nominados hará que DYK destaque artículos populares en lugar de un conjunto diverso de temas, ya que esos son los artículos que más frecuentan los lectores y editores. Si se implementó esta idea, me gustaría que se estableciera un nuevo conjunto de reglas para la ejecución de prueba, de modo que los artículos con etiquetas, problemas de origen o que ya hayan aparecido en DYK en los últimos años no sean elegibles. Me gusta la conversación anterior para agregar una oración sobre qué es DYK y alentar a más editores a participar. Z1720 ( conversación ) 00:00, 8 de junio de 2021 (UTC)

• Comentario Como creador del artículo de Leonard Liebling , encuentro un poco descorazonador leer que otros piensan que mi gancho es tan aburrido que es el ejemplo prototípico de lo que está mal en DYK. Personalmente, pensé que era interesante, simplemente por la variedad de cosas diferentes que se mencionan en el gancho. Pianista de conciertos, libretista de ópera, compositor y editor musical de una importante publicación musical desde hace mucho tiempo. Es un conjunto de habilidades muy variado que es inusual, y creo que es interesante sin importar lo que digan los demás aquí. Al final, este tipo de discusión resalta el gusto personal y la opinión personal sobre lo que te entretiene personalmente, que en última instancia es subjetivo. Mi opinión personal es que DYK está funcionando bien tal como está y tiene un propósito útil para fomentar la edición positiva. Si no está roto, no lo arregles. 4meter4 ( conversación ) 00:02, 8 de junio de 2021 (UTC)

DYK siempre ha sido bastante subjetivo, y lo que podría ser interesante para un nominador puede no serlo para otros, o incluso viceversa. Para ser franco, a veces pienso que hay ocasiones en las que un anzuelo simplemente no va a despertar mucho interés fuera de un nicho pequeño, pero los clientes habituales, ya sea por cortesía u otra razón, se niegan a rechazar el anzuelo o proponer alternativas. También hay casos en los que los ganchos son claramente defectuosos, pero los nominadores insisten en ellos a pesar del consenso en contra, lo que, dado que la mayoría de las veces genera problemas, es otro tema que vale la pena considerar. Narutolovehinata5 ^{t c csd nuevo} 00:15, 8 de junio de 2021 (UTC)

Como colaborador de DYK durante años, mi experiencia es que los revisores suelen ser bastante objetivos, y las reglas de DYK para la revisión proporcionan la estructura suficiente para mantener las cosas así. Francamente, las sugerencias aquí abogan por un mayor grado de subjetividad del que existe actualmente al alentar a los editores a expresar sus propios prejuicios sobre lo que es interesante y permitir que los votos de la mayoría determinen el contenido. Inevitablemente, tal sistema terminará marginando ciertos tipos de contenido (particularmente con una base de votantes predominantemente blanca masculina heterosexual que vota). No estoy a favor de crear un proceso sistemáticamente injusto e injusto, lo que harán las sugerencias aquí. También creará más trabajo y más oportunidades para conflictos y estrés. No me parece un cambio atractivo. 4meter4 ( conversación ) 02:03, 8 de junio de 2021 (UTC)

La preocupación por el sesgo es algo que ciertamente querríamos tener en cuenta, pero no tenemos forma de saber si sería un gran problema o no cuando ni siquiera estamos dispuestos a realizar una prueba. ITN opera con un sistema de votación muy similar y, a pesar de las constantes quejas de ambos extremos, parece funcionar bien al menos en términos de globalizar su cobertura. Una mentalidad cultural de "¡no solo! Vote sí en el gancho de los videojuegos solo porque a usted personalmente le gustan los videojuegos" podría ser suficiente para minimizar los problemas. Y ciertamente no es que nuestro sistema actual esté libre de prejuicios, está fuertemente inclinado hacia áreas temáticas que producen muchas páginas y que tienen editores dispuestos a hacer nominaciones. {{u | Sdkb }}   ^charla 02:36, 8 de junio de 2021 (UTC)

De hecho, tenemos una forma de saberlo. Ya se ha escrito mucho sobre el sesgo heterosexual sistémico masculino blanco en Wikipedia que se basa en la investigación con datos. Buscalo en Google. Crear un sistema de votación en DYK que empodere aún más a la mayoría de edición de hombres blancos heterosexuales no es una solución. No hay absolutamente ninguna manera de que puedas argumentar razonablemente que un cuerpo de votantes compuesto por hombres blancos predominantemente heterosexuales no va a tener su punto de vista dominante en un sistema de votación. Eso es codificar el sesgo en nuestro proceso. En cuanto a los temas actuales, sí, tenemos prejuicios hacia temas occidentales en nuestras nominaciones e ignoramos a las mujeres. Como miembro de WikiProject Women in Red, paso la mayor parte de mi tiempo creando artículos sobre mujeres para ayudar a resolver eso. No podemos evitar lo que se nomina, porque este es un proyecto voluntario, pero podemos crear un sistema que no excluya el contenido de las minorías. 4meter4 ( conversación ) 02:45, 8 de junio de 2021 (UTC)

Bueno, hay una solución fácil para eso, que es que todos los hombres heterosexuales no blancos se muevan y voten. Yo mismo soy uno, así que sé que se puede hacer. E Eng 20:56, 10 de junio de 2021 (UTC)

Lo siento, he estado en este bloque tantas veces que no voy a invertir tiempo en leer todo lo anterior con la esperanza de que DYK realmente cambie, pero repetiré cosas que he estado diciendo durante años:

• El tropo frecuentemente repetido de que "el trabajo de DYK es resaltar nuevos artículos" está en bancarrota. En algún lugar de los primeros días de WP, alguien dijo: "Hola, niños, ¿no sería divertido si dáramos un premio por artículos nuevos? ¡Eso realmente motivaría a la gente!" Así que hicieron eso. No es del todo evidente que esto sea una buena idea, o lo que realmente necesita motivación, o qué.
• Al continuar con el fetiche del "artículo nuevo", constantemente, CONSTANTEMENTE ponemos frente a nuestros lectores nuestro contenido menos desarrollado y menos impresionante, a menudo de manera vergonzosa. Solía ​​pensar que la aparición de un nuevo artículo en DYK atraería a nuevos editores que veían la oportunidad de mejorar toda esta basura incipiente, pero puedo recordar que eso sucedió alguna vez. En cuanto a alentar y recompensar a los nuevos editores, me gustaría ver estadísticas sobre qué proporción de DYK son de principiantes; estoy bastante seguro de que es sorprendentemente pequeño.
• Deberíamos utilizar 1/4 a 1/3 de la cantidad de anzuelos, de una calidad mucho mayor: calidad del artículo y calidad del anzuelo.
  • En lugar de artículos nuevos, DYK debería ejecutar GA (solo, no artículos "nuevos" solo porque son nuevos). Imagínese si todo el esfuerzo de DYK se dirigiera a llevar artículos a GA en lugar de crear estos (en su mayoría) mediocres a casi-stubs deficientes. Si alguien dice que no obtener un crédito DYK significa que no se va a molestar en crear nuevos artículos, entonces difícil. (Me complace ver un artículo que he creado en DYK, pero esa no es la razón por la que creo artículos).
  • Por calidad de gancho me refiero a interés, y la forma de determinarlo es votando: votación despiadada de ILIKEIT / IDONTLIKEIT, ganan los cinco ganadores de votos más altos, los perdedores vuelven al barril y obtienen, digamos, tres oportunidades más de ganar el voto de un día. Argumentos como, "Bueno, lo que les interesa a los que participan en DYK podría no ser representativo de lo que les interesa a nuestros lectores" son estúpidos. Ahora mismo hacemos lo que sea que un solo editor (el nominador) considere interesante: las nominaciones nunca se rechazan porque no hay un gancho lo suficientemente interesante; casi cualquier cosa es mejor que eso. Solo podemos hacer lo mejor que podamos, y lo mejor que podemos hacer es decidir entre nosotros qué servirá mejor a nuestros lectores. Eso es lo que hacemos en cada decisión editorial que tomamos; en la mayoría de los casos es por discusión razonada y consenso, pero el interés del gancho es un presentimiento, así que para eso es mejor votar directamente.

E Eng 02:57, 8 de junio de 2021 (UTC)

Como le dije muchas veces antes de EEng , la adopción de su propuesta (a) agregaría una gran cantidad de gastos generales al proceso, (b) significaría que se presentan muchos menos ganchos, por lo que hay menos contenido nuevo para que los lectores interactúen. en la página principal a diario, (c) privar de derechos a la mayoría de los contribuyentes DYK, y (d) con toda probabilidad, conducir en el mejor de los casos a una mejora marginal general en la calidad del anzuelo. Simplemente no es viable en mi opinión. Gatoclass ( charla ) 03:54, 8 de junio de 2021 (UTC)

• agregue una gran cantidad de gastos generales  : no, votar es rápido y fácil. Y las revisiones y demás se llevarán a cabo solo en los artículos cuyos ganchos ganen la votación (1/3 del número de ganchos que se están ejecutando ahora), por lo que obviamente eso es un ahorro neto gigantesco en el trabajo.
• aparecen muchos menos ganchos  : esa es la idea.
• menos contenido nuevo  : esa también es la idea: ya no es contenido nuevo, sino contenido de calidad razonablemente buena, es decir, GA.
• privar de sus derechos a la mayoría de los contribuyentes de DYK  - No, todos pueden votar.
• mejora general marginal  : 1/3 de los ganchos, extraídos de GA en lugar de nuevos talones aleatorios, sería una GRAN mejora.

E Eng 04:40, 8 de junio de 2021 (UTC)

En primer lugar, cuando dije "privación de derechos", me refería al número reducido de usuarios que de hecho conseguirían que sus artículos aparecieran en la página principal de su sistema. A nadie le importa la cantidad de veces que pueden votar las nominaciones de otra persona. En segundo lugar, la idea de que limitar las nominaciones de DYK a los GA mejoraría de alguna manera el estándar general de los ganchos de DYK es una fantasía. El sentido común por sí solo debería decirle que reducir el número total de nominaciones reduciría correspondientemente el grupo total de anzuelos y, por lo tanto, el estándar general de anzuelos. No existe correlación entre el tamaño o la calidad de un artículo y la calidad de su gancho asociado. Gatoclass ( charla ) 05:10, 8 de junio de 2021 (UTC)

• número reducido de usuarios que de hecho conseguirían que sus artículos aparecieran en la página principal  . ¿Y qué? Estas no son las Olimpiadas Especiales, donde todos reciben un trofeo. El trabajo de menos editores debería estar en la página principal porque relativamente pocos trabajos de editores son dignos de la página principal.
• Reducir el número total de nominaciones reduciría correspondientemente el grupo total de ganchos  . Claro, pero de ese grupo más pequeño sacaremos proporcionalmente menos ganchos (o, idealmente, más que proporcionalmente menos). Los GA contienen más información que nuestros candidatos DYK actuales (nuevos artículos), por lo que contienen más material de gancho potencial.
• Mejorar el estándar general de los ganchos DYK  . Debería haber tenido más claro que el objetivo es mejorar la calidad tanto de los ganchos (lo que significa su interés) como de los artículos que el lector ve cuando hace clic.

Realmente hay tres propuestas independientes aquí: ejecutar menos anzuelos, para que pueda sacar lo mejor de la parte superior y dejar la escoria en el barril; utilizar la votación para determinar cuál consideramos mejor; Mejorar la calidad de los artículos ejecutados ejecutando GA en lugar de los resguardos. Estas tres propuestas pueden adoptarse, o no, de forma prácticamente independiente. E Eng 12:35, 8 de junio de 2021 (UTC)

No odio la idea de votar con ganchos, pero como 4meter4, estoy muy preocupado por el sesgo blanco y masculino en esa votación. Además, en este momento permitimos que hasta la mitad de los ganchos estén relacionados con EE. UU. Si optamos por un formato de votación, ¿vamos a terminar con el tipo de argumentos que vemos en ITN sobre eso, con votos puntiagudos que parecen estar motivados por asegurarse de que no tengamos "demasiada" cobertura de los EE. UU. ? —Valereee ( conversación ) 11:33, 10 de junio de 2021 (UTC)

• DYK no necesita una "reforma radical" tanto como para hacer cumplir una regla que ya está en vigor; los ganchos deben ser "interesantes para una amplia audiencia". Los revisores solo tienen que ponerse firmes y negarse a aprobar los hooks que no cumplan con este criterio, del mismo modo que rechazarían los hooks que no estén verificados o tomados de los stubs. - Tera tix ₵ 09:30, 8 de junio de 2021 (UTC)

Bastante esto. Si bien DYK es subjetivo, hay una línea entre un gancho que llamaría la atención incluso de personas que no están familiarizadas con el tema y uno que solo atrae a un pequeño nicho. No es raro que suceda que se haya aprobado un gancho porque el revisor no tuvo el impulso de rechazar lo que claramente era un gancho inadecuado, y tal vez abordar esto ayudaría a abordar las quejas sobre DYK. En cuanto a las preocupaciones anteriores acerca de que DYK tiene ciertos sesgos, eso tiene más que ver con la composición de los clientes habituales de DYK que con la estructura de DYK en sí. Recuerde que DYK es un esfuerzo voluntario, no es obligatorio, por lo que los artículos presentados están a merced de los editores que nominan. Y aunque yo apoyaría absolutamente una representación más amplia de artículos sobre DYK, bajar nuestros estándares probablemente no sea el camino a seguir, pero tal vez haya otras formas de alentar las contribuciones externas. Narutolovehinata5 ^{t c csd nuevo} 10:26, 8 de junio de 2021 (UTC)

He rechazado ganchos que me parecían aburridos, tanto como revisor directo como mientras escaneaba la lista aprobada. Sin embargo, es muy difícil establecer algún tipo de estándar exigible para que los revisores rindan cuentas. Nunca ha habido un acuerdo entre los clientes habituales de DYK sobre qué hace que un gancho sea interesante, y todos los ganchos pasan por al menos 3 puertas, por lo que presumiblemente alguien en algún lugar de la cadena los encontró interesantes. CMD ( charla ) 10:37, 8 de junio de 2021 (UTC)

Sin embargo, se anima a las personas a revisar las nominaciones más antiguas o promover las nominaciones aceptadas más antiguas. Tendríamos que dejar de hacer eso para fortalecer cualquier efecto de control y simplemente descartar cualquier cosa que no haya tenido acción en un mes. Actualmente, creo que cualquiera que tenga un artículo que cumpla con las reglas puede esperar más o menos que llegue a la página principal en algún momento. - Kusma ( conversación ) 12:49, 8 de junio de 2021 (UTC)

En mi experiencia, las nominaciones más antiguas suelen tardar más porque son controvertidas o complicadas, no porque sean especialmente aburridas. {{u | Sdkb }}   ^charla 16:06, 8 de junio de 2021 (UTC)

Aunque esta publicación es en parte una respuesta a EEng , la pondré aquí ya que la discusión ha avanzado un poco.

El primer punto a destacar es que es una fantasía imaginar que uno va a obtener una calidad sustancialmente más alta de ganchos al tener! Votos en cada nominación. Aparte de la pura impracticabilidad de intentar hacer eso dada la cantidad de nominaciones, en realidad hay muy pocos ganchos realmente destacados. EEng habla de reducir la cantidad de ganchos destacados a un tercio o una cuarta parte del número actual, pero uno de cada tres o uno de cada cuatro ganchos no es notablemente mejor que el resto. Si miras cualquiera de las páginas de nominaciones en un día determinado, es posible que encuentres 5 o 6 ganchos destacados de un centenar o más, si tienes suerte. Eso es más como reducir el número de ganchos destacados a uno de cada 20 o menos. Esto no significa que la gran mayoría de los anzuelos no estén a la altura, solo significa que no obtendrá los anzuelos de Ripley's Believe-It-or-Not- level sin una poda de nominación realmente radical, y probablemente ni siquiera entonces.

El problema, entonces, como yo lo veo, no es tanto una reducción radical, ya que la mayoría de los anzuelos son de un estándar aceptable, sino más bien cómo eliminar ese número relativamente pequeño de anzuelos que no cumplen con el estándar. Seguramente sería considerablemente más fácil crear un proceso para hacer eso que tratar de evaluar cada nominación por consenso. Se podría, por ejemplo, tener un régimen en el que cualquier usuario pueda marcar un gancho como deficiente. Entonces habría algún tipo de proceso para tratar de mejorar el gancho o reemplazarlo, y tal vez un pequeño panel permanente para emitir un juicio final. Seguramente sería mucho más simple que algunas de las alternativas propuestas anteriormente. Sin embargo, en última instancia, no hay sustituto para el compromiso. Si cree que un gancho no está a la altura, modifíquelo, proponga una alternativa o inicie una discusión al respecto. Un gancho de mala calidad solo puede llegar a la página principal porque nadie en el camino consideró oportuno desafiarlo. Gatoclass ( charla ) 13:51, 8 de junio de 2021 (UTC)

• ! vota en cada nominación  : no propongo una votación por separado para cada nominación. Propongo que a cada nominador se le ocurra el mejor gancho que pueda para el artículo que está nominando; todos estos van a una piscina. Cada día, se seleccionan al azar 20 ganchos de este grupo y se enumeran, y todos pueden votar por los 10 que creen que son más interesantes. Los 6 votantes pasan a la siguiente etapa, para revisión; los siguientes 6 vuelven al grupo para ser votados en otro día (cada gancho tiene, digamos, tres oportunidades); los 7 inferiores se caen. Fácil y completamente automatizado excepto por los 60 segundos que cada votante dedica a marcar su 10 favorito.
  Hay todo tipo de formas de modificar la fórmula de votación exacta, por supuesto. Por ejemplo, si su gancho falla, tal vez pueda enviar hasta dos ganchos más para el mismo artículo antes de que el artículo deje de publicarse permanentemente.
  Tenga en cuenta que ningún esfuerzo de revisión entra en una nominación hasta que su gancho pasa esta etapa de votación inicial, por lo que allí mismo hay una tremenda reducción en el trabajo.
• algún tipo de proceso  - algún tipo de saludo con la mano. Le expliqué mi proceso. ¿Lo que es tuyo?
• un pequeño panel permanente para emitir un juicio final  - ¡Gran idea! Eso definitivamente evitaría sospechas de parcialidad porque tal panel representaría inherentemente una amplia gama de gustos y opiniones, a diferencia de mi sistema donde todos votan.

Paginación Wugapodes por lo que puede decir lo emocionado que estaría al código de la maquinaria de votación. E Eng 14:20, 8 de junio de 2021 (UTC)

Le expliqué mi proceso. ¿Lo que es tuyo?  - Bueno, no, has explicado los aspectos básicos de un proceso, que en mi opinión es poco más que mi "saludo". Clasificar los detalles de dicho proceso sería una tarea importante. Aparte de lo cual, por supuesto, se encuentra en la difícil posición de intentar persuadir a la comunidad DYK para que adopte un sistema que reduciría radicalmente la cantidad de contenido que llega a la página principal. Gatoclass ( charla ) 14:45, 8 de junio de 2021 (UTC)

• Clasificar los detalles de dicho proceso sería una empresa importante  . Claro, pero es un trabajo de una sola vez; después de eso, llevar a cabo el proceso, día a día, es bastante fácil, y eso es lo que cuenta.
• tratando de persuadir a la comunidad de DYK para que adopte un sistema que reduciría radicalmente la cantidad de contenido que llega a la página principal  . Y ahí tenemos, de hecho, lo que ha bloqueado la reforma de DYK durante años y años y años. "La comunidad DYK" (es decir, los habituales que dominan el proceso y envían la mayoría de las nominaciones, no los míticos "nuevos editores" que pretendemos están motivados por DYK) tienen sus egos atados al ver sus cosas en la página principal.

E Eng 16:36, 8 de junio de 2021 (UTC)

Bueno, no sé si se trata de "ego" EEng , pero ya sea que un miembro de la comunidad DYK sea nuevo o viejo, es probable que ninguno de ellos esté interesado en ver menos promoción de su trabajo. Pero hemos tenido tantos colaboradores a lo largo de los años, a veces me pregunto si no sería más exacto decir simplemente "Wikipedistas" en lugar de "Comunidad DYK". Gatoclass ( charla ) 17:04, 8 de junio de 2021 (UTC)

Lo siento muy tarde. Tenías razón cuando dijiste "comunidad DYK", aquellos con una inversión en el proceso actual que proporciona la creciente línea de pequeños íconos en sus páginas de usuario. Es ego. E Eng 17:11, 8 de junio de 2021 (UTC)

"Ego" es una palabra muy fungible que puede significar casi cualquier cosa dependiendo del contexto. El tuyo parece estar en la línea de tener una gran cabeza o imaginarse a uno mismo como especial. No puedo hablar por los demás, pero en las cada vez más raras ocasiones en las que he estado en posición de nominar un nuevo artículo para DYK, la recompensa para mí siempre ha sido que algunas personas hagan clic en mi artículo y, con suerte, lo aprecien. el arduo trabajo que implicaba. Así que yo diría que se trata de obtener un pequeño reconocimiento por las contribuciones de uno; creo que hay muy pocos de nosotros que podamos arreglárnoslas sin ninguna; es solo un impulso humano bastante básico. Gatoclass ( charla ) 17:31, 8 de junio de 2021 (UTC)

(Gc, sé que nos gustamos, así que no te importará cuando digo que necesitas buscar la palabra fungible ). En pocas palabras , lo dijiste, no hay forma de evitarlo: la reforma de DYK está bloqueada por aquellos que no toleraré nada que pueda reducir la cantidad de contenido que llega a la página principal . E Eng 18:59, 8 de junio de 2021 (UTC)

No creo que se pueda considerar que toda la comunidad de Wikipedia esté involucrada en el proceso ¿Sabías que ...? Incluso mirando a aquellos que crearon / expandieron los artículos con elementos DYK asociados: escribí uno de esos artículos; Solo supe sobre el artículo DYK cuando recibí una publicación en mi página de discusión sobre él el día en que apareció. No tuve (y todavía tengo) ninguna participación en el proceso. Diré que con respecto al ego, fue una grata sorpresa ver que el artículo atrajo la atención de alguien. Creo que ese sería un buen objetivo para DYK: esforzarse por reconocer algunos artículos creados / expandidos por editores que nunca antes han tenido un elemento DYK asociado. isaacl ( charla ) 18:10, 8 de junio de 2021 (UTC)

@ Isaacl , a mí también me gustaría. Cuando veo buenas páginas de nuevos editores con datos interesantes mientras patrullo, a veces los animo a ir a DYK. Pero debido al mal diseño , el proceso suele ser demasiado intimidante para que lo hagan por sí mismos. Eso significa que tengo que co-nominar con ellos. Y cuando recientemente busqué aclaraciones sobre si las QPQ son necesarias para las nominaciones conjuntas, la mayoría de los editores parecían sentir que sí. Decisiones como esa son las que me hacen sentir más desesperado por DYK: no solo estamos desincentivando activamente el tipo de nominaciones que más necesitamos, estamos tan absortos en nuestros propios procesos que no nos damos cuenta de la magnitud del problema que tenemos. (ver también: todos los comentarios aquí en la línea de "todo es subjetivo, así que no existen los anzuelos aburridos"). {{u | Sdkb }}   ^charla 18:50, 8 de junio de 2021 (UTC)

Amén hermano. E Eng 19:09, 8 de junio de 2021 (UTC)

Creo que sería bueno nominar únicamente un artículo que haya sido creado o ampliado por otro editor, sin acercarme a ellos para pedirles que nominen el artículo o hagan una nominación conjunta, ya que esto mejoraría la naturaleza fortuita del evento. En lugar de utilizar la zanahoria de "nominación sin costo de una revisión obligatoria", sugiero establecer una cuota objetivo durante un período de tiempo (semana, mes, año). Puede que no se logre, pero establecerá un objetivo por el que luchar. (No me gusta particularmente el concepto de revisiones quid pro quo, pero como no estoy familiarizado con la cultura del proceso DYK y los participantes, no tengo ninguna sugerencia sobre qué más se podría hacer). Isaacl ( hablar ) 19:38, 8 de junio de 2021 (UTC)

Si queremos menos de la negatividad involucrada en "ese gancho apesta", tal vez alentar a la gente a publicar ganchos adicionales para algunos puntos de wikibrownie (créditos de nominación o lo que sea) también podría ayudar. Básicamente, anima a {{ sofixit }} por los ganchos aburridos. - Kusma ( charla ) 14:07, 8 de junio de 2021 (UTC)

Un problema con esto es que no es raro que el nominador se queje de los ganchos escritos o modificados por otros editores, y aunque a veces son por razones legítimas, otras veces se siente más como un caso de "No me gusta". . Narutolovehinata5 ^{t c csd nuevo} 14:17, 8 de junio de 2021 (UTC)

Yo no he hecho muchas nominaciones para DYK (ver un comentario que haré más adelante sobre el motivo), pero los pocos que hice, agradecí los comentarios. Mis habilidades son más adecuadas para la redacción técnica (estados financieros, procedimientos operativos estándar, manuales de proceso, cosas realmente emocionantes) y, francamente, apesto en la escritura creativa, y cada gancho que he escrito ha sido modificado por un revisor. Sin embargo, entiendo por qué un editor diferente podría adjuntarse al gancho exacto que escribieron. ¿Quizás si se dejara más claro desde el principio que los ganchos podrían modificarse antes de salir en vivo, salvaría algo de ese drama? Ardilla de Ivanvector ( ^árboles / _nueces ) 15:23, 8 de junio de 2021 (UTC)

Usted no WP: POSEE su gancho DYK más de lo que posee cualquiera de sus páginas creadas. Escuchar al creador de nom / page es importante porque es el que mejor conoce el tema y el contexto, pero es muy poco común permitirle que hable demasiado sobre el gancho. - Kusma ( conversación ) 16:24, 8 de junio de 2021 (UTC)

Tal vez sea bastante incoherente, pero sucede y es una posición complicada colocar a un revisor. Es bastante fácil decir que un revisor debe ser duro y rechazar el DYK, pero es una decisión que invariablemente generará conflictos con esos nominadores. lo cual no es agradable. CMD ( charla ) 02:30, 9 de junio de 2021 (UTC)

Estoy totalmente en desacuerdo con la premisa de que DYK está fundamentalmente roto, pero ciertamente hay oportunidades de mejora. Estoy de acuerdo en gran medida con Andrew Davidson (no le digas que dije eso) acerca de que DYK es habitualmente el más interesante de todo el contenido destacado en la página principal, y también estoy de acuerdo con los editores que han dicho que "interesante" es subjetivo, y una mala razón para revisar completamente el proceso. Es probable que cada uno de los ganchos visibles en un momento dado sea "interesante" para algunos lectores, mientras que otros visibles al mismo tiempo no lo son, y algunos lectores no estarán interesados ​​en ninguno de ellos, pero DYK rota con la frecuencia suficiente para que yo no No veo por qué esto debería ser una preocupación. Para mí, modificar los criterios para DYK sería más útil. No nomino muchos artículos para DYK porque el tipo de escritura que hago tiende a no encajar en ninguno de los criterios. Aparte de las promociones de GA, DYK recompensa el volumen, no la calidad. Realmente no me gustan los criterios 5x para las expansiones de artículos: ¿qué pasa con los artículos que ya son bastante grandes? Por ejemplo, he participado recientemente en un esfuerzo amplio para incluir la historia indígena en artículos sobre ciudades canadienses, donde a menudo no hay información alguna o solo una mención muy breve. Este es el tipo de información que haría buenos ganchos de DYK, pero no hay forma de que amplíe esos artículos cinco veces con esa información. Si queremos que DYK recompense la mejora del artículo , en lugar de recompensar la creación masiva de talones, entonces ese criterio debe ajustarse. Ardilla de Ivanvector ( ^árboles / _nueces ) 15:48, 8 de junio de 2021 (UTC)

Por lo tanto, mi propuesta de eliminar los criterios nuevos / ampliados y ejecutar solo GA. Haz que la gente se concentre en eso . Hay un enorme atraso en GA esperando a ser abordado. E Eng 19:07, 8 de junio de 2021 (UTC)

No creo que limitar DYK a solo los noms de GA haría algo para mejorar la calidad de los noms de DYK, ni para ayudar a la acumulación de GA. Solo conduciría a más nominaciones de GA de mala calidad y evitaría que los revisores promocionen contenido realmente bueno. Mi punto fue que los criterios actuales dejan a DYK una gran brecha entre 1) la creación de una nueva y rechoncha escoria, y 2) hacer el trabajo necesario para promover un buen artículo. Si queremos que DYK promueva mejoras incrementales en el contenido (tal vez no lo hagamos, idk), entonces debe haber un término medio. O, si solo queremos que DYK sea una lista de buenos artículos promocionados recientemente, simplemente dejemos de lado la pretensión de "ganchos interesantes" y haga que un robot complete automáticamente una lista plana de nuevos títulos de buenos artículos en su lugar. Eso liberaría a los revisores de DYK para revisar los GA en su lugar. Ivanvector ( ^Talk / _ediciones ) 21:18 8 de junio 2021 (UTC)

Tus preocupaciones son todas válidas. Pero al menos el esfuerzo de DYK se dedicaría a algo duradero, es decir, GA, en lugar de las revisiones actuales de DYK, esencialmente sin sentido, que son un callejón sin salida. Pero en este punto, he gastado mi cuota anual de esfuerzo en defensa de la reforma DYK. E Eng 23:03, 8 de junio de 2021 (UTC)

Gatoclass, creo que sus cálculos aquí están un poco fuera de lugar, ya que ignoran la probabilidad de que eliminar el requisito de la nueva página haría que las nominaciones de ganchos fueran mucho más interesantes. Comenzaríamos a obtener nominaciones porque alguien se encontró con un hecho interesante mientras navegaba, en lugar de que escribiera una página que desea promocionar. {{u | Sdkb }}   ^charla 16:10, 8 de junio de 2021 (UTC)

Suena como si estuvieras imaginando un DYK que anima a leer (para encontrar hechos interesantes), no a escribir (para agregar esos hechos interesantes). - Kusma ( conversación ) 16:31, 8 de junio de 2021 (UTC)

Quizás, pero ahora mismo tenemos hechos tibios en artículos "nuevos" de mierda. Aquí tienes una idea: requiere que el hecho sea ​​nuevo. Pero sigo diciendo que deberíamos desviar todo este trabajo de revisión a revisiones de GA, ejecutando solo GA. E Eng 16:39, 8 de junio de 2021 (UTC)

A veces me pregunto si alguien en el proceso DYK no leer los artículos en cuestión. A menudo he visto ganchos en la página principal que eran deslumbrantemente obvios ("DYK ... ¿este pez vive en el agua?" Tipo cosas), pero cuando hago clic en el artículo, hay algo asombroso, espectacular y alucinante. rogando ser usado. - Khajidha ( conversación ) 16:47, 8 de junio de 2021 (UTC)

Ciertamente, es cierto que algunas personas no parecen ser muy buenas para identificar un buen material de gancho en sus propios artículos. Pero eres perfectamente bienvenido a proponer anzuelos alternativos cuando los encuentres Khajidha . Gatoclass ( charla ) 16:54, 8 de junio de 2021 (UTC)

Y yo tengo. Ambos completan ganchos alternativos y una redacción mejorada (gramática, tono, flujo) de los ganchos existentes. Pero no tengo tiempo para concentrarme en el proyecto, por lo que mis contribuciones son bastante menores. Alguien de arriba lo dijo antes, parece haber una renuencia a llamar a las cosas por su nombre y decirle al nominador rotundamente "que el gancho es completamente aburrido y no se le permitirá correr, necesita encontrar algo mejor en el artículo. ¿Ha considerado ? "También me pregunto por qué a las personas que nominan 327 artículos prácticamente idénticos sobre mariposas / hongos / estaciones de ferrocarril / etc.no se les dice que solo pueden elegir UNO, los demás no se utilizarán. - Khajidha ( conversación ) 17:07, 8 de junio de 2021 (UTC)

Es posible que haya querido decir "327" como una exageración, pero en realidad tuvimos 314 nominaciones en arroyos y arroyos en Pensilvania [28] , algunos de los anzuelos (y artículos) más asombrosamente aburridos de la historia. Mi intento de sugerir que tal vez los lectores podrían haber estado recibiendo sólo un teensy poco cansado de todo lo que dreck fue abucheado. E Eng 17:19, 8 de junio de 2021 (UTC)

En realidad, no es una exageración, ya me había encontrado con ejemplos antes. - Khajidha ( conversación ) 18:18, 8 de junio de 2021 (UTC)

( editar conflicto ) Oh diablos, no, me opondría totalmente a un modelo que elimina el requisito de contenido nuevo y lo sustituye con "aquí hay un hecho interesante que encontré en algún lugar de la Wiki". También creo que tendría absolutamente ninguna posibilidad de ser adoptado, ya que probablemente no haya un solo colaborador de DYK que esté de acuerdo. Gatoclass ( charla ) 16:48, 8 de junio de 2021 (UTC)

¿Por qué? ¿Cuál es el valor de presentar contenido nuevo, específicamente? Constantemente, constantemente dirige a nuestros lectores a nuestro peor - a menudo excesivamente mala - contenido. Lo escucho una y otra vez: "El propósito de DYK es presentar contenido nuevo, El propósito de DYK es presentar contenido nuevo, El propósito de DYK es presentar contenido nuevo", como si fuera evidente que DYK hace no tiene sentido a menos que sea cierto. Pero no lo es. E Eng 18:59, 8 de junio de 2021 (UTC)

¿Vergonzosamente malo? ¿Cómo es eso? No promocionamos artículos que no estén dentro de la política. Deben ser: 1. Notables; 2. Más de un código auxiliar (es decir, más de 1500 caracteres); 3. Completamente referenciado a fuentes confiables; 4. Neutral; 5. Libre de infracción de derechos de autor. El problema principal aquí parece ser que simplemente no le gustan los temas que se proponen, pero aún así satisfacen WP: GNG para aprobar DYK. La otra queja es el tamaño del artículo, pero no lo veo como un problema. Un mínimo de 1.500 caracteres está perfectamente bien para muchas entradas de enciclopedia. Las ediciones impresas de enciclopedias como Encyclopedia Britannica incluyen entradas de menos de 500 caracteres. Nuestro umbral de inclusión en términos de longitud es razonable. Por último, personalmente creo que la revisión de GA es una broma. Más de la mitad de las veces, los artículos de GA llegan a DYK con problemas de política que deben solucionarse (es decir, plagio, problemas de NPOV, otros problemas de abastecimiento, etc.). Nuestros revisores de DYK parecen ser más astutos al revisar artículos en busca de cuestiones de política que lo que se hace en GA. Estoy más seguro de que un artículo de DYK en la página principal está dentro de la política que un artículo con un sello de GA. 4meter4 ( conversación ) 23:49, 8 de junio de 2021 (UTC)

• El problema principal aquí parece ser que simplemente no le gustan los temas que se proponen, pero aún así satisfacen WP: GNG para aprobar DYK.  - No tengo idea de dónde diablos sacaste esa idea. Mi problema es la calidad de los artículos en sí y sus ganchos.
• "Dentro de la política" es una hoja de parra patéticamente escasa. Entre las cosas que GA requiere, pero DYK no, se encuentran que un artículo sea claro, conciso y comprensible; abordar los principales aspectos del tema; y manténgase enfocado en el tema sin entrar en detalles innecesarios. DYK no tiene tales requisitos, por lo que los artículos que presenta pueden estar mal escritos, ser confusos, lamentablemente incompletos y / o inflados y discursivos, y a menudo lo son. Por supuesto, si está diciendo que eso no es cierto, entonces el artículo de DYK ya cumple con GA y nadie debería tener ningún problema en hacer que GA sea el requisito de activación para DYK. Cual es
• No hay duda de que las reseñas de GA son a menudo de mala calidad, pero también lo son las reseñas de DYK. Lo que salva a DYK son las comprobaciones de la segunda y tercera etapa que se producen en el edificio de preparación y la promoción Q. Si GA se convierte en el requisito de activación de DYK, los GA obtendrán el mismo beneficio.

E Eng 03:10, 9 de junio de 2021 (UTC)

• Si no estuviera ya convencido de que existe una desconexión entre lo que los editores habituales de Wikipedia consideran interesante y lo que hace la gente normal ( es decir, los lectores), entonces esta discusión me habría convencido de ello. Creo que muchos de los comentarios anteriores, incluidos los de los editores con los que suelo estar de acuerdo, son simplemente increíbles. La sección se llama "Sabías que ...", no "Datos aburridos que hemos decidido poner en la página principal para impulsar el ego de algunos editores". Phil Bridger ( charla ) 18:04, 8 de junio de 2021 (UTC)

  Pero, lamentablemente, no existe una regulación de veracidad en la publicidad para las funciones de la página principal de Wikipedia. E Eng 18:59, 8 de junio de 2021 (UTC)

DYK tiene múltiples objetivos , no solo uno, nunca se ha tratado únicamente de resaltar hechos interesantes. Con respecto a mis comentarios anteriores sobre cómo es probable que los colaboradores de DYK reciban ciertas propuestas aquí, no estoy haciendo juicios de valor sobre esas respuestas, simplemente estoy tratando de inyectar una nota de realismo en la discusión. No tiene mucho sentido presentar propuestas de reforma radical que casi con seguridad fracasarán. Gatoclass ( charla ) 01:30, 9 de junio de 2021 (UTC)

• Una cosa que debe tenerse en cuenta aquí es que proponer que DYK se limite a los GA se ha planteado en el pasado, pero nunca ha ganado fuerza. Hay algunas razones suficientemente buenas para eso, y dudo mucho que hacer esto resuelva las quejas que otros han tenido sobre DYK (como ganchos aburridos o sesgos). De hecho, diría que limitar los DYK a los nuevos GA empeoraría el problema del sesgo, porque llevar un artículo a GA ya es difícil y, por lo tanto, es más común entre temas más especializados o temas anglocéntricos. Al menos con los requisitos actuales, la barrera de entrada para las regiones pasadas por alto es baja, por lo que tienen muchas posibilidades de aparecer. Y además, no todos los GA tienen información valiosa en primer lugar, sin importar cuánto tiempo sean. Una cosa que incluso los clientes habituales de DYK tienden a olvidar es que no todos los artículos están destinados a DYK, especialmente cuando el material simplemente no está allí, por lo que hay otras formas de resolver el problema de los ganchos aburridos sin la necesidad de un uso tan radical y radical. idea defectuosa. Personalmente, sigo pensando que algunos de los editores anteriores, como Kusma y CMD, tienen un punto de que los clientes habituales deberían estar más dispuestos a rechazar los ganchos e incluso los artículos si simplemente no son adecuados, y aunque los deseos de los nominadores pueden tenerse en cuenta, deberían no es un dogma y no se puede seguir si es para bien, dado que los nominadores no son dueños de sus nominaciones ni de sus ganchos. Narutolovehinata5 ^{t c csd nuevo} 05:34, 9 de junio de 2021 (UTC)
• Yo apoyaría una propuesta de reforma radical en la línea discutida anteriormente, generalmente cambiando el propósito de DYK de centrado en el editor ("fomentar nuevos artículos") a centrado en el lector (artículos interesantes y de alta calidad). Reducir el número de DYK publicados es un buen primer paso, al menos una vez cada 24 horas en lugar de 12 (la mitad del mundo nunca ve la mitad de los anzuelos con una rotación de 12 horas). El requisito de solo GA es otra idea interesante, aunque Ivan tiene algunos puntos positivos sobre la preocupación de que esto inunde a GA con noms de baja calidad. Otra idea: limitar el número total de DYK que cualquier editor puede enviar en un período de tiempo particular (por mes, por año), lo que detendrá o ralentizará algunos de los ganchos repetitivos de temas estrechos que vemos. En términos generales, DYK debe reformarse para reducir el volumen y aumentar la calidad. Levivich 14:47, 9 de junio de 2021 (UTC)

  Tener un límite numérico en la cantidad de nominaciones que un editor puede hacer suena a instrucción lenta y, honestamente, suena injusto. Narutolovehinata5 ^{t c csd nuevo} 15:04, 9 de junio de 2021 (UTC)

  No entiendo qué tienen que ver WP: CREEP o la justicia con esto. Levivich 15:07, 9 de junio de 2021 (UTC)

  No hay nada de malo en la calidad de los artículos DYK. La mayoría de ellos están bien presentados, son atractivos y están razonablemente bien redactados. Solo mirando los sets de ayer, la mayoría de ambos parecen ser de calidad GA y probablemente se dirigieron en esa dirección. Algunos de ellos son probablemente demasiado cortos para GA, y eso está bien, no todos los artículos sobre todos los temas tienen que ser sustanciales, y una combinación de artículos largos y cortos agrega variedad y atrae a diferentes lectores. Demasiados artículos en Wikipeda, incluidos GA y FA, ​​son artículos de estilo "fregadero" que desalientan la participación. Aparte de la longitud, el DYK y GA típicos serían indistinguibles para el lector promedio de todos modos, solo los wikipedistas notarían, por ejemplo, los puntos más finos del cumplimiento de MOS. Y no habría ningún beneficio en reducir a la mitad el número total de DYK. Gatoclass ( charla ) 16:33, 9 de junio de 2021 (UTC)

  Creo que todos podemos estar de acuerdo en que tal vez la mitad de los DYK están "bien presentados, atractivos y razonablemente bien escritos". (Supongo que tú piensas que es más.) De lo que estamos hablando es de cómo deshacernos de la otra mitad. E Eng 16:40, 9 de junio de 2021 (UTC)

  No tienen nada que ver con eso, por supuesto. E Eng 16:37, 9 de junio de 2021 (UTC)

• Lo que me gusta: Restaurar una breve línea que da contexto a la sección DYK. Hacer un esfuerzo para hacer que los anzuelos sean más consistentemente "enganchados" (pero no necesariamente divertidos o sensacionales). Creo que en el proceso de revisión, y en la asamblea de preparación, sería razonable insistir más en que el gancho sea claramente interesante o tentador para leer más sobre él, incluso si eso significa que algunas nominaciones terminan fallando. Aún así, estoy de acuerdo con algunos otros editores en que DYK es a menudo la parte más interesante de la página principal. Lo que no me gusta: instituir algún tipo de proceso de votación o cambiar el tipo de páginas que son elegibles para DYK. - Tryptofish ( charla ) 20:52, 9 de junio de 2021 (UTC)

  Tu madre usa botas militares. {{Datos del país {{{1}}}

| flaglink / core | variante = | tamaño = | nombre = | altlink = equipo nacional de fútbol B | altvar = fútbol | class = B}} Bueno, ¿podrías aceptar los dos principios siguientes? E Eng 22:04, 9 de junio de 2021 (UTC)

Para aquellos que juegan en casa, Old Army Boots ( por cierto, deberían ver lo que llevo puesto), intentaron poner {{fbdb}}allí, pero solo pusieron "fbb", pobre amigo. Pero de todos modos, ya lo comenté a continuación. (Alerta de spoiler: No.) - Tryptofish ( charla ) 22:13, 9 de junio de 2021 (UTC)

Quise hacer eso . 😜 E Eng 23:47, 9 de junio de 2021 (UTC)

Dos propuestas concretas, hazlo o muere (en mi humilde opinión)

Ahora afirmaré:

• Principio 1 de la reforma DYK: La calidad DYK (de ganchos, de artículos) requiereuna reducción sustancial del volumen, es decir, no más de la mitad del volumen actual, y muy posiblemente 1/3 o incluso menos [modificado a las 22:08, 9 de junio de 2021 (UTC)] algún tipo de reducción en el número de anzuelos presentados por día.
• Principio de reforma de DYK 2: Un límite de X DYK en cualquier Y meses, por editor, es suficiente. (No estoy seguro de si X cuenta las nominaciones hechas, o los créditos de autoría / expansión, o la suma, o qué; y X e Y quedan por determinar).

Si podemos conseguir que se promulguen estos dos principios, entonces podemos estar en camino hacia una reforma real de DYK, porque marcará el fin de la tiranía de aquellos que claman que de alguna manera es injusto reducir la cantidad de su contenido que llega a la página principal (ver más arriba en este hilo); nos obligará a encontrar formas de tomar decisiones sobre las características de DYK, en lugar de que esencialmente todo lo nominado sea bombeado por la tubería de lodos sin importar qué. Si no es así, nunca habrá reforma.

Nominaciones de DYK en trámite

E Eng 16:37, 9 de junio de 2021 (UTC)

@ EEng : Si está buscando! Votos sobre estos, es posible que desee mudarse a VPR u otro lugar donde eso pueda suceder. {{u | Sdkb }}   ^charla 16:43, 9 de junio de 2021 (UTC)

No, solo hablo de eso por ahora. E Eng 17:02, 9 de junio de 2021 (UTC)

Entonces el ¿Dos propuestas concretas no son propuestas concretas? :-) De todos modos, me han advertido que si escribo "Estoy de acuerdo con EEng" una vez más, van a crear un nuevo filtro de edición. Levivich 17:28, 9 de junio de 2021 (UTC)

También reiteraré que me encantaría que alguien hiciera una propuesta concreta para recuperar el mensaje "del contenido más nuevo de Wikipedia". No creo que esa persona deba ser yo dada mi reputación por esto, pero lo apoyaría y, francamente, creo que tiene muchas más posibilidades de aprobarse que cualquiera de las ideas anteriores. {{u | Sdkb }}   ^charla 16:55, 9 de junio de 2021 (UTC)

Excepto que volvería a grabar en piedra probablemente lo peor de DYK: su fetiche del "nuevo contenido". Sin embargo, si quisiera decir: "De los nuevos artículos que se han juntado a toda prisa para cumplir con el arbitrario e inexplicable plazo de 7 días de DYK", estaría de acuerdo con eso. E Eng 17:02, 9 de junio de 2021 (UTC)

El plazo de 7 días me anima a iniciar todos los posibles candidatos DYK en el espacio de usuario para tener tiempo para completarlos. Un plazo más corto funcionaría aún mejor. Admito que es un poco extraño tener un límite de 7 días hasta la nominación seguido de una espera de 1 a 100 días hasta que el artículo llegue a la página principal. - Kusma ( conversación ) 17:59, 9 de junio de 2021 (UTC)

iniciar todos los posibles candidatos DYK en el espacio de usuario para tener tiempo de completarlos  , derrotando así uno de los principios más apreciados de WP, el trabajo colaborativo. E Eng 20:47, 9 de junio de 2021 (UTC)

Aumentamos la fecha límite porque la gente se quejó de que la fecha límite era demasiado corta. La C de E ¡ Dios salve a la reina! ( charla ) 20:23, 9 de junio de 2021 (UTC)

Recuerdo varias discusiones sobre el aumento de los días para nominar, y la objeción más común fue: "¡Pero entonces tendríamos demasiadas nominaciones! ¡Tendríamos que presentar cuatro sets por día!" En otras palabras, la fecha límite ajustada es una forma arbitraria de limitar la entrada al sistema DYK, que no tiene una forma racional, de hecho, no intenta, elegir entre las presentaciones. Por su absoluta arbitrariedad e irracionalidad, el plazo de siete días es quizás el aspecto más ridículo del sistema DYK (y eso es decir mucho). E Eng 20:47, 9 de junio de 2021 (UTC)

No sigo tu lógica. ¿Cuál es el objetivo y por qué ayudan estas cosas? Entiendo el principio "dejar de garantizar una apariencia de página principal para artículos que cumplen con las reglas con ganchos aburridos", pero ¿por qué elegir entre 30 artículos aburridos es mejor que elegir entre 300 artículos aburridos? - Kusma ( charla ) 18:09, 9 de junio de 2021 (UTC)

¿Por qué elegir entre 30 artículos aburridos es mejor que elegir entre 300 artículos aburridos  ? Elegir entre 30 artículos aburridos no es lo que se propone. Lo que se propone es elegir 30 (o más probablemente 100) artículos de 300 artículos. Los 300 van desde aburridos / mal escritos hasta fascinantes / bien escritos, por lo que al tomar solo los mejores 100 probablemente obtendrá un grupo bastante bueno, y ciertamente mejor, en promedio, que el promedio de los 300 (que es lo que presentamos ahora ). E Eng 20:47, 9 de junio de 2021 (UTC)

Comentar . Reducir el número de envíos por editor no garantiza necesariamente una mejora general. De hecho, lo contrario puede ser cierto. Los editores que contribuyen con regularidad suelen ser más hábiles en la elaboración de artículos y artículos más interesantes que los que no participan con frecuencia. Por lo tanto, tal limitación puede tener el efecto contrario de lo que pretendes. Además, controlar el número de nominaciones por editor será un dolor de cabeza. No veo un argumento sólido sobre cómo esto mejora la calidad de DYK. Si esto se votara en otra página, no lo apoyaría. 4meter4 ( conversación ) 19:58, 9 de junio de 2021 (UTC)

Comentar . Reducir las presentaciones por editor no es más que penalizar a los colaboradores habituales que hacen gran parte del trabajo para que DYK funcione. Ya hemos perdido (lamentablemente) a uno de nuestros principales contribuyentes a principios de este año, no necesitamos perder más. Además, no mejorará el contenido, en todo caso, es más probable que funcione / The C of E God Save the Queen! ( charla ) 20:23, 9 de junio de 2021 (UTC)

En orden: propuestas de EEng, no y no. Agregue algo a la página principal para dejar en claro que DYK no es una muestra aleatoria de artículos y está mostrando lo nuevo y mejorado, pero la redacción real es complicada: estoy de acuerdo con EEng sobre el fetiche de artículos nuevos, solo no estoy de acuerdo el grado, por lo que no admite tener un NUEVO NUEVO NUEVO hiperenfoque en la redacción. No estoy seguro de que haya surgido aquí, pero estoy de acuerdo en general con "ampliar el rango de siete días", aunque quizás un poco simbólico porque supongo que la mayoría de los habituales de DYK están trabajando en sandboxen. Profeta Vaticidal 20:26, 9 de junio de 2021 (UTC)

Podría ser bueno tener solo una rotación de DYK por día, a menos que eso cause un retraso. Quizás. De lo contrario, esto me parece agua debajo del puente. - Tryptofish ( charla ) 20:42, 9 de junio de 2021 (UTC)

Bueno, claro, causará un retraso a menos que muerdamos la bala y comencemos a rechazar las nominaciones . En este momento, ejecutamos tantas series por día como sean necesarias para sacar todo, todo lo que se presente, ya sea bueno, malo o indiferente, fuera de la puerta. Y parece que seguiremos haciéndolo, porque ya sabes, ¡son las Olimpiadas Especiales y todos reciben un trofeo! E Eng 23:50, 9 de junio de 2021 (UTC)

Creo que hay (al menos) tres objetivos diferentes asociados con la iniciativa ¿Sabías que ...?, Incluidos los siguientes:

• Anime a los editores a crear nuevos artículos o expandir los existentes.
• Destacar contenido nuevo para los lectores, lo que les da la sensación de que Wikipedia es un sitio activo y, por lo tanto, puede alentarlos a participar más en la comunidad.
• Anime a los lectores a explorar los artículos enumerando un dato interesante de ellos.

Sobre esto se superpone la prioridad que se asigna a estos objetivos. Por ejemplo, el sistema de revisión obligatorio es una consecuencia de dar una prioridad más urgente a la presentación de más elementos (es una dependencia circular: cuando hay más envíos, la gente quiere presentar más elementos; pero para presentar más elementos, es necesario más presentaciones y rendimiento).

Puede ser más fácil lograr estos objetivos por separado con diferentes iniciativas, en lugar de tratar de ampliar ¿Sabías que ... para cubrirlos todos? No importa agregar otro objetivo de destacar los artículos calificados como artículos de buena calidad . isaacl ( charla ) 20:43, 9 de junio de 2021 (UTC)

• Creo que el elefante en la sala es que a la gente no le gusta que su nominación DYK sea rechazada. Por ejemplo, estaba un poco desconcertado porque Fremlin's Brewery y LattePanda no llegaron a DYK porque tenían problemas, pero después de que dejé de quejarme al respecto uno o dos días más tarde, pensé "sí, Wikipedia no va a fallar en su cara si estos artículos no aparecen en la página principal, supérelo ". Ritchie333 ^{(charla) (continuación)} 09:51, 10 de junio de 2021 (UTC)

  En retrospectiva, tal vez DYK podría haberlo hecho sin algunos de mis nominaciones con peor desempeño. 700 , 800 , 1800 . Pero 4000 y 9000 no parecían mucho más emocionantes en el momento nominativo. No estoy seguro de si eso me dice algo. - Kusma ( charla ) 11:03, 10 de junio de 2021 (UTC)

  Creo que a veces se escucha. Algunos de mis anzuelos más mundanos tienen más vistas que anzuelos que parecen más interesantes e inusuales. No podemos presumir de saber lo que la gente querrá leer. Joseph 2302 ( charla ) 11:05, 10 de junio de 2021 (UTC)

  • Lo que encuentro extraño; mi primer nominación a DYK estaba nervioso acerca de si cumpliría con los estándares, si a la gente le gustaría los ganchos! Creo que pasó con bastante facilidad y consiguió la ranura de la imagen, y me sorprendió. Quizás las actitudes hayan cambiado y los nominadores se sientan autorizados y posesivos; aunque esto solo sale cuando hay problemas que no quieren resolver? Pero el proceso DYK también puede ayudar a los nominadores a mejorar parte de la infraestructura básica de sus artículos, incluso si no pasan la prueba. Me han rechazado nominaciones por problemas técnicos o ganchos, y no me molesta. Aún contribuí a la enciclopedia, solo nomino artículos que creo que tienen un buen gancho, por lo que no creo que los artículos "merezcan" lugares para MP. . Tengo más de 70 créditos DYK y no doy por sentado ningún nuevo nominado, y siempre agradezco las sugerencias de ganchos porque realmente creo que los ojos nuevos son mejores para aterrizar en los hechos más interesantes. Creo que todavía prevalece esa actitud. Kingsif ( charla ) 11:19, 10 de junio de 2021 (UTC)
  • Ahí es donde creo que estar más concentrado en los objetivos puede ayudar. Por ejemplo, puede haber un feed de "contenido nuevo" que sea más amplio en la aceptación de envíos, un feed de "buena lectura" que destaque artículos bien escritos y un feed de "hechos interesantes" que se centraría en artículos con buenos ganchos. isaacl ( charla ) 16:13, 10 de junio de 2021 (UTC)
• La sugerencia 2 es contraproducente en mi opinión: más presentaciones de las mismas personas generalmente conduce a que las personas produzcan mejores ganchos. Por lo tanto, creo que desalentar a los buenos editores solo empeoraría la calidad de DYK, no mejoraría. Joseph 2302 ( charla ) 11:04, 10 de junio de 2021 (UTC)
• Y no estoy del todo seguro de cómo se puede hacer cumplir la Sugerencia 1, ya que ejecutar menos ganchos solo conduciría a un retraso. Si desea reducir el número de envíos, deberá cambiar los criterios de elegibilidad (con consenso, por supuesto). Joseph 2302 ( charla ) 11:04, 10 de junio de 2021 (UTC)

  Bueno, DUH . E Eng 11:16, 10 de junio de 2021 (UTC)

  Mi punto (no muy claro) fue que debería cambiar los criterios de elegibilidad de los artículos, en lugar de limitar la cantidad de nominaciones que puede hacer un usuario. Joseph 2302 ( charla ) 11:38, 10 de junio de 2021 (UTC)

  No me estaba poniendo una gorra. Le preguntaba a la gente si podían estar de acuerdo con el principio de que se debería ejecutar mucho menos material. Si pueden estar de acuerdo con eso, entonces podemos comenzar a hablar sobre lo que hacemos con los criterios / procesos que afectarán esa reducción. Si no podemos lograr que la gente esté de acuerdo con esa idea tan simple, podemos dejar de fumar ahora mismo y ahorrar mucho tiempo. E Eng 20:15, 10 de junio de 2021 (UTC)

• Apoyaría cualquier cosa que anime a las personas que piensan que tienen que nominar todos los artículos que escriben para DYK, ya sea que puedan o no crear un gancho interesante.

La gente parece intentar aplicar ingeniería inversa. Si mientras escribes te encuentras con algo que te hace pensar: "¡Vaya! ¡Eso es tan interesante! ¡Sería un gran gancho!", Genial. Nómbrelo. Pero, en cambio, la gente parece estar pensando "Está bien, verifique, se creó el artículo. Ahora, ¿qué puedo usar para el gancho?" Entonces, realmente, todo lo que tenemos que hacer es cambiar la naturaleza humana fundamental. —Valereee ( conversación ) 12:18, 10 de junio de 2021 (UTC)

Según mi experiencia, varía. Si he creado o mejorado un artículo compatible con DYK y puedo pensar en un buen gancho, lo presentaré (a menudo mientras hago ping a EEng para obtener un mejor gancho ;-D). En otras ocasiones, como la carretera A719 , el gancho saltó hacia mí y me apresuré a intentar mejorar el artículo lo suficiente para cumplir con los otros criterios.

" Así que, en realidad, todo lo que tenemos que hacer es cambiar la naturaleza humana fundamental ". Genial, Val, ¡acabas de describir exactamente cómo podemos solucionar la RfA y muchos otros problemas! Ritchie333 ^{(charla) (continuación)} 13:20, 10 de junio de 2021 (UTC)

• Sí, esto está muy bien expresado, esa es la raíz del problema. No tengo mucha confianza en cambiar la naturaleza humana, pero un sistema diferente podría incentivar un comportamiento diferente. Ha habido muchas ocasiones en las que me he encontrado con un hecho súper interesante en una página establecida y pensé "esto sería un excelente gancho DYK si tan solo fuera elegible". No creo que sea imposible para nosotros crear una situación en la que los nominadores de DYK más activos no sean editores que promocionen su propia página, sino editores que busquen en la enciclopedia los datos más interesantes. {{u | Sdkb }}  ^charla 14:29, 10 de junio de 2021 (UTC)

Sugerencia de reforma más pequeña: dividir la revisión

Una propuesta ligeramente diferente: el aspecto técnico de la revisión se realiza normalmente y, cuando se aprueba, el gancho va a una página intermedia (entre nominaciones y nominaciones aprobadas) donde cada nominación tiene sus ganchos votados por la comunidad en general. Cuantos más ojos, mejor y, con suerte, funcionará porque el cuerpo de votantes no tiene que esforzarse mucho en la revisión. Con suerte, se descentralizará el aspecto de "el gancho es interesante" lo suficiente como para que el nominador no se ofenda con los votos de "oposición", o sienta que es solo su único crítico al que no le gusta. Y la naturaleza descentralizada, con suerte, significará que los revisores no se sientan obligados a aprobar un gancho que no consideren interesante (uno a uno, como es, puede parecer personal cuando dices que no). La versión un poco más extrema es simplemente ir a ITN completo, donde está completamente descentralizado y todos obtienen un voto sobre si cumple con las especificaciones técnicas y es interesante, pero dado lo mucho que se debe cumplir para el lado técnico de DYK, creo que eso es demasiado. de una pregunta. Entonces, una persona revisa el aspecto técnico como es normal, luego un sistema de votación; Se puede decidir alguna relación de apoyo: oponerse para que pase un gancho, y esta etapa también permitiría proponer otros ganchos alternativos. Kingsif ( charla ) 11:33, 10 de junio de 2021 (UTC)

Demasiado engorroso. La propuesta de EEng en realidad tiene más sentido que eso, y tampoco tiene suficiente sentido. Gatoclass ( charla ) 12:47, 10 de junio de 2021 (UTC)

Me preocupa mucho el sesgo de los votantes, tanto involuntario como puntiagudo. ¿Vamos a terminar con solo esos anzuelos que son interesantes para los hombres blancos? ¿Vamos a conseguir que la votación esté diseñada para asegurarnos de que no somos US-ipedia? —Valereee ( conversación ) 12:29, 10 de junio de 2021 (UTC)

Votar por ganchos individuales en realidad podría empeorar algunos prejuicios que tenemos, y es un poco torpe. ¿Quizás podríamos tener un sistema donde los artículos decentes con ganchos insuficientemente atractivos puedan ser marcados para el Escuadrón de Rescate de Ganchos? - [[Usuario: | Kusma]] ( conversación ) 12:37, 10 de junio de 2021 (UTC)

Actualmente estoy jugando con la idea de que un proceso de votación puede ser útil como respaldo , donde se cuestiona el interés de un gancho. De esa manera, no se usa para todos los ganchos (y, con suerte, no para muchos), pero proporciona un camino claro a seguir en los debates de interés y elimina parte de la personalidad de los resultados. CMD ( charla ) 12:40, 10 de junio de 2021 (UTC)

Me hago eco de las preocupaciones sobre la diversidad de ganchos. Muchos editores serán estadounidenses o británicos, y creo que eso conduciría a un sesgo inconsciente hacia los ganchos de estos países. Al igual que en WP: ITNC , donde obtenemos muchas más propuestas de artículos estadounidenses que cualquier otro país. Además, en todo caso, el proceso DYK debe simplificarse, no complicarse más. Ya es el proceso más complejo en el que se involucra un editor novato. Joseph 2302 ( charla ) 12:43, 10 de junio de 2021 (UTC)

Además, no resuelve el problema que mencioné anteriormente en alguna parte: lo que los editores pensamos que podría ser "interesante" no siempre coincide con lo que los lectores terminan decidiendo que quieren leer. Por lo tanto, podríamos excluir los ganchos como aburridos, cuando los lectores pueden haberlos encontrado interesantes, o viceversa. Joseph 2302 ( charla ) 12:50, 10 de junio de 2021 (UTC)

( editar conflicto ) Sí, estoy de acuerdo con usted y Valereee en que mantener la diversidad de ganchos probablemente sería un gran desafío en cualquier sistema basado en votos. Hay ciertos temas que son perennemente fascinantes para los seres humanos y otros que casi invariablemente no lo son. Uno se pregunta cómo les iría a los anzuelos sobre oscuras especies de esponjas marinas en un sistema de votación. ¿O ganchos sobre ópera o ballet? Somos una enciclopedia, no un tabloide, y los ganchos deben reflejar la diversidad completa de temas enciclopédicos, no solo aquellos que puedan atraer la mayor atención. Gatoclass ( charla ) 13:07, 10 de junio de 2021 (UTC)

Sigo creyendo que se puede escribir un gancho interesante sobre cualquier tema (siempre que haya algo interesante allí), los nominadores solo deben dejar de intentar forzar todo el conocimiento especializado en el gancho, interesante para ellos, aburrido para las personas que no lo hacen. No sé de esponjas / ópera / ballet. Encuentre algo universal sobre el artículo, incluso si no parece impresionante para los expertos, o mantenga el gancho del especialista lo suficientemente simple. Kingsif ( charla ) 18:17, 10 de junio de 2021 (UTC)

Creo que esto es un problema. Tenemos nominaciones que piensan que es una pena que los principales logros de la persona se vean marginados por el hecho de que hicieron algo sorprendente. Tal vez debamos discutir el hecho de que "El escritor escribió un libro" es mucho menos interesante que "El escritor aprendió a saltar en paracaídas a los 89" o lo que sea. —Valereee ( conversación ) 22:00, 10 de junio de 2021 (UTC)

Estoy muy de acuerdo con este sentimiento. Probablemente debería haber un cambio en el pensamiento de los colaboradores de DYK de que los ganchos que escriben no son para ellos, sino para un mayor número de lectores, y que los ganchos deben escribirse primero con el interés de esa audiencia, incluso si puede no ser favorable para el público. especialista. Por ejemplo, un gancho sobre un cantante de ópera que interpreta un papel puede ser de interés para los fanáticos de la ópera, pero puede ser menos interesante para el hoi polloi, mientras que si el cantante de ópera hizo algo sorprendente para un cantante de ópera (por ejemplo, si también cantó rap u otro género completamente diferente), que es más probable que capte la atención incluso de los entusiastas de la ópera. Entiendo que todos tenemos nuestros prejuicios, pero no somos dueños de nuestros artículos o ganchos y siempre debemos tener eso en cuenta. Narutolovehinata5 ^{t c csd nuevo} 01:38, 11 de junio de 2021 (UTC)

Esto es algo que he notado mucho. Y a veces el colaborador está tan cerca del tema que no ve que algo que le parece interesante (y que no necesita explicación para él) sería muy intrigante para el público en general con solo una pequeña expansión, pero resulta increíblemente aburrido. sin ello. - Khajidha ( conversación ) 11:43, 11 de junio de 2021 (UTC)

@ Valereee , Kusma , Chipmunkdavis , Joseph2302 y Gatoclass : Los promotores de la preparación parecen hacer un buen trabajo construyendo conjuntos diversos, estoy seguro de que un grupo de usuarios, ¿o quizás el revisor técnico? - podría estar revisando las nominaciones para descartar básicamente cualquier apoyo y oposición que parezca parcial (por ejemplo, "apoyar - California es genial" u "oponerse - nunca he oído hablar de Petrovic" simplemente se descartaría). Pero esto dependería de que todos dieran una razón para su voto. Kingsif ( charla ) 18:22, 10 de junio de 2021 (UTC)

No creo que eso funcione. ¿Descontar las "matemáticas apestan", pero mantener "nuestros lectores se desaniman por tener que ver matemáticas avanzadas"? Descontar "oh no, no otra estación de radio" pero mantener "las estaciones de radio sólo tienen un impacto muy local"? Si tiene que desarrollar criterios sobre qué votos lanzar, ¿no debería simplemente desarrollar mejores criterios para los ganchos? - Kusma ( charla ) 18:37, 10 de junio de 2021 (UTC)

Lo que me preocupa son votos como "Oponerse. Hay demasiados ganchos de Estados Unidos. Esto no es US-ipedia". Además, si un gran apoyo para un determinado gancho se debe a que se trata de un tema que suele ser de gran interés para los hombres blancos, y viceversa. ¿Vamos a terminar con cada gancho de footy enviado porque, duh, footy es intrínsecamente interesante, y uno sobre vestidos de sacos de alimentación bostezó debido a los datos demográficos de nuestro editor? —Valereee ( conversación ) 18:49, 10 de junio de 2021 (UTC)

Evaluación de la calidad de la página

Los editores han comentado anteriormente que puede haber un problema cuando se resalta una nueva página de mala calidad. Aparte de limitar el DYK solo a los GA, hay otras ideas que podrían valer la pena analizar. Actualmente, DYK requiere que las páginas nuevas y recientemente expandidas cumplan con las políticas básicas, cumplan con algunos estándares para citar fuentes (principalmente para el gancho) y no sean stubs, pero también dice que no se debe esperar que las páginas estén al nivel de un GA (supongo que los GA son de nivel GA, guiño, guiño). Hay espacio para algunos ajustes potenciales de los estándares.

Reconozco que hay que tener cuidado de no abrir la puerta para, en efecto, hacer que la revisión de DYK sea casi lo mismo que la revisión de GA, porque eso haría que muchas nominaciones fueran demasiado prolongadas y difíciles. El simple hecho de pedir a los revisores que confirmen que la página cumple con las políticas básicas es una barrera necesaria pero baja. También podríamos estipular que las páginas no deben tener problemas de formato notorios y tener los mismos requisitos para las citas en línea que actualmente requerimos para el gancho, en todo el texto principal. Podríamos decir que la página debe estar lo suficientemente bien escrita como para que sea comprensible para cualquier lector que acceda a ella desde la página principal. Quizás requiera más de una o dos fuentes. Yo pensaría en ello como establecer el listón un poco más alto que la clase Start, pero más bajo que GA. También más como "el mejor contenido nuevo de Wikipedia" en lugar de "el contenido más nuevo de Wikipedia". Si se pensara detenidamente en la redacción, esto eliminaría algunas páginas nominadas de la elegibilidad, pero de una manera beneficiosa, sin hacer que el proceso de revisión sea insuperable. No creo que haya consenso para limitar DYK solo a GA, pero este es un paso menos drástico que vale la pena evaluar. - Tryptofish ( charla ) 18:52, 10 de junio de 2021 (UTC)

Publiqué el siguiente desafío (ligeramente modificado aquí) en algún lugar arriba, pero (¡sorpresa!) No recibió respuesta:

Entre las cosas que GA requiere, pero DYK no, se encuentran que un artículo sea claro, conciso y comprensible; abordar los principales aspectos del tema; y manténgase enfocado en el tema sin entrar en detalles innecesarios. DYK no tiene tales requisitos, por lo que los artículos que presenta pueden estar mal escritos, ser confusos, lamentablemente incompletos y / o inflados y discursivos, y a menudo lo son. Por supuesto, si está diciendo que eso no es cierto, entonces el artículo de DYK ya cumple con GA y nadie debería tener ningún problema en hacer que GA sea el requisito de activación para DYK. ¿O admite que los artículos de DYK a menudo están mal escritos, son confusos, lamentablemente incompletos y / o inflados y discursivos, pero como está bien, no deberíamos aplicar el estándar GA? Por favor diga cual. E Eng 20:20, 10 de junio de 2021 (UTC)

Sí, esos criterios son buenos. Sin embargo, no me gustaría que reinventáramos el concepto de rueda de evaluación de artículos, y sugeriría permanecer cerca de cosas existentes como WP: B? o WP: C? . - Kusma ( conversación ) 20:58, 10 de junio de 2021 (UTC)

Creo que elevar un poco los estándares (duración, abastecimiento) está bien. Para los perezosos que quieren hacer clic en lugar de leer, algo como "si mw: ORES dice B, pasa, si dice Stub o Start, falla, si dice C, mira más de cerca" podría funcionar como un proxy para una revisión real . - Kusma ( conversación ) 20:40, 10 de junio de 2021 (UTC)

Oh, sí, por supuesto, sustituyamos la evaluación automática por la revisión humana. ¡Eso nos permitiría ejecutar el doble, tres veces más, cinco veces más DYK cada día sin esfuerzo humano adicional!

Más en serio, nadie ha respondido todavía a mi desafío aquí arriba. Quizás seas el primero. E Eng 20:50, 10 de junio de 2021 (UTC)

No estoy seguro de si esto no ha sucedido ya (algunas personas parecen pensar que "no copyvio" es lo mismo que "Earwig no encuentra un copyvio"). Siempre es bueno tener alguna revisión humana (idealmente con sugerencias sobre cómo mejorar el artículo) si me preguntas (prefiero comentarios constructivos a solo una marca). Solo debe tener cuidado de no hacerlo demasiado abrumador para los nuevos revisores. - Kusma ( conversación ) 21:09, 10 de junio de 2021 (UTC)

Tengo poco, muy poco entusiasmo por cualquier cosa que sea automatizada. Preferiría verlo en términos de mejorar la redacción de las reglas DYK (y preferiblemente no las reglas complementarias, excepto para hacerlas consistentes). Algo cercano a la clase B, pero no tan alto como GA, me parece aproximadamente correcto. En cuanto a EEng, quiero desafiar a que deje de cambiar el tema a sus propios principios de los comentarios, y para centrarse en las ideas aquí. - Tryptofish ( charla ) 21:17, 10 de junio de 2021 (UTC)

• Si vamos a seguir reservando DYK para nuevas páginas, no creo que haya nada terriblemente malo con nuestros estándares actuales. La mayoría de las páginas nuevas no son de muy alta calidad (el desarrollo de artículos lleva tiempo) y eso se refleja en DYK. Mi opinión es que deberíamos deshacernos de la novedad como el requisito (habitual), pero eso ya se ha discutido (en gran detalle) anteriormente. {{u | Sdkb }}  ^charla 21:29, 10 de junio de 2021 (UTC)

  Quizás hay formas de abordar algunas de las preocupaciones que subyacen al deseo de deshacerse de la novedad, sin realmente deshacerse de ella. Este enfoque intermedio no satisfará a los editores que "lo quieren todo", pero quererlo todo rara vez obtiene consenso. - Tryptofish ( conversación ) 21:44, 10 de junio de 2021 (UTC)

Pero DYK no está reservado a la novedad. Puede incluir cualquier artículo, sin importar la antigüedad, siempre que se haya incorporado recientemente al estándar GA. Así que me gustaría que la gente dejara de decir que es solo para artículos nuevos. Ya puede tomar cualquier artículo en Wikipedia que aún no sea un FA o GA y presentarlo llevándolo al estándar GA. Entonces, la única barrera es que debes trabajar un poco en un artículo que quieras nominar para mejorarlo. Eso es bueno para la enciclopedia y, en mi opinión, es un requisito apropiado. Gatoclass ( charla ) 06:52, 11 de junio de 2021 (UTC)

Llevar un artículo al estado GA no es solo "un poco de trabajo", especialmente si es un artículo grande para un tema importante, que es también donde es probable que se encuentren los ganchos DYK más interesantes. E independientemente de su opinión personal sobre si las personas deberían estar dispuestas a trabajar más, la realidad es que no es así: el 90% de los DYK son para artículos nuevos, no para GA, y no se va a producir un cambio de mentalidad colectivo gigante. que suceda simplemente porque nosotros lo decidimos. La única forma en que cambiará la dinámica de nominación actual es si somos lo suficientemente audaces para cambiar (o al menos experimentar) las reglas. {{u | Sdkb }}   ^charla 07:25, 11 de junio de 2021 (UTC)

Bueno, tal vez algunos de ustedes necesiten dedicar un poco más de tiempo a tratar de averiguar exactamente qué es lo que quieren de DYK, porque un minuto la discusión parece ser sobre ganchos de mejor calidad y el siguiente sobre artículos de mejor calidad. Pero ciertamente no obtendrá artículos de mejor calidad al deshacerse del requisito de GA y simplemente ir con cualquier gancho que encuentre en algún lugar que le guste. Aparte de eso, cuestionaría la afirmación de que hay mucho trabajo para conseguir que los artículos se ajusten al estándar de GA; depende completamente del estado del artículo de antemano y de la rigurosidad del revisor. Pero incluso si hubo un trabajo considerable en la AG promedio, ¿y qué? ¿No debería esperarse que hagas un pequeño trabajo por el privilegio de obtener un DYK en la página principal? Parte del propósito de DYK es mejorar la enciclopedia, y el requisito de GA lo logra. Gatoclass ( charla ) 09:40, 11 de junio de 2021 (UTC)

Independientemente, creo que está bastante claro que la principal queja sobre DYK a lo largo de los años ha sido la calidad del gancho, pero creo que la mayoría de los ganchos en estos días son en realidad de un estándar aceptable. El problema es una cantidad relativamente pequeña de ganchos que simplemente no están a la altura, y si resolviéramos ese problema, probablemente eliminaríamos el 90% de las quejas.

Entonces, por lo que vale, aquí está mi propuesta para mejorar la calidad general del gancho, que no requiere cambios de imagen radicales de dudosos beneficios o factibilidad. Básicamente, solo le damos a la gente un incentivo para trabajar más duro en los ganchos. Una forma de hacer esto sería tener algún tipo de crédito DYK para identificar un gancho deficiente y obtener una alternativa mejor. Llamémoslo el crédito "Eagle Eye" o algo así. Por lo tanto, si desafía un gancho como insuficientemente interesante y crea un gancho alternativo que llega a la página principal sin cambios sustanciales, entonces el retador obtiene un crédito DYK "Eagle Eye". Eso les da a los revisores y otros usuarios un incentivo para comenzar a prestar más atención a enganchar el interés y ver si pueden encontrar algo mejor. Es una solución simple y de bajo costo que sería fácil de probar y que posiblemente podría resultar en una mejora significativa en la calidad general del gancho. Gatoclass ( charla ) 09:46, 11 de junio de 2021 (UTC)

Me gusta. Crowdsourcing y zanahoria en lugar de palo. - Kusma ( charla ) 10:30, 11 de junio de 2021 (UTC)

Plantilla: ¡La medalla DYK ya está disponible para usar mientras tanto! CMD ( conversación ) 11:52, 11 de junio de 2021 (UTC)

¡Me gusta mucho esta idea! Ciertamente he hecho eso para los ganchos en el pasado, y ciertamente podría verme haciendo más si contara como un QPQ. No resolverá el problema de que algunos artículos sean nominados porque el nominador quiere ver que funcionan en la página principal en lugar de porque el artículo contiene algún dato de interés. Pero ayudaría a abordar el problema de que los nominadores estén demasiado cerca del tema para saber qué es realmente interesante sobre él (lo que Narutolovehinata5 y Khajidha discutieron anteriormente; búsqueda de "cambio en el pensamiento de los colaboradores de DYK"). {{u | Sdkb }}   ^charla 20:42, 11 de junio de 2021 (UTC)

Nuevo derecho de usuario (editar revisores de solicitud)

Esto nevó en VPR y también va a nevar aquí; no tiene sentido alargarlo. {{u | Sdkb }}   ^charla 17:41, 8 de junio de 2021 (UTC)

La siguiente discusión está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

---

Movido de WP: VPR

Propongo la creación de un nuevo derecho de usuario: "revisores de solicitudes de edición" que tienen la capacidad de aceptar / rechazar solicitudes de edición que se proponen en la conversación de páginas protegidas (excepto protección PRC y protección total) Este derecho se asigna automáticamente a los administradores y PRC que han extendido la confirmación.

Hago esta propuesta porque creo que solo los usuarios confiables pueden aceptar / rechazar solicitudes de edición siguiendo la misma lógica que llevó a la creación del derecho de usuario de PCR. Dr Salvus 23:11, 5 de junio de 2021 (UTC)

• Oponerse porque esto no parece tener sentido o resolver un problema, y ​​es técnicamente inviable. El permiso para editar una página semiprotejada está limitado a usuarios autoconfirmados. De ello se deduce que cualquier usuario autoconfirmado puede realizar la misma edición de forma independiente y, por lo tanto, también debería poder procesar el mismo contenido cuando se le solicite en la conversación. Cuando el contenido está en disputa, se resuelve mediante los procesos habituales de WP: DR para generar consenso. Esta propuesta también es técnicamente inexigible y no puede ser un derecho de usuario como se propuso, porque técnicamente es indistinguible si una edición está implementando una solicitud o es una edición independiente. Finalmente, Wikipedia no necesita limitar la edición de esta manera, y no hay evidencia de un problema con los usuarios autoconfirmados que responden a las solicitudes de edición. En realidad, el problema real es que PCR no debería ser un derecho de usuario separado. Debe incluirse con autoconfirmado o extendidoconfirmado. Un usuario autoconfirmado es suficiente para implementar una solicitud de edición a través de talk, y es suficiente para editar una página de cambios pendientes directamente y hacer que sus cambios se activen inmediatamente, y por lo tanto debería poder aprobar un cambio también. ProcrastinationReader ( charla ) 01:28, 6 de junio de 2021 (UTC)
• Oponerse , parece ser una solución buscando un problema. ¿Puede darnos algunos ejemplos de editores con confirmación automática o confirmación ampliada que aceptan o rechazan solicitudes de edición de forma incorrecta? Sungodtemple ( charla ) 01:48, 6 de junio de 2021 (UTC)
• Nota @ Dr. Salvus : moví esto de VPR a VPI. Esto realmente necesitaría mucho trabajo comprando antes de que esté listo para una discusión de propuesta. Si no está totalmente de acuerdo, siga adelante y muévalo hacia atrás, pero es probable que la nieve se cierre allí. Aquí podría desarrollarse más. - ^Charla xaosflux 03:15, 6 de junio de 2021 (UTC)
• No. Cualquier editor experimentado que esté al día puede revisar una solicitud de edición. Esa es la política. 🏳️‍🌈 ¡  Chicdat   ^{Bawk para mí!} 10:09, 6 de junio de 2021 (UTC)
• Oponerse , como ProcrastinationsReader afirma anteriormente y mucho mejor de lo que yo podría, esto no tiene sentido desde un punto de vista técnico. Además, no veo ninguna razón por la que esto deba implementarse, la razón por la que se realizan casi todas las solicitudes de edición es porque el editor actualmente no puede editar la página debido a circunstancias fuera de su control, y normalmente no tendríamos una verificación especial de grupo de usuarios. sus ediciones eiter. - ^Charla Asartea ^{| Contribuciones} 15:20, 7 de junio de 2021 (UTC)
• Oponerse , revisar una solicitud de edición no debería requerir más capacidad técnica que editar un artículo, que es básicamente el nivel básico de competencia que se espera de todos los editores. Crear un derecho de usuario para esto sería un sombrero para coleccionar: no mejoraría nada y haría que responder a las solicitudes de edición fuera mucho más burocrático de lo necesario, lo que es activamente perjudicial para la creación de contenido. Ardilla de Ivanvector ( ^árboles / _nueces ) 15:13, 8 de junio de 2021 (UTC)
• Comentario: He notificado las solicitudes de edición de WikiProject sobre esta discusión. ¡Feliz edición! --- Otro creyente _{( conversación )} 15:19, 8 de junio de 2021 (UTC)
• Estoy de acuerdo en que a veces hay una tendencia a ir directamente a la respuesta XY o RS de plantilla fácil en las solicitudes de edición: responder la carta de la solicitud, en lugar de tomar los dos minutos adicionales para buscar una fuente o averiguar lo que el solicitante está tratando de decir. Yo mismo he sido culpable en ocasiones. Sin embargo, hacerlo a través de los derechos del usuario no es la forma de abordar eso, por las razones declaradas por otros (la inviabilidad técnica es una de las principales). Si ve una solicitud rechazada que habría completado, no hay nada que diga que aún no puede trabajar en ella, y si ve que alguien lo hace mucho, discútalo con ellos. Si es algo que está más extendido, eso es algo que debería demostrarse con diffs y abordarse, pero por ahora estoy de acuerdo en que esta es una solución que busca un problema. ‑‑ El Hef  ( Meep? ) 17:22, 8 de junio de 2021 (UTC)

La discusión anterior está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

Lidiar con campañas fuera de la wiki con el poder de los votos positivos

WP: AN # Posible nueva herramienta / técnica / procedimiento ( enlace permanente ) me dio una mala idea. El objetivo es lidiar con el flujo de visitantes para que las operaciones de Wikipedia se vean afectadas lo menos posible. Así que hagamos una página fuera de la wiki para enviarlos. Propongo que hagamos algo que se parezca a Reddit, donde las "publicaciones" son preguntas (para nosotros, los editores) o solicitudes de edición. Se pueden hacer comentarios, y los visitantes pueden votar las publicaciones y los comentarios, de la manera habitual (tal vez necesitemos que se cree una cuenta, tal vez ofrezcamos Google / lo que sea que inicie sesión). ¡¿Por qué, Enterprisey, por qué?!, Te estarás preguntando. Creo que una plataforma al estilo de Reddit es la solución óptima para esta situación: muchos visitantes entrantes / atención, la mayoría mala , por lo que usamos la sabiduría de esa multitud para clasificar los elementos más populares en la parte superior y luego tratar con ellos. de manera pública. La idea es que las personas quieren ser escuchadas y, con suerte, estarán satisfechas con votar a favor las publicaciones que habrían hecho en lugar de escribirlas una vez más en una solicitud de edición, en nuestras páginas de discusión o en artículos. A modo de respuesta, tal vez los editores de Wikipedia puedan publicar con una etiqueta especial, o incluso con el nombre "Wikipedia", y sus publicaciones podrían clasificarse automáticamente en la parte superior ("pegadas", en términos de Reddit). Sí, esto es realmente anti-igualitario, pero nuestros sistemas se rompen por encima de una cierta cantidad de carga de todos modos (ejemplo reciente: el alboroto del "quinto califa del Islam"), y la alternativa es usar protección de página en todo.

Goszei sugiere usar un modelo similar a Twitter en lugar de un modelo similar a Reddit; en realidad, usando Twitter mismo: cree un hashtag, como #WikipediaSuggest, y luego la gente publica usando tanto ese como algún hashtag específico del "incidente". Si bien esta es una gran idea y aborda algunos de los ( masivos ) problemas de moderación que encontraremos, creo que la gente ya sabe la táctica de enviar gente a Twitter y luego no responderles. Demonios, incluso UserVoice obtiene ese tipo de reacción en estos días. Así que creo que Reddit en un sitio original tiene la mejor oportunidad. Enterprisey  ( ¡habla! ) 08:55, 6 de junio de 2021 (UTC)

• Esto es una locura delirante, y creo que podría funcionar. Necesitaría pensarlo mucho, pero está lejos de ser la peor idea para lidiar con este problema. firefly ( t · c ) 09:10, 6 de junio de 2021 (UTC)
• Nota: mencioné esto en el servidor no oficial de Wikimedia Discord ( WP: DISCORD ). No tenía alrededor de 8 años, pero me basé en la Herramienta de comentarios de artículos, que se puso a prueba aquí en en.wiki en 2013. Este RfC que detuvo su implementación generalizada es una buena lectura ( [29] ). Las grandes conclusiones del experimento fueron las siguientes: (1) La gran mayoría de las publicaciones no fueron procesables (los informes de WMF situaron esta cifra en el 12%); y (2) La moderación de las violaciones de BLP, tonterías, etc. pone una carga de trabajo en los editores. Sin embargo, fue útil como herramienta de participación: involucró a los lectores, dio voz a aquellos que no se sienten cómodos editando o publicando en una charla, y convirtió a algunos lectores en editores (a una tasa de registro del 2.7%, según los informes).

Cualquier propuesta que pueda eliminar los problemas de la AFT y mantener los beneficios sería buena. Creo que simplemente hacer que los problemas sean de otra persona, es decir, de Twitter, es una forma (quizás la única) de resolver esto. La moderación sería su problema, y ​​sus algoritmos están diseñados para eliminar la basura. También serviría como un acercamiento y un llamamiento para retomar la edición que se extiende más allá de Wikipedia. El modelo de Reddit sugerido es más "controlado" que simplemente arrojarlo al mar abierto y ver qué flota, pero ese control viene con una carga de moderación significativa. - Goszei ( conversación ) 20:43, 6 de junio de 2021 (UTC)

• Tanto los sitios de preguntas y respuestas como Stack Overflow o Quora como los sitios de publicación gratuita upvote / downvote como Reddit tienen el mismo problema: cuanto más popular sea su tema, más moderación necesitará. Ninguna plataforma resuelve el problema de volver a publicar (la misma pregunta) con los votos positivos; simplemente hace que las cosas populares sean más populares y descarga la carga de filtrar / eliminar contenido a los moderadores. Y, por supuesto, las cosas más populares se vuelven a publicar con mayor frecuencia para ser la pesadilla de los moderadores. El objetivo del voto positivo de los lectores ("¡Me gusta esto!") No es el mismo objetivo que el de Wikipedia ("¡Esto mejora la enciclopedia!"). Por ejemplo, la vista predeterminada de Reddit entierra temas de nicho y requiere un esfuerzo consciente para navegar a contenido específico. Los tableros de estilo Stack Exchange funcionan mejor cuando tienes una pregunta específica en mente que puedes buscar y no funcionan en absoluto para preguntas generales. Estas plataformas tienen sus beneficios y funcionan para casos de uso específicos, pero tampoco estoy convencido de que puedan mejorar el tipo de discusiones que Wikipedia quiere sin mucho esfuerzo adicional fuera del sitio. -  HELL KNOWZ    ▎ TALK 21:01, 6 de junio de 2021 (UTC) 
• Qué propuesta audaz pero controvertida. Me gusta cómo saliste y dijiste que solo vamos a hacer de los nuevos editores "el problema de otra persona", a diferencia de la mayoría de las propuestas que simplemente lo implican. El problema con esta propuesta es que en realidad no hará nada de este "problema de otra persona". Si simplemente volcamos a todos en un subreddit o alguna plataforma similar a Reddit, lo que sucede es que todavía tenemos que moderar el subreddit ya que hemos lo aprobó oficialmente y es una extensión de la plataforma Wikimedia. Si simplemente decidimos abdicar de cualquier responsabilidad por hacer cumplir las reglas, le daría alrededor de una semana hasta que se convierta en / pol / (tablero de contención de 4chan). Eso es si WMF no lo hace ' t cerrarlo a través de la acción de la oficina. Por ejemplo, será una mierda sobre cómo nuestro artículo sobre el holoengaño es incorrecto y la gente solicita que el tema principal de la BBC sea algo diferente a la agencia de noticias. Eso y un montón de Blp vios.

Entonces, por supuesto, los medios de comunicación serán alertados y recibiremos críticas interminables (que, con toda honestidad, nos lo mereceremos por completo) por tener esta plataforma. En ese momento intervendrá la WMF.

Por supuesto, si moderamos esta nueva plataforma para evitar todo el / pol / shit, básicamente no hemos hecho nada para abordar el problema más allá de simplemente cambiar la carga de trabajo. : Parafrasearé esto de Ratatouille y diré que el significado de "cualquiera puede editar" no es que cualquiera pueda ser un buen editor, sino que un buen editor puede venir de cualquier parte. Si bien la gran mayoría de los nuevos colaboradores no son buenos, debemos tratar a todos con respeto y darles la oportunidad de estar al mismo nivel que cualquier wikipedista "establecido", porque nuestro trabajo más importante es encontrar el 10% de las personas que en realidad serán buenos editores y los mantendrán editando de manera productiva.

Además, el quinto califa del Islam ni siquiera es culpa nuestra. Eso es culpa de Google y Bing por tener un paradigma basado en hacer surgir cualquier cosa independientemente de la precisión real. Cuando lo busca en Wikipedia, le damos los resultados correctos. Ajedrez ( charla ) (utilícelo en la respuesta){{reply to|Chess}} 21:08, 6 de junio de 2021 (UTC)

• Creo que los editores seguirán viniendo a Wikipedia y harán lo que hacen, así que no estoy seguro de que se vea ningún beneficio neto en Wikipedia. Además, mi preferencia personal sería que los editores puedan participar completamente únicamente a través de contribuciones en este sitio, y por lo tanto, preferiría que los comentarios con voto positivo en Reddit solo sean de asesoramiento. Esto, por supuesto, haría que Reddit sea menos efectivo como lugar para celebrar una discusión o votación, pero creo que de lo contrario le daría a las opiniones de los Redditors un peso indebido con respecto al resto de la comunidad de Wikipedia en inglés. isaacl ( charla ) 21:47, 6 de junio de 2021 (UTC)
• Me gusta la idea. RationalWiki tiene algo similar , cuyo código puede ser adoptado. Elli ( charla | contribuciones ) 05:29, 8 de junio de 2021 (UTC)

Sugerencia: las reversiones también deben obtenerse

En los últimos meses, he visto que mis ediciones se revierten cada vez con más frecuencia. No estoy diciendo que todas mis ediciones fueran buenas, pero * estoy * diciendo que algunas de ellas eran conocimientos nuevos adecuados para la enciclopedia. Algunos de ellos fueron, también, creo, revertidos debido al sesgo partidista, siempre por la razón de que no me abastezco lo suficientemente bien.

Es cierto que este es mi pecado. No obtengo bien, debido a cómo funciona mi memoria. ¿Pero no es también un pecado revertir sin razón?

Sobre todo porque en la filosofía de la ciencia soy un seguidor de Karl Popper, es decir, un falsacionista. Desde ese punto de vista, parece un poco trillado revertir cosas que no han sido debidamente falsificadas. Tal cosa no parece conducir a la acumulación de conocimientos. Sobre todo porque esta enciclopedia * intenta * seguir los principios ampliamente popperianos; ¿De verdad, ya?

¿Por qué no requerir una cita para una reversión sustancial, así como una edición, para la simetría? Quiero decir, una reversión es tanto una eliminación como una edición de eliminación. Ambos deben obtenerse. Incluso más la eliminación y la reversión, que la adición, de hecho: destruyen el conocimiento agregado por la comunidad, en aras de una regla arbitraria y muchas veces inútil. Creo que la mejor opción sería hacer que las ediciones destructoras y las reversiones sean tan difíciles de hacer y con un buen origen estándar, como lo es una adición.

Y, por cierto, ese tipo de cambio de reglas también revitalizaría a la comunidad. * A todo el mundo * le duele cómo está cambiando la cultura editorial aquí. Es cada vez más difícil simplemente editar en wiki, porque la curva de aprendizaje y la cultura editorial se han vuelto muy empinadas. No puedes meter tus cosas, incluso si sabes de lo que estás hablando. En las wikipedias menos conocidas, como la finlandesa, apenas puedes intervenir todavía. Pero en en-pedia, es casi imposible, a menos que seas un editor (semi) profesional.

Eso es entonces totalmente contrario a la misión original de Wikipedia. No puede recopilar todo el conocimiento enciclopédico que existe si presenta este tipo de barreras al experto común que simplemente lo escribe. Por supuesto, las reglas facilitan que la dirección mantenga los estándares y se defienda, pero la acumulación de conocimiento sufre. Por ejemplo, a través de esas reversiones constantes, formalistas y sin fuentes, yo y todos los demás sufrimos.

Por favor, ponles fin por regla. Si no es por la regla que estoy sugiriendo, en la búsqueda de reversiones y ediciones incorrectas, entonces de lo contrario. Porque, de lo contrario, el desarrollo de esta enciclopedia se va a encontrar con un caso grave de rentabilidad disminuida. Nos estancaremos, como lo hizo DMOZ una vez. Señuelo ( charla ) 20:56, 6 de junio de 2021 (UTC)

La verificabilidad es una política de Wikipedia, no "una regla arbitraria y a menudo inútil". Schazjmd   (charla) 21:00, 6 de junio de 2021 (UTC)

Y la mayor parte de lo anterior se aborda específicamente en WP: BURDEN . -  HELL KNOWZ    ▎ TALK 21:07, 6 de junio de 2021 (UTC)  

En realidad, está perfectamente en línea con la misión original de Wikipedia. En el pasado solíamos decir que "en Internet nadie sabe que eres un perro". La idea de Wikipedia es que en lugar de centrarnos en el viejo paradigma en el que confiamos en un "experto" para escribir un artículo basado en su conocimiento del tema, permitimos que cualquiera (incluso los perros) lo edite, pero hacer que confiar en ellos sea irrelevante con requisitos de abastecimiento muy estrictos. Entonces, cuando estás leyendo Wikipedia, no tienes que confiar en los editores de Wikipedia que podrían ser perros. Simplemente haga clic en el cuadro con el número y observe la información original.

Si no le gustan los principios fundamentales de Wikipedia, vaya a Citizendium . Ajedrez ( charla ) (utilícelo en la respuesta){{reply to|Chess}} 21:21, 6 de junio de 2021 (UTC)

@ Ajedrez : No estoy seguro de que Citizendium exista más para cuando Decoy llegue allí. 🏳️‍🌈 ¡   Chicdat    ^{Bawk para mí!} 10:33, 7 de junio de 2021 (UTC)

• Señuelo ... simpatizo (apesta ser revertido). Mi consejo: adopte un enfoque de "más largo plazo" para su edición. Si desea agregar algo a un artículo, ¡ESPERE! Suponga que cualquier fuente que tenga no es lo suficientemente buena y dedique unos días a buscar una fuente aún mejor antes que usted. intente agregarlo. Verá que se revertirá mucho menos. Mejor Blueboar ( charla ) 12:15, 7 de junio de 2021 (UTC)
• Me pregunto si deberíamos considerar algo que la Wikipedia alemana hace bien: su campo "editar resumen" se llama Zusammenfassung und Quellen , "resumen y fuentes". Si bien el resumen de edición no es un gran lugar para guardar fuentes a largo plazo, esto recuerda a las personas que siempre deben decir de dónde proviene su contenido y, solo con mirar su feed de cambios recientes, parece ayudar un poco. Por supuesto, se necesita más investigación . - Kusma ( conversación ) 12:54, 7 de junio de 2021 (UTC)

• Si desea una fuente para reversiones, usaré [30] para obtener esta reversión . ¡Este fue un párrafo pobre, con una cita sin fuente porque aparentemente no es una cita real! Mantenga un WP: TONE enciclopédico formal sin una redacción tan obstinada o como un ensayo. Reywas92 ^Talk 19:07, 7 de junio de 2021 (UTC)

Valores patrimoniales en IB

Encuentro que las estimaciones de patrimonio neto en IB (por ejemplo, en Bill Gates ) son muy problemáticas y confusas. ¿Cómo podemos realmente proporcionar al lector una estimación precisa cuando Bloomberg y Forbes a menudo entran en conflicto? Cual elegimos? ¿Hacemos un promedio? ¿Debería ser un promedio semanal o mensual? ¿Con qué frecuencia debería actualizarse? ¿Qué indica el triángulo rojo o verde que lo acompaña? (Un aumento / disminución en el último día, semana, mes, año, etc.) Abre una lata completa de gusanos. En situaciones similares, como los valores de los elementos o los precios de los medicamentos, evitamos incluir valores monetarios. Empiezo a pensar que deberíamos hacer lo mismo y guardar una explicación de los valores netos para la prosa donde se pueda explicar mejor. ¿Qué piensas? ~ HAL 333 04:31, 8 de junio de 2021 (UTC)

( editar conflicto ) Utilice ambos. 🏳️‍🌈 ¡   Chicdat    ^{Bawk para mí!} 10:38, 8 de junio de 2021 (UTC)

No use ninguno. Como se señaló, cuando corresponda, se puede explicar de manera más completa en otro lugar. Nikkimaria ( charla ) 12:07, 8 de junio de 2021 (UTC)

Tuvimos una discusión en alguna parte (pero no recuerdo dónde) recientemente sobre el "valor neto". Notaré que odio el término "valor" en este contexto como si el valor de alguien estuviera determinado por lo que posee, pero parece que estamos estancados con él. Estoy en la posición bastante normal de un inglés de clase media que se acerca a la edad de jubilación en el sentido de que mi patrimonio neto consiste en una casa y un fondo de pensiones y poco más, pero me costaría mucho decirles que mi patrimonio neto está más cerca del 20%. así, entonces, ¿cómo diablos podemos considerar que las suposiciones publicadas son de alguna manera precisas? Los muy ricos tienden a tener activos en grandes participaciones y propiedades, cuyo valor monetario solo puede evaluarse adecuadamente cuando se venden; el precio actual de las acciones de una empresa no determina por qué se puede vender una gran participación. Por supuesto, Bloomberg y Forbes a menudo entran en conflicto, porque ambos hacen conjeturas descabelladas y luego fingen que sus cifras son de alguna manera objetivas. Phil Bridger ( charla ) 15:39, 8 de junio de 2021 (UTC)

• Enlace a RfC en esto: Charla de plantilla: Infobox persona # ¿Desaprovechando el parámetro de patrimonio neto? . Salud. ~ HAL 333 17:05, 8 de junio de 2021 (UTC)

exportación de artículos de formato

Seguimiento en Phabricator
Task T167956

Hola, me gustaría configurar el formato de página para la exportación del artículo (PDF, libro y / o impresión, lo que sea). No puedo encontrar esas opciones (¿es mi culpa?). Estoy pensando en cosas simples como el tamaño de fuente, la posición de las tablas y el ancho del marco exterior de las páginas. No tengo idea de cómo se podría implementar, probablemente no sea demasiado difícil. Sería genial si alguien se encargara de eso. Gracias - Comentario anterior sin firmar agregado por Hennk von Muspelsheim ( charla • contribuciones ) 12:51, 8 de junio de 2021 (UTC)

No en este momento. Esto debería ser realmente técnico . Alguien, por favor, mueva la discusión en consecuencia, no tengo idea de cómo hacerlo. Sungodtemple ( charla ) 12:02, 9 de junio de 2021 (UTC)

@ Hennk von Muspelsheim : en el panel de la barra lateral izquierda hay un ejemplo de botón de "versión imprimible" en el que puede hacer clic; sin embargo, tenga en cuenta que esta función está obsoleta ; si utiliza la función "imprimir" en su navegador (incluidas las opciones que puede tener para "imprimir en pdf") probablemente obtendrá mejores resultados. Si tiene otras preguntas generales sobre cómo usar Wikipedia, consulte Wikipedia: Mesa de ayuda ; si cree que ha identificado un problema técnico, puede publicarlo en WP: VPT . - ^Charla xaosflux 15:51, 9 de junio de 2021 (UTC)

Añadiendo una nueva opción de idioma como inglés indio

Seguimiento en Phabricator
Task T212313

Movido de WP: VPR

Se debe ofrecer una nueva opción de idioma a los usuarios conocida como inglés indio . Es importante no solo como un nuevo idioma, sino que también todos los indios usan su propio sistema de numeración conocido como Sistema de Numeración Indio, que usa lakhs y crores en lugar de millones y miles de millones donde 100,000 = 1 lakh (1,00,000) y 1 millón (1,000,000) = 10 lakh (10,00,000). La mayoría de los sitios web y aplicaciones convierten valores al sistema de numeración indio cuando se selecciona inglés (India) y creo que Wikipedia debería hacer lo mismo. - Comentario anterior sin firmar agregado por Sreeganesh MR ( charla • contribuciones ) 10:58, 9 de junio de 2021 (UTC)

¿Existe un estándar formal reconocido para el inglés indio? Y, si es así, ¿en qué se diferencia de los del inglés británico, el inglés australiano, el inglés irlandés, etc.? Realmente ni siquiera necesitamos todas las etiquetas "_______ English" que ya tenemos. Tenga en cuenta que los coloquialismos y términos para cosas que realmente no se encuentran fuera de la India no cuentan para estas diferencias. Su sugerencia de conversión automática de números parece algo similar a la idea de conversión automática de unidades. Tales cosas han sido rechazadas en el pasado. - Khajidha ( conversación ) 11:17, 9 de junio de 2021 (UTC)

Estoy seguro de que esto se ha discutido en profundidad anteriormente, pero mi opinión es que las diferencias entre las diversas variedades de inglés son lo suficientemente pequeñas como para significar que no necesitamos ninguna conversión automática. El sistema numérico es una de las características principales que es diferente en el inglés indio del de otras variedades, pero creo que todo lo que hay que hacer es que los editores sean conscientes de que otros, aunque dominen bastante el inglés, pueden no serlo. estar muy familiarizado con términos como millón o crore y tenerlo en cuenta al decidir si vincularlos. Phil Bridger ( charla ) 12:07, 9 de junio de 2021 (UTC)

• ¿Qué quiere decir exactamente con la opción de nuevo idioma, Sreeganesh MR ? Ya es una política que los artículos se pueden escribir en cualquier variedad de inglés, incluido el inglés de la India, por lo que, por ejemplo, los temas relacionados con la India ya deberían escribirse en grandes cantidades en lakhs. -  Joe  ( charla ) 12:17, 9 de junio de 2021 (UTC)

  El manual de estilo desalienta el uso de lakhs y crores incluso cuando se escribe en inglés indio. Usedtobecool  ☎️ 13:47, 9 de junio de 2021 (UTC)

  @ Usedtobecool : ¿ Lo hace? Lo único anterior que veo en WP: CURRENCY es para artículos que no son específicos de un país. {{u | Sdkb }}   ^charla 14:13, 9 de junio de 2021 (UTC)

Según MOS: INDIA, el uso de lakhs / crores está permitido siempre que se proporcionen millones / billones de equivalentes entre paréntesis, y que lakh / crore esté vinculado en la primera mención. Narutolovehinata5 ^{t c csd nuevo} 14:16, 9 de junio de 2021 (UTC)

MOS: LAKH : Somos los Borg. Usedtobecool  ☎️ 15:20, 9 de junio de 2021 (UTC)

• @ Sreeganesh MR : esta propuesta no es procesable y necesitaría mucho desarrollo, incluso para que usted sea mucho más específico sobre lo que desea cambiar (y luego cómo desea que eso suceda). Me mudé del foro VPR aquí a el laboratorio de ideas para que no se rechace y cierre. - ^Charla xaosflux 13:42, 9 de junio de 2021 (UTC)
• Para utilizarlo en el software, consulte el phab: T212313 . - ^Charla xaosflux 13:45, 9 de junio de 2021 (UTC)
• Creo que hace varios años hubo una discusión (no puedo encontrarla) acerca de la fusión de todas las diferentes plantillas y directivas de "use ____ English" solo para aquellas que son funcionalmente únicas, lo que nos hubiera dejado con solo {{ Use inglés americano }}, {{ Use inglés británico }} y {{ Use inglés canadiense }}, con todas las demás plantillas existentes redirigidas a la que se aplique a esa variante (entre EE. UU. Y el Reino Unido; el canadiense es único). Evidentemente, no llegó a un consenso. Puedo ver el caso que se está haciendo aquí de que el inglés indio es una variante que es lo suficientemente única como para ser tratada de manera única en este esquema. Sin embargo, si la propuesta es crear una Wikipedia en inglés indio separada (similar a la Wikipedia en inglés simple), entonces no, fuerte oposición. Ardilla de Ivanvector ( ^árboles / _nueces ) 14:29, 10 de junio de 2021 (UTC)
• Un problema con el inglés indio es definirlo. A nivel académico, pierde la mayoría de sus características distintivas, y como es un segundo idioma para la gran mayoría de sus usuarios, muchos hacen "elecciones" gramaticales que no se encontrarían en los mejores periódicos indios (que probablemente sean los mejores opción para un "estándar"). ¿Pero son estos "errores"? Quien va a decir Un maestro de escuela indio, supongo, pero tenemos pocos de esos ediciones. Una de las diferencias más notorias es el uso de "the", que los escritores indios tienden a omitir (como los polacos). ¿Eso está mal o no? The Times of India no lo haría, o no lo haría con frecuencia. Johnbod ( charla ) 15:08, 10 de junio de 2021 (UTC)

Exactamente. Creo que los hablantes nativos establecerían las verdaderas variantes del idioma. Si el carácter distintivo del "inglés indio" se debe principalmente al uso por hablantes secundarios, no lo consideraría válido. En las fuentes en inglés de la India, las fuentes académicas y las principales fuentes de noticias probablemente serán indistinguibles del inglés británico. - Khajidha ( conversación ) 16:10, 10 de junio de 2021 (UTC)

Bueno, las principales fuentes de noticias ciertamente no son indistinguibles en sus referencias a grandes números. Las fuentes indias casi siempre usan lakh y crore, que son términos desconocidos en inglés británico. Phil Bridger ( charla ) 16:32, 10 de junio de 2021 (UTC)

Es cierto, pero eso podría manejarse con una opción de "usar inglés británico, pero proporcionar números de lakh / crore". ¿Existen otras diferencias en las fuentes formales de alto nivel? - Khajidha ( conversación ) 18:12, 10 de junio de 2021 (UTC)

Sí, estoy de acuerdo en que hay muy pocas cosas que sean exclusivas del inglés indio formal, de ahí mi declaración anterior, pero debemos reconocer las que existen y esperar que nuestros lectores las conozcan. Phil Bridger ( charla ) 20:03, 10 de junio de 2021 (UTC)

Ciertamente no estoy de acuerdo en que "hay muy pocas cosas que sean exclusivas del inglés formal de la India"; en realidad, hay muchas (dependiendo de cómo se defina ese dialecto). Si Khajidha cree que "las principales fuentes de noticias probablemente serán indistinguibles del inglés británico", esto me sugiere que no dedica mucho tiempo a leerlas. Johnbod ( charla ) 21:52, 11 de junio de 2021 (UTC)

Ocultar firmas personalizadas para nuevos editores

Recientemente escribí User: Enterprisey / signature rfc Drafting . Podría proponerlo formalmente en algún momento. Todos los comentarios son bienvenidos (aquí o allá). Enterprisey  ( ¡habla! ) 22:20, 9 de junio de 2021 (UTC)

Agregando un poco a lo que escribí allí, creo que en este momento es complicado, porque necesitamos encontrar un equilibrio imposible entre tener un wikitexto legible (porque las páginas de discusión todavía se editan en wikitext) y tener suficiente sintaxis para que los programas puedan decir qué es una firma, para que puedan hacer cosas como la pantalla variable que estás proponiendo. Esto es bastante similar al problema que tenemos con las referencias que llenan el wikitexto y el debate sobre las referencias definidas por listas. A largo plazo, espero que la solución para ambos sea la misma: hacer que VisualEditor (o, en el caso de las páginas de discusión, las herramientas de discusión) sea tan efectivo que casi nadie mire el wikitexto, momento en el que podrá convertirse en tan complejo como sea necesario. {{u | Sdkb }}   ^charla 22:44, 9 de junio de 2021 (UTC)

Sí, espero que la sintaxis propuesta, o cualquier cosa que se le ocurra a la gente, sea aceptable. Si la posición de la comunidad es de hecho de tolerancia cero ante cualquier cambio, la situación parece bastante grave. Enterprisey  ( ¡habla! ) 22:58, 9 de junio de 2021 (UTC)

• Personalmente, creo que es una gran idea. SportingFlyer T · C 23:01, 9 de junio de 2021 (UTC)

Disculpe mi ignorancia, ¿hay una ola de nuevos editores que se quejan de lo confusas que son las firmas? ¿Es esto realmente un problema? HighInBC ¿ ^{Necesita ayuda? Solo pregunta.} 23:03, 9 de junio de 2021 (UTC)

Sí, algunos. Solo mirando los comentarios actualmente en WT: SIG, encontré la perspectiva del lector de WT: SIG # A , Special: Diff / 1025529507 (del hilo anterior), Special: Diff / 1027705784 y Special: Diff / 1027480740 . Desafortunadamente, debido al sesgo de supervivencia , la falta de más ejemplos no es un argumento a favor o en contra de que los nuevos editores encuentren confusas las firmas. Enterprisey  ( ¡habla! ) 23:22, 9 de junio de 2021 (UTC)

Parece un sesgo de confirmación allí, ya que las únicas personas involucradas en esa encuesta son las que tenían una queja. - ^Charla xaosflux 01:12, 10 de junio de 2021 (UTC)

Me imagino que los nuevos editores tienen la misma probabilidad de encontrar su camino hacia la discusión, tengan o no una queja. Claro, las personas que tuvieron una queja están más motivadas para compartirla, pero seguramente alguien sin una hubiera visto las 4+ respuestas y hubiera querido hacer oír su lado. Enterprisey  ( ¡habla! ) 03:40, 10 de junio de 2021 (UTC)

• Dado que el actual RfC incluido en WP: CENT en WT: SIG está mostrando una avalancha de oposición a incluso restringir el uso de firmas personalizadas, ¿cuál es el punto de incluso preguntar esto? -  Joe  ( charla ) 10:18, 11 de junio de 2021 (UTC)

Lo que tenemos aquí es una falla en la comunicación (algunos editores móviles a los que simplemente no puede comunicarse)

Resumen de problemas generales: Usuario: Sufusión de errores de comunicación amarilla / móvil Procrastinación Lector ( charla ) 03:08, 21 de marzo de 2021 (UTC)

Hace más de un año, informé dos problemas a la WMF:

Seguimiento en Phabricator
Task T240976

(1) Los editores web móviles que han iniciado sesión no reciben una indicación muy clara de que tienen mensajes nuevos. Solo hay un pequeño número en un círculo rojo. Es similar a lo que muchos otros sitios usan para "¡Emocionantes! ¡Nuevas! Ofertas!" y otra basura. No hay nada que diga "Un ser humano quiere hablar contigo".

Seguimiento en Phabricator
Task T240889

(2) Los editores de IP de la web móvil no reciben ninguna indicación de que tengan nuevos mensajes. Nada. Cada plantilla de advertencia, cada mensaje personal cuidadosamente pensado y todo lo demás simplemente desaparece en un agujero negro, a menos que el usuario se tropiece con su página de discusión por accidente o cambie a la interfaz de escritorio.

Pero lo entiendo. Los errores ocurren. Se pueden arreglar. En cambio, ambos problemas se marcaron como de prioridad "baja".

Esto es desconcertante. El problema 1 es un problema grave. El problema 2 es absolutamente inaceptable .

Estamos gritando a los usuarios (o incluso arrastrándolos a WP: ANI ) por " ignorar " nuestros mensajes que no tienen idea de que existen. Esperamos que aprendan sin ninguna comunicación todo tipo de reglas desde WP: V a WP: 3RR a WP: MOS que ni siquiera se aplican a la mayoría de los otros sitios en la web.

Hasta que se bloqueen, por supuesto. Qué terrible experiencia. ¿Cómo se supone que vamos a ganar nuevos usuarios cuando a su primera interacción con un humano se le dice que se vaya a la mierda, por "ignorar" un mensaje que ni siquiera conocían?

WMF, explique a esta comunidad por qué esta es una prioridad "baja". Un año es suficiente. Suffusion of Yellow ( charla ) 22:55, 16 de febrero de 2021 (UTC)

Solo señalaré que la mayoría de nuestros usuarios acceden a nosotros en dispositivos móviles, por lo que este tampoco es un problema de nicho. Lo mejor, Barkeep49 ( charla ) 23:26, 16 de febrero de 2021 (UTC)

Guau. Los tickets de fabricador de alta prioridad desatendidos no son nada nuevo, pero este es otro nivel. Jimbo Wales , esto merece su atención. {{u | Sdkb }}   ^charla 08:11, 18 de febrero de 2021 (UTC)

Me gustaría señalar que la mayoría de los mensajes dejados en IP nunca llegarán al usuario en cuestión de todos modos, ESPECIALMENTE en conexiones móviles. Debido a los ips compartidos, la probabilidad de que otra persona vea el mensaje antes que la persona a la que está tratando de comunicarse es probablemente de 50/50. Me doy cuenta de que a veces dejar un mensaje es efectivo, pero hay serias dudas sobre todos los casos en los que simplemente deja un mensaje muy confuso y, a menudo, con un tono agresivo a un usuario completamente diferente que acaba de leer al azar un artículo en la parada del autobús un mes después. Lo que realmente necesitamos es una forma completamente nueva de dejar mensajes a usuarios anónimos. Posiblemente con algún tipo de sesión de muy corta duración o algo así. Pero como los usuarios de IP son más o menos apátridas (el concepto de software) en este momento, probablemente sea difícil de implementar. - Th e DJ ( hablar • contribuciones ) 09:26, 18 de Febrero 2021 (UTC)

@ TheDJ : No tendría ninguna objeción a que expire el OBOD si no se hace clic en la página de discusión en unos días. Muchos mensajes llegan solo unos minutos después de que el usuario realiza la edición; la mayoría de las compañías de telefonía móvil no son que la dinámica. Suffusion of Yellow ( charla ) 17:14, 23 de febrero de 2021 (UTC)

Seguimiento en Phabricator
Task T263943

Igualmente desconcertante es que los usuarios de aplicaciones móviles no ven ninguna notificación , incluidas las notificaciones de la página de discusión, cuando inician o cierran sesión. El enlace para hablar está enterrado dentro de la configuración. ¡Aplicaciones móviles oficiales! ¡Ni siquiera ven mensajes de bloqueo! Consulte T263943 y otros. Esta revisión de bloque y también esta discusión donde un editor también probó mensajes de bloque. El editor fue bloqueado varias veces por algo que no fue culpa suya, sino de una aplicación mal pensada. No estan solos. Cita de la tarea phab: Conclusión: Usar la aplicación es como estar dentro de una burbuja, sin contactos con el exterior. No es de extrañar que haya tanta gente quejándose aquí de que el uso de la aplicación provocó el bloqueo de su cuenta de Wikipedia, por razones que no comprenden. ProcrastinationReader ( charla ) 09:33, 18 de febrero de 2021 (UTC)

Seguimiento en Phabricator
Task T275117

Seguimiento en Phabricator
Task T275118

He presentado T275117 y T275118 . ProcrastinationReader ( charla ) 10:22, 18 de febrero de 2021 (UTC)

Siempre me sorprende que alguien pueda editar con la interfaz móvil. Como otro ejemplo, si no ha iniciado sesión, no hay forma de acceder a la página de discusión de un artículo, o incluso ninguna indicación de que existe. Si un usuario no registrado hace una edición y se revierte con un resumen común como "ver charla", imagino que muchos no tendrán idea de lo que está pasando. -  Joe   ( charla ) 09:39, 18 de febrero de 2021 (UTC)

La web móvil y las aplicaciones móviles parecen estar diseñadas para lectores y no para escritores. Habiendo utilizado la web móvil de vez en cuando, creo que se puede utilizar para la edición iniciada, pero tengo que cambiar al escritorio de vez en cuando. He usado la aplicación de iOS solo para una prueba; no se puede usar para editar imo. ProcrastinationReader ( charla ) 09:55, 18 de febrero de 2021 (UTC)

La cantidad de ediciones que he realizado con la interfaz web o de la aplicación móvil es probablemente menos de 50 (de 13,000). Incluso para leer, la interfaz móvil está prácticamente inutilizable. Edito con frecuencia desde la pantalla de mi teléfono celular de 4 pulgadas (de hecho, lo estoy haciendo ahora mismo) ... pero uso la versión de escritorio. - codificador de Python  ( charla  |  contribuciones ) 14:04, 18 de febrero de 2021 (UTC)

Estoy de acuerdo con Joe y siempre he encontrado que Cullen328 es un poco un superhéroe por ser quien es en un dispositivo móvil. Saludos , Barkeep49 ( charla ) 18:19, 18 de febrero de 2021 (UTC)

Gracias por las amables palabras, Barkeep49 , pero simplemente uso el sitio de escritorio completamente funcional en mi teléfono inteligente Android. Es fácil. Si yo fuera el rey de la Fundación Wikimedia, cerraría el sitio móvil y las aplicaciones, porque son un impedimento continuo para la edición seria. RoySmith , no hay necesidad de invertir más esfuerzo (dinero) en una buena interfaz de edición para dispositivos móviles, porque esa interfaz ya existe: el sitio de escritorio. Simplemente cambie su nombre de escritorio a universal o algo así, y el problema se resolverá. Cullen ³²⁸ Vamos a discutirlo 18:34, 18 de febrero de 2021 (UTC)

• En algunas partes del mundo, las computadoras portátiles y de escritorio son comunes, y los teléfonos de las personas son su segunda pantalla. En un entorno como ese, sí, tiene sentido que los dispositivos móviles se consideren una interfaz de lectura mayoritaria. Por otro lado, en otras partes del mundo (particularmente India en el contexto de los usuarios del idioma inglés), el móvil es la forma en que las personas acceden a Internet. [31] No hay duda de que crear una buena interfaz de edición para dispositivos móviles es algo difícil, pero deberíamos invertir más esfuerzo allí. Las herramientas de edición móviles deficientes privan de derechos a un gran segmento de la población mundial. - RoySmith (charla) 14:41, 18 de febrero de 2021 (UTC)

• @ Suffusion of Yellow : Gracias por expresar básicamente exactamente el mismo problema que yo quería. He bloqueado a algunos editores que parecen estar editando de buena fe pero simplemente no se comunican, que eventualmente terminan en ANI y después de mucho dolor, son golpeados con un bloque WP: ICANTHEARYOU tan amigable como podemos reunir. En la última instancia, Mdd97  ( talk  · contribs ), hice específicamente una plantilla de bloque personalizada que decía "HAGA CLIC AQUÍ PARA LEER SUS MENSAJES" de una manera que seguramente no podrían perderse ... pero nuevamente, siguiendo el bloque No he vuelto a editar. Nosotros tenemos que llegar al fondo de esto; si ha llegado a un punto en el que tengo que bloquear a las personas y la causa principal es una falla de software, es necesario solucionarlo. Sin duda, la WMF no puede estar contenta de que haya tenido que emitir bloqueos sobre editores de buena fe de esta manera. Ritchie333 ^{(charla) (continuación)} 16:10, 18 de febrero de 2021 (UTC)
• Para abordar una reacción que algunos puedan tener, sí, la gran mayoría de los usuarios en dispositivos móviles son lectores, no editores, y no, no quisiera que la comunidad se encargara totalmente de rediseñar la interfaz móvil, ya que terminaríamos con el fenómeno que tenemos en el escritorio donde, por ejemplo, la sección de herramientas de la barra lateral es visible para todos los usuarios en todas las páginas a pesar de que no tiene ningún uso para el 99,9% de ellos. Pero esta solicitud no es solo editor-centrismo; se aplica a los usuarios que ya han editado y que necesitan urgentemente una notificación para no perderse. {{u | Sdkb }}  ^charla 18:55, 18 de febrero de 2021 (UTC)
• Creo que el proyecto mw: Talk Pages , especialmente ahora que están empezando a trabajar en la suscripción de notificaciones para las secciones de la página de discusión , podría estar interesado en esta discusión. Usuario de ping : PPelberg (WMF) y Usuario: Whatamidoing (WMF) . También toca la aplicación de UCoC , destacando que debe haber financiación para el desarrollo de software. además de otras medidas. Ping Usuario: SPoore (WMF) y Usuario: BChoo (WMF) por no saber a quién contactar con respecto a la Fase 2. Pelágicos (  mensajes  ) - (09:51 Sábado 20, AEDT) 22:51, 19 de febrero de 2021 (UTC). .. Agregar usuario: Xeno (WMF) después de ver la sección anterior. Pelágicos (  mensajes  ) - (09:55 Sábado 20, AEDT) 22:55, 19 de febrero de 2021 (UTC)

  Pelágico : Gracias por el ping y resaltar cómo esta es una necesidad relacionada para mi proyecto actual. He estado siguiendo este hilo e incluiré los comentarios (y los enlaces de fabricador, ¡gracias por esos!) En mi trabajo categorizados bajo solicitudes importantes de recursos humanos o técnicos adicionales para ayudar con los flujos de trabajo en wiki . Xeno (WMF) ( charla ) 15:02, 14 de marzo de 2021 (UTC)

Pregunta - ¿Es esto algo que podría curarse al traer de vuelta la "Barra Naranja de la Muerte"? Mjroots ( charla ) 16:31, 22 de febrero de 2021 (UTC)

@ Mjroots : la barra naranja de la muerte nunca desapareció. La última vez que verifiqué, todavía está disponible para editores de IP no móviles. Es por eso que reciben una indicación de nuevos mensajes. AFAIK, nunca estuvo disponible para el editor web móvil, eso es probablemente parte del problema. Nil Einne ( charla ) 03:06, 23 de febrero de 2021 (UTC)

Lo que nadie me ha dicho nunca es por qué se omitió en primer lugar. ¿Fue un simple descuido? ¿Alguien entendía tan poco cómo funcionan los sitios que pensaba que la comunicación era innecesaria? ¿Alguna otra razón en la que no estoy pensando? Ésta es la parte más confusa. Suffusion of Yellow ( charla ) 17:14, 23 de febrero de 2021 (UTC)

Ojalá se pudiera traer de vuelta para todos los editores. Parece que traerlo para IP en móviles podría ser la cura aquí. Mjroots ( charla ) 18:40, 23 de febrero de 2021 (UTC)

Esto es alarmante pero no sorprendente. Dado que respondo muchas preguntas en Teahouse, señalaré una publicación de IP aleatoria de ayer , en la misma línea que algunos de los sentimientos mencionados anteriormente: "Además, ¿por qué no se deshacen de la vista móvil ? ¡Tan terrible!" .-- Fuhghettaboutit ( charla ) 00:29, 24 de febrero de 2021 (UTC)

• ¿Alguien con una cuenta (WMF) planea comentar en este hilo? Suffusion of Yellow ( charla ) 17:21, 8 de marzo de 2021 (UTC)

  No contengas la respiración. Para la mayoría de los empleados de WMF, comentar en Wikipedia usando una cuenta de WMF es una forma rápida de hacer que lo despidan. Si hace suficiente ruido, podría hacer que un jefe de departamento responda diciendo que los usuarios de dispositivos móviles son muy importantes para nosotros y que haremos todo lo posible para abordar esto, hasta pero sin incluir hacer algo diferente a lo que estamos haciendo ahora. . - Guy Macon ( charla ) 17:39, 8 de marzo de 2021 (UTC)

  @ Guy Macon : Cuando hicieron lo mismo con las IP de escritorio, se solucionó a las pocas horas de haber sido señalado . Pregunta seria, no retórica: ¿qué ha cambiado en la cultura de WMF desde 2013? Suffusion of Yellow ( charla ) 17:58, 8 de marzo de 2021 (UTC)

Cuando gasta tres veces más dinero sin cambiar el trabajo real para el que fue contratado, comienza a concentrarse más en gastar todo ese dinero en lugar de hacer su trabajo. Cuando contrata una gran cantidad de nuevos empleados cuando el grupo actual es más que suficiente para hacer el trabajo, esos nuevos empleados encuentran algo que hacer, ya sea que sea necesario o no. Sólo digo. - Guy Macon ( charla ) 18:31, 8 de marzo de 2021 (UTC)

• Usuario: Sufusión de amarillo en términos generales, tiene dos factores. En primer lugar, hay pocos incentivos para que la gente de WMF se involucre con la gente aquí, donde habrá un montón de gente gritándolos (lo cual no es divertido). En segundo lugar, ha habido un entendimiento no escrito desde hace mucho tiempo de que los dispositivos móviles son el terreno de la WMF, mientras que la comunidad tiene más propiedad del escritorio. © Geni ( conversación ) 11:21, 11 de marzo de 2021 (UTC)

  Bueno, imagina esto. Alguien está parado en tu pie. Cortésmente les pides que se aparten de él. No lo hacen. Repite su solicitud más alto. Siguen ignorándote. Todavía duele. En algún momento, ¿entran en juego los gritos y los empujones?

  Si a WMF no le gusta que le griten, bueno, ciertamente, a nadie le gusta. Pero a las personas tampoco les gusta que las ignoren, y hacerlo es una excelente manera de hacer que empiecen a gritar solo para ser escuchadas. Seraphimblade ^Háblame 21:42, 14 de marzo de 2021 (UTC)

• ¡Acción de la WMF! Uno, dos, tres nuevos errores móviles que descubrí mientras investigaba esto se clasificaron como de prioridad "baja", y un cuarto se redujo a "medio", después de que un desarrollador voluntario lo subiera a "alto". Todo sin una palabra de explicación. El primero (mensajes de lista negra de spam sin analizar) no es un gran problema, estoy de acuerdo. Pero, ¿por qué no decirles a los usuarios por qué están bloqueados o decirles falsamente a los usuarios registrados que están bloqueados personalmente no es una preocupación importante? Así es como perdemos gente. Suffusion of Yellow ( charla ) 22:55, 22 de marzo de 2021 (UTC)
  • ¿Podemos bloquear localmente estas aplicaciones para que no editen la Wikipedia en inglés? Eso obligaría a la WMF a arreglarlos. Vallas y ventanas 00:02, 26 de marzo de 2021 (UTC)

    @ Vallas y ventanas : Sí, esto se puede hacer con el filtro de edición. Incluso podría limitarse a usuarios sin una dirección de correo electrónico confirmada. Pero hay una trampa. ¡Las aplicaciones tampoco muestran correctamente las advertencias de filtros de edición personalizados! La aplicación de iOS solo muestra el título de la página donde se almacena el mensaje. Y la aplicación de Android no muestra mensajes personalizados en absoluto. El editor web móvil hace mensajes de la pantalla correctamente, sin embargo. Suffusion of Yellow ( charla ) 00:10, 26 de marzo de 2021 (UTC)

    Si este fuera un problema de menor prioridad, diría que deberíamos regresar en un mes y ver si WMF lo solucionó. Pero este es un descuido tan flagrante que creo que puede ser la única opción si queremos solucionarlo. Pregunta: ¿esto se aplicaría solo a la aplicación o también al sitio móvil? - codificador de Python  ( charla  |  contribuciones ) 15:06, 29 de marzo de 2021 (UTC)

    Es solo una aplicación (la user_appvariable en el filtro de edición). ProcrastinationReader ( charla ) 15:12, 29 de marzo de 2021 (UTC)

  Gracias, ProcrastinationReader . Si preparamos un RfC, ¿dónde se llevaría a cabo? Necesitaría publicidad en centavo. Vallas y ventanas 23:47, 29 de marzo de 2021 (UTC)

  @ Vallas y ventanas : Cualquier RFC necesitará primero una redacción muy cuidadosa . Si falla (por cualquier motivo), WMF podría interpretar la falla como "ver que a la comunidad realmente no le importa este problema". Suffusion of Yellow ( charla ) 23:51, 29 de marzo de 2021 (UTC)

  Es posible que deseemos mover este hilo a WP: VPT ; este tablón de anuncios no tiene mucha audiencia . - xeno ^talk 23:54, 29 de marzo de 2021 (UTC)

  Sin embargo, realmente no quiero apresurarme a un RFC. Hay muchas preguntas. ¿Deberíamos también prohibir los editores web de IP para móviles? ¿Deberíamos rechazar las ediciones de los usuarios con una dirección de correo electrónico confirmada? ¿Qué errores, exactamente, queremos que se solucionen? ¿Cuánto tiempo le damos a la WMF para arreglarlos? Esta es una opción nuclear. No debe tomarse a la ligera.

  Pero no mueva todo el hilo a VPT. Está aquí para que no quede enterrado en los archivos. Suffusion of Yellow ( charla ) 00:33, 30 de marzo de 2021 (UTC)

  ( editar conflicto ) ¿Quizás RfC de dos preguntas? Lluvia de ideas inicial - Pregunta 1: 'carta' de consenso a WMF solicitando que se asignen recursos para solucionar rápidamente los problemas. Pregunta 2: si no se hace dentro de los 90 días, las aplicaciones móviles bloqueadas para editar enwiki por el filtro de edición. Es mejor trasladar este asunto en particular a VPI. ProcrastinationReader ( charla ) 00:36, 30 de marzo de 2021 (UTC)

  Sin embargo, debe tenerse en cuenta que rechazar las ediciones, si se trata de eso, realmente no es genial y es bastante mordaz, ya que los editores difícilmente tendrán idea de lo que está sucediendo debido a que los mensajes de EF son dudosos. ¿Quizás molestar a Jimbo y / o Doc James para que se pongan en contacto con alguien de ingeniería es una opción viable? ProcrastinationReader ( charla ) 00:43, 30 de marzo de 2021 (UTC)

  Como ya he dicho. Nuclear. Suffusion of Yellow ( charla ) 01:09, 30 de marzo de 2021 (UTC)

  Sí, IDEALAB es el mejor lugar (para un nuevo hilo). Eso desalentará cualquier apoyo y oposición hasta que averigüemos exactamente lo que estamos pidiendo. Suffusion of Yellow ( charla ) 01:09, 30 de marzo de 2021 (UTC)

  Esto necesita precaución: una propuesta o RfC demasiado entusiasta en WP: VPI seguramente será rechazada y eso haría que mucha gente rechace automáticamente cualquier propuesta futura de naturaleza similar. Estoy pensando en IP enmascaradas: cualquier propuesta para impedir o bloquear a estos usuarios podría fallar fácilmente si pareciera ser similar a una idea anterior para bloquear a los usuarios de "buena fe" que no sabían que la comunicación era posible, y mucho menos necesaria. Johnuniq ( charla ) 08:34, 30 de marzo de 2021 (UTC)

• Desearía poder decir que me sorprendió todo esto, pero durante mucho tiempo he asumido que algo como esto fue la causa de numerosos editores con los que me he encontrado que muestran con bastante claridad que nunca han visto su página de conversación de IP / usuario, y simplemente no tengo idea de por qué sus ediciones "no se realizan" (porque un editor humano las sigue deshaciendo). Una completa pérdida de miles de horas de tiempo voluntario, en ambos extremos . Hay algunos países o regiones en los que el acceso a Internet solo es financieramente posible para la persona común a través de un teléfono móvil, por lo que la inacción de la WMF aquí es otro sesgo sistémico incorporado que impide que algunas culturas contribuyan de manera efectiva con sus conocimientos y habilidades a Wikipedia. - Bilorv ( conversación ) 06:51, 29 de marzo de 2021 (UTC)
• Seguimiento en Phabricator
  Task T278838
  
  
  Usuario: Suffusion of Yellow / Mobile communication bugs parece ser una excelente descripción general, pero recibiría más atención si estuviera en phab. Intenté copiarlo aproximadamente en https://phabricator.wikimedia.org/T278838, que probablemente se pueda usar como tarea principal para todos estos problemas. - SD0001 ( conversación ) 15:04, 30 de marzo de 2021 (UTC)

Hola a todos, gracias por plantear estos problemas y documentarlos tan a fondo. Vamos a reunir a un grupo de personas del departamento de Producto la semana que viene para hablar sobre estos problemas y ver qué podemos hacer al respecto. Te haré saber lo que averiguamos. Les agradezco a todos que lo mencionen. -  DannyH (WMF) ( conversación ) 22:17, 7 de abril de 2021 (UTC)

¡Gracias Danny! Espero ver lo que se te ocurra. Suffusion of Yellow ( charla ) 19:55, 9 de abril de 2021 (UTC)

Actualización del 26 de abril

Hola a todos, hablamos en el departamento de Producto sobre los problemas que se están planteando en esta conversación.

Actualmente, mostramos notificaciones a los editores que han iniciado sesión en la web móvil, que aparecen como un número dentro de un círculo rojo en la parte superior de la página. Es el diseño estándar en dispositivos móviles que indica que hay mensajes para ti.

Nos hemos mostrado reacios a hacer eso para los editores de IP en la web móvil, porque las IP móviles cambian mucho. Las IP de escritorio también pueden cambiar, por lo que existe el riesgo de no llegar a la persona adecuada en el escritorio, pero el riesgo es mucho mayor para los dispositivos móviles. Las personas caminan con sus teléfonos y se mueven de una wifi o torre celular a otra. No hemos querido mostrar una barra de mensajes a un lector móvil que está recogiendo la misma torre celular o punto de acceso wifi que alguien que hizo una edición hace un año.

En las aplicaciones, el equipo de Android ha lanzado mejoras a la experiencia de la página de discusión en febrero y marzo. Las notificaciones de eco existen actualmente en la aplicación de Android y las páginas de conversación de los usuarios también se pueden descubrir a través de la lista de seguimiento. Los usuarios pueden acceder a la charla del artículo usando un menú desplegable en la parte superior derecha; puedes ver cómo funciona esto en este tutorial de gif . Se planean algunas mejoras adicionales, incluida la habilitación de respuestas en línea y la creación de funciones de incorporación para ayudar a las personas a descubrir tanto la lista de seguimiento como las páginas de discusión. Puede obtener más información y hacer preguntas al equipo en la página del proyecto de comunicación de Android .

El equipo de iOS también está buscando mejorar la experiencia de conversación en su aplicación. Actualmente se encuentran en la fase inicial de diseño y planificación técnica para habilitar las notificaciones Echo en iOS . A finales de este año, planean completar algunas de las funciones de colaboración que faltan en la aplicación, incluido hacer que las herramientas de edición y las páginas de discusión sean más prominentes.

Hay algunas cosas diferentes para discutir aquí, y me gustaría saber qué piensas. -  DannyH (WMF) ( charla ) 18:47, 26 de abril de 2021 (UTC)

¿Qué estamos haciendo con los mensajes de notificación de bloqueo y los otros avisos de la pantalla de edición? - Th e DJ ( hablar • contribuciones ) 19:02 26 de abril 2021 (UTC)

@ DannyH (WMF) :

• Acerca de los usuarios de IP : Como otros y yo mismo hemos sugerido, hay una solución al problema del "lector aleatorio no relacionado": no mostrar la alerta si el nuevo mensaje tiene más de X días de antigüedad. O (si la política de privacidad lo permite) establece una cookie cada vez que hacen clic en "publicar" y solo muestra cualquier alerta de mensaje nuevo a las personas que lo han editado en los últimos X días. O incluso ambos. Creo que la mayoría de la gente ya comprende que no se garantiza que los mensajes enviados a los usuarios de IP lleguen al usuario. Pero nosotros sí esperamos que cuando edita 1.2.3.4 Foo , les dejamos un mensaje, y luego una hora más tarde 1.2.3.4 ediciones Foo vez más , que han visto nuestro mensaje. Esa es la desconexión entre las expectativas y la realidad que nos ha estado molestando. También está asumiendo que los usuarios de dispositivos móviles también tienen conexiones móviles . ¿Qué pasa con el usuario del teléfono en el WiFi de su hogar? Eso podría mantenerse estable durante meses.
• Acerca de los usuarios que han iniciado sesión : No, el círculo rojo no es (solo) la alerta estándar de "tiene mensajes nuevos". También es la alerta estándar "tenemos basura con spam que nos gustaría venderle". Por supuesto, los usuarios experimentados saben que Wikipedia no hace eso, pero los inexpertos son las personas a las que estamos tratando de llegar. Como cuestión de costumbre, yo ignoro avisos de aspecto similar en sitios web desconocidos.
• Acerca de la aplicación de Android : una vez más, ¿qué pasa con los usuarios cansados ​​del spam que han desactivado las notificaciones push ? Sin alerta en la aplicación, ¿cómo se supone que saben que hay un mensaje urgente en su página de discusión?
• Acerca de la aplicación iOS : si los usuarios se encuentran actualmente en una burbuja total, ¿por qué habilitar la edición? ¿Por qué no esperar hasta que se implementen las funciones básicas de comunicación y, mientras tanto, mantener la aplicación como de solo lectura?

Realmente tengo la impresión de que la WMF piensa que la comunicación con el usuario es una ocurrencia tardía. No se olvidó simplemente de una función relacionada con la comunicación, sino que se olvidó de la mayoría de las funciones relacionadas con la comunicación . ¿Cómo sucedió esto en primer lugar? Suffusion of Yellow ( charla ) 20:15, 26 de abril de 2021 (UTC)

@ DannyH (WMF) : Gracias por su tiempo trabajando y respondiendo a esto. Reconozco las dificultades para desarrollar un buen producto de software para los diversos proyectos que dependen del software MediaWiki. Sin embargo, estoy profundamente frustrado de que se haya permitido que esto ocurra. Asegurar que los mecanismos comunitarios existentes para comunicarse con otros editores, especialmente los nuevos editores, continúen funcionando es un requisito básico para cualquier producto mínimo viable de Wikimedia . Parafraseando los pensamientos relacionados de Risker sobre el desarrollo de software de Wikimedia en un área diferente : la intención detrás de mucho de esto ha sido buena, pero a veces creo que los ingenieros no tienen idea de cómo funcionan realmente nuestros proyectos y cuán importantes son algunos de estos problemas. Francamente, si los editores móviles desconectados no tienen una interfaz para ver los mensajes, entonces la interfaz móvil desconectada no debe contener la función de edición. De lo contrario, este software está desperdiciando muchas horas al día de tiempo voluntario rastreando y revirtiendo y advirtiendo (no es que vean las advertencias) y bloqueando a los usuarios de IP de buena fe que son ajenos a las normas de la comunidad y este software está desperdiciando tanto tiempo dedicado por los nuevos editores que intentan ayudar pero no pueden acceder a comentarios sobre su edición. Saludos , KevinL ( también conocido como L235 · t · c ) 10:01, 28 de abril de 2021 (UTC)

Permítanme hacer más explícita una posición que sospecho que una amplia franja de la comunidad de Wikipedia en inglés puede apoyar: si la Fundación considera que no es práctico construir un sistema de comunicación para comunicarse con editores móviles desconectados, entonces los usuarios móviles desconectados deberían Se le pedirá que inicie sesión para editar. Wikipedia es un proyecto colaborativo; simplemente no podemos permitir que los usuarios editen sin poder comunicarse con ellos de manera efectiva. KevinL ( también conocido como L235 · t · c ) 10:05, 28 de abril de 2021 (UTC)

Absolutamente, gracias por la clara descripción de la situación. Estaba pensando en volverme deshonesto y simplemente bloquear cualquier usuario / IP no comunicativo después de una sola advertencia. Eso evitaría la mega frustración y la pérdida de tiempo y centraría las mentes en solucionar el problema en lugar de marcar casillas para la cantidad de nuevas ediciones de nuevos usuarios. Johnuniq ( charla ) 10:23, 28 de abril de 2021 (UTC)

@ DannyH (WMF) : Si solucionar todos los problemas va a llevar algún tiempo y no desea deshabilitar la edición por completo, ¿puede romper un poco más la aplicación de Android? Mira esto . Con ese truco, se puede transmitir un mensaje a los usuarios de iOS, pero no se puede hacer lo mismo para Android. No debería llevar mucho tiempo hacer el ajuste, que al menos permitiría un mecanismo personalizado para comunicar un mensaje a los editores de Android. Quizás dirigiéndoles a iniciar sesión a través de la aplicación de su navegador, por ejemplo. ProcrastinationReader ( charla ) 03:16, 30 de abril de 2021 (UTC)

Hola a todos, gracias por publicar más pensamientos. Como de costumbre, hay muchas cosas a las que responder aquí.

Es cierto que las aplicaciones tardan en incluir funciones de página de discusión. Eso es en parte porque no teníamos una estrategia clara sobre cómo podríamos mejorar las páginas de discusión en todo el sitio; sabíamos que queríamos mejorar la usabilidad de las páginas de discusión, pero el proyecto Flow no tuvo éxito y sabíamos que necesitábamos encontrar una nueva dirección. Determinamos esa nueva dirección con la Consulta de páginas de conversación a mediados de 2019, y luego el equipo de edición comenzó su proyecto de páginas de conversación para crear herramientas para responder , iniciar nuevas discusiones y recibir notificaciones cuando las personas comentan en secciones específicas de la página de conversación. (Si aún no lo ha hecho, puede activar las nuevas herramientas para responder e iniciar nuevas discusiones en la pestaña de preferencias Beta ).

Como parte de ese proyecto, el equipo de edición ha desarrollado la capacidad de dividir las conversaciones de wikitexto en comentarios individuales, y todo ese trabajo ahora informa el trabajo que los equipos de Android e iOS están haciendo para mejorar la experiencia de la página de discusión en las aplicaciones. también.

Ahora, una de las cosas que hacemos cuando un equipo de producto está trabajando en una función es mirar tanto los números de uso como la tasa de reversión de las ediciones que se realizan con la función. Si la tasa de reversión es superior a la media, es evidente que hay un problema con la función que debemos solucionar.

Al comparar las tasas de reversión en computadoras de escritorio, dispositivos móviles y aplicaciones, vemos un patrón similar con los editores conectados y desconectados. En cuanto a los últimos 30 días en Wikipedia en inglés, las ediciones web móviles tienen una tasa de reversión más alta en comparación con las ediciones de escritorio. Eso es cierto tanto para los usuarios que han iniciado sesión (el 10,2% revierte en la web móvil al 3,7% en el escritorio) como para los editores de IP (el 35% revierte en la web móvil al 22% revierte en el escritorio). Las ediciones realizadas a través de las aplicaciones se acercan más a la tasa de reversión del escritorio. Para los usuarios de aplicaciones que han iniciado sesión, aproximadamente el 6,5% de las ediciones de la aplicación se revierten, en comparación con el 3,7% en el escritorio. Para los usuarios de aplicaciones IP, se revierte alrededor del 24% de las ediciones de la aplicación frente al 22% de las ediciones de IP en el escritorio. Entonces, si bien cada reversión es una pérdida de tiempo para alguien, no vemos que la edición de aplicaciones cause muchos más problemas que la edición de escritorio, especialmente en comparación con la web móvil.

Como dije anteriormente, el equipo de Android lanzó recientemente mejoras para las páginas de discusión el mes pasado y tiene planes de continuar trabajando en ellas, e iOS trabajará en las funciones de comunicación a finales de este año. Entonces, si bien esos equipos comenzaron tarde en estas características, actualmente están recibiendo atención.

Algunos puntos más específicos: Suffusion of Yellow, su sugerencia sobre ofrecer un mensaje por tiempo limitado es interesante, e inició una conversación en un par de equipos, así que gracias por mencionarlo. Para su pregunta sobre la suposición de que los dispositivos móviles se usan sobre la marcha: sí, definitivamente hay personas que usan dispositivos móviles en IP estables. Sin embargo, es mucho más probable que cualquier dispositivo móvil tenga una IP inconsistente que un dispositivo de escritorio.

En cuanto a las personas que ignoran los círculos rojos y desactivan las notificaciones automáticas, es cierto que la ceguera de los banners es muy fuerte y eso es un problema para los diseñadores web en general. Sin embargo, hemos descubierto que cuando alguien da un paso específico como desactivar las notificaciones automáticas, es probable que responder con notificaciones más grandes e insistentes no ayude.

Me alegra seguir hablando, si la gente tiene más preguntas o sugerencias. DannyH (WMF) ( charla ) 18:47, 30 de abril de 2021 (UTC)

Danny, estoy intrigado y desconcertado por tu declaración aquí. Hay personas aquí (y en muchas conversaciones anteriores) que expresan su frustración por la incapacidad de comunicarse con los usuarios. Algunas discusiones anteriores han sido sobre editores específicos que tienen una mezcla de ediciones constructivas y preocupantes, que son el tipo de editores a los que con frecuencia se puede ayudar a detener las ediciones preocupantes. Su respuesta, si la entiendo correctamente, es que debido a que no hay diferencia en las tasas de reversión para estos editores en comparación con los de otras plataformas, la falta de comunicación no importa. Esto podría ser cierto, pero sería un cambio radical en la cultura en términos de cómo manejamos la edición disruptiva y estaría en desacuerdo con otras iniciativas patrocinadas por la fundación, incluidas las obligaciones de ayudar a los nuevos usuarios en la UCoC. ¿Puedes ayudarme a entender dónde no consigo lo que estás diciendo o si entiendo lo que estás diciendo cómo nosotros, como comunidad enwiki, podemos cuadrar este círculo? Lo mejor, Barkeep49 ( charla ) 19:17, 30 de abril de 2021 (UTC)

Hola Barkeep49 : Lo que compartí sobre la tasa de reversión fue en respuesta a un par de cosas. Primero, Johnuniq comentó el hecho de que solo había hablado de las ediciones de los usuarios de la aplicación y no reconocí el impacto en la comunidad de editores que tiene que arreglar un desastre. (La parte sobre "marcar casillas para la cantidad de nuevas ediciones de nuevos usuarios"). También fue una respuesta a la sugerencia hecha en algunos lugares de que las aplicaciones no deberían permitir la edición si las funciones de comunicación no están disponibles en el escritorio. estándar. Mi punto es que intentamos tener en cuenta el impacto en la comunidad, asegurándonos de que las funciones que creamos no provoquen un desorden notablemente mayor que el desorden que ya existe.

Pero sí, esta conversación se trata principalmente de llegar a editores específicos que podrían recibir ayuda para dejar de hacer ediciones preocupantes. Estoy de acuerdo en que las funciones de comunicación son importantes, y ambos equipos de aplicaciones han estado y seguirán trabajando en las funciones de comunicación. Algunos de los problemas de los que estamos hablando ya se han abordado en Android; Creo que en el caso mencionado en el hilo de la página de discusión de Jimbo, habrían recibido notificaciones de la página de discusión a partir del 30 de marzo, pero lamentablemente fue demasiado tarde para comunicarse con ese usuario. Estas conversaciones nos han inspirado a hablar más sobre las funciones de comunicación como equipo de producto, y agradezco a las personas que lo han mencionado aquí. -  DannyH (WMF) ( charla ) 20:37, 3 de mayo de 2021 (UTC)

DannyH (WMF) , el sitio de escritorio es completamente funcional en dispositivos móviles modernos. La solución a este problema es cerrar todas las aplicaciones y sitios que no son completamente funcionales, y redirigir a todos los usuarios al sitio de escritorio, que debería ser renombrado como "sitio completamente funcional". Eso ahorraría enormes cantidades de dinero y atraería a un gigantesco grupo mundial de nuevos editores a los sitios web de conocimiento gratuito de WMF. En este momento, estamos erigiendo barreras para la colaboración con personas que editan con dispositivos móviles, y eso es terriblemente triste. Hablo como un editor que ha estado editando y más recientemente administrando con teléfonos inteligentes Android durante diez años. Más del 99% de mis ediciones se realizan en teléfonos inteligentes. La WMF está gastando grandes cantidades de dinero en un problema que no existe y empeorando las cosas en el proceso. Cullen ³²⁸ Vamos a discutirlo

Si bien esto puede haber sido hipotético, personalmente me opondría a tal propuesta, únicamente porque si bien el sitio para computadoras de escritorio es funcional en dispositivos móviles, el texto sigue siendo realmente pequeño. La solución probablemente loca que viene a la mente de inmediato es cambiar la máscara del sitio al nuevo Responsive MonoBook, porque eso mostraría el contenido en un tamaño razonable en el dispositivo móvil y, presumiblemente, permitiría que los IP vean la barra naranja de Doom. (No lo he probado, pero supongo que funciona porque, a diferencia de Minerva, MonoBook es mantenido por la comunidad de edición). Además, hay algunos planes para hacer que Vector responda también, pero no sé nada al respecto. - codificador de Python  ( charla  |  contribuciones ) 22:19, 5 de mayo de 2021 (UTC)

Al menos un par de nosotros hemos estado en desacuerdo con tu punto de vista algunas veces, Cullen. El sitio de escritorio no está del todo bien optimizado y las aplicaciones ya son mejores para leer. La solución no es eliminar todo, sino solucionar los problemas. De todos modos, es una visión demasiado simplista; compare esto con esto en términos de tamaño de página. Quiero decir, la sugerencia simplemente no tiene en cuenta todos los proyectos de lenguaje y los usuarios globales, y es tan poco probable que suceda que distraiga de las soluciones reales, que en realidad es deshabilitar la edición en el ínterin / proporcionar una hoja de ruta, o al menos permitir que la comunidad lo haga si así lo desea por consenso. ProcrastinationReader ( charla ) 01:36, 6 de mayo de 2021 (UTC)

escucha Escucha. - Th e DJ ( hablar • contribuciones ) 08:35 6 de mayo 2021 (UTC)

Estoy de acuerdo en que destruir el móvil y obligar a todo el mundo a utilizar el escritorio es la solución incorrecta. Lo que mucha gente no comprende del todo es que no todo el mundo es como ellos. Asumen que debido a que tienen un teléfono inteligente de pantalla grande y una conexión rápida, entonces, por supuesto, todos lo tienen, y si un sitio web de escritorio funciona para ellos, entonces, por supuesto, funciona bien para todos los demás.

En el mundo real, algunas personas acceden a Wikipedia en viejos teléfonos plegables, teléfonos satelitales con grandes retrasos en los paquetes, teléfonos industriales resistentes con pantallas diminutas y computadoras antiguas que usan módems.

Recientemente terminé un diseño preliminar para un importante fabricante de juguetes que incluye un navegador web de muy bajo rendimiento con una pantalla realmente barata. Ese fue cancelado (el 90% de los juguetes que llegan al prototipo lo hacen) pero tarde o temprano verás algo similar en el pasillo de juguetes de Wal-mart por $ 29.95 USD. - Guy Macon ( charla ) 11:02, 6 de mayo de 2021 (UTC)

@ DannyH (WMF) : ¿esto es una broma o lo estoy entendiendo mal? ¿Está diciendo que es una elección de diseño deliberada que los editores de aplicaciones móviles no vean los mensajes que se les dejan? ¿Cómo sugiere que nos comuniquemos con CejeroC , o no importa que se esté desperdiciando el tiempo de miles de voluntarios (tanto novatos como experimentados)? - Bilorv ( conversación ) 23:33, 29 de mayo de 2021 (UTC)

Hola @ Bilorv : Creo que te estás malinterpretando un poco. Es una elección de diseño deliberada no mostrar notificaciones para editores de IP en la web móvil , porque existe una mayor probabilidad de que mostremos la notificación a la persona equivocada. Es más probable que alguien que se está moviendo haya realizado una edición web móvil, por lo que la notificación aparecerá para un lector aleatorio que esté captando la misma torre celular o acceso wifi. Estamos mostrando notificaciones para los editores que han iniciado sesión en la web móvil, y editores que han iniciado sesión y que han cerrado la sesión en las aplicaciones de Android e iOS.

CejeroC era un editor en la aplicación de Android, que agregó notificaciones de la página de discusión en algunos cambios realizados en febrero-marzo de 2021. Desafortunadamente, esto era demasiado tarde para las personas que intentaron comunicarse con CejeroC, pero debería ser más fácil contactar a los editores de aplicaciones de Android a partir de ahora. en. -  DannyH (WMF) ( conversación ) 18:35, 4 de junio de 2021 (UTC)

Gracias por la respuesta, DannyH (WMF) . Me alegro de haberlo entendido mal, ya que la otra opción era profundamente indeseable. Mis nuevas preguntas son las siguientes: ¿está diciendo que es una elección de diseño deliberada que los editores web móviles no registrados no vean los mensajes que se les dejan? ¿Dónde puedo ver los datos de WMF sobre el porcentaje de mensajes de la página de conversación de IP que habría visto alguien que no era el objetivo previsto, en comparación con el porcentaje que habría visto el objetivo previsto? ¿Y cómo debería un voluntario intentar ponerse en contacto con un editor de IP etiquetado como que realiza ediciones web móviles, particularmente cuando la IP ha sido claramente estática durante un período de tiempo no trivial (según la duración de las contribuciones del editor)? - Bilorv ( conversación ) 18:57, 4 de junio de 2021 (UTC)

@ Bilorv : Ojalá pudiéramos obtener datos sobre quién ve qué notificaciones; haría la vida más fácil. Desafortunadamente, no lo sabemos. (Hay muchas estadísticas que normalmente recopilan otros sitios web importantes que no recopilamos por respeto a la privacidad de los usuarios). El juicio que estamos tomando en este momento se basa en nuestro entendimiento de que una gran cantidad de Las IP se mueven y son inalcanzables incluso en el escritorio, y ese problema obviamente se magnifica para las IP móviles. Para la pregunta de cómo un voluntario podría ponerse en contacto con un editor de IP móvil estable, una posible solución sería dejarle un mensaje en la página de discusión del IP y luego, cuando revierte una de sus ediciones, coloca un enlace a su página de discusión en el resumen de edición. Obviamente, eso es un truco, pero los editores de IP que tienen una página de discusión es una especie de truco. - DannyH (WMF) ( conversación ) 20:58, 8 de junio de 2021 (UTC)

No creo que los usuarios en los que estoy pensando sepan que hay un historial de páginas; de hecho, a menudo veo comportamientos que me hacen pensar que "mi edición no se realizó, por qué no aparece cuando ¿Miro de nuevo unas horas más tarde? " después de una reversión (y no creo que el diseño haga que el historial de la página sea obvio). Necesito enviar una gran pancarta que diga "ALGUIEN ESTÁ INTENTANDO HABLAR CON USTED SOBRE LA EDICIÓN QUE HIZO" para llamar la atención. Desafortunadamente, no existe tal funcionalidad. Aprecio la privacidad que se brinda a los lectores y editores, pero usted está tomando una decisión basada en no mucho, ciertamente no en lo que la comunidad quiere, y el uso de un sistema basado en IP de 2001 no es la base sólida para la comunicación que necesito. . (Entiendo que WMF planea anonimizar las direcciones IP, pero no cambiarlas como método para rastrear contribuyentes no registrados). No necesariamente quiero que comencemos a rastrear personas con cookies, así que sé que todas las soluciones tienen una desventaja, pero esta situación es honestamente ridículo. Gran parte de mi tiempo lo desperdicio enviando mensajes a personas que nunca lo verán, y la alternativa es simplemente deshacer lo que hicieron sin explicación (¿qué mensaje es ese para enviar a un recién llegado? ¿Cómo podemos involucrar a los nuevos editores haciendo ¿que?). - Bilorv ( conversación ) 21:25, 8 de junio de 2021 (UTC)

@ Bilorv : Como usted dice, el sistema de comunicación basado en IP de 2001 es muy defectuoso. El gran banner f'off ni siquiera funciona para los editores de IP de escritorio con demasiada frecuencia, porque las IP cambian, o simplemente porque la persona que realiza las ediciones no comprende o no responde a los mensajes de la página de discusión. Para los editores de IP móviles, es incluso menos probable que establezca una conexión. Creo que si las personas que crearon MediaWiki hace veinte años lo estuvieran creando hoy, probablemente no usarían direcciones IP como base para la comunicación, pero este es el sistema heredado que tenemos.

Creo que el trabajo que está haciendo el equipo de Herramientas contra el acoso en el "enmascaramiento de IP" ayudará con esto, especialmente si usamos cookies en dispositivos móviles para asociar el dispositivo con un nombre de usuario generado automáticamente. Queda mucha planificación y discusión por hacer en el proyecto de enmascaramiento de IP, y descubrir cómo comunicarse con los editores de IP "enmascarados" será una de las muchas cosas por resolver. -  DannyH (WMF) ( conversación ) 22:42, 9 de junio de 2021 (UTC)

@ DannyH (WMF) :Estamos mostrando notificaciones para ... editores conectados y desconectados en las aplicaciones de Android e iOS. ¿Me pueden vincular a la tarea phab donde se solucionó la falta de notificaciones de iOS? No tengo un dispositivo iOS a mano y phab: el T274404 y sus subtareas sugieren que el trabajo apenas está comenzando. Además, la aplicación de Android todavía no me muestra ninguna alerta para los mensajes de la página de conversación que no se conectó. Y al menos nadie ha respondido a mi simple pregunta en phab: T95396 . Entonces, ¿qué me he perdido? Suffusion of Yellow ( charla ) 19:37, 6 de junio de 2021 (UTC)

@ Suffusion of Yellow : Lo siento, tienes razón sobre iOS. Revisé mi propia publicación en la parte superior de la sección y me di cuenta de que cometí un error cuando respondí a Bilorv. Android ya ha realizado los cambios; iOS está comenzando con ese trabajo. Miré su pregunta en ese boleto, que creo que no era el boleto correcto para ese informe de error; parece que ese boleto se cerró en mayo de 2020 y, de todos modos, es posible que no haya sido el boleto correcto. Solo le pedí al primer ministro que le echara un vistazo y me dijera dónde debería ir ese informe; Te avisaré cuando reciba una respuesta. - DannyH (WMF) ( conversación ) 21:06, 8 de junio de 2021 (UTC)

Ah, veo que ya hiciste esa conexión en el teléfono móvil: T276147 . Al menos eso pienso. Avísame si no estoy en lo correcto. - DannyH (WMF) ( conversación ) 21:22, 8 de junio de 2021 (UTC)

@ DannyH (WMF) : Tengo entendido que todavía hay un subconjunto de editores móviles desconectados que no reciben notificaciones de la página de discusión, pero todavía están editando. Esto es inaceptable.

Como se indicó anteriormente, si una interfaz no tiene capacidades de comunicación básicas, entonces la interfaz no debería tener capacidades de edición. - DB1729 ( conversación ) 02:17, 8 de junio de 2021 (UTC)

@ DB1729 : Entiendo su consternación; Estoy de acuerdo en que la comunicación es esencial para una colaboración wiki productiva. Creo que, en el fondo, esto es en realidad una falla en el concepto de permitir que las personas editen sin una cuenta en Wikipedia. Hace veinte años, puede haber sido más o menos exacto asumir que las direcciones IP eran en su mayoría estables, porque todos tenían un escritorio y principalmente una conexión de acceso telefónico, por lo que si publicaba un mensaje para una dirección IP en particular, era probable que se comunicara con el misma persona. Hoy en día, el uso de computadoras portátiles en puntos de acceso wifi y teléfonos y tabletas que utilizan el servicio celular básicamente ha roto ese modelo. Hace unos años, llegamos al punto en que las páginas vistas desde dispositivos móviles alcanzaban el 50% de nuestro tráfico, y ahora la mayoría de los lectores de Wikipedia acceden a nuestro sitio con un dispositivo móvil.

Creo que su sugerencia de restringir la edición de IP en dispositivos móviles es interesante, y es posible argumentar que eso debería aplicarse tanto a computadoras de escritorio como a dispositivos móviles. Pero esa es una conversación mucho más importante y no creo que podamos resolverlo aquí. -  DannyH (WMF) ( conversación ) 21:19, 8 de junio de 2021 (UTC)

No tengo los datos, pero las ediciones que hago con mi teléfono generalmente provienen de la misma IP (mi wifi de casa o del trabajo) de donde provienen las ediciones de mi escritorio. (Yo uso monobook sensible, por lo que las ediciones de mi teléfono cuentan como "escritorio"). Lo que inhibe la comunicación con algunos editores móviles no es que su IP cambie, es que el software que usan no es adecuado para su propósito. ¿Conoce a alguna de las personas que puedan arreglar el software? - Kusma ( charla ) 08:28, 10 de junio de 2021 (UTC)

# sugetededit-add 1.0

Seguimiento en Phabricator
Task T227623

Creo que sería una buena idea mencionar también lo que creo que es el problema relacionado con el proceso # sugertededit-add 1.0, ya que esto parece una idea móvil. Véase, por ejemplo, Jomart Allaguliyev  ( talk  · contribs ), un nuevo usuario móvil que ha realizado más de 1000 ediciones exclusivamente a través de este proceso. La mayoría están bien, pero algunas están equivocadas y algunas son casi absurdas . ¡A veces vuelven a hacer y empeoran su propio mejor trabajo! [32] [33] . También hicieron un par de veces la misma edición dos veces después de haber sido revertida [34] [35] , lo que se siente como si algo surgiera y simplemente repitieran la acción. La única documentación parece estar en Wikidata , por lo que no está claro cómo están sucediendo exactamente o de dónde están sucediendo. Hay una antigua tarea de Phab (T227623) cerrada que sugiere que el proceso está funcionando según lo previsto. CMD ( charla ) 02:42, 22 de abril de 2021 (UTC)

Estoy confundido acerca de cómo este es un problema sugerido. Ese editor recibió exactamente una advertencia, por lo que yo sé. Si un editor está editando de manera disruptiva, el primer paso es notificarlo en su página de discusión, ¿no es así? (Además, he arreglado su enlace roto arriba.) - Jonesey95 ( hablar ) 04:26, 22 de abril de 2021 (UTC)

Gracias por la solución. El usuario no está editando de forma disruptiva, en general. El punto es que las ediciones de este usuario están siendo guiadas únicamente por algún programa que proporciona sugerencias de edición a los nuevos usuarios, proporcionado por WMF, del cual parece haber poca documentación. ¿Cómo no es un problema de edición sugerido, cuando se presume que cualquier interrupción potencial se debe a esta función? Sería bueno tener documentación. Si los resúmenes de edición se generan automáticamente, ¿por qué no incluyen un wikilink a dicha documentación? Las preguntas frecuentes de Mediawiki solo establecen que es para "Agregar descripciones breves a los artículos a los que les faltan descripciones", lo que claramente no es el caso dado que se trata de ediciones de descripciones breves existentes. CMD ( charla ) 09:14, 22 de abril de 2021 (UTC)

Nuevo récord anual de recaudación de fondos de WMF después de solo nueve meses

Desarrollo financiero de la Fundación Wikimedia (en dólares estadounidenses), 2003-2020
Negro: Activos netos (excluyendo la Dotación de Wikimedia, actualmente a más de $ 90 millones)
Verde: Ingresos (excluyendo las donaciones de terceros a la Dotación de Wikimedia)
Rojo: Gastos (incluidos los pagos de WMF a Dotación de Wikimedia)

La Fundación Wikimedia ha recaudado 142 millones de dólares en los primeros tres trimestres de este año financiero, más de lo que se llevó durante los doce meses del año anterior. Eso es según una revisión trimestral del tercer trimestre (de enero a marzo de 2021) del año financiero de WMF (que comenzó el 1 de julio de 2020 y finalizará el 30 de junio de 2021). La meta del año original era de $ 108 millones (gastos planificados coincidentes en el plan anual); en el segundo trimestre, se elevó a $ 125 millones. Para el 31 de marzo, la WMF también había superado este objetivo revisado, en $ 17 millones. (Tenga en cuenta también que el año pasado la WMF gastó menos de lo esperado, debido a que se cancelaron muchos eventos. Esto es lo que lo llevó a guardar $ 9 millones en un nuevo fondo de Tides Advocacy, ya que la gente no sabía qué más hacer con el dinero . la pandemia mundial en realidad se aceleró durante los últimos 10,5 meses, uno esperaría que volvieran a ocurrir las mismas cancelaciones).

Además de los 142 millones de dólares, en los primeros tres trimestres del año también se han añadido 18,6 millones de dólares a Wikimedia Endowment . Establecida en 2016, la Dotación estaba en $ 90 millones a principios de año; será llegar a sus diez años de meta - $ 100 millones - cinco años antes.

En estos momentos, hay banderas de recaudación de fondos runnning en América del Sur: 1 2 3 4 . Según un artículo del Washington Post publicado la semana pasada, "América del Sur lidera el mundo en nuevos casos y muertes per cápita". A los lectores se les pide que "defiendan la independencia de Wikipedia", diciendo que hoy se requiere una donación para que la WMF pueda continuar protegiendo dicha independencia. Los banners añaden que es el 2% de los lectores que donan lo que garantiza que Wikipedia siga siendo accesible para todos. También agregan que al donar dinero a la WMF, las personas pueden decirles a los voluntarios que su trabajo es importante.

Ahora, dado que la WMF ya había excedido su objetivo original de recaudación de fondos en $ 34 millones hace seis semanas, ¿la gente siente que eso está éticamente bien? - Andreas JN 466 08:32, 17 de mayo de 2021 (UTC)

Enlace relevante: WP: CANCER - codificador de Python  ( charla  |  contribuciones ) 16:40, 17 de mayo de 2021 (UTC)

No sé si éticamente está bien. Eso depende de cómo se gaste el dinero. El trabajo adecuado de la WMF debería ser proporcionar la infraestructura necesaria para respaldar sus proyectos y garantizar que todos los proyectos se ejecuten de acuerdo con sus obligaciones legales como organización benéfica y que no sean asumidos por personas que lo deseen. para excluir a otros en base a atributos que nada tienen que ver con sus objetivos. La impresión que tengo es que gasta su dinero en perpetuar y expandir los muchos puestos remunerados en su burocracia en lugar de estos. La independencia y la accesibilidad se pueden garantizar con mucho menos dinero. Phil Bridger ( charla ) 17:54, 17 de mayo de 2021 (UTC)

Como autor de WP: CANCER , durante varios años he estado pidiendo a la WMF que haga lo siguiente:

• Haga que el gasto sea transparente, publique una cuenta detallada de en qué se está gastando el dinero y responda cualquier pregunta razonable pidiendo más detalles.
• Limite los aumentos del gasto a no más que la inflación más un porcentaje (ajustado por cualquier aumento en las visitas a la página), incluso si el límite es "no gastar más de diez veces lo que gastamos el año pasado".
• Acumule nuestra dotación y estructure la dotación de modo que la WMF no pueda recurrir legalmente al capital cuando los tiempos se pongan malos.

Las tres recomendaciones han sido rechazadas de plano o respondidas con afirmaciones ridículamente falsas de que ya se están haciendo.

Por ejemplo, me han dicho que las palabras "Gastos de servicios profesionales: $ 8,998,26" y "Otros gastos operativos $ 9,005,744" cumplen con el requisito de "publicar una cuenta detallada de lo que se está gastando el dinero" y que apuntan a esas dos líneas items es "responder cualquier pregunta razonable pidiendo más detalles".

También me han dicho que el hecho de que exista una cuenta etiquetada como "dotación" cumple con el requisito de "estructurar la dotación de modo que la WMF no pueda recurrir legalmente al capital cuando los tiempos se pongan malos".

Si hacemos estas cosas ahora, en unos pocos años podríamos estar en condiciones de hacer todo lo que estamos haciendo ahora mientras vivimos de los intereses de la donación, y no tendríamos necesidad de recaudar más fondos. O podríamos seguir recaudando fondos, usando las donaciones para hacer muchas cosas nuevas y útiles, sabiendo que hagamos lo que hagamos allí hay un flujo de ingresos garantizado de la donación que mantendrá los servidores funcionando indefinidamente. - Guy Macon ( charla ) 19:20, 17 de mayo de 2021 (UTC)

En 2020, la masa salarial se expandió> 20% a> $ 55 millones, por lo que pasará mucho tiempo antes de que una dotación sea adecuada. EddieHugh ( charla ) 22:14, 17 de mayo de 2021 (UTC)

En 2010, el gasto total para todo fue de diez millones. Estuve aquí en 2010. No me di cuenta de que Wikipedia no podía funcionar porque gastaban muy poco. - Guy Macon ( charla ) 12:05, 18 de mayo de 2021 (UTC)

Guy , la Fundación puede esperar ganar más de $ 10 millones en intereses anuales a partir de ahora, en base a la dotación de $ 100 millones que tiene con Tides y otros 100 millones de inversiones que tiene en su propio nombre. Si bien esto no paga a más de 500 empleados y contratistas, ya es suficiente para garantizar la "sostenibilidad real de la misión de Wikimedia", según escribió Erik Möller en 2013. - Andreas JN 466 10:51, 18 de mayo de 2021 (UTC)

Eso supone que la dotación de $ 100 millones no desaparece. Así es como puede y cómo podemos prevenirlo.

Supongamos, en aras del argumento, que llega el día en que el gasto se vuelve mayor que los ingresos. Esto podría suceder debido a un escándalo que haga que las contribuciones se caigan por un precipicio. O los ingresos se estabilizan mientras el gasto sigue aumentando. O perdemos una gran demanda y nos vemos obligados a pagar una sentencia de $ 300 millones. O tenemos otra gran depresión. O hiperinflación. O tal vez algún futuro CEO decide intentar competir con Google en el espacio de los motores de búsqueda, nuevamente.

Suponga que la WMF ve el déficit pero asume que es temporal. Después de todo, a todo el mundo le encanta tener reuniones en destinos de vacaciones exóticos, y todos esos empleados son absolutamente esenciales, ¿verdad? Seguramente no querrás que despidamos a nuestros amigos, monstruo. Entonces se sumergen en los ahorros. Después de todo, para eso están los ahorros.

Ahora suponga que queman todos los ahorros y persiste el déficit.

Si me saliera con la mía, no podrían agotar la investidura. Tendrían que vivir de las donaciones que aún reciban más una gran cantidad de intereses de la donación. Pero no pudieron gastar el principio. Resultado: Wikipedia sobrevive.

De la forma en que están configuradas las cosas ahora, podrían agotar la dotación para mantener el gasto. Cuando eso se acaba, es vender activos y despedir tiempo a la gente, a menos que puedan pedir prestado dinero y, por lo tanto, seguir gastando más de lo que reciben. Hay abogados inteligentes que podrían hacerlo para que la WMF enciclopedia como garantía. ¿Cuánto crees que pagaría Google por poseer Wikipedia? Resultado: wikipedia ahora es propiedad de una corporación.

Todo esto podría evitarse si sólo la WMF estructurara la dotación de modo que la WMF no pueda recurrir legalmente al capital cuando los tiempos se pongan malos. Sin embargo, se niegan a hacer eso (oa veces mienten y dicen que ya lo han hecho, pero guardan silencio cuando se les pide que proporcionen un acuerdo legalmente vinculante que diga que no pueden tocar el principio). Te hace preguntarte por qué se resisten a la idea, ¿no es así? - Guy Macon ( charla ) 12:05, 18 de mayo de 2021 (UTC)

Guy , ninguna disposición de ese tipo es férrea. Por ejemplo, tenga en cuenta: "En casos de dificultades económicas extremas, el tribunal puede otorgar un alivio cy pres permitiendo que una organización benéfica invada un fondo de dotación para cumplir con las obligaciones financieras de la organización". [36] (Tal como está, algunos de los fondos vendrán con restricciones de donantes). Lo mejor: Andreas JN 466 17:15, 22 de mayo de 2021 (UTC)

Estoy bien con la doctrina Cy-près o, de hecho, con cualquier situación en la que la WMF pueda sumergirse en el principio solo después de que un juez apruebe hacerlo. En este momento, la WMF se niega incluso a intentar imponer restricciones sobre el drenaje de la dotación. Adelante, pregúntales. Pídales que le muestren cualquier acuerdo, contrato, estatuto o cualquier otro documento que imponga alguna restricción sobre el gasto de la dotación en lo que elijan. Estaría feliz de informar que estaba equivocado. - Guy Macon ( charla ) 17:50, 22 de mayo de 2021 (UTC)

Estoy bastante convencido de que tienes razón. Es muy probable que existan algunas restricciones que se apliquen ahora, debido a lo que especificaron los donantes, y algunas regulaciones de UPMIFA que limitan lo que se puede hacer con el dinero, pero al igual que usted, no he visto ningún compromiso de WMF de que el director permanecerá intacto excepto por cy près. casos. Y estoy de acuerdo en que ese compromiso sería algo bueno. Lo que también es importante a corto plazo es la forma que tomará la nueva organización benéfica 501c3; como saben, la donación completa, los $ 100 millones, pronto se devolverán a la WMF para que se destinen a una organización benéfica independiente. Dije en la lista de correo hace algunas semanas que sería bueno si la WMF pudiera compartir los detalles legales de esa organización prevista, sin respuesta. Si todos los fondos se devuelven a la WMF, ¿está la WMF legalmente obligada a establecer la nueva organización benéfica como una donación? - Andreas JN 466 11:11, 23 de mayo de 2021 (UTC)

"Tengo aquí una bolsa vacía, capaz de contener £ 100,000. Como quiero esa cantidad, simplemente coloco la bolsa sobre la mesa, susurro las palabras mágicas 'Gordon', 'Khartoum', cuando, ¡listo! Encontraremos la bolsa está llena ". También se adapta a la recaudación de fondos de Wikipedia. Simplemente reemplace las palabras Gordon y Khartoum con "realmente necesito dinero hoy para proteger la independencia de Wikipedia". Excepto que las bolsas de dinero de WMF no tienen fondo.

Honestamente, esto es lamentable y está mal. Las recomendaciones de Guy parecen completamente razonables. No estoy muy familiarizado con las finanzas, las donaciones, etc., pero si esta cantidad de dinero está llegando, ¿tal vez podría usarse para donaciones, servidores, etc.? Honestamente, estoy confundido sobre los gastos de WMF. EpicPupper ( charla ) 16:23, 18 de mayo de 2021 (UTC)

Podría asignar el 0.1% de eso para contratar a más personas para corregir errores y trabajar en proyectos como Implementar alertas de artículos en otras wikis y otras cosas de las listas de deseos de la comunidad. Demonios, vamos a volvernos locos. Vamos por el 0,2% . Headbomb { t · c · p · b } 01:23, 21 de mayo de 2021 (UTC)

Eso es una locura. ¿Quién dejó entrar a este tipo? "Arreglando errores" de hecho. ¡Le digo buenos días señor!

Desaprobar la nutria desaprueba  :) - Guy Macon ( charla ) 14:27, 23 de mayo de 2021 (UTC)

He sido fideicomisario de una organización benéfica con una donación, hay una desventaja en la idea de no poder echar mano del principal. Para invertir a largo plazo, es necesario que la mayoría de los activos estén en acciones o bienes raíces, activos que funcionan bien a largo plazo pero que tendrán años buenos y malos. En el mediano y largo plazo, esto superará al dejar el dinero en el banco y solo recibir intereses, pero habrá años en los que el fondo se reduzca un poco. El mantenimiento del valor a largo plazo en términos reales se puede hacer de varias maneras, incluida la inversión de parte del fondo en acciones y el uso de los dividendos como ingresos, estableciendo un piso para el fondo por debajo del cual los fideicomisarios no pueden o no deben prescindir de un acuerdo unánime. votar, o tener un piso que aumenta en línea con la inflación y las reservas no gastadas en el fondo que brindan un colchón contra años malos. Pero si vamos a obtener algo útil de tener este fondo, como la capacidad de comprometernos con las instituciones que están considerando cargas masivas en Wikimedia Commons, los bienes comunes estarán presentes en el futuro previsible; No desea configurar el fondo de tal manera que cada década, cuando el mercado tenga una recesión, tenga uno o tres años en los que no pueda obtener nada de la dotación. Un rendimiento a largo plazo del 3% no es descabellado, pero para que sea útil es necesario establecer una dotación para que pueda seguir otorgando subvenciones durante una recesión. Ϣere Spiel Checkers 20:22, 22 de mayo de 2021 (UTC)

No sigo tu razonamiento allí. Si invade la investidura, solo empeora la situación para los años futuros difíciles. La idea general de la dotación es tener un ingreso anual mínimo por intereses. - Andreas JN 466 11:16, 23 de mayo de 2021 (UTC)

( editar conflicto ) Esa es ciertamente la promesa hecha en [ https://wikimediaendowment.org/ ].

"Wikimedia Endowment es nuestro compromiso duradero con un mundo de conocimiento compartido libremente, ahora y para siempre".

También

"El propósito de Wikimedia Endowment es apoyar los proyectos de Wikimedia a perpetuidad. [Esto] garantiza la seguridad a largo plazo. Un Endowment sólido también brinda a la comunidad de voluntarios y donantes de Wikimedia la confianza de que la misión y la visión en las que han invertido recibir apoyo para las generaciones futuras ".

El diablo siempre está en los detalles. En la parte inferior de [ https://wikimediaendowment.org/ ] dice:

"Tides o la Fundación Wikimedia pueden optar por transferir la Dotación de Tides a la Fundación Wikimedia, u otras organizaciones benéficas identificadas por la Fundación Wikimedia que participan en actividades que promueven el propósito de la Dotación Wikimedia. Después de cualquier transferencia, la Dotación continuaría actuando para el propósito de ser un fondo permanente de generación de ingresos para apoyar los proyectos de Wikimedia ".

La mayoría de la gente lectura que suponer que significan la financiación de las actividades básicas que mantienen Wikipedia, Wictionary, etc. en el Internet. Pagar por los servidores y el ancho de banda, financiar el número mínimo de empleados en el área legal y contable para seguir siendo una organización benéfica y responder a las demandas, solucionar errores de seguridad en el software, ese tipo de cosas.

¿Pero realmente dice eso? ¿Dice "Mantenga Wikipedia en funcionamiento" o dice "Apoye los proyectos de Wikimedia"? Ya teníamos un CEO que comenzó a gastar en secreto una gran cantidad de dinero en efectivo en un "proyecto Wikimedia" para desarrollar un motor de búsqueda para competir con Google y Bing. Literalmente, cualquier cosa puede declararse como proyecto de Wikimedia.

Deberíamos tener un acuerdo legalmente vinculante de que el principio de la dotación no debe gastarse y que el interés de la dotación debe gastarse para mantener los proyectos actualmente enumerados en [ https://www.wikipedia.org/ ] en funcionamiento e independientes.

Tenga en cuenta que la WMF también tiene aproximadamente $ 100 millones de dólares en inversiones no patrimoniales. Deberían seguir siendo libres de gastar ese dinero en cualquier cosa que elijan. Pero si la WMF la caga, gasta todos esos $ 100 millones de dólares en ahorros y luego trata de agotar la dotación para evitar vivir con un presupuesto como el resto de nosotros tenemos que hacer, deberían tener que ir ante un juez, presentar un caso. que el gasto es necesario para mantener los proyectos actualmente enumerados en [ https://www.wikipedia.org/ ] en funcionamiento e independientes, y obtener el permiso del tribunal según la doctrina Cy-près . Así que dime; ¿Pedirle a la WMF que esté de acuerdo con esto es una solicitud irrazonable? ¿Pedirles que expliquen por qué se niegan a discutir esto es una solicitud irrazonable? Sólo digo. - Guy Macon ( charla ) 14:10, 23 de mayo de 2021 (UTC)

Solo obtiene intereses si presta el dinero en lugar de invertirlo. Sería irresponsable prestar una dotación en lugar de invertirla en activos como acciones y participaciones. Tal vez prestaría una parte si fuera cauteloso o si tuviera aversión al riesgo. Pero incluso si pone parte de la dotación en bonos de interés fijo, el valor de esos bonos subirá y bajará. Entonces, si el fondo se invirtiera parcialmente en bonos del gobierno, recibiría pagos de intereses por poseer esos bonos. Pero si tuviéramos un pico en la inflación y las tasas de interés subieran, entonces el dinero por el que podrías vender esos bonos caería y el valor de la dotación bajaría. Además, los dividendos o intereses son parte de la dotación, necesita parte de ellos para mantener el valor de la dotación en términos reales. Si configura su dotación de modo que todos los intereses y dividendos se traten como dinero que podría desembolsarse, entonces su fondo está prácticamente garantizado para disminuir con el tiempo. Ϣere Spiel Checkers 13:44, 23 de mayo de 2021 (UTC)

Es cierto, pero hagamos que acepten no sumergirse en el principio antes de centrarse en dónde va el interés. Pequeños pasos. :) - Guy Macon ( charla ) 14:13, 23 de mayo de 2021 (UTC)

Ya sean intereses o dividendos (o cualquier ingreso que desee), el principio sigue siendo que si desea convencer a otros, por ejemplo, de que Commons está aquí para quedarse, nunca se debe indagar en el capital de la dotación. Si la dotación puede evaporarse, no se puede argumentar que garantiza la existencia de los Comunes a perpetuidad. Y sí, se debe retener parte de los intereses y dividendos para que la dotación mantenga su valor en términos reales. (La WMF ha estado enviando correos electrónicos pidiendo a las personas que los incluyan en su testamento. Por lo tanto, es probable que el capital aumente naturalmente ...) - Andreas JN 466 14:37, 23 de mayo de 2021 (UTC)

Mi objeción es a su sugerencia de que nunca se puede sumergir al director. Una dotación subirá y bajará de valor a medida que fluctúe el mercado de valores o cualquier cosa en la que se invierta. Mantener ese principio en términos reales durante un período de décadas o incluso siglos es una cosa. No poder otorgar subvenciones durante dos o tres años después de una caída del mercado de valores sería un problema. Hay varias formas de evitar esto, pero una que desea evitar es establecer un principio de que "el principal nunca puede ser sumergido". Fui fideicomisario de una organización benéfica con una donación durante los años del colapso bancario de 2008 . Mantuvimos nuestros nervios y continuamos otorgando subvenciones durante esos años, pudimos hacerlo porque nuestro objetivo era mantener el valor de la dotación a largo plazo, pero aceptamos que fluctuaría en el corto plazo. Hay varias formas de hacerlo, incluido el establecimiento de un piso en el valor del fondo o vincularlo a varios índices bursátiles. Lo importante es evitar comprometerse como "nunca se puede sumergir al director". Ϣere Spiel Checkers 15:43, 23 de mayo de 2021 (UTC)

Te entiendo. - Andreas JN 466 16:17, 23 de mayo de 2021 (UTC)

Yo no veo su punto. Puedo ver el punto en el caso en el que una donación está otorgando subvenciones de manera regular, pero no hay necesidad de hacerlo cuando tiene cien millones en la donación, cien millones adicionales en el banco y los ingresos nunca se han registrado. menor que los gastos. Básicamente, la donación de WMF no está ahí para otorgar subvenciones. Está ahí para asegurar la supervivencia de Wikipedia.

No confío en que todos los futuros gerentes y miembros de la junta de WMF no agoten la dotación para retrasar temporalmente los recortes de gastos necesarios. Es demasiado fácil mirar el comienzo de un declive de varios años y decir "esto es solo un error temporal. Las donaciones han bajado, quemamos nuestros cien millones en el banco y ahora no podemos permitirnos nuestro enorme plan Wikimania en una estación de esquí en los Alpes suizos. Paguémoslo con la donación. Lo devolveremos cuando las cosas se pongan mejor, lo prometemos con el meñique ". - Guy Macon ( charla ) 16:46, 23 de mayo de 2021 (UTC)

En realidad, ahora son más de 200 millones de dólares en el banco. [37] En total, hay $ 100 millones + con Tides (no incluido en esa página) y $ 200 millones + en inversiones a corto / largo plazo y efectivo ($ 180 millones que se muestran en esa página, pero agregue el hecho de que esto El año fiscal ya ha superado el gasto presupuestado según el plan anual en más de $ 34 millones, y la WMF todavía está recaudando fondos como si estuviera en su último centavo, y ya está). Sólo digo'. - Andreas JN 466 17:30, 23 de mayo de 2021 (UTC)

Para el punto de WSC, ninguna institución importante (es decir, aquellas con una dotación del tamaño de la fundación) de la que yo tenga conocimiento gestiona su dotación sobre una base "legalmente obligada a no tocar nunca el principio". El efecto práctico de esto sería gastar menos que el interés total en un año dado porque los retornos de inversión fluctúan mucho y no desea contratar personas o comprometerse a gastar de otra manera que no pueda pagar de manera continua. Al menos con la junta / administración actual, lo que vimos con la pandemia es que el gasto se redujo drásticamente, y en retrospectiva innecesariamente, por temor a que las donaciones se agotaran. Eso no sucedió, pero las secuelas de esa decisión condujeron a los hechos que iniciaron este hilo. Entonces, en esencia, el enfoque conservador y cauteloso de la fundación para la elaboración de presupuestos ahora se está aprovechando como una razón para esposarlos aún más. Tengo problemas importantes con la forma en que la fundación asigna sus recursos (y planeo preguntarle a los candidatos de la junta al respecto de alguna manera), pero esta crítica me parece injusta. Saludos , Barkeep49 ( charla ) 15:32, 24 de mayo de 2021 (UTC)

Re: "ninguna institución importante (es decir, aquellas con una dotación del tamaño de la fundación) de la que tenga conocimiento gestiona su dotación sobre una base 'legalmente obligada a no tocar nunca el principio'", mientras que las dotaciones no restringidas son comunes, también lo son las dotaciones donde no se puede tocar al director.

• "Según la ley, a Cornell no se le permite gastar el valor principal de la dotación, pero puede gastar una parte de los retornos de la inversión. Casi todos los $ 5.400 millones se invierten y, después de ajustar la inflación, se gasta una parte de los retornos de la inversión". [38]
• "La Whatcom Community Foundation (Fundación) existe, en parte, para administrar fondos dotados permanentemente por donantes para el beneficio de una causa benéfica específica ... Un fondo dotado es un fondo permanente, diseñado para trabajar a perpetuidad en beneficio de su organización. Su el capital no se distribuye y se invierte para mantener el poder adquisitivo del fondo a lo largo del tiempo ". [39]
• "Uno de los primeros puntos que la gente debe saber es que, si bien no se puede gastar el capital de la dotación a menos que el donante o el tribunal lo indique , normalmente se puede acceder a los ingresos del capital". [40]
• "La gran dotación de Wellesley es el resultado de donantes generosos y una gestión prudente durante muchos años. El valor de la dotación al 30 de junio de 2019 era de $ 2.2 mil millones. Se compone de unos 3.000 fondos de dotación individuales, la mayoría de los cuales tienen restricciones de gasto de los donantes. Las donaciones al fondo patrimonial se hacen generalmente de modo que los ingresos anuales obtenidos por el principal respalden una actividad como la ayuda financiera o una cátedra a perpetuidad. Los ingresos solo se pueden gastar para apoyar esa actividad y el principal no se puede gastar ". [41]
• "Las verdaderas dotaciones, que a menudo se denominan simplemente dotaciones, reflejan la intención histórica original del término. En una verdadera dotación, el donante transfiere activos a la institución que prohíbe gastar el principal. Las instituciones dependen de los ingresos de estos activos para proporcionar fondos para promover su propósito filantrópico ". [42]
• "Se retendrán todos los montos de capital y solo se gastará el ingreso o una parte del mismo " . [43]

- Guy Macon ( charla ) 17:34, 24 de mayo de 2021 (UTC)

Gracias por estos ejemplos Guy. Lo mejor, Barkeep49 ( charla ) 18:04, 24 de mayo de 2021 (UTC)

Tenga cuidado con lo que desea y sepa que puede que no ayude. El ejemplo de Cornell vinculado anteriormente es bueno. Su rendimiento fue de + 1,9%, pero el saldo general de su dotación se redujo de $ 7,3 mil millones a $ 7,2 mil millones (-1,4%). Es posible que no hayan gastado ningún capital, técnicamente, pero el resultado es el mismo. Imagine una dotación de $ 1,000 donde la mitad del capital tiene un rendimiento de + 100% (+ $ 500) y la mitad tiene un rendimiento de -100% (- $ 500). Gasta todos los ingresos de la inversión ($ 500). Su saldo final es de $ 500 (la mitad de lo que comenzó) y no ha tocado nada del capital. - Jonesey95 ( charla ) 18:52, 24 de mayo de 2021 (UTC)

Guy, es posible que tú y yo no estemos tan lejos como crees. Actualmente nos encontramos en una era de tasas de interés bajas y tasas de inflación bajas, que puede que no dure. En el futuro, una posibilidad es que podamos estar en una era de, digamos, 10% de inflación anual y 14% de tasas de interés. Si simplemente tenemos una política de no sumergirnos en el principal, la fundación podría poner la dotación en cuentas y bonos que devengan intereses que generarían un 14% de interés anual y diez años después tendrían la misma cantidad de dólares en el principal, pero con 10 % de inflación, el fondo habría perdido más del 60% de su valor en una década. Incluso con las tasas de inflación actuales, durante décadas el fondo disminuiría en términos reales si no incorporamos algo en la estructura que requiera que los fideicomisarios mantengan el valor de la dotación en términos reales. Una estrategia es mantener una cartera mixta de acciones y bonos: las acciones tienden a pagar un dividendo y también aumentan su valor, otra es la inversión de retorno total. Pero para cualquier estrategia que no sea simplemente dejarla en el banco, espere que haya años en los que el fondo pierde valor. En cuanto a la idea de no tocar al principal, siempre verifique si están hablando del monto o del valor en términos reales. Una organización benéfica que tiene como objetivo mantener el valor de su dotación en términos reales durante el ciclo económico es una organización benéfica que pretende durar indefinidamente. Uno que simplemente quiere mantener el monto del capital puede verse muy diferente después del próximo episodio de inflación. Ϣere Spiel Checkers 20:04, 24 de mayo de 2021 (UTC)

Si nos dirigimos a una inflación alta [44] y la WMF quiere mantener el valor real de la dotación, la WMF no solo no debería gastar el principio, sino que no debería gastar parte de los intereses y, en su lugar, retirarlo. en la investidura. Gastar todo el interés más gastar parte del principio iría en la otra dirección, lo que haría que el valor real cayera más rápido de lo que lo haría por la inflación sola.

El hecho de que la WMF se niegue incluso a discutir la posibilidad de no gastar en el principio no es un buen augurio para que decidan no gastar parte de los intereses. - Guy Macon ( conversación ) 05:00, 27 de mayo de 2021 (UTC)

El artículo que cita es de Babylon Bee , una publicación sátira, no conocida por su análisis económico. - Wug · a · po · des​ 05:07, 27 de mayo de 2021 (UTC)

En realidad [45] es tanto una sátira como un excelente comentario económico, al igual que Los viajes de Gulliver es tanto una sátira como un comentario sobre pequeñas diferencias entre religiones. (Por lo tanto, qué extremo de un huevo no se ? Agrieta ¿Es bigEndian o una smallendian?) - individuo Macon ( talk ) 15:59, 1 de Junio 2021 (UTC)

Artículo de Daily Dot

Fuera hoy:

• Wikipedia está nadando en dinero, ¿por qué le pide a la gente que done?

Si pudieras compartirlo en línea, ¡te lo agradecería! Lo mejor, - Andreas JN 466 13:42, 24 de mayo de 2021 (UTC)

Gracias Andreas, no sé si esa estimación de 2013 de $ 10M + / año, "para garantizar no solo la supervivencia, sino la sostenibilidad real de la misión de Wikimedia" sigue siendo válida, y lo que incluye y omite. No estoy seguro de que pueda equiparar sustentable con cómodo, como lo ha hecho en ese artículo. Para mí, la comodidad incluiría la internacionalización para que algún día los editores de la Wikipedia georgiana pudieran simplemente hacer clic en un icono y editar en sus teclados Qwerty o cirílico, en lugar de solo poder editar si tienen un teclado georgiano. Erik tenía claro que su estimación sostenible no requería volver a un solo centro de datos, por lo que no era "básico", pero ¿incluía fondos para solucionar problemas importantes, como que nuestros sitios sean casi de solo lectura para la generación de teléfonos inteligentes? No estoy defendiendo la recaudación de fondos de la WMF, algo de lo que he visto da la impresión de que el sitio tiene dificultades financieras. Pero mi idea de comodidad financiera es más que sostenible, pero suficiente para abordar algunos de nuestros problemas que se pueden abordar con dinero. Por supuesto, sería mejor si le pidiéramos a la gente que donara para cosas como la internacionalización en lugar de dar la impresión de que necesitamos lo que podría ser bastante dinero de ellos porque nuestros programadores beben café que cuesta £ 5 la taza. Ϣere Spiel Checkers 20:53, 24 de mayo de 2021 (UTC)

El artículo dice específicamente: "Pero mantener Wikipedia en línea es una tarea que la WMF podría manejar cómodamente con $ 10 millones al año . Creo que eso es cierto, dado que Erik dijo que incluye la sostenibilidad real de la misión WMF, además de alojar Wikipedia. Como referencia, aquí está el pasaje del artículo en contexto:

... estos carteles han creado una impresión generalizada de que la WMF debe estar luchando para mantener Wikipedia en funcionamiento, con mensajes que suenan llorosos como: “Este jueves, Wikipedia realmente te necesita. Este es el décimo llamamiento que le mostramos. El 98% de nuestros lectores no da; miran para otro lado ... Te pedimos, humildemente, que no te deslices ". Pero mantener Wikipedia en línea es una tarea que la WMF podría manejar cómodamente con $ 10 millones al año, según una estimación casual de 2013 de Erik Möller, su vicepresidente de ingeniería y desarrollo de productos en ese momento.

Y lo que dijo Erik fue esto:

WMF ha operado en el pasado sin personal y con un personal mínimo, por lo que claramente es _posible_ alojar un sitio web de alto tráfico con muy poco dinero. Pero yo diría que una donación, para que realmente valga la pena, debería apuntar a un nivel base significativamente más alto de gastos operativos anuales mínimos, más del orden de magnitud de $ 10M + / año, para garantizar no solo la supervivencia pura, sino la sostenibilidad real de Misión de Wikimedia. La pregunta de "cuál es el nivel requerido para la supervivencia pura" es, en mi opinión, solo de interés marginal ... - Andreas JN 466 21:21, 24 de mayo de 2021 (UTC)

Como dijo Erik, la sostenibilidad significa cosas como "más de un centro de datos", por lo que ambos podemos estar de acuerdo en que los $ 10 millones son más que una simple supervivencia. He dado un par de ejemplos de actividades que son más que simplemente hacer que el movimiento sea sostenible, ¿estás de acuerdo en que esas cosas valen la pena? Ϣere Spiel Checkers 22:29, 24 de mayo de 2021 (UTC)

Seguro. - Andreas JN 466 23:29, 24 de mayo de 2021 (UTC)

¿Has escuchado alguna vez la historia del yate del almirante? Según la historia, cada vez que alguien propone una reducción del gasto militar, los militares recortan inmediatamente el presupuesto al no comprar balas ni comida para las tropas, pero nunca tocan el yate de los almirantes ni las vacaciones de esquí del general en los Alpes suizos. Si la historia es cierta o no en el caso del ejército real, ciertamente lo es en el caso de la WMF. Seguimos escuchando sobre tal vez gastar menos en centros de datos redundantes o en corregir errores, pero nunca hablamos de las Wikimanias o la sede ubicada en la segunda ciudad más cara del mundo. - Guy Macon ( conversación ) 05:00, 27 de mayo de 2021 (UTC)

Noticias de hackers

• Actualmente en discusión en Hacker News - Andreas JN 466 17:01, 31 de mayo de 2021 (UTC)
• Katherine intervino al final del día. - Andreas JN 466 23:14, 3 de junio de 2021 (UTC)

Horario de oficina de accesibilidad de la Fundación Wikimedia 20 de mayo (aviso tardío)

Estamos organizando un horario de oficina de accesibilidad abierto para todos en el Día de Concienciación sobre Accesibilidad Global 20 de mayo de 2021 de 8:30, 20 de mayo de 2021 (UTC) a 18:30, 20 de mayo de 2021 (UTC) - Volker E. (WMF) ( hablar ) 17:04, 20 de mayo de 2021 (UTC)

Al hacer el anuncio una hora y media antes de que cerrara el horario de oficina, nadie tuvo tiempo de sacar a relucir el hecho de que la WMF discrimina a las personas con discapacidad visual y que esto se denunció hace más de 15 años. Sólo digo. - Guy Macon ( conversación ) 15:16, 24 de mayo de 2021 (UTC)

@ Guy Macon : ¿Cómo discrimina a las personas con discapacidad visual y dónde se informó? Realmente curioso. Kleinpecan ( charla ) 18:54, 10 de junio de 2021 (UTC)

El 3 de febrero de 2006, se informó a la WMF que nuestro sistema CAPTCHA discrimina a las personas ciegas. Ver [ https://phabricator.wikimedia.org/T6845 ]

Esto parece ser una violación directa de la Ley de Estadounidenses con Discapacidades de 1990 y deja a Wikipedia abierta a demandas por discriminación.

Relacionados:

• Wikipedia: Mesa de ayuda / Archivos / 20 de julio de 2016 # Tengo discapacidad visual y no puedo editar artículos sin que me pidan que complete el capcha
• https://lists.wikimedia.org/pipermail/wikitech-l/2008-April/037341.html
• https://lists.wikimedia.org/pipermail/wikitech-l/2013-January/065820.html
• https://lists.wikimedia.org/pipermail/wikitech-l/2008-April/037309.html

National Federation of the Blind v. Target Corporation fue un caso en el que un minorista importante, Target Corp. , fue demandado porque sus diseñadores web no diseñaron su sitio web para permitir que las personas con poca o ninguna visión lo usaran. Esto resultó en que Target pagara aproximadamente diez millones de dólares.

Me han dicho repetidamente que la forma correcta de solicitar que Wikipedia deje de discriminar a los ciegos es a través del fabricador, pero claramente esto no fue efectivo en este caso. Yo no considero a 15 años de negarse a responder a un comportamiento razonable por parte de la WMF. He estado haciendo esta pregunta desde el 3 de agosto de 2017.

Lo que espero de la WMF

Espero una respuesta de sí o no. O la WMF hace una declaración oficial que dice "No, hemos decidido no arreglar esto" o una declaración oficial que dice "Sí, hemos decidido arreglar esto".

Si la respuesta es "Sí", espero que se cree una página (preferiblemente en la Wikipedia en inglés, pero aceptaré una página en Meta) que nos proporcione los requisitos (una definición comprobable de "hecho"), un calendario con hitos y actualizaciones e información presupuestaria y de personal. La WMF ha hecho múltiples declaraciones diciendo que tienen la intención de ser más abiertos sobre este tipo de cosas, y este es un excelente lugar para mostrar que el compromiso con la apertura es más que solo hablar. - Guy Macon ( conversación ) 22:01, 10 de junio de 2021 (UTC)

@ Volker E. (WMF) , Raystorm , Jimbo Wales , y Pundit : . Por favor, no ignore esto. Si te hicieron ping y no es "oficialmente" tu trabajo encargarte de esto, entonces haz los arreglos necesarios para que la persona que es su trabajo se encargue de esto, vea el mensaje y responda. Y si no hay nadie que se encargue de esto, entonces haga los arreglos necesarios para nombrar a alguien para que se encargue de esto. Headbomb { t · c · p · b } 23:01, 10 de junio de 2021 (UTC)

... o sé sincero conmigo y dime en mi cara que te niegas a arreglar esto. No pongas obstáculos durante quince años.

Nuevamente, si a nadie se le asigna la tarea de solucionar este problema, no se solucionará. Si arreglar esto no está en el presupuesto, no se solucionará. Si no hay una fecha límite asignada, no se solucionará. - Guy Macon ( conversación ) 01:24, 11 de junio de 2021 (UTC)

Únase a los nuevos Comités Regionales de Subvenciones

Estimados,

Esperamos que este correo electrónico lo encuentre bien y a salvo. La situación de COVID 19 continúa afectando a muchos de nosotros en todo el mundo y nuestros pensamientos están con todos los afectados. También somos conscientes de que actualmente hay varios procesos en curso que demandan tiempo de voluntariado y no queremos sumar más trabajo al plato de nadie.

Sin embargo, queremos llamar su atención sobre nuestros nuevos Comités Regionales de Subvenciones, ya que son una oportunidad para que usted tenga una voz activa en el futuro de nuestro Movimiento.

📣 ¡Así que hoy, lo invitamos a unirse a nuestros nuevos Comités Regionales de Subvenciones! 📣

Alentamos a los wikimedianos y los defensores del conocimiento libre a formar parte de los nuevos comités regionales que el equipo de recursos comunitarios de WMF está creando como parte del relanzamiento de la estrategia de subvenciones [46] . Serás un socio de pensamiento estratégico clave para ayudar a comprender las complejidades de cualquier región, brindar conocimientos y experiencia a los solicitantes, respaldar actividades de movimiento exitosas y tomar decisiones de financiamiento para solicitudes de subvenciones en la región.

👉Más información en meta [47] .

Se establecerán comités regionales para las siguientes regiones:

• Medio Oriente y Africa
• Región de la SAARC [48] (incluye Afganistán, Bangladesh, Bután, India, Maldivas, Nepal, Pakistán y Sri Lanka)
• Región de Asia oriental, sudoriental y el Pacífico (ESEAP)
• América Latina (LATAM) y el Caribe
• Estados Unidos y canadá
• Europa del Norte y Occidental
• Europa central y oriental (CEE)

👉Todos los detalles sobre los Comités y cómo postularse se pueden encontrar en meta [49] . ¡Las solicitudes deben enviarse antes del 4 de junio de 2021 !

Si tiene alguna pregunta o comentario, utilice la página de meta discusión [50] .

Comparta este anuncio ampliamente con su red.

Los mejores deseos,

JBrungs (WMF) ( charla ) 06:22, 21 de mayo de 2021 (UTC) en nombre del Equipo de recursos comunitarios

En la línea de asunto y la elección de palabras en el mensaje

Sinceramente, dudo que se vayan a plantear nuevos puntos si esta discusión continúa, así que intentemos cerrarla. Barkeep49 ( charla ) 18:19, 28 de mayo de 2021 (UTC)

La siguiente discusión está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

---

"Línea de asunto"? "Este correo electrónico"? ¿Alguien en la WMF recuerda cuando obtuvo su dinero y trabajos del trabajo que hicieron algunos voluntarios en algún wiki? Los buenos viejos tiempos, ¿sabes? Mostraría un poco más de respeto si nos dirigieras como si fueras un wikipedista / wikimediano también, y no como si este mensaje aquí fuera una ocurrencia tardía después de haber sido compartido en una lista de correo mucho más importante para los "verdaderos". WMFians.

Saludos, su socio de pensamiento estratégico clave de su red. Fram ( charla ) 07:34, 21 de mayo de 2021 (UTC)

WP: SOFIXIT - Wug · a · po · des​ 21:15, 22 de mayo de 2021 (UTC)

Y se supone que Fram "arregla" la forma en que WMF toma decisiones ... ¿cómo? ¿Qué pasos, exactamente, tendría que tomar Fram para lograr esto? - Guy Macon ( charla ) 14:16, 23 de mayo de 2021 (UTC)

Estás perdiendo la cabeza por una publicación en un tablón de anuncios asumiendo que es una gran conspiración para insultarlo. El comentario de Fram no fue una obra maestra sobre la estructura organizativa de la WMF; era una queja sobre cómo se formateó un aviso a cientos de wikis y listas de correo. Esta podría ser una idea loca, no podemos tener la tecnología en estos tiempos, pero tal vez algunas personas sean notificadas de los cambios en la lista de observación por correo electrónico y, por lo tanto, ¿verían esto como un correo electrónico? ¿Quizás, y en este momento solo estoy inventando cosas, se puede hacer una publicación por correo electrónico y en la wiki simultáneamente para minimizar el trabajo y maximizar la audiencia y la participación? No, eso no tendría sentido. ¿Por qué el imperio del mal WMF intentaría informar a tanta gente como fuera posible? Es mucho más simple asumir que esto es parte de una gran conspiración en la que los illuminati WMF deciden arruinar esta wiki específicamente con su insidioso mensaje masivo a cientos de comunidades. Deja de gritarle a las nubes y​ enojarte con los mensajes masivos como si fuera un insulto personal, te ves desquiciado. Si desea volver a los "buenos viejos tiempos", intente editar la publicación para eliminar la "línea de asunto" vulgar e insultar "este correo electrónico". Después de todo, es un wiki, ¿o solo apelamos a la ética del wiki cuando es conveniente? - Wug · a · po · des​ 22:06, 24 de mayo de 2021 (UTC)

Fram estaba señalando que alguien de la WMF no tiene idea de las normas de la comunidad para publicar un mensaje en una página de discusión. No se trata de arreglarlo o educarlos, es un reflejo del lamentable hecho de que muchas personas en la WMF están en una burbuja donde el personal está preocupado por su propio bienestar y está casi totalmente aislado de Wikipedia. Johnuniq ( charla ) 23:24, 24 de mayo de 2021 (UTC)

Johnuniq , esta página fue creada para mejorar la comunicación entre los editores de WMF y enwiki. Golpear e insultar al personal de WMF cuando intentan comunicarse no va a promover ese objetivo. WP: CIVIL y WP: BITE se aplican aquí tanto como en cualquier otro lugar de enwiki. - RoySmith (conversación) 23:45, 24 de mayo de 2021 (UTC)

WP: BITE no debería aplicarse a los usuarios de WMF, no deberían ser "recién llegados". Encuentro su publicación insultante, a ti no, está bien. No veo que te quejes de Wugapodes diciendo "Estás perdiendo la cabeza por una publicación en un tablón de anuncios asumiendo que es una gran conspiración", que es una respuesta completamente exagerada a mi publicación y la de Guy Macons. Más adelante: "pareces desquiciado". En serio, esa es una publicación aceptable, pero ¿la mía o la de Guy son un problema? Nadie afirmó o insinuó una gran conspiración, nadie más que Wugapodes está "perdiendo la cabeza" por ello. Pero aparentemente está bien dar respuestas tan exageradas a los editores de enwiki, pero no está bien ver problemas con la forma en que WMF interactúa con nosotros con demasiada frecuencia. Curiosamente, la parte "Asunto:" ya se eliminó de su publicación cuando publicaron en otras comunidades [51] , por ejemplo, aquí dos minutos después. Entonces fue perfectamente posible cambiar el mensaje, se dieron cuenta de que su publicación se veía pobre, simplemente no regresaron para cambiarla aquí. Los Wugapodes simplemente asumieron cosas que ponen a la WMF de la mejor manera posible, como un medio para insultar descaradamente a la gente aquí, y tú, RoySmith, ¿aparentemente no tienes ningún problema con eso? Bien ir allí. Fram ( charla ) 08:16, 25 de mayo de 2021 (UTC)

No puedo imaginar por qué alguien preferiría no volver a este foro. Es un lugar tan agradable donde todos asumen de buena fe (¡ah, los buenos viejos tiempos, recuerden cuando eso era una política!). Ciertamente, no es un lugar donde los avisos simples se encuentren con insultos pasivos agresivos de alguien previamente amonestado y desaprovechado por no mejorar su comportamiento hacia otros editores, particularmente aquellos en la WMF . Me disculpo por ser una falta de respeto, pensé sarcasmo era aceptable teniendo en cuenta que su primera respuesta, pero al igual que dije en 2018 Haré todo lo posible para trabajar en estas cosas . Saludos cordiales de su socio de pensamiento estratégico - Wug · a · po · des​ 04:50, 27 de mayo de 2021 (UTC)

Tu respuesta no fue "irrespetuosa" o "sarcástica", fue un ataque personal puro y simple. Haz una disculpa genuina o no te molestes. Si quieres sermonear a la gente sobre su comportamiento, quizás primero mírate a ti mismo. Y, por favor, no tergiversen el caso de ArbCom, no había "particularmente los de la WMF" ni nada parecido en el enlace que proporcionó. Fram ( charla ) 07:09, 27 de mayo de 2021 (UTC)

Lo siento, estás en lo correcto y lo recordé mal; fue amonestado por su conducta hacia las personas con las que no estaba de acuerdo en general, no necesariamente la WMF, así que he mencionado esa parte arriba. Parece que piensa que fue un ataque personal, en el que confiaré en usted dada su experiencia con el tema documentado en el enlace anterior. Como dije, pensé que decir con franqueza mi respuesta sin filtros al tono de alguien en lugar del contenido era apropiado en este tablero dado su comentario original. Con razón, señala que la descortesía está mal independientemente de a quién se dirija (creo que en realidad ignoró por completo el punto de Roy sobre WP: CIVIL en lugar de tratar de justificar por qué se le debería permitir morder el WMF y desviar la atención de su conducta, pero Asumiré lo mejor). Ojalá que ambos podamos aprender de esta experiencia. Quizás mi sinceridad se perdió en mi sarcasmo, es una pena cómo puede suceder eso, pero sinceramente haré todo lo posible para trabajar en estas cosas. ¿Ojalá puedas decir lo mismo? - Wug · a · po · des​ 19:46, 27 de mayo de 2021 (UTC)

Tomaré sus comentarios sinceros un poco más en serio cuando dé alguna indicación de que los dice en serio. Algo como "Parece que piensa que fue un ataque personal, en el que confiaré dada su experiencia con el tema documentado en el enlace anterior". no es realmente reconfortante, tanto porque aparentemente no puede reconocer sus propios ataques personales incluso cuando se citan, como porque sintió la necesidad de agregar otro comentario franco en esto. Si no puede abstenerse de hacer tales ataques en la misma declaración en la que afirma que hará todo lo posible para trabajar en ellos, entonces o no se refiere a sus comentarios "sinceros" o le falta la autoconciencia necesaria. para su papel. En cualquier caso, no creo que sea fructífero continuar con esta discusión que aparentemente sólo ha reafirmado su opinión sobre mí y me ha dado una buena opinión sobre usted. Fram ( charla ) 07:22, 28 de mayo de 2021 (UTC)

Y el usuario: JBrungs (WMF) es un "Especialista sénior en relaciones con la comunidad". Dios sabe lo que habríamos obtenido de alguien más joven, o que no se especializara en Relaciones Comunitarias. Johnbod ( charla ) 20:07, 27 de mayo de 2021 (UTC)

Me imagino que habría contenido exactamente la misma información pero con un nombre diferente en la parte inferior. - Wug · a · po · des​ 20:55, 27 de mayo de 2021 (UTC)

Esa respuesta probablemente no sea tan inteligente como usted pretendía. Pero el sarcasmo no es tu punto fuerte, ¿verdad? Fram ( charla ) 07:22, 28 de mayo de 2021 (UTC)

• Publiqué esto en WP: VPM con las correcciones menores mencionadas, ya que este tablón de anuncios no está bien vigilado. Estoy escribiendo en mi calidad de voluntario aquí, pero a veces también publico en este tablero como Usuario: Xeno (WMF) .
  Solo un pensamiento, pero tal vez no deberíamos morder en general, ya sean recién llegados, personal, personal recién llegado o de otra manera. Si bien todos tienen derecho a tener su propia opinión sobre las prácticas de contratación de la Fundación, no creo que sea práctico ni posible contratar a un colaborador para cada puesto relacionado con la wiki. Como tal, algunos miembros del personal que realizan actividades de divulgación necesariamente aprenderán terminología y cómo funciona MediaWiki "en el trabajo", y la asistencia constructiva de colaboradores establecidos sería más útil (en mi opinión) cuando nos encontremos con un nuevo usuario, incluso si tienen esas tres letras entre corchetes en el final de su nombre de usuario. - xeno ^talk 13:26, 28 de mayo de 2021 (UTC)
  • No entiendo cómo una empresa tan grande como la WMF, que en gran parte de sus ingresos depende de Wikipedia y su entidad más grande, enwiki ("dependiente", ya que las personas y las instituciones dan dinero a la WMF debido a Wikipedia, Commons y en un grado mucho menor, todas las demás partes), puede contratar a un "Especialista sénior en relaciones con la comunidad, Fundación Wikimedia" y no buscar a alguien con conocimientos de edición (muchos de ellos), o como segunda opción, asegurarse de que la persona con esta función obtiene un conocimiento profundo de primera mano de los sitios principales y sus entresijos (es decir, no solo juega la aventura de Wikipedia y termina con ella). ¿Cómo se pueden tener buenas relaciones con la comunidad si no se tiene el más mínimo conocimiento de "la comunidad", de qué trata, cómo lo hace, ...? Estos son dos meses de "edición", bueno, ni siquiera simplemente interactuando con las comunidades en el terreno , por parte del Especialista Senior en Relaciones Comunitarias. Parece que ninguna de las cuatro palabras del título del trabajo está particularmente bien elegida. Fram ( charla ) 13:51, 28 de mayo de 2021 (UTC)
    • El hilo está relacionado con la asignación de asientos a los comités regionales para otorgar dinero a los voluntarios (¡incluidos los voluntarios que forman parte del comité!), Lo que esencialmente ayuda a proporcionar recursos a los voluntarios que ayudaron a generarlos. Si tuviera que adivinar, sus primeros dos meses involucraron un trabajo fuera de la wiki, andamiando la estructura que nos llevó a esta publicación. Simplemente creo que sería más útil expresar pensamientos sobre la contratación y la práctica de incorporación a alguien de Talent and Culture , en lugar de una publicación en un hilo no relacionado en un tablón de anuncios apenas visto. - xeno ^talk 14:11, 28 de mayo de 2021 (UTC)
      • Mis pensamientos, mi publicación original, fueron sobre el texto de la publicación que publicó aquí. Si no estuviera dirigido a la gran mayoría de los voluntarios, sino solo a los de las organizaciones regionales (capítulos), entonces no debería haberse publicado aquí. Si estaba dirigido a voluntarios individuales, y a la comunidad de voluntarios individuales en su conjunto, entonces lo mínimo que podía hacer era fingir que estaba escrito como un mensaje de onwiki, y no como una ocurrencia tardía que de mala gana tuvo que ser publicada aquí como bien. El hilo luego degeneró en ataques personales por parte de un administrador, y luego se desvió de la publicación original a la función del póster. No tengo ningún interés en tratar con la gente de Talento y Cultura ni con nadie en la WMF, mis experiencias con ellos no son realmente brillantes (con algunas excepciones). Es en gran parte una organización parasitaria en lugar de simbiótica. A veces trato de lidiar con esto de este lado, pero eso es todo lo que tengo que hacer. Fram ( charla ) 14:28, 28 de mayo de 2021 (UTC)
        • Si la intención era mejorar las comunicaciones futuras y mejorar la comprensión del personal de las normas de nuestro proyecto, algo como: "Bienvenido al proyecto. Espero que hayas disfrutado de The Wikipedia Adventure y estés empezando a comprender cómo funcionan los wikis. Solo para que lo sepas, técnicamente, ha publicado un "mensaje" (es decir, en un tablero de mensajes), no un correo electrónico. No estoy seguro de si lo notó, pero olvidó eliminar el marcador "Línea de asunto:" aquí, como lo hizo en mensajes posteriores en este proyecto. Ambos hacen que la publicación parezca un poco incómoda en contexto. La buena noticia es que se trata de una wiki y (casi) todo se puede editar. Simplemente haz clic en el botón "Editar" en la parte superior de esta sección y borra la parte que dice "Asunto:", luego "Publicar cambios", puedes solucionarlo. Sé que esto puede ser un poco confuso al principio, también me tomó un tiempo. No te preocupes, no puedes romper cualquier cosa, al menos no de forma permanente;>. Avísame si puedo ser de alguna ayuda ". también podría haber funcionado (jmho). - xeno ^talk 14:50, 28 de mayo de 2021 (UTC)
          • Y entonces probablemente alguien se habría quejado de que envié un mensaje condescendiente al "Especialista senior en relaciones con la comunidad" de la WMF (más, por supuesto, "sofixit"). ¿Cómo puede alguien ser responsable del marco, la comunicación, la divulgación, para otorgar subvenciones a los voluntarios de Wikipedia, si no tienen idea de cómo funciona realmente Wikipedia? ¿O han renunciado a toda pretensión de que tales subvenciones son para mejoras de Wikipedia y no solo para algunos trabajos lujosos y dinero extra para los iniciados? De todos modos, ¿no ves lo ridículo que es que alguien tenga que enviar un mensaje así a una persona con esa descripción de trabajo? "Mejorar la comprensión del personal o las normas de nuestro proyecto" en la medida en que ni siquiera sepan la diferencia entre un correo electrónico con una línea de asunto o una publicación con un encabezado de sección (que no incluiría las palabras "encabezado de sección" para empezar )? No es una política o pauta oscura de la que no estaban al tanto, simplemente nunca habían interactuado con nadie en la wiki (ni con artículos editados). Fram ( charla ) 15:05, 28 de mayo de 2021 (UTC)
            • Cada día es el primer día de alguien para interactuar con otra persona en una wiki, hay literalmente miles de millones de ellos. Ésta es una razón de más para hacer que su primera interacción sea positiva. - xeno ^talk 15:24, 28 de mayo de 2021 (UTC)
• Fram, no es razonable que critique a alguien por escribir "correo electrónico" y "asunto". ¡Dios no lo quiera, alguien copió y pegó un mensaje en las plataformas sin personalizarlo para cada plataforma! ¡Dispárelos inmediatamente! La crítica no solo es fundamentalmente ridícula, de una importancia tan minúscula que no valía la pena plantearla en absoluto, sino que la forma en que la ha planteado es increíblemente dura. Cuando te comportas como un imbécil, alguien que dice "te estás comportando como un imbécil" no es un ataque personal, es la verdad: te estás comportando como un imbécil. Quiero que la WMF siga publicando actualizaciones aquí, y se detendrán si se enfrentan al acoso de miembros de la comunidad descontentos. Deja de "morder" al personal de WMF. Manténgalo profesional o manténgase en silencio. Levivich 14:59, 28 de mayo de 2021 (UTC)
  • No. Fram ( charla ) 15:06, 28 de mayo de 2021 (UTC)

    Fram , Su crítica pública de las calificaciones de un empleado de WMF y el desempeño de sus funciones es inapropiada y linda con WP: ACOSO . Por favor deje de. - RoySmith (conversación) 15:17, 28 de mayo de 2021 (UTC)

    • Todos se inclinan ante los señores supremos. Te tomaría más en serio si, por ejemplo, hubieras interferido cuando los Wugapodes comenzaron a lanzar ataques personales, pero aparentemente no todos aquí son dignos de tu interés y protección. Bueno, el voluntario "lo mantendrá profesional" y el profesional puede mantenerlo amateur, ¿a quién le importa cómo interactúan con nosotros siempre que podamos aguantar y patear, no? Hasta la próxima ronda, supongo. Fram ( charla ) 15:35, 28 de mayo de 2021 (UTC)

Su crítica pública de las calificaciones de un empleado de WMF y el desempeño de sus funciones es inapropiada y linda con WP: ACOSO No. La WMF trabaja para nosotros. Cuando apestan en algo, tenemos más derecho a criticarlos. Existe una desconexión muy real entre la WMF y la comunidad, y este es un ejemplo de ello. No es el fin del mundo, en el gran esquema de las cosas, pero es algo a lo que se debe llamar a la WMF y es algo que la WMF debería abordar a través de sesiones de orientación o lo que sea. Especialmente para alguien cuyo trabajo es aparentemente representar al "Equipo de Recursos Comunitarios" como "Oficial Superior de Relaciones Comunitarias". Esta no es una posición interna para empujar el lápiz. Por mucho que esto sea una tempestad en una tetera, los debates sobre quién (y si) se le permite criticar a la WMF son pistas falsas que son perjudiciales para la salud de la comunidad. Headbomb { t · c · p · b } 16:04, 28 de mayo de 2021 (UTC)

Estoy de acuerdo con Roy, esto no es una crítica, es un acoso al límite. Critico la WMF todo el tiempo, muchos editores lo hacen, pero no deberíamos hacerlo de una manera hostil como esta. Y no solo eso, es algo infantil criticar a la WMF. Cambiar el "correo electrónico" y la "línea de asunto" no es ni de lejos lo suficientemente importante como para darle a alguien uno nuevo. Nosotros (la comunidad de editores) tenemos serias preocupaciones sobre el WMF, y este no es uno de ellos; esto es inmaduro y distrae de los asuntos importantes, como quiénes serán los próximos fideicomisarios y CEO, y cómo van a gastar esos $ 300 millones en los que están sentados. Levivich 16:51, 28 de mayo de 2021 (UTC)

La discusión anterior está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.

Propuesta que puede ser de interés para la WMF

Perdón si mi inglés es un poco malo. Soy brasileño y vine aquí solo para hacer una propuesta que se está debatiendo en lengua lusófona y que ustedes pueden seguir adelante con la ayuda de ustedes y de la WMF. ¿Qué opinas de una asociación entre Wikipedia y Kindle? Se puede encontrar más información en Wikipedia en portugués (más específico en la sección Explanada: Propuestas). Si este no es el lugar adecuado para hacer esta propuesta, les pido que me orienten. Editor Master Plus ( charla ) 17:15, 24 de mayo de 2021 (UTC)

No soy parte de WMF, pero creo que es una buena idea. Quiero decir, ¡ Amazon Alexa usa Wikipedia para preguntas! Pero solo por curiosidad, ¿tienes un kindle y hay una enciclopedia al respecto? Ah, y tendrían que llegar a acuerdos con Amazon (empresa) para tenerlo en kindle, ya que es propiedad de Amazon. Gracias. Yaxops Banter 18:11, 24 de mayo de 2021 (UTC)

Así que se trata de w: pt: Wikipédia: Esplanada / propostas / Parceria entre Kindle ea Wikipédia Lusófona (24mai2021) . Editor Master Plus , su propuesta es efectivamente agregar la biblioteca de la Tienda Kindle a Wikipedia: La Biblioteca de Wikipedia . Excepto, ¿quién exactamente va a pagar por esto? La biblioteca de Wikipedia puede funcionar porque los socios publican principalmente su propio contenido. Así que regalar cuentas de forma gratuita les cuesta casi nada. Sin embargo, Amazon / Kindle paga a los autores una tarifa por página, y esos miles de autores no van a renunciar a esa tarifa para Wikipedia. Por lo tanto, espera que WMF (olvídelo) o Amazon (lo más probable es que lo olvide) para toser la masa. - Alexis Jazz ( charla o de ping conmigo) 08:53 25 de mayo 2021 (UTC)

@ Alexis Jazz :, como dije en Lusófona: “No está de más intentarlo”, sé que es muy optimista, pero Amazon es grande, ¡y se vende a todo el mundo! Somos una organización sin fines de lucro, y no una empresa que busca lucro, sería poco ético que ellos (los autores de los libros) cobraran por esto, no estamos ganando (en términos monetarios) prácticamente nada con esto. - Editor Master Plus ( charla ) 13:23, 25 de mayo de 2021 (UTC)

Editor Master Plus , en realidad, no se pierde nada con probar cuando no es más que una ilusión porque es una pérdida de tiempo. Este es un infierno administrativo y no tienes idea de cuán grande es el infierno (es muy, muy grande) o cómo lidiar con él y no tienes idea de por qué Amazon siquiera consideraría esto. Además de eso, me preocuparía que Wikimedia pudiera obtener un WP: COI para todos los artículos relacionados con Amazon. - Alexis Jazz ( charla o de ping conmigo) 20:48 25 de mayo 2021 (UTC)

Alexis Jazz déjame ver si te entiendo, tu justificación para que la propuesta se considere inadecuada es porque "sería demasiado complicada". Ya veo, todos odiamos la burocracia, pero, con el debido respeto, creo que su argumento no está respaldado. Entiendo que deberíamos evitar tener que pasar por la burocracia tanto como sea posible, a nadie le gusta eso. Pero no podemos simplemente huir de la burocracia y decidir no buscar más burocracia porque "sería demasiado complicado". Creo que, de ser necesario, deberíamos pasar por la burocracia para conseguir más socios. Llamas a mi propuesta "muy optimista". Ya dije que era muy optimista. Solo quería proponer esta idea aquí y ver si la comunidad tiene un entendimiento como el mío. Por el momento, se han manifestado dos. Una vez más digo que entiendo su punto de vista y respeto, pero mi punto de vista difiere del suyo (al menos) en ese punto. Hago hincapié en que les hablo en un tono respetuoso. Editor Master Plus ( charla ) 21:23, 26 de mayo de 2021 (UTC)

Editor Master Plus , con el debido respeto, su propuesta es inadecuada porque no ha sido bien pensada. Es como proponer la paz mundial : todos están a favor, nadie sabe cómo. Ya les dije que no hay ningún incentivo para que Amazon haga esto. Ese es tu primer obstáculo, tendrías que pensar en algo. Pero digamos que lo hiciste. Les dije que no hay forma de lograr que miles de autores estén de acuerdo. ¡Simplemente contactarlos sería un desafío! Y que ni siquiera podemos hacerlo, Amazon tendría que, porque el permiso tendría que ir a Amazon. Así que ahora tienes que idear un incentivo para que Amazon pase por todo eso. Pero digamos que tú también lo lograste. (No tengo idea de cómo, pero por el bien del argumento) Dado que muchos autores no responderán o no estarán de acuerdo, Amazon tendría que hacer cambios en su infraestructura para excluir a esos autores. Será divertido. Pero digamos que tú también lo lograste. (ya estamos en la tierra de la fantasía) Decidí leer un poco más sobre Kindle Store . Como podría haber adivinado, utiliza la gestión de restricciones digitales . Este es el polo opuesto de todo lo que representa Wikimedia, por lo que incluso si logras superar todos los obstáculos anteriores, ¡simplemente no lo queremos! Está bien fantasear con cosas tontas, es posible que accidentalmente te encuentres con algo que resulte no ser del todo tonto. Pero, por favor, no pida a otros que fantaseen por usted. Investigue un poco y piénselo bien. No proponga la paz mundial a menos que ya haya descubierto una manera de hacer que funcione. - Alexis Jazz ( charla o de ping mí) 03:33, 27 de Mayo 2021 (UTC)

• Editor Master Plus : No hay opinión sobre la idea, aunque creo que Meta: Wikimedia Forum sería un lugar mejor para sugerencias como esta, este tablón de anuncios es específico de EnWiki y no está bien visto. - xeno ^talk 13:38, 28 de mayo de 2021 (UTC)

Actualización de enmascaramiento de IP

El equipo de IP Masking ha proporcionado una actualización sobre IP Masking que se puede ver aquí .

Dado que esto afectará los flujos de trabajo de muchos editores, así como un cambio de WP: PERM bastante significativo , tómese el tiempo para mirar y comentar Nosebagbear ( charla ) 13:12, 10 de junio de 2021 (UTC)

Problema grave para SPI, creo. Ahora, a menudo publicamos cuentas + IP en SPI para ilustrar la cantidad total de calcetines. Según la propuesta, "Todos los usuarios con cuentas de más de un año y al menos 500 ediciones podrán acceder a direcciones IP parcialmente desenmascaradas sin permiso. Esto significa que aparecerá una dirección IP con sus octetos finales, la última parte (s). ) - oculto. Será accesible a través de una preferencia en la que acuerden no compartirlo con otras personas que no tengan acceso a esta información. ": (Énfasis mío) ya no se permitirá publicar ninguna información de IP, ni siquiera con el último octeto (s) oculto, a páginas SPI (u otras páginas como AN / ANI). Esto hará que luchar contra la edición disruptiva de calcetines de IP sea mucho más difícil y probablemente aumentará el vandalismo de IP. Fram ( charla ) 14:41, 10 de junio de 2021 (UTC)

Fram , creo que la respuesta es simple; tome la iniciativa de ptwiki y prohíba por completo la edición de IP. - RoySmith (charla) 15:00, 10 de junio de 2021 (UTC)

No tengo ninguna objeción, pero dudo que eso sea lo que quería la WMF. Esto reduciría la cantidad de ediciones, y las estadísticas de tendencia a la baja no son realmente lo que buscan. Fram ( charla ) 15:04, 10 de junio de 2021 (UTC)

Solo puedo preguntarme qué porcentaje de editores de IP productivos no estarían dispuestos a registrar un nombre de usuario. - Guy Macon ( conversación ) 15:19, 10 de junio de 2021 (UTC)

Creo que cómo funcionarían los informes de SPI es una buena pregunta para hacer en meta desde este marco. Lo mejor, Barkeep49 ( charla ) 16:48, 10 de junio de 2021 (UTC)

Barkeep49 , vea mis comentarios allí . - RoySmith (charla) 20:03, 10 de junio de 2021 (UTC)

Usando mi bola de cristal, preveo un uso mucho más liberal de semiprotección para proteger la enciclopedia. - Malcolmxl5 ( conversación ) 16:48, 10 de junio de 2021 (UTC)

• Claramente, esto tendrá consecuencias no deseadas, que podrían incluir la prohibición de la edición no registrada o una gran expansión de la semiprotección, que resultarán en una reducción de la edición. Si esto es lo que quiere la WMF, entonces deberían seguir adelante con esa propuesta, pero dudo que realmente quieran esto, porque estoy seguro de que hay muchos empleados que se verán mal si los números de edición bajan. Phil Bridger ( charla ) 17:18, 10 de junio de 2021 (UTC)

• Sin conocer el asesoramiento legal, es realmente difícil predecir cómo funcionará esto. La realidad es que cualquier acuerdo que consigas que la gente marque a través de Máscaras a listas de IP comenzará a crearse. La única forma de evitarlo es una rotación de máscara bastante agresiva en ese punto, es esencialmente un proxy abierto y bloqueamos los que están en el sitio. © Geni ( conversación ) 17:39, 10 de junio de 2021 (UTC)
• Acuerde que si lo racional es enmascarar las direcciones IP porque quienes editan desde las direcciones IP no comprenden las ramificaciones de hacerlo, entonces las direcciones IP deben tener prohibido editarlas por completo. Headbomb { t · c · p · b } 22:42, 10 de junio de 2021 (UTC)
• Vaya, esto es horrible. Es increíblemente obvio que los autores de esta propuesta (mal informada) en la WMF no han dedicado prácticamente ningún tiempo a revertir el vandalismo y / o eliminar LTA. De acuerdo con los sentimientos anteriores; es hora de considerar seriamente seguir el manual de ptwiki y restringir la edición a los usuarios registrados. - F ASTILAMENTE 00:38, 11 de junio de 2021 (UTC)
• Antes de comenzar a escribir código, ¿tenemos alguna estadística actualmente sobre la calidad de las ediciones de IP frente a las ediciones registradas? No estoy seguro de cómo medir la "calidad", pero la métrica más obvia sería qué porcentaje de ediciones se revierten. - RoySmith (conversación) 01:35, 11 de junio de 2021 (UTC)

  

  un gráfico circular útil que visualiza los datos

  RoySmith : WP: IPHUMAN cita estudios que dicen que el 80% del vandalismo total proviene de IP, pero> 80% de las ediciones de IP no son vandalismo. Los datos son de 2004 y 2007, por lo que pueden haber cambiado desde entonces, pero probablemente no demasiado. - codificador de Python  ( charla  |  contribuciones ) 13:30, 11 de junio de 2021 (UTC)

  Esperaría que los datos hayan cambiado significativamente. En el mundo actual, obsesionado con la hiper-privacidad, creo que menos personas estarían bien con que se registren sus IP, a menos que solo estén haciendo actos de vandalismo. - SD0001 ( conversación ) 16:09, 11 de junio de 2021 (UTC)

• Uhh, si realmente están considerando implementar esto en lugar de simplemente pedir sugerencias, esto es increíblemente miope, no sé qué decir. De todos modos, no estoy seguro de cómo esto tiene algún impacto legal. Las direcciones IP no son privadas. NUNCA han sido privados. - Rockstone ^{[¡Envíame un mensaje!]} 03:27, 11 de junio de 2021 (UTC)
• Creo que la forma actual de enmascaramiento de IP que se implementará convertiría el trabajo de SPI y AIV en una pesadilla logística porque los planes actuales para el enmascaramiento de IP es que dirigiría a los usuarios registrados con acceso a IP, que deseen informar ediciones no registradas en SPI AIV a listas de correo privadas, como la cola info-en-v OTRS (de manera similar a cómo ArbCom maneja actualmente la evidencia privada). Como resultado, mi predicción es que veríamos un aumento sustancial en los correos electrónicos enviados a esas colas de OTRS en comparación con lo que tratan actualmente los equipos de OTRS.
  
  Lo peor de todo esto es que WMF no ha encontrado una razón lo suficientemente creíble que permita implementar el enmascaramiento de IP de la manera que esperan lograr, y por las razones que mencioné anteriormente, daría aumente para que la comunidad enwiki implemente cambios radicales en WP: OUTING, lo que facilitaría que alguien se bloquee y no pueda editar simplemente por revelar una IP en la wiki. Si bien creo que algún día el enmascaramiento de IP se implementará de una forma u otra, la implementación del enmascaramiento de IP en proyectos WMF debería posponerse hasta que WMF pueda proporcionar una explicación satisfactoria de la necesidad de enmascaramiento de IP que generaría suficiente apoyo de la comunidad Wikimedia en general . Hx7 08:24, 11 de junio de 2021 (UTC)
• +1 para prohibir por completo la edición de IP. Ahora es el momento. - SD0001 ( conversación ) 10:52, 11 de junio de 2021 (UTC)
• Soy como "cualquiera puede editar" como vienen, pero si la opción es "prohibir la edición de IP" o "algún lío complicado", prohibir la edición de IP tiene mi voto. - Kusma ( charla ) 11:06, 11 de junio de 2021 (UTC)
• 

  Representación de la Fundación Wikipedia La Fundación Wikimedia destruye Wikipedia con la prohibición de Fram , el enmascaramiento de IP y el cambio de marca de 2020 en lugar de hacer mejoras obvias pero aburridas en lo que tenemos. - codificador de Python  ( charla  |  contribuciones ) 13:27, 11 de junio de 2021 (UTC)
  Apoyaría la prohibición de toda edición de IP, efectiva inmediatamente después de que este cambio se implemente en enwiki. La prohibición se levantaría si la WMF cambia de opinión. Es decepcionante, pero a la luz de la opacidad / terquedad de WMF, es la única opción que tenemos si no queremos abrir Wikipedia a inundaciones de vandalismo / abuso. - codificador de Python  ( charla  |  contribuciones ) 13:27, 11 de junio de 2021 (UTC)
• Estoy de acuerdo con la postura de WMF Legal, pero por razones ligeramente diferentes: ningún otro sitio web importante registra públicamente las IP en el mundo exterior como lo hacemos nosotros, y las leyes de privacidad se están poniendo al día. Personalmente, apoyaría la desactivación de la edición de IP en todos los espacios de nombres excepto main. Solo soy un poco reacio a optar por la desactivación completa porque aprecio el argumento de que no debería necesitar completar formularios por triplicado para corregir un error tipográfico, pero la forma en que otras partes resuelven esto es mediante un "inicio de sesión desde Google". o la opción "iniciar sesión desde Facebook", que tarda un par de segundos. Ahora, podemos discutir sobre los pros y los contras de ese método hasta que las vacas regresen a casa, pero recuerde que esa opción no es para nosotros - ya tenemos cuentas registradas aquí - es para el editor casual que quiere cambiar "teh" a "el" en algún artículo en algún lugar y no podría dar un monos voladores sobre lo que es la Wikipedia Adventure. Una relajación general de cuándo semi-proteger puede ser la respuesta también. Ritchie333 ^{(charla) (continuación)} 13:58, 11 de junio de 2021 (UTC)
• Pensando un poco más en esto, me estoy convenciendo cada vez más de que esto no hará nada para aumentar la privacidad y bien puede reducirla. Cada sitio web que visita conoce su dirección IP, esa es simplemente la forma en que funciona el Protocolo de Internet, por lo que ninguna cantidad de enmascaramiento o cualquier otra cosa le impedirá revelarlo. La introducción de medidas como el enmascaramiento puede hacer que las personas piensen que no lo están revelando cuando este no es el caso. Deberíamos educar a las personas de que cada vez que visitan un sitio web están revelando algo sobre sí mismos, en lugar de tratar de convencerlos de que están protegiendo su privacidad cuando visitan Google o Facebook o un blog político o un sitio porno o Wikipedia o lo que sea. . Phil Bridger ( charla ) 19:32, 11 de junio de 2021 (UTC)

  Phil Bridger , en realidad, "ninguna cantidad de enmascaramiento o cualquier otra cosa le impedirá revelar [su dirección IP]" es incorrecta. Consulte WP: PROXY .

  Pero esa no es mi principal preocupación aquí. Casi siempre llevo puesto el fez de mi secretario de SPI y veo cómo una tarea que ya es difícil se volverá aún más difícil. Incluso si la información de IP completa todavía es visible para los usuarios autorizados a través de alguna herramienta nueva, es otro nivel de complejidad para un trabajo ya complejo. Ya estamos perdiendo la guerra. Esto será solo una cosa más de su lado de la balanza. - RoySmith (charla) 20:37, 11 de junio de 2021 (UTC)

  Si está utilizando un proxy, entonces le revelará su dirección IP. Si desea alguna respuesta a algo, debe revelárselo a alguien , o simplemente no se comunicará con usted. Phil Bridger ( charla ) 20:41, 11 de junio de 2021 (UTC)

  Encuentro que es una toma miope. Solía ​​haber un tiempo en el que "Internet" conocía todos los sitios de los que venía y a los que iba, todo el tráfico no estaba asegurado a través de la línea, etc., y los problemas de XSS y CSRF eran los predeterminados. .Estos son todos los agujeros que se han cerrado en su mayoría. Me parece increíblemente lógico que la información de IP se oculte cada vez más, especialmente de otros visitantes de ese sitio web. ¿Educar? las personas ni siquiera leen las Condiciones de servicio, y usted va a explicar qué es una dirección IP y sus implicaciones de privacidad para ese 99,9% de las masas que no solían estar en línea cuando usted mismo conoció Internet por primera vez. Para las masas, Internet no es más que una utilidad para cumplir su objetivo. Es exactamente que el sector de la tecnología se preocupa cada vez más por proteger la privacidad de las masas que todavía les queda algo de privacidad. Algunas divisiones de Google y Facebook podrían haber sido arrastradas a esa nueva realidad pateando y gritando, es innegable que está sucediendo y ha estado sucediendo durante años. - Th e DJ ( hablar • contribuciones ) 20:51 11 de Junio de 2021 (UTC)

Me siento como una mierda

He estado sentado en esto durante unos dos años. Me ha llevado mucho tiempo descubrir cómo expresar esto.

Como sabrá, trabajé para la Fundación Wikimedia de 2018 a 2019. Esto fue después de toda una vida de servicio al movimiento Wikimedia. Comencé a contribuir con mi tiempo en 2004 y con el tiempo participé en capacidades mayores y más consecuentes. Estoy orgulloso del trabajo que he realizado, desde hacer que los flujos de trabajo sean más eficientes con bots, hasta organizar conferencias grandes y exitosas, hasta mi trabajo en la construcción de un gráfico de citas abierto en Wikidata.

De lo que no estoy orgulloso es de trabajar en la Fundación Wikimedia.

Trabajé muy duro a lo largo de mi carrera y finalmente encontré un trabajo de tiempo completo en una de las organizaciones sin fines de lucro más ilustres del mundo. Lo que obtuve durante toda mi vida laboral fue la experiencia de trabajar con matones.

La Fundación Wikimedia está dirigida por matones.

Hay dos miembros de la dirección ejecutiva que me vienen a la mente. Ambos me han hecho objeto de repetidas burlas durante un período de varios años en mi calidad de voluntario y profesional. Uno ha interactuado conmigo un número de veces de un solo dígito y solo lo hizo para burlarse de algún error verbal que cometí o para burlarse de algo que dije o hice. A otro también le gustaba hacer bromas sobre mí, a menudo directamente en mi cara. Tuve la experiencia de entrevistarme con este ejecutivo, solo para que se burlaran de mí en mis encuentros posteriores.

Ambas personas todavía trabajan en la Fundación Wikimedia. No me refiero a ellos directamente porque no quiero que me demanden y no quiero que mi puesto sea descuidado, pero siguen ocupando puestos de poder y siguen siendo responsables de la gestión del personal.

Hay muchas cosas que podría contarte sobre la fundación, buenas o malas. Podría contarles sobre la brillantez del personal, las colaboraciones genuinas entre profesionales y voluntarios que se llevan a cabo, y la sincera dedicación de todos los que he conocido trabajando allí.

También podría contarles sobre la falta de liderazgo en los niveles más altos y la guerra interdepartamental por recursos que resultó. Pero simplemente estaba desmoralizado por este caos; no fue mi propia experiencia personal. Podría contarles cómo las mujeres, y las mujeres de color en particular, son masticadas y escupidas por la gerencia. Pero esa no es mi historia para contar. Podría quejarme de que su estrategia de crecimiento es una completa tontería y está destinada al fracaso, pero esa es, simplemente, mi opinión.

Pero esta es mi historia para contar: soy un adulto con autismo. A lo largo de los años, especialmente cuando era más joven, es inevitable que dijera y hiciera cosas un poco divertidas. Y me han burlado de toda mi vida por eso. Puedo perdonarme a mí mismo por decir cosas incómodas y puedo perdonar a las personas por lo que hicieron cuando eran niños. Lo que no puedo perdonar es que un adulto adulto, en una posición de autoridad significativa, intimide a otro adulto en su lugar de trabajo. Es imperdonable.

Después de unos caóticos 18 meses de trabajo en Wikimedia, entregué mi placa. La experiencia me dejó con un trastorno de estrés postraumático, gravemente a la deriva a nivel moral y emocional, y ocasionalmente propenso a episodios psicóticos. Con el tiempo he podido perdonar la disfunción que definió mi experiencia laboral, pero no podía dejar de lado el hecho de que hay matones que trabajan para la Fundación Wikimedia y aún trabajan allí.

Como wikipedistas somos una comunidad neurodiversa y venimos de muchos orígenes diferentes. Necesitamos una gerencia que no solo sea carismática, no solo buena para dar discursos, sino empática y compasiva, que comprenda genuinamente nuestras experiencias.

Me siento terrible y expuesto al escribir esto. Puede que me esté abriendo a las represalias. Pero he estado sentado en esto durante tanto tiempo y me ha torturado mucho. Y no puedo vivir conmigo mismo sin saber que esta perspectiva es invisible. No lo va a escuchar del hábil equipo de Comunicaciones, y no lo va a escuchar de personas que piensan que hablar los dejará sin empleo. Pero en este punto, no creo que tenga nada que perder. Y si otros hablan por mí, espero que valga la pena. Harej ( charla ) 03:14, 22 de mayo de 2021 (UTC)

Harej , maldita sea. No soy un empleado de WMF, pero ¿por qué no me sorprende? Para responder a mi propia pregunta, probablemente se deba a cómo la WMF tiende a aplastar los deseos de la comunidad (la locura del proyecto de marca , WP: FRAMBAN , tratando de echar a Jimbo , sin tratar adecuadamente con WP: THEYCANTHEARYOU y los subtítulos fiasco en Commons, que es una historia para otro día y no suficientemente cubierta por ese enlace) Te he citado en su totalidad en Charla de usuarios: Jimbo Wales . Ser intimidado es devastador. La dirección ejecutiva de WMF intimidar a la gente es una locura. Y la peor parte es que las personas que lo hacen suelen ser demasiado estúpidas para darse cuenta de lo que están haciendo. No compensan ni son "secretamente inseguros" como suele escuchar. Son demasiado estúpidos. Simplemente carecen de la capacidad cerebral para comprender las consecuencias de sus acciones. - Alexis Jazz ( charla o de ping mí) 04:58, 22 de Mayo 2021 (UTC)

No estoy seguro si diría que se debe a eso, o si tienen el mismo problema subyacente (estaría más inclinado a pensar lo último). Elli ( charla | contribuciones ) 03:13, 24 de mayo de 2021 (UTC)

Oye, Harej , lamento mucho que te haya pasado y gracias por ponerte de pie y decirlo. Yngvadottir ( charla ) 05:59, 23 de mayo de 2021 (UTC)

Gracias por dar un paso adelante y escribir esto. Legoktm ( charla ) 07:00, 23 de mayo de 2021 (UTC)

Gracias por ser honesto acerca de sus experiencias, Harej . Es realmente decepcionante escuchar esto. Como bien sabrá, las personas autistas son una parte importante de nuestra comunidad, muy por encima de su proporción en la población general. Cualquier empresa que realmente aprecie que está construida y dirigida por nuestro trabajo voluntario haría todo lo posible para ser complaciente con las personas autistas y neurodivergentes. Sin duda, estas figuras gerenciales también se han burlado de los neurotípicos y los han hecho sentir como una mierda también. Y un lugar de trabajo desorganizado es un semillero de problemas de salud mental. No es un momento de orgullo para la WMF. - Bilorv ( conversación ) 14:31, 23 de mayo de 2021 (UTC)

• Bien hecho al hablar, Harej . Como arriba, ni entristecido ni sorprendido. (Tomo nota de que esta página se ha archivado en al menos dos archivos importantes en línea, varias veces -así oversighting sería un poco de un escenario de puerta de caballos / estable!.) - S erial 17:27 23 de mayo 2021 (UTC)
• Gracias por compartir tu experiencia James. Hemos trabajado un poco juntos y esto me entristece mucho. Ojalá WMF hubiera sido un lugar mejor. Ladsgroup ^overleg 18:07, 23 de mayo de 2021 (UTC)
• Lamento mucho que se sienta así, y me avergüenza que pueda haber gente así. Tú vales mucho, son ciegos si simplemente no supieran reconocer eso, subiendo al bullying ... No tengo palabras para describirlo. Es realmente triste que hayas sufrido tal experiencia. Platonides ( charla ) 20:23, 23 de mayo de 2021 (UTC)
• Buena salsa, Harej, estaba tan contento cuando finalmente tuviste una carrera abierta después de todo tu trabajo. Debemos señalar que usted no es la única persona de nuestro grupo de wikibuddies que ha tenido dificultades en la vida real como resultado de sus esfuerzos de buena fe en nombre de esta enciclopedia. Acepte mis mejores deseos en sus esfuerzos futuros y sepa que hay muchos lugares donde la civilidad ordinaria y las leyes EEO / ADA de EE. UU. Han creado un entorno mucho menos tóxico que el que ha experimentado hasta ahora. Se pone mejor, ¡mantente en contacto! Oliveleaf4 ( charla ) 21:45, 23 de mayo de 2021 (UTC)

Harej , lamento mucho oír eso. Como padre de un niño que fue acosado debido a su trastorno del espectro autista, nuestro fracaso colectivo para proteger a los miembros neurodiversos de nuestras comunidades me parece particularmente atroz e intolerable. Podemos y debemos hacerlo mejor. Gracias por hablar. Vexations ( charla ) 22:01, 23 de mayo de 2021 (UTC)

• Perdón por tu mala experiencia y espero que contar tu historia ayude de alguna manera. Las grandes organizaciones como la WMF a veces pueden ser involuntariamente crueles y por eso es tan importante que todos trabajen duro para ser más amigables e inclusivos. Flounder ceo ( charla ) 01:22, 24 de mayo de 2021 (UTC)

Para agregar algunas observaciones aclaratorias: no me refiero a los gerentes a los que reporté directamente; son personas increíbles. Y creo que la mayoría del personal de la fundación está trabajando de buena fe y está tratando de hacer lo correcto por las personas con las que trabajan, profesionalmente y en la comunidad. Me preocupa profundamente que haya una cultura entre, específicamente, los ejecutivos (es decir, subordinados directos al CEO) que es tóxica, y yo he sido el receptor de esto de maneras sutiles que me marcaron. Mientras trabajaba allí y sobre todo desde que me fui, muchos de ellos han sido reemplazados por otros nuevos, y no tengo opinión sobre ellos porque no he trabajado con ellos. Me he dado cuenta de que mucha gente ha traído sus propias quejas con la Fundación Wikimedia a esto, y lo entiendo completamente, solo que creo que mi posición es un poco más matizada que la dinámica "comunidad vs. fundación" que veo a menudo. Y también quiero señalar que meramente la experiencia de poder escribir lo que hice, y la gran cantidad de apoyo, ha sido inmensamente significativa para mí. Gracias. Harej ( conversación ) 17:32, 24 de mayo de 2021 (UTC)

• Gracias por hablar sobre tu experiencia, James. Has hecho mucho por el proyecto y me entristeció leer esto. Se necesita una comunidad de neurodiversos para construir este proyecto y mantenerlo en funcionamiento, y gran parte de nuestro movimiento probablemente podría usar más (o cualquier) información y / o capacitación con respecto a la neurodiversidad de nuestros valiosos contribuyentes. Esperemos que este hilo ayude a impulsar eso. - ^{Hablar de las} rododendritas \\ 12:28, 25 de mayo de 2021 (UTC)
• Como otros anteriores, esto me entristece pero no me sorprende. Gracias por hablar claro. Una cosa se te ocurrió de inmediato cuando escribiste: "Necesitamos una gerencia que no solo sea carismática, no solo buena para dar discursos, sino que también sea empática y compasiva, que entienda genuinamente nuestras experiencias": personas carismáticas (o lo que en algunos casos pasa por carismático entornos) y buenos para dar discursos rara vez son también empáticos y compasivos. Nuestros artículos sobre el encanto superficial y la psicopatía en el lugar de trabajo pueden resultar de interés. DuncanHill ( charla ) 14:16, 25 de mayo de 2021 (UTC)

  Interesante, Robert D. Hare acuñó el término " serpientes en traje " como sinónimo de psicópatas en el lugar de trabajo.

La manipulación implica que el psicópata cree un escenario de " ficción psicopática " donde se creará información positiva sobre sí mismo y desinformación negativa sobre los demás, donde se utilizará su papel como parte de una red de peones o patrocinadores y se le preparará para aceptar la la agenda del psicópata. Una vez en la etapa de confrontación, el psicópata usará técnicas de asesinato de personajes para mantener su agenda, y usted será descartado como peón o usado como patrón. Finalmente, en la etapa de ascensión, el papel del sujeto como patrón en la búsqueda de poder del psicópata será descartado, y el psicópata tomará para sí mismo una posición de poder y prestigio de cualquiera que alguna vez lo apoyó.

¿En quién te hace pensar eso ? wbm1058 ( conversación ) 16:39, 25 de mayo de 2021 (UTC)

Sé que no es mi lugar, pero ese último enlace no tiene nada que ver con lo que se supone que trata esta discusión. Golollop ( rebote ) 16:55, 25 de mayo de 2021 (UTC)

No hay problema, sé que ese enlace está fuera de tema y espero que esta barra lateral sobre la psicopatía en el lugar de trabajo también esté fuera de tema. Si no es así, necesitamos saberlo. wbm1058 ( conversación ) 17:03, 25 de mayo de 2021 (UTC)

Estás balbuceando y lo que dices no ayuda. Moneytrees🏝️ Guía de ^{charla / CCI} 21:01, 30 de mayo de 2021 (UTC)

• Hola harej , fue triste leer sobre tu experiencia. El valor que ha mostrado aquí al expresar cómo se sintió es inspirador y me alegra que, en cualquier caso, dar este paso haya sido personalmente significativo para usted. Espero que otras personas que sienten lo mismo acerca de sus lugares de trabajo actuales o anteriores también se expresen de manera efectiva y brinden una oportunidad para que ocurran cambios positivos. Gracias por compartir esto y les deseo todo lo mejor. Ncmvocalist ( charla ) 18:23, 26 de mayo de 2021 (UTC)
• Harej , es realmente una pena escuchar eso. También he trabajado en algunos lugares como ese, y realmente te deja huella. Espero que la WMF tome esto en cuenta y se preocupe por la conducta de sus propios empleados y ejecutivos. Deberíamos hacerlo mejor que eso. Seraphimblade ^Háblame 15:57, 29 de mayo de 2021 (UTC)
• Que una de las personas más agradables y dedicadas en la historia del sitio haya sido tratada tan mal es una acusación condenatoria. Pasé por una situación similar cuando era niño y es triste ver que ese comportamiento todavía se considera aceptable tan alto. Moneytrees🏝️ Guía de ^{charla / CCI} 22:17, 30 de mayo de 2021 (UTC)
• Harej Lamento mucho escuchar esto. Puedo relacionarme un poco, aunque lo que experimenté no fue tan malo como lo que describiste aquí. Hacia el final de mi tiempo en la WMF, me sentí bastante incómodo debido a las acciones de algunas personas allí. Traté de encontrar una posición diferente a la que estaba, que me distanciara de esas personas, pero me dijeron que esa no era una opción que estaba abierta para mí. Entonces, mis opciones eran aguantarlo o irme. Ojalá no sintiera que necesitaba irme para preservar mi salud mental, pero lo hice. Al final, no fue la relación antagónica entre el personal asalariado y los voluntarios lo que me hizo irme, fueron las relaciones antagónicas internas. Es una pena, trabajar en una empresa con impacto global que no está totalmente impulsada por las ganancias, el pensamiento a corto plazo y los precios de las acciones del próximo trimestre podrían ser fácilmente el mejor trabajo del mundo ... pero, al final, de alguna manera termina. De todos modos, no es tan diferente de las empresas centradas en las ganancias a corto plazo, y realmente no es el mejor trabajo del mundo en absoluto. Espero que pueda comenzar a recuperarse de este trauma. Todo lo mejor. - Deskana ( charla ) 09:11, 1 de junio de 2021 (UTC)
  • Yo también me relaciono. En mi caso, me quedé y traté de rechazar los crecientes intentos de marginación y acoso laboral. Llegué al punto en que me quejé oficialmente a Recursos Humanos (y en retrospectiva debería haber usado una redacción más fuerte), eventualmente afirmaron que "no hay evidencia", pero todo lo que pedí sucedió de todos modos, luego un mes más tarde permitió una represalia masiva. Me parece que la gerencia de WMF se ha vuelto bastante disfuncional, fomentando una cultura donde su propia imagen y progresión profesional es un objetivo importante de una manera que asociaría más con empresas feroces con fines de lucro que con una organización sin fines de lucro. lucro. Anomie ⚔ 13:32, 1 de junio de 2021 (UTC)
• Al tener el placer de trabajar con usted en el pasado, y también experimentar el acoso ejecutivo en la Fundación Wikimedia, creo en cada detalle de su historia, y puedo imaginar exactamente este tipo de mala conducta administrativa estratosférica que queda impune. No quiero diluir la conversación dando mi propia opinión de hasta dónde se extiende esta podredumbre en la estructura organizativa, pero digamos que la Fundación Wikimedia sería un entorno de trabajo mucho mejor y se beneficiaría incluso a nivel programático, si el El personal de base y los miembros de la comunidad se incluyeron en un proceso democrático. ¡Espero que tengamos otra oportunidad de trabajar juntos! Adamw ( charla ) 07:23, 2 de junio de 2021 (UTC)
• ¿Y ahora que? @ Harej , Deskana , Anomie y Adamw : todos ustedes se han presentado valientemente ... en un hilo que se iba a archivar en unos días. Esto no debe olvidarse. Esto merece alrededor de 1000 veces más atención. ¿Pero donde? Suffusion of Yellow ( charla ) 20:48, 6 de junio de 2021 (UTC)

  Suffusion of Yellow , ¿ como la página de discusión de Jimbo, tal vez ? - Alexis Jazz ( charla o de ping mí) 21:33 6 de junio 2021 (UTC)

  ¿Quizás alguien pueda ofrecerse como voluntario para trabajar con los editores en cuestión para discutir los próximos pasos que le gustaría que sucedieran? isaacl ( conversación ) 21:50, 6 de junio de 2021 (UTC)

"> Reproducir medios

En una convocatoria de febrero de 2021 para recibir comentarios , solicité una respuesta a las travesuras del personal de la Fundación Wikimedia de los miembros de la junta de la Fundación Wikimedia.