Обсуждение в Википедии: Политика в отношении ботов

Это не место, чтобы запрашивать бота, запрашивать разрешение на запуск бота или жаловаться на отдельного бота. Чтобы запросить создание бота, см. Википедия: запросы ботов . Чтобы запросить разрешение на запуск бота, см. Википедия: Боты / Запросы на одобрение . Чтобы сообщить о неисправных ботах, свяжитесь с оператором бота напрямую через его страницу обсуждения пользователя (или через страницу обсуждения учетной записи бота). Если оператор не отвечает, а бот продолжает вызывать проблемы, обратитесь к администратору на Википедии: Доска объявлений для администраторов .

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

Эта страница политики была упомянута медиа-организацией : Роберт Горва (23 октября 2017 г.). «У Twitter есть серьезная проблема с ботами, и Википедия может найти решение» . Кварц . Проверено 23 октября 2017 .

Проблемы с WP: BOTMULTIOP [ править ]

Я думаю, что в разделе «Боты, управляемые несколькими пользователями» есть несколько проблем.

1. Здесь используется определение «оператора», отличное от того, которое использовалось в нескольких разделах выше в WP: BOTACC . На самом деле, речь не идет об операторах (а-ля User: ClueBot NG или User: ArbClerkBot - буквально несколько операторов). Скорее, насколько я понимаю, речь идет о ботах, которые могут запускаться для работы другими пользователями (например, Citation Bot, возможно, AnomieBOT TfDTemplateSubster, CFDW и т. Д.). Это совсем другое дело. Действительно, «операторы» WP: BOTACC не могут и не выполняют (см. Вклад ClueBot или ArbClerkBot) критерии WP: BOTMULTIOP . Путаница, кажется, подтверждается очень низким использованием ярлыка- многие из этих обсуждений указывают на такую ​​же путаницу в определении. Изменять определения "оператора" на полпути через BOTPOL нецелесообразно. С этой целью, я думаю, нам следует переименовать этот раздел.
2. Какие ограничения действительно применяются к реальным нескольких операторов (например , Пользователь: ClueBot NG или Пользователь: ArbClerkBot ). Кто из операторов отвечает за правки бота, как указано в WP: BOTACC ? Я предполагаю, что «несколько операторов» - это люди, у которых есть доступ к учетной записи / серверу, на котором запущен бот.
3. В соответствии с обсуждением, которое я провел с Xaosflux , я думаю, что нам нужно уточнить / изменить ответственность оператора бота за изменения, инициированные другими пользователями. Хотя да, я согласен, что существует некоторая ответственность, если они выбирают свои собственные критерии, но если сообщество - это те, кто создал, установил и утвердил критерии через RfC, и другие администраторы являются теми, кто обеспечивает соблюдение критериев (например, добавление имен в список разрешений) Я не думаю, что логично возлагать ответственность на оператора бота за некорректное использование бота, равно как и на автора патчей для программного обеспечения MediaWiki для сисопа (предоставленных сообществом инструментов). череда блокировок. ( контекст , также бот автозащиты :Следует иметь в виду, что боты - это просто альтернативные учетные записи своего оператора, поэтому администратор, запускающий такого бота, должен будет нести личную ответственность за все меры защиты, которые они применяют, чтобы обеспечить соответствие политике защиты. )

ProcrastinatingReader ( разговор ) 11:41, 9 декабря 2020 (UTC)

@ ProcrastinatingReader : для администрирования, я думаю, нам нужно начать с политики администратора - если вы хотите, чтобы администратор мог делегировать свои полномочия другим, позволяя им запускать их без ручного просмотра ( WP: ADMINACCT ) в настоящее время возлагает на них личную ответственность за все, что они делают. - ^{Обсуждение} xaosflux 12:26, ​​9 декабря 2020 г. (UTC)

Разве это не небольшая уловка-22? afaik это считается делегированием полномочий только потому, что BOTPOL считает это так (какое изменение я прошу здесь)? Скажите, в упомянутом вами методе фильтра злоупотреблений, к кому применяются принципы ADMINACCT? Это не может быть фильтр и, вероятно, не человек, пишущий фильтр, так что, предположительно, это человек, который активировал фильтр? Думаю, я прошу, чтобы задачи, одобренные консенсусом, также рассматривались просто как технические реализации.

Я также думал, что этого требует часть BOTPOL «задача имеет консенсус». Насколько я понимаю, это в некоторой степени само собой разумеющееся, что все, что позволяет другим выполнять административные задачи, требует одобрения широкого сообщества (вероятно, о чем свидетельствует RfC с высоким участием), а бот является лишь технической реализацией этого (с, на мой взгляд, , небольшая разница в том, что это функция интерфейса MW). С практической точки зрения, я думаю, что меня беспокоит то, что, учитывая, что выполнение чего-либо в MediaWiki может быть проблемой, я подумал, что изменение BOTPOL, явно позволяющее сообществу делать эти вещи другим путем (если оно того пожелает), может помочь. ProcrastinatingReader ( обсуждение ) 13:25, 9 декабря 2020 г. (UTC)

