Según el usuario: Izno , los 'crats' pueden otorgar derechos de administrador de interfaz, pero esta página no menciona eso en ningún lugar que yo pueda ver fácilmente. Lo habría arreglado yo mismo directamente, pero no estoy muy familiarizado con los permisos ni las implicaciones. ~ 🦝 Shushugah (él/él • discusión ) 23:04, 8 de junio de 2022 (UTC) [ responder ]
- @ Shushugah Es la segunda viñeta de Wikipedia:Burócratas ya; esta página es similar a Wikipedia:Administradores en cuanto a cómo explica las cosas. — xaosflux Discusión 00:31, 9 de junio de 2022 (UTC) [ responder ]
Según mis comentarios en BN, la política actual impone un período de espera sin otorgarles a los burócratas la capacidad de decir que no, ni definir cuándo pueden hacerlo. Para aclarar esa cuestión, propongo agregar el siguiente texto a la política: La solicitud permanecerá abierta durante 48 horas para las solicitudes que se hagan por primera vez y, si existe un consenso de la comunidad en contra de la concesión, los burócratas pueden negarse a conceder el acceso.
No creo que sea necesario un RfC formal, pero no voy a actualizarlo sin iniciar una discusión. TonyBallioni ( discusión ) 00:47 16 jun 2022 (UTC) [ responder ]
- (ver Special:PermaLink/1093342938 ) Debería ser por "al menos" 48 horas, la cantidad de horas no está limitada. Por lo general, estos no reciben mucha publicidad, etc., por lo que no espero que haya un indicador de consenso "comunitario" que deba surgir para derrotarlos en tan poco tiempo. Me gustaría no hacer esto demasiado "burocrático", algo así como si un "crat" tiene inquietudes, entonces debería ocurrir una discusión de consenso adicional/extendida . Mantiene la expectativa de que el valor predeterminado es SÍ, deja una válvula de seguridad, pero en última instancia lo pone en manos de la comunidad. — xaosflux Talk 00:57, 16 de junio de 2022 (UTC) [ responder ]
- Sí, estoy de acuerdo con lo que dices. No creo que hayamos tenido nunca una oposición, ni siquiera por parte de un chiflado, así que vale la pena aclarar que hay una forma de rechazarla, así que creo que al menos deberíamos decir algo relacionado con eso en alguna parte. TonyBallioni ( discusión ) 01:00 16 jun 2022 (UTC) [ responder ]
- Aunque tal vez vaya en contra de mis intereses personales, apoyo tanto la idea básica de la aclaración (los burócratas deberían tener cierta discreción) como la interpretación de Xaosflux. {{ Nihiltres | discusión | ediciones }} 01:27, 16 de junio de 2022 (UTC) [ responder ]
- Hmm, no estoy seguro de que esto sea necesario. La política actual establece:
Todos los editores pueden discutir sobre el solicitante, pero la decisión final recae en el burócrata revisor.
Interpreto que eso significa que los burócratas individuales pueden aceptar o rechazar cualquier solicitud a su discreción, independientemente de lo que piense la comunidad en general (aunque estoy seguro de que los burócratas no ignorarían deliberadamente un consenso claro de la comunidad). Esto es similar a cómo funciona WP:PERM : independientemente de lo que comente la gente, la decisión final sobre las solicitudes la toma el administrador revisor. La redacción propuesta parece restringir la capacidad de los burócratas de rechazar solo a situaciones en las que existe un consenso de la comunidad en contra de la concesión
, por lo que parece que este cambio tendría el efecto de limitar lo que los burócratas pueden hacer actualmente. Mz7 ( discusión ) 01:47, 16 de junio de 2022 (UTC) [ responder ] - Creo que los crats deberían tener la discreción de rechazar una solicitud, ya sea en función de los comentarios de la comunidad o de sus propios hallazgos. Apoyo cualquier cambio o aclaración necesaria para implementar eso. Si resulta que se necesita una RFC, avísenme, ya que no espero ver esta discusión. Thryduulf ( discusión ) 02:00, 16 de junio de 2022 (UTC) [ responder ]
- Creo que la frase "la decisión final recae en el burócrata revisor" es bastante explícita en el sentido de que un burócrata puede conceder o rechazar la solicitud. Y los motivos para rechazarla se dan en la sección Antecedentes. Si un usuario cumple con los criterios: "altamente confiable, tiene al menos un conocimiento básico de JS y CSS, conoce las expectativas de privacidad de los wikis de Wikimedia y tiene un conocimiento decente de cómo proteger sus cuentas", se le concederá el derecho; si no cumple con uno de esos criterios, se le negará el derecho. Existe una discusión sobre si se puede confiar en Nihiltres dado que cometió un error; y el consenso es que se puede confiar en ellos porque corrigieron su error y no han cometido otros. El proceso parece estar funcionando bien. Si las personas desean modificar la redacción para que sea más clara, pueden hacerlo; siempre que no alteren las implicaciones de la redacción, no hay necesidad de buscar consenso. Se podría agregar una redacción como: "Si el consenso es que el administrador no es muy confiable, o no tiene al menos un conocimiento básico de JS y CSS, o no es consciente de las expectativas de privacidad de los wikis de Wikimedia, o no tiene un conocimiento decente de cómo proteger sus cuentas, entonces no se concederá el derecho" para mayor claridad.
- Estoy de acuerdo con Xaosflux en que se debe agregar "al menos" antes de "48 horas". Tal como está, se podría interpretar que después de 48 horas la solicitud se cierra automáticamente y, si la solicitud no se ha concedido, podría pasar a no completarse por defecto, por lo que sería necesario realizar una nueva solicitud. SilkTork ( discusión ) 02:04 16 jun 2022 (UTC) [ responder ]
- ¿Debería decir "conceder si hay consenso" o "no conceder si hay consenso en contra"?
Y si hay consenso en la comunidad en contra de conceder, los burócratas pueden negarse a conceder el acceso.
Podría interpretarse como "los burócratas deben conceder si no hay consenso". Jo-Jo Eumerus ( discusión ) 10:54 16 jun 2022 (UTC) [ responder ]- @ Jo-Jo Eumerus similar a WP:PERM, normalmente no tenemos una discusión de medición de consenso sobre estos temas, el consenso anterior de RfC se inclinaba hacia la "discreción de la crat"; al igual que si rechazo a alguien en WP:PERM , si se llega a un consenso a través de la discusión, algún otro administrador lo haría. — xaosflux Talk 13:40, 16 de junio de 2022 (UTC) [ responder ]
- "la decisión final recae en el burócrata revisor" me parece bastante inequívoco. Parece un elemento normal que recibirías en WP:PERM , con una antelación adicional de al menos 48 horas para que la comunidad comente si hay razones para denegar. Si bien WP:BN no es el lugar con más tráfico, ciertamente recibe suficientes visitas para saber si la comunidad en su conjunto tiene razones para denegar la solicitud. Si el tiempo es un problema importante, que sea una semana. Las solicitudes en WP:PERM solo requieren que el administrador de cierre vea si se puede confiar en el usuario y otros usuarios pueden opinar sobre la solicitud. Aunque,
y si existe un consenso de la comunidad en contra de la concesión, los burócratas pueden negarse a conceder acceso
, esto me sugiere que un burócrata no tendría otra opción que conceder el permiso si no hubiera más discusión al respecto. Lee Vilenski ( discusión • contribuciones ) 11:27, 17 de junio de 2022 (UTC) [ responder ] - Somos voluntarios, por eso siempre tenemos una opción.
- El valor predeterminado es que el derecho se otorgará siempre que no haya objeciones, porque el derecho solía ser parte del conjunto de herramientas de cada administrador. Se decidió (no por la comunidad si mal no recuerdo, sino por WMF) que permitir que todos los administradores, incluidos aquellos designados aleatoriamente por Jimbo en aquel entonces, tengan acceso a la herramienta podría ser problemático. Si bien se consideraría que los administradores designados más recientemente tienen el sentido común de no encender la motosierra si no saben cómo usarla, WMF claramente sospechaba que algunos de los primeros administradores eran idiotas. Como tal, la situación es que un administrador tiene que solicitar la herramienta, y esa solicitud debería ser suficiente en sí misma para disipar cualquier inquietud; sin embargo, solo para estar seguros, hay una retención de 48 horas para que las personas puedan presentarse con evidencia de que el administrador es de hecho un idiota. Si nadie se presenta, simplemente podemos presionar el interruptor (o dejarlo para otra persona si no nos gusta o no entendemos las implicaciones).
- Por política, no se nos permite otorgarnos el derecho, aunque técnicamente podemos hacerlo. Es interesante que se confíe en nosotros lo suficiente como para no otorgarnos el derecho, pero no se confíe en nosotros para otorgarnos el derecho. Supongo que es simplemente un error que se nos haya dejado con la capacidad de otorgarnos el derecho. SilkTork ( discusión ) 13:31 19 jun 2022 (UTC) [ responder ]
- @ SilkTork es principalmente que se necesitan capas adicionales de controles técnicos para agregar también una verificación de "pero no para ti mismo" que realmente no son necesarias: si alguien que otorga acceso no está haciendo nada bueno, podría simplemente dar acceso a una cuenta alternativa y omitir todo el asunto de todos modos. — xaosflux Talk 13:48, 19 de junio de 2022 (UTC) [ responder ]
- Estoy de acuerdo con tu descripción general del proceso: básicamente, si un 'crat' de procesamiento rechaza una solicitud, puede ser una declaración sutil de "es posible que en realidad seas un idiota", que otros 'crats pueden rechazar simplemente otorgándola (especialmente después de algún aporte de la comunidad). — xaosflux Talk 13:50, 19 de junio de 2022 —(UTC)
- Como nota al margen, los desarrolladores de MediaWiki proporcionaron la capacidad, pero dejaron en manos de las comunidades wiki locales la decisión sobre cómo asignar el privilegio (consulte Wikipedia:Village pump (miscellaneous)/Archive 59 § New user group for editing sitewide_CSS/JS y m:Creation of separate user group for editing sitewide_CSS/JS). Todas las decisiones sobre el proceso de concesión fueron tomadas por la comunidad (consulte los archivos de esta página de discusión). isaacl ( discusión ) 16:28, 19 de junio de 2022 (UTC) [ responder ]
- Sabrás más sobre esto que yo, isaacl. Entiendo que el derecho ya existía dentro del conjunto de herramientas de administración, pero que los "desarrolladores de MediaWiki" (no estoy muy seguro de cuál es su posición en el mundo de Wikipedia, pero como son MediaWiki, que es parte de WMF, tiendo a pensar en ellos como parte de WMF en lugar de Wikipedia, aunque creo que es posiblemente un área turbia: ¿algunos desarrolladores son voluntarios y otros son pagados por WMF?) le quitaron el derecho a los administradores de Wikipedia porque decidieron que era un riesgo de seguridad. Entiendo (y corrígeme si me equivoco), es que esto se hizo sin consultar con la comunidad de Wikipedia. Entiendo (y, nuevamente, corrígeme si me equivoco: este no es un área en la que suelo involucrarme) que la comunidad de Wikipedia luego buscó una manera de que se le devolviera el derecho a los administradores, y el consenso fue que el derecho podría ser restaurado mediante una solicitud con una simple pausa de 48 horas para ver si había alguna objeción. Básicamente, cada administrador de Wikipedia podría solicitar el derecho y, a menos que nadie declare que alguno de ellos es idiota, se le podría otorgar. Podríamos, en teoría, restaurar el derecho a cada administrador de Wikipedia en un período de 48 horas. Y, supongo, los "desarrolladores de MediaWiki" (¿WMF?) estarían perfectamente de acuerdo con eso, ya que habríamos seguido el procedimiento acordado de Wikipedia. ¿O sospecha que habría una objeción porque existiría el riesgo de que algunos de los administradores no sean de confianza (por parte de la WMF, ya que supongo que la comunidad confía en ellos, de lo contrario, no seguirían siendo administradores)? SilkTork ( discusión ) 18:13, 20 de junio de 2022 (UTC) [ responder ]
- @ SilkTork tangencialmente relacionado, WMF (los propietarios de los servidores) requieren que cualquiera que quiera ser administrador interno debe usar 2FA, por lo que todos esos administradores tendrían que activarlo primero. — xaosflux Talk 18:52, 20 de junio de 2022 (UTC) [ responder ]
- Si bien no me hubiera sorprendido si este fuera el caso, la única guía que pude encontrar provino de Tgr en su rol como desarrollador de MediaWiki. Hasta donde recuerdo (y como puedo ver en un vistazo rápido al archivo), había consenso en la Wikipedia en inglés para requerir la autenticación de dos factores para los administradores de interfaz, en reconocimiento del poder extremo de poder hacer que Javascript malicioso se ejecute dentro de los navegadores de los usuarios. isaacl ( discusión ) 20:55, 20 de junio de 2022 (UTC) [ responder ]
- La autenticación de dos factores (2FA) es un requisito global para cada proyecto, hay algunos roles que la requieren (consulte el banner en meta:Interface_administrators). — xaosflux Talk 22:21, 20 de junio de 2022 (UTC) [ responder ]
- Gracias por la referencia; para mí tiene sentido. Veo que la nota se agregó en diciembre de 2018, después de que el proceso de concesión hubiera alcanzado un consenso aquí. isaacl ( discusión ) 22:59 20 jun 2022 (UTC) [ responder ]
- La página meta a la que hice referencia tiene enlaces a la discusión correspondiente de la lista de correo de wikitech y el ticket de Phabricator. Hasta donde sé, Tgr creó la función por iniciativa propia para mejorar la seguridad, lo que implicó crear un nuevo privilegio de usuario (que sí, hizo posible evitar que los administradores editaran las páginas de Javascript y CSS de todo el sitio). Es cierto que los desarrolladores de MediaWiki consideraron que la implementación era de su competencia, como un asunto de seguridad, y por eso solo llevaron a cabo lo que en esencia fue una consulta consultiva sobre meta. Wikipedia talk:Interface administrators/Archive 2 § RfC: Approving the updated proposal tiene la discusión de Wikipedia en inglés para el proceso final (que reemplaza el proceso provisional, que la comunidad puso en marcha para garantizar que alguien pudiera editar las páginas en el ámbito de aplicación durante el período interino) que, como usted dijo, aprobó un proceso en el que "los burócratas están autorizados" a otorgar el permiso de administrador de interfaz a pedido después de un período de espera de 48 horas. Quien sea responsable de la seguridad en la WMF puede tener opiniones, pero hasta donde sé, la comunidad sigue siendo libre de decidir por sí misma sobre el proceso. isaacl ( discusión ) 21:32 20 jun 2022 (UTC) [ responder ]
- Esto parece correcto (tanto la propuesta original como el "al menos" por el momento). Parece innecesario dar más detalles que los requeridos, pero TB tiene razón en que es mejor tener un "por qué necesitamos esto" que discutir los cambios al mismo tiempo que se resuelve el problema. Nosebagbear ( discusión ) 12:34 24 jun 2022 (UTC) [ responder ]
- Estoy de acuerdo con el cambio propuesto en la redacción de la política para mayor claridad; no veo ningún problema en aclarar los detalles si parecen ambiguos, y agregar una cláusula WP:SNOW a la redacción de la política parece razonable. Estoy de acuerdo con lo que Nosebagbear afirmó anteriormente, en el sentido de que "[m]ás detalles más allá de los requeridos parecen innecesarios, pero TB tiene razón en que [es] mejor tener un 'por qué necesitamos esto'". ~Oshwah~ (discusión) (contribuciones) 02:52, 4 de julio de 2022 (UTC) [ responder ]
- La siguiente discusión es un registro archivado de una solicitud de comentarios . No la modifique. No se deben realizar más modificaciones a esta discusión. A continuación se incluye un resumen de las conclusiones a las que se llegó.
Existe
un consenso claro para aumentar el requisito de inactividad a 12 meses. Como resultado, a los administradores de interfaz que no hayan realizado ediciones ni otras acciones registradas durante al menos 2 meses, o que no hayan realizado ediciones utilizando el permiso durante al menos 12 meses, se les debería quitar su derecho de usuario. Aquellos que se opusieron a este cambio argumentaron que el nivel de inactividad actual es suficiente, citando la naturaleza sensible del permiso y su facilidad de restauración a través de una solicitud en
WP:BN .
( cierre no administrativo ) –
DreamRimmer (
discusión ) 02:30, 29 de febrero de 2024 (UTC)
[ responder ]
Propuesto:
En: A los administradores de interfaz que no hayan realizado ediciones ni hayan registrado otras acciones durante al menos 2 meses o que no hayan realizado ediciones utilizando el permiso durante al menos 6 meses se les debe quitar el derecho de usuario.
- Cambiar a
los administradores de interfaz que no han realizado ediciones ni otras acciones registradas durante al menos 2 meses o que no han realizado ediciones utilizando el permiso durante al menos
6 meses12 mesesDebería eliminarse el derecho de usuario.
Discusión reciente: Especial:PermaLink/1200817440
Razonamiento propuesto: las acciones de los administradores de interfaz no son muy numerosas, pero en general son productivas. Para los editores que aún están activos en general, pero tienen actualizaciones de interfaz menos frecuentes, hacer que tengan que volver a solicitarlas cuando sea necesario es contraproducente. Actualmente tenemos <10 administradores de interfaz y no se espera que este cambio nos haga tener "demasiados", ya que el umbral de inactividad total sigue siendo bajo. — xaosflux Talk 11:23, 30 de enero de 2024 (UTC) [ responder ]
Apoyo
- Tal como se propuso. — xaosflux Discusión 11:23 30 enero 2024 (UTC) [ responder ]
- No tengo ningún problema con el cambio propuesto. El requisito de los dos meses también podría considerarse innecesariamente estricto — Martin ( MSGJ · discusión ) 12:20, 30 de enero de 2024 (UTC) [ responder ]
- Apoyo Por lo que dije en la otra discusión sobre ser un usuario poco frecuente como mantenedor de gadgets y que hay muy pocos administradores internos. Galobtter ( discusión ) 14:01, 30 de enero de 2024 (UTC) [ responder ]
- Soporte - ¿Por qué también tenemos un requisito de dos meses? Parece DEMASIADO estricto. Creo que unos requisitos de edición más similares a WP:INACTIVITY serían más adecuados para los administradores de interfaz:
(1) No ha realizado ediciones ni acciones administrativas durante al menos un período de 12 meses. (2) Ha realizado menos de 100 ediciones en un período de 60 meses.
Alguien que me diga por qué esto no funcionaría suponiendo que (2) se aumentara a 1000 ediciones aproximadamente. Schierbecker ( discusión ) 17:03, 30 de enero de 2024 (UTC) [ responder ]- La idea detrás del requisito de los 2 meses es probablemente asegurar que el usuario siga en activo. Una cuenta completamente inactiva es un riesgo mayor, ya que su usuario legítimo no sabrá si hay intentos de entrar, además del hecho de que un usuario que abandonó su cuenta no cambiará repentinamente la contraseña; una cuenta completamente inactiva es indistinguible de una inactiva. Amante de los animales |666| 00:33, 2 de febrero de 2024 (UTC) [ responder ]
- Apoyo , aunque estoy de acuerdo con el requisito de inactividad general de 2 meses. Es difícil exagerar lo potencialmente peligroso que es el derecho de intadmin, por lo que tiene sentido eliminarlo ante la primera señal de inactividad general. Es solo que el uso del bit de intadmin en sí no aparece muy a menudo, por lo que el requisito de uso de herramientas necesita un poco de calibración. Writ Keeper ⚇ ♔ 17:12, 30 de enero de 2024 (UTC) [ responder ]
- Soporte . Creo que hay varios administradores internos cuya actividad principal es ser el encargado del mantenimiento de un gadget importante. Las actualizaciones de ese gadget pueden pasar más de 6 meses sin una implementación a veces, por lo que es fácil que el administrador interno deje de hacerlo. Los {{ IAER }} tampoco son siempre buenos para actualizar gadgets importantes. A veces, los gadgets tienen scripts de implementación personalizados que solo una o dos personas saben cómo usar. – Novem Linguae ( discusión ) 17:31, 30 de enero de 2024 (UTC) [ responder ]
- ' El volumen de solicitudes de soporte no es alto. Hawkeye7 (discutir) 01:10, 31 de enero de 2024 (UTC) [ responder ]
- Apoyo , en deferencia al criterio de Xaosflux. No estoy lo suficientemente familiarizado con las acciones de administración de la interfaz como para poder evaluar esto de forma independiente, pero confío en Xaosflux como uno de los administradores más activos en esa área, y la propuesta suena razonable. {{u| Sdkb }} discusión 05:16, 31 de enero de 2024 (UTC) [ responder ]
- Se deben mantener los requisitos de actividad general relativamente estrictos, pero es mucho menos necesario que se controlen tan estrictamente las "ediciones que utilizan el permiso". CMD ( discusión ) 05:26 31 ene 2024 (UTC) [ responder ]
- Soporte Bajo volumen de solicitudes y consideraciones de seguridad, es lo lógico - Fastily 06:50, 31 de enero de 2024 (UTC) [ responder ]
- Soporte Parece un cambio muy razonable. The Wordsmith Háblame 16:54, 31 de enero de 2024 (UTC) [ responder ]
- Los usuarios de soporte que aún están activos en la wiki no deberían necesitar volver a solicitar derechos si no los usan con demasiada frecuencia pero aún están presentes -- DannyS712 ( discusión ) 22:19, 31 de enero de 2024 (UTC) [ responder ]
- El soporte parece razonable y no agrega ningún riesgo adicional. Existen riesgos adicionales con las cuentas no utilizadas, así que mantengámoslas separadas. -- zzuuzz (discusión) 00:14 1 feb 2024 (UTC) [ responder ]
- Apoyo Creo que esto es razonable. La cantidad de acciones es bastante baja y, si una persona tiene un pico de actividad, puede dominar fácilmente la cantidad de acciones manejadas en comparación con los demás. — The DJ ( discusión • contribuciones ) 09:47 , 1 de febrero de 2024 (UTC) [ responder ]
- Apoyo lo anterior. Stifle ( discusión ) 12:03 1 febrero 2024 (UTC) [ responder ]
- Soporte Incluso mantener los "2 meses" parece demasiado estricto. En general, necesitamos un escrutinio más minucioso para que este y otros administradores no se oxiden, pero una fecha límite muy breve para usar las herramientas no es la forma de hacerlo. North8000 ( discusión ) 18:12 1 feb 2024 (UTC) [ responder ]
- Soporte : en mi opinión, solo hay 3 razones legítimas para hacer tales requisitos: mantener el sitio a salvo de robos de cuentas, evitar que los usuarios con poca actividad realicen acciones que violen los cambios recientes en las reglas y evitar que la ilusión de que muchos usuarios con el derecho disuada a los usuarios novatos de solicitar (o recibir) el derecho. El primero se maneja mediante el requisito de cualquier acción, el segundo es de baja relevancia (es más una preocupación para los administradores habituales), y con solo 10 usuarios de este tipo debería estar claro que necesitamos muchos más. Amante de los animales |666| 00:48, 2 de febrero de 2024 (UTC) [ responder ]
- Soporte : el propósito de los requisitos de actividad es asegurar que el iadmin esté activo y pueda usar las herramientas. Agregar burocracia y tiempo de espera a los mantenedores de gadgets activos que pueden no usar las herramientas cada 6 meses no es deseable. Tenemos (y con el cambio todavía tendríamos) bastantes iadmins, por lo que el riesgo de seguridad es bajo (yo diría que hay un riesgo mayor en las cuentas de crat/requisitos de actividad de crat). — Bilorv ( discusión ) 21:39, 4 de febrero de 2024 (UTC) [ responder ]
- Soporte : Esto parece un cambio menor, bien pensado y razonable. ++ Lar : t / c 00:12, 6 de febrero de 2024 (UTC) [ responder ]
- Apoyo La enmienda propuesta es comprensible. Jerium ( discusión ) 13:25 6 feb 2024 (UTC) [ responder ]
- Parece bastante razonable ahora que hemos podido ver cuál es realmente la carga de trabajo de los administradores de interfaz. Callanecc ( discusión • contribuciones • registros ) 04:10, 11 de febrero de 2024 (UTC) [ responder ]
- Apoyo Me parece razonable. Los beneficios superan los riesgos, como dicen. DarmaniLink ( discusión ) 05:10 19 feb 2024 (UTC) [ responder ]
- Las personas que claramente siguen aquí no deberían ser penalizadas por no realizar cambios imprudentes para cumplir con una cuota. Doce meses es un período de tiempo suficiente para extender esto, dado que aún existe el requisito de que realicen una edición o una acción registrada dentro de los últimos dos meses. EggRoll97 ( discusión ) 05:14 21 feb 2024 (UTC) [ responder ]
- Si un derecho de usuario se creó porque está destinado a usarse con moderación y por razones excepcionales, es razonable que puedas pasar un año sin usarlo. – xeno talk 18:21, 24 de febrero de 2024 (UTC) [ responder ]
Oponerse a
- Débil se opone , dada la barrera absurdamente baja que tenemos para recibir privilegios de administrador interno entre los administradores y la naturaleza relativamente sensible del permiso, tiene sentido tener un requisito de actividad más alto de lo normal. Si bien no tengo ningún problema con que la cohorte actual conserve los permisos indefinidamente, el hecho de que un administrador teóricamente pueda tener cero contribuciones técnicas durante más de un año (y con solo 6 ediciones normales durante el mismo período) y aún así poder hacer cambios importantes sin supervisión en dispositivos ampliamente utilizados me asusta. Sohom ( discusión ) 08:51, 1 de febrero de 2024 (UTC) [ responder ]
- Débilmente. Básicamente lo que dijo Pppery en la conversación anterior de IANB ( este comentario , aunque creo que 6 es el número correcto): una cuenta IA es un riesgo de seguridad, y si no se está usando, es mejor girar un poco las puertas. Estoy bien si Xaosflux se demora un poco cuando surge el tema de la desadministración (no es grave) , pero en todo caso es un argumento para aumentar el número de burócratas. Si es un dispositivo o un script que necesita hacerse, una pequeña espera para que aparezca un burócrata en BN no es un gran problema. No hay un período de espera para la renovación, no hay estigma para la renovación con una necesidad que afecta la inactividad previa, y el elenco presumiblemente rotativo es un subconjunto de un subconjunto, y uno bien conocido en eso. No soy un burócrata, pero imagino que la doble pregunta de que la 2FA todavía está activa puede ser la parte más molesta. En cuanto a la cuestión de los dos meses (que no está a la altura de esta RFC), creo que tres meses sería mejor. ~ Amory ( u • t • c ) 20:20, 1 de febrero de 2024 (UTC) [ responder ]
- Por otro lado, más crats = más personas con acceso de nivel de administrador interno (ya que los crats pueden autoasignarse), ¿no? Galobtter ( discusión ) 20:30, 1 de febrero de 2024 (UTC) [ responder ]
- Bueno, pasé quizás dos minutos enteros debatiendo si terminar esa oración con un signo de exclamación o no para enfatizar lo descarado que es, ¡así que fue un tiempo mal invertido! Pero claro, ese es un argumento que podrías hacer para simplemente hacer coincidir la política de IA con la política de Crat (más 2FA), o viceversa, supongo. Resolviendo diferentes problemas. Un contrapunto (no relacionado con la seguridad) es que, para cualquier sysop dado, la IA es dramáticamente más fácil de obtener. ~ Amory ( u • t • c ) 20:50, 1 de febrero de 2024 (UTC) [ responder ]
- La premisa de esta solicitud es que hay una escasez de trabajo administrativo de interfaz que se necesita hacer. El hecho de que hayan pasado menos de seis meses desde que hubo solicitudes de edición protegidas de interfaz hace 3 meses (!) muestra que dicha premisa es falsa. * Pppery * ha comenzado... 01:50, 2 de febrero de 2024 (UTC) [ responder ]
- Oposición : Estoy de acuerdo con las preocupaciones de Sohom Datta (pero no las encuentro "débiles"). Eliminar este permiso por inactividad básicamente no significaría nada para nadie, ya que si un administrador que estuvo ocupado en la vida real regresara, podría simplemente solicitar el permiso nuevamente y se le otorgaría casi automáticamente, a menos que exista alguna razón convincente para no otorgarlo nuevamente (como un mal uso anterior que posiblemente debería haber resultado en su eliminación por causa justificada). — SMcCandlish ☏ ¢ 😼 13:25, 21 de febrero de 2024 (UTC) [ responder ]
Discusión
- Un equilibrio importante para la seguridad es que no deberíamos tener demasiados usuarios de este tipo, y los requisitos actuales se crearon en función de eso. Ha pasado bastante tiempo y no vemos que los administradores utilicen este rol como una especie de colección de sombreros (no me sorprende, ya que no esperamos ese tipo de comportamiento de nuestros administradores...). Algunos de nuestros administradores de sistemas se ocupan de problemas poco frecuentes, como el mantenimiento de ciertos gadgets. — xaosflux Talk 11:30, 30 de enero de 2024 (UTC) [ responder ]
- ¿Estamos restaurando los derechos de los administradores internos (si los hay) que dejaron de cumplir con la política de seis meses pero nunca se vieron afectados por la nueva política propuesta? Schierbecker ( discusión ) 17:53, 30 de enero de 2024 (UTC) [ responder ]
- Dado que ya podrían simplemente pedirlo de vuelta en BN, dudo que sea necesario. Writ Keeper ⚇ ♔ 17:58, 30 de enero de 2024 (UTC) [ responder ]
- De acuerdo. Creo que es una buena idea mantener el RFC simple y tal como está. – Novem Linguae ( discusión ) 17:59, 30 de enero de 2024 (UTC) [ responder ]
- No, esto es realmente sólo para detener futuras puertas giratorias en WP:BN . — xaosflux Talk 18:06, 30 de enero de 2024 (UTC) [ responder ]
- AIUI el sistema en el Wikisource en inglés es un poco diferente, y tiene algunas ventajas de seguridad: tienen una lista de personas que son elegibles para este derecho de usuario, y cuando lo necesitas, configuras el bit, haces tu trabajo y luego lo eliminas. Cuando no lo necesitas, no estás haciendo tu trabajo diario con todos tus privilegios habilitados. No sé qué tanta molestia sería esto, especialmente si tienes que pedirle a otra persona que lo habilite por ti, pero podría valer la pena pensarlo. WhatamIdoing ( discusión ) 00:23, 7 de febrero de 2024 (UTC) [ responder ]
- @ WhatamIdoing Acabo de comprobar el último año del registro de derechos de usuario en enwikisource y no veo ni una sola instancia de ese comportamiento, y solo los "crats" de enwikisource pueden cambiar esa bandera; además, veo un intadmin de enwikisource sin uso en más de un año allí --- así que no creo que esto sea en lo que estás pensando. ¿Quizás estás pensando en la bandera "flood"? — xaosflux Talk 00:32, 7 de febrero de 2024 (UTC) [ responder ]
- Billinghurst debería poder decirnos si mi memoria está equivocada. Hace mucho tiempo que no me entero de esto. WhatamIdoing ( discusión ) 02:04 7 feb 2024 (UTC) [ responder ]
- Comentario: No solemos hacer mucha edición en ese espacio. Antes de que lo discutiéramos más formalmente, teníamos una asignación de derechos a corto plazo a pedido de la comunidad, con una evaluación ligera por parte de la comunidad, notando una comunidad de administradores mucho más pequeña y menos manipuladores. No teníamos ni hemos tenido una IA autoconfigurada. Tenemos derechos AF y flood autoconfigurados para los administradores. Normalmente no queremos tantos derechos de IA permanentes y no solemos tener la necesidad. — billinghurst sDrewth 02:29, 12 de febrero de 2024 (UTC) [ responder ]
La discusión anterior está cerrada. No la modifique. Los comentarios posteriores deben realizarse en la página de discusión correspondiente. No se deben realizar más modificaciones a esta discusión.