Esta es la página de la bomba de la aldea (todas) que enumera todos los temas para facilitar su 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 desea hacer un comentario. Para ver una lista de todas las revisiones recientes de esta página, haga clic en el enlace de historial que se encuentra arriba y siga las instrucciones que aparecen en la pantalla.
Haga clic aquí para purgar el caché del servidor de esta página (para ver los cambios recientes en las subpáginas de Village Pump)
Las discusiones con más de 7 días de antigüedad (fecha del último comentario realizado) se mueven a una subpágina de cada sección (llamada (nombre de la sección)/Archivo).
¿La fecha redirecciona a los portales?
El 16 de agosto de 2006 se señala el portal de eventos actuales como resultado de esta discusión . Sin embargo, las redirecciones de fecha seguirán apareciendo en RfD, y algunas discusiones y aportes de la comunidad más amplia son útiles para determinar si el portal de eventos actuales es o no un objetivo apropiado para las redirecciones del espacio principal . Consulte también: esta discusión en curso para obtener algo de contexto.
Preguntas relacionadas a considerar: ¿Los portales son "parte de la enciclopedia"? Gracias, Cremastra ( u — c ) 00:55, 30 de octubre de 2024 (UTC) [ responder ]
La segunda pregunta es fácil: Sí, los portales son parte de la enciclopedia. En cuanto a la primera pregunta, los portales son contenido orientado al lector, por lo que no veo ninguna razón por la que no sean objetivos apropiados para las redirecciones del espacio principal, dado que, sin lugar a dudas, las redirecciones del espacio principal se dirigen a plantillas y categorías orientadas al lector cuando son el mejor objetivo. Si el puerto es el mejor objetivo para una fecha determinada dependerá de la fecha específica, pero en general, el portal siempre debería ser una opción a considerar. Thryduulf ( discusión ) 01:32, 30 de octubre de 2024 (UTC) [ responder ]
Estoy de acuerdo con esto. El portal definitivamente no es siempre la mejor opción y tiene sus limitaciones, pero, como escribí en WP:RDATE, debe considerarse y evaluarse junto con los artículos del espacio principal. Cremastra ( u — c ) 01:44, 30 de octubre de 2024 (UTC) [ responder ]
Si un espacio de nombres no tiene los mismos estándares que el espacio principal, entonces el lector no debería ser redirigido allí sin darse cuenta de que ahora está fuera del espacio principal. Sí, hay más contenido en Portal:Actualidad/Agosto 2006 que en 2006#Agosto 2006 , pero el lector ahora se enfrenta a una página de hace décadas sin control de calidad, donde los enlaces a Breitbart están etiquetados de manera engañosa como (AP). Chaotic Enby ( discusión · contribs ) 00:50, 6 de noviembre de 2024 (UTC) [ responder ]
El portal tiene los mismos estándares que el espacio principal. Que un portal no cumpla con esos estándares no es diferente a que un artículo esté en mal estado: arréglenlo. Thryduulf ( discusión ) 00:54 6 nov 2024 (UTC) [ responder ]
¿Entonces puedo usar los criterios A rápidos para las páginas del portal? Fram ( discusión ) 17:40 7 nov 2024 (UTC) [ responder ]
No, porque no son artículos. Dos cosas pueden ser consideradas iguales sin que sean lo mismo. El criterio P1 lo permitía anteriormente (indirectamente), pero fue derogado en 2023 debido a la falta de uso. Thryduulf ( discusión ) 19:42 7 nov 2024 (UTC) [ responder ]
Entonces no están sujetos a los mismos estándares... En términos más generales, no, obviamente no están sujetos a los mismos estándares, por ejemplo, una página de portal no tiene que ser un tema importante, sino que puede ser puramente decorativa o (como es el caso de las páginas de fechas) ser una lista de cosas principalmente no importantes, en su defecto WP:NOTNEWS y WP:LISTN . Que algunos estándares sean los mismos (BLP, copyvio, ...) también se puede decir de, por ejemplo, las páginas de discusión de usuarios, y tampoco redirigimos a estas páginas. Fram ( discusión ) 20:24, 7 de noviembre de 2024 (UTC) [ responder ]
No redireccionamos a las páginas de discusión de los usuarios porque no están orientadas al lector, por lo que eso es irrelevante. No aplicamos políticas de contenido de artículos a las plantillas y categorías orientadas al lector (porque no son artículos), pero sí redireccionamos a ellas. No confunda los estándares de calidad con las políticas de inclusión, no son lo mismo. Thryduulf ( discusión ) 21:15, 7 de noviembre de 2024 (UTC) [ responder ]
No sabía que los estándares de los que hablábamos eran únicamente estándares de calidad, sean los que sean, y no estándares de contenido, estándares de abastecimiento, ... Lamentablemente, no me sorprende que consideres que estos son irrelevantes a la hora de decidir qué presentar a nuestros lectores. Fram ( discusión ) 21:37 7 nov 2024 (UTC) [ responder ]
En teoría, creo que los portales deberían estar sujetos a los mismos criterios de la CSD que los artículos. Pero, por supuesto, los criterios A en realidad solo se aplican a los artículos. Cremastra ( u — c ) 22:08, 7 de noviembre de 2024 (UTC) [ responder ]
Hay un montón de basura aleatoria en el espacio de portales, pero sí , es parte de la enciclopedia. Al igual que las categorías y las plantillas, los portales son contenido orientado al lector. C F A 💬
En realidad no tenía opiniones muy firmes sobre los portales hasta que vi este enlace a Breitbart, dos veces, de forma engañosa. Esto no está bien. Estoy de acuerdo con Fram en que claramente los portales no están sujetos a los mismos estándares que los artículos normales y podría ser una mala idea redirigir a los lectores a ellos. Toadspike [Discusión] 23:00, 7 de noviembre de 2024 (UTC) [ responder ]
Vi esto en CENT y la pregunta me confunde. Portal:Current events/2006 August 16 es muy diferente de algo como Portal:Belgium y no tiene sentido pretender que son lo mismo para establecer una política. ¿Y qué significa "parte de la enciclopedia"? "Interpretar una frase confusa" es una forma terrible de decidir los objetivos de redireccionamiento. En cuanto a la pregunta específica de "¿Las fechas deberían redireccionar al portal de Actualidad en lugar de a una página como Agosto de 2006 ...? No lo sé. No veo una razón convincente por la que no puedan hacerlo, ni una razón convincente por la que deban hacerlo". Walsh90210 ( discusión ) 15:45 8 nov 2024 (UTC) [ responder ]
¡Ey, qué bonito portal! Gracias por devolverme la fe en los portales. Al hacer clic en "Portal aleatorio", llegué a Portal:Trees , que también es bastante bueno. Ahora mi opinión es que sí, los portales pueden ser buenos, pero me parece que actualmente no tenemos reglas que aplicar a su contenido o medir su calidad, no hay consenso sobre cómo dirigir a los lectores hacia ellos y un historial de eliminación muy accidentado y controvertido. Realmente no sé qué hacer con ellos. Toadspike [Discusión] 16:49 8 nov 2024 (UTC) [ responder ]
Por supuesto que es un lindo portal, mira quién lo creó :-D Fram ( discusión ) 17:51 8 nov 2024 (UTC) [ responder ]
No , no deberíamos redirigir las fechas a las subpáginas del portal de eventos actuales. Es una redirección entre espacios de nombres que lleva a los lectores de un lugar en el que esperan estar (un artículo de una enciclopedia sobre el tema "16 de agosto de 2006") a un lugar en el que no esperan estar (una ayuda de navegación (?) que resalta algunas cosas que sucedieron ese día). No estoy 100% seguro de para qué sirven las subpáginas del portal de eventos actuales, pero no están pensadas para sustituir a pseudoartículos en lugares en los que carecemos de artículos reales. Ajpolino ( discusión ) 22:04 8 nov 2024 (UTC) [ responder ]
Las redirecciones entre espacios de nombres no son un problema en sí mismas. Solo causan problemas cuando llevan a alguien que espera contenido para el lector a contenido "de trastienda" (por ejemplo, el espacio del proyecto). Tanto los artículos como los portales son contenido para el lector, por lo que esto no es un problema. Thryduulf ( discusión ) 22:17 8 nov 2024 (UTC) [ responder ]
¿Existe otro caso en el que vinculamos a un lector de un artículo a un artículo que no es un artículo sin indicarlo claramente? Por ejemplo, no tengo ningún problema con la plantilla {{ Portal }} que la gente suele usar en la sección Ver también. Ajpolino ( discusión ) 01:12 9 nov 2024 (UTC) [ responder ]
Hay muchas redirecciones a plantillas y categorías. Muchas plantillas de navegación tienen enlaces a otras plantillas de navegación. Thryduulf ( discusión ) 08:12 9 nov 2024 (UTC) [ responder ]
¿Hay algún ejemplo de estas páginas del espacio principal que son redirecciones a plantillas? 08:42, 9 de noviembre de 2024 (UTC) Fram ( discusión ) 08:42, 9 de noviembre de 2024 (UTC) [ responder ]
Gracias. Vale, Citeweb es un mal ejemplo, no es algo que busquen los lectores, sino algo que buscan los editores. Los otros dos se encuentran entre los 6 redireccionamientos existentes a plantillas que enfrentan los lectores (de Category:Redirects to template namespace , los únicos que son del espacio principal y no están relacionados con el editor como las plantillas de citas). No son exactamente los "lotes" que parecías estar sugiriendo a lo largo de esta discusión, sino casos atípicos extremadamente raros que probablemente deberían ser modificados por RfD. Fram ( discusión ) 11:42, 10 de noviembre de 2024 (UTC) [ responder ]
Ahora solo quedan 2, los otros 4 los convertí en artículos u otras redirecciones. Fram ( discusión ) 11:52 10 nov 2024 (UTC) [ responder ]
Sí , los portales de eventos actuales son objetivos de redireccionamiento válidos para fechas y, en este caso, se prefiere la mejor redirección de artículo para una fecha específica, que es la sección del mes de un artículo sobre un año completo. Estoy de acuerdo con Fram en que los portales no están sujetos a los mismos estándares que los artículos, pero no estoy de acuerdo con la postura de Ajpolino de que una redirección entre espacios de nombres es tan disruptiva que está prohibida en todos los casos, dado que WP:Portal dice "los portales están destinados principalmente a los lectores". ViridianPenguin 🐧 ( 💬 ) 23:46, 8 de noviembre de 2024 (UTC) [ responder ]
Si nos limitamos a comentar la pregunta de si los portales son parte de la enciclopedia, sí lo son. Lamentablemente, hubo una voz extremadamente fuerte y disruptiva que siguió haciendo que los portales fueran menos útiles y sofocando cualquier discusión que los haría más beneficiosos para los lectores. Muchos colaboradores voluntarios de portales, incluido yo mismo, abandonamos este espacio y los lectores todavía están cosechando las semillas de lo que ese usuario disruptivo plantó incluso después de haber sido baneados por ArbCom hace más de un año. Por lo tanto, puede haber dado a algunas personas la ilusión de que los portales no están haciendo mucho por el objetivo enciclopédico, porque el estado actual está limitado por su historia. Me reservo mis opiniones sobre la parte de la discusión relacionada con la redirección. Página de discusión de OhanaUnited 07:29, 9 de noviembre de 2024 (UTC) [ responder ]
No , los portales no están sujetos a los estándares de los artículos, y si algo, por cualquier razón, no debería o no puede ser un artículo enwiki, no se debería evitar colocándolo en el espacio del portal. O bien estas páginas de fecha son aceptables, y entonces deberían estar en el espacio principal. O no son lo que queremos como artículos, y entonces no deberíamos presentarlas a nuestros lectores de todos modos. Fram ( discusión ) 11:42 10 nov 2024 (UTC) [ responder ]
Estas páginas de actualidad difieren de los artículos en muchos aspectos, pero los estándares de referencia son similares. El hecho de que tengan o no el prefijo "Portal:" no refleja su calidad. J 947 ‡ edits 23:18, 11 de noviembre de 2024 (UTC) [ responder ]
Sí , porque el objetivo de Portal:Actualidad/21 de agosto de 2022 es proporcionar información enciclopédica sobre el 21 de agosto de 2022 y este objetivo ha tenido un éxito rotundo. J 947 ‡ edits 23:18, 11 de noviembre de 2024 (UTC) [ responder ]
El ejemplo del portal de eventos actuales que se menciona parece bastante enciclopédico, ya que, aparte de algunas diferencias de formato, bien podría ser un artículo de lista, pero he visto otros portales que tienen contenido orientado al editor que es más dudosamente apropiado para el espacio principal. Considere, por ejemplo, Portal:Schools § Wikiprojects (mayúsculas [ sic ]) y Portal:Schools § Things you can do , y los módulos similares en muchos otros portales. Sdkb talk 18:27, 13 de noviembre de 2024 (UTC) [ responder ]
Sí, según J947, especialmente teniendo en cuenta que los portales de eventos actuales funcionan como una lista enciclopédica para la fecha dada. -- T avix ( discusión ) 16:46 14 nov 2024 (UTC) [ responder ]
Problemas con las directrices anticuadas paraWP:NBANDque básicamente hacen que se conserven elementos comunes y corrientes que no son destacables
5.) Ha lanzado dos o más álbumes en un sello discográfico importante o en uno de los sellos independientes más importantes (es decir, un sello independiente con una historia de más de unos pocos años y con una lista de artistas, muchos de los cuales son notables independientemente).
6.) Es un conjunto que contiene dos o más músicos notables de forma independiente, o es un músico que ha sido un miembro razonablemente destacado de dos o más conjuntos notables de forma independiente. Esto debe adaptarse adecuadamente al género musical; por ejemplo, haber interpretado dos papeles principales en importantes teatros de ópera. Tenga en cuenta que este criterio debe interpretarse con cautela, ya que ha habido casos en los que se citó de manera circular para crear un ciclo de notabilidad autocumplido (por ejemplo, músicos que eran "notables" solo por haber estado en dos bandas, de las cuales una o ambas eran "notables" solo porque esos músicos habían estado en ellas).
Parece que estos fueron elaborados por un número muy reducido de editores hace más de una década y no han cambiado mucho desde entonces, y creo que es mucho más indulgente que cualquier otra cosa. Este SNG define un "sello" que ha existido durante "algunos años" y que tiene una lista de artistas como "importante". Por lo tanto, cualquier grupo de personas que haya publicado dos álbumes a través de CUALQUIER sello verificable que haya existido durante más de unos pocos años puede terminar siendo mantenido y esto no está exactamente en línea con GNG. Creo que se debe llevar a cabo un debate para adaptarlo a las expectativas de GNG de ahora.
Especialmente si tenemos en cuenta la amplitud con la que se han "interpretado" los distintos criterios en los debates sobre la eliminación, la mejor manera de hacerlo es simplemente desaprobar todo el asunto. Confíen en el GNG para la notoriedad de las bandas, y si eso da como resultado que desaparezcan un montón de artículos sobre conjuntos efímeros, bandas de garaje y actos locales, ¡hurra! Ravenswing 09:07, 30 de octubre de 2024 (UTC) [ responder ]
El SNG no es viable en la era de la distribución digital. Es muy fácil crear "un sello independiente con una trayectoria de más de unos pocos años". Si alguien quiere sugerir una forma de reformar el SNG, estoy abierto a soluciones. Pero la desvalorización es una alternativa sencilla si no podemos hacerlo. El GNG siempre es un buen estándar porque garantiza que tengamos fuentes de calidad para escribir un artículo. Shooterwalker ( discusión ) 14:22 30 oct 2024 (UTC) [ responder ]
Participé activamente en los debates de AfD cuando NBAND era bastante nuevo, y fue útil para lidiar con una avalancha de artículos sobre bandas de garage y cosas así, pero creo que nuestros estándares en general se han vuelto más estrictos desde entonces, y estoy de acuerdo en que es hora de revisarlo. Sin embargo, existe la posibilidad de que la revisión de NBAND requiera tanta discusión como la revisión de NSPORT. Donald Albury 17:49, 30 de octubre de 2024 (UTC) [ responder ]
Esto suena razonable. Supongo que necesitamos algunas sugerencias concretas de reescritura en las que basar una RFC. Gråbergs Gråa Sång ( discusión ) 18:17 30 oct 2024 (UTC) [ responder ]
Supongo que la pregunta subyacente es: ¿hay algún daño real en tener un artículo permanente sobre una banda que resulta estar en el límite en términos de GNG? Consideren esto:
" Alice y Bob son un dúo musical del género de ciencia ficción . [1] Lanzaron su primer álbum, Foo , en 2019 y su segundo, Bar, en 2020. Ambos álbumes fueron lanzados por Record Label . [2] Son principalmente conocidos por cantar durante un evento menor . [3] "
Pregunto esto porque creo que la naturaleza de las fuentes ha cambiado, en particular para la cultura pop, desde que se escribieron NBAND y GNG. Ahora tenemos temas que reciben "atención del mundo en general", pero que no son fuentes del tipo Correcto™ y, si bien estas fuentes Incorrectas™ definitivamente brindan "atención", parte de esa atención podría no brindar información biográfica (lo que significa que estamos viendo un artículo breve).
Por ejemplo, en lugar de llamar la atención en la sección de arte de un diario, están recibiendo atención de Anthony Fantano en YouTube. Es un crítico musical importante,[1] pero sospecho que nuestra reacción instintiva es "Pffft, solo un YouTuber, totalmente poco confiable". En consecuencia, podríamos calificar a una banda que teóricamente pretendemos incluir ("atención del mundo en general") como no conforme con el GNG (porque todo el campo se basa en el estilo de fuentes Wrong™). WhatamIdoing ( discusión ) 19:02 30 oct 2024 (UTC) [ responder ]
Tenga en cuenta que, como ocurre con la mayoría de las demás pautas de notabilidad, se presume que un tema es notable si cumple con estos criterios. Si realiza una revisión exhaustiva y demuestra que no hay una cobertura significativa más allá de las fuentes para satisfacer sus criterios, el artículo debe eliminarse de todos modos. Ninguno de los SNG está orientado a prevenir este tipo de cuestionamientos. — M asem ( t ) 19:30, 30 de octubre de 2024 (UTC) [ responder ]
Si tuviéramos que ceder ante la presunta notoriedad de una banda al azar porque lanzó dos álbumes con Backyard Trampoline Recordings, establecida hace unos años, y tuviéramos que hacer una búsqueda exhaustiva para refutar la notoriedad, nos estamos preparando para una situación en la que la eliminación es 10 veces más desafiante que la creación de artículos. Entonces... Veo un gran valor en eliminar NBAND 5 y 6. Graywalls ( discusión ) 00:47, 31 de octubre de 2024 (UTC) [ responder ]
Bienvenidos a WP:SNGs . Como dijo Masem, se supone que son una idea aproximada para medir la notoriedad antes de buscar exhaustivamente las fuentes. Pero casi todos ellos han terminado siendo utilizados como un medio para mantener artículos sobre temas triviales o comunes. El gran alienígena feo ( discusión ) 19:37, 30 de octubre de 2024 (UTC) [ responder ]
Graywalls enumeró dos criterios, pero la discusión principal parece ser sobre el primero (#5). Estoy de acuerdo con Graywalls en eso. Con la evolución de la industria, el criterio de la etiqueta ya no es un indicador útil como lo fue antes y, en mi opinión, el #5 debería eliminarse o modificarse. Atentamente, North8000 ( discusión ) 19:13, 30 de octubre de 2024 (UTC) [ responder ]
Estoy de acuerdo, ambos criterios deberían eliminarse. JoelleJay ( discusión ) 22:21 30 oct 2024 (UTC) [ responder ]
Yo también me he dado cuenta de eso. Creo que el punto 6 todavía tiene algo de valor, mientras que el punto 5 es como decir que un autor que ha publicado dos o más libros con una editorial importante se presume notable. Es un listón demasiado bajo sin exigir un cierto nivel de recepción de esos álbumes/libros. ( WP:NAUTHOR no tiene ese criterio de 2 libros, por supuesto, solo parecen puntos de referencia paralelos). Schazjmd (discusión) 13:25 31 oct 2024 (UTC) [ responder ]
Por otro lado, en este caso, sospecho que un artista que "ha lanzado dos o más álbumes en un sello discográfico importante o en uno de los sellos independientes más importantes" tendrá en el 99% de los casos suficiente cobertura para superar la barrera de GNG. Me gustaría ver un ejemplo de uno que no la tenga. Black Kite (discusión) 13:29 31 oct 2024 (UTC) [ responder ]
La definición de importante, como se dice en el punto 5, es "una historia de más de unos pocos años y con una lista de intérpretes, muchos de los cuales son notables de forma independiente". Esto significaría que una banda de garaje es notable, porque ha lanzado dos álbumes en CD-R en Rotten Peach Recordings, que lleva en activo tres años y medio, tiene una lista de intérpretes y algunos de los cuales tienen una página de Wikipedia sobre ellos. A menudo, "notable" se determina por la presencia de una página de Wikipedia independiente. Cuando miras la página, muchas páginas de miembros de la banda son irremediablemente no notables, pero la eliminación requiere una AfD. Por lo tanto, una simple eliminación puede convertirse en una AfD de varios pasos que consume mucho tiempo. Graywalls ( discusión ) 19:18, 31 de octubre de 2024 (UTC) [ responder ]
No opino sobre la notoriedad de esa banda, pero Metal Blade es un sello independiente famoso que existe desde hace 42 años, ha publicado material de bandas muy conocidas y es distribuido por Sony; no es un sello unipersonal que opera desde su garaje. Black Kite (discusión) 11:28 1 nov 2024 (UTC) [ responder ]
Estoy de acuerdo con ese ejemplo particular.
Metal Blade es un sello importante y, como era de esperar, su notoriedad se demostró rápidamente en la discusión sobre la eliminación al citar fuentes confiables. Y así es como debería funcionar el punto 5: el artista está en un sello importante, lo que sugiere que existe cobertura. Y luego se encuentra cobertura. -- 3family6 ( Háblame | Mira lo que he hecho ) 12:08, 16 de noviembre de 2024 (UTC) [ responder ]
Una sugerencia que añadiría es que estos dos criterios se apliquen únicamente a las bandas anteriores a un año específico, siendo ese año en el que los lanzamientos físicos todavía dominaban sobre las ventas digitales. No sé el año exacto, pero creo que es alrededor de 2000 a 2010. Es posible que todavía haya grupos más antiguos durante la época de los lanzamientos físicos que aún no tengan artículos que entren en uno de estos criterios. M asem ( t ) 20:02, 31 de octubre de 2024 (UTC) [ responder ]
Como alguien que ha tenido a WP:DSMUSIC en la lista de seguimiento durante la mayor parte de su historial de edición, y que tiende a eliminarlos, en realidad no veo un gran problema con estos criterios. Ciertamente parece cierto que la mayoría de los músicos que están firmados con un sello o son miembros de múltiples bandas con otros dos músicos que cumplen con WP:GNG , ellos mismos cumplen con GNG. Creo que a veces está justificado aceptar fuentes que no sean GNG en artículos en los que se cumple con un SNG (ver Wikipedia:Artículos para eliminar/John LeCompt para esto, ya que se aplica a c6 específicamente) y, lo que es más importante, NMUSIC contiene un lenguaje que permite eliminar artículos incluso cuando se cumple técnicamente (ver Wikipedia:Artículos para eliminar/Rouzbeh Rafie para un argumento más extenso al respecto. Mach61 23:29, 31 de octubre de 2024 (UTC) [ responder ]
Entendí que estos criterios complementaban a GNG, es decir, que si una banda o artista individual cumple con uno o más de estos criterios, es *probable* que sean notables. Sin embargo, en el pasado, cuando era un editor más joven y con menos experiencia, creo que entendí que estos eran agregados o alternativas a GNG. Así que creo que eso debería aclararse. Esto surgió en la discusión sobre la eliminación de Jayson Sherlock . Es miembro o ex miembro de varias bandas muy notables y, por esa razón, supuse que fácilmente tendría una cobertura independiente sobre él específicamente. Sin embargo, para mi sorpresa, solo hay una entrevista de él en una fuente confiable que proporcionaría notoriedad (hay algunas entrevistas en blogs personales o sitios menores que no serían RS excepto por las declaraciones que hace sobre sí mismo). Pero al menos un editor ha utilizado el criterio anterior para argumentar que el artículo debería conservarse. -- 3family6 ( Háblame | Mira lo que he hecho ) 12:20, 1 de noviembre de 2024 (UTC) [ responder ]
Como acotación al margen, las entrevistas no contribuyen al GNG a menos que incluyan SIGCOV secundario independiente (como una introducción sustancial de antecedentes por parte del entrevistador). JoelleJay ( discusión ) 15:39 1 nov 2024 (UTC) [ responder ]
De acuerdo. Es importante tenerlo en cuenta. Yo lo suponía y también por qué no confiaría en una entrevista singular como única fuente para establecer GNG.-- 3family6 ( Háblame | Mira lo que he hecho ) 16:30, 1 de noviembre de 2024 (UTC) [ responder ]
Así es como veo la mayoría de los SNG (y los valores atípicos deberían seguir su ejemplo). Como mínimo, podemos aclarar que NBAND está pensado como un indicador del GNG, y no como un sustituto. Shooterwalker ( discusión ) 02:04 2 nov 2024 (UTC) [ responder ]
Como alguien que pensaba que el antiguo NSPORTS era demasiado inclusivo y necesitaba una limpieza... ¿estas pautas de NBAND no parecen tan malas? Si se descubrió que dos músicos claramente notables habían formado un equipo poco conocido en los años 70, ese parece ser de hecho un tema notable y útil para tener un enlace en algún lugar, incluso si no hay toneladas de información sobre esta colaboración. Vale la pena mencionarlo porque los subtemas menores a menudo se fusionan con el tema general (por ejemplo, las canciones del álbum), pero puede que no haya una ubicación de fusión clara para esto si ambas partes fueron contribuyentes iguales, y un artículo separado breve es un compromiso aceptable. De manera similar, la queja sobre el n.° 5 parece ser sobre cuán "indie" es el sello hipotético, pero este parece un problema solucionable. Si una banda no pasa la prueba GNG, eso implica que sus dos álbumes realmente eran de un grupo indie muy desconocido y, por lo tanto, también no pasan la prueba NBAND, o que tenemos algún tipo de problema con fuentes que no están en inglés y que podemos considerar mantenernos en base a WP:CSB (es decir, que probablemente existan fuentes para pasar la prueba GNG, pero son difíciles de encontrar, y podemos confiar en que existen porque este era un sello importante y notable que lanzó el trabajo de la banda). La única sugerencia que puedo ofrecer es que el comentario en 6 sobre evitar la notabilidad circular probablemente podría formularse en el sentido de GNG, es decir, que los dos músicos notables deben cumplir con GNG y luego esto creará una notabilidad NBAND nueva y segura para su colaboración. SnowFire ( discusión ) 17:36, 4 de noviembre de 2024 (UTC) [ responder ]
La situación inversa, como la que se está discutiendo actualmente en Wikipedia:Artículos para eliminar/Jayson Sherlock , es aquella en la que tienes a alguien que estuvo/está en múltiples bandas notables, pero no hay una cobertura independiente sobre ellas como persona individual. -- 3family6 ( Háblame | Mira lo que he hecho ) 22:30, 7 de noviembre de 2024 (UTC) [ responder ]
Estoy de acuerdo con la desaprobación; "Confiar en el GNG para la notoriedad de la banda" es la respuesta correcta. Y es la respuesta correcta para muchas otras cosas sobre las que tenemos SNG que intentan ser alternativas al GNG. Tal vez el único justificable sea WP:NACADEMIC , porque se aplican consideraciones especiales en esa esfera (los académicos y otros investigadores que publican revistas generalmente son desconocidos para el público y la cobertura de los medios de comunicación de cara al público, como los periódicos, pero pueden tener impactos importantes en campos particulares y en el mundo; lo que determina su nivel de influencia es primordialmente la frecuencia de citación de su trabajo por parte de otros académicos). No se aplican tales consideraciones especiales con respecto a las bandas o la mayoría de las otras categorías. Tenemos algunos SNG que son útiles porque están escritos para cumplir con el GNG, para explicar de manera predictiva qué es más probable o improbable que pase una prueba GNG en ANI, en lugar de intentar ser una maniobra evasiva para el GNG. Si realmente necesitáramos un SNG para bandas y músicos, entonces el SNG actual para ellos podría reemplazarse por algo así. Sin embargo, en realidad no necesitamos un SNG para bandas y músicos.
PS: Las ideas en el actual NBAND SNG son tontas. Muchos grupos musicales tienen múltiples álbumes (es decir, canciones lanzadas al mismo tiempo bajo un nombre de grupo) y muchos sellos independientes (que pueden ser simplemente un tipo en su dormitorio) existen con múltiples grupos, algunos de ellos nominalmente notables [debido a los problemas de NBAND, lo que hace que esto sea un círculo vicioso], pero eso no hace que cada banda en ese sello nocional (ni el sello en sí) sea digno de una enciclopedia. Algunos de estos son grupos ridículamente oscuros [no es una denigración, probablemente estoy comprando su material]. Esto no es 1977; no necesitas una planta de prensado de vinilos para ser un sello musical. Solo necesitas descubrir cómo completar un formulario web en Bandcamp y Spotify, y tener una idea suficiente sobre cómo funciona la industria musical actual (a menudo solo dentro de una subcultura estrecha) como para poder convencer a algunos grupos (probablemente tus amigos en la misma escena) de que puedes ayudarlos si aceptan estar en tu lista. PD: Un tema secundario es que, de todos modos, los "álbumes" no son una buena métrica, ya que varios géneros no se basan en álbumes en absoluto, y la noción completa de álbumes está siendo cada vez más cuestionada en la era de la música a pedido. — SMcCandlish ☏ ¢ 😼 21:59, 15 de noviembre de 2024 (UTC) [ responder ]
Me encantaría ver que los números 5 y 6 se eliminaran por completo. ¿Qué hace falta para que eso suceda? ¿Cuál es el siguiente paso? Graywalls ( discusión ) 02:08 16 nov 2024 (UTC) [ responder ]
Si crees que esto supondría un cambio importante en las directrices, entonces probablemente deberías presentar una WP:PROPOSAL formal . WhatamIdoing ( discusión ) 04:52 16 nov 2024 (UTC) [ responder ]
WhatamIdoing , ¿aclarar que SNG no anula los requisitos de GNG sería un cambio importante? -- 3family6 ( Háblame | Mira lo que he hecho ) 11:57, 16 de noviembre de 2024 (UTC) [ responder ]
RfC: ¿Acortar el período para la petición de revocatoria?
La siguiente discusión está cerrada. Por favor, no la modifiques. Los comentarios posteriores deberán realizarse en una nueva sección.
Para cualquiera que no esté familiarizado con esto, la destitución de un administrador es un proceso nuevo que es exactamente lo que parece. Actualmente, hay un período de petición de 30 días: si 25 personas la firman, el administrador debe aprobar una nueva solicitud de autorización dentro de los 30 días para conservar las herramientas. ¿Deberíamos cambiar el período de petición?
Opción A: Mantener el mismo período de petición (30 días)
Opción B: Cambiar el plazo de petición a 7 días
Opción C: Algún otro período de tiempo (¿como 14 o 15 días?) que sea más largo que una semana pero más corto que un mes.
La discusión anterior está cerrada. No la modifique. Los comentarios posteriores deben realizarse en la página de discusión correspondiente. No se deben realizar más modificaciones a esta discusión.
Drm310 y yo tenemos un desacuerdo cortés sobre la interpretación de WP:PAID , y es muy posible que me equivoque. Lo que está muy claro es que si un editor es empleado de una empresa, es un editor pago. Lo que no está claro es qué sucede si el editor es el propietario de una empresa. Claro, hay un conflicto de intereses , pero ¿es un editor pago? Citaré a Drm310, ya que lo dice mejor que yo. "Dijeron que eran propietarios de una empresa y no empleados. Dijiste que eso los convierte en editores pagos. Siempre interpreté la política como: si una persona recibe (o espera) una compensación como parte de su trabajo, entonces es un editor pago. Pero si tiene una participación accionaria en la empresa/organización, entonces queda fuera de la definición de empleado. ¿Ahora lo estamos interpretando de modo que los propietarios también son editores pagos, porque obtienen un ingreso de su negocio?" Mi postura es que el propietario de una empresa cuenta como editor pago en virtud de su propiedad (ni siquiera necesita estar percibiendo ingresos). ¿Es correcta esa postura o es ir demasiado lejos con respecto a WP:PAID ? -- Yamla ( discusión ) 15:25 4 nov 2024 (UTC) [ responder ]
Yo lo leería como lo haces tú, @Yamla : tienen un interés personal en que la empresa tenga éxito, lo que, en mi opinión, en última instancia significa obtener "algo" de ello (que en la mayoría de los casos significará algún tipo de ingreso). Leerlo de otra manera tiene un ligero tufillo a (wiki-)abogacía. Lectonar ( discusión ) 15:35 4 nov 2024 (UTC) [ responder ]
Mmm. Bueno, Lectonar , siempre me ha parecido que la frase "puedes ganar con tu edición, por lo que efectivamente te pagan, incluso si en realidad no te pagan por la edición" es wikilawyering, por lo que evidentemente es una cuestión de punto de vista.
Siempre he considerado que la edición pagada no incluye la edición sobre el propio negocio, en línea con lo que dice Drm310 , pero mi experiencia es que muchos administradores, quizás la mayoría, lo toman de la misma manera que Yamla y Lectonar. En cierto modo, no hace mucha diferencia, ya que en ambos casos se aplica la cuestión del conflicto de intereses, pero hay formas en las que puede marcar la diferencia. En mi opinión, la forma más importante en la que puede marcar la diferencia es la consideración puramente práctica de que la mayoría de los propietarios de empresas que escriben sobre sus propios negocios no reconocen la "edición pagada" como una descripción de lo que están haciendo, por lo que es, en mi opinión, más útil utilizar otra redacción que tengan más probabilidades de entender que insistir "sí, es edición pagada". (Ya hay bastante problema con: "No, no me pagan por editar Wikipedia, es sólo parte de mi trabajo" ... "Sí, pero si es parte de un trabajo por el que te pagan, entonces es trabajo pago" ... "Sí, pero..." sin añadir otra capa de espacio para malentendidos.) Por lo tanto, creo que es más útil tratar la expresión "edición pagada" como si no se aplicara a la edición sobre el propio negocio.
En teoría, no nos corresponde a nosotros decidir qué significa la expresión, porque forma parte de los términos de uso de la Fundación Wikimedia, sobre los que no tenemos jurisdicción. Sin embargo, esos términos de uso se refieren a "todos y cada uno de los empleadores, clientes, beneficiarios previstos y afiliaciones" y, hasta donde puedo ver, no hay una definición o aclaración de la palabra "afiliación", por lo que eso no ayuda mucho. JBW ( discusión ) 16:10 4 nov 2024 (UTC) [ responder ]
Creo que un propietario es un "beneficiario previsto", siendo la propiedad un interés beneficioso en lo que se posee, incluso si no se puede analizar la "afiliación". Alanscottwalker ( discusión ) 16:17 4 nov 2024 (UTC) [ responder ]
Soy de la opinión de que PAID se aplica a los propietarios, pero la redacción de WP:PAID es lo suficientemente ambigua como para que una persona razonable pueda estar en desacuerdo con esa opinión, y creo que eso debería aclararse en esa página. Un propietario de una empresa aún puede ser un empleado de esa empresa (por ejemplo, si la empresa está configurada como una corporación C, puede considerarse un empleado para fines impositivos y de seguros). No creo que la aplicabilidad de la divulgación de contribuciones pagadas deba cambiar dependiendo de cómo estructure su empresa si el rol en la empresa está situado de manera similar. Si recibe una compensación por trabajar en una empresa como propietario o de otra manera, eso debe divulgarse. Incluso situaciones en las que un propietario no recibe pagos financieros directos o dividendos de su propiedad de la empresa (como con una empresa emergente más pequeña) aún necesitaría divulgarlo bajo WP:PAID , ya que el dinero no es la única forma de compensación. Incluso en una empresa unipersonal se les paga directamente por su trabajo en la empresa, lo mismo que si fueran empleados. La propiedad de la empresa no debería ser un vacío legal que excluya la necesidad de divulgación. - Aoidh ( discusión ) 16:48 4 nov 2024 (UTC) [ responder ]
@ Aoidh : ¿Alguien ha sugerido que debería evitarse la necesidad de divulgación? Si lo han hecho, no he visto dónde lo han hecho. Supuse que era obvio que existe la necesidad de divulgar la propia posición porque es un conflicto de intereses. JBW ( discusión ) 22:30 4 nov 2024 (UTC) [ responder ]
@ JBW : Estoy seguro de que lo he visto aparecer, pero no recuerdo dónde. Alguien con un conflicto de intereses que lea Wikipedia:Conflicto de intereses podría asumir razonablemente que si no se lo considera un editor pago, entonces no está obligado a revelar nada. La diferencia entre la redacción PAGADA ( obligatorio... requisito... debe revelar... no debe usar herramientas administrativas para ninguna actividad de edición paga ) contrasta con la redacción menos estricta de COI NO PAGADO ( se espera que revele... debe revelar... se desaconseja enfáticamente la edición de COI ). La sección Wikipedia:Guía simple y sencilla sobre conflictos de intereses#Divulgación también hace esta distinción. No digo que no crea que los COI deban divulgarse, pero alguien con un COI que se ponga a hilar fino sobre si el propietario de una empresa lo convierte en editor pago probablemente también hilaría fino en ese aspecto. - Aoidh ( discusión ) 23:51, 4 de noviembre de 2024 (UTC) [ responder ]
Si bien técnicamente un propietario no es un empleado, sería absurdo sugerir que PAID se aplica a los empleados pero no a los propietarios. ~~ Jessintime ( discusión ) 16:22 4 nov 2024 (UTC) [ responder ]
Jessintime No pretendo decirte que tu opinión sobre esto es "absurda"; prefiero simplemente decir que respetuosamente discrepo. Quizás quieras considerar cuál de esos dos enfoques es más constructivo. JBW ( discusión ) 16:28 4 nov 2024 (UTC) [ responder ]
No quise ser irrespetuoso, pero mi uso de la palabra "absurdo" aquí fue en referencia a la doctrina del absurdo . ~~ Jessintime ( discusión ) 16:34 4 nov 2024 (UTC) [ responder ]
Jessintime Vale, gracias por aclarar eso. Sin embargo, después de haber visto el artículo que has vinculado, me pregunto cuál crees que sería el resultado absurdo que se obtendría. ¿Qué es lo que se le permitiría hacer al propietario de una empresa y que no haría un empleado? Ciertamente no editar sin revelar un conflicto de intereses. JBW ( discusión ) 22:36 4 nov 2024 (UTC) [ responder ]
Creo que la respuesta de Buster a continuación (los pasantes no remunerados de Starlink contarían como editores pagos, pero no Elon) ilustra el problema. ~~ Jessintime ( discusión ) 17:18, 5 de noviembre de 2024 (UTC) [ responder ]
De la página de políticas: Los pasantes se consideran empleados a estos efectos. Por lo tanto, los pasantes no remunerados cuentan como editores pagos cuando editan el artículo de Wikipedia de Starlink para su empleador. Pero las ediciones de Elon Musk no contarían como ediciones pagadas. Eso me parece un resultado absurdo. ¿Entiendo mal la política? BusterD ( discusión ) 19:42 4 nov 2024 (UTC) [ responder ]
Alguien que posee algunas acciones de una gran empresa es uno de sus "propietarios" ante la ley, pero probablemente no tiene una participación financiera lo suficientemente grande como para que se considere un COI en términos de Wikipedia. Alguien que posee la mayoría de las acciones de una pequeña empresa, por otro lado, tiene un COI.— S Marshall T / C 22:10, 4 de noviembre de 2024 (UTC) [ responder ]
Si me permites extender tu ejemplo, si yo estuviera en el negocio de acciones o futuros, podría tener una participación (directa o de otro tipo) suficiente para ponerme en conflicto directo, sin importar cuál sea la empresa en cuestión. BusterD ( discusión ) 23:00 4 nov 2024 (UTC) [ responder ]
Acabo de ver un mensaje en la página de discusión de Yamla, donde creo que plantea un punto que yo he intentado plantear, pero él lo ha expresado quizás con más claridad que yo. Dijo: "Al final, sea cual sea el camino que tome el consenso, creo que la combinación de WP:PAID y WP:COI significa que el resultado final (aunque no la comunicación) termina siendo el mismo". Muchos de los comentarios anteriores parecen estar basados en la suposición de que no interpretar la "edición paga" como la inclusión de la edición por parte del propietario significaría permitir que los propietarios editen sin revelar nada, pero no sería así. JBW ( discusión ) 22:50, 4 de noviembre de 2024 (UTC) [ responder ]
Gracias por copiar mi comentario aquí, JBW. En mi publicación inicial, quise decir "Seguro, hay un conflicto de intereses " para cubrir este punto, pero no fui claro. Creo que la comunicación en torno a la edición paga es importante, incluso si el resultado final (el usuario tiene que declarar un conflicto) es el mismo. Este es un concepto que suele ser difícil de comunicar a los nuevos editores. -- Yamla ( discusión ) 22:56, 4 de noviembre de 2024 (UTC) [ responder ]
Creo que puede haber un malentendido más fundamental de WP:PAID aquí de lo que crees. La edición pagada se trata de personas a las que se les paga por editar . Tomemos Lo que está muy claro es que si un editor es un empleado de una empresa, es un editor pagado hasta el punto del absurdo: un volteador de hamburguesas en una cadena de restaurantes de comida rápida con 40.000 sucursales que edita el artículo sobre la cadena de ninguna manera recibe un pago por hacer esa edición. Su trabajo es voltear hamburguesas, no hacer relaciones públicas corporativas. Tienen un COI (positivo o negativo) debido a la relación laboral, pero a menos que el CEO o el departamento de relaciones públicas o quien sea que les diga a los empleados que editar Wikipedia ahora es parte de su trabajo, no es WP:PAID .Pero, como ocurre con muchas otras cosas por aquí, dado que WP:PAID tiene requisitos y sanciones más estrictos que WP:COI , la gente tiende a intentar estirar las definiciones lo más que pueda para utilizar los requisitos y sanciones más estrictos para combatir las ediciones que no les gustan. No me sorprendería que la gente de ese ámbito objetara mi párrafo anterior sobre la base de que restringir WP:PAID a las definiciones claras obstaculizaría sus esfuerzos por combatir el azote de los spammers.En cuanto al propietario de la empresa, si la empresa realiza ediciones pagas en nombre de los clientes, entonces la empresa en su conjunto, incluido el propietario, recibe WP:PAID por editar en nombre de los clientes de la empresa. Y la divulgación requerida incluye a esos clientes, no solo a su propiedad general de la empresa de edición paga. Por otro lado, si la empresa fabrica widgets, entonces diría que la edición del propietario es un conflicto de intereses muy importante, pero no es específicamente WP:PAID . Anomie ⚔ 00:21, 5 de noviembre de 2024 (UTC) [ responder ]
No estoy de acuerdo con esa interpretación de WP:PAID . La política dice: "Los usuarios que reciben una compensación por cualquier esfuerzo publicitario relacionado con el tema de sus contribuciones a Wikipedia se consideran editores pagos, independientemente de si recibieron una compensación específicamente por editar Wikipedia". Creo que es completamente razonable creer que la "publicidad" es casi siempre parte del trabajo del propietario de una empresa y otros funcionarios superiores, por ejemplo, los ocupantes de la C-suite, los miembros de la junta directiva. ElKevbo ( discusión ) 02:43, 5 de noviembre de 2024 (UTC) [ responder ]
Sí, y más aún, el propietario, los funcionarios y los miembros de la junta directiva son fiduciarios de la empresa, y son "compensados" e "incentivados" por la propiedad y/u otra compensación (dinero, bienes o servicios; la posesión de la empresa es un bien) para trabajar en el mejor interés de la empresa, ya sea editando Wikipedia o en cualquier otro lugar. -- Alanscottwalker ( discusión ) 12:52 5 nov 2024 (UTC) [ responder ]
Sin duda, el propietario único o mayoritario de la empresa tiene un conflicto de intereses real o un riesgo de conflicto de intereses (según la definición de conflicto de intereses que utilice), pero "pagado" implica más que eso... que alguien les está pagando y les está diciendo qué hacer. North8000 ( discusión ) 02:53 5 nov 2024 (UTC) [ responder ]
En mi opinión, WP:PAID debería dividirse en sus dos interpretaciones principales: "instruido (aunque sea implícito, por ejemplo, contratado para publicidad en general) para editar Wikipedia a cambio de una compensación" e "interés financiero directo en un tema". JoelleJay ( discusión ) 17:39 5 nov 2024 (UTC) [ responder ]
El problema aquí es WP:COI , no WP:PAID . Cuando te PAGAN por editar, el propietario (o alguien que actúe en nombre del propietario) te dice "tu trabajo es hacer esto por mí". Si no lo haces, pierdes tu trabajo/no te pagan, así que de ahí viene tu incentivo. WP:PAID existe, entre otras razones, porque hay empresas que intentan vender estos servicios a empresas/propietarios, y empresas/propietarios que pagan a personas para que editen en su nombre para que puedan decir "contratamos a profesionales, si son un problema, ¡échenles la culpa!". Es un tipo especial de edición de COI que es lo suficientemente común como para tener una política especial para ese tipo especial de edición de COI.
Cuando el propietario hace la edición, todas las preocupaciones especiales de PAID desaparecen, salvo la restante: la edición de COI. Pero eso lo cubre WP:COI . No hay nada especial en que el propietario de Mary Sue, propietario de Certified Reiki Thetan-Level 3 Shop edite un artículo sobre su negocio, que Rocker Boy Joe escribiendo sobre su banda Rocket Bobs, o Jensen Huang vandalizando artículos de AMD a través de una cuenta llamada User:AMDTROLL4V3R. No pierden sus trabajos, siguen teniendo sus ingresos y no se meten en problemas si no cumplen con sus obligaciones. Headbomb { t · c · p · b } 17:50, 5 de noviembre de 2024 (UTC) [ responder ]
Si tu trabajo incluye promocionar una empresa y vienes a Wikipedia para promocionarla, eso es edición PAGADA, seas propietario o no. Que alguien sea despedido por negarse no es el criterio, un propietario tiene un gran incentivo para promocionar su empresa y puede esperar ser compensado por ese esfuerzo a través del crecimiento y las ganancias de la empresa, y es el elemento de compensación lo que hace que un editor sea un editor pagado. - Aoidh ( discusión ) 17:58, 5 de noviembre de 2024 (UTC) [ responder ]
Esto es simplemente un WP:COI normal . No hay compensación a cambio ni ninguna dinámica de poder en juego cuando/si "no cumplen". Headbomb { t · c · p · b } 18:11, 5 de noviembre de 2024 (UTC) [ responder ]
No hay ninguna parte de WP:PAID que sugiera que una dinámica de poder o una consecuencia por el incumplimiento de la entrega sea un factor determinante, y los propietarios efectivamente reciben una compensación por su trabajo. Esto es especialmente cierto si se tiene en cuenta que la compensación no se limita a la remuneración. - Aoidh ( discusión ) 19:27 5 nov 2024 (UTC) [ responder ]
Recordatorio del administrador: reapertura del taller
Se le invita a refinar y elaborar propuestas para modificar el proceso de destitución en Wikipedia:Destitución de administradores/Reformulación . Una vez que se cierre la reformulación, las propuestas resultantes se someterán a votación en una convocatoria de propuestas. theleekycauldron ( discusión • ella/ella) 00:51, 8 de noviembre de 2024 (UTC) [ responder ]
1RR/3RR ciego
La aplicación ciega de las normas 1RR/3RR no beneficia al proyecto. La cuestión no debería ser si uno ha violado la norma, sino si la ha violado de una manera que no beneficia al artículo. Si no hay objeción a la violación, podemos asumir razonablemente que están beneficiando al artículo, o al menos no causando daño. La decisión debería quedar en manos de otros editores. ¿Podría utilizarse esto como arma? ¿Habría editores que alegaran daño cuando no lo hay? Por supuesto, pero eso es preferible a lo que tenemos ahora.
El problema, que sin duda les resultará familiar a los editores que lean esto, es que a menudo no hay suficientes editores "buenos" para proteger un artículo de los editores "malos" (maliciosos o simplemente inexpertos) y, al mismo tiempo, mantenerse dentro de los límites de 1RR o 3RR. No hay ninguna restricción en la cantidad de ediciones BOLD que puede hacer un editor determinado, ni en la cantidad de editores que realizan ediciones BOLD. ― Mandruss ☎ 00:09, 10 de noviembre de 2024 (UTC) [ responder ]
En las áreas conflictivas, la regla 1RR debe mantenerse en su totalidad, sin excepciones. De lo contrario, se desarrollarán rápidamente guerras de edición. GoodDay ( discusión ) 00:11 10 nov 2024 (UTC) [ responder ]
Si alguien está revirtiendo reversiones repetidamente, entonces hay una objeción a la violación por definición. Eso es lo que es la guerra de ediciones. Si alguien está haciendo la misma edición BOLD que necesita ser revertida varias veces, entonces también está en guerra de ediciones. Ya hay excepciones a estas reglas para las tonterías patentes o el vandalismo obvio. Si hay una interrupción rutinaria, entonces solo empeora el problema revertir una y otra vez en lugar de llevarlo a WP:RFPP . Si sientes la necesidad de hacer más de una o dos reversiones en una disputa de contenido, entonces es hora de considerar otras opciones o alejarte del artículo. The big feo alien ( discusión ) 01:31, 10 de noviembre de 2024 (UTC) [ responder ]
No se trata de guerras de ediciones ni de reversiones; el problema existe sin que se produzca una sola reversión. El editor A hace diez ediciones BOLD, cinco de las cuales son perjudiciales para el artículo porque son demasiado inexpertos (esto requiere años de dominio, por lo que no es nada raro). Los editores B, C, D y E contribuyen con veinte ediciones perjudiciales adicionales (junto con cualquier cantidad de ediciones buenas, siendo ese número irrelevante para nuestros propósitos aquí). Mientras tanto, los editores competentes F, G y H están limitados a un total de nueve reversiones, lo que deja 21 ediciones perjudiciales en el artículo. Yo digo que a F, G y H se les debería permitir revertir hasta que alguien alegue que están haciendo daño. ― Mandruss ☎ 02:04, 10 de noviembre de 2024 (UTC) [ responder ]
¿Dónde ves treinta ediciones perjudiciales de un artículo cada día? ¿Por qué no está protegido este artículo? ¿Por qué los editores F, G y H no inician una discusión? ¿Por qué están revirtiendo las ediciones del editor A individualmente en lugar de revertirlas? ¿Por qué es tan urgente que estas ediciones deban revertirse ahora mismo? Incluso si se encontraran con un artículo así, F, G y H no querrían participar en una reversión en equipo (que sigue siendo una guerra de ediciones) si supieran lo que están haciendo. The big feal alien ( discusión ) 02:07, 10 de noviembre de 2024 (UTC) [ responder ]
Usted puede reducir los números como desee; el problema existe de todos modos. El artículo está protegido, incluso con ECP, y no faltan editores registrados que tienen 30 días y 500 ediciones y aún les quedan años antes de que puedan editar con un nivel razonable de competencia. Algunos nunca llegan a ese punto. ¿Por qué los editores F, G y H no inician una discusión? ¿En serio? ¿Por qué están revirtiendo las ediciones del Editor A individualmente en lugar de revertirlas? Porque (1) es posible que no tengan el derecho de revertir, y el derecho de revertir no debería ser necesario para funcionar como editor, (2) estarían revirtiendo cinco ediciones buenas, y (3) es imposible si las ediciones del Editor A están intercaladas con las de cualquier otro editor. ¿Por qué es tan urgente que estas ediciones se deban revertir en este momento? Porque (particularmente en artículos grandes y muy activos) las ediciones malas pueden pasarse por alto fácilmente si no se detectan de inmediato. Luego permanecen en el artículo durante un tiempo indeterminado hasta que un editor competente los detecta y los corrige con una edición BOLD. Podrían ser meses o incluso años. ¿Eso es bueno para el artículo? ― Mandruss ☎ 02:27, 10 de noviembre de 2024 (UTC) [ responder ]
Puede que no tengan la opción de revertir correctamente : no es el punto principal de este hilo, pero Wikipedia:Twinkle tiene su versión de revertir, disponible para cualquier usuario registrado. — Bagumba ( discusión ) 04:57 10 nov 2024 (UTC)[ responder ]
¿Podrías darme un ejemplo o dos en los que esto haya causado un problema? Y observo que has respondido de forma inadecuada a las dos preguntas más importantes: si un artículo está sujeto a una guerra de ediciones, debería estar completamente protegido, y has descartado la pregunta "¿Por qué los editores F, G y H no están iniciando una discusión?" con "¿En serio?". Sí, por supuesto que es una pregunta seria. Iniciar una discusión es la mejor manera de desactivar una guerra de ediciones. Phil Bridger ( discusión ) 09:20 10 nov 2024 (UTC) [ responder ]
"¿En serio?", aunque va en contra de la política de WP:DR , podría ser una respuesta honesta. A menudo recibo solicitudes de protección de páginas o de bloqueo, en las que mi primera respuesta suele ser "¿dónde está la discusión?" — Bagumba ( discusión ) 10:02, 10 de noviembre de 2024 (UTC) [ responder ]
A menos que Mandruss sea extremadamente vago, de lo cual no tengo pruebas, no veo cómo esa respuesta puede ser honesta. Solo se necesitan unos segundos para iniciar una discusión, no más de lo que tomó iniciar esta, y la persona que la inicia gana algunos puntos extra. Phil Bridger ( discusión ) 17:08 10 nov 2024 (UTC) [ responder ]
extremadamente vago, de lo cual no tengo evidencia ¡Gracias! Tengo mi cuota de fallas y deficiencias, pero no creo que la pereza extrema sea una de ellas. Por lo tanto, debería haber nuevas discusiones para cada una de las malas ediciones (por separado en aras de la eficiencia y la organización), y las malas ediciones deberían permanecer en el artículo hasta que suficientes editores tengan el tiempo, el interés y la capacidad de atención para formar consensos en contra de ellas mientras atienden otros asuntos importantes. Esto, en un ATP donde estamos luchando por mantener la tabla de contenidos en un tamaño manejable incluso sin tales discusiones . No sé qué artículos estás editando, pero quiero trabajar allí. ― Mandruss ☎ 03:51, 11 de noviembre de 2024 (UTC) [ responder ]
¿En serio acabas de señalar a Donald Trump como tu ejemplo y luego dices que no sabes qué artículos no son así? El gran extraterrestre feo ( discusión ) 04:01, 11 de noviembre de 2024 (UTC) [ responder ]
Supongo que el artículo de Donald Trump es una anomalía poco común en la que el contenido de mala calidad es algo con lo que tenemos que convivir porque las normas actuales son incapaces de evitarlo. Después de todo, es solo un artículo. Me opondría a ese razonamiento. Diría que la calidad del artículo es al menos tan importante allí como en cualquier otro lugar. ― Mandruss ☎ 04:33, 11 de noviembre de 2024 (UTC) [ responder ]
Entonces, debería haber nuevas discusiones para cada una de las malas ediciones... : Sí, ¿o cuál es una alternativa? Tu sugerencia de favorecer las ediciones "buenas" sobre las "malas" es problemática cuando todos dicen que las suyas son las "buenas". Polarizar temas puede ser difícil para los administradores de patrullaje de WP:AGF para determinar las ediciones "buenas" y "malas" si no son expertos en la materia.— Bagumba ( discusión ) 05:43 11 nov 2024 (UTC) [ responder ]
Si la regla fuera "no repetir ediciones sin consenso" (en lugar de "no revertir"), se solucionaría este problema. Levivich ( discusión ) 03:42 10 nov 2024 (UTC) [ responder ]
¿Quién dijo algo sobre ediciones repetidas? ¿Me estoy perdiendo algo? Estoy cansado en este momento, así que es una posibilidad. ― Mandruss ☎ 04:04, 10 de noviembre de 2024 (UTC) [ responder ]
¿Qué quieres decir, quién lo dijo? Dije algo sobre ediciones repetidas :-) Si la regla fuera "no repetir ediciones sin consenso" 1x o 3x en 24 horas, en lugar de "no revertir" 1x o 3x en 24 horas (lo que lleva a todo el problema de "¿qué cuenta exactamente como una reversión?"), el problema que estás describiendo no ocurriría. El editor "malo" puede hacer 10 ediciones malas, y el editor "bueno" puede revertir las 10 ediciones sin violar la regla de no repetir 3RR, y el editor "malo" podría repetir 3 de esas 10 ediciones sin cruzar la regla de no repetir 3RR, y el editor "bueno" puede revertir las 3 sin cruzar la regla de no repetir 3RR, et voilá : equilibrio. El problema es que nos centramos en "revertir" en lugar de "repetir". Para reducir las guerras de ediciones, deberíamos prohibir que la gente repita sus ediciones, no que las "revierta" (lo que sea que eso signifique, exactamente). Levivich ( discusión ) 04:50 10 nov 2024 (UTC) [ responder ]
Bueno, tendré que volver después de dormir y tratar de comprenderlo. ― Mandruss ☎ 04:56, 10 de noviembre de 2024 (UTC) [ responder ]
La aplicación ciega de 1RR/3RR no beneficia al proyecto : ¿se refiere a la protección de páginas o a bloqueos? ¿Sobre temas polémicos o sobre cualquier tema? — Bagumba ( discusión ) 05:11 10 nov 2024 (UTC) [ responder ]
Hay una discusión RFC sobre la consideración de la literatura gris relacionada con la cobertura BLP en el Tablón de anuncios de confiabilidad que puede interesar a los observadores de esta página. Raladic ( discusión ) 15:37 10 nov 2024 (UTC) [ responder ]
Parece que se trata de una cuestión de política de verificabilidad, no de una evaluación de fuentes específicas. ¿Por qué estamos manteniendo la discusión en un tablón de anuncios? ¿Por qué no aquí o en WT:V ? BusterD ( discusión ) 16:11 10 nov 2024 (UTC) [ responder ]
Política wiki sobre Lista bibliográfica en un artículo sobre una persona famosa.
El usuario: Walter Tau y el usuario: Yngvadottir no pueden ponerse de acuerdo sobre si una lista de publicaciones sobre un cantante es apropiada en el artículo sobre este cantante Orville Peck . Coloqué esta lista “Bibliografía: publicaciones sobre Orville Peck” después de la sección “Filmografía”. Ella sigue borrándola sin citar una política wiki específica. Thriley explicó la eliminación con “Esto es excesivo” nuevamente sin citar una política wiki específica. ¿Puede alguien explicarnos qué política wiki regula las listas bibliográficas en un artículo? — Comentario anterior sin firmar agregado por Walter Tau ( discusión • contribs ) 16:06, 11 de noviembre de 2024 (UTC) [ responder ]
@ Walter Tau : Las políticas y pautas definen lo que está permitido en los artículos, no obligan a agregar nada. El hecho de que el contenido deba incluirse o no en un artículo es una decisión editorial que refleja el consenso de la comunidad interesada. A propósito, estoy de acuerdo en que una sección de Bibliografía tan grande es excesiva. Llévelo a la página de discusión y obtenga consenso allí sobre qué tan grande debe ser la bibliografía, si es que debe incluirse alguna, en el artículo. (Estoy ignorando la guerra de ediciones que ha estado ocurriendo, pero tenga en cuenta que cualquier guerra de ediciones futura puede dar lugar a sanciones por su edición). - Donald Albury 16:28, 11 de noviembre de 2024 (UTC) [ responder ]
Citar un artículo de una revista frente a citar la revista en sí
Quería dar a conocer esta discusión sobre la interpretación adecuada del ensayo WP:NJOURNALS . En esencia, la cuestión es si una revista que publica artículos citados con frecuencia cuenta como "citada con frecuencia" o si la revista en sí tiene que ser citada con frecuencia. Aunque el ensayo es solo un ensayo, se usa a menudo en las discusiones de AfD y las suposiciones sobre su significado han sido la base de las decisiones de cierre, por lo que aquí hay una cuestión material. Botterweg (discusión) 00:25 15 nov 2024 (UTC) [ responder ]
Probablemente no sea algo que deba anunciarse aquí. WT:N hubiera sido un mejor lugar. En cualquier caso, parece que tu pregunta ya ha sido respondida por otros. No estoy seguro de qué más hay que agregar. voorts ( discusión / contribuciones ) 01:21, 15 de noviembre de 2024 (UTC) [ responder ]
Gracias, todavía estoy aprendiendo a manejarme en estas páginas que se esconden tras bastidores. Lo que busco es un consenso claro en un sentido u otro. Nada de extravagancias, solo comentarios del tipo "estoy (o no) de acuerdo con fulano". Botterweg (discusión) 01:51 15 nov 2024 (UTC) [ responder ]
¿Proteger las etiquetas de las marionetas de calcetín?
¿Las páginas de usuarios de Sockpuppet con etiquetas deberían estar protegidas solo para usuarios confirmados o solo para administradores? Esto es para evitar la eliminación o modificación, ya que el filtro de edición solo impide la edición a usuarios con menos de 4 días de antigüedad y que hayan realizado menos de 10 ediciones. 125.63.140.154 (discusión) 00:04, 16 de noviembre de 2024 (UTC) [ responder ]
Los usuarios que no sean administradores pueden etiquetar en WP:RFPP como siempre. 1.129.104.29 ( discusión ) 00:13, 16 de noviembre de 2024 (UTC) [ responder ]
Mensajes del sistema duplicados, idénticos e inconsistentes
Estoy tratando de averiguar si estos mensajes se utilizan realmente por alguna razón o si ya no se utilizan y se pueden eliminar de forma segura. Recientemente retiré mi propio MFD de las tres páginas porque necesito obtener más ayuda con esto. Y también retiré una discusión rápida de ideas sobre criterios. Al investigar un poco en los archivos, encontré Wikipedia:Village pump (technical)/Archive 195#Nombres de pestañas inconsistentes en monobook para las dos últimas. Sin embargo, al observar el valor predeterminado, parece que se ha solucionado.
En cuanto a MediaWiki:Edit, existe phab:T310529. Este comportamiento se está volviendo bastante confuso y necesito averiguar qué está sucediendo.
Me pregunto si podemos extraer más de estos mensajes y tal vez, en un día lluvioso, podamos decidir qué hacer con ellos; enviarlos al MFD o qué.
Haciendo ping a los usuarios que estuvieron involucrados previamente en esto (al menos en los últimos días o cuando sea). @ Pppery @ Xaosflux @ Thryduulf @ Robert McClenon
Tengo otras preguntas sobre MediaWiki:Rollbacklinkcount ( editar | discusión | historial | enlaces | vigilancia | registros) y MediaWiki:Rollbacklinkcount-morethan ( editar | discusión | historial | enlaces | vigilancia | registros) , y recuerdo haber abandonado la discusión porque es una cuestión de estilo, pero tengo inquietudes sobre si alguna de estas modificaciones (especialmente las menores, menores en el sentido de que solo agregan una coma o cambian el caso o lo que sea) se están haciendo con consenso o no, y si son para resolver un problema temporal, por qué no se están deshaciendo una vez que se soluciona ese problema temporal.
Para ser claros, no tengo ningún problema con las modificaciones que se hacen para el bien de Wikipedia, como las que enlazan a las políticas de Wikipedia o a las páginas de ayuda de Wikipedia o las que añaden un estilo adecuado. Se trata principalmente de "ediciones menores" en las que se utiliza una puntuación, una capitalización o una redacción diferentes a las del mensaje original. Si de hecho hay un problema con un mensaje del sistema para todas las wikis (no solo para Wikipedia), entonces la redacción debería corregirse en el software.
Hay alrededor de 1000 anulaciones según los datos de AllMessages. Revisarlos todos probablemente sea una molestia, especialmente porque la mayoría de estos mensajes no tienen la documentación adecuada en MediaWiki. Awesome Aasim 02:19, 9 de noviembre de 2024 (UTC) [ responder ]
Gracias por retirar las nominaciones del MFD a la espera de una investigación más profunda. No entiendo los detalles de cómo se utilizan esos archivos y preferiría, antes de votar si eliminar algo, saber qué es y para qué se utiliza:
Antes de construir un muro, preguntaría para saber
Estos tres son mensajes muy antiguos y no tengo tiempo para buscar códigos en ningún lugar donde puedan estar en juego. Como señaló phab:T310529, al menos uno de ellos todavía se está importando en las apariencias actuales. La mayor parte del uso de estos se ha migrado a mensajes más nuevos, pero es posible que algo aún los esté usando. A menos que haya un problema real, los dejaría así. Los problemas de código sin duda deberían plantearse en phab. — xaosflux Talk 10:48, 9 de noviembre de 2024 (UTC) [ responder ]
No veo (editar) en ningún lado. (skin-view-edit) sí, pero no (editar). ¿Quizás falta algo? Impresionante Aasim 14:58, 9 de noviembre de 2024 (UTC) [ responder ]
Previsualizar el uso de un mensaje en el lugar donde crees que aparecerá no evalúa correctamente si aparecerá allí. mw:Codesearch es la herramienta adecuada. Izno ( discusión ) 16:58 9 nov 2024 (UTC) [ responder ]
Incluso con la búsqueda de códigos, algunos mensajes se utilizan de formas poco convencionales y pueden ser difíciles de localizar (existen definiciones dinámicas y definiciones compuestas). — Th e DJ ( discusión • contribuciones ) 22:31, 9 de noviembre de 2024 (UTC) [ responder ]
En cualquier caso, cambiar MediaWiki:Edit para que diga "Editar" tiene ventajas, en concreto, que permite a los editores utilizar el mensaje del sistema en las plantillas. Lo mismo ocurre con MediaWiki:Protect y MediaWiki:Delete .
Administradores: ¿"Eliminar" y "proteger" aparecen en minúsculas cuando se utiliza un diseño que no es MonoBook? De forma predeterminada, deberían estar en mayúsculas. Awesome Aasim 19:18, 11 de noviembre de 2024 (UTC) [ responder ]
Espero estar en el lugar correcto con este problema; si no, ¡agradecería mucho una redirección! He estado tratando de arreglar la apariencia de la plantilla:Chloroplast DNA , que se supone que proporciona una versión cliqueable de File:Nicotiana tabacum Choroplast genome.svg , pero no logro que se muestre correctamente tanto en la computadora de escritorio como en el móvil (ver plantilla discusión:Chloroplast DNA ). Se usa en Chloroplast y Chloroplast DNA , dos artículos bastante importantes, el primero de los cuales se está ordenando actualmente. Tengo la persistente sensación de que debería haber una forma completamente diferente de hacer esto que la que [[[:template:Chloroplast DNA]] hace.
He preparado una maqueta de la plantilla en User:Felix QW/sandbox 2 con una página de prueba en User:Felix QW/sandbox si alguien quiere experimentar con ella sin afectar el espacio principal. ¡Gracias de antemano a cualquiera que esté dispuesto a echarle un vistazo! Felix QW ( discusión ) 12:06 9 nov 2024 (UTC) [ responder ]
Sí, una plantilla que utilice una gran cantidad de valores absolutos de visualización sobre una imagen tendrá dificultades en el móvil. El móvil tiene diferentes suposiciones sobre el ancho de una imagen, incluso si preferirías que tuviera un tamaño determinado. Izno ( discusión ) 16:56 9 nov 2024 (UTC) [ responder ]
Quizás usar mw:Extension:ImageMap en su lugar funcionaría. * Pppery * ha comenzado... 22:34, 9 de noviembre de 2024 (UTC) [ responder ]
Muchas gracias por la sugerencia. ¡Era exactamente el tipo de solución que estaba pensando! Felix QW ( discusión ) 22:37 9 nov 2024 (UTC) [ responder ]
Después de pensarlo un poco más, no estoy seguro de cómo funcionaría ImageMap con una imagen svg que no necesariamente tiene un "tamaño original". ¿El "tamaño nominal" de 1125 × 960 píxeles informado en Commons es un "tamaño original" en este sentido? Felix QW ( discusión ) 11:40 10 nov 2024 (UTC) [ responder ]
Funciona, al menos si el <svg>...</svg>elemento tiene width=atributos height=que tienen valores distintos de cero sin unidades, por ejemplo, width="1125" height="960"como en c:Archivo:Nicotiana tabacum Choroplast genome.svg. Véase también mw:Extension:ImageMap#Syntax description, que dice Todas las coordenadas corresponden a la imagen de tamaño completo, no a la imagen visible. -- Red rose64 🌹 ( discusión ) 15:36 10 nov 2024 (UTC) [ responder ]
¡Gracias! También encontré Template:World image map , que también es un mapa de imagen superpuesto a un svg. Cuando tenga algo de tiempo libre, jugaré con ImageMapEdit y veré qué puedo hacer. Felix QW ( discusión ) 15:51 10 nov 2024 (UTC) [ responder ]
Página de estilo CSS convertida en artículo
En la Wikipedia en cingalés intenté importar manualmente Help:Your first article/styles.css de aquí a allá si:උදවු:Your first article/styles.css. Pero se convirtió en una página de tipo artículo. Nunca me había pasado antes. ¿Alguien puede solucionar esto? VihirLak007 ¡envíame un mensaje! / duh. 19:45, 9 de noviembre de 2024 (UTC) [ responder ]
¿Puede un administrador cambiar el modelo de contenido de esta página? Si:උදවු:Tu primer artículo/styles.css VihirLak007 ¡envíame un mensaje! / duh. 19:54, 9 de noviembre de 2024 (UTC) [ responder ]
Tienes que preguntarle a alguien que tenga derechos de administrador en siwiki. Aquí nadie los tiene. *Pppery* ha comenzado... 20:04, 9 de noviembre de 2024 (UTC) [ responder ]
Ah, cierto. Gracias. Por cierto, ¿no existen administradores que tengan derechos de administrador en todos los proyectos de Wikipedia? ¿Quiénes podrían hacer este tipo de ediciones en proyectos que abarcan varias wikis si se les pide ayuda? Solo tengo curiosidad. VihirLak007, ¡envíame un mensaje! / duh. 20:12, 9 de noviembre de 2024 (UTC) [ responder ]
Los sysops globales y los m:Stewards existen. *Pppery* ha comenzado... 20:16, 9 de noviembre de 2024 (UTC) [ responder ]
¿Cómo crear una página con "CSS saneado" desde cero? Cada vez que lo intento, la ventana de creación de páginas es para una nueva página de tipo artículo (no conozco el término técnico) y no para una página de modelo de contenido CSS. VihirLak007 ¡Escríbeme! / duh. 22:28, 9 de noviembre de 2024 (UTC) [ responder ]
Solo puedes crearlos en el espacio de plantilla, con el sufijo .css. Pero después de eso, puedes moverlos a otro espacio de nombres. Consulta también el uso de TemplateStyles. — Th e DJ ( discusión • contribuciones ) 22:34, 9 de noviembre de 2024 (UTC) [ responder ]
... también puedes crearlos como tales en el espacio de nombres del módulo. Izno ( discusión ) 01:20 10 nov 2024 (UTC) [ responder ]
Si eres administrador, también puedes usar Special:ChangeContentModel e ingresar el título de una página que no existe para crearla con ese modelo de contenido. Matma Rex talk 21:06, 10 de noviembre de 2024 (UTC) [ responder ]
Pregunta sobre bloqueo parcial y creación de páginas.
En este momento, en ANI hay una discusión que apunta a prohibir a un usuario crear nuevos artículos, y ha surgido una subpropuesta para permitirles usar WP:AFC en su lugar. Mi pregunta sería la siguiente: si marca la casilla "Crear nuevas páginas y cargar nuevos archivos", ¿eso se aplica a todo el sitio o solo se aplicará al espacio de nombres seleccionado para el bloqueo parcial? ¿O deberíamos considerarlo simplemente como una prohibición de tema tradicional sin implementación técnica? Simplemente aléjese de este mundo... hoy 22:22, 10 de noviembre de 2024 (UTC) [ responder ]
@ Just Step Sideways es un control para todo el sitio. Los bloques de 'espacio de nombres' solo sirven para editar. — xaosflux Talk 23:39, 10 de noviembre de 2024 (UTC) [ responder ]
@Novem Linguae me criticará por sugerir esto: Editar filtro para evitar que ese editor cree nuevos artículos en el espacio principal. (Pero no, por favor, no lo haga. Si el editor no tiene autocontrol después del consenso para banearlo de un tema, es posible que se gane un ticket para que lo bloqueen). – robertsky ( discusión ) 14:11, 13 de noviembre de 2024 (UTC) [ responder ]
Los filtros de edición son costosos en términos de rendimiento al enviar una edición y de mantenimiento, por lo que normalmente no deberían escribirse para evitar que un solo usuario haga algo. Así que sí, probablemente sea mejor que el usuario simplemente ejerza un poco de autocontrol :) – Novem Linguae ( discusión ) 14:15, 13 de noviembre de 2024 (UTC) [ responder ]
+2. Abusefilter no debería usarse para restringir a un único usuario. — xaosflux Discusión 14:32, 13 de noviembre de 2024 (UTC) [ responder ]
+3, aunque no tengo idea de a qué usuario te refieres (no frecuento AN/ANI). Es de suponer que la solución a esto es simplemente decirle al usuario que deje de crear artículos en el espacio principal, lo que se hará cumplir mediante un bloqueo de la creación de páginas en todo el sitio si continúa a pesar de la prohibición. Se cubriría un poco más que la prohibición, pero sin duda se haría cumplir la prohibición. EggRoll97 ( discusión ) 01:44, 15 de noviembre de 2024 (UTC) [ responder ]
Discusión sobre filtros protegidos en el tablón de anuncios de filtros de edición
Hay una discusión en curso sobre filtros protegidos y para llegar a un consenso sobre la incorporación abusefilter-access-protected-varsde ayudantes y administradores de filtros de edición que no sean administradores. Para obtener más información o para participar, consulte Wikipedia:Tablón de anuncios de filtros de edición#Filtros protegidos . Codename Noreste 🤔 Discusión 00:19, 11 de noviembre de 2024 (UTC) [ responder ]
Noticias tecnológicas: 2024-46
Últimas novedades tecnológicas de la comunidad técnica de Wikimedia. Por favor, informe a otros usuarios sobre estos cambios. No todos los cambios le afectarán. Hay traducciones disponibles.
Actualizaciones para editores
En los wikis con la extensión Traducir habilitada, los usuarios notarán que FuzzyBot ahora creará automáticamente versiones traducidas de las categorías utilizadas en las páginas traducidas. [2]
En 1.44.0-wmf-2, la lógica de la función Wikibase getAllStatementscambió para comportarse como getBestStatements. La invocación de la función ahora devuelve una copia de los valores que son inmutables. [4]
Los usuarios de la API REST de Wikimedia, como los operadores de bots y los encargados del mantenimiento de herramientas, pueden verse afectados por las actualizaciones en curso. La API redireccionará algunos puntos finales de contenido de página desde RESTbase a los nuevos puntos finales de la API REST de MediaWiki. Los puntos finales afectados incluyen la obtención de metadatos de página/revisión y el contenido HTML renderizado. Estos cambios estarán disponibles en testwiki a finales de esta semana, y otros proyectos seguirán su ejemplo. Este cambio no debería afectar a la funcionalidad existente, pero los usuarios activos de los puntos finales afectados deben verificar el comportamiento en testwiki y plantear cualquier inquietud en el ticket relacionado de Phabricator.
A fondo
Los administradores y usuarios de los proyectos Wikimedia donde está habilitado Automoderator ahora pueden monitorear y evaluar métricas importantes relacionadas con las acciones de Automoderator. Este panel de control Superset calcula y agrega métricas sobre el comportamiento de Automoderator en los proyectos en los que está implementado. Gracias al equipo de Herramientas de moderación por este panel de control; puede visitar la página de documentación para obtener más información sobre este trabajo. [5]
Reuniones y eventos
21 de noviembre de 2024 (8:00 UTC y 16:00 UTC): convocatoria comunitaria con voluntarios y partes interesadas de Wikimedia Commons para ayudar a priorizar las iniciativas de apoyo para el año fiscal 2025-2026. El tema de esta convocatoria es cómo se debe organizar el contenido en Wikimedia Commons.
Noticias tecnológicas preparadas por escritores de Tech News y publicadas por bot • Contribuir • Traducir • Obtener ayuda • Dar retroalimentación • Suscribirse o cancelar la suscripción.
Las imágenes no se muestran en ninguna página Topjimz (discusión) 01:20 12 nov 2024 (UTC) [ responder ]
Parece que hay un problema con tu navegador o con la forma en que está configurado, a menos que hayas tomado medidas para suprimir la visualización de imágenes (según WP:NOSEE ). 331dot ( discusión ) 01:58, 12 de noviembre de 2024 (UTC) [ responder ]
@Topjimz: Las imágenes se cargan desde upload.wikimedia.org, por ejemplo, https://upload.wikimedia.org/wikipedia/commons/7/70/Example.png, que veo aquí en esta sección. Si lo ve en upload.wikimedia.org pero no aquí, es posible que su navegador esté bloqueando las imágenes si se cargan desde otro dominio. Si no lo ve en upload.wikimedia.org, es posible que su navegador o conexión a Internet estén bloqueando ese dominio. Algunas imágenes de interfaz se cargan desde en.wikipedia.org, por ejemplo, https://en.wikipedia.org/w/resources/assets/poweredby_mediawiki.svg. ¿Lo ve? PrimeHunter ( discusión ) 03:03 12 nov 2024 (UTC) [ responder ]
Lo que quise decir fue que cuando veo a una persona en su sitio, no puedo ver su foto.
¿Qué tipo de persona? ¿Estás hablando de artículos biográficos sobre personas conocidas o de otros usuarios del sitio? ¿Tienes un enlace a una página en la que tengas este problema? Nardog ( discusión ) 07:24 12 nov 2024 (UTC) [ responder ]
A todas las personas que busco no les aparece la foto, pero aparece un pequeño recuadro en el lugar donde suele estar la foto de la persona. Topjimz (discusión) 08:34 12 nov 2024 (UTC) [ responder ]
¿Puedes darme un ejemplo específico de un artículo que hayas visto? 331dot ( discusión ) 08:52 12 nov 2024 (UTC) [ responder ]
¿Esto sucede solo cuando estoy conectado o cuando estoy conectado y desconectado? -- Red rose64 🌹 ( discusión ) 09:01 12 nov 2024 (UTC) [ responder ]
Parece que su navegador está configurado de alguna manera para bloquear imágenes, tal vez como sugiere PrimeHunter anteriormente. 331dot ( discusión ) 10:11 12 nov 2024 (UTC) [ responder ]
@Topjimz: Necesitamos más información para brindar más ayuda.
¿Ves una imagen que dice "Esto es sólo un ejemplo" en esta sección?
¿Lo ves en https://upload.wikimedia.org/wikipedia/commons/7/70/Example.png?
¿Ves una imagen en https://en.wikipedia.org/w/resources/assets/poweredby_mediawiki.svg?
¿Ves imágenes en sitios web no relacionados como el logotipo de Google en https://www.google.com/?
Uso Chrome, que tiene el problema, y rara vez uso Firefox. Firefox consume demasiado. Topjimz (discusión) 12:44 12 nov 2024 (UTC) [ responder ]
Importar plantillas de taxonomía
¿Hay alguna manera de importar todas las plantillas de taxonomía a un proyecto de Wikipedia diferente (por ejemplo, Wikipedia en cingalés) de una sola vez? He estado haciendo manualmente una por una cuando alguien hace un nuevo artículo para un animal o una planta y aparece el error del cuadro de información que dice que falta una plantilla. No hay traducción de nombres, ya que son nombres científicos y, en casos raros, se dirigen al mismo nombre escrito en letras locales. ¿Hay alguna manera de importar todo esto de manera más fácil para que luego la gente pueda hacer las páginas de artículos faltantes relevantes de clados, géneros, familias, etc. y no tener que copiar y pegar cada plantilla una por una? Espero haber sido claro VihirLak007 ¡envíame un mensaje! / duh. 09:35, 12 de noviembre de 2024 (UTC) [ responder ]
La posibilidad de que otras Wikipedias utilicen las plantillas de taxonomía surge con bastante frecuencia. Actualmente hay 119 000 plantillas de taxonomía. Supongo que se podría obtener una lista utilizando la API, pero no sé si se puede utilizar para obtener una descarga masiva y luego importarlas a otro lugar. Hay una categoría: Category:Taxonomy_templates . — Jts1882 | discusión 13:22, 12 de noviembre de 2024 (UTC) [ responder ]
He investigado un poco y creo que se puede hacer en dos pasos.
Primero, exporte las plantillas de taxonomía de Wikipedia en inglés a un archivo XML. Use Special:Export y exporte el archivo desde Category:Taxonomy_templates . Probé esto y descargué un archivo de 4 Mb.
En segundo lugar, importe el archivo a la Wikipedia de destino. Esto requiere permisos especiales, por lo que solo puede hacerlo un administrador. Ni siquiera puedo acceder a la página para ver las opciones, pero supongo que hay una opción para importar el archivo XML descargado.
Espero que esto ayude. Me interesaría saber si funciona, ya que a menudo nos preguntan sobre el uso de interwike en las páginas de discusión automatizadas de taxobox. — Jts1882 | discusión 16:38, 12 de noviembre de 2024 (UTC) [ responder ]
Tenga en cuenta que la Wikipedia en inglés no tiene plantillas de taxonomía para todos los taxones con artículos (y mucho menos para los taxones que no tienen artículos). Hay alrededor de 20.000 taxones con artículos que aún no tienen una plantilla de taxonomía. Plantdrew ( discusión ) 20:49 12 nov 2024 (UTC) [ responder ]
Veo. ¡ Anotado VihirLak007 hmu! / claro. 05:23, 13 de noviembre de 2024 (UTC) [ respuesta ]
Entonces le pedí a un administrador de allí los derechos de importador/importador interwiki, me dijeron que no tienen poder para darme ese derecho, pero un administrador sí puede. ¿Dónde puedo encontrar administradores ? VihirLak007, ¡envíame un mensaje! / duh. 05:23, 13 de noviembre de 2024 (UTC) [ responder ]
Para recibir derechos de importador, primero deberá realizar una solicitud en su wiki para demostrar que existe consenso para que se le otorgue este permiso. Esta solicitud debe cumplir con los requisitos establecidos en meta:Solicitudes de administradores/Permisos/Requisitos mínimos de votación § Importador temporal (según meta:Importador, no se otorgará acceso permanente de importador a menos que la comunidad local tenga una política que lo permita específicamente). A modo de ejemplo, la solicitud más reciente de acceso de importador en enwiki está aquí , aunque esa era una solicitud de acceso permanente. Luego, presentaría una solicitud a los administradores en meta:SRP. Tenga en cuenta que este es un permiso muy sensible (básicamente otorga la capacidad de agregar ediciones falsas al historial de una página), por lo que los estándares para otorgarlo son (o al menos deberían ser) altos.Si no prevés utilizar este permiso con frecuencia, creo que podrías iniciar una discusión en tu wiki para solicitar la aprobación de estas importaciones específicas. Si esa discusión tuviera éxito, presentarías una solicitud en meta:SRM para que un administrador se encargue de las importaciones. La otra alternativa, que evita por completo el problema de los permisos de importación, sería que un bot copie las plantillas en tu wiki (sujeto a la política de bots local, por supuesto). 50.223.140.130 ( discusión ) 07:55, 13 de noviembre de 2024 (UTC) [ responder ]
Sí. Un mayordomo que se encargue de las importaciones suena mejor. Lo intentaré de esa manera. También es más seguro. VihirLak007 ¡Escríbeme! / duh. 08:31, 13 de noviembre de 2024 (UTC) [ responder ]
Eso debería funcionar, pero tenga en cuenta que la importación desde un archivo XML solo puede ser realizada por importadores (o más específicamente, usuarios con el importuploadderecho); otros administradores solo pueden importar a través de un interwiki, que solo puede hacer una página a la vez. 50.223.140.130 ( discusión ) 07:15, 13 de noviembre de 2024 (UTC) [ responder ]
Sincronización entre diferentes wikis
¿Hay alguna forma de sincronizar los contenidos de las plantillas/listas en las distintas wikis? Por ejemplo: Plantilla:Totd . Imagina que otro proyecto wiki también tiene esta plantilla. ¿Hay algún código que podamos introducir para que todo lo que se actualice/agregue/cambie/muestre en la plantilla de la wiki en inglés también se actualice/agregue/cambie/muestre en la otra wiki a través de su plantilla? Será útil para cosas como noticias técnicas, Totd, etc. VihirLak007 ¡Escríbeme! / duh. 11:41, 12 de noviembre de 2024 (UTC) [ responder ]
Es un deseo que tengo desde hace mucho tiempo, ver phab:T121470. CMD ( discusión ) 13:27 12 nov 2024 (UTC) [ responder ]
Oh maaaan. ¡Gracias por cierto VihirLak007 hmu! / claro. 05:23, 13 de noviembre de 2024 (UTC) [ respuesta ]
@ VihirLak007 Había un bot que proporcionaba esta funcionalidad, pero creo que se rompió. Creo que ahora esta funcionalidad solo sincroniza módulos (lo que tiene sentido, porque es más fácil hacer que sean independientes del lenguaje y de la wiki que las plantillas). — The DJ ( discusión • contribuciones ) 12:47, 13 de noviembre de 2024 (UTC) [ responder ]
Hay dos aspectos de esto: uno es la plantilla global wiki/sincronización, el otro es el soporte multilingüe. Por lo general, los módulos con subpáginas '/config' o '/configuration' son más fáciles de sincronizar, ya que las configuraciones y traducciones multilingües están en esas páginas de configuración. Además de eso, hay módulos que cambian los argumentos, lo que provoca un cambio en las traducciones en todos los wikis. Por lo tanto, no es un trabajo de copiar y pegar. Snævar ( discusión ) 14:03, 13 de noviembre de 2024 (UTC) [ responder ]
Problemas con el modo oscuro
La clase mw-no-invert, utilizada para garantizar que los colores se muestren correctamente en modo oscuro, no parece funcionar en la escala internacional Fujita en ningún lugar, excepto en las tablas laterales tituladas "Clasificaciones de clasificación de tornados". – Laundry Pizza 03 ( d c̄ ) 20:18, 12 de noviembre de 2024 (UTC) [ responder ]
La página se ve muy bien en modo oscuro (navegador Brave en Mac OS). ¿Puedes darme un ejemplo específico de una parte del artículo que no se muestra como se esperaba? ¿Qué parte del artículo, qué hace y qué esperabas que hiciera? – Jonesey95 ( discusión ) 20:29, 12 de noviembre de 2024 (UTC) [ responder ]
LaundryPizza03 , no veo, |class="mw-no-invert"por ejemplo, en la tabla de la escala internacional Fujita § Medición de tres segundos . Las tablas de "Clasificación de tornados" que aparecen flotando a la derecha en la versión § 2018 de eg sí lo incluyen y se muestran como se supone que está previsto (de manera diferente, al menos).Creo que los colores invertidos se ven bien; de hecho, los caracterizaría como "más interesantes" que el degradado amarillo-rojo que se suele utilizar. Esto es bueno, ya que el color Template:Storm tiene alrededor de 5300 transclusiones. Folly Mox ( discusión ) 13:57 14 nov 2024 (UTC) [ responder ]
En realidad, se me ocurrió antes (cuando ya era demasiado tarde para trabajar y escribirlo) que, dado que la mayoría de estos colores de insensibilidad a las tormentas se realizan como bgcolor="#{{storm colour|value}}", alguien podría modificar {{ Storm colour }} para que aparezca después de la cadena hexadecimal recuperada de Module:Storm categorías/categories" class="mw-no-invert . Por supuesto, esto es un mal diseño y probablemente romperá (o al menos molestará al linter sobre) algún subconjunto de transclusiones llamadas sin encerrar comillas, o que ya contienen un |class=parámetro en el estilo de celda de la tabla. Sin embargo, debería alterar todos los artículos de una sola vez. Folly Mox ( discusión ) 17:16, 14 de noviembre de 2024 (UTC) [ responder ]
Error de secuencia de comandos en dispositivos móviles que provoca que los encabezados dejen de mostrarse
Si revisa https://en.m.wikipedia.org/wiki/2024_United_States_presidential_election en Chrome con las herramientas para desarrolladores y el Galaxy S20 activados, no se muestran títulos en Resultados y el depurador se detiene en un error de jQuery. -- SarekOfVulcan (discusión) 19:42 13 nov 2024 (UTC) [ responder ]
Los encabezados deberían estar arreglados ahora. No estoy seguro de si se trata de un error de jQuery. Puede ser de un script de usuario. – Ammarpad ( discusión ) 22:28, 13 de noviembre de 2024 (UTC) [ responder ]
El color de fuente no cambia en los cuadros de información cuando el modo oscuro está activado
En la wiki sinhala, algunos cuadros de información no cambian el color de fuente a blanco en el modo oscuro, por lo que no son legibles. ¿Cómo solucionar esto y dónde encontrar exactamente el código que determina el color de fuente según el modo que esté usando un usuario? Si es posible, ¿alguien puede solucionarlo?
El cuadro de información que tiene el problema en este asunto:
Plantilla: ඡන්ද විමසීම තොරතුරු පැනලය (elección del cuadro de información)
si:මාධ්යවිකි:Common.css tiene colores codificados, yo empezaría por ahí y los reemplazaría con tokens del Codex según mw:Recomendaciones para la compatibilidad del modo nocturno en los wikis de Wikimedia. Sjoerd de Bruin (discusión) 08:50, 14 de noviembre de 2024 (UTC) [ responder ]
¿Cuál es la forma de hacer cumplir la prohibición de creación de artículos utilizando el software?
Viendo este caso de ANI , me pregunto si hay una manera de hacer cumplir la prohibición de crear páginas desde el software, como si el usuario sancionado hubiera perdido su autoconfirmación (pero sin perder la capacidad de editar páginas semiprotegidas). Esto también podría extenderse a otros espacios de nombres, como el espacio de nombres Draft: o User: si es necesario. FMecha ( para hablar | para ver el registro ) 18:22, 14 de noviembre de 2024 (UTC) [ responder ]
Técnicamente, es posible bloquear parcialmente la creación de cualquier tipo de página. Es técnicamente posible bloquear parcialmente la edición de todo el espacio de nombres del artículo. Cualquier otra cosa se puede hacer usando un filtro de edición, lo que generalmente no se hace en esta situación.Las restricciones que son tan simples que una computadora podría (incluso en teoría) hacerlas cumplir son raras: la comunidad tiende a depender de prohibiciones de temas que son inherentemente subjetivas por naturaleza, por lo que no creo que valga la pena gastar tiempo codificando nuevas características de MediaWiki para implementar esto. * Pppery * ha comenzado... 18:27, 14 de noviembre de 2024 (UTC) [ responder ]
Creación de un nuevo conjunto de plantillas para las elecciones del STV
Hola a todos. Actualmente estoy intentando crear un nuevo conjunto de plantillas para las elecciones de STV.
Las plantillas estarían pensadas principalmente para su uso en las elecciones de Irlanda del Norte, donde hay tres bloques (unionista, nacionalista y “otros”), pero podrían adaptarse a otros contextos.
A modo de ilustración, aquí está el resultado de las elecciones a la Asamblea de 2022 para el distrito electoral de West Tyrone, tal como aparece actualmente en Wikipedia.
Así es como me gustaría que se viera la plantilla, y también cómo me gustaría que se viesen todas las plantillas para todos los resultados de las elecciones STV de Irlanda del Norte.
Elecciones a la Asamblea de 2022 – West Tyrone: 5 escaños
Tenga en cuenta que también me gustaría que el color del partido y el color del bloque se muestren en "Resultados por partido", "Resultados por bloque" y en el panel de resumen en la parte inferior derecha, y probablemente preferiría que se muestren las abreviaturas de cada partido, en lugar del nombre corto de cada partido (he escrito libremente las abreviaturas en el panel central, pero las abreviaturas reales difieren).
Tenga en cuenta las siguientes adiciones:
Cada candidato y partido tendría su bloque en la lista (unionista, nacionalista u "otros"). También habría una opción "sin clasificar" (señalada con una X), destinada a independientes poco conocidos cuya afiliación no puede determinarse a través de ninguna fuente.
El recuento total de votos de primera preferencia y el porcentaje de votos, y el cambio de los mismos con respecto a la última elección, se mostrarían para cada partido y cada bloque, en lugar de solo mostrar explícitamente el recuento de votos/el porcentaje de votos para cada candidato individual.
'Mayoría de partido' y 'mayoría de bloque' mostrarían el margen entre el partido/bloque más grande en el distrito.
También se muestra una oscilación entre los dos partidos más grandes y también entre los dos bloques más grandes.
Los paneles indican el partido más grande y el bloque más grande, y si tienen pluralidad o mayoría, respectivamente.
Se muestra un resumen de electores, participación, votos válidos, etc., con desgloses porcentuales completos y cambios numéricos/porcentuales entre esa elección y la anterior.
Un panel de resultados resumidos en la parte inferior derecha indicaría si hubo cambios en los escaños entre partidos/bloques y cambios en los legisladores elegidos dentro de cada partido en comparación con la elección anterior.
Hasta ahora, he hecho las plantillas para el panel más a la izquierda, pero aún no para ninguno de los otros paneles.
Para ser claro, me gustaría poder armar algo usando Lua/las plantillas, que toma los recuentos de votos de primera preferencia de la tabla más a la izquierda, los suma para cada partido (y también para los independientes de cada bloque; no quiero que los independientes de diferentes bloques se sumen colectivamente), y automáticamente genera el recuento total de votos y la participación en los votos para cada partido, y también para cada bloque, en los paneles correspondientes.
También sería interesante si los votos de primera preferencia de los candidatos se pudieran sumar para producir el voto válido, y si la entrada numérica de electores, participación, votos nulos, votos válidos, etc. se pudiera mostrar automáticamente como porcentajes de la cifra de electores, y si la cuota se pudiera calcular automáticamente en función del número de escaños y votos válidos.
Referencias
^ "Declaración de las personas nominadas – West Tyrone" . Consultado el 8 de abril de 2022 .
Agradecería cualquier orientación al respecto y cualquier comentario constructivo sobre el diseño propuesto. Hice lo mejor que pude según lo que sabía, pero puede que haya una manera de mejorarlo. ¡Muchas gracias! PointUnderstander ( discusión ) 18:59 14 nov 2024 (UTC) [ responder ]
Cambia la tabla que hay alrededor de las tablas "Elecciones a la Asamblea 2022 – West Tyrone: 5 escaños", "Resultados por partido" y "Resultados por bloque" para usar un div. De esa manera, el móvil puede mover las tablas hacia abajo en la página, mientras que no hay ancho disponible en el móvil para las tres. Snævar ( discusión ) 23:56 14 nov 2024 (UTC) [ responder ]
Muchas de estas preguntas sobre cómo se ve, qué columnas se deben mantener, si se deben agregar nuevas, son más bien una pregunta para la discusión de Wikipedia:WikiProject Elections and Referendums . Este foro es más bien sobre cómo lograr este diseño. Hay una o más plantillas que suman números, no las estoy rastreando lo suficiente como para saber cuáles son. Snævar ( discusión ) 10:49, 16 de noviembre de 2024 (UTC) [ responder ]
Snævar , De esa manera, los dispositivos móviles pueden tirar las tablas hacia abajo en la página , y en el escritorio . — Qwerfjkl talk 11:11, 16 de noviembre de 2024 (UTC)[ responder ]
Infobox del Partido Republicano
No puedo obtener ninguna respuesta en la página en cuestión, así que tal vez pueda obtener ayuda aquí. En la página del Partido Republicano (Estados Unidos) , el cuadro de información no muestra al líder de la minoría del Senado, Mitch McConnell . Aunque sí lo ves en la ventana de edición. GoodDay ( discusión ) 19:52 14 nov 2024 (UTC) [ responder ]
No veo a McConnell en la ventana de edición en el contexto del cuadro de información. Izno ( discusión ) 21:11 14 nov 2024 (UTC) [ responder ]
@ Izno : Lo volví a agregar y ahora el cuadro de información no muestra al líder de la mayoría de la Cámara, Steve Scalise. GoodDay ( discusión ) 23:08, 14 de noviembre de 2024 (UTC) [ responder ]
Creo que he encontrado la solución. Bajé las entradas de los líderes de 1-6 a 0-5. GoodDay ( discusión ) 23:14 14 nov 2024 (UTC) [ responder ]
Hay algunos problemas con las plantillas en el encabezado de la página. No tengo una idea clara de cuáles podrían ser los problemas, pero algunas plantillas no parecen existir o algunos parámetros son incorrectos.
Voy a contactar al monje @Trappist para volver a comprobarlo, pero estoy bastante seguro de que el problema es que el parámetro nunca fue admitido. Realmente no entiendo cómo no se detectó antes de hoy, que es quizás la pregunta más interesante que tendría. Izno ( discusión ) 21:17, 14 de noviembre de 2024 (UTC) [ responder ]
|translit-standard=no es un parámetro compatible; utilice |translit-std=. No se detectó hasta hoy porque recién hoy actualicé Module:Lang para detectar este tipo de parámetros desconocidos.
La función de autocompletar búsqueda selecciona resultados aleatorios al usar la flecha hacia abajo
Seguimiento en la tarea T379983 de Phabricator
Recientemente intenté buscar algunas cosas y noté que si presiono la flecha hacia abajo en los resultados de autocompletar, selecciona un resultado aleatorio, en lugar del resultado esperado de seleccionar el primero en la lista (y luego bajar un nivel si se presiona nuevamente, etcétera). Por ejemplo, para probar esto, escribí "AS" en la barra de búsqueda, que mostró "AS", "Fútbol de asociación", "Associated Press", "Asesinato de John F. Kennedy", entre otros. Presioné la flecha hacia abajo y resaltó el último resultado, "ASEAN". La presioné nuevamente y resaltó "síndrome de Asperger", que es el sexto resultado en la lista y 4 resultados por encima de "ASEAN". Esto continúa durante algún tiempo, pero generalmente salta por la lista a intervalos aleatorios. Verifiqué que tenía activado el modo seguro antes de intentar esto y estoy usando la última versión de Chrome de 64 bits, la versión 131.0.6778.70. EggRoll97 ( discusión ) 01:11 15 nov 2024 (UTC) [ responder ]
Por cierto, dado el día, puede que sea WP:THURSDAY , pero no estoy seguro de que ese sea el caso. EggRoll97 ( discusión ) 01:13 15 nov 2024 (UTC) [ responder ]
Yo también, Windows 10 versión 22H2, Firefox 132.0.2 (actualización reciente), todas las máscaras excepto Vector-2022 y Minerva Neue, inicié sesión y cerré sesión. El síntoma principal parece ser que en el cuadro de búsqueda, las funciones de las flechas hacia arriba y hacia abajo se intercambian. También afecta a Commons:. -- Red rose64 🌹 ( discusión ) 01:22, 15 de noviembre de 2024 (UTC) [ responder ]
Probablemente esto esté relacionado con phab:T379983, aunque, por supuesto, puedes informar una tarea aparte. Izno ( discusión ) 01:33, 15 de noviembre de 2024 (UTC) [ responder ]
Parece que sí, y parece que se ha incorporado un cambio, por lo que esto debería (con suerte) resolverse bastante pronto. EggRoll97 ( discusión ) 01:38 15 nov 2024 (UTC) [ responder ]
Estoy teniendo el mismo problema con Vivaldi (7.0.3495.11 (64 bits)) en Windows 11 Home 23H2. ¿Por casualidad tienes la máscara heredada Vector 2010 de Wikipedia (la antigua interfaz gráfica de usuario predeterminada)? Tengo este problema con esa máscara, pero no con la nueva máscara Vector de Wikipedia. Tube · of · Light 11:21, 15 de noviembre de 2024 (UTC) [ responder ]
Tengo el mismo problema en Firefox 128.4.0 con Vector 2010 en macOS 12.7.6. – dudhhr talk contribs she her 22:57, 15 de noviembre de 2024 (UTC) [ responder ]
Se necesita ayuda con Lua en Template:Text diff
La plantilla {{ Text diff }} está causando algunos errores de etiquetas mal anidadas en Linter que no parecen poder solucionarse localmente en las páginas. No es un problema nuevo, pero hemos solucionado la mayoría de los problemas de Linter que se pueden solucionar de alta prioridad y estamos tratando de limpiar los últimos casos difíciles. Estoy buscando personas con conocimientos de Lua para ayudar en Template talk:Text diff#Lint errors . Cualquier pista será apreciada. Gracias de antemano. – Jonesey95 ( discusión ) 01:57, 15 de noviembre de 2024 (UTC) [ responder ]
Filtrar registros: registro (estoy seguro de haber visto otros registros hace un par de días, pero es difícil encontrarlos)
¿Qué son estos enlaces? ¿Tienen algo que ver con los bots? – 2804:F1...F5:391A ( ::/32 ) ( discusión ) 17:41 15 nov 2024 (UTC) [ responder ]
Radware vende software anti DDoS, supongo que estos editores estaban usando una herramienta automatizada para completar las citas (es decir, la herramienta de citas automáticas en el editor visual), que el software de Radware detectó como tráfico de bots y bloqueó. 86.23.109.101 ( discusión ) 17:53, 15 de noviembre de 2024 (UTC) [ responder ]
Páginas con errores de referencia que provocan diferencias visuales
Hay una categoría con un enlace rojo, Categoría:Páginas con errores de referencia que desencadenan diferencias visuales , que aparece de repente de la nada en más de 2000 páginas y sigue creciendo. La encontré con una edición no relacionada con otra página que no tenía eso cuando comencé a editar la página, pero de repente lo tenía tan pronto como guardé mi edición, y al intentar "expandir plantillas" en la página no pude identificar de dónde provenía.
La última vez que ocurrió algo así, hace un par de semanas, fue una Categoría:Páginas absolutamente inútiles y no deseadas que usaban la extensión JsonConfig y que se crearon y luego se eliminaron rápidamente en cuestión de días por ser inútiles y no deseadas.
Pero, por supuesto, las páginas no pueden quedar en categorías con enlaces rojos, por lo que esto debe crearse o desaparecer. ¿Alguien podría investigar esto y crear la categoría de inmediato si realmente se desea o averiguar cómo hacer que desaparezca si no se desea? Gracias. Bearcat ( discusión ) 21:53 15 nov 2024 (UTC) [ responder ]
Se extrajo una página, Brisbane Airport , que tiene una referencia de grupo sin una lista de referencias. Sospecho que será la mayoría de los casos. En el analizador actual, esa nota parece no aparecer en ninguna lista, sino que se muestra un error en la parte inferior de la página. En Parsoid, tanto esta como el error se muestran en la parte inferior. Izno ( discusión ) 22:28 15 nov 2024 (UTC) [ responder ]
Parece haber sido el resultado de la actividad en el contexto de phab:T372709 y/o su hijo phab:T378386. Probablemente el analizador antiguo necesita una actualización para generar el mismo resultado que Parsoid. Izno ( discusión ) 22:44 15 nov 2024 (UTC) [ responder ]
Sí, esto es todo lo que se necesitaba en una página de discusión elegida al azar. -- Red rose64 🌹 ( discusión ) 22:32 15 nov 2024 (UTC) [ responder ]
Rediseño de cerraduras y otros iconos
Retomando esta propuesta , quiero que los íconos se vean más claros y elegantes; eventualmente agregaré más a los íconos (como buenos artículos, artículos de audio, etc.) También quiero agregar grilletes de letras basados en la región, por lo que, por ejemplo, 拡 (拡張, Kakuchō) sería el ícono de protección extendida japonés, lo mismo con 満 (満杯, Manpai) para protección completa.
Petición de nuevos iconos para Wikipedia. (Disponible para todos)
por 2I3I3 ( discusión ) 16:25 16 oct 2024 (UTC) [ responder ]
Estoy de acuerdo con otros en que estos nuevos íconos parecen anticuados. Sin embargo, si estamos hablando de cambios en los íconos de bloqueo, entonces debo decir que el morado para carga protegida es incongruentemente llamativo. Cremastra — discusión — c 20:23, 17 de octubre de 2024 (UTC) [ responder ]
Estoy de acuerdo y apoyaría con gusto una propuesta para oscurecerlo, ¿quizás #813ec3? Rexo ( discusión | contribuciones ) 20:33 29 oct 2024 (UTC) [ responder ]
Oposición. Creo que los degradados o biseles hacen que estos íconos sean menos claros y elegantes, al menos en su versión actual. Los íconos también se vuelven menos legibles en resoluciones más pequeñas, ya que la parte del grillete de los candados ocupa más espacio, lo que hace que el símbolo real en el interior sea más pequeño.
Quién sabe, parece que el diseño gráfico se está alejando poco a poco del diseño plano, así que tal vez en unos años... quidama talk 22:19, 23 de octubre de 2024 (UTC) [ responder ]
Me opongo firmemente a intentar ejecutar un script de geolocalización en cada carga para intentar crear etiquetas dinámicas aquí. En todo caso (lo cual tampoco me gusta), las etiquetas deberían seguir el lenguaje de la interfaz de usuario. — xaosflux Talk 17:39, 16 de octubre de 2024 (UTC) [ responder ]
Entiendo las diferencias, solo estaba sugiriendo (porque realmente no hablo ningún otro idioma, podrías proponer una versión específica). Además, más adelante agregaré las letras en los grilletes.
por 2I3I3 ( discusión ) 19:16 16 oct 2024 (UTC) [ responder ]
y los iconos* 2I3I3 ( discusión ) 19:16 16 oct 2024 (UTC) [ responder ]
Los formatos de archivo SVG se pueden traducir. Consulte c:Commons:Translation possible/Learn more. WhatamIdoing ( discusión ) 23:33 16 oct 2024 (UTC) [ responder ]
Opóngase a que la diferenciación primaria (única) sea el color, ya que eso brinda menos información que el esquema actual y es inútil para quienes no tienen habilidades para ver el color. — xaosflux Talk 17:41, 16 de octubre de 2024 (UTC) [ responder ]
Estoy de acuerdo con Xaosflux en este punto. Además, los dos problemas del antiguo esquema de iconos (color y sombreado "realista" que no se ve muy bien en iconos pequeños), que fueron las razones del cambio inicial, también están presentes en este.En cuanto a los símbolos basados en regiones, tendría más sentido mostrarlos en función de la edición del idioma y, dado que cada edición del idioma ya establece sus propios estándares para este tema, no hay mucho más que podamos hacer. Chaotic Enby ( discusión · contribuciones ) 18:13, 16 de octubre de 2024 (UTC) [ responder ]
Estoy de acuerdo , pero solo un poco. Si agregaras las letras, sería mejor. Además, una solución para tu clasificación por regiones podría ser hacer una clasificación por idioma (como "O" de "Oficina" se convertiría en "S" de "Escuela" en un "inglés invertido" teórico). The Master of Hedgehogs ( converse ) ( erizos ) 14:33, 17 de octubre de 2024 (UTC) [ responder ]
¿Esos iconos/colores funcionarán con el modo oscuro? También estoy de acuerdo en que las letras son esenciales. Thryduulf ( discusión ) 14:44 17 oct 2024 (UTC) [ responder ]
Véase también Grillete . Son candados y la parte superior en forma de U es el grillete. WhatamIdoing ( discusión ) 20:22 17 oct 2024 (UTC) [ responder ]
Pensé que estábamos usando "shackle" como la palabra para describir algo por un solo aspecto con el fin de evitar la confusión con la edición de protección/bloqueo. Aaron Liu ( discusión ) 18:13 2 nov 2024 (UTC) [ responder ]
Bueno, no deberíamos, porque como señaló @WhatamIdoing , el grillete es una parte de un candado. Y simplemente usar la palabra "candado" evita la confusión, sin llamar a las cosas de la manera incorrecta. (Incluso tiene exactamente la misma cantidad de letras). FeRDNYC ( discusión ) 03:55 3 nov 2024 (UTC) [ responder ]
Otra solución más en busca de un problema. *Pppery* ha comenzado... 16:18, 17 de octubre de 2024 (UTC) [ responder ]
Según WP:WIKICLICHE, nos han pedido que no digamos esto tanto, debido a problemas con la cadena de suministro: si los usamos demasiado, podríamos ver una gran escasez en el futuro. Pero espero podernoGenerar más calor que luz con este comentario, o tirar al bebé junto con el agua de la bañera. Cremastra — discusión — c 20:22, 17 de octubre de 2024 (UTC) [ responder ]
Nunca tires al bebé junto con el agua del baño. Esto contaminará tu sistema de recolección de aguas grises. Al igual que otras carnes, los bebés no son compostables, por lo que deben clasificarse en el flujo de desechos del vertedero a menos que la autoridad de gestión de residuos municipal indique lo contrario. Folly Mox ( discusión ) Folly Mox ( discusión ) 20:46 17 oct 2024 (UTC) [ responder ]
¿El agua del baño es la misma a la que se supone que debo llevar a este caballo? Remsense ‥ 论21:40, 17 de octubre de 2024 (UTC) [ responder ]
Tal vez esté debajo de un puente, eso explicaría todo este problema. jlwoodwa ( discusión ) 01:14 19 oct 2024 (UTC) [ responder ]
El sombreado pseudo-3D parece anticuado en comparación con los iconos planos actuales. La mayoría de los sistemas de diseño modernos (incluido Codex, que es el nuevo sistema de diseño para los wikis de Wikimedia) se basan en iconos planos. -- Ahecht ( PAGINA DE DISCUSION) 18:36, 17 de octubre de 2024 (UTC) [ responder ]
¿Qué pasa con los íconos como destacado, bueno y de audio? 2I3I3 ( discusión ) 18:55 17 oct 2024 (UTC) [ responder ]
Sólo para travesuraAún parece un paso atrás. El icono actual de "Buen artículo", además de tener un sombreado que distraiga menos y ser más legible, tiene un estilo coherente con muchos de nuestros otros iconos. El icono actual de "Artículo destacado", aunque no es coherente con los demás, es bastante único y reconocible en diseño, mientras que este parece una estrella genérica.Solo por diversión, una vez hice una estrella de "Buen artículo" al estilo de la de FA; no estaba destinada a ninguna implementación oficial más allá de mi script personal , por supuesto, pero es interesante ver cómo se vería. Chaotic Enby ( discusión · contribuciones ) 22:14, 17 de octubre de 2024 (UTC) [ responder ]
¿Qué es lo que realmente pasa? Aaron Liu ( discusión ) 17:10 2 nov 2024 (UTC) [ responder ]
¿Alguna vez has visto el ícono del artículo destacado en tamaño completo? (Si no, compruébalo en File:Cscr-featured.png . Te esperaré.) ... Me guste o no la estrella GA de Chaotic Enby , en realidad tiene un estilo bastante armonioso con la estrella FA actual, que (como se señaló) actualmente no es consistente con nada más en ningún otro lugar. Podría decirse que es bien conocido/reconocible (Chaotic plantea ese argumento, de todos modos), pero, para ser honesto, tengo la sensación de que la gran mayoría de los lectores nunca lo ven más grande que la escala de la cabeza de un alfiler, y ni siquiera reconocerían la imagen real, de tamaño completo, como nuestro ícono FA. FeRDNYC ( discusión ) 04:10, 3 de noviembre de 2024 (UTC) [ responder ]
He visto el ícono de FA completo; la estrella de GA parece sacada directamente de Cthulhu (...positivamente). Es divertido, pero creo que GA debería estar más en línea con el resto de los íconos de calificación de artículos debido al menor rigor. Aaron Liu ( discusión ) 13:26 3 nov 2024 (UTC) [ responder ]
Para ser justos, es definitivamente un diseño conceptual más que una propuesta real. En todo caso, prefiero tener el ícono de GA actual como nuestro ícono oficial, ya que es más armonioso con básicamente cualquier cosa que no sea la estrella de FA. Chaotic Enby ( discusión · contribuciones ) 22:18, 4 de noviembre de 2024 (UTC) [ responder ]
Lamentablemente, no se trata de mejoras visuales en absoluto. Son claras regresiones en el diseño, y los íconos actuales están bien. Nuestro sistema es específico para la Wikipedia en inglés, por lo que es perfectamente apropiado que su diseño sea relativo al idioma inglés. Remsense ‥ 论19:29, 17 de octubre de 2024 (UTC) [ responder ]
Estoy desconcertado. Al empezar con Reinstalar esta propuesta , me haces pensar que quieres revitalizar alguna propuesta fallida. Pero luego sigo tu enlace y veo que la propuesta llevó a la implementación de nuevos íconos de candado, lo que; supongo, quieres decir revertir . Tampoco entiendo qué quieres decir con grilletes de letras basados en regiones ; ¿te refieres a artículos sobre , por ejemplo, Japón? ¿O artículos vistos por alguien que se supone que hemos adivinado que podría estar en Japón? ¿O alguien con el idioma japonés listado en un cuadro de usuario en su página de Usuario? Es Wikipedia en inglés, así que no puedo ver que las dos últimas sean opciones útiles, y la primera solo conducirá a discusiones y confusión y eso ya lo tenemos . Los íconos actuales me parecen bastante claros, aunque no sé cómo medir "elegante", supongo. En resumen: desconcertado . — JohnFromPinckney ( discusión / ediciones ) 12:15, 18 de octubre de 2024 (UTC) [ responder ]
Me refiero a que los grilletes de letras basados en regiones son básicamente como las letras de los grilletes pero con diferentes traducciones regionales. (Esto probablemente no funcionará debido a la publicación de @Chaotic Enby ).
por 2I3I3 ( discusión ) 18:36 18 oct 2024 (UTC) [ responder ]
Entonces (solo para ver si lo entiendo finalmente), estás proponiendo en la Wikipedia en inglés que la Wikipedia en japonés use íconos con simbología japonesa, y que la Wikipedia en español use algún indicador en español en el candado, etc. ¿Sí? — JohnFromPinckney ( discusión / ediciones ) 22:30 18 oct 2024 (UTC) [ responder ]
Por ahora, opónte. El status quo está bien. Sin embargo, es realmente genial que estés contribuyendo con tus habilidades gráficas al movimiento. Estoy seguro de que hay algunas áreas menos destacadas que realmente podrían beneficiarse de tus habilidades. – Novem Linguae ( discusión ) 03:55, 23 de octubre de 2024 (UTC) [ responder ]
Oposición : Las nuevas propuestas son agradables, pero a mí personalmente me gusta más el estilo de las antiguas, y los iconos planos también me parecen más actuales. Las cadenas regionales parecen una buena idea, pero no parecen estar en esta propuesta, así que diré que las apoyo (quizás en el estilo de diseño antiguo, según mi preferencia). Mrfoogles ( discusión ) 20:22 23 oct 2024 (UTC) [ responder ]
Me opongo a Remsense. Los nuevos íconos 3D parecen sacados de los primeros tiempos de Internet. Además, el sombreado hace que los íconos parezcan innecesariamente "voluminosos" (no estoy seguro de cómo decirlo). Nythar ( 💬 - 🍀 ) 22:33, 25 de octubre de 2024 (UTC) [ responder ]
También me opongo aquí. No se trata de un status quo ni de resistencia al cambio, prefiero ampliamente los íconos actuales a los reemplazos propuestos. (Admito que son subjetivos) Puntos a favor de los íconos actuales sobre los nuevos:
El aspecto más plano se verá mejor en tamaños pequeños (ya que estos íconos en realidad se muestran en una fracción del tamaño en que se muestran en este hilo).
Lo mismo ocurre con la fuente más cuadrada.
Lo mismo ocurre con los arcos de grillete más gruesos.
Los grilletes delgados y el cuerpo rectangular dan a los reemplazos propuestos la apariencia de bolsos, no de candados.
La colocación de las letras es más uniforme y precisa en los íconos actuales; los reemplazos propuestos parecen haber sido "elaborados a ojo". En mi humilde opinión, es mejor codificar a mano el arte SVG de este tipo (si no desde cero, al menos como una pasada de finalización para limpiar el código), con todas las dimensiones precisas y uniformes.
Aprecio el esfuerzo y lamento ser crítico, pero no me gustan en absoluto. El conjunto actual, por otra parte, está bastante bien diseñado y optimizado para su propósito, lo cual es una consideración importante al diseñar obras de arte funcionales de este tipo. Me resulta desconcertante que alguien quiera reemplazarlos, ya que, sorprendentemente, hay poco margen de mejora en mi humilde opinión. FeRDNYC ( discusión ) 13:19 26 oct 2024 (UTC) [ responder ]
Creo que los conjuntos propuestos pueden haber sido interesantes en el momento de la propuesta anterior. Esas cerraduras serían más apropiadas para algo como en 2008. Es por la misma razón por la que los semáforos son siempre (de arriba a abajo) rojo, amarillo y verde. Y por la que las puertas de los trenes británicos necesitan puertas que tengan suficiente contraste con el resto (véase la ETI de PRM ). En otras palabras, no basta con utilizar el color solo para distinguir.
Además, esta es la misma razón por la que los logotipos se están volviendo más planos. JuniperChill ( discusión ) 01:49 2 nov 2024 (UTC) [ responder ]
Oposición : no soy partidario de los íconos propuestos (ver también el comentario de Nythar), y los candados actuales funcionan bastante bien. Sin embargo , apoyaría un rediseño de los íconos de GA/FA (/los diversos íconos del mismo estilo) en un estilo similar a los candados actuales. Rexo ( discusión | contribuciones ) 20:30, 29 de octubre de 2024 (UTC) [ responder ]
¿Qué pasaría si mantuviéramos los grilletes y el ícono bueno, consiguiéramos un nuevo ícono destacado y hiciéramos una función incorporada que permitiera que los grilletes fueran compatibles con el modo oscuro? 2I3I3 ( discusión ) 03:07 2 nov 2024 (UTC) [ responder ]
Eso todavía no es un grillete. (Y, para Rexo, no veo por qué los símbolos de artículos de calidad deberían implicar protección y edición bloqueada). Aaron Liu ( discusión ) 17:07 2 nov 2024 (UTC) [ responder ]
(para aclarar: el estilo utilizado por muchos íconos en la wiki (incluyendo FA/GA) se siente anticuado, y los candados tienen un aspecto más limpio que creo que podría usarse como base para futuros rediseños. No creo que eso conduzca inherentemente a que los símbolos de calidad impliquen protección). Rexo ( discusión | contribuciones ) 13:54, 4 de noviembre de 2024 (UTC) [ responder ]
No creo que los íconos de Norro o FA estén desactualizados, y el uso de candados para indicar calidad simplemente no tiene sentido semántico. Adoptamos los candados porque mostraban que el artículo estaba bloqueado y no se podía editar. Aaron Liu ( discusión ) 14:07 4 nov 2024 (UTC) [ responder ]
@ Aaron Liu No creo que Rexo se refiera a utilizar candados reales; creo que se refiere a desarrollar un diseño más plano inspirado en nuestros íconos de protección y similar a ellos . Cremastra ( u — c ) 20:56, 4 de noviembre de 2024 (UTC) [ responder ]
¿Cómo se hace eso sin quitar elementos de las cerraduras? Aaron Liu ( discusión ) 21:32 4 nov 2024 (UTC) [ responder ]
Creo que puedes lograrlo tomando los elementos que no son de bloqueo, como el texto y el fondo de color sólido. Cremastra ( u — c ) 21:35, 4 de noviembre de 2024 (UTC) [ responder ]
Entonces, básicamente, la interfaz de usuario de OOUI/Codex, como se muestra en Usuario:Arsonxists/Flat Icons (excepto la sección de iconos de temas). Aaron Liu ( discusión ) 21:40 4 nov 2024 (UTC) [ responder ]
Más o menos, al menos eso es lo que creo que quieren decir. Cremastra ( u — c ) 21:47, 4 de noviembre de 2024 (UTC) [ responder ]
Disculpen la confusión, pero sí, más o menos esto. Rexo ( discusión | contribuciones ) 22:32 4 nov 2024 (UTC) [ responder ]
Estoy confundido. ¿Las cerraduras se ven bien en el modo oscuro (de Vector 2022)? El fondo de Office es un poco difícil de ver, pero el resto se ve bien para mí. Rexo ( discusión | contribuciones ) 13:56 4 nov 2024 (UTC) [ responder ]
Sólo para que estemos todos en la misma página, en cuanto a terminología:
Son diferentes ¿Ves?
Cremastra ( u — c ) 17:12 2 nov 2024 (UTC) [ responder ]
Nuestro artículo Shackle dice "Un grillete es también una pieza de metal de forma similar que se utiliza con un mecanismo de bloqueo en los candados . [1] ". Algunos aquí parecen confundidos, pero cualquiera que use "grillete" para referirse a la parte del asa del ícono que parece un bolso de mano está en lo correcto. Anomie ⚔ 21:18, 2 de noviembre de 2024 (UTC) [ responder ]
\o/ Técnicamente estoy en lo cierto: "¡El mejor tipo de razón!" (Lamentablemente, te sorprenderá saber con qué poca frecuencia ocurre eso). FeRDNYC ( discusión ) 03:43 3 nov 2024 (UTC) [ responder ]
¿En serio? ¿Estás citando un artículo de Wikipedia para definir qué significa "grillete"? ¿No sabes que cualquiera puede editar artículos en ese sitio? — penultimate_supper 🚀 ( discusión • contribuciones ) 16:05, 14 de noviembre de 2024 (UTC) [ responder ]
He actualizado el encabezado de la sección para que no sea confuso (excepto, supongo, para una persona cuyo idiolecto equipara cerraduras y grilletes, lo que es más bien como llamar a su puerta "manija" o "perilla"). — SMcCandlish ☏ ¢ 😼 21:21, 15 de noviembre de 2024 (UTC) [ responder ]
Oposición . Aunque personalmente estoy a favor del esceuomorfismo en el diseño de interfaces electrónicas y no soy partidario de la moda de la última década de hacer que todo sea plano y de aspecto similar, no podemos reinyectar sensatamente un conjunto de elementos de diseño esceuomórficos y dejar el resto antiesceuomórfico. El diseño y la experiencia del usuario no funcionan así. PD: La parte del candado que en realidad lleva el nombre de grillete y que aparece en los nuevos iconos propuestos parece ridículamente delgada y débil, como los que aparecen en la supuesta seguridad de los candados para equipaje, así que incluso si WP volviera a optar por un diseño esceuomórfico (para todo), estos iconos en particular no deberían utilizarse. — SMcCandlish ☏ ¢ 😼 21:33, 15 de noviembre de 2024 (UTC) [ responder ]
Referencias
^ Robinson, Robert L. (1973). Curso completo de cerrajería profesional. Rowman & Littlefield. ISBN978-0-911012-15-6.
Cuando finalice la discusión , elimine esta etiqueta y se eliminará de la lista. Si esta página está en otras listas, se indicará a continuación.
¿Debería añadirse a Wikipedia un nuevo nivel de protección de cambios pendientes (cambios pendientes confirmados ampliados, abreviado en adelante como PCECP)? Awesome Aasim 19:58, 5 de noviembre de 2024 (UTC) [ responder ]
Fondo
WP:ARBECR (según mi entender) fomenta el uso liberal de la protección de EC en áreas temáticas autorizadas por la comunidad o el comité de arbitraje. Sin embargo, algunos administradores se niegan a proteger páginas a menos que haya una interrupción reciente. Los cambios pendientes confirmados extendidos permitirían a los usuarios que no sean de XCON proponer cambios para que sean aprobados por alguien confirmado extendido, y se pueden aplicar de manera preventiva a estas áreas temáticas.
Se supone que es técnicamente posible tener PCECP. Es decir, podemos tener PCECP como "[auto-accept=extended confirm users] [review=extended confirm users]". En este momento, es posible que no sea posible que los usuarios confirmados extendidos revisen los cambios pendientes con esta protección con la iteración actual de FlaggedRevs, pero tal vez en el futuro.
Encuesta (PCECP)
Soporte (PCECP)
Apoyo por múltiples razones: WP:ARBECR solo se aplica a temas polémicos. Corregir errores tipográficos no es un tema polémico. En segundo lugar, WP:ARBECR fomenta el uso de cambios pendientes cuando no se utiliza protección. En tercer lugar, los cambios pendientes sirven efectivamente para permitir solicitudes de edición no controvertidas sin necesidad de crear una nueva página de discusión. Y por último, esto está dentro de la línea de nuestra política de protección, que establece que la protección no debe aplicarse de forma preventiva en la mayoría de los casos. Awesome Aasim 19:58, 5 de noviembre de 2024 (UTC) [ responder ]
El soporte (¿por... nombre?) de la PC es la forma superior de solicitudes de edición no controvertidas. Aaron Liu ( discusión ) 20:09 5 nov 2024 (UTC) [ responder ]
Es mejor que EC, que ya limita más el hecho de ser una enciclopedia libre. Como dije más abajo, el editor visual permite mucha más edición por parte de gente nueva que la solicitud de edición, lo que obliga a la gente a usar el editor de código fuente. Aaron Liu ( discusión ) 03:52 6 nov 2024 (UTC) [ responder ]
Esto no es de ninguna manera más o menos restrictivo que el ECR. Es exactamente el mismo nivel de protección, solo que implementado de una manera diferente. No recibo los votos a favor de ninguno de los dos bandos que afirman que esto implicará más restricciones o más burocracia. No entiendo a ninguno de los dos y los insto a que expliquen sus razones. Aaron Liu ( discusión ) 12:32 12 nov 2024 (UTC) [ responder ]
Al crear una diferencia entre lo que ven los lectores no registrados (es decir, la gran mayoría de ellos) y lo que ven los usuarios registrados, existe una capa adicional de dificultad para los editores no confirmados y no confirmados automáticamente, que no verán la página real que están editando hasta que comiencen el proceso de edición. Los editores confirmados y confirmados automáticamente también pueden confundirse al saber que sus ediciones no están siendo vistas por lectores no registrados. Debido a que los cambios pendientes ya se enviaron al historial lineal del artículo, deshacer una edición rechazada es potencialmente más complicado que aplicar solicitudes de edición sucesivas realizadas en la página de discusión. (Esto no es un problema significativo cuando no hay muchos cambios pendientes en cola, lo que es parte de la razón por la que uno de los criterios recomendados para aplicar la protección de cambios pendientes es que la página se edite con poca frecuencia). Para bien o para mal, no hay una fecha límite para procesar las solicitudes de edición, lo que ayuda a mitigar los problemas con la fusión de múltiples solicitudes, pero existe la presión de lidiar con todos los cambios pendientes de manera expedita, para reducir las complicaciones en la edición. isaacl ( discusión ) 19:54 12 nov 2024 (UTC) [ responder ]
¿Crees que esto se solucionaría con "ramificaciones" (similares a las ramas de GitHub)? En otras palabras, en lugar de que PC dé la última edición, PC solo da la edición de la revisión estable y cuando se hace clic en "Publicar cambios", hace algo como poner la revisión en un espacio de nombres separado (algo así como Revisión:NOMBREDEPÁGINA/#######) donde ####### es el ID de la revisión. Si se acepta la edición, entonces esa página se fusiona y se elimina la revisión. Si se rechaza la edición, se elimina la revisión, pero siempre se puede restaurar mediante un revisor de cambios pendientes o un administrador. Awesome Aasim 21:01, 12 de noviembre de 2024 (UTC) [ responder ]
Técnicamente, eso llevaría bastante tiempo de implementación. Aaron Liu ( discusión ) 23:18 12 nov 2024 (UTC) [ responder ]
Hay muchos programadores que tienen problemas con las ramificaciones; no estoy seguro de que sea una gran idea convertirlas en una parte integral de la edición de Wikipedia, al menos no de una manera oculta e implícita. Si una edición de un artículo siempre procediera de la última versión revisada, los editores no podrían crear cambios sobre sus ediciones anteriores. Creo que, como mínimo, un editor debería poder hacer el equivalente a crear una rama de trabajo personal. Por ejemplo, esto se podría hacer trabajando en el cambio como una subpágina de la página del usuario (o posiblemente en otro lugar (¿quizás en el espacio de nombres Draft?), utilizando alguna jerarquía de nombres estándar) y luego enviando una solicitud de edición. Eso sería más parecido a cómo se diseñó Git para permitir la colaboración descentralizada: todos trabajan en su propio repositorio, reorganizando desde un repositorio central (*) y piden a un integrador que extraiga los cambios que publican en su repositorio público.
(*) Cualquier repositorio público puede actuar como repositorio central. Solo tiene que ser uno que todos los colaboradores acuerden utilizar y, por lo tanto, concuerden con las decisiones que toman los integradores al fusionar los cambios en ese repositorio. isaacl ( discusión ) 23:22 12 nov 2024 (UTC) [ responder ]
Eso tiene sentido. Esto me ha influido para modificar ligeramente mi respuesta a la segunda pregunta, pero sigo apoyando la existencia de esta protección y la protección preventiva de la PC para páginas con poco tráfico. (Además, sigue sin suponer una restricción mayor). Aaron Liu ( discusión ) 23:20 12 nov 2024 (UTC) [ responder ]
Soporte , una forma funcionalmente más eficiente de solicitudes de edición. El volumen de cambios pendientes aún es lo suficientemente bajo como para que se pueda abordar este tema, y podría alentar a que se otorgue el derecho de revisión de cambios pendientes a más personas que actualmente revisan solicitudes de edición, especialmente en temas polémicos. Chaotic Enby ( discusión · contribuciones ) 20:25, 5 de noviembre de 2024 (UTC) [ responder ]
Apoyo que esta opción sea válida. Valoro especialmente el efecto que tiene en la atribución (porque el cambio se atribuye directamente a la persona que lo quiso, no al editor que procesó la solicitud de edición). WhatamIdoing ( discusión ) 20:36 5 nov 2024 (UTC) [ responder ]
Soporte : sistema mejor y más directo que la protección extendida confirmada preventiva seguida de solicitudes de edición en la página de discusión. Cremastra ( u — c ) 20:42, 5 de noviembre de 2024 (UTC) [ responder ]
Soporte , Cambios pendientes tiene la capacidad de asumir esta nueva tarea. PC es mucho mejor que el sistema de solicitud de edición tanto para los nuevos editores como para los revisores. También elimina las desventajas de aplicar ECP a todo lo que se encuentre dentro de áreas temáticas polémicas. Toadspike [Discusión] 20:53, 5 de noviembre de 2024 (UTC) [ responder ]
He leído las opiniones que se encuentran a continuación y estoy completamente en desacuerdo con que esto conduzca a una mayor restricción de acceso. El sistema actual de solicitudes de edición es extremadamente complicado e inaccesible para los nuevos usuarios. Llevo aquí media década y todavía no sé realmente cómo funciona. Las solicitudes de edición que recibimos son una pequeña fracción de las ediciones que la gente quiere hacer en las páginas de ECP pero no puede. PCECP les permitiría hacer esas ediciones. Y muchas (¿la mayoría?) de las solicitudes de edición están formateadas de una manera que no se pueden aceptar (no está claro qué cambio se debe hacer, dónde, en base a qué fuente), un gran problema que se resolvería por completo con PCECP.
La protección automática de la CE de todas las páginas en ciertos CTOP no es el objetivo de esta propuesta . La existencia de PCECP no altera si la interrupción es un requisito previo para la protección y debe decidirse en otra convocatoria de propuestas en otro lugar o por ArbCom. PCECP trata únicamente de ampliar la accesibilidad a la edición de páginas ECP para editores nuevos y no registrados, lo que sin duda es una medida positiva.
Yo también odio el sistema de PC en dewiki, y agradezco que Kusma lo haya mencionado. Sin embargo, lo que estamos viendo aquí es reducir los niveles de protección y las barreras para la edición, que es lo opuesto a las barreras de PC de dewiki. Toadspike [Discusión] 10:24 16 nov 2024 (UTC) [ responder ]
Soporte ( invocado por bot ) : según lo indicado anteriormente. C F A 💬 23:34, 5 de noviembre de 2024 (UTC) [ responder ]
Soporte : según lo indicado anteriormente. La PC siempre tiene un nivel de trabajo atrasado bajo o muy bajo, por lo tanto, es completamente capaz de aceptar este cambio. ~/Bunny pranav :< ping > 11:26, 6 de noviembre de 2024 (UTC) [ responder ]
Soporte : Me encantaría que se implemente. Grab Up - Talk 15:14, 6 de noviembre de 2024 (UTC) [ responder ]
Apoyo Estoy de acuerdo con el principio de JPxG de que es mejor "tener drama en un proyecto vivo que paz en uno muerto", pero esto es mucho menos restrictivo que establecer de manera preventiva la protección de EC para todas las páginas WP:ARBECR . Desde la perspectiva de un nuevo editor, experimentan un retraso en la experiencia positiva de ver su edición implementada, pero mientras los revisores de cambios pendientes estén equipados para minimizar este retraso, entonces este descuido parece un beneficio neto. Los nuevos usuarios recibirán comentarios de editores experimentados sobre cómo operar en las áreas de contenido más difíciles de Wikipedia, en lugar de tropezar con ellas. ViridianPenguin 🐧 ( 💬 ) 08:57, 8 de noviembre de 2024 (UTC) [ responder ]
Soporte No sé cómo es en otras áreas, pero en la mía, de las solicitudes de edición que veo, hay muchas, tal vez incluso la mayoría de ellas son desde el punto de vista del usuario/no procesables/sin sentido/insultos, así que si ya es solo ECR, entonces sí, más filtros son algo bueno. Selfstudier ( discusión ) 18:17, 11 de noviembre de 2024 (UTC) [ responder ]
Apoyo suponiendo que esto sea técnicamente posible (de lo cual no estoy completamente seguro), parece una buena idea y definitivamente haría que los cambios pendientes sean más útiles desde mi punto de vista. Zippybonzo | discusión | contribuciones (ellos/ellas) 20:00, 12 de noviembre de 2024 (UTC) [ responder ]
Fuerte apoyo al razonamiento de @JPxG : creo que es una locura que estemos dispuestos a cerrar tantos artículos a tantos editores potenciales, e incluso una liberalización gradual de las restricciones de edición en estos artículos debería ser bienvenida. Este cambio ampliaría sustancialmente el número de editores potenciales al permitir que los contribuyentes no pertenecientes a la CE sugieran fácilmente ediciones a áreas temáticas controvertidas. Sería una gran victoria para las contribuciones si lográramos reemplazar la mayoría de los bloqueos de ECP con este nuevo PCECP. – Closed Limelike Curves ( discusión ) 02:07, 14 de noviembre de 2024 (UTC) [ responder ]
Sí , de hecho, alguien leyó mi mente aquí (estaba pensando en esto anoche, aunque no vi este hilo de VP...)) Mi verdadero namm ( 💬Hablemos · 📜Mi trabajo ) 21:38 14 nov 2024 (UTC) [ responder ]
Oponerse (PCECP)
Oponerse Hay mucha historia aquí, y me he opuesto a WP:FPPR /FlaggedRevs consistentemente desde ~2011. Sin reabrir las viejas heridas sobre cómo se implementó/terminó la prueba inicial, nada de lo que sucedió desde entonces ha cambiado mi posición. Creo que proceder con una expansión de FlaggedRevs sería un paso más lejos de nuestro compromiso de ser la enciclopedia libre que cualquiera puede editar sin resolver realmente ningún problema crítico que nuestras herramientas existentes no estén manejando ya. Si bien la propuesta incluye Sin embargo, algunos administradores se niegan a proteger páginas a menos que haya una interrupción reciente como un problema, lo veo como algo positivo. De hecho, ese es el punto principal; la protección debe ser preventiva y debe haber evidencia de una interrupción reciente. Si una página está experimentando una interrupción, la protección puede manejarla. Si no, no hay necesidad de limitar la capacidad de nadie para editar. The Wordsmith Háblame 03:45, 6 de noviembre de 2024 (UTC) [ responder ]
The Wordsmith , en relación con " Sin embargo, algunos administradores se niegan a proteger páginas a menos que haya una interrupción reciente como un problema, lo veo como algo positivo", por interés, lo veo como algo negativo por varias razones, al menos en el área temática de WP:PIA , principalmente porque es subjetivo/no determinista.
Las reglas de WP:ARBECR no dependen de evaluaciones subjetivas de la calidad de las ediciones. Los editores que no pertenecen a la CE solo pueden hacer solicitudes de edición. Eso es lo que les decimos.
Si es el caso que sólo a los editores no pertenecientes a EC se les permite realizar solicitudes de edición, no hay razón para dejar las páginas desprotegidas.
Si no es el caso de que sólo los editores no pertenecientes a EC puedan realizar solicitudes de edición, entonces no deberíamos decírselo a través de los encabezados de las páginas de discusión y los mensajes de notificación estándar.
Parece existir una cultura basada en una creencia optimista y basada en la fe según la cual la comunidad puede ver las violaciones de la ARBECR, emitir juicios subjetivos confiables basados en algún sistema de valores y abordarlas adecuadamente mediante la acción o la inacción. Esto es incompatible con mis observaciones.
Muchas violaciones disruptivas pasan desapercibidas cuando hay cientos de miles de revisiones realizadas por decenas de miles de actores.
El tamaño de la población de editores/administradores que intentan abordar las violaciones de ARBECR es muy pequeño, y su muestreo del espacio es inevitablemente un ejemplo del efecto farola .
El área temática de PIA está en gran parte desprotegida y hay miles de artículos, plantillas, categorías, páginas de discusión, etc. La aleatoriedad juega un papel importante en la aplicación de ARBECR por todo tipo de razones (y tal vez eso sea bueno hasta cierto punto, es difícil saberlo).
La falta de herramientas de Wikipedia para abordar de manera efectiva la evasión de prohibiciones en áreas temáticas polémicas significa que actualmente no es posible determinar si una revisión realizada por una cuenta no registrada en la CE o una IP que viola WP:ARBECR que se asemeja a una edición aceptable (para mí personalmente, con todos mis prejuicios y subjetividad poco confiable) es el producto de una persona útil o un reincidente que evade la prohibición/miembro de un grupo activista externo que explota una puerta trasera.
Me opongo firmemente a la idea de obtener otro nivel de protección con el único propósito de usarlo de manera preventiva, lo cual nunca ha sido aceptable y no debería serlo. Simplemente aléjense de este mundo... hoy 21:25, 6 de noviembre de 2024 (UTC) [ responder ]
Me opongo , odio los cambios pendientes. Usarlos de forma generalizada romperá la wiki. Necesitamos ser lo más acogedores posible con los nuevos editores, y la gratificación instantánea de la edición de la wiki debería estar presente en tantas páginas como sea posible. — Kusma ( discusión ) 21:47 6 nov 2024 (UTC) [ responder ]
@ Kusma ¿Podrías explicar con más detalle que "su uso generalizado romperá la wiki", especialmente porque actualmente tenemos la protección de la CE más estricta y menos amigable? Aaron Liu ( discusión ) 22:28, 6 de noviembre de 2024 (UTC) [ responder ]
El Anexo A es el retraso de 53 días en los cambios pendientes de dewiki. — Kusma ( discusión ) 23:03, 6 de noviembre de 2024 (UTC) [ responder ]
Ya tenemos un backlog similar y más grande en CAT:EEP . Todo lo que esto hace es mover el backlog a una interfaz manejada por software de servidor que permite a los recién llegados usar VE para sus "solicitudes de edición", donde actualmente deben usar el editor de código fuente debido a que están confinados a las páginas de discusión. Aaron Liu ( discusión ) 23:06, 6 de noviembre de 2024 (UTC) [ responder ]
El backlog de dewiki supera las 18.000 páginas. CAT:EEP tiene 54. La falla de sistemas opcionales como VE no debería ser un factor en la forma en que hacemos políticas. — Kusma ( discusión ) 09:40 7 nov 2024 (UTC) [ responder ]
El retraso no será mayor que el de EEP. (Además, quise decir que la solicitud principal de EEP fue hace más de 3 meses, lo siento). Aaron Liu ( discusión ) 12:23 7 nov 2024 (UTC) [ responder ]
... si no aumenta el número de páginas protegidas . Espero que la propuesta aumente, incluso si no se aprueba la aterradora propuesta de proteger de forma preventiva grandes clases de artículos. — Kusma ( discusión ) 13:08 7 nov 2024 (UTC) [ responder ]
La mayoría de las páginas PCECP deberían ser páginas ECP (¿reducidas?) ya que tienen menos tráfico/interrupciones. Por lo tanto, la cantidad de páginas que aumentarán no debería ser tan grande. ~/Bunny pranav :< ping > 13:35, 7 de noviembre de 2024 (UTC) [ responder ]
@ Kusma ¿No es la pérdida de la gratificación instantánea de editar mejor que crear una solicitud en la página de discusión de una página ECP y no tener idea de cuándo será revisada e implementada? ~/Bunny pranav :< ping > 11:25, 7 de noviembre de 2024 (UTC) [ responder ]
Con una PC tampoco sabes cuándo o si tu edición se implementará. — Kusma ( discusión ) 13:03 7 nov 2024 (UTC) [ responder ]
Oponerse : parece innecesario y solo evitará que otros editores de buena fe editen, sin mencionar el esfuerzo de la comunidad que se requiere para monitorear y revisar las solicitudes de cambios pendientes, dado que algunas áreas como ARBIPA se aplican a cientos de miles de páginas. Ratnahastin ( discusión ) 01:42, 7 de noviembre de 2024 (UTC) [ responder ]
@Ratnahastin De manera similar a mi pregunta anterior, ¿esto no alentará a más editores de buena fe en comparación con un bloqueo literal de la edición de una página ECP? ~ / Bunny pranav :< ping > 11:32, 7 de noviembre de 2024 (UTC) [ responder ]
Hay una muy buena razón por la que hago referencia a Recursos comunitarios contra matones callejeros en mi nombre preferido para el esquema de protección, y la respuesta es generalmente no, ya que el área temática de la que estamos hablando principalmente es un tema polémico etnopolítico, que tiende a atraer a partidarios interesados solo en "ganar la guerra" en Wikipedia. Esto no se limita solo a los nuevos usuarios que ingresan, sino también a editores establecidos que tienen opiniones firmes sobre el tema y que pueden estar en la posición de revisar estas ediciones, como lo dejaría claro una lectura rápida de cualquier caso de arbitraje centrado en Europa del Este o Palestina-Israel. — Jéské Couriano v^_^v hilos críticas 18:21, 7 de noviembre de 2024 (UTC) [ responder ]
¿No son estos problemas los que también se pueden ver en la misma medida en las solicitudes de edición, si es que existen? Aaron Liu ( discusión ) 19:10 7 nov 2024 (UTC) [ responder ]
Las ediciones claramente disruptivas y frívolas son vandalismo, énfasis en "claramente". Aaron Liu ( discusión ) 16:28 8 nov 2024 (UTC) [ responder ]
La promoción del punto de vista no es vandalismo a primera vista . — Jéské Couriano v^_^v hilos críticas 16:32, 8 de noviembre de 2024 (UTC) [ responder ]
La imposición de puntos de vista no es evidentemente disruptiva o frívola y no se puede eliminar en las solicitudes de edición. Aaron Liu ( discusión ) 16:45 10 nov 2024 (UTC) [ responder ]
Pero las solicitudes de edición hacen que sea más difícil llevar ese punto de vista a un artículo publicado. — Jéské Couriano v^_^v hilos críticas 17:22, 11 de noviembre de 2024 (UTC) [ responder ]
Lo mismo con los cambios pendientes. Aaron Liu ( discusión ) 17:36 11 nov 2024 (UTC) [ responder ]
Tal vez en algún país de fantasía donde la edición no necesitara estar vinculada a la historia del artículo. — Jéské Couriano v^_^v hilos críticas 18:08, 11 de noviembre de 2024 (UTC) [ responder ]
Excepto que así es como funcionan las solicitudes de incorporación de cambios en GitHub. Tú haces la edición y alguien con permisos de revisor la aprueba para completar la fusión. Aquí, se produce la "confirmación", pero la revisión no es visible hasta que se revisa y se aprueba. Las solicitudes de edición no son solicitudes de incorporación de cambios, son el equivalente a los "problemas" en GitHub. Awesome Aasim 19:03, 11 de noviembre de 2024 (UTC) [ responder ]
Puede resultar sorprendente, pero Wikipedia no es GitHub. Si bien ambos son proyectos colaborativos, son muy diferentes en la mayoría de los demás aspectos. Thryduulf ( discusión ) 19:20 11 nov 2024 (UTC) [ responder ]
Con Git, los remitentes realizan un cambio en su propia rama (que incluso puede estar en su propio repositorio) y luego solicitan que un integrador extraiga ese cambio en la rama principal. De esta manera, el historial de la rama principal permanece limpio: solo tiene los cambios que se fusionaron. (Es uno de los principios rectores de Git: permitir que el árbol del historial de cualquier rama se simplifique para mejorar la claridad y el rendimiento). isaacl ( discusión ) 22:18, 11 de noviembre de 2024 (UTC) [ responder ]
Se supone que las solicitudes de edición son solicitudes de extracción.
Indique claramente qué secciones o frases deben reemplazarse o agregarse, y con qué deben reemplazarse o agregarse. — WP:ChangeXY
Sí, eso es lo que se supone que deben ser, pero en la práctica no lo son. Como cualquiera que haya respondido a solicitudes de edición antes, a menudo hay mensajes que se parecen a esto:
This template must be followed by a complete and specific description of the request, that is, specify what text should be removed and a verbatim copy of the text that should replace it. "Please change X" is not acceptable and will be rejected; the request must be of the form "please change X to Y".
The edit may be made by any extended confirmed user. Remember to change the |answered=no parameter to "yes" when the request has been accepted, rejected or on hold awaiting user input. This is so that inactive or completed requests don't needlessly fill up the edit requests category. You may also wish to use the {{EEp}} template in the response. To request that a page be protected or unprotected, make a protection request.
La referencia es incorrecta. Por favor, arréglenla. 192.0.0.1 (discusión) 23:19 11 nov 2024 (UTC) [ responder ]
No veo que eso sea un gran problema, especialmente porque las ediciones también se guardan en el historial de la página de discusión. Aaron Liu ( discusión ) 22:50, 11 de noviembre de 2024 (UTC) [ responder ]
¿Significan algo las palabras "Provocar guerras de edición"? Es mucho menos probable que las publicaciones en las páginas de discusión sean el foco de una guerra de edición que las ediciones de artículos. — Jéské Couriano v^_^v hilos críticas 18:05, 14 de noviembre de 2024 (UTC) [ responder ]
Como editor que empezó procesando solicitudes de edición, incluidas las solicitudes de edición de ECP, no estoy de acuerdo. Aaron Liu ( discusión ) 18:08 14 nov 2024 (UTC) [ responder ]
Me opongo , según lo que ha dicho JSS . Me siento un poco incómodo por el grado en que aparentemente hemos aceptado la protección preventiva de artículos en áreas polémicas. Puede ser una forma conveniente de reducir el drama con el que tenemos que lidiar los administradores y los usuarios avanzados... pero solo a costa de renunciar al principio básico de que cualquiera puede editar. Prefiero tener drama en un proyecto vivo que paz en uno muerto. jp × g 🗯️ 18:16, 7 de noviembre de 2024 (UTC) [ responder ]
Oponerme Soy uno de esos administradores a los que les gusta ver disrupción antes que proteger. Lectonar ( discusión ) 08:48 8 nov 2024 (UTC) [ responder ]
Oponerse por innecesario parece una solución en busca de un problema. Además, esto *es* Wikipedia, la enciclopedia que cualquiera puede editar; la protección preventiva de las páginas desalienta las contribuciones de nuevos editores. - Fastily 22:36, 8 de noviembre de 2024 (UTC) [ responder ]
Débil En contra Entiendo que esta protección sería útil, pero creo que algo puede o no protegerse con la CE. No creo necesariamente que agregar otro nivel de burocracia sea particularmente útil. -- Takipoint123 ( discusión ) 05:14 11 nov 2024 (UTC) [ responder ]
Oponerme . Me inclino a estar de acuerdo en que los escenarios en los que esta herramienta podría resultar beneficiosa como solución técnica serían excesivamente específicos, y que ese escaso beneficio probablemente se vería compensado por el impacto de tener una herramienta más para seguir mordisqueando los bordes de los espacios abiertos del proyecto que están disponibles para los nuevos editores. Francamente, en los últimos años ya hemos tenido una tendencia absurdamente agresiva hacia las decisiones de la comunidad (y de ArbCom) que han aislado cada vez más cualquier cosa remotamente en vano de controversia de los nuevos editores, con consecuencias predecibles para el reclutamiento y la retención de editores más allá del período de participación temprana, lo que exacerba aún más nuestras cargas de trabajo y otros problemas sistémicos. Honestamente, necesitamos revertir algunos de estos cambios, no agregar una capa más (por delgada y contextual que sea) al tejido burocrático/carrera de obstáculos para los nuevos usuarios. S n o w Rise vamos a rapear 11:23, 12 de noviembre de 2024 (UTC) [ responder ]
Oposición . Cuanto más leo esta discusión, más me parece que esto no resolvería la mayoría de lo que se propone resolver, sino que crearía más problemas al hacerlo, lo que lo convertiría en un aspecto negativo para el proyecto. Thryduulf ( discusión ) 21:43 12 nov 2024 (UTC) [ responder ]
Oposición y punto de orden Oposición porque los cambios pendientes ya son demasiado complicados y no muy útiles. Soy un revisor de cambios pendientes y nunca he rechazado uno por razones políticamente correctas (básicamente vandalismo). Pero a menudo vuelvo a hacerlo por razones normales de editor después de aceptar por razones políticamente correctas. (Sospecho que muchos rechazos políticamente correctos se hacen por razones no políticamente correctas en lugar de hacer esto) "Punto de orden" se debe a que la RFC no es clara sobre qué es exactamente lo que se rechaza. Atentamente, North8000 ( discusión ) 22:15, 12 de noviembre de 2024 (UTC) [ responder ]
Estoy bastante seguro de que lo que sucede es que cuando los vándalos se dan cuenta de que tendrán que enviar su edición para su revisión antes de que se publique, eso les quita toda la diversión porque, obviamente, será rechazada y no se molestan. Así es como se suponía que debía funcionar. Simplemente aléjate de este mundo... hoy 22:22, 12 de noviembre de 2024 (UTC) [ responder ]
Este es un muy buen punto y solicito la aclaración de @ Awesome Aasim sobre si los revisores podrán rechazar ediciones por motivos de reversiones normales combinadas con la restricción de EC. Creo que hay suficiente fundamento para aplicar esto aquí más allá del fundamento inicial para PC como lo explicó JSS anteriormente. Aaron Liu ( discusión ) 23:24, 12 de noviembre de 2024 (UTC) [ responder ]
A los revisores se les dan razones específicas para aceptar ediciones (ver Wikipedia:Cambios pendientes § Revisión de ediciones pendientes ) para evitar sobrecargarlos con trabajo mientras se procesan los cambios pendientes de manera expedita. Si las razones se abren a una mayor evaluación de la calidad de las ediciones, entonces las expectativas pueden cambiar y hacer que esto sea una norma. Por lo tanto, a algunos usuarios les preocupa que esto cree una jerarquía de editores, donde las ediciones de los no revisores estén controladas por los revisores. isaacl ( discusión ) 23:44, 12 de noviembre de 2024 (UTC) [ responder ]
Entiendo eso y me pregunto cómo propone el revisor abordar esto. Aún así, apoyaría esta propuesta si la norma fuera que los revisores rechazaran según si revertirían y "aparentemente" aplicaran la EC, aunque en menor medida por las razones que mencionaste (aunque reemplazaría "no revisores" por "todos los que no son aceptados automáticamente"). Aaron Liu ( discusión ) 00:13 13 nov 2024 (UTC) [ responder ]
No estoy seguro a quién te refieres cuando dices "el revisor"; eres tú quien sugiere que hay una razón para respaldar más razones para rechazar un cambio pendiente más allá del conjunto actual. Dado que cualquier cambio pendiente en la cola evitará que los cambios posteriores realizados por personas que no son revisores sean visibles para la mayoría de los lectores, sus ediciones también serán evaluadas por un solo revisor antes de ser visibles para todos. isaacl ( discusión ) 00:59, 13 de noviembre de 2024 (UTC) [ responder ]
Perdón, me refería a Aasim, el nominador. Me lo he planteado. Actualmente, los revisores pueden deshacer solo las ediciones que no son buenas y luego aprobar la revisión de su propia versión. Pensé que eso era lo que se suponía que debíamos hacer. Aaron Liu ( discusión ) 02:13 13 nov 2024 (UTC) [ responder ]
Sí. Todo lo que sea vandalismo evidente o una violación de las políticas existentes de Wikipedia puede ser rechazado. Sin embargo, en el caso de ediciones en las que no exista otro problema, la edición puede ser aceptada. En otras palabras, que un usuario no esté confirmado no será motivo suficiente para rechazar una edición según el PCECP, ya que el usuario confirmado asume la responsabilidad de la edición. Si el usuario confirmado acepta una mala edición, la responsabilidad recae sobre él, no sobre quien la haya realizado. Esa es la idea.
Por supuesto, los cambios obviamente útiles, como corregir errores tipográficos y agregar información actualizada, deberían aceptarse antes, mientras que los cambios más controvertidos deberían discutirse primero. Awesome Aasim 17:37, 13 de noviembre de 2024 (UTC) [ responder ]
Cuando dices que se trata de una violación de las políticas existentes de Wikipedia , ¿te refieres únicamente a violaciones de BLP, copyvio y "otro contenido obviamente inapropiado" que se puede comprobar muy rápidamente, que es el alcance actual de lo que se debe rechazar ? Aaron Liu ( discusión ) 17:41 13 nov 2024 (UTC) [ responder ]
Sí, pero también las ediciones realizadas en violación de un consenso ya bien establecido. Las ediciones que imponen un consenso claramente establecido (probado por una discusión previa en la página de discusión) están, según tengo entendido, exentas de todas las restricciones de WP:EW . Awesome Aasim 18:38, 13 de noviembre de 2024 (UTC) [ responder ]
Thryduulf y SnowRose se oponen . Además, independientemente de si esta es una buena idea como política, FlaggedRevs tiene una gran cantidad de deuda técnica, hasta el punto de que está prohibida su implementación en cualquier wiki adicional de WMF, por lo que no parece prudente ampliar su uso. nuevodiscusión edita 19:05 13 nov 2024 (UTC) [ responder ]
Oponerme Nunca me ha resultado fácil navegar por el sistema de cambios pendientes actual como revisor. ~~ AirshipJungleman29 ( discusión ) 20:50 14 nov 2024 (UTC) [ responder ]
Neutral (PCECP)
He dejado dolorosamente clara mi oposición a todas las formas de FlaggedRevisions desde 2011. Sin embargo, no me opondré formalmente a esto para evitar que el proceso se descarrile si hay personas que refutan mi oposición. — Jéské Couriano v^_^v hilos críticas 02:36, 6 de noviembre de 2024 (UTC) [ responder ]
No soy partidario de los cambios pendientes actuales, por lo que no podría apoyar esto. Pero tampoco afectaría mi edición, por lo que no me opondré si ayuda a otros.-- LCU A ctively D isinterested « @ » ° ∆t ° 14:32, 6 de noviembre de 2024 (UTC) [ responder ]
Discusión (PCECP)
Alguien que sea experto en la configuración de mw:Extension:FlaggedRevs deberá confirmar que es posible tener simultáneamente nuestro tipo actual de protección contra cambios pendientes más este nuevo tipo de protección contra cambios pendientes. La configuración actual de FlaggedRevs enwiki se parece a la siguiente y puede que no sea fácil de configurar. Es posible que desees contactar a Ladsgroup o publicar en WP:VPT para obtener ayuda.
Básicamente vine aquí para preguntar si esto es posible o si necesitaría la participación de los desarrolladores de WMMF o lo que sea.
Para aquellos que no lo saben, los cambios pendientes no son lo mismo que las revisiones marcadas que se usan en de.wp. PC fue desarrollado por la fundación específicamente para este proyecto después de que lo solicitamos. También solíamos tener WP:PC2, pero nadie sabía realmente qué se suponía que era eso ni cómo usarlo, y se discontinuó. Solo aléjate de este mundo... hoy 21:21, 6 de noviembre de 2024 (UTC) [ responder ]
¿Es PC2 una indicación de que la implementación es posible? Aaron Liu ( discusión ) 22:27 6 nov 2024 (UTC) [ responder ]
Depende de qué se entienda exactamente por "implementación". Una configuración en la que las ediciones de usuarios no confirmados por extensión necesiten ser revisadas por revisores probablemente sería similar a lo que se eliminó en gerrit:/r/334511 para implementar T156448 (eliminación de PC2). No sé si es posible o no una configuración en la que las ediciones de usuarios no confirmados por extensión puedan ser revisadas por cualquier usuario confirmado por extensión mientras que las PC normales solo puedan ser revisadas por revisores. Anomie ⚔ 13:32, 7 de noviembre de 2024 (UTC) [ responder ]
Si nos fijamos en la documentación de MediaWiki, no es posible en este momento. Dicho esto, actualmente la propuesta supone que es posible y deberíamos trabajar con eso (aunque también apoyaría que se permitiera a todos los que hayan confirmado la extensión revisar todos los cambios pendientes). Aaron Liu ( discusión ) 13:56 7 nov 2024 (UTC) [ responder ]
Creo que la declaración resumida de la RfC está un poco incompleta. Entiendo que la función de cambios pendientes introduce un conjunto de derechos que se pueden asignar a los grupos de usuarios correspondientes. Creo que toda la lógica se basa en los derechos de usuario, por lo que no hay forma de designar que un artículo pueda ser revisado automáticamente por un grupo de usuarios mientras que otro artículo puede ser revisado automáticamente por un grupo de usuarios diferente. Por lo tanto, a menos que la propuesta sea reemplazar los cambios pendientes autoconfirmados con cambios pendientes confirmados extendidos, no creo que decir "habilitado" en el resumen sea una descripción adecuada. Y si la propuesta es reemplazar los cambios pendientes autoconfirmados, creo que eso debería indicarse explícitamente. isaacl ( discusión ) 22:06, 6 de noviembre de 2024 (UTC) [ responder ]
La propuesta supone que la coexistencia es técnicamente posible. Aaron Liu ( discusión ) 22:28 6 nov 2024 (UTC) [ responder ]
La propuesta no especificó si se suponía que la coexistencia era posible o que era posible habilitarla, lo que podría significar un reemplazo. Por lo tanto, considero que la declaración resumida (antes de la marca de tiempo, que es lo que aparece en la lista central de RfC) está incompleta. isaacl ( discusión ) 22:31, 6 de noviembre de 2024 (UTC) [ responder ]
Al volver a leerlo, se supone que es técnicamente posible que el PCECP no implique explícitamente la coexistencia, así es como lo interpreté. De todos modos, sería maravilloso escuchar a @ Awesome Aasim sobre esto. Aaron Liu ( discusión ) 22:42, 6 de noviembre de 2024 (UTC) [ responder ]
La cuestión clave que debe aclararse es si la propuesta es tener ambas, o reemplazar la actual por una nueva versión. (Eso se relaciona con la cuestión de si es necesaria o no la participación del comité de arbitraje). Además, sería más preciso no utilizar una palabra en el resumen que implique que el único costo es encender un interruptor. isaacl ( discusión ) 22:49, 6 de noviembre de 2024 (UTC) [ responder ]
Se supone que podemos tener PC1, donde solo los revisores pueden aprobar ediciones, y PCECP, donde solo los usuarios confirmados extendidos pueden aprobar ediciones Y hacer ediciones sin requerir aprobación. Con la iteración actual, no sé si es técnicamente posible. Si requiere una reescritura o reemplazo de la extensión, está bien. Si algo aún no está claro, háganmelo saber. Awesome Aasim 23:06, 6 de noviembre de 2024 (UTC) [ responder ]
Sugiero cambiar la declaración de resumen por algo como "¿Debería añadirse a Wikipedia un nuevo nivel de protección de cambios pendientes: cambios pendientes confirmados ampliados (abreviado en adelante como PCECP)?". El párrafo siguiente puede proporcionar una explicación más detallada sobre quiénes serían autorrevisados y quiénes actuarían como revisores con el nuevo nivel propuesto. isaacl ( discusión ) 23:19 6 nov 2024 (UTC) [ responder ]
Está bien, ya está. He modificado un poco la redacción. Genial . Aasim 23:40, 6 de noviembre de 2024 (UTC) [ responder ]
Creo que la inclusión de la parte de protección preventiva en la declaración de antecedentes está generando confusión. Por lo que sé, la protección preventiva y si deberíamos usar PCECP en lugar de ECP son cuestiones separadas. Aaron Liu ( discusión ) 19:11 7 nov 2024 (UTC) [ responder ]
P2: Si se aprueba esta propuesta, ¿se debe aplicar el PCECP de manera preventiva aWP:ARBECR¿Temas?
Particularmente en artículos con poco tráfico, así como en todas las páginas de discusión. WP:ECP seguiría siendo una opción para aplicar además de PCECP. Genial Aasim 19:58, 5 de noviembre de 2024 (UTC) [ responder ]
Apoyo (PCECP preventivo)
Apoyo a mis razones en el primer trimestre. ¡Genial! Aasim 19:58, 5 de noviembre de 2024 (UTC) [ responder ]
Además, es necesario que exista alguna medida de cumplimiento para WP:ARBECR . No tener medidas técnicas de cumplimiento para WP:ARBECR es como prohibirle el acceso a un editor y luego negarse a bloquearlo porque "los bloqueos deberían ser preventivos". Awesome Aasim 19:42, 13 de noviembre de 2024 (UTC) [ responder ]
Bloquear a un usuario baneado del sitio es preventivo, porque si no tuviéramos que impedirle editar, no se le habría baneado del sitio. Thryduulf ( discusión ) 21:16 13 nov 2024 (UTC) [ responder ]
Tengo algunas dudas sobre la protección de las páginas de discusión, pero supongo que esto daría protagonismo a las páginas con poco tráfico. Aaron Liu ( discusión ) 20:13 5 nov 2024 (UTC) [ responder ]
Por isaacl, solo apoyo la protección preventiva en páginas con poco tráfico. Aaron Liu ( discusión ) 23:21 12 nov 2024 (UTC) [ responder ]
Soporte , incluso en las páginas de discusión. Dado que las solicitudes de edición se gestionan principalmente a través de cambios pendientes, proteger también las páginas de discusión debería limitar las interrupciones y los comentarios no constructivos que suelen ser habituales allí. (Cambiando de opinión, no creo que aplicar PCECP en todas las páginas sea una solución constructiva. Las reglas de ARBECR limitan la participación a los editores confirmados de forma extendida, pero el espíritu de las reglas ha sido aplicar eso solo en páginas con interrupciones reales, no de forma preventiva. 20:49, 7 de noviembre de 2024 (UTC)) Chaotic Enby ( discusión · contribuciones ) 20:21, 5 de noviembre de 2024 (UTC) [ responder ]
Apoyo Voy a estar en total desacuerdo con el argumento del "no" - deberíamos estar aplicando ECP de manera preventiva (incluso sin cambios pendientes). Es una perversión de la lógica decir "no puedes (según la política) presionar este botón", y luego negarnos a impedir técnicamente que presiones el botón a pesar de que sabemos que puedes hacerlo. * Pppery * ha comenzado... 20:52, 5 de noviembre de 2024 (UTC) [ responder ]
Soporte ( invocado por un bot ) : si bien no estoy de acuerdo con el ECR en general, esta es una mejor manera de aplicarlo mientras exista. Se pueden aceptar "solicitudes de edición" constructivas y las ediciones con las que la gente no está de acuerdo se pueden revertir fácilmente. Me preocupa un poco cómo esto podría afectar la lista de cambios pendientes (que tiene una cantidad bastante pequeña de revisores activos en este momento), pero estoy seguro de que se puede resolver. C F A 💬 23:41, 5 de noviembre de 2024 (UTC) [ responder ]
Oponerse (PCECP preventivo)
No, no creo que sea necesario en este momento. Creo que debería poder usarse allí, pero no creo que sea un paso necesario en este momento. Podríamos volver a analizarlo más adelante. WhatamIdoing ( discusión ) 20:37 5 nov 2024 (UTC) [ responder ]
No, todavía no deberíamos estar protegiendo de manera preventiva. Esperemos hasta que haya una interrupción y luego elijamos entre la protección PCXC o la protección XC normal (yo estaría totalmente a favor de la primera por las razones que expliqué anteriormente). Cremastra ( u — c ) 20:43, 5 de noviembre de 2024 (UTC) [ responder ]
Mu - Esta es una pregunta que debería hacerse después , no al mismo tiempo , ya que ArbCom querrá analizar cualquier propuesta de este tipo. — Jéské Couriano v^_^v hilos críticas 02:38, 6 de noviembre de 2024 (UTC) [ responder ]
No, creo que sería una mala idea. Los críticos de Wikipedia ya utilizan la idea de que está controlada por un grupo selecto, esto solo haría que esa idea errónea fuera más común. -- LCU A ctively D isinterested « @ » ° ∆t ° 14:36, 6 de noviembre de 2024 (UTC) [ responder ]
En absoluto. No es necesario protegerse si no hay interrupciones. La cantidad de páginas protegidas debe mantenerse baja y la cantidad de páginas que gritan "¡mírenme!" en su lista de seguimiento (cualquier página que esté bajo cambios pendientes) debe ser lo más cercana posible a cero. — Kusma ( discusión ) 21:44 6 nov 2024 (UTC) [ responder ]
No hay necesidad de protección si no hay interrupción. El problema es que la restricción ECR se promulga en respuesta a una interrupción generalizada, esta vez a toda el área temática en su conjunto. El desprecio por el punto de vista, la inclusión flagrante de información no verificable o falsa (no confiable) y más, plantean serias amenazas de interrupción para el proyecto. Si WP:ARBECR se aplicara ampliamente sin ninguna protección, estaría de acuerdo, pero WP:ARBECR se aplica en respuesta a la interrupción (o una amenaza grave de ella), no de manera preventiva. Tomemos este como ejemplo, que es una discusión larga y prolija de ANI que terminó en WP:GS para la guerra ruso-ucraniana (y las restricciones ECR). Y en cuanto al Comité de Arbitraje, ArbCom es un último recurso cuando todos los demás intentos de resolver la interrupción fallan. Véase WP:ARBPIA WP:ARBPIA2 WP:ARBPIA3 WP:ARBPIA4 . La primera referencia al precursor de ARBECR en este caso está en el tercer caso ArbCom. No proteger un área temática que presenta un alto riesgo de interrupción es similar a tener una plantilla de alto riesgo sin protección. La única diferencia es que editar descuidadamente una plantilla de alto riesgo crea problemas técnicos, mientras que editar descuidadamente un área temática de alto riesgo crea problemas de contenido.
O bien la página está protegida técnicamente (lo que hace cumplir una decisión de la comunidad o de ArbCom de que sólo editores específicos pueden acceder a áreas temáticas) o bien la página no está protegida técnicamente pero sí socialmente (lo que entonces da una oportunidad de evasión). Considero que esta situación no es diferente a prohibir a un editor en todo el sitio y luego negarse a bloquearlo con el argumento de que "los bloqueos sólo deben usarse para evitar interrupciones" mientras se ignoran las circunstancias que llevaron a la prohibición del sitio.
Lo que haría el PCECP es permitir una mejor aplicación del aspecto comunitario. Los nuevos editores no se verían perjudicados, si encuentran algo que necesite ser corregido, como un error tipográfico, pueden hacer una edición y se aprobará. Las ediciones más controvertidas se relegarán a la página de discusión, donde los editores que no hayan sido prohibidos en esa área temática podrán discutir ese tema. Y las propuestas descaradamente explícitas y demás se revertirían y los lectores nunca las verían.
El flujo de trabajo se vería así: un usuario nuevo/anónimo hace una edición → la edición se retiene para revisión → el usuario confirmado extendido aprueba la edición. En lugar del flujo de trabajo actual (y la razón por la que el ECP preventivo es impopular): un usuario nuevo/anónimo hace una edición → el usuario es recibido con un mensaje de "esta página está protegida" → el usuario describe lo que le gustaría que se cambie pero de una manera mal formulada → la solicitud de edición se cierra como "poco clara" o algo similar. Awesome Aasim 14:21, 11 de noviembre de 2024 (UTC) [ responder ]
Según mi voto anterior. Ratnahastin ( discusión ) 09:00, 7 de noviembre de 2024 (UTC) [ responder ]
En absoluto. La protección debería ser siempre preventiva. Kusma lo explica mejor que yo. Thryduulf ( discusión ) 13:49 7 nov 2024 (UTC) [ responder ]
Según mi comentario anterior. jp × g 🗯️ 18:17, 7 de noviembre de 2024 (UTC) [ responder ]
No, véase mi comentario anterior. Prefiero ver disrupción antes que proteger. Lectonar ( discusión ) 08:51 8 nov 2024 (UTC) [ responder ]
No. Deberíamos ser más rápidos en aplicar la protección en estos temas que en otros, pero no de manera preventiva, excepto en páginas muy visibles (que, en estos temas, probablemente estén protegidas por ECP de todos modos). Amante de los animales |666| 17:18, 11 de noviembre de 2024 (UTC) [ responder ]
@ Jéské Couriano ¿Podrías incluir un enlace a la discusión de ArbCom? Aaron Liu ( discusión ) 03:51 6 nov 2024 (UTC) [ responder ]
No digo que exista tal discusión, pero los cambios en los recursos de arbitraje/sanciones discrecionales son algo en lo que querrían intervenir. La política de arbitraje (que incluye los temas de WP:Contentious ) es de su competencia y esto tendría serias implicaciones para WP:CT/AI y cualquier otra instancia en la que ArbCom (en lugar de editores individuales, como sanción discrecional) tendría que recurrir a una regla 500/30 como un remedio explícito. — Jéské Couriano v^_^v hilos críticas 04:58, 6 de noviembre de 2024 (UTC) [ responder ]
Esa no es mi interpretación de WP:ARBECR . Específicamente, en cualquier página donde la restricción no se aplique a través de una protección confirmada extendida, esta restricción puede aplicarse mediante... el uso de cambios pendientes ... (negrita agregada por mí para enfatizar). Pero si hay consenso para no usar esto de manera preventiva, que así sea. Awesome Aasim 05:13, 6 de noviembre de 2024 (UTC) [ responder ]
Aunque aprecio la visión de futuro de que el PCECP pueda querer ser utilizado en áreas de arbitraje, esto parece una confusión considerable en la demarcación entre el papel del Comité y el papel de la comunidad. Tradicionalmente, los temas contenciosos han sido el ámbito del ArbCom, y las sanciones generales han sido el ámbito de la comunidad. Parte de la lógica se reduce a quién asume la culpa cuando las cosas van mal. La comunidad no debería asumir la culpa cuando el ArbCom toma una decisión, y viceversa. Parte de la lógica es la separación de poderes. Si la comunidad quiere decir "ArbCom, harás cumplir esto, que Dios te ayude", entonces eso debería hacerse modificando ArbPol . Parte de la lógica es práctica. Si la comunidad crea un proceso que se suma a un proceso de arbitraje existente, ¿qué sucede cuando los Arbs quieren cambiar ese proceso? ¿O incluso terminarlo por completo? En resumen: adoptar el PCECP para ARBECR es ciertamente algo que el ArbCom podría hacer. Pero me gustaría pedirle a la comunidad que considere los problemas estructurales más amplios que surgirían si la comunidad lo adoptara en nombre de ArbCom. CaptainEek Edits ¡Ho Cap'n! ⚓ 05:18, 7 de noviembre de 2024 (UTC) [ responder ]
Interesante. Yo diría que ArbCom debería poder anular a la comunidad si realmente considera que esa acción es adecuada y merece una posible reacción negativa. Aaron Liu ( discusión ) 12:30, 7 de noviembre de 2024 (UTC) [ responder ]
Solo una nota sobre la terminología: aunque aprecio que muchos piensen en las sanciones generales de esa manera, se define en la página Wikipedia:Sanciones generales como ... un tipo de sanciones de Wikipedia que se aplican a todos los editores que trabajan en un área temática en particular. ... Las sanciones generales son medidas utilizadas por la comunidad o el Comité de Arbitraje ("ArbCom") para mejorar la atmósfera de edición de un artículo o área temática. . Por lo tanto, el marco de temas polémicos es una forma de sanciones generales. isaacl ( discusión ) 15:22, 7 de noviembre de 2024 (UTC) [ responder ]
En cuanto al punto general: estoy de acuerdo en que es complicado para la comunidad imponer una sanción general que se añada a una solución de arbitraje específica. Preferiría que la comunidad trabajara con el comité de arbitraje para modificar su solución, lo que facilitaría mantener la descripción de la sanción y el registro de su aplicación juntos, en lugar de separados. (Aprecio que para esta propuesta específica, el registro de su aplicación no sea un problema). isaacl ( discusión ) 15:30, 7 de noviembre de 2024 (UTC) [ responder ]
La confirmación extendida comenzó como un concepto de arbcom (500 ediciones/30 días) que la comunidad decidió adoptar. ArbCom decidió entonces que su solución coincidiera con la versión de la comunidad, de modo que si la comunidad decidiera que la confirmación extendida fuera de 1000 ediciones/90 días, todas las restricciones de ArbCom se actualizarían. Considero que este es un ciclo de retroalimentación saludable entre ArbCom y la comunidad. La comunidad podría elegir claramente (al menos a nivel de política, dadas algunas preocupaciones técnicas) implementar PCECP. Podría elegir aplicar esto a algunas/todas las páginas. Si se siente cómoda diciendo que quiere delegar algunas de las páginas a las que se aplica esto al Comité de Arbitraje, creo que puede hacerlo sin modificar ArbPol. Sin embargo, creo que ArbCom podría decidir que PCECP no se aplicaría en algunas/todas las áreas de CTOP dado que el Comité está exento del consenso para las áreas dentro de su alcance. Y, por lo tanto, en última instancia, podría tener más sentido hacer lo que sugiere isaacl. Best, Barkeep49 ( discusión ) 16:02 7 nov 2024 (UTC) [ responder ]
El procedimiento de "temas polémicos" parece ser algo que la comunidad debería reflejar sin dudarlo y que, en última instancia, tanto la comunidad como ArbCom deberían resolver. Si uno de ellos difiere, probablemente haya una buena razón para ello.
En cuanto a los problemas estructurales más amplios que surgirían si la comunidad lo adoptara en nombre de ArbCom , ya existen problemas estructurales con las sanciones generales debido a que la comunidad no adoptó el nuevo procedimiento CTOP para nuevos temas polémicos. Aunque la comunidad ha adoptado el contenido de WP:ARBECR para otras áreas temáticas como WP:RUSUKR , no lo adoptan por referencia sino copiando todo el texto textualmente. Awesome Aasim 17:13, 7 de noviembre de 2024 (UTC) [ responder ]
Ese no es el mismo problema estructural. La comunidad no ha tenido mucha discusión sobre la adopción del marco de temas polémicos para su propio uso (en mi opinión, porque es una discusión muy complicada en cuanto al proceso que no interesa a suficientes editores como para generar un consenso), pero eso no interfiere con la forma en que el comité de arbitraje utiliza el marco de temas polémicos. Esta propuesta sugiere que la comunidad añada automáticamente su propia sanción general sobre cada vez que el comité de arbitraje decida promulgar una sanción específica. Por lo tanto, el comité tendría que considerar cada vez si anular o no el complemento de la comunidad, y es posible que se deban realizar solicitudes de enmiendas tanto al comité como a la comunidad. isaacl ( discusión ) 17:33, 7 de noviembre de 2024 (UTC) [ responder ]
Antes de los temas polémicos, había sanciones discrecionales. Se volvieron muy confusas y, por lo tanto, el comité creó Temas polémicos para ayudar a aclarar la línea entre la comunidad y el comité (divulgación: ayudé a redactar gran parte de ese trabajo). Como parte de eso, el comité también estableció formas para que la comunidad se vinculara a los temas polémicos si quería. Por lo tanto, la comunidad no ha tomado esa decisión, lo cual está bien. Pero creo que esta es un área en la que, en general, ArbCom se desempeña mejor que la comunidad porque se presta más atención a tener coherencia en todas las áreas y, cuando surge un problema, he descubierto (básicamente en esta área solamente) que ArbCom es más ágil para abordarlo. Pero la comunidad también está más dispuesta a aprobar una GS que ArbCom a designar algo como CT (lo que creo que es una buena idea en general), por lo que lograr que la comunidad llegue a un consenso sobre cómo, si es que lo hace, quiere vincularse con CT (y sus evoluciones) o si preferiría hacer lo que quiera (incluso simplemente reflejar lo que esté en CT en ese momento, pero no los cambios posteriores) probablemente sería una buena discusión meta para tener. Pero tampoco parece necesario para esta propuesta en particular. Saludos, Barkeep49 ( discusión ) 17:41, 7 de noviembre de 2024 (UTC) [ responder ]
P3: Si esta propuesta no se aprueba, ¿debería aplicarse el ECP de manera preventiva a los artículos bajoWP:ARBECR¿Temas?
Soporte (ECP preventivo)
Soporte como segunda opción, pero solo para artículos. Las páginas de discusión se pueden aplicar únicamente a través de reversiones y protecciones breves, por lo que veo pocas razones por las que se deban proteger. Impresionante Aasim 19:58, 5 de noviembre de 2024 (UTC) [ responder ]
Soporte para artículos según Aasim. Las páginas de discusión aún deben estar abiertas para solicitudes de edición. (También cambié de opinión, según lo mencionado anteriormente. En todo caso, deberíamos aclarar ARBECR para que el límite de 500 a 30 solo se aplique en casos en los que sea necesario, no automáticamente, para resolver la ambigüedad. 20:52, 7 de noviembre de 2024 (UTC)) Chaotic Enby ( discusión · contribuciones ) 20:20, 5 de noviembre de 2024 (UTC) [ responder ]
Apoyo por mi comentario en la sección anterior. *Pppery* ya empezó... 20:52, 5 de noviembre de 2024 (UTC) [ responder ]
Estoy de acuerdo con Chaotic Enby y Pppery y creo que todos los artículos de CT deberían estar protegidos. En general, no soy partidario de proteger las páginas de discusión, pero es cierto que muchas páginas de discusión de CT son pozos negros de odio, por lo que no estoy seguro de cuál es mi postura sobre la protección de las páginas de discusión. Toadspike [Discusión] 20:57, 5 de noviembre de 2024 (UTC) [ responder ]
Según la redacción actual de ARBECR , cuando una restricción de este tipo está en vigor en un área temática, solo los editores confirmados por extensión pueden realizar modificaciones relacionadas con el área temática. Deberíamos proteger las páginas, en lugar de permitir que los nuevos editores editen y luego revertirlas básicamente sin ningún motivo. Esto es una pérdida de tiempo y muy mordaz .
No me opongo a cambiar la redacción de ARBECR para prohibir la reversión únicamente porque un editor no está confirmado, lo cual es una razón tonta para revertir ediciones que de otro modo serían buenas. Sin embargo, hasta que ArbCom cambie ARBECR, estamos atascados con las reglas que tenemos. Deberíamos dejar estas reglas claras a los editores antes de que editen, mediante la protección de la página, en lugar de después de que editen, mediante la reversión. Toadspike [Discusión] 10:55 16 nov 2024 (UTC) [ responder ]
Oponerse (ECP preventivo)
Me opongo porque creo que es una mala idea. Por un lado, hacer una lista de todos los artículos incluidos en el área restringida podría generar disputas que no necesitamos. (Este artículo podría estar incluido, pero ¿está realmente incluido? Las personas razonables podrían fácilmente estar en desacuerdo sobre si algunos artículos tratan "principalmente" del área restringida o "parcialmente", y por lo tanto sobre si la regla se aplica). En segundo lugar, cuando se trata de un problema serio y obvio, como un vandalismo flagrante, sería mejor que una IP la revirtiera en lugar de seguir las reglas sin pensar. Es importante recordar que nuestras reglas existen como un medio para un fin. Las seguimos porque, y en la medida en que, ayudan en general. Esperamos que los administradores y otros editores ejerzan su discreción. Nuestra política es que Wikipedia: Si una regla le impide mejorar o mantener Wikipedia, ignórela. Esta es una propuesta para declarar que la política de IAR nunca se aplica a la regla sobre quién debería editar normalmente estos artículos, y que no se permite ejercer la discreción. WhatamIdoing ( discusión ) 20:42 5 nov 2024 (UTC) [ responder ]
No soy Arb ni administrador, pero creo que las palabras "interpretado en sentido amplio" se eligieron específicamente para que, si un tema trata "en parte" del área restringida, se incluya en el CTOP. @ WhatamIdoing , ¿podría mostrarme un ejemplo de un caso en el que se haya disputado la designación CTOP o ECP? Toadspike [Discusión] 10:59, 16 de noviembre de 2024 (UTC) [ responder ]
Si bien ya existen precedentes de protección preventiva en, por ejemplo, RFPP, esto no me gusta. Por un lado, como las páginas de discusión (y, por extensión, las solicitudes de edición) no pueden usar el editor visual, esto hace que sea mucho más difícil para los recién llegados contribuir con ediciones, a menudo innecesarias en artículos donde no hay interrupciones. Aaron Liu ( discusión ) 23:47, 5 de noviembre de 2024 (UTC) [ responder ]
Oponerse ( Invocado por un bot ) : Demasiado estricto. C F A 💬 00:03, 6 de noviembre de 2024 (UTC) [ responder ]
Mu - This is basically my reading of the 500/30 rule as writ. Anything that would fall into the 500/30'd topic should be XCP'd on discovery. It's worth noting I don't view this as anywhere close to ideal but then neither did ArbCom, and given the circumstances of the real-world ethnopolitical conflict only escalating as of late (which in turn feeds the disruption) the only other - even worse - option would be full-protection across the board everywhere in the area. So why am I not arguing Support? Because just like the question above, this is putting the cart before the horse and this is better off being discussed after this RfC ends, not same time as. —Jéské Courianov^_^vthreadscritiques 02:47, 6 November 2024 (UTC)[reply]
Absolutely not, pages that do not experience disruption should be open to edit. Pending changes should never become widely used to avoid situations like dewiki's utterly absurd 53-day backlog. —Kusma (talk) 21:53, 6 November 2024 (UTC)[reply]
Very strong oppose, again Kusma puts it excellently. Protection should always be the exception, not the norm. Even in the Israel-Palestine topic area most articles do not experience disruption. Thryduulf (talk) 13:50, 7 November 2024 (UTC)[reply]
WP:RUNAWAY sums up some of the tactics used by disruptive editors: namely Their edits are limited to a small number of pages that very few people watch and Conversely, their edits may be distributed over a wide range of articles to make it less likely that any given user watches a sufficient number of affected articles to notice the disruptions. If a user is really insistent on pushing their agenda, they might not be able to push it on the big pages, they may push it on some of the smaller pages where their edits may get unwatched for months if not years. Then, researchers digging up information will come across the POV article and blindly cite it. Although Wikipedia should never be cited as a source, it still happens. AwesomeAasim 14:35, 11 November 2024 (UTC)[reply]
Per my comment above. jp×g🗯️ 18:18, 7 November 2024 (UTC)[reply]
No, see my comment to the other questions. Lectonar (talk) 08:52, 8 November 2024 (UTC)[reply]
No, we should never be preemptively protecting pages. Cremastra (u — c) 16:35, 10 November 2024 (UTC)[reply]
No, except on the most prominent articles on each CT topic (probably already done on current CTs, but relevant for new ones). Animal lover|666| 19:47, 11 November 2024 (UTC)[reply]
Absolutely not. See above comments for details. ~~ AirshipJungleman29 (talk) 20:50, 14 November 2024 (UTC)[reply]
Neutral (preemptive ECP)
Discussion (preemptive ECP)
I think this question should be changed to "...articles under WP:ARBECR topics?". Aaron Liu (talk) 20:11, 5 November 2024 (UTC)[reply]
Okay, updated. Look good? AwesomeAasim 20:13, 5 November 2024 (UTC)[reply]
As I discussed in another comment, should this concept gain approval, I feel it is best for the community to work with the arbitration committee to amend its remedy. isaacl (talk) 15:34, 7 November 2024 (UTC)[reply]
And as I discussed in another comment while I think the community could do this, I agree with isaac that it would be best to do it in a way that works with the committee. Best, Barkeep49 (talk) 16:03, 7 November 2024 (UTC)[reply]
General discussion
Since we're assuming that PCECP is possible and the last two questions definitely deal with policy, I feel like maybe this should go to VPP instead, with the header edited to something like "Extended-confirmed pending changes and preemptive protection in contentious topics" to reflect the slightly−larger-than-advertised scope? Aaron Liu (talk) 23:53, 5 November 2024 (UTC)[reply]
I think policy proposals are also okay here, though I see your point. There is definitely overlap, though. This is both a request for a technical change as well as establishing policy/guidelines around that technical change (or lack thereof). AwesomeAasim 00:26, 6 November 2024 (UTC)[reply]
If this proposal is accepted, my assumption is that we'd bring back the ORANGELOCK which was used for the original incarnation of Pending Changes Level 2. There's a proposed lock already at File:Pending_Changes_Protected_Level_2.svg, though it needs fixes in terms of name (should probably be something like Pending-level-2-protection-shackle.png or Extended-pending-protection-shackle.png), SVG code (the top curve is a bit cut off), and color (should probably be darker but still clearly distinguishable from REDLOCK). —pythoncoder (talk | contribs) 21:43, 8 November 2024 (UTC)[reply]
I think light blue is a better color for this. But in any case we will probably need a lock with a checkmark and the letter "E" for extended confirmed. AwesomeAasim 22:22, 8 November 2024 (UTC)[reply]
I am actually starting to wonder if "protection" is a bit of a misnomer, because technically pages under pending changes are not really "protected". Yeah the edits are subject to review, but there are no technical measures to prevent a user from editing. It is just like recent changes on many wikis; those hold edits for review until they are approved, but they do not "protect" the entire wiki. AwesomeAasim 23:40, 11 November 2024 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Okay, to make this clear, The content should NOT be taken down. NSFW and NSFl content needs to be shown because Wikipedia is a censor free website. No content should be treated over the other and NSFW and NSFL content needs to be treated the same as all the others. Now the proposal I will make is that since a lot of kids use Wikipedia to learn stuff and they may come across these things. For the sake of safety, gory, offensive and sexual content should have a blur or a black screen, and in order to view the image, they have to click the image and click I am over 18 or something like for example, they come across the Russo-Ukrainian war. In this article there is a gory picture. What there should be instead is a blur or a black box, the description of the picture still stays, and in order to view the content they have to press the picture, and it will ask for verification, like when you press the picture it says, this picture has gore in it or something like that, then it says you have to be 18 to view the image or something like that, then there is a button saying I am over 18 or something like that, then to view the content just press the button. If this somehow doesn’t work at least have a disclaimer at the top saying there is bad stuff in it. So yeah, here is my suggestion. Datawikiperson (talk) 11:11, 6 November 2024 (UTC)[reply]
What makes you think kids would not lie and just click "I'm 18"? Also see Striesand effect. 331dot (talk) 14:23, 6 November 2024 (UTC)[reply]
This has been proposed many times previously. It has failed for multiple reasons, including what should be censored being highly context and culturally (and even subculturally) dependent - for example person A might wish to blur a photograph of a woman breastfeeding but not a photograph of a gunshot wound, while person B might wish the exact opposite. If you take the view that anything anybody wants to be blurred should be blurred, even if others do not, but that would lead to extremes like all images of people being blurred.
A second reason is that there is no practical reason to apply the setting en-masse. At first glance, images in Commons:Category:Sex and subcategories would seem to be fairly uncontroversial, but that falls apart very quickly when you see what sort of images that would catch, for example:
Sex → Books about sex → Books about human sexuality, Books about LGBT
Sex → Biology of sex → Sex determination → Haplodiploidy
Sex → Sex in art → Sex (text) → CIL XIII 000129 → Musée Saint-Raymond, Ra 196
Sex → Ejaculation → Ejaculation of humans → Female ejaculation → Rufus, Le Poil
Sex → Females → Female symbols → Women icons → Blank persons placeholders (women)
So it would have be to set for at least each category, without subcategories, and there are at least thousands of them on Commons. At the individual image level you are looking at over 110 million. And that's assuming you can get agreement (per above). Thryduulf (talk) 11:57, 6 November 2024 (UTC)[reply]
I agree with what Lectonar and Thryduulf have said above. If this was implemented it would (since most of our editors are American) be as a very Americo-centric view of what is not safe - it would be Thryduulf's person A's view, not mine. The only way to guarantee safety is to block all images using one of the approaches on the page mentioned by Lectonar, Phil Bridger (talk) 13:17, 6 November 2024 (UTC)[reply]
People have created mirrors like Hamichlol, that is an option for those who want. Gråbergs Gråa Sång (talk) 14:43, 6 November 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Add AI translation option for translating from English to non-English article.
AI certainly improved a lot by now. It can translate to many non-english language better than traditional translators . My suggestion is to add AI translation option for translating from English to non-English article. User will review the AI translation to see if its correct. It will increase the translation quality. I dont suggest using AI for English article, that could have a devastating impact. Dark1618 (talk) 18:50, 7 November 2024 (UTC)[reply]
That's out of scope here, and would need to be asked on each and every individual language-edition of Wikipedia, as those would be the ones dictating policy for translations into their respective languages. —Jéské Courianov^_^vthreadscritiques 19:10, 7 November 2024 (UTC)[reply]
Why would a translation into English be devastating, but a translation from English into any other language be acceptable? English just happens to be that most used language in the world by some measures: beyond that it has no special status. Anyway, we can not decide here what is appropriate for other language Wikipedias. Phil Bridger (talk) 19:33, 7 November 2024 (UTC)[reply]
Good Idea! That’s actually what I was going to propose but you took it. To add to your amazing proposal, I suggest that every wiki translation must be approved by a speaker. Like If someone translated an article from English to Arabic, the translated article goes to an Arab speaker, by algorithm when the person would press a button that says “send for approval” or something like that, and the Arab person who gets the translated article will read the Wikipedia page and look for any errors, then the Arab corrects it and it gets published to the world. And why can’t the opposite happen, when an article gets translated to say french To English the same thing happens the French person machine translates the article, it gets sent to approval, a fluent English speaker goes and corrects it, then it gets published. If it is an extinct language, a person who is a professional in the language will correct it, and as for rates, I mean Wikipedia has at least 1 person who knows the language. Anyway have a good day! Cheers! Datawikiperson (talk) 10:10, 10 November 2024 (UTC)[reply]
I'm not sure of the technical backend for that tool, but I do see at English Wikipedia a constant inflow of articles translated from sister projects, usually without proper attribution, sometimes with broken templates.Some of these translations are pretty good, up to idiomatic phrasing; others have the appearance of raw machine translation, with errors no one fluent in the target language would leave in.As to the original proposal / idea, a flow of machine translations from this project to sister Wikipediae, that is indeed out of scope here, and would have to be brought up individually at each language project. Except maybe Cebuano Wikipedia. Folly Mox (talk) 14:49, 10 November 2024 (UTC)[reply]
I occasionally translate from English to Chinese and vice versa, and take on some bits from Japanese and Korea projects to be translated on to here if the information and sources can be used on here. And I strongly discourage automated AI translations from English to other languages, which you are proposing, without further inputs from the targeted language projects. AI translations to other languages from English are not perfect and can have the same devastating impact you don't want to see on English Wikipedia. – robertsky (talk) 14:30, 11 November 2024 (UTC)[reply]
Machine translation from English to most other languages is already enabled (and where it isn't it is a choice of the to project, not of the English Wikipedia). I don't think there is anything for us to do about this proposal? — xaosfluxTalk 10:33, 16 November 2024 (UTC)[reply]
"Wikipedia:Redirect sandbox"
A sandbox for testing redirects, which redirects to Wikipedia:Sandbox and has a sandbox notice when you click for more information about that sandbox. It can be redirected anywhere and is automatically reverted like all other sandboxes.
What is there to test that this would be good for? If you make a mistake while creating a redirect, you can just fix it. Remsense ‥ 论 08:42, 8 November 2024 (UTC)[reply]
Additionally, if you create an account you can experiment with redirects in your userspace as much as you want. Thryduulf (talk) 11:10, 8 November 2024 (UTC)[reply]
Authors should provide size of objects
The cliche is “Size doesn’t matter," but it does in many things — paintings, sculptures, jewelry, crystals, anything larger or small than usual and even if it’s the usual size if readers don’t know what that it. It makes a difference if a painting is 2” by 3” or 2’ by 3’. Especially in TPOD, because more people will see it, but really everywhere. I suggest that writers be encouraged to provide the relevant size in the text or caption of every photo where it’s necessary and that the editors working on TPOD be strongly encouraged to give the size whenever possible. If the size is not given in the text being referenced, that information is often in the photo's "details," in addition to the editing history. Wis2fan (talk) 04:51, 9 November 2024 (UTC)[reply]
True (MOS:ART naturally says this for article text) but vast numbers of Commons photos don't supply this info - probably the majority. Johnbod (talk) 12:42, 9 November 2024 (UTC)[reply]
Firstly, excuse my ignorance, but what is TPOD? Secondly, I don't see any clear proposal here. Yes, size is often important, but what do you think we should do about it? We can cajole editors into providing size, but we shouldn't reject images without it. Phil Bridger (talk) 13:48, 9 November 2024 (UTC)[reply]
Sorry I got the abbreviation wrong — POTD. Today’s (11/10/2024) POTD is an example of what I’m talking about. The reader knows a bark beetle is tiny, but why not give the actual size? It’s not that the information isn’t available. I clicked on the photo, then on "details." The description of the photo says the adult male is 4.0 mm to 5.5 mm long. I came back to the post and clicked on the name. The linked article includes the same information. The information is there this time. I agree, it’s not always either place. But when it is, it should be provided to be complete. Wis2fan (talk) 04:54, 10 November 2024 (UTC)[reply]
A picture caption is finite, it does not need to (and indeed in most cases cannot) include every detail about an image and its subject. Therefore it should only include information that is most relevant, and that will not always include the size. For example the POTD for 8 November was an 1860 photograph of John Tarleton (Royal Navy officer), is the size of the print really the most relevant information or is it the size of the subject what you want to know? It's fine to encourage people to put the size of the image and/or subject in the caption where that is relevant, but it is not always going to be, so a one-size-fits all rule is not going to be appropriate. If you want to know, just look at the extra details. Thryduulf (talk) 14:37, 10 November 2024 (UTC)[reply]
Thryduulf is absolutely correct, the size of the object in a photo is unimportant when it is a human. The size isn’t necessary for today’s POTD (11/11/2024). But I still think it is important when it is a bark beatle. And many other things. I also think that a writer should anticipate a reader’s questions and provide the answers. Suggesting that if a reader wants the size of an object they should look at the extra details is not helpful. I’d bet most readers don’t know how to find them. Wis2fan (talk) 04:29, 11 November 2024 (UTC)[reply]
I vaguely remember I suggested something similar at commons once, requesting that more people who post photos consider including a scale-bar if it's the sort of subject that would benefit from one (biological specimens, museum artefacts whose size is likely to be unclear to a general reader). I think I got shot down in flames for general naivete. My opinion is: In any situation where a reference book would use a scale bar, or indicate prominently by caption or other means, the size of an illustrated object, we should do the same, so far as we can. This would probably include articles about most species (birds, insects etc.) and articles about things where the size is central to the article (an article on miniaturisation of transistors, for example, should show the size of the transistors in its photos). Elemimele (talk) 13:52, 12 November 2024 (UTC)[reply]
Artist collective infobox
Hello! I have made an infobox for artist collectives (inspired by my own frustration trying to use the regular artist one for graffiti crews) and would like feedback from the community before publishing it. The old infobox proposal page is now defunct and suggests posting here instead.
Personally, I'd much rather not see this, or anything like it, used. Almost everything in it will be disputable or disputed, or is really vague. It seems a classic example of where an infobox is just unhelpful clutter, and will displace or make too small an image that would be more helpful. Are you asking at the VA project, & if not, why not? It's not really for here. Johnbod (talk) 05:03, 12 November 2024 (UTC)[reply]
Require 2FA for bureaucrats
Heya, I noticed a couple of weeks ago that while interface administrators and central notice administrators need 2FA, bureaucrats, who can grant interface admin don't need 2FA. To me this seems a bit weird, because if you wanted to compromise an account with access to interface admin tools, bureaucrats may not all have 2FA. Hence, I'm proposing requiring all enwiki bureaucrats to enable 2FA as a precaution. Zippybonzo | talk | contribs (they/them) 09:24, 12 November 2024 (UTC)[reply]
If this is the case then they absolutely should begin to require 2FA (although I'm sure in practice they all have it anyway) Gaismagorm(talk) 13:35, 12 November 2024 (UTC)[reply]
Yeah, that's my thoughts, I imagine they do all have it, but formalising it as a requirement seems to make sense IMO. Zippybonzo | talk | contribs (they/them) 14:30, 12 November 2024 (UTC)[reply]
Hold. This is being evaluated upstream (phab:T242555 (restricted task)) - if WMF ends up requiring it we won't need a local project rule. — xaosfluxTalk 13:51, 12 November 2024 (UTC)[reply]
I see non-restricted adjacent bugs T242553 and T242556 were both created on 12 Jan 2020. Would it be accurate to describe this as an evaluation which has been unresolved for about 5 years? -- zzuuzz(talk) 13:58, 12 November 2024 (UTC)[reply]
Hold—for another five years :) SerialNumber54129 14:39, 12 November 2024 (UTC)[reply]
Before GTA6 maybe lol Zippybonzo | talk | contribs (they/them) 17:02, 12 November 2024 (UTC)[reply]
There's no reason we can't impose a local requirement for this independently of the WMF. And the current system is utterly illogical. Support doing so. * Pppery *it has begun... 17:07, 12 November 2024 (UTC)[reply]
Support per pppery and zippybonzo - should be a requirement locally. Waiting for phab tickets could take years while I imagine a RFC would pass pretty quickly. BugGhost🦗👻 19:44, 12 November 2024 (UTC)[reply]
Easy support. They have to much potential power to not have max security on accounts. Kingsmasher678 (talk) 19:54, 14 November 2024 (UTC)[reply]
No knowing when WMF might implement. Support. ~~ AirshipJungleman29 (talk) 21:02, 14 November 2024 (UTC)[reply]
The fact that 'crats can assign interface admin (a role which requires 2FA) but are not required to have 2FA personally enabled is wild. Support a local rule (and hopefully the largest WMF project implementing such a rule will encourage others to make such a change). HouseBlaster (talk • he/they) 00:43, 15 November 2024 (UTC)[reply]
Definite support. I am personally in favor of a 2FA requirement for any privileged group, but it is something I doubt will happen anytime soon. Crats should absolutely have it enabled. EggRoll97(talk) 01:51, 15 November 2024 (UTC)[reply]
Question. How are you going to check whether the user enabled 2FA or not? This information is not public. Only WMF can confirm this. Ruslik_Zero 20:02, 15 November 2024 (UTC)[reply]
Technically stewards can do it too. And, of course, trusting people not to lie to us. * Pppery *it has begun... 20:10, 15 November 2024 (UTC)[reply]
If someone's a crat and lies about having their 2FA enabled then that's probably breaching the trust we have in them as crats. Zippybonzo | talk | contribs (they/them) 09:12, 16 November 2024 (UTC)[reply]
Yes, stewards can check this, and we periodically audit this for compliance on projects. Also, 'crats will very likely soon be able to check this as well - just some paperwork in that way right now (primarily so they can check it before assigning intadmin to others). — xaosfluxTalk 10:29, 16 November 2024 (UTC)[reply]
Oppose, because the last time I checked, WMF's self-developed version of 2FA was not really fit for purpose. It's not like they're using Duo or Google or something. If anything, I'd support removing it from the roles requiring it now. --Floquenbeam (talk) 20:16, 15 November 2024 (UTC)[reply]
It works OK, but is certainly not ready for large-scale deployment due to the support model and capacity. Staff is generally responsive to recovery requests for those that WMF requires enrollment though. — xaosfluxTalk 10:30, 16 November 2024 (UTC)[reply]
RfC: Should a blackout be organized in protest of the Wikimedia Foundation's actions?
I think we should have infoboxes for rituals and cultural practices, as studied in anthropology and religious studies. Parameters like associated culture, associated religion, purpose, origin, place, whether or not it is extinct, and when it is observed could be included. Examples of articles that could benefit are Akazehe, Savika, Sikidy, Haka, Bar Mitzvah, Quinceañera, Nggàm, and Hajj. ꧁Zanahary꧂ 19:17, 14 November 2024 (UTC)[reply]
Can you perhaps make an example? Polygnotus (talk) 23:24, 14 November 2024 (UTC)[reply]
I like infoboxes but I don't think these topics need it. PARAKANYAA (talk) 09:26, 15 November 2024 (UTC)[reply]
I agree, there’s not really enough fields they’d have in common. Although I personally believe that every article that has an applicable infobox should use it, there’s also many articles that work best without them. novovtalkedits 10:38, 15 November 2024 (UTC)[reply]
Yes, infoboxes work best when there are a number of basic uncontroversial factual characteristics that are shared by a group of articles. That's very far from the case here. Johnbod (talk) 14:06, 15 November 2024 (UTC)[reply]
Johnbod said it well. To that I would add info that easily reduces to a short factoid. North8000 (talk) 14:11, 15 November 2024 (UTC)[reply]
Extended confirmed users should be allowed to CheckUser their IP that they are currently on
I propose that extended confirmed users should be allowed to get users from the IP address that they are currently logged onto because to see and disclose on Template:User shared IP address. Extended confirmed users are trusted (30 days and 500 edits) and the CheckUsers can see the log to see who's outing. 1.144.109.84 (talk) 21:08, 15 November 2024 (UTC)[reply]
That would clearly violate the privacy of other users who might have used the IP address. It's not going to happen. -- zzuuzz(talk) 21:13, 15 November 2024 (UTC)[reply]
Connecting users to IP addresses is something that not even Checkusers (arguably the most trusted editors on the project) do, as it is a breach of the Wikimedia Foundation Privacy Policy. We couldn't do this even if we wanted to. Thryduulf (talk) 21:44, 15 November 2024 (UTC)[reply]
Can we consider EC level pending changes?
This is just an idea, and I want to workshop this a bit more, but I think it would be helpful to have pending changes at the extended confirmed level. This could be called "PC2" again (not to be confused with the original PC2) or "PCECP". The idea would be to help enforce WP:ARBECR and similar restrictions where non-extended confirmed users are prohibited from certain topic areas. Under this level, edits by non-extended-confirmed editors would be held for review, while extended confirmed users can approve these edits and thus take responsibility under WP:PROXYING.
I think it would be helpful for pages where (1) parts of the article intersect with a contentious topic, or (2) the article in its entirety intersects with a contentious topic, but not edited frequently. AwesomeAasim 16:54, 27 September 2024 (UTC)[reply]
This seems like it could be useful. It would have to be restricted to infrequently edited pages (likely excluding all current events articles) so as not to overwhelm Pending Changes every time Reuters publishes a new story or an edit war erupts. The big question is: what problem are you trying to solve? Toadspike[Talk] 20:39, 27 September 2024 (UTC)[reply]
There are some contentious topics designated either by ArbCom or the community where only extended confirmed users are allowed to participate. However, admins refuse to protect pages where there isn't enough disruption to justify protection. Although, it should be considered that the XCON restriction applies regardless of whether a page is protected or not.
What PCECP would do is essentially remove fears that there "isn't enough disruption to justify protection" while buffering all non-extended-confirmed contributions so they have to be approved, in line with "non-extended-confirmed can only make edit requests". Templates that are specifically for this case like {{edit protected}} break when the page is not protected. AwesomeAasim 22:00, 27 September 2024 (UTC)[reply]
The problem with that is that the 500/30 rule is specifically designed to keep newer editors out due to extreme amounts of disruption as a rule. There's a good reason why both of the world's main hot wars (the Arab-Israeli conflict and the Russo-Ukrainian war) are under 500/30. And, as has been brought up repeatedly and bears repeating again, high volumes of edits on a given article contraindicate CRASHlock.
But the biggest stumbling block here is that no consensus exists yet for an extended-confirmed CRASHlock. The last discussion about expanding CRASHlock to higher protection levels predates XCP entirely. There would need to be a formal RfC for this, not VP spitballing. —Jéské Courianov^_^vthreadscritiques 15:37, 28 September 2024 (UTC)[reply]
XCON protection makes sense for high traffic articles, but low traffic articles? If the edit is minor such as fixing spelling mistakes or grammatical errors, there should be no problem. Fixing spelling and grammar is generally outside of contentious topic areas anyway. From WP:ARBECR: On any page where the restriction is not enforced through extended confirmed protection, this restriction may be enforced by other methods, including ... the use of pending changes.
I probably would set up abuse filters as well to see if a page is in a category that primarily deals with a contentious topic, and then warn and tag the edit in question. AwesomeAasim 16:22, 28 September 2024 (UTC)[reply]
Most low-traffic CT articles don't have any protection since they never saw amounts of vandalism necessitating protection. Protection requests that solely rely on arb enforcement and little to no evidence of vandalism get declined. Aaron Liu (talk) 23:26, 28 September 2024 (UTC)[reply]
Yeah I see that, but the problem is that a non-XCON edit will get approved on pages that not many people are watching. Pending changes still allows non-XCON users to make these edits, but their edits will need to be approved and they can be reverted if in violation of WP:ARBECR. This is also in line with how pending changes is used on low-traffic articles to monitor (not prevent) disruption. AwesomeAasim 18:26, 29 September 2024 (UTC)[reply]
@Aaron LiuMost low-traffic CT articles don't have any protection since they never saw amounts of vandalism necessitating protection. Protection requests that solely rely on arb enforcement and little to no evidence of vandalism get declined. Untrue, articles in ECR topics can and are pre-emptively locked. What actually happens is that articles with minimal disruption are usually not brought to WP:RFPP or noticed by a wayward admin. Mach61 19:53, 29 September 2024 (UTC)[reply]
Untrue, articles in ECR topics can and are pre-emptively locked.
Could you add an example? There is a long list of declined RFPP requests for arbitration enforcement. Aaron Liu (talk) 20:42, 29 September 2024 (UTC)[reply]
See this exchange between an admin who refused to protect based on ECR due to a lack of disruption and a (former) admin who explained to them otherwise. Mach61 19:46, 1 October 2024 (UTC)[reply]
Thanks, I get the "can" now. Aaron Liu (talk) 20:59, 1 October 2024 (UTC)[reply]
Seems reasonable. I've always wondered why pending changes isn't deployed more often. It seems a useful tool, and there are lots of pending changes reviewers so very little backlog Cremastra (talk) 14:18, 28 September 2024 (UTC)[reply]
Would you care to elaborate on your point? I'm not seeing it. Anomie⚔ 17:04, 28 September 2024 (UTC)[reply]
@Anomie: Read the "Proposal" section on the linked page. The fact that RfC even exists should give you a clue as to why CRASHlock is so mistrusted by a significant minority of editors. —Jéské Courianov^_^vthreadscritiques 18:01, 9 October 2024 (UTC)[reply]
Still not seeing it. People supposedly mistrust it because there was a trial 14 years ago and enwiki admins didn't immediately stop using it after the trial period pending a consensus on the future of the feature? Anomie⚔ 18:43, 9 October 2024 (UTC)[reply]
The TL;DR I'm taking away from this discussion is that you're still butthurt over consensus not going your way 12 or 13 years ago, and assuming that anyone opposed to PC shares that reason and no other. I think it's unlikely continuing this conversation is going to go anywhere useful. Anomie⚔ 18:59, 9 October 2024 (UTC)[reply]
That isn't how consensus works, either. Consensus can be determined by an RfC, yes. But it can also develop just by the way that things are done already, regardless of whether it has formally discussed.
I think about the example given by Technology Connections about "the danger of but sometimes". The LED traffic light is superior in energy savings and much more, but sometimes snow and ice builds up on them, so they are bad. Likewise, XCON pending changes will help with enforcement of WP:ARBECR but sometimes admins might apply this to pages out of policy, so it shouldn't be used again. The correct response would be to place in policy guardrails so that admins don't do that. AwesomeAasim 19:00, 9 October 2024 (UTC)[reply]
How is an RfC from over 13 years ago still reflective of consensus today? I am pretty certain that while some opinions might not have changed, others definitely will have. No one is saying there should be full pending changes. AwesomeAasim 18:16, 9 October 2024 (UTC)[reply]
Also, please explain what you mean by "crashlock". I cannot find any discussion or glossary entry on "crashlock". AwesomeAasim 18:21, 9 October 2024 (UTC)[reply]
I guess you might be the only one using this terminology; as it is not in WP:GLOSSARY or anywhere else.
Nonetheless, this is the Idea Lab; it is the place to develop ideas, not to show stark opposition to ideas. That is what the other discussion boards are for; consensus polling. It should be noted that WP:ECP was created originally for the purpose of enforcing arbitration decisions and community sanctions. It was never intended for anything else; it just got used for other stuff de facto. AwesomeAasim 18:40, 9 October 2024 (UTC)[reply]
(edit conflict) All these things you think are obvious really are not. You should try explaining yourself better instead of emphatically waving your hands at something random. Anomie⚔ 18:43, 9 October 2024 (UTC)[reply]
Obvious perhaps, but it still doesn't make much sense. I'm not sure how using your own special terms of unclear implications to disparage things you dislike is helping communication or community understanding here. Cremastra (talk) 19:37, 9 October 2024 (UTC)[reply]
I don't understand. People mistrust PC because of a bureaucratic misimplementation of an experiment over 10 years ago? (In a noncentralized bureaucracy where dumb shit happens all the time?) The RfC is explicit that it makes no normative judgement on PC, and it seems the !voters are not doing so either. SamuelRiv (talk) 18:37, 9 October 2024 (UTC)[reply]
Ok for those not into WP politics, there's an overview opinion piece from the August 2011 WSP that seems to capture the attitude and aftermath. It appears the closure results of the RfCs left admins in an indeterminate state as to whether PC can ever be applied or removed. SamuelRiv (talk) 18:47, 9 October 2024 (UTC)[reply]
as to whether PC can ever be applied or removed True in 2011 when that was written, but later RFCs resolved that. Anomie⚔ 19:02, 9 October 2024 (UTC)[reply]
Could you link to said RfCs? All else that's linked previously regards the main page. SamuelRiv (talk) 19:56, 9 October 2024 (UTC)[reply]
It's worth noting that the 2017 RfC is the last one about any aspect of CRASHlock, to my knowledge. As I said above, there would need to be a new RfC in order to get consensus for extended-confirmed CRASHlock, as PC2 was originally full-protection level and no ECP!CRASHlock question was asked in the2016RfCs, none of which were particularly comprehensive. (The last comprehensive RfC was the 2014 clusterfuck.) —Jéské Courianov^_^vthreadscritiques 06:47, 10 October 2024 (UTC)[reply]
I think the main reasons editors don't want to expand the use of pending changes are practical: no technical support for fixes (or additional feature development) is on the horizon, in spite of documented bugs; and uncertainty in the community's ability to manage expanded use. There are certainly vocal editors who are wary due to past history, but this has already been a factor in other decisions, and they have accordingly been influenced to be more definitive about how any trials will proceed. isaacl (talk) 18:55, 9 October 2024 (UTC)[reply]
Ok so there's a lot of history here as you are already seeing above, and no one's even gotten to discussing Phillipe's little misadventure yet. Despite all that I actually think the general idea here is sound. And since we are discussing history its worth pointing out that as a practical matter this is actually closer to what the EC restriction was intended to do in its earliest incarnation where it functioned as a softer version of 1RR originally enforced as a bespoke AE remedy on one specific article reverts of non-qualifying accounts did not count towards 1RR.
Times have changed, ECR now tends to be enforced in mainspace with ECP and is applied far more broadly than anyone from then would have envisioned, for better and for worse.
The best use case here is for quiet pages where the history of non-EC editing is largely one of minor non-contentious fixes and improvements, but have caught attention due to sporadic contentious edits, where it can offer a middle way between leaving enforcement to post-edit reverts and preventing all non-EC editing.
As a practical matter the limitations of the extension mean that it really only works-well on low-traffic pages and realistically improvements to the extension aren't coming anytime soon. So use case (2) makes sense, but (1) is a harder sell. Might not be enough of a use case to justify the hassle. Personally I'd have to do some research and think about this a little but the basic idea is sound.
Apologies for the hastily typed response, I'm a little pressed for time; hopefully there was something useful in there. 184.152.68.190 (talk) 16:06, 22 October 2024 (UTC)[reply]
Maybe what is needed is this...
A multi-part RfC asking how ECR should be enforced for existing pages, including based on activity. High traffic pages will need extended protection retroactively as those tend to get the most disruption from ECR violations. Low-traffic pages, not so much, but we can use abuse filters and workshop ECP pending changes for this. Spelling and grammar fixes as far as I am aware are excluded from WP:ARBECR. AwesomeAasim 19:52, 1 October 2024 (UTC)[reply]
I view the ECR in the PIA area to be absolute (no editing full stop by those who do not meet 500/30), so CRASHlock would be off the table there in any event. I'm not sure if this also applies to WP:GS/RUSUKR (which falls into the EE area). —Jéské Courianov^_^vthreadscritiques 18:57, 9 October 2024 (UTC)[reply]
Can we build the proposal here?
Here is some starter text maybe to get the ball rolling:
What is the best way to enforce WP:ARBECR on articles?
Option 1: Preemptive XCON protection
Option 2: Preemptive XCON pending changes
Option 3: Edit filters
anything else?
This probably is incomplete, anyone else have ideas for this proposal? AwesomeAasim 19:41, 16 October 2024 (UTC)[reply]
I'd say remove "preemptive", as it is sometimes placed only in response to disruptive activity from non-ECs. Aaron Liu (talk) 11:31, 17 October 2024 (UTC)[reply]
So should reactive also be an option? AwesomeAasim 17:32, 17 October 2024 (UTC)[reply]
I think so. That's what I support. Cremastra — talk — c 19:29, 17 October 2024 (UTC)[reply]
So we should have it like this?:
What is the best way to enforce WP:ARBECR on articles? Please rate whether these options should be preemptive, reactive, or not used.
sure. Cremastra — talk — c 19:42, 17 October 2024 (UTC)[reply]
Sounds good - but bear in mind we are discussing CRASHlock (which would require developer buy-in to make XC happen) and an Arbitration policy (which ArbCom may short-circuit). Also note that there would likely need to be a separate RfC consensus to allow XC CRASHlock in the first place; like I said above we haven't had a comprehensive discussion about it since 2014. —Jéské Courianov^_^vthreadscritiques 16:26, 26 October 2024 (UTC)[reply]
@Jéské Couriano, I do wish you would quit using that made-up word. WP:PC is shorter to type, and when editors use the same words for the same thing, then we're less likely to end up with avoidable confusion ("CRASHlock sounds really bad, but I'm just asking for WP:PC"). WhatamIdoing (talk) 00:26, 27 October 2024 (UTC)[reply]
My point still stands - a new RfC, developer buy-in, and ArbCom not interdicting the RfC would be required for this to become a reality. —Jéské Courianov^_^vthreadscritiques 17:34, 27 October 2024 (UTC)[reply]
No, we're discussing "pending changes protection". Crashlock is a type of cardboard box. --Ahecht (TALK PAGE) 21:18, 28 October 2024 (UTC)[reply]
WP:ARBECR can first just be XCON PC. After extensive edits by non-EC, piling on to PC backlog, then it can just be upgraded to normal XCON. If the disruption is already severe before being brought to RFPP or other venue, then XCON protection can just be the first action. ~/Bunnypranav:<ping> 13:05, 28 October 2024 (UTC)[reply]
Please, stop calling it "CRASHLOCK" it's confusing and pointless. At least explain why pending changes = crashing. Cremastra (u — c) 19:59, 28 October 2024 (UTC)[reply]
@Jéské Couriano the discussions that you linked are from 2016, so we cannot assume the consensus has not changed. Also, I believe that this is a platform for building ideas and new proposals, hoping to bring them to reality while abiding by consensus. ~/Bunnypranav:<ping> 15:28, 30 October 2024 (UTC)[reply]
@Bunnypranav: Which is why I'm saying "start a new RfC." Something everyone seems to be glossing over despite me saying something to this effect four separate times in this thread. —Jéské Courianov^_^vthreadscritiques 06:44, 3 November 2024 (UTC)[reply]
On another thought I am actually wondering if we can just have a two-part RfC as to whether to turn on this feature I discuss. Part 1 would just be about PCECP and part 2 would be just about replacing ECP with PCECP on low-traffic WP:ARBECR and related articles. AwesomeAasim 16:41, 30 October 2024 (UTC)[reply]
That makes sense, but the second RfC might fail, as it one would have to discuss page wise about the change in protection. Also proving that PCECP is enough for said pages will be complicated, and also have to think about the storming of backlog in PC if it is not enough. ~/Bunnypranav:<ping> 16:45, 30 October 2024 (UTC)[reply]
That would be hard-required, as I've repeatedly been saying. Without an existing consensus for the former, any discussion on using it for 500/30 rule areas is academic. —Jéské Courianov^_^vthreadscritiques 06:51, 3 November 2024 (UTC)[reply]
While many people have made contributions to history (many more than could fit in one timeline), it's undoubtable that some people's influence far exceeds that of others. 
Therefore, I think we should have a timeline of the significant figures in history. 
I completely understand that determining how significant some people are is a difficult task. It's expected to take struggle and effort to make this work. However, people deserve to know who made the greatest contributions to the advancement of humanity.
Also, many scholars themselves have written about who they believe are to be the most significant people.
I have created a sketch of this idea at User:Wikieditor662/sandbox. It's far from perfect, but you get the main idea. The people are colored based on the era they were in. The most significant people make it to the overview and those who are not as important but still nonetheless significant (as well as people born earlier so the overview doesn't get clumped) go to the individual timelines (below the overview) along with those in the overview.
I would again like to reiterate that this is something that is going to take effort, dedication, and much debate, but if we do this, then I think it could be worth it. What do you all think?
Kindly, I'm experiencing philosophical opposition to this project. History has been a team effort, and further elevation of the already elevated is not likely to improve genuine understanding of historical processes. The Great man theory correctly fell out of fashion early last century.Having said that, I don't mean to dissuade you from undertaking a project you're clearly interested in, and this seems like it could serve as some kind of subpage of WikiProject Vital Articles. Using the inclusion criterion "listed at WP:VA" is probably the only way you'd ever develop any kind of agreement as to which historical figures to include. That WikiProject has already done a lot of debating over which topics are more important than others.The periodisation scheme is pretty parochial and Eurocentric, and would have to be converted to numeric year spans or whatever schema WP:VA uses (and the section headings would have to be delinked per MOS:NOSECTIONLINKS). You'll also want to consider how to handle cases where vital dates are approximate, unknown, disputed, etc. Folly Mox (talk) 00:12, 24 October 2024 (UTC)[reply]
I would tend to agree with Folly Mox on this. I'll add that it might be pretty much impossible to find an actual inclusion criteria, that is, any kind of consensus in reliable sources as to who is a significant enough figure – or even if we can compare the significance of historical figures across times, cultures, and domains. If anything, that page will inform more about our own selection than about any historical truth behind it.However, having it as part of WP:VA, rather than as an encyclopedic article, could make it a pretty useful reference for articles about famous figures needing improvement, without claiming that these are necessarily the most significant ever. Chaotic Enby (talk · contribs) 01:07, 24 October 2024 (UTC)[reply]
@Wikieditor662: you may have set yourself up for a poor reception with the questionshould people be included based off on how significant, famous, or both they are/were?. Both of these attributes are not quantifiable: the only inclusion criteria VA would recognise as feasible would probably be "limit to Level 3" (112 figures), or "include Level 3 and Level 4" (1995 additional figures; 2107 total). (Delta qualifiers like "vital dates securely known".)When a discussion is opened on a page and nobody responds for almost two weeks – as is the case here – this can often be understood as signalling lack of interest.If you really are interested in this data visualisation existing somewhere outside your userspace – which has seen no buy-in by participants at this thread nor any of the 93 watchlisters of the WikiProject talkpage – a next step might be to make a new timeline including precisely the figures listed at Wikipedia:Vital articles/Level/3 § People, and pitch the idea again, specifically as a WikiProject subpage, perhaps at WT:VA instead of WT:PVITAL.I'm afraid I feel compelled to reiterate that this idea does not feel pedagogically sound, and is likely to tell us more about the people who select the figures to include than it teaches about history. Folly Mox (talk) 01:06, 7 November 2024 (UTC)[reply]
That sounds like a giant pile of WP:OR – Joe (talk) 12:26, 24 October 2024 (UTC)[reply]
Avoiding a long month of drama
Well. WP:RECALL is upon us now, and, while clearly an improvement for community accountability, the first petition is already showing that the system has its limits. To be fair, that is to be expected – we can't really brainstorm a perfect system without any real-life testing, and such a new system should be open to community inputs for tweaking it into a more functional state.
Namely, the issue is with recall proposals that are, from the start, overwhelmingly likely not to succeed. In a case such like this one, where the number of (informal) opposes far outweighs the number of signatories, prolonging the long drawn-out process (the petition being open for a month, and then potentially seven days of RRfA) isn't desirable if the outcome is already pretty much known. I figure there should be a way to cut short petitions where it is clear that most editors are not behind it, a sort of WP:SNOW close, to avoid dragging the admin and the community through a month-long slog.
Of course, the petition itself shouldn't be the final !vote on admin accountability, but only a means to bring up the issue. So, if we go through an opposes/signatories ratio to close it early, for instance, it should be pretty high (maybe 3 to 1?), but still allow a way to cut short petitions with no chances of succeeding. Chaotic Enby (talk · contribs) 13:55, 28 October 2024 (UTC)[reply]
Discussion ongoing: limiting petition participation to signatures Discussion ongoing: shortening the recall period Links added 12:24, 7 November 2024 (UTC) —Folly Mox (talk)
Agreed. If each person were allowed to write a single short statement (absolute maximum 2 sentences) about why they support/oppose and no discussion or replies were allowed then a month would be reasonable. A month of what's currently happening at the first petition is completely unreasonable - a week of that plus a week of RFA hell is not reasonable even for someone whose conduct is beyond the pale (and they should be at Arbcom anyway) let alone a month for someone who has just made a few minor mistakes or pissed off a few people.
The Crats should be empowered to close petitions early if the result is clear (either way). Arbcom still exists as a venue should people think that a petition that was going to succeed was closed too early. Thryduulf (talk) 14:15, 28 October 2024 (UTC)[reply]
Isn't the primary point of the petition process to ensure that we don't have frivolous RRFAs? It seems that most of the participants are already trying to skip to a future RRFA discussion that may not even materialize. — xaosfluxTalk 14:23, 28 October 2024 (UTC)[reply]
That is indeed an issue, the petition is itself getting a RfA-like amount of discussion before the RRfA even started. Thryduulf's proposal of limiting the conversation to a single short statement per person could make it much more manageable, and cut short the problem by making 30 days long petitions less awful. Chaotic Enby (talk · contribs) 14:59, 28 October 2024 (UTC)[reply]
Opposes don't formally affect the outcome of the petition, that's what the RRfA is for. From my own thought process (and from what I read from that discussion), opposes can only dissuade potential petition signers to NOT sign the petition. fanfanboy(block) 14:39, 28 October 2024 (UTC)[reply]
I know, that's why I was referring to them as informal opposes above. But there should still be a way for the community to formally state that the vast majority is not in support of a petition. At least to shut down frivolous petitions in advance. Chaotic Enby (talk · contribs) 14:57, 28 October 2024 (UTC)[reply]
I feel like if a petition is unnecessary, then no one would sign it. fanfanboy(block) 15:02, 28 October 2024 (UTC)[reply]
The Lizardman's Constant means that pretty much all views will be supported by some people, so no, I don't think we can rely on that. It's a complete waste of everyone's time if we only pay attention to the support votes and force a WP:SNOWBALL petition to go to RRfA. Theknightwho (talk) 18:34, 30 October 2024 (UTC)[reply]
There is no drama except what some editors are creating. I don't think an admin is going to quit because they discover that five people think they shouldn't be an admin. Those that oppose the petition can just... not sign it. It'll be over in 30 days. I'm not opposed to shortening the 30 days but I'd rather wait at least one full cycle before deciding. Preferably more than one full cycle. Levivich (talk) 14:47, 28 October 2024 (UTC)[reply]
As I have said elsewhere, we need to reduce the drama surrounding these. I agree that people opposing the petition should just leave it alone. There should be no discussion section and no threaded responses to endorsement; a week of discussion (which is plenty) happens once the petition is successful. Additional discussion only makes the signal to noise level worse and cranks up the heat. —Kusma (talk) 22:54, 29 October 2024 (UTC)[reply]
Noting I've withdrawn the petition. Sincerely, Dilettante 15:41, 28 October 2024 (UTC)[reply]
Agree with some of the others that shortening the time makes sense, though I don't think we should be cutting it to shorter than 2 weeks if we started at 30 days. 25 signatures in 30 days does seem really out of wack - less than one signature a day, in a community this large, where RFAs have some 200 votes in a week and we've already got more than 400 votes in the admin elections? Seems very off. -- asilvering (talk) 16:12, 28 October 2024 (UTC)[reply]
Two weeks as a baseline sounds like a more reasonable time, that could very much work. Chaotic Enby (talk · contribs) 16:15, 28 October 2024 (UTC)[reply]
Thing is that many editors (including myself) voted for the 30 days. Now seeing what has happened, I agree it should be shortened. 2 weeks seems like a good number. fanfanboy(block) 16:21, 28 October 2024 (UTC)[reply]
I suppose, we'll have to be mindful of the potential for editors to seek an administrator's recall, who blocked/banned them, in the past. Grudges are always possible as being a core of recall attempts. GoodDay (talk) 14:46, 28 October 2024 (UTC)[reply]
I think shortening the time period for the petition to 10 or 14 days makes sense. I would oppose allowing snow closes regardless of how unlikely it appears that a petition will pass. ~~ Jessintime (talk) 15:18, 28 October 2024 (UTC)[reply]
That's exactly what I suggested a few months back Mach61 16:44, 28 October 2024 (UTC)[reply]
I'm inclined to believe that, instead of tinkering with this on an ad hoc basis with every new petition, we modify the terms of the recall process to be a six-months trial and then -- at the end of that -- evaluate everything that worked and didn't and make whatever modifications are needed in one fell and final swoop. Chetsford (talk) 16:25, 28 October 2024 (UTC)[reply]
@Chetsford The close of the final RfC establishing recall instructed that any outstanding issues may be resolved through normal editing. (emphasis mine), and personally, I am very burnt out by all the multi-step trials and ratification RfCs that sprung out of RFA2024. Mach61 16:47, 28 October 2024 (UTC)[reply]
I have no idea what that means. Any single editor can just change the process by WP:BOLD editing it? If that's the case, why are we having this discussion? Chetsford (talk) 16:52, 28 October 2024 (UTC)[reply]
To be fair, this is a discussion on the idea lab, so the goal is first to figure out what to change before figuring out how to change it. And also because, even if a user could technically make a WP:BOLD edit, having a consensus behind it is always good. Chaotic Enby (talk · contribs) 17:00, 28 October 2024 (UTC)[reply]
I looked at the petition before it closed, and realised multiple editors opposing it despite it not having any effect. I think it should be possible to run a petition in a closer timeframe to an RfA or AfD. To summarise, petitions could be changed as follows :
Each petition runs for exactly a week.
Any extended confirmed editor can support or oppose the petition
If consensus is reached to desysop after a week (ie: support / support + oppose = 70% per current RfA thresholds) then the admin is desysopped
I think holding an admin to the threat of being desysopped for over a month is worse than what happens at Arbcom. Conversely, if the community is in obvious agreement than an admin has outstayed their welcome and must go, it gets the job done far more quickly without people getting frustrated about when it's going to happen. And furthermore, if somebody starts a petition in retaliation ("Desysop this admin, he blocked me for no reason!") it'll get short shrift and SNOW opposed by the community.
The only issue I have with that is theoretical. Ostensibly, the petition is supposed to create a turnstile sparing an Admin from having to go through the back-and-forth of an entire RfA unless there's some minimum support for that. In other words, ideally, the Admin simply ignores the petition until or if the threshold is met. Only then do they need to ramp up to start compiling, potentially, years of diffs, etc. to defend themselves at RfA. Going straight to RfA means any single, aggrieved editor can encumber an Admin with the significant angst of a full RfA. Of course, that's all theoretical. As we've seen from the current example, the mere act of petitioning creates the angst it was designed to mitigate. So, if we're going to introduce a Reign of Terror anyway, we may as well make it the most efficient Reign of Terror we can come up with, on which basis I'd support this suggestion. Chetsford (talk) 17:01, 28 October 2024 (UTC)[reply]
The other option would be to make it so that the petition doesn't turn into a Reign of Terror to begin with. Which is easier said than done, but a good first step would be to limit back-and-forth conversation and just have it be, well, a petition. Chaotic Enby (talk · contribs) 17:05, 28 October 2024 (UTC)[reply]
I do have a few concerns on that. In this situation the Admin is being recalled for reasons no one is allowed to articulate to them, but maybe they'll learn them during sentencing (RfA)? I liked The Trial as much as anyone, but I'm not sure how I feel about recreating it IRL. But I'm open to whatever. Chetsford (talk) 17:13, 28 October 2024 (UTC)[reply]
No it wouldn't prevent reasons being given, it would just restrict discussion of those reasons. So everybody supporting or opposing the petition would be able to (arguably should be required to) give a single short statement (50 words or 2 sentences have been suggested) about why they are supporting/opposing. However there would be no discussion unless and until an RRFA was opened. There would be no restriction on clarification being sought on user talk pages, e.g. if user:Example wrote "Support because of their actions at the recent AfD" anyone would be allowed to go to user talk:Example and ask which AfD(s) they were referring to if it wasn't clear. Thryduulf (talk) 17:20, 28 October 2024 (UTC)[reply]
I would say no. If the petition can get 25 people to agree (despite all the issues of the discussion section), then the RFA should run. Y'all are Streisanding the current petition and bringing people in. If it was as sterile and clinical as the process laid out was supposed to be, it would more than likely died in a month. spryde | talk 20:52, 28 October 2024 (UTC)[reply]
I think any petition is going to get significant amounts of attention, maybe not quite this much if they become routine, but certainly enough that it's never going to be "sterile and clinical" under the current setup. Thryduulf (talk) 21:14, 28 October 2024 (UTC)[reply]
If the time is reduced to a week, then the number of signatures needed should be reduced. I also don't understand the point of opposition statements. If it is a petition, then there should just be people signing it, maybe proposing changes to the petition statement. It seemed like a lot of the opposition was based on people not likely the process. There is already a problem with accountability for admins in Wikipedia, because admins are not only well known, but have power to block people, and probably have more knowledge of how Wikipedia works than the poor editors who try to recall them. Admins are pretty safe. Term limits would have been a better solution, as well as temporary blocks for admins. Tinynanorobots (talk) 11:35, 29 October 2024 (UTC)[reply]
For now, we have a sample set of one incomplete case. Ten editors have signed the petition in the first 40 hours. A linear projection would predict that 25 signatures would be reached in less than five days. Some commenters have assumed that the level of opposition expressed to this petition indicates that Graham87 would retain the admin bit in an RRFA. If a case that appears this weak does reach 25 signatures in less than a week, why should we have to wait a month for cases where there is less enthusiasm for signing a petition. I will note that the rate of new signatures likely will decline, prolonging the end, and that some commenters are claiming that many potential signers will wait to the last minute to sign to avoid social pressure, but that is not an argument for waiting a month, as they can sign the petition at the last minute whether the duration is for a week, two weeks, or a month. But, as I said, this is the first case, and my crystal ball is very murky. Donald Albury 13:39, 29 October 2024 (UTC)[reply]
I think that that first recall petition showed some of the warts of the process in a really stark way. Floating 4 significant changes for the community to think about here, either separately or in combination:
1) - The petition process is too long. If these are going to turn into mini-RfAs, then the petition needs to be significantly shorter than a RFA. 24-72 hours is plenty of time to see whether the petition has legs, anything more is cruel.
2) - The petition is too easy to initiate. I know that people will complain about cabals, but I really think it should take an admin to initiate one of these. Alternatively a small group (3 ish) of extended confirmed users works.
3) - We should move from number of supports to number of net supports. If a petition has 1 net support at closing time, it can go through as prima facie evidence that the petition has legs. If the ratio of opposes to supports gets over 2-3 to 1, we can close early without losing many petitions that would wind up successful.
4) - The commentary is too much. Restrict people, both support and oppose, to something very short, like 10 words and 1 link.
Obviously this is idea lab, so please discuss which of these have merit fluidly either alone or in any combination. tweak numbers, break things. Tazerdadog (talk) 17:07, 28 October 2024 (UTC)[reply]
I'd agree with shortening the petition process (although 72 hours might be too drastic), but I think turning them into mini-RfAs is not the goal. The point of the petition is to see if there is a substantial number of editors wanting a recall election to begin with, not to replace the recall election entirely. And, if you need to get 3 people on board to start the petition, you're functionally making a petition for the petition.For the same reason, net supports shouldn't really be what is measured (as it isn't about whether the admin has majority support, but only about whether some people are questioning it). A large oppose ratio, however, would indicate the petition will likely not be successful, so the early close you suggest could work. Also agree with your idea of restricting commentary, as said above. Chaotic Enby (talk · contribs) 17:11, 28 October 2024 (UTC)[reply]
The old RFC/U process required two editors to sign within 48 hours, or the page would get deleted. These two editors had to show evidence(!) of having attempted to resolve the same(!) dispute with the targeted editor. This was fairly effective at preventing RFC/Us over disputes that just needed a Wikipedia:Third opinion. WhatamIdoing (talk) 18:43, 29 October 2024 (UTC)[reply]
That could work, in a way. Every editor can start a petition, but two editors have to sign within 48 hours or it gets closed without further ado. Chaotic Enby (talk · contribs) 18:50, 29 October 2024 (UTC)[reply]
It's impossible to constrain the discussion when the petition has started and for the petition page not to turn into a quasi-RfA. That's why the petition signatures and comments should be understood as RRfA !votes. The signatures would begin counting as !votes when 25 of them are collected, and prior to that, the signatures would be null !votes, and only valid as fulfilling a precondition to their collective validity as !votes. A signature is actually a latent 'oppose adminship' RRfA !vote. An "oppose petition" comment is actually a 'support adminship' RRfA !vote. At any point, if the admin does not like the protraction and feels secure about passing, the admin can cut the petition stage short and start the RRfA with their statement, answers and all, without a need to wait for signatories to reach 25. That imbues all signatures with the power of a !vote immediately, regardless of how many there are, whereas the "oppose petition" comments have had the power of a 'support adminship' !vote all along. If the admin doesn't feel secure, they can wait it out, and are protected by the fact that the opposition to their adminship is ineffective until it reaches the critical mass of 25 signatories. It isn't reasonable to think that the admin is unfairly treated by the fact that opposition to their adminship is rendered ineffective until a difficult procedural barrier is overcome; that's obviously a mechanism that protects their status. If they don't feel like they need that protection, if the climate seems friendly to their adminship, they can relinquish it and start the RRfA.—Alalch E. 17:32, 28 October 2024 (UTC)[reply]
I'm not sure we should understand them as quasi-votes, since it would be perfectly reasonable for someone to sign the petition because they think a re-RFA ought to be initiated, not because they think the admin should step down. That is, I can easily see someone putting their name on the petition because they believe a re-RFA is the right thing to do, not because they desire for the admin in question to be de-sysopped. But it's true that nothing is stopping an admin from "calling the bluff" and standing for re-RFA before the petition reaches 25 signatories. At this point, frankly, that doesn't look like it would be a bad move for our unfortunate first candidate. -- asilvering (talk) 19:27, 28 October 2024 (UTC)[reply]
The way the process is currently set up, you're right. But I would argue that it should be different (that's the idea I'm presenting): If you do not think that the admin should cease being admin, you should not sign the petition. On the material side, the petition should be presented as: "By signing you are stating that the administrator has lost your confidence"; and on the procedural side: "By signing you are stating that (because the administrator has lost your confidence and provided that he has also lost the confidence of many other editors) the administrator should undergo a RRfA". —Alalch E. 11:09, 29 October 2024 (UTC)[reply]
It isn't impossible to constrain discussion. We are capable of setting and enforcing a rule that says "Signatures only. No diffs, no explanations, no discussion, no opposes". This might be fairer, since even a few words or a single diff could prompt "me too" votes from people who had no concerns of their own, and a diff or a brief comment could be taken unfair or out of context. It would probably be stressful for the admin, as people would be publicly expressing dislike without any reason.
Editors generally oppose efforts to prevent them from talking about other editors, though, so I doubt we'll end up there. More realistically, we could insist that any discussion happen on the talk page. WhatamIdoing (talk) 20:00, 29 October 2024 (UTC)[reply]
ArbCom manages to have strict rules about constraining discussion, and it does lead to more productive cases (read: not a shiftest). I would support a "Signatures only" rule, especially considering the opening comment should already be expected to have the needed context.A talk page discussion would be already lower profile and likely more calm, and ultimately look less like a !vote or like its own mini-RfA. Chaotic Enby (talk · contribs) 20:21, 29 October 2024 (UTC)[reply]
Any rule restricting what can and can't be said on the page needs to come with explicit instructions to this on the page and a clear statement of who is allowed to remove things that objectively break the rules (I'd favour "anybody"). Perhaps accompanied with a "you will be partially blocked from this page if you reinsert, without explicit advanced consensus, something removed." Thryduulf (talk) 20:46, 29 October 2024 (UTC)[reply]
That could definitely work. WP:RECALL doesn't need a set of clerks like the (much more complex) ArbCom cases do, if the only rule is "just leave a signature" or close to that. Also agree with the disclaimer, and good of you to be thinking of the implementation details already!I'm thinking of having a formal proposal with both the restriction on discussion and the shortened timeframe as independent options. Given how the WP:RECALL RfCs have been criticized for not being well-advertised, it might be good to bring this one up on WP:CENT. Chaotic Enby (talk · contribs) 21:55, 29 October 2024 (UTC)[reply]
I think that's a good course of action. Aaron Liu (talk) 22:25, 29 October 2024 (UTC)[reply]
We can start workshopping the RfC right now, but it's probably best to hold off opening the RfC itself for the moment given how heated emotions are. Chaotic Enby (talk · contribs) 22:48, 29 October 2024 (UTC)[reply]
Discussion will migrate elsewhere. ArbCom is mentioned as a counterexample, but discussion there is quite free-flowing, only formatted differently to avoid long non-constructive threads... but the stated problem here is not non-constructive threads, the stated problem is comments. That is completely different. "Discuss calmly and with measure" and "don't talk" is different. It will be possible to have an adjacent discussion on some other page or pages. And if you are blocked from the page, so what, what you added to the page, diffs and all, stays in history and can be viewed by anyone. —Alalch E. 23:36, 29 October 2024 (UTC)[reply]
And if you are blocked from the page, so what, what you added to the page, diffs and all, stays in history and can be viewed by anyone.
Nobody inspects every nook and cranny in history for bad things people have said to agree with it. Aaron Liu (talk) 01:29, 30 October 2024 (UTC)[reply]
I agree that a complete ban on discussion will result in the discussion happening elsewhere, but that's not necessarily a bad thing. Wherever there are humans, there will be gossip mongers, but gossip whispered between a few people (e.g., via Special:EmailUser) for a few days, or even for 30 days, is not as widely and as permanently destructive as accusations posted on the internet forever. WhatamIdoing (talk) 18:04, 30 October 2024 (UTC)[reply]
That elsewhere could just be the talk page, and it appears that it might just be that. Edit: All in all, "discussion elsewhere" + word limits + RfA monitor function preserved + "five uninvolved signatories first" latch mechanism could all add up to something good. I'm for trying. —Alalch E. 22:32, 30 October 2024 (UTC)[reply]
It all depends on who you want to sign up to a petition. If it is only "editors who have independently decided that an admin's conduct should be examined", the only way is to disallow comments from both signatories and opponents. Otherwise many signatories will sign because they are convinced by the arguments, even if they never heard of the admin before. In that case, allowing only signatories to comment will dramatically skew the results and be quite unfair. In summary, allow everyone to comment or allow nobody to comment. Zerotalk 02:10, 30 October 2024 (UTC)[reply]
Very good point, and why I would favor "allow nobody to comment" as a general rule. Chaotic Enby (talk · contribs) 02:22, 30 October 2024 (UTC)[reply]
I'd also like to raise another issue. We have created a risk-free way for editors to get back at an admin who has sanctioned them. I think that editors who have received a recent (definition?) personal sanction from an the admin should not be a signatory. Zerotalk 02:10, 30 October 2024 (UTC)[reply]
On the other hand, editors victims of administrator misconduct should definitely be able to support the administrator being brought to recall. Chaotic Enby (talk · contribs) 02:26, 30 October 2024 (UTC)[reply]
I can see both sides of this. Perhaps a reasonable way forwards is to disallow someone from initiating a petition if they have received a recent (within the last 3 months?) personal sanction from the admin. They can still support a petition initiated by someone else, but perhaps only if 5 uninvolved editors have already supported. If there is a genuine issue this should be an easy bar to clear but it would make retaliatory petitions much harder to initiate and harder for them to succeed. Thryduulf (talk) 02:35, 30 October 2024 (UTC)[reply]
Maybe we could make it so that the first five signatures (other than the initiator) must not have been involved with any dispute in which the admin concerned acted in their capacity as an administrator within the last (1? 2? 3?) months. If five uninvolved editors are prepared to sign a petition that suggests it's more likely to have some merit than if no such group of five are? Thryduulf (talk) 02:39, 30 October 2024 (UTC)[reply]
That makes sense. Zerotalk 02:42, 30 October 2024 (UTC)[reply]
Let's say it's day three and there are fifteen signatures. The first five signatories have not been involved in the discussed sense, followed by ten signatures from people who have been involved (they were the greater cohort that was waiting for the special signatures to add up so that they can add theirs; imagine ANI participants). One among the first five withdraws their signature ("I changed my mind after reading the talk page"). There are no longer five signatures from uninvolved signatories. What then? All's good? (Probably not.) Petition has failed? (Probably not.) Monitor halts signature collection only allowing signatures from uninvolved signatories, until one such additional signature is collected? (Probably not.) Monitor notes that the petition will be invalid unless at least one more special signature is supplied during the entire remaining period? (Maybe.) Monitor notes that the petition will be invalid unless at least one more special signature is supplied during a set period, for example three days? (Maybe.) —Alalch E. 17:00, 30 October 2024 (UTC)[reply]
I hadn't thought of that scenario. The simplest option would just be a latch - once five uninvolved people have signed the petition is unlocked and remains that way for the duration. Thryduulf (talk) 19:03, 30 October 2024 (UTC)[reply]
I agree. Anything more complicated would be too complicated. —Alalch E. 22:30, 30 October 2024 (UTC)[reply]
Workshopping the RfC
As the two main proposals that editors seem to converge on (limiting discussion and shortening the petition timeframe) are essentially independent, I'm thinking it can be best to go for a two-part RfC, with the following questions:
Should input to WP:RECALL petitions be limited to signatures only?
Should the petition duration be limited to X amount of days?
There is also the possibility of having multiple options for each question. For the first one, an alternate proposal of limiting input to to a short statement per person was also suggested, while multiple timeframes for the petition could also be proposed. Chaotic Enby (talk · contribs) 22:59, 29 October 2024 (UTC)[reply]
I think a RFC like this needs to happen. I think the second bullet point is fairly self-explanatory, but the first needs more thought. On a recall petition, is there value in having a statement from the initiator? A statement from the admin being recalled? Statements from people bringing up new evidence? Statements/signatures from supporters? Which belong on the main page, and which belong on the talk page? If we impose a length limit, can anyone truncate statements to fit in it? Do we need clerks, arb style?
For example, I favor the initiator getting a short statement, the admin having unlimited length to respond optionally (hidden comment in the template that makes a section if they choose to respond), all recallers signature only on the main page, with limited commentary on the talk page, and any list of supporters with limited commentary on the talk page, no threaded discussion anywhere. Any editor except the initiator and the admin being recalled can move comments to enforce length/threading/talk page. This is not about my preference, but more saying that this bullet point can get really complex really fast, and we should think about that now in workshopping. Tazerdadog (talk) 02:04, 30 October 2024 (UTC)[reply]
Thanks a lot for the feedback! You're right that the first bullet point should definitely be clarified before the actual RfC.In my mind, the initiator would be able to make a short statement, with the rest being only signatures (as the point of the petition isn't to be its own RRfA, but only to gauge whether it has enough support). Regarding the admin responding, I think it (and other replies) should be reserved to the talk page, to avoid it becoming a RfA-lite where the admin has to respond to the claims to not be seen as suspicious. Chaotic Enby (talk · contribs) 02:20, 30 October 2024 (UTC)[reply]
If the admin is allowed a right of reply, but only on the talk page, it should be possible to see from just the main page whether they have chosen to respond or not. Regardless of where, everybody who has the right to comment (including the responding admin) should be subject to a word limit, although not necessarily the same limit. Thryduulf (talk) 02:30, 30 October 2024 (UTC)[reply]
In my mind, the initiator is no more or less important than anyone else who prefers to recall that admin, I prefer not creating a "first mover" advantage. So I'd rather just be strictly signatures only, or strictly "Short statement on main page without replies" for everyone.
The talk page will be open anyway, so people who want to elaborate on why can do it as they prefer Soni (talk) 05:14, 30 October 2024 (UTC)[reply]
I can get behind a word limit for the responding admin. I do think it's important that the admin have the ability to present their case in the same location that the initiator does. Tazerdadog (talk) 06:55, 30 October 2024 (UTC)[reply]
I agree with that as well, I just end up at "Initiator and all future signatures should be given same weightage" and "Maybe both should be on talk" as my preferences. Soni (talk) 05:20, 30 October 2024 (UTC)[reply]
I start with "someone should say why we're all here" and "I don't want everyone piling on with extensive commentary. I will concede that I create a first mover advantage as a consequence of those, but I think that's the best we can do. Either way, I think we can craft a RFC that presents all this fairly without too much difficulty. Tazerdadog (talk) 06:52, 30 October 2024 (UTC)[reply]
Ultimately, a "first mover" advantage makes sense in that, since they're starting the petition, they are responsible for explaining it. We don't need 25 redundant explanations, but we don't need an unexplained petition either, so it is logical that the creator of the petition be the one to state the case for it. Chaotic Enby (talk · contribs) 08:10, 30 October 2024 (UTC)[reply]
"The talk page will be open anyway", will that result in all the "pre-RRFA RRFA" stuff just happening there instead of on the petition itself? Anomie⚔ 07:49, 30 October 2024 (UTC)[reply]
Moving the discussion to a less prominent place behind the petition, plus a word limit as Thryduulf suggested, would definitely limit the "pre-RRFA RFA" stuff. Not everyone will go through long talk pages, making it less critical to respond than with the "in-your-face" discussion that currently runs in the middle of the signatures. Chaotic Enby (talk · contribs) 08:07, 30 October 2024 (UTC)[reply]
Will this: Any ... comment may be struck based on the same criteria used during requests for adminship (from WP:RECALL) hold true on the talk page? —Alalch E. 16:33, 30 October 2024 (UTC)[reply]
I think that is something that will need to actively decided. Thryduulf (talk) 16:45, 30 October 2024 (UTC)[reply]
If it's mandated that no discussion happen on the petition page, I'm not so sure the petition's talk page would remain very much "less prominent". Sure, not everyone will bother to check the talk page, but knowing that's where discussion is I suspect anyone who would have pre-RRFA RFFA-ed as things are now would. Anomie⚔ 07:51, 31 October 2024 (UTC)[reply]
I don't think it's a good idea to start a two-part RFC so soon after we just ended a three-part RFC. Take note of the backlash to the third RFC; a fourth RFC will get even more backlash; a fifth even more. Levivich (talk) 16:45, 30 October 2024 (UTC)[reply]
By two-part, I mean asking two questions simultaneously, not running one RfC and then another. The second RfC had more then ten simultaneous questions, so two should be manageable. Chaotic Enby (talk · contribs) 17:28, 30 October 2024 (UTC)[reply]
But you really think, three days into the first petition, you've learned enough about this process to know how to change it for the better? There's no part of you that's thinking "it's too soon to draw any conclusions"? Levivich (talk) 17:33, 30 October 2024 (UTC)[reply]
I share Levivich's concerns here. Now's a fine time to take some notes, but we're 10% of the way through the first use of a process. We might learn something in the coming days, or in a second petition. We might also discover that the RFC question needs to be "Well, that was a disaster. All in favor of canning the idea completely?" WhatamIdoing (talk) 18:12, 30 October 2024 (UTC)[reply]
And this is why I said, above, We can start workshopping the RfC right now, but it's probably best to hold off opening the RfC itself for the moment given how heated emotions are. I do not claim to personally know exactly how to change the process, but we can already start discussing the shortcomings we can see, even if we are not going to open the RfC right now. Chaotic Enby (talk · contribs) 18:21, 30 October 2024 (UTC)[reply]
People have been proposing changes all over the place. Why not have a discussion that will hopefully bring up possible problems with proposed changes, even if it will be a while before any RfC should start? Donald Albury 19:42, 30 October 2024 (UTC)[reply]
@Chaotic Enby: I've been thinking about how to format this RfC for a fair while. If someone has a better idea than yet another dedicated subpage, I'm all ears, because I'm not sure how else to deal with the number of proposals and changes people are asking for. theleekycauldron (talk • she/her) 18:44, 31 October 2024 (UTC)[reply]
I think subpages is fine, but we probably should try to limit the number of options to be voted on, in some way. Either by number or some other ways.
Say if a proposal is something like "For 2 future RECALL petition, the petition will not have any discussion. After this trial, you need consensus to make it permanent" - that's self contained and gives place to start off from. Much better than just trying to push through every change at once. Soni (talk) 20:56, 31 October 2024 (UTC)[reply]
That's the point of starting this discussion now. We're at the ideas stage, at some point after the first petition ends (and, if one happens, after the subsequent RRFA ends) this will move into the stage of collating those ideas that both could work and got some indication they might be supported and refining them into draft proposals. Once we have a rough idea of what and how many proposals there are is the time to work out the best structure for an RFC, as until we know those things we can't know what will and won't work. Thryduulf (talk) 00:39, 1 November 2024 (UTC)[reply]
Wikipedia:Administrator recall has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. CNC (talk) 21:59, 1 November 2024 (UTC)[reply]
Wikipedia:Administrator recall has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. Chaotic Enby (talk · contribs) 15:58, 3 November 2024 (UTC)[reply]
The first notification is for shortening the period and the second one is for limiting comments to just signatures. Aaron Liu (talk) 16:03, 3 November 2024 (UTC)[reply]
Have modified title of first notification to make more sense. CNC (talk) 16:38, 3 November 2024 (UTC)[reply]
Allow IP editors to set preferences
IP editors now have the ability to turn on dark mode, which previously was limited to logged in users setting a preference. We should extend this concept to allow IP editors to set other prefernces such as disabling fundraising banners or whatever other preference they prefer. RudolfRed (talk) 23:33, 1 November 2024 (UTC)[reply]
I believe that would require changes to the software. Thryduulf (talk) 00:46, 2 November 2024 (UTC)[reply]
I mean, temporary accounts are already on. I doubt that the WMF isn't already planning this. Aaron Liu (talk) 00:49, 2 November 2024 (UTC)[reply]
Supporting preferences in general would mean the caching infrastructure could no longer be used for non-logged in users, which would have a big impact on the amount of computing resources required to handle Wikipedia's traffic. So I don't believe that general support is in the works. isaacl (talk) 05:40, 2 November 2024 (UTC)[reply]
They could 1. restrict preferences to a subset that won't interfere with caching; or 2. figure out a way to serve cache to everyone who didn't touch certain preferences. Aaron Liu (talk) 18:28, 2 November 2024 (UTC)[reply]
I've discussed this before so don't really want to get into the details again, beyond saying that making the servers do anything is more expensive than reading ready-to-go HTML content and sending it back. Please feel free to discuss your ideas with the WMF engineering team. isaacl (talk) 21:33, 2 November 2024 (UTC)[reply]
There was some talk in 2023 about a limited set of prefs. mw:Temporary accounts are only created upon editing, not ordinary readers. I can't remember whether they settled on creating the account at the time you open the page to edit, or if it's created only when you click the big blue Publish button, but we should expect only a few logged-out users to gain access that way. However, that requires getting temp accounts fully deployed everywhere, which will happen eventually rather than soon. (Fundraising banners can already be suppressed [for a week at a time?] via cookie; just click the button to make it go away.)
As for the desirability: You should believe Isaacl when he says that this is a lot more expensive and difficult than people think it 'should' be. WhatamIdoing (talk) 01:14, 6 November 2024 (UTC)[reply]
I don't see the slightest problem in restricting privileges like preferences to logged-in editors. If the default editing experience for IPs can be improved, that's fine, but if someone wants an experience different from the default, they already have a very simple way to get it. Zerotalk 02:40, 6 November 2024 (UTC)[reply]
Comparison shopping with data from factboxes
As more information is put in Wikidata and is presented in Wikipedia's fact boxes, I think this opens a possible new feature or gadget similar to the comparison shopping offered by many e-commerce websites. As I visit the article Thailand, the factbox should have a little tick box to add this article to my personal comparison basket, and when I tick that box on another comparable object (using the same factbox template), say Chile, I should be able to view my current comparson set, presenting a table with two columns for Thailand and Chile, and rows for their attributes: capital city, main language, population, area, GDP, etc. LA2 (talk) 11:45, 2 November 2024 (UTC)[reply]
LA2, this doesn't sound like it would be possible to implement entirely in client-side scripting, and would require dev involvement. Software changes like this can be suggested at the global Community Wishlist. Folly Mox (talk) 12:06, 7 November 2024 (UTC)[reply]
Idea to reduce issue with user pages being used for hosting a vanity page or advertisement
Some of the recent discussion on AN/I regarding Fastily and U5 closures centered on the challenges of properly addressing misuse of user pages. I believe the high volume of apparent misuse is causing difficulty in balancing protecting Wikipedia and taking due care in deletions. Anything that would reduce misuse (or reduce the consequences of misuse) should help relieve some of the pressure.
Thus my half-baked proposal below. The goal of this proposal is to reduce the attractiveness of putting up fake Wikipedia pages and holding yourself out to the world as having a page about you.
Proposal
The primary user page will automatically have the output of {{User page}} displayed at the top. Once a user becomes extended confirmed, they will have the ability to suppress display of the template. Extended confirmed users who abuse this by making an inappropriate user page can have the right to suppress display taken away by an admin. When first enacting this change, all current extended confirmed users will have the display suppressed, though they can enable the display if desired.
This is a Wikipediauser page. This is not an encyclopedia article or the talk page for an encyclopedia article. If you find this page on any site other than Wikipedia, you are viewing a mirror site. Be aware that the page may be outdated and that the user whom this page is about may have no personal affiliation with any site other than Wikipedia. The original page is located at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(all).
Above is the output of the template, for those unfamiliar with it.
Thoughts? — rsjaffe🗣️ 19:59, 5 November 2024 (UTC)[reply]
That could be a good idea. For new users who might not know it, a message could also be added to inform them that drafts should ideally not be written on their main userpage, with a link to automatically move it to their user sandbox. Chaotic Enby (talk · contribs) 20:16, 5 November 2024 (UTC)[reply]
I don't have any objection to this in principle. I think the application of this is likely to get pretty hairy, though. And I think most people write promo drafts on their userpage because they don't know they're promo and don't know that's not the place for drafts - so I don't think this would really help. But if I woke up tomorrow and this was the status quo, I wouldn't be mad about it or anything. -- asilvering (talk) 20:35, 5 November 2024 (UTC)[reply]
After giving it more thought, one objection I can see is that enforcing a banner on people's userpages might not be well-received, especially since the target demographic (non-ECP editors) likely won't overlap much with the people who will take the decision. I agree with your explanation for why people write promo drafts on their userpage, and a way to gently inform them that that isn't the place might be better.Now that I think about it, we need an equivalent of U5 that isn't "speedy deletion" but "speedy move to sandbox" (with a message informing the user of what happened, of course). Now that would be helpful. Chaotic Enby (talk · contribs) 20:40, 5 November 2024 (UTC)[reply]
It's just "move to draft". I have no idea why more CSD taggers don't use it. -- asilvering (talk) 20:41, 5 November 2024 (UTC)[reply]
I don't think we give clear enough guidance on what the taggers can/can't do. — rsjaffe🗣️ 22:24, 5 November 2024 (UTC)[reply]
The main issues with user pages seem to be promotional drafts and non-Wikipedia uses (like fake election articles for alternate history forums). It's non merely an enwiki issue - while userspace pages aren't prominently visible, images uploaded for them are. It's a big problem for Commons to have spam and hoaxes mixed in with other images. I'm not sure there's actually a common problem with userspace pages being passed off as real articles; I don't object to this proposal, but I think other changes might be more effective. In particular, I would propose stricter rules and other changes for userspace, with the primary aim of reducing incorrect userspace usage to reduce admin work:
Edit filters disallowing commonly misused elements like external links, images, and infoboxes for new users in userspace. This would essentially kill userspace for fake articles and make promotional userpages less attractive. Maybe even have a fairly strict character limit for new users - that would allow them to have a bluelinked user page introducing themselves, but not enough space for their CV or fake article.
Prominent edit notices for userspace explaining restrictions and directing users to draftspace
Disable the "upload file" link in userspace. The vast, vast majority of crosswiki uploads from userspace are junk.
Better bot patrolling of userspace. This could include creating lists of new userspace pages for easier patrolling, or even automatic moves of likely drafts to draftspace.
Partial blocks from userspace for those who misuse it. This should be more akin in seriousness to an edit filter than a mainspace block.
Formally expand U5 to include any clearly non-Wikipedia usage, regardless of whether the user has mainspace edits, after other interventions reduce userspace usage overall. Obvious junk shouldn't have to go to MfD just because the creator has mainspace edits.
As to passing off user pages as Wikipedia articles, I have encountered it once in real life, and everyone in that conversation was convinced it was real until I started reading the URL more carefully. Admittedly, this was a while ago, and perhaps people are more sophisticated now, but I suspect it is still a bit of an issue, and one that would be easily stomped out with this change. — rsjaffe🗣️ 22:21, 5 November 2024 (UTC)[reply]
@Rsjaffe if anything, people are less sophisticated about this now, since many mobile browsers try very hard to obscure URLs. -- asilvering (talk) 22:37, 5 November 2024 (UTC)[reply]
I do agree that there's lots more things that should/could be done and appreciate your list. Perhaps the discussants here could put together a package of changes to improve the situation, though approval of each one would be independent, as some items in the package may be more of an issue than others. — rsjaffe🗣️ 22:23, 5 November 2024 (UTC)[reply]
I particularly like the edit filter preventing links idea. A plaintext page without through links is (generally) essentially harmless. I don't like the idea of a character limit unless it could be just applied to the top-level user page, rather than subpages which can legitimately be used for draft development. Espresso Addict (talk) 06:35, 6 November 2024 (UTC)[reply]
This is mostly in response to the first point. When creating a new article in mainspace, the little popup on the side always invites me to create the article in my userspace instead. Help:Your first article#Where to start writing also recommends placing drafts in a user subpage. I could very easily see a new editor not understanding the difference between their main userpage and a user subpage. If we block things such as infoboxes, external links, or set word limits, we will be sending a very mixed message to new users. Maybe an edit filter to block new editors from adding external links to commercial/social media sites? (LinkedIn, YouTube, blogspot, what have you). There's very valid reasons why we don't block these types of links in general, but if we're thinking about userspace spam from non-contributors, then maybe? Lots of good faith users do end up adding links to these sorts of websites, but I also think discouraging them from doing that until they've been around long enough to learn the intricacies of WP:SPS isn't a bad idea. I don't really know edit filters, however, so I have no idea how practical this would be. I also don't have enough data to throw myself behind this suggestion just yet.
Not a fan of expanding u5. But maybe, for abandoned SPAs with a spammy vibe, a process similar to PROD? A user tags something as obviously unencyclopedic, and the creator has a month or so to return to their account and contest it, or else an admin reads the userpage, confirms it's never likely to be useful, and either a)declines the tag (so it can never be tagged again) or b) bins it on the understanding that should the creator return, they can request undeletion. MfD doesn't get clogged up with long-abandoned quasi-spam, and it limits the risk of biting newer contributors since it wouldn't work on them. This won't do anything for active spam-like users, but neither does U5, seeing as they can just re-create the page as many times as they'd like before getting inevitably blocked. (And then we go back to userspace prod). There's probably flaws with this idea. I could absolutely see somebody trying to abuse it in the way U5 is abused. The most obvious way is if two editors get into a dispute, one of them is blocked, and the other tries to delete their userspace now that their "enemy" is gone. I like to think that would be noticeable, however. Also, admins would still be required, and thus required to read the pages before deleting them. If the admin fails to do so, that would be very bad.
I like the idea of removing the "upload file" link in userspace. I also think we should remove it in draftspace. I also think we should make the "upload to commons!" link less prominent. A few gours ago, I nearly accidentally uploaded a non-free book file to commons; it was only once I got to the second page when I realised I'd mistakenly clicked the giant blue box as opposed to the tiny grey one. If I'm doing that, then goodness knows what a new user who doesn't understand the difference between their own work and a screenshot is thinking. (And that's just talking about good-faith newbies who are still hunting for clues. Commons does not need anymore copyvio spam than it already puts up with.) This also would not stop users from adding images to their userspace. They would still have other ways. It would merely slow them down, force them to ask questions, and hopefully learn about copyright. GreenLipstickLesbian (talk) 09:46, 7 November 2024 (UTC)[reply]
This isn't a good template for this use. The header is harmless, but of the main text only the first sentence (to the effect of "this is not an encyclopedia article") is relevant. That sentence is needed, though, as well as a statement that this page hasn't been reviewed or quality-checked (even to the extent that normal Wikipedia articles are).Also, we don't need the option to let the page owner turn it off for everybody else, just a handy gadget to hide it for logged-in users who don't know to edit their own css. Without that, we could do this right now without the proposed software changes, which probably would never happen anyway. —Cryptic 22:29, 5 November 2024 (UTC)[reply]
Oh, and I see no reason at all to limit it to the primary user page. I don't think I've seen anybody passing off a main user page in their "now read our article on Wikipedia!" link, but have to sandboxes and other subpages a couple times. —Cryptic 22:34, 5 November 2024 (UTC)[reply]
Is there any way to get the software to display the namespace in User: and User talk: the way it shows up for every other namespace? Seems like that would be a step towards the goal here. Folly Mox (talk) 00:49, 6 November 2024 (UTC)[reply]
It already does that? WhatamIdoing (talk) 01:17, 6 November 2024 (UTC)[reply]
Thanks, @WhatamIdoing, I thought I was the crazy one. -- asilvering (talk) 01:18, 6 November 2024 (UTC)[reply]
The theme Minerva does not appear to me to show the User: prefix, but does seem to for most namespaces <https://en.wikipedia.org/wiki/User:Example?useskin=minerva>. Skynxnex (talk) 02:23, 6 November 2024 (UTC)[reply]
And Folly Mox is on the mobile site. @SGrabarczuk (WMF), could you please talk to the Web team about this? User pages ought to say that they're User: pages, even if someone would like to hide that fact. WhatamIdoing (talk) 03:33, 6 November 2024 (UTC)[reply]
Whoops I didn't think to check in other skins. Apologies for the confusion. Folly Mox (talk) 14:05, 6 November 2024 (UTC)[reply]
This problem is especially bad on mobile since, as asilvering points out, mobile browsers hide URLs. McYeee (talk) 07:06, 7 November 2024 (UTC)[reply]
What is the onboarding (or whatever it's called) doing in the way of suggesting very new editors start user pages by the way? I did wonder if we were inadvertently inviting users to make a profile in their first or second edit, and then immediately deleting it U5 with unfriendly messages. Espresso Addict (talk) 06:59, 6 November 2024 (UTC)[reply]
Unless things have changed in the twelve months since I tested the new user signup flow, accounts are presented with a couple messages about Suggested Edits, then land at Special:Homepage. I don't remember there being (and definitely didn't screencap) anything related to creating a userpage. Folly Mox (talk) 11:19, 7 November 2024 (UTC)[reply]
It is, however, a pretty normal impulse to have, creating a userpage. Social media and various apps outright make you do it before being able to do anything else, and many newcomers will have been trained on that kind of behaviour. Also, if you're nervous, userspace edits feel safe, like you're not disturbing anybody while you're mucking around. -- asilvering (talk) 14:18, 7 November 2024 (UTC)[reply]
It's something that is encouraged in in-person training for new editors. A new editor with a userpage tends to be treated less harshly by some new page patrollers than one whose name is a redlink. Thryduulf (talk) 19:00, 7 November 2024 (UTC)[reply]
@Folly Mox, Asilvering, and Thryduulf: Thanks, Folly Mox. I think we need more advice on what the top-level user page may be used for, aimed both at new editors trying to create a profile and, perhaps more importantly, at patrollers. I've seen user pages that were entirely appropriate even for an editor with no other edits ("Hello world, my name is EA, I'm excited to edit Wikipedia!" sort of thing) being tagged G11/U5 by patrollers. (As far as I can tell, some patrollers think U5 is for anything created by a user with few non-userspace edits.) Asilvering writes, "if you're nervous, userspace edits feel safe", and I've found new patrollers think the same, it's a safe space to patrol without offending anyone who knows how to complain. And the flipside to Thrydulf's "A new editor with a userpage tends to be treated less harshly by some new page patrollers than one whose name is a redlink" is that patrollers are suspicious that a blue-linked user page is just the first step in a campaign of terror spam. Espresso Addict (talk) 23:09, 7 November 2024 (UTC)[reply]
Is there an editnotice for new users when they go to edit their userpage? I don't think there is. I don't see one when I try to edit mine, at any rate. -- asilvering (talk) 23:27, 7 November 2024 (UTC)[reply]
Welp. You can't fix that level of banner-blindness with anything. -- asilvering (talk) 00:46, 8 November 2024 (UTC)[reply]
I'm getting the impression that some don't speak English at all and have used AI to draft something. Certainly that's true of promotional autobios submitted to draftspace in perfect American Marketing Speak, where I sometimes find it is impossible to communicate with the creator because they don't speak plain-old (British) English (and I don't speak their language). Espresso Addict (talk) 02:14, 8 November 2024 (UTC)[reply]
Wouldn't adding {{Userspace draft}} to the userpage fix the issue? Nobody (talk) 10:44, 6 November 2024 (UTC)[reply]
Researcher group
Okay, so this is a very barebones proposal at the moment, and I'm looking for thoughts into it, especially about viability and how likely this would be to gather consensus. This seems like the right place. Essentially, the idea I'd like to develop is allowing requests for the researcher group. At Special:ListGroupRights, it has the three rights commonly referred to as viewdeleted, as well as apihighlimits. This was discussed a bit at Wikipedia_talk:Requests_for_adminship/Archive_269#Temperature_check:_Applying_for_the_Researcher_right. Essentially, this would add a third section to WP:RFA, perhaps called Requests for Researcher, and would follow the same general process as an RFA, compliant with the WMF's requirements for viewdeleted access. Unlike other unbundling proposals, this includes only viewing rights, and while it would probably be a fairly rare ask, it would avoid many of the issues that plague other unbundling proposals, since it does not necessary unbundle actions, just viewing permissions, meaning it doesn't touch the block/delete/protect triad of rights that will likely never be unbundled. EggRoll97(talk) 00:09, 6 November 2024 (UTC)[reply]
The WP:RESEARCHER right, since its inception, has required approval from the WMF (specifically from the Legal department, if memory serves). I suspect, but don't know for sure, that this approval requires signing contracts about protecting privacy, etc. It sounds like your plan is to make this userright available to more people, with fewer controls. Is that your goal? WhatamIdoing (talk) 03:36, 6 November 2024 (UTC)[reply]
@WhatamIdoing: Based on the general response from the WMF, we (the community) are allowed to use it as a normal usergroup, if we wish, based on Joe Sutherland's response of Generally you all can do as you want with the Researcher right, though of course Legal will require that anyone who receives it still pass some form of RfA-like process. It historically was only given to those who signed NDAs with the WMF, but as of now is unused and the WMF has indicated they are fine with us using it. I would say the controls would actually be greater, since it would require anyone seeking it request community approval. EggRoll97(talk) 06:05, 6 November 2024 (UTC)[reply]
What sort of editors are you thinking might wish to get this right, EggRoll97? Espresso Addict (talk) 06:38, 6 November 2024 (UTC)[reply]
I imagine the usecase would probably depend, and might need to be somewhat flexible (similar to how those who make a request for adminship generally have areas they're requesting the tools for), though it should serve to provide some benefit to others. I imagine good use cases might include those who work with LTAs, SPI, edit filters, or other areas where the ability to view deleted contributions would enable them to make a better contribution to the project and where a good case can be made that they are handicapped by its absence, using the wording that ArbCom in 2008 used about viewdeleted. Overall though, I'd think it would be very much still up to the community at large to determine "is this a good use-case, or is there no reason to actually grant this?". EggRoll97(talk) 06:56, 6 November 2024 (UTC)[reply]
Right now, the process is closer to provide your real name, sign a legally binding contract, and have a good reason, probably involving paperwork showing approval from your Institutional review board.
I'm not sure your use cases are realistic. People working with LTAs need a block button. SPI needs more CheckUsers. The edit filter managers have to be admins. WhatamIdoing (talk) 07:18, 6 November 2024 (UTC)[reply]
I agree with WhatamIdoing that those people with a genuine need to view deleted material are usually admin or admin+ already. There's some scope for research on what WP deletes, which I suppose is why it has been referred to as "researcher", but that's not really benefiting the community directly. Espresso Addict (talk) 07:59, 6 November 2024 (UTC)[reply]
@WhatamIdoing Edit filter managers don't need to be administrators, see WP:EFM. Thryduulf (talk) 08:33, 6 November 2024 (UTC)[reply]
You're right. I should have looked it up instead of relying on memory. Thank you. WhatamIdoing (talk) 16:26, 6 November 2024 (UTC)[reply]
I agree this would be very useful for non-admin EFMs. I asked xaosflux about this once upon a time - he raised some pitfalls at the time. My feeling is that the use case is too niche for most to feel it's worth the community time needed to develop a process around this, when probably less than 10 people will ever hold this right. ProcrastinatingReader (talk) 18:43, 6 November 2024 (UTC)[reply]
I wonder if, similar to how the import right was assigned without necessarily having a dedicated process behind it, it might be easier and less of a burden on community time to simply have individual requests at WP:VPP for the researcher right if it's that niche of a usecase. The usecase you describe was actually part of my motivation for making this. EggRoll97(talk) 21:42, 6 November 2024 (UTC)[reply]
As just a bit of an addendum to the previous comment, I checked the listing of all EFMs and checked through which ones are non-admins. We have a total of 15 non-admin accounts that have EFM. Of those, 8 were granted the right by a consensus discussion, 5 were self-granted as the user was formerly an administrator, 1 is a bot (so technically 14 human EFMs), and 1 was granted the right for bug checking(?) with a user talk page discussion. I imagine your estimate is quite right, in that case, since the 5 who self-granted as admins I believe can simply ask for their admin rights back at WP:BN if they need viewdeleted. The bot obviously doesn't need it, so that leaves 9, at least for that particular usecase. EggRoll97(talk) 21:55, 6 November 2024 (UTC)[reply]
Short note on this: I don't think we should not use that group for anything from the community and once no longer required it should be removed. We could make a process for a community-managed group that allows viewing non-suppressed deleted content, however the approval process will need to be "rfa like" to meet foundation requirements. It would need not be strenuous and should be able to get by so long as it: accepts both support and opposition feedback from the community, be able to measure that appropriate support exists, be well-advertised, and be well-attended. — xaosfluxTalk 18:59, 6 November 2024 (UTC)[reply]
Example is our RFA system, which we could even use the existing system with an option that someone is only running for "view deleted admin". If it ran for at least a week, had at least 25 attendees, and had good consensus (i.e. ~2/3 support) think that would more than suffice. Could be assignable by 'crats. — xaosfluxTalk 18:59, 6 November 2024 (UTC)[reply]
So if I follow you correctly, the ideal path would probably involve creating a separate group with the permissions duplicated, and some form of "request for view deleted" being added to WP:RFA? EggRoll97(talk) 21:42, 6 November 2024 (UTC)[reply]
Duplicated? No, for example apihighlimits isn't likely required at all here. — xaosfluxTalk 10:17, 7 November 2024 (UTC)[reply]
Creating "Machine Wikipedia" as an edition of Wikipedia
Hi, according to Tim Berners Lee's proposal, that is "Web 3.0" or semantic web, we should make our existing web machine-readable. But current editions of Wikipedia (English, French, etc.) are not machine-readable. Even though "Wikidata" provides some "structured machine-readable data", it does not implement Web 3.0, because Wikidata only provides structured data for one concept and the article may contain many concepts that are not included in its Wikidata item.
So I propose to create "Machine Wikipedia" like other editions of Wikipedia (such as English) which is written in the "machine language", e.g. triples of RDF (Resource Description Framework). This way, Chat-bots and other machines can access required information more accurately and more conveniently. This new edition of Wikipedia (Machine Wikipedia) can be filled with RDFs, both by humans and by artificial intelligence using natural language processing (NLP). Thanks. Hooman Mallahzadeh (talk) 10:08, 7 November 2024 (UTC)[reply]
Sigh. Since I'm genuinely not sure whether you're aware, I'm going to head off with the obligatory remark that a sizable plurality of editors are either highly skeptical of or firmly oppose operation of the Chat-bots and artificial intelligence using natural language processing (NLP) you see as the primary benefactors of this proposal—either as they presently exist, or in principle. That is to say, I would not get invested in this proposal, as the benefits you envision are already seen instead as clearly negative outcomes by much of the community.
I'll give fair warning that I am not really volunteering to have you pitch me on why these things are actually good, but I just don't want you to get your hopes up. Remsense ‥ 论 11:00, 7 November 2024 (UTC)[reply]
Hooman Mallahzadeh, this project is already underway. See m:Abstract Wikipedia. Folly Mox (talk) 11:08, 7 November 2024 (UTC)[reply]
@Folly Mox I propose to change the project name from "Abstract Wikipedia" to "Machine Wikipedia" to match Tim Berners-Lee's vocabulary, and finally add it an interWiki like other editions of Wikipedia. We can call the goal article "Machine article".
I should note that extraction RDFs from an article by humans needs some expertise, i.e. this is an encoding process, but the product of this extraction process is very simple, it contains many lines of RDF triples, and we call that "Machine article".
I really think that "Machine Wikipedia" project can be made very fast, and the delay that "Abstract Wikipedia" project had made is unreasonable. Hooman Mallahzadeh (talk) 11:35, 7 November 2024 (UTC)[reply]
Ok, it sounds like you know quite a bit about machine learning. But, kindly, this has no relation to English Wikipedia. m:Talk:Abstract Wikipedia has 236 watchlisters, and the project has a public mailing list, if you want to get in touch about your ideas with the team involved. Folly Mox (talk) 12:01, 7 November 2024 (UTC)[reply]
Is there a script or gadget that adds "[Thank]" before "[Reply]"? After is fine too, but I think before might be better.
If not, is someone willing/able to make one? It would make thanking easier, I think. Gråbergs Gråa Sång (talk) 14:12, 7 November 2024 (UTC)[reply]
@Gråbergs Gråa Sång, Convenient Discussions does that (after). Beneath each comment on a talk page are the options Reply Edit Thank. If you highlight some text in the comment, Reply changes to Quote, and it automatically includes the text in your reply formatted with Template:TQ. I like CD because it shows signatures before the comment, which has made it a lot easier for me to follow threads. Schazjmd(talk) 14:52, 7 November 2024 (UTC)[reply]
For a by default feature that would benefit to all users, the Editing team has a thank button on the works. This deployment is currently blocked as this "Thank" button is dependent of other design changes. These changes have been deployed to 50% of users at English Wikipedia; we have to make it a default component. I'm a bit behind schedule regarding this deployment (listed as T379264) as other priorities came up. If you think these design changes and the thank button would be welcomed, I more than welcome support to prioritize this! Trizek_(WMF) (talk) 14:57, 7 November 2024 (UTC)[reply]
You can also turn off the feature to change signature positions. Aaron Liu (talk) 15:17, 7 November 2024 (UTC)[reply]
Having started some Wikipedia articles and added to others, I have the following questions and suggestions:
Why are there four different reference templates, when they all have roughly the same content?
Why does one template call it “Journal”, and another call it “Work”?
Why does there need to be a Page slot and a Pages slot? (printer drivers handle both together)
Should there not be one uniform format for all references when published? (see "Notes", David Graham Phillips: six different references, six different formats)
I suggest there be one reference template that has places for all necessary content, and that all references follow the same format when published:
Template
Title of source _________________ URL ___________________
Last name of source creator _________________ First name ________________________
News agency _____________________ Website name ___________________________
Name of journal, magazine, newspaper, etc. ___________________________ Volume _____ Issue _________ Page(s) ________
Name of publisher ________________________________ Location of publisher _________________________
Date source published __________________ Date source accessed____________________
Ref name ________________ Ref group __________________ Ref ID for anchor ___________________
(put DOI and PMID in “extra fields”)
Print references in same order of information as in the template above. Pbergerd (talk) 14:19, 7 November 2024 (UTC)[reply]
There are quite a few more citation templates, it is just the four most commonly used that are available in the tool bar. All of the citation templates use the same set of fields, and you can build a citation from scratch using Template:Citation. The four citation formats available in the tool bar just start you with the fields most commonly used for each type of citation. You can leave fields empty, and you can add other fields as needed, as is needed when citing a chapter in a book, for instance. Donald Albury 18:53, 7 November 2024 (UTC)[reply]
As a minor correction, not all of the CS1|2 templates support the same parameter set. For example, as of 2023, calling {{Cite book}} with the parameter |website= (or any of its aliases, like |work=, |journal=, |periodical=, |magazine=) will cause a template error, and add the article to Category:CS1 errors: periodical ignored (23,172).To address the substance of the OP, that there is any consistency among the most commonly used citation templates is the result of years of effort and discussion. The multiplicity of display formattings is a feature, not a drawback. There will never be just one single citation template, uniform in formatting across all sources and transclusions.Pbergerd, if you want the input fields in whatever editor you're using (not clear from tags in your contribs) to match the displayed format of those templates, that would best be addressed to whomever maintains your editing interface of choice (if anyone). The formatting will not be changed in the other direction (i.e. display matches input field ordering). Additionally, to my knowledge no citation template display leads with the title when the author is known, so I doubt you'll find consensus for your specific implementation proposal anywhere. All the best, Folly Mox (talk) 18:39, 9 November 2024 (UTC)[reply]
As a less gloomy follow up, our editing guideline WP:CITEVAR allows for articles to maintain the style used by the first major contributor or adopted by the consensus of editors already working on the page. So if you feel strongly about title-headed citations, you can implement your preferred formatting on articles you create, or unreferenced articles you provide the first citations for. But don't be surprised if bots come along and change it.With respect to your specific example David Graham Phillips § Notes: three two of the six citations – Fellow, Mencken, and Ravitz – are manually formatted (not the result of any citation template) and shouldn't be used as examples of a surfeit of citation formats. Two of the three four sources used in citation templates do not provide any authorial or editorial attribution (verified in sources), so naturally the format will differ from that of sources where the author is known.Tangentially, it is somewhat common for articles to use a mixture of Shortened footnotes and regular "defined in place" citations. Usually this is unintentional, as editors new to an article will almost never add citations in shortened format, except improperly, adding to Category:Harv and Sfn no-target errors (4,783). Converting all the new sources to shortened footnote form happens very irregularly. Sometimes articles will intentionally adopt a mixed style, where "main sources", multiply cited sources, or sources cited at more than one in-source location (a subset of the previous criterion) will be formatted in shortened form, and the remainder in the standard fashion. Folly Mox (talk) 19:22, 9 November 2024 (UTC) corrected per below 20:38, 10 November 2024 (UTC)[reply]
There are plenty of reasons not to use shortened footnote templates, and the lack of support for extra parameters is a feature (the footnotes, after all, are supposed to be short).I'm wondering why |access-date= in particular would ever be helpful to support: it's one of the cruftiest parameters, displaying rather a lot of text for information only really needed during archive snapshot hunting; it's not useful for print sources, which have a stable form per publication date, and are the most common types of sources where shortened footnotes are used; and why would you have different access dates for different sections of the source? Can't it just be added to the full citation template the shortened footnote links to?Quotes are another matter, but are easily included within the <ref>...</ref> tags following a harv family template like {{harvp}} or {{harvnb}}, which can be embedded within ref tags. Folly Mox (talk) 15:51, 10 November 2024 (UTC)[reply]
The attributes I mentioned were just random examples, but, e.g., |sectionlink= certainly seems important, and lots of printed sources are also available as PDF. Placing detail as free text in <ref>{{harvnb}}...</ref> does not create the proper metadata, so while it might work for |quote= it does not for other attributes. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:40, 11 November 2024 (UTC)[reply]
Thanks for all of your information. (I actually did use the book template for the Ravitz citation.) Pbergerd (talk) 15:58, 10 November 2024 (UTC)[reply]
Whoops, sorry; not sure how I misread / misremembered that. Corrected my earlier reply. Folly Mox (talk) 20:38, 10 November 2024 (UTC)[reply]
Has anyone proposed using the military history's criteria for C-class universally before?
"The article cites more than one reliable source and is better developed in style, structure, and quality than Start-Class, but it fails one or more of the criteria for B-Class. It may have some gaps or missing elements, or need editing for clarity, balance, or flow."
The heuristic for C-class is "substantial but is still missing important content". The heuristic for Start-class is, similarly "developing but still quite incomplete": not very different. As an alternative, you can try to determine whether the article is "Useful to a casual reader, but would not provide a complete picture for even a moderately detailed study" or "Provides some meaningful content, but most readers will need more."
And here's the military history version of C-class:
"The article meets B1 or B2 as well as B3 and B4 and B5 of the B-Class criteria.
Here, rather than having to make a difficult heuristic judgement between C-class and start-class, clear criteria determine whether an article is start-class and other clear criteria determine whether it is C-class. It seems to me to be a reasonable formalization of the two heuristics (referencing and completeness) used to determine C versus Start class anyways. I think if Wikipedia adopted this generally, it would make rating articles much faster and simpler and less confusing given that the criteria for distinguishing C-class articles are formalized rather than subject to essentially how complete the article feels. When I rate articles, I usually spend a good bit of time worrying about whether it is C-class or Start-class -- a major part of the decision making currently is informed by observing other people's decisions. WP:MILHIST has basically solved that and added a FAQ.
Has anybody ever proposed using the MILHIST criteria before? I do remember seeing proposals (not successful) to merge C and Start class, but not this specifically. Mrfoogles (talk) 08:55, 11 November 2024 (UTC)[reply]
Making the assessment process any more formalized than it is is a non-starter when we have hundreds of thousands of articles that aren't assessed at all. PARAKANYAA (talk) 15:32, 12 November 2024 (UTC)[reply]
Well, the idea of this would be to make it easier to assess them. Mrfoogles (talk) 23:09, 12 November 2024 (UTC)[reply]
My experience is that any article ratings other than those which are part of a formal process (i.e. all those except GA, A, and FA) tend to be assigned based on vibes rather than any strict concern with the criteria, and mostly are not updated when the article changes. If assessments are largely made without reference to the criteria, I'm not sure that changing the criteria will have much effect. Even assuming for the sake of argument that people are carefully rating articles based on the assessment criteria, ratings are updated so infrequently that there's no guarantee that they are still appropriate at any given time. I don't object to clearer criteria for what is a start/C/B class article, but I also don't know that I really see the point: at this point in Wikipedia's development, what if anything do people actually use these ratings for? Generally I agree with the view which has been expressed by various people in the past (I know Iridescent used to make this point, as in this thread) that the distinctions between start/C/B class are pretty pointless and we'd be just as well off scrapping them entirely and ending up with a scale which goes stub/standard/good/featured or even unassessed/good/featured. (You mention proposals to merge start- and C-class, but I cannot find them in the archives of Wikipedia talk:Content assessment or WP:VP) Caeciliusinhorto-public (talk) 12:58, 13 November 2024 (UTC)[reply]
I'd pretty much agree with this, adding that in my experience most ratings are assigned almost entirely on article length, and also that nearly all our readers and most of our editors never look at them. Johnbod (talk) 13:37, 13 November 2024 (UTC)[reply]
They are pointless, generally speaking, other than that it's nice to say you've improved the quality of X article to Y, which can be a nice achievement. You might be right than eliminating the distinctions might be a good idea -- stub/start/C are very difficult to distinguish meaningfully, and checking that everything is cited correctly in B requires a mini-GA review level of work for long articles. Mrfoogles (talk) 02:58, 14 November 2024 (UTC)[reply]
Given the reception, probably not going to propose this. What the system really needs is a reform based on determining what purposes it actually serves. Mrfoogles (talk) 02:59, 14 November 2024 (UTC)[reply]
Enable interlanguage links to author links in cite templates
One of the edits I most often do is to use author link to wiklink names in citations, including in citations that use templates like Template:Cite book. This works great if the author already has an article in English Wikipedia.
Unfortunately, when the author only has an article about him in some other language, this cannot be taken advantage of. Interlanguage links do not work in cite templates. I think Wikipedia does not allow one set of braces or curly brackets {{}} to be inside another set {{}}; in other words does not permit nested layers of templates.
Proposal
I propose that Wikipedia, via some way (whether or not that means allowing nested layers of curly-bracketed templates), enable interlanguage links in citations that use cite templates.
Eberhard Straub (2011). Eine kleine Geschichte Preußens. Klett-Cotta. p. 17.
The wiki markup for the citation reads:
{{cite book|title=Eine kleine Geschichte Preußens|author=Eberhard Straub|year= 2011|pages=17|publisher=Klett-Cotta}}
To make the author's name in the citation be a wikilink to his article, one would insert a new field in the citation like this:
|author-link=Eberhard Straub
but that would create a red link in English Wikipedia, because Eberhard Straub does not currently have an article in English Wikipedia.
However, he does in German Wikipedia, making it preferable for such a link to be an interlanguage link, thus empowering readers who want to know more about the cited author to at least be able to look at the article about him in German, and also inviting readers to be editors and create a new English-language article about him. If and when that English-language article is posted, then the red link to his name and the smaller bracketed blue link to the German article disappear from view and the link appears to readers to be an ordinary blue link to the new English language article.
How?
I don't know how to accomplish this.
I don't know if it's technically feasible to change the Wiki software to allow for a nested layer of curly-bracketed template to be used within another curly-bracketed template, using the already-existing author-link field, like this:
{{cite book|title=Eine kleine Geschichte Preußens|author=Eberhard Straub|author-link={{interlanguage link|Eberhard Straub|de}}|year= 2011|pages=17|publisher=Klett-Cotta}}
Or if a new interlanguage author-link field in the citation template needs to be created instead, like
{{cite book|title=Eine kleine Geschichte Preußens|author=Eberhard Straub|ill-author-link-de=Eberhard Straub|year= 2011|pages=17|publisher=Klett-Cotta}}
What do you think?
Carney333 (talk) 17:12, 12 November 2024 (UTC)[reply]
just put :de:Eberhard StraubEberhard Straub [in German] (2011). Eine kleine Geschichte Preußens. Klett-Cotta. p. 17.The real reason it didn't work is because the template already generated a [[]], so the parameter tries to linkify a link and render "[[[[:de:Eberhard Straub]]]]], causing it to fail. You can nest templates easily.
Doe, John (1 April 2020). [I witnessed Tom Hanks admitting to actually being born one year earlier, faking his age to enlist in the scouts] (Dream). Lucid. Recurring Tom Hanks scouts dream number 8. Doe's bedroom, 412 Example Street, Suburbiaville, London: REM stage R.
Aaron Liu (talk) 17:30, 12 November 2024 (UTC)[reply]
Thanks for your feedback, but the main problem with your suggestion is that it doesn't work with author links, which can draw from separately provided surnames and given names, and then display the results as surname first, then comma, then given name, hyperlinking to the article about the author. I didn't mention this in my original comment for reasons of space and focus.
In other words, what I really want to be able to do is to do something like
{{cite book|title=Eine kleine Geschichte Preußens|author-first=Eberhard author-last=Straub |ill-author-link-de=Eberhard Straub|year= 2011|pages=17|ill-publisher-de=Klett-Cotta}}
to produce something like:
Straub, Eberhard [de]. (2011). Eine kleine Geschichte Preußens (in German), Klett-Cotta [de]. p. 17.
Carney333 (talk) 01:25, 14 November 2024 (UTC)[reply]
If you want to suggest something to do with with the citation templates I suggest you post it to Help talk:Citation Style 1. This, and similar ideas, have been discussed before. The solution is to use: {{cite book |title=Eine kleine Geschichte Preußens |author-first=Eberhard |author-last=Straub |author-link=:de:Eberhard Straub |year= 2011 |pages=17 |publisher=[[:de:Klett-Cotta|Klett-Cotta]]}} which produces: Straub, Eberhard [in German] (2011). Eine kleine Geschichte Preußens. Klett-Cotta. p. 17.
It definitely works with both |author= and |last=, |first=. -- LCU ActivelyDisinterested«@» °∆t° 13:29, 14 November 2024 (UTC)[reply]
Disclosure: I hate {{ill}} since it breaks title display in non-ASCII scripts on Firefox; i.e. you have to click through and load the sister Wikipedia page just to retrieve the title instead of a bunch of percent escaped garbage numbers for unicode codepoints. Folly Mox (talk) 14:08, 14 November 2024 (UTC)[reply]
In principle, one could set up a disambiguation page (thereby allowing for multiple languages) for the target and use {{interlanguage link}} on the disambiguation page. Of course, there may be a mild "surprise" for the user, but there can be sufficient explanatory text on the disambiguation page to explain the situation.
A side-effect of this (unless there's some provision to suppress this behavior), is that the page will be recognized as a valid "local wiki" page for other purposes as well, but IMO, that's not necessarily a bad thing ... and we can always include a qualifier in the title of the disambiguation page to help address that concern. Also, this is a little more work, but I think it's an improvement over the current practice of not providing the link. Fabrickator (talk) 15:26, 14 November 2024 (UTC)[reply]
Another option would be to create a stub/start article, link it to wikidata to get the language links, and tag it with the relevant "Expand language" template EdwardUK (talk) 17:49, 14 November 2024 (UTC)[reply]
I'm not sure a bunch of transwiki dabpages or nearly content-free stubs are the solution to this unproblem. {{ill}} formatting aside, what's wrong with linking an article on a sister project? We do it with Wikisource, Wiktionary, and Wikidata all the time. Folly Mox (talk) 21:44, 14 November 2024 (UTC)[reply]
In the context of citations, the actual target is only visible when you mouse over it (assuming the user bothers to examine the link preview), so it will typically be a surprise when a non-English page is displayed. Also, the general intent is to let the user select their preferred language, if multiple languages are available. (Of course, there will be a list of all available languages when you go to any language version of the article.) As a fairly minor point, the existing use of {{ill}} provides for the replacement of {{ill}} when a local link becomes available. Fabrickator (talk) 02:16, 15 November 2024 (UTC)[reply]
Favoriting articles for logged-out and IP users
Hi. Before i joined Wikipedia, i always wanted a way to save my favorite articles somehow. When i logged in, i was excited to see a star button on a article (which signaled it was a sort of a favorite button) but to my disappointment it just made articles go on the watchlist. So what if there was a way to save certain articles to, say, read later or gather a collection for a school assignment. This would be very useful to both logged-out and in users. This could mean good for Wikipedia editing too! If you favorite a article, there should be a way to easily come back too it. This would make more efficient editing, rather then a confusing “watch list” of articles. Another way to implete this idea is to add it to a group, where you can come back to later. But either way, there should be a way to save articles to a dedicated area, logged in or not. Edit: I apologize if this is the wrong area,i couldn’t quite figure out if i should out this in Proposals or here.K.O.518 (talk) 06:49, 15 November 2024 (UTC)[reply]
Note that the “View and edit watchlist” tab of the watchlist has a list of all your watched articles in alphabetic order, which could be used as a favourites list. novovtalkedits 10:44, 15 November 2024 (UTC)[reply]
The official Android and iOS Wikipedia apps also have the ability to bookmark and save articles for offline reading. the wub"?!" 16:35, 15 November 2024 (UTC)[reply]
The Asian News International vs. Wikimedia Foundation situation
The open letter has reached over 600 signatures, for those unaware. Aaron Liu (talk) 17:34, 10 November 2024 (UTC)[reply]
In light of the fact that we now have an additional public court disclosure seeming to overwhelmingly indicate that the WMF will imminently be disclosing the personally identifying information of at least the three volunteers that ANI has identified as defendants in its suite, I am proposing we have as broad a community discussion as possible on what further response (up to and including large organized protest actions aimed to challenge the WMF's intended course of action) might be appropriate and feasible in the circumstances. Please see here, for further details. SnowRise let's rap 16:13, 14 November 2024 (UTC)[reply]
Journal article about coverage of native American topics in English-language Wikipedia
There is a journal article titled Wikipedia’s Indian problem: settler colonial erasure of native American knowledge and history on the world’s largest encyclopedia.
Given that it's recent (May 2024) and it has suggestions directed at Wikimedia Foundation, I was just wondering if Wikimedia Foundation is aware of this article. And I am not asking with respect to editor conduct, but with respect to any potential initiatives (such as partnerships with potential volunteer experts to audit few articles). Bogazicili (talk) 19:12, 4 November 2024 (UTC)[reply]
BC government sound file
Advice please on whether this sound file provided by the British Columbia government, Ministry of Environment, would be considered free and uploadable to Commons for Wikipedia articles about Osoyoos, the town and lake, and sw̓iw̓s Park. It comes from this provincial park website, and would be a useful example for pronunciation. Thanks. Zefr (talk) 15:29, 6 November 2024 (UTC)[reply]
Here is a quick overview of highlights from the Wikimedia Foundation over the first half of November 2024. Please help translate.
WikiCelebrate Mārtiņš Bruņenieks
Upcoming and current events and conversations Talking: 2024 continues
Commons Community Call: The first community call with Wikimedia Commons volunteers and stakeholders to help prioritize support efforts for 2025-2026 Fiscal Year will take place on November 21. The theme of this call will be about how content should be organised on Wikimedia Commons. The call will be hosted by Chief Product and Technology Officer Selena Deckelmann.
Conferencia Justicia climática Perú 2024: Conference on climate justice, indigenous voices and Wikimedia platform will be held in Huaraz, Peru from November 8 to 10.
Affiliations Committee: Applications for joining the Affiliations Committee is open until November 18.
Ombuds Commission and Case Review Committee: Applications for joining the Ombuds commission and the Case Review Committee are open until December 2.
Language community meeting: A language community meeting will be hosted on November 29, 16:00 UTC, discussing technical updates and problem-solving.
Annual Goals Progress on Infrastructure See also newsletters: Wikimedia Apps · Growth · Research · Web · Wikifunctions & Abstract Wikipedia · Tech News · Language and Internationalization · other newsletters on MediaWiki.org
Advisory Council: The new Product and Technology Advisory Council (PTAC) was announced. The PTAC will try to publish a set of community-validated recommendations that can serve as a potential 2-3 year blueprint for product and technical success.
Wikifunctions: The Abstract Wikipedia team is working toward a rewrite of our backend services in a different programming language, likely Rust. More status updates.
Tech News: The Guided Tour extension, which help newcomers understand how to edit, now works with dark mode; Wikipedia readers can now download a browser extension to experiment with potential features that making it easier for readers to discover information on the wikis. More tech updates from tech news 44 and 43.
Temporary accounts: Logged-out editors on 12 wikis, including Norwegian, Romanian, Serbian, Danish, and Cantonese Wikipedia, receive temporary accounts now. This new account type enhances the privacy of logged-out editors and makes it easier for community members to communicate with them. Read the new Diff post to learn more about temporary accounts.
Mobile apps: The Mobile Apps team has released an update to the iOS app’s navigation, now available in the latest App store version.
Campaign Events Extension: The Campaign Events extension is now live on two more wikis, Wikidata and the Spanish Wikipedia.
Admin Retention: A survey on Wikipedia Administrator Recruitment, Retention, and Attrition is open until November 11. As part of the Foundation's 2024-2025 Annual Plan, the research team and collaborators are studying recruitment, retention, and attrition patterns among long-tenured community members in official moderation and administration roles.
Knowledge is Human: The campaign web page, which educates visitors on Wikipedia’s model and why it’s trustworthy, has earned over 140,000 clicks. The campaign has increased pageviews on WikimediaFoundation.org by more than 50%.
Annual Goals Progress on Equity See also a list of all movement events: on Meta-Wiki
WikiCelebrate: From making a minor maintenance edit in 2005 to being one of the most appreciated Wikimedians in the Central Eastern European (CEE) region: this month we celebrate Mārtiņš Bruņenieks.
Wiki Loves Earth: Mountains, Birds and Lakes – Central Asia Edition
Future of Language Incubation: As part of a new Future of Language Incubation initiative to support language onboarding, Wikipedia is now live for five languages: Pannonian Rusyn, Tai Nüa, Iban, Obolo, and Southern Ndebele.
Annual Goals Progress on Safety & Integrity See also blogs: Global Advocacy blog · Global Advocacy Newsletter · Policy blog
Global Advocacy: Reflecting on the anniversary of the EU’s Digital Service Act (DSA), Wikimedians share successes and public policy priorities at digital rights Global Gathering event, and more global advocacy updates.
Annual Goals Progress on Effectiveness See also: quarterly Metrics Reports
English Fundraising: The Road to Launch: Wikimedia’s 2024 English Fundraising Campaign.
Fundraising Report: Our annual fundraising report for the 2023-2024 fiscal year is published. Last year, we had over 8 million donors giving an average donation of m:Fundraising/2023-24 Report0.58. We ran campaigns in 33 countries, 18 languages, and received donations from over 200 countries.
Other Movement curated newsletters & news See also: Diff blog · Goings-on · Planet Wikimedia · Signpost (en) · Kurier (de) · Actualités du Wiktionnaire (fr) · Regards sur l’actualité de la Wikimedia (fr) · Wikimag (fr) · other newsletters:
Topics: Education · GLAM · The Wikipedia Library
Wikimedia Projects: Milestones · Wikidata
Regions: Central and Eastern Europe
Subscribe or unsubscribe · Help translate
Previous editions of this bulletin are on Meta-Wiki. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!
Interesting note buried in this about how IP addresses are going to be handled in future, thanks for the update on that timely issue. Espresso Addict (talk) 09:26, 8 November 2024 (UTC)[reply]
We would prefer not to deploy on English Wikipedia at that time, though. A knee jerk reaction would be requesting otherwise and have enwiki be onboard as early as possible. – robertsky (talk) 08:48, 9 November 2024 (UTC)[reply]
It makes sense to fine-tune implementation on smaller wikis before rolling out to larger ones, but I am a lot more comfortable about this implementation than I was with earlier reports, which merely talked of hiding IP addresses, with all the worries over how we then handle IP vandalism, and did not provide any benefits to the (logged-in) community of editors. Espresso Addict (talk) 08:57, 9 November 2024 (UTC)[reply]
Currently, extended-confirmed editors -200 edits will have access to the ip information. It is a large pool of users (>70k here) who can look that data. – robertsky (talk) 09:12, 9 November 2024 (UTC)[reply]
Indeed, I was very pleased that the ability to look at IPs had been extended to patrollers. Is there somewhere better that we can highlight this useful update, which allayed many of my concerns as an administrator about the upcoming change, as I fear the WMF page is not much read? Espresso Addict (talk) 09:33, 9 November 2024 (UTC)[reply]
I see the option in the Preferences page. It wasn't there before. Enabling now. :D – robertsky (talk) 11:59, 9 November 2024 (UTC)[reply]
How will this change the WP:OUTING policy? For example can I include the IP address or cidr range of a temporary account in the suspected sock list? Would that be considered outing? Because anyone(logged out editors too) can see a SPI report.Ratnahastin (talk) 09:38, 9 November 2024 (UTC)[reply]
Most likely not, as you're required to agree to certain terms when opting in to view IPs (as you already are on this wiki when enabling IP info). It would be a violation of not only local policy but ToS. Nardog (talk) 11:51, 9 November 2024 (UTC)[reply]
I think there should not be a need to include the IP address or the CIDR range in SPI report. Just the list of temporary accounts will do. Any CU, clerks, or patrolling admins will to have updated their checking processes to account for temporary accounts. – robertsky (talk) 12:02, 9 November 2024 (UTC)[reply]
Has anyone seen an indication of how many buttons you have to click to see IP info? In the past, people might post half-a dozen IPs at ANI and someone else would point out that that was a /64 that should be blocked with no collateral damage. At least one template ({{blockcalc}}) can extract IPs from wikitext and show the ranges involved. We will have to see how much hassle will be involved with the new system. Johnuniq (talk) 02:02, 10 November 2024 (UTC)[reply]
You can ask for the permissions and try it on testwiki: or, if you have enough edits, on any other wiki where it's been rolled out. Nardog (talk) 06:23, 10 November 2024 (UTC)[reply]
@Johnuniq: I have the global version of edit filter helper, so I have access on the wikis where it's just been rolled out (plus testwiki). If I recall correctly, it's just one button agreeing to the IP information policy to reveal IPs, but there are more boxes in Special:Preferences that allow for things like revealing IPs in the edit filter and using IP information on contribution pages. There's also a global preference available to CU/OS and certain global groups (global rollback/sysop, and global abuse filter helper/maintainer) to enable IP information cross-wiki. EggRoll97(talk) 23:32, 10 November 2024 (UTC)[reply]
Temporary accounts can be changed if one clears cookies or uses a different browser, not the same case with a cidr IP range. This will certainly make it a bit of a hassle to list out every temporary account associated with the IP range, anyway let's see how this feature is implemented first. Ratnahastin (talk) 02:06, 10 November 2024 (UTC)[reply]
Open letter about Asian News International vs. Wikimedia Foundation
If you (the WMF) are not already aware of it there is an open letter here with over 600 signatures. Phil Bridger (talk) 18:46, 10 November 2024 (UTC)[reply]
Will you be moving operations overseas?
Trump has a tendency to cause disruptions in a number of different ways. He seriously interfered with a government directed radio station of some sort when he was in office last time (https://www.npr.org/2020/06/18/879873926/trumps-new-foreign-broadcasting-ceo-fires-news-chiefs-raising-fears-of-meddling). Will it be necessary for you to move Wikipedia operations overseas or is it already handled in some other way? I'm sorry to voice my concern this directly, but: I'd rather this didn't turn into conservapedia mkII and have Trump attempt to re-write history.75.142.254.3 (talk) 19:15, 10 November 2024 (UTC)[reply]
The Wikimedia community is editorially independent of the foundation and has remained so during Trump's first presidency, so I see no reason to be worried. * Pppery *it has begun... 19:22, 10 November 2024 (UTC)[reply]
Do you mean the users or a part of the body of wikipedia itself? As in, could Trump take over the website or otherwise exert significant pressure that would otherwise be alleviated by relocation? If not, then I guess no action necessary.
The only thing he could do is hire a troll farm of some sort, which I don't expect us to have much trouble defending against. Aaron Liu (talk) 19:58, 10 November 2024 (UTC)[reply]
Are the servers located in the United States? It's looking like the answer is no, and I'm sorry for being paranoid, it's just that he has done things in this country that we didn't anticipate because we didn't expect anyone to have the sort of character that it would be a problem in that position. 75.142.254.3 (talk) 20:01, 10 November 2024 (UTC)[reply]
The primary Wikimedia data centers are located in the U.S., with caching centers distributed around the globe. I think you'd be hard pressed to find a country with better legal protections for online free speech, but as you note, it shouldn't be taken for granted. Legoktm (talk) 20:13, 10 November 2024 (UTC)[reply]
Yeah, the 1st amendment provides stronger protections than almost all countries have; even if Trump tried he'd be hard pressed to find a court that would agree with Wikipedia censorship (unlike in India...). Galobtter (talk) 04:34, 11 November 2024 (UTC)[reply]
The Wikimedia Foundation, which hosts Wikipedia, is based in the United States, and has to comply with US laws. Unless a relevant law is passed or legal action is taken, there isn't much Trump can do. ARandomName123 (talk)Ping me! 20:17, 10 November 2024 (UTC)[reply]
If Trump goes authoritarian, which at this point I'm not going to rule out, US Law could be changed on a whim. But, I'm going to try to not be paranoid as much on this and WMF may already have evaluated appropriate courses of action given how they've managed to handle a wide variety of different kinds of disruption already. 75.142.254.3 (talk) 20:20, 10 November 2024 (UTC)[reply]
The bottom line is, we just don't know. I'm sure the WMF has contingencies in place for if US law ever becomes prejudicial to the project. Until he actually becomes president, we don't know what will happen. We just have to wait and see. TheLegendofGanon (talk) 20:22, 10 November 2024 (UTC)[reply]
The Constitution of the United States provides protections that would be very hard for Trump or any other president to circumvent, and the consent of 2/3 of both houses of Congress and 3/4 of the states is required to amend it, so I'm not too worried yet. QuicoleJR (talk) 15:24, 11 November 2024 (UTC)[reply]
Not only that, but we already can handle dealing with edits from congress itself. Gaismagorm(talk) 14:15, 12 November 2024 (UTC)[reply]
As a basic precaution there should be a Wikipedia mirror with daily backups hosted on a server geolocated in a country with a higher democracy index and a higher internet freedom index than the US. I'd suggest Iceland, personally.—S MarshallT/C 04:23, 13 November 2024 (UTC)[reply]
Honestly, it's unneeded. Look, I get worrying about this situation but I doubt the situation will get so bad where wikipedia needs to move overseas. As stsated above, wikimedia also likely already has a plan for if this happens. Gaismagorm(talk) 11:40, 13 November 2024 (UTC)[reply]
Just a thought, but if the WMF does have or in the future creates contingency plans for moving operations in response to political developments, publicly revealing such plans in advance might make it harder to carry them out. It would be like a business announcing that they will build a factory in a given location without having at least an option to buy the land they will build on. Donald Albury 16:11, 13 November 2024 (UTC)[reply]
Stop worrying to much, I doubt Trump is going to do anything against Wikipedia. Attacking and threatening to block Wikipedia will only infuriate the centrist voters, which I didn't think anyone would want to do. Some of the editors here are Trump supporters as well! What is concerning for Wikipedia today is the above case in India, where WMF HAD agreed to disclose the editor's information because of a defamation suit. ✠ SunDawn ✠(contact) 06:01, 14 November 2024 (UTC)[reply]
Realistically, I doubt anything in particular will happen to Wikipedia. But if you want to prepare for the worst, as it were, and you have a machine with some extra disk space, consider periodically keeping an updated copy of the Wikipedia database dump. I get one periodically, just in case, since I've got plenty of spare space on this machine anyway. If worst ever came to worst, plenty of volunteers have the technical skill to get a DB dump up and working on a MediaWiki instance elsewhere, and run it at least while things are sorted out. I doubt it'll ever come to that, but if you want to be prepared just in case, well, the more widely copies of those are available, the better. Just remember that Wikipedia was completely run by volunteers once, from software development to sysadmins, and we could do it again if we had to. SeraphimbladeTalk to me 06:12, 14 November 2024 (UTC)[reply]
The biggest problem would be providing sufficient server capacity to handle the traffic. Anybody can put up a static mirror of WP as it was on the download date (Lord knowns there are a lot of those on the Internet), but providing an editable version that would be used by a large proportion of current editors would be pretty expensive. And if there were more than one editable version out there, it would be very difficult to ever merge the changes back into a single database, with some clones becoming permanent forks, perhaps sponsored by governments and other large entities. Donald Albury 18:19, 14 November 2024 (UTC)[reply]
((uh-oh ... IF the above "attempted" wikilink does not work, then ... maybe try this instead.))
By the way, perhaps that above-mentioned "Talk:" page section -- which is brand new, right now -- might be difficult to find, in the future ... if/when it has been archived.
(Perhaps even when using the link displayed as "this", where, besides those [ill-advised?] square brackets in the section name, having been "escaped" [in some way] by using "percent-5B" and "percent-5D", it also uses a full URL starting with "https" instead of a syntax involving "double"square brackets.)
If so, then this link to the DIFF listing might help: https://en.wikipedia.org/w/index.php?title=Talk%3ALeslie_Winkle&diff=1255765446&oldid=1203561430
Thank you, and please forgive me if I chose the wrong place to add this "mention".
@Mike Schwartz, when a redirect isn't working correctly, just fix the target that it's pointing to. I've repaired Leslie Winkle. Schazjmd(talk) 16:47, 6 November 2024 (UTC)[reply]
@Schazjmd : Thank you. -- Mike Schwartz (talk) 17:04, 6 November 2024 (UTC)[reply]
@Schazjmd: It's not always that simple. "Just fixing the target" can be a real problem if someone reorganizes the target article and changes sections' titles. Been there, experienced that. CiaPan (talk) 18:37, 6 November 2024 (UTC)[reply]
Let me clarify what I meant: fix the target on the redirect page. If the redirect page is pointing to a section that has been renamed, change the wikilink on the redirect page to the new section name. Schazjmd(talk) 18:44, 6 November 2024 (UTC)[reply]
Fictional flag used in multiple places
This problem is not unique to the English-language Wikipedia, but I'm starting here because this is my native language. I'm bringing this to an explicit discussion here rather than just editing so that we can build an explicit consensus that I can then show the other Wikipedias.
I see a bot being viable that checks for flags (and maybe maps) tagged either as fictional (or frankly, with Commons:Template:Datasource needed) and strips them from articles. Remsense ‥ 论 01:26, 7 November 2024 (UTC)[reply]
I've seen this kind of thing in the past. I remember one user who created and uploaded to Commons dozens of fictional flags for provinces in various countries, and then added them to WP articles. Another user and I spent a fair amount of time documenting the flags were fictional and getting them deleted. (See Commons:Deletion requests/Files in Category:Fictitious flags of municipalities of the Dominican Republic&diff=prev&oldid=353306231#Files in Category:Fictitious flags of municipalities of the Dominican Republic) fictional flags created for just one country.. Donald Albury 16:00, 7 November 2024 (UTC)[reply]
I think this is a more general case of Commons is not a reliable source. I often see people take images in commons completely at face value, including them in articles without any real source. Commons has very different rules than enwiki. They are mostly concerned with copyright and licensing, and (intentionally) make no attempt to verify that images are "real" or that the descriptions are factually correct. That's just not their job. But it is our job when we use one of their images in an enwiki article. RoySmith(talk) 16:21, 7 November 2024 (UTC)[reply]
Not exactly fictitious, but there was also the case of Flag of Vatican City#Incorrect version where we had an inaccurate flag for years which spread across the internet and out into the real world. the wub"?!" 17:14, 7 November 2024 (UTC)[reply]
I belong to an organization which has a flag. The design is described in exquisite detail in our charter ("white stripe, whose width is one-sixth of the hoist", that kind of thing). I sat down one day and carefully drew an example in a drawing app, taking pains to get the geometry exactly as described. The charter (long) predates things like Pantone, but I did consult with a commercial artist to get their input on the correct RGB values to use for the colors and attempted to get all the people who produce material for us to use these "official" versions. Eventually I gave up and accepted that people will just copy-paste from whatever is handy. Now I just amuse myself by tracing the lineage of various bits of marketing material by which version of the flag they've got. But, yeah, we should do better than that. RoySmith(talk) 17:25, 7 November 2024 (UTC)[reply]
@Jmabel, I suggest thinking about c:Commons:File renaming#Which files should be renamed?, particularly item 3, and seeing if they could get renamed to something like "Fictional standard of the President of Syria" (or "Fake" or whatever else you want). WhatamIdoing (talk) 04:44, 10 November 2024 (UTC)[reply]
@WhatamIdoing: please feel more than free to pursue that.
I am glad to see there appears to be consensus to remove this from all articles. I will do so, or at least attempt to (some may be tricky because of templates). - Jmabel | Talk 17:03, 10 November 2024 (UTC)[reply]
I suspect there will be few objections to bold removal of any fictional flags. Commons has a real issue with their flag galleries, unfortunately. CMD (talk) 11:06, 11 November 2024 (UTC)[reply]
1) Deals with user behavior problems that our normal consensus process at WP:ANI can't handle. 2) Deals with administrator behavior problems. 3) Deals with anything related to private, off-wiki information. 4) Deals with certain unblock requests. –Novem Linguae (talk) 02:56, 10 November 2024 (UTC)[reply]
I have trawled through some dark places on Wikipedia and collated Wikipedia:Open letters, I have added summaries and outcomes to the older open letters, do correct me directly there if the summaries aren't right. if there's any other open letters from the community or the enwiki community had participated to be added, go ahead (except for the burger king related ones as those explicitly said they were not from the community). – robertsky (talk) 04:08, 10 November 2024 (UTC)[reply]
Redirects are cheap, but how many is too many?
I'm just wondering how others feel about this, without immediately starting an RfC or deletion discussion. @Hughbe98: as the one who created this example (but discussion is not about editor, but about edits).
Is this excessive, and if so how to reduce this? Removing the uppercase / lowercase variations would halve this already... Do we have guidance on a best approach for redirect creators? In total we now have already 448 redirects to this one article[6]. Fram (talk) 17:48, 12 November 2024 (UTC)[reply]
Ugh. This is what search engines are for. In the deep dark old days, we used to create these kinds of redirects because search wasn't very good. It's much better now (where "now" means the better part of 20 years) so we should just let it do its job. RoySmith(talk) 17:59, 12 November 2024 (UTC)[reply]
Do these redirects actually prevent anything desirable happening? DuncanHill (talk) 18:22, 12 November 2024 (UTC)[reply]
I see no problem here to be addressed. None of these individual redirects is so wrong as to merit deletion, so I don't see how the quantity much matters. BD2412T 19:07, 12 November 2024 (UTC)[reply]
448 redirects would occupy the same storage space as a single .jpg Doug butler (talk) 19:32, 12 November 2024 (UTC)[reply]
Oh, storage space wasn't my concern. More things like issues with "what links here" being harder to navigate, more redirects to watchlist for vandalism, more work when the target gets changed (e.g. in the list above, the target is a potential article apparently, so when it gets created all the redirects need updating), more potential "wrong" results in searches (to take the most recent creation, is 13 W. 3 significantly different from 13W3, which has a different target), ...? But if people see no issue, then my question is answered and no action is needed. Fram (talk) 20:00, 12 November 2024 (UTC)[reply]
I think you are right to question this. The problems you mention are small but not zero. Exhaustively redirecting variations of words is not something I would want to catch on as a normal practice. Barnards.tar.gz (talk) 14:58, 14 November 2024 (UTC)[reply]
It would be something to look at if a non-EC editor were adding a lot of such low-priority redirects, but otherwise, meh. Donald Albury 17:59, 14 November 2024 (UTC)[reply]
Redirects are cheap and usually uncontentious. Just occasionally an unambiguous redirect can become ambiguous as a new meaning arises for it. I suspect that only fixing redirects when they have become ambiguous would save a lot of unnecessary distraction and pointless make work. I used to spend quite a lot of time resolving multiple redlinks, and yes some of the redirects set up to do this would now be resolved by search. But improved search doesn't on its own resolve redlinks. ϢereSpielChequers 09:04, 13 November 2024 (UTC)[reply]
This is one of those situations where WP:CHEAP conflicts with a desire not to keep/hoard useless things. The question is: are these redirects actually useless? For most cases, I would suggest waiting at least six months, better a year, as long as the redirect is not linked from anywhere, and see if it gets any pageviews. If it doesn't, it can probably be deleted. Cremastra ‹ u — c › 13:31, 14 November 2024 (UTC)[reply]
Another way of thinking about it is, is the effort to check whether anyone uses a redirect worth less than the value of the resources freed up by deleting the redirect? My understanding was that the overhead of holding a redirect was so low that it meant any review of redirects, however cursory, was going to waste more effort than it could possibly save. ϢereSpielChequers 22:27, 14 November 2024 (UTC)[reply]
I agree with RoySmith that would should let search engines do their job, and I don't feel it's necessary to have a redirect for every variation that someone might write in an article. I don't think that does our readers any favours; having a common style helps them become familiar with it and thus more quickly recognize a citation. I agree with Fram that there are maintenance costs, and an increased risk of overlapping topics. For this particular case, is there a standard style that is generally used? isaacl (talk) 18:11, 14 November 2024 (UTC)[reply]
With legal citations, standards change over time. Any of the above variations for the particularly ancient statute in question may have been the most correct at a particular time. Even the ones that were never the most correct may have been used enough to show up in legal writings, such that a reader might see and want to look up the specific variation they have come across. Again, this is an unusually old statute. I don't see the case for deleting any specific one of these variations, and I doubt it's worth the effort to investigate whether there are some particularly low-value variations in the group. BD2412T 02:39, 15 November 2024 (UTC)[reply]
Sure, but as Wikipedia's prose is being written now, I feel it's reasonable to standardize on something in common use today. Plus removing some of the variations wouldn't stop them from being used; it would just would mean that a wikilink target would have to be specified. I'll agree that there are more important maintenance tasks that could be done, but if someone wants to do it, I have no objection to it. isaacl (talk) 04:56, 15 November 2024 (UTC)[reply]
From the reader/searcher POV, I don't see a need for someone to spend time creating redirects from slight variations on modern names, but:
From the editor POV, if we're going to link to this in a variety of different articles (or, in this case, the refs therein), each of which might have its own WP:STYLEVAR or WP:CITEVAR, then any of these might actually be wanted.
Once the time has already been spent making the redirects, I agree with what WSC said: The cost of debating it is likely higher than the cost of ignoring it. If and when any given instance ever becomes an actual problem, we should address it at that point, but not before.
When the redirect isn't merely a matter of capitalization, punctuation, and spacing, then I think it's generally helpful to have more redirects. In this instance, we ought to consider not only 25. Edw. Stat. 2, but also Sententia lata super Confirmatione Cartarum, Sentence of the Clergy given on the Confirmation of the Charters, and/or Sententia Domino R. Archiepiscopi super premissis.
Why was Real Clear Politics deleted prior to the election and then put back in to 2024 Poll averages afterward? It turns out they were the most accurate of the aggregaters. Ticketmand (talk) 23:05, 15 November 2024 (UTC)[reply]
@Ticketmand, which article(s) are you talking about? WhatamIdoing (talk) 05:07, 16 November 2024 (UTC)[reply]
@https://open.substack.com/pub/taibbi/p/how-americas-accurate-election-polls?utm_source=share&utm_medium=android&r=j0rzu Ticketmand (talk) 05:46, 16 November 2024 (UTC)[reply]
Welcome to Wikipedia, @Ticketmand. Have you figured out how to read the article's history page yet? If not, then Help:Page history might be useful. Looking through the history of the page, it looks like several different editors added or removed that particular poll multiple times, so whether it was in the article or not depends on when you were looking.
En 
.jpg/1280px-2015_0603-LGBTQ-4_(34631002910).jpg)
.jpg/1280px-Autel_votif,_MSR,_Mus%C3%A9e_Saint-Raymond_(7220963000).jpg)
wikimedia.org know if you have any feedback or suggestions for improvement!
_2024-11-16.png){kind=link}
_2024-11-16.png){kind=link}
.jpg){kind=link}
.jpg){kind=link}
