Обсуждение в Википедии:Администраторы интерфейсов

Прямо указать, что бюрократы имеют/могут предоставлять права администратора интерфейса?

По словам пользователя:Izno , «краты могут предоставлять права администратора интерфейса, но эта страница нигде не упоминает об этом, насколько я мог бы легко увидеть. Я бы сам исправил это напрямую, но не очень хорошо знаком с разрешениями или последствиями. ~ 🦝 Shushugah (он/он • talk ) 23:04, 8 июня 2022 (UTC) [ ответить ]

@ Shushugah Это уже второй пункт на Wikipedia:Bureaucrats ; эта страница похожа на Wikipedia:Administrators в том, как она объясняет вещи. — xaosflux ^Talk 00:31, 9 июня 2022 (UTC) [ ответить ]

Уточните, в праве может быть отказано

Согласно моим комментариям в BN, существующая политика устанавливает период ожидания, фактически не предоставляя бюрократам возможности сказать «нет» или не определяя, когда они могут это сделать. Чтобы прояснить этот вопрос, я предлагаю добавить в политику следующий текст: Запрос будет оставаться открытым в течение 48 часов для впервые поданных запросов, и если в сообществе будет достигнут консенсус против предоставления, бюрократы могут отказать в предоставлении доступа.

Не думаю, что это нуждается в официальном RfC, но не собираюсь обновлять без начала обсуждения. TonyBallioni ( обсуждение ) 00:47, 16 июня 2022 (UTC) [ ответить ]

(см. Special:PermaLink/1093342938 ) Это должно быть «как минимум» 48 часов, количество часов не ограничено. Обычно они не получают большой рекламы и т. д., поэтому я не ожидаю, что будет много мерил консенсуса «сообщества», который должен возникнуть, чтобы победить его за такое короткое время. Я бы не хотел делать это слишком «бюрократическим», что-то вроде того, что если у «крата» есть опасения, то должно произойти дополнительное/расширенное обсуждение консенсуса . Сохраняет ожидание того, что по умолчанию ДА, оставляет предохранительный клапан, но в конечном итоге передает это в руки сообщества. — xaosflux ^Talk 00:57, 16 июня 2022 (UTC) [ ответить ]

Да, меня все устраивает, и я согласен с тем, что вы говорите. Я просто не думаю, что у нас когда-либо были возражения, даже со стороны чудака, поэтому стоит уточнить, что есть способ отклонить это, так что я думаю, что мы должны хотя бы сказать что-то об этом где-то. TonyBallioni ( talk ) 01:00, 16 июня 2022 (UTC) [ ответить ]

Даже если это, возможно, противоречит моим личным интересам, я поддерживаю как основную идею разъяснения («краты должны иметь некоторую свободу действий»), так и интерпретацию Xaosflux. {{ Nihiltres | talk | edits }} 01:27, 16 июня 2022 (UTC) [ ответить ]

Хм, я не уверен, что это необходимо. Текущая политика гласит: Все редакторы могут обсуждать заявителя, но окончательное решение остается за проверяющим бюрократом. Я интерпретирую это так, что отдельные бюрократы могут принять или отклонить любой запрос по своему усмотрению, независимо от того, что думает сообщество в целом (хотя я уверен, что бюрократы не будут намеренно игнорировать четкий консенсус сообщества). Это похоже на то, как работает WP:PERM : независимо от того, что комментируют люди, окончательное решение по запросам принимает проверяющий администратор. Предложенная формулировка, по-видимому, ограничивает возможность бюрократов отклонять только ситуациями, когда существует консенсус сообщества против предоставления , поэтому, похоже, это изменение ограничит то, что бюрократы могут делать в настоящее время. Mz7 ( обсуждение ) 01:47, 16 июня 2022 (UTC) [ ответ ]

Я думаю, что 'crats должны иметь право отклонять запрос, основываясь либо на комментариях сообщества, либо на своих собственных выводах. Я поддерживаю любые изменения или разъяснения, необходимые для реализации этого. Если окажется, что RFC необходим, пожалуйста, напишите мне, так как я не собираюсь смотреть это обсуждение. Thryduulf ( обсуждение ) 02:00, 16 июня 2022 (UTC) [ ответить ]