AbuseFilter не имеет обычных полномочий администратора (по крайней мере, здесь, на enwiki), мы не разрешаем ему блокировать пользователей или IP-адреса, и он не может вносить изменения. Любой администратор, создающий плохой фильтр, будет нести ответственность за его провал - и если бы они сказали, что создали фильтр для получения преимущества в споре, это было бы столь же серьезно, если бы они сделали это любым другим способом. Общий принцип заключается в том, что человек не может делегировать свою ответственность, ответственность всегда возвращается к источнику. Думайте о действиях бота как о быстром выполнении того, что вы в противном случае сделали бы вручную. - xaosflux ^Talk 15:28, 9 декабря 2020 г. (UTC)

Пример концепции блокировки, скажем, я много работаю с WP: AIV - и это становится повторяющимся. Поэтому я делаю сценарий, который позволяет мне блокировать пользователей, о которых сообщают, одним щелчком мыши. Затем это становится повторяющимся, потому что мне все еще не нравится заглядывать в отчеты - возможно, я вижу там много отчетов от User: ProcrastinatingReader, поэтому я немного обновляю свой скрипт, в котором говорится что-то вродеIF (REPORTER = ProcrastinatingReader) THEN BLOCK REPORTED USER FOR 1 DAY). Затем это начинает повторяться, поэтому я просто делаю программу для постоянного запуска скрипта. Итак, что здесь произошло, в основном я делегировал все, о чем вы сообщаете, слепо блокировать. Снимает ли это с меня ответственность администратора применять только соответствующие блоки? Устраняет ли это высказывание «заблокировано по запросу ProcrastinatingReader» - я бы не подумал. Теперь, возможно, я бы сказал, что если бы это был созданный мной инструмент, который мог бы использоваться только людьми, которые изначально могли выполнять действие вручную (например, другие администраторы), он мог бы быть для них прокси - таким, чтобы отчет поддерживал ответственность за действие. Без этого вы столкнетесь с ситуацией, когда отдельные администраторы предоставляют доступ не администраторам без проверки сообщества, которая обычно требуется для администраторов. - ^{Обсуждение} xaosflux 15:28, 9 декабря 2020 г. (UTC)

Еще одна концепция ботов, о которой следует помнить, заключается в том, что ни один бот никогда не должен делать другое действие или редактировать. Так что «важные» процессы не должны строиться вокруг чьего-то бота. - xaosflux ^Talk 15:28, 9 декабря 2020 г. (UTC)

В общем, я не против создания неадминистраторов, которые могут применять больше технических средств контроля (например, блокировать, удалять и т. Д.) - просто это должно быть сделано в виде процесса предоставления полномочий сообщества, а не отдельного администратора, лишающего их индивидуальных полномочий. . - xaosflux ^Talk 15:28, 9 декабря 2020 г. (UTC)

@ Xaosflux : Думаю, я пока на одной с тобой странице. Если вы решили, что мои отчеты достаточно хороши, и создали скрипт или бот, который автоматически брал мои отчеты AIV и блокировал их, я согласен с тем, что вы несете ответственность за эти блоки в равной степени, как если бы вы просматривали каждый из них, даже если ошибочный отчет был моим. В основном, я полностью согласен с тем, что это должно происходить как процесс предоставления полномочий сообщества, а не как отдельный администратор, лишенный своих индивидуальных полномочий . Я говорю о тех случаях , когда община имеетсогласился что-то сделать. Скажем, RfC передает создание «группы», которая может блокировать IP-адреса с менее чем 100 правками, но обнаруживает, что разрешение на полную «блокировку» слишком велико, чтобы давать людям (не мое личное мнение, но все же гипотетически), поэтому функция требуется, чтобы блоки выполнялись только в том случае, если они соответствуют этому критерию. В этом гипотетическом RfC сообщество также говорит, что разрешение должно быть предоставлено любым администратором WP: PERM после минимального периода обсуждения. Итак: и концепция, и критерии установлены и одобрены сообществом, скажем, 200 редакторов за и 0 против.

Что ж, чтобы технически реализовать этот консенсус, это либо патч MediaWiki (предпочтительнее, но сложнее), либо бот (которым должен управлять кто-то). Теперь, из-за упомянутого вами принципа, действия бота являются расширением их оператора, если он запускается как бот, он считается таким же, как оператор администратора, в одностороннем порядке разрешающий неадминистраторам блокировать через свою учетную запись (и возможно, что администратор хочет взять на себя эту ответственность, поскольку это справедливое бремя). imo не должно быть разницы между запуском через бота или через программное обеспечение MediaWiki. Пока человек, запускающий запуск, может быть проверен в вики, а задача и критерии запуска широко одобрены сообществом RfC, я не уверен, почему это техническое различие актуально? Почему для этого нельзя использовать бота, если человек, который закодировал бота, не несет ответственности за то, чтобы каждый блок соответствовал WP: BP? Если, в качестве альтернативы, упомянутый оператор бота сделал патч MediaWiki для технических функций, выполняя в остальном то же самое, он освобождается от такой ответственности. Эта часть меня сбивает с толку. Та же самая недавно созданная политика, с тем же консенсусом, поддерживающим ее, тот же процесс предоставления прав и тот же индивидуальный блок одним и тем же человеком, но одна (возможно) проблематичная, если технически выполняется ботом, а другая в порядке, поскольку она через интерфейс MediaWiki? Есть ли причина, по которой к этим двум вещам следует относиться по-разному? ProcrastinatingReader ( разговор ) 16:16, 9 декабря 2020 (UTC)

