Википедия:Заявки на статусы инженера и администратора интерфейса/Архив/2020

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Serhio Magpie[править код]

Открываю заявку на подтверждение флага администратора интерфейса согласно решению АК:1076 (ч.2 п.2.2.5). Правки с использования флага совершаю достаточно регулярно (список). Двухфакторная авторизация включена с момента получения флага инженера. Serhio Magpie (обс.) 23:55, 28 января 2020 (UTC)[ответить]

Вопросы (Serhio Magpie)[править код]

  • Это наверное должен быть вопрос не только к вам лично, а к АИ вообще, но поскольку в вашем относительно свежем вкладе есть создание нового гаджета: есть ли на него документация? Как вы считаете - достаточно ли документированы в целом разработанные у нас гаджеты и прочий код? — Lev (обс.) 07:06, 29 января 2020 (UTC)[ответить]
    • Это не совсем свежий гаджет, а небольшая переработка Википедия:Гаджеты/Выделение неоднозначностей в связи с возникновением коллизий. В старом варианте всплывающая подсказка была выполнена с помощью стилей, а с появлением функции предпросмотра страниц, накладывалась на последнюю. Вторая проблема была описана на техническом форуме. После переработки, чтобы не дублировать одну и ту же информацию, подсказка отображается стандартными возможностями браузера вместо стилей, и только когда отключён предпросмотр страниц. В документации гаджета я дополнил используемые файлы, но конечно стоило бы уточнить, что кроме выделений появляются и всплывающие подсказки.
      К сожалению документация наших гаджетов желает лучшего. Далеко не всегда указаны используемые ресурсы, как например в Википедия:Гаджеты/Зачеркнуть заблокированных, только знающий специфику определения гаджетов может найти нужный файл. На прошлом примере также видно насколько документация, как и сам код гаджета, устарели. Пользовательский скрипт «Lupin’s popups», написанный в середине нулевых, уже давно помечен как deprecated. Наши общесайтовые стили и скрипты в целом в приемлемом состоянии — к каждому блоку содержат пояснительные комментарии.
      Как по мне хороший код не требует комментариев, ну а плохой… лучше потратить время на его улучшения вместо комментирования :) В своём коде, если функция получается объёмной и нет необходимости её разбивать, я обычно на автомате добавляю краткую пометку что в следующем блоке будет происходит, а так же на не очевидную специфику, вроде нюансов в работе api или кросс-браузерных заморочек. Serhio Magpie (обс.) 18:53, 29 января 2020 (UTC)[ответить]

Обсуждение (Serhio Magpie)[править код]

Итог[править код]

Причин сомневаться в технической грамотности участника нет, цели получения флага вполне очевидны, ответ на заданный вопрос подробный и резонный, обсуждение показывает очень высокий уровень доверия. Флаг подтвержден. — Lev (обс.) 20:34, 3 февраля 2020 (UTC)[ответить]


Jack who built the house[править код]

Подаю заявку на подтверждение полномочий администратора интерфейса. Обладаю ими больше трёх лет, совершил 918 действий, требующих их (например, см. правки в MediaWiki), и пока планирую совершать и дальше. Принципы безопасности понимаю и безопасность учётной записи оберегаю. — Джек (обс.) 03:14, 29 января 2020 (UTC)[ответить]

Вопросы (Jack who built the house)[править код]

  • Коллега, с вашего позволения вопрос (я не очень хорошо разбираюсь в JS, заранее извиняюсь за глупости). Вот эта правка: правильно ли я понимаю, что вот эта строка var events = $._data( document, 'events' ); – a) инвариант цикла (вы ее вынесли за цикл в одной из последующих правок) и б) если она вернула "пусто" цикл можно вообще не запускать?— Lev (обс.) 06:08, 29 января 2020 (UTC)[ответить]
    • Ммм, зависит от того, что мы понимаем под инвариантом. Если брать именно выражение $._data( document, 'events' ), под инвариантом понимать величину, остающуюся неизменной (что несколько отличается от точного значения термина «инвариант цикла»), а под величиной, если мы говорим об объекте, — набор всех свойств объекта и их значений, а не ссылку на этот объект (дело в том, что приведённое выражение возвращает объект, а в JavaScript объекты передаются по ссылке (reference), а не по значению (value), то есть объект может изменяться, но сравнение (===) переменных, которым он был присвоен в разное время, всегда будет возвращать true), то нет, это не инвариант: строки
                  $( document )
                    .off( property, event.selector )
                    .on( property, event.selector.replace( regexp, '' ), event.handler );
      
      подспудно изменяют значение этого выражения, удаляя и добавляя события к документу. Сама функция внесённого этой правкой кода в том, чтобы скорректировать некоторые свойства событий, которые «повешены» на документ, так что инвариантом выражение, возвращающее коллекцию этих событий, быть никак не может.
      Возможно, вы заметили инвариантность в том, что одно событие удаляется, а другое, того же типа, добавляется, то есть сам факт присутствия события данного типа остаётся неизменным. То есть под инвариантом понимается набор ключей, без значений. Тогда да, это инвариант.
      Если выражение вернуло пусто (undefined), цикл, да, можно вообще не запускать (на практике на document в обязательном порядке «повешены» много событий, и выражение всегда что-то вернёт, так что проверка на заполненность ниже выполняется в основном как мера предосторожности). — Джек (обс.) 11:56, 29 января 2020 (UTC)[ответить]
      • Спасибо за ответ. Еще небольшой вопрос: все эти правки были совершены вами на протяжении очень короткого времени, чуть более часа, и закончились практически полной отменой исходно вставленного кода. Есть ли у администраторов интерфейса техническая возможность, а главное - практика отлаживаться не на живой ру-вики? Какова по вашему мнению должна быть оптимальная практика внесения изменений в скрипты затрагивающие многих, если не всех участников? — Lev (обс.) 13:04, 29 января 2020 (UTC)[ответить]
        • Ну, отлаживания как исправления ошибок, которые бы проявляли себя у живых пользователей, тем более драматически, тем более у большого их количества, там не было, и я бы никогда не стал записывать код, в котором недостаточно уверен в этом отношении (пожалуй, единственное исключение — когда всё изначально сильно поломалось и надо чинить как можно быстрее, а сильнее мы уже не сломаем). Хотя, конечно, бывают недогляды. Но этот код с самого начала, по моей оценке, работал успешно у всех посетителей; в дальнейшем происходила лишь его полировка «до блеска». Почти полной отменой всё закончилось по счастливому случаю — оказалось, что интересующий нас функционал MediaWiki проверяет свою включённость каждый раз, когда себя проявляет, а не один раз после загрузки, что, в общем-то, довольно контринтуитивно. Даже обнаружив это, я вначале не планировал убирать внесённый код, потому что он делал всё капитально, а инструкция, отсылающая к чужому коду, может повести себя непредсказуемо. И только проверив всё, я его убрал. Так что то, что может выглядеть как отлаживание по живому, на практике чаще всего является чем-то средним между доведением до блеска, оптимизацией, исправлением второстепенных недочётов и редких случаев, ну и на взаправдашние косяки тоже сделаем скидку.
          А что касается возможности и практики отлаживаться не на живом проекте — у нас, конечно, несколько связаны руки по сравнению с разработчиками MediaWiki. Мы имеем доступ (в плане возможности тестирования) не ко всему объёму кода, а только к маленькому его сегменту и до того, как запишем код, не можем предусмотреть всех зависимостей от остального кода (мы можем сталкиваться, в частности, с проблемами из разряда race condition, но самый крупный косяк такого рода на моей памяти — висевший у части пользователей до весны снеговик в 2016 году, когда проблема лежала в специфике взаимодействия нашего кода с кодом MediaWiki и никто был как бы не виноват, хотя скорее, конечно, виноваты были разработчики MediaWiki, которые впоследствии исправили свою оплошность). Поэтому определённая часть действий всегда будет выполняться «по живому», с долей неизвестности. Но в подавляющем большинстве случаев, конечно, можно и нужно тщательно всё предварительно тестировать, и в целом, по моему опыту, все этому стараются следовать. Оптимальная практика — если сильно переделывается большой скрипт, затрагивающий многих, наилучшим вариантом может быть отладка его как персонального скрипта. Более мелкие изменения можно тестировать через инструменты разработчика, присутствующие в современных браузерах. — Джек (обс.) 15:32, 29 января 2020 (UTC)[ответить]
          • > Но этот код с самого начала, по моей оценке, работал успешно у всех посетителей
            Сейчас закопался в этот код и таки нашёл одну ошибку, которая могла без видимых последствий проявлять у себя у очень узкого класса участников, сомневаюсь, что такой был хоть один. — Джек (обс.) 00:16, 30 января 2020 (UTC)[ответить]
  • Среди персональных скриптов, используемых многими участниками, некоторые принадлежат участникам, не правившим уже несколько лет. Как бы вы оценили риски в случае захвата учётных записей этих участников? С точки зрения безопасности стоит ли переносить активно используемые скрипты из личного пространства? NBS (обс.) 16:55, 30 января 2020 (UTC)[ответить]
    • Я не вижу на данный момент удачной конструкции, которая позволила бы сохранить все возможности для продолжения разработки скрипта, что включает сохранение для разработчика скрипта возможности его править, и устранить все риски безопасности. Забирать у разработчика возможность править собственный скрипт может быть не вполне этичным, вдобавок к тому, что неполезным. Персональные скрипты участники по умолчанию ставят по своему усмотрению, на свой страх и риск, о чём уведомляет плашка над полем редактирования.
      С другой стороны, перенос персональных скриптов участников, которые вряд ли вернутся к их разработке, тоже не выглядит чем-то неправильным. Но смотреть на каждого из немногих, в общем-то, разработчиков популярных персональных скриптов как на потенциальную жертву взлома, и на этой почве превентивно переносить их в другое место... не уверен, что это стоит того.
      Риски безопасности тут сопоставимые с теми, когда атакующий заполучает возможность править гаджет: под угрозой первоначально оказываются все, у кого он установлен, а дальше всё зависит от того, что делает вредоносный код.
      В англовики число установок самого популярного персонального скрипта в 47 раз выше, чем у нас, а его автор не появлялся 10 лет, и ничего. Причём там практика использования персональных скриптов куда более распространена: по сравнению с цифрой для персональных скриптов, число установок их самого популярного гаджета, не включённого по умолчанию, лишь в 3 раза выше, чем у нас. — Джек (обс.) 09:58, 31 января 2020 (UTC)[ответить]
  • Хотелось бы задать вопрос, пользуясь тем, что здесь кандидат может продемонстрировать технические знания. Я интересуюсь шахматами, вопрос будет частично по этой теме. Я конечно не знаю, насколько он уместен к получению флага администратора интерфейса, но я очень рассчитываю, что кандидат сможет на него ответить, поскольку он технический. :) Есть модуль Модуль:Шахматная доска. При его использовании (например, статья Открытые дебюты), при наведении на иконку фигур всплывает надписи типа «e4 белые пешка», «b8 чёрные конь». В модулях на др.языках такой проблемы нет, так как там нет склонений (например, в английском — white pawn). Как бы вы, Джек, предложили решить проблему склонений слов, обозначающих шахматные фигуры, чтобы было «e4 белая пешка» и «b8 чёрный конь»? Мне кажется, что строка alt = alt .. colornames[color] .. ' ' .. piecenames[piece] мало годится для русского языка, и там должен быть род (мужской/женский) для той или иной шахматной фигуры. Спасибо. — Brateevsky {talk} 11:24, 31 января 2020 (UTC)[ответить]
    • > Как бы вы, Джек, предложили решить проблему склонений слов, обозначающих шахматные фигуры, чтобы было «e4 белая пешка» и «b8 чёрный конь»?
      Как-то так. Единственная проблема — при обновлении модуля из источника придётся заново делать эту правку. — Джек (обс.) 13:05, 31 января 2020 (UTC)[ответить]

Обсуждение (Jack who built the house)[править код]

Итог[править код]

Вклад участника в техническую часть проекта и отзывы коллег в обсуждении делают этот итог совершенно очевидным - флаг подтвержден. — Lev (обс.) 07:08, 5 февраля 2020 (UTC)[ответить]

В принципе, я давно занимаюсь шаблонами, первый крупный был {{Вещество}}, модуль Calendar, из-за которого сыр-бор, появился вначале просто на замену {{Slidate}}, потом уже в него добавил обработку юлианской/григорианской даты, также в нём есть побочная функция отображения UTC в карточках населённого пункта (оставил в Модуль:Calendar, т.к. использует некоторые локальные функции).