Я считаю, что «окончательное решение остается за проверяющим бюрократом» — это довольно ясно, что Crat может либо удовлетворить, либо отклонить запрос. А основания для отказа указаны в разделе «Предыстория». Если пользователь соответствует критериям: «высокодоверенный, имеет хотя бы базовые знания JS и CSS, знает об ожиданиях википедии Wikimedia в отношении конфиденциальности и имеет приличное понимание того, как защитить свои учетные записи», ему будет предоставлено право, если он не соответствует одному из этих критериев, ему будет отказано в праве. Существует дискуссия о том, можно ли доверять Nihiltres, учитывая, что они совершили ошибку; и консенсус заключается в том, что им можно доверять, поскольку они исправили свою ошибку и не совершили других. Процесс, похоже, работает нормально. Если люди хотят изменить формулировку, чтобы сделать ее более ясной, они могут это сделать; пока они не изменят последствия формулировки, то нет необходимости искать консенсус. Для ясности можно добавить такую формулировку: «Если все согласны с тем, что администратор не пользуется большим доверием, или не имеет хотя бы базовых знаний JS и CSS, или не осведомлен о требованиях к конфиденциальности вики-проектов Wikimedia, или не имеет достаточного представления о том, как защитить свои учетные записи, то право не будет предоставлено».

Я согласен с Xaosflux, что "как минимум" следует добавить перед "48 часами". В нынешнем виде это можно интерпретировать так, что по истечении 48 часов запрос автоматически закрывается, и если запрос не был удовлетворен, он может по умолчанию считаться невыполненным, поэтому необходимо будет сделать новый запрос. SilkTork ( обсуждение ) 02:04, 16 июня 2022 (UTC) [ ответить ]

Должно ли это быть «предоставлять, если есть консенсус» или «не предоставлять, если есть консенсус против»? и если есть консенсус сообщества против предоставления, бюрократы могут отказать в предоставлении доступа. может быть истолковано как «бюрократы должны предоставлять, если нет консенсуса». Jo-Jo Eumerus ( обсуждение ) 10:54, 16 июня 2022 (UTC) [ ответить ]

@ Jo-Jo Eumerus, как и в WP:PERM , у нас обычно нет дискуссий, измеряющих консенсус, вокруг них, предыдущий консенсус RfC склонялся к «дискреционности crat»; точно так же, как если бы я отклонил кого-то в WP:PERM — если бы консенсус был достигнут в ходе обсуждения, это сделал бы какой-то другой администратор. — xaosflux ^Talk 13:40, 16 июня 2022 (UTC) [ ответить ]

«окончательное решение остается за проверяющим бюрократом» кажется мне довольно недвусмысленным. Это похоже на обычный элемент, который вы получили бы в WP:PERM , с добавленным предварительным просмотром не менее 48 часов, которые даются сообществу для комментариев, если есть причины отклонить запрос. Хотя WP:BN не является самым посещаемым местом, он, безусловно, получает достаточно просмотров, чтобы узнать, есть ли у сообщества в целом причины отклонить запрос. Если время имеет большое значение, сделайте это на неделю. Запросы в WP:PERM требуют только, чтобы закрывающий администратор проверил, можно ли доверять пользователю, и чтобы другие пользователи могли высказать свое мнение по запросу. Хотя, и если есть консенсус сообщества против предоставления, бюрократы могут отказать в предоставлении доступа , это говорит мне о том, что у крата не было бы выбора, кроме как предоставить разрешение, если бы не было дальнейшего обсуждения по этому поводу. Ли Виленски⁽^{обсуждение}^•^вклад⁾ 11:27, 17 июня 2022 (UTC) [ ответ ]

Мы волонтеры, поэтому у нас всегда есть выбор.