Если вы пишете произвольный сценарий, чтобы что-то делать, вы определенно несете ответственность за то, что он делает. Однако предположим, что если сообщество, гипотетически, решит это "all users who have > x% accuracy at reporting users to AIV may have their future reports automatically actioned", и оператор бота напишет сценарий для реализации консенсуса сообщества, на самом деле это должно быть сообщество в целом (а не оператор бота), которое несет ответственность за блоки, поскольку бот оператор просто выполнял решение сообщества. Я не читал комментарий PR из-за его большой длины, прошу прощения, если я просто повторяю аргументы. - SD0001 ( разговор ) 17:31, 9 декабря 2020 г. (UTC)

Это хорошее начало для изучения подхода, он расширяет политику сообщества (в данном случае политику блокировки), чтобы конкретно разрешить администраторам делегировать ответственность за свои действия другим (которые, как я предполагаю, будут переданы администратору). политика стандартов при запуске другого администратора для выполнения их ставок?). - ^{Обсуждение} xaosflux 17:37, 9 декабря 2020 г. (UTC)

Наконец, прочитайте комментарий PR выше и хочу отметить, что полностью с ним согласен. Боты - мощные инструменты; возлагать на оператора ответственность за все действия, даже если они были инициированы другими разумными пользователями (которые знали, что они делают), - просто плохая политика, которая серьезно ограничивает потенциальную полезность ботов. Никто не захочет внедрять таких ботов, пока соблюдается эта политика. - SD0001 ( разговор ) 17:41, 9 декабря 2020 г. (UTC)

Да, это то, что я пытаюсь понять! Мой комментарий немного длинный, но я действительно пытался подчеркнуть, что описываемый мной сценарий - это сценарий, в котором существует консенсус сообщества, который необходимо реализовать, но патч MediaWiki невозможен. Я думаю, что важно отделить технические средства выполнения действия от фактического предложения, поддержанного консенсусом.

Более простой пример, и это было бы нелепо, но это вполне допустимый технический подход, чтобы продемонстрировать суть, рассмотрите одобренное сообществом руководство WP: TPE . Что, если бы редактор шаблонов существовал точно так же, как и сейчас (поддержка RfC, тот же процесс предоставления , отзыв и т. Д., Все одобрено сообществом), но люди не могут редактировать страницу напрямую (возможно, MediaWiki не может его поддерживать), поэтому им нужно отредактировать песочница, затем бот проверяет, является ли человек редактором шаблона, и (если да) копирует его код в действующий шаблон. Почему ботоп теперь внезапно берет на себя ответственность, если TPE испортился, и это изменение плохое? ProcrastinatingReader ( обсуждение ) 18:00, 9 декабря 2020 г. (UTC)

В этом случае BotOp получит разрешение на выполнение этой функции. AnomieBot срабатывает, когда кто-то добавляет в статью недатированный {{ cn }}. Если вандал добавит к статье 432 {{ cn }}, Anomie не в беде, потому что бот расширил их все. Бот не вышел из строя, он сделал именно то, что должен был делать. Headbomb { t · c · p · b } 18:25, 9 декабря 2020 г. (UTC)

Верно, и я думаю, что именно здесь мы возвращаемся к MULTIOP и всей этой штуке «админ / защита бота», которая есть в AN. Если у бота есть согласие блокировать / защищать / что-то еще, на основе установленных правил, с которыми согласилось сообщество, бот (или оператор бота) не «виноват», если кто-то намеренно нарушает эти правила, чтобы получить верх рука и т. д. Primefac ( разговор ) 20:36, 9 декабря 2020 (UTC)

Чтобы проигнорировать вышесказанное и вернуться к исходному пункту, я думаю, что необходимо небольшое пояснение; Оператор - это тот, кто «владеет» и обслуживает бота. Однако есть боты, которые могут запускаться другими пользователями (как описано выше); именно те редакторы несут ответственность за правки, вносимые ботом, который они запускали (что, насколько я помню, является причиной ограничений в отношении того, кто может запускать Citation Bot или редактировать страницу TFDSubster AnomieBOT). Primefac ( разговорное ) 20:36, 9 декабря 2020 (UTC)

В случае с CitationBot ограничения в основном существуют для предотвращения его использования заблокированными пользователями. Headbomb { t · c · p · b } 20:44, 9 декабря 2020 г. (UTC)

( конфликт правок ) IIRC (но я, возможно, не R-ing C), WP: BOTMULTIOP был написан для случаев, когда инструмент на Toolserver позволял людям вручную ставить в очередь произвольные правки, которые затем применялись связанной учетной записью бота. Некоторые люди вносили неправильные правки с помощью этого механизма, но не было возможности сказать, кто виноват. Даже если и были журналы, они были недоступны для обычных редакторов вики. Теперь, когда у нас есть такие вещи, как OAuth, таких инструментов, вероятно, больше не существует, поскольку теперь они могут использовать OAuth для редактирования через учетную запись запрашивающего пользователя.

