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

Editar-buscar-reemplazar.svg
Política
mensaje , reloj , la búsqueda
discutir las políticas existentes y propuestas

Preferences-system.svg
Técnica
posterior , reloj , buscar
examinar cuestiones técnicas sobre Wikipedia

Dialog-information on.svg
Propuestas
publicar , reloj , búsqueda
discutir nuevas propuestas que no están relacionadas con las políticas

Herramientas-hammer.svg

Publicar , ver y buscar en el laboratorio de
ideas Incubar nuevas ideas antes de proponerlas formalmente

Wikimedia-logo black.svg

Publicar , ver , buscar en WMF
Discutir temas relacionados con la Fundación Wikimedia

Help-browser.svg

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

Hyperlink-internet-search.svg
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 WikimediaWikimedia 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 ( charlacontribuciones ) 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 ( charlacontribuciones ) 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ágicosmensajes  ) - (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 ( charlacontribuciones ) 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 ( charlacontribuciones ) 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 328 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 328 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 ( hablarcontribuciones ) 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

¿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

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 ( hablarcontribuciones ) 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 ( talkcontribuciones ) 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ágicosmensajes  ) - (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 ( charlacontribuciones ) 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 - Maple Leaf (Pantone).svg 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 ( talkdgaf )   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 ( talkdgaf )   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 considerab