По умолчанию право будет предоставлено, пока нет возражений, поскольку это право раньше было частью инструментария каждого администратора. Было решено (не сообществом, если я правильно помню, а WMF), что предоставление доступа к инструменту каждому администратору, включая тех, кого Джимбо назначил случайно, может быть проблематичным. Хотя недавно назначенные администраторы, как считалось, обладают здравым смыслом и не включают бензопилу, если не знают, как ею пользоваться, у WMF были явные подозрения, что некоторые из ранних администраторов были идиотами. Таким образом, ситуация такова, что администратор должен запросить инструмент, и этого запроса должно быть достаточно, чтобы развеять любые опасения, однако, просто для уверенности, есть 48-часовое удержание, чтобы люди могли выступить с доказательствами того, что администратор на самом деле идиот. Если никто не выступит, мы можем просто щелкнуть выключателем (или оставить это кому-то другому, если нам это не нравится или мы не понимаем последствий).

Согласно политике, нам не разрешено давать себе право, хотя технически мы можем. Интересно, что нам доверяют достаточно, чтобы не давать себе право, но не доверяют, чтобы давать себе право. Я предполагаю, что это просто ошибка, что нам оставили возможность давать себе право. SilkTork ( talk ) 13:31, 19 июня 2022 (UTC) [ ответить ]

@ SilkTork в основном это дополнительные уровни технического контроля, которые потребуются, чтобы также добавить проверку «но не для себя», которая на самом деле не нужна — если кто-то, предоставивший доступ, задумал что-то нехорошее, он может просто предоставить доступ альтернативной учетной записи и обойти все это в любом случае. — xaosflux ^Talk 13:48, 19 июня 2022 (UTC) [ ответить ]

Я согласен с вашим общим обзором процесса — по сути, если обрабатывающий «крат» отклоняет запрос, это может быть тонким заявлением «вполне возможно, что вы на самом деле идиот», которое другие «краты» могут отменить, просто предоставив его (особенно после некоторого вклада сообщества). — xaosflux ^Talk 13:50, 19 июня 2022 г. — (UTC)

Кстати, разработчики MediaWiki предоставили эту возможность, но оставили на усмотрение местных вики-сообществ решение о том, как назначать привилегию (см. Wikipedia:Village pump (разное)/Архив 59 § Новая группа пользователей для редактирования CSS/JS на всем сайте и m:Создание отдельной группы пользователей для редактирования CSS/JS на всем сайте). Все решения о процессе предоставления принимались сообществом (см. архивы этой страницы обсуждения). isaacl ( обсуждение ) 16:28, 19 июня 2022 (UTC) [ ответ ]

Вы знаете об этом больше меня, isaacl. Насколько я понимаю, это право уже существовало в наборе инструментов администратора, но "разработчики MediaWiki" (я не совсем уверен, где они находятся в мире Википедии, но поскольку они MediaWiki - часть WMF - я склонен думать о них как о части WMF, а не Википедии, хотя я думаю, что это, возможно, темная область - некоторые разработчики - добровольцы, а некоторые - оплачиваемые WMF?) отобрали это право у администраторов Википедии, потому что они решили, что это риск для безопасности. Насколько я понимаю (и, пожалуйста, поправьте меня, если я не прав), это было сделано без консультации с сообществом Википедии. Насколько я понимаю (и, опять же, поправьте меня, если я не прав - это не та область, в которую я склонен вмешиваться), сообщество Википедии затем рассмотрело способ восстановления права администраторов, и консенсус был в том, что право может быть восстановлено по заявлению с простой 48-часовой паузой, чтобы посмотреть, есть ли какие-либо возражения. По сути, каждый администратор Википедии может подать заявку на это право, и, пока никто не объявит кого-либо из них идиотами, это право может быть предоставлено им. Теоретически мы могли бы восстановить право для каждого администратора Википедии в течение 48 часов. И, я полагаю, «разработчики MediaWiki» (WMF?) были бы совершенно согласны с этим, поскольку мы бы следовали согласованной процедуре Википедии. Или вы подозреваете, что будут возражения, поскольку возникнет риск того, что некоторым администраторам не следует доверять (WMF, поскольку, как я предполагаю, им доверяет сообщество, иначе они бы не были администраторами)? SilkTork ( обсуждение ) 18:13, 20 июня 2022 (UTC) [ ответить ]