Что касается ответственности за такие вещи, как TemplateSubster от AnomieBOT и TFDTemplateSubster, я думаю, что это сводится к совместной ответственности. Оператор бота должен включать соответствующие меры безопасности для ограничения злоупотреблений и реагирования на любые серьезные случаи злоупотреблений, в то время как любой нарушитель несет ответственность за свои действия, нарушающие его. Должен ли бот идентифицировать инициирующего пользователя или нет, вероятно, зависит от специфики задачи, например, насколько легко найти ответственного пользователя постфактум. Anomie ⚔ 20:45, 9 декабря 2020 (UTC)

Правильно. Я не думаю, что TFDSubst нужна такая атрибуция (поскольку история определить несложно), но она потенциально полезна для людей, запускающих бота Citation. Primefac ( разговор ) 21:39, 9 декабря 2020 г. (UTC)

Ответственность за неисправность там по-прежнему лежит на операторе бота, поскольку люди, активирующие бота, в конечном итоге не контролируют его действия. Там знание того, кто запустил бота, в основном помогает увидеть, кто заинтересован в статье, и (возможно) отфильтровать редакторов-новичков от запуска массового запуска. Был один случай преследования, который привел к блокировке (редактора преследования, а не бота), и после этого в качестве меры безопасности была реализована идентификация редактора на основе OAuth. Хотя его можно было бы сделать частью BOTPOL, я считаю, что его будет сложно кодифицировать, поскольку он сильно зависит от задачи бота. Насколько я понимаю, это то, что следует отметить во время BRFA, а не предупреждать на уровне BOTPOL. Головная бомба { t · c ·p · b } 22:31, 9 декабря 2020 г. (UTC)

Снятие ограничений в программном обеспечении [ править ]

На WPPOL есть текущая ветка : VPPOL # Huggle & Rollback, которая, я думаю, заслуживает здесь некоторого внимания. Игнорируя конкретного пользователя (который может быть обсужден там) и конкретный поток (этот WP: PERM предположительно является проблематичным процессом), пользователь был достаточно техническим, чтобы изменить Huggle, чтобы удалить проверку разрешений для отката. Впоследствии он использовал это программное обеспечение в вики.

Еще один инструмент, на который это влияет, - это WP: AWB , который реализует проверку CheckPage на предмет отсутствия администраторов и ботов или того, что вы являетесь администратором по умолчанию.

Я рассматриваю этот выбор как WP: GAMING . По крайней мере, двое других пользователей либо сказали, что это не ИГРА, либо не считали, что это может быть ИГРОВОЙ.

Следует ли в этой политике что-либо сказать о скриптовых инструментах, изменяемых для обхода социальных элементов управления в инструменте, который может быть реализован в инструменте напрямую как ИГРОВОЙ (а не, например, WP: AWB, имеющий социальные элементы управления внешними по отношению к этому программному обеспечению в WP: AWBRULES ), или факт, что это ИГРЫ, на самом деле является логическим выводом, и мы только что нашли двух пользователей, которые пришли к другому выводу? - Изно ( разговорное ) 21:42, 18 декабря 2020 г. (UTC)

Копирую мой ответ:

Думаю, добавить в BOTPOL действительно проблематично. Насколько приемлемо изменение AWB до тех пор, пока оно не перестанет считаться AWB, и я могу использовать AWB без запроса доступа к AWB? Что, если я сделаю свой собственный сценарий с нуля, чтобы делать то же самое (конкретное полуавтоматическое редактирование)? Что, если я основываю этот скрипт на регулярных выражениях AWB? Похоже на ситуацию с Huggle. Здесь невозможно провести линии, поэтому установить для этого BOTPOL-ограничение сложно. Если проблема связана с откатом, примените ограничение к этому руководству , но, честно говоря, я думаю, что ничего не следует делать, если не будет показано, что сами измененияподрывные, проблемные антивандалистские правки. Это также единственное имеющее исковую силу средство правовой защиты. Кроме того, если правки не вызывают проблем, я не понимаю, в чем заключается большая проблема. И довольно редко кто-то действительно способен отредактировать исходный код инструмента и перекомпилировать его, так что, я думаю, это не та вещь, над которой стоит законодательно регулировать - от этого будет больше вреда, чем пользы. ProcrastinatingReader ( разговор ) 21:56, 18 декабря 2020 г. (UTC)

