Раздел предложений в Village Pump используется для предложения конкретных изменений для обсуждения. Перед отправкой :
Проверьте, не описано ли ваше предложение в разделе Perennial suggestions . Вы также можете поискать в разделе FAQ .
Эта страница для конкретных, действенных предложений. Рассмотрите возможность разработки предложений на более ранней стадии в Village pump (идеальная лаборатория) .
Текущая система очень запутана. Нахождение на подстранице четвертого уровня в другой вики с 90% неподписанных комментариев и использование системы эмодзи для различения решенных/нерешенных проблем превращает ее в кошмар для a) поиска проблем, b) ответа и c) запроса дополнительных подробностей. Было бы проще иметь страницу вроде Wikipedia:Dark mode reports, чтобы больше редакторов могли помогать исправлять проблемы. Нам следует импортировать страницу сюда и архивировать страницу вики MediaWiki. Мысли? @ SCP-2000 , FeRDNYC , и я Andumé : как редакторы, участвующие там в исправлении проблем (если я кого-то пропустил, не стесняйтесь пинговать их). — Matrix(!) { пользователь - обсуждение? - бесполезные вклады } 14:42, 5 октября 2024 (UTC) [ ответить ]
Примечание: когда вы переходите к «Сообщить о проблеме с темным режимом», вы должны попасть сюда: https://www.mediawiki.org/wiki/Wikipedia:Village_pump_(proposals)/Reading/Web/Accessibility_for_reading/Reporting/en.wikipedia.org?section=new&action=submit&preloadtitle=PAGEYOUAREON%20dark%20mode%20error&preload=MediaWiki:vector-night-mode-issue-reporting-preload-content . Рабочий процесс для вышедших из системы пользователей/мобильных устройств может отличаться. — xaosflux Talk 20:30, 5 октября 2024 (UTC) [ ответить ]
Их можно локализовать, изменив эти интерфейсные сообщения. Однако, если мы не сообщаем об этом на странице, на которую это сообщается на mediawikiwiki, мы не должны ожидать, что разработчики программного обеспечения и команда проекта будут отслеживать отчеты. — xaosflux Talk 23:28, 5 октября 2024 (UTC) [ ответить ]
^ Это. Подумайте, что для вас важнее — структурировать страницу по-вашему или чтобы команда разработчиков посмотрела на отзывы. Компромиссы — это факт жизни. По моему скромному мнению, они, скорее всего, оценили бы некоторые улучшения формата, но также возможно, что это то, что работает для них лучше всего (например, возможно, исключение подписей решает для них проблему конфиденциальности, если они импортируют отзывы в другую систему? Я сомневаюсь, но забор Честертона предполагает, что мы не должны предполагать, что нет причин для необычного формата). WhatamIdoing ( talk ) 00:48, 6 октября 2024 (UTC) [ ответить ]
@ Xaosflux : Я не думаю, что команда разработчиков программного обеспечения уже давно смотрела на какие-либо отчеты. Похоже, что это в основном оставлено на усмотрение сообщества. Они сделали кое-что в начале бета-тестирования темного режима, но поскольку самые важные функции были реализованы, более мелкие шаблоны и страницы были оставлены сообществу. — Matrix(!) { пользователь - обсуждение? - бесполезные вклады } 09:35, 6 октября 2024 (UTC) [ ответить ]
Я согласен, что отчеты со всех вики должны собираться в одном централизованном месте, чтобы разработчикам приходилось просматривать только одну вики, но я не уверен насчет значков статуса. Разработчики должны уметь читать по-английски, чтобы понимать отчеты, так разве их статус не может быть на английском? Фил Бриджер ( обсуждение ) 11:07, 6 октября 2024 (UTC) [ ответить ]
Темный режим предназначен не только для английской Википедии, поэтому архивация страницы в вики Mediawiki и привлечение сообществ всех других вики к английской Википедии для отправки отчетов — не идеальный вариант. isaacl ( обсуждение ) 01:37, 6 октября 2024 (UTC) [ ответ ]
@Isaacl, если бы мы изменили ссылку на отчет здесь, она была бы доступна только пользователям enwiki — любой пользователь сотен других проектов все равно перешел бы на mediawikiwiki, если только их проект также не переопределил бы ссылку по умолчанию. — xaosflux Talk 02:33, 6 октября 2024 (UTC) [ ответить ]
Я отвечал на предложение заархивировать вики-страницу Mediawiki. isaacl ( обсуждение ) 02:44, 6 октября 2024 г. (UTC) [ ответ ]
Ах, ладно, это определенно не решение, которое нужно принимать здесь. — xaosflux Talk 11:36, 6 октября 2024 (UTC) [ ответить ]
@Isaacl: Кажется, вы неправильно поняли предложение. Мы можем архивировать только эту страницу, нам не нужно архивировать все для каждого сайта. — Matrix(!) { пользователь - обсуждение? - бесполезные вклады } 09:37, 6 октября 2024 (UTC) [ ответить ]
Это на самом деле второстепенно, но, конечно, если они попадут куда-то еще, их можно будет скопировать и просто оставить там заметку. — xaosflux Talk 11:44, 6 октября 2024 (UTC) [ ответить ]
Спасибо за разъяснение. Я согласен с другими, кто высказался в пользу централизованного расположения для сообщений об ошибках. isaacl ( talk ) 16:33, 6 октября 2024 (UTC) [ ответить ]
cc @ Jon (WMF) и SGrabarczuk (WMF) : кто является членами команды WMF Web. SCP -20 00 10:38, 6 октября 2024 (UTC) [ ответить ]
Примером проекта, который делает что-то подобное, является dewiki, см. w:de:Wikipedia:Dark Mode/Probleme для их страницы. — xaosflux Talk 11:44, 6 октября 2024 (UTC) [ ответить ]
Я вспоминаю ранний выпуск визуального редактора, когда некоторые редакторы (включая по крайней мере одного сотрудника WMF) тратили значительное время и усилия на перевод пользовательских отчетов, оставленных на странице en.wp, в тикеты phabricator, часто после дополнительного тестирования для проверки отчетов и предоставления более полезных для разработчиков деталей. Я вообще не участвую в темном режиме (и лично им не пользуюсь), но если найдутся добровольцы, чтобы сделать что-то подобное, то предоставление людям возможности отправлять отчеты локально с копированием этих отчетов может сработать. Thryduulf ( talk ) 17:12, 6 октября 2024 (UTC) [ ответить ]
Это принципиально иная ситуация, поскольку, в то время как любые проблемы с визуальным редактором, как правило, проявляются везде, независимо от того, какая установка сообщила о проблеме, в случае с проблемами темного режима подавляющее большинство случаев решается путем внесения локальных изменений в контент (в конкретную статью или шаблон). Исчезающе малый процент сообщенных проблем каким-либо образом обобщается за пределами непосредственного контекста первоначального отчета. (Поэтому, я согласен, немного странно изначально пересылать отчеты в другую вики; проблемы с локальным контентом — а это так — должны решаться и в конечном итоге будут решаться локально.) FeRDNYC ( обсуждение ) 20:38, 6 октября 2024 (UTC) [ ответ ]
Привет всем - хотел бы дать быстрый ответ с точки зрения команды. Короче говоря - это полностью зависит от того, что сообщество сочтет более простым/удобным. Изначально мы настроили систему так, чтобы она была более централизованной, поскольку не хотели предполагать, какую локальную страницу каждая вики посчитает более удобной. Тем не менее, у нас нет проблем с тем, чтобы вики вносили изменения в локальную страницу, если это предпочтительнее, и несколько вики до сих пор решили сделать это с хорошими результатами. Более подробная информация о том, как это сделать, доступна в верхней части нашей общей страницы отчетов. Надеюсь, это будет полезно! OVAsileva (WMF) ( talk ) 19:47, 8 октября 2024 (UTC) [ reply ]
Спасибо за разъяснение, что это нормально для команды разработчиков, я сейчас начну раздел опроса, чтобы проверить консенсус сообщества. — Matrix(!) ping one при ответе { пользователь - обсуждение? - бесполезные вклады } 16:19, 9 октября 2024 (UTC) [ ответить ]
Опрос (отчетность в темном режиме)
После ответа от WMF я думаю, что было бы неплохо провести опрос, чтобы проверить, хотим ли мы двигаться дальше. @ Xaosflux , FeRDNYC , SCP-2000 , Isaacl, Phil Bridger , WhatamIdoing и Thryduulf : и любые другие люди, пожалуйста, кратко изложите свою позицию:
Поддержка как предлагающего: Большинство людей, которые на самом деле решают проблемы темного режима, сейчас не разработчики WMF, а волонтеры. Проблемы темного режима являются локальной проблемой по FeRDNYC и поэтому должны решаться локально на этой вики для достижения наилучших результатов. Мы также можем изменить систему на что-то лучшее в процессе (включая подписи, использование шаблонов архивов вместо эмодзи и т. д.). — Matrix(!) пинг один при ответе { пользователь - обсуждение? - бесполезные вклады } 16:28, 9 октября 2024 (UTC) [ ответ ]
@ Matrix , ты планируешь следить за страницей и решать проблемы? Я нет. WhatamIdoing ( talk ) 17:02, 9 октября 2024 (UTC) [ ответить ]
В этом случае я полагаюсь на то, что вы считаете функциональным для себя/любого другого, кто выполняет эту работу. Если объем достаточно мал (одна заметка в неделю?), то перенаправление ссылки на Wikipedia:Village pump (техническая) может быть лучше, чем создание новой страницы. WhatamIdoing ( обсуждение ) 17:24, 9 октября 2024 (UTC) [ ответить ]
Скорее 3-4 в день. Похоже, что обращение к VPT вызовет проблемы. — Matrix(!) пинг один при ответе { пользователь - обсуждение? - бесполезные вклады } 20:38, 9 октября 2024 (UTC) [ ответить ]
Я полностью нейтрален по этому поводу, комментирую здесь только потому, что меня запинговали. Thryduulf ( обсуждение ) 17:04, 9 октября 2024 (UTC) [ ответить ]
Oppose Я не вижу смысла - это подразумевает трату больших усилий на исправление того, что на самом деле не сломано. * Pppery * это началось... 15:11, 12 октября 2024 (UTC) [ ответить ]
@ Pppery : Но он сломан — на странице нет архива, нет подписей, поэтому ответы медленные, текущая система эмодзи для ответа на проблемы некачественная, и она спрятана в неизвестном месте, поэтому никто не может ее найти, чтобы помочь исправить проблемы. Кроме того, поскольку нет подписей, это кошмар — гоняться за людьми, чтобы получить дополнительные сведения о проблемах. Какая часть этого не сломана? — Matrix(!) пинг один при ответе { пользователь - обсуждение? - бесполезные вклады } 11:35, 13 октября 2024 (UTC) [ ответить ]
Я просто не уверен, что стоит изобретать новое колесо ради чего-то подобного — система не сломана в том смысле, что о проблемах сообщают и их устраняют. * Блин * началось... 16:19, 17 октября 2024 (UTC) [ ответить ]
То, что проблемы решаются, не означает, что это происходит эффективно. Текущая система очень неэффективна, даже если проблемы решаются. Она по-прежнему создает много трений, мешая новым пользователям решать проблемы. — Matrix(!) ping one при ответе { пользователь - обсуждение? - бесполезные вклады } 18:19, 17 октября 2024 (UTC) [ ответить ]
Выполнение
Хорошо, консенсус заключается в том, что люди, устраняющие проблемы с темным режимом, могут определить местоположение , и FeRDNYC также выразил текущие проблемы с текущей системой. Проблемы с темным режимом в конечном итоге обычно являются локальной проблемой, и WMF также заявил, что это технически возможно. Нам нужно будет сделать несколько вещей:
Импортируйте страницу MediaWiki в enwiki с параметрами «Копировать все редакции этой страницы» и «Назначить правки локальным пользователям, если указанный пользователь существует локально» (это важно для последующего архивирования).
Думаю, мы можем начать работать над этим.
— Matrix(!) пинг один при ответе { пользователь - обсуждение? - бесполезные вклады } 08:57, 12 октября 2024 (UTC) [ ответить ]
Я согласен сделать transwiki-импорт для этого, когда буду готов, но пока не вижу консенсуса в обсуждении выше. Часть «назначить локальный» не нужна; сомневаюсь, что кто-то в mwwiki будет заботиться об этой странице, мы не собираемся ничего удалять там, но можем просто наложить на нее кросс-вики-перенаправление. Ну и что дальше? Тот, кто не !проголосовал за это выше, должен в конечном итоге закрыть это обсуждение с результатом. Что касается части xmlimport, не стесняйтесь пинговать меня в это время. — xaosflux Talk 11:43, 13 октября 2024 (UTC) [ ответить ]
Справедливо. Я подожду, пока не будет достигнут консенсус (я просто потерял терпение, так как никто не участвовал). — Matrix(!) пинг один при ответе { пользователь - обсуждение? - бесполезные вклады } 11:49, 13 октября 2024 (UTC) [ ответить ]
Жеребьёвка для получения повышенных разрешений
Предложение для испытания: назначение небольшой случайной группы редакторов с повышенными правами доступа на фиксированный короткий срок путем жеребьевки .
Тест 1: Выбранные редакторы с расширенным подтверждением , которые редактировали в течение последних 100 дней, получают AfC и/или нового рецензента страницы, у которых есть бэклоги. Им все равно придется читать инструкции. (PCR слишком слаб для практического эксперимента, имхо.)
Правила: Любой администратор может вынести предупреждение за любое поведение в любое время; одно предупреждение, и вы исключены; продление срока не предусмотрено; исключений нет. Также: вы не можете отказать в разрешениях, и ваша история редактирования или санкций (но не история блокировок) не влияет на то, получите ли вы разрешения или нет. Каждый администратор и редактор с равными правами, способный осуществлять надзор, будет иметь легкодоступный список тестовых редакторов. (Нетрудно вывести иное.)
Цифры: По консервативной оценке, для первого эксперимента может потребоваться участие 200 редакторов в обоих тестах одновременно в течение 6 месяцев, в зависимости от уровня активности участников выборки. Если 20 редакторов существенно увеличат свою активность в ответ, это можно будет измерить и контролировать.
Цель состоит в том, чтобы повысить вовлеченность относительно активных редакторов по всему спектру и, возможно, даже мотивировать запросы на постоянные разрешения и администрирование в дальнейшем. В этом духе, если тестовый редактор теряет разрешения в правиле одного удара, это должно иметь минимальное или нулевое влияние на запрос разрешений в будущем. Это обучающий и мотивирующий опыт. То, что разрешения здесь в конечном итоге обратимы и имеют надзор, означает, что в конечном итоге, если плохо себя ведущий редактор теперь в конечном итоге сможет достоверно запросить разрешения в будущем, эта модель, если она является причинной, действительно была успешной.
Исследования, преимущества и предостережения
Литература по жеребьевке рассматривает как вопросы, которые не имеют никакого отношения к управлению WP, так и вопросы, которые весьма важны. Кроме того, я считаю, что есть вопросы, уникальные для WP, которые может решить жеребьевка, но которые литература еще не сделала. Обзор: (TG Bouricius 2013 "Democracy Through Multi-Body Sortition: Athenian Lessons for the Modern Day").
То, что предлагается, называется частичным управлением путем жеребьевки с ротацией и мандатом (Оуэн и Смит 2018 «Жеребьёвка, ротация и мандат»). Известные и возможные преимущества и предостережения:
Случайный выбор с большей вероятностью обеспечит демографическое и идеологическое представительство (Ebadian et al 2022 «Является ли жеребьевка и репрезентативной, и справедливой?»). В то время как редакторы WP не являются репрезентативными для населения в целом, наша администрация еще менее репрезентативна (в Corple 2016 «Beyond the Gender Gap» стр. 25: 6% против 15%+).
Высокий барьер для входа на администрирование WP и некоторые разрешения в сочетании с неблагодарностью задач и относительно низким социальным престижем означает, что мы, вероятно, ниже уровня замещения на администрировании, и есть невыполненные задания для областей, требующих разрешений. Жребий, если он приводит к участию, снимает это бремя. Он также увеличивает представительную справедливость и идеологическое разнообразие для тех, кто будет обрабатывать контент и административные невыполненные задания. (Насколько мне известно, это уникальная проблема WP.) В польской Википедии изучалось исключающее влияние знакомства среди администраторов на новых кандидатов (Spychała et al 2014 "Does the Administrator Community ... Acquaintance Relation?"); поэтому, если подобное явление существует во всех разрешениях, то жеребьевка поможет его разрушить.
Если есть административная коррупция (и некоторые редакторы заявляют об этом), предлагается жеребьевка для ее уменьшения (Bagg 2024 «Жребий как средство борьбы с коррупцией»). Это также потенциально является проверкой против административной подрывной деятельности (Sutherland 2011 «Что может и не может сделать жеребьевка») со стороны заговорщиков редакторов, как недавно было раскрыто в хорватской Википедии .
О влиянии предоставления привилегий/власти: В (Sassenberg et al 2014 "Власть развращает: пересмотрено") связь повышенной власти и чувства общественной ответственности против индивидуальной коррупции (независимо от того, повышено ли одно по сравнению с другим) является сложной с противоречивыми результатами в литературе. В целом, если люди находятся в социально ориентированной среде и целях, которые, как я полагаю, олицетворяют редактирование WP, то власть будет ориентировать их на первое. Однако обзор также предполагает, что восприятие власти как возможности увеличения или поощрения, а не просто увеличения ответственности, является большой частью повышенных мотивационных эффектов, что предполагает, что, поскольку жеребьевка может снизить престиж повышенных привилегий, она будет иметь отрицательное влияние на мотивацию; но это снова кажется сильно зависящим от социального контекста и цели в литературе.
Мой краткий обзор литературы предложил возможные пути для будущих исследований WP; для дальнейшего изучения власти и мотивации см. Pappas APA 2021; и в частности, мы могли бы настойчиво добиваться повышения социального престижа повышенных привилегий в WP, а также связанных с ними социальных обязанностей, согласно таким управленческим документам, как (Friedrichs 2023 «Преимущества мотивации просоциальной власти в лидерстве»). Также, хотя и заманчиво рассмотреть, если этот эксперимент будет успешным, радикальное будущее предлагаемое разделение администраторов, похожее на админ-на-день, предложенное в 2012 году , но , согласно WMF, это юридически неосуществимо , запретительные привилегии являются откатом и удаленным материалом . SamuelRiv ( обсуждение ) 22:39, 7 октября 2024 (UTC) [ ответить ]
Мне трудно представить, что мы (т. е. те из нас, кто достиг определенной степени власти и контроля в нынешней системе) будем готовы отказаться от контроля над разрешениями, какими бы незначительными они ни были.
Тем не менее, я думаю, что и Тест 1, и Тест 2 были бы полезными экспериментами, и я специально предлагаю рассмотреть возможность выбора кандидатов для Теста 2 из числа тех, кто в любом случае близок к EXTCONF (например, у них есть время, но им не хватает 100–200 правок, или у них есть правки, но им не хватает 1–2 месяцев).
Что касается масштаба эксперимента, то его действительно следует определять с помощью анализа мощности (статистики) . WhatamIdoing ( обсуждение ) 17:22, 9 октября 2024 (UTC) [ ответить ]
Даже если в них есть элемент власти и статуса, подавляющее большинство того, что делают люди с расширенными правами, — это просто рутина. Мне кажется крайне маловероятным, что кто-то, случайно назначенный NPP или даже администратором, действительно захочет ими воспользоваться. И одна из основных функций системы perm — уменьшить поверхность атаки, которую предлагают эти права, предоставляя их только тем людям, которые достаточно мотивированы, чтобы попросить об этом.
Кроме того, да, AfC и NPP отстают, но «проверка рецензентов» — это тоже работа, и ею занимается очень мало администраторов. Это значительно увеличит нагрузку — кто возьмет на себя эту нагрузку? – Джо ( обсуждение ) 17:58, 9 октября 2024 (UTC) [ ответить ]
Я представляю, что редактор, получивший записку, в которой говорится что-то вроде "Вам дали это разрешение временно. Пожалуйста, прочтите и используйте его, если хотите", может воспользоваться им несколько раз, по крайней мере, чтобы попробовать. Если у них будет положительный опыт, они могут запросить разрешение позже через обычные каналы.
Предоставление разрешения только тем, кто достаточно мотивирован, чтобы попросить, означает, что более высокий процент запрашивающих имеет неправильную мотивацию. Необъявленные оплачиваемые редакторы будут более мотивированы просить разрешение, чем обычный доброволец. WhatamIdoing ( talk ) 18:20, 9 октября 2024 (UTC) [ ответить ]
Я большой поклонник жеребьевки для заполнения реальных должностей, как там, где она используется во многих странах (в основном для отбора присяжных), так и для некоторых других должностей. Несколько мыслей о ее применимости к Википедии:
Я сомневаюсь, что многие люди будут уделять много времени этой задаче, поскольку им нужно зарабатывать на жизнь, а выплата зарплаты выбранным людям вызовет множество других проблем.
Многие люди попробуют воспользоваться новыми разрешениями, но большинство откажутся.
Должны быть четкие критерии успеха/неудачи. Слишком много вещей здесь пробуют, затем явно терпят неудачу, но продолжают использовать из-за заблуждения о невозвратных затратах (я знаю, что это спорно, но я бы отнес черновое пространство к одному из них).
Я уверен, что мог бы привести еще массу доводов, как за, так и против, но мне пора идти. Фил Бриджер ( обсуждение ) 19:49, 9 октября 2024 (UTC) [ ответить ]
Крайне желательны четкие критерии. К сожалению, я не уверен, что работает одна метрика (например, мы не хотим потерять этих случайно выбранных редакторов и не хотим, чтобы статьи WP:UGLY были в основной теме), и вполне возможно, что правильное выполнение работы приведет к тому, что выбранные редакторы уйдут. Например:
Существующие акции AFC имеют очень низкий процент удалений в AFD. (Я считаю, что нормальный процент составляет около 75%). Учитывая, что они должны продвигать статьи, которые с большой вероятностью (т. е. 51%, а не 90%) переживут AFD, это означает, что они недостаточно продвигают и чрезмерно ограничивают.
Если новые люди из AFC коллективно продвигают статьи, которые удаляются только в 40% случаев, это признак того, что они делают это правильно (все еще недостаточно продвигают, на самом деле), даже если их статьи удаляются чаще, чем старые люди из AFC. Метрика AFD показала бы успех.
Но: если каждый AFD или подготовка к этим AFD сопровождается взаимными обвинениями и жалобами на то, что они слишком «снисходительны», то редакторы, на которых кричали, могут уйти. Метрика удержания редакторов покажет провал.
Если мы получим неоднозначные результаты, что нам делать? WhatamIdoing ( обсуждение ) 21:50, 9 октября 2024 (UTC) [ ответить ]
Если новые люди из AFC коллективно продвигают статьи, которые удаляются только в 40% случаев, это признак того, что они делают это правильно (на самом деле, все еще недостаточно продвигают).Не обязательно. Если они продвигают статьи с вероятностью выживания AfD выше 50%, и мы предполагаем, что они равномерно распределены по вероятности, средняя продвигаемая статья будет иметь 75% шансов выживания AfD, или, другими словами, будет удалена в 25% случаев. Если они будут удалены в 40% случаев, может иметь место уровень чрезмерного продвижения. Chaotic Enby ( обсуждение · вклад ) 16:38, 16 октября 2024 (UTC) [ ответить ]
(Я люблю людей, которые умеют считать.)
Я думаю, это зависит от ваших основных предположений о распределении. Если у вас есть 10 статей, каждая с 51% вероятностью выживания в AFD, и вы продвигаете их все, и все 10 отправляются в AFD, то вы ожидаете, что пять будут удалены — и все они по-прежнему были правильными продвижениями. WhatamIdoing ( talk ) 16:55, 16 октября 2024 (UTC) [ ответить ]
Это, безусловно, зависит от наших гипотез о распределении, на самом деле. Если 10 статей находятся в диапазоне от 51%, 56%, ... до 96%, то у вас будет более низкое ожидание удаленных статей (2,65, если я правильно посчитал). Но здесь также есть скрытое предположение, что статья с 96% шансами выжить в AfD, вероятно, не будет отправлена туда изначально, что означает, что скорость удаления статей, отправленных в AfD, будет, естественно, выше, чем общая скорость удаления.В целом, было бы интересно получить больше статистики как о вероятности удаления статей AfC в AfD, так и о том, насколько статьи AfC изначально недопредставлены в AfD. Chaotic Enby ( обсуждение · вклад ) 18:18, 16 октября 2024 (UTC) [ ответить ]
Статистику удалений трудно измерить ретроспективно. Возможно, нам нужно изучить это в перспективе. Также есть сложность с опытом: люди, отправляющие статьи через AFC, не будут иметь такой же процент удалений, как люди вроде вас и меня. WhatamIdoing ( talk ) 18:51, 16 октября 2024 (UTC) [ ответить ]
Также, хотя и заманчиво рассмотреть, если этот эксперимент будет успешным, радикальное будущее предложение о сортировке администраторов, похожее на админ-на-день, предложенное в 2012 году, но согласно WMF это юридически невыполнимо, запретительные привилегии - это откат и удаленный материал. Это не обязательно должно предотвратить это; WMF не устанавливает фактическую планку для обзора сообщества. Таким образом, мы могли бы иметь гораздо менее нажимной, менее значимый обзор сообщества каждого редактора, который соответствует определенному порогу правок и возраста, чтобы определить право на получение этих прав на один день через сортировку, с единственным фокусом на том, «вероятно ли, что этот человек будет злоупотреблять откатом или доступом к удаленному материалу?» (что почти всегда склонялось бы к принятию, поскольку это автоматически, делается для всех и не предоставляет администрирование напрямую.) Только аргументы и обоснования, конкретно связанные с этим вопросом, будут разрешены и рассмотрены закрывающими при закрытии таких обсуждений, а не общие обсуждения того, станут ли они хорошими администраторами в других отношениях; и они не будут требовать закрытия bcrat или чего-то еще. Это затем позволит предоставить статус администратора этим редакторам через жеребьевку, поскольку они ранее прошли проверку сообщества по аспектам, которые волнуют WMF. -- Aquillion ( обсуждение ) 19:12, 16 октября 2024 (UTC) [ ответить ]
запретительные привилегии — откат и . Откат не кажется очень опасным. Сомневаюсь, что wmf будет слишком легко его раздавать. Согласен, что wmf будет возражать против раздачи view removed по юридическим причинам. Это уже хорошо обсуждалось. – Novem Linguae ( talk ) 19:19, 16 октября 2024 (UTC) [ ответить ]
Я не думаю, что WMF заботится о Wikipedia:Rollback (который даже не используется часто, потому что Twinkle и другие скрипты могут имитировать тот же эффект). Юридическая проблема в том viewdeleted. Они постоянно заявляли, что хотят доказательств того, что сообщество доверяет людям, у которых есть это конкретное право (например, мы доверяем им не восстанавливать copyvios или повторно размещать загруженное порно мести на другом сайте). Процесс проверки сообщества может измениться, но должен быть процесс проверки сообщества. WhatamIdoing ( обсуждение ) 19:43, 16 октября 2024 (UTC) [ ответ ]
(например, мы доверяем им не восстанавливать copyvios или повторно размещать загруженное порно мести на другом сайте) . Я никогда не слышал об этом. Заявленная WMF причина того, что viewdeleted считается чувствительным, заключается в том, что они хотят иметь возможность сказать в суде, что когда что-то удаляется, это действительно удаляется, и что только проверенные лица будут иметь к этому доступ, а не быть легкодоступным. Мне кажется, что BLP, клевета и оскорбления и т. д. остаются удаленными, и что они могут утверждать, что это действительно удалено в суде. – Novem Linguae ( обсуждение ) 20:40, 16 октября 2024 (UTC) [ ответить ]
Если кто-то восстанавливает здесь неуместное или размещает его на других сайтах, то это не "оставаться удаленным", и никто не может утверждать, что это так, даже за обеденным столом. Мы должны быть уверены, что администраторы этого не сделают. WhatamIdoing ( обсуждение ) 21:59, 16 октября 2024 (UTC) [ ответить ]
В любом случае, я хочу сказать, что мы можем иметь более легкий процесс проверки, сосредоточенный конкретно и исключительно на том, может ли кто-то злоупотреблять конкретными инструментами, которые беспокоят WMF. Всякий раз, когда возникают альтернативные подходы к администрированию, люди поднимают эту проблему WMF, и ее легко решить. WMF не беспокоится о людях, злоупотребляющих блокировками или разблокировками или взвешивающих действия по обеспечению соблюдения WP:AE или AE; и (воспринимаемый, по крайней мере) высокий риск, связанный с этими вещами в рамках текущей системы, на самом деле заставляет людей неохотно продвигать администраторов и, следовательно, затрудняет RFA . Это также самоподдерживающееся явление, поскольку чем меньше администраторов, тем большее влияние оказывает каждый из них, повышая ставки RFA таким образом, что возникает риск его нарушения. Сообщество и WMF беспокоятся о разных вещах. -- Aquillion ( обсуждение ) 22:34, 16 октября 2024 (UTC) [ ответить ]
Согласен. Это решаемая проблема. Кроме того, ее не обязательно решать в первой итерации. Мы могли бы протестировать систему на нескольких других правах пользователя, а затем вернуться и протестировать другие. WhatamIdoing ( talk ) 23:09, 16 октября 2024 (UTC) [ ответить ]
Разве порно мести и т.п. не будут контролироваться , а не просто удаляться? jlwoodwa ( обсуждение ) 04:57, 17 октября 2024 (UTC) [ ответить ]
Да, но администраторы часто сначала выявляют серьезные проблемы, прежде чем сообщать об этом контролерам. (Кроме того, это обычно не загружается локально.) WhatamIdoing ( обсуждение ) 05:02, 17 октября 2024 (UTC) [ ответить ]
WMF не заботится об откате. Мы могли бы даже автоматически продвигать пользователей в какую-нибудь группу «существует некоторое время», которая включает в себя все Autopatrolled, New page reviewer, Page mover, Pending changes reviewer, Rollback, и им было бы все равно. — xaosflux Talk 13:53, 17 октября 2024 (UTC) [ ответить ]
Возвращаясь к этому предложению , я хочу сделать значки более четкими и изящными; со временем я добавлю больше значков (например, хорошие статьи, аудиостатьи и т. д.). Я также хочу добавить региональные буквенные скрепки, например, 拡 (拡張, Kakuchō) будет японским значком расширенной защиты, то же самое с 満 (満杯, Manpai) для полной защиты.
Запрос новых иконок для Википедии. (Доступно всем)
2I3I3 ( обсуждение ) 16:25, 16 октября 2024 (UTC ) [ ответ ]
Согласен с другими, что эти новые значки выглядят устаревшими. Однако, если мы обсуждаем изменения в значках блокировки, то должен сказать, что фиолетовый цвет для защищенной загрузки неуместно безвкусен. Cremastra — talk — c 20:23, 17 октября 2024 (UTC) [ ответить ]
Довольно сильно против попытки запустить скрипт геолокации при каждой загрузке, чтобы попытаться сделать динамические метки здесь. Если что (что мне тоже не нравится), метки должны следовать языку пользовательского интерфейса. — xaosflux Talk 17:39, 16 октября 2024 (UTC) [ ответить ]
Я понимаю различия, я просто предположил (так как я не говорю ни на каком другом языке, вы могли бы предложить конкретную версию). Также, позже я добавлю буквы на скобы.
2I3I3 ( обсуждение ) 19:16, 16 октября 2024 (UTC ) [ ответ ]
и значки* 2I3I3 ( обсуждение ) 19:16, 16 октября 2024 (UTC) [ ответ ]
Форматы файлов SVG могут быть переведены. Смотрите c:Commons:Возможность перевода/Узнать больше. WhatamIdoing ( обсуждение ) 23:33, 16 октября 2024 (UTC) [ ответить ]
Выступайте против того, чтобы основным (единственным) различием был цвет, поскольку это дает меньше информации, чем текущая схема, и бесполезно для тех, у кого нет способностей видеть цвет. — xaosflux Talk 17:41, 16 октября 2024 (UTC) [ ответить ]
Согласен с Xaosflux по этому поводу. Более того, две проблемы старой схемы иконок (цвет и "реалистичное" затенение, которое не очень хорошо смотрится на маленьких иконках), которые изначально были причинами изменений, присутствуют и здесь.Что касается региональных символов, было бы разумнее отображать их в зависимости от языковой версии, и поскольку каждая языковая версия уже устанавливает свои собственные стандарты для этого, мы не можем сделать больше. Chaotic Enby ( обсуждение · вклад ) 18:13, 16 октября 2024 (UTC) [ ответить ]
Согласен с Xaosflux, так как раскраска и затенение не очень хорошо смотрятся на маленьких значках. ‹ hamster717🐉 › ( обсуждайте что угодно!🐹✈️ • мой вклад🌌🌠 ) 20:33, 18 октября 2024 (UTC) [ ответить ]
Согласен , но только немного. Если бы вы добавили буквы, было бы лучше. Кроме того, решением для вашего региона-базирования может быть создание языкового базирования (например, "O" для "Office" станет "S" для "Schoolhouse" в теоретическом "Reversed English") Мастер ёжиков ( converse ) ( hedgehogs ) 14:33, 17 октября 2024 (UTC) [ ответить ]
Будут ли эти значки/цвета работать с темным режимом? Я также согласен, что буквы необходимы. Thryduulf ( talk ) 14:44, 17 октября 2024 (UTC) [ ответить ]
См. также Shackle . Это навесные замки, а верхняя U-образная часть — это скоба. WhatamIdoing ( talk ) 20:22, 17 октября 2024 (UTC) [ ответить ]
Еще одно решение в поисках проблемы. * Pppery * началось... 16:18, 17 октября 2024 (UTC) [ ответить ]
Согласно WP:WIKICLICHE, нас попросили не говорить об этом так много из-за проблем с цепочкой поставок – если мы будем использовать их слишком много, то в будущем мы можем столкнуться с огромным дефицитом. Но я надеюсь, что янетгенерируя больше тепла, чем света этим комментарием, или выплескивая ребенка вместе с водой. Cremastra — talk — c 20:22, 17 октября 2024 (UTC) [ ответить ]
Никогда не выплескивайте ребенка вместе с водой из ванны. Это загрязнит вашу систему сбора серой воды. Как и другие виды мяса, младенцы не подлежат компостированию, поэтому их следует сортировать в поток отходов на свалке, если иное не рекомендовано вашим муниципальным органом по управлению отходами. Folly Mox ( обсуждение ) Folly Mox ( обсуждение ) 20:46, 17 октября 2024 (UTC) [ ответить ]
Является ли вода в ванне той же водой, в которую я должен привести эту лошадь? Remsense ‥ 论21:40, 17 октября 2024 (UTC) [ ответить ]
Может быть, он находится под мостом — это объяснило бы все эти проблемы. jlwoodwa ( обсуждение ) 01:14, 19 октября 2024 (UTC) [ ответить ]
Псевдо-3D-затенение выглядит устаревшим по сравнению с текущими плоскими иконками. Большинство современных систем дизайна (включая codex, которая является новой системой дизайна для вики-сайтов Wikimedia) построены вокруг плоских иконок. -- Ahecht ( СТРАНИЦА ОБСУЖДЕНИЯ) 18:36, 17 октября 2024 (UTC) [ ответить ]
А как насчет таких значков, как избранный, хороший и аудио? 2I3I3 ( обсуждение ) 18:55, 17 октября 2024 (UTC) [ ответ ]
Просто для развлеченияВсе еще кажется шагом назад. Текущая иконка «Хорошая статья», помимо того, что имеет меньше отвлекающей тени и более удобочитаема, имеет единый стиль со многими другими нашими иконками. Текущая иконка «Избранная статья», хотя и не согласуется с другими, довольно уникальна и узнаваема по дизайну, в то время как эта выглядит как обычная звезда.Просто ради забавы я однажды сделал звезду «Хорошая статья» в стиле FA — конечно, она не предназначалась для какой-либо официальной реализации, выходящей за рамки моего личного сценария , но интересно посмотреть, как это будет выглядеть. Chaotic Enby ( обсуждение · вклад ) 22:14, 17 октября 2024 (UTC) [ ответить ]
К сожалению, это не визуальные улучшения. Это явный регресс в дизайне, и текущие значки хороши. Наша система специфична для английской Википедии, поэтому вполне уместно, чтобы их дизайн был соотнесен с английским языком. Remsense ‥ 论19:29, 17 октября 2024 (UTC) [ ответить ]
Покрасьте меня в тупик. Начиная с Re-instating this proposal , вы заставляете меня думать, что вы хотите оживить какое-то провалившееся предложение. Но затем я перехожу по вашей ссылке и вижу, что предложение привело к внедрению новых значков замка, которые; я полагаю, вы имеете в виду отменить . Я также не понимаю, что вы имеете в виду под региональными буквенными скобами ; вы имеете в виду статьи о , например, Японии? Или статьи, просмотренные кем-то, кто, как мы должны были предположить, может быть в Японии? Или кем-то, у кого японский язык указан в поле пользователя на его странице пользователя? Это английская Википедия, поэтому я не вижу, чтобы последние два были полезными вариантами, а первый приведет только к спорам и путанице , и у нас это уже есть . Текущие значки кажутся мне достаточно понятными, хотя я не знаю, как измерить «гладкий», я полагаю. Подводя итог: сбит с толку . — JohnFromPinckney ( обсуждение / редактирование ) 12:15, 18 октября 2024 (UTC) [ ответить ]
Я имею в виду региональные буквенные скобы, в основном такие же, как буквы на скобах, но с разными региональными переводами. (Это, вероятно, не сработает из-за поста @ Chaotic Enby .)
2I3I3 ( обсуждение ) 18:36, 18 октября 2024 (UTC ) [ ответ ]
Итак (просто чтобы проверить, правильно ли я понял), вы предлагаете в английской Википедии, чтобы японская Википедия использовала значки с японской символикой, а испанская Википедия использовала какой-то индикатор на испанском языке на замке и т. д. Да? — JohnFromPinckney ( обсуждение / редактирование ) 22:30, 18 октября 2024 (UTC) [ ответить ]
Включение выборов SecurePoll с правами electionadmin
Отслеживается в задаче Phabricator T301180
Здравствуйте! Меня зовут Джо Сазерленд, и я работаю в команде доверия и безопасности в Фонде Викимедиа. В прошлом ваше сообщество проявляло интерес к проведению выборов с помощью SecurePoll — возможно, вы уже делали это через votewiki. Сейчас мы рассматриваем возможность сделать это доступным для местных сообществ, чтобы они могли проводить выборы самостоятельно. Для этого в вашем проекте должно быть включено право "electionadmin", которое является правом, разрешающим доступ к конфиденциальной информации.
Таким образом, вам, скорее всего, понадобится запустить Request for Comment (или аналогичный процесс), чтобы достичь консенсуса по внедрению этой функции. Чтобы помочь направить такое обсуждение, мы создали страницу Meta-Wiki с дополнительной информацией о том, что включение права будет означать для вашего сообщества.
Если ваше сообщество обсудит и решит двигаться вперед, T&S хотели бы поддержать вас — сообщите нам по электронной почте ([email protected]), если и когда будет достигнут консенсус. Спасибо!
PS, это может лучше подойти для технического деревенского насоса, так что можете смело переместить его туда, если хотите. Джо Сазерленд (WMF) ( обсуждение ) 20:07, 17 октября 2024 (UTC) [ ответ ]
Поддержка включения. Это кажется формальным шагом, необходимым для содействия выборам администратора , на проведение которых мы пришли к консенсусу . Вопрос о том, нужен ли вообще этот отдельный RfC, является спорным, но я думаю, будет проще просто получить консенсус, чем спорить о его необходимости. Sdkb talk 20:17, 17 октября 2024 (UTC) [ ответить ]
Извините, я не совсем ясно выразился - это будет для будущих выборов (администратор/ArbCom), которые сообщество хотело бы провести. Выборы, которые должны начаться в ближайшее время, будут использовать существующую систему votewiki. Джо Сазерленд (WMF) ( обсуждение ) 19:43, 18 октября 2024 (UTC) [ ответ ]
Поддержка . Это не обязательное условие для проведения административных выборов, выборов в arbcom (или любых других выборов), но (если я правильно понял) это уменьшит объем поддержки, который нам нужен от WMF, когда мы их проведем. Я полностью согласен с последним предложением Sdkb. Thryduulf ( talk ) 20:35, 17 октября 2024 (UTC) [ ответить ]
Поддержка . Это помогло бы нам проводить выборы местных администраторов и выборы арбитражных комитетов , которые не так зависят от ограниченной пропускной способности стюардов (контролеров) и WMF T&S (для настройки vote.wikimedia.org). Кстати, являются ли администраторы выборов в основном проверяющими пользователями в инструменте SecurePoll (имеющими возможность видеть информацию об IP избирателей)? Поэтому нам нужно будет убедиться, что люди, получающие это разрешение, являются функционерами и/или подписывают NDA? – Novem Linguae ( обсуждение ) 20:35, 17 октября 2024 (UTC) [ ответить ]
PS Есть ли на Phab тикет для разделения возможностей проверки выборов от возможностей создания/редактирования выборов? Это может стоить рассмотрения. Человек, который настраивает опросы, не обязательно должен быть тем же человеком, который проверяет всех избирателей. И может иметь смысл иметь здесь разделение. Например, кто-то технический может настроить SecurePoll, а существующие проверяющие пользователи могут проводить проверку. – Novem Linguae ( обсуждение ) 20:39, 17 октября 2024 (UTC) [ ответить ]
Я провел небольшое исследование, и похоже, что любой администратор может создать опрос, но только администраторы выборов (контролеры) могут редактировать опрос или просматривать данные checkuser-like по избирателям. Это разделение немного странное, так как я думаю, что было бы лучше, если бы администраторы также могли редактировать опросы , в которые они были добавлены при создании опросов, поэтому я подал phab:T377531, чтобы немного глубже изучить эту идею. – Novem Linguae ( talk ) 23:56, 17 октября 2024 (UTC) [ ответить ]
Поддержка, чтобы помочь нам реализовать выборы администраторов более практичным способом как для нас, так и для WMF. Однако будут ли администраторы выборов новой группой пользователей? Они, похоже, сочетают в себе характеристики проверяющих пользователей и бюрократов, и я не уверен, сработает ли объединение права в одну из них по умолчанию. С другой стороны, предложение Novem Linguae о разделении права пользователя могло бы работать лучше, с технически мыслящим кратом, настраивающим опрос, в то время как проверяющие пользователи получают право проверки. Chaotic Enby ( обсуждение · вклад ) 22:20, 17 октября 2024 (UTC) [ ответить ]
Если я правильно читаю код... да, electionadmin должен быть либо новой группой пользователей, либо разрешения для нее (securepoll-create-poll, securepoll-view-voter-pii) добавлены к существующей группе пользователей, например checkusers. Последнее может быть проще, чем создание совершенно нового процесса назначения для electionadmins.
На первый взгляд, я не вижу связи между бюрократами и администраторами выборов. Администраторы выборов не могут предоставлять никаких групп пользователей, в отличие от бюрократов. Опять же, если я правильно читаю код, любой администратор может создать опрос. – Novem Linguae ( talk ) 00:01, 18 октября 2024 (UTC) [ ответить ]
Что касается отношений между бюрократами и избирательными администраторами, то это скорее означает, что одна и та же группа будет отвечать за регулярные RfA и административные выборы, а также отделить checkusers от этой дополнительной ответственности. Но это может быть слишком избыточно, и наличие любого технически подкованного администратора, способного это сделать, может быть достаточным, хотя это будет серьезной ответственностью для любого администратора и может затруднить потенциальным кандидатам завоевание доверия избирателей. Chaotic Enby ( обсуждение · вклад ) 13:14, 18 октября 2024 (UTC) [ ответить ]
Технический раздел «Деревня» предназначен для вопросов о том, как сделать X, тогда как предоставление права администратора выборов требует предложения по политике, поэтому эта страница — подходящее место. Поскольку право предоставляет доступ к информации об избирателях (согласно meta:SecurePoll/Local election § Что делает право администратора выборов?), необходим процесс для установления того, кому доверен этот доступ. Варианты, которые я могу придумать, — это обсуждение на основе консенсуса, выборы или назначение (что поднимет вопрос на один уровень выше о том, как решить, какая группа назначает). Принадлежность к существующей доверенной группе, например, к группе с правом надзора или правом проверки пользователя, может быть требованием для того, чтобы стать администратором выборов. isaacl ( talk ) 23:35, 17 октября 2024 (UTC) [ reply ]
Возможно, проще всего предоставить разрешения securepoll-create-poll и securepoll-view-voter-pii для checkusers. Таким образом, нам не нужны накладные расходы на отдельную группу пользователей или отдельный процесс назначения. Я думаю, что вам нужно быть специально добавленным в опрос создателем опроса, чтобы увидеть его PII, поэтому не должно быть никакого риска безопасности от предоставления всем checkusers возможности быть добавленными в опросы создателем опроса. – Novem Linguae ( talk ) 00:03, 18 октября 2024 (UTC) [ ответить ]
Это похоже на серьезную оплошность. Выборы администратора смоделированы по образцу WP:ACE , но, по-видимому, никто не подумал о контролерах, которых нужно одобрять и оснащать каждый год для ACE. Я предполагаю, это означает, что выборы приостановлены, пока мы это не проясним? Просто отойдите в сторону от этого мира ..... сегодня 00:15, 18 октября 2024 (UTC) [ ответить ]
Нет, я думаю, что административные выборы будут продолжаться с использованием старого процесса (голосование будет проводиться на VoteWiki), и это только вопрос будущего. * Pppery * это началось... 00:20, 18 октября 2024 (UTC) [ ответить ]
Ну, это облегчение. Это был такой долгий процесс, чтобы добраться сюда, я не могу сказать, что следовал каждой его части. Просто шаг в сторону от этого мира ..... сегодня 06:56, 18 октября 2024 (UTC) [ ответить ]
Поддержка Если мы собираемся проводить регулярные административные выборы, то имеет смысл, чтобы инфраструктура была локальной. Pinguinn 🐧 00:24, 18 октября 2024 (UTC) [ ответить ]
Локально у нас есть несколько вариантов, которые мы могли бы рассмотреть, если решим проводить опросы. Во-первых, нам НЕ НУЖНО шифровать базу данных, это не делает голоса легкодоступными, но разработчик может получить к ним доступ, так что это то, что следует учитывать (также это означает отсутствие необходимости иметь дело с депонированием ключей для завершения выборов). Кроме того, нам не нужно позволять SP собирать личную информацию. У нас все равно будут имена пользователей, это просто предотвратит использование информации checkuser в голосах securepoll. Это все просто вещи, которые следует учитывать, если мы настроим опросы, — суть в том, что есть варианты. — xaosflux Talk 13:41, 18 октября 2024 (UTC) [ ответить ]
Поддержка Местные сообщества должны иметь автономию для проведения выборов, когда они считают нужным, и не быть настолько зависимыми от определенной команды WMF, у которой плотный календарь. Кроме того, невозможность проводить отдельные выборы на нескольких участках одновременно является большим ограничением текущей системы, которое будет устранено этим. – SD0001 ( обсуждение ) 08:55, 19 октября 2024 (UTC) [ ответить ]
Поддержка — Согласно SD и Xaos выше, я думаю, что локальное развертывание SecurePoll, чтобы отдельные сообщества могли проводить выборы автономно и децентрализованно, жертвуя некоторой конфиденциальностью, в целом является хорошей идеей. Sohom ( обсуждение ) 14:26, 19 октября 2024 (UTC) [ ответить ]
Поддержка Поскольку это дает сообществу возможность для будущих опросов. Как это следует использовать, можно будет сократить позже. -- LCU Активно Неинтересно « @ » ° ∆t ° 20:28 , 19 октября 2024 (UTC ) [ ответить ]
Согласен , но только немного. Если бы вы добавили буквы, было бы лучше. Кроме того, решением для вашего региона-базирования может быть создание языкового базирования (например, "O" для "Office" станет "S" для "Schoolhouse" в теоретическом "Reversed English") Мастер ёжиков ( converse ) ( hedgehogs ) 14:33, 17 октября 2024 (UTC) 