@ SilkTork косвенно связано, WMF (владельцы серверов) требуют, чтобы любой, кто хочет получить доступ к внутреннему администратору, использовал 2FA - так что всем этим администраторам сначала нужно будет его активировать. — xaosflux ^Talk 18:52, 20 июня 2022 (UTC) [ ответить ]

Хотя я бы не удивился, если бы это было так, единственное руководство, которое я смог найти, было от Tgr в их роли разработчика MediaWiki. Насколько я помню (и как я могу видеть при беглом просмотре архива), в английской Википедии существовал консенсус в поддержку требования двухфакторной аутентификации для администраторов интерфейса в знак признания чрезвычайной силы возможности заставить вредоносный Javascript запускаться в браузерах пользователей. isaacl ( talk ) 20:55, 20 июня 2022 (UTC) [ ответить ]

Двухфакторная аутентификация является глобальным требованием для каждого проекта, есть несколько ролей, для которых она необходима — см. баннер на meta:Interface_administrators. — xaosflux ^Talk 22:21, 20 июня 2022 (UTC) [ ответить ]

Спасибо за ссылку; для меня это имеет смысл. Я вижу, что примечание было добавлено в декабре 2018 года, после того, как процесс предоставления достиг здесь консенсуса. isaacl ( talk ) 22:59, 20 июня 2022 (UTC) [ ответить ]

Мета-страница, на которую я ссылался, содержит ссылки на соответствующий тикет Phabricator и обсуждение в списке рассылки wikitech. Насколько я могу судить, Tgr создала эту функцию по собственной инициативе в целях повышения безопасности, что включало создание новой пользовательской привилегии (что, да, позволило запретить администраторам редактировать страницы Javascript и CSS на всем сайте). Действительно, разработчики MediaWiki считали, что развертывание находится в их компетенции, как вопрос безопасности, и поэтому провели только то, что по сути было консультативной консультацией по мета. Обсуждение в Википедии: Администраторы интерфейса/Архив 2 § RfC: Утверждение обновленного предложения содержит обсуждение в английской Википедии для окончательного процесса (заменяющего процесс временного прекращения, который сообщество ввело, чтобы гарантировать, что кто-то сможет редактировать страницы в области действия в течение промежутка времени), которое, как вы заявили, одобрило процесс, в котором «[б]юрократы уполномочены» предоставлять администратору интерфейса разрешение по запросу после 48-часового периода ожидания. Тот, кто отвечает за безопасность в WMF, может иметь свое мнение, но, насколько я могу судить, сообщество по-прежнему свободно в принятии решений относительно этого процесса. isaacl ( обсуждение ) 21:32, 20 июня 2022 (UTC) [ ответить ]

Это кажется нормальным (и первоначальное предложение, и «по крайней мере» на данный момент). Больше подробностей, чем требуется, кажется излишним, но TB прав, что лучше всего иметь «зачем нам это нужно», а затем нужно обсудить изменения одновременно с проблемой. Nosebagbear ( обсуждение ) 12:34, 24 июня 2022 (UTC) [ ответить ]
Меня устраивает предлагаемое изменение формулировки политики в целях ясности; я не вижу ничего плохого в том, чтобы сделать детали более понятными, если они кажутся двусмысленными, и добавление пункта WP:SNOW в формулировку политики кажется разумным. Я согласен с тем, что сказал Nosebagbear выше, в том, что «[б]ольше подробностей, чем требуется, кажется ненужным, но TB прав, что [лучше] иметь „зачем нам это нужно“». ~Oshwah~ ^{(обсуждение) (вклад)} 02:52, 4 июля 2022 (UTC) [ ответить ]

RFC: Увеличить требования к бездействию

Следующее обсуждение представляет собой архивированную запись запроса на комментарий . Пожалуйста, не изменяйте его. Дальнейшие правки в это обсуждение вноситься не должны. Ниже приводится резюме сделанных выводов.