Чтобы добавить: публикуя инструмент под разрешенной лицензией, вы соглашаетесь с тем, что люди могут его редактировать. У нас также нет политики, требующей от людей получения каких-либо конкретных прав, прежде чем они смогут использовать полуавтоматические инструменты в целом. Таким образом, независимо от того, используете ли вы конкретный инструмент, модифицированную версию этого инструмента, производную от этого инструмента или свой собственный полностью настраиваемый инструмент, все это равнозначные вещи. В некоторой степени нелогично (и, следовательно, не имеет исковой силы или только произвольно) пытаться ограничить объем редактирования, который кто-то может сделать с инструментом, пока он не сделает слишком много, и это отдельный инструмент. Черт возьми, как вы вообще можете доказать, что кто-то редактировал инструмент? Что, если они перекодировали половину инструмента иудалили требование разрешения, решив, что они не хотят, чтобы их производная имела это ограничение. Это тоже сейчас недопустимо? ProcrastinatingReader ( обсуждение ) 22:01, 18 декабря 2020 г. (UTC)

• Две вещи: во-первых, программное обеспечение находится под открытой лицензией, они могут делать с ним практически все, что захотят. Если они хотят удалить проверку или средство отката, они могут. Во-вторых: все редактирование, подобное ботам, подпадает под BOTPOL. Если пользователь использует инструмент редактирования для редактирования таким образом, чтобы он не превышал порогового уровня, чтобы быть ботом / бот-подобным / автоматизированным для MEATBOT, в настоящее время нет политики, запрещающей это. Если пользователь использует инструмент редактирования, чтобы упростить действия, которые он делает в вики, и не требует для этого определенных разрешений, то нет политики, запрещающей это. Если мы хотим, чтобы люди не использовали инструменты редактирования, которые * имитируют * действие в вики, например откат, нам нужно: а) добиться согласия редакторов, которые не должны выполнять задачи, для выполнения которых обычно требуются права пользователя, и б) добавить, что формулировку соответствующей политики. Вероятно, наиболее вероятным виновником здесь является Botpol, поскольку он наиболее тесно связан с автоматизированными инструментами. Как бы то ни было, я лично не думаю, что редакторы должны выполнять задачи, имитирующие откат, без соответствующего права. Смысл получения * разрешения * на что-то заключается в том, что это проверка того, есть ли у человека суждение сделать что-то, а не только технические возможности.Только смерть заканчивает долг ( разговор ) 22:25, 18 декабря 2020 (UTC)
• Каждый может изменять любое программное обеспечение с открытым исходным кодом по своему усмотрению, включая проверку разрешений. Тем не менее, мы можем: а) запретить использование такого программного обеспечения; б) запретить блокировку тех, кто его использует, согласно WP: DE . На практике? Блок WP: DE будет выдан тем, кто обходит проверки и нарушает правила с его помощью. И если User: Example удаляет разрешение из Huggle, но не редактирует с его помощью, кого это волнует. WP: этим управляет не BOTPOL , это WP: DE и WP: CLUE . Головная бомба { t · c · p · b } 22:55, 18 декабря 2020 г. (UTC)
• Требовалось ли одобрение в первую очередь? В случае «отката с Huggle» вопрос состоит из двух частей:
  1. Может ли неутвержденный редактор использовать Huggle для отката? и
  2. Может ли неутвержденный редактор использовать другой инструмент или создать свой собственный с нуля для выполнения откатов?

Ответ на первый вопрос однозначно «нет». Ответ на второй - «да». Если это правда, то «изменение Huggle для отката» должно быть разрешено. Если это не так, то необходимо уточнить язык политики бота, чтобы запретить использование любого инструмента для отката, кроме того, который предоставляется самой Википедией, если у вас нет этого права пользователя.

В качестве примечания: любой редактор, вошел в систему или нет, может выполнить откат, просмотрев историю редактирования, выбрав самое последнее изменение другим редактором, открыв его и сохранив. Это можно сделать довольно быстро, не задумываясь, и, как говорится в политике WP: Bot , со всей ответственностью, связанной с использованием автоматизированного инструмента. Я упоминаю об этом только для того, чтобы сказать, что если мы запретим автоматическим и полуавтоматическим инструментам выполнять откат, мы не помешаем людям откатывать изменения, не задумываясь об этом. davidwr / ( talk ) / ( вклад ) 🎄 23:25, 18 декабря 2020 г. (UTC)

В WP: ROLLBACK следует учитывать особенности отката . WP: CLUE и WP: DE покрывают все остальное. Headbomb { t · c · p · b } 23:32, 18 декабря 2020 г. (UTC)

@ Davidwr : «откат» - это особая техническая операция, которая выполняется на стороне сервера, ни один редактор не может инициировать откат без разрешений на откат. Обратите внимание, это не имеет ничего общего с «откатом», только с «откатом». - ^{Обсуждение} xaosflux 00:11, 19 декабря 2020 г. (UTC)

Проблема здесь не в WP: DE . См. Обсуждение пользователей: ChipWolf . Предыстория этого раздела состоит в том, что редактор был заблокирован за то, что сделал 3 правильных (как заявил там администратор), Huggle возвращается, но не выполняет откат. В этом нет ничего разрушительного - по определению, 3 хороших отката не помешали прогрессу в улучшении статьи или создании энциклопедии - хотя один вполне может оказаться на более коротком поводке, если они испортят его, и, следовательно, это нецелесообразно. В любом случае, я думаю, что это проблема WP: ROLLBACK (как я сказал на VPP). afaik нет PAG, поддерживающего этот блок, и блок на основе возможного «неявного консенсуса» (особенно без предупреждения) - это meh. ProcrastinatingReader (разговор ) 23:37, 18 декабря 2020 (UTC)

