Una solicitud de comentarios para discutir los cambios a la política sobre la eliminación de permisos administrativos 20:43, 20 de febrero de 2021 (UTC)
Wikipedia: Solicitudes de comentarios / sentimiento de la comunidad de 2019 sobre el procedimiento de desysop vinculante ( WP: DESYSOP2019 ) se cerró con un consenso para un procedimiento de desysop (eliminación deprivilegiosde administrador ) diferente al proceso actual que requiere la remisión al Comité de Arbitraje . Esa discusión no resultó en acción porque ninguna propuesta tuvo el apoyo necesario para lograr el consenso de la comunidad. El cierre también destacó las preocupaciones que tenía la comunidad, entre las que se incluyen:
- El proceso del Comité de Arbitraje (ArbCom) es innecesariamente difícil
- Los administradores que hacen llamadas impopulares podrían sufrir acoso
- Es posible que los procesos de otros proyectos no funcionen en la Wikipedia en inglés
- La comunidad necesita una forma de abordar la conducta problemática
Como seguimiento de ese RfC, propongo que se agregue lo siguiente a Wikipedia: Política de administradores :
Cualquier usuario que esté confirmado extendido y haya realizado al menos 25 ediciones en los últimos 6 meses puede presentar una solicitud de desysop bajo las siguientes condiciones:
- La solicitud debe vincularse a al menos un hilo en un foro de la comunidad como AN o ANI que se cerró en los últimos 6 meses donde la declaración de cierre indica que hubo consenso de que el administrador se comportó de manera inapropiada.
- La solicitud estará abierta para respaldos. Si 10 usuarios confirmados extendidos que cumplen con los requisitos de presentación anteriores, incluidos al menos tres administradores actuales, respaldan la solicitud dentro de las 48 horas, la solicitud será revisada por un burócrata y, si cumple con los requisitos, se certificará como una solicitud activa para desysop. Si los endosos requeridos no ocurren dentro de las 48 horas, la solicitud se archivará como no exitosa.
- Una vez certificado, el administrador en cuestión debe incluir la solicitud de desysop en Wikipedia: Solicitudes de administración dentro de los 14 días o renunciar como administrador. Si ninguno de los dos ocurre dentro de los 14 días posteriores a la certificación, un burócrata concluirá la discusión.
Cuando se abre, el editor que inicia debe colocar avisos en WP: AN y WP: BN y WT: RFA . Una vez que una solicitud se ha incluido, se debe agregar a WP: CENT y los avisos se deben colocar nuevamente en WP: AN, WP: BN. La solicitud permanecerá abierta para comentarios durante 7 días después de la transclusión.
Si hay un consenso con un umbral mínimo de apoyo del 60% que respalda la eliminación, un burócrata cerrará la solicitud de desysop como exitosa y eliminará
+sysop
. Los usuarios que comenten deben cumplir con los requisitos para presentar una solicitud de desysop para apoyar u oponerse, pero pueden hacer comentarios generales si no califican.Además, los usuarios pueden iniciar esta solicitud para eliminar los permisos de administrador o burócrata de la interfaz de forma individual. Si un usuario es desysoped a través de estos procesos, también se eliminarán los permisos de administrador de interfaz y burócrata.
TonyBallioni ( charla ) 20:43, 20 de febrero de 2021 (UTC)
Hubo un apoyo mayoritario (55%) para esta propuesta y el caso de la oposición se vio algo debilitado por la falta de coherencia interna. Sin embargo, muchas de las inquietudes fueron fuertemente argumentadas, y colectivamente fueron fácilmente suficientes para evitar que la propuesta lograra un consenso.
Al igual que en WP: DESYSOP2019 , sigue habiendo un consenso aparente fuerte, aunque no abrumador, para un hipotético ideal comunitario desysop. Aunque consulte los análisis en recuadro para saber por qué puede ser un desafío lograr el consenso para una propuesta específica.
¡Gracias a todos los que contribuyeron a esta discusión de excepcional calidad! FeydHuxtable ( charla ) 17:56, 17 de abril de 2021 (UTC)- La siguiente discusión está cerrada. Por favor no lo modifique. Los comentarios posteriores deben hacerse en la página de discusión correspondiente. No se deben realizar más ediciones en esta discusión.
Sugerencias para futuros intentos de desysop comunitario |
---|
Incluso varios opositores parecían estar de acuerdo en que la propuesta de Tony estaba bien elaborada. El hecho de que no haya llegado a un consenso sugiere lo difícil que puede ser crear una tarea significativamente más exitosa. Especialmente porque los no votantes llegaron desde perspectivas parcialmente opuestas: algunos sintieron que la propuesta dificultaría demasiado la eliminación del sistema, frente a algunos que sentían lo contrario. (o al menos que tendría un efecto desalentador en los administradores). Sin embargo, con el beneficio de la retrospectiva, lo siguiente podría ayudar: 1) Tener un mejor momento (más afortunado). Muchos sienten que el sistema Arb actual está funcionando bien. Entonces, antes de lanzar el próximo intento, tal vez espere hasta el momento en que haya más descontento en la comunidad acerca de Arbs, lo que hace que sea demasiado difícil presentar un caso contra un administrador, o por el contrario, los Arbs están aprobando remedios desysop con demasiada facilidad. Entonces, menos podría oponerse con el argumento 'solución en busca de un problema / Arbcom está funcionando bien'. 2) Si bien ~ 20 se opusieron debido a la sensación de que la propuesta haría demasiado difícil el des-sysop, estos fueron superados en número 4: 1 por los interesados, haría que el des-sysoping fuera demasiado fácil (o al menos proporcionaría muy poca protección contra los administradores acosado por el proceso, incluso si no es probable que tales intentos den como resultado la pérdida de la herramienta). Por lo tanto, un proceso que es más difícil de desencadenar (aunque no necesariamente más difícil de obtener el resultado final) puede tener más probabilidades de obtener consenso. 3) Si esto se puede hacer manteniendo la protección adecuada, simplifique la próxima propuesta. 4) Tal vez reduzca el requisito de aprobación de 3 administradores. 5) No requiera que el administrador transcluya su propio de-RfA (pero conserve cierta capacidad para que ellos controlen el tiempo, tal vez déles una ventana de más de 2 semanas para esto). Más de 10 votantes expresaron su preferencia por esto, incluyendo algunos de los simpatizantes y un neutral. 6) Posiblemente introducir como un ensayo, prometiendo volver al status quo después de 1 año, a menos que una segunda discusión dé luz verde a una continuación con un consenso claro. 7) Antes de la próxima propuesta, tal vez tenga un RfC para ayudar a afinarlo, tal vez como lo ejemplifica Silktork en la sección de "comentarios". 8) Lea toda esta discusión: hay alrededor de 50 sugerencias de mejora que no he mencionado anteriormente, pero que podrían resonar más con el pensamiento actual de la comunidad, siempre que alguien vuelva a proponer. |
Análisis adicionales |
---|
En general, una discusión de calidad excepcional, tanto en términos de colegialidad como de fuerza de argumentación. En resumen, es un caso desafiante, ya que hubo múltiples líneas de argumentación parcialmente incompatibles e incluso inconmensurables, tanto a favor como en contra. Este es WP: NOTAVOTE , sin embargo, haré uso de números para indicar la contribución relativa al consenso. Aparte de los simples "totales", todos los números dados son subjetivos. Por ejemplo, si observa detenidamente algunos de los votos individuales, no siempre es fácil clasificar su fundamento. Sin embargo, espero que las cifras sean de alguna ayuda para resumir cuántos sostuvieron las diversas opiniones ampliamente compartidas. Desglose del voto de apoyo. 168 votos en total. A diferencia de los opositores, muy pocos apoyos tenían problemas de coherencia con otros fundamentos de apoyo. La excepción más clara a esto fue el voto de Maile, que estaba condicionado a aumentar el umbral para retener un administrador del 40> 60%. Cerca de 20 simpatizantes expresaron reservas. (Esta es una cifra subjetiva alta, algunos podrían decir menos de 10 si cuentan solo las reservas más fuertes. O> 50 si cuentan a las personas que hicieron sugerencias para modificar la propuesta de Tony, con solo un leve indicio de reserva). La mayoría de los votos de apoyo fueron esencialmente por propuesta, pero bastantes argumentos adicionales avanzados. DGG y AKG hicieron votos individuales especialmente fuertes, no es que estuviera de acuerdo con ellos, pero como ex Arbs, su posición de que la comunidad en general está en mejor posición para tomar las decisiones sobre los desysops, tenía que tener un peso adicional. Algunos hicieron el argumento adicional de que la propuesta facilitaría la aprobación de nuevos RpA. Esto no fue refutado, por lo que se agregó ligeramente al consenso de apoyo. Richite333 argumentó que los administradores opuestos podrían tener su opinión descontada por motivos de COI; estuve de acuerdo con esto, pero solo muy ligeramente. Sam-2727 hizo un argumento conciso pero efectivo refutando la opinión de Oppose de que la propuesta daría lugar a presentaciones frívolas, lo que nuevamente agregó un poco de peso adicional al caso de apoyo. Varios, de manera más reveladora Swarm, señalaron la inconsistencia en el voto en contra sobre la dimensión "demasiado fácil / demasiado difícil" para desysop. Esto reflejó mi propia lectura del caso Oppose, hasta el punto de hacerme descontarlo colectivamente en aproximadamente un 5%. Este es, con mucho, el mayor cambio de ponderación: todos los demás puntos tuvieron como máximo una influencia del 1%. Pero aún así, solo acercó el% de soporte ponderado al 60%. Tan lejos del umbral para el consenso, especialmente cuando, en conjunto, otros factores empujaron el consenso ponderado hacia abajo en parte a favor de oponerse ... Varios hicieron que 'lo perfecto es enemigo del buen argumento', y el caso aliado de que no podremos evaluar adecuadamente los pros y los contras de la propuesta hasta después de que se haya probado. Aunque no se ha refutado por completo, varios editores refutaron esta idea, especialmente Dirk Beetstra. Varios sugirieron que propuestas similares habían funcionado en otros wikis grandes, junto con la opinión estrechamente relacionada de que los datos triunfan sobre la especulación. Sin embargo, en términos de proporcionar datos específicos y bien presentados, ninguno podría compararse con Hammersoft, por lo que consideré este argumento bien refutado. Desglose del voto en contra Hubo 138 votos en contra en total. Aproximadamente 80 podrían clasificarse como opositores en gran parte debido a la preocupación de que la propuesta hizo que el abandono fuera "demasiado fácil", o al menos tuviera muy poca protección contra el uso para acosar a los administradores. Los comentarios de Beeblebrox y Sandstein estuvieron entre los más persuasivos a este respecto. Por el contrario, hubo alrededor de 20 opositores que parecían sentir que la propuesta haría que fuera demasiado difícil desistir. Sandy Georgia y Joe Roe presentaron argumentos especialmente sólidos en este sentido. Y hubo un puñado de votantes que (correctamente en mi opinión) señalaron que la propuesta corría el riesgo de hacer ambas cosas. Entonces, cuando se mira de cerca, el caso Oppose parecía menos incoherente de lo que parecía en un principio. Un par de votantes argumentaron que toda la propuesta se basó en una idea errónea: que Arbcom ya es un proceso comunitario. Si bien esto solo parece cierto hasta cierto punto, agregó un ligero peso adicional. Los fundamentos de oposición más comunes incluyeron que la propuesta era demasiado compleja y que era una solución innecesaria en busca de un problema. Otros sintieron que podría crear un espectáculo desagradable que podría sumarse a las luchas negativas e interpersonales. Y luego hubo algunas oposiciones simplemente por no gustarle elementos del proceso propuesto. Quizás solo un voto podría descartarse ligeramente por no ser lo suficientemente específico. Los editores que aumentaron especialmente el peso del caso opuesto, sin ser fáciles de clasificar sucintamente, incluyen Hammersoft, Huggums537 y NSK92. Aunque menos cohesivo que los votos de apoyo, sentí que los votos en contra eran generalmente más fuertes en bases individuales agregadas. Los votos neutrales también se sumaron ligeramente al caso Oppose (pero solo muy ligeramente; si desea que su declaración produzca consenso, debe hacerlo en la sección Oppose o Support. En mi opinión, al menos, los crats casi nunca prestan mucha atención a un voto neutral, incluso cuando tiene un punto excepcionalmente bien argumentado). En términos de resaltar partes de la propuesta de Tony de modificar, el Neutral de RoySmith puede ser especialmente útil. Al leer la discusión general fuera de los bloques de votación, el equilibrio pareció inclinarse hacia Oponerse, especialmente en las secciones "Hammersoft" y "Elefante". (Aunque nuevamente, esto solo afectó muy marginalmente mi lectura de la falta de consenso, a menos que los votantes se refirieran explícitamente a la sección de discusión como parte de su razón de ser). Un último factor que favoreció levemente a Oppose fue el hecho de que durante las últimas semanas, la tendencia había sido hacia Oppose, incluidos varios votantes que cambiaron sus votos en esa dirección. A fin de cuentas, los opositores hicieron lo suficiente para bloquear con bastante facilidad la formación de consenso. PD: como puede ser útil para los editores más nuevos ver qué argumentos tienen más influencia en una visión más cercana del consenso, mencioné a algunos editores que parecían presentar los argumentos más sólidos. Literalmente, más de 100 editores parecieron hacer contribuciones particularmente notables, por lo que la lista podría haber sido mucho más larga. Además, lo más fuerte no significa lo mejor: algunas de las contribuciones más perspicaces o elocuentes, por ejemplo, de Barkeep o Chicdat, fueron quizás demasiado matizadas para tener la mayor contribución al consenso. |
Apoyo
- Apoyo Tradicionalmente me he opuesto a esto con el argumento de que el proceso actual no está roto, pero creo que desde la última discusión sobre esto ha cambiado mucho en el proyecto y en la creación de un marco para el desyop iniciado por la comunidad que tiene en cuenta las necesidades y condiciones de la Wikipedia en inglés, aunque es probable que se haya logrado ser justo con todos los involucrados. El marco anterior tiene como objetivo proporcionar a la comunidad una forma de iniciar un proceso de desysop sin pasar por el proceso de hasta 2 meses de un caso ArbCom, al tiempo que brinda protección contra presentaciones frívolas. El requisito de actividad para los votantes es una forma de lidiar con el uso de calcetines, ya que desde que EC existe desde hace un tiempo, un montón de calcetines lo tienen. También tomé en cuenta el beneficio tradicional de un caso de ArbCom que le da a la persona bajo escrutinio tiempo para presentar su respuesta, permitiéndoles elegir cuándo realizar la transclusión. Creo que esto es justo cuando se trata de circunstancias de la vida real. El umbral del 60% se basa en la práctica estándar de en.wiki de requerir consenso para sancionar a alguien, y el consenso no es una mayoría pura. También es un número factible y no inalcanzable. No creo que esta sea una propuesta perfecta, pero sí creo que es un buen primer paso para un marco que proporcionará a las personas que creen que un administrador se ha comportado de manera inapropiada, pautas más claras sobre cómo proceder sin la necesidad de preocuparse por un ArbCom. caso, y también proporcionar al administrador bajo escrutinio equidad para evitar el ferrocarril. También estoy de acuerdo con el comentario de Sdkb a continuación de que esto probablemente se perfeccionará con el tiempo y es un punto de partida. TonyBallioni ( charla ) 20:43, 20 de febrero de 2021 (UTC)
- Observando que si hay consenso aquí, no me opongo a elevarlo al 65%. Además, según Tryptofish , esta es una discusión basada en el consenso, los umbrales numéricos son solo mínimos. Eso se puede aclarar al final / cuando esté escrito en la política si esto se aprueba. TonyBallioni ( charla ) 23:08, 20 de febrero de 2021 (UTC)
- Apoyo Esto parece que está bien pensado y tiene suficientes garantías para evitar que las solicitudes frívolas o de represalia se activen. - MelanieN ( charla ) 20:50, 20 de febrero de 2021 (UTC)
- Apoyo Creo que el requisito de endosos es particularmente útil para prevenir presentaciones de "rencor". Schazjmd (charla) 20:57, 20 de febrero de 2021 (UTC)
- Soporte No soy realmente un fanático de requerir tres administradores para iniciar un desysop, lo que creo que iría en contra de WP: TROPHY (es decir, otorgar a los administradores un estatus elevado en la comunidad). Sin embargo, ciertamente puedo ver por qué Tony sintió la necesidad de incluir eso como un requisito, lo que imagino ayudaría a evitar solicitudes frívolas de desysop. Dicho esto, todavía considero que esto es un resultado positivo neto, en lugar del mosaico de procesos de retiro voluntario que tenemos y que los administradores pueden o no seguir. OhKayeSierra ( charla ) 21:27, 20 de febrero de 2021 (UTC)
- Soporte , con la salvedad de que probablemente necesite ajustes en el futuro. Actualmente, no tenemos una buena forma de eliminar a los administradores que tienen derechos adquiridos y que realmente no deberían ser administradores. Puede que esto no sea perfecto, pero es algo y se puede perfeccionar con el tiempo a medida que comprendamos lo fáciles o difíciles que son los umbrales. {{u | Sdkb }} charla 21:41, 20 de febrero de 2021 (UTC)
- Sdkb , ¿podría ampliar lo que quiere decir con "derechos adquiridos"? - RoySmith
(conversación) 17:53, 21 de febrero de 2021 (UTC)
- @ RoySmith : Me refiero a los administradores que se convirtieron en administradores cuando no había estándares estrictos y retuvieron el bit. Ver cláusula del abuelo . {{u | Sdkb }} charla 18:05, 21 de febrero de 2021 (UTC)
- Sdkb , eso es lo que pensé. En otras palabras, ¿ gente como yo ? - RoySmith (charla) 18:12, 21 de febrero de 2021 (UTC)
- @ RoySmith : Me refiero a los administradores que se convirtieron en administradores cuando no había estándares estrictos y retuvieron el bit. Ver cláusula del abuelo . {{u | Sdkb }} charla 18:05, 21 de febrero de 2021 (UTC)
- Sdkb , ¿podría ampliar lo que quiere decir con "derechos adquiridos"? - RoySmith
(conversación) 17:53, 21 de febrero de 2021 (UTC)
- Soporte : creo que la comunidad debería tener un proceso para eliminar administradores sin la burocracia y la naturaleza de puertas cerradas de ArbCom, un proceso diseñado para la resolución de conflictos más que averiguar si un administrador ha conservado la confianza de la comunidad. Esta propuesta tiene las garantías adecuadas contra nominaciones frívolas y una barrera relativamente alta para eliminar el bit de administrador, lo que debería hacer que el proceso sea viable en los casos en que un administrador claramente necesita ser eliminado, pero permite que los administradores sujetos a disputas a pequeña escala sean retenidos. - Ajraddatz ( conversación ) 21:46, 20 de febrero de 2021 (UTC)
- Más estricto que mis propios procedimientos , así que estoy a favor. Parece lo suficientemente suave y fuerte como para permitir una gran aceptación al tiempo que limita el uso indebido / abuso y las trampas más comunes. ~ Amory ( u • t • c ) 21:58, 20 de febrero de 2021 (UTC)
- Para expandirme un poco, me tomo las preocupaciones en serio, pero parece que están divididas entre "demasiado estrictas" o "demasiado flexibles", lo cual (a riesgo de un argumento a la falacia de la moderación ) espero que sugiera que esto estará bien. . Parece que gran parte de la oposición restante se basa en la mera oposición a todo el concepto en sí y, por lo tanto, a nuestro consenso previo de WP: DESYSOP2019 . No estoy seguro de qué hacer con eso, pero será intratable si cada vez que se toma una decisión, intentar promulgar esa decisión falla porque todos los que inicialmente se opusieron a la idea se oponen a cualquier trabajo para promulgar la voluntad de la comunidad. ~ Amory ( u • t • c ) 12:05, 24 de febrero de 2021 (UTC)
- Soporte Este es un marco lo suficientemente decente como para darle una oportunidad. Por supuesto, los números son arbitrarios y pueden necesitar ajustes (especialmente después de que realmente se usan), pero no creo que estén demasiado fuera del campo de la izquierda. Cualquier cosa que rechace la narrativa de "la administración es de por vida" para aliviar potencialmente la presión en RfA es algo bueno. - T avix ( conversación ) 22:05, 20 de febrero de 2021 (UTC)
- Soporte . Esta propuesta utiliza aportes de toda la comunidad para responsabilizar a los administradores de las políticas y pautas. Una política de desysop tiene el potencial de reducir las expectativas en RfA , lo que alentaría a más editores a postularse para la administración y ayudaría a minimizar nuestros numerosos retrasos. Otros proyectos de Wikimedia han implementado con éxito métodos de desysop orientados a la comunidad, y también vale la pena probarlos aquí. - Charla de Newslinger 22:07, 20 de febrero de 2021 (UTC)
- ( editar conflicto × 2) Soporte Bien pensado. Parecen mis comentarios a continuación para mi única advertencia con respecto a los usuarios inactivos, pero eso no es suficiente para oponerme. Thryduulf ( conversación ) 22:07, 20 de febrero de 2021 (UTC)
- Soporte : propuesta muy bien pensada que corta muchas rutas para posibles abusos. Comparto la mayoría de las preocupaciones de Beeblebrox , pero en mi opinión personal, el plan de Tony las mitiga lo suficiente para que yo pueda apoyar lo que es un proceso muy necesario. ƒirefly ( t · c ) 22:21, 20 de febrero de 2021 (UTC)
- Soporte . Hace once años, fui el proponente principal del fallido WP: CDARFC , y pasé un período de tiempo algo desagradable volviendo a leer todas las objeciones que se plantearon a eso , para ver si alguna me parecía aplicable. aquí . Las propuestas son sorprendentemente similares, pero no iguales. (La anterior tenía un umbral del 65%, y no estoy seguro de si eso realmente marca la diferencia. Esta nueva propuesta requiere un consenso existente de un hilo que se cerró como una búsqueda de uso indebido de herramientas, y eso es una clara mejora). Creo que esta propuesta aborda adecuadamente las preocupaciones que se han planteado en el pasado sobre propuestas anteriores, y parece factible, a menos que uno simplemente no crea en permitir que la comunidad elimine el permiso. Con el tiempo, he llegado a sentir que ArbCom ha mejorado cada vez más en esto y, por lo tanto, he llegado a tener menos entusiasmo por un proceso basado en la comunidad, pero sigo pensando que esta propuesta puede satisfacer una necesidad. Quizás en-wiki finalmente esté listo para esto. Creo que esto podría funcionar. - Tryptofish ( charla ) 22:58, 20 de febrero de 2021 (UTC)
- Agregando que creo que la cosa del 60% debería ajustarse un poco hacia arriba, y que debería haber una declaración más explícita de que Crats tiene discreción para determinar el consenso. Esto debe ser sin voto. - Tryptofish ( charla ) 23:04, 20 de febrero de 2021 (UTC)
- Tryptofish , estoy completamente de acuerdo, debe ser una discusión así que "Desysop - ¡tenemos demasiados administradores"! Los votos no cuentan mucho. Ritchie333 (charla) (continuación) 10:54, 21 de febrero de 2021 (UTC)
- Después de leer más comentarios en esta discusión, quiero sugerir agregar el siguiente lenguaje a la parte sobre discusiones anteriores de AN / ANI: "... hubo consenso de que el administrador se comportó de manera inapropiada , y para lo cual se proporcionan diferencias de que el administrador posteriormente rechace o ignorando ese consenso ". - Tryptofish ( conversación ) 23:14, 21 de febrero de 2021 (UTC)
- Agregando que creo que la cosa del 60% debería ajustarse un poco hacia arriba, y que debería haber una declaración más explícita de que Crats tiene discreción para determinar el consenso. Esto debe ser sin voto. - Tryptofish ( charla ) 23:04, 20 de febrero de 2021 (UTC)
- Soporte . De hecho, necesitamos un proceso comunitario para eliminar la administración para reducir el miedo que se manifiesta como falta de voluntad para promover candidatos en RfA, e independiente del proceso brutal de ArbCom y, a menudo, decisiones aparentemente arbitrarias y las implicaciones de un caso de ArbCom de que alguien haya hecho algo inconcebible ( ArbCom debería lidiar principalmente con situaciones extremas). Comparto la preocupación de que los números puedan necesitar ajustes, en particular el porcentaje de apoyo, que parece bajo ya que necesitamos administradores lo suficientemente valientes para tomar medidas en áreas polémicas. También tengo algunos reparos en usar el estado confirmado extendido como parte de las calificaciones para la certificación, pero dado que existe, sí, es una métrica válida. Sugiero encarecidamente que haya un límite para la participación en la eventual discusión de desysop al mismo nivel que para la certificación, ya que el 60% es mucho más bajo que el nivel mínimo de soporte habitual para una RfA exitosa, y no veo nada en la propuesta impide que los editores recién registrados y no registrados voten, a menos que se suponga que esté implícito en la ubicación de la discusión en la página de RfA. No comparto la preocupación por las 48 horas, ya que le sigue un período de 14 días, pero debería existir el requisito de notificar al administrador en las tres etapas y sugiero solicitar una notificación por correo electrónico además de en la wiki. (la última vez que verifiqué, se espera que los administradores tengan activado el correo electrónico). Finalmente, creo que debo agregar que la preocupación no es únicamente con los administradores "heredados" o incluso con los administradores heredados "oxidados". Sigo oponiéndome a los requisitos de actividad para los administradores, en parte porque los sugeridos nunca han capturado acciones no registradas como eliminar una etiqueta WP: G4 después de mirar el artículo previamente eliminado y determinar que el nuevo es diferente, o desactivar un conflicto explicando el tema. a un nuevo editor, y queremos administradores que eliminen los conflictos más que administradores que se pavonean por bloquear a todos los que están a la vista o eliminar todo lo nominado para rápido. Pero también porque es un proyecto voluntario y RL existe, al igual que fuera de la wiki. Algunos administradores "legado", incluyendo algunos que vuelven a los años posteriores del proyecto, son valiosos vínculos cuando el proyecto fue la creación de contenido y sobre audazmente no ser una
vergarellena la camisa... un estorbo. Al ritmo de la WMF , hay una diferencia entre sabiduría y claridad y "abuso de antigüedad y conexiones". Y algunos administradores abusivos han sido corrompidos por su poder desde RpA mucho más recientes en la era posterior a la "no gran cosa". Yngvadottir ( charla ) 23:01, 20 de febrero de 2021 (UTC)- Yngvadottir , para mayor claridad, existe un requisito que prohíbe la participación en la discusión a las mismas métricas que se usan para certificar: los
usuarios que comenten deben cumplir con los requisitos para presentar una solicitud de desysop para apoyar u oponerse, pero pueden hacer comentarios generales si no califican .
TonyBallioni ( charla ) 23:04, 20 de febrero de 2021 (UTC)- ¡Oh bien, gracias! Seguí retrocediendo para volver a leer la propuesta, pero no pude encontrarla. También agregaré aquí que me opongo mucho al apéndice de Tryptofish : los burócratas han perdido por completo mi confianza en que disciernen un consenso en los RpA que caen dentro o por debajo del rango discrecional, en contraposición a la supervotación. Esta debe ser una votación directa, como se propone. Yngvadottir ( charla ) 23:10, 20 de febrero de 2021 (UTC)
- Yngvadottir , para mayor claridad, existe un requisito que prohíbe la participación en la discusión a las mismas métricas que se usan para certificar: los
- Apoyo ; relativamente similar a lo que ya he acordado ( Usuario: ToBeFree / recall ) basado en una buena experiencia con el procedimiento en la Wikipedia alemana. Con respecto a la "solicitud de desysop" ya certificada, que se incluyó para su discusión en WP: RfA, si es posible, preferiría que el administrador en discusión tenga el primer párrafo en la página, o una sección destacada para refutación, encima de los votos. ~ ToBeFree ( charla ) 23:13, 20 de febrero de 2021 (UTC)
- Apoye este plan tan necesario y bien pensado. En la actualidad, es demasiado difícil lidiar con administradores abusivos. Xxanthippe ( charla ) 23:24, 20 de febrero de 2021 (UTC).
- Me gustaría ver alguna evidencia de que 'es demasiado difícil lidiar con administradores abusivos', Xxanthippe , y no creo que este fuera el espíritu con el que se lanzó esta propuesta. Más en la sección de comentarios a continuación. Kudpung กุด ผึ้ง ( charla ) 07:46, 21 de febrero de 2021 (UTC)
- Soporte en principio. Sugeriría algunos refinamientos menores (ver la sección de Comentarios), pero esta es una propuesta razonable que evita los rencores contundentes. - BillHPike ( charla , contribuciones ) 23:29, 20 de febrero de 2021 (UTC)
- Soporte . Claro y bien pensado con controles y contrapesos. El marco funciona (aunque aclararía en el paso 1. es AN / ANI y no NAC) y las métricas se pueden refinar con el tiempo. Creo que el Paso 3. también sería útil para ArbCom, que podría enviar los casos de ADMINACCT directamente. Britishfinance ( conversación ) 23:35, 20 de febrero de 2021 (UTC)
- Apoyo : sobre la base de no dejar que lo perfecto se convierta en enemigo de lo bueno; los detalles se pueden modificar a medida que aprendemos de la experiencia y, en mi opinión, esta es una propuesta suficientemente buena para empezar. Levivich acosar / perro doce y catorce, 21 de Febrero 2021 (UTC)
- Estoy de acuerdo con Rschen a continuación.
La única forma en que vamos a obtener una propuesta mejor en este punto es obtener más datos.
Datos> opiniones. Hay tantas personas que se oponen a esto porque es demasiado estricto, como hay personas que se oponen a esto porque es demasiado laxo. La gente argumenta que nadie será desocupado, o que habrá turbas con horquillas y antorchas. Podemos discutir sobre esto durante otros 10 años, o podemos intentar algo y recopilar algunos datos. Algunos de nosotros estamos equivocados; averigüemos, por fin, quién. Probémoslo. Observo que en 10 años no hemos tenido un retiro del mercado, a pesar de que más de un centenar de administradores se pueden recuperar voluntariamente. Así que eso debería aliviar las preocupaciones de la "turba". También observo que no importa cuán engorroso sea este sistema, es menos engorroso que ningún sistema , que es lo que tenemos ahora. Eso debería aliviar las preocupaciones "demasiado estrictas". Creo que casi todas las partes de esta propuesta deberían cambiar: no estoy de acuerdo con cada umbral, cada paso, casi cada detalle. Pero aún lo apoyo, porque es mejor probarlo y ver cómo funciona en la práctica, en lugar de discutir interminablemente sobre teorías. Levivich acoso / sabueso 20:23, 25 de febrero de 2021 (UTC) - Estoy totalmente de acuerdo con el meollo del voto oponer! De L235 a continuación (
no necesitamos otro proceso para eliminar administradores por mala conducta; necesitamos uno para eliminar administradores por perder la confianza de la comunidad
), y casi me hace reconsiderar mi apoyo. Pero sigo apoyando esto, porque aunque está demasiado orientado a la mala conducta y no lo suficiente a la confianza de la comunidad, eso se puede solucionar cambiando los detalles. Como dije anteriormente, no estoy de acuerdo con casi todos los detalles, lo que básicamente significa que creo que este sistema propuesto fallará. Sin embargo, creo que obtendremos mucha información muy valiosa al ver exactamente cómo y dónde falla: ¿está en el cierre de los hilos de ANI sobre administradores? ¿En fase de aval? ¿En la transclusión? ¿En el umbral de conteo final? Sé que no estoy de acuerdo con todos esos detalles, pero no estoy seguro de cuál necesita ser ajustado y exactamente cómo. Realmente no lo sabremos hasta que lo intentemos. Levivich acoso / sabueso 04:26, 3 de marzo de 2021 (UTC)- Levivich , lo siento, tuve que empezar a responder al "Realmente no lo sabremos hasta que lo intentemos" / "... básicamente significa que creo que este sistema propuesto fallará". tipo de comentarios. Como esta propuesta está escrita actualmente, todo lo que necesita es a) ser un administrador no muy popular yb) un hilo AN / I negativo. Excepto por WP: UNBLOCKABLES, que es la gran mayoría de los administradores (muchos están activos en áreas no muy populares de wikipedia, y no toman decisiones demasiado populares, supongo que aproximadamente la mitad de la comunidad es inclusiva y no está contenta con muchos eliminaciones, ya que creen que el artículo se puede mejorar, y la otra mitad de la comunidad es más delecionista y no está de acuerdo con los fáciles de mantener; algunos administradores me gritaron porque (legítimamente) incluí en la lista negra un enlace (muy spam) que necesitaban una vez , diablos, hice que un administrador lo eliminara sin rodeos porque lo necesitaban, inmediatamente después de lo cual se reinició felizmente la eliminación de spam). Intentar esta propuesta tal como está corre el riesgo de que primero desysop 10-20% de nuestros administradores, y luego concluyamos 'meh, tal vez esta no fue una buena propuesta después de todo'. SI queremos probar esto, debemos establecer nuestros estándares de selección en el lado estricto y luego aflojarlos lentamente, no 'un golpe y estás fuera', causar daños colaterales y luego decidir que la propuesta fracasó. Y es posible que esos no necesariamente se hayan eliminado porque perdieron la confianza en la comunidad. Dirk Beetstra T C 07:34, 3 de marzo de 2021 (UTC)
- Estoy de acuerdo con Rschen a continuación.
- Soporte como mejor que nada. Mi sospecha es que este proceso propuesto es lo suficientemente complejo como para que nunca se utilice. Pero siempre podemos modificarlo en el futuro si la gente está interesada. Ajpolino ( charla ) 00:46, 21 de febrero de 2021 (UTC)
- Solo una nota para agregar que mi preferencia es mantener el umbral del 60% o menos (apoyaría hasta al menos el 50%, posiblemente más bajo). El 65%, como algunos han sugerido, parece estirarlo. Si la mayoría de los editores en una discusión quieren que les entregue las herramientas, probablemente sea mejor que las entregue. Dicho esto, estoy feliz de que los "crats" tengan cierto margen de maniobra, como lo hacen ahora en RfA. Ajpolino ( charla ) 05:57, 21 de febrero de 2021 (UTC)
Soportecon la advertencia de que espero que haya algunos cambios después de que veamos cómo funciona esto en la práctica. Esto no es una vía libre para mover a cuentas de desadministración, es solo una forma para que la comunidad maneje algunos casos de disciplina sin pasar por los procedimientos de ARBCOM. power ~ enwiki ( π , ν ) 00:51, 21 de febrero de 2021 (UTC) (movido a neutral Usuario: 力(power ~ enwiki, π , ν ) 01:50, 31 de marzo de 2021 (UTC))
- Apoyo Creo que este es un buen intento de una política de desysop que hasta la fecha ha estado muy ausente. Creo que la propuesta tiene controles suficientes para garantizar que no se utilice indebidamente y respalde su implementación. Con suerte, esto podría actuar como una alternativa a Arbcom y ayudar a la comunidad a sentirse más empoderada para lidiar con el raro caso de mal uso del poder administrativo .-- Tom (LT) ( charla ) 01:52, 21 de febrero de 2021 (UTC)
- Fuerte apoyo : esto me parece una propuesta excepcionalmente razonable y justa, realmente no puedo ver ningún defecto obvio en ella. Le da a la comunidad un proceso realista para destituir a alguien por una causa, de una manera que no es demasiado difícil, pero incluye suficientes advertencias y restricciones para evitar que sea armado de manera disruptiva o injusta. Podemos jugar el juego de "qué pasaría si" y nunca llegar a ninguna parte, o podemos implementar una buena propuesta, probablemente tan buena como sea posible, con el entendimiento de que si se presenta algún defecto, el proceso siempre se puede modificar según sea necesario. ~ Swarm ~ {picadura} 01:57, 21 de febrero de 2021 (UTC)
- Es perfecto No, pero perfecto / enemigo de lo bueno y todo eso. Pero las variaciones de esta propuesta han estado activas durante años en múltiples wikis grandes y más o menos parece haber funcionado bien para ellos. Es hora de que demos más responsabilidad a los administradores de enwiki. - Rs chen 7754 03:49, 21 de febrero de 2021 (UTC)
- Algunas reflexiones adicionales: la única forma en que vamos a obtener una mejor propuesta en este momento es obtener más datos. Podemos hacer ajustes en una fecha posterior cuando veamos cómo funciona esta propuesta. También creo que tenemos que dar cuenta de un mundo posterior a WP: FRAM aquí, y la presión de la WMF para que nuestros administradores sean más responsables de su conducta, incluso si no se relaciona con el uso de herramientas. - Rs chen 7754 01:38, 24 de febrero de 2021 (UTC)
- Apoyo, como otros han dicho anteriormente, no podemos permitir que lo perfecto se convierta en enemigo de lo bueno. Hace mucho que necesitamos algún tipo de procedimiento de desysop basado en la comunidad. La comunidad es competente para otorgar las herramientas y la comunidad es igualmente competente para quitárselas. L EPRICAVARK ( conversación ) 03:58, 21 de febrero de 2021 (UTC)
- Apoyo No sé cómo funcionará esto en la práctica, pero esa no es una razón suficiente para oponerse. Hawkeye7 (discutir) 03:59, 21 de febrero de 2021 (UTC)
- Soporte . Tony tiene grandes ideas y esta es buena. ArbCom no necesita ser el alfa y omega para todas y cada una de las revocaciones del sistema. Sin decir que debería renunciar a su función de desysop, pero tener otra opción que, también, establezca las salvaguardias adecuadas, eso es algo bueno. Confío en nuestros administradores, confío en nuestros burócratas y confío en la comunidad. Este es un progreso. El_C 04:43, 21 de febrero de 2021 (UTC)
- Soporte . Atrasado. Es casi imposible eliminar a un administrador abusivo y este es un paso en la dirección correcta. - F ASTILAMENTE 05:32, 21 de febrero de 2021 (UTC)
- No diría que es particularmente casi imposible Fastily . Arbcom se ha hecho una tarea fácil para ellos en los últimos tiempos, casi alineando a los administradores contra la pared y disparándoles en una sesión ... Kudpung กุด ผึ้ง ( charla ) 07:37, 21 de febrero de 2021 (UTC)
- Soporte Esto solo puede beneficiar a la enciclopedia: los administradores deben ser extremadamente responsables de todas las acciones. Más concretamente, la percepción de que los administradores son más responsables ante el mundo exterior solo puede beneficiar al proyecto. Hace que la gente crea que somos más justos y que se reducirán las posibilidades de que un administrador les "aproveche". Desafortunadamente, puedo ver que existe una oposición significativa a la propuesta específica más que a la idea general . Por favor, reconsidere y confíe en que el panorama general de permitirnos mantener a los administradores bajo control es más importante que los detalles prácticos: piense en el bien mayor o el mal menor, por así decirlo. De hecho, me atrevería a sugerir que cualquier voto de un administrador que se oponga a esto debería tener menos peso, ya que tienen un conflicto de intereses. Ritchie333 (charla) (continuación) 10:23, 21 de febrero de 2021 (UTC)
- Soporte por nom. Tal vez aumente el bit de 48 horas a 72 horas para tener en cuenta los fines de semana largos, feriados bancarios y similares. Lugnuts Fire Walk with Me 10:25, 21 de febrero de 2021 (UTC)
- Soporte . Esta es una buena propuesta, y aunque estoy dispuesto a negociar algunos detalles, incluidos los números, me parecen razonables en la primera aproximación. Sí, este procedimiento definitivamente se utilizará para acosar a los administradores, no hay duda de esto. Pero los administradores activos están siendo objeto de acoso constante de todos modos, y la comunidad no está dispuesta o no puede hacer nada en el 90% de los casos (el peor de los casos que me sucedió tuve que informar a la policía, y tenía sitios externos específicamente fundados para difundir mentiras deliberadas sobre mi vida personal; no veo cómo la nominación al puesto de Deadmins sería peor). Para ser honesto, no preveo que este procedimiento se use con frecuencia; para empezar, no tenemos tantos subprocesos AN (I) formalmente cerrados, incluso menos cerrados con un consenso explícito de que un administrador tuvo la culpa, y en el En los casos límite, en realidad es más difícil lograr el consenso de ANI que lograr que ArbCom analice el caso, pero creo que es importante tener este procedimiento .-- Ymblanter ( charla ) 10:28, 21 de febrero de 2021 (UTC)
- Hola, te apoyo . No hay ningún artículo sobre mí en en.wp, pero posiblemente podría haber uno de un día ( charla ) 11:17, 21 de febrero de 2021 (UTC)
- Nota: El editor anterior, cuya cuenta se creó el 5 de febrero, tiene 5 ediciones, dos para artículos, dos para su propia página de discusión y la edición anterior. Beyond My Ken ( charla ) 17:37, 21 de febrero de 2021 (UTC)
- Apoyo. Mi principal motivación para apoyar es que necesitamos algún proceso implementado. Reconozco e incluso estoy de acuerdo con algunas de las objeciones publicadas en la sección de comentarios. Sin embargo, creo que tener un sistema funcional en su lugar aumentará la confianza en el desempeño de los administradores en la comunidad en general. Tide rolls 13:53, 21 de febrero de 2021 (UTC)
- Soporte Tiene que haber una mejor manera de eliminar a los administradores que han perdido la confianza de la comunidad que los casos completos de ArbCom, y esta propuesta tiene suficientes garantías para evitar juegos o acoso. P-K3 ( conversación ) 14:31, 21 de febrero de 2021 (UTC)
- Apoye la propuesta en su conjunto. Sin embargo, no puedo cumplir con el requisito de aprobación de tres administradores. Supongo que la intención del requisito es tener al menos tres contribuyentes respetados a largo plazo que muy probablemente se incluirían en una solicitud exitosa. ¡Gran paso en la dirección correcta! - Dolotta ( conversación ) 14:38, 21 de febrero de 2021 (UTC)
- Soporte en principio, con los detalles por resolver. Podría ser bueno tener un RfC de informe planificado después de un incidente para ver si las cosas funcionaron según lo previsto o si era necesario modificarlas. —Valereee ( conversación ) 15:57, 21 de febrero de 2021 (UTC)
- ETA: de acuerdo con BK49, el problema de la renuencia a cerrar una AN / I de una manera que apoye o no esto debe abordarse, y sí, un voto para desysop de más de la mitad pero menos que el umbral es una preocupación. . —Valereee ( conversación ) 22:57, 22 de febrero de 2021 (UTC)
- Apoyo Estoy de acuerdo precisamente con los comentarios de Tide rolls; días felices, Lindsay H ello 16:31, 21 de febrero de 2021 (UTC)
- Soporte Creo que la fecha límite para la aprobación extendida de 10 editores confirmados es un poco corta, según Lugnuts, pero en general, la política propuesta es una gran reforma. Además, una vez implementado, estoy seguro de que podemos revisarlo según sea necesario. P, TO 19104 ( charla ) ( contribuciones ) 17:20, 21 de febrero de 2021 (UTC)
- Apoyo con la expectativa de que se modifiquen los detalles, y con agradecimiento a TB por haberlo hecho, y una nota a los opositores: "Lo perfecto es enemigo de lo bueno". Beyond My Ken ( charla ) 17:32, 21 de febrero de 2021 (UTC)
- Soporte por BMK; "Lo perfecto es enemigo de lo bueno", de hecho. Como menciona GiantSnowman en la sección de comentarios, parece un poco extraño exigir que el administrador en cuestión transcluya su propia solicitud de desysop; parece como pedirle a un usuario que construya su propia horca. (No soy realmente un fanático de este tipo de hipérbole, pero es la única metáfora que me viene a la mente). Sin embargo, el comentario de TB en respuesta a eso tiene sentido, así que creo que deberíamos agregar algo de lenguaje para formalizar que puede pedirle a un crat que lo haga por ellos si lo desean. Pero independientemente, no creo que eso sea un factor decisivo. Writ Keeper ⚇ ♔ 18:10, 21 de febrero de 2021 (UTC)
- Soporte . La propuesta de política es detallada, bien pensada y parece difícil de abusar. Estoy abierto a considerar enmiendas a la política, pero este es un buen comienzo. - codificador de Python ( charla | contribuciones ) 19:37, 21 de febrero de 2021 (UTC)
- Apoye el principio. Si esto pasa, esperaría una discusión más detallada sobre el proceso exacto. Cosas como 10 usuarios, 48 horas, etc. se pueden ajustar más tarde. No estoy de acuerdo con el requisito de que tres editores deban ser administradores. - Martin ( MSGJ · charla ) 20:57, 21 de febrero de 2021 (UTC)
- Tengo mis reservas sobre los detalles (siento que esto nunca terminaría siendo utilizado realmente debido al proceso complicado) pero es necesario tener un proceso de desysop comunitario. Moneytrees🏝️ Talk / CCI help 22:06, 21 de febrero de 2021 (UTC)
- Soporte por Pythoncoder. JJP ... ¡MAESTRO! [hablar con] JJP ... maestro? 22:19, 21 de febrero de 2021 (UTC)
- Mis sentimientos reflejan los de MSGJ . ¡ Consultame SQL ! 23:32, 21 de febrero de 2021 (UTC)
- Una propuesta completa que me inclino a ver implementada. Está claro que el método actual no es satisfactorio y esta propuesta parece una solución adecuada. Estoy seguro de que la mayoría de los problemas relacionados con el acoso o la evidencia singular se abordarán de manera adecuada en el paso de revisión inicial de 10 usuarios confirmados extendidos y 3 administradores. Aza24 ( charla ) 00:24, 22 de febrero de 2021 (UTC)
- Lo perfecto es enemigo de lo bueno - Guerillero Parlez Moi 04:08, 22 de febrero de 2021 (UTC)
- Apoyo. Estoy completamente de acuerdo con otros sobre esto: tres administradores es mucho
(mi preferencia es que no haya administradores), 48 horas es demasiado corto, y acercarme a AN que mencione específicamente el abuso de herramientas será extremadamente improbable. Sin embargo, esta podría ser la primera propuesta de política de des-sysop exitosa en la historia de Wikipedia, y ciertamente no es nada allí. Podemos discutir las enmiendas sobre los detalles más tarde (o tal vez el más cercano lea la discusión y encuentre un consenso para que se implementen los cambios relevantes ... ilusiones, lo sé). Sin embargo, ahora mismo, deberíamos dar este paso a la vez para hacer las correcciones correctas más adelante. - MJL - Talk - ☖ 07:51 , 22 de febrero de 2021 (UTC)- Para el registro, tampoco soy un fanático de que el administrador tenga que transcluir su propia solicitud de des-sysop (suena honestamente terriblemente malvado)
, y también creo que debería ser un umbral del 65% (y probablemente no debería ser tan discrecional como lo es una RFA). - MJL - Talk - ☖ 07:55, 22 de febrero de 2021 (UTC)- Permítanme explicar por qué creo que no hay administradores no es una buena idea. Imagínese al usuario A obsesionado con el administrador B hasta el punto de que no puede ver su nombre. Si están determinados, pueden crecer 10 o 15 de cualquier usuario confirmado extendido para certificar la solicitud de desysop (después de que B una vez se haya metido en problemas en ANI). Pero no hay forma de que puedan hacer crecer una cuenta de administrador, porque el administrador es actualmente casi la única marca que se da como resultado de la discusión de la comunidad (sin tener en cuenta la interfaz de administrador, que no prueba las cualidades relevantes para esta situación, y burócrata y árbitro, que en la práctica son siempre administradores). Claro, hay algunos administradores que aprobaron RfA hace mucho tiempo, y donde hay dudas sobre si están en contacto con la comunidad, pero aún así es mejor que nada .-- Ymblanter ( charla ) 08:26, 22 de febrero de 2021 (UTC)
- Todo el mundo quiere que el sistema sea iniciado únicamente por editores "reales". Pero no necesitamos que "admin" sea la forma de distinguir a los editores "reales" de los calcetines EC. Otra forma posible de examinar a los iniciadores es requerir editores "veteranos", independientemente de cómo se defina: tal vez 1 año / 10k ediciones, tal vez 2 años / 20k ediciones ... requieren 10 de ellos para iniciar una petición. No creo que un sockmaster pueda crear 10 de esos tipos de cuentas, y si lo hacen: quiero decir, si pueden ejecutar 10 cuentas con 20k ediciones durante 2 años ... entonces, mierda, déjelos comenzar el proceso de eliminación de RFA. , ¡se lo han ganado! :-D Levivich acoso / sabueso 18:38, 26 de febrero de 2021 (UTC)
- @ Levivich : Para ser honesto, probablemente debería ser como 1 o 2 administradores. Sería bueno que alguien que haya pasado por una RFA exitosa (y sepa cómo puede ser) opinar afirmativamente sobre el asunto antes de que se deba tomar una acción tan drástica. - MJL - Talk - ☖ 18:43, 26 de febrero de 2021 (UTC)
- Ningún administrador querrá certificar uno de estos, predigo. Y si algún administrador alguna vez certificara uno de estos, sería solo porque las circunstancias eran tales que Arbcom desaparecería de todos modos. No creo que un proceso de desysop comunitario funcione si requiere la aprobación de un administrador. En los parlamentos, cuando hay un voto de censura en el primer ministro, no se necesita que un miembro del liderazgo lo apruebe, porque ningún miembro del liderazgo lo haría jamás. (Sigo apoyando esto, porque yo podría estar equivocado.) Levivich acosar / perro 18:48, 26 de Febrero 2021 (UTC)
- De hecho, esto no es correcto. Cuando apliqué a BN para recuperar mis herramientas (esto fue, creo, en junio de 2018), tenía alrededor de cinco administradores que se opusieron fuertemente, uno de ellos dijo que debería estar feliz de no haber sido bloqueado indef. Estoy seguro de que habrían certificado al desysop. Recuperé las herramientas. No se habló seriamente sobre un caso de ArbCom de ninguna sustancia real .-- Ymblanter ( charla ) 18:55, 26 de febrero de 2021 (UTC)
- Ningún administrador querrá certificar uno de estos, predigo. Y si algún administrador alguna vez certificara uno de estos, sería solo porque las circunstancias eran tales que Arbcom desaparecería de todos modos. No creo que un proceso de desysop comunitario funcione si requiere la aprobación de un administrador. En los parlamentos, cuando hay un voto de censura en el primer ministro, no se necesita que un miembro del liderazgo lo apruebe, porque ningún miembro del liderazgo lo haría jamás. (Sigo apoyando esto, porque yo podría estar equivocado.) Levivich acosar / perro 18:48, 26 de Febrero 2021 (UTC)
- @ Levivich : Para ser honesto, probablemente debería ser como 1 o 2 administradores. Sería bueno que alguien que haya pasado por una RFA exitosa (y sepa cómo puede ser) opinar afirmativamente sobre el asunto antes de que se deba tomar una acción tan drástica. - MJL - Talk - ☖ 18:43, 26 de febrero de 2021 (UTC)
- @ Ymblanter : Notado y afectado. ( editar conflicto ) - MJL - Charla - ☖ 18:40, 26 de febrero de 2021 (UTC)
- Todo el mundo quiere que el sistema sea iniciado únicamente por editores "reales". Pero no necesitamos que "admin" sea la forma de distinguir a los editores "reales" de los calcetines EC. Otra forma posible de examinar a los iniciadores es requerir editores "veteranos", independientemente de cómo se defina: tal vez 1 año / 10k ediciones, tal vez 2 años / 20k ediciones ... requieren 10 de ellos para iniciar una petición. No creo que un sockmaster pueda crear 10 de esos tipos de cuentas, y si lo hacen: quiero decir, si pueden ejecutar 10 cuentas con 20k ediciones durante 2 años ... entonces, mierda, déjelos comenzar el proceso de eliminación de RFA. , ¡se lo han ganado! :-D Levivich acoso / sabueso 18:38, 26 de febrero de 2021 (UTC)
- Permítanme explicar por qué creo que no hay administradores no es una buena idea. Imagínese al usuario A obsesionado con el administrador B hasta el punto de que no puede ver su nombre. Si están determinados, pueden crecer 10 o 15 de cualquier usuario confirmado extendido para certificar la solicitud de desysop (después de que B una vez se haya metido en problemas en ANI). Pero no hay forma de que puedan hacer crecer una cuenta de administrador, porque el administrador es actualmente casi la única marca que se da como resultado de la discusión de la comunidad (sin tener en cuenta la interfaz de administrador, que no prueba las cualidades relevantes para esta situación, y burócrata y árbitro, que en la práctica son siempre administradores). Claro, hay algunos administradores que aprobaron RfA hace mucho tiempo, y donde hay dudas sobre si están en contacto con la comunidad, pero aún así es mejor que nada .-- Ymblanter ( charla ) 08:26, 22 de febrero de 2021 (UTC)
- Modifiqué mi comentario para reflejar un malentendido que tuve con el umbral del 65%, ya que no creo que deba cambiarse. También quiero señalar que tengo mucho peso con respecto al voto opuesto de Sandstein , y creo que cualquier proceso que pueda castigar a un administrador por tomar medidas contra un IMBLOQUEABLE es fundamentalmente defectuoso. Sin embargo, como señala Swarm , lograr que el 40% de los usuarios lo apoyen en una RFA es bastante trivial, y tengo que imaginar que hay suficiente voluntad en esta comunidad para que esa cantidad de usuarios quiera retener a ese administrador. ( editar conflicto ) - MJL - Charla - ☖ 18:40, 26 de febrero de 2021 (UTC)
- Para el registro, tampoco soy un fanático de que el administrador tenga que transcluir su propia solicitud de des-sysop (suena honestamente terriblemente malvado)
- Aterrizo aquí, en general. No me gusta el obstáculo número 1, en gran parte la nota de los 6 meses, la idea de que si un administrador comete un "error" y especialmente si está arrepentido y lo acepta como un error, debería estar mirando por encima del hombro para el próximo 6 meses no sienta bien. Sin embargo, creo que el obstáculo número 2 es excelente, tanto que he estado manteniendo algo similar en mi proceso de recuperación durante una década. Realmente no veo la necesidad del obstáculo 1 si el obstáculo 2 está ahí, por eso estoy apoyando, no hay "mirar por encima del hombro" si hay una salvaguarda decente como esa. Entonces, si tiene 10 usuarios en buen estado que piensan que ya no debería ser un administrador, ese es un umbral razonable para un proceso de desysop. No estoy seguro de que me guste que RfA sea el proceso, pero es simple y bien entendido por la comunidad. Eso deja la pregunta de "necesitamos este proceso". Bueno, yo diría que sí. Kudpung menciona a continuación que él y yo trabajamos en WP: BARC hace unos años, un proceso de desysop comunitario que obtuvo el apoyo mayoritario , incluso si no se implementó. Este proceso es más simple: ya he mencionado lo cerca que está de mi proceso de recuperación, un proceso que creo firmemente que es necesario. La administración de por vida es un problema enorme en la comunidad de Wikipedia: es un rol que requiere trabajo y tiene una responsabilidad asociada. La responsabilidad de mantenerse al día con los cambios, con asegurar que se siga tratando a las personas con respeto. La expectativa de dar un buen ejemplo. Sin embargo, la barrera para la desocupación en este momento es un caso arbcom. En primer lugar, eso significa alcanzar el umbral de un caso aceptado: bastantes arbs, incluido yo, tienen un umbral más bajo para aceptar casos de conducta administrativa, pero aún es confuso. En segundo lugar, pasar por un caso arbcom. Poca gente quiere hacer eso. Este proceso es mucho más claro. Tengo algunas preocupaciones, que abordaré en los comentarios. Worm TT ( charla ) 10:37, 22 de febrero de 2021 (UTC)
- Soporte : la necesidad de una declaración de cierre de AN (I) que indique mala conducta en los últimos 6 meses y el requisito de que se incluyan 3 administradores en la solicitud de discusión de desobediencia me hacen pensar que el mal uso sería suficientemente raro. Apoyo más rutas para que la comunidad desysop porque creo que se están produciendo casos de administradores que se comportan con descortesía constante y que alejan a los editores (tanto nuevos como antiguos) del proyecto, creo que ArbCom no acepta los casos necesarios y, por lo demás, es menos adecuado para evaluar ciertos tipos de problemas que la comunidad (como los casos en los que muchas personas de ArbCom tendrían que recusarse) y nadie quiere que la WMF se involucre. Durante más de una década, la gente se ha estado quejando, al menos en RfA, por la falta de procedimientos adecuados para desysop y necesitamos al menos probar este. No es un pacto suicida y el fracaso en la práctica podría hacer que este proceso se elimine por consenso de la comunidad, pero el momento de actuar es ... bueno, 2010, pero dado que estamos en esta posición, el momento de actuar es ahora. Animo a cualquiera que se preocupe por los detalles (% de edad, número de patrocinadores, etc.) a que solo apoye porque números como estos se ajustan mejor a través de la práctica (como lo era el porcentaje de respaldo necesario en RfA) y nadie puede llegar a priori cifras que todos mirarán y dirán "eso es exactamente correcto". Me absolutamente no apoyar el requisito de que una solicitud desysop debe pasar por este proceso antes de ArbCom se lo lleva, o viceversa. Deberíamos ver esto como dos lugares que se adaptan mejor a diferentes situaciones, pero si se presenta un lugar con una solicitud que necesita ser atendida, entonces debería aceptarla en lugar de pasar la pelota. - Bilorv ( conversación ) 13:17, 22 de febrero de 2021 (UTC)
- Apoyo De acuerdo con la propuesta. Abhishek0831996 ( charla ) 13:25, 22 de febrero de 2021 (UTC)
El apoyoprobablemente el comentario de Bilorv anterior me ha convencido más, pero también una discusión con Tony. Sin embargo, me gustaría enfatizar la segunda parte del comentario de Bilorv con respecto a ArbCom, que fue mi mayor preocupación. Esta propuesta no puede convertirse en un requisito de facto antes de que se escuche un problema en ArbCom. No debería alterar en absoluto las expectativas de que ArbCom conozca un caso. En particular, porque esta propuesta solo requiere un 40% de apoyo de la comunidad para que un administrador retenga el bit, y también porque creo que algunos problemas se benefician más de la estructura de un caso. Además, me opongo a elevar el umbral de soporte al 65% (es decir, al 35% de la comunidad a favor de que se retenga el bit). También señalando explícitamente que no creo en absoluto las preocupaciones de que esto sea mal utilizado; mi única preocupación es que la gente piense que esto puede resolver repentinamente todas las formas de mala conducta administrativa, lo cual no puede. ProcrastinationReader ( charla ) 14:30, 22 de febrero de 2021 (UTC)- Y nuevamente, Joe Roe y Hammersoft me hacen reconsiderar esta posición. Supongo que esta es una propuesta que realmente quiero apoyar, pero mis comentarios anteriores se refieren principalmente a que esto podría afianzar inadvertidamente la dificultad de desocupar aún más (sospecho que ArbCom asumirá incluso menos casos de uso indebido del sistema que ahora si esto pasa, aprovechando al máximo administradores populares más difíciles de desysop) y Joe Roe hace buenos puntos en ese sentido y algunos de Hammersoft son interesantes en otros aspectos de esta propuesta. ProcrastinationReader ( charla ) 12:12, 24 de febrero de 2021 (UTC)
- Soporte : vale la pena intentarlo; se puede modificar más tarde si es necesario. Graham 87 15:29, 22 de febrero de 2021 (UTC)
- Soporte Creo fundamentalmente que es un proceso roto en el que la comunidad no ha podido eliminar el bit de un administrador por una causa. Creo que a veces provoca una atmósfera de comunidad poco saludable entre editores de mucho tiempo que no son administradores y administradores. Estamos todos juntos en esto, la comunidad es bastante sofisticada en general en estos días, y ArbCom no debería ser la única opción para despojar a la gente. Es por eso que tengo mi propio procedimiento de retiro, pero preferiría un proceso comunitario estándar, así que aquí estoy votando por esto. Ahora, dicho esto, permítanme expresar todas mis preocupaciones con esta propuesta con la esperanza de que el cerrador sea lo suficientemente sofisticado como para aceptar las críticas que veo no solo de quienes se oponen / son neutrales sino de quienes apoyan al elaborar una declaración de cierre (asumiendo que esto gane consenso ). Creo que esta propuesta presume que la cultura actual de AN / ANI continuará después de que esto pase. Si esa cultura continuara, el paso 1 funcionaría bien. Sin embargo, creo que esta propuesta haría que AN / ANI actuara de manera diferente. Creo que algunos clientes habituales de AN / ANI serían más reacios a cerrar el hilo de mala conducta del administrador de una manera que proporcione una declaración definitiva para desencadenar el paso 1 (más sobre esto en un momento). Creo que también habría retrocesos / desafíos cuando un hilo se cerró pero se cerró de una manera que los partisanos encontraron insatisfactoria (ya sea esperando activar el paso 1 o no queriendo que se active el paso 1). Eso no será saludable para nuestra comunidad. En segundo lugar, creo que necesitaremos algunas cajas nuevas para que este proceso funcione. Francamente, estaba esperando un poco de apoyo crat (no me sorprendió la oposición / neutralidad) antes de apoyar porque sin crats dispuestos a hacer este proceso no funcionará. Y, en mi experiencia, la abrumadora mayoría de los crats son muy reacios a actuar de manera que nieguen a las personas el funcionamiento del sistema, incluso frente al consenso de la comunidad de que deberían hacerlo ( ejemplo ). Todos somos voluntarios, así que no les envidio esto. Sin embargo, me preocupa que los crats solo juzguen declaraciones muy claras como que satisfacen los criterios aquí tal vez hasta el punto de lo absurdo. He visto hilos en los que hay un claro consenso de que un administrador actuó mal, cerrados con declaraciones como "Aquí se aprendieron lecciones". Por el momento, eso está bien (de hecho, el cierre correcto para el administrador que se siente mal por un error), pero ¿sería eso suficiente para este proceso? Creo que la respuesta sería no para la mayoría de los crats (y también sería un ejemplo de una situación cercana a ser desafiada sobre la que ya escribí). Entonces, al final, creo que la respuesta a esto es simplemente elegir algunos crats más que estén dispuestos a implementar cualquier consenso de la comunidad que se derive aquí (nuevamente asumiendo que esto pase). Finalmente, me preocupa que alguien con un 40% de confianza en la comunidad pueda continuar como administrador. Estamos tan preocupados por la confianza de la comunidad que decimos que, a menos que 3/4 de la comunidad confíe en usted, no estamos dispuestos a dárselo en primer lugar (al menos no sin más discusión), pero si el 59,9% de la comunidad desconfía usted, pero tuvo la buena suerte (o habilidad / competencia real) de aprobar en un momento, seguro que todavía puede ser un sysop. Si alguna vez hubiera un escenario en el que una mayoría votara a favor de desysop pero no fuera suficiente para aprobar, especialmente con todas las otras salvaguardas que tiene esta propuesta, ese resultado sería increíblemente divisivo para la comunidad. Creo fundamentalmente que es insostenible que alguien que la mayoría de la comunidad, en una discusión con mucha asistencia, desconfíe de continuar como administrador. En resumen, ¿tener algún proceso es mejor que nada para mí? Si. ¿Son buenos los "huesos" de este proceso? Si. ¿Es necesario replantear los detalles para que funcionen mejor? Si. Lo mejor, Barkeep49 ( charla ) 16:10, 22 de febrero de 2021 (UTC)
- Soporte Es mejor tener este proceso que no tenerlo. Algunos usuarios están haciendo suposiciones sobre lo que la comunidad hará o no hará una vez que esto se implemente, pero no lo sabremos con certeza hasta que se implemente. Deberíamos revisar este proceso con otro RfC en seis meses a un año. Mi apoyo a este proceso se basa en el supuesto de que complementará el sistema ArbCom actual, no lo reemplazará. ArbCom no debería utilizar este proceso como motivo para denegar casos. Barkeep49 dijo anteriormente
que he visto hilos en los que hay un claro consenso de que un administrador actuó mal, cerrados con declaraciones como "Aquí se aprendieron lecciones".
Si esta propuesta se aprueba, las declaraciones finales dirían una de estas tres cosas: "La comunidad determina que no hay suficiente evidencia para justificar una solicitud de admin desysop", "La comunidad determina que hay suficiente evidencia para una solicitud de admin desysop" o "No se alcanzó el consenso ". Si hay un par de informes de AN que concluyen sin consenso, debe aceptarse como un caso de ArbCom. Z1720 ( conversación ) 16:58, 22 de febrero de 2021 (UTC) - Soporte Creo que este proceso ayudará a mejorar la confianza entre los administradores y los editores a largo plazo que a veces sospechan de los administradores. Un proceso sencillo con puntos de referencia claros es complementario y una buena alternativa a la ruta ArbCom. He leído los contrarios y entiendo muchos de los puntos planteados, pero llego a la conclusión de que los beneficios superan con creces los riesgos. Cullen 328 Vamos a discutirlo 19:00, 22 de febrero de 2021 (UTC)
- Soporte : Hemos tenido tantos casos de ArbCom revocando el acceso de administrador e incluso un ex administrador de Fram fue prohibido por conducta inapropiada sin discusión en la comunidad. Creo que ArbCom debe considerarse un último recurso, ya que ArbCom está destinado a resolver problemas a largo plazo con la conducta de comportamiento que la discusión de la comunidad no puede manejar. Aasim ( charla ) 19:30, 22 de febrero de 2021 (UTC)
- Usted estés papel de tergiversar ARBCOM en WP: FRAMSUM allí. No tuvieron nada que ver con la prohibición de Fram. Cabayi ( charla ) 16:04, 23 de febrero de 2021 (UTC)
- A lo que me refería era a que Fram fue prohibido sin una discusión comunitaria por parte de la WMF y no escuché de ninguna queja formal presentada a la comunidad en WP: ANB (sin decir que no sucedió) e incluso entonces no habría forma de comunidad para intervenir y decidir que las acciones de este usuario no merecen las herramientas de administración, lo que lo convierte en una situación de pérdida y pérdida; tanto una pérdida para el editor que es destituido o prohibido sin discusión en la comunidad como para la comunidad que no tenía idea de que había problemas con las acciones de un usuario. Aasim ( charla ) 17:07, 23 de febrero de 2021 (UTC)
- Usted estés papel de tergiversar ARBCOM en WP: FRAMSUM allí. No tuvieron nada que ver con la prohibición de Fram. Cabayi ( charla ) 16:04, 23 de febrero de 2021 (UTC)
- Soporte Esta será una propuesta perenne hasta que sea adoptada (o una variante), por lo que también podría hacerlo. - John M Wolfson ( charla • contribuciones ) 19:55, 22 de febrero de 2021 (UTC)
- Soporte débil Veo muchos problemas aquí y cosas que no funcionarán tan bien como se esperaba. Sin embargo, prefiero que tengamos un proceso imperfecto que se puede mejorar que ningún proceso en absoluto. El mes pasado en ANI ha presentado al menos dos demostraciones de administradores que muestran serios problemas de competencia que podrían no ameritar una presentación ARBCOM, pero también muestran que necesitamos algún tipo de recurso. Grandpallama ( charla ) 20:04, 22 de febrero de 2021 (UTC)
Soporte débilen nombre de comenzar en algún lugar, según lo que escribí en el RfC anterior. Dicho esto, como escribí a continuación, me gustaría ver un período de prueba de 12 meses y una regla que restrinja la frecuencia con la que alguien puede iniciar este proceso contra el mismo administrador . - Hablar de las rododendritas \\ 20:19, 22 de febrero de 2021 (UTC)- Pensando más en ello, estoy dividido entre querer probar algo y querer una seguridad (período de prueba o de otro tipo) de que si no funciona bien, entonces no será difícil deshacerlo. Moviéndose, vaya neutral por el momento. - Hablar de las rododendritas \\ 03:37, 23 de febrero de 2021 (UTC)
- Soporte , esto parece un proceso de desadministración muy cuidadoso que limitaría en gran medida la cantidad de amiguismo que muchos temen crearía un proceso de desadministración. Está claro que es necesario cambiar algo sobre la desadministración, y aunque esto no es perfecto, parece suficientemente bueno. Si surgen problemas graves, se puede modificar. Devonian Wombat ( charla ) 20:54, 22 de febrero de 2021 (UTC)
- Soporte por numerosos arriba. Ya era hora. Pero también por Barkeep. Gog the Mild ( hablar )
- Support Power corrompe, el poder absoluto corrompe absolutamente .-- Catlemur ( charla ) 22:53, 22 de febrero de 2021 (UTC)
- Apoyo débil Aquí hay peligros reales. AN / I es un concurso de popularidad del 80%, sustancia del 20%. Los cierres prematuros y los cierres de edición y guerra ya existen, y si esta es una política, se garantizará que un administrador popular no se manche con un cierre AN / I condenatorio. La preocupación de Sandstein en la sección opuesta es buena, aunque los imbloqueables no se bloquearán de ninguna manera. Con suerte, esto no disuadirá a ArbCom de aceptar algunos casos de conducta administrativa porque ahora existe un proceso comunitario y las situaciones pueden ya no ser "intangibles". Sería desafortunado si ese fuera el caso porque significaría que los administradores populares pero abusivos no serían examinados por nadie, y este proceso solo se usaría para eliminar a los "administradores heredados fuera de contacto" que por casualidad pisaron el dedos de los pies de un imbloqueable, como una extensión de la mentalidad de la mafia en AN / I. Si bien estos requisitos de aprobación de AN / I y tres administradores son malos, creo que este es un instrumento importante que debería existir. La comunidad tiene el poder de otorgar administración y, por lo tanto, también debería tener el poder de eliminar los bits. Ojalá se hubiera implementado al principio para que ya se hubiera refinado. - Pudeo ( charla ) 23:01, 22 de febrero de 2021 (UTC)
- Apoyo : la gente cambia. ~ Tom.Reding ( talk ⋅ dgaf ) 00:25, 23 de febrero de 2021 (UTC)
- Soporte - Neutralhomer • Charla • 00:27 del 23 de febrero de 2021 (UTC)
- Apoyarlo no es lo que hubiera hecho, pero es mejor que nada. A muchos opositores les preocupa que habrá muchos procedimientos frívolos, pero no entiendo por qué sucedería eso: tener tres administradores firmados parece ser suficiente para evitar procedimientos frívolos. Vale la pena intentarlo, hay una alta probabilidad de que sea una adición bienvenida. Sam-2727 ( conversación ) 00:37, 23 de febrero de 2021 (UTC)
- Apoyo Un proceso bien definido hace que todos sean más responsables. Mysteryman azul 01:19, 23 de febrero de 2021 (UTC)
- Soporte: He estado esperando algo como esto. Este es un buen intento de una política desysop que hasta la fecha ha estado muy ausente. Siento que la propuesta tiene suficientes controles y contrapesos, y apoyo su implementación. Los números se pueden modificar, como muchos dicen. También me gusta la discusión a continuación en los Hipotéticos. Mucha discusión sensata allí. Con más discusión, podemos llegar a algo viable. - Whiteguru ( charla ) 04:58, 23 de febrero de 2021 (UTC)
- Soporte: Puede realizar casi el 90% de las acciones, ediciones, etc. en Wikipedia sin privilegios de administrador. Aunque los privilegios de administrador se implementan para que las acciones importantes y críticas sean administradas por editores confiables, podrían reemplazarse fácilmente por un permiso similar a los procesos de confirmación extendida. Los administradores solo tienen acceso a una pequeña cantidad de acciones, que son importantes, pero la OMI no tiene suficiente importancia para tener su propia posición. Senador LEVI 05:13, 23 de febrero de 2021 (UTC)
- Apoyar: . Aumentará la responsabilidad. Desertarun ( charla ) 09:17, 23 de febrero de 2021 (UTC)
- Apoyo : apoyo totalmente la implementación de esto, que a su vez obligaría a los administradores a ser completamente responsables de cada acción de ellos y seguir WP: ADMINCOND al pie de la letra, lo que invariablemente frenaría el abuso de los administradores. Tengo pocas reservas, una de las principales preocupaciones sería esta, digamos, por ejemplo, un administrador no tan popular se folla al "administrador equivocado" con los "amigos adecuados". Solo me imagino que el administrador no tan popular se des-sysope tan rápido ellos no sabrían qué los golpeó. Pros y contras realmente. Celestina007 ( charla ) 09:27, 23 de febrero de 2021 (UTC)
- Soporte , en gran parte por WTT. Los administradores deben rendir cuentas directamente a la comunidad, y siempre he apoyado un proceso de desysop comunitario. No estoy seguro de algunos de los detalles, pero eso siempre será un problema con una propuesta como esta. Si lo mantiene relativamente suelto, algunos se opondrán debido a la falta de detalles, y si lo hace detallado, algunos se opondrán debido a su complejidad, mientras que ambos grupos de personas podrían apoyar un proceso de desysop en principio. Si bien puede que no sea perfecto (y ninguna propuesta satisfará a todos los que apoyan el principio), creo que hay suficientes garantías. Y podemos ajustarlo a medida que avanzamos en función de la experiencia que obtengamos. ¡Boing! dijo Zebedee ( hablar ) 11:26, 23 de febrero de 2021 (UTC)
- Según Iridescent, para aclarar: Mi apoyo es para " ... un consenso con un umbral mínimo de apoyo del 60% que apoya la eliminación ... " (énfasis mío) como se indica en la propuesta. Si eso se cambia, el RfC debe volver a ejecutarse, y ciertamente me opondría a que se cambiara el 60/40. ¡Boing! dijo Zebedee ( hablar ) 11:14, 27 de febrero de 2021 (UTC)
- Apoyar esto ayudará a la comunidad a mantener a los administradores bajo control y permitirá a los usuarios una forma más sencilla de expresar sus preocupaciones sobre la conducta administrativa. Willbb234 Talk ({{ ping }} en las respuestas) 12:06, 23 de febrero de 2021 (UTC)
- Soporte en su forma amplia. Todos los funcionarios son nombrados por la comunidad y deben estar sujetos a destitución por parte de la comunidad a través de un proceso transparente que puede ser iniciado por la comunidad. Estoy de acuerdo con la propuesta de exigir una o varias funcionario para apoyar la petición que veo como similar a la que requiere un senador a proceder con una objeción al colegio electoral votación. Algunos de los detalles pueden necesitar ajustes en umbrales, escalas de tiempo, etc., en un RFC posterior. En particular, creo que la política debería rechazar dos solicitudes de desysop para la misma persona dentro de un período de tiempo determinado (por ejemplo, solo se permite una cada seis meses, aunque ArbCom aún podría desysop a través de sus procedimientos) y solo una por informe AN / ANI - no doble incriminación . QuiteUnusual ( conversación ) 13:51, 23 de febrero de 2021 (UTC)
- Soporte : el arreglo actual no es satisfactorio. Si un editor se queja de la conducta de un administrador en AN o AN / i, se le dice que es el foro equivocado. Si van directamente a Arbcom, su solicitud es rechazada debido a una resolución previa insuficiente de la disputa. Esta propuesta parece una forma sensata de resolver este problema. Cwmhiraeth ( charla ) 14:07, 23 de febrero de 2021 (UTC)
- Apoyo : como alguien más dijo anteriormente, las personas cambian. Algunos de los detalles de la propuesta parecen ser necesarios para trabajar en ellos, pero en general estoy a favor de una rendición de cuentas más accesible y directa. ❯❯❯ Mccunicano ☕️ 15:03, 23 de febrero de 2021 (UTC)
- Soporte : no creo que sea un problema requerir que tres administradores estén de acuerdo. También creo que necesitamos un programa de desysop comunitario y Dios, hemos pasado demasiado tiempo diciendo "sí, necesitamos uno, pero no este". Protonk ( charla ) 15:29, 23 de febrero de 2021 (UTC)
- Apoyar el proceso parece bueno, aunque creo que tendremos que ver cómo va y qué se debe cambiar βӪ ᑸᙥ Ӵ • Charla • Contribuciones 15:35, 23 de febrero de 2021 (UTC)
- Soporte . Solo repetiré mi comentario de 2019 aquí: "Parece obvio que si la comunidad puede promover un administrador sin pasar por ArbComm, deberían poder degradar a un administrador a través del mismo proceso. El sistema" no vinculante "actual es peor que nada, ya que da una falsa sensación de que realmente tenemos procesos en marcha mientras que los administradores son libres de (y han) modificado sus requisitos no vinculantes sobre la marcha para evitar tener que seguir adelante ". - Ahecht (
PÁGINA DE HABLAR) 15:46, 23 de febrero de 2021 (UTC) - Soporte - Mucho tiempo atrasado en mi humilde opinión. La política, etc. se puede modificar a lo largo del camino si las cosas no salen bien. - Davey 2010 Talk 15:58, 23 de febrero de 2021 (UTC)
- Apoyar la imposición de un proceso de retiro obligatorio e implícitamente la eliminación de todos los procesos de retiro diseñados individualmente para garantizar la igualdad de condiciones. Me gustaría ver una cláusula de suspensión para que el funcionamiento del proceso pueda revisarse después de 6 meses o un año, o después de que se haya invocado 4 veces, y los números se modifiquen si es necesario. Cabayi ( charla ) 16:22, 23 de febrero de 2021 (UTC)
- Todos los administradores estarían sujetos a procedimientos aprobados por la comunidad, pero dado que pueden renunciar en cualquier momento o simplemente dejar de realizar acciones administrativas, no creo que podamos obligarlos a renunciar a sus propios estándares personales para retirarse de sus funciones administrativas. isaacl ( charla ) 19:05, 23 de febrero de 2021 (UTC)
- Apoyo Aunque tengo fe en los administradores de Wikipedia, pueden perder competencia moral a lo largo de los años o como resultado de su poder. Painting17 ( charla ) 19:03, 23 de febrero de 2021 (UTC)
- Soporte Proporciona un aporte de la comunidad. Incluso resaltar el comportamiento de mal genio puede ayudar a las personas a controlarse y equilibrarse entre sí de manera más pública. Aunque desvincularse y alejarse es principalmente la opción para entrar en disputas, a veces es unilateral cuando se prueba contra poderes desiguales. Se puede cambiar una vez implementado, pero es necesario para la participación de la comunidad en todos los roles administrativos. Encomendamos a las personas para que desempeñen sus funciones lo mejor que puedan de manera correcta, sean responsables de cualquier comportamiento, ya sea conocido en general o mínimamente, y conduzcan sus negocios de manera civilizada y respetuosa. Aunque no es perfecto, el comportamiento similar repetido en sucesión corta y horas extras no es aceptable sin importar el rol de uno en la comunidad. Adog ( Charla・Cont ) 21:06, 23 de febrero de 2021 (UTC)
- Soporte porque es mejor que antes. Pero preferiría requisitos más realistas para evitar solicitudes de presentación de cuentas de venganza. Con 25 ediciones, difícilmente se puede obligar a 3 Sysops a estar de acuerdo con ellas. Paradise Chronicle ( charla ) 22:35, 23 de febrero de 2021 (UTC)
- Soporte Creo que los requisitos aquí son más estrictos que la mayoría de los criterios de recuperación de administrador , y allí la lista de solicitudes pasadas no me dejó creer que el proceso se podría jugar o se podría jugar (pocas personas que veo fueron a) arrastradas incorrectamente a Recuerdo, yb) abandonado a través de ese método.) Entiendo las preocupaciones sobre la burocracia excesiva, pero a) es mejor que la burocracia de un caso de arbitraje, b) ese método en capas es lo que evitará que se juegue fácilmente. Charla de Der Wohltemperierte Fuchs 23:17, 23 de febrero de 2021 (UTC)
- ( editar conflicto ) Soporte - Cualquier método es mejor que ningún método. Podemos aumentar o disminuir los umbrales, ajustar tiempos específicos o corregir cualquier falla en el proceso más adelante. En algún momento dejamos que lo perfecto sea enemigo de lo bueno.
Por ejemplo, creo que el 60% es un umbral demasiado alto, pero no me opondré porque creo que si incluso la mayoría de los editores creen que un administrador ha abusado de su posición hasta el punto de requerir un desysop , debería ser eliminado. Tampoco creo que a ninguna de las personas que certifiquen la solicitud se le deba exigir que sea sysops. Sin embargo, nuevamente, cualquier método ejecutable que permita la recuperación del administrador es mejor que el que tenemos ahora: nada.
Por cierto, varios administradores y yo estamos abiertos a la retirada , y creo que ha habido exactamente un intento de retirada (que también tuvo éxito) en mis 10 años en este sitio, por lo que dudo que los trolls abusen significativamente de este proceso. o editores de venganza. En el caso de que algún calcetín de interrupción aleatoria presente una solicitud claramente frívola, podemos tratarla de la misma manera que tratamos cualquier otro acto de vandalismo. Reaper Eternal ( charla ) 23:18, 23 de febrero de 2021 (UTC) - Apoye esta y cualquier otra propuesta que permita el desysop de la comunidad.— S Marshall T / C 23:21, 23 de febrero de 2021 (UTC)
- Soporte como buen punto de partida. No será perfecto, pero habrá oportunidades para mejorarlo. - J947 ‡ mensaje ⁓ edita 01:59, 24 de Febrero 2021 (UTC)
- Soporte débil Ⓩⓟⓟⓘⓧ Charla 02:34, 24 de febrero de 2021 (UTC)
- Soporte Paso correctivo muy necesario. Siempre debemos recordar que el propósito de este proceso no es el castigo personal; más bien, su función es principalmente mantener el propósito de Wikipedia. Nalbarian ( charla ) 02:52, 24 de febrero de 2021 (UTC)
- Apoyo Esta propuesta parece justa pero también eficaz. Jmbranum ( charla ) 03:37, 24 de febrero de 2021 (UTC)
- Soporte . Necesitado desde hace mucho tiempo y un buen lugar para comenzar. A largo plazo, comparto las preocupaciones sobre vincular esto a ANI (que tiende a requerir múltiples visitas para "hacerlo bien") y preferiría algo más parecido al sistema alemán de umbrales graduales para la reconfirmación, es decir, suficiente descontento para demostrar que tal gasto de esfuerzo tiene más posibilidades que una bola de nieve. zar 04:51, 24 de febrero de 2021 (UTC)
- Apoyo : estoy a favor de esto. GamerPro64 06:12, 24 de febrero de 2021 (UTC)
- Soporte Todo el poder no controlado conduce al abuso. Keepcalmandchill (haga ping en las respuestas) ( charla ) 06:14, 24 de febrero de 2021 (UTC)
- Soporte Preferiría que solo las discusiones en el tablón de anuncios que fueron cerradas por un administrador sean un desencadenante del proceso, pero podemos ver si eso se convierte en un problema o no avanza. Scribolt ( charla ) 06:54, 24 de febrero de 2021 (UTC)
- Apoyo. Esta propuesta estaba bien pensada y, aunque todavía me irrita que la comunidad de Wikipedia se esté inclinando hacia el procedimentalismo, ese fenómeno parece estar funcionando en general. Mi base principal para apoyar esta propuesta es ArbCom. Ahora confío en el consenso de la comunidad mucho más que en el juicio de los miembros del comité. Es simplemente un juego de números: elija diez miembros de la comunidad y obtendrá algunos que realmente no dan en el clavo cuando opinan sobre un tema en particular. No es culpa suya; simplemente no son los más informados, o no leyeron el material con suficiente atención, o están demasiado ocupados pensando en otra cosa. Desafortunadamente, en un escenario donde la comunidad no está decidiendo, sino ArbCom, entonces esas personas tienen proporcionalmente mucha más influencia de la que deberían. Las discusiones de voto de la comunidad tienden a permitir que los puntos de vista correctos floten hacia la cima y se vuelvan prolíficos, poniendo mucha menos confianza en las personas individuales que en un modelo de toma de decisiones de comité. Todos los viejos argumentos para hacer una excepción cuando se trata de administradores y otorgar el poder de desysop a ArbCom, ya no son válidos. No tengo la sensación de que ArbCom tome mejor las decisiones de desocupación; ahora es todo lo contrario. AGK ■ 10:01, 24 de febrero de 2021 (UTC)
- La propuesta no está bien pensada en absoluto, como lo demuestran los muchos comentarios en la sección de oposición. Incluso si pasa, necesitará una revisión considerable antes de que sea realmente viable, en mi opinión. Con respecto a que la comunidad en su conjunto es mejores jueces que Arbcom, si ese fuera el caso, ¿por qué la necesidad de Arbcom? Porque la comunidad ha demostrado una y otra vez que hay ciertos problemas que encuentra intratables. En su mayor parte, Arbcom ha servido muy bien a la comunidad. Los miembros de Arbcom generalmente se comportan de la mejor manera, porque saben que cualquier demostración de imprudencia o parcialidad los desacreditará, a diferencia de las discusiones de la comunidad donde los participantes no tienen reparos en agregar las declaraciones más perjudiciales debido al grado de responsabilidad personal muy atenuado. Y lo que es más importante, Arbcom cuenta con procedimientos para garantizar que todas las partes obtengan una audiencia justa, no existen tales salvaguardas en este proceso propuesto; Una vez que se confirma una solicitud, ¡básicamente va a ser un caótico festival de votaciones sin garantías procesales en absoluto! Gatoclass ( charla ) 11:30, 24 de febrero de 2021 (UTC)
- El procedimiento es sencillo y viable; ninguno de los opositores presentó un caso creíble de otra manera. ArbCom se creó para resolver los problemas de una comunidad diferente. Si se pregunta por qué lo necesitamos ahora, que así sea. Finalmente, si RFA funciona, también lo hará RFDA. AGK ■ 12:09, 24 de febrero de 2021 (UTC)
# Soporte Creo honestamente que esta es una gran idea, porque durante mucho tiempo he pensado que los administradores son como reyes. 🐔 ¡ Chicdat Bawk para mí! 11:09, 24 de febrero de 2021 (UTC)Movió para oponerse . 🐔 ¡ Chicdat Bawk para mí! 10:22, 15 de marzo de 2021 (UTC)
- La propuesta no está bien pensada en absoluto, como lo demuestran los muchos comentarios en la sección de oposición. Incluso si pasa, necesitará una revisión considerable antes de que sea realmente viable, en mi opinión. Con respecto a que la comunidad en su conjunto es mejores jueces que Arbcom, si ese fuera el caso, ¿por qué la necesidad de Arbcom? Porque la comunidad ha demostrado una y otra vez que hay ciertos problemas que encuentra intratables. En su mayor parte, Arbcom ha servido muy bien a la comunidad. Los miembros de Arbcom generalmente se comportan de la mejor manera, porque saben que cualquier demostración de imprudencia o parcialidad los desacreditará, a diferencia de las discusiones de la comunidad donde los participantes no tienen reparos en agregar las declaraciones más perjudiciales debido al grado de responsabilidad personal muy atenuado. Y lo que es más importante, Arbcom cuenta con procedimientos para garantizar que todas las partes obtengan una audiencia justa, no existen tales salvaguardas en este proceso propuesto; Una vez que se confirma una solicitud, ¡básicamente va a ser un caótico festival de votaciones sin garantías procesales en absoluto! Gatoclass ( charla ) 11:30, 24 de febrero de 2021 (UTC)
- Fuerte apoyo . Como otros, no tengo idea de si los números son perfectos y espero que cambien con la experiencia. Lo que hace esto es agregar una herramienta adicional para eliminar a un administrador. Para la mayor parte de mi edición de Wikipedia (incluso en áreas polémicas), WP: COOL y WP: AGF me han funcionado bien. En casos excepcionales, he visto administradores de WP: ROGUE , pero de manera aún más generalizada el fenómeno de no administradores de WP: UNBLOCKABLES . Estoy convencido de que aumentar el número de ADMINS es la solución, y esto sucederá, si reducimos la presión de este nombramiento vitalicio . Irónicamente, al mejorar el proceso de recuperación, también retendremos / reclutaremos a más administradores y haremos que tengan menos miedo a las represalias por eliminar a los editores abusivos, simplemente porque no estarán tan solos. Shushugah ( charla ) 13:39, 24 de febrero de 2021 (UTC)
- Existe una solución mucho más sencilla. Cambiar la administración de ser un nombramiento de por vida a uno de plazo limitado, digamos 5 o 6 años. Requerir una reconfirmación vinculante de RfA (con el mismo umbral de aprobación que los nuevos RfA, de modo que no sea necesario inventar nuevos estándares) al final del plazo para aquellos administradores que quieran continuar como sysops. Todos los administradores, no solo los que se desvían seriamente, serán responsables por la comunidad. Deje que ArbCom se ocupe de la eliminación de la administración por causa justificada. Nsk92 ( conversación ) 15:37, 24 de febrero de 2021 (UTC)
- Yo también apoyaría eso, tal vez incluso lo preferiría, porque permitiría que las RFA se hicieran de manera cordial. Sin embargo, esa no es la propuesta que se nos presenta aquí. ¿Sabes si eso se ha discutido antes? Me imagino que el miedo a perder demasiados administradores pendientes de una nueva confirmación fue una de las razones por las que no se propuso. Shushugah ( charla ) 15:49, 24 de febrero de 2021 (UTC)
- Se ha discutido muchas veces. Los inconvenientes obvios, la pérdida de la "cola larga" de los administradores que ocasionalmente usan el trapeador, pero cuyos niveles de actividad recientes dificultarían la aprobación de la RFA, y al igual que con un sistema de desysop que no es Arbcom, el fuerte incentivo para que los administradores se involucren en controversias. áreas han kyboshed propuestas hasta ahora. Por cierto, sería bueno aumentar el número de administradores, pero ¿la experiencia en proyectos como Commons indica que al facilitar el envío de muertos se obtienen más solicitudes de reembolso? Ϣere Spiel Checkers 16:15, 24 de febrero de 2021 (UTC)
- Yo mismo no he seguido estas discusiones previas y no tengo ningún recuerdo específico de ellas. Recuerdo haber visto algunos RfA de reconfirmación voluntaria no vinculantes y creo que todos pasan con bastante facilidad. Con respecto a los administradores con bajos niveles de actividad administrativa, no los vería perder el estado de administrador como una pérdida grave para el proyecto. Pero un sistema de reelección regular podría darles el incentivo para comenzar a usar el trapeador con más regularidad. Nsk92 ( conversación ) 16:27, 24 de febrero de 2021 (UTC)
- Se ha discutido muchas veces. Los inconvenientes obvios, la pérdida de la "cola larga" de los administradores que ocasionalmente usan el trapeador, pero cuyos niveles de actividad recientes dificultarían la aprobación de la RFA, y al igual que con un sistema de desysop que no es Arbcom, el fuerte incentivo para que los administradores se involucren en controversias. áreas han kyboshed propuestas hasta ahora. Por cierto, sería bueno aumentar el número de administradores, pero ¿la experiencia en proyectos como Commons indica que al facilitar el envío de muertos se obtienen más solicitudes de reembolso? Ϣere Spiel Checkers 16:15, 24 de febrero de 2021 (UTC)
- Yo también apoyaría eso, tal vez incluso lo preferiría, porque permitiría que las RFA se hicieran de manera cordial. Sin embargo, esa no es la propuesta que se nos presenta aquí. ¿Sabes si eso se ha discutido antes? Me imagino que el miedo a perder demasiados administradores pendientes de una nueva confirmación fue una de las razones por las que no se propuso. Shushugah ( charla ) 15:49, 24 de febrero de 2021 (UTC)
- Existe una solución mucho más sencilla. Cambiar la administración de ser un nombramiento de por vida a uno de plazo limitado, digamos 5 o 6 años. Requerir una reconfirmación vinculante de RfA (con el mismo umbral de aprobación que los nuevos RfA, de modo que no sea necesario inventar nuevos estándares) al final del plazo para aquellos administradores que quieran continuar como sysops. Todos los administradores, no solo los que se desvían seriamente, serán responsables por la comunidad. Deje que ArbCom se ocupe de la eliminación de la administración por causa justificada. Nsk92 ( conversación ) 15:37, 24 de febrero de 2021 (UTC)
- Soporte Definitivamente debe haber un mecanismo para eliminar administradores abusivos, desorientados o deshonestos, y este es un medio tan bueno como cualquier otro. Es cierto que la necesidad de acudir primero a una junta de teatro tiene sus defectos. Por lo general, hay soporte automático para un administrador, especialmente uno de larga duración, por lo que con frecuencia se puede encontrar a administradores abusivos que digan "¡claro, adelante, vaya a ANI!" cuando es desafiado. Pero el fenómeno del administrador abusivo es una realidad en Wikipedia y esa es solo una de las molestias necesarias para participar en este pasatiempo. Una sugerencia: mantendría la ruta del comité de arbitraje. No está claro si se mantendría, como otra alternativa, en esta propuesta. Coretheapple ( charla ) 16:57, 24 de febrero de 2021 (UTC)
- ¡La opción de arbitraje definitivamente se mantendrá! Eso se ha afirmado, porque a veces hay información / temas sensibles que serían inapropiados con este foro propuesto. Shushugah ( charla ) 17:59, 24 de febrero de 2021 (UTC)
- Apoyo - propuesta sensata. No es perfecto, pero es mejor que nada. PhilKnight ( charla ) 18:17, 24 de febrero de 2021 (UTC)
- Soporte ¿Es perfecto? No. Sin embargo, necesitamos algún tipo de procedimiento de des-sysop de la comunidad, considerando que Arbcom a menudo se mueve lentamente y los administradores deben ser responsables en última instancia ante la comunidad. Hay un par de problemas: los hilos de ANI a menudo no reflejan cuál sería el consenso entre la comunidad en general y son más fáciles de manipular, pero es una mejora. ThePlatypusofDoom (charla) 18:53, 24 de febrero de 2021 (UTC)
- Admite una prueba por tiempo limitado . Estoy extremadamente sensible al argumento de que esto sería colgar una piedra de molino alrededor del cuello de alguien que pone aún más hallazgo de menor importancia contra ellos en un drama tablero-tal como está redactado, incluso el más anodino de administración ": Foo se le recuerda utilizar el
upright=
lugar que elwidth=
parámetro al cambiar el tamaño de las imágenes "encontrar dispararía a Admin: Foo en la cabeza durante los próximos seis meses. Dicho esto, la historia de Wikipedia está llena de cosas que la gente esperaba que fallaran y que no causaron ningún problema. Apoyaría ejecutar esto durante unos meses, con una cláusula de suspensión estricta que diga que, a menos que haya un consenso claro de que funciona, caducará en una fecha determinada, para ver si realmente tiene algún efecto útil. Sí, será potencialmente desagradable y una pérdida de tiempo para cualquiera que se vea atrapado en él, pero hablando como alguien que ha sido llevado a Arbcom por presunto abuso, puedo asegurar a todos que el mecanismo existente no es divertido ni rápido. - Iridiscente 20:07, 24 de febrero de 2021 (UTC)- Para mayor claridad y para evitar y dudar en el futuro, si la propuesta a continuación requiere un 60% de apoyo para que el administrador retenga las herramientas , entonces cambie a una fuerte oposición . Suponiendo (basado en cifras de cuando los TFA eran más comunes) que una vez que la novedad de los primeros desaparezca, estas cosas atraerán alrededor de 100 participantes cada una, eso significa que solo se necesitarán 40 descontentos para despojar a un administrador del bit. Cualquier administrador que no haya logrado molestar a 40 personas durante su tiempo probablemente esté tan inactivo que debería ser despojado de la parte por inactividad; un umbral del 60% para la retención haría que este procedimiento sea insuperable y, como tal, mantendría el requisito de certificación burócrata y, por lo tanto, haría que los 'crats ingresen al Panel de eliminación de administradores, o permitiría que cualquier grupo de personas infelices inicie el proceso y acabar con el cuerpo administrativo por completo. - 10:19 iridiscente , 27 de febrero de 2021 (UTC)
- Apoyo Si podemos votar para darles la prohibición, podemos quitárselo. Chris Troutman ( charla ) 21:54, 24 de febrero de 2021 (UTC)
- En la vida real, los funcionarios electos casi siempre son elegidos por un período fijo y se les hace presentarse a una reelección. Las elecciones de recordatorios rara vez se utilizan, pero cuando ocurren, a menudo conducen a desastres. En cambio, se utilizan diferentes procedimientos para la destitución de funcionarios electos por causa justificada mientras están en el cargo (juicio político para presidentes, expulsión de miembros del Congreso, etc.). Para otros funcionarios de la wiki (por ejemplo, árbitros, delegados), tenemos nombramientos de plazo limitado que requieren reelecciones, pero no para administradores. De alguna manera, los administradores obtienen nombramientos vitalicios, como los jueces de la Corte Suprema de EE. UU. Nsk92 ( conversación ) 22:12, 24 de febrero de 2021 (UTC)
- Soporte tentativo , probablemente inicialmente para una prueba por tiempo limitado. Es difícil predecir cómo resultaría realmente. Johnbod ( charla ) 04:43, 25 de febrero de 2021 (UTC)
- Apoyo El sistema actual de facto equivale a decir que la única forma de revisar la conducta de un oficial de policía es si la Corte Suprema de los Estados Unidos escucha el caso ..... una receta para la no revisión. Me gustaría ver un sistema que también pudiera dar advertencias, dirección y orientación, pero al menos esto es algo. North8000 ( conversación ) 05:18, 25 de febrero de 2021 (UTC)
- Se puede modificar más tarde si es necesario. Sugiero señalar esto. North8000 ( conversación ) 21:58, 3 de marzo de 2021 (UTC)
- Apoyo Deberíamos tener tal proceso. El sugerido es un buen punto de partida. Alaexis ¿pregunta? 08:06, 25 de febrero de 2021 (UTC)
Miré esto desde el principio y mis reacciones iniciales fueron mixtas. Por un lado , apoyo firmemente la noción de que la comunidad debería poder manejar un desysop; es algo que he apoyado durante la mayor parte de mi tiempo aquí, y es algo que siento que la mayoría de nosotros queremos. Por otro lado , estoy incómodo con esta propuesta por temor a una reacción instintiva a un solo evento con una acumulación posterior: hemos visto que estas cosas suceden; y gran parte del sistema propuesto es demasiado problemático, demasiado burocrático y no permite que 'Crats haga una evaluación de los argumentos, etc.No creo que este sea el procedimiento que deberíamos tener. Pero , dudo en impedir o complicar una propuesta para un desysop comunitario, porque propuestas anteriores se han despegado en temas menores similares. Dado que casi nada de lo que hemos hecho en Wikipedia ha comenzado perfecto, pero ha mejorado con el tiempo a medida que lo hemos trabajado, es mejor tener un procedimiento de desysop comunitario, imperfecto seguro, pero con la tendencia natural que tiene Wikipedia. de mejorar el proceso a medida que avanzamos, que rechazar esta propuesta porque es un fragmento en lugar de un artículo destacado.Creo que deberíamos aceptar esta propuesta y trabajar en ella para que funcione . Creo que podemos aceptar esta propuesta tal como está y ajustarla a medida que avanzamos, aunque con tres enmiendas importantes: 1) "Si [netos] 10 usuarios confirmados extendidos ..." (no tiene sentido iniciar un procedimiento si diez están a favor pero 110 están en contra, por lo que debería ser un "neto" 10, no un simple 10), 2) Que una vez certificadas, las herramientas del administrador se eliminen temporalmente o se renuncien (como es estándar en todas las ocupaciones si alguien está bajo investigación) 3) Que luego se apliquen las mismas reglas que para una reconfirmación RfA: ¿la comunidad tiene confianza en el individuo, con la misma interpretación 'Crat del consenso y los mismos umbrales porcentuales? (Este es un sistema que conocemos y entendemos, permite a la comunidad mira la totalidad del individuo, y es más equilibrado y neutral).SilkTork ( charla ) 11:05, 25 de febrero de 2021 (UTC) Pasar a oponerse ya que esto parece ser demasiado problemático. SilkTork ( charla ) 13:40, 27 de febrero de 2021 (UTC)
- Apoyo Es tan poco probable que los administradores esperados se vigilen por sí mismos, como esperar que la policía lo haga. FlailingEnglish ( charla ) 11:11, 25 de febrero de 2021 (UTC)
- Soporte muy retrasado. Me he encontrado con algunos administradores abusivos a largo plazo y me pregunto cómo lograron seguir siendo administradores durante tanto tiempo. Hzh ( conversación ) 12:47, 25 de febrero de 2021 (UTC)
- Apoyo. Algo como esto hace tiempo que se debió. La propuesta ciertamente no es perfecta, pero podemos modificarla más tarde. Majavah ( ¡habla! ) 14:39, 25 de febrero de 2021 (UTC)
- Soporte Tener una política es mejor que no tener ninguna. ‐‐ 1997kB ( charla ) 15:58, 25 de febrero de 2021 (UTC)
- Soporte Esto es un poco más oneroso de lo que me propongo, pero por otro lado, eso ciertamente evitará que se use de manera frívola. Si la comunidad intenta el procedimiento y falla, se puede modificar una vez que haya evidencia de lo que funciona y lo que no. Y ARBCOM siempre puede actuar si es necesario. (Alt declarado, mira quién creó la página de usuario) - IamaPOVpushingSPA ( hablar ) 17:33, 25 de febrero de 2021 (UTC)
- Soporte Hay demasiados administradores de sistemas que piensan que son dueños de wikipedia, por lo general citando su "tiempo en el proyecto" como una razón de su comportamiento. Sin duda, sería beneficioso disponer de una forma sencilla de eliminarlos; una forma de eliminarlos sin atascarse en toda la burocracia y los largos procesos de wikipedia. Fortnum ( charla ) 18:26, 25 de febrero de 2021 (UTC)
- Soporte en principio . Solía oponerme a tales propuestas, preocupado por la resolución de rencores y sintiendo que ArbCom podría ocuparse de problemas reales. Pero creo cada vez más que necesitamos más responsabilidad administrativa de la 'comunidad', y un proceso de desadministración de la comunidad es preferible al endurecimiento periódico de la política de inactividad del administrador que en realidad no aborda el problema subyacente, que es el comportamiento, no la actividad. Sin embargo, algunos detalles me molestan: a) no estoy seguro de que 25 ediciones en 6 meses sea útil; b) 48 horas es demasiado corto; c) Dejaría a los burócratas determinar el consenso para desysop en lugar de prescribir el 60%. Sin embargo, esas preocupaciones no son suficientes para oponerme o incluso mantenerme neutral a algo que vale la pena intentar. Martinp ( charla ) 18:59, 25 de febrero de 2021 (UTC)
- Reafirmo mi apoyo , habiendo revisado la discusión en esta página desde mi voto. Al igual que Tony, mi opinión ha cambiado en los últimos 12-18 meses, principalmente porque está claro que las preocupaciones sobre los administradores que se desvían del buen comportamiento, pero no lo suficiente para cumplir con el estándar de Arbcom desysop, se sienten lo suficientemente entusiastas como para hacer que aprobar RFA sea más difícil de lo necesario. . Así que espero que un procedimiento de desysop comunitario razonable pueda realmente hacer que la RFA sea menos tóxica y hacer que la comunidad esté más dispuesta a arriesgarse con alguien. En segundo lugar, no me convencen las preocupaciones sobre el acoso, las bandas contra los administradores, etc. Sí, sería posible que el juego el sistema lo suficiente como para iniciar las etapas iniciales de este proceso de desysop. Pero un administrador "limpio de manos" realmente no necesita prestar atención hasta que 10 usuarios con confirmación extendida, incluidos al menos 3 administradores, firmen la solicitud. Eso es una tarea difícil. En tercer lugar, como he dicho, no estoy interesado en prescribir% para que el de-RFA tenga éxito, pero mi apoyo aquí está condicionado a que se necesite consenso para desysop, no consenso para retener + sysop. No me opongo categóricamente a la administración por tiempo limitado + el consenso necesario para la reconfirmación, pero esta propuesta no lo es. Martinp ( charla ) 18:33, 2 de marzo de 2021 (UTC)
- Soporte El proceso actual de eliminación es demasiado complejo y requiere mucho tiempo, ya que generalmente requiere Arbcom, que puede ser bastante largo y prolongado incluso en el mejor de los casos, y esto parece ser un buen compromiso entre ser demasiado fácil para los administradores de desysop y ser demasiado complicado para que alguna vez se utilice. Jackattack1597 ( charla ) 19:35, 25 de febrero de 2021 (UTC)
- Apoyo débil Ciertamente una propuesta de buena fe bien pensada con algunos buenos argumentos tanto a favor como en contra. Confieso que el tiempo es demasiado limitado para analizarlo por completo, y podría existir el riesgo de que el proceso sea engañado o abusado, en cuyo caso podría ser necesario revisarlo o modificarlo. En última instancia, me he encontrado con un apoyo débil. Djm-leighpark ( charla ) 20:31, 25 de febrero de 2021 (UTC)
- Soporte Algo es mejor que nada. Leí todos los contrarios y no estoy convencido de que alguien haya encontrado un defecto fatal. Tener administradores bien intencionados pero impulsivos se sienten amenazados por un proceso que es más liviano / efectivo que ArbCom es, en mi opinión, una característica, no un error. Mis dos centavos de bicishedding (cosas que me gustaría, pero ciertamente no retendría un apoyo sobre ellas): (1) no hacer que el administrador de destino transcluya la solicitud, eso es simplemente malo; (2) eliminar los requisitos de aprobación de administrador (si los administradores pueden vetar un desysop de administrador, eso crea la situación para una espiral de muerte estilo Wikipedia croata ; reemplácelo por 10 WP: XC -editors o similar si es necesario); (3) requerir que la falla de búsqueda de subprocesos AN / ANI se cerró al menos una semana antes y la apertura de la solicitud de desysop (esto permite que la "mafia" se enfríe antes de entregar una segunda sanción; reemplace "una semana" por " un mes "o lo que sea si es necesario). Tigraan Haga clic aquí para contactarme 21:36, 25 de febrero de 2021 (UTC)
- Soporte . No estoy instintivamente a favor; No creo que me ayude personalmente porque hasta la fecha nunca he querido cumplir con el prerrequisito de llevar un administrador a ANI, y no creo que eso hará que la candidatura a RFA sea más atractiva (agregando la perspectiva de un segundo guante ¡no es un argumento de venta!) Pero, en consecuencia, creo que es muy poco probable que esto cambie las cosas drásticamente, y los seguidores me impresionan, así que si creen que podría ayudar en los márgenes, estoy de acuerdo con intentarlo. Supongo que lo modificaremos en seis meses o un año, si es que se usa. Lo cual está bien. Como digo, lo veo como una propuesta de bajo riesgo. Gracias Tony por sus continuos esfuerzos para buscar oportunidades para mejorar el proyecto. Innisfree987 ( conversación ) 23:49, 25 de febrero de 2021 (UTC)
- Apoyo , ya que se espera que esto anime a WMF a entregar la desobediencia a la comunidad en lugar de hacerlo ellos mismos arbitrariamente. Y, aparte de eso, hemos necesitado un proceso de juicio político durante algún tiempo, y esto encaja muy bien. esquema ( charla ) 02:59, 26 de febrero de 2021 (UTC)
- Um ... @ Schetm : ¿Podrías ponernos al día sobre estos arbitrarios despidos en la oficina? No tengo conocimiento de ninguna actividad de este tipo en este proyecto. Beeblebrox ( charla ) 18:29, 26 de febrero de 2021 (UTC)
- Soporte en principio, con detalles para posterior determinación. Hay dos tipos de razones por las que se debería exigir a alguien que deje de ser administrador. Una, que arb com maneja adecuadamente, son las violaciones graves o repetidas de una política clara sobre el uso de los derechos de administrador, o el uso burdo o repetido de los derechos de administrador de tal manera que infrinja gravemente la política general de WP. La otra, que en realidad no se aborda en absoluto, es la falta de retención de la confianza de la comunidad. Cuando se eligen administradores, se consideran ambos tipos: deben conocer la política administrativa y no dar indicaciones de que sean propensos a violar la política en general, Y deben tener la confianza, por cualquier motivo, de la supermayoría del 65 al 75% de la comunidad. No es necesario dar una razón explícita para un voto positivo o negativo, solo la implicación de que el votante cree que puede hacer correctamente el trabajo y tiene su confianza (aunque a veces los burócratas tienen en cuenta razones más específicas de una forma u otra, y razones más específicas pueden influir mucho en otros votantes). Gran parte del trabajo de los administradores es seguir las reglas en situaciones inequívocas, pero dependiendo de lo que elijan hacer, también implica juzgar el consenso informado de la comunidad en situaciones ambiguas. Este tipo de juicio no puede regirse por pautas estrictas (si lo hiciera, no habría situaciones ambiguas) y requiere la confianza general de la gente de la comunidad en que la decisión será justificada y racional. La mayoría de los administradores activos en general retienen esta confianza, pero siempre habrá algunos que actúen de manera errática o irresponsable o lleguen a considerar que sus opiniones privadas son el consenso. Las personas en las que la comunidad cree que no puede confiar al respecto no son elegidas como administradores. Las personas que, después de haber ejercido sus derechos, la comunidad concluye que ya no tienen esa confianza o que se puede demostrar que nunca fueron dignas de confianza, ya no deberían ser administradores. Arb com no está equipado para emitir estos juicios. La mayoría de los arbs son personas que no son necesariamente representativas de la comunidad en todos los sentidos, ni deberían serlo, ya que se eligen sobre la base de que, de toda la comunidad, son especialmente adecuados para el tipo de juicios difíciles que se necesitan, y su compromiso total de mantener la privacidad. Según mis 5 años allí, la mayoría de los arbs, incluido yo mismo, no puedo estar seguro de que realmente estemos expresando la gama completa de opiniones de la comunidad; a diferencia de los administradores, se espera que los arbs hagan sus propios juicios, no solo ejecuten lo que la comunidad juzgaría. correcto en la forma en que lo hace el administrador.
- La única forma en que se pueden contar los verdaderos puntos de vista de la comunidad es haciendo que la comunidad en general los exprese, y la única forma justa de juzgar que aceptamos es la de votar. La votación puede dar o no el resultado "ideal" final, pero ofrece una visión general de la comunidad total de editores activos e interesados. Y en un sistema como el nuestro, que no está dictado jerárquicamente por una aristocracia o un gobierno o una junta directiva, solo esa visión general es lo que en última instancia debería importar.
- La razón por la que se requiere una cantidad menor de apoyo numérico para desysop que para sysop es que ninguna persona muy activa puede evitar tener antagonismo y ser susceptible a la censura de las camarillas; esto se aplica tanto a los administradores como a los arbs. Cuál debería ser el porcentaje exacto y las otras condiciones detalladas realmente no se pueden determinar de antemano; es razonable que adoptemos esto para una prueba de un año y luego lo reconsideremos. DGG ( charla ) 04:55, 26 de febrero de 2021 (UTC)
- En cuanto a su último punto, sobre un umbral de soporte más bajo. Tenemos varios RfA de reconfirmación, todos por "personas activas", y todos pasaron fácilmente con un 75% + de apoyo. Aquí hay algunos ejemplos: Wikipedia: Solicitudes de administración / Harrias 2 , Wikipedia: Solicitudes de administración / LessHeard vanU 2 , Wikipedia: Solicitudes de administración / HJ Mitchell 3 . En mi opinión, siempre que se utilice cualquier tipo de formato RfA, simplemente no podemos aceptar que un editor tenga herramientas de administración si tiene menos del 50% de apoyo de la comunidad para hacerlo. El 40% de apoyo no es apoyo de la comunidad. Si la barra para retener las herramientas debe establecerse tan baja, el proceso no debe usarse en absoluto. Nsk92 ( conversación ) 11:27, 27 de febrero de 2021 (UTC)
- Soporte vencido. No confío en los administradores más que en otros usuarios fundamentalmente. Revocar su estado de forma registrada es la única forma en que la comunidad puede poner a los administradores bajo control. KitsuneLogic ( charla ) 09:02, 26 de febrero de 2021 (UTC)
- Soporte . Si bien no es perfecto, representa una mejora con respecto al sistema existente. RecycledPixels ( charla ) 17:06, 26 de febrero de 2021 (UTC)
- Soporte: condicionado a aumentar el porcentaje necesario para seguir siendo un operador de sistema . Si corregimos la redacción para tener un requisito del 60% para la retención, no del 40%. Necesitamos algo: ARBCOM no cuenta con suficiente personal para manejar estas cosas, sin importar cuán diligentes sean. Espero que esto sea una válvula de seguridad para evitar que las situaciones se agraven durante un largo período hasta que terminen involucrando a la WMF. Además, tal vez requerir una retención del 60% mitigará el escenario de que un administrador errante o abusivo sea retenido porque tiene suficientes amigos para salvar su administración. Nada será perfecto nunca, pero el sistema es actualmente demasiado defectuoso y necesitamos una mejora. - Maile ( conversación ) 22:54, 26 de febrero de 2021 (UTC)
- @ Maile66 : ¿Puede explicar por qué siente que "ARBCOM no tiene suficiente personal"? No he visto nada que sugiera que lo sea. Sofocar ( charla ) 11:17, 11 de marzo de 2021 (UTC)
- Soporte Mejor que el proceso actual y al menos 10 años de retraso. La comunidad necesita un método para eliminar administradores por causa. Si la comunidad los elige, deberían poder eliminarlos de la misma manera. ♟♙ ( hablar ) 00:31, 27 de febrero de 2021 (UTC)
- Soporte por EnPassant CanadianOtaku Talk Página 04:37, 27 de febrero de 2021 (UTC)
- El soporte debería ser más sencillo, pero se necesitan cambios para ayudar a deshacerse de los administradores realmente terribles. Los muchos, muchos buenos administradores no se verían afectados. Si sacude la mentalidad de la mafia del club de chicos buenos, lo apoyo. GaryColemanFan ( charla ) 06:44, 27 de febrero de 2021 (UTC)
- Más o menos por iridiscente. No creo que el porcentaje de apoyo necesario para mantener sea importante, pero debe ser al menos 50% + 1 según el comentario de seguimiento de Iridescent. Jo-Jo Eumerus ( charla ) 11:33, 27 de febrero de 2021 (UTC)
- Soporte Esto es bastante similar a mi proceso de recuperación personal . Creo firmemente que la administración la otorga la fe de la comunidad, y que perder esa fe significa que ya no debería haber dicho privilegios en la comunidad. Es un privilegio ser administrador, no un derecho. Estoy de acuerdo en que debería ser un poco difícil de hacer, ya que es algo serio y uno debe tener una buena evaluación sobre si la fe de la comunidad está realmente perdida. Charla de Red Phoenix 16:53, 27 de febrero de 2021 (UTC)
- Soporte . Facilitar la eliminación de administradores problemáticos hará que las RfAs sean más fáciles de aprobar, porque el proceso de desysop proporciona un respaldo en caso de que el administrador se comporte de manera inapropiada. Creo que esto resultará en un aumento neto de administradores. Prefiero un umbral superior al 60%; Creo que la desocupación debería ser tanto un proceso basado en el consenso como el RfA, lo que significa un rango discrecional del 65-75%. Pero este es un paso en la dirección correcta. feminista (charla) 16:57, 27 de febrero de 2021 (UTC)
- Si observa detenidamente las RfA durante los últimos años, verá que los candidatos exitosos tienden a aprobar con bastante facilidad y el proceso se ha vuelto menos polémico. Los candidatos que se estrellen y se quemen en RfA ahora todavía se estrellarán y se quemarán, incluso si esta propuesta se implementa. El problema real en RfA es que la cantidad de editores de WP regulares no está creciendo significativamente, pero el trabajo real de ser administrador se está volviendo cada vez más complicado y abrumador. Tener la perspectiva de un espectáculo público como el previsto en esta propuesta no hará que la gente esté más dispuesta a postularse para RfA, todo lo contrario. Nsk92 ( conversación ) 02:09, 28 de febrero de 2021 (UTC)
- Los administradores de soporte deben ser responsables ante la comunidad en general, no solo ante ArbCom. Hay suficientes controles y contrapesos para hacerme pensar que es poco probable que se abuse del sistema. PinkPanda272 ( charla / contribuciones ) 18:49, 27 de febrero de 2021 (UTC)
- Soporte muy retrasado. Headbomb { t · c · p · b } 21:09, 27 de febrero de 2021 (UTC)
- Apoyo el concepto , pero no soy el mayor admirador de cómo se presenta arriba; parece demasiado complicado para lograr algo en realidad. " Cualquier usuario extendido confirmado y ha realizado al menos 25 ediciones en los últimos 6 meses " es demasiado restrictivo; cualquier usuario registrado puede apoyar u oponerse a una RfA, por lo que cualquier persona debería poder iniciar o votar una solicitud de eliminación. " 10 usuarios confirmados extendidos [...], tres administradores actuales " es demasiado burocrático. No entiendo por qué necesitaríamos que los administradores examinen a otros administradores si todas las acciones, excepto dos, son públicas. Podría entenderlo si las preocupaciones giraran en torno al uso del botón de eliminar, pero aparte de eso, creo que cualquiera debería poder responsabilizar a los administradores, no solo a otros administradores. Además, el requisito de un plazo de 48 horas también es demasiado procesal. Puedo apreciar que estamos tratando de evitar las trampas de la respuesta de ArbCom de medio año en los casos, pero creo que dejar las discusiones abiertas por períodos de tiempo no revelados da como resultado una mejor discusión, especialmente si luego vamos a proceder a una procedimiento RfA de siete días. Es posible que necesitemos más de nueve días o es posible que necesitemos menos. Al involucrar a RfA, hemos reservado al menos siete días, así que deje la discusión anterior sin restricciones (en su mayor parte). Anarchyte ( charla • trabajo ) 09:56, 28 de febrero de 2021 (UTC)
- apoyar un buen proceso pero un poco complicado 007sak ( hablar ) 11:10, 28 de febrero de 2021 (UTC)
- apoyo Ese diagrama de flujo fue suficiente para comprender el proceso (aunque creo que podría necesitar un poco de trabajo). Habría agregado algo acerca de que el administrador está a punto de ceder el bit por un tiempo para posponer el RfA durante ese tiempo (tal vez con un límite de 3 o 6 meses), ya que pude ver que uno podría no tener tiempo. para hacer frente a un RfA en un período arbitrario de 2 semanas. Creo que el 60% necesario para eliminar es quizás * demasiado * alto, pero tengo la idea de que se necesita histéresis. Podría haber elegido el 50% o el 55%. Hobit ( charla ) 12:55, 28 de febrero de 2021 (UTC)
- Soporte: Pensé mucho en esto y leí todos los argumentos de esta página. Lo que me empujó al límite fueron dos cosas. Primero, será mucho más fácil pasar un proceso de 60% / 40% y luego modificarlo a 65% / 35% o 75% / 25% de lo que sería obtener ciegamente los porcentajes perfectos la primera vez. En segundo lugar, he estado pensando en WP: FRAMSUM , donde, en mi opinión, W? F intimidó a arbcom para que investigara algo que habrían rechazado si usted o yo lo hubiésemos presentado. No creo que un proceso de sysop de la comunidad sea tan fácil de intimidar, y creo que un proceso de sysop de la comunidad le da a Arbcom una buena "salida"; en lugar de simplemente rechazar ciertas solicitudes, pueden rechazar-mientras-sugieren-el-proceso-del-sistema-de-comunidad. - Guy Macon ( charla ) 13:57, 28 de febrero de 2021 (UTC)
- Err, creo que necesitas releer esos argumentos que mencionas nuevamente, particularmente la sección "No es 60%, es 40%" en esta página. La principal objeción a los porcentajes propuestos es que el umbral propuesto del 40% a favor de retener los derechos de administrador difiere demasiado radicalmente del estándar existente de RfA de demostrar el apoyo de la comunidad para que alguien tenga derechos de administrador (65% de apoyo). Con respecto a Framgate y WMF, ese tipo de situación ocurrió exactamente una vez en la historia de Wikipedia. Por otro lado, los hilos ANI / AN relacionados con los administradores ocurren todo el tiempo. La cantidad de drama y comportamiento cliquístico aumentará enormemente si se implementa esta propuesta. Nsk92 ( conversación ) 15:20, 28 de febrero de 2021 (UTC)
- Soporte . Creo que los administradores sirven para el placer de la comunidad, por lo que la comunidad debe tener alguna forma directa de eliminar a un administrador problemático. Apoyo la creación de dicho proceso, luego podemos ver qué tan bien funciona y modificarlo si es necesario .-- Mojo Hand ( charla ) 15:31, 28 de febrero de 2021 (UTC)
- Soporte: Se plantea un punto muy válido. Estoy totalmente de acuerdo con eso. Hindustanilanguage ( charla ) 16:08, 28 de febrero de 2021 (UTC)
- Soporte No estoy demasiado enamorado con los detalles detallados, pero en general sería una mejora. Hrodvarsson ( charla ) 20:29, 28 de febrero de 2021 (UTC)
- Soporte : Necesitamos una mejor manera de eliminar administradores incorrectos. Esta propuesta está lejos de ser perfecta, pero al menos es una mejora. Wikiman2718 ( charla ) 21:39, 28 de febrero de 2021 (UTC)
- Soporte Se necesita un proceso para esto, y esta parece una solución tan buena como cualquier otra. Natureium ( charla ) 22:24, 28 de febrero de 2021 (UTC)
- Apoyo El umbral para la remoción es lo suficientemente alto, y el marco de tiempo lo suficientemente corto, para que el proceso no interrumpa la función administrativa (como preocuparse por un desysop por cada acción algo controvertida o audaz). Zoozaz1 charla 00:44, 1 de marzo de 2021 (UTC)
- Soporte Este es el primer proceso de desysop racional que he visto y tiene mucho sentido. Estoy feliz de verlo progresar hacia la aceptación. scope_creep Talk 16:23, 1 de marzo de 2021 (UTC)
- Soporte No es perfecto, pero confío en que se repetirá y mejorará con el tiempo. Legoktm ( charla ) 20:46, 1 de marzo de 2021 (UTC)
- Soporte Sigue siendo demasiado complicado y, por lo tanto, seguirá siendo una desventaja para todos, excepto para los usuarios más experimentados. Pero es mejor que nada. Los sysops no sirven syops. Sirven al proyecto y a la comunidad. Por lo tanto, no deben responder únicamente ante un tribunal de otros operadores de sistema. G M G talk 21:39, 1 de marzo de 2021 (UTC)
- Soporte , con revisión después de 1 año. Existe un acuerdo general de que es deseable un proceso alternativo de desysop, y éste parece estar bien pensado y con suficientes garantías. Espero que Arbcom siga siendo una ruta viable para los desysops también, aunque es de esperar que esto les permita centrarse más en su función original de resolución de disputas en lugar de tener que ser la policía administrativa. También tengo la esperanza de que la mejora de la responsabilidad de los administradores genere una mayor disposición para promover otros nuevos. el wub "?!" 00:00, 2 de marzo de 2021 (UTC)
- Apoyo Enfoque equilibrado y justo. Mpajor2020 ( charla ) 09:09, 02 de marzo de 2021 (UTC)
- Soporte , falta una mejor opción. Benjamin ( charla ) 09:33, 2 de marzo de 2021 (UTC)
- Apoyo Muchos opositores se basan en el argumento de que necesitamos un proceso de desysop basado en la comunidad, pero que la propuesta es de alguna manera defectuosa (por ejemplo, el procedimiento es demasiado complicado). A la luz del hecho de que podemos hacer cambios en él en el futuro a medida que aprendamos y veamos qué funciona y qué no, creo que los beneficios de establecer el proceso superan los costos. wikitigresito ( charla ) 14:05, 2 de marzo de 2021 (UTC)
- El soporte siempre que se modifique el proceso de aprobación, lo que requiere 10 usuarios confirmados extendidos, 3 de los cuales son administradores, en 48 horas parece una barrera innecesariamente alta para comenzar una discusión. No creo que deba haber un requisito de administrador (ya que es una población más pequeña de usuarios y el grupo preciso que debe ser verificado por un procedimiento de desysop) y la fecha límite debe ser algo razonable, como una semana. También responderé a continuación, pero creo que otros requisitos arbitrarios deberían eliminarse tanto como sea posible para simplificar el procedimiento. Hacer que el proceso sea inaccesible, por temor al abuso, simplemente lo deslegitimará. - Wingedserif ( conversación ) 15:54, 2 de marzo de 2021 (UTC)
- Más bien hesistant apoyo . Mis preocupaciones expresadas en la sección neutral permanecen; brevemente, estoy preocupado por el efecto en AN / ANI, y también estoy preocupado por wikilawyering con respecto a la redacción específica utilizada. Pero las opiniones opuestas me han convencido de que es fundamentalmente poco probable que veamos más apoyo para una propuesta de desysop de la comunidad, ya que hay una división equitativa entre los que creen que esto es un listón demasiado alto para un desysop y los que creen que es demasiado bajo. Entonces, a pesar de mis reservas, prefiero trabajar para afinar una propuesta que parece estar en la zona de los ricitos de oro en lo que respecta a toda la población de votantes. En ese sentido, idealmente me gustaría ver algún tipo de discusión moderada en AN / ANI, o un requisito administrativo, o algo para mitigar la cultura de todo vale que hemos desarrollado allí. En segundo lugar, me opondría firmemente a cualquier intento de cambiar el umbral de desysop al 40% de eliminación de apoyo, según Iridiscente anterior; Si queremos que los administradores sigan trabajando en nuestras áreas conflictivas, el 40% es una barra demasiado baja. Vanamonde ( Discusión ) 16:46, 2 de marzo de 2021 (UTC)
- Apoyo fuerte. No estoy seguro de que me gusten todos los detalles de esta propuesta. Sin embargo, hemos llegado al punto en que cualquier propuesta razonable a medio camino es mejor que la que tenemos ahora. La única parte específica de esto que no me gusta es la sección AN / ANI, pero honestamente, es intrascendente preparada con todo lo demás. Podemos revisar el procedimiento más adelante a la luz de más experiencia. También le imploro a quien cierre esta propuesta que considere el fuerte consenso entre la comunidad de que se debe hacer algo . Si esto está al borde de un cierre sin consenso, eso debería pesar a favor de cerrarlo como se adoptó. Tamwin ( charla ) 04:23, 3 de marzo de 2021 (UTC)
- Ese es un ejemplo perfecto de la falacia del Sí Ministro : "Debemos hacer algo. Esto es algo. Por lo tanto, debemos hacerlo". - O Still Small Voice of Clam 12:49, 3 de marzo de 2021 (UTC)
- Soporte Esto parece un buen punto de partida para un proceso de desysop basado en la comunidad y no hay razón para que no se pueda modificar más adelante. Además, es claramente necesario. - Adamant1 ( conversación ) 06:43, 3 de marzo de 2021 (UTC)
- Soporte . La propuesta parece ser un equilibrio razonable entre la formalización de la responsabilidad administrativa mediante la discusión comunitaria, mientras se mantienen suficientes garantías procesales para desalentar los litigios frívolos. Deryck C. 13:45, 3 de marzo de 2021 (UTC)
- Soporte . Buena decisión, Tony. ¡Ya era hora también! diseño nagual 17:21, 3 de marzo de 2021 (UTC)
- Soporte - muy retrasado. Smallbones ( smalltalk ) 17:56, 3 de marzo de 2021 (UTC)
- Soporte con un período de prueba . Solo se puede llegar hasta aquí con consideraciones teóricas sobre algo como esto; la prueba está en el pudín. Démosle una vuelta, y si ANI explota con informes "básicos" de mala fe o todos están descontentos por otras razones, retrocedemos. - Elmidae ( charla · contribuciones )
- Soporte Definitivamente. Un enfoque equilibrado y sencillo. Me gusta. ¡Consenso! ─ The Aafī (charla) 16:55, 4 de marzo de 2021 (UTC)
- Soporte : es un estándar alto y es necesario que exista una política como esta para los casos muy raros de abuso de administradores (personalmente nunca me he encontrado con un administrador realmente enrojecido, pero es posible imaginarlo). La idea de que 'los administradores deben poder tomar decisiones que serán impopulares' es cierta, pero también es una gran falacia en este contexto. Si es posible que alguien pueda ser degradado indebidamente bajo estos complejos procedimientos, lo que requeriría la aprobación de tres administradores antes incluso de iniciarse oficialmente, y luego necesitaría la aprobación del 60% de la comunidad en general, entonces todo el sistema está roto. Respetuosamente, no puedo imaginar cómo esto tendría un "efecto escalofriante" en cualquier administrador racional. ‡ Єl Cid de Valencia charla 16:59 4 de marzo 2021 (UTC)
- Soporte Un enfoque equilibrado, hará que los administradores sean más cuidadosos con sus acciones, lo que siempre es necesario para algunos administradores. USaamo ( t @ lk ) 03:33, 5 de marzo de 2021 (UTC)
- Soporte - Hnsjrgnweis 10:52, 5 de marzo de 2021 (UTC)
- Soporte Mejor que el statuus quo y proporciona una plataforma para mejoras. Tazerdadog ( charla ) 22:00, 5 de marzo de 2021 (UTC)
- El soporte de 48 horas debe cambiarse a 72 horas, de lo contrario, mucha gente ni siquiera sabrá que existe la propuesta de desysop. No creo que esto desanime a los administradores de trabajar en áreas polémicas, ya que creo que otros administradores usarán el sentido común y no apoyarán una propuesta frívola. - Gladamas ( charla · contribuciones ) 03:57, 6 de marzo de 2021 (UTC)
- Soporte por arriba. ~ HAL 333 00:20, 7 de marzo de 2021 (UTC)
- Apoyo : apoyo esto como un paso en la dirección correcta. Aunque obviamente elementos de la propuesta actual son palpables disparates (especialmente el límite de 48 horas). Como han dicho otros, las posibilidades de utilizar con éxito este proceso para eliminar un administrador inactivo deben ser extremadamente pequeñas. Traer de vuelta a Daz Sampson ( charla ) 18:15, 7 de marzo de 2021 (UTC)
- Soporte : esta es una propuesta increíblemente bien pensada de TonyBallioni . Hace mucho que se necesita un mecanismo fuera de ArbCom, especialmente para casos como estos:
207.161.86.162 ( conversación ) 03:41, 9 de marzo de 2021 (UTC)Creo que en los últimos 2 años, han surgido muchas preocupaciones en torno a las acciones inapropiadas de los administradores que no están familiarizados con la práctica actual y que luego desaparecen o continúan comportándose fuera de las normas en pequeñas formas. Creo que es muy probable que exista un consenso de la comunidad para eliminarlos, pero que tendrías muchas dificultades para lograr que ArbCom abra un caso.
- Usuario: TonyBallioni 18:37, 21 de febrero de 2021 (UTC) - Soporte . Es mejor tener un procedimiento defectuoso que permanecer en el status quo. El número de administradores necesarios para iniciar el proceso debería ser 2 o incluso 0, pero estuve de acuerdo en que necesita algunos administradores para eliminar las acciones frívolas. Aunque en ese sentido, los editores de mucho tiempo también deberían tener derecho a iniciar el proceso, ya que los editores de mucho tiempo pueden no ser administradores, y WP: TROPHY declaró claramente que los administradores no tienen un rango más alto que el resto de los editores. El proceso se mejoraría con el tiempo y, a pesar de las fallas, es mejor que no tener ningún proceso y reiniciar todo el próximo año. Al menos con algún proceso defectuoso, podemos enfocarnos en los defectos, no en todo el proceso. Como proceso, es necesario eliminar a los administradores realmente malos. Todo este proceso solo perjudicará a los administradores realmente malos. SunDawn ( charla ) 08:28, 9 de marzo de 2021 (UTC)
- Soporte . Podría discutir con los detalles, pero necesitamos un proceso de control de la comunidad y esto tiene suficientes garantías para no ser usado frívolo o tener un efecto paralizador. Vallas y ventanas 00:52, 10 de marzo de 2021 (UTC)
- Soporte Se necesita algo, no un fan de los porcentajes que se proponen (solo se necesita ~ 40% para "mantener" el bit de sysop si se cumple todo lo demás), pero esto es aún mejor que no tener nada en absoluto. Y nada de esto impide el uso del arbitraje si este sistema falla. - Locke Cole • t • c 04:20, 16 de marzo de 2021 (UTC)
- Apoyo muy fuerte Nosotros, como comunidad, elegimos a los administradores. Deberíamos tener derecho a quitárnoslo. Night Wolf 1223 14:47, 19 de marzo de 2021 (UTC)
- Apoyar un proceso de desysop comunitario. Este en realidad me parece débil, pero como han dicho otros, es un lugar para comenzar. No debería ser más fácil sancionar a un editor que eliminar los privilegios de administrador. También podríamos implementar un proceso para la eliminación temporal de herramientas de administración. La administración no es sagrada y perder un privilegio que la mayoría de la gente no tiene no es un castigo. Kolya Butternut ( charla ) 17:50, 21 de marzo de 2021 (UTC)
- Apoyo Creo que esta es una propuesta razonable con las salvaguardas apropiadas para abordar las preocupaciones de la comunidad de discusiones anteriores. Se pueden agregar ajustes específicos a los detalles de implementación según sea necesario, si se aprueba. DanCherek ( charla ) 01:22, 22 de marzo de 2021 (UTC)
- Apoyo : He leído los apoyos y contrarios. Como mencioné, también tengo fe en los administradores y ARBCOM. El título es Solicitudes de comentarios / Política de Desysop (2021) y aquí es donde se deben sacar a la luz las inquietudes y ofrecer soluciones "si" parece (como sucede) que hay apoyo general, y se puede avanzar desde allí. Veo que hay lo que me parece ser algo de miedo. De los +/- 45 administradores (un Steward seguro) en apoyo, no veo justificación para, como dijo Wehwalt : "Protección insuficiente contra una turba aullante", y no parece ser un problema que no se pueda solucionar. fuera. Varios administradores que se opusieron estuvieron de acuerdo en que debe haber un proceso (incluidos los primeros 4), pero tienen inquietudes. Se mencionó que hubo
un apoyo generalizado para un procedimiento alternativo de desocupación basado en la opinión de la comunidad, pero que no involucra a ArbCom.
( Wikipedia: DESYSOP2019 ) que aún no he leído. Tal vez me he perdido algo, pero 10 editores sólo pueden "iniciar" tal procedimiento, ¿correcto? Luego iría a la "comunidad" que probablemente no caería en una red de engaños debido a algunos editores descontentos. Tener un procedimiento alternativo (a ARBCOM) y no necesitarlo es mejor que no tener un proceso comunitario en absoluto. Argumentos de que "tenemos un proceso comunitario" porque ARBCOM es la comunidad no es lo mismo. Puede funcionar, y bastante bien, pero en caso de que exista una falla, debería haber una resolución basada en la comunidad. Nosotros (Wikipedia) aprendimos mediante un proceso (FRAM) que la comunidad tiene más poder de lo que muchos imaginaban por tener un brazo fuerte. Hubo comentarios de miembros de la WMF que fueron 100% inapropiados. Comentarios como los que había visto, si los hubiera hecho un administrador, serían motivo para examinar si las acciones de esa persona eran motivo para considerar la desocupación. Si el consenso es para "considerar" tal procedimiento, entonces es el momento de hacerlo, teniendo en cuenta que algunos consideran que"requiere una reelaboración sustancial"
( SmokeyJoe ) - Otr500 ( charla ) 17:27, 5 de abril de 2021 (UTC) - Soporte : en ru.wp tuvimos un caso con el administrador Sealle , quien violó WP: SOCK , hubo un consenso de que era necesaria la confirmación / eliminación de la bandera, pero no había ningún procedimiento excepto ArbCom. Y ArbCom (yo estaba entre los árbitros) tampoco estaba seguro, debería ser la confirmación o la eliminación de la bandera (en nuestra wiki, las violaciones de las reglas no eran severas). Era completamente obvio que el administrador había perdido la confianza de la comunidad. Y un administrador sin la confianza de la comunidad es una fuente de decisiones que serán cuestionadas simplemente porque ha perdido la confianza. En ruwiki decidimos que debe haber algún tipo de procedimiento fuera de arbitraje para eliminar la bandera de administrador ru: ВП: Г-КОНФ : 76% fue para eso. Luego también realizamos una encuesta, reunimos a un grupo para resumirla y establecimos que la bandera de administrador debe ser confirmada por votación, es decir, de la misma manera que se obtiene esta bandera. ru: ВП: О-КОНФ2 . Donde han surgido las discrepancias es en el mecanismo de lanzamiento de la confirmación. ¿Debería hacerlo un grupo de iniciativa (potencialmente un mecanismo generador de conflictos) o debería hacerse con regularidad (por ejemplo, cada 5 años, pero de todos modos con mucho alboroto innecesario)? Las opiniones estaban divididas, ahora estamos buscando enfoques adicionales a este problema, por ejemplo, un lanzamiento simplificado de la confirmación a través de ArbCom bajo ciertas condiciones o algún tipo de "corte de honor" / "código de conducta" para los administradores. · Carn · !? 14:27, 14 de abril de 2021 (UTC)
Oponerse a
- Según mis comentarios en la sección de discusión. En general, creo que esto es necesario y quiero apoyarlo, pero tengo demasiadas preocupaciones sobre los detalles. Beeblebrox ( charla ) 22:05, 20 de febrero de 2021 (UTC)
- Por Beeblebrox; También quiero apoyar, pero tengo demasiadas preocupaciones. En particular, este proceso, como muchos otros procesos comunitarios, es un circuito de retroalimentación. - Ryk72 talk 00:00, 21 de febrero de 2021 (UTC)
- ¿Bucle de retroalimentación? · · · Peter Southwood (charla) : 05:48, 21 de febrero de 2021 (UTC)
- Retroalimentación en este sentido. A lo largo de múltiples iteraciones, los procesos de "vote por usted fuera de la isla / fuera del club infantil genial" refuerzan y arraigan los prejuicios y prejuicios de la comunidad; particularmente procesos con participantes / votantes auto-seleccionados. Y, aunque aprecio la intención y la reflexión puesta en la propuesta, considero que el proceso anterior es demasiado complejo y, en algunos lugares, desequilibrado - "y ha realizado al menos 25 ediciones en los últimos 6 meses" es innecesario; "incluyendo al menos tres administradores actuales", paso 3 y "60%" son perjudiciales y no es probable que cambien una vez que se implemente el proceso. Si vamos a tener un proceso de votación, los administradores deben demostrar que conservan la confianza de la comunidad; con (la barra fijada en) al menos 50% a favor de que retengan las herramientas (; probablemente más alto). - Ryk72 talk 11:00, 21 de febrero de 2021 (UTC) - aclaración Ryk72 talk 12:05, 21 de febrero de 2021 (UTC)
- Sin embargo, el 50% es un problema: ¿por qué los administradores deberían poder permanecer como administradores con solo el 50% de soporte, cuando los editores perfectamente capaces y competentes no pueden aprobar RfA con el 50% de soporte de esa comunidad? Sé que son manzanas versus peras, pero aún así ... Y sí, si se trata de eso, probablemente estoy abogando por bajar el listón en RfA, no subir el listón en una discusión desysop. Nick ( hablar ) 11:54, 21 de febrero de 2021 (UTC)
- Estoy completamente de acuerdo; por eso he incluido, y enfatizado, "al menos". La barra debe ser al menos tan alta como un 50% de soporte para retener; probablemente mayor. El proceso, tal como está redactado y propuesto, requiere un 60% de apoyo para el desysop y (suponiendo que se permitan respuestas neutrales) permite a los administradores retener herramientas con entre 0% y 40% de apoyo para que lo hagan; esto es problemático. - Ryk72 talk 12:01, 21 de febrero de 2021 (UTC)
- Una vez que algunos han sido administradores durante algún tiempo, por lo general han tomado una serie de decisiones que eran correctas, pero que aún molestaban a algunas personas. En consecuencia, es muy probable que un proceso DeRFA haga que esas personas apoyen la eliminación independientemente de la causa. Como tal, requerir un porcentaje más alto para eliminar tiene sentido para contrarrestar estos impulsos. Saludos Así que ¿Por 14:19, 21 de Febrero 2021 (UTC)
- Entiendo esta línea de pensamiento. Estoy de acuerdo con las dos primeras oraciones y en desacuerdo con la última. Me siento cómodo con una barra más baja para retener al administrador que para ganarla inicialmente; pero no para que esa barra esté por debajo del 50%. También estoy de acuerdo con el pensamiento anterior de abogar por bajar el listón en RfA. - Ryk72 talk 14:25, 21 de febrero de 2021 (UTC)
- Una vez que algunos han sido administradores durante algún tiempo, por lo general han tomado una serie de decisiones que eran correctas, pero que aún molestaban a algunas personas. En consecuencia, es muy probable que un proceso DeRFA haga que esas personas apoyen la eliminación independientemente de la causa. Como tal, requerir un porcentaje más alto para eliminar tiene sentido para contrarrestar estos impulsos. Saludos Así que ¿Por 14:19, 21 de Febrero 2021 (UTC)
- Estoy completamente de acuerdo; por eso he incluido, y enfatizado, "al menos". La barra debe ser al menos tan alta como un 50% de soporte para retener; probablemente mayor. El proceso, tal como está redactado y propuesto, requiere un 60% de apoyo para el desysop y (suponiendo que se permitan respuestas neutrales) permite a los administradores retener herramientas con entre 0% y 40% de apoyo para que lo hagan; esto es problemático. - Ryk72 talk 12:01, 21 de febrero de 2021 (UTC)
- Sin embargo, el 50% es un problema: ¿por qué los administradores deberían poder permanecer como administradores con solo el 50% de soporte, cuando los editores perfectamente capaces y competentes no pueden aprobar RfA con el 50% de soporte de esa comunidad? Sé que son manzanas versus peras, pero aún así ... Y sí, si se trata de eso, probablemente estoy abogando por bajar el listón en RfA, no subir el listón en una discusión desysop. Nick ( hablar ) 11:54, 21 de febrero de 2021 (UTC)
- Retroalimentación en este sentido. A lo largo de múltiples iteraciones, los procesos de "vote por usted fuera de la isla / fuera del club infantil genial" refuerzan y arraigan los prejuicios y prejuicios de la comunidad; particularmente procesos con participantes / votantes auto-seleccionados. Y, aunque aprecio la intención y la reflexión puesta en la propuesta, considero que el proceso anterior es demasiado complejo y, en algunos lugares, desequilibrado - "y ha realizado al menos 25 ediciones en los últimos 6 meses" es innecesario; "incluyendo al menos tres administradores actuales", paso 3 y "60%" son perjudiciales y no es probable que cambien una vez que se implemente el proceso. Si vamos a tener un proceso de votación, los administradores deben demostrar que conservan la confianza de la comunidad; con (la barra fijada en) al menos 50% a favor de que retengan las herramientas (; probablemente más alto). - Ryk72 talk 11:00, 21 de febrero de 2021 (UTC) - aclaración Ryk72 talk 12:05, 21 de febrero de 2021 (UTC)
- ¿Bucle de retroalimentación? · · · Peter Southwood (charla) : 05:48, 21 de febrero de 2021 (UTC)
- Aparcar aquí ya que hay bastantes preguntas sin resolver a continuación que podrían cambiar el contenido de lo que se está votando. Apoyo un proceso de desysop comunitario en general. - Charla xaosflux 04:36, 21 de febrero de 2021 (UTC)
- Estoy "apoyando el apoyo", y probablemente lo cambiaré una vez que las discusiones a continuación se resuelvan más. - Charla xaosflux 05:35, 21 de febrero de 2021 (UTC)
- No apoyo la adición de las partes int-admin a esta política, crea una superposición de otras políticas existentes y no mejora las opciones para tratar con malos int-admins, no se ha identificado ningún beneficio por agregar este componente. - xaosflux Talk 12:37, 21 de febrero de 2021 (UTC)
- Oponerse a una política innecesaria con respecto a los administradores de interfaz; Neutral en los componentes relacionados con los administradores (todavía creo que hay algunas lagunas con respecto al proceso en relación con los tiempos de las renuncias); indeciso sobre el complemento desburócrata. - xaosflux Talk 15:31, 22 de febrero de 2021 (UTC)
- También se oponen al uso de WT: RFA como tablón de anuncios, si estos deben estar en RFA, deberían estar en una nueva sección de WP: RFA . - xaosflux Talk 15:12, 25 de febrero de 2021 (UTC)
- Oponerse a una política innecesaria con respecto a los administradores de interfaz; Neutral en los componentes relacionados con los administradores (todavía creo que hay algunas lagunas con respecto al proceso en relación con los tiempos de las renuncias); indeciso sobre el complemento desburócrata. - xaosflux Talk 15:31, 22 de febrero de 2021 (UTC)
- Opónganse por los de arriba. Es muy probable que apoye la creación de dicho proceso, pero no puede respaldar estos detalles. - Godsy ( TALK CONT ) 05:10, 21 de febrero de 2021 (UTC)
- Me preocupa el proceso que se describe aquí; tiene una sensación de doble peligro. Me gustaría imaginar que alguien que se ha comportado de forma inapropiada debería ser animado a mejorar su comportamiento. El proceso que se describe aquí se siente más punitivo. Además, "se comportó de manera inapropiada" es demasiado vago; un cierre que incluye "truchas por todas partes" podría interpretarse como una conclusión de que alguien se comportó de manera inapropiada. Creo que necesitamos algo que incentive la mejora del comportamiento y que le dé a alguien una ventana protegida en la que mejorar. Guettarda ( charla ) 05:22, 21 de febrero de 2021 (UTC)
- Oponerse "La solicitud debe vincularse a al menos un hilo en un foro de la comunidad como AN o ANI que se cerró en los últimos 6 meses donde la declaración de cierre indica que hubo consenso de que el administrador se comportó de manera inapropiada". Todos cometemos errores, todos somos humanos y, aunque creo que estoy bastante al día con las políticas y las pautas, siempre hay cosas que no sé. El 'al menos uno' sigue siendo 'un strike es suficiente'; 'foro de la comunidad como AN o ANI' todavía puede ser un oscuro tablón de anuncios de la comunidad; 'el administrador se comportó de manera inapropiada' es demasiado vago, hay varias acciones que están dentro de la política o pauta, pero atrape a los oponentes correctos y se enfrentará a que es 'inapropiadamente' (especialmente en un tablón de anuncios oscuro). Ten a tus fans a tu alrededor y estarás bien incluso si 'te comportas de manera inapropiada', caes en desgracia e incluso algo dentro de la política puede ser inapropiado. Apoyo plenamente el hecho de que necesitamos esto, pero esto, como está escrito, es un atajo a un ArbCom que requiere niveles que están muy por debajo de lo que normalmente iría a ArbCom (generalmente no informamos a ArbCom en un AN negativo ( / I). - Dirk Beetstra T C 05:45, 21 de febrero de 2021 (UTC)
- Oponerse . La terrible experiencia descrita suena horrible. Si una persona está en el extremo equivocado de un hilo AN / I, entonces tiene que vigilar su espalda en sentido figurado durante seis meses (tal vez incluso considere alejarse por completo de Wikipedia para permitir que transcurran los seis meses). No le permite a la persona de AN / I, si se enteró de su error, dejar el asunto en paz durante medio año. En el caso de que alguien obtenga los diez respaldos requeridos, entonces esta persona tiene que sudar hasta dos semanas mientras trabaja en su defensa. Luego, cuando comienza la Solicitud de Desysop propiamente dicha, esta persona tiene que (potencialmente) observar a decenas de personas que se acumulan durante una semana sobre todos los errores que esta persona ha cometido y por qué no son aptas para la administración. Suena emocionalmente brutal. Prefiero el enfoque (con suerte) discreto de ArbCom. Eso no quiere decir que las personas que comentan sobre el RFD necesariamente carezcan de tacto, solo digo que los de ArbCom son específicamente discretos. Useight ( charla ) 06:17, 21 de febrero de 2021 (UTC)
- Creo que hará que AN tenga tanto en juego, como menos probable que corrija a los administradores, porque todos sabrán lo importante que se ha vuelto. Los administradores que se comportan mal necesitan dominarse y detenerse temprano, pero tendrán menos estímulo para hacerlo, porque AN los 'reivindicará' en su falta de conclusión. - Alanscottwalker ( charla ) 09:07, 21 de febrero de 2021 (UTC)
- Oponerse . Administración. El amiguismo siempre ha sido un factor importante en las discusiones de AN / ANI. Establecer un requisito de "al menos tres administradores actuales, respaldar la solicitud" establece el inicio de un debate de desysop comunitario exitoso demasiado alto. Caldero con goteras ( charla ) 09:35, 21 de febrero de 2021 (UTC) Feliz de apoyar si el umbral se reduce a DOS. Caldero con fugas ( charla ) 10:48, 21 de febrero de 2021 (UTC)
- Si esta propuesta se aprueba con éxito, será necesario prestar mucha atención a cómo se manejan las discusiones de AN / ANI: el intercambio de caballos que ocurre con ArbCom también continúa con otros administradores, y un área que deberá ser analizada con mucho cuidado es el cierre de las discusiones de AN / ANI que podrían conducir a Community Desysop. Existe el riesgo (intencional o involuntario) de que los administradores que comentan afirmen que el problema no es grave o grave, que hubo provocación y existe un riesgo muy significativo de que se soliciten y realicen favores, lo que hará que los hilos de discusión se cierren a medida que el administrador se comporta apropiadamente sin ningún caso para responder. Existe un riesgo igualmente severo de que el quejoso inicial en tal hilo, si no un administrador, sea sujeto a un escrutinio masivamente incrementado, sancionado o bloqueado (por la duración de la discusión o más) y tratado de la manera más injusta. Pero eso está fuera del alcance de esta política y necesitaría más atención si la propuesta tuviera éxito. Nick ( charla ) 10:54, 21 de febrero de 2021 (UTC)
- Estoy de acuerdo en que necesitamos una forma de deshacerse de los administradores problemáticos. No estoy 100% de acuerdo con las decisiones que Arbcom ha tomado durante el proceso de eliminación de votos de nuestra comunidad. Pero han demostrado ser un proceso más matizado y eficaz que el que se detalla aquí. Cuando necesitan moverse rápido con un movimiento para desysop, pueden hacerlo más rápido de lo que este proceso permitiría, cuando necesitan dar tiempo y tratar a las personas con el respeto debido a cualquiera de nuestros voluntarios, también pueden hacerlo. Creo que sería un error tener dos procesos de desysop operando bajo diferentes criterios, así que me opongo a esta propuesta a favor de mantener Arbcom como nuestro proceso de desysop. Insto a aquellos que no estén contentos con nuestros acuerdos actuales a definir qué criterios adicionales creen que Arbcom debería desysop a las personas y presentar una RFC en la línea de "en el futuro, Arbcom debería desysop a los administradores sorprendidos haciendo x" Ϣere Spiel Checkers 12:19, 21 de febrero de 2021 (UTC)
- De acuerdo con muchos de los anteriores. Protecciones insuficientes contra una turba aullante .-- Wehwalt ( charla ) 13:44, 21 de febrero de 2021 (UTC)
- A menos que uno crea en la existencia de la supuesta "brigada anti-administración" (cuya realidad fue ampliamente desacreditada hace un año), sugiero que una supuesta "turba aulladora" (en AN o ANI) tiene el propósito de intentar hacer frente a con las malas prácticas del administrador. No es un mal motivo. Caldero con fugas ( charla ) 13:59, 21 de febrero de 2021 (UTC)
- Si bien la propuesta está bien concebida en general, la necesidad de incluir salvaguardas contra el abuso la hace bastante compleja, con un número relativamente grande de pasos que probablemente se convertirán en puntos focales para el wikilawyering y el drama. Y a pesar de las salvaguardias, es probable que la existencia de este proceso haga que los administradores sean aún más reacios a tomar las medidas necesarias contra editores problemáticos populares y bien conectados (consulte WP: UNBLOCKABLES ). Pero lo más importante es que todavía no me han convencido de que este es un problema que necesita una solución. El número relativamente alto de administradores eliminados por ArbCom me indica que el proceso existente funciona bastante bien. Sandstein 13:49, 21 de febrero de 2021 (UTC)
- Oponerse Ya tenemos un proceso de desysop comunitario: ¡y se llama Arbcom! Arbcom es un proceso de la comunidad, ya que todos los miembros destacados son de la comunidad y también son seleccionados por la comunidad. Que Arbcom no es un proceso comunitario es esencialmente un nombre inapropiado, son tan comunitarios como la comunidad puede ser IMO. ¿Necesitamos un proceso paralelo a Arbcom? Creo que no, funciona bien en mi experiencia, y no ha habido argumentos convincentes de que este no sea el caso. Los casos de Arbcom son extremadamente matizados y tiene una gran cantidad de salvaguardias contra el abuso de mis camarillas de editores. No se me ha demostrado ninguna demostración razonable de que Arbcom haya fallado, y hasta que esto suceda me opondré a procesos paralelos innecesarios y considerablemente más defectuosos. Jules (Mrjulesd) 16:19, 21 de febrero de 2021 (UTC)
- Por lo que vale, WP: DESYSOP2019 cerró con un
amplio soporte para un procedimiento alternativo de desobediencia basado en la opinión de la comunidad, pero no involucra a ArbCom
. Se ha decidido tener uno; simplemente no nos hemos puesto de acuerdo en uno. ~ Amory ( u • t • c ) 13:46, 22 de febrero de 2021 (UTC)- El gran defecto de los RfC como WP: DESYSOP2019 es que imaginan que se puede crear un proceso de desocupación superior (o al menos no inferior) al proceso actual (es decir, Arbcom). Cuando se formula un proceso, se produce una desagradable realización; que es casi completamente inferior al proceso actual. Y para competir con el proceso actual, se tendría que considerar la formación de un cuerpo similar a Arbcom, lo que sería esencialmente inútil. La "prueba está en el pudín" por así decirlo, y este pudín deja un sabor desagradable. Jules (Mrjulesd) 11:56, 25 de febrero de 2021 (UTC)
- Excepto que eso no es lo que dice la gente. Ya sea "solución en busca de un problema" o
ya tenemos un proceso de desysop comunitario: ¡y se llama Arbcom!
, tampoco indica ningún comentario más allá de "No lo quería en primer lugar". Los oponentes que dicenque es casi completamente inferior al proceso actual
son geniales, pero, como ejemplo, no veo ningún juicio sobre la propuesta actual en su oposición, solo oposición a su propia existencia. ~ Amory ( u • t • c ) 14:36, 25 de febrero de 2021 (UTC)- Punto a favor. Pero mi punto es que puede tener RfC como WP: DESYSOP2019 para un "proceso de desysop comunitario" (como si no existiera), pero a menos que proporcione detalles de un proceso real, son discutibles, porque ¿qué pasa si un proceso no satisfactorio? -¿El proceso de comité no existe? Pero si desea algunas inquietudes, consulte las contribuciones de Usuario: Hammersofts , especialmente Archivo: 2021DesysopProcessFlow.gif . - Jules (Mrjulesd) 14:50, 25 de febrero de 2021 (UTC)
- Excepto que eso no es lo que dice la gente. Ya sea "solución en busca de un problema" o
- El gran defecto de los RfC como WP: DESYSOP2019 es que imaginan que se puede crear un proceso de desocupación superior (o al menos no inferior) al proceso actual (es decir, Arbcom). Cuando se formula un proceso, se produce una desagradable realización; que es casi completamente inferior al proceso actual. Y para competir con el proceso actual, se tendría que considerar la formación de un cuerpo similar a Arbcom, lo que sería esencialmente inútil. La "prueba está en el pudín" por así decirlo, y este pudín deja un sabor desagradable. Jules (Mrjulesd) 11:56, 25 de febrero de 2021 (UTC)
- Por lo que vale, WP: DESYSOP2019 cerró con un
- Oponerse : si bien estoy abierto a una idea como esta en principio, hay demasiadas preocupaciones sobre el riesgo de abuso / falta de salvaguardas, y es necesario pensar mucho más en el proceso en sí. Muñeco de nieve gigante 16:39, 21 de febrero de 2021 (UTC)
- Oponerse por Tony:
Oposición
más fuerte posible
Ya tenemos un sistema de desysop comunitario: elegimos miembros de la comunidad de confianza para escuchar la evidencia y luego votar las conclusiones.
Un sistema que proporciona cierta apariencia de imparcialidad al mismo tiempo que hace que los administradores rindan cuentas y, lo que es igualmente importante, deja en claro que las personas que soliciten una audiencia también tendrán su conducta examinada.
Todas las propuestas anteriores han fracasado porque cualquiera que sea justa es efectivamente una propuesta para crear ArbCom con otro nombre.
Además, existe la idea de que es más fácil deshacerse de alguien a través del proceso de la comunidad que a través de ArbCom. No estoy de acuerdo completamente. Un administrador popular que se porta mal repetidamente nunca será abandonado por la comunidad. Lo harían por ArbCom. A pesar de todas sus fallas, el proceso de ArbCom al menos intenta brindar a ambas partes una audiencia justa. Ningún otro proyecto hace eso. TonyBallioni ( charla ) 12:44, 18 de octubre de 2019 (UTC) Ya lo he comentado, pero he estado pensando en esto la mayor parte del día, y cuanto más lo pienso, más me deprimo por lo que esto significaría. probablemente conduzca a nuestra comunidad. Esto se debe a que el problema con un sistema de desysop basado en la comunidad no es que resulte en más desysop. No lo hará. Con toda probabilidad, un proceso basado en la comunidad daría como resultado una cantidad sustancialmente menor de pérdidas ( ver Commons como ejemplo ). El problema es que obtendríamos una herramienta para que la gente acose e intente silenciar a las buenas personas que no tienen ninguna posibilidad de ser desocupadas, pero que trabajan en áreas donde se han ganado suficientes enemigos, probablemente podría iniciar una solicitud válida. Seré franco y diré que probablemente soy uno de esos administradores en los que podría encontrar suficientes personas para realizar cualquier proceso de certificación, pero donde es poco probable que se produzca la eliminación de la comunidad, y no es algo que me guste particularmente, incluso si Estoy seguro de que conservo la confianza de la comunidad. Si no sintiera que tenía esa confianza, ya habría renunciado. El problema aquí es que cualquier proceso de desysop comunitario será un espectáculo , donde todos sus defectos serán comentados a través de aspersiones y una minoría enojada podrá hacer que su vida apesta durante una semana. ¿Quién diablos querría someterse a eso? La gente se está enfocando demasiado en el objetivo del proceso final aquí: sí, es probable que la comunidad pueda evitar que los buenos administradores reciban solicitudes de venganza, pero ese no es el problema. El problema es el ser humano al otro lado de la pantalla que tendrá que pasar por una semana de humillaciones, a menudo por parte de personas que probablemente serán excluidas de la comunidad durante el año. Tendrán sus peores momentos destacados en lugar de su norma, y la comunidad no lo detendrá, porque damos una latitud excepcionalmente amplia a las personas en foros como RfA / RfB / CUOS / ACE, y es muy probable que demos la misma latitud aquí. El resultado final es la intimidación de otros seres humanos, tolerada en nombre de la responsabilidad, dirigida a los sysops que no tienen ninguna posibilidad de ser realmente desobedientes. Deberíamos ser mejores que eso, y aunque ArbCom puede tener fallas, es mejor que cualquier otro proceso que se describe a continuación para tratar de dar una sacudida justa a todas las partes. Eso es en lo que deberíamos centrarnos. TonyBallioni ( charla ) 22:49, 18 de octubre de 2019 (UTC)
- wbm1058 ( charla ) 17:23, 21 de febrero de 2021 (UTC)- Sí, me preguntaba cuándo la gente mencionaría eso. Para ser claros, mis puntos de vista han cambiado en el sentido de que lo que me importa son los resultados justos para todos los involucrados, tanto las personas que se quejan como las que están bajo escrutinio. En los 16 meses transcurridos desde la última discusión, muchas cosas han cambiado en el proyecto, y creo que la implementación de una forma de desysop comunitario con las comprobaciones adecuadas facilitará en última instancia la eliminación de administradores que se comportan de manera problemática y, al mismo tiempo, hará una defensa de sus propias acciones también más fáciles. En otras palabras, creo que veríamos más desysops que tienen un consenso de la comunidad que no ocurriría ahora, y que los casos más controvertidos obtendrían una audiencia más directa. En última instancia, creo que eso conducirá a resultados más justos para las personas involucradas y mejores resultados para la comunidad. No pensé esto hace 16 meses, pero mi forma de pensar obviamente ha cambiado. TonyBallioni ( charla ) 17:41, 21 de febrero de 2021 (UTC)
- Explique los dos cambios más importantes de los últimos 16 meses que le han hecho perder la confianza en el manejo que hace ArbCom de los desysops y por qué le han hecho cambiar de opinión. wbm1058 ( conversación ) 18:17, 21 de febrero de 2021 (UTC)
- Con mucho gusto: primero he pensado más en cómo sucede esto en otros proyectos y cómo parece funcionar perfectamente bien en proyectos grandes. Uno de los principales problemas que me preocupaban en en.wiki son las disputas AE / nacionalistas, pero creo que los requisitos que rodean la certificación allí abordan mi preocupación anterior de que podría tener un lado de un conflicto dirigido a un administrador. La otra es que creo que en realidad no sabemos si la comunidad considera un comportamiento digno de desobedecer más allá de los trazos generales de la política. Creo que en los últimos 2 años, han surgido muchas preocupaciones en torno a las acciones inapropiadas de los administradores que no están familiarizados con la práctica actual y que luego desaparecen o continúan comportándose fuera de las normas en pequeñas formas. Creo que es muy probable que exista un consenso de la comunidad para eliminarlos, pero que tendrías muchas dificultades para lograr que ArbCom abra un caso. En el otro extremo, hubo casos como Portals en los que la votación desysop estuvo cerrada, al menos un árbitro que dijo que podrían haber sido demasiado duros, pero donde había preocupaciones de conducta. La justificación que generalmente se da en casos como ese es que pueden demostrar la confianza de la comunidad a través de un RfA, pero no conozco a nadie que lo haya hecho, y parte de eso se debe a lo difícil que puede ser la marca desysop, incluso si es posible que no lo haya hecho. tenía consenso de la comunidad en ese momento. Crear un proceso en el que podamos ver directamente si la comunidad apoya la desobediencia en casos extremos que rodean la conducta administrativa, en mi opinión, es probable que sea un proceso que probablemente refleje la opinión de la comunidad sobre un caso específico que el actual "desysop y vea si puede pasar RFA ". Como dije, creo que probablemente generará resultados más justos tanto para las personas que piensan que alguien debería ser desocupado como para los que están en discusión. TonyBallioni ( charla ) 18:37, 21 de febrero de 2021 (UTC)
- Como señalé en mi comentario de apoyo, volví a leer los comentarios en contra de la propuesta de hace once años, y si vamos a tomar nota de los comentarios anteriores de los editores, no puedo dejar de notar que algunos de los que se oponen que han aparecido aquí utilizan un lenguaje notablemente coherente ahora como entonces. Bueno, supongo que hay algo que decir sobre coherencia. Sólo digo'. - Tryptofish ( charla ) 22:46, 21 de febrero de 2021 (UTC)
- Comparo un desysop comunitario con la destitución de un representante estatal del Congreso de los EE. UU. Por comportamiento poco ético a través de elecciones generales frente a la destitución por parte del Comité de Normas de Conducta Oficial; al menos, existen algunos paralelismos muy estrechos. Atsme 💬 📧 11:32, 24 de febrero de 2021 (UTC)
- Como señalé en mi comentario de apoyo, volví a leer los comentarios en contra de la propuesta de hace once años, y si vamos a tomar nota de los comentarios anteriores de los editores, no puedo dejar de notar que algunos de los que se oponen que han aparecido aquí utilizan un lenguaje notablemente coherente ahora como entonces. Bueno, supongo que hay algo que decir sobre coherencia. Sólo digo'. - Tryptofish ( charla ) 22:46, 21 de febrero de 2021 (UTC)
- Con mucho gusto: primero he pensado más en cómo sucede esto en otros proyectos y cómo parece funcionar perfectamente bien en proyectos grandes. Uno de los principales problemas que me preocupaban en en.wiki son las disputas AE / nacionalistas, pero creo que los requisitos que rodean la certificación allí abordan mi preocupación anterior de que podría tener un lado de un conflicto dirigido a un administrador. La otra es que creo que en realidad no sabemos si la comunidad considera un comportamiento digno de desobedecer más allá de los trazos generales de la política. Creo que en los últimos 2 años, han surgido muchas preocupaciones en torno a las acciones inapropiadas de los administradores que no están familiarizados con la práctica actual y que luego desaparecen o continúan comportándose fuera de las normas en pequeñas formas. Creo que es muy probable que exista un consenso de la comunidad para eliminarlos, pero que tendrías muchas dificultades para lograr que ArbCom abra un caso. En el otro extremo, hubo casos como Portals en los que la votación desysop estuvo cerrada, al menos un árbitro que dijo que podrían haber sido demasiado duros, pero donde había preocupaciones de conducta. La justificación que generalmente se da en casos como ese es que pueden demostrar la confianza de la comunidad a través de un RfA, pero no conozco a nadie que lo haya hecho, y parte de eso se debe a lo difícil que puede ser la marca desysop, incluso si es posible que no lo haya hecho. tenía consenso de la comunidad en ese momento. Crear un proceso en el que podamos ver directamente si la comunidad apoya la desobediencia en casos extremos que rodean la conducta administrativa, en mi opinión, es probable que sea un proceso que probablemente refleje la opinión de la comunidad sobre un caso específico que el actual "desysop y vea si puede pasar RFA ". Como dije, creo que probablemente generará resultados más justos tanto para las personas que piensan que alguien debería ser desocupado como para los que están en discusión. TonyBallioni ( charla ) 18:37, 21 de febrero de 2021 (UTC)
- Explique los dos cambios más importantes de los últimos 16 meses que le han hecho perder la confianza en el manejo que hace ArbCom de los desysops y por qué le han hecho cambiar de opinión. wbm1058 ( conversación ) 18:17, 21 de febrero de 2021 (UTC)
- Commons es mi 'otro' proyecto y he estado involucrado en varias de las discusiones de desysop allí: es un proyecto completamente diferente con patrones de comportamiento muy diferentes y problemas muy diferentes que dan como resultado las discusiones de desysop. Realmente tiende a ser un mal uso directo de herramientas en Commons, pero como hay menos oportunidades para el mal uso de herramientas y la gran mayoría de administradores están tirando en la misma dirección (principalmente manejando problemas de propiedad intelectual) las fuertes disputas de edición que caracterizan muchos casos de arbitraje en.wp simplemente no aparezcan en Commons con la misma regularidad o intensidad.
También me preocuparía que un administrador popular que se porta mal repetidamente nunca sea abandonado por la comunidad. Lo harían por ArbCom. es correcto, pero minimiza esa popularidad: es igualmente probable que sean elegidos para ArbCom ... Nick ( hablar ) 09:35, 22 de febrero de 2021 (UTC) - También creo que vale la pena señalar que WP: DESYSOP2019 cerró con un
amplio soporte para un procedimiento alternativo de desobediencia basado en la opinión de la comunidad
. Incluso si Tony no hubiera cambiado de opinión, valdría la pena sugerir una política, ya que el consenso es tener una. Oponerse a esta propuesta con el argumento de que no deberíamos tener una es oponerse a ese consenso comunitario previo. ~ Amory ( u • t • c ) 13:52, 22 de febrero de 2021 (UTC) - TonyBallioni , Algo sigue desconcertando aquí. Espero no estar malinterpretando su punto de vista (y, por favor, corríjanme si lo estoy), pero lo leí como "He cambiado de opinión porque ArbCom se ha vuelto demasiado activista, en relación con las acciones contra varias personas que pensé que no se lo merecían ". Supongamos por el momento que eso es correcto y, en respuesta, promulgamos un des-sysop comunitario. Eso no cambia lo que puede hacer ArbCom. Si quieren seguir siendo activistas, pueden hacerlo. ¿Cómo arregla eso esta propuesta? - RoySmith
(charla) 16:15, 23 de febrero de 2021 (UTC)
- @ TonyBallioni : No estoy seguro de haber visto mi pregunta arriba. - RoySmith (charla) 14:51, 3 de marzo de 2021 (UTC)
- Sí, me preguntaba cuándo la gente mencionaría eso. Para ser claros, mis puntos de vista han cambiado en el sentido de que lo que me importa son los resultados justos para todos los involucrados, tanto las personas que se quejan como las que están bajo escrutinio. En los 16 meses transcurridos desde la última discusión, muchas cosas han cambiado en el proyecto, y creo que la implementación de una forma de desysop comunitario con las comprobaciones adecuadas facilitará en última instancia la eliminación de administradores que se comportan de manera problemática y, al mismo tiempo, hará una defensa de sus propias acciones también más fáciles. En otras palabras, creo que veríamos más desysops que tienen un consenso de la comunidad que no ocurriría ahora, y que los casos más controvertidos obtendrían una audiencia más directa. En última instancia, creo que eso conducirá a resultados más justos para las personas involucradas y mejores resultados para la comunidad. No pensé esto hace 16 meses, pero mi forma de pensar obviamente ha cambiado. TonyBallioni ( charla ) 17:41, 21 de febrero de 2021 (UTC)
- Oponerse sin prejustice a cualquier futuro y mejor versión. La idea puede ser genial, pero es difícil imaginar que un procedimiento tan complejo funcione alguna vez. Mis mejores deseos ( charla ) 03:56, 22 de febrero de 2021 (UTC)
- Aterrizo aquí, según la respuesta de Nick al Caldero Chorreante y los efectos emergentes en AN y ANI, que están bastante rotos o deformados como ya están. Además, WP: TINC , pero no pasa mucho tiempo para ver que algunos editores (administradores o no) se vuelven amistosos con otros editores y luego parecen hacer cierres en esos lugares, lo que impide que la comunidad, según esta propuesta, utilice el proceso. en cuestión (no, no solo de GAMEmanship). No hay suficientes protecciones contra los problemas de hundimiento de las camarillas que se plantean en nuestras juntas de revisión de comportamiento. - Izno ( charla ) 03:58, 22 de febrero de 2021 (UTC)
- Oponerse . Si bien tengo buenas intenciones, comparto la preocupación de Sandstein con respecto al efecto escalofriante que esto puede tener en las acciones administrativas correctas pero impopulares (como bloquear los "imbloqueables"). Sjakkalle (¡Compruebe!) 10:48, 22 de febrero de 2021 (UTC)
- Oponerse En primer lugar, como señala Sandstein, esta es una solución en busca de un problema; ArbCom está dispuesto a desysop en casos controvertidos, y nadie ha señalado un caso de ArbCom (o falta de caso) que terminó con un resultado atrozmente malo. En segundo lugar, no hay forma de que la comunidad rechace la apertura de un anti-RfA vejatorio si se cumplen técnicamente los requisitos (bueno, hay IAR pero no veo ninguna caja que quiera invocar eso aquí en ninguna circunstancia). Y finalmente, el umbral para la remoción es más bajo que para la promoción, y no hay orientación sobre cuál es el rango discrecional para que los crats discutan el asunto (si es que hay alguno); convirtiendo efectivamente este anti-RfA en un voto desde la perspectiva de la comunidad. Iffy ★ Chat - 12:00, 22 de febrero de 2021 (UTC)
- Oponerme Aprecio el principio, pero creo que esto hará que los administradores sean aún más reacios de lo que ya son a hacer algo contencioso, o cualquier cosa que moleste a un gran grupo de editores. Por ejemplo, el problema de los imbloqueables empeorará mucho, porque intentar bloquear un imbloqueable generalmente resulta en un hilo en algún tablón de anuncios donde los amigos del imbloqueable atacan al administrador de bloqueo. Esto probablemente conduciría ahora a una solicitud de desysop, e incluso si el administrador sobrevive, no será una experiencia agradable. Tampoco creo que debamos descartar administradores por un solo error, a menos que el error sea muy grave, y el umbral de un solo hilo permitirá que esto suceda. Hut 8.5 13:03, 22 de febrero de 2021 (UTC)
- No sería descartar un solo error, permitiría un consenso de que un comportamiento o acción era inapropiado para ser utilizado para obtener una petición que, si es respaldada por varios editores (incluidos los administradores de pares), entonces sería enviado a la comunidad para su revisión. Ahora mismo, tenemos que conseguir un montón de cierres de AN / ANI y luego pedirle a ArbCom que intervenga; la comunidad puede expresarse repetidamente en AN / I y al votar por Arbs, esperando que los dos choquen. Esto simplemente instituiría un proceso mediante el cual la comunidad puede votar por sí misma. Casi por definición, si consideramos que un RpA es la voluntad de la comunidad, entonces cualquier cosa que decida un de-RpA será igualmente la voluntad de la comunidad. Simplemente no tenemos forma de llegar allí. ~ Amory ( u • t • c ) 13:40, 22 de febrero de 2021 (UTC)
- Una elección de retirada no es la única forma de expresar la voluntad de la comunidad. En política, las elecciones revocatorias suelen conducir a costosos desastres. Los funcionarios electos deben poder hacer su trabajo mientras están en el cargo. Su responsabilidad ante los votantes está garantizada por cargos electos que tienen mandatos limitados y porque los funcionarios electos deben presentarse periódicamente a la reelección. Podríamos considerar usar un sistema similar con los administradores. Nsk92 ( conversación ) 14:09, 22 de febrero de 2021 (UTC)
- Agregaré un poco a lo que Amorymeltzer , pero me parece interesante que la gente se oponga por esta razón, ya que lo agregué para ser un aumento de los requisitos actuales para presentar un caso ArbCom: no hay ninguno. Es totalmente posible elaborar una solicitud de caso sin demostrar que existe un acuerdo por parte de la comunidad de que alguien está actuando de manera problemática y convencer a 2-3 arbs de que "esto debe ser analizado pero no tenemos que sancionar", lo que luego se convierte en una bola de nieve. una aceptación. Básicamente, el proceso actual de desysop es completamente arbitrario en cuanto a cuál puede ser una causa para iniciarlo. Si bien puede iniciar una docena de subprocesos ANI y no conseguir que se acepte un caso, puede ir sin que ningún ANI encuentre un problema y hacer que se acepte uno. Esto tenía la intención de crear un estándar para evitar que las personas usen el proceso como una forma de evitar la resolución normal de disputas y crear un estándar sobre cuándo es aplicable, en comparación con el estándar actual de 'saber qué arbs se preocupan por problemas específicos y presentar casos estarán de acuerdo en escuchar. TonyBallioni ( charla ) 13:50, 22 de febrero de 2021 (UTC)
- Creo que la diferencia es que Arbcom tiene dos caras; Si presenta una solicitud de caso frívolo o está jugando a la marihuana, es probable que se meta en problemas. Si haces lo mismo en este de-RfA, ¿qué pasa? Jo-Jo Eumerus ( charla ) 14:58, 22 de febrero de 2021 (UTC)
- No hay un umbral para presentar una solicitud de caso ArbCom, no, pero presentar una solicitud de caso ArbCom por sí solo no es un gran problema. A menos que ArbCom lo acepte, sucederá muy poco. Por otro lado, esta solicitud de desysop sería un gran problema, e incluso si sobreviviera a la mera amenaza de uno, sería un disuasivo significativo por sí mismo. RfA ya tiene una reputación tan mala que muchas personas calificadas se ven disuadidas de pasar por ella, y esto sería mucho peor. Otra diferencia importante es que alcanzar el umbral aquí podría ser poco más que un concurso de impopularidad. Un administrador que ha hecho algo controvertido (por ejemplo, bloquear a alguien popular) puede hacer que algunos editores experimentados les griten en un tablón de anuncios, que es todo lo que realmente necesita para que comience este proceso. Convencer a la mayoría de los árbitros es bastante más difícil. Hut 8.5 18:19, 22 de febrero de 2021 (UTC)
- Creo que la diferencia es que Arbcom tiene dos caras; Si presenta una solicitud de caso frívolo o está jugando a la marihuana, es probable que se meta en problemas. Si haces lo mismo en este de-RfA, ¿qué pasa? Jo-Jo Eumerus ( charla ) 14:58, 22 de febrero de 2021 (UTC)
- No sería descartar un solo error, permitiría un consenso de que un comportamiento o acción era inapropiado para ser utilizado para obtener una petición que, si es respaldada por varios editores (incluidos los administradores de pares), entonces sería enviado a la comunidad para su revisión. Ahora mismo, tenemos que conseguir un montón de cierres de AN / ANI y luego pedirle a ArbCom que intervenga; la comunidad puede expresarse repetidamente en AN / I y al votar por Arbs, esperando que los dos choquen. Esto simplemente instituiría un proceso mediante el cual la comunidad puede votar por sí misma. Casi por definición, si consideramos que un RpA es la voluntad de la comunidad, entonces cualquier cosa que decida un de-RpA será igualmente la voluntad de la comunidad. Simplemente no tenemos forma de llegar allí. ~ Amory ( u • t • c ) 13:40, 22 de febrero de 2021 (UTC)
- Los detalles siempre se pueden modificar, pero si vamos a hacer esto, debemos hacerlo al menos en términos generales al principio o solo afianzará aún más la dificultad de deshacerse. Desafortunadamente, creo que esta propuesta combina los peores aspectos de AN / I sin mantener ninguno de los puntos fuertes de los casos de arbitraje. Seamos honestos, AN / I es un ejercicio disfuncional en el gobierno de la mafia. Arraigar el proceso de desysop allí le dará el control a las voces más fuertes de nuestra comunidad, no a la comunidad en su conjunto. La ventana de oportunidad inicial de 48 horas acentúa esto al alentar a las personas a apresurarse a juzgar. Probablemente funcione bien para esos casos raros en los que un solo incidente es lo suficientemente atroz como para justificar un desysop, pero esos son también los casos en los que ArbCom ya es bueno para tratar. Los casos con los que luchamos, y los casos en los que el formato de arbitraje puede ser bueno, cuando el comité supera su letargo constitucional, son aquellos en los que se repite una mala conducta de bajo nivel durante un período de tiempo más largo. AN / I habitualmente no hace nada al respecto porque se centra en incidentes individuales recientes, decidir qué parte tiene la mayor culpa y llegar a un "cierre" rápido. El arbitraje es mejor porque permite suficiente tiempo y espacio para discutir cuestiones más complejas, y el formato de decisión fomenta un vínculo explícito entre las conclusiones de los hechos y las soluciones en lugar de tomar partido. Lo que me gustaría ver es un procedimiento comunitario que reproduzca esto, tal vez enumerando casos específicos de mala conducta que, si se demuestran razonablemente con diffs, pueden ser una base para una solicitud de desysop, pero es más simplificado y más fácil de acceder que ArbCom. Y no tiene nada que ver con AN / I. - Joe ( charla ) 16:33, 22 de febrero de 2021 (UTC)
- Mudarse aquí, originalmente por las razones de mi posición neutral-inclinada-opuesta, pero simplemente inflada hasta el punto de lo inevitable. Estoy particularmente preocupado por los problemas que se plantean aquí con respecto a lo difícil que será tomar decisiones difíciles o polémicas, considerando lo obstinada que puede llegar la gente al respecto. En última instancia, esta propuesta parece demasiado fácil de convertir en arma. Vaticidalprophet ( charla ) 18:23, 22 de febrero de 2021 (UTC)
- Oponerse Este es un intento bien intencionado de mejorar el proceso de desysop, pero creo que nuestro actual sistema 'bicameral' proporciona un mejor resultado en general, por imperfecto que sea. Hay una razón por la que los sistemas de gobierno funcionan mejor y duran mucho más cuando hay una especie de cámara superior, que se encuentra por encima de la refriega, que generalmente se mueve más lento y con más cuidado que una unicameral que está abierta a cambios repentinos y dañinos por medio de la rodilla. -Reacciones bruscas de los partidarios involucrados, que también pueden ser demasiado tímidos para tomar decisiones controvertidas pero necesarias que alteran su posición dentro del órgano de gobierno y la población (la "comunidad", en nuestro caso). Desocuparse puede ser el más difícil de todos los deberes en esta comunidad. Creo que fue correcto poner ese poder en manos de un comité electo no involucrado, y eso debería continuar. Mi principal preocupación por cualquier cambio en este procedimiento sería tratar eficazmente con WP: UNBLOCKABLES , y Sandstein me convenció de que esta propuesta empeorará las cosas. RandomGnome ( charla ) 18:31, 22 de febrero de 2021 (UTC)
- Oponerse Muchos de los votantes opuestos expresaron sentimientos similares a los míos. Siempre he sentido que la necesidad de sacar a ArbCom del circuito se deriva más de la frustración de los líderes de la mafia linchadora que de cualquier "dificultad" genuina que tuviera el método existente. Lo que no se me había ocurrido era la idea de que facilitar la eliminación de los administradores conduciría inevitablemente a que los administradores se negaran a realizar llamadas controvertidas, algo que parece un resultado muy probable. Ravenswing 20:20, 22 de febrero de 2021 (UTC)
- Oponerse por
34 motivos: 1) Ser administrador ya es bastante difícil, sin necesidad de evitar decisiones controvertidas. Ya vemos la mentalidad de linchamiento en RFA para candidatos con antecedentes menos que perfectos, y puedo ver que esto les sucede a los administradores que trabajan en las áreas más oscuras de Wiki. 2) Si bien el proceso de Arbcom puede ser difícil, no estoy de acuerdo con la premisa de que lo es innecesariamente. 3) No veo evidencia de que haya algún problema con el sistema actual. - O Still Small Voice of Clam 21:38, 22 de febrero de 2021 (UTC)- Añadiendo una cuarta razón: en la actualidad, los candidatos en RFA pueden elegir el momento de su nominación, una semana en la que es probable que estén disponibles para responder preguntas y puedan lidiar con cualquier estrés que se produzca. Con un procedimiento de des-sysop, el candidato no tendría nada que decir en esto, aparte de una ventana de 14 días. Incluso pueden estar de vacaciones o en una wikibreak durante este tiempo. De hecho, algunos usuarios pueden incluso jugar con el sistema para forzar el problema si saben que es poco probable que el candidato pueda responder bien. Esto conduciría a que el candidato a desysop no pudiera defenderse adecuadamente. - O Still Small Voice of Clam 11:15, 25 de febrero de 2021 (UTC)
- (Inicialmente publiqué esto en "Neutral", pero después de leerlo, creo que podría encajar mejor en "Oponerse". Mz7 ( hablar ) 21:55, 22 de febrero de 2021 (UTC)) Primero, lo bueno: creo que esto es una propuesta muy bien pensada y es probablemente la mejor propuesta de desysop basada en la comunidad que he visto. Aborda muchas de las preocupaciones más críticas que anteriormente han causado el fracaso de las ideas desysop basadas en la comunidad. Hay una barra relativamente alta para comenzar una revisión (requiere un hilo AN / ANI inicial, 10 usuarios establecidos deben respaldar dentro de las 48 horas, 3 de los cuales deben ser administradores, y se requiere un voto de mayoría (60%) para desysop) - Estas salvaguardas pueden prevenir adecuadamente solicitudes frívolas así como "efectos escalofriantes" cuando los administradores dudan en tomar la decisión correcta en una disputa controvertida por temor a represalias. Dicho esto, en WP: DESYSOP2019 , expresé bastante escepticismo sobre si realmente necesitamos un proceso de desysop basado en la comunidad, especialmente uno que resulte en una especie de "anti-RfA". No es ningún secreto que muchos de nosotros pensamos que el proceso de RpA está "roto" porque a menudo hace demasiado hincapié en incidentes aislados y dramas recientes, no requiere corroboración de alegaciones o afirmaciones, y requiere que los candidatos se sometan a un examen intenso y a menudo desagradable de cada rincón y grieta de su especial: Contribuciones . Y aunque no me queda claro cómo se pueden solucionar estos problemas, sigo siendo escéptico sobre cualquier propuesta que reutilice el formato no estructurado de RfA en una solicitud de abandono. Como escribí en 2019,
siento que cada vez que pienso en reformar el proceso de desysop, mis pensamientos siempre vuelven a la pregunta: "¿Qué pasaría si hiciéramos un proceso que permita a un grupo de usuarios confiables, que son examinados regularmente para su juicio? y experiencia en saber qué es bueno para el proyecto, ¿será el organismo principal a cargo de revisar la conducta del administrador? "
Ese es el proceso que ya tenemos.
Como no estoy convencido de que el sistema actual necesite ser reparado, me encuentro en esta sección. Mz7 ( conversación ) 20:55, 22 de febrero de 2021 (UTC) - Oponerse . Esto tiene buenas intenciones y se ofrece de buena fe, pero (1) no hay evidencia de que ArbCom y otros procesos no estén funcionando para frenar los abusos (es decir, esta es una solución en busca de un problema); (2) existe demasiado riesgo de destreza en el juego; y (3) me temo que esto disuadirá a los administradores de tomar la decisión correcta. Charla de neutralidad 22:32, 22 de febrero de 2021 (UTC)
- Inclinarse oponerse , con pesar. - Me gustaría apoyar un proceso como este, pero tengo serias preocupaciones sobre las partes 1 y 2. El hecho de que esto coloque la redacción de un cierre de AN (I) como parte del requisito haría que el cierre de AN (I) fuera incluso más tóxico y político de lo que ya es. Tampoco me agrada el requisito de que tres administradores respalden la petición. Puedo ver por qué algo así está ahí para evitar pruebas frívolas iniciadas por calcetines enojados, pero el requisito explícito de tres administradores parecerá amiguismo desde afuera y comenzará a hacer las cosas inherentemente políticas. Creo que se debería hacer algo aquí, pero este proceso tiene demasiadas minas terrestres wikipolíticas para que pueda apoyar una con esta redacción. Charla sobre la granja de cerdos 23:42, 22 de febrero de 2021 (UTC)
- Oponerse a la propuesta es muy complicado y creo que es más sencillo simplemente tener un "RpA inverso". Banedon ( charla ) 00:29, 23 de febrero de 2021 (UTC)
- Oponerse Lo siento, me encantaría apoyar, ya que creo que una Política Desysop genuina está muy atrasada, pero no es así. Me preocupa que si esto despega, será para Desysop durante los próximos cinco años. Además, dudo seriamente que cualquier administrador cerraría un informe de ANI a favor de un denunciante cuando la queja es sobre un administrador. No estoy tan familiarizado con ANI, pero nunca había visto una acción así en mis más de 14 años aquí. ¿Ha habido uno? Yo diría que la mayoría de los habituales preferirían dejar que una queja de esta naturaleza se abriera paso en el territorio del archivo antes que ser "cerrada", per se. Así que el resto de la propuesta es discutible, en mi opinión. Estoy de acuerdo con Banedon arriba: un proceso de "RfA inverso" más simple, es decir, "te equivocaste a lo grande, así que votemos", sería preferible a este proceso de Wikilayering. Homeostasis07 ( charla / contribuciones ) 00:52, 23 de febrero de 2021 (UTC)
- Opónganse por Sandstein, Neutrality y otros. Aunque bien intencionado, me temo que este proceso abriría las puertas al abuso y a un drama innecesario .-- Darwinek ( charla ) 01:35, 23 de febrero de 2021 (UTC)
- Oponerse 1. El umbral de edición es demasiado bajo. 2. ¿Por qué necesita 3 administradores para que también lo aprueben? Los administradores son solo usuarios que tienen herramientas especiales cuando surge la necesidad, pero esto es una discusión, por lo que deberían ser los usuarios quienes decidan, no necesariamente el administrador. Sir Joseph (charla) 02:06, 23 de febrero de 2021 (UTC)
- Oponerse : el proceso es demasiado arcano y abre las puertas al abuso según Darwinek. - Rockstone [¡Envíame un mensaje!] 02:29, 23 de febrero de 2021 (UTC)
- Oponerse . Requiere reelaboración sustancial.
Esto es demasiada burocracia dramática. Parece una prueba objetiva, pero devuelve la subjetividad en el tiempo a un desafortunado cierre de hilo que puede o no entender la implicación de su cierre de hilo.1. "La solicitud debe vincularse a al menos un hilo en un foro de la comunidad como AN o ANI que se cerró en los últimos 6 meses donde la declaración de cierre indica que hubo consenso de que el administrador se comportó de manera inapropiada".
Sugerir:
Esto deja en manos del proceso en curso discutir y acordar si se trataba de una acusación no refutada de mala conducta grave del administrador."La solicitud debe vincularse a al menos un hilo en un foro de la comunidad, como AN o ANI, donde no se refutó una acusación seria de comportamiento del administrador".
Elimine "cerrado" porque no todas las discusiones serias están formalmente "cerradas". Eliminar "dentro de los últimos 6 meses" porque esto crea una fecha límite artificial. Sugiera "en los últimos meses" si se considera que el tiempo es importante; sin embargo, sugiero que sea mejor incluir una cláusula de "problemas en curso".
Oponerse a estas reglas de quórum de 10 usuarios confirmados extendidos y tres administradores actuales. En su lugar, imponga un estándar particular de publicidad. Sugiero: la página de discusión del administrador del tema; WP: AN; WP: BN.2. "La solicitud estará abierta para respaldos. Si 10 usuarios confirmados extendidos que cumplen con los requisitos de presentación anteriores, incluidos al menos tres administradores actuales, respaldan la solicitud dentro de las 48 horas, la solicitud será revisada por un burócrata y, si cumple los requisitos, certificados como una solicitud activa para desysop. Si los endosos requeridos no ocurren dentro de las 48 horas, la solicitud se archivará como no exitosa ".
Oponerse a este futuro definitivo "será revisado". No se debe obligar a los burócratas a actuar conforme a este procedimiento. En cambio, déle a un burócrata el papel de un juicio subjetivo sobre si "se ha acordado que haya un caso para desysop". NÓTESE BIEN. Los burócratas saben cómo decir un consenso, este RfC no debería definir eso.
"Si los respaldos requeridos no ocurren dentro de las 48 horas" Opónganse las 48 horas como tiempo de estilo dramático. En cambio, 8 días. Este es un asunto serio, no algo que deba apresurarse durante un fin de semana.
Oponerse a. Esperaba que el n. ° 3 fuera la verdadera discusión, no un proceso de sello de goma de amplificar el hilo de ANI duro de casi seis meses sobre un administrador que muerde a alguien.3. "Una vez certificado, el administrador en discusión debe incluir la solicitud de desysop en Wikipedia: Solicitudes de administración dentro de los 14 días o renunciar como administrador. Si ninguna de las dos ocurre dentro de los 14 días posteriores a la certificación, un burócrata excluirá la discusión".
En su lugar: 3. Inicie una RfA de reconfirmación. Otra semana, sí, excepto que no exija una semana, deje que los burócratas encuentren un consenso para la reconfirmación, o no. Si no es así, des-sysopted. - SmokeyJoe ( charla ) 04:46, 23 de febrero de 2021 (UTC) - Oponerse . Por Dirk Beetstra, Useight, Alanscottwalker, Nick, Sandstein, Hut 8.5, Joe y otros. (1) Creo que el enraizamiento de esto en ANI tendría todo tipo de efectos negativos no deseados en la práctica; (2) Creo que es fácil para un administrador tomar decisiones correctas pero impopulares que, con el tiempo, conducen a la acumulación de una masa suficiente de editores descontentos; y (3) Creo que el umbral de edición debe aumentarse, probablemente en gran medida. Básicamente, estoy contento con la apelación actual al Comité de Arbitraje, que últimamente ha demostrado estar más listo para eliminar los privilegios de administrador, y también apoyaría el uso de los burócratas como un jurado neutral. Adicto a Espresso ( charla ) 05:07, 23 de febrero de 2021 (UTC) ETA: Veo muchos comentarios en el sentido de que los administradores deberían ser responsables ante la comunidad, no ante ArbCom, y ArbCom no representa a la comunidad, pero los miembros de ArbCom son elegidos por la comunidad para este propósito (entre otros). Más de 1700 editores votaron en la última elección de ArbCom, muchos más de los que probablemente participarán aquí, y todos los candidatos electos obtuvieron al menos dos tercios de apoyo neto. Espresso Addict ( charla ) 01:14, 28 de febrero de 2021 (UTC)
- oponerse . Parece una buena idea en principio, pero me preocupa que el requisito de que el cierre del hilo de ANI tenga consecuencias no deseadas, como otros han señalado anteriormente, parece que esto podría llevar a que las discusiones de ANI se conviertan en riesgos mucho más importantes que en la actualidad. C apital S asha ~ t alk 06:04, 23 de febrero de 2021 (UTC)
- Oponerse a otros que han notado que esta es una solución sin problemas. Tenemos procesos para des-sysoping, y no he visto ningún tipo de patrón en desarrollo que indique que no están funcionando. "Comportamiento inapropiado" no está definido y podría significar cualquier cosa. Aquí hay muchas posibles consecuencias no deseadas. - Comentario anterior sin firmar agregado por Peacemaker67 ( charla • contribuciones ) 9:40, 23 de febrero de 2021 (UTC)
- Oponerse : apoyo una ruta basada en la comunidad para eliminar administradores de sistemas, pero el proceso propuesto es más restrictivo y complicado que simplemente ir a ArbCom. Mr rnddude ( charla ) 10:34, 23 de febrero de 2021 (UTC)
- Oponerse , lamentablemente. Aprecio el pensamiento y el esfuerzo que se ha invertido en esto, pero esto se jugará con demasiada facilidad y hará que ANI sea aún más un circo abusivo de lo que ya es. La razón por la que los administradores abusivos se convierten en administradores abusivos es porque otros administradores abusivos los protegen y los cubren en ANI, por lo que mi preocupación es que esto solo hará que se apresuren a cerrar los hilos de ANI para que no se puedan cumplir las condiciones necesarias. Muchos opositores dicen que las barreras son demasiado bajas; mi preocupación es que las barreras aquí son demasiado altas. Hasta ahora, a los arbs les está yendo bien en el abandono, y aunque me gustaría que la comunidad pudiera hacerlo nosotros mismos, esto podría debilitar nuestras posibilidades de lidiar con administradores problemáticos mientras aumenta la tensión en ANI. Sandy Georgia ( Discusión ) 11:26, 23 de febrero de 2021 (UTC)
- Oponerse : este procedimiento lo convierte en un concurso de popularidad similar al que dio origen a ArbCom. Soy de la opinión de que agrega un paso adicional innecesario para deshacerse del proyecto de administradores abusivos que acosan a los editores, flexionan sus músculos administrativos contra sus oponentes y empujan su propia agenda / POV. Es una situación difícil porque está en la naturaleza humana que las personas compatibles formen alianzas. Lo que un editor puede desaprobar como abusivo, otro lo está animando. Los editores que hemos elegido para formar parte de ArbCom, por una razón u otra, se han elevado por encima de la refriega y se han ganado nuestra confianza; repetidamente han demostrado buen juicio. ArbCom también puede ver las cosas de forma privada para proteger a los abusados, mientras que la información privada no se enviaría a la comunidad en general. Atsme 💬 📧 13:35, 23 de febrero de 2021 (UTC)
- Oponerse . No creo que haya suficientes salvaguardias contra el acoso de los spammers. El umbral de tres administradores gana tiempo, pero no creo que esto sea sostenible a largo plazo. Esta propuesta tiene el efecto secundario de reducir los umbrales en RFA y, por lo tanto, hace que sea más probable que uno de esos spammers de tipo patrulla que se escabullen por las grietas gane la administración. Por contexto, he bloqueado cuatro cuentas confirmadas extendidas para UPE en los últimos tres días. Es necesario que se demuestren varios casos de mala conducta administrativa. MER-C 13:43, 23 de febrero de 2021 (UTC)
- Fuerte oposición La propuesta va completamente en contra de nuestra política WP: CONSENSUS , y se enfoca más en números absolutos. ¿Qué pasa si 10 usuarios extendidos respaldan y 90 rechazan la propuesta? ¿Por qué un administrador debe dejarse abierto a someterse a este linchamiento público y apelar por una solicitud de revisión de desysop solo porque diez personas tenían una queja común en su contra, cuando la mayoría no podría hacerlo? Política estructuralmente fuera de lugar, mal construida y mal dirigida. Lourdes 14:03, 23 de febrero de 2021 (UTC)
- Oponerse . Los administradores casi inevitablemente deben antagonizar a algunos usuarios mientras se ocupan de sus negocios, y es probable que esos usuarios aparezcan en tales retiros de administradores para descarrilarlos. También corre el riesgo de convertir la administración en un concurso de popularidad, en los casos en que el administrador haya tomado medidas contra uno o más usuarios con un apoyo sustancial de la comunidad. No queremos que los administradores comiencen a comportarse como políticos, atendiendo a electores influyentes en lugar de hacer su trabajo sin miedo ni favoritismos. Esto también me parece que está abriendo la puerta al acoso de los administradores, particularmente porque no hay nada en la propuesta que evite las frecuentes solicitudes de desysop de los mismos partidos o grupos. ¿No es ya bastante difícil encontrar personas dispuestas a presentarse a la administración? Además, no existe ningún mecanismo en este proceso para una presentación ordenada de la evidencia, o incluso ninguna evidencia en absoluto, como lo hay en Arbcom, lo cual es inquietante. Finalmente, como otros han señalado, esta es una solución en busca de un problema, ya que ya existe un medio de fácil acceso para deshacerse de los administradores descarriados. Gatoclass ( charla ) 14:54, 23 de febrero de 2021 (UTC)
- Oponerse . Según Useight, WereSpielChequers, Sandstein y Joe Roe. Si bien recientemente estuve a favor de tales desysops basados en la comunidad (los administradores " derivan sus poderes justos del consentimiento " de la comunidad según Locke y Jefferson ), leyendo los argumentos en WP: DESYSOP2019 y aquí, así como casos anteriores del Comité de desysop me ha convencido de que no sería prudente instituir tal cambio. Los casos de comité, los aman o los odian, permiten un mayor matiz en la discusión. El proceso propuesto empeoraría el problema de WP: UNBLOCKABLEs y no tiene salvaguardas contra la doble incriminación. Por favor envíeme un mensaje o publique en mi charla si respondo como (se supone que debo hacerlo) en Wikibreak. Sdrqaz ( charla ) 16:00, 23 de febrero de 2021 (UTC)
- Oponerse ahora, no me malinterpretes. Creo que la comunidad necesita un proceso para eliminar a los administradores que han perdido la confianza de la comunidad. Pero la forma en que está redactada esta propuesta es ... fundamentalmente defectuosa. En realidad, no tengo muchas preocupaciones con el requisito de discusión de ANI, pero se trata del requisito de endosos. Por primera vez, no debería existir el requisito de que tres patrocinadores sean administradores. Sí, el bit de administrador generalmente significa que tienes una buena cantidad de experiencia, pero a menos que algo realmente cambie, los administradores siguen siendo editores, solo con botones extra elegantes. En segundo lugar, Loudres lo dijo bastante bien. Diez personas podrían decir, claro, deshagámonos de ellos. Entonces, podría haber incluso 400 personas entrando y diciendo que no, que no deberían ser desocupados. Esta propuesta permitiría que las voces de 10 sean tratadas como más importantes que las voces de 400. Obviamente, estos son probablemente números de participación poco realistas, pero el punto se mantiene independientemente de los números. Mi punto final es que, si bien esto no es específicamente un error de propuesta, creo que sería mejor si estuvieran en un lugar separado de RFA. Por ejemplo, una nueva página específicamente para solicitudes de desysops y discusiones sobre ellos. EggRoll97 ( charla ) 18:37, 23 de febrero de 2021 (UTC)
- Oponerse a una propuesta contraproducente y oclocrática que parece más abusiva que efectiva. Todas mis reservas han sido expuestas claramente por encuestados anteriores. Más importante aún, esta es una mala solución para un problema inexistente. Neodop ( charla ) 19:52, 23 de febrero de 2021 (UTC)
- Oponerse Movido de "Neutral". Como se menciona allí, este proceso es redundante y la propuesta original o modificada no aborda en ninguna parte la posibilidad de usarlo para ajustar puntajes. No encuentro convincentes los argumentos del "apoyo" en términos de salvaguardias. La propuesta se basa en la idea de que los editores que podrían iniciar o comentar dicho proceso están tomando decisiones individuales en un momento en el que sabemos que tenemos organizaciones importantes, incluidos actores estatales, que están coordinando la propaganda en este proyecto. Esta es una invitación abierta a estos actores para que eliminen la oposición a su abuso del proceso. Eggishorn (charla) (contrib) 20:38, 23 de febrero de 2021 (UTC)
- Me opongo , no creo que 3 esté bien pensado, ya que alguien más dijo que no debería ser un sello de goma, también un proceso como este debería garantizar que se esté haciendo claramente para facilitar el trabajo de ArbCom y no el de los administradores. Los administradores problemáticos deben investigarse absolutamente, pero ese proceso también debe tener capacidad heredada para proteger contra ataques injustificados. No siempre es fácil estar seguro. Creo que, conceptualmente, esto puede ser un buen movimiento, pero no está listo para su implementación. Saludos Scott Thomson ( Faendalimas ) charla 21:34, 23 de febrero de 2021 (UTC)
- Oponerse por Wehwalt, Sandstein, y Hut8.5. Gamaliel ( charla ) 21:43, 23 de febrero de 2021 (UTC)
- Oponerse - (1) No es necesario; para bien o para mal, ArbCom ha dejado en claro que manejará los problemas de WP: ADMINCOND a la primera señal de problemas. (2) Nunca se utilizará; Esto es muy parecido a un retiro de administrador +. A pesar de que muchos administradores están abiertos a la retirada, no ha habido una sola solicitud en casi 9 años (consulte esta lista de retiradas anteriores ). (3) Se puede jugar; Según Beeblebrox, este sistema se puede jugar. Tampoco hay ningún esfuerzo por eliminar los votos engañados de este estricto sistema de votación. (4) Demasiado burocrático ; vea el diagrama de flujo que publiqué a continuación . Eso es mucha burocracia. Por no mencionar; esta descripción muestra que hay al menos un paso que es superfluo. (5) la barra es demasiado baja; pequeños errores pueden convertirse en problemas importantes. Esto no es compatible con la política WP: ADMINCOND . (6) Solución en busca de un problema; He dicho muchas veces en el pasado que es necesario realizar un análisis adecuado antes de encontrar una solución. Esto no se ha hecho. Es solo una solución propuesta sin abordar cómo resuelve ningún problema. Según la ley de las consecuencias no deseadas , debería haber al menos algún tipo de análisis de resolución de problemas antes de que esto se sugiera. Esta política propuesta podría causar tantos problemas como teóricamente puede resolver. Pero no lo sabemos porque no ha habido ningún análisis. (7) el 60% es arbitrario; El umbral debe alinearse con los requisitos de WP: RFA y permitir a los burócratas la oportunidad de evaluar el consenso ... que es lo que se ofrecieron a hacer. Esta estructura no es más que un voto. Eso es contrario a lo que somos, más especialmente en algo tan polémico como sería una solicitud de desadministración. Si quiere que sea un voto estricto, intente hacer de este RfC estrictamente un voto y vea cómo responde la gente. (8) Sin evidencia; Tal proceso podría avanzar sin que se presente ninguna evidencia, aparte del requisito mínimo de un hilo AN previo que concluya en contra del administrador. (9) El hilo AN podría estar mal cerrado; He visto hilos en los tablones de anuncios cerrados por personas que no tenían por qué cerrar discusiones, y mucho menos una polémica como la mala conducta de los administradores. Es muy raro que un editor se quede corto para los problemas de WP: BADNAC . Esto también es una oportunidad para jugar con el sistema. En resumen; Respeto los esfuerzos bien intencionados de TonyBallioni al proponer este sistema. Sin embargo, está plagado de problemas muy serios, como yo y otros hemos destacado. Simplemente hay demasiados problemas aquí para que esto siga adelante. Esto necesita volver a algún tipo de borrador para desarrollarlo más, si es que lo hace. - Hammersoft ( charla ) 22:37, 23 de febrero de 2021 (UTC)
- Oponerse (movido de 'Neutral') según Hammersoft y comentarios de Atsme y DGG . Kudpung กุด ผึ้ง ( charla ) 01:56, 24 de febrero de 2021 (UTC)
- Kudz, creo que puede haber estado en algo relativo a los burócratas; creo que deberían elegir (entre ellos) un Comité de Ética de 9 miembros para escuchar solo los casos administrativos; las quejas administrativas van a ellos, punto, al final. Atsme 💬
📧 11:43, 24 de febrero de 2021 (UTC)
- No necesitamos más comités ni burocracia, por favor. Los burócratas no se eligen para tratar las quejas de los administradores; ArbCom sí lo hace anualmente. ProcrastinationReader ( charla ) 11:56, 24 de febrero de 2021 (UTC)
- Kudz, creo que puede haber estado en algo relativo a los burócratas; creo que deberían elegir (entre ellos) un Comité de Ética de 9 miembros para escuchar solo los casos administrativos; las quejas administrativas van a ellos, punto, al final. Atsme 💬
📧 11:43, 24 de febrero de 2021 (UTC)
- Oponerse : Arbcom es un proceso comunitario existente y, aunque es difícil y largo, también lo es RfA. La comunidad carece de administradores y esto parece ser un atajo innecesario que puede alentar su pérdida por razones posiblemente frívolas o por esfuerzos de escrutinio. - Paleo Neonate - 05:35, 24 de febrero de 2021 (UTC)
- Oponerse : según Hammersoft , esencialmente. - Jack Frost ( charla ) 08:53, 24 de febrero de 2021 (UTC)
- Oponerse a Joe Roe hace algunos puntos sólidos arriba. ArbCom está haciendo un buen trabajo al deshacerse de los administradores problemáticos. Esta propuesta parece un intento de contener el poder de ArbCom. De hecho, como muestra Wbm1058, el propio Tony Balioni solía oponerse firmemente al desysop comunitario. Perdóname por asumir mala fe, pero parece que Tony está más interesado en poner ArbCom en una jaula y no preocupado por administradores abusivos. El requisito del 60% de soporte para desysop es demasiado alto; dicho de otra manera, permite la retención de la administración con solo el 40% del apoyo de la comunidad. Incluso Fram tenía hasta un 47% de apoyo ; si este proceso hubiera existido en ese entonces, ArbCom probablemente habría diferido la pregunta de desysop-or-not a la comunidad y Fram habría seguido siendo un administrador. Los proponentes parecen decir que el proceso de desysop de ArbCom sería independiente de este proceso, pero ¿en serio? Más bien, ArbCom comenzaría a hacerse la pregunta "¿es probable que tenga el 40% del respaldo de la comunidad?" en la decisión de casos de desysop, lo que daría lugar a un menor número de desysop en general; y tendrían toda la razón al hacerlo, porque de lo contrario se crea una asimetría injusta de que un proceso sea más difícil que el otro. En las solicitudes de arbitraje, habrá comentarios como "Rechazar, por favor, la comunidad puede manejar desysops". Sospecho que esto pondría fin a los desysops de ArbCom. - SD0001 ( conversación ) 09:32, 24 de febrero de 2021 (UTC)
- Ese es un muy buen punto de que un proceso de desysop comunitario probablemente signifique el fin de los desysops de Arbcom. Estoy seguro de que los miembros de Arbcom estarán encantados de enviar cualquier solicitud de desysop a la comunidad para que se resuelva una vez que se establezca dicho proceso. Gatoclass ( charla ) 10:42, 24 de febrero de 2021 (UTC)
- Me opongo por muchas razones que explicaré, pero quiero señalar solo comentar aquí porque el RfC apareció como un banner en mi página de usuario. Mi oposición se basa en el hecho de que se supone que la propuesta aborda las siguientes preocupaciones:
- El proceso de ArbCom es innecesariamente difícil
- Los administradores que hacen llamadas impopulares podrían sufrir acoso
- Es posible que los procesos de otros proyectos no funcionen en la Wikipedia en inglés
- La comunidad necesita una forma de abordar la conducta problemática
- 1) Esta propuesta parece ser tan difícil como un proceso de Arbcom para un editor ordinario porque incluso con los requisitos de edición muy bajos de 25 ediciones en los últimos 6 meses, sería casi imposible para un editor obtener una declaración de cierre en AN / Yo en contra de un administrador popular que simplemente dice que "se comportaron de manera inapropiada" sin recibir un boomeran. Para obtener ese tipo de declaración final en AN / I, necesitarían evidencia de comportamiento atroz, en cuyo caso no necesitarían AN / I ya que tendrían suficiente evidencia para ArbCom.
- 2) La idea de que los administradores puedan sufrir acoso es un argumento basado en el miedo que no tiene base en la realidad. Si hubiera hordas de enemigos invisibles esperando para atacar, entonces se habrían acumulado en las discusiones anteriores, como la de 2019, así como esta.
- 3) Si el proceso ha funcionado antes en otros
sistemas[proyectos], entonces hay evidencia de que funciona, pero nada en esta propuesta parece tener nada en común con lo que sabemos que funciona en los otrossistemas[proyectos]. - 4) En cuanto al resto de los requisitos, me resultan demasiado espeluznantes , lo que no resuelve el problema de ser más fácil que ArbCom.
- 5) Nuestro umbral actual para permitir que un editor obtenga el estado de administrador es del 65%. Lo que esto significa lógicamente en términos proporcionalmente inversos es que la comunidad ha determinado consistentemente que cualquier editor que no haya hecho absolutamente nada malo no es apto para tener las herramientas si solo el 35% las considera indignas. Esta propuesta básicamente pide que cualquier administrador que haya sido acusado de irregularidades y cuya confianza en la comunidad haya sido cuestionada, ¿debería tener el privilegio de tener un umbral absurdo del 60% antes de que se lo considere indigno? Huggums537 ( charla ) 09:38, 24 de febrero de 2021 (UTC)
- 6) También agregando que me opongo a la parte, los usuarios que comenten deben cumplir con los requisitos para presentar una solicitud de desysop para apoyar u oponerse ... porque cualquier forma de limitar a la comunidad para poder participar es contradictoria con la idea de lo que la definición misma de un medio desysop comunitario . Eso no es desysop comunitario, es desysop "solo para miembros". Huggums537 ( charla ) 22:50, 26 de febrero de 2021 (UTC)
- Solo con fines explicativos, y en caso de que no lo haya dicho bien, lo que esencialmente dice la propuesta es;
- Si el 35% de la comunidad puede considerar que un editor no es apto para tener herramientas de administración por no hacer nada malo,
- entonces deberíamos incluir en la política que se necesitará el 60% de la comunidad para considerar que un editor no es apto para tener las herramientas de administración cuando se le acusa de irregularidades o la confianza de su comunidad se pone en duda.
- ¿Esto realmente suena razonable para alguien? Huggums537 ( charla ) 10:14, 24 de febrero de 2021 (UTC)
- "Razonable" depende del contexto de su pregunta - ¿razonable en comparación con qué? Esto también recuerda el estudio y la conformidad de Asch . El consenso no se trata / no debería tratarse de números. Es muy posible que haya una situación en la que el 10% de los editores participantes hayan proporcionado pruebas extremadamente sólidas de que otros pueden estar descartando debido a alianzas o popularidad del administrador en cuestión, o igualmente mala conformidad. No queremos que la comunidad o incluso un "comité de ética" diga, bueno , ese es un administrador popular, hay mucho apoyo entre pares, no deberíamos desysop. También se puede decidir que un período de prueba funcionaría para la primera infracción, por lo que hay otras opciones para que un comité las considere. No se debe pensar en ArbCom ni como la Parca. 💀 Atsme 💬
📧 14:17, 24 de febrero de 2021 (UTC)
- El experimento de conformidad de Asch es uno de mis favoritos entre los "clásicos". Gracias por compartir. Huggums537 ( charla ) 15:07, 25 de febrero de 2021 (UTC)
- "Razonable" depende del contexto de su pregunta - ¿razonable en comparación con qué? Esto también recuerda el estudio y la conformidad de Asch . El consenso no se trata / no debería tratarse de números. Es muy posible que haya una situación en la que el 10% de los editores participantes hayan proporcionado pruebas extremadamente sólidas de que otros pueden estar descartando debido a alianzas o popularidad del administrador en cuestión, o igualmente mala conformidad. No queremos que la comunidad o incluso un "comité de ética" diga, bueno , ese es un administrador popular, hay mucho apoyo entre pares, no deberíamos desysop. También se puede decidir que un período de prueba funcionaría para la primera infracción, por lo que hay otras opciones para que un comité las considere. No se debe pensar en ArbCom ni como la Parca. 💀 Atsme 💬
📧 14:17, 24 de febrero de 2021 (UTC)
- Oponerse , principalmente según Huggums537 (moviéndose aquí desde Neutral). Todavía tengo las preocupaciones expresadas en mi comentario neutral anterior, pero después de una reflexión más profunda, encuentro inviable el sistema propuesto, particularmente debido al problema 5) planteado por Huggums537. El requisito del 60% es ridículo. Tenemos un estándar bien establecido para demostrar el apoyo de la comunidad de que un usuario debe tener herramientas de administración: 65% de soporte en RfA. Deberíamos usar el mismo estándar o uno similar para ver si un administrador cuya continua idoneidad para la administración se puso seriamente en duda aún tiene el apoyo de la comunidad para ser un administrador, una vez que un esfuerzo de retiro se haya certificado adecuadamente. Con el requisito del 60%, realmente no podría deshacerse de nadie excepto en los casos más atroces, y para esos casos será mucho más rápido y fácil ir a ArbCom. Será un proceso de desysop comunitario solo de nombre. No se utilizará o se utilizará con el propósito de no despojar a alguien (incluso los administradores más impopulares pueden dominar el 40% del apoyo), sino simplemente hacer la vida de alguien difícil y desagradable. El sistema arruinará ANI aún más de lo que ya es y probablemente desestabilizará el proceso de desysop existente de ArbCom. Esa no es la forma de aumentar la responsabilidad administrativa. Si se intentara algo como esta propuesta, tendría que ser a prueba, digamos durante 1,5 años, con otro RfC requerido después de eso, para determinar si el sistema debe ser desechado, reautorizado o modificado. Nsk92 ( conversación ) 12:52, 24 de febrero de 2021 (UTC)
- Espero que todos lean atentamente la oposición de Dennis Brown (actualmente número 83 en esta columna). Él plantea varios problemas clave con respecto a la idea de un desysop comunitario como tal, y para mí estas objeciones son incluso más importantes que los problemas del 60% -40%. Apoyo cada palabra de lo que dice allí. Nsk92 ( conversación ) 00:46, 28 de febrero de 2021 (UTC)
- Oponerse : No me parece que se haya demostrado que los procesos actuales de ArbCom sean deficientes y necesiten reparación, y la base probatoria de esta propuesta, si se promulga, parece probable que lleve a consecuencias negativas en AN / I, con la posibilidad de escaramuzas prolongadas y desgaste al concluir los casos. AllyD ( charla ) 14:29, 24 de febrero de 2021 (UTC)
- Oponerse : esta es una solución en busca de un problema. Ya tenemos un mecanismo para remover a los administradores por mala conducta: está basado en evidencia, tiene una mejor protección contra la mentalidad de la mafia y sus decisiones se pueden apelar a la comunidad. Esta propuesta solo crea un proceso inferior duplicado y, por lo tanto, debilitaría el que tenemos. - brad v 🍁 15:23, 24 de febrero de 2021 (UTC)
- Oponerse : además de estar de acuerdo con muchos de los argumentos presentados anteriormente (especialmente los de Hammersoft y Mz7), creo fundamentalmente que esto sienta un mal precedente. El proceso es demasiado susceptible a la manipulación por parte de un pequeño grupo de usuarios. Si bien no creo que de-sysops estén sucediendo todo el tiempo con este sistema, creo que la cantidad de intentos de de-sysop se dispararía y desperdiciaría mucho tiempo para todos los involucrados. Podría tener un efecto escalofriante en las acciones de los administradores. Siempre estamos buscando más administradores y más actividad de administrador. Ya tenemos un procedimiento para eliminar administradores incorrectos. Esta propuesta no dará lugar a ninguna mejora en la enciclopedia. Ganesha811 ( charla ) 16:03, 24 de febrero de 2021 (UTC)
- Oponerse : trato de evitar traer o participar en discusiones de ANI, y mucho menos ArbCom. Pero mi lectura de esto es que esto empeora las cosas. La propuesta no identifica un problema discernible. En el mejor de los casos, puedo ver una justificación general de que ArbCom es lento. Pero esta propuesta no es tanto más rápida como tiene menos construcción de consenso y búsqueda de hechos, que son dos principios que considero fundamentales para Wikipedia.
- Creo que nuestros sistemas de rendición de cuentas son defectuosos. Somos buenos en los casos extremos: denunciamos lo atroz y toleramos lo tolerable. Pero he visto a varias personas a las que se les perdona por empujar los límites una y otra vez, hasta que finalmente pisan una mina terrestre política y son bloqueados. Crea meses o incluso años de interrupción antes de que se aborde el problema. Un componente desagradable de eso será el faccionalismo y la mentalidad de WP: BATTLEGROUND en las discusiones de conducción. Para muchos problemas de conducta, verá dos facciones peleando por una solución de todo o nada, un bloqueo instantáneo versus una amnistía completa sobre la base de que la mala conducta fue solo una reacción emocional hacia las personas que quieren que se bloqueen. No puedo decirte lo increíblemente estúpido y frustrante que es verlo, y estoy agradecido de haber evitado estas discusiones. Pero el enfoque de todo o nada deja una hazaña masiva en el medio, donde puedes ser vagamente un idiota siempre que otras personas hayan sido un idiota contigo, generalmente reforzado por tus amigos idiotas más pasivos y agresivos.
- La solución más sencilla sería empezar a ser mucho más liberal con las advertencias. Sí, advierta a un editor por hacer comentarios sarcásticos e improductivos. Advertir a un editor por comentar sobre otros editores en lugar del contenido. Advierta a ambos lados de algunas disputas (aunque las advertencias deben ser específicas, ya que la mala conducta nunca es igual en ambos lados). Lo que esto haría es (a) trazar una línea clara en cada momento en que sucede algo improductivo en lugar de ignorarlo hasta que se vuelve verdaderamente destructivo, (b) usar advertencias cada vez mayores para que los editores reconozcan su comportamiento problemático y los empujen hacia la colaboración editar, (c) dejar de usar bloqueos u otras sanciones como remedio primario, lo que también (d) despojaría de poder a las facciones que esperan "atrapar" o "engañar" a alguien para que se bloquee, y (e) dejar un rastro muy claro de advertencias dondequiera que tenga un patrón de mala conducta impenitente, ya que esos patrones de comportamiento son lo que realmente queremos eliminar.
- Supongo que hay un lugar mejor para mí para plantear esto como una solución, pero veo que esto está totalmente relacionado con el tema. Mucha gente sigue intentando resolver esto facilitando la sanción de las personas, pero creo que debemos facilitar la creación de un rastro de búsqueda de hechos. No solo por una eventual sanción, sino para que el editor en cuestión reflexione sobre su comportamiento y lo desanime mucho antes de que se convierta en un patrón perturbador. Me imagino que funcionaría tan bien en administradores como en cualquier otra persona. Shooterwalker ( charla ) 16:47, 24 de febrero de 2021 (UTC)
- Oponerse . No suelo venir de las trincheras a votar sobre cosas como esta, porque cuando trabajas mucho en el contenido no tienes tiempo para el drama y, de hecho, no estaba al tanto de la discusión hace dos años. Sin embargo, me notificaron por esto, y después de revisar las cosas, no creo que sea prudente. Bien intencionado, estoy de acuerdo, pero no menos inteligente.
Para el caso amplio en su contra, no creo que nadie pueda agregar a los argumentos de Hammersoft , ¡pero hay otro tema al que solo he visto a uno oponerse! Vote aquí, toque: el efecto que esto tendrá en nuestros otros foros para resolver estos problemas. .
No siempre estoy de acuerdo con Sandy , pero ella está totalmente convencida de que esto no funcionará en el sentido de que es poco probable que ponga a los administradores abusivos en el talón y, en consecuencia, en mi opinión, en unos años escucharemos quejas de que esto " RFdS ", o como se llame, está" roto "por personas que no podrán darse cuenta de que nació de esa manera ya que no formaron parte de esta discusión y no querrán profundizar en él para ver! votos como estos que predijeron esos mismos problemas. Y dado que serían el tipo de personas poco inclinadas a considerar que ArbCom podría estar funcionando, al menos mejor de lo que piensan, es más probable que caigan más desanimados, editen menos y luego se vayan silenciosamente .
En cuanto al resto de nosotros ... bueno, estoy de acuerdo con Sandy en que la probabilidad de cierres rápidos de AN / I podría aumentar, eso es algo que ciertamente podría suceder, pero no será el único efecto que este procedimiento tendría sobre allí. Francamente, veo que este procedimiento conduce a más subprocesos AN y AN / I de los que tenemos actualmente sobre esto, lo que, por supuesto, conducirá inevitablemente a más solicitudes de ArbCom de las que el comité ya está considerando (y eso ni siquiera trae AE) , lo que probablemente dirían que es más que suficiente y ¿quiénes somos el resto de nosotros para estar en desacuerdo con ellos? Y, por supuesto, las acaloradas discusiones que este proceso producirá naturalmente conducirán a más y más enlaces de diferencia numerados en estos hilos para cualquiera que intente resolver lo que sea que haya que resolver allí para examinarlo.
En resumen, este proceso propuesto será un detrimento neto para el proyecto, y sólo servirá para complicar lo que ya tiene una tenue relación con la simplicidad. Daniel Case ( charla ) 20:04, 24 de febrero de 2021 (UTC)
- Oponerse : Aunque ciertamente creo que se necesita un procedimiento impulsado por la comunidad para revocar la administración, no creo que tenga que ser tan complicado. Mi opinión personal tiende a ser que si hay consenso para que algo suceda, debería hacerlo. Del mismo modo, si existe un consenso de la comunidad para revocar los derechos de administrador, eso debería suceder. El proceso de ArbCom no es perfecto, y sería bienvenido un proceso comunitario para complementarlo, pero esta propuesta tiene demasiados problemas (como lo mencionaron otros) para que yo la apoye. - Twassman [ Discusión · Contribuciones ] 20:58, 24 de febrero de 2021 (UTC)
- '' 'meh' '' este proceso es demasiado complicado para responsabilizar a los administradores malos y puede apostar su vida a que las condiciones que deben cumplirse nunca se lograrán para administradores poderosos con muchos amigos dispuestos a cerrar discusiones con conclusiones neutrales. Preveo argumentos estúpidos sobre si la culpa debe ser atribuida o si el cierre se revertirá y se disputará, etc. ¿Esto va a hacer que los administradores abusivos rindan cuentas? ¡No! Por lo tanto, haga que el proceso sea factible o no someta a la comunidad a más dramas innecesarios. Spartaz Humbug! 21:26, 24 de febrero de 2021 (UTC)
- Oponerse . (1) Sería un voto de censura en Arbcom que no creo que se merezca. (2) Apoyo al usuario: la justificación bien considerada de Hammersoft . Moriori ( charla ) 00:16, 25 de febrero de 2021 (UTC)
- Oponerse : con respecto al proponente, personalmente no veo cómo un proceso con tantos pasos adicionales y calificaciones y requisitos mínimos arbitrarios para publicar avisos en tantos lugares sería una mejora con respecto a simplemente escribir evidencia en una solicitud de Arbcom. Comparto las preocupaciones sobre el acoso (puede leer lo que escribí hace dos años sobre este punto específicamente) pero ese será el caso con cualquier proceso de desysop decidido por la comunidad, así que no nos detengamos en eso. Mis preocupaciones con esta propuesta son específicamente toda la burocracia adicional para ningún beneficio, y que los umbrales arbitrarios son mucho demasiado bajo. La elección de destitución de gobernador de California de 2003 requirió que el 12% de los votantes de la elección anterior certificara la destitución; Es justo decir que una RFA exitosa promedio atrae a unos 200 electores (consulte Usuario: Ivanvector / Estadísticas de RFA # Tabla 2: Participación de RFA ), lo que haría un umbral justo dos o tres veces más alto que lo que se propone para certificar un retiro de administrador. Eso es realmente solo una estadística; Me preocupa mucho más que esto cree una forma para que los malos actores paguen para eliminar a los administradores que no les gustan, o al menos crearles dolores de cabeza, y no creo que haya ninguna forma de que un proceso de desysop comunitario pueda funcionar. mitigar esa preocupación. Estoy de acuerdo en que Arbcom es demasiado reacio a considerar casos de responsabilidad administrativa, especialmente casos de "pérdida de confianza", y deberíamos estar hablando de abordar eso de una manera que la comunidad pueda obligar a Arbcom a considerar casos en los que ha resultado algo así como una discusión de ANI. en una amonestación o remisión, pero dejando la decisión final al organismo que elegimos y en quien confiamos para considerar cuidadosamente la evidencia y tomar decisiones racionales (y también tenemos WP: LEVEL1 y tal); ya sabes, la forma en que esto ha funcionado bien durante 20 años. De esa manera, no obtiene 50 usuarios en ANI pidiendo un trapeador de administrador y Arbcom simplemente no hace nada al respecto, pero tampoco obtiene una multitud de nacionalistas que brillan en un administrador que no apoyará su guerra de POV. Ivanvector ( Talk / ediciones ) doce y treinta y tres, 25 de Febrero 2021 (UTC)
- Oponerse Para ser francos, no deberíamos crear un nuevo proceso que sea más difícil de usar que el proceso existente. Si no me equivoco, todo lo que se requiere para presentar un caso ARBCOM es una nota en la página de discusión del proyecto o una edición directa a la página de solicitud del caso si es un usuario confirmado. Todas las restricciones y requisitos previos que se proponen aquí son mucho mayores de lo que se requiere para iniciar una solicitud de caso Arb. Cualquier proceso nuevo para complementar ARBCOM debería ser más fácil de usar, no más difícil. - Precediendo sin firmar comentario añadido por 192.196.218.211 ( talk • contribuciones ) - 192.196.218.211 ( charla ) ha hecho pocos o ningún otro tipo de edición fuera de este tema.
- Una solución en busca de un problema. No. ◦ Trey Maturin 03:51, 25 de febrero de 2021 (UTC)
- Oponerse Me gustaría apoyar con fuerza un nuevo procedimiento deysop, pero no ésta. Los administradores simplemente no son responsables en este momento. Para todos aquellos que se quejan de que los administradores serían acosados si se permitiera un deysop comunitario, tengo poca preocupación por esto. Lo que más me preocupa es que los administradores acosen a los editores y que tengan poco o ningún recurso. Yo mismo he sido objeto de acoso administrativo. Sin embargo, esta propuesta actual es tan complicada que sería casi tan difícil (y quizás más) que el único proceso actual. Requiere un mínimo de tres discusiones separadas con todo tipo de límites de tiempo y obstáculos para obtener soporte para un gran número de diferentes tipos de usuarios. Una mejor propuesta sería de dos pasos: un editor activo con confirmación extendida abre una discusión que proporciona evidencia (diffs) y obtiene el apoyo de un mínimo de otros 10 usuarios activos con confirmación extendida (y no tienen que ser administradores). En este punto, se crea la discusión formal, se notifica a toda la comunidad y el administrador puede ser eliminado por mayoría simple. Una propuesta adicional que apoyaría sería hacer que cada administrador pase por una nueva RFA cada 4 años .-- Rusf10 ( hablar ) 04:16, 25 de febrero de 2021 (UTC)
- Débil Oponerse Creo que Hammersoft explica bien los problemas. Como árbitro, creo que el comité es la entidad mejor posicionada para revisar la conducta administrativa, aunque por alguna razón ese mensaje se pierde y en su lugar tenemos (en mi opinión, falaz) la opinión de que no hay forma de eliminar herramientas, que en El turno conduce a una votación más estricta en RfA, etc. No creo que sea una idea terrible, pero me preocupa su capacidad para ofrecer una revisión más estructurada o matizada que la que existe actualmente en AN / ANI. Cas Liber ( charla · contribuciones ) 05:02, 25 de febrero de 2021 (UTC)
- Oponerse . Esto parece una receta para la acción de la mafia después de una decisión difícil, lo que hace que los casos difíciles sean aún más difíciles. Tarl N. ( discutir ) 05:17, 25 de febrero de 2021 (UTC)
- Oponerse con arrepentimiento . Hay demasiados problemas que no tienen salvaguardias claras que los respalden con la conciencia tranquila. No los repetiré, ya que ya se enumeraron anteriormente y varias personas los analizaron a continuación. Si un cerrador considera la fuerza del argumento lógico, no debería ser necesario repetirlos. Si el cerrador está contando votos, este es mío. Recomiendo que se consideren las cuestiones planteadas y, cuando sea necesario, se aborden y se haga una propuesta enmendada. Lo perfecto puede ser enemigo de lo suficientemente bueno, pero no creo que este proceso sea lo suficientemente bueno como se propone. - Comentario anterior sin firmar agregado por Pbsouthwood ( charla • contribuciones ) 05:44, 25 de febrero de 2021 (UTC)
- Básicamente según Guettarda, Useight, Hut 8.5 y Mz7. GAB Gab 16:47, 25 de febrero de 2021 (UTC)
- Oponerse Aunque, en principio, soy de la opinión de que si la comunidad crea administradores, la comunidad deshace administradores. Sin embargo, a menos que haya leído mal la propuesta, esta propuesta permite que los administradores apilen en gran medida el proceso de confirmación en las primeras 48 horas. Eso es antes de la discusión de 2 semanas sobre si deben seguir siendo administradores o no. Además, dado que estas propuestas deben colocarse en AN o ANI, inevitablemente serán los administradores los primeros en recoger cualquier propuesta de este tipo. Me temo que esto podría resultar en un posible conflicto de intereses; naturalmente, se espera que los administradores tengan una colaboración más estrecha entre sí y, por lo tanto, es posible que no sean una parte tan desinteresada como los no administradores. Me gustaría ver una enmienda que elimine las 3 coincidencias de administrador para desysop. BrxBrx ( hablar ) (responda con {{SUBST: re | BrxBrx}}) 16:57, 25 de febrero de 2021 (UTC)
- No estoy seguro de lo que quiere decir con "apilar" el proceso en las primeras 48 horas: ¿quiere decir que más de tres administradores pueden optar por certificar la solicitud? Dado que solo se solicitan opiniones de certificación, no es posible apilar el voto en contra de la certificación. Aunque los conflictos de intereses personales son una preocupación razonable, no creo que el lugar desempeñe un papel. isaacl ( charla ) 17:28, 25 de febrero de 2021 (UTC)
- Oponerse según mis comentarios de soporte originales. Supongo que quiero convencerme de apoyar esto, pero no puedo quitarme la sensación de que esta propuesta empeorará las cosas. En particular, esta propuesta requiere un 40% de apoyo de la comunidad para mantener los derechos (que es muy bajo) (ver comentarios en contra de SD). También sospecho que ArbCom comenzará a buscar más razones para rechazar casos si esto pasa, especialmente si un editor ya ha pasado por el proceso bajo esta propuesta (y, digamos, terminó con el 45%). Si ese es el caso, creo que esta propuesta en realidad sería netamente negativa. Una mención explícita de la relación de este proceso en relación con ArbCom en el texto de la propuesta podría haber aliviado mi preocupación, pero no estar codificado me preocupa. Además, existe el problema del doble riesgo y es probable que los procesos también sean estresantes para el administrador. ProcrastinationReader ( charla ) 22:49, 25 de febrero de 2021 (UTC)
- Oponerse Soy generalmente de apoyo de la noción de desysopping comunidad, pero tengo muchas objeciones a los detalles: 1) El requerimiento reciente edición de elegibilidad no es útil. 2) "Se comportó de manera inapropiada" es demasiado vago. 3) Es posible que un administrador no pueda responder a la solicitud durante 14 días debido a problemas personales. Quizás podamos decir que los permisos de administrador se eliminarán automáticamente si no responden en 14 días, pero pueden optar por realizar la elección de destitución en cualquier momento del próximo año y se les restaurará su parte si sobreviven a las elecciones. 4) El 60% es demasiado alto, si un administrador pierde el apoyo de una mayoría simple de editores, ya no debería ser administrador. - Rey de ♥ ♦ ♣ ♠ 04:37, 26 de febrero de 2021 (UTC)
- Opongo Me encuentro aquí porque no me opongo al principio, pero no creo que esta propuesta sirve bien a la comunidad. Estoy bastante preocupado por el problema de la "turba enojada" que puede desarrollarse (ya hay muchos que piensan que la RfA es polémica, este proceso solo lo hará más), y los buenos administradores pueden simplemente empacar sus maletas y otros pueden no querer participar en los problemas de administración más difíciles. Si bien no creo que exista necesariamente otra forma fuera de un foro comunitario contencioso, deberíamos ajustar los criterios para un esfuerzo de retirada. Mi preferencia sería que dos burócratas decidieran si había motivos suficientes para el esfuerzo, en lugar de tres administradores. - Enos733 ( conversación ) 05:15, 26 de febrero de 2021 (UTC)
- Oponerse . Seamos justos: si bien se necesita un procedimiento de desysop basado en la comunidad, este sistema adolece de dos o tres defectos graves que probablemente demuestren impedimentos importantes para que este procedimiento se convierta en algo muy práctico. El primero es el problema de la "turba enfurecida"; el segundo es el hecho de que muchos administradores (y por esa razón la mayoría de los editores establecidos) tienden a tener varios "amigos", por así decirlo, y también algunos usuarios a los que no les agradan: es probable que esto influya en los resultados del desysop pedido. En tercer lugar, tener un nivel explícito del 60% viola WP: NOTVOTE : no estamos votando, el consenso es necesario en esta solicitud. Java Hurricane 06:24, 26 de febrero de 2021 (UTC)
- Oponerse . Este proceso parece ser al menos tan difícil como deshacerse de él a través de ArbCom y, en mi opinión, es más probable que resulte en acoso hacia los administradores que toman decisiones difíciles. No creo que esta propuesta logre los objetivos especificados. GorillaWarfare (charla) 20:31, 26 de febrero de 2021 (UTC)
- Oponerse . Uno de los principales problemas que estaba abordando la eliminación del sistema de WMF parecía ser la descortesía de los administradores que alejaba a los nuevos editores. Si este proceso excluye a dichos editores, ¿cómo es útil para abordar este problema? De lo contrario, no veo que el cuerpo de administración necesite ser controlado: por lo general, están bien informados sobre la política, son cuidadosos al aplicarla y son susceptibles de reproches cuando se sobrepasan (me impresionó la calma con que los objetivos recientes de la WMF proceso hizo sus casos y lo rápido que se dio cuenta de que todo era en vano). Este proceso es corto en dar fundamentos (¿por qué 10 confirmados extendidos y 3 administradores?) Y parece innecesariamente complejo. Dhtwiki ( charla ) 02:20, 27 de febrero de 2021 (UTC)
- Oponerse . Apoyo la idea general de un desysop comunitario, pero los detalles de este son demasiado problemáticos. Creo que primero debemos trabajar para obtener los detalles correctos. SilkTork ( charla ) 13:42, 27 de febrero de 2021 (UTC)
- Oponerse ... mi opinión sobre este tema ha sido la misma antes de mi administración, durante ella y después de mi propio desysop ... los procesos existentes para desysop son suficientes y la amenaza de una nueva RFA solo agregará estrés a un puesto de voluntario ya estresante. - Jabón - 23:25, 27 de febrero de 2021 (UTC)
- Me opongo, estoy de acuerdo con ciertos puntos que Hammersoft ha planteado. Realmente me gustaría apoyar una propuesta de des-sysop de la comunidad, pero siento que los problemas superan los beneficios. La importancia de un proceso de des-sysop liderado por la comunidad es importante, ya que la relación entre arbcom y la comunidad debe ser tal que a arbcom se le presenten los problemas que la comunidad no ha podido resolver utilizando los procesos y rutas disponibles. Este es el caso de la mayoría de los problemas en los que ocurren discusiones de ANI / AN que proponen y pueden abordar problemas y no veo por qué este no puede ser el caso para los de-sysops (de modo que un proceso de-RfA sería un ruta). Sin embargo, esta propuesta tiene varias cuestiones que me llevan a oponerme, especialmente en torno al apoyo del 60% para eliminar la marca que creo que no se relaciona bien con un RfA. En un RfA, existe la zona de discresión en la que los crats pueden usar el chat de crat para decidir evaluar el consenso. Cualquier proceso de-RfA no debería ser muy diferente a un RfA, por lo que tener una charla crat no parece una mala idea. Además, es posible que el subproceso de AN no esté cerrado como no todos, por lo que esto podría conducir a la reconfirmación de RfA que deberían seguir adelante y no seguir adelante. Además, es posible que un hilo AN no se cierre bien, por lo que debería haber una vía para descontar los cierres incorrectos. Dreamy Jazz habla conmigo | mis contribuciones 00:16, 28 de febrero de 2021 (UTC)
- Oponerse (movido de neutral) - He tenido algo de tiempo para pensar en esto, y nuevamente, he estado por este camino proponiendo políticas similares en el pasado y viendo a muchos otros hacer lo mismo. En resumen, Arb simplemente no está tan ocupado y, en todo caso, han demostrado que pueden actuar rápido (o, a veces, demasiado rápido) para eliminar el bit de administración. En cuanto a la complejidad de presentar un caso Arb, encuentro que es una razón hueca. Cuando hay apoyo para conseguir que un administrador sea desocupado, siempre hay muchas personas que pueden completar el papeleo con bastante rapidez o ayudarlo. Además, no es tan difícil y si lo hace mal, los empleados ayudarán a limpiar la solicitud. La sección de evidencia real (que es lo más importante) no es tan diferente a la ANI, así que en realidad, no es tan diferente. Lo que es diferente es el ritmo, la estructura y un conjunto de reglas que hacen que el evento sea menos dramático y más investigativo. Cuanto más miro esta idea (y otras ideas similares), más siento que la idea de un método de desysop comunitario está desactualizada. Arb está más abierto a la entrada de datos y tiene una carga mucho más liviana, es probablemente la mejor opción para manejar solicitudes, ya que los que toman las decisiones son elegidos por todos los editores aquí precisamente para temas como desysopings. Dennis Brown - 2 ¢ 00:18, 28 de febrero de 2021 (UTC)
- Oponerme Estoy de acuerdo con el principio general, pero no estoy de acuerdo con la propuesta. Prefiero un escenario en el que la comunidad solicite a Arb un desysop. SportingFlyer T · C 00:47, 28 de febrero de 2021 (UTC)
- Oponerse a la condición n. ° 2 es demasiado arbitrario. Depende más de cuántas personas ven la solicitud en un período de tiempo específico que de la gravedad de la infracción. ~ Charla EdGl 01:37, 28 de febrero de 2021 (UTC)
- Oponerse . Como otros, puede valer la pena seguir un proceso de eliminación, pero esta propuesta no lo es. Sería el cebo más truculento para cualquiera que sea llamado apropiadamente por su comportamiento. En teoría, una solicitud de desysop debería requerir al menos varios declarantes y tal vez un extenso proceso de investigación. Montanabw (charla) 01:49, 28 de febrero de 2021 (UTC)
- Oponerse Si bien no es un mal esfuerzo, esta propuesta no parece viable. El proceso para activarlo no se "siente" bien, ya que el listón para los editores que pueden iniciar desysops es demasiado bajo. Esto conducirá a que los administradores sean acosados por solicitudes de mala fe para desysop (25 ediciones en 6 meses no es la definición de un 'editor en regla'). Sin embargo, el requisito de que tres administradores respalden la propuesta tiene sentido. El requisito de que los administradores se vean obligados a transcluir su propia solicitud de desysop está muy mal considerado: si se cumplen los criterios, esto debe ser automático y debe ser manejado por un editor confiable como un miembro o empleado de ArbCom en lugar de obligar al administrador a hacer lo que podría ser un acto angustioso para ellos. Nick-D ( charla ) 10:15, 28 de febrero de 2021 (UTC)
- Oponerse El objetivo de una política de desysop no es malo, pero desafortunadamente no estoy de acuerdo con los detalles y las especificaciones que se proporcionan aquí. Garnarblarnar ( charla ) 15:40, 28 de febrero de 2021 (UTC)
- Oponerse En principio estoy de acuerdo con la propuesta. No estoy de acuerdo con sus mecanismos que, en mi opinión, no nos brindan suficientes garantías contra el uso indebido. Como mínimo, me gustaría ver el punto tres enmendado para que diga "dentro de los 14 días posteriores a su última edición desde la certificación o renuncia como administrador". Sin embargo, hay suficientes otras lagunas que podrían explotarse aquí, por lo que incluso esta enmienda sería insuficiente para llevarme a la columna de apoyo. Una vez más, sin embargo, aprecio el espíritu de la propuesta. Chetsford ( charla ) 19:58, 28 de febrero de 2021 (UTC)
- Oponerse Si bien creo que esto se propuso con buenas intenciones, creo que facilitará la purga de administradores con los que la gente no esté de acuerdo. El proceso de RfA ya es lo suficientemente difícil de aprobar en primer lugar, creo que debería haber más requisitos para desysop un administrador. Andrew nyr ( charla , contribuciones ) 20:48, 28 de febrero de 2021 (UTC)
- Oponerse Si bien apoyo un proceso para deshacerse de un administrador descarriado que no lleva meses, creo que el 60% de aprobación es demasiado bajo. Creo que el porcentaje de aprobación para desysop debería estar en el mismo rango que un RfA exitoso, con burócratas tomando la decisión final en casos cercanos o dentro del rango discrecional. También creo que el proceso debería durar dos semanas, básicamente, como un RfA al revés. Ser eliminado como administrador no debería ser más fácil que el proceso de convertirse en administrador y creo que cualquier administrador activo que haya tomado algunas decisiones impopulares podría llegar fácilmente a un 50-60% de desaprobaciones de las multitudes de los tablones de anuncios. Los participantes en un retiro del mercado deben tener la misma barra que los participantes en un RfA. Si bien me opongo a algunos de los aspectos específicos de esta propuesta, sí apoyo un proceso simplificado para deshacerse de un administrador. L iz Read! ¡Hablar! 21:55, 28 de febrero de 2021 (UTC)
- Estoy empezando a darme cuenta de que lo que todo el mundo realmente quiere decir con "RfA inverso" es simplemente "hacer otro RfA". Lo que más me desconcierta es cómo algunas personas parecen pensar que un administrador que tenía las herramientas, pero falló por algún tipo de irregularidad o pérdida de la confianza de la comunidad, debería tener el mismo listón que un RfA de alguien que no hizo nada malo. Todavía estoy tratando de envolver mi cerebro alrededor de eso. Tuve la impresión de que "las multitudes de los tablones de anuncios" solían ser un grupo de administradores y otros "amigos", así como miembros de la comunidad ... Huggums537 ( charla ) 01:56, 1 de marzo de 2021 (UTC)
- Dado que una revisión del candidato incluiría la revisión de cualquier paso en falso pasado, los participantes lo incluirían como parte de su evaluación. Cualquier deseo de evidencia adicional más allá de lo que normalmente se busca se incluye en la ponderación realizada por los comentaristas de los pros y los contras. isaacl ( charla ) 02:46, 1 de marzo de 2021 (UTC)
- Veo el punto que está tratando de hacer, pero sigue siendo una equivalencia falsa porque apuesto mi último dólar a que nunca ha habido un candidato de RfA que tenga un caso AN / I pendiente en su contra. Huggums537 ( charla ) 03:24, 1 de marzo de 2021 (UTC)
- No estoy seguro de qué estás pensando que estoy haciendo equivalente. Cuando los participantes deciden si un candidato es lo suficientemente confiable y, por lo demás, apto para tener (o seguir teniendo) privilegios administrativos, sopesarán si los pros superan a los contras. Considerarán cualquier problema que surja cada vez que sucedió (recientemente, hace seis meses, hace un año) y lo tendrán en cuenta. Isaacl ( charla ) 03:33, 1 de marzo de 2021 (UTC)
- Hipotéticamente, está tomando a un administrador acusado de irregularidades, que presumiblemente tiene un caso actual de desysop de AN / I en su contra, y está tratando de hacer eso equivalente a un candidato para RfA dándole el mismo procedimiento, barra y criterio, excepto usted No se puede
equívocarequiparar los dos porque a un candidato RpA nunca se le permitiría participar en un RfA si tuviera un caso AN / I pendiente en su contra. Por lo tanto, no hay razón para que un administrador acusado de estar equivocado con un AN / I pendiente reciba la misma barra, o incluso otro RfA cuando a otros candidatos ni siquiera se les permite participar en RfA si tienen un AN / I pendiente. Huggums537 ( charla ) 04:59, 1 de marzo de 2021 (UTC)- No digo que las dos candidaturas sean equivalentes; Estoy diciendo que la gente evaluará a los candidatos sobre la base de toda la información disponible. Cualquiera puede enviar una solicitud en cualquier momento. Si hay una discusión abierta en el tablón de anuncios de incidentes del administrador, eso se tendrá en cuenta. Si la solicitud se cierra rápidamente debido a una disidencia abrumadora, que así sea. Los participantes ajustarán automáticamente sus estándares al presentar sus puntos de vista. isaacl ( charla ) 05:13, 1 de marzo de 2021 (UTC)
- Hipotéticamente, está tomando a un administrador acusado de irregularidades, que presumiblemente tiene un caso actual de desysop de AN / I en su contra, y está tratando de hacer eso equivalente a un candidato para RfA dándole el mismo procedimiento, barra y criterio, excepto usted No se puede
- No estoy seguro de qué estás pensando que estoy haciendo equivalente. Cuando los participantes deciden si un candidato es lo suficientemente confiable y, por lo demás, apto para tener (o seguir teniendo) privilegios administrativos, sopesarán si los pros superan a los contras. Considerarán cualquier problema que surja cada vez que sucedió (recientemente, hace seis meses, hace un año) y lo tendrán en cuenta. Isaacl ( charla ) 03:33, 1 de marzo de 2021 (UTC)
- Veo el punto que está tratando de hacer, pero sigue siendo una equivalencia falsa porque apuesto mi último dólar a que nunca ha habido un candidato de RfA que tenga un caso AN / I pendiente en su contra. Huggums537 ( charla ) 03:24, 1 de marzo de 2021 (UTC)
- Dado que una revisión del candidato incluiría la revisión de cualquier paso en falso pasado, los participantes lo incluirían como parte de su evaluación. Cualquier deseo de evidencia adicional más allá de lo que normalmente se busca se incluye en la ponderación realizada por los comentaristas de los pros y los contras. isaacl ( charla ) 02:46, 1 de marzo de 2021 (UTC)
- Estoy empezando a darme cuenta de que lo que todo el mundo realmente quiere decir con "RfA inverso" es simplemente "hacer otro RfA". Lo que más me desconcierta es cómo algunas personas parecen pensar que un administrador que tenía las herramientas, pero falló por algún tipo de irregularidad o pérdida de la confianza de la comunidad, debería tener el mismo listón que un RfA de alguien que no hizo nada malo. Todavía estoy tratando de envolver mi cerebro alrededor de eso. Tuve la impresión de que "las multitudes de los tablones de anuncios" solían ser un grupo de administradores y otros "amigos", así como miembros de la comunidad ... Huggums537 ( charla ) 01:56, 1 de marzo de 2021 (UTC)
- Oponerse , una solución en busca de un problema. Esta propuesta da la impresión de que alguien quiere deshacerse de un administrador y piensa que es demasiado difícil. ¿Cuántos administradores activos tenemos? 500? En todo caso, debemos facilitar la tarea de convertir a las personas en administradores .-- Berig ( charla ) 08:01, 1 de marzo de 2021 (UTC)
Lo siento, pero esto casi llega a la cúspide de parecer como un reclamo sin fundamento contra el nominador de esta propuesta, que no proporciona ninguna evidencia de que haya habido cierres de AN / I contra otro administrador a quien hayan opuesto en los últimos 6 meses que yo sepa. Ese es el tipo de evidencia que necesitaría para llegar a ese tipo de conclusión. Tenga cuidado con lo que está sugiriendo, incluso si no es intencional, a menos que tenga algún tipo de evidencia como esa. Gracias.Huggums537 ( charla ) 16:30, 1 de marzo de 2021 (UTC)- Creo que tal vez este editor realmente no quiso hacer daño con su comentario, y solo estaba tratando de expresar una opinión. Tachando mi comentario en consecuencia. Huggums537 ( charla ) 17:20, 1 de marzo de 2021 (UTC)
- Oponerse , no veo ninguna razón para creer aquí que ArbCom no está dispuesto a desysop a los administradores cuando sea necesario. Como dijo Bradv anteriormente, ese proceso se basa en la evidencia y es deliberativo, y así es como debe hacerse. Seraphimblade Háblame 14:53, 1 de marzo de 2021 (UTC)
- Oponerse porque necesitamos más administradores, no menos, y este proceso arreglaría lo que no está roto. Jonathunder ( charla ) 15:49, 1 de marzo de 2021 (UTC)
- Por supuesto que está roto. Es absurdo decir tal cosa. ¿Por qué está en proceso, si no estaba roto? scope_creep Talk 16:28 , 1 de marzo de 2021 (UTC)
- Hay una amplia variedad de opiniones en esta sección en contra, pero una proporción significativa se opone porque no creen que el proceso actual deba arreglarse, por lo que es injusto descartar esta preocupación como "absurda". Mz7 ( conversación ) 17:21, 1 de marzo de 2021 (UTC)
- Por supuesto que está roto. Es absurdo decir tal cosa. ¿Por qué está en proceso, si no estaba roto? scope_creep Talk 16:28 , 1 de marzo de 2021 (UTC)
- Oponerse Básicamente a todo lo dicho anteriormente. Necesitamos más administradores, no menos. Arbcom es un lugar mucho mejor para lidiar con la mala conducta de los administradores. Esto apesta a "justicia de masas". La amenaza de esto podría tener efectos paralizantes en los administradores que deseen trabajar y realizar llamadas difíciles en áreas controvertidas. IronGargoyle ( charla ) 01:00, 2 de marzo de 2021 (UTC)
- Oponerse según la mayoría de los anteriores. Pero haré dos observaciones específicas. Primero, esto parece ser una solución en busca de un problema. En segundo lugar, no se ha ofrecido ningún argumento creíble de por qué ARBCOM es, o debería ser visto, incompetente para lidiar con acusaciones de mala conducta del administrador. Y si ARBCOM no es incompetente, ¿qué estamos haciendo aquí? - Ad Orientem ( charla ) 01:12, 2 de marzo de 2021 (UTC)
- @ Ad Orientem : AFAICS, la pregunta no es si ArbCom no puede lidiar con el problema, ya que es más algo que podría quitarse de las manos de ArbCom, o al menos esto reduciría su carga de trabajo en esta área (ya que, en última instancia, el dice el argumento, los administradores son responsables ante la comunidad, que los eligió). Si eso aborda otros problemas y preocupaciones con la propuesta es otro asunto. Saludos, RandomCanadian ( charla / contribuciones ) 01:36, 2 de marzo de 2021 (UTC)
- Oponerse . Esta es una política de "un solo golpe". La desobediencia debe basarse en un abuso atroz de la confianza o en un patrón de incompetencia a largo plazo. La política propuesta anteriormente establece el listón demasiado bajo para la eliminación de privilegios de administrador, permitiendo efectivamente la eliminación con un solo error. Un error, especialmente en un sitio cuyas reglas y políticas están en constante cambio, puede y debe ser perdonado. Creo que Arbcom ya funciona lo suficientemente bien como para deshacerse de él. En todo caso, los efectos para mejorar la desisolación deberían girar en torno a simplificar y agilizar ese proceso. Jason Quinn ( charla ) 02:06, 2 de marzo de 2021 (UTC)
- Oponerse . Arbcom es incompetente, pero agregar nuevos procesos de trollbait tampoco ayuda. jni ( hablar ) ( borrar ) 07:02, 2 de marzo de 2021 (UTC)
- Oponerse , una vez más, tenemos una solución en busca de un problema. Necesitamos más administradores, no menos, y dar gente con hachas (¿o deberían ser espadas de Damocles?) Para moler un lugar como este simplemente significará que los administradores se desanimarán aún más de manejar algo remotamente controvertido.
Yo podría ser convencido de soportar una prueba de 1 año, con una garantía de hierro fundido que después del período de prueba de un año, el proceso termina, y un consenso total, completa y positiva después de la discusión es necesario para volver a ponerlo en práctica. Sofocar ( charla ) 11:59, 2 de marzo de 2021 (UTC) - Al leer el comentario de SD0001 a continuación, me di cuenta de que no es un 60%, pero el 40% de soporte es suficiente para seguir siendo administrador. ¿Por qué alguien debería necesitar el apoyo firme de la mayoría para convertirse en administrador, pero el apoyo de la minoría es suficiente para seguir siendo administrador? Esta propuesta solo sería buena para deshacerse de los administradores heredados que no tienen muchos amigos, pero hará que deshacerse de WP: UNBLOCKABLES sea aún más difícil que el sistema actual. No me habría opuesto basándome solo en el porcentaje, pero hay muchos otros problemas con esta propuesta que otros han destacado anteriormente. AVS malnad 77 talk 15:52, 2 de marzo de 2021 (UTC)
- Oponerse según los comentarios hechos anteriormente por bradv, neodop, wbm1058, Sandstein y muchos de los puntos de Hammersoft. Cbl62 ( charla ) 17:24, 2 de marzo de 2021 (UTC)
- Oponerse a. Esta propuesta es como una que yo mismo escribiría, pero con un detalle esencial equivocado. Esta propuesta busca crear un medio para eliminar a los administradores que se han involucrado en una mala conducta, que es exactamente el grupo equivocado al que apuntar, ya que ArbCom lo hace bastante bien y la comunidad lo hace comparativamente mal. Los casos de mala conducta administrativa son a menudo enormes y expansivos, involucrando muchos años de historial de conducta y cientos y cientos de diferencias, que requieren semanas de esfuerzo por parte de personas dedicadas. ¿Alguien realmente piensa que la discusión en el tablero de drama es un medio superior para investigar y resolver esos casos? ¿O otro proceso similar a RfA? Lo que realmente necesitamos es un proceso comunitario para despedir a los administradores que no se han involucrado en actos identificables específicos de mala conducta administrativa, sino que han perdido la confianza de la comunidad (por ejemplo, por mal juicio, por un patrón de descortesía que no se eleva a un nivel sancionable nivel, etc.). Por lo tanto, apoyaría esta propuesta si se aplicara solo a los casos de no mala conducta de alguna manera, y explícitamente no se aplicara en el caso de mala conducta real. En este caso, debo oponerme con pesar porque creo que, por implicación y en la práctica, aunque no formalmente, debilitaría los procesos existentes que tenemos (ArbCom) sin proporcionar un sustituto bueno o adecuado. Me complace dar más detalles sobre mis pensamientos si alguien tiene preguntas. Saludos , KevinL ( también conocido como L235 · t · c ) 20:13, 2 de marzo de 2021 (UTC)
- Este, por cierto, era el problema fundamental con WP: BARC e ideas similares. No necesitamos otro proceso para remover administradores por mala conducta; necesitamos uno para eliminar administradores por perder la confianza de la comunidad. KevinL ( también conocido como L235 · t · c ) 20:19, 2 de marzo de 2021 (UTC)
- En un grado mucho mayor que otros argumentos opuestos, encuentro su argumento muy interesante y vale la pena reflexionarlo más. ¡Gracias por plantear estas cuestiones! Estoy tratando de visualizar mentalmente lo que implicaría que un administrador no hubiera hecho nada incorrecto de manera procesal y no hubiera hecho nada incorrecto con respecto a la "conducta [no] convertirse en administrador" y, sin embargo, condujo a una pérdida de consenso de la comunidad. confianza. Tal como está escrito, la propuesta aquí se enmarca en términos de un consenso de tablón de anuncios de que el administrador "se comportó de manera inapropiada". Creo que eso es más amplio que un mal uso específico de herramientas y claramente abarca una conducta inapropiada / impropia. Me parece que alguien que ha perdido la confianza de la comunidad habrá sido objeto de algún tipo de discusión en el tablón de anuncios, pero tal vez me esté perdiendo algo. - Tryptofish ( charla ) 22:49, 2 de marzo de 2021 (UTC)
- Las respuestas agresivas durante un largo período de tiempo es un ejemplo típico de comportamiento que puede fallar en producir una sola discusión que equivale a más que una reprimenda a medias ("el comportamiento no era ideal, pero surgió de una defensa apasionada de Ideales de Wikipedia ") y, sin embargo, ser parte de un patrón a largo plazo que posiblemente no cumpla con las expectativas de la comunidad, por lo que podría justificar una revisión. Por supuesto, cómo pasar de "podría justificar" a decidir si se hace o no una revisión es el meollo del problema. isaacl ( charla ) 23:09, 2 de marzo de 2021 (UTC)
- Sí, creo que eso es todo. Quizás debería haber un posible desencadenante que consistiría en un patrón de discusiones (¿relacionadas?) A lo largo del tiempo. Por otro lado, KevinL sostiene que los problemas que se acumulan con el tiempo se adaptan mejor a ArbCom que a la comunidad, aunque yo diría que la "confianza de la comunidad" es algo que la comunidad debe determinar. - Tryptofish ( conversación ) 23:34, 2 de marzo de 2021 (UTC)
- Continuando en esa línea, la propuesta aquí claramente permitiría múltiples discusiones AN / ANI, en lugar de requerir que no haya más de una. Puedo imaginarme que los argumentos sobre "el comportamiento no era ideal" es igual o no igual a "se comportó de manera inapropiada". Pero creo que la propuesta aquí podría usarse para examinar un caso que se ajuste a esta descripción y, apropiadamente, dependería de la comunidad si un patrón repetido de "no ideal" alcanza o no el umbral de abandono. - Tryptofish ( conversación ) 23:41, 2 de marzo de 2021 (UTC)
- @ Tryptofish : Otro caso a considerar es lo que yo llamo "administradores en cuclillas" que hacen lo mínimo para mantenerse por encima de nuestros requisitos de inactividad. Menciono esto en mi comentario de apertura en WP: DESYSOP2019 :
Creo que es un proceso mediante el cual la comunidad puede decirle a un administrador ocupante "gracias por todo lo que ha hecho por la comunidad, pero claramente ha seguido adelante y nos gustaría dejarte seguir adelante "podría ser realmente saludable.
No habrían hecho nada malo o digno de ArbCom, pero con el ir y venir de los contribuyentes, es posible que no tengan la confianza de la comunidad actual. Una forma de probar eso y sopesar los costos y beneficios del acceso continuo a las herramientas es una situación que veo surgir con más frecuencia que una mala conducta. - Wug · a · po · des 21:49, 5 de marzo de 2021 (UTC)
- Las respuestas agresivas durante un largo período de tiempo es un ejemplo típico de comportamiento que puede fallar en producir una sola discusión que equivale a más que una reprimenda a medias ("el comportamiento no era ideal, pero surgió de una defensa apasionada de Ideales de Wikipedia ") y, sin embargo, ser parte de un patrón a largo plazo que posiblemente no cumpla con las expectativas de la comunidad, por lo que podría justificar una revisión. Por supuesto, cómo pasar de "podría justificar" a decidir si se hace o no una revisión es el meollo del problema. isaacl ( charla ) 23:09, 2 de marzo de 2021 (UTC)
- En un grado mucho mayor que otros argumentos opuestos, encuentro su argumento muy interesante y vale la pena reflexionarlo más. ¡Gracias por plantear estas cuestiones! Estoy tratando de visualizar mentalmente lo que implicaría que un administrador no hubiera hecho nada incorrecto de manera procesal y no hubiera hecho nada incorrecto con respecto a la "conducta [no] convertirse en administrador" y, sin embargo, condujo a una pérdida de consenso de la comunidad. confianza. Tal como está escrito, la propuesta aquí se enmarca en términos de un consenso de tablón de anuncios de que el administrador "se comportó de manera inapropiada". Creo que eso es más amplio que un mal uso específico de herramientas y claramente abarca una conducta inapropiada / impropia. Me parece que alguien que ha perdido la confianza de la comunidad habrá sido objeto de algún tipo de discusión en el tablón de anuncios, pero tal vez me esté perdiendo algo. - Tryptofish ( charla ) 22:49, 2 de marzo de 2021 (UTC)
- Este, por cierto, era el problema fundamental con WP: BARC e ideas similares. No necesitamos otro proceso para remover administradores por mala conducta; necesitamos uno para eliminar administradores por perder la confianza de la comunidad. KevinL ( también conocido como L235 · t · c ) 20:19, 2 de marzo de 2021 (UTC)
- Oponerse . Cualquiera debería poder proponer tal cosa y hacerlo de forma anónima. Un procedimiento demasiado complejo aquí. Hyperbolick ( charla ) 22:21, 2 de marzo de 2021 (UTC)
- Oponerse . El intento es noble, pero no puede funcionar por muchas razones: la mayoría de los comentarios aquí se basan en una plataforma negativa peyorativa como en, identificar y castigar (desysop). Como dice Hammersoft, estas son personas reales, agregaría, no nombres en una pantalla. Hay un abuso y una descortesía muy reales en Wikipedia; algunos son obvios, viciosos, deliberados. El verdadero abuso no es el administrador que está cansado y frustrado y cuyo lenguaje indica ese estado de fatiga física y mental. El verdadero abuso y la descortesía son las mentiras, las manipulaciones en los intentos de controlar el contenido y el poder. Los arbitrajes tampoco son necesariamente la respuesta. Funcionan mejor para casos atroces en los que los arbitros deben dedicar una gran cantidad de tiempo a determinar las acciones y el contexto que describirán cuáles son los problemas reales. Pero nadie gana en un arbitraje. El estrés de un arbitraje prolongado crea fatiga para la mayoría de las personas y si pierden y se avergüenzan, más. El sistema construido en los primeros días de Wikipedia ya no funciona. Hablé de esto antes, así que no volveré a hablar de ello. Pero al final, un sistema obsoleto basado en una plataforma peyorativa, donde el abuso verdadero es difícil de detectar, no se puede arreglar con otro tipo de sistema de tablón de anuncios en el que los choques son posibles. Si basamos nuestra comunidad colaborativa en la negatividad y el estrés, crearemos negatividad y estrés y perderemos editores y administradores. Los días iniciales y las funciones de la entonces nueva Wikipedia no son sagrados. Este es un experimento y flexibilidad en curso, y se necesitará un enfoque en los editores como seres humanos que funcionan mejor en entornos de apoyo para que Wikipedia crezca y sea saludable. De todas formas. Littleolive oil ( charla ) 00:30, 3 de marzo de 2021 (UTC)
- Oponerse Dadas las preocupaciones muy válidas expresadas sobre los detalles de esta implementación, dada la poca frecuencia con la que los administradores son desocupados por una causa, dado que esta solución podría estar solucionando un problema que no necesariamente existe (ArbCom es competente para manejar esto con seguridad, problemas sobre la comunidad confianza a un lado), y finalmente dadas las convincentes súplicas de KevinL y de Littleolive Oil, no puedo apoyar esta propuesta. RandomCanadian ( charla / contribuciones ) 03:18, 3 de marzo de 2021 (UTC)
- Oponerse , por dos razones. Primero: un proceso público tiene el potencial de ser espectacular, por lo que, sin una razón primordial para utilizar dicho proceso, en general debería evitarse. Segundo: los únicos casos en los que este proceso funcionaría mejor que el proceso existente de Arbcom es cuando el operador del sistema ya es impopular, o cuando Arbcom no tiene la capacidad de manejar todos esos casos. Pero estas no son razones suficientemente buenas porque (1) no tenemos un problema particular con los sysops impopulares que necesitan ser eliminados; y (2) Arbcom no está actualmente (ni esperamos que lo esté en un futuro próximo) sobrecargado con la carga de trabajo. - Eric Herboso 05:07, 3 de marzo de 2021 (UTC)
- Oponerse a. Hay parte de una buena idea aquí, pero los detalles hacen que sea demasiado fácil crear un circo de problemas mientras se va demasiado rápido a la silla eléctrica. En cambio, el proceso hace que sea demasiado fácil derribar a un administrador que no le gusta o que realmente cometió un error de juicio sin mostrar suficiente buena fe a ese administrador, al tiempo que complica las cosas para que ese administrador reaccione, defienda o mejore. Doczilla @SUPERHEROLOGIST 09:21, 3 de marzo de 2021 (UTC)
- Oponerse . Realmente desearía que hubiera algún proceso para que la gente decida directamente, pero es bastante difícil en este caso, cuando se trata de evaluar a las personas. También observo que un representative_democracy , es decir, el ARbCom, es una forma válida de una comunidad que se expresa. En cuanto a la propuesta actual, creo que el problema no está tanto en lo que dice, que es en su mayoría sensato, como en lo que no dice. Dos cosas que no dice. Uno, ¡no requiere advertir al administrador de la solicitud! Dos, no impone ningún tipo de límite en la cantidad de solicitudes o respaldos por parte de ningún usuario, por lo que puede haber un conjunto de ' vigilantes ' que acosa a algunos administradores una y otra vez. La regla del 60% no está bien pensada, permite un voto de 2-1 para desysop a alguien ... improbable, sí, pero no debe ser suficiente para desysop, nunca. Debería haber un número mínimo de votos o, mejor, un umbral variable, digamos a partir del 100% con 10 votos, hasta el 50% con muchos (cientos ...) de votos - Nabla ( charla ) 19:55, 3 de marzo 2021 (UTC)
- Oponerse . El número correcto de administradores necesarios para iniciar dicho proceso es cero. Los des-sysops son raros en wikipedia debido al amiguismo de los administradores, y cualquier proceso que no aborde este problema es inútil. Los administradores son seleccionados por procesos impulsados por la comunidad y deben ser deseleccionados por procesos similares impulsados por la comunidad sin poner barreras masivas en el camino. Muchos administradores aquí son habitualmente descorteses y no sobrevivirían a un proceso de recuperación / reconfirmación. MaxBrowne2 ( charla ) 21:08, 3 de marzo de 2021 (UTC)
- Oponerse . Se espera que los administradores tomen acciones que a muchos editores no les gustarán. Me temo que los administradores serán aún más reacios a tomar las medidas necesarias contra los editores populares si están sujetos a ser retirados. Además, en los últimos años, ArbCom ha demostrado que es muy capaz de usar sus poderes de desysop cuando es necesario. Básicamente, creo que esta propuesta es innecesaria y perjudicial. Red Rock Canyon ( conversación ) 23:58, 3 de marzo de 2021 (UTC)
- Oponerse con pesar y sin prejuicios a futuras propuestas sobre este tema. Este es un esfuerzo bien intencionado y muy bien meditado. Me preocupa el efecto escalofriante que esto puede tener en los administradores y su voluntad de hacer un trabajo bueno, pero a veces impopular. Se debe alentar a los administradores a tener políticas de retiro del mercado y ArbCom debe continuar funcionando lo mejor que pueda. - t u coxn \ talk 20:17, 4 de marzo de 2021 (UTC)
- Oponerse por varias razones. Siento que un consenso de la comunidad podría ser algo bueno, pero creo que este sistema es demasiado complejo y que hacer cumplir las reglas generales podría conducir a correcciones excesivas en ocasiones. Si bien creo que la idea de tener algún tipo de consenso comunitario para deshacerse de las personas, siento que esta propuesta no es la forma correcta de hacerlo y es demasiado compleja en muchos sentidos. Al igual que con los editores, siento que "uno y listo" solo debe reservarse para los errores más atroces y creo que el estándar de asumir la buena fe debe ir no solo a los editores sino también a los administradores. Esta política, en mi opinión, va en contra de la buena fe y siento que muchas discusiones de desysops serían usuarios descontentos que respondieran a los administradores que hacen su trabajo. Siento que con muchos errores de administrador, una simple discusión en su página de discusión solucionará el error (o un RfC). Vi a un usuario aquí proponer que crats elimine cualquier discusión que obviamente fallaría o no cumpliría con los criterios, pero creo que esto anularía el punto de tener un consenso de la comunidad. Si bien no estoy en contra, creo que el conjunto de reglas propuesto anteriormente haría más daño que bien al final. Jns4eva ( charla ) 05:35, 5 de marzo de 2021 (UTC)
- Esta es una propuesta perfectamente buena. Simplemente no estoy convencido de que el procedimiento actual de desysop esté roto. Los ArbCom recientes tienen un historial bastante bueno de resolución de disputas de conducta de administradores. - Tera tix ₵ 06:14, 5 de marzo de 2021 (UTC)
- Oponerse : para esto tenemos ArbCom. Graham Beards ( charla ) 19:29, 5 de marzo de 2021 (UTC)
- Fuerte oposición . Esta propuesta perenne carece de salvaguardias y, como han señalado otros, penaliza a los administradores que trabajan en áreas difíciles (donde más las necesitamos). El comité de arbitraje, aunque imperfecto, ha demostrado capacidad y voluntad para lidiar no solo con abusos atroces de autoridad, sino también con patrones continuos de mal juicio. Compañía no invitada 01:05, 6 de marzo de 2021 (UTC)
- Oponerse y oponerse a cualquier modificación de esta propuesta. Después de ver esto por un tiempo, no me siento inclinado a apoyar. ¿Esto incluso está resolviendo un problema necesario? Los únicos casos en los que se debe usar esto, en mi opinión, son cuando un administrador está haciendo algo atrozmente malo, en cuyo caso ArbCom debería encargarse de ello (si no, ¿por qué están allí?). ser muy estresante y ahuyentar a muchos buenos administradores, o evitar que trabajen en campos potencialmente controvertidos. La razón por la RFA y los criterios de escrutinio son tan altos es robaba esta es la única vez que la mayoría de la gente va a llegar a decidir si alguien es un administrador. En WP: los administradores de PERM a menudo otorgan derechos temporalmente, pero la administración es permanente, por lo que, por supuesto, se presta a un mayor escrutinio. Exigir a las personas que pasen por posibles RfA de confirmación, incluso con una barra alta, simplemente no es una buena idea. Ahora, ¿sería mejor un mundo donde los términos administrativos son temporales y los criterios para aprobar un RfA son más bajos? Tal vez, pero ese no es el lugar en el que vivimos, y soy muy cauteloso al arreglar algo que no está roto, especialmente con el peligro potencial de ahuyentar a los administradores en el proceso. Elli ( charla | contribuciones ) 23:05, 7 de marzo de 2021 (UTC)
- Oponerse : la pregunta no es si la comunidad debe tener un proceso de desysop, sino más bien cómo se debe establecer el listón alto para iniciar el proceso: debe ser (1) lo suficientemente alto como para aislar a los administradores (y candidatos a administradores potenciales) del miedo indebido en el desempeño de sus funciones, y (2) lo suficientemente bajo para garantizar que los administradores que han perdido nuestra confianza puedan ser eliminados. Creo que el proceso actual de ArbCom es el nivel correcto para que se establezca este listón, y que el proceso propuesto bajaría demasiado el listón (creo que Hammersoft ha examinado esto bien; aunque esta propuesta se ha endurecido con respecto a las anteriores, permanece fundamentalmente débil al juego, mala fe, ajuste de cuentas debido al origen del proceso). Los malos administradores deberían temer que la comunidad elimine sus herramientas, pero hacer que el proceso se origine en AN y ANI crearía un efecto escalofriante sobre las acciones de cada administrador en un grado que creo que es subestimado por los partidarios de esta propuesta. Creo firmemente que hay un área gris dentro de (1) mala conducta administrativa flagrante, (2) mala conducta más sutil y (3) una pérdida de confianza de la comunidad que no llega al nivel de ninguna de las dos. Las tres categorías son claramente motivo de des-sysop, pero ArbCom a menudo carece del capital político para lidiar con la última de manera efectiva. La última categoría es el espacio donde se debe insertar el proceso comunitario, y señalo la propuesta planteada por Tryptofish a continuación (un desysop iniciado por el remedio o moción de ArbCom) como donde debe estar una propuesta futura. - Goszei ( conversación ) 23:21, 7 de marzo de 2021 (UTC)
- Oponerse por GorillaWarfare . Ed [charla] [titán majestuoso] 05:07, 9 de marzo de 2021 (UTC)
- Oponerse por muchos de los anteriores. Esperé un rato para decidir si apoyar porque entiendo el sentimiento detrás de él, pero al final, no veo cómo este sistema sería superior al sistema actual de ArbCom que maneja estos casos. Cualquier sistema para reemplazar o complementar ArbCom en esta área debe incluir las mismas salvaguardas que ArbCom tiene contra el abuso del sistema para penalizar a los administradores que realizan el trabajo necesario y correcto en áreas difíciles. Este sistema probablemente disminuirá el número de administradores dispuestos a trabajar en esas áreas por temor a ser desocupados por los amigos de los sancionados. Saludos, entonces por qué 11:17, 9 de marzo de 2021 (UTC)
- Oponerse . Esta propuesta esencialmente da un cheque en blanco a las personas en áreas temáticas divisivas / sancionadas para excluir a cualquier administrador que no les guste. - Un pequeño Bori azul v ^ _ ^ v Se necesita un hombre fuerte para negar ... 17:14, 9 de marzo de 2021 (UTC)
- Oponerse , demasiado burocrático, y creo que la participación de ANI es contraproducente y tendrá consecuencias no deseadas. - Kusma ( t · c ) 21:44, 9 de marzo de 2021 (UTC)
- Me opongo , por las muchas cuestiones planteadas, apoyo moralmente una propuesta como esta, pero no puedo apoyarla en su forma actual. Charla Asartea | Contribuciones 16:00, 12 de marzo de 2021 (UTC)
- Oponerse debido a las muchas cuestiones planteadas, en particular las preocupaciones de Beeblebrox. Siento que esta sería una buena manera de acosar a los administradores, especialmente a aquellos involucrados en áreas conflictivas (es decir, lleve cada pequeño error que pueda encontrar a ANI, cerrándolo como "sí, no deberían haber hecho eso", y luego repetidamente "Ya ha habido 15 intentos, deben ser eliminados"), y me resulta difícil establecer una barrera adecuada sin requerir una coordinación secreta fuera de la wiki o correr hacia preocupaciones de WP: TROPHY , las cuales son inaceptables. - csc -1 23:34, 12 de marzo de 2021 (UTC)
- Oponerse . Encuentro esta propuesta defectuosa tanto en los detalles como en la motivación. Autorizar a los "grandes jurados" a emitir juicios amplios sobre la idoneidad del administrador basándose en tan solo un hilo ANI desfavorable es una receta para todo tipo de juegos y pandillas. Estoy de acuerdo con lo que se ha dicho anteriormente sobre ANI: es esencialmente una mobocracia con una apariencia de proceso y, en ese sentido, está lejos de ser autoritaria. Prácticamente cualquiera puede cerrar una discusión y el "consenso" depende principalmente de quien esté patrullando la junta ese día ... o, potencialmente, quien esté más decidido a impulsar su agenda.
En cuanto a otros detalles: "se comportó de manera inapropiada" es una acusación demasiado vaga, la parte de trasladar-en-14-días-o-renunciar me parece innecesariamente degradante (y extraño - si el caso ha "ido a juicio", el juicio debería comenzar de inmediato) y me parece extraño que las discusiones sobre eliminación del sistema se publiquen de maneras tan diferentes a las de las RpA.
En cuanto a la motivación, veo poca necesidad de este proceso cuando tenemos un ArbCom que es totalmente capaz de tomar medidas contra un administrador cuando los miembros de la comunidad presentan un buen caso con buena evidencia. Desde el cierre del último RfC de des-sysopping en enero de 2020, ha habido tres arbitrajes que resultaron en un des-sysopping, y desde el inicio de este RfC, se abrió otro caso de administrador. El arbitraje puede ser un proceso largo, pero al menos no es una simple acumulación, y todos los involucrados deben actuar con decoro y moderación. No creo que se pueda decir lo mismo de lo que aquí se propone.
Finalmente, en respuesta a los apoyos en la línea de "otras propuestas han fracasado y algún tipo de proceso es mejor que nada", el hecho de que otras propuestas no hayan sido aprobadas no significa que ésta deba hacerlo. Super Mario Man ( Discusión ) 23:22, 13 de marzo de 2021 (UTC) - Oponerse Según mi comentario sin respuesta a continuación, podría haber podido respaldar esta propuesta si el requisito hubiera sido que el cierre de ANI hubiera concluido que un administrador había utilizado incorrectamente sus herramientas / estado, pero permitiendo que un proceso de desysop comenzara basado en un no -el error de juicio relacionado con el administrador va demasiado lejos. Como dice Dirk Beetstra anteriormente, todos somos humanos y todos cometemos errores. Estoy seguro de que hay algunas cosas por las que podría haberme criticado a lo largo de los años, pero no creo que ninguna de ellas se acerque a ser una justificación para iniciar un proceso de desysop. Hay muchos editores que guardan rencor contra los administradores a los que les encantaría tener la oportunidad de eliminarlos (recibo pings no deseados ocasionales que se burlan de mi estado como administrador debido a una disputa sobre una pauta de notabilidad) y, desafortunadamente, tantos como he señalado anteriormente, sospecho que esto se utilizará para acosar a los administradores que regularmente se ocupan de un área temática con un grupo significativo de editores con un punto de vista claro. Mi RfA atrajo a dos grupos de editores nacionalistas a los que había cabreado (incluido un editor que solicitó votos en contra), y aunque al final se aprobó por poco, realmente no me gustaría que otros experimentaran eso. Saludos, número 5 7 14:38, 14 de marzo de 2021 (UTC)
- Me opongo a que me preocupe que los administradores que trabajan en las áreas más difíciles sean acosados indebidamente por esta propuesta. Creo que aquellos colaboradores que se someten a los rigores de RfA y son recompensados con la confianza de la comunidad, deben seguir recibiendo la confianza de la comunidad. En el caso de que el comportamiento del administrador se ponga en duda, ese editor debe estar abierto al proceso de retirada (su elección) o hacer que su comportamiento sea examinado por un organismo que también haya sido recompensado con la confianza de la comunidad; ese organismo es en este momento el Comité de Arbitraje. En general, el comportamiento de los administradores no parece ser un problema significativo, pero puede causar mucho drama y pérdida de tiempo. Aumentar el número de administradores ayudaría a reducir el problema con una reducción de la presión sobre el cuerpo actual. Concentrémonos en aumentar el número de administradores en lugar de idear esquemas que los reduzcan. Poltair ( conversación ) 08:34, 15 de marzo de 2021 (UTC)
- Opónganse principalmente por Hammersoft. Para obtener mi opinión completa, consulte la sección #Oh, administración a continuación. 🐔 ¡ Chicdat Bawk para mí! 10:24, 15 de marzo de 2021 (UTC)
- Oponerse El diablo está en los detalles. Esta propuesta es inviable y causaría todo tipo de problemas a los administradores que asumen la muy difícil tarea de trabajar en las áreas difíciles. - DJSasso ( charla ) 15:25, 16 de marzo de 2021 (UTC)
- Oponerse según los datos de Hammersoft de de.wiki. Solo puedo respaldar una eliminación o reconfirmación más fácil con un RfA más fácil, que no es la realidad actual en en.wiki. Los requisitos de RfA son demasiado altos y cada día tenemos menos administradores para trabajar activamente en en.wiki. Carlosguitar (¿Sí, Ejecutor?) 11:17, 17 de marzo de 2021 (UTC)
- Aunque voté a favor, entiendo su argumento aquí. ¿Apoyaría / estaría interesado en redactar una propuesta de DRFA que vincularía el% de RFA a la inversa del porcentaje de DRFA? (IE: Si el porcentaje de DRFA para eliminar a un administrador fuera aproximadamente del 60%, el porcentaje de RFA para convertir a alguien en administrador se reduciría a aproximadamente el 60% con un rango discrecional de 55 a 65). Jackattack1597 ( charla ) 18:54, 17 de marzo 2021 (UTC)
- Yo apoyaría la reducción del porcentaje para el éxito de un RfA, no estoy seguro de si puedo ayudar a redactar. Pero sería interesante estudiar propuestas anteriores para reformar el RpA y entender por qué no llegamos a un consenso para rediseñar el RpA. Carlosguitar (¿Sí, Ejecutor?) 15:30, 18 de marzo de 2021 (UTC)
- ¿Cuál crees que sería el porcentaje ideal? 65% con discrecional de 55-65, o 60 con discrecional de 50-60, pero un piso duro en 50, ya que nadie debería convertirse en administrador sin el apoyo de la mayoría. (IE: si tiene un 49,8% de apoyo y un 50,2% se opone, falla automáticamente). Jackattack1597 ( hablar ) 00:32, 22 de marzo de 2021 (UTC)
- Yo apoyaría la reducción del porcentaje para el éxito de un RfA, no estoy seguro de si puedo ayudar a redactar. Pero sería interesante estudiar propuestas anteriores para reformar el RpA y entender por qué no llegamos a un consenso para rediseñar el RpA. Carlosguitar (¿Sí, Ejecutor?) 15:30, 18 de marzo de 2021 (UTC)
- Aunque voté a favor, entiendo su argumento aquí. ¿Apoyaría / estaría interesado en redactar una propuesta de DRFA que vincularía el% de RFA a la inversa del porcentaje de DRFA? (IE: Si el porcentaje de DRFA para eliminar a un administrador fuera aproximadamente del 60%, el porcentaje de RFA para convertir a alguien en administrador se reduciría a aproximadamente el 60% con un rango discrecional de 55 a 65). Jackattack1597 ( charla ) 18:54, 17 de marzo 2021 (UTC)
- Oponerse . Realmente no estoy seguro de qué problema está tratando de resolver, pero soy consciente de muchos problemas que esto crearía. Chicdat y Hammersoft han expresado bien mis propias opiniones en la sección "Oh administración" de la discusión a continuación. W a g ge r s TALK 15:56, 17 de marzo de 2021 (UTC)
- Oponerse . Si bien una política comunitaria de desysop de algún tipo es bienvenida, las numerosas preocupaciones (por ejemplo, el acoso de administradores en áreas contenciosas, umbrales, facilidad de uso) planteadas en esta sección muestran que no es así. Realmente, esto hubiera sido mejor como RFA para averiguar cuál es el consenso de la comunidad sobre los umbrales, características de tal política en lugar de lanzarse a proponer una. ---- Patar knight - chat / contribuciones 06:16, 18 de marzo de 2021 (UTC)
- ¿Te refieres a un RFC para averiguar el consenso de la comunidad? Muchos de ellos se han intentado antes, pero ninguna propuesta ha obtenido consenso, y esto parece que tampoco obtendrá consenso, a menos que el administrador de cierre diga que el 55% es suficiente consenso. Jackattack1597 ( charla ) 00:21, 22 de marzo de 2021 (UTC)
- Oposición más fuerte posible - Me opongo firmemente a esta y todas las propuestas desysop basadas en la comunidad. Claramente, esto no es lo que necesitamos ni siquiera lo que necesitamos. La situación en la que un administrador se vuelve problemático o se comporta de manera inapropiada suele ser muy rara y ocasional. Los procesos actuales que hay están completamente bien y no veo ni un 1% de necesidad para implementar propuestas como estas. Ya es muy difícil convertirse en administrador y ayudar a Wikipedia y lo que necesitamos son más administradores para que nunca haya escasez de administradores y una crisis de administrador en Wikipedia. Los administradores problemáticos pueden ser tratados caso por caso por Arbcom, tal como lo ha hecho normalmente. Los administradores son personas que deben atender llamadas difíciles en muchas situaciones que generalmente molestarán a alguien o al otro y este proceso solo les dará a esas personas municiones para usar contra ese administrador específico para que cumplan con su deber legítimo. Esto evitará que incluso más personas se conviertan en administradores, lo que eventualmente conducirá a una crisis administrativa en la Wikipedia en inglés en el futuro y dañará gravemente el proyecto y su futuro. Necesitamos crear un entorno más amigable y útil para todos que ayude a promover la armonía y mejorar la enciclopedia y no crear más campos de batalla, ya que ya hay más de los necesarios. Wikipedia realmente necesita más administradores, no menos. TheGeneralUser ( charla ) 19:49, 20 de marzo de 2021 (UTC)
- Fuerte oposición por Useight . Ya es difícil ser administrador, no los necesitamos cuidando la espalda cada vez que alguien los menciona en un hilo de ANI. Esta es una buena idea en el fondo, pero ciertos detalles que requieren que los administradores puedan ser desocupados son demasiado fáciles en mi opinión. - sportzpikachu mi charlacontribuciones 00:03, 24 de marzo de 2021 (UTC)
- Nota: relea la propuesta nuevamente, y hacer que el administrador discutido transcluya su propio desysop es demasiado humillante, considerando que cada sysop se ha ganado algunos enemigos aquí y allá y se pueden encontrar fácilmente 10 usuarios excon a quienes no les gusta un sysop, el 2 otros sysops pueden ser una tarea más difícil, pero tener al administrador discutido para que transcluya su propio desyop es demasiado. - sportzpikachumi charlacontribuciones 00:07, 24 de marzo de 2021 (UTC)
- @ Sportzpikachu : Personalmente, lo veo como un paso importante para asegurarme de que estén involucrados en el proceso y participen en él. De lo contrario, ¿dónde está el impulso para ellos de no simplemente ignorarlo con la esperanza de que desaparezca? Lo que parece que hicieron algunos administradores en la Wikipedia alemana cuando se aprobó algo similar. Creo que asegurarse de que haya participación de los administradores en su potencial proceso de desysop sería más importante que sus sentimientos personales de humillación en dicho proceso. Se sentirán humillados de todos modos si son tan sensibles al respecto. Entonces, ¿por qué hacer lo imposible? Más aún porque de ninguna manera es la misma consideración sobre los sentimientos de las personas por las personas que son enviadas a ANI. ¿Qué hace que los sentimientos de los administradores sean especiales? - Adamant1 ( conversación ) 01:27, 24 de marzo de 2021 (UTC)
- Nota: relea la propuesta nuevamente, y hacer que el administrador discutido transcluya su propio desysop es demasiado humillante, considerando que cada sysop se ha ganado algunos enemigos aquí y allá y se pueden encontrar fácilmente 10 usuarios excon a quienes no les gusta un sysop, el 2 otros sysops pueden ser una tarea más difícil, pero tener al administrador discutido para que transcluya su propio desyop es demasiado. - sportzpikachumi charlacontribuciones 00:07, 24 de marzo de 2021 (UTC)
- Oponerse Si bien se necesita una política de desysop, no me gusta el requisito de que una petición de desysop debe estar firmada por al menos tres administradores. No entiendo por qué es necesario tratar a varias clases de editores de manera diferente. Además, estoy un poco preocupado por lo que sucedería si una petición de desysop popular entre los usuarios habituales no obtuviera suficientes firmas de administrador; esto parece una buena receta para un drama innecesario. Spirit of Eagle ( charla ) 04:34, 26 de marzo de 2021 (UTC)
- Oponerse - Debería haber un proceso de desysop comunitario. Sin embargo, esto sería demasiado complicado y tendría demasiadas lagunas, según los opuestos anteriores. - La silla más cómoda 05:30, 29 de marzo de 2021 (UTC)
- Oponerse por usuario: el razonamiento de Chicdat en § Oh, administración , y porque ArbCom es una cosa que existe. TucanHolmes ( charla ) 20:08, 8 de abril de 2021 (UTC)
- Oponerse : Arbcom parece estar manejando esto decentemente en este momento. y según muchos de los más elocuentes que yo se opone arriba. - jc37 22:47, 8 de abril de 2021 (UTC)
- Oponerse : los sentimientos de Dennis Brown y otros me han llevado a creer que ArbCom actualmente puede procesar las solicitudes de desysop de manera eficiente. Solían tener mucho más en su plato en lo que respecta a los casos; Ese ya no es el caso. Kurtis (charla) 13:18, 9 de abril de 2021 (UTC)
Neutral
NeutralObviamente, esta es una propuesta de tipo "remoción por causa" y no creo que los procesos actuales sean incapaces de abordar rápida o eficazmente a los administradores que están realizando intencionalmente acciones en contra de los intereses de la comunidad. Son los administradores que inadvertidamente o involuntariamente realizan tales acciones, o que no realizan ninguna acción, los que constituyen un problema mayor. Tenemos políticas y procedimientos para abordar el mal comportamiento, pero no tenemos ninguno para abordar la retención continua de las herramientas por parte de administradores que no realizan tareas administrativas . Los administradores que obtuvieron el bit a principios de la década de 2000, cuando el estado de administrador estaba sujeto a muy poco examen y se las han arreglado solo para mantener el estado, están conservando sus sombreros no porque quieran mejorar el proyecto (evidentemente no lo están haciendo). El administrador que se porta mal se puede abordar a través de ANI, ArbCom, T&S (y posiblemente otros procesos que olvido), por lo que esta propuesta sería un cuarto proceso de este tipo. No hay procesos para la otra categoría. Debemos abordar la laguna en proceso antes de agregar otra al conjunto actual de procesos. Eggishorn (charla) (contrib) 22:31, 20 de febrero de 2021 (UTC)- En mi opinión, el único problema con los administradores que no realizan tareas administrativas es que no realizan tareas administrativas, no que conservan las herramientas. Deberíamos pensar en cómo hacer que dichos administradores realicen más tareas administrativas en lugar de intentar deshacerse de ellas. Nsk92 ( conversación ) 02:24, 21 de febrero de 2021 (UTC)
- Si bien es ideal convertir a los administradores inactivos en administradores activos, en algún momento nuestra varita mágica falla. Es un error pensar que un administrador inactivo que retiene las herramientas no es un problema. Es un principio básico de seguridad informática que nunca le das permiso a alguien que nunca lo usa. Digamos que hicimos un sorteo e hicimos, digamos, Nsk92 administrador, pero nunca usaron las herramientas. Entonces alguien comprometió la cuenta (Nsk92, ¡ te dije que no usaras '1234' como contraseña! Usa siempre 'Swordfish'. Nunca adivinarán esa). Podrían hacer mucho más daño del que podrían hacer si Nsk92 fuera una persona normal. usuario. - Guy Macon ( charla ) 05:30, 24 de febrero de 2021 (UTC)
- ¿Ha sido esto un problema importante? Sería un argumento para desagregar el conjunto de herramientas de administración. Brinde a los administradores las herramientas que necesitan y usan, elimine las que no necesitan o usan hasta que indiquen una necesidad e intención de usar, luego, si permanecen en buen estado, gire la broca para la herramienta mientras sigue siendo útil. · · · Peter Southwood (charla) : 04:49, 25 de febrero de 2021 (UTC)
- Si bien es ideal convertir a los administradores inactivos en administradores activos, en algún momento nuestra varita mágica falla. Es un error pensar que un administrador inactivo que retiene las herramientas no es un problema. Es un principio básico de seguridad informática que nunca le das permiso a alguien que nunca lo usa. Digamos que hicimos un sorteo e hicimos, digamos, Nsk92 administrador, pero nunca usaron las herramientas. Entonces alguien comprometió la cuenta (Nsk92, ¡ te dije que no usaras '1234' como contraseña! Usa siempre 'Swordfish'. Nunca adivinarán esa). Podrían hacer mucho más daño del que podrían hacer si Nsk92 fuera una persona normal. usuario. - Guy Macon ( charla ) 05:30, 24 de febrero de 2021 (UTC)
- En mi opinión, el único problema con los administradores que no realizan tareas administrativas es que no realizan tareas administrativas, no que conservan las herramientas. Deberíamos pensar en cómo hacer que dichos administradores realicen más tareas administrativas en lugar de intentar deshacerse de ellas. Nsk92 ( conversación ) 02:24, 21 de febrero de 2021 (UTC)
- Neutral Apoyaría esto, pero creo que el umbral mínimo de apoyo debería cambiarse del 60% de apoyo a la eliminación al 65% y las solicitudes de desysop entre el 65 y el 75% de apoyo deberían estar sujetas a la discreción de los burócratas para alinearlo con el trabajo de RfA 🌸 1.Ayana 🌸 ( charla ) 22:53, 20 de febrero de 2021 (UTC)
- Esto será difícil de implementar dado que los burócratas no fueron elegidos para tomar esta decisión. ¿Los burócratas actuales estarían felices de tomar tal decisión y, a su vez, la comunidad estaría feliz de que los burócratas lo hicieran? Nick ( charla ) 00:16, 21 de febrero de 2021 (UTC)
Neutral, inclinado a oponerse alas preocupaciones de Beeblebrox son profundamente convincentes, especialmente considerando el potencial de acoso. También me preocupa la tendencia humana hacia el sesgo de negatividad, es decir, la posibilidad de que más personas salgan con opiniones negativas que positivas incluso para administradores bastante poco polémicos, de modo que solo las personas con un número suficiente de amigos en lugares altos pueden pasar la prueba. desysop-RfA. Al mismo tiempo, existen preocupaciones reales sobre los administradores heredados en particular que dan como resultado una categoría "probablemente no debería arrastrar a ArbCom, probablemente no debería tener el bit". Todavía no voy a la columna opuesta, pero tengo preocupaciones reales. Vaticidalprophet ( charla ) 23:04, 20 de febrero de 2021 (UTC)- Moviéndose para oponerse. Vaticidalprophet ( charla ) 18:21, 22 de febrero de 2021 (UTC)
- Pasar a oponerse -
Neutral Lo primero que hice una vez que me convertí en administrador (2012) fue iniciar una propuesta similar WP: RAS , que falló. Coren (ex Arb entonces) fue de gran ayuda y fue coautor del intento. Varios otros también han fracasado desde entonces, hasta el punto de ser un tema perenne. En aquel entonces, Arb estaba mucho más ocupado de lo que está ahora, en términos de casos, y realmente no veo la necesidad, pero tengo la mente abierta si la idea se puede desarrollar correctamente. La parte inferior de la página RAS tiene algunos enlaces a intentos anteriores de 2012 y anteriores. Dennis Brown - 2 ¢ 23:55, 20 de febrero de 2021 (UTC) Neutral(movido para oponerse). Sé que Tony se decepcionará de que no lo apoye. Como Dennis arriba, lancé una propuesta similar hace poco menos de una década. Todavía queda trabajo por hacer y se necesita urgentemente una alternativa a Arbcom, pero no es así. He hecho una explicación más extensa en la sección de comentarios. Espero no haberle hecho perder el tiempo a nadie pidiéndoles que lo lean. Kudpung กุด ผึ้ง ( charla ) 07:23, 21 de febrero de 2021 (UTC)
Neutral, por ahora. (movido a oponerse) Siento que en este caso la preocupación sobre "qué pasaría si" está justificada y hay que pensar en las posibles consecuencias de implementar esta propuesta con más cuidado. También me gustaría escuchar una justificación más sólida de por qué la propuesta es necesaria en primer lugar. Un sentimiento generalizado de que los administradores deberían ser más responsables es, en mi opinión, insuficiente como justificación aquí. El proceso descrito en la propuesta es bastante brutal y arduo. El proceso puede ser necesario y podría apoyarlo, pero me gustaría escuchar una explicación más convincente de por qué es necesario (por ejemplo, que el proceso actual de arbcom desysop es seriamente deficiente y no elimina muchos administradores que deberían eliminarse). En general, puedo ver formas menos brutales y conflictivas de aumentar la responsabilidad administrativa, como instituir límites al período administrativo, con una RfA de reconfirmación obligatoria al final del período para aquellos que deseen retener el bit de sysop. Alguien en la columna de apoyo mencionó que la falta de un proceso de desysop comunitario hace que la gente sea más reacia a apoyar a los candidatos de la RpA. Un problema mucho mayor en RfA ahora es la falta de candidatos de RfA y la dificultad para reclutarlos. Por más estresantes y desagradables que puedan ser ahora los RfA, estos desysop RfA serán 100 veces más polémicos. Es probable que la perspectiva de enfrentarse potencialmente a un espectáculo público tan sangriento dificulte aún más la tarea de reclutar candidatos de RpA. También me preocupan las interacciones del proceso propuesto con el proceso de desysop de ArbCom existente. Es ingenuo suponer que el proceso de desysop de ArbCom simplemente continuará con su alegre camino, completamente intacto. Bien puede suceder que ArbCom se vuelva mucho más reacio a aceptar casos de desysop, prefiriendo / esperando que se lleve a cabo el desysop de la comunidad. ArbCom suele recurrir a la comunidad en busca de orientación sobre cuestiones importantes de política. En mi opinión, una versión exitosa de esta propuesta debe indicar explícitamente algo en el sentido de que los dos procesos son estrictamente independientes y complementarios y, además, que, en opinión de la comunidad, el ArbCom nunca debe considerar la falta de una comunidad previa. intento de desysop como razón para rechazar una solicitud de desysop. Es una pregunta más complicada saber qué se supone que sucederá si falla una RfA de desysop de la comunidad y luego se presenta un caso de desysop en ArbCom. Nsk92 ( conversación ) 11:53, 21 de febrero de 2021 (UTC)
- Esto será difícil de implementar dado que los burócratas no fueron elegidos para tomar esta decisión. ¿Los burócratas actuales estarían felices de tomar tal decisión y, a su vez, la comunidad estaría feliz de que los burócratas lo hicieran? Nick ( charla ) 00:16, 21 de febrero de 2021 (UTC)
Algo desgarrado aquí. Apoyo un procedimiento de desysop comunitario en principio, y me gustan los esquemas de este. Agradezco las medidas tomadas para prevenir la "turba aulladora", como otros la han llamado; pero estoy un poco preocupado por los detalles. Primero, ¿va a convertir cualquier discusión de AN sobre un administrador en una situación de "turba aullante"? Tal como están las cosas, todo lo que AN puede hacer es golpear a un administrador en los nudillos; ahora el consenso de una discusión de ANI es un paso necesario para un desysop; Me parece que las discusiones de AN se convertirán en una prueba mucho más difícil como consecuencia. No creo que sea necesariamente un defecto fatal, pero vale la pena pensarlo. En segundo lugar, entiendo que los tres administradores están destinados a actuar como un control de cordura, pero las disputas entre administradores no son infrecuentes, y no es improbable que para cualquier administrador de larga data, se puedan encontrar otros tres que piensan que deberían ser destituidos. . Los administradores también son humanos; tenemos peleas al igual que otros editores. Se espera que los árbitros se abstengan de casos en los que estén demasiado cerca de las partes; idealmente, me gustaría ver la misma protección aquí. Dicho esto, no estoy seguro de que sean razones suficientes para oponerme, así que me estacionaré aquí por el momento y leeré lo que mis colegas tienen que decir. Vanamonde ( Discusión ) 20:06, 21 de febrero de 2021 (UTC)Pasando a un soporte vacilante. Vanamonde ( Discusión ) 16:29, 2 de marzo de 2021 (UTC)- Tony , ¿hay alguna razón por la que la propuesta dice "que se cerró en los últimos 6 meses donde la declaración de cierre indica que hubo consenso" en lugar de simplemente "llegó a un consenso"? De ninguna manera creo que esto sea intencional, pero tal como está escrito, esto en realidad no requiere un consenso y, por lo tanto, abre la puerta a una mayor acritud. Lo vi solo porque estaba repasando la redacción en detalle para ver si mis inquietudes estaban justificadas y pensé que un cierre de administrador no involucrado ayudaría considerablemente. Sé que está demasiado avanzado para ese tipo de enmienda, pero creo que vale la pena señalarlo. Vanamonde ( Discusión ) 17:01, 22 de febrero de 2021 (UTC)
- Intentaba requerir un cierre formal para que la gente no pudiera simplemente señalar que un hilo era todo “¡mira! ¡Una queja!" Básicamente, tener un estándar objetivo aquí, que como mencioné en mi respuesta a Hut 8.5, veo que falta el proceso actual de ArbCom. TonyBallioni ( charla ) 17:05, 22 de febrero de 2021 (UTC)
- Tony , ¿hay alguna razón por la que la propuesta dice "que se cerró en los últimos 6 meses donde la declaración de cierre indica que hubo consenso" en lugar de simplemente "llegó a un consenso"? De ninguna manera creo que esto sea intencional, pero tal como está escrito, esto en realidad no requiere un consenso y, por lo tanto, abre la puerta a una mayor acritud. Lo vi solo porque estaba repasando la redacción en detalle para ver si mis inquietudes estaban justificadas y pensé que un cierre de administrador no involucrado ayudaría considerablemente. Sé que está demasiado avanzado para ese tipo de enmienda, pero creo que vale la pena señalarlo. Vanamonde ( Discusión ) 17:01, 22 de febrero de 2021 (UTC)
- Hágase a un lado . Sospecho de la propuesta, en gran parte según Vanamonde y Beeblebrox, pero no tengo la intención de evitar su adopción. Si bien veo la democracia directa como una ventaja, mi impresión de WP: DESYSOP2019 fue que la comunidad no está de acuerdo sobre si la democracia directa es positiva o negativa. Ese desacuerdo fundamental no se puede resolver estructuralmente, razón por la cual las propuestas, por muy bien que diseñemos las salvaguardas, fracasan repetidamente. Personalmente, no hice un seguimiento de la discusión de 2019 porque llegué a la conclusión de que cualquier solución que lograra el consenso no diferiría sustancialmente de ArbCom, por lo que también podríamos trabajar en la reforma de la estructura y la cultura de ArbCom. Eso no quiere decir que me oponga al recuerdo directo, todo lo contrario, pero significa que me gustaría obtener algún beneficio tangible más allá del recuerdo directo. Dicho de otra manera, el retiro directo es una brecha importante en la comunidad, y cerrar esa brecha requiere un objetivo superior que todos estamos de acuerdo en que sería ayudado por un RFC / U resucitado. Sin ese objetivo unificador más amplio, dudo que la comunidad pueda ponerse de acuerdo sobre un sistema de retiro por el bien de un sistema de retiro. Sería feliz si me equivocara en este caso. Quiero ver un sistema de recordatorio directo, pero ese deseo no es suficiente para que pase por alto los problemas reales que plantean los editores de la oposición. Hay suficientes preocupaciones con esta propuesta que no me siento cómodo apoyando, pero no tengo ningún deseo de bloquear la propuesta, así que me hago a un lado. - Wug · a · po · des 01:47, 22 de febrero de 2021 (UTC)
- No estoy seguro de lo que nos diría un juicio. Si tenemos una prueba, querría metas tangibles para que podamos medir el éxito al final de la misma en lugar de tener esta misma discusión nuevamente un año después. Sin una idea de lo que el juicio busca lograr, continuaré dejando que otros decidan el asunto. - Wug · a · po · des 23:26, 3 de marzo de 2021 (UTC)
- Me acabo de dar cuenta de que Vanamonde93 se movió para apoyar, y dado que cité su voto neutral en mi justificación, creo que debería explicar por qué ahora llego a una conclusión diferente y sigo manteniéndome al margen. Cuando me preocupa la falta de acuerdo de la comunidad, no es por ideas elevadas sobre el consenso o el respeto de las opiniones de las minorías: es práctico. Nuestros procesos solo funcionan cuando todos estamos de acuerdo en que beneficiarán a la enciclopedia a largo plazo (incluso si no estamos de acuerdo con el valor inmediato), pero fallan cuando una parte importante de la comunidad piensa que un curso será activamente dañino. Esto conduce a un sabotaje activo o al fracaso debido al trabajo retenido. Si un procedimiento de desysop pasa sin resolver el desacuerdo fundamental de la comunidad, creo que nos estamos preparando para el fracaso. Peor aún, si no tuvo éxito, servirá como evidencia contra cualquier propuesta futura, sin importar cuán bien concebida esté. No creo que debamos precisar todos los detalles correctamente, pero sí creo que tenemos que hacer que todos participen. Para dar un ejemplo personal, en la ciudad donde crecí teníamos una carretera que atravesaba un parque. El límite de velocidad era de 55 MPH y un camino para peatones estaba a solo unos metros de la carretera. Un día, un conductor perdió el enfoque por un segundo, se salió de la carretera y mató a un niño en el parque. Ninguno de nosotros quería que esto sucediera de nuevo. Por supuesto, la solución es obvia: no atraviese una carretera en un parque. Sin embargo, esa no es la solución que se le ocurrió a nuestro gobernador: redujo el límite de velocidad a 35 MPH, un avance lento en una ruta importante de transporte para la segunda área metropolitana más grande del estado. Por supuesto, muchos en la comunidad no estaban de acuerdo con esta solución, por lo que comenzaron a acelerar. A medida que pasa el tiempo, menos personas recuerdan la tragedia que provocó que se redujera el límite de velocidad en primer lugar, por lo que menos personas sienten la necesidad emocional de obedecerlo. Pero algunas personas todavía lo hacen. La disparidad de velocidad entre los automóviles que van a 55 y los que van a 35 aumenta las posibilidades de colisiones de vehículos. Los recursos necesarios para garantizar el cumplimiento llevan a la policía de otras áreas donde se necesitan y agotan los recursos de la ciudad. La gente todavía recorre 55 MPH por el parque. ¿Conseguimos hacer la ciudad más segura? Por supuesto, esta es una enciclopedia en línea, y esta decisión no es de vida o muerte (aunque con nuestro irregular historial de lidiar con el acoso, tampoco es trivial). No me opondré porque a mis ojos los beneficios son mejores que los problemas, pero si la comunidad no puede ponerse de acuerdo en eso, me preocupa que apoyar su adopción sea realmente contraproducente. Me gustaría un sistema de destitución, y estaría sujeto a este sistema de destitución, pero prefiero abstenerme hasta que los ideólogos puedan llegar a un acuerdo sobre un curso de acción. - Wug · a · po · des 01:06, 4 de marzo de 2021 (UTC)
- Hace mucho que estoy a favor de un proceso de eliminación del sistema impulsado por la comunidad, pero encuentro esta propuesta demasiado burocrática. Si creo que un administrador ha sido extremadamente descortés, por ejemplo, ¿por qué debería tener que revisar seis meses de archivos AN / ANI para desenterrar la suciedad sobre dicho administrador o comenzar un nuevo hilo solo para repetir la misma discusión en un lugar separado? - Calidum 02:43, 22 de febrero de 2021 (UTC)
- ¿Cómo es que un hilo de AN respalda una re-RfA demasiado burocrático? Buscar en los archivos de AN lleva uno o dos minutos. ~ Swarm ~ {picadura} 03:07, 22 de febrero de 2021 (UTC)
- Tener una discusión solo para tener una segunda (realmente una tercera si incluye el período de aprobación) parece ser el epítome de la burocracia. - Calidum 04:21, 22 de febrero de 2021 (UTC)
- También me gustaría agregar que hacer de AN / ANI un requisito previo para cualquier solicitud de desysop solo aumentará la mentalidad del campo de batalla que se ve allí, ya que cualquier intento de discutir un administrador podría verse como una RFA anterior a la inversa. Sin embargo, mis preocupaciones sobre esta propuesta van más allá. El grupo de usuarios que podría iniciar el proceso es demasiado restringido; 48 horas es un tiempo demasiado corto para el período de aprobación; exigir que cualquiera de los patrocinadores sea administrador es contrario a WP: NOBIGDEAL ; y los administradores deberían ser desysopted si más de la mitad de la comunidad ya no les confía sus herramientas, no el 60%. - Calidum 18:33, 22 de febrero de 2021 (UTC)
- ¿Qué "mentalidad de campo de batalla"? Estamos hablando de un consenso de la comunidad formal que concluye que un administrador ha violado los estándares de comportamiento del administrador, como un mero requisito previo para una discusión que puede solicitar respaldos, con el objetivo final de un RfA que solo requerirá un 40% de soporte. Esta propuesta requiere un apoyo comunitario abrumador, en todos los ámbitos. ~ Swarm ~ {picadura} 03:02, 23 de febrero de 2021 (UTC)
- ¿Cómo es que un hilo de AN respalda una re-RfA demasiado burocrático? Buscar en los archivos de AN lleva uno o dos minutos. ~ Swarm ~ {picadura} 03:07, 22 de febrero de 2021 (UTC)
- Neutro . Estoy a favor de un proceso de desysop comunitario, y no creo que este esté muy lejos de lo que necesitamos. Pero tengo suficientes reservas específicas que no puedo apoyarlo. Específicamente (en el orden de cómo se mencionan las cosas en la propuesta):
- Elimine el requisito de "al menos 25 ediciones en los últimos 6 meses". Como mencioné en un comentario anterior, priva de derechos a las personas que han sido acosadas hasta la jubilación y es demasiado fácil de engañar por los malos actores. Por lo que agrega complejidad sin valor.
- Deshazte de la dependencia de las declaraciones de cierre. Muchas discusiones nunca se cierran formalmente. Además, hacer que un cierre negativo sea un detonante de este proceso cambiará tanto la forma en que las personas cierran las discusiones como cuándo / cómo las personas plantean los problemas para la discusión. WP: ARBGUIDE dice :
También se espera que el usuario que realiza la presentación muestre que ya se ha intentado la resolución de disputas anterior
. Una redacción similar funcionaría aquí. - Deshágase de los "al menos tres administradores" necesarios para respaldar. Se supone que este es un proceso comunitario. Reglas como esta solo refuerzan la impresión de que los administradores tienen más peso en la formación de consenso de la comunidad.
- Este es un poco molesto, pero la ventana de aprobación de 48 horas es demasiado corta. Mucha gente lo extrañaría por completo porque no editan más de un par de veces a la semana.
- Realmente no me gusta el "deber" en
el administrador que se está discutiendo debe incluir la solicitud
. Eso parece cruel. Es como verse obligado a llevar su propia cruz a la crucifixión. Cámbielo a algo como "puede iniciar la discusión mediante la traducción de la solicitud en el momento que elija en los próximos 14 días". Es lo mismo, pero suena menos rencoroso. - Una vez que se inicia la discusión, debe ser responsabilidad del administrador colocar los avisos requeridos. Realmente desea asegurarse de que se haga correctamente. Lo último que desea es que un proceso como este se descarrile debido a un aviso defectuoso.
- Finalmente, me haré eco del sentimiento que otros han notado. La esencia de esto es que si no puedo lograr que el 40% de la comunidad esté de acuerdo en que todavía merezco un trapeador, debo haber estado haciendo cosas realmente malas y claramente necesito encontrar un nuevo pasatiempo. - RoySmith (charla) 17:32, 22 de febrero de 2021 (UTC)
- Inclinación neutral oponerse. El ítem # 3 "Una vez certificado, el administrador en discusión debe incluir la solicitud de desysop en Wikipedia: Solicitudes de administración dentro de los 14 días o renunciar como administrador". no es un comienzo para mí. Hay demasiada vergüenza proveniente de una cultura de cancelación en wikipedia tal como está (sin mencionar en línea en general).
Elimine elcambio n. ° 3 y es posible que obtenga mi apoyo. - Ched ( charla ) 19:31, 22 de febrero de 2021 (UTC) (editado después de leer el comentario de "The Earwig". - Ched ( charla ) 03:45, 25 de febrero de 2021 (UTC)- Ched , si se elimina el n. ° 3, ¿cómo funciona el proceso? ¿La solicitud siempre se transcluye con un 'crat después de un cierto período de tiempo (no le da al administrador flexibilidad sobre el tiempo de su RfDA), o todo el proceso se vuelve no vinculante (es decir, el administrador puede negarse a iniciar el RfDA y nada? sucede), o qué? - La Tijereta ⟨ charla ⟩ 01:02, 23 de Febrero 2021 (UTC)
- La tijereta , realmente no había estado pensando en ninguna línea de desysop, pero déjame considerarlo un poco e intentaré pensar en algo. - Ched ( charla ) 01:12, 23 de febrero de 2021 (UTC)
- Creo que no tiene por qué ser más prescriptivo que algo como "Un burócrata iniciará la solicitud de eliminación de privilegios administrativos en un plazo de 14 días, a menos que el administrador renuncie". El burócrata iniciador acordará el tiempo con el administrador. isaacl ( charla ) 01:20, 23 de febrero de 2021 (UTC)
- La tijereta , disculpas por no volver a esto antes. De acuerdo, cambiaría la redacción a algo como "El administrador puede transcluir y, si no se hace en 7 días, un crat puede hacerlo. Otro elemento que noté en el que podría hacer un pequeño ajuste es el elemento número 2:". .. respaldar la solicitud dentro de las 48 horas ... ". Probablemente cambiaría eso a 72 horas para tener en cuenta los fines de semana. Otro elemento que parece ser polémico para algunos usuarios: los" al menos 3 administradores "... me gustaría que se mantuviera. Por no decir que los administradores son mejores que cualquier otro editor (obviamente), pero más una cuestión de "pares" en la que las personas que han ocupado ese puesto entienden ese puesto en particular. De todos modos, gracias por ofrecerme una oportunidad para expresar mis pensamientos. Saludos y lo mejor. - Ched ( charla ) 03:42, 25 de febrero de 2021 (UTC)
- Ched , si se elimina el n. ° 3, ¿cómo funciona el proceso? ¿La solicitud siempre se transcluye con un 'crat después de un cierto período de tiempo (no le da al administrador flexibilidad sobre el tiempo de su RfDA), o todo el proceso se vuelve no vinculante (es decir, el administrador puede negarse a iniciar el RfDA y nada? sucede), o qué? - La Tijereta ⟨ charla ⟩ 01:02, 23 de Febrero 2021 (UTC)
- Definitivamente, los administradores neutrales deben rendir cuentas al usar las herramientas de administración (me he suscrito a Wikipedia: los administradores están abiertos a recordar desde que obtuve las herramientas), pero esto parece un conjunto de reglas demasiado complejo para iniciar el proceso. Preferiría algo más en la línea de 'N editores en buen estado' (donde N editores podría ser un número bastante bajo) + alguien razonable que verifique que es una solicitud sensata + un proceso de desysop que esté separado de RfA (ya que debería ser una revisión en lugar de una solicitud desde cero, pero luego, si el editor es desysop'd, entonces tendría que pasar por RfA para recuperar las herramientas). Pero ese es el ideal, se deben tomar medidas para mejorar el proceso de desysop (y sysop), de ahí este voto neutral. Gracias. Mike Peel ( charla ) 21:25, 22 de febrero de 2021 (UTC)
- Declare reservas : seré breve. RoySmith y Ched, por encima de mí, expresan numerosas y, en mi opinión, preocupaciones bien articuladas sobre la propuesta. Deseo reiterar las preocupaciones con respecto a requerir que un administrador inicie personalmente una discusión sobre su eliminación, el umbral del 60% (que considero que es una barrera demasiado baja para permitir la eliminación de cualquier administrador), el corto período de tiempo y la cuestión de respaldo del administrador (especialmente dadas las disputas de larga data). Todo esto es suficiente para que yo retenga un voto de apoyo, pero, a la inversa, mis opiniones y circunstancias personales simplemente no son suficientes para convencerme de que no esté de acuerdo con esta propuesta. - Javert2113 ( Siarad. | ¤ ) 22:08, 22 de febrero de 2021 (UTC)
- Neutral (movido desde el soporte): me gustaría ver un período de prueba de 12 meses (el factor principal para pasar del soporte) y una regla que restrinja la frecuencia con la que alguien puede iniciar este proceso contra la misma persona. - Hablar de las rododendritas \\ 03:38, 23 de febrero de 2021 (UTC)
- Neutral : hay algunas preocupaciones válidas sobre esto y creo que la sugerencia de Rhododendrites de ejecutar esto a través de un período de prueba con una regla sobre la frecuencia con la que puede iniciarlo la misma persona. Mi preocupación es que las reglas pueden facilitar la creación de brigadas, particularmente cuando tiene un administrador que interviene con temas controvertidos. Sin embargo, no podemos predecir con total precisión cómo se desarrollará esto, por lo que es necesario un período de prueba para buscar cualquier problema que surja. También creo que cualquier caso que surja debería discutirse a fondo después para determinar si el sistema funcionó como debería, si no lo hizo, y qué puede o debería ajustarse. No creo que esto deba implementarse permanentemente sin probarlo primero. ReaderofthePack (anteriormente Tokyogirl79) (。◕‿◕。) 03:52, 25 de febrero de 2021 (UTC)
- Condicional Neutral (¡un voto extraño! Lo reconozco). En efecto, si esto se cierra como una prueba con una extinción automática (estoy abierto a cualquier tiempo razonable / # de usos), entonces soy neutral; de lo contrario, debería ser considerado un firme opositor . Los aspectos positivos son claros. Los aspectos negativos se han manifestado varias veces, y las personas dicen "podemos mejorar a medida que avanzamos" y demás, pero ninguno de ellos parece decir qué debemos hacer con cualquiera que se quede atrapado en los engranajes del proceso. Digamos que pensamos que un administrador fue un tanto (no atroz) despojado injustamente. Pasar un RfA es más difícil que ser eliminado, por lo que no podemos corregirlo de esa manera. Tal vez tengamos un método mejorado y ese editor no tenga suerte. Debo señalar que el 60% para eliminar la barrera parece justo. Nosebagbear ( charla ) 12:15, 25 de febrero de 2021 (UTC)
- Neutral. Me gustaría apoyar, porque estoy a favor de un proceso de desysop basado en la comunidad, distinto de ArbCom. Sin embargo, me preocupa el umbral de esta propuesta para conservar la administración. Me gustaría que fuera lo mismo que para RfA, es decir, consenso para que el editor sea un administrador (en la práctica, 65-75% de soporte para la administración). Pero en la presente propuesta, el umbral es del 60% para la eliminación , lo que significa que conservar la administración solo requiere un 40% de apoyo. Tony sostiene que "nuestro proceso normalmente requiere consenso para sancionar, no consenso para mantener el status quo". Pero la administración es un privilegio, no un derecho. Cada administrador era originalmente un usuario regular, por lo que revocar la administración es restaurar el estado que tenía originalmente. Por esa razón, preferiría que se requiera un consenso para mantenerlo, en lugar de perderlo. Tim Smith ( charla ) 04:53, 28 de febrero de 2021 (UTC)
Neutral¿Alguien ha considerado el proceso de recuperación como adoptado en otros wikis? p.ej. Usuario: ToBeFree / recordar : quiero decir, el WP alemán no está exactamente en el medio de la nada y, aunque no sé si hay problemas de abuso con eso, (pregunta que @ ToBeFree : podría responder), pero ese proceso parece menos complicado / burocrático (al eliminar el requisito de WP: Dramaboard ) que la propuesta actual. Además, el requisito de un mayor número de usuarios parece hacerlo más sólido que la propuesta actual. RandomCanadian ( charla / contribuciones ) 21:08, 1 de marzo de 2021 (UTC)- Después de la consideración, y con los problemas planteados en la charla y por otros, pasar a oponerse. RandomCanadian ( charla / contribuciones ) 03:13, 3 de marzo de 2021 (UTC)
- Me gusta el proceso ya que, en mi opinión, conduce a retiros razonables, y estos retiros conducen tanto a la reconfirmación como a la resignación y al rechazo, dependiendo de si la comunidad aún mantiene su confianza. Ejemplos recientes son de: Wikipedia: Adminkandidaturen / Björn_Hagemann_ (Wieder-Wahl) (rechazo), de: Special: Diff / 207544035 (renuncia después de las renovaciones de votos de desysop escrutadas, diffs , block , result ) y de: Wikipedia: Adminkandidaturen / LexICon_ (2021 ) (reconfirmación). Las estadísticas se pueden encontrar en de: Wikipedia: Adminwiederwahl / Kurzstatistik . Haciendo ping a Hammersoft, quien probablemente no esté de acuerdo con que el proceso sea agradable, desde un punto de vista diferente. Nota: Contrariamente a la propuesta actual de enwiki, el enfoque dewiki también se usa para tratar con administradores inactivos que hacen algunas ediciones por año para retener las herramientas, eso no funciona allí. ~ ToBeFree ( hablar ) 21:24, 1 de marzo de 2021 (UTC)
- Según recuerdo, cuando de.wiki instituyó su proceso, perdieron 1/3 de sus administradores en poco tiempo. Ya estamos casi en un punto de inflexión en este proyecto, en términos de atrasos y nuestra capacidad para mantener el proyecto con los administradores que tenemos actualmente. Hay discusiones frecuentes en WP: RFA sobre qué hacer al respecto, cómo conseguir más administradores, etc. Si instituimos este procedimiento para la eliminación de la administración, estamos haciendo exactamente lo contrario. En el peor de los casos, estamos destruyendo el proyecto. Pero, dado que nadie se ha molestado en hacer la tarea que debe sustentar un cambio tan importante en la política, no tenemos idea de adónde nos llevará esto. - Hammersoft ( charla ) 22:15, 1 de marzo de 2021 (UTC)
- (34 + 21) / 314 ≈ 16% para un proceso puramente basado en votos (no hay determinación de "consenso" en las RfA de dewiki, se requieren 66% de votos para mantener ) que permite la renuncia sin especificar ninguna razón. La propuesta tiene salvaguardias adicionales. ~ ToBeFree ( hablar ) 22:48, 1 de marzo de 2021 (UTC)
- Según recuerdo, cuando de.wiki instituyó su proceso, perdieron 1/3 de sus administradores en poco tiempo. Ya estamos casi en un punto de inflexión en este proyecto, en términos de atrasos y nuestra capacidad para mantener el proyecto con los administradores que tenemos actualmente. Hay discusiones frecuentes en WP: RFA sobre qué hacer al respecto, cómo conseguir más administradores, etc. Si instituimos este procedimiento para la eliminación de la administración, estamos haciendo exactamente lo contrario. En el peor de los casos, estamos destruyendo el proyecto. Pero, dado que nadie se ha molestado en hacer la tarea que debe sustentar un cambio tan importante en la política, no tenemos idea de adónde nos llevará esto. - Hammersoft ( charla ) 22:15, 1 de marzo de 2021 (UTC)
- Lo que. InedibleHulk ( charla ) 18:31, 7 de marzo de 2021 (UTC)
- El comentario anterior debe ser eliminado, ya que no agrega ningún valor a esta discusión. Jay Jay ¿Qué hice? 02:05, 10 de marzo de 2021 (UTC)
Neutral(movido a oponerse) (opuesto antes, reconsiderado, retrocediendo para oponerse). Desearía poder apoyar, pero los opositores hacen puntos sobresalientes. Creo que desysop debería estar separado de ArbCom, o al menos traerse con un conjunto de procedimientos diferente (no más bajo, solo más específico) que difiera de un caso ordinario de ArbCom de dos meses del infierno, pero la propuesta anterior es demasiado fácil y estoy de acuerdo con algunos de los que se oponen a que simplemente abriría la puerta al acoso y la intimidación de los mejores administradores, los que toman decisiones difíciles y se vuelven severos con la multitud de IDONTGETIT. Extendido confirmado es un estándar demasiado fácil de alcanzar para un calcetín, y es fácil reunir 10 títeres de carne en algunos de los tableros anti-Wikipedia que existen. Montanabw (charla) 17:06, 10 de marzo de 2021 (UTC)
- El comentario anterior debe ser eliminado, ya que no agrega ningún valor a esta discusión. Jay Jay ¿Qué hice? 02:05, 10 de marzo de 2021 (UTC)
- Neutro . Creo que la comunidad necesita una forma de solicitar la desocupación, pero no estoy seguro de que el detalle esté aquí. Como administrador, me he encontrado con algunos otros administradores que han tenido problemas, ya sea que muestran una actitud de "Yo sé más" y no se adhieren a las políticas, abusan de la eliminación rápida o simplemente son desagradables y desagradables para otros editores. pero son una minoría. No estoy convencido de si esta propuesta se ocuparía de aquellos, pero intentar algo para ver si aborda el problema y modificarlo a medida que avanzamos puede valer la pena intentarlo. - Michig ( charla ) 19:27, 10 de marzo de 2021 (UTC)
- No estoy lo suficientemente convencido para apoyar, pero no se oponga - DannyS712 ( hablar ) 22:02, 29 de marzo de 2021 (UTC)
- Pasando a neutral . No estoy convencido de que recordar hubiera ayudado con las situaciones de RexxS o Carlossuarez46; hasta que esté más claro en qué situaciones ayudará, ya no apoyaré esto. Tener a cientos de personas votando por RexxS habría sido más incendiario, y dejar que ARBCOM se encargue de ello es más educado que votar por un editor que parece estar jubilándose. Usuario: 力(power ~ enwiki, π , ν ) 01:50, 31 de marzo de 2021 (UTC)
Comentarios
Se puede decir que está implícito, pero las palabras "o renunciar como administrador" deben estar en el punto 3. Hay Spiel Checkers 20:59, 20 de febrero de 2021 (UTC)
- Quise agregar eso yo mismo. Adicional. TonyBallioni ( charla ) 21:01, 20 de febrero de 2021 (UTC)
- Gracias. Ϣere Spiel Checkers 11:41, 21 de febrero de 2021 (UTC)
- ¿Por qué el administrador que se está discutiendo debe incluir la solicitud de desysop? Ese debería ser el 'crat en mi humilde opinión. Muñeco de nieve gigante 21:06, 20 de febrero de 2021 (UTC)
- Eso se agregó para dar a las personas la flexibilidad de cuándo quieren presentar su caso si están impugnando el desysop. Estoy seguro de que podrían hacerlo por ellos y a nadie le importaría. El objetivo no es obligarlos a entablar una discusión cuando no tienen tiempo para responder debido a compromisos del mundo real. Estoy abierto a cambios en el lenguaje en torno a eso, pero parecía ser la forma más fácil de abordar las críticas que se han planteado anteriormente durante las propuestas de reforma desysop. TonyBallioni ( charla ) 21:10, 20 de febrero de 2021 (UTC)
- ¿Por qué el 60%? ¿Por qué no el 50%? ¿Por qué no el 75%? Por qué no WP: NOTAVOTE . Muñeco de nieve gigante 21:06, 20 de febrero de 2021 (UTC)
- RFA tiene umbrales numéricos, al igual que otros proyectos, y esta parece ser la norma para este tipo de discusiones. Nuestro proceso generalmente requiere consenso para sancionar, no consenso para mantener el status quo. El 60% me parece un número que está en línea con este concepto, pero tampoco es imposible de alcanzar, lo que podría decirse que sería el 75% en la mayoría de los casos. TonyBallioni ( charla ) 21:10, 20 de febrero de 2021 (UTC)
- ¿No debería entonces el umbral ser el mismo que para una RFA exitosa? Parece extraño que necesite menos apoyo para remover a alguien que para nombrarlo en primer lugar. En lugar de poner un porcentaje estricto, ¿qué tal simplemente señalar el que ya está en su lugar para RFA? Además, RFA tiene umbrales, pero no son estrictos. Puede suspender una RFA con un 70% y aprobarla con un 65%. DeRFA debería tener reglas similares. Saludos y por qué 09:36, 21 de febrero de 2021 (UTC)
- RFA tiene umbrales numéricos, al igual que otros proyectos, y esta parece ser la norma para este tipo de discusiones. Nuestro proceso generalmente requiere consenso para sancionar, no consenso para mantener el status quo. El 60% me parece un número que está en línea con este concepto, pero tampoco es imposible de alcanzar, lo que podría decirse que sería el 75% en la mayoría de los casos. TonyBallioni ( charla ) 21:10, 20 de febrero de 2021 (UTC)
- Estoy indeciso sobre la propuesta general, pero dos cuestiones técnicas:
- ¿En qué foro se debe presentar la solicitud de desysop?
- ¿Por qué 48 horas? Eso parece que podría ser incómodo durante los fines de semana y días festivos; parece que la masa crítica de personas debe reunirse antes de presentar el papeleo, lo que puede o no ser la intención.
- power ~ enwiki ( π , ν ) 21:14, 20 de febrero de 2021 (UTC)
- Re: 1, la forma en que me lo imagino sería algo parecido a Wikipedia: Solicitudes de desysop / Example . Esto estaría vinculado a BN, AN y WT: RFA (como este RfC). Contendría la queja y una sección de respaldo, y una sección para una respuesta.
- Re: 2, parecía una cantidad de tiempo razonable para permitir respaldos sin ser algo que se quede para siempre. Estaría abierto a algo así como 72 horas para que siempre tuviera un día laborable, y de hecho debatí eso. Terminé con 48 porque pensé que si se presenta una solicitud frívola, realmente no la necesita allí durante 3 días. Si se presenta una solicitud seria donde la comunidad está de acuerdo, debería poder obtener 10 comentarios que la respalden dentro de las 48 horas (consulte: la mayoría de los hilos ANI o ARC). Tampoco hay nada que impida que se vuelva a presentar si alguien no cumple con el límite y lo haría. He respaldado para llegar a 10. Dicho esto, estoy muy abierto a que se ajuste ese número. TonyBallioni ( charla ) 21:19, 20 de febrero de 2021 (UTC)
- OhKayeSierra , abordaré tu punto aquí, ya que supongo que otros podrían tenerlo. Actualmente, requiere el respaldo de 6 a 8 administradores / funcionarios (es decir, arbs) para iniciar una solicitud de desysop. Lo que me preocupaba trataba específicamente de cuestiones derivadas de las disputas nacionalistas. Puedo pensar en algunos administradores en los que probablemente podría encontrar 10 editores en el otro lado de una disputa étnica para respaldar una solicitud, pero no pudo encontrar un solo administrador que lo hiciera. Estoy de acuerdo en que no es perfecto, pero mientras sigamos teniendo cosas como India-Pakistán, el conflicto árabe-israelí, Armenia-Azerbaiyán, esto será un problema. La otra opción para combatir eso sería aumentar los requisitos de respaldo de 10, pero eso podría ser una carga demasiado grande para eliminar. Esto se sintió como el compromiso más fácil sobre el tema. TonyBallioni ( charla ) 21:33, 20 de febrero de 2021 (UTC)
- Dos preguntas sobre la etapa de aprobación: (1) ¿Dónde será apropiado vincular la solicitud de desysop durante esta etapa? (Queremos lograr un equilibrio entre permitir el escrutinio y mantenerlo totalmente oculto). (2) ¿Qué se debe esperar que hagan las personas que se oponen al dedysop durante esta etapa? Simplemente, siéntese, ya que es solo para reunir apoyos afirmativos, o comentar su oposición, lo que parece que haría que el escenario sea una versión un poco menos publicitada del RfC real. Además, si el objetivo es permitir que el encuestado elija el momento del RfC, los comentarios después de que la aprobación haya tenido éxito, pero antes de que comience el RfC, deben rechazarse. {{u | Sdkb }} charla 21:48, 20 de febrero de 2021 (UTC)
- La propuesta establece AN, BN y WT: RFA durante la fase de aprobación. Mis pensamientos estarían allí, y si hay un ANI activo o similar, también creo que sería razonable vincularlo como parte de ese hilo. En mi opinión, se aplicarían las reglas estándar de escrutinio. En 2, creo que es razonable tener una sección de comentarios debajo de los respaldos para que la gente pueda debatir. También acepto que una vez certificado no debería haber comentarios hasta la transclusión. Básicamente, necesitaríamos crear una plantilla siguiendo las líneas de las plantillas RfA o AE, pero estos son detalles en la implementación que se pueden resolver una vez que obtengamos una política. TonyBallioni ( charla ) 21:54, 20 de febrero de 2021 (UTC)
- Ah, gracias por aclarar sobre (1); Me di la vuelta un poco. Tendremos que encontrar buenos atajos, ya que WP: RFD ya está en uso. {{u | Sdkb }} charla 22:31, 20 de febrero de 2021 (UTC)
- La propuesta establece AN, BN y WT: RFA durante la fase de aprobación. Mis pensamientos estarían allí, y si hay un ANI activo o similar, también creo que sería razonable vincularlo como parte de ese hilo. En mi opinión, se aplicarían las reglas estándar de escrutinio. En 2, creo que es razonable tener una sección de comentarios debajo de los respaldos para que la gente pueda debatir. También acepto que una vez certificado no debería haber comentarios hasta la transclusión. Básicamente, necesitaríamos crear una plantilla siguiendo las líneas de las plantillas RfA o AE, pero estos son detalles en la implementación que se pueden resolver una vez que obtengamos una política. TonyBallioni ( charla ) 21:54, 20 de febrero de 2021 (UTC)
- En el pasado, he abogado fuertemente por un proceso de desysop basado en la comunidad, y yo mismo he escrito una propuesta de este tipo, y he sido un "halcón" cuando se trata de eliminar administradores problemáticos. Sin embargo, no puedo apoyar esta propuesta en su forma actual. Un solo hilo en el que se concluye que un administrador cometió un error es simplemente un umbral demasiado bajo. Hay muy pocas cosas que un administrador puede hacer que sean tan malas que deberían tener herramientas de administración en una sola instancia, y en esos raros casos, arbcom está realmente equipado para actuar considerablemente más rápido que este proceso. En resumen, siento que, como está estructurado actualmente, esto todavía está demasiado abierto a los juegos y al acoso. Es posible que las solicitudes frívolas no sigan adelante, pero después de suficientes de ellas, la gente comenzará a argumentar que "ha habido cinco solicitudes para desysop, debe estar haciendo algo mal" y perderemos buenos administradores. Beeblebrox ( charla ) 21:58, 20 de febrero de 2021 (UTC)
- Es "un solo hilo" que se requiere antes de abrir un proceso en el que muchos usuarios deben respaldar el procedimiento antes de que se enumere para la votación. Son bastantes obstáculos que superar, incluso antes de la RFA. ~ Amory ( u • t • c ) 22:04, 20 de febrero de 2021 (UTC)
- Mi preocupación es que terminará usándose para acosar a los administradores, incluso si los casos no avanzan. La gente simplemente lo usará para más disputas, incluso cuando saben que no obtendrán un desysop. Beeblebrox ( charla ) 22:07, 20 de febrero de 2021 (UTC)
- Tuve muchos conflictos de edición, pero Amory capturó lo que iba a decir de manera más sucinta. También lo expresé como "inapropiadamente" para que no fuera solo un error, es decir, el consenso de la comunidad para desbloquear a alguien no es lo mismo que decir que fue una acción inapropiada que el administrador bloqueara. Curiosamente, diseñé el procedimiento para no acosar a los administradores. Creo que una de las cosas que ha cambiado en los últimos 3 años es que las solicitudes de casos se han vuelto más fáciles de jugar y usar para acosar a las personas también, y sentí que esto sería una mejora en la equidad para ambos lados de la disputa. Beeblebrox , algo que consideré agregar fue permitir que el crat lo elimine si la certificación falla si se determina que se estaba utilizando para acosar a los administradores o era frívolo porque realmente comparto muchas de sus preocupaciones y esta propuesta fue diseñada en parte para arreglar algunos de esos defectos en el sistema ArbCom actual y ambos son menos propensos al acoso y más fáciles de iniciar si es necesario. TonyBallioni ( charla ) 22:12, 20 de febrero de 2021 (UTC)
- Las personas ya pueden acosar a un administrador presentando solicitudes de arbitraje. El comité rechazó alrededor de seis solicitudes de casos el año pasado [1] [2] [3] [4] [5] [6] . No creo que haya más solicitudes de desysop certificadas que casos de conducta administrativa aceptados. AGK ■ 10:08, 24 de febrero de 2021 (UTC)
- Tuve muchos conflictos de edición, pero Amory capturó lo que iba a decir de manera más sucinta. También lo expresé como "inapropiadamente" para que no fuera solo un error, es decir, el consenso de la comunidad para desbloquear a alguien no es lo mismo que decir que fue una acción inapropiada que el administrador bloqueara. Curiosamente, diseñé el procedimiento para no acosar a los administradores. Creo que una de las cosas que ha cambiado en los últimos 3 años es que las solicitudes de casos se han vuelto más fáciles de jugar y usar para acosar a las personas también, y sentí que esto sería una mejora en la equidad para ambos lados de la disputa. Beeblebrox , algo que consideré agregar fue permitir que el crat lo elimine si la certificación falla si se determina que se estaba utilizando para acosar a los administradores o era frívolo porque realmente comparto muchas de sus preocupaciones y esta propuesta fue diseñada en parte para arreglar algunos de esos defectos en el sistema ArbCom actual y ambos son menos propensos al acoso y más fáciles de iniciar si es necesario. TonyBallioni ( charla ) 22:12, 20 de febrero de 2021 (UTC)
- Mi preocupación es que terminará usándose para acosar a los administradores, incluso si los casos no avanzan. La gente simplemente lo usará para más disputas, incluso cuando saben que no obtendrán un desysop. Beeblebrox ( charla ) 22:07, 20 de febrero de 2021 (UTC)
- Es "un solo hilo" que se requiere antes de abrir un proceso en el que muchos usuarios deben respaldar el procedimiento antes de que se enumere para la votación. Son bastantes obstáculos que superar, incluso antes de la RFA. ~ Amory ( u • t • c ) 22:04, 20 de febrero de 2021 (UTC)
- Pregunta: Si se implementa este proceso, ¿está destinado a reemplazar el proceso de desysop de ArbCom? Si no es así, ¿cómo se espera que interactúen los dos procesos entre sí? Nsk92 ( conversación ) 22:09, 20 de febrero de 2021 (UTC)
- @ Nsk92 : ArbCom tiene la capacidad de imponer sanciones vinculantes, y un desysop es una de ellas, por lo que esto no eliminaría eso (no creo que pueda sin enmendar ARBPOL, que lleva una eternidad). Veo aquí como un beneficio que Proporciona orientación sobre lo que la comunidad quiere ver antes de los desastres. Como ejemplo, si hubo un problema hace 10 meses y ahora está en una disputa con un administrador, no podría argumentar a favor de un desysop bajo esto sin obtener un consenso en AN de que había un problema actual con la conducta. Con el sistema actual, podría ejecutar ArbCom y, según el tema, podrían aceptarlo. Creo que, de forma indirecta, esto ayudaría a que el proceso existente también fuera más justo. TonyBallioni ( charla ) 22:16, 20 de febrero de 2021 (UTC)
- Mmm. Un cierto grado de preocupación que tengo es que si se implementa este proceso de desysop comunitario, ArbCom será mucho más reacio a actuar sobre las solicitudes de desysop. De hecho, estoy seguro de que esto sucederá. En algunos casos eso puede ser algo bueno, pero es necesario pensar en las posibles consecuencias ahora. Hay situaciones en las que ArbCom puede, y lo hace actualmente, moverse rápidamente para realizar un desysop. El proceso descrito en este RfC es bastante largo. Creo que es importante no solo diseñar un proceso de desysop comunitario, sino también incluir algún lenguaje que aborde expresamente la interacción con el proceso de desysop de Arbcom. Nsk92 ( conversación ) 22:32, 20 de febrero de 2021 (UTC)
- Mi preocupación personal es si los estándares para los casos de ArbCom sobre asuntos de administradores se vuelven más altos como resultado de esto. Idealmente, esta propuesta es simplemente una ruta alternativa, y nada sobre el proceso actual de ArbCom, o los requisitos que los arbs esperan para los casos, cambiará en comparación con lo que sean ahora. Cualquier editor debe tener la libertad de elegir qué proceso quiere usar, en mi opinión. Existen algunas ventajas del escrutinio del Comité, especialmente para controversias multifacéticas. ProcrastinationReader ( charla ) 23:43, 20 de febrero de 2021 (UTC)
- Mmm. Un cierto grado de preocupación que tengo es que si se implementa este proceso de desysop comunitario, ArbCom será mucho más reacio a actuar sobre las solicitudes de desysop. De hecho, estoy seguro de que esto sucederá. En algunos casos eso puede ser algo bueno, pero es necesario pensar en las posibles consecuencias ahora. Hay situaciones en las que ArbCom puede, y lo hace actualmente, moverse rápidamente para realizar un desysop. El proceso descrito en este RfC es bastante largo. Creo que es importante no solo diseñar un proceso de desysop comunitario, sino también incluir algún lenguaje que aborde expresamente la interacción con el proceso de desysop de Arbcom. Nsk92 ( conversación ) 22:32, 20 de febrero de 2021 (UTC)
- ¿Se puede aplicar este proceso a los burócratas, chequeadores, supervisores o miembros de ArbCom actuales? ¿Solo eliminará la bandera del operador del sistema? - GZWDer ( hablar ) 22:19, 20 de febrero de 2021 (UTC)
- Como se propuso, creo que se aplicará solo al indicador del operador del sistema. Cualquier administrador que también esté en uno de los grupos anteriores aún estaría sujeto a esta propuesta con respecto a sus acciones de administrador. No creo que sea posible un proceso comunitario con respecto a las acciones de control o supervisión de usuarios, dado que, por su naturaleza, la mayoría de los miembros de la comunidad no pueden examinar los detalles de esas acciones. El abuso de estos permisos puede ser investigado por el comité de arbitraje y la comisión del defensor del pueblo . Thryduulf ( conversación ) 22:26, 20 de febrero de 2021 (UTC)
- Creo que los titulares de CU / OS deberían ser inmunes al proceso (deben ir a ARBCOM debido al potencial de información privada), o esos permisos deberían eliminarse automáticamente también mediante este proceso. La bandera de burócrata debería desaparecer al igual que la bandera de administrador. power ~ enwiki ( π , ν ) 01:45, 21 de febrero de 2021 (UTC)
- @ Power ~ enwiki : Como alguien con el derecho de Supervisión, diría que si el problema está relacionado con mis acciones con Supervisión, entonces la queja debe dirigirse a arbcom para que la investigue. Si el problema está relacionado con el trabajo administrativo normal (por ejemplo, cerrar XfD), este proceso sería apropiado. Si la comunidad me rechazara, esperaría que ArbCom sea notificado oficialmente (por el idiota que cambió la parte) y que investigue mi idoneidad continua para el papel. Tendría que ser un conjunto extraordinario de circunstancias para que ellos dictaran que yo estaba, especialmente como una cuestión práctica, la supervisión implica la eliminación regular de páginas / revisiones y la visualización de páginas / revisiones eliminadas. Thryduulf ( charla ) 02:46, 21 de febrero de 2021 (UTC)
- Creo que aquí solo se debe abordar el administrador de interfaz y burócrata (ya que ArbCom puede manejar CU / OS). Y probablemente deberían hacerlo, al menos para los burócratas, ya que solo los administradores pueden eliminarlo. Podríamos terminar con una situación en la que la comunidad haya abandonado, pero ArbCom no eliminará al burócrata ni a los administradores, ya que la política no lo establece explícitamente y los administradores no actuarán fuera de la política explícita, especialmente no en enwiki. - Rs chen 7754 03:06, 21 de febrero de 2021 (UTC)
- @ Power ~ enwiki : Como alguien con el derecho de Supervisión, diría que si el problema está relacionado con mis acciones con Supervisión, entonces la queja debe dirigirse a arbcom para que la investigue. Si el problema está relacionado con el trabajo administrativo normal (por ejemplo, cerrar XfD), este proceso sería apropiado. Si la comunidad me rechazara, esperaría que ArbCom sea notificado oficialmente (por el idiota que cambió la parte) y que investigue mi idoneidad continua para el papel. Tendría que ser un conjunto extraordinario de circunstancias para que ellos dictaran que yo estaba, especialmente como una cuestión práctica, la supervisión implica la eliminación regular de páginas / revisiones y la visualización de páginas / revisiones eliminadas. Thryduulf ( charla ) 02:46, 21 de febrero de 2021 (UTC)
- Tengo preocupaciones menores con respecto a los usuarios inactivos. El primero sería fácil de resolver agregando un requisito de que no se puede abrir ninguna solicitud de desysop a menos que el administrador haya realizado al menos una edición en los últimos 5 días. El otro es para editores que no están disponibles durante el período de RFA. Creo que la forma de manejar esto sería algo como permitir que los administradores declaren esto (públicamente o en privado a arcom o un crat) que no estarán disponibles para dar una atención de RFA dentro de los próximos 14 días. Dichos administradores no podrían realizar ninguna acción administrativa (¿o realizar modificaciones importantes?) Hasta que se encuentren en RFA, con la eliminación de la penalización por no cumplir. Si un editor pensó que estaría disponible para RFA pero resulta que no es así, entonces crats debería tener la discreción de pausar la RFA en la solicitud de ese administrador hasta que regresen. Thryduulf ( conversación ) 22:20, 20 de febrero de 2021 (UTC)
- En el último párrafo, debería
eliminar con éxito
serexitoso y eliminar
? XOR'easter ( charla ) 22:29, 20 de febrero de 2021 (UTC)- Hecho TonyBallioni ( charla ) 22:35, 20 de febrero de 2021 (UTC)
- @ TonyBallioni : Agregue una declaración breve y neutral directamente después de la etiqueta. Con más de 2600 bytes, la declaración existente anterior (desde la etiqueta hasta la primera marca de tiempo) es demasiado larga para que la maneje Legobot ( talk · contribs ), por lo que no se muestra correctamente en Wikipedia: Solicitudes de comentarios / políticas de Wikipedia y directrices . - Red rose64 🌹 ( hablar ) 22:29, 20 de febrero de 2021 (UTC)
{{rfc}}
{{rfc}}
- Me parece bien en esa página, y así es como doy formato a cada política importante que he propuesto. Si hay una solución fácil, no dudes en hacerlo, pero no cambies mi escritura. La presentación en esta página es más importante que en la página que actualiza el bot. TonyBallioni ( charla ) 22:35, 20 de febrero de 2021 (UTC)
- En Wikipedia: solicitudes de comentarios / políticas y directrices de Wikipedia hay un enlace. Eso es todo. Compare los otros RfC en esa lista: con una excepción, cada uno tiene un enlace; una declaración; quizás una firma; y una marca de tiempo. La única excepción es la charla de Wikipedia: los respaldos políticos , y eso también se debe a que carece de una declaración breve. - Red rose64 🌹 ( conversación ) 23:35, 20 de febrero de 2021 (UTC)
- @ TonyBallioni : Han pasado más de 24 horas desde que señalé este problema, ¿se solucionará? - Red rose64 🌹 ( hablar ) 22:57, 21 de febrero de 2021 (UTC)
- No. No lo considero un problema. TonyBallioni ( charla ) 23:03, 21 de febrero de 2021 (UTC)
- ¿Qué, el hecho de que no se muestre ninguna declaración en Wikipedia: solicitudes de comentarios / políticas y directrices de Wikipedia no es un problema? Legobot no puede analizar la declaración porque no es lo suficientemente breve, por lo que no puede procesar el RfC. Esta no es una regla insignificante que me haya inventado, es un hecho. - Red rose64 🌹 ( conversación ) 23:40, 21 de febrero de 2021 (UTC)
- He respondido en su página de discusión porque creo que es un mejor lugar para tener esta discusión, pero sí, no veo ningún problema allí. TonyBallioni ( charla ) 23:57, 21 de febrero de 2021 (UTC)
- ¿Qué, el hecho de que no se muestre ninguna declaración en Wikipedia: solicitudes de comentarios / políticas y directrices de Wikipedia no es un problema? Legobot no puede analizar la declaración porque no es lo suficientemente breve, por lo que no puede procesar el RfC. Esta no es una regla insignificante que me haya inventado, es un hecho. - Red rose64 🌹 ( conversación ) 23:40, 21 de febrero de 2021 (UTC)
- No. No lo considero un problema. TonyBallioni ( charla ) 23:03, 21 de febrero de 2021 (UTC)
- @ TonyBallioni : Han pasado más de 24 horas desde que señalé este problema, ¿se solucionará? - Red rose64 🌹 ( hablar ) 22:57, 21 de febrero de 2021 (UTC)
- En Wikipedia: solicitudes de comentarios / políticas y directrices de Wikipedia hay un enlace. Eso es todo. Compare los otros RfC en esa lista: con una excepción, cada uno tiene un enlace; una declaración; quizás una firma; y una marca de tiempo. La única excepción es la charla de Wikipedia: los respaldos políticos , y eso también se debe a que carece de una declaración breve. - Red rose64 🌹 ( conversación ) 23:35, 20 de febrero de 2021 (UTC)
- Me parece bien en esa página, y así es como doy formato a cada política importante que he propuesto. Si hay una solución fácil, no dudes en hacerlo, pero no cambies mi escritura. La presentación en esta página es más importante que en la página que actualiza el bot. TonyBallioni ( charla ) 22:35, 20 de febrero de 2021 (UTC)
- Creo que los foros de la comunidad en el punto 1. tendrían que ser ANI o AN (y nada más), es decir, un foro importante y muy visible. Creo que también necesitaría confirmar que la discusión de ANI / AN fue cerrada por un administrador (o incluso dos administradores), quienes concluyeron que había problemas, es decir, no un NAC (y probablemente ni un solo administrador). Britishfinance ( conversación ) 23:05, 20 de febrero de 2021 (UTC)
- ¿Estoy en lo cierto al pensar que el paso 3 es, en efecto, un "RfA inverso", que necesita un 60% para oponerse al desyop? Eso tendría sentido para mí como un proceso justo. Britishfinance ( conversación ) 23:08, 20 de febrero de 2021 (UTC)
- ¿Justo? Me parece extraño que un editor que no sea administrador deba obtener un apoyo del 65% al 75% en un RfA para aprobarlo, pero una vez que se haya convertido en un administrador en ejercicio y la comunidad pueda ver cómo usan las herramientas, lo harán solo necesita un apoyo del 40% para mantenerlos. - Uanfala (conversación) 16:19, 23 de febrero de 2021 (UTC)
- Esta idea sobre un "RfA inverso" es sólo una falsa equivalencia muy astuta , así como una inexactitud fáctica. Una comparación equivalente objetivamente precisa entre una RfA y una RfDA compararía el hecho de que solo se necesita entre un 35% y un 40% para considerar a un editor indigno o inadecuado para sostener las herramientas cuando no han hecho nada malo, de la misma manera en una RfDA debería hacerlo. tomar un porcentaje similar o incluso menos que ese para considerar a un editor no apto o indigno si ha sido acusado de hacer algo incorrecto o su confianza en la comunidad ha sido cuestionada. Huggums537 ( charla ) 21:24, 26 de febrero de 2021 (UTC)
- ¿Justo? Me parece extraño que un editor que no sea administrador deba obtener un apoyo del 65% al 75% en un RfA para aprobarlo, pero una vez que se haya convertido en un administrador en ejercicio y la comunidad pueda ver cómo usan las herramientas, lo harán solo necesita un apoyo del 40% para mantenerlos. - Uanfala (conversación) 16:19, 23 de febrero de 2021 (UTC)
- ¿Podría ArbCom utilizar este proceso? Por ejemplo, en lugar de iniciar una investigación de ArbCom de 2 meses, ArbCom podría simplemente votar para enviar al administrador en cuestión directamente al paso 3. (arriba)? En última instancia, ¿el paso 3. podría convertirse en un mejor sistema para los casos ADMINACCT (por ejemplo, conducta general frente a fallas técnicas / uso indebido de herramientas)? Gracias. Britishfinance ( conversación ) 23:13, 20 de febrero de 2021 (UTC)
- Arbcom casi siempre desysops por movimiento, rápidamente, sin abrir una caja completa. No les lleva 2 meses. Nsk92 ( conversación ) 23:19, 20 de febrero de 2021 (UTC)
- No creo que ese haya sido el caso de los recientes desyops de BrownHairedGirl o Kudpung , ¿cuáles fueron, creo, casos de ADMINACCT? Britishfinance ( conversación ) 23:24, 20 de febrero de 2021 (UTC)
- Britishfinance : para responder a sus preguntas, estoy de acuerdo, estaba pensando que AE podría ser otro lugar en algunas circunstancias, así que dejé un margen de maniobra. En el punto 2, sí, invierta RfA. Estoy usando el 60%, pero estoy bien con el 65%, como han sugerido otros aquí. Esa es la gente que necesitaría apoyar la remoción. El 3, no creo que los arbitrajes se abran por moción, pero todos cumplen con los requisitos para iniciar y respaldar una solicitud, por lo que podrían hacer una como miembro de la comunidad si lo sintieran mejor que un caso completo. TonyBallioni ( charla ) 23:28, 20 de febrero de 2021 (UTC)
- TonyBallioni, podría encontrar que si el paso 1. estuviera siendo impugnado entre los administradores, podría pasar a ArbCom, quien al confirmar un cierre válido, lo enviaría directamente al paso 3. Tengo la sensación de que el paso 3. sería importante herramienta para que ArbCom pueda enviar casos tipo ADMINACCT a. Britishfinance ( conversación ) 23:32, 20 de febrero de 2021 (UTC)
- Britishfinance : para responder a sus preguntas, estoy de acuerdo, estaba pensando que AE podría ser otro lugar en algunas circunstancias, así que dejé un margen de maniobra. En el punto 2, sí, invierta RfA. Estoy usando el 60%, pero estoy bien con el 65%, como han sugerido otros aquí. Esa es la gente que necesitaría apoyar la remoción. El 3, no creo que los arbitrajes se abran por moción, pero todos cumplen con los requisitos para iniciar y respaldar una solicitud, por lo que podrían hacer una como miembro de la comunidad si lo sintieran mejor que un caso completo. TonyBallioni ( charla ) 23:28, 20 de febrero de 2021 (UTC)
- No creo que ese haya sido el caso de los recientes desyops de BrownHairedGirl o Kudpung , ¿cuáles fueron, creo, casos de ADMINACCT? Britishfinance ( conversación ) 23:24, 20 de febrero de 2021 (UTC)
- Arbcom casi siempre desysops por movimiento, rápidamente, sin abrir una caja completa. No les lleva 2 meses. Nsk92 ( conversación ) 23:19, 20 de febrero de 2021 (UTC)
- Me preocupa un poco que el paso 1 haga más engorroso cerrar los hilos polémicos del dramaboard. - BillHPike ( charla , contribuciones ) 23:21, 20 de febrero de 2021 (UTC)
- Siento que requerir avisos explícitamente en WP: AN, WP: BN, WT: RFA y WP: CENT está al borde de WP: INSTRUCTIONCREEP . Quizás simplemente diga "publicitado en los tablones de anuncios de la comunidad". - BillHPike ( charla , contribuciones ) 23:25, 20 de febrero de 2021 (UTC)
- Creo que es bueno ser explícito. Esas juntas están altamente en listas de vigilancia, y la idea probablemente sea asegurarse de que ganen una amplia atención. FWIW, el proceso de nominaciones de BAG también enumera cada tablero para anunciar. Por cierto, Tony, supongo que la "solicitud de desysop", una vez traducida, se anunciará en las listas de seguimiento como lo hacen las RfA normales. ProcrastinationReader ( charla ) 23:30, 20 de febrero de 2021 (UTC)
- Intencionalmente evité la sugerencia de la lista de observación, porque no creo que contribuya a una discusión significativa (es decir, se exageraría y las personas que no están familiarizadas con la situación se apilarían de un lado o del otro). Eso podría ser algo discutido después, aunque si la gente lo consideraba necesario. TonyBallioni ( charla ) 23:32, 20 de febrero de 2021 (UTC)
- Entendido, gracias por aclarar. ProcrastinationReader ( charla ) 23:41, 20 de febrero de 2021 (UTC)
- Intencionalmente evité la sugerencia de la lista de observación, porque no creo que contribuya a una discusión significativa (es decir, se exageraría y las personas que no están familiarizadas con la situación se apilarían de un lado o del otro). Eso podría ser algo discutido después, aunque si la gente lo consideraba necesario. TonyBallioni ( charla ) 23:32, 20 de febrero de 2021 (UTC)
- Creo que es bueno ser explícito. Esas juntas están altamente en listas de vigilancia, y la idea probablemente sea asegurarse de que ganen una amplia atención. FWIW, el proceso de nominaciones de BAG también enumera cada tablero para anunciar. Por cierto, Tony, supongo que la "solicitud de desysop", una vez traducida, se anunciará en las listas de seguimiento como lo hacen las RfA normales. ProcrastinationReader ( charla ) 23:30, 20 de febrero de 2021 (UTC)
- Por 'inclinarse en contra', debo señalar que estoy totalmente de acuerdo con las sugerencias de un porcentaje de desysop más alto requerido para perder el bit que la propuesta original del 60%, si esto se lleva a cabo. (Puedo ver un argumento para un porcentaje más alto del necesario para confirmar un RfA en primer lugar). Vaticidalprophet ( hablar ) 23:57, 20 de febrero de 2021 (UTC)
- ¿Qué sucede si ningún burócrata revisa el hilo de respaldo? Lo mejor, Barkeep49 ( charla ) 23:57, 20 de febrero de 2021 (UTC)
- Presumiblemente, el declarante u otra persona haría un cargo en BN. Creo que tenemos suficientes burócratas activos en este punto que un puesto allí pidiéndoles que confirmen que se han cumplido los requisitos resultaría en acción. Tendrían una directiva de política clara a seguir, y no creo que sea probable que todos los activos ignoren una solicitud para hacer algo que la comunidad les ha pedido que hagan. TonyBallioni ( charla ) 01:45, 21 de febrero de 2021 (UTC)
- Comentario. ¿Alguien podría tratar de articular por qué se necesita ahora un procedimiento de desysop comunitario? Leí el RfC 2019 (en el que no participé) pero realmente no encontré respuestas convincentes allí. Las personas que apoyan la idea allí, en su mayoría, postulan su apoyo axiomáticamente ("sí, definitivamente necesitamos tal sistema"). O dicen algo en el sentido de que lo que la comunidad otorgó, la comunidad debería poder quitarlo. Pero, ¿es realmente cierto que el sistema actual de desysop de ArbCom es significativamente deficiente? ¿Es demasiado difícil desysop a los administradores por una causa allí? Nsk92 ( conversación ) 00:13, 21 de febrero de 2021 (UTC)
- El sistema ArbCom siempre ha sido deficiente. ArbCom puede dar forma a los casos para que se adapten a sus propias opiniones sobre el tema del caso, pueden elegir si aceptan el caso, ya limitan la cantidad de pruebas y pueden negarse a escuchar más pruebas, y luego pueden proponer resultados que adaptarse a su perspectiva de la edición. También hay un gran intercambio de ideas entre bastidores para asegurar el apoyo a las propuestas. Es como una versión más o menos de mierda de un juicio político presidencial. Nick ( charla ) 00:43, 21 de febrero de 2021 (UTC)
- " extenso entre bastidores para asegurar el apoyo a las propuestas" Esto no tiene base en la realidad. Tampoco " llega a proponer resultados que se adapten a sus perspectivas de edición ". Beeblebrox ( charla ) 01:23, 21 de febrero de 2021 (UTC)
- Algunas reflexiones: 1) ¿ArbCom aún podría desysop? No creo que eso deba eliminarse por completo, especialmente para emergencias o relacionadas con información privada. 2) Las categorías generales de lo que se cubre probablemente deberían estar detalladas. ¿Esto cubre a) abuso de herramientas b) conducta impropia de un administrador c) inactividad? - Rs chen 7754 00:29, 21 de febrero de 2021 (UTC)
- 1) Por supuesto que lo haría; la adición de texto propuesta no reemplaza nada y no modifica Wikipedia: Arbitraje / Política . 2) El único límite de cobertura requerido se describe en la condición # 1 de la propuesta; esto ya excluye la inactividad pura. No hay necesidad de limitaciones adicionales. ~ ToBeFree ( hablar ) 01:36, 21 de febrero de 2021 (UTC)
- ( editar conflicto ) Re: 1), sí lo harían, ya que es una sanción y, a veces, cae dentro de la información privada. Esto no eliminaría su capacidad para deshacerse de ellos. Creo que, sin embargo, esto reduciría en gran medida los casos de desysop, ya que sería otro lugar de resolución de disputas de la comunidad, y presumiblemente el comité se remitiría a la comunidad cuando sea posible, como ha sido su práctica en los últimos años para cosas como el bloqueo. revisiones. 2) esto fue diseñado en lugar de casos, por lo que principalmente abuso de herramientas y conducta impropia. 3) Estoy a favor de estándares de actividad más estrictos, pero creo que esa es una discusión separada y es poco probable que se apruebe si se unieran. Esto crearía la oportunidad de eliminar a alguien que hace 1 edición al año y luego hace un bloqueo involucrado, edita guerras y luego protege la página, etc.que podría manejarse más fácilmente de esta manera si hubiera un consenso de la comunidad al respecto, lo cual sospecho que existe. probablemente lo sería en algunos casos. TonyBallioni ( charla ) 01:40, 21 de febrero de 2021 (UTC)
- @ TonyBallioni :, un par de preguntas sobre detalles específicos - 1) ¿hay alguna razón por la que se seleccionó una escala de tiempo tan larga de la discusión comunitaria (ya que solo necesita ser el caso más reciente) - 3 meses parecerían servir? 2) ¿Existe alguna limitación para múltiples solicitudes de endosos del mismo hilo? 3) ¿Sería beneficioso incluir específicamente una opción que permitiera a los administradores activar directamente la solicitud de la etapa de desysop? Si esto pasa, puedo ver a muchas personas actualizando sus estándares de recuperación voluntaria o simplemente eligiendo hacerlo en caso de que sientan actuaron de manera problemática, pero no están de acuerdo, justifica su renuncia. Sin una nota clara que sea posible, la primera vez que alguien quisiera hacerlo, implicaría una discusión adicional en lo que presumiblemente sería un momento tenso. 4) ¿Se aplicarían las restricciones normales de escrutinio a la etapa de endoso? Nosebagbear ( charla ) 01:50, 21 de febrero de 2021 (UTC)
- También estoy parcialmente de acuerdo con Britishfinance: sería beneficioso realizar una lista específica de foros que se consideren suficientemente. Por ejemplo, un hilo de DRV que dice que un administrador hizo un cierre incorrecto, generalmente de 5 a 7 personas, probablemente no debería contar (si alguien a menudo está haciendo un cierre deficiente, entonces debería llevarse a AN (I), luego podría contar). Nosebagbear ( charla ) 01:57, 21 de febrero de 2021 (UTC)
- @ Nosebagbear : en el punto 1, la razón de todos estos números es porque escribo mis RfC de una manera en la que me siento cómodo y puedo tener suficientes personas detrás de ellos en ambos lados, incluso si no son perfectos. Personalmente, preferiría 3 meses, pero creo que 6 es suficiente y evita la objeción de que 3 es demasiado corto. Si la gente prefiere 3, eso se puede modificar a medida que se desarrolla el proceso. 2) No necesariamente más allá de la limitación social. Había imaginado esto como "aquí hay un hilo en el que el consenso muestra que están actuando de manera inapropiada", seguido de otra instancia, que podría desencadenar una solicitud. Si alguien realiza acciones involucradas regularmente dentro de los 6 meses, no estoy seguro de que debamos limitar el hilo. Al mismo tiempo, creo que habría un fuerte incentivo social para no seguir golpeando a un caballo muerto, y la comunidad podría sancionar a las personas que lo hicieran. 3) Creo que es una sugerencia razonable. No quiero agregarlo ahora ya que hay votos importantes, pero creo que una nota al pie en la política que indique que está permitido sería razonable si se aprueba. 4) Sí. Espero que aclare. Además, como nota general, habiendo realizado algunas de estas importantes RfC, todas las cuestiones planteadas en los comentarios se pueden aclarar cuando la propuesta se fusiona en la página de políticas de acuerdo con la declaración de cierre. Estos RfC tienden a plantear muchos problemas complejos y, por lo general, funciona mejor establecer un marco y luego ajustarlo para reflejar el consenso total de la discusión. TonyBallioni ( charla ) 02:04, 21 de febrero de 2021 (UTC)
- Más sobre el
renuncia como una
cláusula deadministrador
: esto parece resultar en una "renuncia voluntaria", lo que significa que hay un camino para resysop a través de una simple solicitud que luego pone una responsabilidad en 'crats para determinar si esto es un descalificador --- cualquier razón por la que esto no se puede simplemente codificar? Sugiero que este componente, y toda la política en general, incluyan palabrería que indique específicamente que una futura restauración del acceso debe seguir el proceso "estándar" (es decir, RFA). - Charla xaosflux 04:25, 21 de febrero de 2021 (UTC)- La política ya dice que no lo recuperarían ( Wikipedia: Administrators # Restoration_of_adminship ). Me opondría a agregarlo aquí porque ya hay una política clara sobre el tema, y creo que agregar un texto explícito que lo diga socavaría la utilidad del redacción existente. No se sienta tan fuertemente opuesto a ello, pero creo que la política en su conjunto funciona mejor si no repetimos lo que ya está ahí. TonyBallioni ( charla ) 04:41, 21 de febrero de 2021 (UTC)
- @ TonyBallioni : así que eso es solo poner el problema en el camino, y asumiendo que la "nube" se revelará más tarde, generalmente con arbcom desysops, la nube está prescrita, evitando cualquier drama en BN más adelante. - Charla xaosflux 04:47, 21 de febrero de 2021 (UTC)
- No. Se espera que los burócratas sigan la política ya inequívoca que evita esto. TonyBallioni ( charla ) 04:51, 21 de febrero de 2021 (UTC)
- @ TonyBallioni : así que eso es solo poner el problema en el camino, y asumiendo que la "nube" se revelará más tarde, generalmente con arbcom desysops, la nube está prescrita, evitando cualquier drama en BN más adelante. - Charla xaosflux 04:47, 21 de febrero de 2021 (UTC)
- La política ya dice que no lo recuperarían ( Wikipedia: Administrators # Restoration_of_adminship ). Me opondría a agregarlo aquí porque ya hay una política clara sobre el tema, y creo que agregar un texto explícito que lo diga socavaría la utilidad del redacción existente. No se sienta tan fuertemente opuesto a ello, pero creo que la política en su conjunto funciona mejor si no repetimos lo que ya está ahí. TonyBallioni ( charla ) 04:41, 21 de febrero de 2021 (UTC)
- En lo que respecta a IADMIN, la política de administradores de Wikipedia: Interfaz ya tiene una ruta más simple para la eliminación de la comunidad, y ya incluye la eliminación obligatoria en -sysop por cualquier motivo; así que sugiera que todo esto se elimine en lugar de hacer un proceso competitivo (más difícil). - xaosflux Talk 4:27, 21 de Febrero 2021 (UTC)
- Rschen7754 sugirió esto anteriormente cuando se trataba de la pregunta crat / int-admin. Alguien ya señaló en la página de discusión que ya hay otras formas de hacer esto (de hecho, creo que podría haberlo sugerido en ese momento ...) Sin embargo, no veo la necesidad de cambiar la propuesta nuevamente. Nada se contradice y es solo otro lugar para la eliminación si la gente quiere algo más estructurado por cualquier motivo. TonyBallioni ( charla ) 04:41, 21 de febrero de 2021 (UTC)
- @ Rschen7754 : Realmente no veo por qué alguien querría pasar por este enorme proceso para argumentar -iadmin por alguien, cuando el primer paso ya debería cubrirlo- ¿qué escenarios está visualizando? - Charla xaosflux 04:47, 21 de febrero de 2021 (UTC)
- Burócrata era más lo que me preocupaba; cada wiki tiene sus propias reglas con respecto a la administración de la interfaz y no estoy muy al día en cuanto a las reglas, solo quería asegurarme de que se tuviera en cuenta. - Rs chen 7754 06:33, 21 de febrero de 2021 (UTC)
- Esta propuesta requiere que se cierre un hilo de AN con algo inapropiado, luego puede comenzar el resto. La política de IAdmin solo requiere la primera parte:
Después de un uso indebido del acceso por consenso (por ejemplo, en Wikipedia: tablón de anuncios de los administradores).
Eso hace que esto, en mi opinión, sea una complejidad innecesaria y simplemente confuso. No creo que esta propuesta deba aplicarse a AI, porque ya tenemos un proceso más débil para lidiar con ese abuso. Estoy de acuerdo con la idea de que los derechos de IA deben eliminarse en desysop, pero creo que esa es la práctica actual de todos modos (un no administrador no puede tener IA). Por lo tanto, la propuesta probablemente solo debería aplicarse a administradores y crats. ProcrastinationReader ( charla ) 08:56 21 de febrero de 2021 (UTC)
- @ Rschen7754 : Realmente no veo por qué alguien querría pasar por este enorme proceso para argumentar -iadmin por alguien, cuando el primer paso ya debería cubrirlo- ¿qué escenarios está visualizando? - Charla xaosflux 04:47, 21 de febrero de 2021 (UTC)
- Rschen7754 sugirió esto anteriormente cuando se trataba de la pregunta crat / int-admin. Alguien ya señaló en la página de discusión que ya hay otras formas de hacer esto (de hecho, creo que podría haberlo sugerido en ese momento ...) Sin embargo, no veo la necesidad de cambiar la propuesta nuevamente. Nada se contradice y es solo otro lugar para la eliminación si la gente quiere algo más estructurado por cualquier motivo. TonyBallioni ( charla ) 04:41, 21 de febrero de 2021 (UTC)
- WT: RFA es para discutir las operaciones de WP: RFA, no debería ser un tablón de anuncios para las cosas, ¿por qué es necesario? - Charla xaosflux 04:33, 21 de febrero de 2021 (UTC)
- Porque algunas personas todavía están en la lista de seguimiento WP: RFA para verificar si hay transclusiones de RfAs. Dado que se trata de un proceso similar, tiene sentido permitir que las personas sepan cuándo se inicia en una página muy vista que ya están viendo para esos fines. TonyBallioni ( charla ) 04:41, 21 de febrero de 2021 (UTC)
- ¿Podría pedir algunos ejemplos (digamos, tres) de subprocesos AN / ANI que hubieran calificado en el paso 1? Creo que sería útil para evaluar esta propuesta. En términos más generales, me preocupa un poco que esto empeoraría las tendencias de tablero dramático de AN / ANI: lo último que queremos es convertir los tableros de anuncios en un "buzón de quejas de administradores". Dicho esto, espero que alguien pueda calmar mis temores, porque realmente creo que esta es una propuesta muy bien pensada. Saludos, Escrito extraordinario ( charla ) 04:50, 21 de febrero de 2021 (UTC)
- Mientras leía esta propuesta, se me ocurrieron dos sugerencias. La primera es que, por respeto a las preocupaciones sobre el acoso, dentro de un período de tiempo establecido (digamos 90 días, arbitrariamente), la misma parte no puede presentar otra solicitud de envío de datos muertos contra el mismo administrador. Quizás requiera 11 (1 + 10) personas diferentes para iniciarlo, por ejemplo. Si cualquier incidente nuevo es lo suficientemente atroz como para atraer suficiente apoyo para quitar la bandera, pedir 11 iniciadores diferentes no debería ser un gran obstáculo.
La segunda sugerencia puede ser discutible, porque fue un pensamiento que tuve antes de desplazarme hacia abajo para ver el apoyo abrumador que tiene hasta ahora. No obstante: dado que el último RfC se cerró sin un consenso claro sobre cómo implementarlo, con varias dudas sobre este o aquel enfoque, tal vez sería una buena idea decir que se trata de una prueba de 12 meses. Dado lo difícil que ha sido llegar a un consenso sobre esto, sería más fácil solucionarlo si resulta ser una mala idea y al mismo tiempo permitir una prueba de concepto. - Hablar de las rododendritas \\ 04:57, 21 de febrero de 2021 (UTC)
- Aprecio lo que TonyBallioni está tratando de lograr, y también que está tratando de permitir un tiempo conveniente para el administrador en discusión. Sin embargo, obligar al administrador a transcluir su propia solicitud de desysop parece ... cruel. Estoy seguro de que otros tendrán mejores sugerencias de redacción, pero mi débil intento es el siguiente: "Una vez certificado, el administrador en discusión debe indicar la hora de inicio de la solicitud de desysop, que no exceda los 14 días posteriores a la certificación. Pueden transcluir la discusión de desysop ellos mismos, o indicar que preferirían que un burócrata lo hiciera en su nombre. Si el administrador en discusión desea evitar la discusión, puede renunciar como administrador. Si no se recibe ninguna indicación sobre el tiempo del administrador en discusión, un burócrata concluirá la discusión al cabo de 14 días ". ¿Pensamientos? 78,26 ( Spin Me / revoluciones ) 05:08, 21 de febrero de 2021 (UTC)
- 78.26 , creo que mencioné esto anteriormente, pero asumí que podrían pedirle a un idiota que lo hiciera y lo harían. Creo que la redacción específica podría modificarse si esta política se aprueba sin otro RfC que lo permita, o simplemente podrían preguntar. La razón por la que estoy tratando de evitar más cambios es que ya hemos tenido 30 votos y creo que otro ping masivo sería perturbador. He realizado varios RfC de escala similar antes y, cuando se implementan, nunca están vinculados a la redacción exacta de la propuesta, pero tienden a ser rotos en función del cierre que refleja el consenso total de la discusión sobre puntos como este. . No creo que lo que sugieres esté fuera de lugar para ese tipo de ajuste posterior al cierre. TonyBallioni ( charla ) 05:15, 21 de febrero de 2021 (UTC)
- Estoy de acuerdo. Esto fue pensado como un punto de discusión, y no como una nueva redacción de la política que requiera una votación por separado. 78,26 ( Spin Me / revoluciones ) 05:28, 21 de febrero de 2021 (UTC)
- 78.26 , creo que mencioné esto anteriormente, pero asumí que podrían pedirle a un idiota que lo hiciera y lo harían. Creo que la redacción específica podría modificarse si esta política se aprueba sin otro RfC que lo permita, o simplemente podrían preguntar. La razón por la que estoy tratando de evitar más cambios es que ya hemos tenido 30 votos y creo que otro ping masivo sería perturbador. He realizado varios RfC de escala similar antes y, cuando se implementan, nunca están vinculados a la redacción exacta de la propuesta, pero tienden a ser rotos en función del cierre que refleja el consenso total de la discusión sobre puntos como este. . No creo que lo que sugieres esté fuera de lugar para ese tipo de ajuste posterior al cierre. TonyBallioni ( charla ) 05:15, 21 de febrero de 2021 (UTC)
- ¿Cómo maneja las solicitudes repetidas que se presentan ad infinitum como una forma de acoso? Cualquier grupo de 10 personas puede cumplir fácilmente con los requisitos para volver a presentar la solicitud tan pronto como se elimine la anterior. ¿Necesitamos una advertencia que diga que la misma persona y / o los patrocinadores no pueden volver a solicitar repetidamente? Tarl N. ( discutir ) 05:20, 21 de febrero de 2021 (UTC)
- No creo que vaya a haber ningún sistema perfecto y que si deletreamos cosas así, probablemente obtendríamos opositores por ser demasiado complejo. Mi opinión es que habría una fuerte presión social para no hacer eso, y que el requisito de que haya 3 administradores actuales que lo respalden también sería un poco de control: si lo hicieran de manera inapropiada, podrían ser desanimados por actuar de manera inadecuada. manera inconsistente con la administración. La comunidad también puede sancionar a las personas por comportamiento de WP: POINTy . Básicamente, creo que es la misma razón por la que no ve solicitudes de ArbCom repetidas indefinidamente: la paciencia de las personas se agotará. TonyBallioni ( charla ) 05:31 21 de febrero de 2021 (UTC)
- Claro, pero bloquear a alguien por su "buena fe" en la presentación de un desysop sería bastante audaz ("muéstreme la política que dice que solo puedo comenzar un desysop al mes"). Y el administrador de bloqueo tendría que querer ser un objetivo para un grupo de personas que se sabe que usan desysops como arma. Johnuniq ( charla ) 05:58, 21 de febrero de 2021 (UTC)
- [ec] Estoy cautelosamente a favor de la propuesta, pero como Tarl N. veo potencial para que esto se convierta en una herramienta de acoso, y me gustaría que quedara claro que esto no sería tolerado, posiblemente algunas consecuencias específicas por comportamiento inapropiado. · · · Peter Southwood (charla) : 05:36, 21 de febrero de 2021 (UTC)
- Siento que la comunidad tiene muy poca tolerancia para este tipo de juegos y no me preocupa que los editores puedan lograrlo sin consecuencias. Lo mejor, Barkeep49 ( charla ) 06:16, 21 de febrero de 2021 (UTC)
- Acordado. Me imagino que el rechazo social contra alguien que abusa del sistema de esta manera sería rápido. Y si resulta ser una preocupación una vez implementado, se podrían implementar medidas adicionales para abordar específicamente cómo se está jugando el sistema, algo que simplemente no podemos saber en este momento. - Ajraddatz ( charla ) 06:32, 21 de febrero de 2021 (UTC)
- Siento que la comunidad tiene muy poca tolerancia para este tipo de juegos y no me preocupa que los editores puedan lograrlo sin consecuencias. Lo mejor, Barkeep49 ( charla ) 06:16, 21 de febrero de 2021 (UTC)
- No creo que vaya a haber ningún sistema perfecto y que si deletreamos cosas así, probablemente obtendríamos opositores por ser demasiado complejo. Mi opinión es que habría una fuerte presión social para no hacer eso, y que el requisito de que haya 3 administradores actuales que lo respalden también sería un poco de control: si lo hicieran de manera inapropiada, podrían ser desanimados por actuar de manera inadecuada. manera inconsistente con la administración. La comunidad también puede sancionar a las personas por comportamiento de WP: POINTy . Básicamente, creo que es la misma razón por la que no ve solicitudes de ArbCom repetidas indefinidamente: la paciencia de las personas se agotará. TonyBallioni ( charla ) 05:31 21 de febrero de 2021 (UTC)
- Preguntas: ¿se pretende que esto reemplace eficazmente a ArbCom como método de primer recurso? En otras palabras, ¿se esperará / requerirá de facto que los editores que buscan arbitraje hayan probado este proceso primero? ¿O es solo un proceso secundario, y un editor tiene la opción de pasar por este o por arbitraje? Apoyo la idea de que la comunidad puede recuperar lo que ofrece y tiene derecho a decidir qué administradores pueden limpiar en su nombre. Además, entiendo que hay algunos casos en los que los arbs no abordan y que la comunidad aún podría querer actuar. Aún así, creo que me opondría si esto eleva el listón del arbitraje. Hay algunos problemas que los procesos comunitarios simplemente no pueden abordar, y si esta propuesta eleva el listón para la intervención de ArbCom, creo que sería preocupante. Una mención explícita en la propuesta en este sentido resolvería esta preocupación. ProcrastinationReader ( charla ) 07:15, 21 de febrero de 2021 (UTC)
- También noto la barra alta a la eliminación. Un editor podría conservar su administración con solo el 59% de los editores apoyando la eliminación, es decir, solo el 41% de los editores respaldando su administración. Si eso fuera un RfA, sería un claro fracaso. ProcrastinationReader ( charla ) 07:18, 21 de febrero de 2021 (UTC)
- Un área que sí me viene a la mente es la de evitar la doble incriminación: yo diría que mientras una solicitud de caso en ARBCOM está pendiente, el método comunitario no se puede utilizar también (en casos extremos, siempre se puede cobrar). No considero que esto sea un valor atípico, y si no se agrega ahora, ni siquiera se considerará agregarlo hasta que al menos una persona haya tenido que lidiar con ambos tratando de ocurrir al mismo tiempo . Me gustaría señalar que, si bien la propuesta de TB es decente, me decepcionan un poco que digan que no quieren hacer ciertos cambios porque ¡varias personas han votado! De hecho, esa es la razón por la que la votación no debería haberse abierto hasta que se haya realizado una discusión adicional. Nosebagbear ( charla ) 12:02, 21 de febrero de 2021 (UTC)
- Creo que entra en la categoría de cosas de las que deberíamos ocuparnos socialmente más que con una política específica. Podríamos ajustar esto para muchas hipótesis, pero nunca sería perfecto y se volvería difícil de manejar muy rápidamente. En cuanto a la reparación durante una semana, creo que habría sido la forma más rápida de hacer que fallara, ya que ningún tipo podría crear un procedimiento perfecto, y terminaría oponiéndose por imperfecciones después de un problema menor específico. no fue abordado. Muchas de las cosas que se discuten aquí no son cambios sustanciales, como quién transcluye. Ese es el tipo de cosas que, en mi experiencia, generalmente se limpian mejor después del cierre ajustando la página de la política para que esté en línea con la declaración de cierre y solucionando cualquier problema menor evidente. Es por eso que preferiría hacerlo en lugar de hacer ping masivo a un grupo de personas varias veces. TonyBallioni ( charla ) 13:35, 21 de febrero de 2021 (UTC)
- Algunos en la oposición encuentran que este procedimiento es demasiado propenso a una turba enojada, mientras que otros en la oposición lo encuentran demasiado arraigado para importar debido al requisito de tres operadores. Estoy apoyando, pero tengo curiosidad si alguien que se oponga (o lidere en ese sentido) encuentra que ambos hechos son preocupantes. Supongo que la imaginación sería: (1) el acto de abrir una solicitud de respaldo podría repetirse hasta el punto de abusar, y luego (2) oponerse sistemáticamente por parte de sysops mordaces. ¿Es eso más o menos correcto? De lo contrario, los dos puntos de vista parecen en gran medida mutuamente excluyentes. ~ Amory ( u • t • c ) 15:14, 21 de febrero de 2021 (UTC)
- Desde mi punto de vista, el problema no es eliminar a algunos administradores errantes, es hacer que la mayoría de ellos se responsabilicen (en otras palabras, dar dientes a WP: ADMINACCT ). Los administradores de Wikipedia reciben citas de por vida, un lujo poco común en la mayoría de las otras organizaciones, y por una razón. Lo que deberíamos tener es términos limitados: 2-3 años, después de los cuales el administrador debe enfrentar la revisión de la comunidad. Esto obligará a los administradores no solo a "comportarse", sino también a escuchar .
- En cuanto a esta propuesta, tiene dos problemas: el primero es el requisito de una declaración de cierre de apoyo, lo que significa que los administradores tendrían que criticar a uno de los suyos lo suficientemente fuerte como para merecer una mención, una rara ocasión; el segundo es el requisito de "transcluir" algo, que es un punto técnico y no pertenece a una discusión sustancial (cf. "ley" vs "regulación"). François Robere ( charla ) 16:44, 21 de febrero de 2021 (UTC)
- Queda por probar, pero creo que es más probable que veamos a los operadores de sistemas compartir abierta y honestamente las críticas con tal política. Por el momento, hay pocos incentivos para invectivas a menos que / hasta que haya un caso ArbCom, que, a pesar de algunos ejemplos recientes (ish), es bastante raro. ~ Amory ( u • t • c ) 16:54, 21 de febrero de 2021 (UTC)
- Todavía no sé cuál es mi posición en esto, pero una cosa que me llamó la atención de inmediato fue la
al menos 25 ediciones en el
requisito delos últimos 6 meses
. Sugiero encarecidamente dejar eso. Entiendo el deseo de limitar esto a las personas que están contribuyendo, pero esta es una mala manera de hacerlo. Por un lado, un mal actor que no cumple con el requisito de 25 en 6 puede simplemente hacer 25 ediciones basura, de la misma manera que la gente juega WP: ACPERM ahora. Por otro lado, si alguien es abusado legítimamente por un administrador hasta el punto de que abandona el proyecto, es posible que desee volver un año después y explicar lo que dicho administrador le hizo, que fue tan horrible. Privamos a esas personas. - RoySmith (charla) 17:40, 21 de febrero de 2021 (UTC)- He leído mucho más y todavía no estoy seguro de dónde estoy. Sin embargo, agregaré otro comentario. Existe un acuerdo general de que necesitamos más administradores. Y creo que también hay un acuerdo general en que la atmósfera de novatadas en RfA ahuyenta a los candidatos razonables. Hasta aquí todo bien.
- Una de las premisas planteadas por varios de los partidarios es que al facilitar la eliminación de malos administradores, haremos que la RfA sea más civilizada. Las consecuencias de tomar una decisión incorrecta no serán tan duraderas, por lo que las personas no serán tan quisquillosas. Con un RfA más amable y gentil, atraeremos a más candidatos. Esa es una teoría plausible. Pero, otra teoría plausible es que el RfA no mejorará, porque está en la naturaleza de algunas personas ser quisquilloso. Y si ese es el caso, lo haremos aún menos atractivo. Si no podemos convencer a la gente de que se someta a la semana del infierno ante la posibilidad de ganar un trapeador de por vida, ciertamente no podremos convencerlos de que prueben un trapeador que sea más fácil de quitar. Honestamente, no sé cuál es más probable, pero ciertamente no estoy de acuerdo en que esto necesariamente atraiga a más candidatos. - RoySmith (charla) 20:00, 21 de febrero de 2021 (UTC)
- Estoy decepcionado por la oposición tbh. Un montón de usuarios que dicen "Yo apoyaría esto en teoría, pero hay demasiadas preocupaciones". Cuando literalmente casi no hay preocupaciones lógicas específicas ni siquiera articuladas. La propuesta contiene protección tras protección contra una mentalidad de mafia, desde un consenso reciente existente de que un administrador violó los estándares de comportamiento del administrador, hasta restricciones de actividad, restricciones de respaldo, restricciones de respaldo de administrador, hasta el requisito de que la re-RfA final requiere una supermayoría. de soporte para la eliminación, y que solo tiene que alcanzar el 40% de soporte para retener la broca. ¿La gente realmente está diciendo que esto está desatando a la mafia? ¿En serio? Puedo ser un verdadero gilipollas. Puedo y he cruzado la línea demasiadas veces. E incluso no tengo una sola discusión comunitaria a mi nombre con un consenso que diga que violé los estándares de comportamiento de los administradores. No en la última década, mucho menos en los últimos seis meses. Esta propuesta literalmente hace todo lo posible para adaptarse a la protección del administrador. Si todo sale absolutamente terrible para mí, y me veo obligado a ejecutar una re-RfA, y no puedo alcanzar el puto 40% de apoyo, ¿crees que yo o cualquier otra persona podría afirmar que el proceso es injusto? ¿Que esta RfA que se anuncia en CENT y AN y BN y en todas las listas de vigilancia es injusta conmigo? ¿Que no es representativo de la comunidad? Obviamente no. Si 10 usuarios, incluidos tres administradores, solicitan su eliminación, y ejecuta un RfA y no puede obtener un 40% de soporte, ¿realmente merece ser administrador? Diablos no. ~ Swarm ~ {sting} 02:42, 22 de febrero de 2021 (UTC)
- Creo que es una articulación tan clara como cualquiera de los defectos de la propuesta. De ninguna manera todos ellos, pero capturó muchos. FWIW, he intentado ser específico en mis comentarios de seguimiento. - Ryk72 talk 10:51, 22 de febrero de 2021 (UTC)
- @ Swarm : Eres libre de decir que las razones proporcionadas por quienes se oponen son insuficientes, pero es completamente inexacto decir "casi sin preocupaciones lógicas específicas"; se han proporcionado muchas. Para dar ejemplos: ninguna política de defensa contra múltiples emisiones basadas en los mismos hilos; no hay cobertura de lo que sucede si los casos ARBCOM pendientes y los desastres comunitarios ocurren al mismo tiempo; 6 meses es un tiempo muy largo desde el hilo AN / ANI problemático más reciente; ninguna consideración formal de qué foros cuentan como suficientemente claros para ser autorizados a contar a los efectos del obstáculo 1; no hay aclaraciones sobre si el tiempo comienza seis meses antes de ser aprobado o simplemente al pasar, etc., etc. No intercambie precisión por retórica Nosebagbear ( hablar ) 14:50, 22 de febrero de 2021 (UTC)
- Creo que es una articulación tan clara como cualquiera de los defectos de la propuesta. De ninguna manera todos ellos, pero capturó muchos. FWIW, he intentado ser específico en mis comentarios de seguimiento. - Ryk72 talk 10:51, 22 de febrero de 2021 (UTC)
- Excepto que no, no hay una sola objeción racional o basada en políticas, incluso ahora. ~ Swarm ~ {picadura} 01:45, 23 de febrero de 2021 (UTC)
- Swarm, estoy en la columna neutral por ahora, pero encuentro que una serie de objeciones planteadas por los oponentes son perfectamente racionales. En particular, Sandstein y varios otros plantean el hecho de que la implementación de esta propuesta probablemente empeore el problema WP: UNBLOCKABLES y, en general, haga que los administradores sean más reacios a emitir bloqueos difíciles y realizar acciones de cumplimiento en disputas complicadas. En mi opinión, estas preocupaciones están justificadas. Nsk92 ( conversación ) 02:39, 23 de febrero de 2021 (UTC)
- Me gusta Sandstein y aprecio el papel que juega aquí, y absolutamente no quiero que esto se interprete como un ataque personal contra él, pero se sabe que es uno de los administradores más polémicos y de línea dura en el proyecto y ha tenido una toneladas de quejas y acusaciones de mala conducta administrativa en su contra a lo largo de los años. Soy uno de los mayores defensores del problema IMBLOQUEABLE en este proyecto, así que simpatizo con este argumento, pero incluso yo solo puedo tomarlo con un grano de sal viniendo de Sandstein. No dudo que Sandstein aprobaría un esfuerzo desysop, pero tampoco dudo que le conviene no tener uno. ~ Swarm ~ {picadura} 01:22, 24 de febrero de 2021 (UTC)
- Guau. De acuerdo, no soy un administrador y no tengo la menor inclinación de intentar convertirme en uno. Todavía estoy bastante preocupado por el problema de los DESBLOQUEABLES y creo que es probable que la implementación de esta propuesta de desysop comunitaria exacerbe este problema hasta cierto punto. Supongamos que fui yo y no Sandstein quien hizo este argumento para empezar. El caso es que esta objeción es razonable y racional, independientemente de quién venga. Nsk92 ( conversación ) 01:54, 24 de febrero de 2021 (UTC)
- Si está preocupado por el problema IMBLOQUEABLE, apoyaría una reforma para hacer que los administradores abusivos sean inaceptables a través de un proceso comunitario. La oposición a esta propuesta es el epítome de los imbloqueables que se resisten a las reformas para mejorar marginalmente la situación. Esta noción de que darle a la comunidad una vía para deshacerse de los administradores abusivos haría que los administradores abusivos fueran más imbloqueables porque obligaría a los administradores abusivos a no ser abusivos está más allá de mi comprensión. La gimnasia mental es asombrosa. ~ Swarm ~ {sting} 10:06, 24 de febrero de 2021 (UTC)
- Swarm , no estoy siguiendo la lógica de su argumento, ¿o es retórica? · · · Peter Southwood (charla) : 06:07, 25 de febrero de 2021 (UTC)
- Por favor, dime, Peter, ¿qué parte no estás siguiendo? Todo lo que digo es increíblemente sencillo. ~ Swarm ~ {sting} 08:19, 25 de febrero de 2021 (UTC)
- Swarm , el párrafo directamente encima de mi comentario. ¿Está sugiriendo que la oposición proviene principal o exclusivamente de los elementos desbloqueables y sus facilitadores, o que no hay preocupaciones razonables sobre la implementación y las posibles consecuencias de la propuesta en su forma actual? Mi lectura de la discusión sugiere que hay varias preocupaciones, algunas razonables, que no se han abordado a satisfacción de un número significativo de personas. Afirmar que este no es el caso parece falso. Sugerir que la oposición pone a uno en el campo de los que no se pueden bloquear me parece un etiquetado incorrecto, lo que clasificaría como retórica. Saludos, · · · Peter Southwood (charla) : 15:01, 26 de febrero de 2021 (UTC)
- Por favor, dime, Peter, ¿qué parte no estás siguiendo? Todo lo que digo es increíblemente sencillo. ~ Swarm ~ {sting} 08:19, 25 de febrero de 2021 (UTC)
- Swarm , no estoy siguiendo la lógica de su argumento, ¿o es retórica? · · · Peter Southwood (charla) : 06:07, 25 de febrero de 2021 (UTC)
- Si está preocupado por el problema IMBLOQUEABLE, apoyaría una reforma para hacer que los administradores abusivos sean inaceptables a través de un proceso comunitario. La oposición a esta propuesta es el epítome de los imbloqueables que se resisten a las reformas para mejorar marginalmente la situación. Esta noción de que darle a la comunidad una vía para deshacerse de los administradores abusivos haría que los administradores abusivos fueran más imbloqueables porque obligaría a los administradores abusivos a no ser abusivos está más allá de mi comprensión. La gimnasia mental es asombrosa. ~ Swarm ~ {sting} 10:06, 24 de febrero de 2021 (UTC)
- Guau. De acuerdo, no soy un administrador y no tengo la menor inclinación de intentar convertirme en uno. Todavía estoy bastante preocupado por el problema de los DESBLOQUEABLES y creo que es probable que la implementación de esta propuesta de desysop comunitaria exacerbe este problema hasta cierto punto. Supongamos que fui yo y no Sandstein quien hizo este argumento para empezar. El caso es que esta objeción es razonable y racional, independientemente de quién venga. Nsk92 ( conversación ) 01:54, 24 de febrero de 2021 (UTC)
- Me gusta Sandstein y aprecio el papel que juega aquí, y absolutamente no quiero que esto se interprete como un ataque personal contra él, pero se sabe que es uno de los administradores más polémicos y de línea dura en el proyecto y ha tenido una toneladas de quejas y acusaciones de mala conducta administrativa en su contra a lo largo de los años. Soy uno de los mayores defensores del problema IMBLOQUEABLE en este proyecto, así que simpatizo con este argumento, pero incluso yo solo puedo tomarlo con un grano de sal viniendo de Sandstein. No dudo que Sandstein aprobaría un esfuerzo desysop, pero tampoco dudo que le conviene no tener uno. ~ Swarm ~ {picadura} 01:22, 24 de febrero de 2021 (UTC)
- Swarm, estoy en la columna neutral por ahora, pero encuentro que una serie de objeciones planteadas por los oponentes son perfectamente racionales. En particular, Sandstein y varios otros plantean el hecho de que la implementación de esta propuesta probablemente empeore el problema WP: UNBLOCKABLES y, en general, haga que los administradores sean más reacios a emitir bloqueos difíciles y realizar acciones de cumplimiento en disputas complicadas. En mi opinión, estas preocupaciones están justificadas. Nsk92 ( conversación ) 02:39, 23 de febrero de 2021 (UTC)
- Excepto que no, no hay una sola objeción racional o basada en políticas, incluso ahora. ~ Swarm ~ {picadura} 01:45, 23 de febrero de 2021 (UTC)
- TonyBallioni y cualquier otra persona que esté trabajando duro en esto, tengo algunas preocupaciones.
- Dado que el obstáculo 1 es vincular los asuntos a un solo incidente, ¿cómo manejaremos las preocupaciones de "doble riesgo"? ¿Podrían hacerse múltiples peticiones con respecto al mismo hilo de AN?
- ¿Habría una ubicación central para registrarlos, que tiene sus ventajas (transparencia y capacidad para verificar el historial) y sus desventajas (preocupaciones de "no hay humo sin fuego")?
- Si se acepta una petición, existe una ventana potencial de 2 semanas en la que el administrador está efectivamente bajo una nube. ¿Deberíamos aceptar su juicio como administrador en ese momento, o sería una buena idea incluir una cláusula que indique que no deben tomar acciones administrativas en ese período?
- ¿Qué pasa con el costo personal? Después de haber estado involucrado en muchas desysops (entre mi trabajo en Arbcom y mi participación en las solicitudes de retiro ) y cuando un usuario es desysopted, es un proceso difícil para ellos a nivel personal. Dado que el individuo habría invertido lo suficiente en Wikipedia para convertirse en administrador, ¿tiene alguna idea sobre cómo reducir lo desagradable del proceso y, por lo tanto, aumentar la probabilidad de mantenerlo como editor? Worm TT ( charla ) 11:02, 22 de febrero de 2021 (UTC)
- Ese número 4 es muy interesante, gusano , y merece un cálculo rápido: ¿cuántos administradores desocupados han seguido editando? ¿Cuántos administradores desocupados eran realmente muy visibles y / o estaban totalmente comprometidos en Wikipedia? Sé que dejé por completo de realizar ediciones proactivas. Kudpung กุด ผึ้ง ( charla ) 11:38, 22 de febrero de 2021 (UTC)
- Es muy difícil juzgar a Kudpung , pero de acuerdo con esta tabla , en los últimos 5 años, 11 administradores han sido eliminados por una causa, y solo 1 dejó de editar por completo, 1 detuvo aproximadamente 4 años después y 9 lo editaron en la última semana. Worm TT ( charla ) 14:03, 22 de febrero de 2021 (UTC)
- No es tan difícil de juzgar, Worm . Si uno se toma la molestia de cargar sus recuentos de ediciones, la mayoría de sus patrones de edición desde que fueron desocupados son como los míos: solo una pequeña, diminuta fracción de lo que solían hacer. La mayoría de ellos habían sido editores bastante prolíficos. Habla por sí mismo, sin prejuicios sobre la razón real por la que les arrancan las cosas. Kudpung กุด ผึ้ง ( charla ) 15:24, 22 de febrero de 2021 (UTC)
- Kudpung , de hecho, pero de nuevo los recuentos de ediciones no cuentan la imagen completa, ya que gran parte del recuento estaba ligado a las acciones de administración. Sin embargo, no estoy en desacuerdo con que haya una caída cuando un administrador es despedido por una causa. La creación de una nueva ruta para desysop por causa debería reconocer eso. Worm TT ( charla ) 15:39, 22 de febrero de 2021 (UTC)
- No es tan difícil de juzgar, Worm . Si uno se toma la molestia de cargar sus recuentos de ediciones, la mayoría de sus patrones de edición desde que fueron desocupados son como los míos: solo una pequeña, diminuta fracción de lo que solían hacer. La mayoría de ellos habían sido editores bastante prolíficos. Habla por sí mismo, sin prejuicios sobre la razón real por la que les arrancan las cosas. Kudpung กุด ผึ้ง ( charla ) 15:24, 22 de febrero de 2021 (UTC)
- Es muy difícil juzgar a Kudpung , pero de acuerdo con esta tabla , en los últimos 5 años, 11 administradores han sido eliminados por una causa, y solo 1 dejó de editar por completo, 1 detuvo aproximadamente 4 años después y 9 lo editaron en la última semana. Worm TT ( charla ) 14:03, 22 de febrero de 2021 (UTC)
- IANATB, pero aunque yo también preferiría una cláusula de "doble incriminación", el límite de tiempo ayuda un poco en ese sentido. Si bien no se indica, imagino que sería bastante difícil aclarar cualquiera de estos pasos para algo ya litigado. Para el elemento 2, tenemos Wikipedia: administradores abiertos a recordar / solicitudes pasadas , así que me lo imagino. El 3, no es algo que se haga típicamente en ArbCom, entonces, ¿por qué estaría aquí? ~ Amory ( u • t • c ) 11:48, 22 de febrero de 2021 (UTC)
- Estuve escribiendo lo suficiente en mi apoyo arriba, pero pensé en una forma diferente de doble incriminación: ¿puede un administrador estar sujeto tanto a un caso de ArbCom como al proceso de la comunidad? Siendo realistas, creo que no es probable que ArbCom acepte un caso en el que la comunidad haya pasado por el proceso y no haya eliminado el sysop (pero habría mucha presión en la situación de mayoría insuficiente que discutí anteriormente, por lo que ciertamente es posible). Pero, ¿y al revés? Una persona va a ArbCom, hay un caso, ArbCom se niega a eliminar sysop. ¿Podría la comunidad aún lanzar este proceso? Creo que sí y creo que también es poco probable que la comunidad elimine el sysop (en otras palabras, espero que tanto la comunidad como ArbCom respeten las decisiones a las que llega el otro grupo), pero sería más desagradable para el administrador específico. Creo que no podemos eliminar esta forma de doble riesgo, pero definitivamente estoy a favor de eliminar el doble riesgo que Worm describe aquí. Lo mejor, Barkeep49 ( charla ) 16:16, 22 de febrero de 2021 (UTC)
- Amorymeltzer , ¿Qué es "IANATB"? - RoySmith
(charla) 21:03, 22 de febrero de 2021 (UTC)
- @ RoySmith : Worm hizo algunas preguntas a
TonyBallioni y cualquier otra persona que esté trabajando duro en esto
. Me importa el tema, pero no presumiría decir que he estado trabajando duro en ello. Ciertamente no al grado que Tony tiene en la creación de esto, así que cuando respondí, quería aclarar que no soy un TonyBallioni (fue alegre). ~ Amory ( u • t • c ) 21:54, 22 de febrero de 2021 (UTC)
- @ RoySmith : Worm hizo algunas preguntas a
- Ese número 4 es muy interesante, gusano , y merece un cálculo rápido: ¿cuántos administradores desocupados han seguido editando? ¿Cuántos administradores desocupados eran realmente muy visibles y / o estaban totalmente comprometidos en Wikipedia? Sé que dejé por completo de realizar ediciones proactivas. Kudpung กุด ผึ้ง ( charla ) 11:38, 22 de febrero de 2021 (UTC)
- Publiqué esto como un apéndice a mi comentario de "apoyo", pero con todas las múltiples discusiones secundarias aquí, lo comentaré nuevamente. En lugar de simplemente requerir un incidente AN o ANI pasado, sugeriría que también haya diferencias que muestren que el administrador posteriormente rechazó o ignoró el consenso de esa discusión. En otras palabras, si el administrador dijo que no aceptaba que había hecho algo mal y seguía haciéndolo, entonces esa sería una razón para invocar el procedimiento propuesto aquí, pero si en cambio el administrador hubiera dicho que lo seguiría. con la voluntad de la comunidad y no volver a hacerlo, y mantener su palabra, entonces no habría oportunidad de desysop. Creo que eso eliminaría gran parte del potencial de uso indebido del proceso y la necesidad de estar mirando por encima del hombro. - Tryptofish ( charla ) 21:13, 22 de febrero de 2021 (UTC)
- Estoy de acuerdo en principio pero no en la práctica. Creo que los criterios, tal como están ahora, causarán suficiente angustia y desafío para los crats. No quiero superponer otros criterios, y uno que requiera un juicio aún más subjetivo, además del proceso. En cambio, creo que debemos tener fe en que la comunidad rechazará una propuesta en la que el administrador ya ha dicho "Me equivoqué y lo haré mejor" por primera vez. Para los segundos incidentes y más allá, entonces se convierte en una cuestión de juicio para que la comunidad decida si van a detenerse o no. Lo mejor, Barkeep49 ( charla ) 21:48, 22 de febrero de 2021 (UTC)
- Creo que se abordará en el nivel de endosos antes de que los Crats tengan que pasar por problemas por ello. Y hay una cuestión de calibración con respecto a la confianza en la comunidad. Me parece que mejora el proceso si "Me equivoqué y lo haré mejor" se pone explícitamente fuera de los límites desde el principio, o al menos hace que la propuesta responda mejor a las preocupaciones de muchos de los editores que oponerse a ella en su forma actual. - Tryptofish ( charla ) 00:27, 23 de febrero de 2021 (UTC)
- Estoy de acuerdo en principio pero no en la práctica. Creo que los criterios, tal como están ahora, causarán suficiente angustia y desafío para los crats. No quiero superponer otros criterios, y uno que requiera un juicio aún más subjetivo, además del proceso. En cambio, creo que debemos tener fe en que la comunidad rechazará una propuesta en la que el administrador ya ha dicho "Me equivoqué y lo haré mejor" por primera vez. Para los segundos incidentes y más allá, entonces se convierte en una cuestión de juicio para que la comunidad decida si van a detenerse o no. Lo mejor, Barkeep49 ( charla ) 21:48, 22 de febrero de 2021 (UTC)
- ¿Qué habría en "solicitud de des-sysop"? Pido disculpas, pero no entiendo. Quiero decir, si un editor alega que el administrador XYZ es un malvado y proporciona evidencias, y si ese RfC está respaldado por 10 ex convictos, incluidos 3 administradores. Entonces, ¿se supone que el administrador acusado debe incluir la solicitud de des-sysop en RfA? ¿Y cuál va a ser esa solicitud? ¿Una declaración de defensa? Creo que será un RfA estándar + una declaración de defensa, ¿verdad? —Usernamekiran (conversación) 20:53, 22 de febrero de 2021 (UTC)
- ¿"Hubo consenso de que el administrador se comportó de manera inapropiada" para referirse a cualquier comportamiento inapropiado o comportamiento en el rol de administrador (uso de herramientas, cierre de discusiones, etc.)? Definitivamente estaría a favor si fuera lo último, pero creo que lo primero está abierto al abuso por parte de los editores con rencor. Si se pretende hacer referencia a este último, ¿podría cambiarse la redacción a "hubo consenso en que el administrador utilizó su estado o herramientas de manera inapropiada"? Saludos, número 5 7 22:01, 22 de febrero de 2021 (UTC)
- Comentario. Permítanme hacer otro lanzamiento para un enfoque alternativo para hacer que los administradores sean más responsables: hacer que el tiempo de una cita de administrador sea limitado por un período específico (digamos 6 años) y requiriendo una reconfirmación de RfA al final del período para aquellos que deseen retener el bit de sysop . Este sistema evitará muchos de los problemas que surgen con respecto a esta propuesta de desusop comunitario. No habrá ningún enlace a ANI y no será necesario solicitar respaldos negativos. Un proceso de reconfirmación de RfA proporciona un formato mucho más positivo y menos conflictivo para analizar el registro de un administrador que un desysop RfA. El proceso será más uniforme y expondrá a la responsabilidad de la comunidad a todos los administradores y no solo a aquellos que obviamente se desviaron o hicieron enojar al usuario equivocado. Los administradores que son relativamente inactivos como administradores (no realizan muchas tareas administrativas) se verán obligados a pensar en su situación con más cautela. Algunos de ellos podrían perderse, pero otros comenzarán a ser más activos y a hacer su parte del trabajo. El proceso de desysop de ArbCom no se verá afectado. Durante su mandato de 6 años, los administradores podrán concentrarse en hacer su trabajo sin la perspectiva de una desagradable elección pública que se cierne sobre ellos. La situación será más predecible y estable. Los administradores que hacen bloqueos difíciles y han lidiado con WP: UNBLOCKABLES aún pueden enfrentar críticas en la reconfirmación de RfA, pero el proceso seguirá siendo mucho menos abiertamente cliquísimo y partidista de lo que probablemente sea el proceso de desysop de la comunidad. Todos los administradores tendrán que ponerse en forma un poco. Nsk92 ( conversación ) 10:45, 23 de febrero de 2021 (UTC)
- incluyendo al menos tres administradores actuales ¿Las opiniones de los no administradores deben ser respaldadas por sus mejores? Crispclear ( charla ) 13:39, 23 de febrero de 2021 (UTC)
- [7] - Ymblanter ( charla ) 15:34, 23 de febrero de 2021 (UTC)
- Si alguien creaba más de 9 cuentas ficticias solo para poder certificar una solicitud contra su odiado administrador enemigo y nadie se daba cuenta de que lo había hecho, lo peor que podría pasar sería que la solicitud se abriera para discusión. Es un chequeo contra algo que probablemente nunca suceda y no importaría si sucediera. Crispclear ( charla ) 16:05, 23 de febrero de 2021 (UTC)
- Muchos usuarios bloqueados mantienen varios calcetines activos al mismo tiempo. Recientemente he visto a un usuario bloqueado después de haber sido reportado por un calcetín, y otro que se acerca después de haber sido reportado por un calcetín. Si bien es poco probable que diez calcetines del mismo usuario certifiquen un desysop, el hecho es que convertirse en administrador es prácticamente la única situación relevante en la que se necesita la investigación de antecedentes de la comunidad. Esto puede ser bueno o malo, pero es lo que es .-- Ymblanter ( charla ) 16:14, 23 de febrero de 2021 (UTC)
- Pero incluso si este usuario imaginario lograra usar sus 10 cuentas para obtener la certificación de la solicitud de desysop, eso solo lo movería a la fase de discusión donde necesitarían otras 3 cuentas ficticias por cada 2 usuarios genuinos que votaron para no revocar el sysop. Si 20 personas votaron en contra de la revocación, el usuario necesitaría 30 usuarios ficticios no detectados para votar por ella. Honestamente, si se han tomado tantas molestias y se las han arreglado para hacerlo sin ser detectados en un foro donde serán examinados, entonces a) tenemos problemas más grandes que un administrador poco fiable yb) probablemente deberíamos recompensarlos. por el esfuerzo. Crispclear ( charla ) 16:31, 23 de febrero de 2021 (UTC)
- @ Crispclear : - una de las razones es que está asumiendo que no hay nada negativo salvo que un administrador realmente sea desysopted. Excepto que ese no es el caso. Un RfA regular ya es algo desagradable y tú eliges cuándo hacerlo. Podemos suponer que cualquier desysop RfA será, en el mejor de los casos, tan bueno como uno normal y, en el peor, horrible. Ser sometido por uno, incluso si finalmente se confirma a un candidato, es un gran negativo. Nosebagbear ( charla ) 20:03, 23 de febrero de 2021 (UTC)
- Pero ese escenario solo ocurrirá si este usuario imaginario con un rencor que lo consume todo es una especie de figura de Moriarty que mueve los hilos detrás de escena con decenas o cientos de cuentas ficticias de alguna manera indetectables mientras arrastran lentamente a su víctima desconcertada e indefensa sobre las brasas. No va a suceder y legislar como si fuera una situación probable es una pérdida de tiempo. Crispclear ( charla ) 01:55, 24 de febrero de 2021 (UTC)
- No asume que en lo más mínimo, ¿de dónde vinieron "decenas o centenas"? Parece que se agregó solo para florecer retórico y maldita sea con precisión. Mi punto es el de ser arrastrado al proceso como algo negativo. De hecho, se necesitaría una gran cantidad para que una persona deshonesta lograra que alguien fuera eliminado solo a través de su ejército de calcetines, pero estoy hablando de simplemente ser arrastrado a través del proceso de respaldo, que requeriría mucho menos, y ciertamente menos de lo que hemos visto por múltiples maestros de calcetines en el pasado. Nosebagbear ( charla ) 11:22, 24 de febrero de 2021 (UTC)
- Se requeriría un mínimo de 10 cuentas falsas no detectadas para obtener la certificación de una solicitud frívola (ok ... 9 más el "maestro"), y luego dos cuentas para contrarrestar cada voto para no revocarlo. Si la solicitud no tenía fundamento, entonces presumiblemente el administrador tendría numerosos partidarios, por lo que fácilmente llega a "decenas o cientos". Presumiblemente, cualquiera que odie tanto a un administrador que esté dispuesto a arriesgar su precioso ejército de cuentas falsas previamente no detectadas no querría hacerlo por un proceso que simplemente conducirá a que su enemigo sea respaldado y reciba el beneficio de inmunidad a través del doble riesgo. Para ser honesto, si son tan buenos para fingir un compromiso genuino en tantas cuentas, probablemente también tengan algunas cuentas de administrador. Crispclear ( charla ) 12:38, 24 de febrero de 2021 (UTC)
- Sigues saltando a las "dos cuentas para contrarrestar"; mi punto es que lo negativo se alcanza tan pronto como pasas la etapa de 10 personas, incluso si finalmente no estás desanimado, debido a lo desagradable de esa etapa. No puedo entender por qué sigues cubriendo esa parte cuando no formaba parte de mi respuesta original. Tampoco existe inmunidad de doble incriminación, excepto según lo acordado socialmente por las personas que toman sus propias decisiones sobre el tema. Nosebagbear ( charla ) 16:57, 24 de febrero de 2021 (UTC)
- Porque este escenario es aún más irreal si imaginas que este genio malvado se contentará con simplemente certificar su denuncia. ¿Por qué arriesgar nueve o más de sus cuentas ficticias meticulosamente mantenidas para obtener una queja certificada que será inmediatamente descartada por todos como infundada? La destrucción será el objetivo, no una tormenta en una taza de té que se acaba antes de que haya comenzado y solo sirve para resaltar la connivencia entre las cuentas de certificación. El proceso para tratar las quejas genuinas puede ser perjudicial para el administrador, pero no para las acciones frívolas. Y la "doble incriminación" será de facto: nadie va a abrir una segunda solicitud sobre las mismas acciones. Acabo de buscar usuarios "confirmados extendidos" y deben tener 500 ediciones, por lo que solo para la confirmación, tendrá que haber 5000 ediciones detrás de las cuentas de certificación (más que eso en realidad, ya que exactamente 500 ediciones por cuenta serán sospechosas , y una cosa que sabemos acerca de este editor imaginario es que están seguros de que no sospechan). Cuanto más veo el compromiso de este enemigo imaginario, más creo que, si alguna vez existiera, certificar su denuncia sería lo mínimo que podríamos hacer para agradecerles sus aportes. Crispclear ( charla ) 09:38, 25 de febrero de 2021 (UTC)
- Sigues saltando a las "dos cuentas para contrarrestar"; mi punto es que lo negativo se alcanza tan pronto como pasas la etapa de 10 personas, incluso si finalmente no estás desanimado, debido a lo desagradable de esa etapa. No puedo entender por qué sigues cubriendo esa parte cuando no formaba parte de mi respuesta original. Tampoco existe inmunidad de doble incriminación, excepto según lo acordado socialmente por las personas que toman sus propias decisiones sobre el tema. Nosebagbear ( charla ) 16:57, 24 de febrero de 2021 (UTC)
- Se requeriría un mínimo de 10 cuentas falsas no detectadas para obtener la certificación de una solicitud frívola (ok ... 9 más el "maestro"), y luego dos cuentas para contrarrestar cada voto para no revocarlo. Si la solicitud no tenía fundamento, entonces presumiblemente el administrador tendría numerosos partidarios, por lo que fácilmente llega a "decenas o cientos". Presumiblemente, cualquiera que odie tanto a un administrador que esté dispuesto a arriesgar su precioso ejército de cuentas falsas previamente no detectadas no querría hacerlo por un proceso que simplemente conducirá a que su enemigo sea respaldado y reciba el beneficio de inmunidad a través del doble riesgo. Para ser honesto, si son tan buenos para fingir un compromiso genuino en tantas cuentas, probablemente también tengan algunas cuentas de administrador. Crispclear ( charla ) 12:38, 24 de febrero de 2021 (UTC)
- No asume que en lo más mínimo, ¿de dónde vinieron "decenas o centenas"? Parece que se agregó solo para florecer retórico y maldita sea con precisión. Mi punto es el de ser arrastrado al proceso como algo negativo. De hecho, se necesitaría una gran cantidad para que una persona deshonesta lograra que alguien fuera eliminado solo a través de su ejército de calcetines, pero estoy hablando de simplemente ser arrastrado a través del proceso de respaldo, que requeriría mucho menos, y ciertamente menos de lo que hemos visto por múltiples maestros de calcetines en el pasado. Nosebagbear ( charla ) 11:22, 24 de febrero de 2021 (UTC)
- Pero ese escenario solo ocurrirá si este usuario imaginario con un rencor que lo consume todo es una especie de figura de Moriarty que mueve los hilos detrás de escena con decenas o cientos de cuentas ficticias de alguna manera indetectables mientras arrastran lentamente a su víctima desconcertada e indefensa sobre las brasas. No va a suceder y legislar como si fuera una situación probable es una pérdida de tiempo. Crispclear ( charla ) 01:55, 24 de febrero de 2021 (UTC)
- @ Crispclear : - una de las razones es que está asumiendo que no hay nada negativo salvo que un administrador realmente sea desysopted. Excepto que ese no es el caso. Un RfA regular ya es algo desagradable y tú eliges cuándo hacerlo. Podemos suponer que cualquier desysop RfA será, en el mejor de los casos, tan bueno como uno normal y, en el peor, horrible. Ser sometido por uno, incluso si finalmente se confirma a un candidato, es un gran negativo. Nosebagbear ( charla ) 20:03, 23 de febrero de 2021 (UTC)
- Pero incluso si este usuario imaginario lograra usar sus 10 cuentas para obtener la certificación de la solicitud de desysop, eso solo lo movería a la fase de discusión donde necesitarían otras 3 cuentas ficticias por cada 2 usuarios genuinos que votaron para no revocar el sysop. Si 20 personas votaron en contra de la revocación, el usuario necesitaría 30 usuarios ficticios no detectados para votar por ella. Honestamente, si se han tomado tantas molestias y se las han arreglado para hacerlo sin ser detectados en un foro donde serán examinados, entonces a) tenemos problemas más grandes que un administrador poco fiable yb) probablemente deberíamos recompensarlos. por el esfuerzo. Crispclear ( charla ) 16:31, 23 de febrero de 2021 (UTC)
- Muchos usuarios bloqueados mantienen varios calcetines activos al mismo tiempo. Recientemente he visto a un usuario bloqueado después de haber sido reportado por un calcetín, y otro que se acerca después de haber sido reportado por un calcetín. Si bien es poco probable que diez calcetines del mismo usuario certifiquen un desysop, el hecho es que convertirse en administrador es prácticamente la única situación relevante en la que se necesita la investigación de antecedentes de la comunidad. Esto puede ser bueno o malo, pero es lo que es .-- Ymblanter ( charla ) 16:14, 23 de febrero de 2021 (UTC)
- Si alguien creaba más de 9 cuentas ficticias solo para poder certificar una solicitud contra su odiado administrador enemigo y nadie se daba cuenta de que lo había hecho, lo peor que podría pasar sería que la solicitud se abriera para discusión. Es un chequeo contra algo que probablemente nunca suceda y no importaría si sucediera. Crispclear ( charla ) 16:05, 23 de febrero de 2021 (UTC)
- [7] - Ymblanter ( charla ) 15:34, 23 de febrero de 2021 (UTC)
- Comentario. Busqué el procedimiento en Wikipedia en alemán y utilizan un enfoque de recuperación diferente que me parece mejor. En lugar de desysop RfA, tienen RfA de reconfirmación obligatorios que se activan mediante un determinado proceso de certificación. (En su caso, si 25 usuarios dentro de un mes o 50 usuarios dentro de 6 meses respaldan una llamada para una reconfirmación de RfA para un administrador determinado). Cuando ocurre una reconfirmación de RfA, el umbral para pasarlo es el mismo que para pasar un RfA inicial. La comunidad vota no sobre si desysop a alguien, sino sobre si alguien cumple con los requisitos para ser administrador. Creo que su enfoque es menos conflictivo y negativo que la propuesta que estamos considerando aquí. Si usáramos su modelo, tendríamos que ajustar los números requeridos para la certificación y tal vez requerir que algunos de los patrocinadores sean administradores. También me hubiera gustado más la propuesta actual si, incluso bajo el mismo proceso de certificación que se propone actualmente, el RfA posterior se ejecuta como un RfA de reconfirmación en lugar de un RfA de recuperación / desysop, con el mismo umbral de paso para ser utilizado por los crats que para nuevos RfAs. Nsk92 ( conversación ) 16:18, 23 de febrero de 2021 (UTC)
- Estoy de acuerdo con esta propuesta. Me preocupa que una propuesta de desysop de la comunidad pueda volverse muy desordenada y polémica a medida que los usuarios se apresuran a pintar al administrador con la luz más dura. No estoy seguro de si una reconfirmación de RfA resuelve esos problemas, pero al menos las personas serían más propensas a abogar por un resultado positivo. - Enos733 ( conversación ) 17:11, 23 de febrero de 2021 (UTC)
- El punto que más me molesta es que parece haber solo comprobaciones limitadas contra un ataque coordinado fuera de la wiki en aquellos administradores que se ocupan de contenido pago o que protegen contra los empujadores de PoV. Es trivial generar cuentas que califiquen. Espresso Addict ( charla ) 23:53, 23 de febrero de 2021 (UTC)
- Si mal no recuerdo, en una discusión reciente, alguien compiló las políticas de desysop de Wikipedias en otros idiomas y pensé que era útil para comparar. ¿Podría alguien volver a publicar eso, si existe? zar 04:38, 24 de febrero de 2021 (UTC)
Wikipedia: Solicitudes de comentarios / sentimiento de la comunidad de 2019 sobre el procedimiento de desysop vinculante § Descripciones de los sistemas de desadministración en otros proyectos zar 04:41, 24 de febrero de 2021 (UTC)
- Cosas fascinantes. Gracias Zar. Si los wikis de otros idiomas manejan este tipo de cosas, no veo por qué el wiki en inglés no puede hacerlo. // Lollipoplollipoplollipop :: talk 15:51, 4 de marzo de 2021 (UTC)
- Creo que SD0001 y Gatoclass hicieron un buen punto en la discusión de la declaración de SD0001. ¿Qué motivaría al comité de arbitraje a aceptar un caso para examinar el comportamiento de un administrador en una situación que no es de emergencia? El comité de arbitraje sirve como último recurso para lidiar con la conducta del editor, por lo que, en teoría, se debe intentar primero un proceso de revisión del administrador iniciado por la comunidad. Sospecho que tendría que haber circunstancias muy irregulares en ese proceso de revisión para que el comité de arbitraje acepte posteriormente un caso y anule los resultados del primer proceso de revisión. isaacl ( charla ) 21:30, 24 de febrero de 2021 (UTC)
Sobre hipotéticos
La política nunca es perfecta a la primera. Los gobiernos emplean ejércitos de analistas y asesores de políticas cuyo trabajo es revisar y renovar las reglas y procedimientos existentes para hacer frente a los escenarios cambiantes y abordar las consecuencias imprevistas. El trabajo se considera iterativo: se elabora una política, se evalúa a medida que pasa el tiempo y se realizan las modificaciones necesarias para lograr la intención detrás de la política. El estándar para la primera iteración es que toma en cuenta adecuadamente los riesgos potenciales al mismo tiempo que proporciona el beneficio esperado.
El proceso que Tony ha propuesto tiene amplias salvaguardias contra el uso del proceso como acoso, el doble de lo que la mayoría de los proyectos hermanos usan como estándar antes de una solicitud de desysop. En lugar de preocuparnos por cada escenario hipotético potencial, sugiero que nos centremos en dos cosas: primero, la evidencia, que es que en Meta / Commons / Wikidata (los tres procesos de desysop con los que estoy familiarizado) no se abusa del proceso de desysop como un forma de acoso. En segundo lugar, el hecho de que esta propuesta es lo suficientemente buena , lo que significa que logrará el beneficio deseado y se ha pensado explícitamente en mitigar los riesgos. Y si el proceso no funciona como se esperaba, podemos cambiar estas reglas una vez que se establezcan.
Nosotros, como comunidad, hemos decidido que debería haber un proceso de desysop comunitario. Intentemos implementar uno dentro de una década después de que se tomó esa decisión. - Ajraddatz ( charla ) 06:29, 21 de febrero de 2021 (UTC)
- Es evidente que se necesita algún sistema alternativo y, dado que TonyBallioni no es amigo de los comités de arbitraje, esta propuesta no sorprende. WP: BARC lanzado por mí con el apoyo de Worm That Turned hace casi una década fue un intento de deshacerse de la comunidad sin la interferencia del estilo ANI o los usuarios no involucrados y los titulares de derechos superiores saltando con más amenazas y / o acoso sin haberse familiarizado primero. con el fondo. Si bien algunos sugirieron que podría darles a los 'crats algo que ver con su estado y posición, todavía hay mucha resistencia por parte de la comunidad a forzar tareas en los' crats para los que no se han inscrito; los 'crats mismos dijeron poco sobre el tema. Un usuario parece defender ambas soluciones . A través de nuestro BARC nos enteramos de que primero se debería preguntar a los 'crats' si aceptarían tal extensión de su mandato.
- Hay varias razones muy diferentes para una desobediencia 'por causa'. Algunos son casos claros de flagrante mal uso de las herramientas, conflictos de ruedas, uso de sus herramientas a cambio de pago, etc., mientras que hay otras razones que son más subjetivas y donde la evidencia no es necesariamente clara, es circunstancial, es puramente vengativa o simplemente simple. ferrocarriles. En comparación con el número de administradores que han sido desocupados 'por causa' a lo largo de los años, los Comités de Arbitraje tienen un historial mucho más alto de irregularidades entre sus propios rangos y / o ex miembros. Algunas políticas de Arbcom ya son demasiado vagas y están abiertas a cualquier interpretación que uno quiera hacer para que un caso se mantenga, especialmente en la conocida cultura Wiki de seleccionar y sacar las cosas, de manera deliberada y convincente, fuera de contexto.
- Entre esta propuesta y Arbcom, hay una elección entre el diablo y el mar azul profundo. Como un usuario ya desysoped, no estoy realmente molesta mucho sobre el resultado de este RFC, sino como un usuario retirado, yo voy a salir de su retiro para protestar por los casos que podrían estar inclinándose hacia un veredicto inseguros sobre la base de las reclamaciones y ' Evidencia ', ofrecida por Wikipolice no involucrado, como algunos usuarios ya saben, y especialmente si un administrador está parado en el banquillo y es probable que reciba un castigo por el cual la política de Arbcom no permite apelaciones.
- Esto significa encontrar un procedimiento alternativo de desysop que limite la participación de la galería de maní en lugar de darles aún más alcance y poder. En los últimos tiempos, diversas composiciones de Arbcom han demostrado que, si bien el Comité puede no ser corrupto, sí favorece los reclamos de usuarios no involucrados y muy vociferantes, así como los de sus propios miembros, y aunque es jurado, juez y verdugo. todo en uno, tiende a simplemente leer y ejecutar un consenso de la comunidad y no verifica la veracidad de las afirmaciones de los acusadores, eligiendo una solución que creen que la comunidad quiere escuchar en lugar del bien de la Wipipedia. Por lo tanto, volveré a imprimir el comentario de Nick en su totalidad:
El sistema ArbCom siempre ha sido deficiente. ArbCom puede dar forma a los casos para que se adapten a sus propias opiniones sobre el tema del caso, pueden elegir si aceptan el caso, ya limitan la cantidad de pruebas y pueden negarse a escuchar más pruebas, y luego pueden proponer resultados que adaptarse a su perspectiva de la edición. También hay un gran intercambio de ideas entre bastidores para asegurar el apoyo a las propuestas. Es como una versión más o menos de mierda de un juicio político presidencial
,
- No repetiré aquí todos los comentarios de Beeblebrox , Tarl N. y Peter Southwood , pero son acertados y ciertamente los apoyo. Kudpung กุด ผึ้ง ( charla ) 07:17, 21 de febrero de 2021 (UTC)
- Con respecto al comentario de Kudpung sobre " Arbcom se ha hecho una tarea fácil para ellos en los últimos tiempos, casi alineando a los administradores contra la pared y disparándolos en una sesión ", no estoy de acuerdo. En el caso de RHaworth, tomó años de múltiples hilos ANI, avisos de páginas de discusión, charlas en el pub, y el caso final de Arbcom solo sucedió porque sucedió algo terriblemente mal que lo llevó al límite. Más concretamente, destruyó a RHaworth, el editor que ahora es solo un gruñón amargado por haber sido abandonado, en contraposición a alguien con quien podría trabajar escribiendo sobre arquitectura en el sur de Londres. Y el desysop de Fram solo ocurrió debido a un deus ex machina (sean cuales sean sus puntos de vista sobre Fram, no puede negar que una cantidad significativa de personas se opuso a su administración como se demostró en el RfA posterior; para el registro, creo que Fram ha mejorado desde y no tengo opiniones sólidas sobre él dirigiendo una RfA ahora).
- También estoy realmente sorprendido de ver a Leaky calderón oponiéndose a esto. Habría asumido que estaría firmemente a favor de aumentar la responsabilidad de los administradores y mejorar los mecanismos de sanción. Ritchie333 (charla) (continuación) 10:26, 21 de febrero de 2021 (UTC)
- Ritchie333 Mi oposición, debería haberlo dejado más claro, no se trata de la proposición per se y, si se reflexiona, un apoyo cauteloso o neutral habría sido más apropiado. La principal preocupación que tengo es que se requiere la defensa de 3 compañeros miembros del administrador. brigada será insuperable en el caso de algunos individuos de alto perfil. 2 administradores activos. el apoyo debería ser más que suficiente para respaldar un caso comunitario. Caldero con fugas ( charla ) 10:59, 21 de febrero de 2021 (UTC)
- Caldero con goteras , lo vi como algo que la comunidad podría cambiar fácilmente si no funciona. Nuevamente, el requisito se estableció específicamente para tratar casos de disputas étnicas, donde pude ver que había dos administradores en un "lado" de una disputa que certificaban un caso sin fundamento (hay muchas disputas étnicas y muchos administradores heredados. ) Tres se sintió como un número seguro para lidiar con esto. Creo que es posible ajustarlo a la baja, pero mi objetivo con esta propuesta fue lo que señaló Ajraddatz, proporcionar un marco que pudiera ajustarse con la experiencia, y sentí que 3 administradores trabajaron para esos propósitos, ya que sabía que una preocupación importante sería acoso. TonyBallioni ( charla ) 13:27, 21 de febrero de 2021 (UTC)
- Ritchie333 Mi oposición, debería haberlo dejado más claro, no se trata de la proposición per se y, si se reflexiona, un apoyo cauteloso o neutral habría sido más apropiado. La principal preocupación que tengo es que se requiere la defensa de 3 compañeros miembros del administrador. brigada será insuperable en el caso de algunos individuos de alto perfil. 2 administradores activos. el apoyo debería ser más que suficiente para respaldar un caso comunitario. Caldero con fugas ( charla ) 10:59, 21 de febrero de 2021 (UTC)
- [ec] Estoy de acuerdo en que la política rara vez es perfecta, y no se debe esperar que sea, perfecta a la primera. He visto esto en varias iteraciones de la política de salud y seguridad en las que he estado involucrado, pero a partir de esa experiencia he visto que un cambio relativamente gradual generalmente causa menos dolor y asombro general que un swing revolucionario, que a menudo es seguido por un swing. en la dirección opuesta como reacción al cambio cuando se ve excesivo. Desde el punto de vista de la ingeniería, queremos una oscilación muy amortiguada alrededor de donde creemos que queremos estar en lugar de sobrepasar y establecer un bucle de retroalimentación positiva inestable. Un período de prueba con un límite de tiempo específico y una fecha para la próxima revisión es probablemente una buena idea, y es una práctica estándar en SSO (SST para algunos). Me gustaría ver un dolor mínimo infligido a todos los involucrados en las primeras etapas, ya que habrá algunos con sus cuchillos, ya sea por venganza o para promover una agenda no mencionada. Por otro lado, también creo que hay suficientes de nosotros que estaremos observando el proceso que sería imprudente tratar de salirse con la suya con la venganza o el trabajo político sucio. Aún puede haber consecuencias innecesariamente desagradables, ya que algunos miembros de nuestra comunidad no parecen entender la política de no ataques personales, que deben ser aplicadas estrictamente por los empleados designados para ese propósito específico y que han demostrado su competencia para identificar el rango de ataques ad hominem. argumentos comunes en nuestras disputas. · · · Peter Southwood (charla) : 13:51, 21 de febrero de 2021 (UTC)
- El problema que tengo con esto es que, por poco que confío en las decisiones de arbitraje, confío mucho menos en AN / I. (y he dicho ambas cosas antes de ser elegido para arb com, mientras estaba en arb com, y pienso lo mismo ahora que ya no estoy en arb com.) Arb com a menudo no actúa debido a su tendencia tolerar a las personas hasta que hacen una cosa horrible específica, e incluso cuando actúa, no es necesariamente consistente. AN / I avanza demasiado rápido, tiende a tomar decisiones basadas en los puntos de vista de muy pocas personas y es demasiado susceptible a los rencores y las cábalas. No me gusta usar AN / I como puerta de entrada a nada, y si lo usamos, deberíamos requerir al menos dos incidentes separados. (No hay necesidad de desysop de la comunidad cuando se necesita una acción rápida y drástica - arb com lo hace bien - y muchas de ellas involucran privacidad y, por lo tanto, no se realizan en público). DGG ( charla ) 02:46, 23 de febrero de 2021 (UTC)
- Estoy contigo en ANI, pero las partes más difíciles de crear este proceso siempre han sido la aceptación y la entrada en la discusión de la comunidad. Sabemos cómo tener discusiones dirigidas a algún tipo de consenso, por lo que llegar allí requiere un sistema establecido que todas las personas puedan aceptar, incluso a regañadientes. ANI es malo, pero AN / I es lo que tenemos. Están establecidos, bien pisados y no van a ninguna parte. No tenemos una alternativa razonable sin crear algo de tela completa, que no creo que tenga aceptación. ~ Amory ( u • t • c ) 11:15, 23 de febrero de 2021 (UTC)
- ANI puede y debe ser arreglado comenzando con las aspersiones, PA, juegos y ferrocarriles POV . La mayoría de los administradores ya saben lo que sucede en los foros de drama, pero muchas veces, cuando no tienen un perro en la pelea, prefieren no involucrarse y ¿quién puede culparlos? Irónicamente, esos son los administradores que necesitamos en la discusión. La discusión en sí debe llevarse a cabo de manera ordenada y civilizada. Los editores han aprendido hace mucho tiempo que algunos administradores no leen diferencias más allá de los primeros 3 a 5, y es muy poco probable que se hayan tomado el tiempo para leerlos en contexto ... o si hay muchos, elegirán algunos en aleatorio. No dudo que dependen más de las aportaciones de otros editores / administradores en los que confían. Lo que encuentro más desconcertante es cómo se ignoran las aspersiones y los PA, incluso los ArbCom anteriores son culpables de ese comportamiento en menor grado, mientras que lo veo como el primer lugar donde se deben realizar cambios. No involucrado es otro criterio que no solo necesita una reflexión seria, necesita implementación lo antes posible. Lo que tenemos ahora es la familia y amigos de la víctima y la familia y amigos del acusado sentados en el jurado, y es muy posible que uno supere al otro dependiendo de la popularidad y la tenencia, y para apoyar esa afirmación me referiré a mi referencia favorita, la hegemonía del gilipollas del consenso. Debe haber una sección separada para los EDITORES NO INVOLUCRADOS iVoting en ANI, y solo esos iVotes deben ser tomados en consideración. Los secretarios deben advertir rápidamente a un editor que ha emitido aspersiones, eliminar la aspersión y evitar que ese editor participe en el iVote a menos que ese editor pueda proporcionar las diferencias necesarias para respaldar la (s) aspersión (es). Lo mismo se aplica a las AP flagrantes. Los iVotes de los "habituales" de ANI no deberían contar en absoluto si tienen un historial con el editor "en juicio", ya sea en ese caso en particular o en otro, la historia es importante. Creo que si comenzamos por ahí, estaremos en el camino correcto para reducir el drama y ayudar a hacer de ANI / AN / ArbCom un lugar mucho más colegiado para resolver nuestras diferencias. Atsme 💬 📧 14:39, 23 de febrero de 2021 (UTC)
- Ha habido varias propuestas para agregar alguna estructura a ANI. Hace unos años sugerí secretarios, basándome en su gran ayuda con los procedimientos de arbitraje (y en SPI, fue rechazada por no querer agregar otra capa de burocracia. La alternativa a la burocracia humana es lo que llamaré el " burocracia de los formularios "- confiando en plantillas y secciones. Puede que funcione, pero personalmente me desagradan tanto que rara vez participo en procesos que los usan - y si lo hago, como en los cambios solicitados para coi, comento gratis- forma, ignorando las formas. Pero creo que Atsme tiene razón al decir que necesitamos una definición mucho más rigurosa de "involucrado". Aquí también hice una propuesta anterior, que nadie participe con demasiada frecuencia en ANI o procedimientos similares con respecto a la misma tema o el mismo editor: una vez que lo ha hecho en un grado significativo, como sancionar o cerrar, esencialmente ha formado una vista fija, incluso si no es consciente de ello. DGG ( charla ) 07:15 , 24 de febrero de 2021 (UTC)
- Disculpe si ya se ha abordado anteriormente (solo leí aproximadamente la mitad de estos puntos). ¿Tenemos alguna idea sobre cómo funcionaría realmente un RfD (desysop) en la práctica? ¿Abriría la página con la persona que nomina al usuario justificando por qué es necesario? ¿Incluye esto preguntas como en un RpA regular? Siento que necesitamos un procedimiento para esto, pero hay algunas preguntas sobre cómo funciona exactamente que me gustaría confirmar antes de la implementación. Best Wishes, Lee Vilenski ( discusión • contribuciones ) 19:55, 23 de febrero de 2021 (UTC)
- No he profundizado en todos los antecedentes de este tema, pero ¿no sería más fácil simplemente imponer un límite de plazo para los administradores y requerir un nuevo RfA si quieren conservar las herramientas? Eso eliminaría a los administradores inactivos o malos. Si existe preocupación por la votación de rencor, se podría reducir el porcentaje de apoyo necesario para que los titulares pasen. Supongo que esto ha sido discutido y rechazado por alguna razón, pero no puedo adivinar cuál fue el argumento opuesto. Argento Surfer ( charla ) 14:01, 25 de febrero de 2021 (UTC)
- @ Argento Surfer : Supongo que te refieres a la duración de una cita en lugar de un límite en el número de veces que uno puede atender; El mayor desafío con eso es que tenemos 1.090 sysops; ejecutar tantos RfA completos incluso en la primera ronda sería una barrera logística. - Charla xaosflux 14:26, 25 de febrero de 2021 (UTC)
- ¡Ah! Sí, eso tiene sentido. ¡Gracias! Argento Surfer ( charla ) 14:57, 25 de febrero de 2021 (UTC)
- @ Xaosflux Creo que este no es un problema tan aterrador como usted lo hace parecer. Primero, un número sustancial de esos 1,111 operadores de sistema simplemente no optarán por ejecutarse para confirmación. En segundo lugar, incluso si asumimos que todas esas personas se postularán, podemos ponerlas en tramos cuando establezcamos los límites de mandato iniciales. Sabemos que RfA puede manejar cientos de RfA al año . Por lo tanto, dividimos a los sysops existentes de manera que todos los que hayan prestado servicios durante más de un período de 3-5 años (no puedo imaginar un período de menos de 5 años y, honestamente, espero que termine más cerca de 10 ). Si decidimos que queremos confirmar a los administradores, este es un problema muy solucionable. Simplemente no creo que hayamos decidido que queremos eso. Saludos , Barkeep49 ( charla ) 15:57, 25 de febrero de 2021 (UTC)
- @ Barkeep49 : ciertamente hay formas de hacerlo, eso fue solo un resumen rápido de una de las oposiciones más grandes del pasado. Incluso podríamos hacer una ronda de "votación" simple como lo hacemos con la confirmación del administrador a nivel mundial (tal vez solo haga que el proceso completo de RfA sea necesario para aquellos que no obtienen un voto simple). - Charla xaosflux 16:07, 25 de febrero de 2021 (UTC)
- Xaosflux , estoy de acuerdo con Barkeep49 . hay un problema en que RFA alcanzó su punto máximo entre 2005 y 2008, con ~ 1350 administradores creados en ese período, en comparación con ~ 400 después, así que supongamos que cualquier término que se nos ocurra incluiría aproximadamente 3/4 del número de sysops fuera de. Como sugiere Barkeep, una parte significativa optará por no postularse para la reconfirmación (digamos, hasta 1/4 del resto). Estamos buscando entre 600 y 800 reconfirmaciones para gestionar. Distribuya el resto a lo largo de 50 semanas, y solo verá de 12 a 16 por semana. Póngalo a lo largo de 2 años, y puede la mitad.
- Es más, esperaría un sistema de confirmación más liviano, en lugar de un RfA completo (por ejemplo, ¡los votos centrados en su comportamiento como administrador y no en razones ideológicas más amplias) Worm TT ( charla ) 16:13, 25 de febrero de 2021 (UTC )
- Estoy de acuerdo si hay un testamento, se puede encontrar una manera. Pero no tengo claro si realmente existe la voluntad de que suficientes miembros de la comunidad proporcionen una revisión significativa de, digamos, 6-8 administradores a la semana durante cien semanas consecutivas, y luego continúe a un ritmo de, digamos, 3-4 a la semana si hay un plazo de 5 años para administradores. También es necesario que haya voluntarios para administrar el cronograma y asegurarse de que ocurran en un momento adecuado: ya sea para configurarlo cuando el administrador esté disponible o para confirmar que no les importa tenerlo en cualquier momento. (Algunos pueden querer votar por adelantado si van a estar ausentes; supongo que se puede configurar una página de votación con mucha anticipación, con una hora programada para el cierre). Por supuesto, esta puede ser la mejor manera de avanzar. para hacer la transición a términos fijos. Sin embargo, creo que debemos calibrar las expectativas: para muchos administradores, la revisión será pro forma, aunque es probable que eso esté bien para la mayoría de los administradores. isaacl ( charla ) 16:46, 25 de febrero de 2021 (UTC)
- Isaacl , no estoy muy preocupado por la programación. Si un administrador sabe que no estará disponible cuando venza el suyo, puede programar la revisión con anticipación para restablecer el reloj. O deje que su mandato expire, trate esto como si renunciara, no bajo una nube, y ejecute la revisión cuando regrese. - RoySmith
(charla) 17:43, 25 de febrero de 2021 (UTC)
- No me preocupa lo que sucederá con un individuo. Es necesario que haya alguien dispuesto a realizar un seguimiento del programa para todos, a fin de distribuir las revisiones iniciales durante dos años y programar las revisiones cada semana después, a un ritmo más lento. Para garantizar una tasa regular a partir de ese momento, algunos administradores comenzarán con solo dos años entre revisiones, aumentando gradualmente a medida que pasa el tiempo. Todo esto es absolutamente factible, pero algún grupo de voluntarios tendrá que hacerlo, y ese grupo necesitará suficiente membresía activa (con afluencia y salida) para seguir haciéndolo indefinidamente. Wikipedia en inglés tiene programas en curso de larga data para asuntos relacionados con el contenido, pero no creo que haya nada a la misma escala semanal para tareas administrativas. isaacl ( charla ) 17:54, 25 de febrero de 2021 (UTC)
- Me encanta Wikipedia. De verdad que lo hago. Me encanta un lugar donde podemos empantanarnos en detalles sobre un proceso de confirmación hipotético en medio de una discusión sobre un proceso de desysop. Lo mejor, Barkeep49 ( charla ) 17:57, 25 de febrero de 2021 (UTC)
- Los detalles específicos no son importantes y, obviamente, se pueden cambiar. La conclusión clave es que el proceso no se ejecutará por sí solo, por lo que, si bien el desafío puede no dar miedo al Monte Everest, sigue siendo una escalada que debe superarse todas las semanas, de forma indefinida. Eso a veces puede ser más difícil de sostener que un empujón de una sola vez. isaacl ( charla ) 18:04, 25 de febrero de 2021 (UTC)
- Isaacl , estoy seguro de que alguien escribirá un bot para automatizar la mayor parte. - RoySmith
(charla) 18:41, 25 de febrero de 2021 (UTC)
- Ciertamente, parte de ella se puede automatizar; algunos necesitan interacciones con administradores y otros y deben hacerse manualmente. Es posible que algunas tareas no ofrezcan suficiente redundancia o flexibilidad si se dejan únicamente en un proceso automatizado. Lograr que las personas hagan cosas con regularidad en lo que probablemente sería un horario al menos quincenal es un desafío. isaacl ( charla ) 18:53, 25 de febrero de 2021 (UTC)
- Isaacl , estoy seguro de que alguien escribirá un bot para automatizar la mayor parte. - RoySmith
(charla) 18:41, 25 de febrero de 2021 (UTC)
- Los detalles específicos no son importantes y, obviamente, se pueden cambiar. La conclusión clave es que el proceso no se ejecutará por sí solo, por lo que, si bien el desafío puede no dar miedo al Monte Everest, sigue siendo una escalada que debe superarse todas las semanas, de forma indefinida. Eso a veces puede ser más difícil de sostener que un empujón de una sola vez. isaacl ( charla ) 18:04, 25 de febrero de 2021 (UTC)
- Me encanta Wikipedia. De verdad que lo hago. Me encanta un lugar donde podemos empantanarnos en detalles sobre un proceso de confirmación hipotético en medio de una discusión sobre un proceso de desysop. Lo mejor, Barkeep49 ( charla ) 17:57, 25 de febrero de 2021 (UTC)
- No me preocupa lo que sucederá con un individuo. Es necesario que haya alguien dispuesto a realizar un seguimiento del programa para todos, a fin de distribuir las revisiones iniciales durante dos años y programar las revisiones cada semana después, a un ritmo más lento. Para garantizar una tasa regular a partir de ese momento, algunos administradores comenzarán con solo dos años entre revisiones, aumentando gradualmente a medida que pasa el tiempo. Todo esto es absolutamente factible, pero algún grupo de voluntarios tendrá que hacerlo, y ese grupo necesitará suficiente membresía activa (con afluencia y salida) para seguir haciéndolo indefinidamente. Wikipedia en inglés tiene programas en curso de larga data para asuntos relacionados con el contenido, pero no creo que haya nada a la misma escala semanal para tareas administrativas. isaacl ( charla ) 17:54, 25 de febrero de 2021 (UTC)
- Isaacl , no estoy muy preocupado por la programación. Si un administrador sabe que no estará disponible cuando venza el suyo, puede programar la revisión con anticipación para restablecer el reloj. O deje que su mandato expire, trate esto como si renunciara, no bajo una nube, y ejecute la revisión cuando regrese. - RoySmith
(charla) 17:43, 25 de febrero de 2021 (UTC)
- Estoy de acuerdo si hay un testamento, se puede encontrar una manera. Pero no tengo claro si realmente existe la voluntad de que suficientes miembros de la comunidad proporcionen una revisión significativa de, digamos, 6-8 administradores a la semana durante cien semanas consecutivas, y luego continúe a un ritmo de, digamos, 3-4 a la semana si hay un plazo de 5 años para administradores. También es necesario que haya voluntarios para administrar el cronograma y asegurarse de que ocurran en un momento adecuado: ya sea para configurarlo cuando el administrador esté disponible o para confirmar que no les importa tenerlo en cualquier momento. (Algunos pueden querer votar por adelantado si van a estar ausentes; supongo que se puede configurar una página de votación con mucha anticipación, con una hora programada para el cierre). Por supuesto, esta puede ser la mejor manera de avanzar. para hacer la transición a términos fijos. Sin embargo, creo que debemos calibrar las expectativas: para muchos administradores, la revisión será pro forma, aunque es probable que eso esté bien para la mayoría de los administradores. isaacl ( charla ) 16:46, 25 de febrero de 2021 (UTC)
- Sí, utilicé intencionalmente la palabra confirmación en mi respuesta porque esperaría que cualquier sistema que tengamos que ser informado de cerca por el proceso de confirmación exitoso que usan los administradores en lugar del proceso de RfA que usamos para los nuevos administradores (y que tiene más paralelismos con el proceso utilizado para seleccionar nuevos delegados). Lo mejor, Barkeep49 ( charla ) 16:17, 25 de febrero de 2021 (UTC)
- @ Barkeep49 : ciertamente hay formas de hacerlo, eso fue solo un resumen rápido de una de las oposiciones más grandes del pasado. Incluso podríamos hacer una ronda de "votación" simple como lo hacemos con la confirmación del administrador a nivel mundial (tal vez solo haga que el proceso completo de RfA sea necesario para aquellos que no obtienen un voto simple). - Charla xaosflux 16:07, 25 de febrero de 2021 (UTC)
- @ Argento Surfer : Supongo que te refieres a la duración de una cita en lugar de un límite en el número de veces que uno puede atender; El mayor desafío con eso es que tenemos 1.090 sysops; ejecutar tantos RfA completos incluso en la primera ronda sería una barrera logística. - Charla xaosflux 14:26, 25 de febrero de 2021 (UTC)
Diagrama de flujo del proceso
Pensé que podría ser útil producir un diagrama de flujo de proceso para ilustrar este proceso. - Hammersoft ( charla ) 22:10, 23 de febrero de 2021 (UTC)
- Me encanta esto. ¿Por qué no ponerlo en la parte superior? El texto al respecto fue muy confuso para mí. 🐔 ¡ Chicdat Bawk para mí! 11:36, 24 de febrero de 2021 (UTC)
- Un diagrama de flujo / imagen habla más que palabras. Gracias a este @ Hammersoft : ! Nalbarian ( charla ) 14:47, 24 de febrero de 2021 (UTC)
- Gracias de mi parte tambien. Buen trabajo. - Tryptofish ( charla ) 21:04, 24 de febrero de 2021 (UTC)
- Buen trabajo. Esto lo deja más claro. Para algo que se desarrolló porque "el proceso de ArbCom es demasiado difícil", esto es bastante complicado. Beeblebrox ( charla ) 23:37, 24 de febrero de 2021 (UTC)
- Bueno, podría haber sido diseñado esencialmente como una línea vertical recta, simplemente habría ocupado más espacio vertical. No creo que sea complicado en el sentido de tener muchos caminos diferentes que conducen a diferentes acciones. Tiene (por diseño deliberado) muchas condiciones que, si no se cumplen, abortarán el proceso de iniciar una discusión sobre la eliminación de privilegios administrativos o imponer otras sanciones, y luego el proceso para llegar a un consenso en esa discusión. isaacl ( charla ) 23:49, 24 de febrero de 2021 (UTC)
- Buen trabajo. Esto lo deja más claro. Para algo que se desarrolló porque "el proceso de ArbCom es demasiado difícil", esto es bastante complicado. Beeblebrox ( charla ) 23:37, 24 de febrero de 2021 (UTC)
- Gracias de mi parte tambien. Buen trabajo. - Tryptofish ( charla ) 21:04, 24 de febrero de 2021 (UTC)
- Un diagrama de flujo / imagen habla más que palabras. Gracias a este @ Hammersoft : ! Nalbarian ( charla ) 14:47, 24 de febrero de 2021 (UTC)
- Gracias por crear esto, pero el hecho de que lo hiciera prueba mi punto de que es un proceso extremadamente complicado. Es por eso que no puedo apoyarlo .-- Rusf10 ( hablar ) 01:52, 26 de febrero de 2021 (UTC)
- Rusf10 , también hay muchos pasos en el proceso de arbitraje. Es solo que las reglas del proceso de arbitraje evolucionaron con el tiempo, en lugar de desarrollarse de una vez. AGK ■ 09:03, 26 de febrero de 2021 (UTC)
- Estoy de acuerdo. Si necesitamos un diagrama de flujo, es demasiado complicado para algo tan vital como mantener a nuestros administradores bajo control. Sigo apoyando el concepto, pero los detalles necesitan ajustes antes de ser ratificados. Anarchyte ( charla • trabajo ) 10:12, 28 de febrero de 2021 (UTC)
No es 60%, es 40%
El uso de esta propuesta de la cifra del 60% es astutamente engañoso (incluso si no tiene la intención como tal). La mayoría de los usuarios están familiarizados con el umbral de facto del 70% para los RfA y encuentran que la cifra del 60% se acerca a eso. La falacia, que sospecho ha eludido a muchos, es que se trata de un 60% de votos para la eliminación y, por lo tanto, un 40% de votos para la retención, que está muy lejos del 70% requerido para aprobar un RfA. Algunos usuarios han sugerido subir el listón al 65% (léase 35%), lo que me parece asombroso.
Creo que deberíamos empezar a hablar en términos de la cantidad de soporte que necesita un administrador, porque esta es la forma en que estamos acostumbrados a pensar en ello en las RFA. Si la cifra del 40% se hubiera utilizado directamente, esto habría recibido menos apoyo del que tiene. - SD0001 ( conversación ) 13:08, 26 de febrero de 2021 (UTC)
- @ SD0001 : Eh ... eso es un poco extraño. Como uno de los usuarios que sugirió subir el listón, pensé que era un 60% de votos a favor de la retención. Tendré que modificar mi comentario. - MJL - Talk - ☖ 18:16, 26 de febrero de 2021 (UTC)
- Entonces, básicamente, un editor necesita un apoyo abrumador para convertirse en administrador, pero solo necesita el apoyo de una minoría para mantener su estado de administrador. Ese es otro problema con esta propuesta .-- Rusf10 ( hablar ) 01:05, 27 de febrero de 2021 (UTC)
- Consideramos que las RfA son la comunidad que confía a los usuarios algunas herramientas adicionales, por lo que podría tener sentido comparar "qué porcentaje de la comunidad confía en usted". Alternativamente, buscamos un consenso al cambiar el status quo, por lo que tiene sentido considerar un modelo de "consenso para hacer un cambio". Si queremos modificar o eliminar una política, será necesario estar por encima del 60% antes de que sea claro hacerlo. Un sysop puede retener su parte cuando casi la mitad de ArbCom no tiene fe en ellos. Creo que todas estas son comparaciones y analogías defectuosas, pero cada una tiene sus méritos. Me imagino que se hizo principalmente para trazar una línea de demarcación clara y simple. Además, es una propuesta novedosa, por lo que también podríamos comparar el 40% de retención con el 0% actual: no se pierde nada actual. ~ Amory ( u • t • c ) 01:13, 27 de febrero de 2021 (UTC)
- Esa es una frase interesante: "Ese es otro problema con esta propuesta".
- Se le pide que decida entre dos propuestas:
- El 70% necesitaba convertirse en administrador, el 40% necesitaba seguir siendo administrador (esta propuesta pasa).
- El 70% necesitaba convertirse en administrador, el 0,001% necesitaba seguir siendo administrador (esta propuesta falla).
- ¿Y solo ve un problema con la primera de esas dos opciones?
- Nota: Calculé ese 0,001% asumiendo que todas las personas en Wikipedia, excepto algunos miembros de arbcom, quieren deshacerse del administrador. - Guy Macon ( charla ) 01:23, 27 de febrero de 2021 (UTC)
- Bueno, el factor porcentual debe corregirse antes de aprobarlo. A menos que logremos un 60% o 70% para seguir siendo un administrador en una nominación de de-sysop, entonces todo es inútil. Necesitamos pasar algo que funcione, algo que evite el sistema de amigos, donde un administrador dado tiene suficientes amigos entre otros administradores para que sus amigos descarrilen cualquier proceso de des-sysop. De lo contrario, se convierte en una burla incluso iniciar un proceso de des-sysop. - Maile ( conversación ) 01:30, 27 de febrero de 2021 (UTC)
- Eso es lo que me preocupa de esta propuesta. Cualquier administrador problemático popular podría reunir un 35-40% de apoyo. Según esta propuesta, no serían eliminados, pero ArbCom podría hacerlo. Si se aprueba esta propuesta, es probable que ArbCom ya no toque el caso (“envíelo a la comunidad”). Si esto sucediera, esta propuesta sería una neta negativa seria. ProcrastinationReader ( charla ) 10:04, 27 de febrero de 2021 (UTC)
Se le pide que decida entre dos propuestas ... ¿Y sólo ve un problema con la primera de esas dos opciones?
Sí, porque solo el primero encierra una mala política; una política que es poco probable que se convierta en una buena política a través del cambio evolutivo. El segundo deja abierta la posibilidad de que se proponga y acepte una buena política. No es una decisión única y binaria, y rechazo esa dicotomía.También podríamos comparar el 40% de retención con el 0% actual: no se pierde nada actual.
Se perdería el potencial de una buena política. - Ryk72 talk 01:56, 27 de febrero de 2021 (UTC)- Así que Guy básicamente está haciendo el argumento de que "es mejor que nada". Sí, el proceso actual no es bueno y tampoco lo es esta propuesta. No voy a dar apoyo a algo que porque puede ser un poco mejor que el status quo, presentaré una propuesta mejor y luego la apoyaré .-- Rusf10 ( charla ) 01:34, 28 de febrero de 2021 (UTC )
- Guy , tu punto está tomado, pero en aras de la aritmética deberíamos ser realistas; creo que el 0,001% probablemente sea incorrecto. La mayoría de las RFA solo obtienen hasta un par de cientos de votos. Hubo 589 editores que comentaron en WP: FRAMBAN, que probablemente sea una marca de agua alta para cualquier cosa relacionada con la administración. Así que usemos eso para calcular un porcentaje. Digamos que varios de los 13 argumentos actualmente activos recusan y usan a seis votantes por un valor conservador.
6/589
es aproximadamente el 1%, no el 0,001%. En el peor de los casos, es posible que aparezca una fracción de los 144,229 editores activos; digamos que la mitad para las risas, que es todavía6/72,500
o alrededor del 0.01%, por lo que está al menos 10 veces. - Bri.public ( charla ) 20:02, 3 de marzo de 2021 (UTC)- (Sonríe) El 67,43% de las estadísticas en Internet se elaboran sobre el terreno. :)
- Hasta el sábado 10 de julio de 2021, 10:05 (UTC), la Wikipedia en inglés tiene 41,858,592 usuarios registrados, 124,801 editores activos y 1,090 administradores. Juntos hemos realizado 1.028.186.688 ediciones, creado 53.789.793 páginas de todo tipo y creado 6.334.220 artículos.
- Entonces, si finjo que me molesté en calcular un número real de como porcentaje de un número totalmente falso de usuarios en lugar de simplemente elegir un número de mi sombrero, (sonrisa) ¿por qué no usar usuarios registrados en lugar de usuarios activos? (Sí, estoy siendo tonto. Y sí, "mucho menos de 589" sería un número mucho más útil.) - Guy Macon ( charla ) 20:50, 3 de marzo de 2021 (UTC)
- Bueno, el factor porcentual debe corregirse antes de aprobarlo. A menos que logremos un 60% o 70% para seguir siendo un administrador en una nominación de de-sysop, entonces todo es inútil. Necesitamos pasar algo que funcione, algo que evite el sistema de amigos, donde un administrador dado tiene suficientes amigos entre otros administradores para que sus amigos descarrilen cualquier proceso de des-sysop. De lo contrario, se convierte en una burla incluso iniciar un proceso de des-sysop. - Maile ( conversación ) 01:30, 27 de febrero de 2021 (UTC)
- Me gustaría hacerme eco de que comparto los mismos pensamientos sobre la falacia de equivalencia falsa de los porcentajes de "RfA inverso", y he comentado mi justificación aquí y aquí . Huggums537 ( charla ) 05:13, 27 de febrero de 2021 (UTC)
- No es una equivalencia falsa, un administrador debería tener que retener el mismo apoyo comunitario amplio con el que tenía para empezar. No es como si los administradores tuvieran términos que expiran, se les da administración de por vida. La única forma en que apoyaría una barrera tan alta para eliminar a un administrador es si se combinara con una propuesta para otorgar a los administradores períodos de 2 (o posiblemente 4) años y hacer que cada uno de ellos pase por un nuevo RfA cuando expire su período. La comunidad vota a los administradores para que " asuman el cargo" y deberían poder rechazarlos .-- Rusf10 ( hablar ) 01:40, 28 de febrero de 2021 (UTC)
- No es posible mantener el apoyo con el que tenía que empezar cuando tiene un término de por vida. Esa es una expectativa absurda y una declaración poco realista. Un administrador podría perder el apoyo que tenía solo un año después por no haber hecho realmente mal las cosas terribles cuando la comunidad descubra que no eran tan buenos como pensaban, o que cambiaron después de recibir el bit. Muchas cosas pueden cambiar a lo largo de la vida. Los porcentajes son sin duda una equivalencia falsa, y decir que un administrador tiene que mantener su apoyo no puede usarse como una excusa para cambiar eso. Huggums537 ( charla ) 03:13, 28 de febrero de 2021 (UTC)
- La verdad del asunto es que un administrador no necesita mantener ningún soporte en absoluto, solo necesita el soporte suficiente para obtener el bit, y luego puede ser un idiota después de eso, siempre y cuando no rompa ninguna regla. pero no importa porque tienen algo de por vida a menos que crucen las líneas equivocadas. Huggums537 ( charla ) 03:26, 28 de febrero de 2021 (UTC)
- Ahí está el problema, le parece aceptable que un administrador sea un idiota. Yo no. Creo que los administradores deben cumplir con un estándar más alto. No acepto un desempeño pobre para el liderazgo. Aparentemente sí .-- Rusf10 ( hablar ) 06:32, 28 de febrero de 2021 (UTC)
- Parece haber confundido a alguien dando una descripción precisa de lo que existe con la aprobación de la misma. No creo que estés siendo justo con Huggums537. - Guy Macon ( charla ) 08:37, 28 de febrero de 2021 (UTC)
- Rusf10, Guy Macon tiene razón. No lo apruebo en absoluto. Simplemente declarando hechos. Conozco a algunos administradores muy buenos que nunca serían idiotas, y conozco a un par que lo son. Solo estaba señalando lo mismo que usted, que un nombramiento de por vida presenta este problema, dado que les permite esta opción. También estoy de acuerdo con usted en que un término limitado resolvería esto, ya que luego se verían obligados a mantener su apoyo para las próximas elecciones. La única parte en la que no estamos de acuerdo es en la falsa equivalencia de los porcentajes, y si hace clic en los enlaces que publiqué arriba, es posible que también estemos de acuerdo. Huggums537 ( charla ) 10:46, 28 de febrero de 2021 (UTC)
- Parece haber confundido a alguien dando una descripción precisa de lo que existe con la aprobación de la misma. No creo que estés siendo justo con Huggums537. - Guy Macon ( charla ) 08:37, 28 de febrero de 2021 (UTC)
- Ahí está el problema, le parece aceptable que un administrador sea un idiota. Yo no. Creo que los administradores deben cumplir con un estándar más alto. No acepto un desempeño pobre para el liderazgo. Aparentemente sí .-- Rusf10 ( hablar ) 06:32, 28 de febrero de 2021 (UTC)
- No es una equivalencia falsa, un administrador debería tener que retener el mismo apoyo comunitario amplio con el que tenía para empezar. No es como si los administradores tuvieran términos que expiran, se les da administración de por vida. La única forma en que apoyaría una barrera tan alta para eliminar a un administrador es si se combinara con una propuesta para otorgar a los administradores períodos de 2 (o posiblemente 4) años y hacer que cada uno de ellos pase por un nuevo RfA cuando expire su período. La comunidad vota a los administradores para que " asuman el cargo" y deberían poder rechazarlos .-- Rusf10 ( hablar ) 01:40, 28 de febrero de 2021 (UTC)
- 41,43% : el administrador, a quien ArbCom prohibió el tema por eliminaciones rápidas y prohibiciones de usuarios, violó esta prohibición y se eliminó la marca de administrador. Con un criterio tan bajo (40%), ¿tendría que quedarse (recuperar) la bandera? ¿Por qué no entregar la bandera a nuevos miembros con un nivel de apoyo similar?
No debemos hablar del porcentaje para tomar la decisión de quitar la bandera, no, debemos hablar del nivel de confianza en el administrador. · Carn · !? 14:56, 14 de abril de 2021 (UTC)
Es común (no ilógico) requerir un mayor porcentaje / entrada para realizar un cambio. Incluir en Wikipedia y pasar RFA y obtener Desysopped son ambos cambios. North8000 ( conversación ) 17:55, 14 de abril de 2021 (UTC)
"Siempre podemos cambiarlo más tarde" es engañoso
Creo que se ha mencionado que muchos partidarios de esta propuesta son administradores, y se ha sugerido que tienen un interés personal en el resultado como un conflicto de intereses natural que podría causar que la mayoría de ellos tenga una visión sesgada hacia cualquier políticas que harían más fácil sacarlos de su puesto, independientemente de si se merecería para otros administradores "malos" o no, especialmente si hubieran sido influenciados por argumentos basados en el miedo que sugirieran políticas meritorias para administradores "malos" tener consecuencias perjudiciales y desastrosas para los buenos. Esto es exactamente lo que sucedió en la discusión de 2019. Debido a este fenómeno, quienes han apoyado esta propuesta nunca permitirán que ocurra ningún cambio con mucha facilidad si esta propuesta se aprueba. En otras palabras, si esta propuesta resulta ser igual o más difícil que ArbCom, como los opositores le dicen que será, entonces no espere que ninguno de estos partidarios, que podrían ser los parciales, lo ayude a cambiarla más adelante. . No lo harán. De hecho, se opondrán a los cambios más adelante. Entonces, si ha apoyado solo porque, "lo perfecto es enemigo de lo bueno"; "no es perfecto", pero "es mejor que nada", y piensas, "siempre podemos cambiarlo más tarde", entonces te has engañado creyendo una ideaología que no existe en ningún otro lugar que no sea la mente de alguien que ha sido "wikipedificado". Huggums537 ( charla ) 05:56, 27 de febrero de 2021 (UTC)
- Probablemente estoy totalmente arruinado por mi educación y mi trabajo en ciencias naturales, pero el argumento del tipo "los administradores no quieren que se eliminen sus banderas, y es por eso que han diseñado y apoyado masivamente una propuesta sobre la eliminación de los derechos de administrador" no tiene mucho sentido para mi. La única forma en que podría entenderlo es si hay otra propuesta en torno a la cual facilitaría mucho el proceso, y los administradores no quieren esa propuesta y es por eso que salieron con esta. Bueno, teóricamente esto podría haber sucedido, pero en la práctica no veo ninguna propuesta que facilite la eliminación de la bandera de administrador y tenga alguna posibilidad de ser apoyado por la comunidad .-- Ymblanter ( charla ) 08:01, 27 de febrero 2021 (UTC)
- Lo que dijo Ymblanter; su argumento parece ser "los administradores están tratando de proteger su estado apoyando una propuesta que hace que sea más fácil despojarlos de su estado", lo cual no tiene sentido. Además, ya me sugirieron un mecanismo (una fecha de caducidad codificada de pegar o girar para el proceso después del cual debe ser formalmente readoptado o rechazado) como una forma de evitar que esto se convierta en parte del mueble si gira. resulta ser de alguna manera problemático; Estoy seguro de que hay otras formas igualmente viables de hacerlo. - Iridiscente 09:13, 27 de febrero de 2021 (UTC)
- Existe una amplia historia de industrias que proponen mecanismos de autorregulación para evitar la regulación externa, generalmente gubernamental. El "pegar o girar" no es, en sí mismo, una razón para apoyar. - Ryk72 talk 09:59, 27 de febrero de 2021 (UTC)
- Ymblanter e Iridescent , ambos han malinterpretado mi argumento. Una interpretación más precisa que estaría más cerca de mi argumento es: los administradores no quieren que se eliminen sus banderas, y es por eso que han diseñado y apoyado masivamente una propuesta sobre la eliminación de los derechos de administrador [que es más difícil que ArbCom] , y los administradores están tratando de proteger su estatus apoyando una propuesta que hace más
fácil[más difícil] despojarlos de su estatus , respectivamente. Además, entiendo que Iridescent puede estar ofreciendo una solución viable como uno de los administradores no sesgados, pero creo que los sesgados tampoco lo permitirían. Huggums537 ( charla ) 12:54, 27 de febrero de 2021 (UTC) - Solo quiero agregar que estas interpretaciones (así como las correcciones) tampoco fueron el punto focal de mi argumento. El enfoque de mi argumento es que los cambios serían más difíciles de hacer más adelante, no más fáciles. El hecho de que los administradores quieran proteger su estado es realmente incidental. Huggums537 ( charla ) 13:09, 27 de febrero de 2021 (UTC)
- Sin embargo, esta propuesta no es un reemplazo para los desysops de ArbCom, sino otro método basado en la comunidad. - J947 ‡ mensaje ⁓ edita 18:48, 1 de marzo de 2021 (UTC)
- Esto supone que Arbcom no comenzará a enviar un porcentaje de casos de desysop a la comunidad, como lo hace habitualmente ahora con los casos que no son administradores. - Guy Macon ( charla ) 20:54, 3 de marzo de 2021 (UTC)
- Sin embargo, esta propuesta no es un reemplazo para los desysops de ArbCom, sino otro método basado en la comunidad. - J947 ‡ mensaje ⁓ edita 18:48, 1 de marzo de 2021 (UTC)
- Ymblanter e Iridescent , ambos han malinterpretado mi argumento. Una interpretación más precisa que estaría más cerca de mi argumento es: los administradores no quieren que se eliminen sus banderas, y es por eso que han diseñado y apoyado masivamente una propuesta sobre la eliminación de los derechos de administrador [que es más difícil que ArbCom] , y los administradores están tratando de proteger su estatus apoyando una propuesta que hace más
- Existe una amplia historia de industrias que proponen mecanismos de autorregulación para evitar la regulación externa, generalmente gubernamental. El "pegar o girar" no es, en sí mismo, una razón para apoyar. - Ryk72 talk 09:59, 27 de febrero de 2021 (UTC)
- Lo que dijo Ymblanter; su argumento parece ser "los administradores están tratando de proteger su estado apoyando una propuesta que hace que sea más fácil despojarlos de su estado", lo cual no tiene sentido. Además, ya me sugirieron un mecanismo (una fecha de caducidad codificada de pegar o girar para el proceso después del cual debe ser formalmente readoptado o rechazado) como una forma de evitar que esto se convierta en parte del mueble si gira. resulta ser de alguna manera problemático; Estoy seguro de que hay otras formas igualmente viables de hacerlo. - Iridiscente 09:13, 27 de febrero de 2021 (UTC)
Queremos un proceso de desysop comunitario, pero si no es así, ¿qué es?
Está claro que queremos un proceso de desysop comunitario. Es igualmente claro que este procedimiento propuesto no es el que queremos. Las personas se oponen con pesar porque quieren un procedimiento, pero ven demasiadas fallas en esto. La gente está apoyando a regañadientes / en principio porque a pesar de las fallas, prefieren tener algo que nada, y muchos esperan o esperan que los cambios necesarios ocurran como parte del proceso wiki normal. Lo he apoyado porque es demasiado fácil descarrilar propuestas importantes como esta, y es importante que tengamos un proceso de desysop comunitario para que la comunidad se sienta más en control de lo que está en este momento. Pero aunque he apoyado, para ser honesto, no hay mucho (¿algo?) Que me guste de la idea propuesta. No me gusta la forma en que se debe configurar un desysop (a través de ANI) ni la forma en que se concluye (un enfoque en apedrear al administrador y pedir un porcentaje bastante alto de lanzamiento de piedras para desysop), y el medio La sección también es un poco complicada. En cuanto a los comentarios, parece que un número significativo de personas comparte las mismas preocupaciones. ¿Podemos aprovechar esta oportunidad para generar algunas ideas de la comunidad sobre cómo nos gustaría que procediera un proceso de desysop comunitario y luego votar por lo mejor de ellas? Me siento cada vez más incómodo apoyando esta propuesta, pero quiero ver un proceso de desysop comunitario.
El primer aspecto es el proceso de inicio. La propuesta de Tony es que un proceso de desysop debe comenzar en ANI, y que para llevar el asunto más allá, un usuario debe cumplir con ciertos criterios. Varias personas tienen problemas con esta idea por diversas razones, incluido que no todas las preocupaciones con respecto a un administrador pueden comenzar en ANI (algunos usuarios, por ejemplo, están preocupados por los administradores casi inactivos a largo plazo ), que depende de un El administrador cierra una discusión de ANI con una declaración de que el administrador en cuestión actuó "de manera inapropiada" y que el criterio del usuario limita a quienes pueden plantear el problema. Tenemos WP: ADMINACCT , que permite a los "editores" plantear una inquietud a un administrador: "Sujeto únicamente a los límites de la cortesía, evitando ataques personales y una buena fe razonable, los editores son libres de cuestionar o criticar las acciones del administrador". Y esa, seguramente, también es la primera etapa en cualquier preocupación: plantear el problema directamente con el administrador en cuestión. Sólo cuando se considere que la respuesta es inapropiada o inadecuada, debe llevarse más lejos. Entonces, mi sugerencia es que, según WP: ADMINACCT , cualquier editor puede plantear una inquietud a un administrador, y si la respuesta es inapropiada / inadecuada, y las inquietudes del editor son claramente relevantes para WP: ADMINCOND , pueden solicitar una desysop / reconfirmación RfA. Debería establecerse un nuevo tablón de anuncios para realizar tales solicitudes. Las respuestas apropiadas que un administrador podría darle al editor que presenta una inquietud serían: 1) Responder con una explicación razonable 2) Reconocer la inquietud y comprometerse a abordar el problema en el futuro 3) Reconocer la inquietud y establecer voluntariamente un proceso de reconfirmación 4) Reconocer la inquietud y renunciar permanentemente (bajo una nube). Las respuestas inapropiadas serían 1) Ignorar la inquietud (continuar editando sin responder dentro de un plazo razonable) 2) Descartar la inquietud, ya sea sin rodeos o cortésmente 3) Proporcionar una explicación inapropiada, inexacta o inadecuada 4) Comprometerse a abordar el problema, pero luego, no hacerlo 5) Amenazar o intimidar al editor.
Para evitar que los usuarios descontentos o maliciosos realicen solicitudes repetidas de desysop del mismo administrador o de diferentes administradores, se debe prohibir a cualquier editor que haga tres solicitudes rechazadas hacer más.
Se debe configurar una página específica para realizar solicitudes de desysop. Según la sugerencia de Tony, esto debería ser evaluado y cerrado por un 'Crat. Se debe hacer un enlace al lugar donde el editor planteó el problema al administrador. Si la inquietud está relacionada con un administrador inactivo a largo plazo, se debe enviar un correo electrónico al administrador y darle un tiempo razonable para permitir una respuesta. Sin embargo, a algunas personas les preocupa que una simple reacción instintiva se acelere a una sesión completa de abandono al permitir que 10 usuarios en 48 horas estén de acuerdo; también, que necesita tres administradores. No tengo claro cuál debería ser la alternativa. En mi experiencia, la mayoría de las propuestas tienden a obtener apoyo rápido y temprano, y toma un tiempo para que las oposiciones comiencen a construirse. Sería útil recibir alguna información de la comunidad sobre la forma que debería tomar la solicitud de desysop. Debería haber consenso y debería haber un límite de tiempo, pero ¿qué consenso mínimo y qué tiempo es aceptable y apropiado? ¿Tiene que haber un cierto número de administradores que estén de acuerdo? ¿Es necesario el requisito de administrador si un 'Crat se va a cerrar de todos modos? Si mantenemos los 10 usuarios de Tony, y usamos eso como una calificación mínima, pero permitimos que el 'Crat evalúe el consenso (así, por ejemplo, si 10 usuarios están de acuerdo, pero 20 no están de acuerdo, entonces no hay consenso). Y si ampliamos el tiempo para permitir la oposición (si corresponde) al desysop para que analice las preocupaciones y presente razones razonables por las que no debería ocurrir un desysop RpA. Debido a los fines de semana, etc., se podría permitir un mínimo de cuatro días.
Ahora, el voto / discusión desysop real. Varias personas no están satisfechas con la idea propuesta. Ya estamos familiarizados con las RpA de reconfirmación. El más notable es el de Fram en 2019 . Es un procedimiento que funciona. Es el procedimiento que la mayoría de los que están abiertos a recordar han elegido por sí mismos . Mi sugerencia sería que usemos el proceso de RfA existente como medio para decidir si la comunidad aún conserva la confianza en que el usuario tenga las herramientas del sistema operativo. El consenso se evalúa de la misma manera que ahora. Esto permite que la comunidad haga preguntas y realice una evaluación más detallada y sofisticada que simplemente centrarse en quizás un incidente. También se aleja de la negatividad de votar para desysop (con lo que algunas personas pueden sentirse incómodas y, por lo tanto, pueden evitar votar), en lugar de preguntar a la comunidad si confían en que el usuario sea un administrador. Otras sugerencias son bienvenidas.
Estas son mis sugerencias sobre cómo debería funcionar el procedimiento de desysop. Otros deben sentirse libres de agregar los suyos para que podamos tener una idea clara de lo que la comunidad realmente quiere y luego seguir adelante con eso. SilkTork ( charla ) 13:36, 27 de febrero de 2021 (UTC)
- Más de 200 personas han participado en este RfC. Lo que se muestra a continuación pretende ser un ejercicio de sondeo , ¿correcto? Lo mejor, Barkeep49 ( charla ) 14:41, 27 de febrero de 2021 (UTC)
- Si parte de la justificación de iniciar esta nueva discusión a mitad de RfC es que algunos editores que se opusieron lo hicieron "a regañadientes", entonces hay que considerar cuántos de ellos se mostraron realmente reacios, y cuántos intentaron ser educados, o utilizaron el término para varios propósitos retóricos. Y la suposición de que ya sabemos que esta propuesta no es lo que quiere la comunidad es absolutamente inapropiada. Hay una razón por la que el consenso se determina después de que se cierra una discusión, y que el cierre lo hace alguien que no está involucrado. Sé que SilkTork tiene buenas intenciones con esto, pero creo que es muy problemático. - Tryptofish ( charla ) 21:07, 27 de febrero de 2021 (UTC)
- Mi intención era aprovechar el impulso de esta propuesta y resolver los aspectos que preocupan a las personas e invitar a más (no menos) participación de la comunidad. Creo que tenemos la oportunidad de lograr un proceso de desysop comunitario (CDP), pero, curiosamente, uno en el que la comunidad no esté involucrada en la construcción. Lo que creo que está claro es que la comunidad quiere tener un CDP. Lo que también está claro es que existen preocupaciones con algunos, muchos o todos los aspectos de esta propuesta. Entonces, mientras estamos aquí, lo que sentí que podría ser útil es que la comunidad resuelva cuál sería una buena propuesta. En qué aspectos podría estar de acuerdo la gente. Esencialmente, hay dos enfoques que podemos adoptar aquí. La primera es que rechazamos o aceptamos la propuesta tal como está. Podemos rechazar un CDP, aunque queramos uno, porque hay algunos aspectos de él que no nos gustan. O podemos aceptar un CDP que creemos que es problemático, simplemente porque queremos tal procedimiento. El segundo enfoque es que aceptamos que queremos un CDP y, como comunidad, resolvemos los detalles y llegamos a un consenso. En el primer procedimiento, o rechazamos otro intento de CDP o lo aceptamos, pero con aspectos que nos resultan problemáticos. Algunos de los que votaron para aceptar parecen bastante contentos con la propuesta, algunos solo quieren un CDP y no están preocupados por los detalles; otros, como yo, están aceptando, conscientes de los problemas, pero con la creencia de que vamos a alisar las arrugas a medida que avanzamos. Como siempre lo hacemos. En el segundo, intentamos eliminar las arrugas antes de que se lance el CDP. Desde el momento en que leí la propuesta, no tenía claro en qué dirección votaría. Estoy a favor de un CDP, pero este me preocupa. Decidí apoyar, no porque me guste particularmente este esquema, sino porque hemos estado hablando de tener un CDP durante tanto tiempo, pero cada propuesta se estanca, y sentí que era importante hacer despegar una. Pero a medida que surgían más y más preocupaciones, comencé a sentirme incómodo. ¿Esta propuesta realmente aborda algunos de los problemas que las personas tienen con los administradores, las inquietudes que no se están cumpliendo con ArbCom o nuestras formas existentes de tratar con los administradores problemáticos, en particular aquellos que se convirtieron en administradores hace mucho tiempo, están en su mayoría inactivos, pero ¿Puede en cualquier momento intervenir y realizar una acción administrativa inapropiada? No creo que lo haga. Estoy leyendo las inquietudes y estoy en un punto en el que siento que nuestro sistema actual, aunque no del todo adecuado, es mejor que esta propuesta. Así que es mejor conservar lo que tenemos que agregar más problemas. Aunque podemos hacer que esta propuesta funcione, si la ajustamos. Básicamente, hay tres aspectos: cómo iniciar un CDP, cómo ejecutarlo para garantizar que sea justo para el administrador y la comunidad, y cómo cerrarlo. Mi evaluación rápida de esta página es que las preocupaciones se basan principalmente en cómo comienza y termina el CDP en esta propuesta. Si todos trabajamos juntos para abordar esas preocupaciones ahora, entonces es más probable (y no menos) que obtengamos no solo un CDP, sino el CDP que queremos.
- Lamento no haber sido más claro al configurar esto, lo hice bastante rápido ayer antes de salir. En retrospectiva, hubiera sido mejor que algunas personas lo vieran antes de publicarlo. SilkTork ( charla ) 12:18, 28 de febrero de 2021 (UTC)
- Como dije, sé que tuvo buenas intenciones, pero sigo pensando que esta es una discusión para después de que se cierre el actual RfC, sea como sea. - Tryptofish ( charla ) 19:42, 28 de febrero de 2021 (UTC)
- Si parte de la justificación de iniciar esta nueva discusión a mitad de RfC es que algunos editores que se opusieron lo hicieron "a regañadientes", entonces hay que considerar cuántos de ellos se mostraron realmente reacios, y cuántos intentaron ser educados, o utilizaron el término para varios propósitos retóricos. Y la suposición de que ya sabemos que esta propuesta no es lo que quiere la comunidad es absolutamente inapropiada. Hay una razón por la que el consenso se determina después de que se cierra una discusión, y que el cierre lo hace alguien que no está involucrado. Sé que SilkTork tiene buenas intenciones con esto, pero creo que es muy problemático. - Tryptofish ( charla ) 21:07, 27 de febrero de 2021 (UTC)
Para evitar que los usuarios descontentos o maliciosos realicen solicitudes repetidas de desysop del mismo administrador o de diferentes administradores, se debe prohibir a cualquier editor que haga tres solicitudes rechazadas hacer más.
- No creo que deba haber un límite tan estricto. Creo que un período de recuperación o simplemente la posibilidad de restringirlo funcionaría mejor Asartea Talk | Contribuciones 15:51, 12 de marzo de 2021 (UTC)
El editor primero debe plantear su preocupación con el administrador por WP: ADMINACCT
Para iniciar un procedimiento de desysop, un editor registrado debe primero plantear su inquietud al administrador por WP: ADMINACCT . Solo si la respuesta es inapropiada (los ejemplos incluyen, pero no se limitan a: 1) Ignorar la inquietud (continuar editando sin responder dentro de un período de tiempo razonable) 2) Descartar la inquietud, ya sea sin rodeos o cortésmente 3) Proporcionar una respuesta inapropiada, inexacta, o explicación inadecuada 4) Comprometerse a abordar el problema, pero luego no hacerlo 5) Amenazar o intimidar al editor ) en caso de que el editor inicie el procedimiento.
Apoyo
- Soporte . SilkTork ( charla ) 13:36, 27 de febrero de 2021 (UTC)
SoporteNecesitamos algo. De acuerdo con el primer paso.Huggums537 ( charla ) 13:51, 27 de febrero de 2021 (UTC)- Soporte Siempre debería poder discutir algo con un administrador. No hacer un seguimiento de eso es la raíz de la mayoría de los problemas del administrador. Ritchie333 (charla) (continuación) 18:26, 27 de febrero de 2021 (UTC)
Soporte . Para agregar lo que dijo Ritchie, debe intentar resolver la mayoría de los problemas con cualquier usuario antes de recurrir a la comunidad en busca de ayuda. - Calidum 19:56, 27 de febrero de 2021 (UTC)- Soporte por Richie - Ched ( charla ) 08:35, 6 de marzo de 2021 (UTC)
Oponerse a
- Me opongo , supongo que esto en principio, pero tal como está escrito es un no. "Los editores primero deben plantear sus inquietudes al administrador" está bien. Pero muchas preocupaciones son descartables, y lo que es "inadecuado" está en el ojo del espectador. Simplifique a "Los editores primero deben plantear sus inquietudes al administrador", y estoy a bordo. El punto es que la discusión suceda y que las situaciones disminuyan o que se resuelvan las ambigüedades. Y también quisiera dejar en claro que la presentación de inquietudes se puede hacer en muchos lugares, con varios niveles de formalidad. Headbomb { t · c · p · b } 20:50, 27 de febrero de 2021 (UTC)
- Oponerse . En lectura adicional, creo que esto va demasiado lejos. Si bien un usuario debe comunicarse primero con un administrador en la mayoría de los casos para discutir un problema, creo que las restricciones son demasiadas. - Calidum 20:57, 27 de febrero de 2021 (UTC)
- Oponerse . Un paso innecesario en un proceso que ya es demasiado difícil. Coretheapple ( charla ) 16:04, 28 de febrero de 2021 (UTC)
- Oponerse a "Desestimar la preocupación, ya sea sin rodeos o cortésmente" puede ser la respuesta administrativa apropiada a bastantes acusaciones potenciales de un individuo. Por ejemplo, si alguien se queja de un cierre específico de AfD, a veces lo apropiado es explicar; a veces lo apropiado es decirles que vayan a Revisión de eliminación. Incluso existen algunas preocupaciones, como las denuncias de prejuicio infundadas, para las que es apropiado ignorar la solicitud. DGG ( charla ) 22:26, 1 de marzo de 2021 (UTC)
- Oponerse a Headbomb y DGG plantean algunos puntos que creo que deben abordarse con los OP / partidarios. 🐔 ¡ Chicdat Bawk para mí! 11:31, 5 de marzo de 2021 (UTC)
- Opongo estoy totalmente 100% a bordo con hablar con el administrador y ordenar las cosas de antemano. Esa es la resolución de disputas 101 y debería ser absolutamente un requisito previo si las pautas de desysop de la comunidad entran en vigencia ya que la mayoría de los problemas se resuelven mediante discusión. La parte con la que no estoy de acuerdo es lo que tanto Headbomb como DGG han mencionado: a menudo, descartar o ignorar las quejas es a menudo lo correcto en el procedimiento. Si lo anterior entra en vigencia, los usuarios menos informados o los editores de mala fe podrían abusar de él y que se sientan menospreciados porque un administrador desestimó correctamente una afirmación que consideraba legítima. La discusión debe ser un requisito primero (como con cualquier conflicto) pero las reglas anteriores se sienten demasiado estrictas. Jns4eva ( charla ) 20:14, 5 de marzo de 2021 (UTC)
- Oponerse . Al menos si algo como la propuesta de Tony Ballioni sustenta esto, habrá un evento específico que precipite esto y que, a primera vista, ya se habrá resuelto en AN / ANI / donde sea . El problema es que alguien considera que el comportamiento del administrador, en torno a este problema o un patrón que incluye este problema, es tal que la comunidad ha perdido la confianza en el administrador. Hay poco que ganar aquí forzando una interacción "dime * me * lo que vas a hacer, de lo contrario iniciaré una petición para la interacción -sysop". Si alguien siente que la confianza se ha ido, comienza el proceso. Si están equivocados, ese inicio caduca inofensivamente con un soporte limitado. Martinp ( charla ) 20:53, 6 de marzo de 2021 (UTC)
- Oponerse Es una buena idea hablar primero, pero no es así como me gusta, ahora que lo pienso. ¿Quién decide qué es "inapropiado", el editor o el administrador? Huggums537 ( charla ) 08:04, 11 de marzo de 2021 (UTC)
Neutral
- En primer lugar, tengo serias reservas sobre la forma en que esta encuesta de paja o lo que sea se está iniciando a mitad de RfC, y no quiero que el más cercano de este RfC interprete los comentarios que haga aquí. como indicativo de una disminución del apoyo a la propuesta real que se está considerando aquí . También estoy muy de acuerdo con el director general en que normalmente se debería comenzar discutiendo las preocupaciones directamente con el administrador, a menos que haya otras consideraciones que se interpongan en el camino. Pero tal como está escrito, no puedo ver esta redacción como una adición adecuada a la propuesta principal, porque es demasiado restrictiva. - Tryptofish ( charla ) 21:12, 27 de febrero de 2021 (UTC)
Comentario
Mira, mi impresión fue que cualquier tipo de proceso de abandono que le permita a un editor iniciar el proceso por su propia cuenta fue un fracaso debido a que "los editores de mala fe y los promotores de puntos de vista abusarán de él como una táctica de intimidación". Me imagino que esta es la razón por la que Tony estableció el requisito de "debe tener un hilo ANI", de modo que la gente necesite obtener algún apoyo de otros antes de poder iniciar el proceso. Jo-Jo Eumerus ( charla ) 13:46, 27 de febrero de 2021 (UTC)
- "Debe tener hilo ANI" no es necesariamente malo; "Debe tener hilo ANI con cierre de que el administrador actuó de manera inapropiada " es terrible. - Ryk72 talk 13:50, 27 de febrero de 2021 (UTC)
- El problema entonces serían los casos de "hilo ANI cerrado sin que el administrador encontrara irregularidades". Jo-Jo Eumerus ( charla ) 16:41, 27 de febrero de 2021 (UTC)
- De acuerdo con Jo-Jo. La idea del hilo ANI es horrible en todos los sentidos. Huggums537 ( charla ) 17:16, 27 de febrero de 2021 (UTC)
- No estoy seguro de que esto no se elimine ni en la etapa de "10 respaldos" ni en la etapa de votación final. - Ryk72 talk 23:58, 27 de febrero de 2021 (UTC)
- Un esfuerzo de intimidación exitoso no requiere que el proceso al final produzca un desysop: las personas aún se molestan por el trato injusto percibido, incluso si se revierte rápidamente. Hay una razón por la que tenemos políticas como WP: INVOLVED a pesar de que un bloqueo abusivo generalmente se levanta rápidamente. Jo-Jo Eumerus ( charla ) 10:04, 28 de febrero de 2021 (UTC)
- No estoy seguro de que esto no se elimine ni en la etapa de "10 respaldos" ni en la etapa de votación final. - Ryk72 talk 23:58, 27 de febrero de 2021 (UTC)
- De acuerdo con Jo-Jo. La idea del hilo ANI es horrible en todos los sentidos. Huggums537 ( charla ) 17:16, 27 de febrero de 2021 (UTC)
- El problema entonces serían los casos de "hilo ANI cerrado sin que el administrador encontrara irregularidades". Jo-Jo Eumerus ( charla ) 16:41, 27 de febrero de 2021 (UTC)
Cualquier editor que envíe tres solicitudes de desysop rechazadas tiene prohibido enviar solicitudes futuras.
Apoyo
- Soporte . SilkTork ( charla ) 13:36, 27 de febrero de 2021 (UTC)
- Soporte . Si vamos a tomarnos en serio la creación de un mecanismo para iniciar automáticamente un proceso de desysop, no hay problema con bloquear a un editor que haya realizado * TRES * solicitudes fallidas. Protonk ( charla ) 18:15, 27 de febrero de 2021 (UTC)
- Entonces, ¿un editor al que se le niega repetidamente por un formato incorrecto o por otras razones técnicas ahora se bloquea repentinamente por completo con el pretexto de evitar solicitudes maliciosas a pesar de que pueden tener una válida? Huggums537 ( charla ) 18:27, 27 de febrero de 2021 (UTC)
Oponerse a
- Oponerse a la privación de derechos de los editores por estar equivocados. Las solicitudes claramente maliciosas se pueden abordar por otros medios. - Ryk72 talk 13:53, 27 de febrero de 2021 (UTC)
- Oponerme
Creo que debería decir 3 solicitudes de rechazo contra el mismo administrador, no 3 solicitudes de rechazo en general.[Pasando a neutral]. Huggums537 ( charla ) 13:57, 27 de febrero de 2021 (UTC) Vuelve a oponerse. Tengo que estar de acuerdo con Ryk72. Otros medios pueden abordar solicitudes maliciosas que no privarán por completo a los editores de poder realizar solicitudes válidas cuando sea necesario. Huggums537 ( charla ) 15:14, 27 de febrero de 2021 (UTC) - Per Ryk. Deje que la comunidad se ocupe de esto si es necesario. - Calidum 20:05, 27 de febrero de 2021 (UTC)
- Oponerse como está escrito. Hacer solicitudes frívolas debería ver a la persona bloqueada y prohibida para WP: DE . El simple hecho de pertenecer a una minoría no debería resultar en la eliminación de privilegios. Hacer que los 'crats se involucren en la moderación del recuerdo y empoderarlos para que rechacen tales solicitudes debería ser suficiente. Headbomb { t · c · p · b } 20:54, 27 de febrero de 2021 (UTC)
- Oponerse como está escrito. Tal vez tres solicitudes fallidas sobre un solo administrador o algo así. - Tryptofish ( charla ) 21:14, 27 de febrero de 2021 (UTC)
- Oponerse por la misma razón que no tenemos una política que diga que los editores tienen prohibido presentar AfD si sus últimas n AfD cerraron como mantener. Debe tratarse el comportamiento perturbador, pero no mediante comprobaciones puramente numéricas. - The Earwig ( charla ) 03:54, 28 de febrero de 2021 (UTC)
- por Headbomb. WP: DE cubrirá esto. - CptViraj ( conversación ) 04:50, 28 de febrero de 2021 (UTC)
- Oponerse . Las solicitudes frívolas ya están cubiertas por la política como disruptivas, como se indicó anteriormente. Coretheapple ( charla ) 16:06, 28 de febrero de 2021 (UTC)
- Oponerse Hay un punto en el que las solicitudes repetidas serían perjudiciales, pero a veces podría ser una solicitud abusiva o frívola; ya veces, al abordar los problemas crónicos, el fracaso repetido en la obtención de un desysop real pero que, sin embargo, cambia la dirección de la conducta, puede ser muy productivo. DGG ( charla ) 22:31, 1 de marzo de 2021 (UTC)
- Oponerse a este criterio en particular, pero debería haber algún tipo de "inmunidad" una vez que un administrador ha pasado por este proceso y se ha quedado con el bit. Se agregó una propuesta a continuación. Stifle ( charla ) 11:07, 2 de marzo de 2021 (UTC)
- Oponerse Es improbable que ocurra a menudo, arbitrariamente punitivo, y creo que es mejor resolver el abuso de las reglas con otros métodos, en lugar de complicar demasiado esta propuesta (que será complicada y litigada mucho como está, si se usa cada vez). - Wingedserif ( conversación ) 15:45, 2 de marzo de 2021 (UTC)
- Oponerse por Headbomb, Coretheapple y DGG. Un límite de nominaciones sobre un solo editor en un período de tiempo dado sería propicio, pero ocurriría con tanta poca frecuencia que no tendría sentido y las posibilidades de que no sea una edición disruptiva de algún tipo son tan escasas que sería redundante. Thryduulf ( conversación ) 16:39, 2 de marzo de 2021 (UTC)
- Oponerse porque esto es CREEPy . 🐔 ¡ Chicdat Bawk para mí! 11:25, 5 de marzo de 2021 (UTC)
- Oponerse . El conjunto de herramientas existente sobre comportamiento disruptivo es suficiente. Martinp ( charla ) 20:55, 6 de marzo de 2021 (UTC)
Neutral
Neutral Cambiaré mi posición a "soporte" si SilkTork la modifica para decir 3 solicitudes rechazadas contra el mismo administrador, en lugar de 3 solicitudes rechazadas en general.Huggums537 ( charla ) 14:07, 27 de febrero de 2021 (UTC) [Volviendo a oponerse. Respuesta final.] Huggums537 ( charla ) 17:58, 27 de febrero de 2021 (UTC)- No creo que haga esto obligatorio, pero si alguien sigue presentando solicitudes de desysop rechazadas, puede ser sancionado (a través de una prohibición o bloqueo de tema) utilizando los procedimientos habituales. Ritchie333 (charla) (continuación) 18:45, 27 de febrero de 2021 (UTC)
- Yo apoyaría si hubiera un marco de tiempo aquí, algo como: Cualquier editor que presente tres solicitudes de desysop rechazadas dentro de un año tiene prohibido enviar cualquier solicitud
futuraadicional durante un año . - Ched ( hablar ) 08:28, 6 de marzo de 2021 (UTC) También apoya la opción de sanción que menciona Ritchie. - Ched ( charla ) 08:33, 6 de marzo de 2021 (UTC)
Comentario
@ SilkTork : Para aclarar, ¿es esta una solicitud que no llega a votación o una solicitud que no se desysop? - Ryk72 talk 14:05, 27 de febrero de 2021 (UTC)
- Buscaba evitar solicitudes maliciosas. Entonces, la intención era para las solicitudes que no se envían a un desysop RfA. Comparto algunas de las preocupaciones expresadas hasta ahora. SilkTorkAway ( charla ) 14:17, 27 de febrero de 2021 (UTC)
Se debe configurar una página "Solicitar Desysop / Reconfirmación" bajo la autoridad de 'Crats
Habiendo planteado su inquietud al administrador, y no recibiendo una respuesta adecuada dentro de un tiempo razonable, un editor puede publicar su solicitud de desysop en una página especial "Solicitar Desysop / Reconfirmación" que solo puede ser cerrada por un 'Crat.
Apoyo
- Soporte . SilkTork ( charla ) 13:36, 27 de febrero de 2021 (UTC)
- Soporte Suena como una buena idea. Huggums537 ( charla ) 13:59, 27 de febrero de 2021 (UTC)
- Apoyo Absolutamente. Esto no debe hacerse a menos que se trate de crats. Headbomb { t · c · p · b } 20:55, 27 de febrero de 2021 (UTC)
- Soporte Suena razonable. Los administradores de sistemas y los editores deben tener en primer lugar la posibilidad de aclarar el problema entre ellos y por sí mismos. Paradise Chronicle ( charla ) 01:09, 28 de febrero de 2021 (UTC)
- Apoyar esto parece tener más posibilidades de pasar que el principal. 🐔 ¡ Chicdat Bawk para mí! 11:32, 5 de marzo de 2021 (UTC)
Oponerse a
- Tenemos la mala costumbre de decir "que los Crats se ocupen de ello" sin preguntarles a los Crats, que no fueron seleccionados para realizar esta tarea. Este es un error que cometí también en el pasado, pero del que he aprendido. En el pasado, Crats se ha mostrado muy, muy reacio a que su función se amplíe, comprensiblemente, de leer el consenso y aplicar políticas en situaciones no controvertidas, a hacer otras cosas que son más controvertidas o envueltas en controversias, como la desobediencia. Los bots y el consenso de lectura en RFA es su cometido principal (junto con los bits de cambio cuando el consenso y / o la autoridad son claros como el cristal), que es muy diferente de lo propuesto aquí. Dennis Brown - 2 ¢ 17:25, 5 de marzo de 2021 (UTC)
- Oponerse . En la propuesta original, los crats son los que comprueban si se cumplen las condiciones para forzar una "discusión de retirada" / de-RFA / lo que sea. Si bien no está exactamente en el ámbito de competencia actual de los crats, es razonable: juzgan imparcialmente el consenso para + sysop, por lo que es razonable que se confíe en que digan "mira, se cumplen las condiciones acordadas de la comunidad que se debe verificar si aún conservas la confianza de la comunidad ". Sin embargo, parte de lo que me gusta de la propuesta de Tony es que los intentos mal concebidos (ya sean frívolos o simplemente malinterpretando la situación) de iniciar una discusión desesperada simplemente se desvanecen con un mínimo de drama. Hacer de todo un proceso bajo la égida de los Crats lo está convirtiendo en un gran problema, una de varias rondas de prueba de fuego. Creo que esta propuesta, en un intento bien intencionado de proteger a los administradores de "peticiones de retirada" inapropiadas, en realidad los convierte en un asunto más importante. Martinp ( charla ) 21:06, 6 de marzo de 2021 (UTC)
Neutral
- No me queda claro en qué se diferencia de la propuesta principal. - Tryptofish ( charla ) 21:16, 27 de febrero de 2021 (UTC)
- Creo que es lo mismo. Simplemente haciéndolo explícito, ya que la propuesta de Tony no establece dónde debe realizarse la solicitud. SilkTorkAway ( conversación ) 22:27, 27 de febrero de 2021 (UTC)
Comentario
Una solicitud solo puede proceder a un "Desysop / Reconfirmation RfA" después de que al menos diez usuarios hayan votado y hayan pasado al menos cuatro días.
Cuando un Crat evalúa el consenso para llevar el asunto a un "Desysop / Reconfirmation RfA", debe asegurarse de que al menos diez usuarios hayan votado, que hayan pasado al menos cuatro días y que haya un consenso claro para llevar el asunto adelante. .
Apoyo
- Soporte . SilkTork ( charla ) 13:36, 27 de febrero de 2021 (UTC)
- Soporte débil Creo que un mínimo de siete días es mucho mejor. Huggums537 ( charla ) 14:01, 27 de febrero de 2021 (UTC)
- Soporte . Con la salvedad de que no debería haber ningún requisito para que ninguno de los patrocinadores sea administrador. - Calidum 20:03, 27 de febrero de 2021 (UTC)
- Apoyo Si se siguen las preocupaciones de Calidum, entonces un fuerte apoyo. 🐔 ¡ Chicdat Bawk para mí! 11:35, 5 de marzo de 2021 (UTC)
Oponerse a
- Nuevamente, esto está tratando de obligar a Crats a asumir un papel que no estoy seguro de que quieran aceptar y que no aceptaron asumir. Dennis Brown - 2 ¢ 17:26, 5 de marzo de 2021 (UTC)
- Oponerse . Esta y la propuesta anterior intentan convertir esta etapa de "hay suficiente preocupación para tener una discusión de-RFA" en un ejercicio de lectura de consenso negociado por crats, convirtiéndolo en 2 etapas que son esencialmente iguales, solo que difieren en escala. La verdadera discusión de la comunidad, en busca de consenso sobre si existe una confianza continua en este administrador que tiene el bit, debería ocurrir una vez. El hecho de avanzar en el asunto debería ser solo una verificación de si existe alguna oleada de preocupación. Al igual que las peticiones de destitución política se centran en un número suficiente de firmas válidas que exigen una destitución, no en un intento de evaluar si los partidarios u opositores tienen más apoyo. Pude ver un papel para crats para excluir a los solicitantes obviamente sesgados / vengativos / no involucrados, esperar al menos x días, o lo que sea, pero no hacer un "de-RFA lite" para decidir si proceder a "de-RFA-for -verdadero". Como punto aparte, no estoy de acuerdo con Calidum y Chicdat con respecto a eliminar un requisito para los patrocinadores administradores. De hecho, creo que es muy prudente exigir a un par de administradores que también expresen su preocupación, ya que es más probable que estén familiarizados con las tensiones de la administración. Si ni siquiera 3 administradores piensan que hay un motivo de preocupación, entonces la única ruta para dejar de administrar puede seguir siendo ArbCom. Martinp ( charla ) 21:19, 6 de marzo de 2021 (UTC)
Neutral
- Una vez más, me resulta difícil precisar en qué se diferencia de la propuesta principal. - Tryptofish ( charla ) 21:18, 27 de febrero de 2021 (UTC)
- Hola, se trata de detalles de la propuesta principal para que todos puedan ver cómo nos gustan. 🐔 ¡ Chicdat Bawk para mí! 11:35, 5 de marzo de 2021 (UTC)
Comentario
Un Crat puede cerrar una solicitud en cualquier momento si parece inapropiada o es poco probable que tenga éxito.
Un Crat puede cerrar una solicitud en cualquier momento si parece inapropiada (por ejemplo, si no se contactó al administrador o no dio una respuesta adecuada) o si parece que después de un período de tiempo razonable es poco probable que tenga éxito (como 50 usuarios en 48 horas rechazando la solicitud, y solo el editor que la respalda).
Apoyo
- Soporte . SilkTork ( charla ) 13:36, 27 de febrero de 2021 (UTC)
Soporte débil(mover para oponerse) Iba a oponerme a esto al principio porque parecía poder quitar el desysop de las manos de la comunidad y potencialmente ponerlo en manos de un amigo de Crat de un administrador "malo", pero la forma en que está redactado parece que podría permitir a la comunidad evitar que eso suceda. Huggums537 ( hablar ) 14:01, 27 de febrero de 2021 (UTC) [Mover para oponerse en esto]. Huggums537 ( charla ) 17:44, 27 de febrero de 2021 (UTC)- Apoyo débil . Ya escribí anteriormente que me opongo a toda la parte de insistir en que se contacte específicamente al administrador antes de la "petición" de de-RFA, y también que me opongo a que esta etapa preliminar sea un ejercicio de búsqueda de consenso. Por tanto, no estoy de acuerdo con las dos frases "tales como" de esta propuesta. Pero apoyo permitir que Crats cierre la solicitud / petición si es claramente inapropiada o es poco probable que tenga éxito, según nuestros principios de SNOW. Dicho esto, también estoy de acuerdo con Tryptofish a continuación en que las solicitudes / peticiones equivocadas o perturbadoras son bastante inofensivas, ya que simplemente se desvanecerán, por lo que esto es más en el espíritu de limpieza que cualquier otra cosa. Martinp ( charla ) 21:25, 6 de marzo de 2021 (UTC)
Oponerse a
- Oponerse Cuanto más lo pienso, más me disgusta la posibilidad de que un administrador "malo" pueda tener un amigo de Crat que pueda quitarle la decisión a la comunidad. Huggums537 ( charla ) 17:51, 27 de febrero de 2021 (UTC)
- Sospecho que si eso sucediera, el 'crat en cuestión tendría la cabeza en un plato y recibiría una fuerte patada. Aquí hay un ejemplo de la comunidad que se enoja bastante con un 'crat que parece ir por encima de su estación. Ritchie333 (charla) (continuación) 18:57, 27 de febrero de 2021 (UTC)
- Bueno, esperemos que así sea. Mientras tanto, mi posición sigue siendo opuesta. Huggums537 ( charla ) 23:22, 27 de febrero de 2021 (UTC)
- Sospecho que si eso sucediera, el 'crat en cuestión tendría la cabeza en un plato y recibiría una fuerte patada. Aquí hay un ejemplo de la comunidad que se enoja bastante con un 'crat que parece ir por encima de su estación. Ritchie333 (charla) (continuación) 18:57, 27 de febrero de 2021 (UTC)
- El período de aprobación debería ser una salvaguardia suficiente contra este problema. - Calidum 20:04, 27 de febrero de 2021 (UTC)
- No me opongo firmemente a esto, pero una vez que quede claro que probablemente habrá un consenso en contra del abandono, no será demasiado estresante dejar que el proceso se desarrolle solo. - Tryptofish ( charla ) 21:20, 27 de febrero de 2021 (UTC)
- Oponerse demasiado al potencial de abuso. Coretheapple ( charla ) 16:07, 28 de febrero de 2021 (UTC)
- Oponerse ¿Qué pasa si el administrador en cuestión también es un 'crat? 🐔 ¡ Chicdat Bawk para mí! 11:37, 5 de marzo de 2021 (UTC)
- Una vez más, no he visto a nadie preguntarles a los Crat qué piensan de esta nueva responsabilidad, que está tremendamente fuera de sus competencias habituales. Les está pidiendo que sean jueces y que "desestimen con prejuicios" un caso contra un administrador, lo que no es probable que hagan ya que sería controvertido y los Crats generalmente solo hacen cosas no controvertidas, por lo que la regla se vuelve discutible. Dennis Brown - 2 ¢ 12:16, 7 de marzo de 2021 (UTC)
Neutral
Comentario
Utilice RfA de "reconfirmación"
Para evaluar la confianza de la comunidad en que el usuario permanezca como administrador, utilizamos el proceso de RfA existente con los mismos criterios que los RfA existentes.
Apoyo
- Soporte . SilkTork ( charla ) 13:36, 27 de febrero de 2021 (UTC)
- Soporte como opción aceptable. Aceptaría una marca de "aprobado" tan bajo como 50% + 1. - Ryk72 talk 14:00, 27 de febrero de 2021 (UTC)
- Soporte Sugiero que las preguntas se relacionen con eventos en los que un Sysop estuvo activo y / o en WP general: política / pautas Paradise Chronicle ( charla ) 18:50, 27 de febrero de 2021 (UTC)
- Los administradores de soporte tienen demasiado poder. ArbCom tiene demasiado poder. Wikipedia me parece una oligarquía . 🐔 ¡ Chicdat Bawk para mí! 11:24, 5 de marzo de 2021 (UTC)
Oponerse a
- Fuerte oposición Un voto de la comunidad sobre las irregularidades de un administrador y un RfA son dos cosas fundamentalmente diferentes. En un RfA, todas las cosas buenas de un editor se revisan para ver si son adecuadas y califican para las herramientas. En una discusión sobre irregularidades, las acciones sospechosas están siendo objeto de escrutinio. Es muy probable que los votos vayan en dos direcciones opuestas, dependiendo de la discusión en la que entre. No deberíamos darles a los administradores que han sido objeto de escrutinio por perder la confianza de la comunidad el beneficio de tener una discusión sobre la "popularidad" de RfA que se llevaría a cabo de manera más apropiada en una discusión sobre irregularidades. Huggums537 ( charla ) 15:01, 27 de febrero de 2021 (UTC) Solo quiero agregar que este tipo de proceso sería muy parecido a llevar evidencia de un editor problemático a ANI y simplemente permitirles hacer su solicitud de desbloqueo allí mismo antes de que hayan sido bloqueados, en lugar de dejar que la discusión se desarrolle. Huggums537 ( charla ) 19:08, 27 de febrero de 2021 (UTC)
- Me opongo firmemente a utilizar este sistema en lugar de los umbrales porcentuales y el enfoque de la propuesta principal de este RfC. Y si la intención aquí es exigir un nuevo RpA en lugar de la propuesta principal, entonces, ¿cómo se decide que se requerirá una reconfirmación? Y una vez que alguien pierde su empleo, un nuevo RfA ya es evidente como la forma de recuperar las herramientas. - Tryptofish ( charla ) 21:25, 27 de febrero de 2021 (UTC)
- . El propósito es diferente: en un RfA, estamos adivinando acerca de la idoneidad; En una discusión sobre desysop, generalmente hay problemas específicos, y el formato de nuestro actual RpA muy probablemente conduciría a una argumentación que aumentaría el conflicto. De hecho, muchos administradores potencialmente buenos ya se niegan a postularse debido a la naturaleza de nuestras RpA; llevarlas a cabo en circunstancias como estas sería mucho peor. DGG ( charla ) 22:35, 1 de marzo de 2021 (UTC)
- Fuerte oposición . Los administradores existentes pueden caer fácilmente por debajo del 75% de soporte. En la OMI, el propósito de exigir el apoyo de la supermayoría para la RpA no es solo garantizar un fuerte consenso para la promoción, sino también garantizar que la decisión no se revierta fácilmente por un problema trivial unos meses después. Creo que el 50% es un buen umbral para retener la administración (no el 40% como lo propone OP, o el 75% como se propone aquí). - Rey de ♥ ♦ ♣ ♠ 17:56, 2 de marzo de 2021 (UTC)
- Oponerse . La heurística de Recentism / disponibilidad significará que las decisiones se verán manchadas por lo que ha sucedido recientemente. Stifle ( charla ) 10:08, 3 de marzo de 2021 (UTC)
- Oponerse según DGG . No es necesario repetir sus comentarios. Dennis Brown - 2 ¢ 17:28, 5 de marzo de 2021 (UTC)
- Fuerte oposición, creo . Interpreto esto que los administradores arrastrados a través de este proceso necesitan llegar a un consenso para * mantener * el bit, con cierto debate sobre si debería ser la "supermayoría" necesaria para un nuevo + sysop, o un ligero margen de maniobra como históricamente se ha dado para -RfAs de reconfirmación irregular. Creo firmemente que, en cambio, deberíamos requerir consenso para * eliminar * el bit.
- De hecho, a medida que sigo leyendo esto, me doy cuenta de que hay una diferencia fundamental muy importante entre la propuesta de Tony y la de SilkTork. En la propuesta de Tony, hay una "petición de retirada" con algunas condiciones para asegurarse de que haya suficientes miembros activos de la comunidad y luego una "de-RFA" (en RFA) para buscar el consenso de -sysop. En SilkTork, la etapa de "petición de retirada" ya es una discusión negociada por crat donde se necesita un "mini consenso" para pasar a la siguiente etapa de -sysop, que es entonces una RFA de reconfirmación que necesita consenso para mantener el bit. Creo que esto es mucho más propenso al abuso y mucho más estresante, y terminará sopesando a muchos más administradores. Los participantes de la primera etapa pueden decir: "No nos estamos desanimando, solo decimos que deberíamos pensar en ello" y luego la segunda etapa invariablemente terminará diciendo "bueno, hubo un consenso de que X debería perder el bit, por lo que es tautológicamente claro que no tenemos una confianza supermayoritaria en X ". Si esto es correcto, prefiero las propuestas de Tony a las de SilkTork. Martinp ( charla ) 21:38, 6 de marzo de 2021 (UTC)
Neutral
- Esta propuesta requiere ser desarrollada antes de que pueda favorecer u oponerme. Coretheapple ( charla ) 16:10, 28 de febrero de 2021 (UTC)
- Ídem. ¿Es esta la misma propuesta que la de Tony Ballioni pero sin requisitos especiales más allá de la necesidad de un consenso AN (I)? Jo-Jo Eumerus ( charla ) 10:51, 3 de marzo de 2021 (UTC)
Comentario
- Si bien debería ser una votación de algún tipo, esto es demasiado vago para que pueda comentarlo más. - Calidum 20:01, 27 de febrero de 2021 (UTC)
- Estoy de acuerdo en que el proponente debe desarrollarlo. ¿Cómo empieza esto? Alguien inicia una RfA diciendo: "Creo que este administrador debería ser eliminado, ya que no es bueno por las siguientes razones". ¿Y luego pasa a votación? ¿Quizás se conoce como "RfD" (Solicitud a Desysop}? Eso es sencillo, diré. Coretheapple ( charla ) 16:12, 28 de febrero de 2021 (UTC)
- Tenía la impresión de que la propuesta original tenía la intención de utilizar RpA de reconfirmación. Anarchyte ( charla • trabajo ) 07:15, 1 de marzo de 2021 (UTC)
Solicitudes repetidas
Para evitar solicitudes molestas, un administrador sujeto a una solicitud de desysop que falló no puede estar sujeto a una solicitud de desysop adicional:
- por cualquier motivo dentro de 1 mes después de que una solicitud falla debido a la falta de endosos
- por cualquier motivo dentro de los 3 meses posteriores a la falla de una solicitud debido a una falta de consenso en la RFDA de una semana
- en cualquier momento futuro basado en los hilos AN citados en el momento de la primera solicitud mencionada.
Apoyo
- Como autor. Stifle ( charla ) 09:39, 2 de marzo de 2021 (UTC)
Oponerse a
- Oponerse al consenso puede cambiar. 🐔 ¡ Chicdat Bawk para mí! 11:39, 5 de marzo de 2021 (UTC)
Neutral
Comentario
Para garantizar que un administrador tenga un respiro después de una solicitud fallida y que una vez que se haya citado una conducta en particular, no se pueda volver a utilizar. Stifle ( charla ) 09:39, 2 de marzo de 2021 (UTC)
El elefante en el cuarto
Verdad básica n. ° 1:
durante muchos años, cada vez que ha habido una discusión sobre cómo se debe ganar y perder el bit del sistema, ha habido un consenso abrumador, a menudo por encima del 70%, de que el sistema actual está muy roto y necesita ser arreglado.
Verdad básica n. ° 2:
durante muchos años, las mentes más brillantes de Wikipedia han propuesto una amplia variedad de soluciones al problema anterior, cada una de las cuales no logra el consenso. Muchos no alcanzan el 10%. Algunos lo hacen algo mejor, pero nunca lo suficiente como para aprobar.
Cada vez que veo una nueva propuesta, me pregunto si esta finalmente será la que rompa el patrón. Cada vez que termino decepcionado. Sin embargo, la esperanza es eterna. - Guy Macon ( charla ) 15:02, 27 de febrero de 2021 (UTC)
- ¡Felicidades por lograr lo que todos hemos estado pensando durante 20 años! 🐔 ¡ Chicdat Bawk para mí! 11:46, 5 de marzo de 2021 (UTC)
- * Bing * sobresaliente para Guy por dar en el clavo directamente en la cabeza. Ritchie333 (charla) (continuación) 18:30, 27 de febrero de 2021 (UTC)
- ¡Exactamente! ¡Gracias Guy Macon por decir esto! - Tryptofish ( charla ) 21:26, 27 de febrero de 2021 (UTC)
- ¿Qué tiene de "gravemente roto" el sistema actual? Quizás el primer paso sea llegar a un consenso sobre cuáles son los problemas. Luego, tiene una base sobre la cual tener discusiones sobre propuestas para abordar los problemas y cómo se pretende solucionarlos. - wbm1058 ( conversación ) 23:16, 27 de febrero de 2021 (UTC)
- ( Editar conflicto ) Tenga en cuenta que dije que hay un consenso abrumador de que el sistema actual está muy dañado y necesita ser reparado. Realice su propia encuesta si lo duda. No quise dar a entender que había un consenso sobre cómo se rompió. Eso es parte del problema. Cuando las mejores mentes de Wikipedia propusieron una amplia variedad de soluciones, muchas de ellas empezaron por intentar llegar a un consenso sobre cuáles eran los problemas. Así que esa tampoco es la fórmula mágica. Muy pocas veces veo una solución propuesta que no se haya probado y haya fallado varias veces.
- Casi todas las veces que he expresado la opinión anterior de "dos verdades básicas" en el pasado, varios lectores terminan diciéndose a sí mismos "Eso es fácil de arreglar. ¡Todo lo que tienes que hacer es X!". Pero nunca logran obtener el consenso necesario para que la comunidad pruebe X. Uno solo puede esperar que finalmente, esta conversación sea la que tenga éxito en hacer un cambio. El hecho de que todos los esfuerzos anteriores hayan fracasado no prueba que lo harán todos los esfuerzos futuros. - Guy Macon ( charla ) 00:48, 28 de febrero de 2021 (UTC)
- ¿Qué tiene de "gravemente roto" el sistema actual? Quizás el primer paso sea llegar a un consenso sobre cuáles son los problemas. Luego, tiene una base sobre la cual tener discusiones sobre propuestas para abordar los problemas y cómo se pretende solucionarlos. - wbm1058 ( conversación ) 23:16, 27 de febrero de 2021 (UTC)
- Durante mucho tiempo he defendido precisamente eso. Pero ha habido poco trabajo hacia ese fin. Es fácil idear procesos para la desadministración. Muchos, muchos, muchos editores bien intencionados han hecho exactamente eso . Este es otro más. Desafortunadamente, dependiendo de la experiencia del cerrador de este RfC, esto tiene la posibilidad de ser aceptado como política, sin que se haya realizado ningún trabajo de antemano. También podríamos construir el Empire State Building primero y luego ser completamente aleatorios sobre los cimientos sobre los que lo colocamos. ¿A quién le importa si se cae? ¿A quién le importa si destruye muchos edificios a su alrededor? ¡Es mejor que nada!
- Hammersoft ( charla ) 00:41, 28 de febrero de 2021 (UTC)
- Durante mucho tiempo he defendido precisamente eso. Pero ha habido poco trabajo hacia ese fin. Es fácil idear procesos para la desadministración. Muchos, muchos, muchos editores bien intencionados han hecho exactamente eso . Este es otro más. Desafortunadamente, dependiendo de la experiencia del cerrador de este RfC, esto tiene la posibilidad de ser aceptado como política, sin que se haya realizado ningún trabajo de antemano. También podríamos construir el Empire State Building primero y luego ser completamente aleatorios sobre los cimientos sobre los que lo colocamos. ¿A quién le importa si se cae? ¿A quién le importa si destruye muchos edificios a su alrededor? ¡Es mejor que nada!
- Buen punto. De todas las soluciones que he visto propuestas, muy pocas se han molestado siquiera en buscar y ver si una solución propuesta anterior era similar. Mi propio "Eso es fácil de arreglar. ¡Todo lo que tienes que hacer es X!" La teoría que no funcionará es comenzar por dedicar la enorme cantidad de tiempo necesaria para documentar todos o la mayoría de los esfuerzos anteriores para definir el problema y los esfuerzos para solucionar el problema en un solo lugar. No hace falta decir que las palabras "Durante mucho tiempo he abogado por ..." son un ejemplo de la Verdad Básica # 2 anterior. :) - Guy Macon ( charla ) 00:57, 28 de febrero de 2021 (UTC)
- Se me ocurre que la mayoría de los problemas relacionados con las políticas que se presentan ante la comunidad no combinan (a) la construcción de un proceso completamente nuevo de varios pasos con (b) algo que se siente de gran importancia porque implica eliminar un privilegio previamente conferido. Hay cambios de política propuestos que tratan con las cosas que la gente siente fuertemente, pero por lo general no requieren la creación de un nuevo proceso. Creo que puede estar integrado en la idea básica de un nuevo procedimiento de desysop basado en la comunidad que, sin importar cómo se construya, presentará un objetivo inusualmente grande para que las personas encuentren algo, en algún lugar de la propuesta, con lo que no estén de acuerdo. con. - Tryptofish ( charla ) 19:55, 28 de febrero de 2021 (UTC)
Elefante alternativo en la habitación
Considero que el verdadero "elefante en la habitación" es que, en lugar de arreglar RfA, intentamos crear innumerables procesos para la desaminación . - Jules (Mrjulesd) 12:24, 3 de marzo de 2021 (UTC)
- acordado. - Nabla ( charla ) 20:00, 3 de marzo de 2021 (UTC)
- Exactamente. Yo agregaría la Verdad Básica # 3 a la mezcla aquí: que no hay un "consenso abrumador" - obviamente - que generalmente es fácil conseguir una mayoría para respaldar un resumen ¡Deberíamos cambiar el sistema! voto de protesta (ver la política del mundo real para muchos ejemplos tristes y lamentables), y que bastantes personas que votan por "¡¡Tira a los vagabundos !!" en abstracto, se opone a la hora de afrontar elecciones concretas. (Esta es la razón por la que, con bastante astucia, los lanzadores de ladrillos suelen presentar sus propuestas de protesta en un conjunto de términos tan vago como les sea posible, para luego reclamar un "consenso abrumador" en torno a lo que la gente quiere). Ravenswing 13:08, 5 Marzo de 2021 (UTC)
- Estoy en desacuerdo. Existe una diferencia muy real entre "no hay consenso de que hay un problema" y "un consenso abrumador de que hay un problema, no hay consenso sobre una solución". Parece que está diciendo que el último consenso no puede existir. - Guy Macon ( charla ) 13:59, 5 de marzo de 2021 (UTC)
- Creo que este RfC no demuestra que existe un "consenso abrumador de que existe un problema". Pero también se podría decir que, hasta que se encuentre un proceso satisfactorio, cualquier "consenso abrumador de que hay un problema" es discutible, porque ¿qué pasa si no existe un proceso satisfactorio fuera del comité? - Jules (Mrjulesd) 15:09, 5 de marzo de 2021 (UTC)
- Esta propuesta cuenta con aproximadamente un 60 por ciento de apoyo. Además de eso, muchos de los que están en las columnas opuestas y neutrales, como yo, hemos reconocido que de hecho hay un problema, pero creen que esta es una solución imperfecta (por la razón que sea). Ese es un consenso bastante fuerte. - Calidum 16:16, 5 de marzo de 2021 (UTC)
- Como dije anteriormente, cada vez que veo una nueva propuesta, me pregunto si finalmente será esta la que rompa el patrón. Cada vez que termino decepcionado. Sin embargo, la esperanza es eterna. ¿Será esta propuesta la que rompa el patrón? Podría ser. Incluso los patrones de larga data como "No hay nieve en Malibu, California" a veces se rompen [8] O tal vez no. [9] - Guy Macon ( charla ) 16:57, 5 de marzo de 2021 (UTC)
- Como siempre, cree que existe un supuesto problema, cree que existe una supuesta solución, pero se decepciona cuando la supuesta solución es inferior. Lavar y repetir . - Jules (Mrjulesd) 18:57, 6 de marzo de 2021 (UTC)
- La dificultad para resolver un problema no equivale a la inexistencia de una solución, ni a la inexistencia del problema. - Tryptofish ( charla ) 19:10, 6 de marzo de 2021 (UTC)
- ¿Pero que problema? ¿Realmente puede demostrar que existe un problema? Hasta donde yo sé, Arbcom hace un trabajo razonable, o al menos uno mejor que el "malvado hijastro de RfA" que probablemente haga. - Jules (Mrjulesd) 21:57, 6 de marzo de 2021 (UTC)
- En primer lugar, estoy de acuerdo con usted en que ArbCom actualmente hace un trabajo bastante bueno tal como está. Pero en otra parte de esta página , verá una discusión en la que un miembro de ArbCom señala que hay algunas cosas en las que ArbCom podría querer que la comunidad se involucre más. Me parece un poco simplista descartar el arduo trabajo de tantos miembros. de la comunidad, tratando de encontrar mejoras viables, como "lavar y repetir". - Tryptofish ( conversación ) 23:43, 6 de marzo de 2021 (UTC)
- ¿Por qué soy tan despectivo? En primer lugar, porque deberíamos arreglar RfA en su lugar. En segundo lugar, porque los procesos paralelos inferiores nunca son útiles. En tercer lugar, porque las propuestas perennes suelen ser erróneas y una pérdida de tiempo, y esta no es una excepción. En cuarto lugar, porque no quiero que los administradores pasen por procesos malvados. Jules (Mrjulesd) 08:52, 7 de marzo de 2021 (UTC)
- No tengo ningún problema con la esencia de sus puntos de vista sobre la desocupación, pero estoy muy, muy cansado de que la cultura de los editores desestime las sinceras preocupaciones de otros editores. Puedes expresar las opiniones que tienes sin ser irrespetuoso. - Tryptofish ( conversación ) 23:47, 7 de marzo de 2021 (UTC)
- ¿Por qué soy tan despectivo? En primer lugar, porque deberíamos arreglar RfA en su lugar. En segundo lugar, porque los procesos paralelos inferiores nunca son útiles. En tercer lugar, porque las propuestas perennes suelen ser erróneas y una pérdida de tiempo, y esta no es una excepción. En cuarto lugar, porque no quiero que los administradores pasen por procesos malvados. Jules (Mrjulesd) 08:52, 7 de marzo de 2021 (UTC)
- En primer lugar, estoy de acuerdo con usted en que ArbCom actualmente hace un trabajo bastante bueno tal como está. Pero en otra parte de esta página , verá una discusión en la que un miembro de ArbCom señala que hay algunas cosas en las que ArbCom podría querer que la comunidad se involucre más. Me parece un poco simplista descartar el arduo trabajo de tantos miembros. de la comunidad, tratando de encontrar mejoras viables, como "lavar y repetir". - Tryptofish ( conversación ) 23:43, 6 de marzo de 2021 (UTC)
- ¿Pero que problema? ¿Realmente puede demostrar que existe un problema? Hasta donde yo sé, Arbcom hace un trabajo razonable, o al menos uno mejor que el "malvado hijastro de RfA" que probablemente haga. - Jules (Mrjulesd) 21:57, 6 de marzo de 2021 (UTC)
- La dificultad para resolver un problema no equivale a la inexistencia de una solución, ni a la inexistencia del problema. - Tryptofish ( charla ) 19:10, 6 de marzo de 2021 (UTC)
- Esta propuesta cuenta con aproximadamente un 60 por ciento de apoyo. Además de eso, muchos de los que están en las columnas opuestas y neutrales, como yo, hemos reconocido que de hecho hay un problema, pero creen que esta es una solución imperfecta (por la razón que sea). Ese es un consenso bastante fuerte. - Calidum 16:16, 5 de marzo de 2021 (UTC)
- Creo que este RfC no demuestra que existe un "consenso abrumador de que existe un problema". Pero también se podría decir que, hasta que se encuentre un proceso satisfactorio, cualquier "consenso abrumador de que hay un problema" es discutible, porque ¿qué pasa si no existe un proceso satisfactorio fuera del comité? - Jules (Mrjulesd) 15:09, 5 de marzo de 2021 (UTC)
- Estoy en desacuerdo. Existe una diferencia muy real entre "no hay consenso de que hay un problema" y "un consenso abrumador de que hay un problema, no hay consenso sobre una solución". Parece que está diciendo que el último consenso no puede existir. - Guy Macon ( charla ) 13:59, 5 de marzo de 2021 (UTC)
Todavía es discutible si el Comité 'hace un buen trabajo' o no: no hay arbitraje , a menos que, por supuesto, el caso actual finalmente rompa el patrón y al menos examine la veracidad de los reclamos y el comportamiento de los demandantes antes de pronunciarse. su veredicto e imponer la sentencia más severa que pueden, porque pueden. De lo contrario, en mi opinión, todo lo que Arbcom realmente hace (los que quedan después de las recusales y los que están convenientemente en un Wikibreak) es leer el consenso de todos los WikiCops involucrados, no involucrados y aspirantes (los habituales en los tablones de anuncios) y da la multitud frenética lo que quieren escuchar. A veces parece que el decoro de los participantes no es mejor que el de la galería de maní en ANI y es igualmente bloqueable o desyopable. Los casos de Arbcom están desequilibrados de todos modos porque se trata de enjuiciamiento y 'evidencia' y se permite poca o ninguna defensa. No hay muchas soluciones alternativas que la comunidad pueda encontrar que sean más equitativas o efectivas, según sea el caso, y los casos son tan raros que un ensayo tendría que durar 5 años para ser una muestra razonable. Kudpung กุด ผึ้ง ( charla ) 09:54, 7 de marzo de 2021 (UTC)
Cuando solicitó un Arbcom. asiento en 2019, presumiblemente debe haberlo considerado un papel digno de su tiempo y esfuerzo. No tenías planes para la reforma de Arbcom. Posteriormente tuvo su Admin. privilegios eliminados por el mismo comité del que podría haber sido miembro. Hacer comentarios sarcásticos sobre los miembros de AC '' convenientemente en un Wikibreak '', '' Arbcom se ha hecho una tarea fácil para ellos en los últimos tiempos, casi alineando a los administradores contra la pared y disparándoles en una sesión '', etc., no simplemente ¿Indican amargura de rechazo? Repitiendo persistentemente tropos cansados; "Mobs frenéticos, la galería de cacahuetes, aspirantes a WikiCops" relacionados con la comunidad en general, tampoco ayudan. Si tiene pruebas, preséntelas en lugar de realizar ataques amplios sin fundamento. Caldero con fugas ( charla ) 12:41, 8 de marzo de 2021 (UTC)
- Sí, lo siento por los comentaristas anteriores, pero el 58% a favor (que es donde se encuentra la propuesta ahora) es la mayoría. Ciertamente no es un "consenso", y mucho menos uno abrumador. Nadie se atrevería a cambiar una política o una directriz con tal margen, ningún AfD aprobaría con uno, ninguna acción en ANI pasaría con un margen tan pequeño, y un RfA con un nivel de apoyo tan pequeño fracasaría ... suponiendo que el candidato no canceló todo el asunto desde el principio con la premisa (precisa) de que una candidatura con hasta un 40% de oposición estaba condenada al fracaso. Ravenswing 19:16, 7 de marzo de 2021 (UTC)
- La realidad es que no hay porcentaje. Hay alguien arriba que indicó que hay un 60% de apoyo y que esto significa que hay un fuerte consenso. Esto es evidentemente falso. No se evalúa el consenso contando los votos. De los votos de oposición y apoyo se desprende claramente que existe un gran desacuerdo sobre esta propuesta. Muchos de los votos a favor y en contra son, en el mejor de los casos, equívocos y describen cosas que se buscan en la propuesta que no están en la propuesta. Me preocupa profundamente que esta propuesta sea cerrada por un cerrador sin experiencia o con poca experiencia. Esto generará una enorme controversia en torno a esta propuesta si el más cercano la decreta como exitosa. Incluso un cerrador con mucha experiencia probablemente logre el mismo resultado. No hubo discusión sobre esta propuesta con respecto a su cierre antes de su lanzamiento. Ahora nos quedamos en este enigma de cómo proceder para cerrarlo. Está plagado de dificultades. Esto era totalmente predecible porque no se hizo la tarea previa que era necesario hacer para sentar las bases de esta propuesta. Estamos hablando de un cambio fundamental en la operación del proyecto que podría causar una destrucción catastrófica del cuerpo administrativo. Esto nunca debería haber avanzado en su forma actual, y ahora nos quedamos con este lío muy dividido. Algunos cerradores emprendedores y bien intencionados intentarán cerrar, sin darse cuenta del tsunami que están desatando. Pero, supongo que si arrojas suficientes espaguetis contra la pared, algo eventualmente se pegará, y al diablo con las consecuencias. Tengo dudas reales de que si se va a leer más de cerca las más de 100 páginas impresas de comentarios sobre esta propuesta. - Hammersoft ( charla ) 19:53, 7 de marzo de 2021 (UTC)
- Ya que me está citando (mal), creo que debería reiterar que no dije que hubiera un fuerte consenso para este procedimiento de desysop comunitario. Dije que hay un fuerte consenso de que se necesita un procedimiento de desysop comunitario dado que incluso algunos de los que se oponen o son neutrales a esta propuesta lo han dicho. Y solo un consejo amistoso, pierda la hipérbole. No hace ningún bien a tu causa. - Calidum 20:10, 7 de marzo de 2021 (UTC)
- Tenga en cuenta que sus palabras se pueden leer desde múltiples perspectivas y que las comunicaciones basadas en texto tienen sus limitaciones. No te estaba atacando, y preferiría que no tomaras lo negativo donde lo negativo no se pretendía, y que me devolvieras esa negatividad percibida. Tampoco hice ninguna exageración de ningún tipo. Hablo lo que es la verdad desde mi perspectiva. - Hammersoft ( charla ) 03:21, 8 de marzo de 2021 (UTC)
- Ya que me está citando (mal), creo que debería reiterar que no dije que hubiera un fuerte consenso para este procedimiento de desysop comunitario. Dije que hay un fuerte consenso de que se necesita un procedimiento de desysop comunitario dado que incluso algunos de los que se oponen o son neutrales a esta propuesta lo han dicho. Y solo un consejo amistoso, pierda la hipérbole. No hace ningún bien a tu causa. - Calidum 20:10, 7 de marzo de 2021 (UTC)
- La realidad es que no hay porcentaje. Hay alguien arriba que indicó que hay un 60% de apoyo y que esto significa que hay un fuerte consenso. Esto es evidentemente falso. No se evalúa el consenso contando los votos. De los votos de oposición y apoyo se desprende claramente que existe un gran desacuerdo sobre esta propuesta. Muchos de los votos a favor y en contra son, en el mejor de los casos, equívocos y describen cosas que se buscan en la propuesta que no están en la propuesta. Me preocupa profundamente que esta propuesta sea cerrada por un cerrador sin experiencia o con poca experiencia. Esto generará una enorme controversia en torno a esta propuesta si el más cercano la decreta como exitosa. Incluso un cerrador con mucha experiencia probablemente logre el mismo resultado. No hubo discusión sobre esta propuesta con respecto a su cierre antes de su lanzamiento. Ahora nos quedamos en este enigma de cómo proceder para cerrarlo. Está plagado de dificultades. Esto era totalmente predecible porque no se hizo la tarea previa que era necesario hacer para sentar las bases de esta propuesta. Estamos hablando de un cambio fundamental en la operación del proyecto que podría causar una destrucción catastrófica del cuerpo administrativo. Esto nunca debería haber avanzado en su forma actual, y ahora nos quedamos con este lío muy dividido. Algunos cerradores emprendedores y bien intencionados intentarán cerrar, sin darse cuenta del tsunami que están desatando. Pero, supongo que si arrojas suficientes espaguetis contra la pared, algo eventualmente se pegará, y al diablo con las consecuencias. Tengo dudas reales de que si se va a leer más de cerca las más de 100 páginas impresas de comentarios sobre esta propuesta. - Hammersoft ( charla ) 19:53, 7 de marzo de 2021 (UTC)
¿Puedo señalar amablemente que algunos de ustedes se han apropiado de esta sección y ya no están hablando del tema en la parte superior? ¿Puedo sugerirle que cree un nuevo hilo y mueva lo que sea que esté ahí para que el resto de nosotros podamos discutir la Verdad Básica # 1 y la Verdad Básica # 2 en paz? - Guy Macon ( conversación ) 15:39, 8 de marzo de 2021 (UTC)
- Pero, ¿qué pasa si no estamos de acuerdo con sus "verdades básicas"? Después de todo, esta es una sección de comentarios. Mi verdad "básica" es que sería mejor arreglar RfA. - Jules (Mrjulesd) 15:59, 8 de marzo de 2021 (UTC)
- Si quiere estar en desacuerdo con mis "verdades básicas", esta es la sección correcta. Si desea hablar sobre otras cosas con comentarios como "la cultura de los editores es despreciativa de las preocupaciones sinceras de otros editores", "considere que sus palabras se pueden leer desde múltiples perspectivas" y "los casos de arbcom están desequilibrados de todos modos porque se trata de enjuiciamiento y se permiten "pruebas" y poca o ninguna defensa ", y sí, incluso" Mi verdad "básica" es que estaríamos mejor si arreglamos la RfA ", está bien, pero hágalo en su propia sección en lugar de secuestrar esto. hilo con material que no tiene nada que ver con mi argumento. - Guy Macon ( charla ) 00:56, 10 de marzo de 2021 (UTC)
- Esto es una tontería ya que nunca secuestró tu hilo, estaba bastante separado. Pero muy bien, he creado un nuevo hilo en su lugar. - Jules (Mrjulesd) 01:02, 10 de marzo de 2021 (UTC)
- Si quiere estar en desacuerdo con mis "verdades básicas", esta es la sección correcta. Si desea hablar sobre otras cosas con comentarios como "la cultura de los editores es despreciativa de las preocupaciones sinceras de otros editores", "considere que sus palabras se pueden leer desde múltiples perspectivas" y "los casos de arbcom están desequilibrados de todos modos porque se trata de enjuiciamiento y se permiten "pruebas" y poca o ninguna defensa ", y sí, incluso" Mi verdad "básica" es que estaríamos mejor si arreglamos la RfA ", está bien, pero hágalo en su propia sección en lugar de secuestrar esto. hilo con material que no tiene nada que ver con mi argumento. - Guy Macon ( charla ) 00:56, 10 de marzo de 2021 (UTC)
Periodo de prueba
Me pregunto cuántas personas en los campos opuestos o neutrales estarían dispuestas a apoyar un período de prueba de duración fija (digamos, 12 meses), después del cual volveríamos al status quo ante en espera de un consenso positivo para adoptar el procedimiento de forma indefinida.
Como ha notado mucha gente (aquí, y cada vez, así como en cada cambio propuesto a RfA), hay una gran cantidad de "¡¡se debe hacer algo !! ... pero ehhh, no esta cosa en particular". Esa actitud es parte de la premisa de una propuesta como esta, por lo que cualquier propuesta de este tipo debería tener un período de prueba. Hay muchas incógnitas y muchas preocupaciones válidas. Mi esperanza es que la gente esté dispuesta a ser optimista, con la seguridad de que tiene una fecha de finalización si no funciona.
Entonces, ¿hay suficientes personas que estarían dispuestas a decir "no es exactamente lo que quiero, pero es mejor que nada, por lo que vale la pena intentarlo durante un año" y cambiar su voto? - Hablar de las rododendritas \\ 21:59, 27 de febrero de 2021 (UTC)
- Por mi parte, no. No apoyaré un proceso que tenga repercusiones potencialmente masivas sin que haya un proceso de desarrollo cuidadoso que incluya el examen de la situación y la determinación del análisis del problema. La Wikipedia alemana sufrió un desgaste masivo de su cuerpo administrativo cuando implementaron su proceso. Esa fue una consecuencia no deseada. Creo que veremos el mismo tipo de desgaste masivo con este proceso, en el que muchos administradores ni siquiera se molestarán en defenderse una vez que alcance el quinto diamante en el diagrama de flujo del proceso . Creo que esto se debe en gran parte al hecho de la ausencia casi total de protecciones integradas en este sistema, y a la realidad de que no existe una capacidad incorporada para que un administrador se defienda en cualquier paso de este proceso. Es un mal proceso de principio a fin. Darle una prueba podría tener efectos dramáticamente negativos en el proyecto. - Hammersoft ( charla ) 22:51, 27 de febrero de 2021 (UTC)
- La propuesta principal tiene demasiados problemas que me dan ganas de mantenerme en contra, pero la propuesta por SilkTork parece mucho más viable. Tengo alguna esperanza para eso. Huggums537 ( charla ) 22:58, 27 de febrero de 2021 (UTC)
- Agregando que si no me opongo firmemente, entonces sin duda requeriría un período de prueba, pero me opongo firmemente a la propuesta. Huggums537 ( charla ) 07:51, 2 de marzo de 2021 (UTC)
- Ya hay bastantes soportes que han declarado en ellos que querrían una prueba. En muchos casos, no está claro si se consideran condicionales o no, algunos lo son claramente. De hecho, he optado por ser neutral si es un juicio, me opongo si no. Creo que algunos más se moverían si claramente necesitaran una nueva aprobación en el futuro, pero no estoy seguro de cuántos Nosebagbear ( hablar ) 02:38, 28 de febrero de 2021 (UTC)
- Creo que incluso aquellos como yo que básicamente lo aprueban están tan inseguros acerca de los detalles óptimos que sería imprudente adoptar un cambio importante como este sin una prueba. Hammersmith , sean cuales sean los parámetros que usemos, no creo que haya solicitudes masivas, y no podemos saber qué precauciones necesitamos y qué casos especiales debemos proporcionar sin un período de prueba. Si intentamos hacer todo bien en un proceso complicado antes de comenzar, nunca comenzaremos. DGG ( charla ) 12:12, 28 de febrero de 2021 (UTC)
- Ya hay bastantes soportes que han declarado en ellos que querrían una prueba. En muchos casos, no está claro si se consideran condicionales o no, algunos lo son claramente. De hecho, he optado por ser neutral si es un juicio, me opongo si no. Creo que algunos más se moverían si claramente necesitaran una nueva aprobación en el futuro, pero no estoy seguro de cuántos Nosebagbear ( hablar ) 02:38, 28 de febrero de 2021 (UTC)
- No apoyaría ni siquiera con un período de prueba porque creo que, tal como se enmarca la propuesta, no hay posibilidad de que se promulgue un abandono, sin importar cuánto tiempo se ofrezca el período de prueba. Tenemos aquí una propuesta de desocupación que probablemente nunca resultará en una desocupación, porque las condiciones son tales que es probable que nunca se cumplan, pero es probable que aumenten los mismos problemas que existen ahora en ANI ... administradores abusivos se apresurará a cerrar para proteger a otros administradores abusivos para que las condiciones nunca se cumplan, y los bumeranes aumentarán para apagar a cualquiera que se queje. Ese sistema ya se puede ver como prueba. Sandy Georgia ( Discusión ) 12:35, 28 de febrero de 2021 (UTC)
- Estoy de acuerdo con lo que dice SandyGeorgia anteriormente. Podría apoyar un período de prueba si pensara que la propuesta tiene alguna posibilidad realista de funcionar, pero ese no es el caso aquí. Además, como señala SandyGeorgia, la propuesta empeorará mucho las cosas en ANI. Los administradores ya son reacios a criticarse entre sí en los hilos AN y ANI. Solo cerrarán filas aún más si se promulga esta propuesta, incluso a modo de prueba, y si saben que cerrar un hilo de ANI con un hallazgo formal contra otro administrador constituye un requisito previo para un desysop. Cerrar cualquier hilo de ANI que involucre a un administrador será mucho más difícil, y el comportamiento partidista y cliquish allí aumentará dramáticamente. Los hilos se cerrarán, se volverán a abrir y luego se volverán a cerrar. Es probable que cada cierre de un hilo de este tipo, ya sea a favor o en contra de un administrador en particular, sea impugnado. ANI ya es disfuncional como está, y no necesitamos arruinarlo más durante un año para probar una propuesta poco realista. Nsk92 ( conversación ) 13:11, 28 de febrero de 2021 (UTC)
- Mis preocupaciones se centran en cómo esto se relaciona con el procedimiento ArbCom. Esos no desaparecerían, incluso en un ensayo de 1 año, en la propuesta tal como está redactada actualmente. Así que también es un no de mi parte. También estoy de acuerdo con los puntos de SG. ProcrastinationReader ( charla ) 13:52, 28 de febrero de 2021 (UTC)
- Por cierto, ¿cómo se relaciona esto con ArbCom? Espero que esta propuesta no saque a los desysop de su competencia, porque entonces efectivamente terminaremos sin medios para desysop. Esta propuesta está tan sesgada hacia dar más poder a los administradores para proteger a otros administradores, que no deja ninguna posibilidad para que la comunidad en general se ocupe del abuso de las herramientas, por lo que es de esperar que todavía podamos recurrir a ArbCom. Sandy Georgia ( Discusión ) 15:13, 28 de febrero de 2021 (UTC)
- Preguntado relativamente temprano, respondido relativamente temprano. Sin modificación de los procedimientos de ArbCom. ~ ToBeFree ( conversación ) 23:50, 1 de marzo de 2021 (UTC)
- Creo que, dado que el comité de arbitraje tiene la tarea de ser el último recurso para los problemas de conducta, habrá una tendencia a la objeción de aceptar solicitudes de casos que no sean de emergencia hasta que se complete la revisión de la comunidad, e imagino que cualquier resolución de caso posterior se someterá a la juicio de la comunidad, en ausencia de irregularidades significativas. isaacl ( charla ) 00:26, 2 de marzo de 2021 (UTC)
- @ SandyGeorgia : Lo siento, no vi esto debido a la falta de ping. Mi preocupación es que si esto se aprueba, ArbCom será aún más reacio a tomar cuestiones de conducta administrativa, en lugar de optar por decir que debería pasar a la comunidad. Y este proceso no reemplaza a ArbCom. Al menos por dos razones, la primera es que las estructuras de la comunidad no resuelven bien algunos problemas, una de las cuales probablemente sean problemas de administración con administradores activos ( sin incluir administradores de edad avanzada que están activos de forma intermitente). El segundo es que esta propuesta solo requiere un 40% de apoyo para conservar la administración. Estoy bastante seguro de que esto, un cambio a este método en lugar de ArbCom, es intencional de la propuesta. Incluso si el proceso de ArbCom se mantiene, esto parece un posible doble riesgo que sería profundamente desagradable tanto para el administrador como relativamente perturbador en el tiempo de la comunidad. Estas partes, y otras inquietudes sobre cómo esta propuesta interactúa con el método ArbCom, deben pensarse más a fondo antes de que se apruebe una propuesta, incluso una prueba. ProcrastinationReader ( charla ) 00:26, 8 de marzo de 2021 (UTC)
- Preguntado relativamente temprano, respondido relativamente temprano. Sin modificación de los procedimientos de ArbCom. ~ ToBeFree ( conversación ) 23:50, 1 de marzo de 2021 (UTC)
- Por cierto, ¿cómo se relaciona esto con ArbCom? Espero que esta propuesta no saque a los desysop de su competencia, porque entonces efectivamente terminaremos sin medios para desysop. Esta propuesta está tan sesgada hacia dar más poder a los administradores para proteger a otros administradores, que no deja ninguna posibilidad para que la comunidad en general se ocupe del abuso de las herramientas, por lo que es de esperar que todavía podamos recurrir a ArbCom. Sandy Georgia ( Discusión ) 15:13, 28 de febrero de 2021 (UTC)
No, una vez que esté adentro, no habrá vuelta atrás. Sofocar ( charla ) 09:40, 2 de marzo de 2021 (UTC)
- Creo que es una buena idea, Wikipedia debería estar abierta a experimentar con políticas. También ayudaría con otros proyectos, donde el procedimentalismo honesto está en camino de acabar con proyectos en otros idiomas. Kranke133 ( charla ) 10:29, 7 de marzo de 2021 (UTC)
Otorgue a las discusiones de AN / ANI el poder de pedirle a un administrador que se comprometa con una reconfirmación de RfA
Lo que me apoyo es si una discusión AN / ANI sobre un cierra de administrador con el consenso de que las necesidades de administrador para volver a aplicar para una reconfirmación de la ARF, y si el cierre AN / ANI recibe la aprobación de un crat / CRAT-chat para representar el consenso real, entonces el administrador, sin tener que renunciar / renunciar a sus herramientas, solicitará una reconfirmación de RfA o se acercará a ArbCom para una resolución si sienten que hay problemas con la discusión de AN / ANI que la comunidad no pudo / no pudo estar enterado secretamente. Lourdes 14:51, 28 de febrero de 2021 (UTC)
- Si un administrador "malo" ha obtenido suficiente consenso de que la comunidad siente que ha hecho lo suficientemente mal como para merecer necesitar una RfA, ¿por qué deberíamos perder el tiempo con él? Simplemente quite las herramientas y déjeles que hagan su propio RfA. ¿No se les permite volver a solicitar RfA de todos modos? Déjelos hacerlo en su propio tiempo. El mal comportamiento no debe ser recompensado con una oportunidad inmediata de "rehacer" o "probar". Los editores habituales pueden quedar bloqueados durante mucho tiempo por no actuar correctamente, y los administradores tampoco deberían ser inmunes a las consecuencias. A la larga, elimina los elementos malos y mantiene a los buenos en el camino correcto. Huggums537 ( charla ) 15:31, 28 de febrero de 2021 (UTC)
- Desde noviembre de 2018 , la comunidad ha poseído un medio técnico bastante robusto para promulgar un consenso social de que se debe evitar que un administrador realice más actividades administrativas (opcionalmente pendiente de reconfirmación), por lo que esto ya es posible bajo las estructuras existentes con la única diferencia de que requiere administradores. (no burócratas) para respaldar el consenso, ya que la aplicación no está dentro de las actividades permitidas de los burócratas y requeriría la aplicación de las políticas de Prohibición o Bloqueo .
Una discusión comunitaria donde se establece el consenso de que "un administrador no debe editar más mientras tiene privilegios administrativos sin una indicación renovada de confianza de la comunidad" (por ejemplo, reconfirmación de RfA) puede ser promulgada por un administrador a través de restricciones sociales o técnicas (permitiendo al usuario afectado editar WP: BN, WP: RFA, WP: RFAR o su página de discusión, únicamente). En este contexto, un administrador aún tendría la opción de presentar una petición al comité si hubiera preocupaciones de procedimiento sobre la discusión, mientras que aquellos que se negaran a someterse a una reconfirmación dentro de un período de gracia o renunciaran voluntariamente después de la aprobación del consenso podrían ser bloqueados procesalmente. La decisión de la comunidad podría entonces formalizarse mediante una simple moción que permitiera a los burócratas eliminar los privilegios administrativos.
El problema es que AN o ANI no están realmente estructurados para mantener una conversación como esta, y determinar el consenso de un hilo de 1 mb + AN en expansión será muy difícil. Esa es probablemente la razón por la que la mayoría de las propuestas de desysop intentan proporcionar algunas estructuras y barreras de entrada, y también por qué la mayoría de ellas terminan pareciendo " una RFA inversa ". ← Esta versión modificada de la propuesta de EVula nunca se presentó debido a argumentos convincentes de que el comité ya es un mecanismo de desysop comunitario efectivo con estructuras preexistentes y personal para moderar el volumen de calor a luz junto con la preocupación de que conduciría a una disminución. en lugar de un aumento de los administradores y la actividad administrativa. YMMV.
Tl; dr: Esto ya es posible: si se establece un consenso de que un administrador debe someterse a una reconfirmación, ese usuario puede restringir en consecuencia si no se adhiere al consenso dentro de un plazo aceptable. - xeno talk 17:10, 28 de febrero de 2021 (UTC)
- Que la capacidad técnica para hacer esto no significa que exista la voluntad social para proceder realmente de esa manera (en consecuencia, nunca antes había visto un consenso AN / ANI que limite a un administrador el uso de sus herramientas, ¿existe alguna? mismo concepto con El C antes y dijo que sería voluntario que un administrador se adhiriera a él a menos que ArbCom lo respaldara. Ver aquí ). ProcrastinationReader ( charla ) 17:21, 28 de febrero de 2021 (UTC)
- Sí, creo que lo más probable es que el comité de arbitraje presente una solicitud de caso de arbitraje y la acepte. (Aunque el sentimiento de la comunidad puede haber cambiado, el consenso anterior fue que solo el comité de arbitraje tiene el alcance para hacer cumplir la prohibición del uso de herramientas administrativas). Isaacl ( charla ) 17:36, 28 de febrero de 2021 (UTC)
No estoy seguro de si alguna vez se ha hecho así , pero es probable que haya WP: RFC / Us que llevó a los administradores a renunciar bajo la presión de la comunidad, y los administradores han sido bloqueados y socialmente restringidos antes. Alguien ( ¿ Iridiscente ?) Podría esbozar la historia de los administradores bloqueados (y si alguno llevó a una renuncia voluntaria o reconfirmaciones), pero la política de bloqueo se ha utilizado para evitar actividades administrativas inaceptables en el pasado. - xeno talk 17:44, 28 de febrero de 2021 (UTC)
- Es posible que haya habido otros, pero las únicas ocasiones en las que puedo pensar en las que un administrador se sometió voluntariamente a una reconfirmación sobre la base de que su juicio había sido cuestionado son las pocas que se enumeran en Wikipedia: reconfirmaciones permanentes . La más reciente de ellas fue Wikipedia: Solicitudes de administración / Herostratus 2 hace más de una década (la más reciente fue de alguien que había prometido cumplir solo un 'término' de cinco años y volver a ejecutar si quería mantener después de eso, en lugar de una reconfirmación por causa). Con la excepción de Everyking, que finalmente volvió a aparecer en el quinto intento después de cuatro reconfirmaciones fallidas, e incluso eso fue un baño de sangre (y nuevamente, hace más de una década), no tengo conocimiento de ninguna ocasión en la era moderna (es decir, cuando los administradores no eran solo amigos de Jimmy Wales) de alguien que perdió el bit por una causa y luego lo recuperó, además de calcetines como Law o Pastor Theo en los que el candidato se postuló como un nuevo usuario y la cuenta anterior no se reveló. A todos los efectos prácticos, la desocupación actúa como un impedimento permanente para que un editor vuelva a convertirse en administrador. - Iridiscente 17:59, 28 de febrero de 2021 (UTC)
- Para todos los propósitos prácticos, la desocupación actúa como un impedimento permanente para que un editor se convierta en administrador de nuevo, debería ser una advertencia para todos los administradores nuevos desde el primer día. Es algo que deben considerar en cada decisión, acción y comentario que hagan. Ya sea que se trate de un abuso de confianza único o de patrones de comportamiento crónicos exhibidos durante muchos años, la puerta a la desobediencia ahora está claramente abierta a través de Arbcom, que esencialmente ha reconocido que los tableros administrados por el administrador existentes solo muy rara vez tratarán de manera efectiva con uno de los suyos grupo. Volviendo al comentario citado, es una simple declaración de hechos, no creo que tenga la intención de ganar simpatía, de una forma u otra. Caldero con fugas ( charla ) 13:06, 1 de marzo de 2021 (UTC)
- @ Caldero con fugas : es incorrecto decir que
A todos los efectos prácticos, la desocupación actúa como un impedimento permanente para que un editor vuelva a convertirse en administrador
porque simplemente no hay evidencia que lo respalde. Más de 50 editores han sido despedidos por arbcom desde 2004, 12 fueron reelegidos por el comité (la más reciente, 2009). Del resto, solo 10 se han presentado a RFA, 5 tuvieron éxito y 5 no lo lograron. Solo 3 ex árbitros se han presentado a RFA desde 2015, ninguno desde 2019. De esos 3, uno falló porque los problemas por los que fueron despedidos aún estaban en curso, uno falló debido a nuevos problemas que habrían hecho que una primera RFA no tuviera éxito y otro falló. inmediatamente después de la desocupación, por lo que los editores no tuvieron oportunidad de decir si los números habían cesado o no. Para que su afirmación sea cierta, es necesario que haya varios editores que hayan hecho todo lo siguiente:- He sido destituido por una causa
- Edición continuada (o reanudada)
- Actuó para resolver los problemas que resultaron en su desaparición.
- No participar en ningún otro comportamiento que también hubiera resultado en un desysop o falló la primera RFA
- Se defendió de re-RFA
- Falló en esa re-RFA
- Los ejemplos más recientes que puedo encontrar de un editor que sigue los pasos del 1 al 5 son Everyking ( RFA ) y MZMcBride ( RFA ), ambos en 2009 y ambos tuvieron éxito. Por lo que puedo decir, han pasado más de 10 años desde que cualquiera que haya abordado las razones por las que fueron despedidos incluso ha defendido RFA ( Hawkeye7 ( RFA ) en 2019 falló en el punto 4, pero la RFA no tiene un consenso claro sobre si en realidad habían abordado el motivo de la desocupación o no). Por tanto, es imposible decir si la desocupación es o no una prohibición permanente. Consulte Usuario: Thryduulf / Qué sucedió después de un desysop para la mayoría de las estadísticas y enlaces. Thryduulf ( conversación ) 12:36, 9 de marzo de 2021 (UTC)
- Por favor, no me hecho de bomba, @ Thryduulf : . Estaba "citando" de la publicación inmediatamente anterior a la mía de Iridescent. Caldero con fugas ( charla ) 12:50, 9 de marzo de 2021 (UTC)
- @ Caldero con fugas : es incorrecto decir que
- @ Iridescent : Creo que la Q es más si la comunidad, que puede prohibir la actividad de edición de cualquier editor, también puede prohibir el uso de herramientas administrativas de un administrador. Por ejemplo, ¿"Iridescent tiene prohibido usar sus herramientas de sistema" o "Iridescent tiene prohibido bloquear a los editores" es un consenso válido y ejecutable en AN? Quiero decir, sí, el consenso puede hacer lo que quiera (es decir, si alguien puede tomar una acción y nadie se atreve a hacerlo, supongo que eso es válido), pero la idea es que algo por el estilo sucedió dentro de, digamos, el últimos 5 años? (si no es así, entonces, para todos los propósitos prácticos, ¿supongo que esto no es válido?) ProcrastinationsReader ( charla ) 14:03, 1 de marzo de 2021 (UTC)
- ProcrastATINGReader Ninguno tan reciente, los ejemplos son de 2006 a 2009 . Los administradores que se bloquean entre sí por problemas de larga duración no salieron bien en ese entonces, por lo que probablemente sea por eso que no hacemos mucho, prefiriendo referirnos a arbcom ... Cualquier cosa más complicada que una L1 o L2 realmente no puede ser manejado en AN / ANI. - xeno talk 03:33, 4 de marzo de 2021 (UTC)
- Para todos los propósitos prácticos, la desocupación actúa como un impedimento permanente para que un editor se convierta en administrador de nuevo, debería ser una advertencia para todos los administradores nuevos desde el primer día. Es algo que deben considerar en cada decisión, acción y comentario que hagan. Ya sea que se trate de un abuso de confianza único o de patrones de comportamiento crónicos exhibidos durante muchos años, la puerta a la desobediencia ahora está claramente abierta a través de Arbcom, que esencialmente ha reconocido que los tableros administrados por el administrador existentes solo muy rara vez tratarán de manera efectiva con uno de los suyos grupo. Volviendo al comentario citado, es una simple declaración de hechos, no creo que tenga la intención de ganar simpatía, de una forma u otra. Caldero con fugas ( charla ) 13:06, 1 de marzo de 2021 (UTC)
- Es posible que haya habido otros, pero las únicas ocasiones en las que puedo pensar en las que un administrador se sometió voluntariamente a una reconfirmación sobre la base de que su juicio había sido cuestionado son las pocas que se enumeran en Wikipedia: reconfirmaciones permanentes . La más reciente de ellas fue Wikipedia: Solicitudes de administración / Herostratus 2 hace más de una década (la más reciente fue de alguien que había prometido cumplir solo un 'término' de cinco años y volver a ejecutar si quería mantener después de eso, en lugar de una reconfirmación por causa). Con la excepción de Everyking, que finalmente volvió a aparecer en el quinto intento después de cuatro reconfirmaciones fallidas, e incluso eso fue un baño de sangre (y nuevamente, hace más de una década), no tengo conocimiento de ninguna ocasión en la era moderna (es decir, cuando los administradores no eran solo amigos de Jimmy Wales) de alguien que perdió el bit por una causa y luego lo recuperó, además de calcetines como Law o Pastor Theo en los que el candidato se postuló como un nuevo usuario y la cuenta anterior no se reveló. A todos los efectos prácticos, la desocupación actúa como un impedimento permanente para que un editor vuelva a convertirse en administrador. - Iridiscente 17:59, 28 de febrero de 2021 (UTC)
- Estoy de acuerdo con la declaración de xeno. Quiero agregar que, a veces, iterar sobre un proceso roto es mejor que intentar crear uno desde cero. No usamos prohibiciones como esta, pero no hay nada que diga que no podemos. Si la comunidad no confía en que un administrador use las herramientas, tenemos todo el derecho a decirlo. Si usan las herramientas a pesar de esa desconfianza, tenemos todo el derecho de imponer una restricción social (prohibición) sobre el uso de las herramientas. Si violan esa prohibición, tenemos todo el derecho a bloquearlos. El beneficio de utilizar nuestras políticas de prohibición y bloqueo existentes es que tenemos un control más detallado para manejar casos extremos. Las prohibiciones pueden ser indefinidas, claro, pero también pueden tener un límite de tiempo. Podemos prohibir el uso de herramientas por períodos de tiempo particulares o en áreas particulares. Al igual que los TBAN, podemos apuntar a áreas donde el comportamiento es problemático sin perder las buenas contribuciones que hacen en otros lugares. Ni siquiera necesitamos decir "no use sus herramientas en el área X", un TBAN regular lo detendría sin siquiera tener que cambiar radicalmente nuestros procedimientos estándar típicos. El problema que hemos visto con los diseños de arbcom es que tienen un solo martillo. Incluso aquí, solo tenemos una opción para tratar un problema. Es un desastre o nada. La realidad a la que nos hemos enfrentado es que las situaciones son complejas y un enfoque único para todos conduce a respuestas desproporcionadas similares a las sentencias mínimas obligatorias . Tal vez la respuesta sea simplemente comenzar a tratar a los administradores como editores normales imponiéndoles sanciones como hacemos con los que no lo tienen
+sysop
. - Wug · a · po · des 23:54, 3 de marzo de 2021 (UTC)
- Que la capacidad técnica para hacer esto no significa que exista la voluntad social para proceder realmente de esa manera (en consecuencia, nunca antes había visto un consenso AN / ANI que limite a un administrador el uso de sus herramientas, ¿existe alguna? mismo concepto con El C antes y dijo que sería voluntario que un administrador se adhiriera a él a menos que ArbCom lo respaldara. Ver aquí ). ProcrastinationReader ( charla ) 17:21, 28 de febrero de 2021 (UTC)
- Qué sistema tan complicado. ¡Joder! No creo que tenga mucho más que agregar a estas discusiones. Por lo que parece, todo parece que va a ser un lavado de todos modos, al igual que las discusiones anteriores. Parece que el "Guy" (sin juego de palabras) que publicó esta sección sabía lo que estaba diciendo. Sin embargo, se me ocurrió la idea de que otorgarle a AN / I el poder de hacer cumplir las reconfirmaciones administrativas de RfA podría ser una alternativa viable a los términos limitados de nombramiento, que sé que es contradictorio con mi declaración anterior, pero después de reflexionar sobre ello, creo que Sería más fácil instaurar algún tipo de proceso de reconfirmación de RfA solo para los malhechores que buscar a todos los administradores que tengan términos de servicio que vencen o deban renovarse. Huggums537 ( charla ) 20:19, 28 de febrero de 2021 (UTC)
- Siento que puedo apoyar algo como esto. Creo que debe haber un equilibrio entre la expectativa de la comunidad de responsabilizar a los administradores y reconocer que los administradores a menudo se ven obligados a tomar decisiones difíciles que son o pueden ser controvertidas. Creo que esta propuesta podría permitir que esas juntas expresen su disgusto por ciertas acciones administrativas y al mismo tiempo brindar su capacidad para decir que cierta conducta requiere que la comunidad intervenga para ver si el administrador debe retener las herramientas. - Enos733 ( charla ) 05:48, 1 de marzo de 2021 (UTC)
- xeno , con el debido respeto a lo que ha escrito, actualmente no hay una discusión AN / ANI que pueda pedirle a un administrador que se someta a una re-RfA o que deje de usar sus herramientas. Así que no estoy seguro de dónde ha interpretado esto. A diferencia de lo que ha dicho, esto no existe; sería genial si lo hiciera y se consagraría en la política. Lourdes 06:36, 1 de marzo de 2021 (UTC)
- Lourdes : Estaba pensando en una discusión hipotética en la que se establece que la actividad continua de un administrador se considera, según un fuerte consenso de la comunidad, como disruptiva (es decir, debido a que no se cumple con WP: ADMINCOND o WP: ADMINACCT ), tanto que el Se debe impedir que el administrador realice más actividades. En este contexto, ese administrador podría ser bloqueado por interrupción (esto ha sucedido antes), con las condiciones de desbloqueo establecidas por la comunidad como "renunciar o reconfirmar", aunque no creo que esto haya sucedido nunca, e isaacl arriba sugirió que Hay una discusión comunitaria previa que excluye este tipo de cosas (y también señaló que si hay un consenso tan obvio en esta dirección, la ruta del comité debería funcionar bien, con lo que estoy de acuerdo, especialmente en los últimos años). Por lo tanto, la creencia de que la comunidad ex arbcom no tiene forma alguna de obligar a un administrador perturbador a detener la actividad no es exacta; está ahí , y desde noviembre de 2018, efectivo. Tiene razón en que la comunidad no ha podido ponerse de acuerdo en general sobre los términos de la discusión y no se han alcanzado acuerdos firmes a tal fin. Sigo sin ver que esta ruta esté prohibida por la política, a pesar de las lecturas adicionales . En la situación hipotética en la que existe un consenso de la comunidad de que un administrador no debe continuar, y por cualquier motivo, arbcom no es eficaz, la comunidad puede actuar. La razón por la que las propuestas de CDA que no son de AC siempre fracasan no es porque la comunidad no tenga el poder, es la falta de acuerdo sobre cómo convocar la discusión de una manera que no cause más problemas de los que resuelve. - xeno talk 15:59, 1 de marzo de 2021 (UTC)
- Gracias xeno. Su razonamiento es absolutamente diferente de lo que trata esta discusión. La eliminación de herramientas puede ser necesaria / implementada por muchas razones, incluso para un grado de edición tendenciosa. Pero estás hablando de administradores disruptivos, que es un universo completamente diferente y mucho más estrecho que la eliminación de herramientas / re-RfA. Lo siento, pero su razonamiento está fuera de lugar. Gracias, Lourdes 06:53, 2 de marzo de 2021 (UTC)
- Un "grado de edición tendenciosa" persistente por parte de un administrador es una interrupción. No creo que estemos necesariamente en desacuerdo, estás pidiendo que la comunidad tenga el poder, sugiero que la comunidad tenga el poder (las herramientas necesariamente técnicas; la comunidad podría estar de acuerdo en que "esto es algo que hacemos ahora" , similar a cómo la comunidad acordó expandir los usos aceptables de ECP); la falta de acuerdo sobre un proceso resiliente es el bloqueador. Supongo que la distinción no importa en un sentido práctico. - xeno talk 14:48, 2 de marzo de 2021 (UTC)
- La ANI se ha vuelto levemente notoria por ser disfuncional y muchas personas la evitan. Sospecho que un candidato de la RpA que ha pasado mucho tiempo allí podría oponerse solo por ese motivo. Es particularmente malo para lidiar con problemas de comportamiento que involucran a editores establecidos, que es lo que estaría involucrado en una discusión desysop. Probablemente sea el peor lugar para sostener esas discusiones. AN es mejor pero no mucho. Hut 8.5 08:44, 1 de marzo de 2021 (UTC)
- OTOH, si cualquier 'editor normal' tiene que estar sujeto a las 'injusticias' de ANI, ¿hay alguna razón por la que un administrador no debería estar sujeto a los mismos procesos, independientemente de lo buenos o malos que sean? Quiero decir, creer lo contrario parece ser similar a decir que los administradores son superusuarios. Esto parece complicarse aún más cuando piensa en las herramientas ahora desagregadas. Un editor de plantillas puede ser azotado en ANI por su uso de TPE, pero un administrador no puede ser azotado por la misma acción exacta porque su TPE está incluido en su kit de administración. [reemplace TPE con retroceso, movimiento de página o algo similar para obtener los mismos efectos] ProcrastinationReader ( charla ) 14:10, 1 de marzo de 2021 (UTC)
- Bien dicho PR. Lourdes 06:53, 2 de marzo de 2021 (UTC)
- Puede azotar a los administradores de ANI ahora si es necesario. Esta propuesta le da mucho poder al usuario cerrando el hilo AN / ANI. Debería tener un consenso específico que solicite que las herramientas de administración se eliminen y se vuelvan a confirmar, lo que generalmente requeriría un comportamiento disruptivo constante. SportingFlyer T · C 15:12, 2 de marzo de 2021 (UTC)
- Ignora eso. Releí la propuesta original, que requeriría un consenso. SportingFlyer T · C 15:13, 2 de marzo de 2021 (UTC)
- Bien dicho PR. Lourdes 06:53, 2 de marzo de 2021 (UTC)
- OTOH, si cualquier 'editor normal' tiene que estar sujeto a las 'injusticias' de ANI, ¿hay alguna razón por la que un administrador no debería estar sujeto a los mismos procesos, independientemente de lo buenos o malos que sean? Quiero decir, creer lo contrario parece ser similar a decir que los administradores son superusuarios. Esto parece complicarse aún más cuando piensa en las herramientas ahora desagregadas. Un editor de plantillas puede ser azotado en ANI por su uso de TPE, pero un administrador no puede ser azotado por la misma acción exacta porque su TPE está incluido en su kit de administración. [reemplace TPE con retroceso, movimiento de página o algo similar para obtener los mismos efectos] ProcrastinationReader ( charla ) 14:10, 1 de marzo de 2021 (UTC)
- @ Lourdes :, no veo cómo puede oponerse a una propuesta que requeriría que el 60% de los participantes apoyen un des-sysop como "opuesto a nuestra política de WP: CONSENSUS", y sin embargo apoyar que aproximadamente el mismo número de participantes desencadene una discusión que requiere sólo el 30% de los participantes para apoyar un des-sysop. El requisito de que un consenso AN / ANI haya encontrado que un administrador actuó de manera inapropiada en la propuesta de RFC es funcionalmente equivalente a su desencadenante aquí; no podemos tener una situación en la que el 90% de los editores piense que un administrador se está comportando bien, pero se activa un RFC según la propuesta. power ~ enwiki ( π , ν ) 21:31, 2 de marzo de 2021 (UTC)
- Para ampliar esto, la propuesta de RFC es:
- Una discusión AN / ANI encuentra consenso en que un administrador ha actuado de manera inapropiada.
- Se hace una moción para iniciar una votación de des-sysop.
- La moción debe obtener suficientes segundos .
- La moción se discute durante una semana, si el 40% o más de la comunidad apoya que el administrador siga siendo administrador, seguirá siendo administrador.
- Su propuesta (la propuesta L), según tengo entendido, es:
- Una discusión AN / ANI encuentra consenso en que un administrador ha actuado de manera inapropiada (o posiblemente puede solicitar un des-sysop sin ningún motivo) y solicita una nueva RFA.
- No es necesario ningún movimiento adicional o un segundo.
- La moción se discute durante una semana, si el 65% o más de la comunidad apoya que el administrador siga siendo administrador, seguirá siendo administrador.
- Si apoya la propuesta de L, ¿cómo puede oponerse a la propuesta de RFC por estar "en contra de nuestra política de WP: CONSENSUS"? ¿Cómo los obstáculos adicionales en la propuesta de RFC facilitan que haya un "linchamiento público y una apelación para una solicitud de revisión de desysop"? power ~ enwiki ( π , ν ) 22:35, 2 de marzo de 2021 (UTC)
- Hola power-enwiki. Su descripción anterior está equivocada en dos áreas.
- Para ampliar esto, la propuesta de RFC es:
- Una discusión AN / ANI tiene el poder de concluir que un administrador debe optar por un RfA inverso de reconfirmación, no basado en el consenso , sino en un número específico de editores y administradores que están de acuerdo, ignorando a los editores y administradores que pueden estar en desacuerdo, cualquiera que sea el motivo. número del lote en desacuerdo puede ser.
- Para ampliar esto, la propuesta de RFC es:
- Mi propuesta es:
- Una discusión AN / ANI encuentra consenso que un administrador debe buscar una reconfirmación de RfA, basado en el cierre por consenso y el cierre es considerado apropiado por un crat.
- Gracias, Lourdes 03:42, 3 de marzo de 2021 (UTC)
- Solo veo un desacuerdo, pero hay un desacuerdo. La RFC dice que después de un hallazgo de negligencia, una moción para des-sysop está en orden, mientras que se requiere un consenso para hacer una moción para des-sysop. Estoy en desacuerdo. Una vez que hay acuerdo de que un administrador se está portando mal, creo que una moción para des-sysop no debería requerir consenso para comenzar; la moción en sí misma requerirá consenso para desarmar un editor. Si necesita un consenso para iniciar una moción de des-sysop, está realizando una votación dos veces; esto solo aumentará la potencia de varias cábalas en ANI. power ~ enwiki ( π , ν ) 03:48, 3 de marzo de 2021 (UTC)
- Hola power-enwiki. Su descripción anterior está equivocada en dos áreas.
- Para ampliar esto, la propuesta de RFC es:
- En aras de la claridad, debo señalar que me opongo al plan alternativo propuesto anteriormente; nuevamente sería fácil desencadenar un RfC completo, pero también creo que cualquier administrador que esté tomando acciones que desencadenen una controversia significativa o infelicidad tendrá dificultades para cumplir con los porcentajes. visto en un RfA estándar. Nosebagbear ( charla ) 11:26, 3 de marzo de 2021 (UTC)
- Hay alguna evidencia para esto? Considere el caso de El C , por ejemplo, que ha sancionado a muchos editores habituales e incluso a algunos administradores como probablemente el administrador de AE más activo. No creo que El C caiga por debajo del 75% si ejecuta una RfA de reconfirmación, ciertamente no por debajo del 65%. Irónicamente, al observar algunas interacciones de conversaciones pasadas, parece que El C todavía conserva el respeto de algunos editores a los que sanciona (no estoy seguro de cuál es su secreto). Tengo la sensación de que estos 'administradores que participan en acciones controvertidas' a los que se refiere son personas que lo hacen de manera incompetente. ProcrastinationReader ( charla ) 12:12, 3 de marzo de 2021 (UTC)
- Procrastinando Lector , me estás haciendo
El_C 14:07, 3 de marzo de 2021 (UTC)
- Nosebagbear tienes razón. Podríamos considerar un RfA inverso en tal caso. Lourdes 14:15, 3 de marzo de 2021 (UTC)
- Procrastinando Lector , me estás haciendo
- Sabemos que los administradores que hacen cosas impopulares realmente difíciles (a veces tan impopulares que pueden causar un RfC en el que participan cientos) aún pueden conservar la confianza de al menos el 60% de la comunidad. ¿Cómo? Porque los Árbitros son reelegidos de forma rutinaria con al menos un 60% de apoyo. Ahora parece haber un límite, al menos en ArbCom, pero parte de ese límite también parece ser una función de que sea de suma cero (es decir, solo se eligen tantos Arbs) donde, en una situación de confirmación, no habría tal presión. Lo mejor, Barkeep49 ( charla ) 03:38, 4 de marzo de 2021 (UTC)
- @ Barkeep49 : Es importante notar la diferencia en la estructura entre las elecciones de ArbCom y RfA. Las elecciones de ArbCom emplean una votación secreta donde nadie puede ver cómo los demás están votando o sus razones para hacerlo. Además, las elecciones de ArbCom de los últimos años han sido bien publicitadas utilizando un mensaje de página de discusión de usuarios masivos para cada votante elegible que haya editado en el último año. Por otro lado, la votación de RfA es pública y, por lo general, asiste a las discusiones un pequeño subconjunto de la comunidad de votantes de ArbCom que tiene un interés activo en la gobernanza del proyecto. Estas distinciones tienen importantes consecuencias, la más importante de las cuales es el efecto de "acumulación". En RfA, no es inusual que una voz abierta en la comunidad emita un voto de oposición temprano, lo que lleva a una "pila" de votos en contra que simplemente citan al primero en oposición. Este efecto se atenúa en las elecciones de ArbCom debido a la votación secreta: algunos editores publican sus opiniones en guías de votantes y otras páginas de discusión, pero no parecen tener la misma influencia que el formato abierto y no estructurado de una RfA (I estoy recordando su ensayo en User: Barkeep49 / ACE # Candidate guides ). Además, el mensaje masivo en ArbCom permite una mayor diversidad de opiniones de lo que permite RfA, lo que reduce la probabilidad de que una controversia aislada o una minoría vocal pueda influir en el resultado. El resultado es que, en mi opinión, sería más difícil (aunque no imposible, ver Floquenbeam 2 ) para un administrador controvertido aprobar una reconfirmación del RfA que ser elegido para ArbCom. Mz7 ( conversación ) 07:32, 4 de marzo de 2021 (UTC)
- Más allá de eso, ARBCOM es, en teoría, una competencia de los mejores y más confiables, incluso si algunos toman acciones controvertidas. Estar en esa categoría no debería ser necesario para que un administrador controvertido evite el abandono; incluso un administrador controvertido promedio debería poder sobrevivir sin dificultad, y no creo que eso se sostenga, especialmente teniendo en cuenta lo que será una novedad importante. parcialidad. Nosebagbear ( charla ) 12:00, 4 de marzo de 2021 (UTC)
- Nosebagbear , ¿Qué quieres decir con "sesgo de actualidad"? - RoySmith
(charla) 12:56, 4 de marzo de 2021 (UTC)
- Las personas se enfocan de manera inherente en los eventos más recientes y les prestan más atención. En un RfA normal, el candidato elige cuándo postularse, por lo que esto cae a su favor (o, como mínimo, neutralmente, si se postula cuando le conviene en el tiempo). Los árbitros no pueden elegir cuándo presentarse, pero saben cuándo llegará y pueden evitar cualquier cosa demasiado problemática en la inminente carrera / durante las elecciones. En un proceso de desysop, naturalmente se producirá porque ha ocurrido algo negativo: el sesgo de lo reciente significa que se pondrá un enfoque adicional en los eventos recientes, lo que requiere una ponderación muy grande del "desempeño positivo general" para superarlo. El ejército de los Estados Unidos supuestamente tiene la frase "todos los 'chicos de atta son superados por un' oh mierda '". En este sentido, las circunstancias están significativamente más en contra que, digamos, los arbitrajes en una elección de ARBCOM. Nosebagbear ( charla ) 13:59, 4 de marzo de 2021 (UTC)
- Todavía no estoy convencido con la opinión de que al menos el 65% de la comunidad no puede pensar racionalmente y evaluar a un administrador de RfA reconfirmado en sus méritos generales. Y todavía no veo evidencia aquí de prueba de lo contrario, por lo que todo esto parece muy presuntivo. Y, en general, no creo que un administrador sin el apoyo de la comunidad deba administrarlo de todos modos. ProcrastinationReader ( charla ) 14:15, 4 de marzo de 2021 (UTC)
- No es un problema de "x una gran proporción no hará una evaluación lógica", es "x una proporción apreciable no hará una evaluación 100% lógica". En un evento en el que una minoría significativa pero insuficiente eligiera razonablemente desysop, este grupo podría fácilmente poner el recuento por encima de un umbral alto / bajo (dependiendo del punto de vista). Si bien el artículo de Wikipedia sobre el sesgo de actualidad no es excelente, hay una gran cantidad de literatura académica sobre el tema disponible en una búsqueda rápida, a menos que realmente creamos que los editores de Wikipedia, como clase, son funcionalmente inmunes a él. Nosebagbear ( charla ) 15:28, 4 de marzo de 2021 (UTC)
- Todavía no estoy convencido con la opinión de que al menos el 65% de la comunidad no puede pensar racionalmente y evaluar a un administrador de RfA reconfirmado en sus méritos generales. Y todavía no veo evidencia aquí de prueba de lo contrario, por lo que todo esto parece muy presuntivo. Y, en general, no creo que un administrador sin el apoyo de la comunidad deba administrarlo de todos modos. ProcrastinationReader ( charla ) 14:15, 4 de marzo de 2021 (UTC)
- Las personas se enfocan de manera inherente en los eventos más recientes y les prestan más atención. En un RfA normal, el candidato elige cuándo postularse, por lo que esto cae a su favor (o, como mínimo, neutralmente, si se postula cuando le conviene en el tiempo). Los árbitros no pueden elegir cuándo presentarse, pero saben cuándo llegará y pueden evitar cualquier cosa demasiado problemática en la inminente carrera / durante las elecciones. En un proceso de desysop, naturalmente se producirá porque ha ocurrido algo negativo: el sesgo de lo reciente significa que se pondrá un enfoque adicional en los eventos recientes, lo que requiere una ponderación muy grande del "desempeño positivo general" para superarlo. El ejército de los Estados Unidos supuestamente tiene la frase "todos los 'chicos de atta son superados por un' oh mierda '". En este sentido, las circunstancias están significativamente más en contra que, digamos, los arbitrajes en una elección de ARBCOM. Nosebagbear ( charla ) 13:59, 4 de marzo de 2021 (UTC)
- Nosebagbear , ¿Qué quieres decir con "sesgo de actualidad"? - RoySmith
(charla) 12:56, 4 de marzo de 2021 (UTC)
- Tiene razón en que el grupo de votantes de ArbCom es mucho mayor que un RfA típico. E intencionalmente no mencioné el Floq RfA porque es una anécdota, no un dato (aunque respalda mi opinión). Sin embargo, creo que la mayoría de la gente ha sugerido que la votación anónima facilitará la oposición porque no hay temor a represalias, por lo que no estoy de acuerdo con su análisis de que esto contribuye a un porcentaje de apoyo más alto. Y sugeriría que NBB de "todos los 'chicos Atta se ven compensados por una 'oh mierda'" no es más que administradores en su contra ARA II. Los Arbs tienen términos de 1 o 2 años. Realmente dudo que los editores molestos por decisiones controvertidas lo olviden en ese período de tiempo. El 60% del apoyo retenido ya está un 5% por debajo del límite para el rango discrecional de crats en un RfA típico, lo que permite un amplio margen de maniobra para que uno o dos votantes basados en la venganza sean eliminados. Lo mejor, Barkeep49 ( charla ) 16:48, 4 de marzo de 2021 (UTC)
- Más allá de eso, ARBCOM es, en teoría, una competencia de los mejores y más confiables, incluso si algunos toman acciones controvertidas. Estar en esa categoría no debería ser necesario para que un administrador controvertido evite el abandono; incluso un administrador controvertido promedio debería poder sobrevivir sin dificultad, y no creo que eso se sostenga, especialmente teniendo en cuenta lo que será una novedad importante. parcialidad. Nosebagbear ( charla ) 12:00, 4 de marzo de 2021 (UTC)
- @ Barkeep49 : Es importante notar la diferencia en la estructura entre las elecciones de ArbCom y RfA. Las elecciones de ArbCom emplean una votación secreta donde nadie puede ver cómo los demás están votando o sus razones para hacerlo. Además, las elecciones de ArbCom de los últimos años han sido bien publicitadas utilizando un mensaje de página de discusión de usuarios masivos para cada votante elegible que haya editado en el último año. Por otro lado, la votación de RfA es pública y, por lo general, asiste a las discusiones un pequeño subconjunto de la comunidad de votantes de ArbCom que tiene un interés activo en la gobernanza del proyecto. Estas distinciones tienen importantes consecuencias, la más importante de las cuales es el efecto de "acumulación". En RfA, no es inusual que una voz abierta en la comunidad emita un voto de oposición temprano, lo que lleva a una "pila" de votos en contra que simplemente citan al primero en oposición. Este efecto se atenúa en las elecciones de ArbCom debido a la votación secreta: algunos editores publican sus opiniones en guías de votantes y otras páginas de discusión, pero no parecen tener la misma influencia que el formato abierto y no estructurado de una RfA (I estoy recordando su ensayo en User: Barkeep49 / ACE # Candidate guides ). Además, el mensaje masivo en ArbCom permite una mayor diversidad de opiniones de lo que permite RfA, lo que reduce la probabilidad de que una controversia aislada o una minoría vocal pueda influir en el resultado. El resultado es que, en mi opinión, sería más difícil (aunque no imposible, ver Floquenbeam 2 ) para un administrador controvertido aprobar una reconfirmación del RfA que ser elegido para ArbCom. Mz7 ( conversación ) 07:32, 4 de marzo de 2021 (UTC)
- Hay alguna evidencia para esto? Considere el caso de El C , por ejemplo, que ha sancionado a muchos editores habituales e incluso a algunos administradores como probablemente el administrador de AE más activo. No creo que El C caiga por debajo del 75% si ejecuta una RfA de reconfirmación, ciertamente no por debajo del 65%. Irónicamente, al observar algunas interacciones de conversaciones pasadas, parece que El C todavía conserva el respeto de algunos editores a los que sanciona (no estoy seguro de cuál es su secreto). Tengo la sensación de que estos 'administradores que participan en acciones controvertidas' a los que se refiere son personas que lo hacen de manera incompetente. ProcrastinationReader ( charla ) 12:12, 3 de marzo de 2021 (UTC)
Un enfoque alternativo, donde ArbCom inicia el proceso
KevinL , alrededor de la oposición n. ° 102, presenta un argumento que me ha parecido muy interesante y que vale la pena considerarlo más a fondo: [10] . Él dice en parte que prefiere ArbCom para lidiar con la mala conducta real de los administradores, pero estaría interesado en si la comunidad podría lidiar con la pérdida de confianza de la comunidad en un administrador con el tiempo. He estado pensando mucho en eso durante los últimos días, y también veo que el tema es ampliamente relevante para un caso de ArbCom que está sucediendo simultáneamente con este RfC.
Tengo la idea de que voy a escupir aquí. No hago ninguna suposición sobre si la propuesta en este RfC va a ser aprobada:
- Si la propuesta aquí se aprueba, entonces una idea como la que estoy describiendo aquí podría evaluarse como una enmienda propuesta a la política más adelante.
- Si la propuesta aquí no se aprueba, entonces la idea aquí podría ser una propuesta separada en el futuro.
Este sería un proceso en el que participa la comunidad, pero no sería exactamente un proceso de desysop comunitario. Lo iniciaría ArbCom, no los miembros de la comunidad. Me parece que muchos de los editores que se oponen a los procesos basados en la comunidad pero que apoyan el papel de ArbCom tal vez quieran apoyar una idea como esta.
- La única forma en que se podría iniciar el procedimiento sería mediante una decisión de ArbCom, de acuerdo con sus propios procedimientos. Podrían iniciarlo mediante una moción o mediante un recurso en la decisión final de un caso.
- ArbCom lo iniciaría cuando hayan determinado que un administrador tal vez haya perdido la confianza de la comunidad, pero donde ArbCom también haya determinado que ellos mismos no van a destituir al administrador por los tipos de razones que ArbCom ha citado tradicionalmente ( violaciones específicas de la política del administrador, etc.). ArbCom seguiría siendo libre de actuar en desysops como lo ha hecho tradicionalmente ArbCom; no habría ningún requisito o expectativa de que se abstuvieran de tomar decisiones desysop por sí mismos. Pero si ArbCom elige utilizar este procedimiento en un caso particular, entonces el administrador sigue siendo un administrador en regla durante el procedimiento.
- Dentro de un período de tiempo establecido por ArbCom después de que ArbCom publique su decisión en el Tablón de anuncios de arbitraje , los secretarios de arbitraje serán responsables de configurar y trasladar la página de discusión de la comunidad. Si el administrador que está siendo revisado solicita más tiempo, el tiempo puede extenderse a discreción de ArbCom.
- La página de discusión se parecerá a las páginas de WP: RfA , y se incluirá de manera similar. Los secretarios publicarán avisos de la discusión en los mismos lugares en los que se publicitan las RfA ( WP: CENT , avisos de lista de seguimiento, etc.) y en la página de discusión del usuario del administrador.
- En lugar de la nominación utilizada para los RpA, habrá una declaración de ArbCom. En lugar de la aceptación de la nominación por parte de los candidatos RfA, el administrador puede hacer una declaración. Esta declaración se omitirá si el administrador decide no participar. De manera análoga a las RfA, habrá preguntas de la comunidad para el administrador.
- En lugar de secciones para "Apoyar", "Oponerse" y "Neutral", las secciones serán "Mantener como administrador", "Eliminar (desysop)" y "Neutral".
- La discusión permanecerá abierta durante siete días.
- La discusión será cerrada por burócratas. Considerarán los comentarios numerados de acuerdo con "Eliminar" dividido por "Retener + Eliminar", siendo necesario un valor suficientemente alto de esta relación para llegar a un consenso para la eliminación. Habrá un rango discrecional, como con los RfA. (Las pautas numéricas reales para esto se determinarán más tarde, durante un RfC comunitario, si esta idea se convierte en una propuesta formal). En caso de un consenso para desysop, los burócratas promulgarán la decisión.
Creo que hay mucho en la idea de que los administradores deben tener la confianza de la comunidad, pero que la comunidad, no ArbCom, es quien debe evaluar la "confianza". ArbCom es elegido por la comunidad, pero hasta cierto punto tienen que adivinar si la comunidad todavía confía o no en un administrador en particular. Esto es diferente de que ArbCom abandone a un administrador y el administrador vuelva a presentar una solicitud a través de un nuevo RfA. En este caso, ArbCom no habría rechazado al administrador, por lo que la justificación de que uno debería oponerse a la RfA porque ArbCom ya decidió una vez que no se aplicaría. Y para los editores que se sienten incómodos con que la comunidad pueda despojar a alguien, esto sería algo que requiere que ArbCom lo inicie. (Para los editores que odian ArbCom y odian a los administradores, me temo que no puedo ayudarlos en eso). - Tryptofish ( charla ) 21:05, 5 de marzo de 2021 (UTC)
- En la Wikipedia rusa, un ArbCom puede obligar al administrador a aceptar una reconfirmación de RfA (creo que yo era un árbitro cuando comenzó esta práctica, pero también podría estar equivocado, como lo fue hace más de 10 años). La motivación es que a veces es difícil determinar si el administrador todavía tiene la confianza de la comunidad. En la mayoría de los casos, este RfA está precedido por una notificación, con un número de usuarios (50 aproximadamente) que deben registrarse y luego comienza el RfA. Hubo alrededor de una docena de casos en total, con unos pocos que aprobaron la RfA, unos pocos que no, y un grupo que se negó a ejecutar una RfA .-- Ymblanter ( charla ) 22:30, 5 de marzo de 2021 (UTC)
- @Ymblanter: Lo que describe es básicamente como el proceso de retirada de WP alemán, excepto que primero debe pasar por ArbCom, ¿verdad? No tendría demasiadas objeciones a eso, pero, por supuesto, tendría que ser un RfC RandomCanadian diferente ( charla / contribuciones ) 22:36, 5 de marzo de 2021 (UTC)
- Tuvimos (y creo que todavía tienen) el mismo RfC de siempre, con preguntas y el mismo umbral de soporte .-- Ymblanter ( charla ) 22:58, 5 de marzo de 2021 (UTC)
- @Ymblanter: Lo que describe es básicamente como el proceso de retirada de WP alemán, excepto que primero debe pasar por ArbCom, ¿verdad? No tendría demasiadas objeciones a eso, pero, por supuesto, tendría que ser un RfC RandomCanadian diferente ( charla / contribuciones ) 22:36, 5 de marzo de 2021 (UTC)
- Me temo que no estoy de acuerdo con la separación de Kevin de "pérdida de la confianza de la comunidad" y "actos identificables específicos de mala conducta administrativa". En mi opinión, la comunidad solo pierde la confianza en un administrador debido a actos identificables específicos de mala conducta administrativa. En otras palabras, es necesario que exista evidencia de que un administrador existente es netamente negativo para el proyecto, no solo un "sentimiento general" o un desacuerdo o rencor personal. Si un proceso comunitario da como resultado la destitución de un administrador sin proporcionar evidencia específica de mala conducta, entonces lo vería como una desafortunada falla del proceso: habríamos destituido erróneamente a un administrador. El status quo protege contra este riesgo al exigir evidencia de alta calidad y argumentos sólidos arraigados en nuestras políticas y directrices. Mz7 ( conversación ) 22:41, 5 de marzo de 2021 (UTC)
- @ Mz7 : (también ping Tryptofish ) Puedo ver de qué estás hablando, pero creo que algunas de estas son cosas que ArbCom está institucionalmente en una posición mucho mejor para abordar que otras. Por ejemplo, la falta de competencia (por ejemplo, un administrador de la herencia que se involucra en el proyecto después de un largo período de ausencia casi total que está en más de la cabeza) será finalmente ser abordado por ArbCom si es bastante malo - pero algo tiene que ir bastante mal primero. Si, en cambio, la comunidad determinara mediante un consenso de supermayoría que ese administrador (que podría haberse involucrado en una serie de pequeños pasos en falso muy por debajo de ArbCom normalmente, o de otra manera claramente ya no retiene el mandato de la comunidad para ser un sysop) ya no retiene su confianza, eso sería ser un buen resultado. Saludos , KevinL ( también conocido como L235 · t · c ) 08:41, 6 de marzo de 2021 (UTC)
- @ L235 : Dijo en su comentario opuesto que ha estado pensando en un posible procedimiento y que proporcionaría más detalles si los editores lo preguntaban. Entonces, me gustaría preguntar: ¿hay formas en las que preferiría hacer las cosas de manera diferente a lo que describo aquí? Además, dado que DGG dijo a continuación que cree que esto provocaría que ArbCom se involucre menos en los desysoppings, ¿cuál es su opinión al respecto? Gracias. - Tryptofish ( charla ) 16:10, 6 de marzo de 2021 (UTC)
- De hecho, estaría bastante contento con el proceso propuesto en este RfC, excepto que deberíamos eliminar el requisito de subproceso AN / ANI y tener en cuenta que, en general, las solicitudes de desysopping sobre la base de abuso, etc. generalmente deben dirigirse a ArbCom. Creo que los requisitos establecidos en el punto 2 protegen suficientemente a los administradores de presentaciones de represalias, frívolas o abusivas. Saludos , KevinL ( también conocido como L235 · t · c ) 23:28, 7 de marzo de 2021 (UTC)
- @ L235 : Dijo en su comentario opuesto que ha estado pensando en un posible procedimiento y que proporcionaría más detalles si los editores lo preguntaban. Entonces, me gustaría preguntar: ¿hay formas en las que preferiría hacer las cosas de manera diferente a lo que describo aquí? Además, dado que DGG dijo a continuación que cree que esto provocaría que ArbCom se involucre menos en los desysoppings, ¿cuál es su opinión al respecto? Gracias. - Tryptofish ( charla ) 16:10, 6 de marzo de 2021 (UTC)
- @ Mz7 : (también ping Tryptofish ) Puedo ver de qué estás hablando, pero creo que algunas de estas son cosas que ArbCom está institucionalmente en una posición mucho mejor para abordar que otras. Por ejemplo, la falta de competencia (por ejemplo, un administrador de la herencia que se involucra en el proyecto después de un largo período de ausencia casi total que está en más de la cabeza) será finalmente ser abordado por ArbCom si es bastante malo - pero algo tiene que ir bastante mal primero. Si, en cambio, la comunidad determinara mediante un consenso de supermayoría que ese administrador (que podría haberse involucrado en una serie de pequeños pasos en falso muy por debajo de ArbCom normalmente, o de otra manera claramente ya no retiene el mandato de la comunidad para ser un sysop) ya no retiene su confianza, eso sería ser un buen resultado. Saludos , KevinL ( también conocido como L235 · t · c ) 08:41, 6 de marzo de 2021 (UTC)
- No estoy de acuerdo en que necesitemos actos de mala conducta específicos identificables. Creo que esto lo resume mejor:
"Una moción de censura ... es una declaración o voto sobre si una persona en un puesto de responsabilidad ... ya no se considera apta para ocupar ese cargo, quizás porque son inadecuados en algún aspecto, no están cumpliendo obligaciones o están tomando decisiones que otros miembros consideran perjudiciales ".
Tenemos tres capas allí: 1) hay un cierto nivel de WP: COMPETENCIA requerida para ser un administrador y el nivel de competencia de uno puede cambiar con el tiempo, especialmente a medida que cambian las políticas y procedimientos o cuando los administradores se cambian a sí mismos; 2) muchos administradores no cumplen con sus obligaciones al ser administradores casi inactivos a largo plazo que juegan con el sistema para mantener el trapeador, evadiendo el único método para eliminar sus herramientas y, al mismo tiempo, haciendo poco o nada en términos de trabajo del sistema. ; 3) aquí es donde caerían los comportamientos incivilizados y problemáticos. Los tres son elementos que pueden erosionar la confianza de la comunidad, y los tres han sido problemas en un momento u otro. Nihlus 22:56, 5 de marzo de 2021 (UTC)- Mi respuesta sería que (1) y (3) son ejemplos de problemas en los que se le debería solicitar que encuentre instancias identificables específicas para justificar su caso de desysop. Un administrador que es verdaderamente incompetente o muestra un patrón de descortesía está incurriendo en una mala conducta en torno a la cual usted debería poder construir un caso basado en evidencia. (2) es definitivamente el más complicado, y admitiré que el statu quo puede ser insuficiente en esta área. Sin embargo, soy escéptico de que las propuestas de TonyBallioni o Tryptofish realmente aborden ese problema. En cambio, requeriría ajustar nuestro proceso de inactividad de administrador (lo hemos hecho de manera incremental en los últimos años, por ejemplo, requiriendo un nuevo RfA después de 5 años sin acciones administrativas, pero sospecho que probablemente tenga razón en que no es suficiente) . Mz7 ( conversación ) 23:28, 5 de marzo de 2021 (UTC)
- Debería haberlo redactado mejor y haber dicho que no estoy de acuerdo con necesitar siempre actos identificables específicos. Si bien tiene sentido para (1) y (3), no lo tiene para (2), por lo que tal limitación sería perjudicial para el propósito de un proceso de desysop iniciado por la comunidad. Nihlus 00:00, 6 de marzo de 2021 (UTC)
- Mi respuesta sería que (1) y (3) son ejemplos de problemas en los que se le debería solicitar que encuentre instancias identificables específicas para justificar su caso de desysop. Un administrador que es verdaderamente incompetente o muestra un patrón de descortesía está incurriendo en una mala conducta en torno a la cual usted debería poder construir un caso basado en evidencia. (2) es definitivamente el más complicado, y admitiré que el statu quo puede ser insuficiente en esta área. Sin embargo, soy escéptico de que las propuestas de TonyBallioni o Tryptofish realmente aborden ese problema. En cambio, requeriría ajustar nuestro proceso de inactividad de administrador (lo hemos hecho de manera incremental en los últimos años, por ejemplo, requiriendo un nuevo RfA después de 5 años sin acciones administrativas, pero sospecho que probablemente tenga razón en que no es suficiente) . Mz7 ( conversación ) 23:28, 5 de marzo de 2021 (UTC)
- Una cosa que esto haría es facilitar mucho los arbs. Si le dieran a la comunidad todas las decisiones difíciles sobre desysop, nadie podría culparlos por los resultados. Básicamente, esto es convertir arb com de una junta de apelación final a una junta de evaluación preliminar. DGG ( conversación ) 22:44, 5 de marzo de 2021 (UTC)
Con respecto a lo que dijeron Ymblanter y RandomCanadian, podría ser una ventaja tener una discusión que no sea exactamente una reconfirmación de RfA, ya que podría ser más enfocada que eso. En otras palabras, el administrador (o un nominador) establecería una reconfirmación utilizando el formato estándar de RfA, mientras que esto podría ser algo formateado en torno a una declaración de ArbCom y una respuesta del administrador. Creo que Mz7 tiene razón en que no hay una línea clara que separe la mala conducta específica de la pérdida de confianza, pero no necesariamente veo eso como un problema. Lo veo vinculado con la observación de DGG. Si ArbCom se limita a apostar por esto y recurre a lo que DGG llama una junta de evaluación preliminar, entonces probablemente no debería haber un procedimiento como este, y el statu quo sería mejor. Pero espero que ArbCom no haga eso, y que la comunidad retroceda rápidamente si lo hiciera. Mi intención aquí es que ArbCom siga haciendo lo que hace, no se convierta en un montón de transeúntes. Solo usarían este procedimiento a veces. Y no estaría libre de pruebas, de la manera que Mz7 imagina como una falla del proceso. Si el umbral para el consenso se establece correctamente, sería difícil llegar a desysop solo por corazonadas sin evidencia. Habría evidencia, pero la evidencia sería menos que blanco y negro para los estándares de ArbCom. ArbCom ha realizado (¡posiblemente!) Algunos desysops recientes, y desysops seguidos de nuevos RfA sin éxito, basados en la premisa de que solo ellos pueden desysop, lo que (¡posiblemente!) Podría significar que se habrían sentido menos obligados a desconectar si hubieran tenido otra opción. Esto les daría la opción de entregarlo a la comunidad, pero también conservarían la opción de actuar por su cuenta. Además de lo que dijo Nihlus, consulte los comentarios que siguen a la oposición de KevinL sobre otras concepciones de la pérdida de confianza. Y sí, la inactividad es otro tema relevante, aunque no lo había pensado cuando escribí el artículo de apertura aquí. - Tryptofish ( conversación ) 23:55, 5 de marzo de 2021 (UTC)
- De acuerdo con este sentimiento general. Re. "Inactividad" - sí, eso es ciertamente algo que se puede hacer mejor que lo que tenemos; y Tobias menciona que en dewiki el alcance de las retiradas incluye administradores que están prácticamente inactivos pero que inician sesión de vez en cuando para "jugar con el sistema" (la pregunta más importante, además de los posibles riesgos de seguridad de las cuentas de administrador en su mayoría inactivas, es si dichos usuarios podría haber perdido contacto con la comunidad actual; por supuesto, eso podría requerir algo que trate cada caso individualmente, pero probablemente no queremos un RfA completo para cada uno de estos nuevamente [aunque eso aumentaría la actividad en RfA, que son estos días a menudo notoriamente silenciosos]). RandomCanadian ( charla / contribuciones ) 00:29, 6 de marzo de 2021 (UTC)
- Me opongo. Durante el año sin mucha experiencia que he estado en Wikipedia, he pensado durante mucho tiempo que ArbCom tiene demasiado poder. De hecho, sentí que Wikipedia era feudalismo: ArbCom en la parte superior del triángulo, luego administradores, luego no administradores con innumerables derechos de usuario especiales, luego usuarios regulares (como yo). Las cosas que ArbCom puede hacer ahora incluyen: imponer restricciones de edición a los editores sin ninguna discusión, imponer bloqueos a los editores sin ninguna discusión, imponer prohibiciones a los editores sin ninguna discusión y eliminar los derechos de usuario de los editores sin ninguna discusión. Estoy a favor de todo lo que le dé roles a la comunidad en Wikipedia: esta propuesta de DRfA está entre ellos. 🐔 ¡ Chicdat Bawk para mí! 13:14, 6 de marzo de 2021 (UTC)
- No estoy tratando de molestar a su Chicdat personalmente, pero esto me parece muy lejos de cómo funcionan las cosas aquí. ArbCom hace muy pocas cosas sin una larga discusión. Y el consenso de la comunidad establece políticas y resuelve disputas de edición (razonables). En realidad, después de unos 15 años no muy activos aquí, pondría tu triángulo patas arriba. En la parte superior están los editores habituales, que básicamente pueden correr haciendo lo que quieran. Pueden ser revertidos, desafiados / en desacuerdo con (como estoy en desacuerdo con usted), en el extremo advertidos o bloqueados por un corto tiempo. Pero realmente se necesita una fuerte testarudez (¡no necesariamente algo malo!) Para ser verdaderamente sancionado; la mayoría de los malos comportamientos quedan impunes, solo hacen perder el tiempo a la comunidad. La comunidad nombra administradores, que tienen más dificultades en el medio del triángulo. Es posible que tengan algunas herramientas especiales en su kit de herramientas, pero su comportamiento al usarlas está permanentemente bajo el microscopio y los editores se quejan de forma rutinaria (a veces esas quejas son válidas), y se espera que sean amables, educados y responsables de sus acciones. ¡Algo que un editor individual, curiosamente, realmente no es! Finalmente, en la parte inferior del triángulo se encuentran ArbCom, quienes tienen la ingrata tarea de tratar de resolver conflictos que la comunidad no puede resolver. Su principal herramienta es la pomposidad y la deliberación abrumadora, aunque excepcionalmente pueden votar a alguien fuera de la isla o imponer interruptores a su comportamiento. Sin embargo, son casi perpetuamente criticados por todos los lados por hacer demasiado poco y demasiado, y luego se supone que se presentarán a la reelección. Entonces, de todos, en realidad son los que están más bajo presión y operan con la menor cantidad de impunidad. Lo anterior es un poco irónico y exagerado, pero creo que su lectura de la dinámica está lejos de ser precisa. Martinp ( charla ) 21:59, 6 de marzo de 2021 (UTC)
- Nunca lo había pensado así antes. Intentaré pensar en Wikipedia más así. 🐔 ¡ Chicdat Bawk para mí! 11:08, 7 de marzo de 2021 (UTC)
- No estoy tratando de molestar a su Chicdat personalmente, pero esto me parece muy lejos de cómo funcionan las cosas aquí. ArbCom hace muy pocas cosas sin una larga discusión. Y el consenso de la comunidad establece políticas y resuelve disputas de edición (razonables). En realidad, después de unos 15 años no muy activos aquí, pondría tu triángulo patas arriba. En la parte superior están los editores habituales, que básicamente pueden correr haciendo lo que quieran. Pueden ser revertidos, desafiados / en desacuerdo con (como estoy en desacuerdo con usted), en el extremo advertidos o bloqueados por un corto tiempo. Pero realmente se necesita una fuerte testarudez (¡no necesariamente algo malo!) Para ser verdaderamente sancionado; la mayoría de los malos comportamientos quedan impunes, solo hacen perder el tiempo a la comunidad. La comunidad nombra administradores, que tienen más dificultades en el medio del triángulo. Es posible que tengan algunas herramientas especiales en su kit de herramientas, pero su comportamiento al usarlas está permanentemente bajo el microscopio y los editores se quejan de forma rutinaria (a veces esas quejas son válidas), y se espera que sean amables, educados y responsables de sus acciones. ¡Algo que un editor individual, curiosamente, realmente no es! Finalmente, en la parte inferior del triángulo se encuentran ArbCom, quienes tienen la ingrata tarea de tratar de resolver conflictos que la comunidad no puede resolver. Su principal herramienta es la pomposidad y la deliberación abrumadora, aunque excepcionalmente pueden votar a alguien fuera de la isla o imponer interruptores a su comportamiento. Sin embargo, son casi perpetuamente criticados por todos los lados por hacer demasiado poco y demasiado, y luego se supone que se presentarán a la reelección. Entonces, de todos, en realidad son los que están más bajo presión y operan con la menor cantidad de impunidad. Lo anterior es un poco irónico y exagerado, pero creo que su lectura de la dinámica está lejos de ser precisa. Martinp ( charla ) 21:59, 6 de marzo de 2021 (UTC)
- Creo que permitir que arbcom refiera ciertos casos a la comunidad podría ser una idea interesante. Sin embargo, no lo querría como reemplazo de un proceso iniciado por la comunidad. - Calidum 16:35, 6 de marzo de 2021 (UTC)
- No puedo imaginar lo brutal que sería tener esto como remedio final: la pobrecita habría tenido un mes (al menos) de ARBCOM, y luego tendría un RfA hostil encima. Tengo que preocuparme de cuánto aumentaría la pérdida de editores (manteniendo o perdiendo el bit) Nosebagbear ( hablar ) 11:27, 7 de marzo de 2021 (UTC)
- ( editar conflicto ) Tus puntos están bien tomados. Me parece que una idea como esta solo tendrá éxito en la medida en que ArbCom la utilice correctamente. Si, como sugirió DGG, simplemente envían la mayoría de los casos a la comunidad, eso sería algo altamente indeseable. Pero si usaran este proceso de manera muy selectiva, entonces realmente no debería ser algo que desanime a la mayoría de los administradores, ni a la mayoría de los editores en general. No sería algo a lo que la mayoría de los administradores se enfrentarían alguna vez. Y creo que hay al menos algún caso que justificar que sería mejor pasar por todo esto y salir con una reafirmación del apoyo de la comunidad, que ser rechazado por ArbCom porque ArbCom se considera a sí mismo como la única entidad que está permitido evaluar la confianza de la comunidad. - Tryptofish ( conversación ) 23:42, 7 de marzo de 2021 (UTC)
- Mirando los últimos 3 años (2018-2020), esperaría que en aproximadamente la mitad de los casos en los que se consideró una mala conducta administrativa (y se consideró desysop) que el comité hubiera elegido este proceso en lugar de tomar la decisión por sí mismo (incluido en 1 de esos 9 para no desysop). ¿Es esa la cantidad correcta o demasiado? Saludos , Barkeep49 ( charla ) 00:59, 8 de marzo de 2021 (UTC)
- Sí, esa es la cuestión. De repente, no sé la respuesta, pero vale la pena analizarla. Creo que depende mucho de las especificidades de cada uno de esos casos: qué tan probable hubiera sido en cada caso que la comunidad hubiera decidido de manera diferente a lo que ArbCom terminó decidiendo, qué tan beneficioso o no habría sido cada una de esas diferencias. sido, y en cada caso cuánto habría mejorado realmente la forma en que ArbCom manejó el caso. Pero el mero hecho de que ArbCom probablemente hubiera querido hacer uso de este proceso un número significativo de veces es, en sí mismo, muy significativo, ya que contribuye en gran medida a responder la pregunta de si podría haber una necesidad o no de este proceso. En otras palabras, resulta bastante difícil argumentar de manera convincente que no necesitamos esto porque ArbCom puede hacerlo por sí mismos, si los miembros de ArbCom dicen que preferirían tener esta opción. La pregunta restante, entonces, es si tener un proceso de este tipo sería realmente beneficioso para la comunidad en su conjunto. - Tryptofish ( charla ) 20:23, 8 de marzo de 2021 (UTC)
- Bueno, la razón por la que planteo la pregunta es porque creo que es instructivo decir "¿ArbCom habría realizado este otro proceso?" y en los casos en que la respuesta sea afirmativa "¿Creo que hubiera sido la decisión correcta?" Parte de esa segunda pregunta es más difícil de responder porque no sabemos qué decidiría la comunidad en este escenario, pero todos podemos imaginarlo. ¿Habría conducido eso a resultados "mejores"? Algunas personas me han argumentado que la respuesta a esa pregunta es no. Lo mejor, Barkeep49 ( charla ) 22:23, 8 de marzo de 2021 (UTC)
- Estamos de acuerdo. Puede resultar incómodo compilar los datos reales, caso por caso, pero esa sería probablemente la mejor manera de examinarlos. - Tryptofish ( conversación ) 23:41, 8 de marzo de 2021 (UTC)
- Bueno, la razón por la que planteo la pregunta es porque creo que es instructivo decir "¿ArbCom habría realizado este otro proceso?" y en los casos en que la respuesta sea afirmativa "¿Creo que hubiera sido la decisión correcta?" Parte de esa segunda pregunta es más difícil de responder porque no sabemos qué decidiría la comunidad en este escenario, pero todos podemos imaginarlo. ¿Habría conducido eso a resultados "mejores"? Algunas personas me han argumentado que la respuesta a esa pregunta es no. Lo mejor, Barkeep49 ( charla ) 22:23, 8 de marzo de 2021 (UTC)
- Sí, esa es la cuestión. De repente, no sé la respuesta, pero vale la pena analizarla. Creo que depende mucho de las especificidades de cada uno de esos casos: qué tan probable hubiera sido en cada caso que la comunidad hubiera decidido de manera diferente a lo que ArbCom terminó decidiendo, qué tan beneficioso o no habría sido cada una de esas diferencias. sido, y en cada caso cuánto habría mejorado realmente la forma en que ArbCom manejó el caso. Pero el mero hecho de que ArbCom probablemente hubiera querido hacer uso de este proceso un número significativo de veces es, en sí mismo, muy significativo, ya que contribuye en gran medida a responder la pregunta de si podría haber una necesidad o no de este proceso. En otras palabras, resulta bastante difícil argumentar de manera convincente que no necesitamos esto porque ArbCom puede hacerlo por sí mismos, si los miembros de ArbCom dicen que preferirían tener esta opción. La pregunta restante, entonces, es si tener un proceso de este tipo sería realmente beneficioso para la comunidad en su conjunto. - Tryptofish ( charla ) 20:23, 8 de marzo de 2021 (UTC)
- Mirando los últimos 3 años (2018-2020), esperaría que en aproximadamente la mitad de los casos en los que se consideró una mala conducta administrativa (y se consideró desysop) que el comité hubiera elegido este proceso en lugar de tomar la decisión por sí mismo (incluido en 1 de esos 9 para no desysop). ¿Es esa la cantidad correcta o demasiado? Saludos , Barkeep49 ( charla ) 00:59, 8 de marzo de 2021 (UTC)
- ( editar conflicto ) Tus puntos están bien tomados. Me parece que una idea como esta solo tendrá éxito en la medida en que ArbCom la utilice correctamente. Si, como sugirió DGG, simplemente envían la mayoría de los casos a la comunidad, eso sería algo altamente indeseable. Pero si usaran este proceso de manera muy selectiva, entonces realmente no debería ser algo que desanime a la mayoría de los administradores, ni a la mayoría de los editores en general. No sería algo a lo que la mayoría de los administradores se enfrentarían alguna vez. Y creo que hay al menos algún caso que justificar que sería mejor pasar por todo esto y salir con una reafirmación del apoyo de la comunidad, que ser rechazado por ArbCom porque ArbCom se considera a sí mismo como la única entidad que está permitido evaluar la confianza de la comunidad. - Tryptofish ( conversación ) 23:42, 7 de marzo de 2021 (UTC)
- Si no. ArbCom debería tomar una decisión o no debería hacerlo. Siempre y cuando dejen abierta la posibilidad de re-RfA inmediatamente, no hay mucha diferencia, excepto que el administrador mantiene el bit durante el transcurso de la discusión, lo cual ... sí, probablemente sea insignificante. Los problemas que plantea Nosebagbear son mucho peores que cualquier beneficio aquí. Elli ( charla | contribuciones ) 23:35, 7 de marzo de 2021 (UTC)
- Creo que el punto aquí sería dejar que ArbCom diga "no estamos diciendo que deba ser desysopted". Un desysopping de ArbCom hace que un re-RfA, especialmente un re-RfA poco después del desysopping, sea muy difícil, porque solo alrededor del 30% de la comunidad necesita estar de acuerdo con ArbCom para que el administrador no recupere su parte. En cambio, este proceso haría que ArbCom sea neutral en la cuestión final de si el administrador debe mantener el bit; ArbCom simplemente dice que la pregunta debe hacerse (en RfA). Saludos , KevinL ( también conocido como L235 · t · c ) 00:37, 8 de marzo de 2021 (UTC)
- Hace mucho, mucho tiempo atrás, y me refiero a 2005 ahora, mientras que los despidos habían ocurrido muy pocas veces y el proceso aún no se había concretado, hubo un caso de arbitraje en el que ArbCom difirió la decisión de despido a la comunidad a través de una RFA. No pasó no va bien. El consenso de la comunidad se centró rápidamente en la idea de que si ArbCom cree que se justifica un desysop, debe seguir adelante y hacerlo. No había necesidad de agravar la situación al someter al administrador defensor a un proceso de RFA hostil. Si bien esto fue hace mucho tiempo, creo que la objeción a esta forma de manejar las cosas sigue en pie. Sjakkalle (¡Compruebe!) 15:18, 10 de marzo de 2021 (UTC)
Personas. YA TENEMOS un proceso perfectamente bueno. Todos ustedes solo necesitan implementarlo.
Primero que todo, no leí mucho de esto, ANI lo que sea, este procedimiento y ese procedimiento, alguien inicia, alguien no, etc. Olvídalo. Es tan difícil conseguir que se aprueben cosas como esta como lo es derogar la 2ª Enmienda. Ahora mismo es 159-115, 58% a favor.
Simplemente reflexione sobre los siguientes cuatro puntos:
- No existe ya un procedimiento para la reconfirmación de la comunidad y está justo aquí: Wikipedia: Administradores abren al proceso de retirada / muestra . Se ha utilizado . Se ha utilizado y funciona bien . ¿OK? Funciona bien.
- Ese es un punto realmente muy importante, así que lo repetiré: el procedimiento existe, se ha utilizado, funciona bien. Léelo.
- Que es cierto que, de hecho, solo los administradores que han colocado voluntariamente en Categoría: Wikipedia administradores abierta a la retirada están sujetos a reconfirmación comunidad. Y la mayoría no lo ha hecho.
- Bueno, eso es fácil. Simplemente deje de votar por los candidatos que se niegan a aceptar ser objeto de una revocación . ¿OK? No es dificil. Deja de hacerlo . Sencillo: pregúntele al candidato "¿Aceptará estar sujeto a reconfirmación, colocándose en la Categoría: administradores de Wikipedia abiertos a ser retirados ?" Cualquier cosa menos un "Sí" firme y claro, usted vota Oponerse. Ni siquiera tienes que leer más del RfA. No hay un "Sí" claro y firme, no hay soporte, punto.
Y es un Oponerse completamente legítimo por sus méritos. Simplemente es demasiado arriesgado darles a los editores un trabajo de por vida. No dar un "Sí" firme y claro a esa pregunta es decir "Quiero este trabajo de por vida (siempre que las transgresiones que cometa no sean atroces al nivel de Arbcom), y si resulta que me lleno de mí mismo o lo que sea y lamentas haberme elegido, puedes ir a la arena ". Si eso no merece un voto Oppose, ¿qué sí?
Todo lo que necesita es un pacto de suficientes personas para hacer esto. No necesitas mucha gente, quizás 20 o 30.
Ni siquiera necesitas un acuerdo formal. No es necesario que escribas una lista de miembros en ninguna parte (quizás deberías hacerlo, pero quizás también puedas recibir muchas críticas). Todo lo que necesita es suficiente gente leyendo esta página ahora mismo para decirse a sí mismos "Sí, eso suena bien, hagámoslo, estoy dentro" y reclutar a otros. ¡Eso es! Ningún estudio se compromete, nada de mencheviques contra cadetes contra SR de izquierda y todo eso.
Deja de perder tu tiempo con todas estas otras cosas. Forma un pacto. , clave alta o clave baja. Es completamente legítimo hacerlo. Estoy dentro. Sé como yo. (No soy del tipo líder, así que no me busques por eso ).
Sé un poco sobre esto, porque lo he hecho. Yo era un administrador. Me puse en Categoría: administradores de Wikipedia abiertos a recordar . ¡Me dediqué a ello! Me hicieron pasar por una reconfirmación RfA. Perdí. Ya no soy administrador. Y no debería estarlo (bueno, no lo creo, pero la comunidad sí, y eso es lo que importa). Funcionó bien. Así que sigamos haciéndolo. ¡No se requieren nuevas reglas!
El resto es solo ruido, pero hay más detalles, hablaré de ellos a continuación. Lea o no como desee.
Pero, ¿qué pasa con los administradores actuales ?
Sí, usar el método existente significa que todos los administradores existentes tienen derechos adquiridos. Oh, bueno. Con el tiempo que va a tomar efecto, y de todas formas políticamente que probablemente es una cosa muy buena - tal vez sea necesario , como hopefull administrador cuerpos no será que molesto, ya que no afecta a ellos personalmente - adquiridos! (Aún puede recibir "Decidir con otros de antemano cómo van a votar todos en un RfA es prima facie una conspiración para interrumpir el proyecto, estás en problemas". Pero tal vez no, porque abuelo. El abuelo es tu amigo. Y quiero decir, después de todo lo que intentes hacer que afecte al cuerpo administrativo existente , bueno, buena suerte con eso. No digo que sea imposible, pero es mucho más trabajo pesado. La amenaza de extinción profesional centrará la atención de las personas mentes.
Pero ... ¿puede un "compacto" como este funcionar realmente, en la práctica?
Si. Alguien se postula como administrador, pero no acepta ser sujeto a reconfirmación ... Digamos que tienes 100 votantes. Digamos 30 en el compacto, 5 opuestos por otras razones. Eso es un soporte de 65-35 ... 65%. No es suficiente que el editor obtenga la parte. Realmente, una vez que esto se pone en marcha, no puedo ver hordas de editores pensando "Apoyo. No aceptará ser objeto de reconfirmación y quiere un trabajo de por vida, pero me gusta de todos modos y, oye, soy un riesgo". -taker ". Quizás. Sólo hay una forma de averiguarlo.
FWIW Recibo la palabra "compacto" de National Popular Vote Interstate Compact , un proyecto interesante. Nuestro "compacto" no es el mismo, pero algo así. Al Pacto Nacional Interestatal del Voto Popular no le importa una mierda lo que piensen los estados que no quieren unirse. De manera similar, estoy seguro de que mucha gente aquí piensa "Uf, esa es una idea terrible, votar por un solo tema". De todos modos, hablando por mí mismo, es su prerrogativa pensar eso, pero no me importa. Y, de hecho, es probable que haya suficientes personas de esa opinión como para que, por supuesto, no se acepte ningún procedimiento formal por escrito. Así que despellejemos al gato de otra manera. No necesitamos una pluralidad. Todo lo que necesitamos son 20-30 personas que piensen que es una buena idea. No importa cuántos no lo hagan. Estoy dentro, así que ya son 19-29 personas ...
Detalles del caso piloto
El caso piloto está aquí: Wikipedia: Solicitudes de administración / Herostratus 2 . El único problema real fue que los burócratas no cerrarían una RfD de reconfirmación. Creo que eso se debe a que solo los administradores, no los burócratas, pueden eliminar el bit de sysop. Es una negligencia que no lo harán (por supuesto que pueden, me saltaré los detalles; simplemente no lo harán, hasta ahora). Así que tenemos que resolver eso; en este caso hice algo ad-hoc que funcionó. Pero no funcionará para casi nadie más. La mayoría de las RfA no son cercanas numéricamente, por lo que cualquier persona que hace rando puede cerrar. No sé ... alguien escribe un ensayo que describe un buen procedimiento para seleccionar un cerrador y enlaza con él desde Wikipedia: Administradores abiertos a recordar / Proceso de muestra , o algo así.
Así que un par de cosas sobre ese caso piloto: ArbCom probablemente no habría aceptado un caso, y si lo hubieran hecho, probablemente no habría abandonado. Porque 1) no había una disputa sin resolver en curso, y 2) los detalles del caso preciso no eran muy fuertes, y 3) el caso realmente se trataba de un comportamiento general sin realmente ningún mal patrón de acciones en particular suficiente para obtener la ArbCom funcionó, probablemente.Por lo tanto: si la ruta de reconfirmación RfA no hubiera estado abierta a la comunidad, probablemente todavía sería un administrador que opera en un entorno donde (aparentemente) no debería estar, y eso es algo bueno. Quiero decir que este es un excelente ejemplo de por qué queremos y necesitamos una reconfirmación de la RfA.
Pero ... ¿qué pasa con el espectro de la política?
La política no es un espectro. Así es como se hacen las cosas. Si no le gusta la política, no le gusta la gente. Entonces, ¡el caso piloto se inició por razones políticas! No importa . Un editor había escrito un artículo para, eh, la persona menos notable en wiki para la que he visto un artículo, obviamente por un par de cientos de dólares o lo que sea, y quería quedarse con el dinero, y estaba tratando de evitar que intentara eliminar o al menos castigarme, y consiguió el esfuerzo de reconfirmación pasando por esa razón (pero quiero decir que hice darle la apertura). Entiendo que a la gente le preocupa que esto suceda, y es una preocupación legítima, pero mira: ¿a quién le importa cuál fue la motivación? 147 personas votaron en ese RfA y consiguieron deshacerse de un administrador que muchos de ellos no querían, entonces, ¿cómo es eso de malo? Fui administrador durante 5 años y 48 personas pensaron que eso no funcionaba para el proyecto. No hay ningún planeta en el que una persona con esos números deba ser administrador, entonces, ¿cómo esta motivación "política" condujo a un mal final? La política no es Chthulu.
Ningún sistema será perfecto. Si algunos enemigos políticos te llevan a una reconfirmación de la RfA, eso es muy molesto, pero si tienes la verdad de tu lado, pasarás. RfA funciona y lo ha hecho durante 15 años.
Pero ... la barrera para una reconfirmación de RfA es demasiado baja
Sí, quizás. Es fácil de arreglar. Por lo tanto, Wikipedia: los administradores están abiertos al proceso de recuperación / muestra , que es el proceso predeterminado a menos que un administrador especifique lo contrario al dar a su firma un "Sí" claro en su RfA inicial, requiere la firma de seis editores con más de 500 ediciones y un mes de tenencia, para iniciar una reconfirmación RpA. Funciona para mí, pero tal vez eso sea demasiado fácil. Quizás sea demasiado difícil. Solo hay una forma de averiguarlo, pero tenga en cuenta:
Un candidato individual, al dar su firme "Sí" claro a la pregunta "¿Aceptará ser sujeto a reconfirmación, colocándose en Categoría: Administradores de Wikipedia abiertos a la revocación ?", Puede especificar una crítica diferente. Ella puede decir "Sí, pero tiene que haber diez editores". Ella puede decir "Sí, pero los editores deben tener 2000 ediciones y un año de servicio". Ella puede decir "Sí, pero al menos dos de los editores deben ser administradores", o "Sí, pero debe haber seis editores netos al final de un período de siete días, y cada editor que no quiera la reconfirmación RfA cancelando uno que lo hace "o" Sí, pero en realidad cuatro editores es suficiente "o especificar cualquier número de cambios complicados para su caso particular, o lo que sea.
Esto esta bien. Tal vez seis sea muy poco, así que en lugar de intentar cambiar la regla predeterminada (no es posible), deje que el candidato haga una corrección en tiempo real que crea razonable. No vas a cambiar la regla escrita, así que deja que el cuerpo de candidatos decida de forma orgánica e individual qué nivel de requisitos creen que pueden salirse con la suya.
Entonces, depende de nosotros, la gente "compacta", decidir individualmente cómo llevar esto a cabo. Puede ser como "Apoyar, pedir diez firmas [o lo que sea que hayan hecho] es razonable" o como "Oponerse, pedir diez firmas [o lo que sea que hayan hecho] constituye una barrera demasiado alta". Si la candidata está siendo razonable, probablemente satisfará a la mayoría de nosotros, gente "compacta", si no lo es, entonces no. No es nada de qué preocuparse ahora.
Y, por cierto, la Pregunta tiene que incluir el apéndice "Y si lo olvidas, no te importa si lo hago, ¿verdad?"
Pero ... ¿no habrá una gran cantidad de RfA de repente?
¡Probablemente! ¿Entonces? Nuestras RfA en este momento parecen funcionar a una velocidad de cero, uno o dos a la vez. En el pasado, teníamos media docena o más a la vez. Estuvo bien. El proyecto salió bien.¿Y sabes qué? Supongo que muchos de los RfA serán personas nuevas que soliciten el bit. Y teniendo éxito . Porque los votantes serán de la mente "Bueno, marginal ... pero necesitamos administradores, él podría crecer, y si no, siempre podemos pedir una reconfirmación". En consecuencia, más editores pedirán el bit, porque el estándar de facto será más bajo y es posible que no sean tan tímidos al preguntar. No sé si esto sucederá y no sé si será algo bueno. Probablemente. Pero solo hay una forma de averiguarlo.
Si alguien intenta nominar a 20 administradores para su reconfirmación o nomina a alguien justo después de aprobar uno, eso es solo troleo. La gente puede hacer eso ahora, nominar 1000 artículos en AfD o lo que sea, y nos ocupamos de eso. Simplemente envíelos a WP: ANI y bloquee el tema. Además, el "pacto" puede simplemente ignorar estas nominaciones sin sentido, no hacer la Pregunta y simplemente apoyar a la persona. Pretendo. No son RFA reales y hacer lo contrario es alimentar a los trolls.
Pero, ¿qué pasa si "descubrimos" que no es algo bueno, y todo explota y hay importantes consecuencias imprevistas?
Bueno, eso es fácil. Simplemente deje de exigir que los candidatos administradores acepten estar abiertos a la reconfirmación. Deje que el "compacto" se desmorone y se extinga. Recuerde, relativamente pocos administradores se verán afectados: solo aquellos entre el comienzo del "compacto" y la clara indicación de que no está funcionando. También puede eliminar Wikipedia: administradores abiertos para recordar y Categoría: administradores de Wikipedia abiertos para recordar . Si es clara y obviamente un error, no deberían tener ningún problema en hacerlo. Si no puede, esa es probablemente la forma en que la naturaleza le diga que es solo su opinión de que es clara y obviamente una metedura de pata.
Pero, ¿y si no es posible lograrlo políticamente? ¿Y si digamos que Admin Corps decide que es perturbador y comienza a bloquearnos?
Bueno, eso apestaría. Pero quiero decir, ¿queremos vivir para siempre? ¿Somos ratones o humanos? No podemos evitar que eso suceda ... no hay nada que hacer, solo intentar o intentar no. Estoy para intentarlo.
¿Ver? La magia estuvo dentro de ustedes, todo el tiempo. Buena suerte y no temas a la oscuridad. Herostratus ( charla ) 01:22, 11 de marzo de 2021 (UTC)
- ... @ Herostratus : un par de áreas no cubiertas en el texto de sus respuestas de cobertura (que me gusta, por cierto). 1) Los administradores no pueden estar obligados a retener permanentemente una política de retiro específica ni a tener una. Acabo de crear mis condiciones de retiro del mercado, pero si alguna vez entrara en gran medida, por ejemplo, probablemente cambiaría los términos para aumentar los requisitos. Incluso podría eliminarlos. Los administradores bien podrían hacer esto sin actuar de mala fe, siempre y cuando no lo estuvieran haciendo claramente para aprobar el RfA y luego cambiar. En su penúltimo punto, no cubre lo que les sucede a los desafortunados sujetos de prueba. Pasar RfA es mucho más difícil que fallar en un retiro, por lo que incluso si la mayoría decide que las consecuencias imprevistas son demasiado malas, eso no evita las principales consecuencias negativas en sus casos de prueba. Nosebagbear ( charla ) 02:00, 11 de marzo de 2021 (UTC)
- Bien. ¡Dices que te gusta, así que únete al pacto! Solo en tu propia mente está bien. ¡Ahora solo necesitamos 28 más!
- Sí, claro, escuchaste eso, que los administradores que trabajan en áreas difíciles y toman decisiones difíciles van a crear tantos enemigos que se volverán vulnerables. Nadie sabe realmente si esto es cierto, pero no tomaría en cuenta mis temores, ya que me parece que un administrador de este tipo también adquiriría muchos admiradores, y más en una RfA, donde las personas que no están familiarizadas con ese administrador están expuestas a su trabajo. Después de todo, algunos candidatos de RfA ahora han cabreado a personas que lo merecían, y entran.
- No veo ... si un administrador obtiene como 40 votos contrarios en RfA ... quiero decir, si tienes tantos enemigos, ¿no pasa algo? Y si realmente se trata de un grupo de malos actores que se alían contra un buen administrador, ¿no será eso aparente y contraproducente?
- En cuanto a la aplicación ... si un administrador acepta estar sujeto a la reconfirmación utilizando cualquier criterio que quisiera (debe estar escrito en algún lugar para su conveniencia, pero siempre puede ir a ver el RfA), ¿y se niega? ¿Es eso lo que estás preguntando? Bien, entonces la comunidad tiene una serie de pasos escalonados que podemos tomar:
- Arrastra al chico a WP: ANI . Dígale a Admin Corps en efecto: "Este POS mentiroso está incumpliendo su palabra. No pueden deshacerse de ella, pero pueden prohibirla. Vigilense y hágalo". Tal vez lo hagan, o tal vez serán negligentes en su deber y no lo harán. No puedo hacerlos.
- Entonces, si eso no funciona, arrastre al tipo a ArbCom con la misma solicitud. Tal vez la abandonen, o tal vez sean negligentes en su deber y no lo harán. No puedo hacerlos.
- Si eso no funciona, puede intentar acudir a los Stewards. Muéstreles lo que sucedió y pídales que le hagan algo al chico. No sé cómo funcionan los Stewards, pero estoy bastante seguro de que esto no funcionará. Pero podrías preguntar.
- Si eso no funciona, supongo que podrías enviarla a Coventry y también hacerla famosa. La vergüenza pública regular puede hacer que la vida de una persona aquí sea desagradable. Pero no podrás hacerlo si el Cuerpo de Administración la respalda (te perseguirán por acoso).
- Si el Cuerpo de Administración la respalda, tal vez se esté perdiendo algo y esté equivocado. Eso, o el Cuerpo de Administración son unos poltroons. Si el Cuerpo de Administración son unos idiotas, podrías suspirar, murmurar algo acerca de que nunca se hizo nada recto con la madera torcida de la humanidad y volver a escribir artículos. O si todo el asunto rechina demasiado, entonces supongo que podrías conseguir un nuevo pasatiempo. Los modelos de trenes son divertidos. Herostratus ( charla ) 02:54, 11 de marzo de 2021 (UTC)
- Lo que propones no es solo un acoso dirigido, es un acoso soportado con el propósito claramente establecido de convertir la vida del usuario en un infierno. Esto no es compatible con los términos de uso .-- Ymblanter ( charla ) 08:25, 11 de marzo de 2021 (UTC)
- El más fuerte posible está de acuerdo con Ymblanter aquí. Si ocurre este 'pacto', tendrás suerte de que te lleven al infierno. "No interrumpas la enciclopedia para hacer un punto", etc. Vaticidalprophet ( charla ) 02:03, 12 de marzo de 2021 (UTC)
- Lo que propones no es solo un acoso dirigido, es un acoso soportado con el propósito claramente establecido de convertir la vida del usuario en un infierno. Esto no es compatible con los términos de uso .-- Ymblanter ( charla ) 08:25, 11 de marzo de 2021 (UTC)
- En cuanto a la aplicación ... si un administrador acepta estar sujeto a la reconfirmación utilizando cualquier criterio que quisiera (debe estar escrito en algún lugar para su conveniencia, pero siempre puede ir a ver el RfA), ¿y se niega? ¿Es eso lo que estás preguntando? Bien, entonces la comunidad tiene una serie de pasos escalonados que podemos tomar:
- Entonces, ¿deberíamos rechazar hipotéticamente candidatos perfectamente buenos para RpA (donde ya tenemos tan pocos candidatos) para hacer un punto? Eso es un poco WP: POINTY , y ciertamente no ayudará con los requisitos de la lista de lavandería ya existente de algunos editores ... RandomCanadian ( talk / contribs ) 03:04, 11 de marzo de 2021 (UTC)
- ( editar conflicto ) Por supuesto que deberíamos, y no hay nada hipotético al respecto. A menos que te guste correr riesgos. Quiero decir, si eres un gerente de contratación y el candidato parece un ajuste excelente, estás listo para ir con él y él dice: "Una cosa más, ¿firmarías este contrato diciendo que el trabajo es de por vida, ausente? ¿Algún comportamiento realmente atroz que me lleve ante el vicepresidente de división? ", ¿no mataría eso su entusiasmo?
- Esto debería haberse hecho desde el principio. Debería haber sido una pregunta obligada desde el principio. Es una buena práctica común. Se pasó por alto, pero es hora de dejar de pasarlo por alto.
- Pero eres tú, y eso está bien. Realmente no hay necesidad de comentar aquí, este no es ese tipo de hilo. Estamos buscando
3028 o más humanos buenos y verdaderos. Editores que no están a bordo, de acuerdo. Herostratus ( charla ) 03:19, 11 de marzo de 2021 (UTC)- Ya hay un abandono por inactividad (que podríamos hacer más estricto para evitar los posibles juegos); y hay poca evidencia de que ArbCom no pueda manejar la situación actual; y mucho menos el consenso para implementar algo como esto. RandomCanadian ( charla / contribuciones ) 03:22, 11 de marzo de 2021 (UTC)
- ¿Quién dijo algo sobre el consenso? Este no es uno de esos tipos de propuestas.
- Ya hay un abandono por inactividad (que podríamos hacer más estricto para evitar los posibles juegos); y hay poca evidencia de que ArbCom no pueda manejar la situación actual; y mucho menos el consenso para implementar algo como esto. RandomCanadian ( charla / contribuciones ) 03:22, 11 de marzo de 2021 (UTC)
- Pero eres tú, y eso está bien. Realmente no hay necesidad de comentar aquí, este no es ese tipo de hilo. Estamos buscando
- No sé qué hará ArbCom, y eso nos convierte en dos. Pero quiero decir, en última instancia, Wikipedia se basa en normas, ética y buena fe. Si un administrador dice: "Sí, acepté estar disponible para la revocación, así es como me eligieron, pero mentí y te jode" ... bueno, son descarados, eso es todo, y se han deshonrado a sí mismos en frente a todos, y también a ellos mismos. No debería haber ninguna necesidad de aplicación: simplemente van a los Stewards, señalan el RfA fallido y les piden que pongan su granito de arena. Yo hice. ¿Quién no lo haría? Si la persona no hace eso ... hay cosas que puede hacer, supongamos que eso nunca va a suceder y que no vayamos allí todavía. Herostratus ( charla ) 04:08, 11 de marzo de 2021 (UTC)
- La pregunta de retirada debe ser la RFA Q4 estándar. Levivich acoso / sabueso 03:12, 11 de marzo de 2021 (UTC)
- Bienvenido a bordo Usuario: Levivich ! Hemos bajado a 27. Herostratus ( charla ) 03:20, 11 de marzo de 2021 (UTC)
- Muchos administradores tienen buenas razones por las que no están dispuestos a recordar. Por ejemplo, si me postulara para la administración, no estaría dispuesto a recordarlo, para evitar abusos por parte de los usuarios que, por ejemplo, guardan rencor por el artículo que eliminé y que crearon. Y si requiriera patrocinadores de administradores, entonces podría haber un administrador con el que tuve una disputa en WP: ANI que votó para desysopme. Verá, incluso si ese artículo que eliminé se eliminó por una buena razón. Si decidiera trabajar en la edición de restricciones o disputas de contenido, podría haber una gran coalición de usuarios que quisieran que me desocupara. Todo lo que están esperando es alguna excusa para despojarme de mí cuando bloqueo a uno de ellos por editar en guerra. Todos estos títeres de carne, para venir al rescate de su camarada, inician una discusión sobre el retiro. Los editores con sentido común votan no, pero son superados en número, y yo estoy inevitablemente desolado. ¿Ves el peligro de estar abierto al recuerdo? 🐔 ¡ Chicdat Bawk para mí! 12:46, 11 de marzo de 2021 (UTC)
- El peligro que describe no es real, demostrado por el hecho de que más de 100 administradores ya son recuperables y ni siquiera hemos tenido a alguien que haya iniciado un proceso de recuperación en una década. Si este hipotético peligro de represalia fuera real, ya habría sucedido al menos una vez. Levivich acoso / sabueso 15:19, 21 de marzo de 2021 (UTC)
- Muchos administradores tienen buenas razones por las que no están dispuestos a recordar. Por ejemplo, si me postulara para la administración, no estaría dispuesto a recordarlo, para evitar abusos por parte de los usuarios que, por ejemplo, guardan rencor por el artículo que eliminé y que crearon. Y si requiriera patrocinadores de administradores, entonces podría haber un administrador con el que tuve una disputa en WP: ANI que votó para desysopme. Verá, incluso si ese artículo que eliminé se eliminó por una buena razón. Si decidiera trabajar en la edición de restricciones o disputas de contenido, podría haber una gran coalición de usuarios que quisieran que me desocupara. Todo lo que están esperando es alguna excusa para despojarme de mí cuando bloqueo a uno de ellos por editar en guerra. Todos estos títeres de carne, para venir al rescate de su camarada, inician una discusión sobre el retiro. Los editores con sentido común votan no, pero son superados en número, y yo estoy inevitablemente desolado. ¿Ves el peligro de estar abierto al recuerdo? 🐔 ¡ Chicdat Bawk para mí! 12:46, 11 de marzo de 2021 (UTC)
- Bienvenido a bordo Usuario: Levivich ! Hemos bajado a 27. Herostratus ( charla ) 03:20, 11 de marzo de 2021 (UTC)
El problema aquí es que esto sufre los mismos problemas que el tema de este RfC: trabaja en un área controvertida y acumula a algunas personas que lo odian lo suficientemente rápido, y solo necesita un hilo cerrado negativamente y BAM, está listo para recordar. Cualquier cosa, realmente cualquier cosa, por debajo de 3 casos bastante significativos de pérdida de la fe debe ser realizada por ArbCom (por mucho que desprecio ese sistema), no de ninguna forma por la comunidad. Si hay algo de un patrón repetitivo significativo, entonces hay razones para desysop. Esto realmente necesita ser protegido por un tipo de sistema de '(al menos) tres strikes' (que ni este, ni la pregunta original de RfC anterior tienen) si la comunidad misma tiene que hacerlo. De lo contrario, verá un desglose de todo el cuerpo de administradores a un nivel en el que no habrá suficientes administradores disponibles para mantener Wikipedia (y los administradores que queden tendrán que hacerse cargo de las cosas controvertidas y, por lo tanto, seguir el ejemplo del primero bastante rápido como bueno, o administradores que se niegan a hacer cosas controvertidas, por lo que corren menos riesgos y simplemente cumplen con el estándar). - Dirk Beetstra T C 05:53, 11 de marzo de 2021 (UTC)
- OK, bueno, para llevar mi punto a casa de que este no es un tipo de hilo , seré grosero (para el efecto, nada personal): OK, anotado. No estás a bordo. Próximo. No buscamos consenso aquí. No se puede detener esto porque no es ese tipo de discusión típica de Wikipedia. No se puede "votar en contra" de las personas que se niegan individualmente a aceptar nuevos administradores sobre una base perfectamente razonable o exigir que alguien obtenga un "consenso" para hacerlo.
- No estamos discutiendo. Solo estamos reclutando. 28 para ir.
- Pero discutir sobre los méritos de los esgrimistas: no lo creo. Yo no. Primero que nada, no va a suceder, no creo. No le tengas miedo a la comunidad, no te dejes aconsejar por los miedos. Si no funciona, básicamente se corregirá automáticamente. Si sacar a colación constantemente este punto dudoso es, consciente o inconscientemente, egoísta ... no lo sé. Probablemente, por lo que sé de la gente. Es solo una charla de hombre del saco.
- En segundo lugar: no me importa en qué áreas trabajes, si has sido administrador durante un par de años y tienes una RfA de reconfirmación, 120 personas votan y 35 dicen "Bueno, gracias para el servicio, pero esto simplemente no funciona para la organización ", quiero decir, estás haciendo algo mal. Necesitas encontrar una manera de que 35 personas no repasen la totalidad de tu registro y digan "No, no funcionó". Si no puede ... ¿ debería seguir administrando? No en mi libro.
- Y si no soportas el calor, mantente fuera de la cocina. Hay un montón de trabajo administrativo que necesitamos hacer en el que supuestamente no terminas siendo la víctima inocente de un montón de personas inexplicablemente enojadas contigo. Si trabajar en áreas políticamente tensas no es un punto fuerte para usted, déjelo en manos de otros. Estoy seguro de que nos las arreglaremos.
- Y por Dios, no vas a diezmar el Cuerpo de Administración porque los administradores existentes están excluidos a menos que quieran entrar . ¿Estamos levantando como qué, 20 administradores al año? Es trivial. Demasiado trivial de hecho, pero al menos es un comienzo. Herostratus ( charla ) 13:28, 11 de marzo de 2021 (UTC)
- Herostratus , hay buenos puntos en eso, pero si haces cumplir esto, ejecutas un ReRFA cada tantos meses cada vez que molestas a algunas personas. No estoy en contra de ninguno de los sistemas anteriores y esto, pero con un apagamiento, los '3 golpes'. Como dije anteriormente, cometemos errores (auto-trucha en especial: nuclear, tenía la mitad de Wikipedia apilada en mi página de conversación y ANI). Si ahora hago lo mismo, hay motivo de preocupación, no aprendo. 3 veces con 3 diferentes, bien, estoy haciendo algo mal. Pero primero necesitamos un umbral, y dejemos que ArbCom por ahora maneje los 'casos de primera huelga'.
- Solo pensando en voz alta: primer error - ReRFA, pasas; segundo error - ReRFA, pasaste pero solo, ... eso es mucho estrés por nada. Pruebe con un poco de umbral primero, luego pierda. Dirk Beetstra T C 15:46, 11 de marzo de 2021 (UTC)
- ( editar conflicto ) Sí, correcto, correcto. Puntos justos. Bien ... pensemos en cómo funcionaría esto ...
- Primero, no creo que vaya a suceder. Si usted - rasca el "usted"; si eres un administrador ahora estás bien, abuelo; si el administrador no está cometiendo un error, la gente no se apilará sobre ellos. Si cometieron un error, sí, tal vez suficientes personas se enojen con ellos para forzar una reconfirmación (y recuerde, hay un período de siete días para que las personas se enfríen y retiren sus firmas, y para que otras personas (incluido ese administrador) hacer argumentos sobre cómo no se debe exigir al administrador que reconfirme, tal vez persuadir a algunas personas para que no firmen, o retirar sus firmas si lo han hecho).
- Pero tal vez me equivoque. Bueno ... si el administrador debe pasar por una reconfirmación inmerecida RfA, eso será una mierda para ellos. Sin embargo, no creo que muchas de las personas que están enojadas con el administrador voten en contra de ellos, si su historial está bien. Si lo hacen de todos modos, es un movimiento idiota, y están siendo idiotas. No creo que la comunidad tenga tantos idiotas. Si es así, ¿está seguro de que no está siendo un amargado por tanto tiempo lidiando con reprobados contumaces? Ve a hacer un trabajo más fácil (¡pero aún necesario!) Por un tiempo. ¡La gente aquí es genial, de hecho!
- Quiero decir, recientemente tuve un problema con un administrador, y estaba muy equivocado. Y él estaba siendo un poco lleno de sí mismo y estaba tirando de rango al respecto. Pero, aparentemente, es un administrador muy respetado desde hace mucho tiempo, así que quiero decir, está bien. No es perfecto. Quizás estaba teniendo un mal día. Tal vez se recuperó, la gente lo hace. Suponiendo que estuviera en la categoría: administradores de Wikipedia abiertos a recordar (tal vez lo esté). No voy a tratar de llamarlo, y si no lo hiciera, conseguiría a otras cinco personas a bordo. Y si lo hiciera, aprobaría su reconfirmación con gran éxito (aunque sí, tendría que pasar por la molestia). Ahora ... si me hubiera bloqueado por despecho, eso es diferente. Eso sería un abuso atroz en un grado preocupante y tal vez deberíamos verificar si ese ha sido un patrón. Una reconfirmación de RfA haría eso ... para este tipo probablemente no habría obtenido otras cinco firmas de todos modos. Entonces ... no veo un gran problema aquí.
- ¿Y los trolls que intentan hacer drama? serán manejados. Están en otra parte. Estará bien.
- Entonces ... si los trolls intentan abusar del sistema, bueno, no hay salvaguardas escritas para evitar que las personas sean trolls: digamos, nominar a un administrador para reconfirmar la RfA uno tras otro tan pronto como pasen (y el troll necesitaría un equipo de cinco confederados, eso sí). Pero no hay salvaguardas escritas para muchos comportamientos trolls, y nos las arreglamos.
- Por ejemplo, hasta donde yo sé, no hay nada escrito que diga que no se puede seguir nominando un artículo para AfD una y otra vez tan pronto como pasa uno. Pero nadie lo hace. Porque, ¿qué pasa si alguien hace eso? La segunda AfD es una Fortaleza casi unánime, tal vez rápida, y al troll le gritan y si tienen un patrón de eso, rápidamente se les prohibe el tema, o tal vez de inmediato. Entonces es realmente raro. Lo mismo aqui. No es probable que vote en contra de alguien que acaba de aprobar una reconfirmación de la RfA, y muy pocas personas lo harían. Incluso si el administrador dice "Acabo de aprobar una reconfirmación, y ahora me arrastran a otra, y terminé con eso y no voy a aceptar estar sujeto a confirmación nunca más", tal vez sea comprensivo y considere votar en apoyo en ese caso, supongo, y creo que también lo sería la mayor parte del pacto.
- Y quiero decir ... alguien podría hacer un MfD en el RfA y suspender el RfA mientras está en progreso (hay formas de hacerlo fácilmente); de hecho, esto es precisamente lo que sucedió en el caso piloto, si recuerdo. derecho. El caso piloto pasó fácilmente por el MfD porque no era un carro. Si lo hubiera sido, no lo habría hecho. La comunidad no es idiota. Relajarse. O me refiero a que alguien podría simplemente eliminar la página de RfA por motivos de troleo (usando la regla no escrita WP: No. Simplemente ... no. ) Y si básicamente nadie se opone, estás bien.
- Y quiero decir que hemos descubierto un nido de trolls descontentos (el troll y sus cinco aliados). Seguramente son tema prohibido al menos, y problema resuelto.
- No se preocupe demasiado por eso. Hay muchas salvaguardias contra los carros y los gilipolleces. La comunidad funciona. El río encontrará el camino correcto.
- Recuerde, esto sucederá siempre que suficientes personas asientan con la cabeza en este momento, o lo harán. Nadie puede hacer nada al respecto. Ésta no es una propuesta . Tres strikes o cuatro bolas y el ArbCom esto o aquello y lo que tienes ... Este hilo no es uno de esos hilos, vamos a entender eso.
- Y una cosa más. Recuerda, pasé por esto . En mi opinión, fue una mierda. No merecía perder un poco. Pero claro que voy a pensar eso, ya quién le importa lo que piense. Es lo que piensa la comunidad lo que importa . Incluso si están "equivocados" en el fondo, es lo que importa. Así es como se supone que debemos rodar, debemos rodar y debemos rodar. Si vas a ser un pez gordo por aquí, es mejor que creas en la comunidad. Yo lo hice y lo hago, y tú también puedes. Si no lo hace ... ese no es un buen aspecto, para alguien que quiere ser un pez gordo. Herostratus ( charla ) 17:40, 11 de marzo de 2021 (UTC)
- Si no fuera una buena persona, [ cita requerida ] diría lo siguiente, pero por supuesto que nunca diría algo así. Personas. YA TENEMOS una discusión sobre una propuesta aquí. Podrías intentar leerlo. (En primer lugar, no leí todas las cosas sobre estar abierto a la recuperación. Pero la recuperación no es un proceso estándar. Un administrador puede decir que está abierto a la recuperación, pero construirlo de tal manera que no tenga dientes. E incluso en el mejor de los casos, el retiro no es un proceso deliberativo que atraiga a una gran muestra representativa de la comunidad.) - Tryptofish ( charla ) 16:55, 11 de marzo de 2021 (UTC)
- No, no deberíamos intentar leerlo. Miré los números. Estás corriendo un 58% por ciento a favor. Nadie va a cerrar el RfC así como "aceptado" con esos números, y con 285 votantes hasta ahora, no vas a poder subir mucho ese porcentaje. La propuesta no será aceptada y eso es todo lo que necesito saber. Estamos pasando de eso, aquí.
- Y si la propuesta es aceptada, Dios los bendiga y ya está listo. Puedes ignorar todo esto si quieres. Pero no va a ser así, así que sigamos adelante.
- Entonces, por otro lado ... un administrador no puede construir nada para hacer algo sin dientes, no. No somos idiotas aquí. Alguien tratando de ser falso ... eso no va a funcionar. Si alguien dice "Seguro que estoy abierto a la reconfirmación, pero no lo haré con la oferta estándar; voy a requerir 35 firmas". Eso es evidentemente desdentado, y todos en el pacto lo tomarán como equivalente a "No". Si intentan ponerse elegantes con requisitos complicados para tratar de engañarnos, eso se tomará como un "No". Si los requisitos son razonables, eso es diferente, está bien y no hay problema. El compacto será en su mayoría gente buena e inteligente, al igual que la mayoría de los editores aquí.
- Si la persona simplemente está mintiendo y, si se envía a reconfirmación, dice "Bueno, cambié de opinión y voy a librarme de la arena" ... sí, eso es un problema. Estoy asumiendo que la mayoría de los administradores no son canallas, pero si uno lo es, describí algunos pasos a seguir. Puede que no funcionen. Pero si un administrador está tan decidido a aferrarse a su parte que quemará el mundo ... bueno, al menos sabremos que es una canalla y lo mencionaremos cada vez que intente hacer algo. Realmente no creo que se divertirá más, así que ... Herostratus ( charla ) 18:15, 11 de marzo de 2021 (UTC)
- "No, no deberíamos intentar leerlo." ¡Hagamos de ese el nuevo lema de Wikipedia! (Mucho mejor que "La enciclopedia libre").
- Tryptofish ( charla ) 18:33, 11 de marzo de 2021 (UTC)
- Jajaja. Debería echar un vistazo a la Wikipedia rusa. Se dice que . Pero quiero decir, solo me ocupo de la gestión del tiempo. Herostratus ( charla ) 00:47, 12 de marzo de 2021 (UTC)
- "No, no deberíamos intentar leerlo." ¡Hagamos de ese el nuevo lema de Wikipedia! (Mucho mejor que "La enciclopedia libre").
- Si la persona simplemente está mintiendo y, si se envía a reconfirmación, dice "Bueno, cambié de opinión y voy a librarme de la arena" ... sí, eso es un problema. Estoy asumiendo que la mayoría de los administradores no son canallas, pero si uno lo es, describí algunos pasos a seguir. Puede que no funcionen. Pero si un administrador está tan decidido a aferrarse a su parte que quemará el mundo ... bueno, al menos sabremos que es una canalla y lo mencionaremos cada vez que intente hacer algo. Realmente no creo que se divertirá más, así que ... Herostratus ( charla ) 18:15, 11 de marzo de 2021 (UTC)
- Herostratus , miré los números también. Pero no creo en los cambios drásticamente impuestos. Estoy de acuerdo, puede que tenga razón, pero en caso de que no lo esté, me temo que esto va a volverse dramático. Perder el 30% de nuestros administradores no va a salir bien (y si es el 50%). Nuestra tasa de recarga no va a compensar eso. Odio perder ese 30% y tener que decirle al 25% de eso (o al 40% si resulta ser el 50%) 'lo siento, fue un experimento, lástima, tu parte se ha ido, otros se harán cargo en algún momento'. Ser administrador no es gran cosa, pero de todos modos los necesitamos. Estoy totalmente a favor de los '3 strikes' y luego me doy cuenta de que solo arranca el 1%, y luego digo 'OK, intentemos strikes' y luego arranca el 15%, en lugar de no saber lo que hacemos y arranca el 50% y luego sin saber qué pasará después ('oh, tal vez si hiciéramos 2 strikes ...'). Hay cosas que ES perjudicial (copyvio, spam, bad socks, ...), ¿realmente queremos arriesgarnos a eso? Sé que 'slechte heelmeesters maken stinkende wonden' (lo siento por los holandeses, prueba el traductor de Google), pero 'vamos a cortarle la cabeza, veamos si eso cura el dolor en su dedo' tampoco está cerrando el trato ... Dirk Beetstra T C 19:34, 11 de marzo de 2021 (UTC)
- El punto 4 no es lo que esperaba. Esperaba que dijeras "solicitemos a todos los administradores que estén abiertos para recordar". Si decidimos como comunidad que nos gustaría exigir un cierto nivel de responsabilidad de los administradores, deberíamos exigirlo a todos, no formar un pacto que intente forzar la mano de solo futuros candidatos (son los administradores con derechos adquiridos quienes son el problema más grande de todos modos, en mi opinión). {{u | Sdkb }} charla 21:14, 11 de marzo de 2021 (UTC)
- Pues sí, pero: la política es el arte de lo posible. Sacar el actual Cuerpo de Administración de la mesa elimina, con suerte, un gran obstáculo para que algo funcione. Y sí, tomará algunos años tener mucho mordisco (aunque posiblemente podría ser útil en casos individuales dentro de un año), pero me refiero a que los años van a pasar de todos modos, así que bien podría comenzar. La discusión es genial, pero al final del día, esta no es la sala común para personas mayores en All Souls, es la maldita cara de carbón . Vamos a cavar.
- Y quiero decir que no hay forma de aplicar nada que valga la pena al actual Cuerpo de Administración, incluso si quisiéramos. Dudo que sea políticamente posible. (Tal vez me equivoque, y por todos los medios seguir intentando y godspeed. Pero no estoy equivocado.) Y aunque pudiéramos, supongo que es posible que cualquier cosa que afecta a todo el Cuerpo de administración a la vez podría ser demasiado mal comportado la del Admin Corps (lo dudo, porque incluso los nuevos candidatos que no han tenido la oportunidad de hacer un registro de administrador suelen ser aceptados 103-3 o algo así. Pero nunca se sabe. Así que quiero decir que hacer esto traerá un lanzamiento gradual). Herostratus ( charla ) 00:47, 12 de marzo de 2021 (UTC)
- Entonces, está diciendo que deberíamos usar esto para futuros administradores (que probablemente se eligen de manera mucho más selectiva que antes, porque la lista de RfA), pero no para algunos administradores mayores, con quienes supuestamente algunas personas tienen un problema por una razón xyz. Parece un movimiento ganador real: resolver un supuesto problema aplicando la solución a lo que no es un problema ... Toda la publicación dice que hay un WP: CABAL del "Cuerpo de administración": nuevamente, para repetir el punto: la administración no debería ' No sea un gran problema: son solo algunas herramientas para hacer la vida más fácil a los demás. En cuanto a la política: si pudiéramos deshacernos de eso aquí y solo preocuparnos por escribir una maldita enciclopedia sería una gran mejora; y no es que no haya nada que hacer ... RandomCanadian ( charla / contribuciones ) 00:59, 12 de marzo de 2021 (UTC)
- está bien. No hay necesidad de agitarse. "En cuanto a la política: si pudiéramos deshacernos de eso ..." Bueno, ahora siempre es la parte complicada, ¿no? "En cuanto a la gravedad: si pudiéramos deshacernos de eso ..."
- Entonces, está diciendo que deberíamos usar esto para futuros administradores (que probablemente se eligen de manera mucho más selectiva que antes, porque la lista de RfA), pero no para algunos administradores mayores, con quienes supuestamente algunas personas tienen un problema por una razón xyz. Parece un movimiento ganador real: resolver un supuesto problema aplicando la solución a lo que no es un problema ... Toda la publicación dice que hay un WP: CABAL del "Cuerpo de administración": nuevamente, para repetir el punto: la administración no debería ' No sea un gran problema: son solo algunas herramientas para hacer la vida más fácil a los demás. En cuanto a la política: si pudiéramos deshacernos de eso aquí y solo preocuparnos por escribir una maldita enciclopedia sería una gran mejora; y no es que no haya nada que hacer ... RandomCanadian ( charla / contribuciones ) 00:59, 12 de marzo de 2021 (UTC)
- Y quiero decir que no hay forma de aplicar nada que valga la pena al actual Cuerpo de Administración, incluso si quisiéramos. Dudo que sea políticamente posible. (Tal vez me equivoque, y por todos los medios seguir intentando y godspeed. Pero no estoy equivocado.) Y aunque pudiéramos, supongo que es posible que cualquier cosa que afecta a todo el Cuerpo de administración a la vez podría ser demasiado mal comportado la del Admin Corps (lo dudo, porque incluso los nuevos candidatos que no han tenido la oportunidad de hacer un registro de administrador suelen ser aceptados 103-3 o algo así. Pero nunca se sabe. Así que quiero decir que hacer esto traerá un lanzamiento gradual). Herostratus ( charla ) 00:47, 12 de marzo de 2021 (UTC)
- No tengo una opinión sobre si hay alguna forma de incluir a los administradores actuales en algún sistema o si es una buena idea. ¿Por qué tener una opinión sobre algo que no va a suceder?
- Si tú o alguien puede hacer que suceda, ¡genial! (Supongo.) Nada de lo que estamos haciendo en este hilo lo afecta en absoluto. Pero en ausencia de eso, ¿solo quieres quejarte sobre quién es un ganador y quién no? Si no estás de acuerdo con el compacto, bien, gracias por compartir, supongo.
- Bueno, el ArbCom se deshace de un par de malos administradores al año, supongo. Y hay desgaste general. Con el paso del tiempo, un porcentaje cada vez mayor de administradores estarán sujetos a reconfirmación. Personalmente, me encuentro con administradores malos muy raramente, pero si están ahí fuera, eso apesta. Pero nada de lo que estamos haciendo con el compacto lo empeorará , supongo, entonces, ¿cuál es el problema?
- Una cosa más sobre el tema de la política. Gente, dejen de decir "recuerden". Utilice "reconfirmación". Eso lo arroja de manera positiva. Propaganda 101. ¡Y esperamos que el administrador sea reconfirmado! Eso es una victoria. La persona fue seleccionada para ser administrador, ¡y ahora ha sido retirado y vuelto a seleccionar! ¡Algo de lo que él se sienta orgulloso! Pero habrá que informar a algunos de que creemos que sus puntos fuertes y su valor se encuentran en otras áreas. Herostratus ( charla ) 04:56, 12 de marzo de 2021 (UTC)
Gente, dejen de decir "recuerden". Utilice "reconfirmación". Eso lo arroja de manera positiva. Propaganda 101.
¿Crees que funciona cuando dices que eso es lo que estás haciendo? (Cada administrador terrible con el que me he encontrado se metió un poco cuando estaba en la escuela primaria o cuando era más joven; bueno, aparte de todo lo demás sobre esta propuesta, castiga a los inocentes y libera a los culpables). Vaticidalprophet ( charla ) 05:42, 12 de marzo 2021 (UTC)
- Pase lo que pase, querrá tener cosas en este sentido hechas y listas para funcionar. Herostratus ( charla ) 05:27, 12 de marzo de 2021 (UTC)
¡Este administrador ha sido confirmado nuevamente y está orgulloso de ello!
- Una cosa más sobre el tema de la política. Gente, dejen de decir "recuerden". Utilice "reconfirmación". Eso lo arroja de manera positiva. Propaganda 101. ¡Y esperamos que el administrador sea reconfirmado! Eso es una victoria. La persona fue seleccionada para ser administrador, ¡y ahora ha sido retirado y vuelto a seleccionar! ¡Algo de lo que él se sienta orgulloso! Pero habrá que informar a algunos de que creemos que sus puntos fuertes y su valor se encuentran en otras áreas. Herostratus ( charla ) 04:56, 12 de marzo de 2021 (UTC)
Este antiguo administrador se enorgullece de haber puesto la voluntad de muchos por encima de la voluntad de unos pocos o de uno. |
- Decir que la administración no es gran cosa es una falacia. Si realmente no fuera un gran problema, no necesitaríamos intentar reformar el proceso cada quince minutos. Anarchyte ( charla • trabajo ) 06:57, 13 de marzo de 2021 (UTC)
- Esa idea es realmente peligrosa si miras cómo funcionaría realmente.
- Si puede convencer a una fracción de los votantes de RfA! De que es lo suficientemente grande como para bloquear a los candidatos sin oposición, probablemente pueda elaborar una propuesta que se aprobaría. Entonces, en realidad, lo que espera es un RfA con algo así como ~ 55% de apoyo total, ~ 30% "sin creación de contenido o lo que sea" se opone, y ~ 15% "apoyaría pero el candidato no está abierto a la revocación". . En ese punto, ya sea suficiente en el pliegue lateral y apoyo de "retiro necesario" de todos modos (o el 'crat de cierre ignora esos votos!), En cuyo caso todo es desdentado; o te conviertes en una turba devastadora, matando a una buena candidatura para hacer un punto sobre el proceso.
- En realidad, estaría tentado a unirme: la Causa es Justa o algo así. Pero a continuación, habrá una facción que decida que solo los hablantes nativos de inglés o los lingüistas certificados deben obtener el bit (porque la administración requiere un dominio exquisito de las subteledades del idioma). O solo aquellos con más de 500 participaciones en AfD porque podrían cerrar algunas (incluso si el candidato indica que no tiene interés en hacerlo, ¿qué pasa si cambian de opinión en diez años?). O cualquier cosa en realidad, siempre que puedas expresar la idea sin que te bloqueen y obtengas suficientes seguidores ciegos, eres dorado.
- Si hacer algo al sacrificar al candidato se convierte en una práctica aceptable en las RfA, dudo que el entorno mejore. Esto significa importar el funcionamiento de los partidos políticos en los procesos de Wikipedia (puede debatir internamente en su tiempo libre, pero en público defiende la línea del partido con uñas y dientes incluso contra su propia opinión), lo que no fomenta buenos argumentos. Una gran cantidad de comentarios de RfA son estúpidos, claro, pero estoy seguro de que son estúpidos individualmente , y tener que escribir tu propio comentario estúpido pone un límite superior a lo estúpido que puede ser. Tigraan Haga clic aquí para contactarme 13:11, 15 de marzo de 2021 (UTC)
@ Herostratus : Me uniré a su pacto. ¿Existe una lista de registro? Tim Smith ( charla ) 04:57, 21 de marzo de 2021 (UTC)
Oh, administración
La administración es una de las áreas más decepcionantes de Wikipedia. Cuando Jimbo Wales creó la administración por primera vez, se le otorgó a personas con apenas 1,000 ediciones. Muchos de esos editores apenas editaron. Pero no presumieron de su papel. A menos que tuvieras problemas serios, los requisitos de administración eran tan sutiles como los de nuestra versión extendida moderna confirmada: básicamente, "Un usuario aparece en Wikipedia en 2004 y realiza algunas ediciones. La edición 47 es para solicitar la administración. Se concede, después de un pequeño número de votos de apoyo, que decían "La administración no es gran cosa". Al usuario se le otorgan las herramientas. Se olvidan de Wikipedia. Permanecen como administrador durante siete años, sin hacer ni una sola edición, cuando son desocupados por inactividad ". En aquel entonces ni siquiera necesitábamos deshacernos de él, porque nadie pensaba que la administración fuera un gran problema. Luego, de forma lenta pero segura, la cantidad de nuevos administradores comenzó a disminuir. En 2010, los usuarios se estaban enamorando de la "reforma RfA". Comenzó la propuesta perenne de desisoping de la comunidad, WP: Solicitudes de des-administración , etc. Todas estas cosas continuaron hasta 2013. Para entonces, más de 100 editores estaban votando en las RpA. El tradicional " Soporte - no es gran cosa" que se ve tan a menudo en las RfA de 2003 - 2010 se estaba volviendo cada vez más raro. Menos editores pensaban en la administración como "nada importante", siendo eclipsados por los editores que repentinamente requerían: "¡10,000 ediciones! ¡5 FAs! 20 GAs! 500 informes AIV! 500 informes RfPP! 10 derechos de usuario! 10 años!" Antes, los criterios de la mayoría de los usuarios eran "al menos un no stub", lo que daría a los candidatos de WP: SNOW como Prahlad balaji administración "automática", pero los criterios se hicieron cada vez más grandes. Nuestro número condenado de administradores activos disminuyó cada vez más. Los viejos administradores de la década de 2000, uno por uno, comenzaron a retirarse. En el año (¡solo!) Que he estado en Wikipedia, he visto a muchos editores de 10 o 15 años, a menudo administradores, irse y decir algo como "Wikipedia ha cambiado mucho. Se ha vuelto demasiado hostil para mí. . " Antes de ese momento, ese administrador podría ser, digamos, responsable del 36% de todas las revisiones de AfC, y la acumulación de 5000 borradores solo se desarrolló después. Los administradores de Wikipedia se están yendo y, en lugar de facilitar la RfA, proponemos todo tipo de "duración del período de administración" y "desysop basado en la comunidad" para que sea MÁS FÁCIL para la eliminación de esos administradores. Estos usuarios pobres ahora dicen, "Wikipedia es demasiado hostil para mí" cuando empeoramos las cosas. La administración debería volver a ser "nada importante". Pero es muy difícil si cada pocas horas gritamos: "¿Por qué no realizar un proceso de recuperación para los administradores? Realizamos una RfA de reconfirmación cada tres semanas para cada administrador". Esto pondría tanto estrés en estos pobres administradores que todos dimitirían. A veces, el administrador se está comportando mal, como en el caso de Bbb23 , pero ese es el único caso en el que puedo pensar. ¿Alguna idea? 🐔 ¡ Chicdat Bawk para mí! 12:58, 14 de marzo de 2021 (UTC)
- La administración era un asunto "sin gran importancia" cuando Wikipedia era mucho más pequeño y más simple como proyecto, pero estaba experimentando una afluencia constante de nuevos editores habituales. Ahora las cosas son completamente diferentes. La administración como trabajo se ha vuelto mucho más complicada, complicada y, a menudo, desagradable porque Wikipedia se ha vuelto mucho más compleja. Al mismo tiempo, la oferta entrante de nuevos editores habituales se ha estancado. La única forma realista de hacer que la administración sea "nada importante" de nuevo es cambiar drásticamente la naturaleza del trabajo, muy probablemente mediante la separación de las herramientas y la introducción de varios nuevos derechos de usuario limitados. Nsk92 ( conversación ) 11:40, 15 de marzo de 2021 (UTC)
- Precisamente porque la bandera de administrador no es un gran problema, no hay necesidad de hacer un drama por el hecho de que la bandera de alguien será eliminada. Lo que Wikipedia realmente necesita es algún tipo de proceso fácil de toma de decisiones en grupo que no suponga un peso adicional para los administradores; es por eso que la gente se agota y se va. · Carn · !? 14:35, 14 de abril de 2021 (UTC)
- Estoy completamente de acuerdo (aunque le vendría bien c / e). El problema es que RfA no funciona y no hay consenso para solucionarlo. Y propuestas como esta, si se aprueban, darán a los posibles candidatos de la RpA una razón más para no molestarse. Jules (Mrjulesd) 14:54, 14 de marzo de 2021 (UTC)
- Creo que el adagio "Ten cuidado con lo que pides. ¡Es posible que lo consigas!" se aplica. Aparentemente, algunas personas piensan que podemos prescindir de una gran parte de nuestro cuerpo administrativo y mantener este proyecto en marcha. No podemos. Lo que es deprimente es que este RfC probablemente lo cerrará alguien sin suficiente experiencia y sin las habilidades de evaluación de consenso necesarias. Hay
124130 páginas impresas en este RfC ahora. Me atrevo a decir que pocos, si es que hay alguno, lo leerán en su totalidad para siquiera comenzar a evaluar el consenso correctamente. Por lo tanto, algún cerrador bien intencionado, pero lamentablemente no preparado, cerrará esto como un pase, y ahí va una gran franja de nuestro cuerpo administrativo. - Hammersoft ( charla ) 00:38, 15 de marzo de 2021 (UTC)- No estoy familiarizado con los estándares para decidir el consenso, pero con 125 individuos separados (muchos con larga experiencia) votando en contra, no me parece un resultado obvio de "hay consenso". No es una mayoría (164: 125), pero no estamos recuento de votos!. ¿Ese margen estrecho realmente se consideraría consenso? Tarl N. ( discutir ) 01:10, 15 de marzo de 2021 (UTC)
- Aparte del resentimiento , ¿cuál sería la razón por la que la gran franja se fue? - Ryk72 talk 01:18 , 15 de marzo de 2021 (UTC)
- Cuando la wikipedia alemana lanzó su sistema de desysop comunitario, rápidamente perdieron algo así como 1/3 de su cuerpo administrativo. Pero (no dirigido a ti), ¿a quién le importa? Necesitamos algo, así que también podríamos hacer esto, ¿verdad? Al diablo con las consecuencias.
- Hammersoft ( charla ) 01:29, 15 de marzo de 2021 (UTC)- Hammersoft , tengo curiosidad, ¿qué pasó con el 1/3? ¿Hubo toneladas de desysops, o los administradores simplemente renunciaron en protesta, o algo más? - RoySmith
(charla) 01:33, 15 de marzo de 2021 (UTC)
- Han pasado algunos años, pero como recuerdo cuando me enfrentaron a una solicitud de reconfirmación, al igual que aquí, muchos se negaron a pasar por ella. RfA es un infierno para muchos. Ser forzado a atravesarlo cuando se sabe que hay sangre en el agua (no solo la esperanza de que no la haya) es demasiado para muchas personas. Todos somos voluntarios aquí. Ponerse voluntariamente en tal situación no es aceptable para muchas personas. Entonces, lo corto es que si obtienes un hilo en WP: AN / I que resulta incluso moderadamente en tu contra, básicamente estás jodido. No vale la pena para muchas personas. - Hammersoft ( charla ) 01:39, 15 de marzo de 2021 (UTC)
- Entonces, ¿qué pasa si 1/3 de los administradores alemanes se van? No estoy tan familiarizado con la Wikipedia alemana, pero por lo que sé, todavía está por ahí y avanza perfectamente bien sin ellos. De todos modos, la decisión de cómo se debe responsabilizar a las personas por sus acciones no debe estar determinada por el miedo a que dichas personas se lleven sus juguetes y se vayan a casa. Ser administrador es un privilegio y debe tratarse como tal. Si eso significa que se necesita más responsabilidad, entonces el sistema actual, está bien. Ese es el costo de tener el privilegio. Si un administrador no está dispuesto a pasar por un proceso de reconfirmación porque cree que es demasiado arduo o lo que sea, o si tiene problemas con tener que seguir los estándares básicos de comportamiento, entonces claramente no ve su posición privilegiada como tal y no debería. no lo tengo. - Adamant1 ( conversación ) 02:24, 15 de marzo de 2021 (UTC)
- Han pasado algunos años, pero como recuerdo cuando me enfrentaron a una solicitud de reconfirmación, al igual que aquí, muchos se negaron a pasar por ella. RfA es un infierno para muchos. Ser forzado a atravesarlo cuando se sabe que hay sangre en el agua (no solo la esperanza de que no la haya) es demasiado para muchas personas. Todos somos voluntarios aquí. Ponerse voluntariamente en tal situación no es aceptable para muchas personas. Entonces, lo corto es que si obtienes un hilo en WP: AN / I que resulta incluso moderadamente en tu contra, básicamente estás jodido. No vale la pena para muchas personas. - Hammersoft ( charla ) 01:39, 15 de marzo de 2021 (UTC)
- Hammersoft , tengo curiosidad, ¿qué pasó con el 1/3? ¿Hubo toneladas de desysops, o los administradores simplemente renunciaron en protesta, o algo más? - RoySmith
(charla) 01:33, 15 de marzo de 2021 (UTC)
- Defina "resoplando perfectamente bien". Déjame darte un contraejemplo; Los comunes. Commons tiene una seria falta de administradores. Hay discusiones de eliminación que tienen 10 meses de antigüedad y no se han cerrado. 10 meses. ¿Commons sigue funcionando? Seguro. Pero su capacidad para mantenerse al tanto de los retrasos ha desaparecido. Ese proyecto colapsará en los próximos años porque el control de los archivos entrantes se derrumbará. Sin lugar a dudas, nos dirigimos en la misma dirección, como esto muestra bastante dolorosamente . La wikipedia alemana ha perdido el 42,9% de su cuerpo de administradores desde su pico en 2009. Hemos perdido el 23,6% de nuestro cuerpo de administradores desde nuestro pico en 2010. Los administradores ya son responsables de sus acciones. ArbCom ha demostrado su voluntad de asumir casos de conducta de administradores a la menor pizca de incorrección, lo que hace que este proceso no tenga sentido. ArbCom destituyó por la fuerza a tres administradores en 2020 y a otros cuatro en 2019. No conozco a ningún administrador que tenga problemas con seguir los estándares básicos de conducta. Este proceso de reconfirmación permite que los malos actores jueguen con el sistema. Permitir que las reconfirmaciones procedan con tan pocas protecciones garantiza que los administradores tendrán que enfrentarse a una reconfirmación por las razones más endebles. No hay recopilación de pruebas, no hay oportunidad de refutación, no hay declaraciones de alcance, no hay control sobre cuánto pueden escribir los antagonistas. En efecto, es un linchamiento de todos contra todos. Dudo que haya muchos administradores que quieran enfrentar eso. Ser administrador realmente no otorga privilegios adicionales en el proyecto. Le brinda algunas herramientas para realizar trabajo voluntario en nombre de la comunidad. Actuar con esas herramientas conlleva una gran responsabilidad. Tratar de defender tal uso frente a un proceso que tiene pocas protecciones y ninguna oportunidad para la recopilación de pruebas no tiene sentido. - Hammersoft ( charla ) 02:53, 15 de marzo de 2021 (UTC)
- @ Hammersoft : Prueba Wiktionary. El artículo "Buen aspecto" ha estado ahí durante 17 meses. Existe consenso para eliminar, pero no hay un solo administrador que tenga tiempo para cerrar la solicitud. Wiktionary y Commons? Wikipedia ya es como ellos en algunos aspectos. Tome, artículos para la creación. Su cartera de pedidos tiene 5.100 envíos que se remontan a 5 meses. Solía borrar la categoría de 4 meses todos los días, pero incluía editores impacientes que me presionaron para que aceptara los borradores , así que dejé de revisar . Y ese es un ejemplo de una acumulación de trabajos que ni siquiera se limita a los administradores. Algunos atrasos pueden ser terribles para los usuarios afectados. Desbloquear solicitudes, digamos. Si está atrasado, es muy fácil borrarlo. Todo lo que dice es: "Solo rechazo por procedimiento. Esta solicitud de desbloqueo ha estado abierta durante más de dos semanas, pero no se ha respondido. Si reformula sustancialmente su solicitud ...", cuando podría decir: "Lo sentimos, la categoría de solicitud de desbloqueo era atrasado, así que lamento haberte llegado tan tarde. Ahora ... [acepta o rechaza] "Necesitamos más administradores. Esto hace lo contrario. ¡Golpeo mi! Voto. Yo voto en contra. 🐔 ¡ Chicdat Bawk para mí! 10:19, 15 de marzo de 2021 (UTC)
- Aquí hay algo ridículo: Ayer estaba navegando por un RfA de 2010 y descubrí que algunos usuarios votaron así: " Oponerse , tenemos demasiados administradores". Ojalá estuviéramos en esos días, donde el problema era que los administradores no tenían nada que hacer, ya que los atrasos se borraron tan rápido. 🐔 ¡ Chicdat Bawk para mí! 10:19, 15 de marzo de 2021 (UTC)
- Tanto Commons como Wikipedia deberían hacer más en el back-end para reclutar administradores. Sin embargo, como dices, ya están bajando con ambos proyectos y aún disminuirán en Wikipedia si esto se implementa o no, pero eso no significa que los estándares de comportamiento y las cosas relacionadas con la responsabilidad no deban evolucionar o actualizarse mientras tanto. Lo mismo podría suceder con la disminución de editores a lo largo de los años, pero eso no significa que los estándares o procesos de responsabilidad de los usuarios deban relajarse o eliminarse solo para ganar más editores. Hay mejores formas de reclutar personas. Tampoco conozco a ningún administrador que tenga problemas para seguir los estándares básicos de comportamiento. Mi punto estaba puramente relacionado con la posibilidad de que los administradores decidan retirarse porque no quieren ser confirmados nuevamente. La única razón por la que no querrían volver a pasar por el proceso, además de ser una molestia, es para que no se mencione su comportamiento anterior. Mientras tanto, no hay evidencia de que pasar este RfC permitirá "jugar con el sistema". Incluso los administradores lo apoyan. Enmarcar el proceso basado en la comunidad que esto permitiría como un "linchamiento libre para todos" es bastante hiperbólico. Yo mismo he pasado por algunos procesos BS ANI bonitos y ni siquiera iría tan lejos. Sin embargo, una vez más, ser administrador es un privilegio otorgado por la comunidad. Por lo tanto, no hay ninguna razón por la que la comunidad no se lo quite también. Claramente, no es así como funciona ArbCom. No es una solución basada en la comunidad y claramente no está funcionando por sí sola o no habría necesidad de este RfC en primer lugar. Tampoco esto seguiría apareciendo. No importa lo que los administradores quieran enfrentar o no, importa cuál es la mejor manera de lidiar con el mal comportamiento y claramente esta es una solución necesaria para el problema. ¿Es la "mejor" solución? No. Sin embargo, es mejor que lo que hay actualmente. - Adamant1 ( charla ) 03:12, 15 de marzo de 2021 (UTC)
- Adamant1 , ¿cómo no es ArbCom una solución basada en la comunidad? Obviamente, tiene bastante apoyo si tenemos un número significativo de personas voluntarias en el comité y un número significativo de personas votando para elegir a sus candidatos preferidos. Elegimos tener un ArbCom.
- Estoy de acuerdo en que podemos llegar a una decisión basada en la comunidad (en contraposición a una decisión basada en un comité basado en la comunidad), lo que temo son criterios de selección demasiado laxos de quién representa la reconfirmación, haciendo 1/3 de las personas deciden que no quieren hacerlo más y renuncian de manera preventiva (entonces estamos en una pérdida total del 50% de los administradores desde 2010), luego perdimos otro 1/3 que pasa por el proceso (o que ver que otros se van y deciden ir). ¿Y entonces? El proceso estuvo mal, lo siento, ¿gracias? ¿Queremos correr el riesgo de que ya no podamos manejar discusiones de eliminación, spam, violaciones de BLP, etc., etc.?
- Sí, deberíamos hacer más para atraer a más administradores, pero este proceso primero hará que las personas sean más reacias a convertirse en uno, y dado que no tenemos una tendencia ascendente significativa en la obtención de más administradores ahora (no estamos haciendo nada en el back-end para reclutar administradores ) y corremos el riesgo de que esto nos cueste una gran cantidad de administradores (incluso si aquí sucede lo mismo que en de.wikipedia, y perdemos 1/3, para fines de 2021 hemos perdido casi el 50% de los administradores desde el pico en 2010).
- Esto comienza a parecer un poco como los premios Darwin se encuentran con el rollo de papel higiénico vacío: "Nunca comiences un proyecto a menos que todos los recursos estén disponibles" -meme. Dirk Beetstra T C 06:26, 15 de marzo de 2021 (UTC)
- ArbCom es un proceso mucho menos comunitario que ANI. Ni siquiera son comparables en el nivel de participación o las personas que navegan por uno frente al otro. ArbCom por su naturaleza no es tan exclusivo como lo es ANI. Tampoco hay nada en este RfC de lo que puedo decir que sacaría por completo a ArbCom del proceso. Todavía se podrían utilizar en los casos en los que sea necesario. Esto simplemente hace que no sean el recurso automático para la resolución de disputas administrativas. En cuanto al proceso de selección, podría ser una cosa demasiado laxa, podría serlo. Sin embargo, puede que no lo sea, y al menos se puede ajustar después de un período de prueba. Así funcionan las cosas. Nada es perfecto. Especialmente en los primeros intentos. Sin embargo, eso no significa que no valga la pena hacerlo. Lo mismo ocurre con todo su "vamos a perder 1/3 de los administradores si implementamos esto". No hay evidencia de que suceda e incluso si sucede, hay mejores formas de obtener más administradores, que estarán de acuerdo con una nueva confirmación. Especialmente en desacuerdo con su juicio "masivo" sobre cuántos administradores se perderán cuando muchos administradores hayan dado su aprobación para esto. No hice un recuento exacto, pero parece que en este momento hay más a favor y en contra. La mayoría de las personas que están en contra están de acuerdo en que ArbCom no es la mejor manera de hacer las cosas y que al menos se debe hacer algo. Entonces, ¿cuál es la alternativa? En Wikipedia no es capaz de manejar discusiones de eliminación, etc. Etc. Nuevamente, eso es solo más miedo a la bola de cristal y no es lo que sucedió con la Wikipedia alemana incluso después de que perdieron 1/3 de sus administradores. Sin embargo, una vez más, la forma de asegurarse de que eso no suceda es reclutar más administradores que estén dispuestos a cumplir con los estándares y procesos modernos. No solo estar cerca de los que no lo están. - Adamant1 ( conversación ) 09:24, 15 de marzo de 2021 (UTC)
- Luego, la comunidad descubre un nuevo proceso de RfA que se asemeja a los criterios de 'los buenos viejos tiempos' / uno que puede generar administradores con una producción significativamente más alta que la actual, o aguanta esos retrasos. Sospechoso que la gente se daría cuenta de algo en lugar de ver a WP: AN recibir spam con más avisos de acumulación de lo que ya recibe. ProcrastinationReader ( charla ) 11:28, 15 de marzo de 2021 (UTC)
- Los casos de ArbCom son efectivamente un supervoto al final del día. A los editores se nos permite dejar nuestras opiniones, pero eso no significa que el comité deba tenerlas en cuenta cuando votan aceptar / rechazar, y creo que eso es lo que enoja a la mayoría de las personas en la columna de apoyo. Al hacer que la desadministración pase por la comunidad sin restricciones excesivas, da la impresión de que en realidad podríamos tener voz más allá de la RfA inicial. No estoy diciendo que esta propuesta sea perfecta (mi apoyo es tentativo), pero es mejor que sentarnos y jugar con nuestros pulgares durante otros doce meses mientras nos preguntamos por qué todos se quejan del proceso de administración. Creo que es inevitable que algunos administradores decidan, si esto pasa, que es demasiado burocrático y preferirían renunciar a sus derechos antes que pasar por la tortura de otra RfA, pero con suerte debería abrir otras vías para expandir el grupo de administradores. El aspecto más inmediato que podría cambiar podría ser el estricto criterio administrativo que utilizan algunos opositores en serie. Si todos se vuelven capaces de iniciar solicitudes de desadministración en lugar de ser calzados para tener una oportunidad para evitar que pase un RfA, entonces tal vez sean más indulgentes y que se les otorgue el rol se desarrollará lentamente para no ser un gran problema. Anarchyte ( charla • trabajo ) 11:40, 15 de marzo de 2021 (UTC)
- No sé por qué tomó hasta la última oración anterior de Anarchyte para decirlo en esta sección, pero en mi opinión, ese es el argumento principal de la propuesta: facilitar el desysop disminuye el trato en el que se ha convertido la administración, por lo que RfA se vuelve más fácil de aprobar. Hay argumentos en contra convincentes que hacer ("la administración aún sería un gran problema", "garantizaría un impacto inmediato en los números de administrador para un beneficio especulativo a largo plazo", etc.) pero "una vida más dura como administrador = menos administradores" es ninguno de ellos. Tigraan Haga clic aquí para contactarme 12:29, 15 de marzo de 2021 (UTC)
- La ironía es que esta propuesta le da a la comunidad menos poder. Requiere menos del 40% a favor de mantener la aprobación, y aunque no se dice explícitamente, muchos editores probablemente esperan que los desysops sigan este proceso, no ArbCom. La gente probablemente se opondrá a elevar el umbral al 60%, y ArbCom probablemente rechazará los casos sobre la base de "usar el proceso de la comunidad / DR de la comunidad no agotado" (y cuando sea, probablemente dirán "la comunidad votó para retener, ArbCom no debería no invalide a la comunidad ", o al menos muchas declaraciones probablemente los instarán a votar de esa manera). Un umbral del 40% es tan pobre que solo los administradores más impopulares no podrían lograr ese soporte. De hecho, si User: Thryduulf / Lo que sucedió después de un desysop es algo por lo que pasar, esos 3 desysops con más del 40% pero menos del 65% de apoyo en re-RfA no habrían sucedido bajo esta propuesta (para bien o para mal). Esta propuesta prácticamente hace que los administradores populares sean indeseables, en mi opinión. ProcrastinationReader ( charla ) 12:41, 15 de marzo de 2021 (UTC)
- Los casos de ArbCom son efectivamente un supervoto al final del día. A los editores se nos permite dejar nuestras opiniones, pero eso no significa que el comité deba tenerlas en cuenta cuando votan aceptar / rechazar, y creo que eso es lo que enoja a la mayoría de las personas en la columna de apoyo. Al hacer que la desadministración pase por la comunidad sin restricciones excesivas, da la impresión de que en realidad podríamos tener voz más allá de la RfA inicial. No estoy diciendo que esta propuesta sea perfecta (mi apoyo es tentativo), pero es mejor que sentarnos y jugar con nuestros pulgares durante otros doce meses mientras nos preguntamos por qué todos se quejan del proceso de administración. Creo que es inevitable que algunos administradores decidan, si esto pasa, que es demasiado burocrático y preferirían renunciar a sus derechos antes que pasar por la tortura de otra RfA, pero con suerte debería abrir otras vías para expandir el grupo de administradores. El aspecto más inmediato que podría cambiar podría ser el estricto criterio administrativo que utilizan algunos opositores en serie. Si todos se vuelven capaces de iniciar solicitudes de desadministración en lugar de ser calzados para tener una oportunidad para evitar que pase un RfA, entonces tal vez sean más indulgentes y que se les otorgue el rol se desarrollará lentamente para no ser un gran problema. Anarchyte ( charla • trabajo ) 11:40, 15 de marzo de 2021 (UTC)
- Cuando la wikipedia alemana lanzó su sistema de desysop comunitario, rápidamente perdieron algo así como 1/3 de su cuerpo administrativo. Pero (no dirigido a ti), ¿a quién le importa? Necesitamos algo, así que también podríamos hacer esto, ¿verdad? Al diablo con las consecuencias.
![DeWikiRfasOverTime.gif](http://wikiimg.tojsiabtv.com/wikipedia/en/thumb/a/ae/DeWikiRfasOverTime.gif/220px-DeWikiRfasOverTime.gif)
La idea de que aprobar esta propuesta significa que será más fácil aprobar RfA y, por lo tanto, obtendremos más administradores es una especulación infundada. Como punto de referencia con datos reales: en la Wikipedia alemana, instituyeron su desadministración a fines de 2009. Desde entonces, el número de RpA exitosas ha seguido disminuyendo en promedio, como muestra el gráfico que incluyo aquí. Obtener datos reales para respaldar la búsqueda de soluciones es fundamental en cualquier matriz de resolución de problemas. Mucha gente tiene sus teorías favoritas sobre lo que está mal con RfA y por qué debemos o no tener una desadministración fuera de ArbCom. Actuar sin datos reales es simplemente adivinar. - Hammersoft ( charla ) 15:51, 15 de marzo de 2021 (UTC)
- Ese tipo de datos es muy útil, gracias. ¿Esa disminución es el resultado de que se intentan menos RpA o de que menos de los RpA intentados tengan éxito? - Tryptofish ( charla ) 16:51, 15 de marzo de 2021 (UTC)
- No lo sé, aunque es una pregunta valiosa. Solo estaba intentando recopilar datos para respaldar o refutar la presunción de que un proceso de eliminación de la administración daría como resultado un mayor número de RpA exitosas. En la Wikipedia alemana, no fue así. - Hammersoft ( charla ) 17:05, 15 de marzo de 2021 (UTC)
- Al observar el gráfico, parece que la Wikipedia de Alemania no perdió administradores a un ritmo diferente después de que se aprobó la política en ese momento. Así que aparentemente no tuvo ningún efecto en la tasa de declive y la opinión de que sí lo hizo es básicamente una propaganda del miedo. Cuál es mi suposición. En todo caso, parece que la cantidad de administradores que se perdieron con el tiempo disminuyó después de su aprobación. Aunque, obviamente, el número de administradores no ha aumentado desde entonces, pero de todos modos no aumentó. Por tanto, es evidente que se trata de cuestiones independientes que deberían tratarse como tales. Mientras tanto, sin embargo, existe una clara correlación cero entre el paso de cosas como esta y la pérdida de administradores. - Adamant1 ( charla ) 00:56, 16 de marzo de 2021 (UTC)
- Sin Adamant1, no se trata de infundir miedo. Los datos que se muestran son para nuevos RfA, no para administradores retirados / reconfirmados. Este conjunto de datos no puede mostrar o refutar una correlación, ni debe hacerse ningún intento de hacerlo con él. Simplemente no es relevante. - Hammersoft ( charla ) 01:10, 16 de marzo de 2021 (UTC)
- ¿Cuántos administradores fueron eliminados de la Wikipedia en alemán a través del proceso de la comunidad y por qué razones, alguien lo sabe? ProcrastinationReader ( charla ) 01:20, 16 de marzo de 2021 (UTC)
- No lo sé, y es más difícil derivar esos datos de lo que he podido recopilar. Recuerdo el problema de que perdieron una tonelada de administradores después de que se implementó, pero esto fue hace más de 10 años. No recuerdo dónde tuvo lugar esa conversación. Los datos se complican al cambiar las definiciones de voluntario, reconfirmado, etc. Parece que ~ 57% de las reelecciones involuntarias fueron exitosas (82 de 143). Pero esta cifra no incluye a los administradores que se negaron a pasar por el proceso de reelección. Ahí es donde hubo una caída considerable de administradores. Ojalá pudiera encontrar el artículo que trata sobre esto. Quizás alguien más pueda. Seguiré cavando. - Hammersoft ( charla ) 02:19, 16 de marzo de 2021 (UTC)
- ¡Ah, ja! ¡Lo encontré! Consulte Wikipedia: Administrators / RfC para obtener información sobre el recordatorio del administrador # Estadísticas de Wikipedia en alemán . Corto de eso; ante una elección revocatoria, el 37% de los administradores se jubilaron o se negaron a responder. Extrapolando esos datos, usándolos en 2009, la Wikipedia alemana tenía ~ 325 administradores: en 2009, se ejecutaron 67 reconfirmaciones. 12 fueron reelegidos, 34 no reelegidos y 21 optaron por retirarse. Entonces, el 18% de los 67 fueron reelegidos. El resto fracasó o se retiró. 67 de 325 enfrentaron reconfirmación, o el 20,6%. Actualmente tenemos 1.109 administradores. Si ocurrieran las mismas tasas aquí, veríamos a 228 administradores enfrentar una reconfirmación en el primer año de implementación. De ellos, 41 tendrían éxito. Perderíamos 187 administradores, o aproximadamente el 16.8% de nuestros administradores. Si miramos esto desde la perspectiva de los administradores activos; actualmente tenemos 498 administradores activos ( [11] ). De este organismo perderíamos 84 administradores activos. Este sería el mayor éxito para nuestro grupo de administradores desde 2011 ( Wikipedia: Desysoppings_by_month ). Los que perdieron su granito de arena con una reconfirmación, bien. Quizás se lo merecerían. Pero, habría ~ 71 administradores que simplemente se alejarían en lugar de lidiar con una reconfirmación. - Hammersoft ( charla ) 02:50, 16 de marzo de 2021 (UTC)
- ¿Cuántos administradores fueron eliminados de la Wikipedia en alemán a través del proceso de la comunidad y por qué razones, alguien lo sabe? ProcrastinationReader ( charla ) 01:20, 16 de marzo de 2021 (UTC)
- Dejando de lado los administradores que fallaron en la reconfirmación, 21 de ellos eligieron retirarse (de los cuales estoy seguro de que más de unos pocos habrían fallado en la reconfirmación si hubieran pasado por ella) de 325 no es 1/3 de los administradores. Tampoco es tan importante en el gran esquema de las cosas. A menos que me diga que la comunidad de Wikipedia en inglés no puede encontrar 10 o 15 nuevos administradores para compensar la caída. Si no puede, entonces la plataforma tiene problemas mucho mayores que los que causaría este RfC, si es que causa alguno en primer lugar. Por lo tanto, mantengo el mensaje "No podemos hacer esto porque perderemos administradores", que es principalmente un comentario que infunde miedo. Por cierto, no voy a incluir los que la Wikipedia alemana perdió debido al fracaso del proceso de confirmación. Ya que estoy seguro de que algunos de ellos merecían ser desocupados y no tengo ganas de entrar en una discusión sobre cuántos lo hicieron o no. - Adamant1 ( charla ) 04:08, 16 de marzo de 2021 (UTC)
- Adamant1 , sigo, ahora que he visto esas estadísticas nuevamente, primero puede poner un obstáculo antes y erosionarlo si es demasiado restrictivo, o puede apostar y perder muchas de ellas (como está la propuesta actual).
- Evitas el 'pero se lo merecen', pero surge una pregunta: ¿cuántos de los reelegidos son WP: UNBLOCKABLES ? Dirk Beetstra T C 04:35, 16 de marzo de 2021 (UTC)
- O puede apostar (pero no realmente) y no perder muchos de ellos, porque en última instancia, un punto de datos de una Wiki completamente diferente con sus propios problemas no es evidencia lo suficientemente definitiva como para decir que habrá una caída lo suficientemente grande como para que mueva el proyecto. pararse. Cuál fue la presunción original al respecto. No solo que algunos administradores se irán porque no quieren que se les vuelva a confirmar, sino que será suficiente para finalmente destruir el proyecto o hacerlo inmanejable. Que es principalmente donde entra en juego el miedo. De todos modos, he leído la mayor parte de la discusión aquí y no he visto a un solo administrador comprometerse a deshacerse de sí mismos si tienen que ser confirmados nuevamente. De los administradores que han "votado" hasta ahora que he visto que ninguno de ellos ha dicho nada remotamente en ese sentido. Siempre podríamos hacer una encuesta paralela de RfC preguntando cuántos administradores se comprometen a deshacerse de sí mismos si esto se aprueba, pero entonces yo no llamaría eso definitivo y tampoco deberíamos ser rehenes de un supervoto de administradores en represalia. - Adamant1 ( conversación ) 05:01, 16 de marzo de 2021 (UTC)
- Creo que estás eligiendo lo que quieres ver. Las cifras muestran que 97 de 325 han sido retirados de la administración. Eso es ~ 30%. Ok, no es el 33%, entonces es técnicamente correcto, no es 1/3. Veo perder 84 administradores activos como un impacto catastrófico en el proyecto. Tu no. Se han señalado varios ejemplos de proyectos que fracasan por falta de administradores. No ve esto como un problema. Hago. Varias cosas de este proyecto ya están muy atrasadas. No ve esto como un problema. Hago. Y ya que preguntaste; si tuviera que pasar por una reconfirmación, renunciaría en lugar de ejecutar el proceso. Eso no es represalia, aunque imagino que lo interpretará de esa manera. Soy voluntario aquí. No voy a someterme a una flagelación pública para poder eliminar algo. No es tan interesante. También soy voluntaria en un banco de alimentos. Si tuviera que soportar una flagelación pública para ser voluntario allí, no lo haría. Encontraría otro lugar para hacer voluntariado. En este punto, estamos hablando entre nosotros. Estás convencido de que esto funcionará y yo estoy convencido de que no. Me atrevo a decir que su opinión al respecto no me convence de la veracidad de su opinión, ni la mía la suya. Hemos terminado. Gracias y buena suerte. - Hammersoft ( charla ) 06:09, 16 de marzo de 2021 (UTC)
- Al menos en lo que respecta a la discusión en la que he estado involucrado contigo, tu tema principal de conversación ha sido sobre los administradores que potencialmente se desalojarán a sí mismos debido a esto si se aprueba, no solo "perder administradores", y he sido bastante claro que Solo hablo de eso y no de los que dejarán el proyecto por no ser re-confirmados. Nunca negué que podría ser el 30% del total de administradores perdidos, pero no me importa el porcentaje de administradores que se pierden si se lo merecen. Su argumento parece ser que estaría bien si se quedara con el 30% de los administradores sin importar cómo se hayan comportado o cuál sea la opinión de la comunidad, simplemente porque el proyecto necesita administradores. Lo cual es una lógica inherentemente defectuosa y solo permite un comportamiento inapropiado. Personalmente, y digo esto como alguien que ha sido administrador de otros sitios antes, no veo nada malo en eliminar personas que deberían eliminarse. El hecho de que considere cualquier tipo de escrutinio público del comportamiento de un administrador más allá de las pocas personas que deciden los resultados en ArbCom como una flagelación pública o piensa que los administradores de alguna manera deberían estar por encima de esas cosas mientras que los editores generales no deberían (al mismo tiempo, usted dice los administradores no son "privilegiados" en absoluto) es exactamente la razón por la que estamos "hablando entre nosotros". Estoy presentando un argumento justo, racional y basado en la evidencia de por qué esto debería aprobarse. Mientras que todo lo que haces es apelar a la emoción y tratar de echar a pique las cosas "porque la Wikipedia alemana". No estoy aquí para convencer a gente como tú. Realmente me importa un bledo cuál es tu opinión, porque no se basa en la realidad y no tiene ningún sentido. Que es exactamente la razón por la que nunca refutó directamente nada de lo que dije o se molestó en plantear una alternativa racional a esto además del status quo. No tienes uno que no esté haciendo lo mismo de siempre y lamentándose con nostalgia por los buenos viejos tiempos de la administración. Entonces, claramente no hay nada que discutir. Además, estoy bastante seguro de que el lugar en el que trabaja como voluntario revisa su desempeño de vez en cuando. Si no está dispuesto a hacer lo mismo aquí, en mi opinión. Eres exactamente el tipo de persona que estoy diciendo que este proyecto no debería ser rehén. Adamant1 ( conversación ) 07:37, 16 de marzo de 2021 (UTC)
- O puede apostar (pero no realmente) y no perder muchos de ellos, porque en última instancia, un punto de datos de una Wiki completamente diferente con sus propios problemas no es evidencia lo suficientemente definitiva como para decir que habrá una caída lo suficientemente grande como para que mueva el proyecto. pararse. Cuál fue la presunción original al respecto. No solo que algunos administradores se irán porque no quieren que se les vuelva a confirmar, sino que será suficiente para finalmente destruir el proyecto o hacerlo inmanejable. Que es principalmente donde entra en juego el miedo. De todos modos, he leído la mayor parte de la discusión aquí y no he visto a un solo administrador comprometerse a deshacerse de sí mismos si tienen que ser confirmados nuevamente. De los administradores que han "votado" hasta ahora que he visto que ninguno de ellos ha dicho nada remotamente en ese sentido. Siempre podríamos hacer una encuesta paralela de RfC preguntando cuántos administradores se comprometen a deshacerse de sí mismos si esto se aprueba, pero entonces yo no llamaría eso definitivo y tampoco deberíamos ser rehenes de un supervoto de administradores en represalia. - Adamant1 ( conversación ) 05:01, 16 de marzo de 2021 (UTC)
- Dejando de lado los administradores que fallaron en la reconfirmación, 21 de ellos eligieron retirarse (de los cuales estoy seguro de que más de unos pocos habrían fallado en la reconfirmación si hubieran pasado por ella) de 325 no es 1/3 de los administradores. Tampoco es tan importante en el gran esquema de las cosas. A menos que me diga que la comunidad de Wikipedia en inglés no puede encontrar 10 o 15 nuevos administradores para compensar la caída. Si no puede, entonces la plataforma tiene problemas mucho mayores que los que causaría este RfC, si es que causa alguno en primer lugar. Por lo tanto, mantengo el mensaje "No podemos hacer esto porque perderemos administradores", que es principalmente un comentario que infunde miedo. Por cierto, no voy a incluir los que la Wikipedia alemana perdió debido al fracaso del proceso de confirmación. Ya que estoy seguro de que algunos de ellos merecían ser desocupados y no tengo ganas de entrar en una discusión sobre cuántos lo hicieron o no. - Adamant1 ( charla ) 04:08, 16 de marzo de 2021 (UTC)
- Sin Adamant1, no se trata de infundir miedo. Los datos que se muestran son para nuevos RfA, no para administradores retirados / reconfirmados. Este conjunto de datos no puede mostrar o refutar una correlación, ni debe hacerse ningún intento de hacerlo con él. Simplemente no es relevante. - Hammersoft ( charla ) 01:10, 16 de marzo de 2021 (UTC)
- Al observar el gráfico, parece que la Wikipedia de Alemania no perdió administradores a un ritmo diferente después de que se aprobó la política en ese momento. Así que aparentemente no tuvo ningún efecto en la tasa de declive y la opinión de que sí lo hizo es básicamente una propaganda del miedo. Cuál es mi suposición. En todo caso, parece que la cantidad de administradores que se perdieron con el tiempo disminuyó después de su aprobación. Aunque, obviamente, el número de administradores no ha aumentado desde entonces, pero de todos modos no aumentó. Por tanto, es evidente que se trata de cuestiones independientes que deberían tratarse como tales. Mientras tanto, sin embargo, existe una clara correlación cero entre el paso de cosas como esta y la pérdida de administradores. - Adamant1 ( charla ) 00:56, 16 de marzo de 2021 (UTC)
Eso podría ser un poco extremo. Los administradores que fallarán la reconfirmación se clasifican en tres grupos. "Manzanas podridas" que soportan todo el proceso y fracasan (o que renuncian un poco antes de que quede muy claro que fracasarán). "Divas" que serían reconfirmadas si se quedan hasta el final, pero renuncian al principio del proceso porque creen que está por debajo de ellas. Y los "humanos" que renuncian en algún momento en el que preferirían que se les quitara la administración antes que pasar por un proceso estresante similar al de la RfA.
Estoy de acuerdo en que las manzanas podridas deben ser expulsadas, ya sea el 1% o el 50% de los administradores activos. Las divas son sospechosas en cuanto al temperamento, pero algunas pueden ser administradores decentes en promedio; sin embargo, especulo que las divas no son una fracción significativa del cuerpo administrativo, debido a la ausencia de cualquier comentario anterior como "Si esto pasa, no esperen que yo lo pase". Perder a los humanos es negativo, pero está la cuestión de cuántos hay de nuevo (todos pasaron por RfA-hell en algún momento, y por lo que veo, los administradores que se quedan tienden a volverse más duros con la edad en lugar de más suaves). Tigraan Haga clic aquí para contactarme 15:38, 22 de marzo de 2021 (UTC)
Cuando la wikipedia alemana lanzó su sistema de desysop comunitario, perdieron rápidamente algo así como 1/3 de su cuerpo administrativo
; esto parece ser incorrecto, Hammersoft , como ya había calculado en Special: Diff / 1009704874/1009708189 el 1 de marzo.Las cifras muestran que 97 de 325 han sido retirados de la administración.
Supongo que "97" es "44 + 33 + 20" de Wikipedia: Administrators / RfC_for_binding_administrator_recall # Statistics_from_German_Wikipedia . Sin embargo, esto es "De 2009 a febrero de 2015" y, por lo tanto, probablemente no "de 325". Esta estadística se desglosa por el número de RpA exitosas desde 2009 hasta febrero de 2015, ya que una parte de los "97" probablemente haya sido elegida después de la introducción del proceso e incluso puede incluir a la misma persona varias veces. Se puede encontrar una tabla de todos los RfA, exitosos o no, en de: Wikipedia: Adminkandidaturen / Statistik . Todas estas estadísticas son de dudosa utilidad para evaluar la propuesta de enwiki, ya que el procedimiento dewiki también se utiliza para tratar con administradores inactivos que nunca hicieron nada malo.- Se puede encontrar un gráfico del recuento de administradores de dewiki a lo largo del tiempo en [12] . No puedo ver el supuesto "impacto catastrófico" que se supone que ocurrió en o poco después de 2009. No está en el gráfico. Además, dewiki no parece haberse roto irreparablemente, mirándolo hoy y teniendo en cuenta que el proceso de desysop (bueno, en funcionamiento) todavía está en su lugar. ~ ToBeFree ( hablar ) 18:45, 28 de marzo de 2021 (UTC)
- Con respecto a
"Si miramos esto desde la perspectiva de los administradores activos; actualmente tenemos 498 administradores activos (...). De este organismo, perderíamos 84 administradores activos".
- no, esto tampoco es correcto. Supone incorrectamente que no existe una correlación entre la inactividad y los retiros, lo cual es incorrecto tanto para la situación dewiki como para la propuesta enwiki. Esta es una mala interpretación de una estadística dewiki, una aplicación incorrecta de la estadística a enwiki, seguida de otra falacia lógica. Tres errores seguidos; resultado sin sentido. ~ ToBeFree ( hablar ) 19:34, 28 de marzo de 2021 (UTC)
- Con respecto a
- Bastante justo para tu opinión. Respetuosamente, no estoy de acuerdo con sus conclusiones. - Hammersoft ( charla ) 02:09, 29 de marzo de 2021 (UTC)
- @ Hammersoft : Dejando de lado las "opiniones", ¿cómo es que la tasa de RpA exitosas desciende exactamente a la misma tasa después de que la política se aprueba en la Wikipedia de Alemania que antes de la política? si la política hubiera hecho alguna diferencia, pensaría que la tasa de RfAs que tuvo éxito habría cambiado, pero claramente no fue así. Si bien eso significa que no facilitó las RfA, tampoco las hizo más difíciles. Cuál es mi principal problema con sus afirmaciones al respecto. La póliza tuvo efecto cero y usted trata el efecto cero como si fuera negativo cuando no lo fue. En mi opinión, si algo tiene un efecto nulo, es evidente que algo más debe cambiar antes de este tipo de políticas. Sin embargo, eso no significa que debamos tirar al bebé con agua de baño. Dado que el propósito de esta política es hacer que los administradores actuales sean más fácilmente responsables ante la comunidad. No reclutar más administradores. Sin embargo, por la razón que sea, usted y las otras personas que comparten sus "opiniones" al respecto están confundiendo los dos. - Adamant1 ( conversación ) 03:11, 29 de marzo de 2021 (UTC)
- Todo lo que sé es que he sido administrador durante nueve años y medio, y si todas las personas que pierden la cabeza por el estatus de administradores tuvieran acceso gratuito al mítico "poder" que poseemos, exigirían un reembolso. Esto no es como Earthsea, donde tras una exitosa RfA una bruja te quita el nombre de tu infancia y tienes que encontrar el camino desnudo hacia un mago que te dará un nuevo nombre imbuido de poder mágico. En serio, pensarías que esto es acceso al fútbol nuclear o algo así; solo considere cuántos electrones está dispuesto a matar a sangre fría para lograr su objetivo, y cuántos realmente está ahorrando al final, luego averigüe si honestamente vale la pena. Ahora volvamos al trabajo voluntario real de ser administrador. La espada de la aurora boreal (話 し て 下 さ い) 01:13, 7 de abril de 2021 (UTC)
- Re: su resumen de edición ("¿La gente aquí realmente entiende lo que hacen los administradores?"): Una de las cosas que hacen los administradores es decidir quién no puede editar . Otra cosa que hacen los administradores es decidir qué no se puede editar . Cuando algunos administradores hacen estas cosas de una manera que a la gente no le gusta, la gente quiere poder quitarles los privilegios de esos administradores. Algunas personas piensan que el proceso para hacer eso no debería limitarse a arbcom . Que lo crean no significa que no entiendan lo que hacen los administradores o que no lo aprecien. Levivich acoso / sabueso 03:44, 7 de abril de 2021 (UTC)
- Gracia divina. "Cuando algunos administradores hacen estas cosas de una manera que a la gente no le gusta, la gente quiere poder quitarles los privilegios de los administradores". No importa que el administrador haya actuado dentro de las reglas y en el mejor interés de wiki. Si molestan a alguien a quien no le gusta la forma en que actuó el administrador, ese alguien quiere el derecho de despedir al administrador. No creo que lo digas en serio. Moriori ( charla ) 04:00, 7 de abril de 2021 (UTC)
- Entonces, si no puede eliminar a un administrador porque, digamos, cien administradores veteranos y mil usuarios veteranos ya no quieren que sean administradores, pero también les exige que rompan algún tipo de "un administrador nunca puede hacer esto y seguir siendo una regla de administrador, entonces necesita un grupo de editores experimentados elegidos por la comunidad por su capacidad para determinar si un administrador ha violado o no esas reglas. En otras palabras, Arbcom. Tiene que haber un punto en el que si has cabreado a suficientes personas con la forma en que usas las herramientas, te las quitamos. La única pregunta es qué tan alto deberíamos poner el listón. - Guy Macon ( charla ) 04:41, 7 de abril de 2021 (UTC)
Los grupos de editores experimentados
son definitivamente una mejora del hoi polloi autoseleccionado de WP: AN (I). Pero no es necesario que sea ArbCom. - Ryk72 talk 05:30, 7 de abril de 2021 (UTC)
- Entonces, si no puede eliminar a un administrador porque, digamos, cien administradores veteranos y mil usuarios veteranos ya no quieren que sean administradores, pero también les exige que rompan algún tipo de "un administrador nunca puede hacer esto y seguir siendo una regla de administrador, entonces necesita un grupo de editores experimentados elegidos por la comunidad por su capacidad para determinar si un administrador ha violado o no esas reglas. En otras palabras, Arbcom. Tiene que haber un punto en el que si has cabreado a suficientes personas con la forma en que usas las herramientas, te las quitamos. La única pregunta es qué tan alto deberíamos poner el listón. - Guy Macon ( charla ) 04:41, 7 de abril de 2021 (UTC)
- Gracia divina. "Cuando algunos administradores hacen estas cosas de una manera que a la gente no le gusta, la gente quiere poder quitarles los privilegios de los administradores". No importa que el administrador haya actuado dentro de las reglas y en el mejor interés de wiki. Si molestan a alguien a quien no le gusta la forma en que actuó el administrador, ese alguien quiere el derecho de despedir al administrador. No creo que lo digas en serio. Moriori ( charla ) 04:00, 7 de abril de 2021 (UTC)
- Re: su resumen de edición ("¿La gente aquí realmente entiende lo que hacen los administradores?"): Una de las cosas que hacen los administradores es decidir quién no puede editar . Otra cosa que hacen los administradores es decidir qué no se puede editar . Cuando algunos administradores hacen estas cosas de una manera que a la gente no le gusta, la gente quiere poder quitarles los privilegios de esos administradores. Algunas personas piensan que el proceso para hacer eso no debería limitarse a arbcom . Que lo crean no significa que no entiendan lo que hacen los administradores o que no lo aprecien. Levivich acoso / sabueso 03:44, 7 de abril de 2021 (UTC)
- ¿No son los administradores quienes finalmente cierran y deciden los resultados de las quejas en WP: AN (I) (especialmente WP: AN) de todos modos? Entonces, ¿cómo es eso un " hoi polloi auto-seleccionado " fuera de las personas al azar que dan sus opiniones (generalmente ignoradas junto con la queja de ANI en sí) y exactamente cuál es el problema con las "personas que dicen cosas" a los administradores (o sobre ellos)? Especialmente porque el estándar no se aplica a nadie más y hay una posibilidad extremadamente pequeña de que surja algo de una queja de ANI para un administrador de la forma en que esta propuesta es de todos modos. Excepto tal vez un montón de aire caliente cuando alguien presenta una queja ANI. Lo cual, en mi opinión, sería mejor que cómo están las cosas ahora. Un buen porcentaje de las personas que están en contra de esto parecen querer las dos cosas donde no hay nada especial en ser administrador, pero luego esperan que sean tratados de una manera especial al no tener que pasar por los procesos normales, poniendo especial cuidado. en no herir sus sentimientos y en no quejarse de su comportamiento o hablar de ellos. - Adamant1 ( charla ) 05:37, 7 de abril de 2021 (UTC)
- Si esta fue una respuesta a mi comentario anterior, como sugeriría la sangría, entonces, desafortunadamente, no pude analizarlo por completo. Pueden ser los administradores los que realicen una proporción significativa de los cierres en WP: AN (I); pero esos cierres deben reflejar el consenso de la discusión y, por lo tanto, dependen al menos en parte de las opiniones presentadas en la discusión; particularmente cuando se somete a votación una sanción particular. No estoy de acuerdo en que generalmente se ignoren las opiniones; ni que sean generalmente de personas al azar - que es donde entra en juego el tema de la autoselección. Un problema con la toma de decisiones por consenso en los grupos autoseleccionados es que se puede hacer brigada para tomar una acción; o en brigada a la inacción. No tengo ningún problema con que la gente le diga cosas (o sobre) a los administradores, y he sido muy crítico con una serie de decisiones de los administradores (tanto individuales como en conjunto) a lo largo de mi tiempo aquí. Estoy de acuerdo que
Existe una posibilidad extremadamente pequeña de que surja algo de una queja de ANI para un administrador de la forma en que esta propuesta es de todos modos
y ver esto como una falla crítica de la propuesta. No soy miembro del grupo de personas descrito en la última oración. - Ryk72 talk 01:48, 9 de abril de 2021 (UTC)
- Si esta fue una respuesta a mi comentario anterior, como sugeriría la sangría, entonces, desafortunadamente, no pude analizarlo por completo. Pueden ser los administradores los que realicen una proporción significativa de los cierres en WP: AN (I); pero esos cierres deben reflejar el consenso de la discusión y, por lo tanto, dependen al menos en parte de las opiniones presentadas en la discusión; particularmente cuando se somete a votación una sanción particular. No estoy de acuerdo en que generalmente se ignoren las opiniones; ni que sean generalmente de personas al azar - que es donde entra en juego el tema de la autoselección. Un problema con la toma de decisiones por consenso en los grupos autoseleccionados es que se puede hacer brigada para tomar una acción; o en brigada a la inacción. No tengo ningún problema con que la gente le diga cosas (o sobre) a los administradores, y he sido muy crítico con una serie de decisiones de los administradores (tanto individuales como en conjunto) a lo largo de mi tiempo aquí. Estoy de acuerdo que
- ¿No son los administradores quienes finalmente cierran y deciden los resultados de las quejas en WP: AN (I) (especialmente WP: AN) de todos modos? Entonces, ¿cómo es eso un " hoi polloi auto-seleccionado " fuera de las personas al azar que dan sus opiniones (generalmente ignoradas junto con la queja de ANI en sí) y exactamente cuál es el problema con las "personas que dicen cosas" a los administradores (o sobre ellos)? Especialmente porque el estándar no se aplica a nadie más y hay una posibilidad extremadamente pequeña de que surja algo de una queja de ANI para un administrador de la forma en que esta propuesta es de todos modos. Excepto tal vez un montón de aire caliente cuando alguien presenta una queja ANI. Lo cual, en mi opinión, sería mejor que cómo están las cosas ahora. Un buen porcentaje de las personas que están en contra de esto parecen querer las dos cosas donde no hay nada especial en ser administrador, pero luego esperan que sean tratados de una manera especial al no tener que pasar por los procesos normales, poniendo especial cuidado. en no herir sus sentimientos y en no quejarse de su comportamiento o hablar de ellos. - Adamant1 ( charla ) 05:37, 7 de abril de 2021 (UTC)
- @ La espada de la aurora boreal : Si estamos en el reino de la fantasía, dudo que el mago Yevaud esté demasiado preocupado por los conserjes de la Fundación Enciclopedia. En el ámbito de la realidad, mi pregunta es para @ Guy Macon : - ¿Este proceso habría sido mejor que lo que acaba de suceder para RexxS o Carlossuarez46? Usuario: 力(power ~ enwiki, π , ν ) 18:06, 8 de abril de 2021 (UTC)
- Desconocido. No puedo evaluar un proceso que no ha sido definido, y si lo que escribí en Wikipedia: Solicitudes de comentario / Política Desysop (2021) #The Elephant In The Room es correcto, es imposible en este momento o en cualquier momento próximo definir un política de desysop de la comunidad. No nos hemos puesto de acuerdo (o realmente discutimos, no es que discutir tales detalles no es una pérdida de tiempo colosal) preguntas tan básicas como "¿Puede Arbcom invalidar a la comunidad?", "¿Puede la comunidad invalidar a Arbcom?", "¿Puede el W "¿F anular ambos y salirse con la suya sin que la junta anule una vez más la W? F?" - Guy Macon ( charla ) 19:09, 8 de abril de 2021 (UTC)
- Mi punto principal es que, dado lo absolutamente mundano que es el abrumador número de tareas reales que realiza un administrador de Wikipedia, no creo que la gente se asuste hasta tal punto; No bromeo cuando digo que la mayoría de las personas que lo experimentan gratis todavía querrían un reembolso. ¿Quiénes son estos administradores sin nombre hasta ahora que están quemando mierda y aún no están frente a ArbCom? Específicamente no voté porque no sé cuál es la respuesta correcta, pero sé que ArbCom destituirá a la gente por una causa y que no veo muchos casos rechazados al respecto. La espada de la aurora boreal (話 し て 下 さ い) 04:18, 9 de abril de 2021 (UTC)
- @ La espada de la aurora boreal : Si estamos en el reino de la fantasía, dudo que el mago Yevaud esté demasiado preocupado por los conserjes de la Fundación Enciclopedia. En el ámbito de la realidad, mi pregunta es para @ Guy Macon : - ¿Este proceso habría sido mejor que lo que acaba de suceder para RexxS o Carlossuarez46? Usuario: 力(power ~ enwiki, π , ν ) 18:06, 8 de abril de 2021 (UTC)
- ¿Quién dice que el único estándar para cuando un administrador debe ser desocupado o disciplinado es si están "quemando mierda hasta los cimientos"? Hay muchas formas más sutiles y corrosivas en las que los administradores pueden comportarse, que no necesariamente justificarían o valdrían la pena llevarlos a Arbcom y "quemar mierda hasta los cimientos", pero aún así pueden justificar una queja en alguna parte. Lo que supongo que significaría denunciarlos a ANI (AN) y actualmente no podemos hacer con ningún tipo de utilidad. Por ejemplo, algo como un bloqueo temporal de los privilegios de un administrador o una palmada comunitaria en la muñeca serían formas perfectamente razonables de poner en jaque a un administrador más mal comportamiento de bajo nivel si es necesario, pero nadie va a pasar por un 2 mes proceso Arbcom solo para hacer cualquiera. En última instancia, esto no debería ser un todo o nada. Donde lo único es un bloque completo de privilegios de administrador a través de Arbcom debido a "quemar mierda hasta el suelo", o todo lo demás es una forma aceptable de comportarse y no hay forma de tratar con administradores fuera de Arbcom. - Adamant1 ( charla ) 00:29, 11 de abril de 2021 (UTC)
- ¿Y dónde contiene esta propuesta alguno de los remedios que sugiere? Lo que está describiendo suena como un proceso completamente diferente, uno que no sería afirmado ni rechazado en este RfC. Y hay que decirlo, sea o no ArbCom la solución ideal aquí, en sus últimas acciones han demostrado que, al menos en algunas circunstancias, actuarán sin un caso prolongado de 2 meses. La espada de la aurora boreal ( 話 し て 下 さ い) 05:17, 11 de abril de 2021 (UTC)
- Dos cosas
- ¿Y dónde contiene esta propuesta alguno de los remedios que sugiere? Lo que está describiendo suena como un proceso completamente diferente, uno que no sería afirmado ni rechazado en este RfC. Y hay que decirlo, sea o no ArbCom la solución ideal aquí, en sus últimas acciones han demostrado que, al menos en algunas circunstancias, actuarán sin un caso prolongado de 2 meses. La espada de la aurora boreal ( 話 し て 下 さ い) 05:17, 11 de abril de 2021 (UTC)
- ¿Quién dice que el único estándar para cuando un administrador debe ser desocupado o disciplinado es si están "quemando mierda hasta los cimientos"? Hay muchas formas más sutiles y corrosivas en las que los administradores pueden comportarse, que no necesariamente justificarían o valdrían la pena llevarlos a Arbcom y "quemar mierda hasta los cimientos", pero aún así pueden justificar una queja en alguna parte. Lo que supongo que significaría denunciarlos a ANI (AN) y actualmente no podemos hacer con ningún tipo de utilidad. Por ejemplo, algo como un bloqueo temporal de los privilegios de un administrador o una palmada comunitaria en la muñeca serían formas perfectamente razonables de poner en jaque a un administrador más mal comportamiento de bajo nivel si es necesario, pero nadie va a pasar por un 2 mes proceso Arbcom solo para hacer cualquiera. En última instancia, esto no debería ser un todo o nada. Donde lo único es un bloque completo de privilegios de administrador a través de Arbcom debido a "quemar mierda hasta el suelo", o todo lo demás es una forma aceptable de comportarse y no hay forma de tratar con administradores fuera de Arbcom. - Adamant1 ( charla ) 00:29, 11 de abril de 2021 (UTC)
- 1. Esta propuesta es para que alguien pueda usar "medios normales" para solicitar que un administrador sea desocupado por mal comportamiento. Asumiría que cualquier resultado de la solicitud que no sea su desobediencia sería una palmada en la muñeca. Ya sea uno real o uno que sea solo el resultado del escrutinio público de su mal comportamiento. En los tres casos, serviría para disminuir dicho mal comportamiento y no veo evidencia que demuestre lo contrario. Light es el mejor blanqueador o lo que sea
- La forma actual de solo poder plantear problemas con los administradores en su página de discusión o a través de ArbCom no hace nada para alterar a los administradores que se portan mal. En mi experiencia, actúan con desdén sobre las quejas porque saben que la única opción es ArbCom. Por lo que la mayoría de la gente no pasará, especialmente para cosas de nivel inferior. Nuevamente, no veo evidencia de lo contrario.
- Siéntase libre de señalar una queja de ANI (AN) sobre un administrador donde fueron disciplinados, asumieron la responsabilidad por su mal comportamiento, de lo contrario, hubo consecuencias para un administrador por cualquier cosa. Y mucho menos dónde sucedió algo de eso solo a través de una discusión en su página de discusión. Incluso si puede, tengo alrededor de 100 ejemplos de contador (que no se puede decir de usuarios "normales" por cierto). Sin embargo, el hecho es que el hecho de que esto no resulte en la desobediencia de un administrador todo (o la mayor parte) del tiempo, no significa que no se beneficiará o mejorará el nivel generalmente alto de toxicidad en esta plataforma. Algunos de los cuales, sin duda alguna, provienen de administradores.
- 2. El hecho de que ArbCom no pase por un proceso de 2 meses en "algunas circunstancias" no significa que sea una forma completamente efectiva de tratar con los administradores, que no hay cosas que podrían tratarse mejor fuera de la participación de ArbCom. , o eso no está dentro de su punto de vista para tratar en primer lugar.
- Además, mucha gente no sabe qué es ArbCom en primer lugar, y mucho menos cómo informar a un administrador. Además, la mayoría de la gente tampoco quiere denunciar a un administrador ante ArbCom. Pero sí saben qué es ANI (AN), cómo usarlo, y estarían más dispuestos a reportar un administrador a ANI (AN) si tuvieran la opción de hacerlo. Yo mismo he estado en la situación en la que habría reportado a un administrador a ANI si hubiera resultado en algo, pero no pensé que valiera la pena llevarlo a ArbCom (y simplemente no quería tratar con el proceso ArbCom). He recibido más de un mensaje de otras personas que han estado en la misma situación. Por lo tanto, existe una clara necesidad de una opción fuera de ArbCom para tratar con los administradores y no son completamente efectivos. Adamant1 ( charla ) 02:00, 12 de abril de 2021 (UTC)