Существует четкий консенсус относительно увеличения требования бездействия до 12 месяцев. В результате администраторы интерфейса, которые не вносили никаких изменений или других зарегистрированных действий в течение как минимум 2 месяцев или которые не вносили никаких изменений с использованием разрешения в течение как минимум 12 месяцев, должны быть лишены своего права пользователя. Те, кто выступал против этого изменения, утверждали, что текущий уровень бездействия достаточен, ссылаясь на конфиденциальный характер разрешения и его простоту восстановления через запрос в WP:BN . ( неадминистративное закрытие ) – DreamRimmer ( обсуждение ) 02:30, 29 февраля 2024 (UTC) [ ответить ]

Предложенный:

В: Администраторы интерфейса, которые не вносили никаких изменений или не совершали других зарегистрированных действий в течение как минимум 2 месяцев или которые не вносили никаких изменений с использованием разрешения в течение как минимум 6 месяцев, должны лишиться права пользователя.

Изменение на администраторов интерфейса, которые не вносили никаких изменений или других зарегистрированных действий в течение как минимум 2 месяцев или которые не вносили никаких изменений, используя разрешение, как минимум~~6 месяцев~~12 месяцевследует удалить право пользователя.

Недавнее обсуждение: Special:PermaLink/1200817440

Предлагаемое обоснование: действия интерфейс-администратора не очень высоки, но в целом продуктивны. Для редакторов, которые все еще в целом активны, но имеют менее частые обновления интерфейса, необходимость повторного запроса при необходимости является контрпродуктивной. В настоящее время у нас <10 int-admins, и это изменение не должно привести к тому, что у нас будет «слишком много», поскольку порог общей неактивности все еще низок. — xaosflux ^Talk 11:23, 30 января 2024 (UTC) [ ответить ]

Поддерживать