@ Davidwr : насколько я понимаю, строка здесь, похоже, связана с частотой, с которой инструмент может редактировать. Предположительно инструмент будет считаться требующим отката, если частота, которую он может редактировать, превышает некоторый приемлемый порог. Я предполагаю, что это должно быть достигнуто с помощью ограничения скорости API (для пользователей без явного разрешения), а не социальной политики. Общий запрет на использование всех инструментов, кроме тех, что в белом списке, вызовет больше проблем imho ~ Chip 🐺 01:10, 19 декабря 2020 г. (UTC)

Проблема здесь не в частоте, и блоки для этого не ограничиваются Huggle / откатом. См., Например, это . Проблема, похоже, в том, что некоторым людям не нравится, что другие люди редактируют исходный код, чтобы отключить ограничения доступа, установленные разработчиками инструментов, и рассматривают это как «игру». Если бы вы сделали свой собственный высокочастотный инструмент редактирования и использовали его должным образом, по-видимому, никого это не волновало; вы бы ограничиваться только политикой на WP: ОБДУВ и WP: MEATBOT если разрушительные. ProcrastinatingReader ( разговор ) 01:20, 19 декабря 2020 (UTC)

Надеюсь, мы сможем установить, где находится эта линия; как я кратко упомянул ниже, если у людей действительно есть проблема с изменением инструментов с открытым исходным кодом с ограничениями для их собственного использования, как это будет эффективно реализовано в политике? Разумеется, существует вопрос о том, насколько убогим должен стать код, прежде чем он станет приемлемым для использования, и как это можно будет обеспечить для обеспечения справедливости? Я считаю, что практически невозможно обеспечить соблюдение, поскольку операции, выполняемые этими инструментами, по сути идентичны, они просто позволяют пользователю по-разному, что полностью прозрачно для других редакторов. ~ Чип 🐺 01:39, 19 декабря 2020 (UTC)