Стараюсь документировать свои шаблоны, так как встречал такие, про которые не было ясно сходу, что конкретно они делают ({{Ntsh}}), но пока документация на уровне что именно делает шаблон в целом, а не отдельных частей. Не могу похвастаться что никогда поспешно не отменял изменения в шаблонах в ужасе от того, что произошло со статьями, куда они включены (иногда за меня это делали другие). Считаю, что даже если в результате изменений шаблона негативные последствия затронули лишь 10 % статей, где он используется, это значит что такие изменения вносить не нужно. У меня есть учётная запись User:CarnBot (умею обрабатывать списки не более 25K статей на AWB с модулями на C#, для налаживания работы через API пока не было серьёзного повода), из последнего что с ней сделал — {{Флагификация/doc/list}} (список шаблонов флагификации, объёмная страница).

Я несколько по-другому планировал подать на флаг инженера в качестве немного расширенного редактора шаблонов, предварительно закончив с текущими делами, которыми мог заниматься без данного флага, но в связи с тем, что модуль, который я написал на lua, теперь защищён, а мне ещё нужно включить в него поддержку {{СС}}, {{СС2}}, {{СС4}} (для {{СС3}} замена {{OldStyleDate3/temp}} готова, тесты в обсуждении), я вынужден подать данную заявку. Я и дальше планирую переводить шаблоны «на вики-коде» на lua для разгрузки серверов при выполнении страниц. Часто, даже если у меня было бы право на изменение защищённых страниц, нет консенсуса за такие изменения. Правка защищённых страниц мне периодически необходима, не всегда есть смысл снимать защиту с каких-то страниц, по этому поводу я, как и все, пишу запросы. Если что-то пропустил, прошу задавать вопросы.·Carn 13:02, 25 марта 2020 (UTC)[ответить]

Вопросы (Carn)[править код]

  • Стандартный вопрос от меня: какие проблемы вы видите в техническом обеспечении раздела, какие пути видите к их решению и в чём рассматриваете возможность своего участия (или уже участвуете)? — Джек (обс.) 13:22, 25 марта 2020 (UTC)[ответить]
    • Между разработчиками Фонда и сообществом есть достаточно тонкое место, в котором, скажем мягко, нету избытка участников. Мы не справляемся с внедрением тех инструментов, что нам доступны. Кроме так и не внедрённой, даже частично, системы обсуждений flow, у нас есть другие расширения MediaWiki, которые, хотя установлены, но почти или совсем не используются, или наоборот, очень даже используются, хотя нигде, вроде бы, не прописано, как и когда их стоит и не стоит использовать. Информация на mediawiki.org обычно касается не использования, а установки расширений. Возможно я бы мог и хотел бы воспользоваться какими-то расширениями (к примеру QuickSurveys и ReadingLists), однако об их использовании не так просто найти информацию.
Уходят участники, после них остаётся код, который сложно поддерживать. Функционал меняется быстрее, чем документация. Я не вижу другого пути, кроме понижения барьеров для вхождения участников в деятельность, связанную с техническим обслуживанием Википедии. Для этого не всегда хватает руководств, к примеру, думаю, что ту малость, что я понял про особенности применения того же lua, стоит записать в соответствующее эссе (к примеру что если хочешь внутри if установить значение какой-то переменной, которая понадобится вне этого if, её следует определить как локальную до вызова данного if, или что для строк с юникодом есть отдельные строковые функции, обычные не сработают). Текучка кадров неизбежна, особенно в волонтёрском проекте, и по сути код, его комментарии и другие тексты это всё что остаётся от нашего участия.
Среди крупных задач, которые сейчас решаются силами многих участников я вижу следующие:
  • обеспечение полного функционала для мобильных устройств (вынос значимой информации из элементов, к примеру {{comment}}, которые не отображаются в мобильной версии), это в большой части оформительский вопрос, я хотя что-то понимаю в CSS, не рассматриваю это как область именно своей деятельности пока, тут много проблем с тем что мобильная версия обладает либо крайне непривычно расположенным, либо крайне зарезанным функционалом, а настольная версия сайта крайне неравномерно масштабируется на мобильных устройствах, что делает её использование менее удобным
  • миграция данных на ВикиДанные (в случае с шаблонами экономик стран, где регулярно меняют ВВП и прочие показатели, это вполне оправданно), что связано с некоторыми проблемами — изменяются ежедневные действия, которые необходимо совершать, чтобы отслеживать вандализм. Список наблюдения на самих ВикиДанных обычно замусорен бесконечными добавлениями интервик, вандализм не очень эффективно отслеживать, а это необходимо, чтобы активно внедрять в шаблоны данные с ВикиДанных
Из доступных к выполнению для себя в ближайшей перспективе задач вижу:
  • продолжать добавлять параметры cat/nocat для шаблонов, которые добавляют категории, чтобы повысить гибкость использования таких шаблонов в статьях и обсуждениях
  • дальше переводить шаблоны с вики-кода (к примеру с длинными #switch:, как в {{ISO 3166}}) на lua, чтобы страницы отображались быстрее
  • создавать шаблоны, которые будут обращаться к модулям чтобы не было прямых включений модулей в основное пространство — уже сделал {{Пасха}} для соответствующего модуля
  • перевести обновление списков подстраниц шаблонов на регулярную основу (давно не обновлял список флагификаций, то же самое необходимо сделать и со списком флагов)
Из конкретных планов, правда, точно не требующих флага — это перевод семейства шаблонов, начинающихся с {{Четыре главных конкурса 1952 год}} на ВикиДанные + lua, чтобы вместо кучи страниц была одна с параметром года. К сожалению на ВикиДанных нету какого-то одного элемента со всеми необходимыми значениями, а, подозреваю, как ошибки, так и задержки при нахождении нужной информации через большое количество связей последоватль/предшественник будет делать подобный код неэффективным. Тут бы для кэширования результат такого периодически совершаемого обхода всех нужных элементов ВикиДанных сохранять в JSON, чтобы уже из него брались данные для шаблона, но, боюсь, я могу только ручками составить подобный JSON (либо таблицу в самом модуле), но в таком случае опять же, встаёт вопрос в необходимости обновлений — подозреваю что большинству участников проще будет создать ещё одну страницу шаблона по образцу, чем лезть в модуль или JSON (хотя, в принципе, можно написать инструкцию как это делать, проблема в том что при нарушении синтаксиса что JSON, что LUA перестают работать целиком). ·Carn 15:36, 25 марта 2020 (UTC)[ответить]
  • Я уточню по первому абзацу - я понимаю, что indicator используется рядом с заголовками, тэгу #statements, как и #invoke в основном пространстве не место, по поводу использования тэга #lst в будущем стоит начать тему о конкретных формулировках касательно его использования (на основе того, как он уже используется) в то же время как тэги "ce" и "score" желательно просто добавить в соответствующие списки. ·Carn 21:34, 30 марта 2020 (UTC)[ответить]
  • Вы отметились в свежей теме по оформлению шаблонов на ВП:ВУ. Планируете ли вы заниматься технической стороной этого вопроса в случае реализации предложенного плана действий? — Niklem (обс.) 19:03, 29 марта 2020 (UTC)[ответить]
    • Если речь идёт про Участник:Niklem/Цветовой конфликт, то первичным и самым сложным будет договориться о том, что необходимо сделать, нежели сделать вот это необходимое. Технических решений тут может быть несколько, текущий путь состоит в том, что цвета проставляются вручную, либо используется цвет по умолчанию.
      Мягкий путь по реализации вашего решения будет заключаться в том, чтобы составить список всех карточек и список всех цветов, которые в них используются, часто это не один цвет, как в {{Музыкант}} и представить на СО самих шаблонов и на СО проектов, которые ими занимаются с пингом участников о предлагаемых изменениях — чтобы они выбрали для недостаточно контрастных цветов цвет на замену. Это задача для ботовода, ничего неподъёмного не вижу, шаблонов-карточек не очень много.
      В случае же, если сообщество вдруг покажет чёткий консенсус на тему того, что всё должно быть реализовано так, чтобы контрастность всегда соблюдалась, можно предусмотреть другие решения — один из них — сделать через CSS — так как я подаю не на администратора интерфейса — я обсуждать не буду. Есть и другой метод — сделать модуль, который будет в качестве входящего значения получать желаемый цвет фона карточки и в зависимости от параметров выводить либо просто значение цвета, приведённое к определённой контрастности с заранее известными нам цветами текста и ссылок, либо выдавать один из цветов палитры, наиболее близкий к введённому пользователем цвету. Думаю что подобный модуль я написать могу.
      Если же вы говорили про более недавнюю тему на ВУ, связанную с моим предложением сделать для шаблона {{ВС}} текстовый параметр, который будет передавать в шаблон 80+ переключателей (битов — единичек и нолей, зашифрованных в наборе аски-символов) чтобы отображать или не отображать конкретные внешние ссылки — то я точно смогу сделать реализацию того, чтобы расшифровывать подобный параметр и, соответственно, его зашифровывать (но чтобы делать это модулем надо будет передать соответственно 80+ единичек, лучше это делать, как я и пишу, на основе JSON таблицы + JS скрипт, так как это позволит выводить элементы интерфейса, то есть можно будет просто несколько раз щёлкнуть мышкой, чтобы получить текстовый параметр, который отключит отображение некоторых ссылок, однако не факт что я смогу это сделать даже если у меня будет образец js-скрипта с примером как можно организовать ввод значений). ·Carn 09:27, 30 марта 2020 (UTC)[ответить]

Обсуждение (Carn)[править код]

  • (+) За Личные неоднократные пересечения с участником создали у меня впечатление добросовестного, технически подкованного и прислушивающегося к мнению других, участника. — С уважением, Helgo13(Обс.) 13:15, 25 марта 2020 (UTC)[ответить]
  • К сожалению вынужден отдать свой голос (−) Против этого участника: в последнее время активно с ним переписываюсь на разных площадках и всегда оказываюсь «по разные стороны баррикад» диалога. Зачем давать опасный инструмент тому, кто может применить его против тебя? — VladXe (обс.) 15:16, 25 марта 2020 (UTC)[ответить]
    • Можно спросить, как вы себе представляете применение против вас флага инженера без прав администратора интерфейса? Это же не флаг администратора, который однажды сообщество мне уже доверяло и который я сдал по неактивности. ·Carn 15:38, 25 марта 2020 (UTC)[ответить]
      • Изменение в защищённых шаблонах по тематике, в которой я активен. — VladXe (обс.) 15:42, 25 марта 2020 (UTC)[ответить]
        • Спасибо за ответ. Вы, видимо, считаете, что наличие собственного мнения может помешать мне определить, достигнут ли по какому-то вопросу консенсус или нет. Это понятные опасения, надеюсь что в результате нашего дальнейшего общения вы измените своё мнение. ·Carn 15:52, 25 марта 2020 (UTC)[ответить]
          • Всё-таки вынужден пояснить свою позицию: я не думаю, что Вы своими правками нарушите явно оформленный консенсус. А вот где явного консенсуса нет, в «серой зоне», там и следует боятся инженеров с собственным мнением. Я не против, что оно у Вас есть, я против того, чтобы оно было реализовано втихую. — VladXe (обс.) 04:41, 31 марта 2020 (UTC)[ответить]
            • Спасибо что проясняете свой ход мысли, я считаю что сообществу полезно, когда участники имеют возможность выразить свои опасения, пока это можно делать только во время всяческих «выборных» процедур.
              По поводу того, о чём вы говорите. Вот к примеру, у нас с участником Kalendar возник спор по поводу того, можно ли передавать в модуль год одним отрицательным аргументом. Я счёл низкой вероятность того, что человек случайно введёт «-64» вместо «65» и параметра «bc» = 1. Мы, вроде бы, знаем, что Гораций родился 10 (8) декабря 65 до н. э., но обычно даты до нашей эры достаточно приблизительны, и поэтому то, как ведёт себя код модуля на этом диапазоне не так важно.
              И «серая зона», о которой вы говорите — это ситуация, что когда один человек что-то сделал, если нету другого человека, который готов сам внести рабочие изменения по своему желанию, или нету какой-то сколько-нибудь массовой поддержки чего-либо — скорее всего будет сделано так, как первый смог и захотел сделать. И вот именно для того, чтобы такого было меньше, стоит иметь более обширное сообщество технически подкованных участников. ·Carn 13:42, 4 апреля 2020 (UTC)[ответить]
  • За, нет причин быть против. MBH 16:39, 25 марта 2020 (UTC)[ответить]
  • (−) Против. У меня тоже создалось впечатление, по немногочисленным пересечениям, что участник может ставить собственное мнение выше правил Википедии.— Luterr (обс.) 18:59, 25 марта 2020 (UTC)[ответить]
  • Участник в своё время был администратором, каких-то проблем у него не было, флаг был снят из-за неактивности. Поэтому я не вижу каких-то проблем в том, чтобы ему присвоить технический флаг. И я не понимаю тех участников, которые пытаются излишне социализировать флаг инженера. При этом участник умеет подводить шикарные развёрнутые итоги (что не раз демонстрировал), я бы его поддержал и в том случае, если бы он решил вернуть флаг администратора. И каких-то проблем с коммуникацией у него я не замечал по неоднократным пересечениям. Vladimir Solovjev обс 06:43, 26 марта 2020 (UTC)[ответить]
  • (+) За, конечно, встречал техдеятельность участника (но лучше было бы вернуть админфлаг, имхо). Викизавр (обс.) 07:29, 26 марта 2020 (UTC)[ответить]
  • (+) За, per Helgo13 и Викизавр. Deltahead (обс.) 11:00, 26 марта 2020 (UTC)[ответить]
  • Вижу продуктивного ремесленника и классическую историю кандидата в инженеры — «Не могу править собственный модуль, потому что защитили». Радует системный взгляд на вещи. Проголосовал бы за кандидата и при выдвижении в администраторы. — Джек (обс.) 15:19, 26 марта 2020 (UTC)[ответить]
  • коллега, а я вас прямо попрошу: верните админфлаг, пожалуйста. только лучше всё-таки без оффтопиков :-) — Halcyon5 (обс.) 18:23, 26 марта 2020 (UTC)[ответить]
    • Спасибо большое за поддержку вам и всем кто ранее высказался, боюсь ближайшие года 2-3 не смогу быть особо активным. Думаю не стоит брать инструмент, который не будешь надлежащим образом использовать. Как вы правильно говорите, надо сильнее следить за собой, без админфлага, "в гражданском", чувствуешь себя свободнее. ·Carn 19:21, 26 марта 2020 (UTC)[ответить]
  • (+) За поскольку выполняемые технические работы в пространстве шаблонов и модулей говорят сами за себя. — Ailbeve (обс.) 16:06, 27 марта 2020 (UTC)[ответить]
  • (+) За, соответствует. — Erokhin (обс.) 16:40, 28 марта 2020 (UTC)[ответить]
  • (+) За, и админа пусть возвращает. — ssr (обс.) 09:13, 29 марта 2020 (UTC)[ответить]
  • (+) За разумеется Ghuron (обс.) 17:35, 29 марта 2020 (UTC)[ответить]
  • Даже далекому от технической стороны редактору (как мне) видны многие проблемы Википедии по технической части. И если есть опытный человек (и бывший администратор!), готовый что-то делать, надо дать ему все инструменты. Поэтому только (+) За. Khinkali (обс.) 12:47, 30 марта 2020 (UTC)[ответить]
  • Замечательно, когда хард скиллы достойного уровня сочетаются с богатым метапедическим опытом и стремлением принести реальную пользу проекту. Конечно, (+) За. — Niklem (обс.) 15:11, 30 марта 2020 (UTC)[ответить]
  • (+) За, развёрнутое подробное обоснование причин необходимости флага, плюс большой опыт участника. Отмечу что различные обсуждения, приведенные тут выше, не имеют отношения к флагу инженера, и лично я за участником никаких проблем в социальном аспекте не замечал. Swarrel (обс.) 17:37, 30 марта 2020 (UTC)[ответить]
  • (+) За опытный участник. Максим Стоялов (обс.) 09:34, 1 апреля 2020 (UTC)[ответить]
  • (+) За, у нас немного участников, готовых браться за создание и улучшение модулей. Сергио (обс.) 23:16, 3 апреля 2020 (UTC)[ответить]
  • (+) За, опытный, трудолюбивый и строгий к правилам участник. Уверен, флаг он применит с большой пользой.--Diselist (обс.) 05:44, 4 апреля 2020 (UTC)[ответить]
  • Поскольку претендент ранее был администратором и имел запрашиваемые права и в этом обсуждении не были проведены примеры некорректного использования запрашиваемых прав, то личные обиды нескольких участников, высказавшихся против присвоения флага, не могут быть основанием для отказа в запрашиваемом флаге. Раммон (обс.) 13:40, 4 апреля 2020 (UTC)[ответить]

Итог[править код]

Коллега Carn уже показал себя технически грамотным участником, с точки зрения доверия и к нему тоже больших вопросов к нему быть не должно, флаг присвоен. Track13 о_0 18:25, 5 апреля 2020 (UTC)[ответить]

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Track13 (обс. · вклад · удалённый вклад · статьи · файлы · инфо · журналы · фильтры · блокировки · права). На текущий момент флаг АИ мне нужен для поддержания выборов в АК, скрипт голосования пока не умеет в выгрузку кандидатов из JSON, поэтому было бы желательно флаг подтвердить. Если список кандидатов в JSON будет реализован, то флаг мне особо не нужен. Насколько я помню, файлы из компетенции ИА я правлю очень редко и это некритично для меня. В своей профессии я периодически сталкиваюсь с задачами для front end, не могу назвать себя экспертом, но уверенным пользователем уж точно, и как минимум знаю границы своей компетентности. Если есть вопросы, то я постараюсь ответить. Track13 о_0 21:44, 19 апреля 2020 (UTC)[ответить]

Вопросы (Track13)[править код]

  • Вижу в вашем вкладе правки js выборов и Gadget-osm.js, однако не увидел правок CSS, в связи с чем несколько вопросов по нему (При помощи какого CSS кода можно ...):
    1. присвоить стиль всем элементам списка/строкам таблицы, кроме трёх последних?
    2. избежать того, что изображение на экранах устройств с высоким разрежением становится чересчур маленьким?
    3. скрыть все внешние ссылки на файлы с расширением «.docm» как потенциально опасные?
  • Заранее спасибо.·Carn 08:37, 20 апреля 2020 (UTC)[ответить]
    • Я не правлю css в основном потому, что в ВП нужно отвечать не только на вопрос «как делать», но и «что делать». Нести своё чувство прекрасного в массы я не слишком готов. По вопросам:
  1. tr:nth-last-child(n + 4);
  2. Если я правильно понял вопрос, то используя @media (min-resolution: %%%dpi) можно создавать варианты стилей для разных разрешений, и через них загружать разные по размеру изображения;
  3. a[href$=".docm"] {display:none}
Track13 о_0 11:16, 21 апреля 2020 (UTC)[ответить]

Обсуждение (Track13)[править код]

Итог[править код]

Случай очевидный: бюрократ, которому этот флаг требуется для технического обеспечения проведения выборов в АК. Флаг у участника был, нарушений с ним не было. Формальность — неделя обсуждения — соблюдена. Даже не могу написать, что флаг присвоен — он был, есть и будет есть. — Adavyd (обс.) 21:45, 26 апреля 2020 (UTC)[ответить]


Привет. Некоторое время назад я оставил несколько запросов на Обсуждение модуля:Sources#Чего не хватает в модуле и Обсуждение шаблона:Внешние ссылки#GameRankings. Уже прошло две недели и, не смотря на то, что запросы очень конкретные и простые, ни обращение на ВП:ТЗ, ни упоминание в Discord, как рекомендует {{editprotected}}, не помогли как либо ускорить получение хоть какой-то реакции на них, так что иду сюда в надежде, что получить флаг будет быстрее и проще, чем бегать за флагоносцами по мелочам. Свои ближайшие планы на работу с флагом я более менее описал на Википедия:Форум/Викиданные#Доработка Модуль:Sources, в целом, планирую пройтись по модулям, ответственным за интеграцию с викиданными, как следует в них разобраться (я планирую попутно написать документацию к этим модулям, примерно в таком духе) и исправить очевидные недоработки, которые в них обнаружатся. Конкретно с Lua у меня опыт работы не очень большой, но желание и умение разбираться в чужом коде™ есть, поэтому думаю, что вполне способен принести пользу с флагом. Открыт к любой критике и пожеланиям относительно возможной работы с флагом, недопустимость нарушений ВП:МНОГОЕ и необходимость предварительного тестирования вносимых изменений осознаю. adamant.pwncontrib/talk 07:49, 26 апреля 2020 (UTC)[ответить]

Вопросы (Adamant.pwn)[править код]

  • Традиционный вопрос от меня: какие проблемы вы видите в техническом обеспечении раздела, какие пути видите к их решению и в чём рассматриваете возможность своего участия (или уже участвуете)? — Джек (обс.) 02:49, 27 апреля 2020 (UTC)[ответить]
    • Я только начинаю входить в эту сферу и пока не до конца во всём разобрался, но вот что мне бросилось в глаза:
  1. Достаточно медленная обработка запросов на изменение защищённых страниц, даже мелких и хорошо обоснованных. Наверно, тут более менее единственный реальный способ что-то решить — это расширить круг людей, которые обрабатывают эти запросы. В свою очередь, сам буду стараться принимать в этом посильное участие в случае получения флага.
  2. Отсутствует встроенная система контроля версий. Точнее она как бы и есть, но диффы она показывать умеет, а «прикладывать» их к страницам — нет. Очень неудобно править защищённые страницы в песочнице и потом просить смерджить изменения, потому что переживаешь о том, что за это время кто-то может поправить исходную страницу и придётся как-то объединять эти изменения. Скорее всего, некоторый функционал, позволяющий минимальную работу с диффами и патчами можно реализовать пользовательским скриптом, как это сделано с «вернуть к…» для патрулирующих, но это на текущий момент выходит за грани моей компетенции, к сожалению.
  3. Модули и шаблоны зачастую довольно плохо документированы, что повышает порог вхождения к их использованию и редактированию, и превращает их в загадочный чёрный ящик для менее технически ориентированных участников. Скажем, для Модуль:Sources прямое текстовое описание того, по какому принципу он формирует тексты сносок появилось когда я его туда вписал незадолго до этой заявки, хотя используется модуль повсеместно.
    О том, как это сделать — у меня некоторое время была идея написать модуль, генерирующий эту документацию из исходного текста модуля в духе LuaDoc (так было бы проще поддерживать её актуальной, обновил что-то в модуле — подправил текст документации рядом с функцией, а не пошёл править её на отдельной странице, что делать, скорее всего, будет лень), но, судя по mw:Topic:To2nzjnnt0uj8fct, такой подход в целом нежелателен, так что, наверно, остановлюсь на том, что при знакомстве с новым модулем буду аккуратно текстом прописывать в его документации, что делают интересующие меня функции (как сейчас начал на Модуль:Sources/doc). Это полезно для будущих редакторов модуля и хороший способ безболезненно войти в курс дела и выявить некоторые очевидные проблемы (как то, что форматы имён, поддерживаемые в personNameToAuthorName и personNameToResponsibleName отличаются без видимой на то причины).
  4. Слабая степень интеграции модулей. Насколько я вижу, за формирование текстов сносок, подгруженных из викиданных, отвечает Модуль:Sources, а за подгрузку информации в карточки отвечает Модуль:Wikidata. Кажется, что некоторые функции последнего было бы уместно использовать в первом, но в документации Wikidata внезапно указано: «Функции данного модуля не предназначены для прямого вызова из шаблонов карточек или других модулей, не являющихся функциями расширения данного». Например, Модуль:Wikidata, как я понимаю, умеет определять название сущности по году, в который оно использовалось, а Модуль:Sources этого не делает, хотя надо бы. И из документации Модуль:Wikidata следует, что нужно не ссылаться на подходящую функцию из модуля, а примерно копипастить её. Здесь, наверно, нужно добиваться каких-то внутренних договорённостей между авторами подобных модулей о том, чтобы некоторые наиболее значимые функции были обратно совместимыми и в целом, возможно, разработать что-то в духе Модуль:Utils, основным назначением которого было бы предоставление таких функций другим модулям, чтоб те не изобретали велосипед по сто раз.
  5. Код модулей может быть довольно плохо структурирован (например, на Модуль:External links огромный список используемых ссылок просто засоряет основной код модуля и может быть безболезненно вынесен на какие-нибудь задворки в Модуль:External links/conf. Собственно, это я уже сделал, но запрос на мердж обновленной версии основного модуля из песочницы никто не выполняет). Ну, здесь нужно по возможности иногда осматривать модули в целом и проводить рефакторинг, где это уместно. Эта деятельность довольно органично накладывается на документирование кода, о котором писал выше.
adamant.pwncontrib/talk 06:42, 27 апреля 2020 (UTC)[ответить]
диффы она показывать умеет, а «прикладывать» их к страницам — нет, а как же Служебная:Сравнение_страниц? Вот например сравнение Модуль:Sources и Модуль:Sources/песочница (Diff). Don Rumata 18:36, 30 апреля 2020 (UTC)[ответить]
  • Полезная страница, но это не совсем то, что я имел в виду. Под «приложить» я имею в виду взять дифф между двумя версиями одной страницы и применить только изменения из этого диффа к другой. То есть, например, пока я работаю в песочнице — хочется достаточно быстро синхронизировать её с основной страницей через какой-нибудь аналог git pull если там были изменения в той части, где конфликтов с песочницей нет. adamant.pwncontrib/talk 18:56, 30 апреля 2020 (UTC)[ответить]
    • Вы про разрешение конфликтов? Don Rumata 20:35, 30 апреля 2020 (UTC)[ответить]
      • Да даже не обязательно с разрешением конфликтов, хотя бы про возможность быстро подтянуть бесконфликтные изменения с основной страницы в её форк. То есть, есть основная страница А и её версия Б. Кто-то делает изменение в А, которое не противоречит тому, что уже менялось в Б. В таком случае нужно попробовать в полуавтоматическом режиме добавить это изменение в Б. Это скорее аналог patch (Unix). adamant.pwncontrib/talk 06:40, 1 мая 2020 (UTC)[ответить]
  • Судя по тому, что вы собираетесь править Lua модули, возникает следующий вопрос. А как вы будете их отлаживать? Какие инструменты отладки Lua модулей вы знаете? Что вы предпримете если вам будет необходимо прогнать например 1000 тестов? Don Rumata 18:44, 30 апреля 2020 (UTC)[ответить]
  • А какие у вас знания js, css? Судя по вашему вкладу вы пытались сделать гаджет для переключения между визуальным редактором и редактором викитекта visual.js. А как этo механихм реализован стандартно в VisualEditor? Don Rumata 20:24, 30 апреля 2020 (UTC)[ответить]
    • Базовые, достаточно давно не притрагивался ни к тому, ни к другому. На счёт VisualEditor — я вчера пытался это выяснить, но не очень успешно. А жаль, хочется уметь сохранять текущий текст из редактора при переходе. adamant.pwncontrib/talk 21:07, 30 апреля 2020 (UTC)[ответить]
      • Когда визуальный редактор активирован, то переключать режимы можно функциями ve.init.target.switchToWikitextEditor(); ve.init.target.switchToVisualEditor(); Активировать визуальный редактор можно функцией mw.libs.ve.activateVe('visual'); Подробнее про API тут. Don Rumata 21:53, 30 апреля 2020 (UTC)[ответить]
        • Хм, вызов функции mw.libs.ve.activateVe('visual'); приводит к попытке прогрузить визуальный редактор, но заканчивается сообщением Tried to load the editor in wrong mode (data type: "visual", editor mode: "$2").. А найти какое либо упоминание activateVe у меня по ссылке не получилось. adamant.pwncontrib/talk 07:57, 1 мая 2020 (UTC)[ответить]
        • Кстати, на страницах, где визуальный редактор и так доступен (а меня интересуют именно страницы, где это не так), данная функция адекватно работает. adamant.pwncontrib/talk 10:35, 1 мая 2020 (UTC)[ответить]
          • Эта ошибка возникает, т.к. вы пытаетесь открыть редактор в пространстве, где он запрещён mw.libs.ve.isVisualAvailable == false. В это случае нужно вызывать mw.libs.ve.activateVe('source'); Don Rumata 17:02, 1 мая 2020 (UTC)[ответить]
  • Увидел такую правку правила и с таким комментарием, что вызвало вопрос: а в массово используемых шаблонах тоже следует ожидать правок с описанием вида «этот параметр всё равно никто не использует — убираю» и без всякого обсуждения где-либо? NBS (обс.) 20:34, 30 апреля 2020 (UTC)[ответить]
    • Ну как сказать… Вот мой запрос на изменение отображаемой ссылки с GameRankings на GameFAQs — когда я его сделал, мне указали, что такое изменение следует обсудить с Проект:КИ. Если бы у меня на тот момент был флаг — я бы поменял этот id сразу и без обсуждения, потому что на текущий момент все ссылки по этому идентификатору — битые. То есть, если у меня будут стойкие подозрения в том, что какая-то часть шаблона очевидно вредна (с технической точки зрения: некорректно отображается, порождает битые ссылки, etc), я могу поправить её без обсуждения. Как либо урезать работающий функционал шаблонов или переделывать его без обсуждений точно не буду.
      Касательно конкретной правки в правилах — я некоторое время слежу за происходящим на КПМ и несоответствие реального положения дел изменённому тексту очень сильно бросается в глаза. Никто реально не спрашивает у автора исходного итога разрешение на переподведение, вот вообще. Никогда. И того, что для переподведения итога нужен единогласный порыв всех причастных, а иначе надо ждать администратора — этого тоже фактически нет. Я понимал, что эта правка несёт некоторые риски когда её вносил, но опирался на то, что эта часть правила никаким образом не затрагивает содержание статей, а лишь описывает нашу внутреннюю кухню на КПМ. Соответственно, немедленного вреда моя правка заведомо принести не может, на содержание и внешний вид статей никак не влияет и может быть оспорена в любой момент кем угодно. В этих условиях я посчитал, что допустимо внести её без обсуждения. Если вы с ней не согласны — отмените и я открою обсуждение на ВП:Ф-ПРА. В шаблонах я, конечно, так себя вести не буду, так как правки в них, в отличие от данной, влияют на содержимое статей. adamant.pwncontrib/talk 21:53, 30 апреля 2020 (UTC)[ответить]
      • …влияют на содержимое статей — вы считаете это принципиальным моментом? Например, некоторые юзербоксы используются очень часто — к ним вы предполагаете применять другой подход? NBS (обс.) 19:20, 1 мая 2020 (UTC)[ответить]
        • В случае с шаблонами, затрагивающими основное пространство (первыми на ум пришли именно они, т. к. в основном планирую работать с ними), считаю это наиболее важным моментом, но не единственным. В общем, нет, я предполагаю применять только подход, описанный в первом абзаце моего ответа к любым своим действиям, требующим применения флага инженера. adamant.pwncontrib/talk 20:06, 1 мая 2020 (UTC)[ответить]
  • Чтобы понять насколько вы готовы к работе с Lua, посмотрите Модуль:Convert и расскажите, какие текущие проблемы осталось решить, чтобы прошли оставшиеся 1132 теста? В какой последовательности вы бы начали решать эти проблемы? Don Rumata 17:45, 1 мая 2020 (UTC)[ответить]
    • Насколько я могу судить, ожидаемое поведение модуля — это именно отображение в нашем формате, а не формате английской википедии, поэтому на Шаблон:Convert/тесты большая часть тестов совершенно нерелевантны в плане того, что записано в «Expected». Думаю, правильным подходом к тому, чтобы «озеленить» тесты было бы заменять эти expected на правильные по мере того, как будет переводиться информация из модуля. Основные поля, которые нужно перевести хранятся в Модуль:Convert/data, но есть ряд проблем, связанных с грамматическими отличиями языков:
  1. Для английского важно только отличать единственное число от множественного, у нас ещё есть такие аномалии как «2 метра», но «5 метров», которые нужно учесть отдельно. Я так понимаю, разбирается это в функции variable_name и там частично функционал уже реализован из-за использования на slwiki, надо только разобраться с тем, согласуются ли там правила с нашими, поправить при необходимости и внести изменения в data.
  2. Также я вижу, что нельзя напрямую переводить конструкции вида «57 to 59 inches», так как для английского языка нормально опустить здесь «from», а у нас нужно явно прописать «от … до …». Такие вещи регулируются в range_types из Модуль:Convert/text. Кажется, что это подходит под описание «„input“ and „output“ values (for LHS and RHS);» и изменения нужно вводить примерно здесь.
  3. Ещё вижу какие-то странности в духе «дециквадратный метр». У англичан это решается через поле «prefix position», а у нас оно почему-то было просто удалено этой правкой.
Начал бы я с чего-то, исправляющего описанные выше пункты и попутно пробовал бы постепенно переводить Модуль:Convert/data и решать возникающие проблемы по мере их возникновения. adamant.pwncontrib/talk 21:19, 1 мая 2020 (UTC)[ответить]
Подозреваю, что вы не поняли откуда появились тысячи тестов. Проблема конечно в локализации, но вы посмотрите внимательнее на Модуль:Convert/makeunits и поймете откуда формулы конвертации берутся. Я там всю документацию по-русски перевел. Don Rumata 21:55, 1 мая 2020 (UTC)[ответить]

Обсуждение (Adamant.pwn)[править код]

Итог[править код]

В обсуждении Adamant.pwn показал как знание того, чем он будет заниматься, так и понимание того, где он некомпетентен и где следует проявить повышенную осторожность. С учётом текущей деятельности и консенсуса обсуждающих флаг присвоен, плодотворной работы! Track13 о_0 19:34, 7 мая 2020 (UTC)[ответить]

Здесь текст заявки. Nuralinov 22 (обс.) 07:34, 31 мая 2020 (UTC)[ответить]

Вопросы (Nuralinov 22)[править код]

Обсуждение (Nuralinov 22)[править код]

  • Думаю, что бюрократам нужно быстро закрыть эту заявку, ибо участник явно не соответствует требованиям: «для кандидата является обязательным обладание флагом администратора, бюрократа или инженера». Здесь у участника вообще всего 3 месяца стажа и никаких флагов. Vladimir Solovjev обс 08:27, 31 мая 2020 (UTC)[ответить]
  • 26 мая жёстко нарушить НО, а 31 мая подать заявку на один из самых ответственнейших флагов — неразумно. И это учитывая, что требования не выполнены. — С уважением, Helgo13(Обс.) 09:02, 31 мая 2020 (UTC)[ответить]

Итог[править код]

Обязательным требованием для подачи заявки на статус администратора интерфейса является наличие флага инженера, администратора или бюрократа. Поскольку ни одного из этих флагов у участника нет, заявка быстро закрыта. — Adavyd (обс.) 17:30, 31 мая 2020 (UTC)[ответить]


Заявка на подтверждение флага администратора интерфейса согласно решению АК:1076. В принципе, относительно исходной заявки изменилось немного. Периодически разбираю Категория:Википедия:Запросы на изменение защищённых страниц, часть запросов там теперь требует этого флага. За последнее время количество запросов с просьбой о правке пространства имён MediaWiki значительно снизилось (хотя, к примеру, вот сейчас висит Обсуждение MediaWiki:Edittools#Перестало работать), зато стали периодически всплывать запросы об исправлении скриптов в чужих ЛС (вроде Обсуждение участника:Flint/monobook.js). JS и CSS владею, 2FA использую по очевидным причинам.

Отдельно этот флаг полезен мне как администратору/ЧЮ. Дело в том, после введения флага администратора интерфейса обычные администраторы не могут просматривать содержимое (deletedhistory/deletedtext) или восстанавливать удалённые страницы, вынесены в "зону деятельности" АИ. Соответственно, для того, чтобы посмотреть удалённый скрипт или css, использованный каким-нибудь особо одарённым товарищем, без флага придётся каждый раз обращаться к помощи других участников. Подозреваю, что аналогичная проблема возникнет и с ревизскими действиями (хотя это исключительно гипотетическая ситуация, я с ней никогда не сталкивался) - я не могу скрыть правку (к примеру, от других АИ) на удалённой странице, даже получив на это запрос.

В общем, флагом пользуюсь (и планирую пользоваться) нечасто, в областях, в которых не разбираюсь - не правлю, без флага будет немного неудобнее. — DR (обс.) 18:12, 1 июня 2020 (UTC)[ответить]

Вопросы (DR)[править код]

  • Украду вопрос у Джека — какие проблемы вы видите в техническом обеспечении раздела, какие пути видите к их решению?·Carn 21:43, 2 июня 2020 (UTC)[ответить]
    • В техническом обеспечении интерфейса меня вообще всё устраивает :-) Технические проблемы, с которыми я сталкивался в последнее время (максимальное количество шаблонов на странице, доработка инструментария ЧЮ) лежат вне зоны деятельности АИ. Как человека, периодически вынуженного править чужие скрипты меня раздражает низкий уровень их документации или даже полное её отсутствие. — DR (обс.) 13:22, 3 июня 2020 (UTC)[ответить]
  • Можете ли Вы предложить решение проблемы, описанной здесь? Раммон (обс.) 06:53, 3 июня 2020 (UTC)[ответить]
    • Ну, описанные там обработчики событий определяются в MediaWiki:Common.js. В рамках описанной в заявке концепции использования флага нужно обратиться к коллеге Jack who built the house, который в своё время добавил этот обработчик и попросить его посмотреть на данную проблему. Навскидку хотелось бы отметить, что, похоже, в мобильной версии и в режиме быстрого предпросмотра не работают все скрипты, подключаемые через {{Выполнить скрипт}}.
    На самом деле там (насколько я могу оценить беглым взглядом) ситуация следующая: Jack создал новый обработчик событий и перенёс в него среди прочего функцию обработки объектов $( '.executeJS' ), ответственную за добавление скриптов, указанных при помощи шаблона {{выполнить скрипт}}. Этот обработчик реагировал на появление элемента с id="footer" (в десктопной версии MediaWiki появляющегося одним из последних на странице).
    Это всё прекрасно работало в десктопной версии, но полностью сломалось при быстром предпросмотре или в стиле Minerva Neue, используемом по умолчанию при мобильном просмотре, ибо там такого элемента нет. Не скажу, не работало ли оно сразу, или умерло после каких-нибудь очередных изменений скина Minerva Neue разработчиками MediaWiki.
    Как минимальное решение можно просто вынести функцию за пределы данного обработчика (как это было раньше). Как максимальное - найти объекты, существующие во всех скинах, и реагировать на них. К примеру, вместо $( '#footer' ) использовать $( '.mw-footer' ), что должно решить проблемы с мобильным отображением. Ну и поискать какой-нибудь id или класс, используемый в конце объектов, генерируемых при использовании быстрого предпросмотра. — DR (обс.) 13:22, 3 июня 2020 (UTC)[ответить]
    • Отсутствие #footer в Minerva Neue ни при чём (но спасибо, что обратили внимание) — в отсутствие элемента выполнение скрипта происходит просто по загрузке страницы. В мобильной версии скрипт не работает потому, что в нём не выполняется MediaWiki:Common.js вовсе, — для этих целей существует MediaWiki:Mobile.js. Просто на скине Minerva Neue (не в мобильной версии) всё прекрасно работает. Раммон в своём открывающем посте темы верно указал корень проблемы — у нас скрипт выполняется просто по загрузке страницы, а не по событию wikipage.content, которое охватывало бы и предпросмотр (речь, насколько я понимаю, про быстрый предпросмотр, потому что в обычном предпросмотре всё должно работать и так и у меня работает). Указанная проблема решается так или иначе через привязку к этому событию. Посмотрю, как это лучше решить, как освобожусь. — Джек (обс.) 20:51, 3 июня 2020 (UTC)[ответить]

Обсуждение (DR)[править код]

Итог[править код]

Есть и необходимость во флаге, и техническая грамотность, показанная в прошлой деятельности, и поддержка сообщества, так что флаг без сомнений подтверждён. Track13 о_0 16:26, 8 июня 2020 (UTC)[ответить]

Adavyd (обс. · вклад · удалённый вклад · статьи · файлы · инфо · журналы · фильтры · блокировки · права). Администратор с апреля 2012 года, бюрократ с января 2014 года, флаг АИ имею с самого начала «распила» (с июля 2018 года). В качестве бюрократа более шести лет активно участвую в организации и технической поддержке выборов в АК (старожилы, наверное, помнят случаи, когда голосование запускалось мной «в ручном режиме»). В частности, флаг АИ требуется для редактирования voting.js — мне неоднократно приходилось это делать, в том числе на последних выборах. В настоящий момент из бюрократов флаг АИ подтвердил Track13, но этого недостаточно для надёжного обеспечения проведения выборов. Дополнительным положительным фактором является наш большой сдвиг с ним по часовым зонам. Границы своей компетенции знаю, при необходимости всегда готов попросить о помощи и выслушать совет специалиста. Эту заявку считаю формальностью, которой можно было бы избежать, но готов пройти через неё для пользы дела. Тем не менее, если есть конкретные вопросы, то я постараюсь ответить (но не в экзаменационном формате). — Adavyd (обс.) 18:04, 8 июня 2020 (UTC)[ответить]

Вопросы (Adаvyd)[править код]

  • Согласно Википедия:Администраторы интерфейса#Самоограничения и временный флаг требования к участнику могут быть понижены, если он решит запросить флаг временно или с ограничениями. Рассматриваете ли вы возможность получить флаг временно, но не на жёсткий срок, а до момента когда будет отлажен скрипт выборов, который не будет требовать для проведения очередных выборов правки JS, а только JSON, и/или , возможно, с ограничениями на правку CSSupd с явно заявленным взятием флага только для правки скриптов, относящихся к страницам выборов (в связи с вашей продолжительной работой без нареканий с данным механизмом хватит просто вашего слова что вы берёте флаг только для этого)?·Carn 09:48, 9 июня 2020 (UTC)[ответить]
    • Мне кажется что взятие на себя ограничений, о которых говорят люди в секции ниже, и я говорю выше — было бы устраивающим все стороны компромиссным вариантом. Но так как, хоть вы и активны в Википедии, но на мой вопрос не ответили, я так понял что вы отрицательно относитесь к данной инициативе. upd Только в случае, если вы действительно не согласны заявить о своём согласии на подобные меры, чтобы снять высказанные сомнения в вашей технической компетенции, я собираюсь добавить немного «грязи» в данную секцию, чтобы задать вам сугубо практические вопросы, которые могут возникнуть в связи с работой MediaWiki:Voting.js, прошу отнестись с пониманием. ·Carn 07:55, 11 июня 2020 (UTC)[ответить]
      • То есть если участник говорит, я буду поддерживать только MediaWiki:Voting.js, то этого достаточно, чтобы признать его технически компетентным для поддержки данного механизма, а вот если не говорит, то компетенции нуждаются в проверке. А этой фразы достаточно только для Voting.js или в нее любой(-ые) скрипт(-ы) можно вписать? При этом то, что он раньше уже все это делал в расчет не берем. Luterr (обс.) 11:57, 12 июня 2020 (UTC)[ответить]
        • Видимо, мне следовало просто спросить, сдаст ли участник флаг после того как скрипт выборов будет переведён на json (как, мне известно, планирует сделать Track13). Мой вопрос следует рассматривать как попытку снять противоречия между «избираемым» и частью «избирателей», чтобы итог данного обсуждения был однозначно консенсусным. То что участник справляется с узкой задачей не значит что он справится с широким кругом задач. В случаях, когда участник заявляет что флаг ему нужен для выполнения какой-то задачи и полностью подходит под требования данного флага, то он может по своему усмотрению расширять область своей деятельности с флагом, если в заявке не было оговорено обратного.
          Конечно, я не могу охарактеризовать положительно то, что Adavyd, видимо, до сих пор считает что «флаг у бюрократов должен быть по умолчанию», а данная заявка — лишь формальность. Также меня удручает что он избегает ответа, хотя бы отрицательного, на достаточно закономерный вопрос. Ранее участник был против присвоения полным инженерам прав флага АИН (чему лично я рад, моей технической компетенции на флаг АИН на настоящий момент не хватит): «Насчёт автоматического поголовного присваивания инженерам прав техадминов с соответствующего расширением их прав — я против, так как это не было оговорено при соответствующих заявках», хотя когда соответствующие заявки рассматривались, права редактирования всех JS и CSS были включены во флаг инженера. То что участник сейчас говорит «границы своей компетенции знаю» — не означает автоматически что в дальнейшем он будет заниматься лишь тем, чем уже занимался. Я лишь хочу того же, чего хотел сам участник по отношению к другим — прямо оговорить момент, который вызвал сомнения не только у меня, и, возможно, снять возникшие противоречия, чтобы не было потом разговоров, что флаг присвоен бюрократами из цеховой солидарности, а не по аргументам обсуждения.
          Правки, которые он обычно совершает — это добавление, изменение или удаление параметров, для которого не обязательно понимать хоть сколько-нибудь глубоко сам язык программирования, который их использует (большинство этих правок сделано пока Gadget-markadmins не был переведён на json) — [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44]. Мы видим из данных правок, что участник аккуратен и успешно следует синтаксису. Однако я не могу считать это подтверждением технической компетентности в JS в целом, так как тут не видно работы с самим языком программирования и его логикой, то есть в общем случае нельзя считать что участник данными правками показал техническую компетенцию в JS, которую должен показать каждый кандидат, и каждому из них, насколько я следил, задавались соответствующие вопросы, чтобы её проверить. У меня нету никаких оснований предъявлять (или не предъявлять) к участнику какие-то требования, отличные от тех, которые предъявляются (или не предъявляются) другим участникам.
          Тем не менее, у участника есть формально содержательная правка в JS: [45], а ещё пробная правка и её возврат. Возможно, ниже высказанные аргументы что его техническая компетентность «не превосходит среднюю по проекту» ошибочны, для этого я и задал ему вопрос по JS, который достаточно прост, но требует понимания алгоритма работы скрипта, работу с которым участник обозначил своей основной задачей, это не «эталон заваливания в ходе обсуждения», как выразился VladXe в ходе опроса по принятию правила. Если же эти мнения не ошибочны и участник не планирует широкой деятельности с JS, то ему, по-идее, не холодно и не жарко от подобных ограничений, если только он не воспринимает их в контексте противостояния бюрократов и техников как «победу» последних.
          К тому же, насколько я читаю соответствующий раздел правила, там речь идёт не только о том, что участник подтверждает техническую компетентность в JS (о чём я написал выше), но ещё и про CSS. Кроме одной правки, я не вижу, чтобы участник правил CSS, соответственно ему в принципе противопоказан соответствующий флаг без ограничений. ·Carn 14:20, 12 июня 2020 (UTC)[ответить]
          • «но требует понимания алгоритма работы скрипта» — нет, не требует, требует догадаться заглянуть в консоль браузера, не более того. Luterr (обс.) 07:15, 13 июня 2020 (UTC)[ответить]
            • Вот именно, сложность вопроса была минимальна, участник на него не ответил — если отбросить лишние эмоции, то вывод из этого таков, что в данной заявке не доказано что даже минимальной сложности вопросы находятся в пределах понимания участника. ·Carn 08:40, 13 июня 2020 (UTC)[ответить]
          • «не означает автоматически что в дальнейшем он будет заниматься лишь тем, чем уже занимался» — ВП:ПДН не любит подобных выводов.
            «что флаг присвоен бюрократами из цеховой солидарности» — или не присвоен из-за цеховой солидарности соседнего цеха.
            «не холодно и не жарко от подобных ограничений, если только он не воспринимает их в контексте противостояния бюрократов и техников как „победу“ последних» — как и если последние не воспринимают их отсутствие как свое «поражение».
            «понимать хоть сколько-нибудь глубоко сам язык программирования», «CSS … соответственно ему в принципе противопоказан соответствующий флаг» — это уже все было обсуждено в ходе заявки АК:1076 — что завалить можно любого, и всегда можно признать, что чье-то знание недостаточно глубоко для оценивающего. И сакрализация CSS, свойственная только некоторым заявкам в нашем проекте, и чего не наблюдается во всем остальном мире программирования, тоже обсуждалась. Luterr (обс.) 12:19, 13 июня 2020 (UTC)[ответить]
            • Я не вижу как выбивается из ВП:ПДН то, что участник будет пробовать использовать имеющиеся у его флага функции. Это как если администратор идёт на ВП:ЗСА и говорит что будет удалять статьи, а потом после избрания в том числе начинает блокировать вандалов — совершенно нормальная ситуация, если не было оговорено, что флаг ему выдаётся только для удаления статей.
              Моя аргументация не касается того, что флаг не нужно выдавать, она касается того, что флаг нужно выдать именно для тех задач, для которых он запрашивается. Я так понимаю что я в составе рабочей группы плохо выполнил свою работу, в результате чего разные люди в одном разделе видят совершенно разный смысл (также как разный смысл можно вложить в слова «границы своей компетентности знаю»). Если же мы начнём игнорировать правила во имя абстрактной пользы, то нам придётся принимать во внимание субъективную сторону вопроса и оценивать, кто в результате какого решения по данной заявке может увеличить или уменьшить своё участие в проекте, но боюсь в нашем разделе нету никаких механизмов для принятия подобного решения. ·Carn 12:34, 13 июня 2020 (UTC)[ответить]
              • «совершенно нормальная ситуация» — согласен, но если мы флаг не выдаем по причине того, что «а вот он блокировать вандалов начнет, а вдруг не того заблокирует, лучше не рисковать, и обойдемся уж как-нибудь без удаленных статей», то это уже выбивается. Иначе зачем проверять, если предполагаем, что он и так все сделает хорошо, и не залезет куда не следует.
                «Если же мы начнём игнорировать правила во имя абстрактной пользы, то нам придётся принимать во внимание субъективную сторону вопроса и оценивать, кто в результате какого решения по данной заявке может увеличить или уменьшить своё участие в проекте» — у нас есть 5 столп и правило ВП:ИВП, которые прямо говорят, что все тут во имя абстрактной пользы, и даже правила — набор инструкций, по получению самой пользы — а если правила не ведут к получение пользы, то их надо игнорировать. Luterr (обс.) 12:06, 14 июня 2020 (UTC)[ответить]
  • Выше этого моего сообщения прямо на этой странице вызывается скрипт Voting.js
Почему он ничего не показывает?·Carn 07:56, 11 июня 2020 (UTC)[ответить]
  • Отвечаю по всем пунктам сразу. Мои самоограничения полностью отражены во фразе «Границы своей компетенции знаю, при необходимости всегда готов попросить о помощи и выслушать совет специалиста». Любые другие (само)ограничения в этих условиях (6+ лет работы бюрократом и пр.) считаю унизительными. По поводу игры в вопросы и ответы я уже писал, что не собираюсь отвечать в экзаменационном формате и развлекать аудиторию. Это не заявка от новичка, а вынужденное действие для возможности продолжения работы. Это не заявка на статус, а заявка на сохранение статус-кво. — Adavyd (обс.) 18:03, 12 июня 2020 (UTC)[ответить]
  • Пусть и это формальность, но я прошу вас написать на js выражение заменяющее в строке даты в формате «ГГГГ.ММ.ДД» на даты в формате «ДД месяц_прописью ГГГГ» с помощью единственного вызова функции replace. Заранее спасибо. Don Rumata 19:21, 13 июня 2020 (UTC)[ответить]
    • Спасибо за вопрос. Я выше написал, что на этой странице хотелось бы обойтись без вопросов в экзаменационном формате. Комментарий отправил по емайлу. — Adavyd (обс.) 04:15, 14 июня 2020 (UTC)[ответить]
      • Я тоже ответил вам письмом. Я и не ожидал что ваш ответ на такой простой вопрос будет сколь-нибудь показательным для других в качестве демонстрации знаний js, т.к он легко гуглится в Stackoverflow. Скорее это была бы демонстрация открытости и уверенности. Очень жаль, что вы отказались. Don Rumata 11:01, 14 июня 2020 (UTC)[ответить]

Обсуждение (Adavyd)[править код]

  • Техники предлагали организовать работу голосования в АК через JSON, но почему-то этого до сих пор никто не сделал. В условиях, когда необходимо редактировать JS файл, это могут сделать другие более компетентные администраторы интерфейса. За 2020 год лишь одна правка в JS, а за всё время их примерно 20 за 7 лет. Поэтому категорически (−) против — С уважением, Helgo13(Обс.) 18:13, 8 июня 2020 (UTC)[ответить]
    • Ну вот началось. Сразу видно, что цена на нефть упала — бензина в тлеющий конфликт вокруг АИН плесканули от души. — VladXe (обс.) 18:19, 8 июня 2020 (UTC)[ответить]
    • Техники предлагали организовать работу голосования в АК через JSON - это уже целиком сделано, готово, осталось только протестировать (пишет сейчас в чате один из АИ). MBH 18:22, 8 июня 2020 (UTC)[ответить]
      • Выборы начинаются уже́ в эти выходные. Не вижу необходимости срочно менять механизм на что-то новое и как следует не отлаженное, лишь бы не допустить присвоения флагу неугодному по чисто википолитическим соображениям кандидату. — Deinocheirus (обс.) 15:46, 15 июня 2020 (UTC)[ответить]
        • А что поменяется от того, что новый скрипт включится в эти выборы или в следующие? Тем более на том уровне, на котором его возможно было отладить, всё было произведено. Я не вижу как эти два события (заявка на флаг и скрипт) вообще с друг-другом конфликтуют. Сергио (обс.) 17:01, 15 июня 2020 (UTC)[ответить]
          • Какой-то острой необходимости вводить скрипт прямо перед выборами я тоже особо не вижу, ибо есть риск сорвать выборы. Не нужно следовать по пути некоторых компаний, у которых релиз по сути является открытым бета-тестом. В любом случае это нужно решать совместно с бюрократами, а не вводить решением кого-то из инженеров. Vladimir Solovjev обс 17:15, 15 июня 2020 (UTC)[ответить]
            • Я в первую очередь советуюсь с бюрократом Track13 в этом вопросе, а не с кем-либо с другим. Открытый бета-тест уже неделю проходит у меня на СО. Если есть желание, буду признателен если присоединитесь. Так же мы обсудили варианты если что-то пойдёт не так — всего лишь нужно будет на странице голосования заменить один параметр шаблона на другой, тем самым переопределить какой из скриптов будет грузиться. Сергио (обс.) 17:50, 15 июня 2020 (UTC)[ответить]
              • Раз не дали ссылку на обсуждение этого теста, то пишу сюда: из того, что я увидел на стр. /* и не увидел на стр. Предварительные итоги, делаю вывод, что использовать тестируемый алгоритм ещё рано, и неделю должна уйти только на повторный тест, после исправления ошибок. — VladXe (обс.) 05:33, 17 июня 2020 (UTC)[ответить]
                • Страница «Предварительные итоги» ведёт вовне и не зависит от работы скрипта. Новый скрипт оставляет точно такие же записи на подстраницах, что и предыдущий и при этом учитывает предыдущие голоса самого участника в оформлении — именно это является результатом его работы. Подсчёт голосов inwiki хочется сделать давно и многим, но этого пока, увы, нет. То о чём вы говорите не является ошибкой. ·Carn 06:08, 17 июня 2020 (UTC)[ответить]
  • В связи вот с этим случаем: Обсуждение участника:Adavyd/Архив/9#MoreMenu gadget вынужден быть против, участник скорее всего всегда будет первым в списке администраторов интерфейса и к нему будут обращаться за помощью, которую он не сможет оказать.·Carn 18:44, 8 июня 2020 (UTC) — снимаю, нет необходимости вступать в конфликт, выборы в АК пройдут, если будет новый скрипт и флаг перестанет быть нужен — его будет желательно снять, не обязательно делать это сейчас и ставить бюрократов в неловкое положение когда формально фактор автобуса по поддержке выборов действительно пока равен одному.·Carn 19:27, 8 июня 2020 (UTC)[ответить]
  • (−) Против выдачи флага без явной необходимости, да ещё и участнику, чья техническая грамотность, в отличие от Track13 и DR, сомнительна, так что весь смысл от введения флага АИН пойдёт насмарку. Викизавр (обс.) 19:50, 8 июня 2020 (UTC)[ответить]
    • Вы видимо забыли, в чем именно состоял смысл введения флага АИН. А именно - ограничение числа имеющих возможности править критические файлы в связи с возможностью взлома и сознательного злоупотребления, а не якобы "сомнительной технической неграмотности". Вам процитировать с Меты ? TenBaseT (обс.) 07:21, 13 июня 2020 (UTC)[ответить]
      • В случае, когда в разделе есть принятое правило ВП:АИН отсылки на мету выглядят не очень легитимно. Для получения данного флага необходим «высокий уровень доверия сообщества», участник Wikisaurus вполне может сказать что он участнику не доверяет по любым субъективным причинам. ·Carn 12:44, 13 июня 2020 (UTC)[ответить]
        • Я отвечал на аргумент «весь смысл от введения флага АИН пойдёт насмарку». «Смысл введения флага» не относится к принятому правилу АИН от слова совсем, возможно вы не в курсе происходившего. Так что если бы участник сказал "не доверяю" это одно, а он совершенно не это высказал. TenBaseT (обс.) 18:17, 13 июня 2020 (UTC)[ответить]
  • (+) За. Участнику полностью доверяю, в его компетентности и критичности в оценке своих навыков сомнений нет. Если коллега считает, что ему нужен флаг, то я его, безусловно, поддержу. — Ksc~ruwiki (обс.) 20:14, 8 июня 2020 (UTC)[ответить]
  • У наших выборов бас-фактор, конечно, так себе. Чего стоит одно то, что их много лет поддерживает Калан, который давно неактивен. Если их уже можно провести в этот раз с настройками в JSON, то я бы предпочёл этот вариант. Если же есть объективные причины так не делать, то можно и выдать флаг. Но всё же очень хочется уйти от раздачи флагов по принципу «был, есть и будет есть». — putnik 23:47, 8 июня 2020 (UTC)[ответить]
    • Учитывая, что решение проблемы проведения выборов уже имеется, то после ответа выше я строго (−) Против присвоения флага. — putnik 18:23, 12 июня 2020 (UTC)[ответить]
  • За с условием: как только потребность во флаге отпадёт (в связи с переходом голосования в АК на JSON), так флаг будет сдан добровольно именно из-за «границы своей компетенции знаю» — судя по реплике, компетенция не так широка, как хотелось бы для держателя флага. А так случай подпадает под положение ВП:АИН: «если участник <...> регулярно делает правки, поддерживая работоспособность определённых механизмов, то не стоит лишать такого участника флага без веских оснований». — VladXe (обс.) 04:35, 9 июня 2020 (UTC)[ответить]
  • Флаг нужен для проведения выборов в АК, пока что другой механизм не введён, поэтому позицию участников, которые выступают против, я не совсем понимаю (напоминаю, что выборы поддерживают не инженеры, а бюрократы). Даже если приходится делать всего 1 правку за полгода, но если это нужно для поддержания работоспособности механизма, а также с учётом того, что выборы в АК уже совсем скоро (причём участник чётко знает, что и как делать, поскольку занимался этим во время большинства выборов, когда я был бюрократом), то крайне желательно, чтобы флагом владел не один бюрократ — нужна подушка безопасности. Так что наличие флага нужно подтвердить. А когда новый механизм введут и если после этого необходимость в флаге отпадёт, то участник наверняка сам флаг с себя снимет. Vladimir Solovjev обс 07:38, 9 июня 2020 (UTC)[ответить]
    • Так а в чём проблема, если обычно находящийся онлайн Track13 будет неактивен, пингануть DR, кого-то из инженеров или кто ещё там подтвердит флаг, чтобы они закрыли голосование? Действительно ли для этого нужно выдавать флаг АИН единственному из бюрократов, чья техническая компетентность очень сомнительна? Викизавр (обс.) 09:50, 9 июня 2020 (UTC)[ответить]
      • «Единственному технически некомпетентному из бюрократов» — АИ на утверждение имеется? Sir Shurf тоже никогда себя к технарям не относил. А вообще фраза на или за гранью ВП:ЭП, можно было сказать тоже самое, но мягше. — VladXe (обс.) 09:53, 9 июня 2020 (UTC)[ответить]
      • Правка скрипта нужна не для закрытия, а для правильных параметров голосования, которые могут измениться в последний момент перед его началом. Я, конечно, польщён, что мне одному доверено сидеть до 00UTC и следить, чтобы всё было ОК, но был бы рад разделить эту ответственность с кем-то ещё. Не с DR или с кем-от из инженероов, при всём уважении, они за выборы АК не отвечают и бюрократам ничем не обязаны. Что касается технической компетентности, то некоего абсолютного значения, при котором человек некомпетентен, не существует. Все техники что-то знают лучше, что-то хуже, а что-то вообще не знают. Если мы говорим о конкретной задаче, под которую запрошен флаг, то Adavyd её выполнял и проблем не было. Если он лез куда-то и где-то что-то ломал, не понимая границ своей знаний и умений, то нужно привести примеры, а не балансировать на грани ЭП. Track13 о_0 17:00, 9 июня 2020 (UTC)[ответить]
        • Если коллега Adavyd возьмёт самоограничение, что не сделает никаких правок с помощью флага кроме относящихся к голосованию, а также пообещает присматривать за своим аккаунтом как положено, чтобы его не угнали, то я снимаю свои претензии. Но ведь он не возьмёт самоограничение, он уже явно высказывался, что любое ограничение на его действия считает личным оскорблением и в таком случае покинет проект. P. S. Если вам не нравится фраза, что его «техническая компетентность очень сомнительна», можно позадавать вопросы по знанию JS и CSS — но готов ли коллега Adavyd на них отвечать? Викизавр (обс.) 18:20, 9 июня 2020 (UTC)[ответить]
        • P. S. На всякий случай поясню второй пункт, про отличие бюрократа с флагом АИН и бюрократа, который может выдать себе флаг АИН в любой момент: если злоумышленник захватит аккаунт бюрократа и выдаст себе флаг АИН, то это увидят все люди, наблюдающие за его СОУ, то есть многие десятки активных метапедистов; так что любое вредоносное действие, осуществлённое таким способом, вскоре будет отменено; если же у бюрократа уже есть флаг АИН, злоумышленнику достаточно сделать правку где-то в мутном месте с установлением криптомайнера — и при правильных действиях злоумышленника это никто не заметит много дней. Появление в небольшой группе технически компетентных и потому, как я полагаю, способных позаботиться о своём аккаунте, участников одного без должных навыков — это явная уязвимость, этот участник для какой-нибудь фишинг-атаки будет очевидной целью. Викизавр (обс.) 18:31, 9 июня 2020 (UTC)[ответить]
          • У всех бюрократов, насколько я в курсе, включена MFA, а все изменения в мутных местах отслеживаются ботом с оповещением для весьма широкого круга активных участников. По технической компетенции, мы как-то резко перескочили со знания JS и CSS на уязвимость к фишинг-атакам. Что-то мне подсказывает, что плохое знание JS никак не говорит о том, что человек радостно запускает что попало из странных писем. Я даже не знаю, как эту неуязвимость к фишинг атакам можно проверять. Что касается «не сделает никаких правок с помощью флага кроме относящихся к голосованию», так он уже их не делает, но выше ему это ставят в укор. Track13 о_0 18:49, 9 июня 2020 (UTC)[ответить]
            • Тьфу, я плохо сформулировал: это, конечно же, два разных пункта про техническую компетентность — знание JS/CSS для того, чтобы совершать правки, не относящиеся к голосованию, и умение и готовность тщательно беречь свой аккаунт; такое умение, как мне кажется, можно ожидать от любого ответственного человека с некоторыми техническими навыками (отнюдь не обязательно связанными с технической деятельностью в Википедии), но таких навыков может быть лишён человек с ярко выраженным гуманитарным складом ума; я не знаю, как это в таком случае можно проверить, к сожалению. Викизавр (обс.) 19:03, 9 июня 2020 (UTC)[ответить]
              • В современном мире навык не открывать непонятно что из непонятного источника есть у всех, кто более или менее работает в этих ваших интернетах, дело тут не в складе ума, а просто в практике. Заведомо отказывать в этом навыке бюрократу с очевидно большим опытом работы в интернете немного странно, а как доказать существование этого навыка не совсем понятно. Да и за историю руВП я не припомню случаев взлома таким образом. Кроме того, и у меня, и у других коллег на этой странице про MFA даже не спрашивали. Track13 о_0 22:15, 9 июня 2020 (UTC)[ответить]
      • «чья техническая компетентность очень сомнительна?» — прочитал текущее обсуждение, и не нашел откуда вы это вывели? Luterr (обс.) 19:56, 10 июня 2020 (UTC)[ответить]
        • Доказывать, как известно, нужно наличие, а не отсутствие. Когда участник с высокой технической грамотностью много лет участвует в проекте, это видно, заметно по его действиям. Для кандидата лично мне это не было заметно никогда, он всегда производил впечатление такого классического гуманитария, резко негативно относящегося к определённому паттерну действий "технарей". MBH 00:29, 11 июня 2020 (UTC)[ответить]
          • А негативное отношение к паттерну "технарей" = техническая неграмотность ?? Замечательная оговорка, спасибо. TenBaseT (обс.) 07:21, 13 июня 2020 (UTC)[ответить]
            • Это две независимые вещи. Отсутствие значительной технической грамотности одно, "гуманитарный" стиль мышления (отрицание возможности, допустимости улучшения технических механизмов в проекте, если это улучшение меняет чьё-то привычное рабочее окружение) - другое. "Гуманитарный стиль мышления", как я тут это назвал, характерен для ряда участников (я бы назвал тут Гирлу, Дмартина, и вот Адавыда) и вызывает их вечную холодную войну с "технарями". И хотя основными аргументами здесь являются техническая неграмотность и отсутствие необходимости во флаге, но и "гуманитарный стиль мышления" и твердокаменная уверенность в своей правоте и неправоте несогласных, приводящие при наличии флага к вышеописанным отменам полезных и предварительно обсужденных правок в шаблонах, тоже весьма негативно влияют на техническую сферу работы в проекте, из-за чего вредны и не должны быть допускаемы. MBH 11:03, 13 июня 2020 (UTC)[ответить]
              • Очень спорная позиция и очень спорный аргумент. Я человек с полностью техническим мышлением тоже в очень многом не согласен с указанными "технарями" и "гуманитарный стиль мышления" тут не причем. Ну мы все знаем почему, не буду заново вдаваться в подробности. И разумеется многие взгляды указанных вами участников положительны и правильно влияют на техническую сферу работы в проекте (и не только техническую разумеется). Так что понимание, чьё мнение вредно для Википедии а чьё полезно - у нас с вами разное. И аргументом это являться не может. TenBaseT (обс.) 18:24, 13 июня 2020 (UTC)[ответить]
      • Всегда нужна подстраховка. Тем более что этапы сменяются в 0 UTC, в это время у Трека глубокая ночь, поэтому если вы посмотрите статистику, то именно Adavyd обычно менял параметры. Поэтому ваш аргумент про отсутствие явной необходимости не соответствует реалиям. Причём там нет ничего что-то сложного, нужна только внимательность. И к нему никаких претензий никогда не возникало, когда он их менял. Поэтому и ваш аргумент про техническую компетенцию невалиден и находится на грани нарушения правила ВП:ЭП. Не говоря о том, что выше приводили цитату из ВП:АИН: «если участник <...> регулярно делает правки, поддерживая работоспособность определённых механизмов, то не стоит лишать такого участника флага без веских оснований». Vladimir Solovjev обс 08:13, 11 июня 2020 (UTC)[ответить]
  • (+) За.— Erokhin (обс.) 17:05, 9 июня 2020 (UTC)[ответить]
  • Лучше переписать скрипт (что уже сделано и сейчас тестируется) и избавиться от необходимости править его код бюрократами. Если даже и нужны ещё бюрократы с флагом, лучше пусть флаг получит кто-то технически грамотный, как u:Levg. Видеть этого участника с флагом у меня желания нет, причин много. Он неоднократно отменял (или пытался/требовал отменить) без обсуждения технические правки, улучшающие шаблоны и совершённые по результатам обсуждения (помню кейсы с шаблонами "Картина" и "Примечания"). Он регулярно устраивает сцены драмы в обсуждениях, когда ему что-то не нравится, постоянно выдавая фразу "Если это не отменят/сделают, я уйду из проекта". Мне неизвестны свидетельства того, чтобы техническая грамотность кандидата сколь-либо заметно возвышалась над средним по проекту уровнем (а у обладателей этого флага она, очевидно, должна быть высокой). Наличие участника в списке АИ будет приводить к тому, что к нему будут обращаться сторонние участники по вопросам, требующим технической компетентности (как уже произошло с MoreMenu). Поведение кандидата в сфере технических правок (см. выше про его жёсткую оппозицию не нравящимся ему правкам в шаблонах), по моим данным, внесло его в узкий список участников, получение которыми флага ИА особенно возмутило и разочаровало инженеров первого призыва и привело к массовой сдаче ими флагов. Некоторые из них, насколько я помню, ждали снятия флага с участников из этого узкого списка, чтобы вернуться к инженерской работе, не находясь под постоянной угрозой отмены своих правок из-за того, что они не понравились такому АИ. MBH 14:23, 10 июня 2020 (UTC)[ответить]
    • Активность Levg’а не позволяет ему быть «запасным» АИ, быстрее уж временно флаг получить двум другим бюрократам, чем ждать, когда он появится. — VladXe (обс.) 18:39, 10 июня 2020 (UTC)[ответить]
    • Только вот выборы стартуют уже скоро, изменять что-то прямо перед выборами не стоит, все нужно вводить заранее. В любом случае, когда будет новый скрипт, тогда разговор будет более предметным, пока что у нас есть данность: Adavyd один из самых активных бюрократов, причём по своему часовому поясу ему гораздо удобнее следить за технической стороной голосования. Он это делал не один раз, к нему по этому моменту не было ни одной претензии. Vladimir Solovjev обс 08:19, 11 июня 2020 (UTC)[ответить]
      • Я думаю что хотя аргументы выше могут быть сочтены существенными, чтобы не выдавать полноценный флаг АИН, однако они не подходят в случае, если Adavyd согласится на флаг с ограничениями (под которыми я понимаю либо выдачу флага только для поддержки выборов и/или только на время, пока её не переведут на json). ·Carn 08:53, 11 июня 2020 (UTC)[ответить]
      • Безотносительно данной заявки: до голосования ещё три недели, это очень много. Причём разница между трёхнедельным тестированием и полугодовым тестированием скорее в пользу первого, так как в случае проблем код будет значительно проще поправить. — putnik 12:47, 11 июня 2020 (UTC)[ответить]
      • Новый скрипт уже есть. Написан был в феврале и сейчас проходит тестирование здесь. Сергио (обс.) 17:51, 11 июня 2020 (UTC)[ответить]
  • (+) За.— Участник - опытный, доверять можно. К компетентности участника не имею претензий. Поддерживаю его. GomerPyle1991 (обс.) 18:45, 10 июня 2020 (UTC)[ответить]
  • (+) За. Особых проблем с тем что флаг будет использоваться для решения какой-то локальной и конкретной задачи я не вижу. Def2010 (обс.) 10:21, 11 июня 2020 (UTC)[ответить]
  • После ответа кандидата от 18:03, 12 июня 2020 в секции вопросов я не только (−) категорически против сохранения у него флага АИ, но и вообще против сохранения у него каких-либо расширенных флагов, и очень бы хотел попросить его пройти конфирмацию по каждому из них. Если Adavyd считает, что запрашивая какие-то права, он делает одолжение сообществу, и что любая проверка его компетенции
    это личное оскорбление, то в коллективном проекте иметь какие-то расширенные права ему противопоказано с таким подходом и отношением к другим участникам. Что касаемо правки скрипта голосования: скрипт уже переделан, запрос прав только на этом основании более не аргумент. А какого-либо уровня технической компетенции участник не доказал и отказался отвечать на вопросы. Meiræ 19:16, 12 июня 2020 (UTC)[ответить]
  • (+) За. Своим опытом, подкованностью в ходе организации, проведения и подведения итогов выборов АК и А на протяжении 8 лет, разбором и исправлением технических неурядиц при голосованиях этот компетентный, добросовестный и осторожный коллега уже доказал своё право на флаг. За столько лет стабильно работящий коллега ни разу не выпадал из проекта даже кратковременно. Выгорание ему не свойственно. Никто не указал ни на какие его ошибки в технической деятельности. Сквозящее в отдельных репликах ПЗН никогда не было валидным аргументом в Википедии. Кроме пользы для проекта ничего иного от вручения ему флага не может быть. — Leonrid (обс.) 19:47, 12 июня 2020 (UTC)[ответить]
  • (+) За разумеется. У участника имеется и необходимость во флаге и техническая подкованность достаточная для владения флагом. По выборам - вот когда переход на джейсон будет закончен, отлажен и оттестирован на реальных выборах - будет и обсуждение этого варианта, а пока что участнику флаг необходим (хотя по аналогии с событиями 2018 года, когда был срочно переведен на джейсон гаджет флагов, я уверен что и это будет форсировано и сделано в кратчайшие сроки, лишь бы флаг не получил). Голоса против обоснованы исключительно "политическими" разногласиями на фоне АК:1076 и личным отношением, и не имеют под собой фактических аргументов и претензий. У нас тут не голосование, а обсуждение и необходимы сильные фактические аргументы чтобы тому кто уже имеет данный флаг отказать в продлении. Технические вопросы (по которым можно судить о якобы технической неграмотности) так и не были заданы. Примеры правок даны в комментарии Carn. TenBaseT (обс.) 07:21, 13 июня 2020 (UTC)[ответить]
    • Прошу вас зачеркнуть фразу "Технические вопросы (по которым можно судить о якобы технической неграмотности) так и не были заданы." как не соответствующую действительности (см. коммент выше). Задавать дополнительные вопросы когда участник дважды отказался отвечать: «не в экзаменационном формате», «не собираюсь отвечать в экзаменационном формате и развлекать аудиторию» — я не очень понимаю, в каком формате можно задать вставшему в такую позицию человеку вопросы, чтобы он ответил. Не уверен что любые мои усилия на подбор индивидуального подхода в данном случае окупятся. ·Carn 08:36, 13 июня 2020 (UTC)[ответить]
  • Вот почему я не удивлён сбывшемуся предсказанию, что некоторые техники будут валить кандидатов на основании личной неприязни при абсолютном отсутствии реальных аргументов "против"? --wanderer (обс.) 07:58, 13 июня 2020 (UTC)[ответить]
  • (+) За Флаг нужен для решения конкретной задачи, в выполнении которой участник компетентен. О чём тут можно ещё говорить? — Ibidem (обс.) 14:36, 13 июня 2020 (UTC)[ответить]
  • (+) За. Нет оснований не доверять и опасаться, что флаг будет использован за границами компетентности. Наличие флага у коллеги будет полезным для проекта, ВП:ИВП. — Niklem (обс.) 21:33, 13 июня 2020 (UTC)[ответить]
  • (!) Комментарий: Прошла неделя с момента подачи заявки. Были сформулированы два вопроса от Карна и Дона Румата. На первой линии обсуждения отметилось не менее 16 участников, из них 5 с флагом А. Согласно правилу ВП:АИН «… После этого бюрократы оценивают аргументы, касающиеся технической компетенции и уровня доверия сообщества к кандидату, и принимают решение о присвоении флага.…» Таким образом, учитывая ноль ответов на всего два поставленных вопроса, наличия нескольких (5 против, 4 в сложной позиции) отрицательных аргументированных позиций представляется, что оба критерия для предоставления флага АИН находятся на грани выполнения или даже ниже. Искренне удивляет позиция участника, сначала предложившего обсудить технические вопросы, а потом отказавшегося от этого с аргументации к личному авторитету. С учётом того, что участник «Эту заявку считает формальностью», то и соответствие критериям можно считать формальностью: есть подтвержденные компетенции и высокое уровень доверия — флаг присваивается, иначе — нет. — Ailbeve (обс.) 22:30, 13 июня 2020 (UTC)[ответить]
  • (−) Против: не могу доверять участнику, настолько несерьёзно и пренебрежительно относящемуся к заявке. Есть ВП:АИН, где явно указано: «Помимо этого в ходе обсуждения кандидату могут быть заданы вопросы, направленные на проверку его технической компетентности». Отказ от ответов на заданные вопросы считаю тревожным знаком и поводом считать, что кандидат может так же своевольно распоряжаться флагом. adamant.pwncontrib/talk 10:00, 15 июня 2020 (UTC)[ответить]
  • (+) За. Во-первых, я получил от кандидата письмо с удовлетворительным ответом на свой вопрос. Во-вторых, он явно осознает свой уровень компетентности. И в-третьих, если MediaWiki:Script/Voting.js переведут на json, а других правок, специфичных для флага администратора интерфейса не будет 6 месяцев, то флаг будет автоматом снят согласно ВП:АИН. До наступления этих условий флаг ему нужен и полезен. Риска использования флага не по назначению я лично не вижу. Don Rumata 15:17, 15 июня 2020 (UTC)[ответить]
    • Автоматом он снят точно не будет, придётся подавать новую заявку, в которой группа поддержки кандидата потребует полноценных оснований для снятия флага (отсутствие необходимости в каковом она таковым основанием вовсе не посчитает). MBH 16:20, 15 июня 2020 (UTC)[ответить]
      • Макс, тебе не хочется изучить правило ВП:НО в отрыве от редактирования Википедии? Господа техники, вам очень нравится раскачивать лодку? Хватит травить бюрократов, их и так осталось мало уже! Vladimir Solovjev обс 17:20, 15 июня 2020 (UTC)[ответить]
        • Я не травлю бюрократов, совершенно, и не вижу в своей реплике нарушения НО. Возможно, таковым вы посчитали выражение "группа поддержки кандидата", но ничего оскорбительного в нём нет, эту концепцию можно выразить длиннее, но и так всем всё понятно и неоскорбительно. MBH 18:31, 15 июня 2020 (UTC)[ответить]
          • Макс, сколько человек должны тебе сказать, что отдельные "техники" занимаются травлей, что бы ты признал очевидное? Или вы всё понимаете и сознательно раскачиваете лодку? --wanderer (обс.) 03:55, 16 июня 2020 (UTC)[ответить]
            • Люди могут как искренне поддерживать, так и искренне не поддерживать кого-то, иное не соответствует ВП:ПДН. Все эти обвинения неконструктивны совершенно, так как и близко не соответствуют целям данной страницы. ·Carn 06:06, 16 июня 2020 (UTC)[ответить]
              • Только вот противная сторона про ПДН явно забывает, позволяя себе разные высказывания, которые находятся как минимум на грани ВП:НО. Понимаешь, именно из-за подобного я в своё время сдал флаг. Но я убеждаюсь, что ничего это не изменило. Vladimir Solovjev обс 06:52, 16 июня 2020 (UTC)[ответить]
  • (+) За не вижу не одной причины, которая может вызывать недоверие. Цель прописана. JukoFF (обс.) 21:21, 15 июня 2020 (UTC)[ответить]
  • При всем моём отношении к институту бюрократов, получит ли юзер флажок для редактирования js было ну совершенно фиолетово. Но позвольте, раз он уже ударился в кулуарные приватные переписочки, то это всё, приехали. Если человек не считает себя частью сообщества, публично игнорирует вопросы, отказывается следовать процедурам, то никаких флагов ему давать нельзя априори, просто по причине отсутствия доверия. Доверия как в той части, что флаг будет всегда применяться в рамках, установленных тем самым сообществом, к которому он не лоялен и от которого дистанцируется, так и в том, что использоваться флаг будет уравновешенно (участник, видимо, в социальном плане пошёл сейчас в разнос, сжигает все мосты, а мы помним ещё и попытки шантажа его уходом из проекта). Отдельно не могу не заметить, по пренебрежительным и снисходительным репликам создаётся впечатление, будто заявку подал сам Джимбо или кто-то близкий к его статусу, а не простой участник рувики. Какой уж тут флаг? (−) Против. По крайне мере, сейчас.—Iluvatar обс 08:55, 16 июня 2020 (UTC)[ответить]

Итог[править код]

  • В обсуждении прозвучали следующие аргументы за сохранение кандидатом имеющегося у него флага Администратора интерфейса:
  1. Участник выполняет с помощью флага конкретные функции, которые на данном этапе выполнить без него невозможно, как например обслуживание ВП:ВАРБ.
  2. Участник обладает набором прав входящих в флаг АИН много лет и грамотно распоряжается этими правами.
  3. В обсуждении не было показано что наличие этого флага у кандидата содержит риски для проекта лежащие в основе выделения прав АИН в отдельный флаг.
  • Прозвучали также аргументы против сохранения у участника данного флага:
  1. Узкий набор задач, который кандидат собирается решать с помощью флага.
  2. Недоверие к соответствию технического уровня кандидата требованиям ВП:АИН.
  3. Метод ведения кандидатом обсуждения по своей заявке, в том числе нежелание выполнять тестовые задания.
  4. Недоверие к самому кандидату.

Аргументы 1 и 2 против нейтрализуют друг-друга. В своей узкой области применения прав АИН кандидат продемонстрировал свою безусловную компетентность многолетним опытом работы со скриптами ВАРБ. Нет причин предполагать, что в случае желания кандидата расширить область применения флага он подойдёт к этому менее ответственно, чем к своей текущей деятельности. С аргументом 3 против трудно поспорить, но он не является препятствием для сохранения флага при условии уже доказанной компетентности в предполагаемой области применения. Аргумент 4 против субъективен и при отсутствии конкретных фактов граничит с ВП:ПЗН. Поскольку этот аргумент субъективен, он также не может быть препятствием для сохранения флага при условии уже доказанной компетентности в предполагаемой области применения.

До сих пор — формальный разбор аргументов, согласно которому флаг участнику оставлен.

Пару слов от себя: коллеги, сделайте доброе дело себе и проекту, давайте распрощаемся с эмоциями оставшимися от АК:1076 и вернёмся к ВП:ПДН. Sir Shurf (обс.) 10:43, 16 июня 2020 (UTC)[ответить]

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Запрашиваю флаг в первую очередь для работы бота, обновляющего эдитнотисы для защищённых до апатов статей, см. обсуждение, пример правок бота. Бот также удаляет (не удалением страницы, а её очисткой) нотисы для статей, убранных из фильтра.

Помимо этого, планирую совершать технические правки на полностью защищённых страницах, примеры таких правок, сделанных в последнее время по моему запросу: [46], [47], [48]. Править js/css не планирую, флаг АИ не нужен.

Подавал заявку в 2016-м году, ответы на стандартные и нестандартные вопросы - в ней. MBH 12:03, 27 июня 2020 (UTC)[ответить]

Вопросы (MBH)[править код]

  • В {{Editnotice/АПАТ}} есть несколько дополнительных параметров (подробное описание см. в {{Защита до АПАТ}}). Можете предложить удобные для работающих с фильтром администраторов варианты их учёта в полуавтоматическом режиме? adamant.pwncontrib/talk 12:39, 27 июня 2020 (UTC)[ответить]
    • Причина и дата снятия защиты (со статьи, с которой она ещё не снята) в фильтре не указываются (теоретически админ, меняющий фильтр, может при внесении новой статьи добавить эту инфу последней строчкой в описание фильтра - оттуда бот сможет их читать). Дату добавления статьи в фильтр можно было бы получить анализом разницы между предпоследней и последней версиями фильтра (чтобы понять, какая статья между ними была добавлена), но, насколько я вижу, апи не выдаёт историю фильтров, только последнюю версию. Итого, бот наверное сможет добавлять эти данные, если при каждом добавлении статьи в фильтр в описании фильтра последней строкой в стандартизированном формате будут указываться статья, причина и предполагаемая дата снятия (хотя в последнем параметре я вообще вижу мало смысла, обычно заранее неизвестно, когда такую защиту можно будет снять, и ставится она на годы, пока не будет снята) MBH 14:14, 27 июня 2020 (UTC)[ответить]
      • Кажется, если апи выдаёт только последнюю версию, то модифицировать только последнюю строчку не очень хороший вариант — если бот не успеет какую-то информацию забрать до очередного изменения фильтра, то он её упустит. А если сразу несколько страниц меняется? В общем, получается, надо или всё описание занимать дублированием списка страниц на защите, или вписывать в сам код фильтра. На счёт последнего параметра — возможные причины для того, чтобы ставить страницу на бессрочную защиту описаны в ВП:ПЗС. Мне кажется, к большинству страниц из списка эти критерии не применимы, значит, нужен явно указанный срок когда защиту следует снять. adamant.pwncontrib/talk 15:56, 27 июня 2020 (UTC)[ответить]
  • Считаете ли вы корректной такую правку? Следует ли ожидать от вас схожего подхода при редактировании защищённых страниц? adamant.pwncontrib/talk 16:24, 27 июня 2020 (UTC)[ответить]
    • Считаю, что я дал участнику в описании правки полезный совет, которому ему следовало бы последовать (тем более, что в итоге выяснилось, что _такого_ оспаривания администратор не разрешал). Нет, участники, имеющие право правки защищённых страниц, как правило достаточно способны к обсуждению, поэтому с ними такие разногласия следует решать на странице обсуждения. MBH 18:43, 27 июня 2020 (UTC)[ответить]
      • То есть, если вашу правку опротестует участник без права редактирования защищённых страниц, вы будете действовать по другому? adamant.pwncontrib/talk 19:37, 27 июня 2020 (UTC)[ответить]
        • Я в любом случае буду обсуждать. Вы же сперва спросили, что я буду делать, если мою правку (на защищённой странице) отменят. MBH 20:46, 27 июня 2020 (UTC)[ответить]
  • Насколько я вижу, в прошлом обсуждении часть претензий также относилась к тому, что вы можете небрежно относиться к работе, рассчитывая на то, что потом за ботом кто-нибудь руками поправит. В случае защищённых страниц пул участников, которые смогут поправить ошибочные действия очень ограничен и критически важно, чтобы это делал именно тот участник, по чьей ответственности они были внесены (а лучше не допускал внесения таких правок). Что вы планируете делать (а может, уже делаете), чтобы минимизировать количество ошибочных правок, а также обеспечить оперативность их устранения? adamant.pwncontrib/talk 16:30, 27 июня 2020 (UTC)[ответить]
    • Ботоправки и правка защищённых страниц - две очень разные сферы деятельности, по-моему некорректно в принципе переносить что-то из одной на другую. Ботоправки, по определению, совершаются ботом, то есть без присмотра человека, инженерские правки совершаются вручную. Все проблемы с ботоправками, по крайней мере в случае моего бота, вызваны одной причиной: ты пишешь бота, редактирующего определённый синтаксис, рассчитывая на то, что данный синтаксис встречается только в определённом контексте. Ты перед этим просмотрел десятки случаев, когда встречается этот синтаксис, и во всех этих случаях бот работал корректно. Но оказывается, что в каких-то статьях этот синтаксис использовался для другого, и ботоправка в этих статьях что-то ломает. Эти случаи очень редки, не попадают в предварительный просмотр десятков тестовых ботоправок, поэтому и не обнаруживаются на этапе до запуска бота. К ручной правке защищённых страниц это всё не имеет никакого отношения, там правится одна индивидуальная страница, с предпросмотром (если страница - шаблон, то можно сделать тестовую копию и посмотреть, как работает её включение), так что вышеописанный путь появления ошибок в ботоправках в принципе не может привести к возникновению ошибок в ручных инженерских правках. MBH 18:40, 27 июня 2020 (UTC)[ответить]
      • Выше вы привели примеры правок своего бота по расстановке editnotice. Достаточно ли приведённых по данной ссылке правок, чтобы быть уверенным, что с расстановкой editnotice проблем точно не будет? Почему? На счёт ручных правок — с единичными страницами всё действительно просто, с шаблонами может быть сложнее. В каких случаях вы планируете сперва отрабатывать правки на тестовой странице и ориентировочно сколько примеров его включений будете в таком случае рассматривать? Как вы будете отбирать данные примеры? adamant.pwncontrib/talk 19:48, 27 июня 2020 (UTC)[ответить]
        • Я полагаю, что с расстановкой эдитнотисов проблем не будет. Я знаю, что если эдитнотис пишется для подстраницы, то в полном имени подстраницы надо заменять слеши на дефисы, но в пространстве статей нет подстраниц (если же это нужно для любых статей со слешем в названии, легко сделать такую замену в боте). Эдитнотис на том месте может уже существовать, легко указать боту, чтобы он не замещал его, а добавлял шаблон к существующему тексту (если там другой текст/шаблон). В каких случаях вы планируете сперва отрабатывать правки на тестовой странице - во всех случаях достаточно нетривиальных правок в шаблонах; впрочем, я не планирую делать сложные правки в защищённых шаблонах без консультации с другими техническими участниками. MBH 20:46, 27 июня 2020 (UTC)[ответить]
  • «Шо, опять?» А почему нет ботоссылки на прошлую номинацию?VladXe (обс.) 16:37, 27 июня 2020 (UTC)[ответить]
  • Флаг АИ вам не нужен потому что не планируете редактировать JS/CSS, или же вы тоже ждёте «снятия флага с участников, не являющихся техниками и получивших флаг за наличие у них других флагов, чтобы вернуть себе флаг и продолжить полезную техническую работу в проекте» (diff), или по какой-то другой причине? — Good Will Hunting (обс.) 09:04, 28 июня 2020 (UTC)[ответить]
    • Я думаю участник недостаточно подкован в CSS/JS, чтобы претендовать на флаг АИ. ·Carn 09:20, 28 июня 2020 (UTC)[ответить]
      • Ну, найти и исправить ошибку в скрипте я в определённых пределах смогу (пример, вопреки описанию правки, ошибка найдена и указано, как её исправить - мной), синтаксис js понимаю, т.к. он си-подобный. Писание js-скриптов - не моё, никогда этим не занимался. CSS знаю слабее, но и там основы понимаю и изменить стиль шрифта или повесить раскрашенный див с бордерами - смогу. Когда на СО инженероиска Гребеньков привёл какой-то жс-цсс тест, я набрал в нём, кажется, 23/25 баллов по жс и что-то вроде 18/25 по цсс. MBH 10:44, 28 июня 2020 (UTC)[ответить]
    • Нет: я, в отличие от всех протестантов, сдавших флаги, никогда не понимал этого их решения, считал его глупым и бессмысленным; сам бы флаг, будь он у меня, не сдавал бы. Но раз уж так есть, этот фактор нужно учитывать, как по мне. MBH 10:29, 28 июня 2020 (UTC)[ответить]
      • Если, будь у вас флаг, вы бы его не сдавали, почему тогда сейчас вы его не запрашиваете? А если считаете, что он вам не нужен, почему не сдали бы в такой ситуации? (Второй вопрос меня интересует меньше, я просто вижу определённую непоследовательность) — Good Will Hunting (обс.) 10:49, 28 июня 2020 (UTC)[ответить]
        • Люди сдавали флаг инженера, а не нужен мне - флаг ИА, вы как-то объединяете их во втором вопросе. Не запрашиваю ИА потому, что он действительно может быть нужен мне крайне редко (полагаю, что вряд ли более раза в полгода - мне несложно попросить произвести правку толпу людей в чатике, имеющих право на это), так безопаснее (если злоумышленник получит доступ к моему акку, он сможет меньше навредить), ну и потому, что с запросом на тот флаг пройти заявку было бы существенно сложнее, по моим оценкам. Я ещё в первой заявке, когда указывал предполагаемые области деятельности, скриптов и стилей в них не было (или почти не было). MBH 10:59, 28 июня 2020 (UTC)[ответить]
  • Есть ли у вас опыт программирования на Lua? Планируете ли взять ограничение на правки в пространстве Модуль? Don Rumata 22:30, 28 июня 2020 (UTC)[ответить]
    • Опыта практически нет, но опять же - синтаксис понимаю, несложное исправление внести смогу. Создавать модули пока не планирую, править - тоже, за исключением мелких исправлений (без консультаций с более компетентными участниками), брать ограничения на них - тоже не планирую. MBH 00:20, 29 июня 2020 (UTC)[ответить]
    • У нас пространство Модуль открыто для участников совсем без флагов, я вот хотя прочитал целую книгу по lua (советую всем новичам в этом языке) — всё равно воздерживаюсь от внесения изменений в защищённые модули, которых не понимаю.
      В прошлый раз для standalone-отладки вы посоветовали Visual Studio Code (кроме популярного trixnz.vscode-lua в нём предлагаются разные дебаггеры и расширения для lua, я пытался уточнить у вас в Дискорде, чем вы пользуетесь, но не получил ответа, поэтому остановился не на комбаине, который надо ещё допиливать до своих целей, а на более легковесной и заточенной под lua ZeroBrane Studio). Также вы сказали что ustring не зависит от PHP (хотя в него входит make-normalization-table.php и make-tables.php для связи с includes/libs/normal/UtfNormalData.inc из ядра MediaWiki — у меня получилось запустить ustring из lualib локально так, что он успешно подгрузил все необходимые подмодули, но вот заставить его выполнить полезную работу а не бездействовать у меня не вышло). Также вы посоветовали mw:MediaWiki-Docker — видимо необходимо как-то установить себе локально движок MediaWiki и допилить как-то его, я если честно не понял.
      В связи с этим (прошу прощения за не самое подходящее место для вопроса, но) не могли бы вы, как опытный участник, посоветовать мне как новичку (а возможно и номинант и другие читающие данную заявку воспользуются вашим советом) какой-то более пошаговый метод для локальной отладки модулей.
      (Don Rumata связался со мной и помог запустить модуль локально, я попробую по этому процессу написать какое-никакое руководство)·Carn 09:12, 29 июня 2020 (UTC)[ответить]
  • Как Вы оцениваете правку правка? Это, вроде, техническая правка. Optimizm (обс.) 14:48, 30 июня 2020 (UTC)[ответить]
    • Унификация посредством перевода на меташаблон - полезна. Иконка неуместная, в ней статья отправляется в корзину, а смысл шаблона - снято с удаления (то есть не удалено). Первая и вторая строчки текста шаблона стали лучше, третья плоха что там, что там (нужно указать, что новая номинация возможна лишь с аргументами, не рассмотренными/не опровергнутыми в прошлых номинациях). MBH 17:57, 30 июня 2020 (UTC)[ответить]
  • Что бы всем окончательно убедится в профессиональных знаниях, предлагаю вам написать regexp вот для этой задачи. Don Rumata 11:24, 2 июля 2020 (UTC)[ответить]
    • Жесть какая… Я давно ботовожу на AWB и достаточно свободно пользуюсь регулярками, но пройти это не могу. Почему вы считаете, что эта эзотерика с регулярками нужна для получения инженерофлага? Викизавр (обс.) 12:28, 2 июля 2020 (UTC)[ответить]
    • Написал. 8/11, при этом два теста не пройдены из-за неизвестных мне особенностей JS-движка регексов - я не знаю, почему он применяет выражение всего один раз; АВБ, которым я пользуюсь на практике, заменяет каждое вхождение, а не только первое. Итого: 10/11 на используемом мною движке регексов, как решить четвёртое с конца - я действительно пока не знаю и тратить время на выяснение сейчас не хочу. Потратил на задачу ~7 минут. MBH 12:33, 2 июля 2020 (UTC)[ответить]

Обсуждение (MBH)[править код]

  • (+) За польза очевидна, как и от всех ботовладельцев. — Erokhin (обс.) 12:27, 27 июня 2020 (UTC)[ответить]
  • (+) За участник безусловно доказал свою техническую грамотность, а если кто-то укажет на его оплошности, то они случаются у всех. А обладание потенциально опасным флагом ПИ у бота внушает дополнительное доверие. — С уважением, Helgo13(Обс.) 12:35, 27 июня 2020 (UTC)[ответить]
  • (+) За есть конкретная задача, которую участник может решить, ему для этого нужен флаг. И судя по тому чем обычно занимается участник — и после этого он найдёт как принести пользу с данным флагом.·Carn 16:09, 27 июня 2020 (UTC)[ответить]
  • (=) Воздерживаюсь: технически опытный участник, всегда готовый прийти на помощь, но есть одно «но» — в прошлой попытке получить этот флаг причиной отказа стало его социальное поведение. С того раза фраза «есть два мнения: моё и неправильное» перестала быть Вашим кредо? — VladXe (обс.) 16:43, 27 июня 2020 (UTC)[ответить]
    • Она им никогда не была. MBH 18:30, 27 июня 2020 (UTC)[ответить]
      • (+) За. Перефразируя известную поговорку: «скажи мне, кто твой враг, и я скажу, кто ты». Нужен противовес группе «инженеров-дизайнеров». А не ошибается тот, кто ничего не делает, а в этом случае я вижу, что а) редактор стал легче признавать ошибки и б) оперативно их исправлять. — VladXe (обс.) 17:55, 1 июля 2020 (UTC)[ответить]
  • (+) За по ответам на вопросы. Явного вреда не будет, польза будет — пусть попробует. Только надеюсь, что участник будет чуть внимательнее к тому, что именно он делает, а не как здесь. adamant.pwncontrib/talk 22:54, 27 июня 2020 (UTC)[ответить]
  • С одной стороны, есть темы, в которых Макса заносит. И существуют некоторые проблемы с коммуникацией и соблюдением правила ВП:ЭП. С другой, флаг инженера всё же технический, и не нужно его излишне социализировать. Хотя, как отмечалась в прошлой заявке (да и сам тоже замечал) иногда участник небрежен. И одним из существенных аргументов против в прошлой заявке был тот факт, что «коллега крайне нетерпим к любым мнениям, кроме своих, и зачастую не способен вовремя остановиться». Но всё же польза от него как от техника, имхо, превышает возможные проблемы. Поэтому осторожное (+) За. И пожелание, чтобы в случае получения флага Макс прислушивался к мнению другой стороны, даже если оно не совпадает с его личным мнением, это поможет избежать многих проблем. Vladimir Solovjev обс 07:37, 28 июня 2020 (UTC)[ответить]
  • Если бы флага инженера не существовало, его стоило бы придумать специально для кандидата. Был бы за и в отношении флага АИ. — Good Will Hunting (обс.) 09:08, 28 июня 2020 (UTC)[ответить]
  • (+) За. Приходилось обращаться к участнику по техническим вопросам - опыт взаимодействия положительный (задача была решена качественно и оперативно). — Uchastnik1 (обс.) 09:25, 28 июня 2020 (UTC)[ответить]
  • Я сам неоднократно и много спорю с Максом, но абсолютно не понимаю откуда взялись (и считаю крайне вредными) требования по социализации для инженеров. Давайте просто каждый будет делать свое дело на своем месте? Безусловно (+) За Ghuron (обс.) 10:44, 28 июня 2020 (UTC)[ответить]
    • Работа у инженеров вообще-то не особо благодарная: если они всё делают хорошо, то часто никто этого не замечает, а если наступят кому-то на мозоль, то возникает недовольство. Было несколько конфликтов из-за того, что решения техников по изменению инструментов часто представляют чёрный ящик. Например, когда авторы внезапно узнавали, что на основании своего локального консенсуса техники вносили в инструмент, который они постоянно используют, такие изменения, из-за чего тот вдруг начинал работать иначе. И проблемы именно из-за того, что инженеры не всегда учитывают, как участники воспримут вносимые ими изменения. И хотя флаг технический, но определенная социальная составляющая в нём всё же присутствует. Vladimir Solovjev обс 11:01, 28 июня 2020 (UTC)[ответить]
      • > Было несколько конфликтов из-за того, что решения техников по изменению инструментов часто представляют чёрный ящик. Например, когда авторы внезапно узнавали, что на основании своего локального консенсуса техники вносили в инструмент, который они постоянно используют, такие изменения, из-за чего тот вдруг начинал работать иначе.
        А напомните, пожалуйста, про какие инструменты речь то идет? С уважением, Iniquity 11:39, 28 июня 2020 (UTC)[ответить]
        • Вам конфликта вокруг Ш:{{Произведение искусства}} мало? Требуете противников инженеров & дизайнеров достать записные книжки с грехами многолетней давности? Не надоело на одни и те же грабли наступать? «Давайте жить дружно», пожалуйста. — VladXe (обс.) 15:50, 28 июня 2020 (UTC)[ответить]
          • Не совсем чётко указал: в основном там вокруг шаблонов конфликты были. Кроме указанного были ещё конфликты вокруг шаблонов {{Примечания}} и{{Cite web}}. Это то, что я помню. Vladimir Solovjev обс 06:51, 29 июня 2020 (UTC)[ответить]
            • В {{примечания}} добавляли адаптивность и обсуждения были довольно конфликтные, с классическими НЕПОЛОМАНО и «дайте мне возможность настраивать, чтобы идеально выглядело на моём экране в 1689 пикселей, а на остальное плевать» как до, так и после внесения, но внесение было произведено именно после обсуждения на форуме.
              По {{cite web}} был огромный срач из-за того, что Мастер теней внёс туда одиозные правки и не хотел отменять, хотя ему не только показали, что нет консенсуса на них, но и предъявили консенсус на обратное. Вот только Мастер теней — ни разу не инженер, а администратор (потому и смог себе позволить так игнорировать остальных участников, а инженеру быстро бы натыкали носом в правила). Викизавр (обс.) 07:38, 29 июня 2020 (UTC)[ответить]
          • {{Произведение искусства}} не защищён до админов / инженеров, чтобы его можно было рассматривать в этом контексте. Сергио (обс.) 13:17, 29 июня 2020 (UTC)[ответить]
      • Я не хочу сейчас розжигать очередной техносрач, давайте сконцентрируемся на данной заявке. Хочу обратить ваше внимание на 2 факта:
  1. В нынешний флаг инженера не входит редактирование гаджетов (вокруг работы которых и ломались копья) и т. п. — только модули/шаблоны/editnotice и т.п.
  2. В вопросах раскраски/унификации позиция Макса довольно часто не совпадала с позицией инженеров
Ghuron (обс.) 12:29, 28 июня 2020 (UTC)[ответить]
  • (+) За Деятельность участника по улучшению википедии поддерживаю двумя руками. — Denbkh (обс.) 20:09, 28 июня 2020 (UTC)[ответить]
  • Я осторожно выскажусь (+) За, но с пожеланием выносить содержательные правки, касающиеся многих статей, на обсуждение, где их сможет увидеть максимальное число заинтересованных. Всё же спешка у кандидата часто бывает не к месту (хотя, с другой стороны, его склонность всё же добиваться принятия решений мне импонирует). (И да, у флага инженера есть социальная сторона, всегда была и будет). AndyVolykhov 20:17, 28 июня 2020 (UTC)[ответить]
  • Нисколько не сомневаясь в технической грамотности кандидата, тем не менее голосую (−) Против по причине непонимания кандидатом механизма поиска консенсуса, показанного кандидатом в случае использования своего бота для удаления из статей русской Википедии ссылок на сайты, находящиеся в спам-листе русской Википедии. С этим эпизодом можно ознакомиться по ссылкам: Википедия:Запросы к администраторам/Архив/2020/04#MBHbot, Википедия:Заявки на снятие флагов/Архив/Откатывающие/2020#Раммон: флаг откатывающего и Википедия:Изменение спам-листа/Архив/2020/04#infox.ru. Раммон (обс.) 07:29, 29 июня 2020 (UTC)[ответить]
    • Раз сайт вынесли из спам-листа, правки бота можно и отменить, займусь этим. MBH 12:12, 29 июня 2020 (UTC)[ответить]
    • Я запустил отмену правок по удалению инфокса, минут за 10 всё отменится. MBH 15:00, 29 июня 2020 (UTC)[ответить]
      • Проблему я вижу в том, что Вам не была очевидной ошибочность внесения этого сайта в спам-лист даже тогда, когда Вам об этом сказали все участники обсуждения, и Вы упорствовали в отстаивании своего мнения до формального подведения итога. Именно такое отношение к консенсусу я и считаю проблемой, которая будет проявляться в том числе и при использовании флага инженера если Вам его присвоят. Раммон (обс.) 06:00, 30 июня 2020 (UTC)[ответить]
        • Пока сайт не был изъят из спам-листа, на возврат ссылок на него не было никаких оснований, т.к. 1) сохранялась та техническая проблема, из-за которой эти ссылки и были удалены/поломаны ботом, 2) сайт всё ещё был причислен администраторами проекта к неавторитетным и ненужным нам, не было администраторского итога об отмене предыдущего администраторского решения, которым сайт был внесён в СЛ. Ошибочность мне совершенно очевидна не была потому, что (явно) ошибочным данное действие не было, и это было признано в обсуждениях и итоге по его выносу из СЛ (вынесен он был со словами "ладно, так уж и быть, раз просят ссылки на этот мусорненький источник - вынесем, блокировать массовый спам будем иными способами") MBH 10:05, 30 июня 2020 (UTC)[ответить]
  • Осторожное (+) За по аргументам Vladimir Solovjev. Викизавр (обс.) 07:32, 29 июня 2020 (UTC)[ответить]
  • (−) Против по аргументации Раммона. -- La loi et la justice (обс.) 10:58, 29 июня 2020 (UTC)[ответить]
  • (+) За per Vladimir Solovjev. От себя также пожелаю соблюдать ВП:ЭП (особенно по части подведения итогов), но это уже по общевикипедийной части. :-) Deltahead (обс.) 12:09, 29 июня 2020 (UTC)[ответить]
  • За хорошего технического специалиста. Optimizm (обс.) 14:36, 30 июня 2020 (UTC)[ответить]
  • Умеет в коммуникацию, имеет достаточные технические навыки, которые находят ежедневное применение на благо проекта. — Ailbeve (обс.) 14:40, 30 июня 2020 (UTC)[ответить]
  • В заявке приведены три правки, только одна из которых является технической. Формальное обоснование необходимости флага также не выдерживает критики в том плане, что совсем не очевидно, что для задачи «убрать/добавить эдитнотис при правке фильтра пару раз в месяц» нужен именно бот и именно от этого участника (изначальная простановка эдитнотисов может быть выполнена любым администратором или инженером, последующие — ручные по сути действия). Проблем же у него как поведенческих, так и банальных с договороспособностью и корректностью его правок, на мой взгляд, слишком много. (−) Против, если флаг планируется применять вне конкретной техзадачи с эдитнотисами, иначе (=) Воздерживаюсь. stjn 20:36, 30 июня 2020 (UTC)[ответить]
  • (−) Против. Кандидат не готов к правкам LUA модулей, но нет никаких гарантий, что он не захочет их менять. Мне страшно доверять ему массовые правки ботом защищенных шаблонов и модулей. Владея двумя ботами можно даже нечаянно крупно напортачить. Я вижу у кандидата склонность предпринимать поспешные действия без их предварительного обсуждения. Don Rumata 00:12, 1 июля 2020 (UTC)[ответить]
    • Я, очевидно, в принципе не собираюсь (и постараюсь обеспечить, чтобы этого не происходило) править какие-либо защищённые страницы с кодом - ботами. Я могу править ботом защищённые страницы в следующих случаях, когда это реально нередко нужно: 1) обычные минорные технические правки (рекатегоризация, смена синтаксиса карточки) в статьях, защищённых из-за какой-то политической войны правок, 2) те же действия на полностью защищённых ЛС/архивах обсуждения. Мне все те 9+ лет, что я ботовод, приходится по каждому такому случаю, которые нередки, собирать список необработанных ботом страниц, идти в личку к админам и объяснять им, что нужно сделать. Вот пример одного из таких запросов, и они нередки (эти же правки - ответ на аргументацию в предыдущем голосе о том, что приведено недостаточно примеров технических правок на защищённых страницах). MBH 01:22, 1 июля 2020 (UTC)[ответить]
      • Так и возьмите самоограничение. А то сегодня не собираетесь, а завтра передумаете. Don Rumata 23:14, 1 июля 2020 (UTC)[ответить]
        • На что брать самоограничение, на правку модулей ботом? А смысл? Я вполне могу себе представить, что когда-нибудь переименуют какой-то луа-модуль, как это периодически происходит с js-объектами, и понадобится ботозаменить все его упоминания в коде (в js-файлах сейчас это делают разработчики глобально по всем разделам). То есть я вполне могу выполнять даже это, если такая задача возникнет и меня об этом попросят разбирающиеся в предмете участники. MBH 23:24, 1 июля 2020 (UTC)[ответить]
  • (+) За, несмотря на то, что мы с Максом постоянно оказываемся на разных сторонах всяческих споров, и он считает что мы в конфликте (хотя я устал обьяснять что это не так). Я вообще считаю большой несправедливостью, что флаг инженера, изначально подготовленный и "пробитый" Максом, получили все, кроме него самого. Я по прежнему считаю, что флаги с большой социальной составляющей (типа админа или ПИ) не для Макса (прости Макс, но это правда), но флаг инженера ИМХО подходит ему, как идеально сшитый фрак. Как пожелание - больше прислушиваться к оппонентам в споре и не торопится реализовывать те технические новшества, консенсус на которые в сообществе не сложился. TenBaseT (обс.) 07:05, 1 июля 2020 (UTC)[ответить]
  • (+) За. Андрей Романенко (обс.) 22:19, 1 июля 2020 (UTC)[ответить]
  • (+) За, с пожеланием меньшей поспешности в принятии решений, чем было в некоторых приведенных в обсуждении случаях. Swarrel (обс.) 14:20, 2 июля 2020 (UTC)[ответить]
  • (+) За. Нет оснований полагать, что участник не справится с обязанностями инженера. Jim_Hokins (обс.) 16:30, 2 июля 2020 (UTC)[ответить]
  • (+) За per Vladimir Solovjev. — С уважением, Kazrok4545 Обсуждение 00:09, 3 июля 2020 (UTC)[ответить]
  • Пожалуй, осторожное (+) За. При прошлой номинации был против, однако мы все меняемся, развиваемся и двигаемся. С социальными навыками и коммуникацией сейчас серьёзных проблем у коллеги нет. — Dmartyn80 (обс.) 23:37, 4 июля 2020 (UTC)[ответить]
  • (+) За, согласен с аргументацией Владимира. — Sashatrk (обс.) 05:53, 5 июля 2020 (UTC)[ответить]

Итог[править код]

Прошло уже больше недели, последнее мнение появилось 2 дня назад, пора подводить итог. Из аргументов против, прозвучавших тут:

  • Непонимание механизма поиска консенсуса со ссылкой на инцидент с infox.ru. В данном конкретном случае я не вижу никаких нарушений, само решение по существу, о внесении сайта в СЛ, принималось администратором, MBH не может такие решения отменять и именно что должен был дождаться формальной отмены от другого администратора;
  • Неготовность править модули. Многие флаги в ВП сочетают в себе несколько функций, если успешно выполняется одна из них, а в отношении других кандидат говорит, что не разбирается и не будет их выполнять, то было бы странно не выдавать ему флаг из-за этого. Аналогично, например, неготовность быть посредником при готовности работать на КУ является плохим аргументом против выдачи флага администратора;
  • Огрехи при ботоводстве и недоговороспособность. Я изучил СО MBH за последние полгода и не увидел ярких примеров подобного, в обсуждении они не были приведены;

Из аргументов за — техническая грамотность, не оспариваемая даже противниками выдачи флага, и качественное улучшение работы бота при наличии у него флага.

Бюрократы считают, что в случае, когда польза от наличия флага не оспаривается, а вред будет лишь в гипотетической ситуации, сконструированной с применением изрядной доли ПЗН, технический флаг должен быть присвоен. Track13 о_0 11:34, 7 июля 2020 (UTC)[ответить]

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Прошу подтвердить флаг администратора интерфейса, как того требует АК:1076. Флаг обычно использую для правок по запросам на ВП:ТЗ или ВП:Ф-Т (список). Двухфакторная авторизация включена. Также являюсь администратором интерфейса в Викисловаре. Don Rumata 18:11, 2 июля 2020 (UTC)[ответить]

Вопросы (DonRumata)[править код]

  • По какой схеме именуются гаджеты?
    Большая часть гаджетов имеют исторические названия, но если вы спрашиваете о том коде, который подгружается в MediaWiki:Common.js, то вы его переименовали в 2017‎ году, по принципу ext.gadget.common-special-*, ext.gadget.common-action-* и ext.gadget.common-namespace-*. Don Rumata 20:19, 3 июля 2020 (UTC)[ответить]
  • Каким образом у нас вызываются специализированные скрипты (вроде спецскрипта для страницы блокировок) из MediaWiki:Common.js и ваши мнение, почему это сделано именно так?
    Специализированные скрипты подгружаются через mw.loader т.к. он учитывает зависимости, указанные в MediaWiki:Gadgets-definition. Don Rumata 20:19, 3 июля 2020 (UTC)[ответить]
  • Какие стайлгайды используются для JS и CSS? Какое предпочтительное именование переменных в JS и классов/id в CSS?
    Основной код нашего раздела написан без стайлгайдов. Я использую Visual Studio Code с подключенным VS Code ESLint extension и правилами из eslint-config-wikimedia. Don Rumata 20:19, 3 июля 2020 (UTC)[ответить]
Другие вопросы:
С уважением, Iniquity 15:27, 3 июля 2020 (UTC)[ответить]

Обсуждение (DonRumata)[править код]

  • (+) За, большой специалист, с социальной частью проблем тоже не замечено.— Luterr (обс.) 16:08, 3 июля 2020 (UTC)[ответить]
    • Я бы этого не сказал, что с социальной частью проблем не замечено, я как раз их очень хорошо заметил в своё время. Но к флагу АИ отношения прямого эти проблемы не имеют. Технически участник достаточно подкован, так что по наличию у него флага у меня лично вопросов никаких нет. Vladimir Solovjev обс 16:36, 3 июля 2020 (UTC)[ответить]
      • Видимо данные проблемы прошли мимо меня. Но сейчас хороший момент обратить внимание коллеги DonRumata на это обстоятельство, что не стоит забывать где мы находимся, ради чего мы здесь, и что нужно стараться быть терпимее, толерантнее к коллегам. Luterr (обс.) 16:56, 3 июля 2020 (UTC)[ответить]
  • Конечно. — Good Will Hunting (обс.) 20:05, 3 июля 2020 (UTC)[ответить]
  • Ответы на вопросы Iniquity демонстрируют общую компетенцию и обучаемость, за. — Джек (обс.) 21:31, 3 июля 2020 (UTC)[ответить]
  • Очевидная заявка. MBH 23:40, 3 июля 2020 (UTC)[ответить]
  • (+) За — техническая компетентность показана.·Carn 09:51, 4 июля 2020 (UTC)[ответить]
  • (+) За, спасибо за ответы. Понимание важных механик работы с MediaWiki в части где именно нужен данный флаг показано, а в технической компетенции вроде сильных нареканий не было. Просто уточню пару моментов:
  1. Я больше имел ввиду обычные гаджеты, которые мы с 2017 года именуем camelCase с маленькой буквы. Старые гаджеты переименовать нельзя, так как вы правильно и сказали, слетят настройки.
  2. Да, ResourceLoader, позволяет указывать зависимости, но не только. Он удобен из-за автоматической минификации + общего вызова JS и CSS.
  3. На самом деле большая часть кода опирается на mw:Manual:Coding conventions + стайлгайды от гугла, если в нативных что-то не описано.
С уважением, Iniquity 12:04, 4 июля 2020 (UTC)[ответить]

Итог[править код]

Налицо всенародная поддержка, аргументов против практически нет. Консенсус за сохранение флага очевиден, так и тому и быть. Удачной работы! — Adavyd (обс.) 21:56, 9 июля 2020 (UTC)[ответить]

В ближайшем будущем у меня появится свободное время, часть которого хотелось бы потратить на доработки по модулям и скриптам. Собственно, поэтому хотелось бы получить оба флага. Что я делал раньше, можно посмотреть по вкладу в соответствующих пространствах. На вопросы готов ответить. — putnik 17:44, 10 сентября 2020 (UTC)[ответить]

Вопросы (Putnik)[править код]

  • Я пользуюсь на телефоне десктопной версией Википедии, и в разных местах ссылки нормального размера после нажатия на них уменьшаются, а перехода по ссылке не происходит. С чем это может быть связано и как это можно починить?·Carn 17:55, 10 сентября 2020 (UTC)[ответить]
    • Как минимум, тут недостаточно данных для воспроизведения проблемы. В современных браузерах на телефонах всё работает хорошо. Так что стоит смотреть либо в сторону браузера (и попробовать в другом), либо посмотреть, какие включены персональные скрипты. — putnik 18:28, 10 сентября 2020 (UTC)[ответить]
  • В текущей конфигурации движка в пространствах Шаблон: и Модуль: есть ли какие-либо сообщения/иные метки на (полу)защищённых страницах, по которым любой участник может понять, кто может править такую страницу: ВП:ИНЖ или только ВП:АИН? — Neolexx (обс.) 08:14, 11 сентября 2020 (UTC)[ответить]
    (дополнение) Или расширенные полномочия ВП:АИН касаются только пространства MediaWiki: - а в Шаблон: и Модуль: ВП:ИНЖ могут править что угодно?
    Вопрос без подвоха, я действительно не могу понять из текущих текстов возникшей конфигурации прав и посчитал, что ясное понимание этой конфигурации прав кандидатом на флаги должно быть продемонстрировано. — Neolexx (обс.) 09:20, 11 сентября 2020 (UTC)[ответить]
    • Единственное, что могут править АИ и не могут ИНЖ/админы - это страницы с окончанием .js и .css, расположенные 1) в медиавики, 2) на подстраницах других участников. MBH 11:26, 11 сентября 2020 (UTC)[ответить]
      • Спасибо за ответ, но вообще-то значок Е после ника у вас уже, спрашивал того, кто на него претендует ;-) — Neolexx (обс.) 11:47, 11 сентября 2020 (UTC)[ответить]
        @MBH: такая простая схема в 1) и 2), как вы написали чуть выше, мне самому приходила в голову из доступных текстов. Однако увидел (возможно, ошибочно) контрпример. Кандидату флаг администратора (старого, обычного) нужен был именно и прежде всего "для редактирования скриптов". И пока он от этого флага не отказался, он действительно активно их редактировал. "Их" - имею в виду ваше определение "страницы с окончанием .js и .css, расположенные 1) в медиавики". То есть либо схема прав доступа к страницам летом 2018 была иная, либо картина сложнее, чем ваши 1) и 2).
        Хотелось бы и самому всё это понять - и видеть, что кандидат понимает, в каких случаях он будет действовать как инженер, а в каких - как администратор интерфейса. — Neolexx (обс.) 12:49, 11 сентября 2020 (UTC)[ответить]
        • Флаг администратора интерфейса сейчас работает как расширение прав либо администратора, либо инженера, и сама бы заявка на него без заявки на флаг инженера (или администратора) противоречила бы правилам. Соответственно, и вся деятельность регулируется ВП:ИНЖ, поэтому во всех случаях действия будут регулироваться именно этим правилом. Ну а флаг администратора интерфейса просто расширяет область этой деятельности. — putnik 13:10, 11 сентября 2020 (UTC)[ответить]
        • Нет, реализуется третье "либо": вы неправильно понимаете ту реплику участника. Флаг админа для скриптов ему был нужен тогда, когда ещё не был выделен ИА; после выделения ИА для скриптов нужен админ или инж, плюс ИА. MBH 13:51, 11 сентября 2020 (UTC)[ответить]
    • Я занимался и планирую заниматься как шаблонами/модулями, так и скриптами/гаджетами, именно поэтому такая конфигурация. Когда я этим занимался раньше, то имел флаг админа, который это всё покрывал, но на данный момент этих двух флагов мне вполне достаточно, поэтому не вижу смысла подаваться на флаг администратора. — putnik 13:00, 11 сентября 2020 (UTC)[ответить]
  • Хотелось бы уточнить вопрос, который уже поднимал. При реализации решения об удалении свойства на Викиданных по итогу этого обсуждения у Вас есть практическое решение для воспроизведения ссылок на категорию Викисклада в карточках статей, в элементах которых есть основные категории и, ссылки на категории, соответственно находятся в элементах категорий, а не статей, галерея на Викискладе при этом также отсутствует (то есть в элементах статей нет прямых ссылок на Викисклад, а ее воспроизведение необходимо в карточке через Викиданные)? P.S. Отдельная личная просьба, конечно, необязательная для выполнения. На мой взгляд, наиболее технически грамотные участники русской Википедии, работающие с Викиданными, в обсуждении об удалении свойства не высказались. Мне бы не хотелось тормозить решение проблем Викиданных и задерживать развитие этого проекта, но и в пожарном порядке постфактум искать какие-то решения в русской Википедии тоже не считаю правильным, поэтому было бы правильно, если бы от русской Википедии оставил комментарий более технически подкованный участник, чем я, например. Если Вы не видите проблем для проекта - пожалуйста, напишите об этом в обсуждении удаления свойства, если риски есть - тоже оставьте об этом комментарий. — Ksc~ruwiki (обс.) 18:53, 11 сентября 2020 (UTC)[ответить]
    • Я не считаю, что то обсуждение уже завершилось, и что в обозримом будущем свойство будет удалено. В случае, если всё же будет, мы можем реализовать получение ссылки на Викисклад как раз тем способом, который предлагается в обсуждении:
      1) смотреть, привязана ли к элементу ссылка на категорию Викисклада,
      2) если нет, то брать элемент из свойства основная категория по теме (P910) и смотреть, если ли ссылка на категорию там.
      Да, это требует больше кода (и загрузки большего числа элементов) на нашей стороне, и в целом выглядит как перенос костыля из Викиданных на нашу сторону, но каких-либо проблем в реализации не составляет. Готового кода на данный момент нет, но он пишется (и тестируется) за один вечер. Со своей стороны я бы предпочёл, чтобы эта сложность была скрыта внутри модуля Wikibase для Scribunto, но не уверен, что команда Викиданных на это пойдёт. — putnik 21:30, 11 сентября 2020 (UTC)[ответить]
      • Мы различаемся в оценках перспектив обсуждения, но это вторично. Есть еще один вопрос. Категории в разных языковых разделах и на самом Викискладе формируются по разным принципам. В ряде случаев, не так уж и редких, возникают ситуации, когда категории в разных языковых разделах отличаются по смыслу и их элементы не могут быть объединены, а категория на Викискладе только одна. Самый простой пример, категории для колледжей и университетов на Викисладе общие, а в языковых разделах они разные. Предположим, что ссылка пойдет на университеты (или в языковые разделы, где они университеты и колледжи также общие), а тот, что для колледжей останется без ссылки. Каким образом в такой ситуации будет обеспечиваться ссылка на Викисклад в нашей категории (например, в панели слева или шаблоне навигация, проставленном на категорию), если она останется без ссылки? Пример условен, но я сам именно через это свойство обеспечивал ссылку на Викисклад в категориях, где "Архитектура чего-то" и "Здания и сооружения..." в разных разделах были различны и не подлежали объединению. — Ksc~ruwiki (обс.) 19:48, 13 сентября 2020 (UTC)[ответить]
        • Мы не так сильно различаемся в оценках: имхо реалистичный сценарий таков, что обсуждение будет идти ещё какое-то время, потом свойство пометят как «(DEPRECATED)» и через год-два удалят. Запас по времени вполне достаточный, и нет необходимости реагировать прямо сейчас. Если говорить про конкретный пример, то в таком случае для категории можно создать отдельный элемент, к которому будет привязана категория на Викискладе, и прописать его как основную категорию для обоих элементов. Мне кажется, что проблему эту решает, и ничему не противоречит. — putnik 22:39, 13 сентября 2020 (UTC)[ответить]
          • Честно говоря, я не понял ответа. «Основная категория» это же свойство именно для элементов категорий, противоположный свойству «основная статья» элементов статей. Здесь речь идет только об элементах категорий. Например, на Викискладе есть категория Universities and colleges by country её линк, как Вы говорите, находится, в элементе Category:Universities and colleges by country and city (в русской Википедии такой категории нет), а вот имеющиеся элементы Категория:Университеты по странам и Категория:Колледжи по странам (с нашими категориями) связаны с Викискладом именно через свойство «категория на Викискладе». Меня интересует: каким образом эти две наши категории (их элементы на Викиданных) будут связаны с Викисладом после удаления свойства? Тут же никак не подойдет «Основная категория». — Ksc~ruwiki (обс.) 19:26, 14 сентября 2020 (UTC)[ответить]
            • Не совсем корректно вас изначально понял: подумал, что речь идёт про две статьи и категорию. Конкретно в такой ситуации теоретически тоже возможно прописать основная категория по теме (P910) для категории (хотя такой вариант может не пройти одобрение сообщества), либо создать свойство наподобие «основная категория с изображениями», которое будет аналогом для добавления в элементы категорий. — putnik 02:09, 15 сентября 2020 (UTC)[ответить]
              • Благодарю за ответ. Против первого варианта я бы и сам возражал, а второй вполне возможен, хотя и немного странно удалить одно свойство, чтобы создать другое. В любом случае наличие хоть одной идеи - уже хорошо. Просто у меня вариантов решения вопроса пока не было. — Ksc~ruwiki (обс.) 20:05, 15 сентября 2020 (UTC)[ответить]
  • Будете ли Вы ещё устраивать демарши со снятием флагов, подобные недавнему, когда Вам или группе Ваших единомышленников не понравится действие того или иного администратора? А то такие регулярные голосования по любому поводу даже у убеждённого сторонника конфирмаций вроде меня вызывают ассоциации с игрой на публику и бессмысленным отвлечением ресурсов сообщества. nebydlogop 14:50, 14 сентября 2020 (UTC)[ответить]
    • Наверно, вам лучше не называть себя сторонником конфирмаций, если вы считаете подачу на флаг раз в 7,5 лет «регулярными голосованиями» и «бессмысленным отвлечением ресурсов сообщества». Больше мне нечего вам ответить. — putnik 17:22, 14 сентября 2020 (UTC)[ответить]
  • В модуле foobar определена функция p.function(frame), рассчитанная на единственный строковый аргумент, хранящийся в frame.args[1]. Опишите корректный способ вызова этой функции с аргументом 'foo bar' из другого модуля barfoo. adamant.pwncontrib/talk 23:26, 14 сентября 2020 (UTC)[ответить]
    • Я даже не знаю, что вы ожидаете в ответе. Вот так?
      local foobar = require( 'Module:Foobar' )
      local subframe = mw.clone( frame )
      subframe.args = {'foo bar'}
      return foobar.function( subframe )
      
      Или вот так?
      return frame:callParserFunction{ name = '#invoke', args = { 'foobar', 'function', 'foo bar' } }
      
      Вообще, на мой взгляд, в таком случае в модуле лучше делать отдельный метод, который можно вызвать без фрейма. И обёртку для него с фреймом. — putnik 02:03, 15 сентября 2020 (UTC)[ответить]
  • Как вы оцениваете средне- и долгосрочные риски для проекта связанные с поддержкой модулей на Lua? У нас есть модули в стони строк не вполне тривиального кода без какой-либо документации, с отсутствующими или не проходящими юнит-тестами и т.п. Что произойдет, когда и если их разработчики утратят к ним интерес или вообще покинут проект? Существуют ли такие риски? Если да - следует ли предпринимать какие-то меры по их нивелированию? Заранее спасибо за ответы. — Lev (обс.) 13:39, 18 сентября 2020 (UTC)[ответить]
    • В качестве одного из разработчиков, который поддерживал в частности и модули наград в те периоды времени, когда Сергей был не особо активен в ру-вики, хотел бы заметить что конечно лучше быть здоровым и богатым иметь документацию и тесты нежели их не иметь. Но я бы не стал переоценивать значение документации (и тем более юнит-тестов) для увеличения maintainability модулей. Гораздо важнее качество кода и продуманность дизайна с которыми у Сергея (да и в целом по часто наиболее популярным модулям в нашем разделе) все более-менее прилично. По сравнению собственно с «порогом входа в технологию», необходимым для правки абсолютно любого модуля (понимания как они встроены в движок и как их можно отлаживать) сложности с фтыканием в перечисленные Вами модули IMHO пренебрежимо малы. Ghuron (обс.) 11:57, 19 сентября 2020 (UTC)[ответить]
  • Когда это уже наконец-то починится? FF 80, Ubuntu 20.04. — Incredible Terence (обс.) 02:45, 21 сентября 2020 (UTC)[ответить]
    • Интересно, а почему «когда уже», этот вопрос уже не первый раз поднимается? К сожалению, под линуксом сейчас проверить не могу (вот под всем остальным могу, а десктопного линукса под рукой нет). Если раньше никто не займётся, то через пару недель оживлю Raspberry Pi и посмотрю, в чём проблема. — putnik 11:10, 21 сентября 2020 (UTC)[ответить]

Обсуждение (Putnik)[править код]

Итог[править код]

Высказанные замечания к кандидату относятся к 2017 году и ранее, поэтому при отсутствии новых аналогичных претензий бюрократы не склонны рассматривать это как сильный аргумент в пользу невыдачи флага. В то же время с точки зрения технической грамотности серьёзных претензий к участнику предъявлено не было, а прошлый опыт, в том числе администраторской работы, и высказывания участников тут не оставляют сомнений в доверии сообщества. Флаг присвоен. Track13 о_0 17:07, 22 сентября 2020 (UTC)[ответить]

Запрашиваю флаг инженера (без АИНа) для правки шаблонов и модулей. Уже запрашивал в 2018 году. Примеры задач, для которых нужен флаг:

Викизавр (обс.) 11:24, 18 сентября 2020 (UTC)[ответить]

Вопросы (Wikisaurus)[править код]

  • Возможно ли сохранить в викитекст статьи код {{subst:example}}, чтобы подстановка произошла при следующем сохранении кода страницы, и если да, то как?·Carn 11:36, 18 сентября 2020 (UTC)[ответить]
  • В прошлом обсуждении флаг не был присвоен, поскольку были отмечены «проблемы с соблюдением правила ВП:МНОГОЕ, конфликтное поведение в обсуждениях, иногда с нарушением правил ВП:ЭП либо с балансированием на грани их нарушения». Соответственно, вопрос: возникают ли сейчас те проблемы, из-за которых флаг тогда не был присвоен? Vladimir Solovjev обс 12:25, 18 сентября 2020 (UTC)[ответить]
    • Это сложно самому оценить, тут скорее смотрю на мнение коллег: прошлый раз меня блокировали больше года назад (ну кроме блокировки по собственному желанию, чтобы не отвлекаться на рувики по время викиотпуска), а коллега Oleg Yunakov, выступавший в прошлой заявке категорически против выдачи флага, считает, что проблемы решились. Викизавр (обс.) 12:10, 19 сентября 2020 (UTC)[ответить]

Обсуждение (Wikisaurus)[править код]

Итог[править код]

Проблемы, на которые обращали внимание в прошлой заявке, решены. Есть отдельные предупреждения за нарушение ВП:ЭП, но этот пункт не был определяющим в прошлом итоге и для заявки на технический флаг может быть рассмотрен как исключительно второстепенный. В обсуждении новых проблем не выявлено, поэтому флаг присвоен, приятной работы с ним. Track13 о_0 18:38, 27 сентября 2020 (UTC)[ответить]


Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

Прошу присвоить мне статус инженера. Igor M. Chernov (обс. 10:12, 26 октября 2020 (UTC)[ответить]

Вопросы (Igors Cernovs)[править код]

Зачем оно вам надо? Ghuron (обс.) 10:24, 26 октября 2020 (UTC)[ответить]

У Вас нет правок в шаблонах и модулях. Для чего Вам нужен флаг инженера? — Venzz (обс.) 10:57, 26 октября 2020 (UTC)[ответить]

Обсуждение (Igors Cernovs)[править код]

Итог[править код]

Заявка снята. — Adavyd (обс.) 08:48, 6 ноября 2020 (UTC)[ответить]