Как и предложено. — xaosflux ^Talk 11:23, 30 января 2024 (UTC) [ ответить ]
У меня нет проблем с предлагаемым изменением. Требование в 2 месяца также может рассматриваться как излишне строгое — Мартин ( MSGJ · talk ) 12:20, 30 января 2024 (UTC) [ ответить ]
Поддержка Согласно тому, что я сказал в другом обсуждении о том, что я нечастый пользователь в качестве обслуживающего гаджета и что очень мало внутренних администраторов. Galobtter ( обсуждение ) 14:01, 30 января 2024 (UTC) [ ответить ]
Поддержка - А почему у нас есть двухмесячное требование? Кажется, это СЛИШКОМ слишком строго. Я думаю, что требования к редактированию, более похожие на WP:INACTIVITY, больше подойдут администраторам интерфейса: (1) Не вносил никаких правок и не выполнял административных действий в течение как минимум 12 месяцев. (2) Внес менее 100 правок за 60 месяцев. Кто-нибудь скажет мне, почему это не сработает, если предположить, что (2) было увеличено до 1000 правок или около того. Schierbecker ( talk ) 17:03, 30 января 2024 (UTC) [ ответить ]
Идея двухмесячного требования, вероятно, заключается в том, чтобы убедиться, что пользователь все еще активен. Полностью неактивная учетная запись представляет больший риск, поскольку ее законный пользователь не будет знать о попытках взлома, а также тот факт, что пользователь, отказавшийся от своей учетной записи, не сменит внезапно пароль; полностью неактивная учетная запись неотличима от неактивной. Любитель животных |666| 00:33, 2 февраля 2024 (UTC) [ ответить ]
Поддержка , хотя меня устраивает требование 2-месячной общей неактивности. Трудно переоценить, насколько потенциально опасно право intadmin, поэтому имеет смысл удалить его при первых признаках общей неактивности. Просто использование самого бита intadmin на самом деле встречается не так уж часто, поэтому требование использования инструмента требует некоторой калибровки. Writ Keeper ⚇ ♔ 17:12, 30 января 2024 (UTC) [ ответить ]
Поддержка . Я думаю, что есть несколько intadmins, чьей основной деятельностью является поддержка крупного гаджета. Обновления этого гаджета иногда могут проходить более 6 месяцев без развертывания, поэтому легко потерять intadmin. {{ IAER }} также не всегда хороши для обновления крупных гаджетов. Иногда гаджеты имеют пользовательские сценарии развертывания, которые знают, как использовать только один или два человека. – Novem Linguae ( обсуждение ) 17:31, 30 января 2024 (UTC) [ ответ ]
' Поддержка Объем запросов невелик. Hawkeye7 (обсудить) 01:10, 31 января 2024 (UTC) [ ответить ]
Поддержка , в знак уважения к мнению Xaosflux. Я недостаточно хорошо знаком с действиями администратора интерфейса, чтобы иметь возможность оценить это независимо, но я доверяю Xaosflux как одному из самых активных администраторов в этой области, и предложение звучит разумно. {{u| Sdkb }}  ^talk 05:16, 31 января 2024 (UTC) [ ответить ]
Поддержка , относительно строгие требования к общей активности должны оставаться в силе, но гораздо меньше необходимости в столь строгом контроле «редактирования с использованием разрешения». CMD ( обсуждение ) 05:26, 31 января 2024 (UTC) [ ответить ]
Поддержка Низкий объем запросов и соображения безопасности, это логично - Fastily 06:50, 31 января 2024 (UTC) [ ответить ]
Поддержка Кажется, это очень разумное изменение. Wordsmith ^{Talk to me} 16:54, 31 января 2024 (UTC) [ ответить ]
Пользователям службы поддержки , которые все еще активны в вики, не нужно повторно запрашивать права, если они не используют их слишком часто, но все еще присутствуют -- DannyS712 ( обсуждение ) 22:19, 31 января 2024 (UTC) [ ответить ]
Поддержка , кажется разумной и не добавляет никаких дополнительных рисков. Есть дополнительные риски с неиспользуемыми аккаунтами, поэтому давайте будем держать это отдельно. -- zzuuzz ^{(обсуждение)} 00:14, 1 февраля 2024 (UTC) [ ответить ]
Поддержка Я думаю, что это разумно. Количество действий действительно довольно низкое, и если у человека всплеск активности, он может легко доминировать по количеству обработанных действий по сравнению с другими. — Th e DJ ( talk • contribs ) 09:47, 1 февраля 2024 (UTC) [ ответить ]
Поддержка выше. Stifle ( обсуждение ) 12:03, 1 февраля 2024 (UTC) [ ответить ]
Поддержка Даже сохранение "2 месяцев" выглядит слишком строго. В целом нам нужно более пристальное внимание, чтобы этот и другие администраторы не заржавели, но очень короткий срок для использования инструментов - это не способ сделать это. North8000 ( обсуждение ) 18:12, 1 февраля 2024 (UTC) [ ответить ]
Поддержка - на мой взгляд, есть только 3 законных причины для предъявления таких требований: защитить сайт от взломов учетных записей, не допустить, чтобы пользователи с низкой активностью предпринимали действия, нарушающие недавние изменения правил, и не допустить, чтобы иллюзия множества пользователей с правом удерживала новых пользователей от запроса (или предоставления) права. Первое обрабатывается требованием любого действия, второе имеет низкую релевантность (это больше касается обычных администраторов), и с учетом всего 10 таких пользователей должно быть ясно, что нам нужно гораздо больше. Любитель животных |666| 00:48, 2 февраля 2024 (UTC) [ ответить ]
Поддержка : цель требований к активности — гарантировать, что iadmin активен и имеет возможность использовать инструменты. Добавление бюрократии и времени ожидания для активных обслуживающих гаджеты, которые могут не использовать инструменты каждые 6 месяцев, нежелательно. У нас есть (и при изменении все еще будет) довольно мало iadmins, поэтому риск безопасности низок (я бы сказал, что есть более высокий риск в учетных записях crat/требованиях к активности crat). — Bilorv ( обсуждение ) 21:39, 4 февраля 2024 (UTC) [ ответить ]
Поддержка : Это кажется незначительным, хорошо продуманным и разумным изменением. ++ Lar : t / c 00:12, 6 февраля 2024 (UTC) [ ответить ]
Поддержка Предлагаемая поправка понятна. Jerium ( обсуждение ) 13:25, 6 февраля 2024 (UTC) [ ответить ]
Поддержка Кажется вполне разумным теперь, когда мы смогли увидеть, какова на самом деле нагрузка на администраторов интерфейсов. Callanecc ( обсуждение • вклад • журналы ) 04:10, 11 февраля 2024 (UTC) [ ответить ]
Поддержка Мне кажется разумным. Преимущества перевешивают риски, как говорится. DarmaniLink ( обсуждение ) 05:10, 19 февраля 2024 (UTC) [ ответ ]
Поддержка Люди, которые явно все еще здесь, не должны быть наказаны за то, что не внесли безрассудные изменения для выполнения квоты. Двенадцать месяцев — достаточный срок, чтобы продлить это, учитывая, что требование, чтобы они внесли редактирование или зарегистрировали действие в течение последних двух месяцев, все еще существует. EggRoll97 ^{( обсуждение )} 05:14, 21 февраля 2024 (UTC) [ ответить ]
Если право пользователя было создано для того, чтобы его использовали экономно и по исключительным причинам, то вполне разумно, что вы могли бы прожить год, не используя его. – xeno talk 18:21, 24 февраля 2024 (UTC) [ ответить ]