• @ Izno : Ваше первоначальное резюме, похоже, не имеет ничего общего с «ботами», поэтому я не думаю, что проблема в политике ботов. Если бы это программное обеспечение использовалось настоящим ботом, это все равно не имело бы значения - пока бот работал в рамках утвержденных задач. Что касается возможной реальной проблемы - если кто-то нарушает правила редактирования, с ним следует обращаться как с разрушительным редактором, независимо от того, используют ли они скрипты, веб-интерфейс, api, свое собственное программное обеспечение или чужое программное обеспечение. Если человек выполняет редактирование как бот, не будучи утвержденным ботом - это уже неприемлемо, нам не нужны новые специальные правила для его контроля. - xaosflux ^Talk 00:06, 19 декабря 2020 г. (UTC)

  Я думаю, что Изно говорит о внесении изменений в WP: ASSISTED, чтобы сказать что-то вроде «Инструменты, в которых разработчик пытался ограничить доступ к определенным редакторам, должны использоваться только этими редакторами. Попытки обойти эти элементы управления являются нарушением этой политики». (что я считаю плохой идеей по причинам, указанным выше) ProcrastinatingReader ( talk ) 00:13, 19 декабря 2020 г. (UTC)

  Не думайте, что нам вообще нужна политика по этому поводу - если кто-то нарушает правила, это уже является достаточной причиной для вмешательства, а если нет, то зачем это нужно? - ^{Обсуждение} xaosflux, 01:03, 19 декабря 2020 г. (UTC)

  Это была моя первоначальная мысль, и она возвращается к обсуждению открытого исходного кода; в какой момент этот инструмент по-прежнему считается тем же самым инструментом, и действительно, как вы могли бы доказать или обеспечить соблюдение такой политики? Если нет вреда в вики или намерения причинить вред, я не думаю , что другие редакторы должны заботиться ~ Чип 🐺 01:27, 19 декабря 2020 (UTC)

  Я согласен с Xaosflux: если чье-то использование {huggle, AWB, скрипта pywikibot, их собственного полностью настраиваемого инструмента} является разрушительным, то относитесь к нему как к любому разрушительному редактированию. Если их скорость редактирования настолько высока, что они наводняют списки наблюдения или последние изменения, скажите им, чтобы они установили флаг бота. У нас уже есть очень четкие правила для обоих этих случаев, независимо от того, какой инструмент используется. Если они не нарушают порядок, то кого это волнует? Использование Huggle без разрешения не более разрушительно, чем использование pywikibot без разрешения. Контрольная страница хороша для отсеивания полных новичков, но любой, кто способен перекомпилировать Huggle или AWB, также способен читать документацию Mediawiki API и писать свой собственный инструмент. Пользователи могут изменять бесплатное программное обеспечение. Это, наверное, суть «свободных программ», и это прямо разрешено в соответствии с лицензионной информацией, распространяемой как часть Huggle. Мы не должны блокировать редакторов с хорошей репутацией только потому, что они использовали часть бесплатного программного обеспечения без «разрешения».ST47 ( разговор ) 03:44, 19 декабря 2020 (UTC)

  @ ST47 : Прошу прощения за опоздание, я только что нашел это обсуждение. Боюсь, я не полностью согласен с этим. Проблема с простым ожиданием, пока неавторизованный пользователь вызовет сбой, заключается в том, что с помощью таких инструментов, если пользователь действительно нарушает работу, они становятся оченьразрушительный. Возможно, нам придется не только заблокировать, но и проверить сотни и сотни правок, которые были отправлены за короткое время, чтобы отреагировать на нарушение. Да, это «бесплатное программное обеспечение», то есть лицензирование позволяет редакторам разветвлять и модифицировать программное обеспечение, точно так же, как CC BY-SA позволяет редакторам копировать содержимое одной статьи и вставлять его поверх другой статьи при условии указания авторства - но это не означает, что это всегда хорошая идея. Тот факт, что пользователь достаточно технически квалифицирован, чтобы перекомпилировать такой инструмент, как Huggle, не обязательно означает, что ему можно доверять в его ответственном использовании. Если редактору было отказано в доступе к Huggle или AWB традиционными способами, по-видимому, для этого есть веская причина (ошибка администратора действительно случается, но технический обход, безусловно, не является решением этой проблемы).Mz7 ( разговор ) 06:01, 27 декабря 2020 (UTC)

  Я также должен уточнить, что я не обязательно думаю, что блокировка является первым средством в случае, когда редактор совершил такой обход, но я обеспокоен тем, что мы, похоже, узакониваем этот вид обхода, когда его следует препятствовать или запрещать. . Mz7 ( разговор ) 06:12, 27 декабря 2020 (UTC)

  AWB используется для поиска + замены так же, как pywikibot. Я могу написать несколько строк кода поверх pywikibot, чтобы выполнить полуавтоматический поиск + замену без использования AWB / JWB, и это вполне приемлемо без каких-либо разрешений. Pywikibot не имеет контрольной страницы. Или, может быть, я могу написать свои собственные запросы API, как это делает ProcBot. Он будет с той же (или более высокой) скоростью, таким образом, такой же / больший «урон». Так что идея о том, что можно написать этот код, и все в порядке, но нельзя редактировать код AWB, нелогична, imho. Кроме того, где вы проводите черту, если мы сейчас разрабатываем политику в отношении исходного кода для разработчиков? Если завтра pywikibot скажет, что «пользователи должны быть + сисопом, чтобы использовать этот инструмент», 95% ботов должны прекратить свои операции? Вот почему я говорю, что не думаю, что кто-то, отстаивающий эту позицию, действительно продумал это. ProcrastinatingReader ( говорить) 11:47, 27 декабря 2020 г. (UTC)

  @ ProcrastinatingReader : Я не верю в этот аргумент о скользкой дорожке. Если завтра pywikibot скажет, что пользователи должны быть + сисопом, чтобы использовать этот инструмент, это, конечно, было бы нелепо, и у нас было бы обсуждение, чтобы отменить это (примечание: правильным ответом будет обсуждение). Однако требование предварительной авторизации для использования Huggle и AWB является давним ожиданием сообщества в отношении этого проекта, и нет никакого смысла в том, что мы позволяем редакторам намеренно обходить это ожидание. (На самом деле, на мой взгляд, даже если мы говорим здесь, что разработчики не могут в одностороннем порядке налагать технические ограничения на свои инструменты, требования страницы отката и проверки в узком контексте Huggle и AWB больше не являются просто «исходным кодом разработчика», но полноценные ожидания сообщества.)

  Что касается вашего примера find + replace pywikibot, мне кажется, что причина, по которой у нас в настоящее время нет контрольной страницы для pywikibot, заключается в том, что pywikibot требует нетривиального количества технических навыков для правильного использования, и исторически только опытные редакторы заинтересованы достаточно, чтобы изучить его, поэтому мы не стали беспокоиться о какой-либо предварительной проверке. Как только какой-либо технически подкованный LTA выясняет, как использовать pywikibot на регулярной основе, чтобы сорвать проект в широком масштабе (что, конечно, не выходит за рамки возможного, и я говорю, что это честно может быть WP: BEANS ), я подозреваю, что сообщество благосклонно отнесется к наложению каких-либо ограничений на использование pywikibot. Другими словами, pywikibot представляет собой скорее исключение, чем норму в этой области, и я не могу не рассматривать это как своего родаРГ: ДРУГАЯ ситуация. Mz7 ( разговор ) 19:23, 27 декабря 2020 (UTC)

  Это обсуждение политики, а не обсуждение удаления, поэтому OSE вполне допустима imo. Не учитывать более широкие последствия политики - это плохо при разработке политики. Я не понимаю, что такого законного в ограничении РБ и незаконного в ограничении сисопа. И, увы, если удалить тег на AWB и, возможно, отключить генфиксы, довольно сложно / невозможно определить, используется ли AWB, pywikibot или необработанные запросы API. И я не думаю, что это имеет значение. Но, думаю, я сказал свое слово. ProcrastinatingReader ( обсуждение ) 00:01, 28 декабря 2020 г. (UTC)

  Любой, кто способен написать цикл for, может вызвать массовые сбои. Использование pywikibot и большинства других инструментов требует большего знания программирования, а не опыта работы с Википедией, или, другими словами, им не нужно быть «опытными редакторами». Невозможно ограничить использование pywikibot политикой, потому что в первую очередь невозможно определить, кто использует pywikibot. Точно так же для Huggle и других инструментов, если кто-то взломает инструмент и заставит его использовать другие теги и редактировать сводки, отличные от того, что инструмент обычно использует, никто не может сказать, что он использует этот инструмент. Политика всегда должна быть обеспечена правовой санкцией, запрет на использование вилок Huggle не является обязательной политикой. В лучшем случае это может быть «обескураженная практика». - SD0001 ( разговор) 17:37, 28 декабря 2020 г. (UTC)

  Хм, это хороший момент. Я полагаю, что редакторы всегда могут запутать действия своих инструментов, чтобы они выглядели так, как будто они редактируют вручную, и мы мало что можем сделать, кроме ограничения редактирования API как такового. С другой стороны, это возможно для людей , которые были заблокированы на неопределенное время, чтобы просто вернуться через несколько месяцев под новым именем пользователя и попытаться запутать свою деятельность таким образом , они остаются незамеченными, что не означает , что такое поведение не может быть запрещено по политика . По крайней мере, я был бы удовлетворен , если результат этого обсуждения является четким пониманием того, что такое поведение не является законным -ie , если пользователь фиксируемый взломали Huggle с явным намерением обойти ограничение отката, они должны быть попросили остановиться. Mz7( разговор ) 23:04, 28 декабря 2020 (UTC)