Выступать против

Слабое противодействие , учитывая абсурдно низкую планку, которую мы имеем для получения привилегий intadmin среди администраторов, и относительно чувствительную природу разрешения, имеет смысл иметь более высокие, чем обычно, требования к активности. Хотя у меня нет никаких проблем с тем, что текущая когорта сохраняет разрешения на неопределенный срок, тот факт, что администратор теоретически может иметь нулевой технический вклад в течение года (и всего с 6 обычными правками за тот же период) и все равно иметь возможность вносить серьезные неконтролируемые изменения в широко используемые гаджеты, пугает меня. Sohom ( talk ) 08:51, 1 февраля 2024 (UTC) [ ответить ]
Слабо. В основном то, что сказал Pppery в предыдущем разговоре IANB ( этот комментарий , хотя я думаю, что 6 — правильное число): учетная запись IA представляет собой риск для безопасности, и если она не используется, лучше немного покрутить двери. Я не против, если Xaosflux немного замешкается, когда речь зайдет о де-интадмин-инге — это не страшно — но, если уж на то пошло, это аргумент в пользу увеличения числа Бюрократов. Если это гаджет или скрипт, который нужно сделать, небольшое ожидание появления «крата» в BN — это не проблема. Нет периода ожидания для продления, нет стигмы для продления с потребностью, на которую влияет предыдущий переход в неактивный режим, и предположительно ротационный состав — это подмножество подмножества, и к тому же хорошо известное. Я не «крат, но я полагаю, что двойная просьба о том, что 2FA все еще включена, может быть самой раздражающей частью. Что касается (не-подходящего-для-этого-RFC) двухмесячного срока, я бы лучше выбрал 3 месяца. ~ Эмори ( u • t • c ) 20:20, 1 февраля 2024 (UTC) [ ответить ]
С другой стороны, больше кратов = больше людей с доступом уровня intadmin (поскольку краты могут назначать себя сами), не так ли? Galobtter ( обсуждение ) 20:30, 1 февраля 2024 (UTC) [ ответить ]
Ну, я потратил, наверное, целых две минуты, размышляя, заканчивать ли это предложение восклицательным знаком или нет, чтобы подчеркнуть его нахальство, так что время потрачено зря! Но, конечно, это аргумент, который вы могли бы привести, чтобы просто сопоставить политику IA с политикой Crat (плюс 2FA), или наоборот, я полагаю. Решая разные проблемы. (Не связанный с безопасностью) контраргумент заключается в том, что для любого заданного сисопа IA получить значительно проще. ~ Amory ( u • t • c ) 20:50, 1 февраля 2024 (UTC) [ ответить ]
Предпосылка этого запроса заключается в том, что существует нехватка работы по администрированию интерфейса, которую необходимо выполнить. Тот факт, что прошло менее шести месяцев с того времени, когда были запросы на редактирование защищенного интерфейса 3-месячной давности (!), показывает, что эта предпосылка ложна. * Pppery * _{это началось...} 01:50, 2 февраля 2024 (UTC) [ ответить ]
Oppose : Я согласен с опасениями Sohom Datta (но не считаю их «слабыми»). Удаление этого разрешения за бездействие по сути ничего не будет значить для кого-либо, поскольку если администратор, который был занят в реальной жизни, вернется, он может просто снова запросить разрешение и почти автоматически получить его повторно, при отсутствии какой-либо веской причины не предоставлять его повторно (например, неправильное использование ранее, которое, возможно, должно было привести к его удалению по причине). —  SMcCandlish ☏ ¢ 😼 13:25, 21 февраля 2024 (UTC) [ ответить ]