• Гипотетическая ситуацияподумать над этим, решая этот вопрос: что, если редактор, не относящийся к Википедии, создаст полуавтоматический инструмент, который может вернуться в исходное состояние очень быстро, так же быстро, как Huggle или быстрее. Допустим, он делает это, потому что ему это нужно в проекте, отличном от WMF, который использует программное обеспечение Викимедиа. Теперь предположим, что он издает это в какой-то форме. Может, он его продает, может, раздает «бесплатно, как в пиве». Может быть, он откроет это. Неважно. Это там. Если предлагаемое нами решение хотя бы не учитывает эту возможность, значит, оно не очень хорошо продумано. «Признать возможность» может быть таким же простым, как «пнуть консервную банку с дороги», говоря: «Да, это может произойти, если это произойдет, мы рассмотрим это в то время, а пока, мы» davidwr / ( talk ) / ( вклад ) 🎄 19:39, 27 декабря 2020 г. (UTC)

  Я вступил в конфликт с вами, поэтому мой ответ охватывает изрядную часть «ответа» на вашу ситуацию, но как TLDR не имеет значения, что они используют - если это подрывает, мы их санкционируем. Если нет, значит, нет. Primefac ( разговор ) 19:43, 27 декабря 2020 (UTC)

  Я рассматриваю это как индивидуальный подход, когда мы обсуждаем новые инструменты по мере их появления. Если новый инструмент предлагает функциональность, идентичную Huggle, я, вероятно, поддержу ограничение инструмента для откатчиков в качестве решения сообщества. Однако мое понимание этого обсуждения больше касается пользователей, которые намеренно уклоняются от какого-то давнего ограничения на существующий инструмент, который, как я утверждаю, легко отличить от тех, кто добросовестно создает новый инструмент с нуля. Ключевым моментом здесь является намерение. Намереваются ли они обойти давнишние ожидания сообщества, или они на законных основаниях намереваются создать новый инструмент для внесения вклада в энциклопедию? Если это первое, то я думаю, что их следует попросить сначала остановиться и запросить соответствующее разрешение, что обычно не должно иметь большого значения, если они действительно заслуживают доверия, чтобы использовать инструмент ответственно. Mz7 ( разговорное ) 22:21, 27 декабря 2020 (UTC)

• Если пользователь вызывает сбой, неважно, использует ли он AWB / Huggle / Twinkle или какой-либо «взломанный» вариант, он будет наказан. У нас были редакторы, которые использовали свои собственные сценарии для быстрого редактирования; некоторые были обеспокоены нарушением, другие, наконец, поняли, что сообщество было серьезным, и, так сказать, "замедлили свой ход". На мой взгляд, конкретные инструменты не имеют значения, проблема заключается в их реализации. Сказать что-то вроде «вы можете использовать только AWB и ни одну другую вещь для массового редактирования», на мой взгляд, глупо и, вероятно, причина, по которой WP: MEATBOT ничего не говорит о конкретных инструментах. Primefac ( разговор ) 19:43, 27 декабря 2020 (UTC)
  • Происхождение MEATBOT идет еще дальше. Некоторые люди массово создавали статьи в стиле ботов, но заявляли, что они вообще не использовали автоматизацию в качестве попытки защиты. Основной дискуссией, приведшей к добавлению, был доклад в Википедии: Политика ботов / Архив 24 # Разъяснение относительно высокоскоростного редактирования, сделанного человеком . Anomie ⚔ 14:48, 28 декабря 2020 (UTC)