Обсуждение

Важный баланс для безопасности заключается в том, что у нас не должно быть слишком много таких пользователей, и текущие требования были построены в соответствии с этим. Прошло уже довольно много времени, и мы не видим администраторов, использующих эту роль как своего рода коллекцию шляп (неудивительно, поскольку мы не ожидаем такого поведения от наших администраторов...). Некоторые из наших внутренних администраторов решают нечастые проблемы, такие как обслуживание определенных гаджетов. — xaosflux ^Talk 11:30, 30 января 2024 (UTC) [ ответить ]
Восстанавливаем ли мы права админов (если таковые имеются), которые нарушили шестимесячную политику, но не нарушили новую предлагаемую политику? Schierbecker ( обсуждение ) 17:53, 30 января 2024 (UTC) [ ответить ]
Учитывая, что они уже могли бы просто попросить его обратно в BN, я сомневаюсь, что это необходимо. Writ Keeper ⚇ ♔ 17:58, 30 января 2024 (UTC) [ ответить ]
Согласен. Я думаю, что сохранение RFC простым и как есть — это хорошая идея. – Novem Linguae ( обсуждение ) 17:59, 30 января 2024 (UTC) [ ответ ]
Нет, это действительно просто для того, чтобы остановить будущие вращающиеся двери в WP:BN . — xaosflux ^Talk 18:06, 30 января 2024 (UTC) [ ответить ]
Система AIUI в английском Wikisource немного отличается, и у нее есть некоторые преимущества в плане безопасности: у них есть список людей, которые имеют право на это пользовательское право, и когда оно вам нужно, вы устанавливаете бит, делаете свою работу, а затем удаляете его. Когда оно вам не нужно, вы не делаете свою повседневную работу со всеми включенными привилегиями. Я не знаю, насколько это будет хлопотно, особенно если вам придется просить кого-то другого включить его для вас, но, возможно, стоит подумать об этом. WhatamIdoing ( talk ) 00:23, 7 февраля 2024 (UTC) [ ответить ]
@ WhatamIdoing Я только что проверил журнал прав пользователей на enwikisource за последний год и не увидел ни одного примера такого поведения — и только enwikisource 'crats могут изменить этот флаг; кроме того, я вижу enwikisource intadmin, который не использовался там больше года — так что я не думаю, что это то, о чем вы думаете? Возможно, вы думаете о флаге 'flood'? — xaosflux ^Talk 00:32, 7 февраля 2024 (UTC) [ ответить ]
Биллингхерст должен быть в состоянии сказать нам, если моя память неверна. Прошло много времени с тех пор, как я слышал об этом. WhatamIdoing ( talk ) 02:04, 7 февраля 2024 (UTC) [ ответить ]
Комментарий: Обычно мы не занимаемся редактированием в этой области. До того, как мы более формально обсудили это, у нас было краткосрочное распределение прав по запросу сообщества с легкой оценкой со стороны 'crat, отмечая гораздо меньшее сообщество администраторов и меньше скрипачей. У нас не было и не было самостоятельно установленных прав доступа. У нас есть самостоятельно установленные права доступа и права на затопление для администраторов. Обычно мы не хотим так много постоянных прав доступа и обычно не имеем в этом необходимости. — billinghurst sDrewth 02:29, 12 февраля 2024 (UTC) [ ответить ]

Обсуждение выше закрыто. Пожалуйста, не изменяйте его. Последующие комментарии должны быть сделаны на соответствующей странице обсуждения. Дальнейшие правки в это обсуждение не должны вноситься.