Википедия: Деревенский насос (все)

Это страница Village pump (all), на которой перечислены все темы для удобного просмотра. Перейдите к деревенскому насосу, чтобы просмотреть список подразделений Village Pump, или нажмите ссылку редактирования над разделом, в котором вы хотите оставить комментарий. Чтобы просмотреть список всех последних изменений этой страницы, нажмите ссылку истории выше и следуйте указания на экране.

Щелкните здесь, чтобы очистить кеш сервера на этой странице (чтобы увидеть последние изменения на подстраницах Village Pump)

Секции деревенских насосов
Политика пост , часы , поиск Обсудить существующие и предлагаемые политики	Технический пост , смотреть , искать Обсудить технические вопросы по Википедии	Предложения размещать , смотреть , искать Обсудить новые предложения, не связанные с политикой	Идея лаборатории пост , часы , поиск Инкубируйте новые идеипрежде чем официально их предлагать	WMF размещать , смотреть , искать Обсудить вопросы, связанные с Фондом Викимедиа	Разное пост , смотри , поиск Размещай сообщения, не попадающие ни в одну другую категорию
Посмотреть сразу все секции деревенских насосов

Обсуждения старше 7 дней (дата последнего оставленного комментария) перемещаются на подстраницу каждого раздела (называемую (название раздела) / Архив).

Дата рождения человека, противоречивые (надежные) источники и WP: SYNTHESIS

На Talk: Taylor Lorenz ведется спор о том, может ли дата рождения субъекта быть указана в ее статье. Независимо от специфики, этот случай вызывает ряд интересных вопросов:

1. Можно ли "построить" DOB человека из нескольких надежных источников? (В случае Лоренца, ее рождение день базировались краткое упоминание о ней находится в «сегодняшние дни рождения» раздел , посвященной Политико , и ее рождение год был выведен из в сентябре 2020 года фортуна статьи листинг ее возраст как 35 ) .
2. Можно ли выносить суждение между конфликтующими источниками? (В случае с Лоренц другой источник назвал ее возраст 31 в 2018 году, подразумевая год рождения 1986/87, но Брандт Люк Цорн утверждал, что скорее доверяет Fortune )

Лоренц - не единственный случай, просто самый последний, который привлек мое внимание. Для аналогичного случая из 2017 см. Обсуждение: Вернон Джарретт (там нам также нужно было взвесить противоречивую информацию из Библиотеки Конгресса, различных некрологов и собственного надгробия человека). Итог: вопрос в том, нарушает ли что-либо из этого WP: SYNTHESIS . В эссе WP: SYNTHNOT этот случай не упоминается среди множества исключений, но, возможно, стоит. - bender235 ( разговор ) 18:24, 15 марта 2021 (UTC)

Изменить : покопавшись в архивах VPP, я увидел, что второй пункт кратко обсуждался в 2013 году . Jayron32 пришел к выводу, что лучше включить противоречащие даты (и указать их явно), чем полностью исключить дату рождения. - bender235 ( разговорное ) 15:19, 27 марта 2021 (UTC)

• Джейрон32 заявил, и я цитирую, «либо цитирую их обоих, и прямо указываю их в тексте (« Источник A говорит, что он родился в 1963 году, но источник B говорит, что он родился в 1959 году), либо полностью опустите его » ( курсив добавлен) - The SandDoctor ^Talk 18:14, 27 марта 2021 г. (UTC).

@ TheSandDoctor : ... и он продолжал, в следующем предложении, с: « Прежний лучше , потому что это то , что мы должны сделать, представляют собой надежные точки зрения в пропорции и позволяют источники говорят сами за себя. » Как Я подвел итог. - bender235 ( разговор ) 22:11, 27 марта 2021 г. (UTC)

Дело в том, что оба были представлены как допустимые варианты, которые не отражала исходная отредактированная цитата. Также стоит отметить, что то, что отстаивалось и неоднократно восстанавливалось, не является ни одним из этих двух вариантов, описанных Jayron32. - The SandDoctor ^Talk, 02:55, 28 марта 2021 г. (UTC)

Было предложено рассмотреть два варианта, а не как действительные. Утверждалось, что одно предпочтительнее другого. Я не понимаю, почему вы продолжаете искажать это. Если я напишу «если раздел 230 будет отменен, Википедия может либо принять, либо закрыть. Первое лучше, потому что ...» не означает, что я считаю оба варианта одинаково хорошими. Здесь вы просто спорите ради спора. - bender235 ( разговор ) 14:46, 28 марта 2021 (UTC)

Я работаю над такими ситуациями уже много лет, часто включая обсуждения в BLPN. Ребекка Де Морней ( редактировать  | говорить  | история  | защищать  | удалять  | ссылки  | смотреть  | журналы  | просмотры ) ,Ли Грант ( редактировать  | говорить  | историю  | защищать  | удалять  | ссылки  | смотреть  | журналы  | просмотры ) , иЛидия Корнелл ( редактировать  | говорить  | история  | защищать  | удалять  | ссылки  | смотреть  | журналы  | просмотры ) являются примерами. Я взгляну. - Хипал ( разговор ) 18:39, 15 марта 2021 (UTC)

Помогло бы четкое определение всех ссылок на странице обсуждения. Также важно отметить любой адрес WP: DOB или, по крайней мере, четко указать статус WP: DOB с учетом ссылок. - Хипал ( разговор ) 18:52, 15 марта 2021 (UTC)

• Я считаю (1) приемлемым в рамках исключения для обычных вычислений для WP: OR. Что касается (2), если один источник явно более приемлем, чем другой, я бы сказал, что нам разрешено позвонить, но если есть настоящая путаница, может быть лучше отметить неопределенность. Имейте в виду, что, поскольку многие источники полагаются на Википедию (даже если они не должны этого делать ), неправильная дата рождения может привести к цитогенезу, что затрудняет поиск правды в будущем. {{u | Sdkb }}  ^talk 19:15, 15 марта 2021 г. (UTC)

• Мысль: раз уж субъект живая, почему бы не спросить ее? Да, она могла солгать об этом факте (некоторые лгали, см., Например, Энн Коултер и другие материалы в архивах разговоров этого человека), но по большей части я бы доверял любому человеку в таких основных фактах, если нет другого источника для для них: дата рождения, место учебы в школе, имена членов семьи (т.е. супруга, родители, дети). Если человек лжет, значит, дезинформация касается этого человека, а не нас. И если они отказываются делиться этой информацией, мы используем самую лучшую информацию, которая у нас есть. Да, в будущем может возникнуть проблема с тем, чтобы полагаться на кого-то в отношении таких основных фактов, но если это подтверждается косвенными доказательствами и соответствует здравому смыслу, это не будет серьезно ошибаться. - llywrch ( говорить) 21:51, 15 марта 2021 г. (UTC)
  • Или еще лучше, если у нас нет четкого источника для дня рождения, просто откажитесь от него. За редким исключением, это мелочи. Пока в статье достаточно информации, чтобы поместить тему в контекст поколений, точная дата рождения - пустяк. - Нат Гертлер ( разговор ) 21:57, 15 марта 2021 г. (UTC)
    • Это сработало бы, если бы у нас были даты, когда она училась в колледже. Я считаю, что это общедоступная информация, которую организация с радостью предоставит. - llywrch ( разговор ) 22:14, 15 марта 2021 (UTC)
      • Ни вопрос человека, ни вопрос учреждения не удовлетворяют нашу потребность в проверяемости. И то и другое является навязчивым и ненужным поиском информации, которая нам не нужна. - Нат Гертлер ( разговор ) 22:26, ​​15 марта 2021 г. (UTC)
        • Значит, навязчивость хуже, чем неверный факт? - llywrch ( разговор ) 23:33, 15 марта 2021 (UTC)
          • Исключение дня рождения, на который были высказаны ваши последние два комментария, не означает неправильного понимания фактов. Это просто что-то не включающее. - Нат Гертлер ( разговор ) 23:59, 15 марта 2021 г. (UTC)

• Спрашивать человека - не лучший вариант. Как мы можем его получить, чтобы его можно было проверить? Кроме того, этот вопрос не был о ситуации, когда «источник не существует», а о ситуации, когда несколько надежных источников противоречат друг другу или у каждого есть только «кусочек головоломки». - bender235 ( разговор ) 23:21, 15 марта 2021 (UTC)

• Получите ответ по электронной почте, сохраните копию с заголовками в Фонде, как мы это делаем сейчас с разрешениями авторских прав на фотографии. Я думаю, люди захотят, чтобы факты о них в Википедии были правильными. (И если конкретный человек не хочет, чтобы этот факт в своей биографии в Википедии, мы могли бы записать и это.) Единственная причина, по которой мы не делаем что-то подобное сейчас, - это неправильный акцент на вторичных источниках. - llywrch ( разговор ) 23:33, 15 марта 2021 (UTC)

• «[...] если данный человек не хочет, чтобы этот факт был в его биографии в Википедии»? Я помню время, когда Википедия обратилась в суд, утверждая, что мы не даем людям редакционные права на их статьи в Википедии. - bender235 ( разговорное ) 00:36, 16 марта 2021 (UTC)

• Сильно согласны, что это ужасный и неработающий стандарт для общественных деятелей. - BLZ · talk 05:22, 18 марта 2021 (UTC)

• В некоторых случаях может сработать оригинальное исследование для определения даты рождения. Тем не менее, это плохая идея для Википедии, поскольку я видел много примеров полных догадок, основанных на чем-то вроде сообщения в Твиттере с надписью «Счастливого 21-го !!!». Даты рождения без указания источника или с указанием неверных источников следует удалить. Джонуник ( разговорное ) 23:19, 15 марта 2021 (UTC)
• Я - главный сторонник добавления даты рождения на основе статьи Fortune 40 Under 40, в которой Лоренц назван известным человеком в возрасте до 40 лет. Мои рассуждения просты: из трех противоречащих друг другу источников это единственный источник, который является биографическим, Единственный источник, в котором основным субъектом является Лоренц, и поскольку «40 моложе 40 лет» является наградой на основе возраста, это единственный источник, в котором ее возраст является ключевым фактом. Два других источника посвящены совершенно не связанным между собой предметам и упоминают имя Лоренц лишь вскользь, потому что она (1) оказалась свидетельницей случайного происшествия в поезде и (2) случайно участвовала в тенденции и могла предложить свою точку зрения. и опыт для тренда. Ни один из этих двух источников сам по себе не является надежным относительно возраста Лоренца., что гораздо менее предпочтительно в этом отношении. Есть причина доверять источнику Fortune как точному, но нет причин доверять кому-либо из двух других по сравнению с Fortune здесь. Я думаю, что важно не просто задавать поверхностный вопрос «предоставляют ли эти источники разную информацию?» и оставить его в нерешительности, потому что мы должны также спросить «есть хорошая причина доверия одного источника над другим для этой части информации ?» Никто из участников обсуждения не назвал причину, по которой анонимная статья CBS News моглабудь единственным, кто понял это правильно, потому что в это никто всерьез не верит; Нет ни малейшего доказательства, чтобы предположить, что анонимный репортер новостей, работающий в крайний срок, чтобы опубликовать историю о громком звуке в поезде, на самом деле исследовал возраст Лоренца и нашел правильный ответ, ответ, который позже ускользнул от репортера Fortune, чья основная задача определяла ее возраст. Несоответствие возрастов в источниках - в лучшем случае любопытная сноска. В противном случае статью о поезде даже не стоило бы цитировать, если только кто-то не хочет работать «Лоренц однажды услышала громкий звук в поезде» в своей энциклопедической биографии. - BLZ · talk 02:54, 16 марта 2021 (UTC)

  Если бы нам пришлось выбирать только одну ссылку, я не уверен, что выбрал бы Fortune, а не NYTimes. Я часто задавался вопросом, сколько времени Fortune проверяет свои списки, по сравнению с тем, что каждый человек отправляет информацию для кратких биографий, которые появляются вместе со списками. Тем не менее, выбор одного качественного рефери над другим редко бывает хорошей стратегией.

  Вот ссылка CBN News: сотрудники CBS News (1 февраля 2016 г.). «Крики« Боже мой! »Слышны на движущемся поезде Amtrak» . CBS News . Проверено 6 марта 2021 года . CS1 maint: discouraged parameter (link)- Хипал ( разговор ) 03:48, 16 марта 2021 г. (UTC)

• Хорошо, давайте поговорим о статье в New York Times : «Эти компании действительно, действительно, действительно хотят заморозить ваши яйца» (29 августа 2018 г.). Является ли Тейлор Лоренц основным предметом этой статьи? Нет; это о тенденциях в криоконсервации ооцитов(в просторечии «замораживать яйца»). Лоренц цитируется за ее точку зрения и опыт женщины, которая заморозила несколько своих яиц. Я не сомневаюсь, что ее точка зрения и опыт верны и даже интересны, но она не является экспертом в этой области, а просто тем, кто может рассказать о своем собственном анекдотическом опыте и послужить примером, иллюстрирующим (предполагаемую) тенденцию среди «амбициозных, амбициозных, амбициозных и амбициозных». сосредоточенные и сверхорганизованные миллениалы ". Лоренц появляется всего в двух абзацах - 27-м и 28-м абзацах статьи из 40 абзацев. Нью - Йорк ТаймсВ статье были внесены два последующих редакционных исправления: одна ошибка заключалась в неправильной атрибуции экспертного источника, другая - в неверном указании местоположения клиники, описанной в статье. Обе эти ошибки намного ближе затрагивают суть того, о чем якобы идет речь; это не о Лоренц и не о ее возрасте.
  Я хочу подчеркнуть , что я не , в любом случае, говоря « Фортуна всегда и во всех случаях категорически более надежным источником , чем Нью - Йорк Таймс и должно быть предпочтительным во всех случаях , когда существует несоответствие между двумя источниками». Я просто говорю, что для этого факта в данном контексте у нас есть только один источник, в котором ее возраст является центральным фактом. - BLZ · talk 06:40, 17 марта 2021 (UTC)

WP: BLPPRIVACY говорит: «Википедия включает [...] даты рождения, которые были широко опубликованы надежными источниками или источниками, связанными с субъектом, так что можно разумно сделать вывод, что субъект не возражает против обнародования подробностей. . Если субъект жалуется на то, что мы указали дату его рождения, или если человек является погранично заметным, сделайте ошибку в сторону осторожности [...] ". Если у нас есть только несколько источников, и они непоследовательны, и ни один из них не предназначен для всей даты рождения, так что мы должны оба оценивать один из источников как более надежный, чем другой для года, а затем комбинировать это с другим источником в течение дня (считаем ли мы это неприемлемым WP: SYNTHing или приемлемым WP: CALCing), он явно не "широко опубликован из надежных источников". Как предлагает Нат Гертлер, просто опустите его, чтобы найти лучший источник. -sche ( разговор ) 07:32, 16 марта 2021 (UTC)

Рискуя ошибиться , WP: BLPPRIVACY - одна из самых бесполезных политик, которые у нас есть. Я предпринял несколько попыток удалить или, по крайней мере, изменить его , именно из-за такой загадочной терминологии, как «пограничная значимость» (где это определяется? Разумеется, нигде на WP: NBIO ) или «широко опубликовано» (что широко публикуется на в Интернете? WP: PUBLISHED не помогает), но, как я уже сказал, это выходит за рамки данной дискуссии. - bender235 ( разговор ) 17:15, 16 марта 2021 (UTC)

Тем не менее, он по-прежнему является частью Википедии: Биографии живых людей , что является основополагающей политикой, которой необходимо следовать. Несмотря на настойчивые требования, BLP и его подразделы остаются в силе до тех пор, пока они не будут удалены / отменены посредством успешного RfC. На основании обсуждения, которое вы связали, попытка была закрыта ; как мы знаем, закрытие снега означает по определению, что у него был "шанс снежного кома в аду быть принятым". Попытка понять, что означало бы «широко опубликованные»: это, как минимум, означало бы «несколько» (надежных) источников, заявляющих одно и то же. В настоящее время у нас этого нет, согласно имеющимся / обнаруженным на данный момент ссылкам. Это обсуждение не место, чтобы спорить / обсуждать отмену - полностью или частично - политики. Для этого нужен отдельный RfC, работающий отдельно. - The SandDoctor ^Talk 16:06, 26 марта 2021 г. (UTC)

@ TheSandDoctor : WP: DOB был добавлен в первые дни существования Википедии без каких-либо обсуждений, и с тех пор это вызвало проблемы. Триггером для RfC 2019 года стала статья Брыны Кра , где явно существует надежный источник ее DOB, но WP: DOB злоупотребляли, чтобы утверждать, что Википедисты должны требовать конфиденциальности от имени Kra без ее просьбы. . Этот абсурдный театр приватности стал возможен только из-за двусмысленного языка WP: DOB (WP: RS недостаточно, он также должен быть «широко опубликован»; и «пограничные WP: NBIO» в любом случае не подпадают под действие по причинам), которые Я пытался удалить в этом RfC 2019 года. Итог: DOB ничем не отличаютсячем любой другой биографический факт (название средней школы, имя родителей, год выпуска и т. д.) и, как таковой, должен соответствовать тем же стандартам, что и они (например, WP: RS). Не больше, не меньше. Вместо этого WP: DOB объединяет даты рождения вместе с «телефонными номерами, адресами, номерами счетов», как если бы любой из последних даже отдаленно имел какое-либо энциклопедическое значение.

Тем не менее, заканчивая это касательное и возвращая его к Тейлору Лоренцу: если вы спорите на основе WP: DOB, вы, по сути, должны заявить, что журнал Fortune опубликовал ее возраст без ведома и согласия Лоренца. Потому что это то, что гласит политика: вы должны сделать вывод, что субъект возражает против того, чтобы ее DOB был «опубликован» в Википедии (несмотря на то, что он был опубликован в другом месте). И удачи в попытках сопоставить аргумент «мы можем сделать вывод о проблемах конфиденциальности человека» с аргументом «мы не должны делать вывод о годе рождения по возрасту на дату». (Я саркастичен, чтобы продемонстрировать абсурдность WP: DOB). - bender235 ( разговор ) 17:38, 26 марта 2021 (UTC)

Если технически это еще не было частью политики биографии живых людей (BLP), то теперь это связано с тем RfC, который вы цитируете. РФК эффективно рассматривает любые исторические дискуссии или прецеденты, которые можно было бы назвать спорными. Вообще говоря (в отрывке из этого обсуждения), цитирование RfC, у которого есть один результат, в качестве оправдания для действий, прямо противоположных этому результату, не соответствует консенсусу (по духу или по иному). Игнорирование консенсуса потенциально может рассматриваться как подрывное поведение. IARне освобождает редакторов от последнего и не может использоваться буквально для противодействия результату RfC (который не был заменен) только потому, что редактору не нравится его результат. Правильный способ изменить политику / руководство - это успешно пройти новый RFC (желательно, посвященный исключительно этому вопросу). Эта ветка не подходит для этого обсуждения; Обсуждение в Википедии: Биографии живых людей , вероятно, были бы лучшим местом встречи, с самим VPP и WP: BLPN в качестве альтернативы (все перекрестно рекламируются тем, кто не является хозяином, конечно).

Если вдаваться в это исторически, то выясняется, что раздел о днях рождения действительно присутствовал (в форме), когда BLP был повышен с руководства до политики в июле 2006 года. С учетом сказанного, конфиденциальность была ключевым соображением на странице BLP с декабря 2005 год, когда это все еще было предложено, но не действовало. - The SandDoctor ^Talk 03:58, 28 марта 2021 г. (UTC)

Я определенно заинтересован в том, чтобы дата рождения была точной и получена из высококачественных RS, поскольку это действительно имеет аспекты, связанные с конфиденциальностью. (например, меня постоянно спрашивают о дне рождения, когда я обращаюсь к медицинским работникам для подтверждения личности). Но я бы разумно сказать , что рождение год и / или возраст человека или оценить его может иметь более слабые требования сорсинга, до тех пор , пока есть еще какая - то надежность участвует. За исключением некоторых ситуаций, возраст кого-то гораздо менее важен для конфиденциальности, и большинство людей может догадаться +/- 5 лет, просто взглянув на фотографию человека, поэтому это не то, что вы легко замаскируете. - M asem ( t ) 15:01, 16 марта 2021 г. (UTC)

• Мелочи, если они не получены из надежных источников, не добавляйте их. Акусмана ( разговор ) 16:53, 16 марта 2021 (UTC)

Я согласен с вами, что WP: RS - это порог для включения любой информации, но дата рождения - не пустяк. Не больше, чем отчество человека или старшую школу, в которой он учился. - bender235 ( разговор ) 17:17, 16 марта 2021 (UTC)

извините, в случае с BLP, и в частности с мусором из культуры знаменитостей, есть навязчивая идея о возрасте, росте, размерах тела и т. д., все это относится к пустякам. Возможно, в этом тоже есть намек на эйджизм. Акусмана ( разговор ) 10:39, 17 марта 2021 (UTC)

• Я бы сказал, что если есть противоречие между датами, ни один из них, очевидно, не является явно лучшим источником, и ни один источник не отмечает конфликт, мы должны полностью отказаться от него. Выбор любого из них был бы неприемлемым по очевидным причинам; Прикрытие разногласий в данном случае является проблемой, потому что мы, по сути, сами «создаем» конфликт. То есть, если ни один источник не отмечает конфликт, но мы указываем в статье «источники различаются», мы, по сути, вводим эту концепцию, что есть путаница или разногласия по поводу даты рождения субъекта целиком - на практике это WP: ИЛИ / WP: СИНТ . Мягкая форма его, да, но я не уверен , что это просто WP:CALC / WP: СИНИЙДело в том, что прямое заявление о разногласиях превращает то, что могло быть простой опечаткой в ​​одном источнике, в более серьезный конфликт. Если это что-то, что нам не нужно сразу взвешивать и где в конечном итоге есть один правильный ответ, лучше подождать, пока мы не сможем сформулировать правильный ответ с большей уверенностью. - Аквиллион ( разговор ) 17:11, 16 марта 2021 (UTC)

@ Aquillion :: Я упомянул вверху, что речь идет не только о Тейлоре Лоренсе, потому что в прошлом было много подобных случаев. И поэтому, чтобы быть ясным, в случае противоречивых источников, вы бы предпочли полностью исключить DOB или обработать его, как в случае с Верноном Джарреттом , где мы с Лвальтом выносили суждение (см. Обсуждение: Вернон Джарретт ), в статью добавлена ​​сноска с упоминанием конфликтующих источников. На мой взгляд, это было бы правильным решением и в случае Лоренца. Вы согласны? - bender235 ( разговор ) 01:24, 18 марта 2021 (UTC)

Несколько участников дискуссии просили (или сетовали на отсутствие) прямого параллельного сравнения трех рассматриваемых источников. Я хочу изложить это как можно проще:

Я также хочу согласиться с Аквиллионом , который очень проницательно указал на то, что утверждение о том, что возраст Лоренца каким-то образом объективно «оспаривается», является («мягкой» и, возможно, приемлемой) формой WP: SYNTH . Дело в том, что в реальном мире у Лоренца есть установленная дата рождения. Ни один из достоверных источников не указывает на этот «спор». (В этой статье в The Washington Free Beacon от декабря 2020 года отмечается несоответствие между источниками, но я бы не стал утверждать, что Free Beacon в целом надежен и независимо от того, что статья помечена в разделе «сатира» (?) Сайта - сделайте из этого что ты будешь.)

В этой связи бросается в глаза то, что никто не утверждает, что «история CBS, скорее всего, была правильной по [причинам], что делает две другие ошибочными» или « история New York Times, скорее всего, была правильно на основе [причин], делая два других неправильными ". Две стороны этого обсуждения - « Фортунаистория, скорее всего, была правильной на основе [причин], что делает два других ошибочными »или« тот факт, что в целом достоверные источники различаются, означает, что возраст Лоренц неизвестен (и поэтому в принципе она могла быть старше или моложе, чем указано в любой из трех источников) ». Другими словами, аргумент таков:« если все три «надежны», но различаются, то ни один из них не является надежным ». Это не имеет смысла, особенно когда на самом деле никто не ручается за контекстно-зависимые причины предпочесть статью CBS или статью New York Times , за исключением того, что они полагаются на их общую надежность как институтов (что я совершенно не оспариваю; CBS и NYT - прекрасные источники в целом). - BLZ · talk 07:47, 17 марта 2021 г. (UTC)

почему это так важно, когда родился этот «американский репортер по культуре и технологиям»? это пух. Акусмана ( разговор ) 10:43, 17 марта 2021 (UTC)

Если дата рождения (этого человека или любого другого) пустяковая, то что нет? Определяет ли это ее как личность, или ее роль в истории, или ее известность для Википедии? Возможно нет. Но и ее диплом о высшем образовании, и какие социальные сети она использовала в свои 20 лет. Пытаюсь взглянуть на все эти лакомые кусочки биографии и спросить: « Неужели это имеет значение?» это все равно что смотреть на карту США и спрашивать: «А где сейчас экономика?» Это все актуально. - bender235 ( разговор ) 01:12, 18 марта 2021 (UTC)

Я сам не могу увидеть возраст в статье Fortune, но если предположить, что он такой же, как и два других, и просто дает возраст на дату, то это дает вам диапазон: (ср: {{ Рождение на основе возраста как даты }}

• 30 февраля 2016 г .: родился в 1985/86 г.
• 29 августа 2018 г., 31 год: 1986/1987 г.р.
• 02.09.2020 35 лет: родился 1984/1985

Это все еще оставляет несоответствие, но возможно ли, что у нее был день рождения между интервью и публикацией одной из этих статей? Очень маловероятно для источника CBS, учитывая характер истории, но для двух других это правдоподобно в абстракции. Однако, если день рождения 31 октября правильный, то это маловероятно, так как между интервью и публикацией должен пройти почти год, учитывая даты произведений - не невозможно, но маловероятно. Не исключено, что одна из них была опубликована на пару месяцев раньше, чем предполагалось, или это может быть просто опечатка - кто из взрослых потрудится исправить статью, в которой говорится, что вы на год моложе, чем вы есть на самом деле? Однако насколько надежна дата 31 октября? Политика описана в WP: RSPкак «надежный для американской политики», но г-жа Лоренц, похоже, не участвует в политике. В общем, я бы сказал, оставьте это в стороне, поскольку нет очевидного способа получить точную цифру без оригинального исследования. Если это действительно необходимо, скажите «родился около 1984–1987 годов»). Тридуульф ( разговор ) 13:00, 17 марта 2021 (UTC)

Я согласен с Тридюльфом и Аквиллионом . Аргумент ( ссылка ) в пользу выбора Фортуны среди других, потому что публикация "безусловно [самая] заслуживающая доверия" и поскольку она дает самый старый возраст, буквально основан на личном мнении и оригинальном исследовании , поскольку говорится, что она солгала (сама по себе необоснованное обвинение и ИЛИ на данном этапе), а затем поместите его версию в статью. (Остальное обоснование для одностороннего восстановления возрастного содержания также проблематично, поскольку я сломался на Talk: Taylor Lorenz # Birthdate(с которого началась эта ветка). То, что Тридулф указал на Политику в RSP и где она надежна, также вызывает у меня новую озабоченность тем, что она используется за пределами его текущей определенной области.

Однако я согласен с тем, что линия, расположенная в Taylor Lorenz # Личная жизнь о том, что она была свидетелем убийства, - это WP: TRIVIA . Тем не менее, источник CBS не следует сбрасывать со счетов, когда речь идет об этом обсуждении и о проблемах, связанных с возрастом. У нас просто нет реального способа на основе надежных источников определить ее возраст в настоящее время. Как уже упоминалось ранее в этой теме, заглядывая в будущее, мы также должны помнить о цитогенезе . - The SandDoctor ^Talk 14:55, 17 марта 2021 г. (UTC)

@ Thryduulf : Politico сообщает о дне рождения Тейлора Лоренца 21 октября каждый год с 2016 года ; вот 2017 , 2018 , 2019 , 2020 и снова 2020 . Политико освещает внутренние дела медиа-бизнеса (особенно в округе Колумбия, Нью-Йорк и вдоль Северо-восточного коридора ) и предлагает предположить, что эта тема каким-то образом выходит за рамки их надежности, или даже что бизнес журналистики как-то совершенно оторванный от темы «политика», кажется мне абсурдным.

@ TheSandDoctor : Ты возвращаешься к тому, что я предположил, что Лоренц солгал. Я признаю, что, возможно, это было со мной жестоко, но, как я уже сказал, это совсем не главное в моих аргументах. Я не собираюсь доказывать, что Лоренц лгал, и мне не нужно этого делать. Несоответствие в сообщениях можно так же легко объяснить, как опечатку или путаницу в заметках, и, в конечном счете, что бы ни случилось, это все равно не имеет значения. На самом деле мы не знаем, почему были указаны разные возрасты, они просто были. Я просто предложил правдоподобное объяснение, учитывая, что Лоренц почти наверняка единственный человек, которого они бы спросили о ее возрасте для тех историй, которые - в конце концов - не оЛоренц в любом значительном смысле. Лично меня не волнует, солгала Лоренц о ее возрасте или нет, и даже если она это сделала, честно говоря, это было полезно для нее, я отмечаю это. У меня действительно нет никакого анти-Лоренцевского топора, который я мог бы здесь заткнуть.

Но мой вопрос, опять же, таков: почему мы должны доверять истории CBS News или New York Times, а не истории Fortune ? Обратите внимание: речь идет не о публикациях , поскольку все мы согласны с тем, что все эти три публикации являются надежными, но как насчет этих трех историй . Есть ли какие-либо указания на то, что этот факт существует исключительно в историях CBS или NYT , но не в журнале Fortune?сказка? Ответ кажется отрицательным, поэтому вместо этого аргумент сводится к следующему: «два обычно надежных источника ошиблись в этом факте на полях, сообщая по другим вопросам, поэтому самый последний и единственный фактически биографический источник также должен ошибаться в этом факте». Это не имеет никакого смысла. - BLZ · talk 05:22, 18 марта 2021 (UTC)

Пример того, что мы сделали в похожей ситуации после нескольких RFC, можно увидеть у Джоан Кроуфорд. - Moxy - 05:10, 18 марта 2021 г. (UTC)

Есть некоторые фундаментальные отличия от ситуации с Кроуфордом, в первую очередь то, что в случае Кроуфорда у нас есть стороннее освещение неопределенности даты; эта неопределенность становится частью истории. Дело не только в том, что мы, википуддисты, находим противоречивые источники. (Кроме того, в последний раз, когда я проверял, мисс Кроуфорд оставалась вне зоны действия BLP, хотя за последний год произошло столько странных вещей, что я, возможно, пропустил некоторые новости по этому поводу.) - Нэт Гертлер ( разговор ) 12:54 , 18 марта 2021 г. (UTC)

• Я просто хотел бы добавить, что Викиданные делают вид, что знают день рождения Тейлора Лоренца, и просто говорят «21 октября 1984» без указания на синтез ( d: Q89135464 ). Но Викиданные прекрасно представляют гипотезу как факт (мой любимый - d: Q55072099 ). - Кусма ( t · c ) 16:23, 26 марта 2021 г. (UTC)

  @ Kusma : Это было добавлено первоначальным сторонником этой даты / года в этом обсуждении, Брандтом Люком Цорном. - The SandDoctor ^Talk 16:42, 26 марта 2021 г. (UTC)

  TheSandDoctor , и теперь я его удалил. Лучше не выдвигать домыслы за факт. ( Хотя я не знаю, что делать с Б. Травеном , поэтому я сохраню это как пример отсутствия тонкости в Викиданных). - Кусма ( t · c ) 16:48, 26 марта 2021 г. (UTC)

  @ Kusma : Я согласен с тем, что предположение как факт проблематично. Что меня беспокоит, так это то, что оспариваемая информация была повторно добавлена, и мой откат был отменен, цитируя это обсуждение как мертвое и игнорируя направление, в котором оно, по-видимому, идет. - The SandDoctor ^Talk 16:51, 26 марта 2021 г. (UTC)

  @ Kusma : удаление информации не является правильным решением. В Викиданных не зря есть квалификаторы . - bender235 ( разговор ) 16:53, 26 марта 2021 (UTC)

  Bender235 , это здорово. Я не знал об этом. Я по-прежнему считаю, что лучше удалить потенциально неточные данные, чем хранить их в неквалифицированном виде, но я не возражаю предоставить наилучшие доступные данные, если мы заявляем, что в этом могут быть сомнения. (Таким образом, мое добавление "вероятно" в информационное окно здесь). - Кусма ( t · c ) 17:00, 26 марта 2021 г. (UTC)

  @ Kusma : в целом я за сохранение всей информации (вместе с определителями того, как они противоречат друг другу), а не никакой информации. И в Викиданных, и здесь, в Википедии. - bender235 ( разговор ) 17:05, 26 марта 2021 (UTC)

  Bender235 , Викиданные сейчас говорят "возможно". Если вы знаете квалификатор получше, во что бы то ни стало измените его. - Кусма ( t · c ) 17:49, 26 марта 2021 г. (UTC)

  ( редактировать конфликт ) Однако серьезная проблема, по крайней мере здесь, в Википедии, заключается в том, чтобы представить один из них как факт для читателя, включив его в информационное окно и предоставив, не квалифицируя его как не более чем предположение (которое Кусма теперь частично решило) . Когда источники совершенно противоречат подобной информации, хотя она не публикуется широко, ее, вероятно, не следует выставлять на видном месте, если она вообще включена. Нам нужно сделать это правильно , а не синтезировать противоречивые отчеты и решить, что один из них явно «правильный», если RS также не заметит проблему и не сделает это определение. Личное мнение и оригинальные исследования не относятся к статьям Википедии или как оправдание для включения таких материалов. - The SandDoctor ^Talk 17:50, 26 марта 2021 г. (UTC)

  DOB (или любой другой биографический факт в этом отношении) не представляется как факт, если есть заметная сноска (или другой комментарий), объясняющая расхождения. Показательный пример: в статье Фреда Трампа упоминается тот факт, что существуют противоречивые источники о его происхождении: некоторые RS утверждали, что они были немцами, другие (включая его самого) утверждали, что они были шведами. По вашей логике это противоречие RS подразумевает, что мы не можем включить ни то, ни другое, тогда как обычная практика в Википедии до сих пор заключалась в том, чтобы включать оба (или все), и комментировать правдивость и т. Д. - bender235 ( разговор ) 18:06, 26 марта 2021 (UTC)

  Да, но в этом есть диапазон . Здесь пропагандируется включение единой даты / года в body / lede. Вот что было восстановлено. - The SandDoctor ^Talk 18:42, 26 марта 2021 г. (UTC)

• Это не может быть прецедентом, как было указано в резюме этого редактирования вопроса RfC, если не будет достигнут консенсус; два редактора, согласные друг с другом, также не являются широко распространенным консенсусом, ведущим к прецеденту, равно как и мнение одного редактора само по себе не является прецедентом. Переходя к тому, что было заявлено, хотя в связанном обсуждении bender, в отличие от того, что bender указано выше, Jayron32 предлагает два возможных решения: включить все в начале или ничего вообще в статье. Оба этих решения не являются тем, что здесь пропагандируется / с чего началось это обсуждение, а именно включение одной даты / года как единственно правильного из-за личного мнения ,домыслы и оригинальные исследования . (Стоит отметить, что и личное мнение, и предположения буквально являются WP: НЕТ .) Я был бы в порядке, если бы все три были упомянуты / процитированы в начале или, как заявил Jayron32 в то время, ни одного (то есть, как это происходит в настоящий момент / отметка времени написания этого комментария). - The SandDoctor ^Talk 18:09, 27 марта 2021 г. (UTC)
• Я действительно не понимаю, почему это такой спорный вопрос, который требует столь долгого обсуждения. Конечно, мы должны просто сказать то, что поддается проверке. Если дата рождения согласована между надежными источниками, то мы должны указать ее в первую очередь. Если это не согласовано, мы не должны говорить об этом там. Если есть надежные источники, сообщающие о разногласиях, мы должны сказать об этом, но если нет, мы не можем пойти дальше того, чтобы сказать, что достоверные источники не согласны. Разве это не просто базовая проверяемость , которой должны следовать все правки? Фил Бриджер ( разговор ) 18:22, 27 марта 2021 (UTC)

  @ Фил Бриджер : это то, о чем я все время говорил. РГ: МНООН также применяется. Нет двух источников, содержащих одинаковую информацию о году ее рождения, и ни один источник, который я нашел, не упомянул об этом разногласии между другими источниками. Несмотря на это, некоторые другие здесь, похоже, думают иначе, желая выбрать один как правильный и продолжая добавлять его в статью, несмотря на продолжающееся обсуждение. - The SandDoctor ^Talk 18:48, 27 марта 2021 г. (UTC)

Опять же, вспомните прецедент Вернона Джарретта : существуют противоречивые (надежные!) Источники, и ни один из них «не упомянул о разногласиях», поэтому требовалось решение; и это было основано не на количестве источников, приводящих одну дату, а на наиболее вероятной. РГ: СИНТЕЗ не требует, чтобы мы были безмозглыми зомби, неспособными решить, какой источник более надежен, чем другой. Фактически, WP: RSCONTEXT указывает, что взвешивание RS и оценка того, «насколько оно достоверно для утверждения, сделанного в статье в Википедии», в значительной степени точно так же, как Брандт Люк Цорн сделал в таблице выше, - это именно то , что мы должны делать. - bender235 ( обсуждение) 22:19, 27 марта 2021 г. (UTC)

Два редактора не могут прийти к единому мнению, не говоря уже об особенно убедительном прецеденте. Вернон Джарретт не подпадает под BLP и, следовательно, имеет другие стандарты, которым необходимо соответствовать; с учетом сказанного, статья Джарретта также имеет диапазон дат / года, включенный в lede, что не является тем, что неоднократно восстанавливалось вами и Брандтом Люком Цорном. Как я уже говорил ранее в этом обсуждении, я был бы счастлив пойти на компромисс с диапазоном дат в lede и примечании. Тем не менее, это означает , что вы защищаете за это вводит в заблуждение , когда, по той же причине, вы восстановили обратно два разав пользу единственной даты (той самой, с которой началось обсуждение ТП Лоренца и этой) во время этого обсуждения. Несмотря на то, что это игнорировалось продолжающимся здесь обсуждением и ответственностью за достижение консенсуса, предоставленной WP: ONUS , это также не соответствовало конечному / фактическому результату обсуждения Джарретта, которое вы процитировали здесь и в сводке редактирования. - The SandDoctor ^Talk, 02:55, 28 марта 2021 г. (UTC)

В какой-то момент я вынужден поверить в то, что вы постоянно искажаете мою позицию. Я уже несколько раз писал, что предпочел бы, чтобы наиболее правдоподобная дата была указана в первом абзаце, плюс сноска (как у Вернона Джарретта ), указывающая на существование противоречивых источников. - bender235 ( разговор ) 14:46, 28 марта 2021 (UTC)

@ Bender235 : В этом обсуждении (или любом другом, о котором я знаю) явно нет единого мнения о том, что какой-либо один источник для единственной даты более надежен, чем любой другой. Поэтому любое использование единственной даты в статье неуместно WP: OR и / или WP: SYNTH . Тридуульф ( разговор ) 11:14, 28 марта 2021 (UTC)

Я думаю, мы все можем согласиться с тем, что один из The New York Times не так высокого качества, как два других, и когда есть источники получше, мы должны их использовать. К сожалению, в этом случае они противоречат друг другу. Эмир Википедии ( разговор ) 14:36, 28 марта 2021 (UTC)

@ Эмир из Википедии : Я не уверен, что мы все можем с этим согласиться. У нас есть три источника, все из которых не согласны без каких-либо внешних указаний на точность или неточность любого из них в отношении этого конкретного факта. Любое утверждение о том, что одна из этих дат более или менее надежна, чем другие, не может быть более надежным, чем наше собственное исследование. Тридуульф ( разговор ) 18:03, 28 марта 2021 (UTC)

Я не совсем понимаю, что вы имеете в виду. Есть таблица, сравнивающая расположенные рядом источники. Эмир Википедии ( разговор ) 19:01, 28 марта 2021 (UTC)

Мнения одного википедиста, основанные на оригинальных исследованиях (их и / или других википедистов), которые представлены в таблице, не являются внешним признаком точности или неточности любого из этих источников в отношении даты рождения. Отмечается, что две существенные ошибки в статье NYT были исправлены, но не уточняется, что это за факты и имеют ли они какое-либо отношение к дате рождения. Это также означает, что по статье был проведен как минимум еще один раунд проверки фактов, и если это так, это может сделать ее наиболее надежной для других содержащихся в ней фактов - а может и нет. Дело в том, что у нас нет возможности узнать. Тридуульф ( разговор ) 21:27, 28 марта 2021 (UTC)

@ Thryduulf : Вы хоть раз смотрели Talk: Vernon_Jarrett # Date_of_birth ? Как вы думаете, было принято неправильное решение? Если да, то какой из них лучше? - bender235 ( разговор ) 14:46, 28 марта 2021 (UTC)

Что касается Вернона Джарретта, кажется, что дата 19 июня явно поддерживается, так что это не проблема. Я бы сказал что-то вроде «около 1917-1919 (источники различаются), 1921 год в некоторых источниках, вероятно, ошибочен». В этом обсуждении была задействована целая куча оригинальных исследований и первоисточников, и мы никогда не должны рассматривать результаты это более надежно, чем вторичные источники. Тридуульф ( разговор ) 17:59, 28 марта 2021 (UTC)

RfC: Атрибуция при копировании в Википедии

Копирование в Википедии: следует ли разрешить гиперссылку?

Википедия: Копирование в Википедии # Гиперссылка говорит:

"Заявление в сводке редактирования, такое как скопированный контент из имени страницы ; просмотр истории этой страницы для атрибуции направит заинтересованные стороны к истории редактирования исходной страницы, где они могут точно отследить, кто и какой контент добавил. Недостаток этого метода состоит в том, что история страниц исходной статьи должна впоследствии сохраняться для сохранения атрибуции ".

Хотим ли мы считать это правильной атрибуцией? - Гай Мейкон ( разговор ) 16:57, 21 марта 2021 (UTC)

• Нет: как сторонник. На мой взгляд, это создает фугас авторских прав. Требовать, чтобы страница никогда не удалялась из-за того, что кто-то сделал копию, неразумно. Было бы слишком легко пропустить одну сводку редактирования, которая делает страницу недоступной для удаления, и все равно удалить ее, тем самым создавая непреднамеренное нарушение авторских прав. Если сделать страницу недоступной для удаления, может злоупотребить кто-то, кто возражает против удаления. - Гай Мейкон ( разговор ) 16:57, 21 марта 2021 (UTC)
• Да . Это один из трех методов атрибуции, явно разрешенных в Условиях использования . Я думаю, что мы можем доверять WMF Legal в их интерпретации лицензии. -  Finnusertop ( обсуждение ⋅ вклад ) 17:14, 21 марта 2021 г. (UTC)
  • Нет, это не так. На этой странице написано «гиперссылка (где возможно) или URL-адрес страницы или страниц, которые вы повторно используете» (наряду с двумя другими способами сделать это). Гиперссылка на страницу, которая больше не существует, не соответствует требованиям. Если вы разрешаете атрибуцию гиперссылки, вы должны сделать страницу, на которую вы ссылаетесь, недоступной для удаления. - Гай Мейкон ( разговор ) 17:49, 21 марта 2021 г. (UTC)
    • Я просто не уверен, что это проблема, пока вы не получите ответ от юридической службы WMF. -  Finnusertop ( обсуждение ⋅ вклад ) 18:53, 21 марта 2021 г. (UTC)
• Да . Как указывает Finnusertop, включение ссылки на исходную страницу источника является одним из трех явно упомянутых методов атрибуции, разрешенных в соответствии с нашей правовой политикой. Как упоминает ProcrastinatingReader ниже, если вы обоснованно обеспокоены тем, что исходная страница может быть удалена в какой-то момент в будущем, вы можете добавить {{ Copied}} на страницу обсуждения исходной страницы, чтобы проинформировать удаляющих администраторов о проблеме авторских прав. В случае, если кто-то использует эту стратегию для игры в систему, чтобы сделать страницу, которую следует удалить, невозможно удалить, ситуацию можно исправить, переместив страницу из основного пространства, например, на подстраницу страницы обсуждения целевой статьи, а затем обновив атрибуция соответственно. На практике это кажется проблемой очень редко, и я хотел бы увидеть доказательства того, что это действительно повторяющаяся проблема, прежде чем рассматривать изменение наших руководящих принципов здесь, а также жизнеспособное альтернативное решение, выходящее за рамки идеи "списка авторов". . Mz7 ( разговор ) 17:24, 21 марта 2021 (UTC)
  • Ссылка на исходную исходную страницу или ссылку на отсутствующую страницу, на которой была исходная исходная страница до того, как она была удалена годом позже? - Гай Мейкон ( разговор ) 17:49, 21 марта 2021 г. (UTC)

    Если бы страницу удалили, это, конечно, было бы проблематично, но ситуация не была бы непоправимой: мы можем просто отменить удаление страницы и переместить ее в непонятное место, а затем добавить новое фиктивное редактирование с резюме редактирования, которое ссылается на новое расположение истории страницы. Если бы нам пришлось делать это постоянно, то, возможно, я мог бы поддержать какую-то реформу процесса, но в нынешнем виде я сомневаюсь, что этот сценарий повторяется чаще, чем пару раз в год. Mz7 ( разговорное ) 19:22, 21 марта 2021 (UTC)

    И просто чтобы добавить к этому, я не предлагаю это на пустом месте. Этот процесс восстановления задокументирован в Википедии: Руководство администратора / Исправление перемещений вырезания и вставки # Параллельные версии : иногда это делается путем перемещения истории страницы на подстраницу страницы обсуждения целевой страницы. Пример можно найти в Talk: Compilation of Final Fantasy VII # Old page history . Mz7 ( разговорное ) 19:29, 21 марта 2021 (UTC)

• Да . Это уже разрешено и рекомендовано политикой защиты авторских прав . Альтернатива - отслеживание и составление списка авторов - часто бывает непрактичной. Самая большая проблема заключается не в том, что исходные страницы удаляются, а в том, что редакторы никаким образом не указывают авторство при копировании, и от этого не будет ничего лучше, если мы сделаем требуемый процесс более обременительным.
  Что касается сохранения историй - это делается не только для атрибуции, но и в любом случае это лучшая практика. Я действительно не вижу проблем с "не удаляемыми". Если исходную страницу необходимо удалить по какой-либо причине, ее историю следует просто сохранить с перенаправлением , возможно, под другим заголовком. Здесь нет никакой пользы от удаления. Если в некоторых исключительных обстоятельствах страницу действительно нужно удалить, то удаляющий администратор может извлечь список авторов и отметить его на целевой странице; во всех остальных случаях нет необходимости принудительно выполнять это действие. - Уанфала (разговорное) 22:50, 21 марта 2021 г. (UTC)
• Что ж, я был бы разочарован тем, что удаление администраторов не знает, что это значит и что происходит, когда они удаляют историю страниц. Думаю, я очень рано осознавал, что происходит при удалении при стирании истории. Разве кто-нибудь не написал инструкции для админов о сохранении истории, когда это необходимо? - Аланскоттуокер ( разговор ) 23:44, 21 марта 2021 года (UTC)
• Да , очевидно, это должно быть разрешено. Несмотря на то, что на странице политики говорится, что существует «три» метода, два из них основаны на «гиперссылках». Третий метод - перечисление каждого отдельного участника. Перечислить всех участников в сводке редактирования часто невозможно из-за ограничений на количество символов, и это всегда неудобно. Насколько я понимаю, это часто делает невозможным разделение / слияние. Уже существует шаблон для страниц обсуждения, когда существует значительная история редактирования, относящаяся к контенту на других страницах, поэтому случайное удаление на самом деле не проблема.力(power ~ enwiki, π , ν ) 00:54, 22 марта 2021 г. (UTC )
• Да нет причин менять статус-кво. Элли ( Обсуждение | вклад ) 05:40, 22 марта 2021 (UTC)
• Да для Mz7. - The SandDoctor ^Talk 16:35, 26 марта 2021 г. (UTC)

Обсуждение (указание авторства при копировании в WP)

• Исключает ли это использование ссылок oldid / diff? Я понимаю, что вас беспокоит базовое название статьи, но использование ссылок w / oldid / diff, содержащих скопированный текст, должно быть нормальным? - M asem ( t ) 17:03, 21 марта 2021 г. (UTC)
  • Это сделает исходную страницу не удаляемой? Я не уверен, работают ли различия после удаления. Сводка редактирования, такая как «Добавлено 'I like cake!', Первоначально опубликованная пользователем: Masem» вместе с различием сохранит атрибуцию, даже если различие больше не работает. - Гай Мейкон ( разговор ) 17:27, 21 марта 2021 г. (UTC)
• Как еще мы могли бы поддерживать атрибуцию при объединении статей или копировании контента? -  Джо  ( разговор ) 17:05, 21 марта 2021 г. (UTC)
  • Слияние удаляет источник без удаления истории, поэтому у нас не будет статьи, которую нельзя удалить. Короткие разделы содержания см. В моем ответе Масему. Если кто-то хочет скопировать большую страницу с большим количеством редакторов, сохранение истории для атрибуции является абсолютным требованием; в противном случае нарушается лицензия CC BY-SA 3.0. - Гай Мейкон ( разговор ) 17:28, 21 марта 2021 года (UTC)
• Во многих случаях это единственный возможный способ атрибуции. Например: копирование шаблона или другой страницы в песочницу. Я не собираюсь сидеть и копаться в истории страниц и записывать имена всех в сводке редактирования каждый раз, когда я создаю песочницу. При разделении или слиянии страниц ожидать тоже неразумно. {{ Copied }} существует, чтобы гарантировать, что страница не будет удалена. ProcrastinatingReader ( разговор ) 17:09, 21 марта 2021 (UTC)
  • Затем вы говорите, что можно сделать страницу, которую вы скопировали, не удаляемой. Сохранение истории для атрибуции - абсолютное требование; в противном случае нарушается лицензия CC BY-SA 3.0. Мне это тоже не нравится, но мы не отказываемся от соблюдения правил авторского права, когда это становится неудобно. - Гай Мейкон ( разговор ) 17:29, 21 марта 2021 г. (UTC)
    • Хорошо и хорошо, что вы говорите, что это абсолютное требование , но на самом деле это вопрос к юристам Фонда. Если они сочтут это необходимым, список редакторов, которые внесли свой вклад в удаленную статью, может быть предоставлен для соблюдения, избегая всех практических проблем, связанных с предложением. На практике эти страницы обычно хранятся как перенаправления с историей изменений.力(power ~ enwiki, π , ν ) 00:57, 22 марта 2021 г. (UTC)
• Не могли бы мы получить некоторую предысторию, например, в чем именно заключается проблема и где были предыдущие обсуждения по этой теме? Цель предложения - запретить редакторам давать ссылки или заставить их всегда предоставлять список авторов? Это может сработать, если количество участников невелико, но как отследить всех участников до раздела большой установленной статьи при ее разделении? Кроме того, список участников может быть достаточным для целей авторского права, но всегда желательно иметь актуальную историю этого контента: он показывает, как контент развивался, он позволяет в принципе увидеть, кто что написал (полезно, например, если позже выясняется, что один из участников был причастен к созданию мистификаций), и он сохраняет запись в сводках редактирования с обоснованиями для частей этого контента.
  И зачем нужно удалять исходную страницу? Его всегда можно превратить в перенаправление (а также потенциально переместить в другое название), сохранив историю, и если в этой истории есть что-то действительно гнусное, ее можно пересмотреть. А что касается непреднамеренного удаления, когда оно действительно может произойти? Копирование обычно указывается в шаблоне страницы обсуждения или иногда в сводке редактирования исходной страницы; даже если это не так, то исходная и конечная страницы почти всегда будут иметь очевидную связь, например, если одна будет перенаправлением на другую. - Уанфала (разговор) 17:23, 21 марта 2021 (UTC)
  • Re: «А зачем нужно удалять исходную страницу? Ее всегда можно превратить в перенаправление (а также потенциально переместить на другой заголовок), сохранив историю» , это не проблема. Проблема заключается в том, что вы копируете часть страницы на другую страницу, используя гиперссылку для атрибуции, а затем, спустя годы, исходная статья удаляется в AfD. Бам. Мгновенное нарушение авторских прав.

  Проблема настоящая. Одно из решений - запретить атрибуцию гиперссылки. Еще одно решение - сделать все большее количество страниц, которые невозможно удалить, - это еще одно решение (но нам понадобится какой-то способ отслеживать, какие статьи нельзя удалить). Я хотел бы услышать решение, которое лучше, чем два выше, но «Игнорировать лицензию Creative Commons Attribution-ShareAlike и намеренно нарушать авторские права, потому что это удобно» не является приемлемым решением. - Гай Мейкон ( разговор ) 17:41, 21 марта 2021 года (UTC)

  Отказ от указания ссылки на гиперссылку сам по себе не является решением; нам все еще нужен способ атрибутировать текст. Должны ли мы выгрузить авторов в список и включить его, скажем, на подстраницу соответствующей страницы обсуждения? В этом случае было бы полезно, если бы программное обеспечение предоставило дополнительную поддержку для этого. isaacl ( разговор ) 18:02, 21 марта 2021 (UTC)

  Еще одно возможное усовершенствование программного обеспечения - поддержка механизма «ссылки на историю», чтобы вы могли связать новую статью с историей любых статей-предков. Если предок был удален, программное обеспечение могло бы предоставить способ по-прежнему извлекать имена редакторов. Но еще предстоит сделать кое-что еще, пока работа с новыми функциями не будет запланирована, запланирована, реализована, протестирована и доставлена ​​(если это когда-либо произойдет). isaacl ( разговор ) 18:06, 21 марта 2021 (UTC)

  Поскольку Гай не ответил, это явно связано с темами DRV, обсуждаемыми на WP: AN # Обзор суперволосов DRV от King of Hearts . Изно ( разговор ) 18:27, 21 марта 2021 (UTC)

  Вы можете подумать, что это «явно связано», но я не знал об этом до сих пор. Это не имеет ничего общего с общим вопросом, который я задаю , но см. Википедию: Сборник материалов для удаления / Пользователь: Frobozz1 / PA-design , Википедия: Доска объявлений администратора / Инциденты # Я чувствую себя лично подвергнутым нападкам за добросовестные правки - MfD my страница пользователя, угрозы инцидентов, нарушение работы BRD - все еще учусь, я ошибаюсь? и Википедия: Доска объявлений для администраторов / Инциденты # Parental Alienation, если вы действительно хотите попасть в сорняки. - Гай Мейкон ( разговор )

  Соответствующий бит в потоках AN / DRV - насколько я могу судить по всем уровням процедурных споров - связан со статьей о Squid и тем фактом, что администратор предположительно знал о проблеме атрибуции, но решил все равно удалить статью. Что касается случая MFD, насколько я могу судить по беглому взгляду, на карту поставлено удаление цели слияния, а не его источника, поэтому на данном этапе атрибуция не должна быть проблемой, должна Это? - Уанфала (разговор) 19:53, 21 марта 2021 (UTC)

  Таким образом, мое заявление: «Это практически не имеет ничего общего с общим вопросом, который я задаю». Я изначально проигнорировал ваш запрос на "контекст", потому что здесь нет контекста, а просто общий вопрос о наших правилах. Тогда за меня ответил Изно и получил неправильный ответ. Все это не имеет ничего общего с вопросом, который я задаю в этом RFC. - Гай Мейкон ( разговор ) 20:12, 21 марта 2021 г. (UTC)

• Разве это не имеет юридических последствий? Разве это не офисное дело? Эмир Википедии ( разговор ) 22:57, 21 марта 2021 (UTC)
  • Нет, по двум причинам. Во-первых, Википедия: копирование в Википедии # Гиперссылка - это руководство по редактированию английской Википедии, контролируемое редакторами Википедии. Во-вторых, вам нужно обращаться в юридический отдел только в том случае, если вы разрешаете что-то запрещенное законом или снимаете ограничение, установленное законом. Мы совершенно свободны добавлять ограничения. Мы могли бы решить, что никому не разрешено использовать букву «E», и юридические лица не будут иметь права голоса в этом вопросе. - Гай Мейкон ( разговор ) 23:27, 21 марта 2021 г. (UTC)

    Вы, должно быть, фанат Жоржа Перека . Матглот ( разговор ) 08:44, 24 марта 2021 (UTC)

Возможное решение

• Похоже, что нам нужен механизм для обработки следующей ситуации:

1. Статья X создается и расширяется с течением времени
2. Статья Y требует достаточного количества статьи X, чтобы требовать указания ссылки (например, не только цитирования, но и целого абзаца). Атрибуция добавлена ​​путем привязки некоторого времени
3. Через некоторое время после того, как этот контент добавлен в Y, статья X отправляется в AFD и определяется как подлежащая удалению (не объединяется и не перенаправляется, а также там, где было бы целесообразно объединить X в Y).

Таким образом, удаление «нарушает» атрибуцию, которая была на Y, которая указывала обратно на X, которая была бы там в истории страниц X, которая, вероятно, все еще будет там для администраторов, но не для обычных пользователей. Нам нужно найти способ, позволяющий сохранить историю X доступной, но без статьи X там. Возможно, когда мы знаем, что было выполнено некоторое копирование (можно ли автоматизировать эту проверку?), Мы не можем удалять статьи, но делаем удаленную цель перенаправлением на какую-то общую специальную страницу, на которой говорится о сохранении истории для правильной атрибуции и как пользователь может вернуться к истории перенаправления, чтобы изучить это? - M asem ( t ) 18:12, 21 марта 2021 г. (UTC)

По сути, это то, о чем я размышлял как возможное усовершенствование программного обеспечения, хотя я не вижу, как можно автоматизировать проверку, поэтому я думаю, что редактор, создающий страницу Y, должен будет явно ссылаться на историю, ведущую к конкретной версии страницы X Обратите внимание, что это относится ко всем страницам Википедии, а не только к статьям. isaacl ( разговор ) 18:19, 21 марта 2021 (UTC)

Я уверен, что можно провести несколько проверок, если {{ скопировал}} шаблон найден на странице обсуждения, или если сводки редактирования истории содержат diff или oldid (что необычно, так что это может быть по крайней мере список, который можно проверить вручную). Но мы, вероятно, упустим другие способы, которые в настоящее время допускает текущий язык (простая гиперссылка без oldid или diff), поэтому, возможно, в Викимедиа почти возникла потребность в том, чтобы, если кто-то нажимает на oldid / diff страницы, которая удаляется, они попадают на специальную страницу, где объясняют, что они могут оттуда делать; Мы можем объяснить, что они могут связаться с администратором, чтобы помочь - и если у нас есть эта система перенаправления, то администратор может восстановить + перенаправить в соответствии с целью. Я не вижу простого способа выполнить полный поиск в Wiki таким образом,но мы можем настроить процессы, чтобы предотвратить проблему в будущем и отреагировать, когда возникнет необходимость из прошлых удалений. -М асем ( t ) 18:25, 21 марта 2021 г. (UTC)

Да, именно это я имею в виду, говоря, что редактор должен явно связывать историю, будь то через шаблон {{ copied }} или новый пользовательский интерфейс. Чтобы уменьшить окно для условий гонки, я думаю, что новый пользовательский интерфейс был бы лучше. isaacl ( разговор ) 18:29, 21 марта 2021 (UTC)

RfC: Могут ли редакторы запрашивать у сообщества обзор чужих блоков?

Могут ли редакторы запрашивать у сообщества обзор блоков других редакторов, особенно проблемных и / или не соответствующих политике? ProcrastinatingReader ( talk ) 16:33, 22 марта 2021 (UTC)

Предложение (просмотр блока)

В июле 2019 года в Википедию смело был добавлен раздел под названием «Апелляции от третьих лиц» : обжалование правила блокировки, в котором говорится, что апелляции могут подаваться только редакторами, находящимися в активном блоке; другие редакторы могут обсуждать блокировку только с блокирующим администратором (но не могут запрашивать проверку). Этот текст несколько раз удалялся разными редакторами, но был восстановлен Сандштейном, который заявил, что для удаления или изменения текста необходимо согласие. Обсуждения на странице обсуждения по поводу удаления / изменения текста не достигли консенсуса по поводу сохранения текста. [1] Этот раздел в настоящее время конфликтует с политикой WP: ADMINACCT и WP: Blocking , а именно:Если редакторы считают, что блок был выпущен неправильно, они могут запросить проверку этого блока в Википедии: Доска объявлений для администраторов / Инциденты . Некоторые редакторы пытались процитировать этот раздел в обзоре блоков WP: AN , чтобы объяснить, почему обзор не может состояться. Фактически, проверки блоков все еще происходят с некоторой регулярностью.

Этот RfC начал получать широкое согласие сообщества по поводу этого дополнения с тремя представленными вариантами:

• Вариант 1 : ( текст ) Сохранить текущий текст: Апелляции на блоки могут подаваться только редактором под текущим активным блоком. Другие редакторы могут обсудить блокировку с блокирующим администратором. С этой целью также следует изменить политику WP: Blocking , чтобы разрешить конфликт .
• Вариант 2 : ( образец текста ) Блоки, как правило, должны быть апеллированы только редактором, подчиненным блоку. Кроме того, другие редакторы могут запросить у сообщества обзор блоков, которые, по их мнению, являются проблематичными или противоречащими политике (согласно WP: ADMINACCT ), после попытки сначала обсудить свои проблемы с блокирующим администратором.
• Вариант 3. Удалить раздел полностью.

Опрос (просмотр блока)

• Вариант 3, второй вариант предпочтения 2 : Текст в Википедии: Политика блокировки в порядке, и этот раздел не нужен. На мой взгляд, даже вариант 2 не совсем точно отражает статус-кво (я пытался добавить его только в попытке пойти на компромисс с Sandstein). Я считаю, что позиция, выдвинутая некоторыми администраторами, вызывает беспокойство, как показано на одном примере: в прошлом году я столкнулся с проблемной неопределенной полной защитой, которую администратор сделал после телефонного звонка от субъекта, говоря, что все будущие правки должны быть выполнены. страницу обсуждения как запросы на редактирование. Защита полностью не соответствовала политике, но ее защищали некоторые админки, кружившие на некоторых малоизвестных страницах обсуждений . Как только оно дошло до АН, оно было почти единогласно отменено. [2]Я также ранее успешно запрашивал проверку блоков для добросовестных, но проблемных блоков, которые, вероятно, остались бы на месте, если бы проверка не была сделана. То, что редакторы могут запросить обзор действий администратора у более широкого сообщества, является фундаментальной гарантией против любого вида «просчитанных» действий администратора, и эту защиту не следует ослаблять смелыми попытками внести неконсенсусное изменение в низкопрофильное руководство. страница, что прямо противоречит политике и прецеденту . ProcrastinatingReader ( разговор ) 17:06, 22 марта 2021 (UTC)
• Вариант 1. Есть веские причины, по которым только сами заблокированные редакторы могут и должны иметь возможность обжаловать свои блоки.
  • Во-первых, это вопрос базового индивидуального самоопределения и автономии. Заблокированные редакторы - это люди, а не объекты нашего развлечения. Это люди, лучше всего способные решить, хотят ли, когда и как они хотят обсуждать свой блок публично, включая, конечно, их собственное предположительно деструктивное или неловкое поведение, которое привело к блокировке.
  • Во-вторых, и в том же духе, это вопрос предоставления заблокированным редакторам возможности самим сформулировать обсуждение разблокировки, включая его время и форум, а также аргументы, которые они хотят выдвинуть. Возможно, они захотят сначала обсудить этот вопрос с блокировщиком или позволить сделать это другому доверенному редактору. Они могут захотеть привести аргументы, которые могут не прийти в голову тому, кто еще делает запрос на разблокировку, или они могут захотеть убедиться, что любое обсуждение разблокировки происходит в то время, когда они доступны для участия. Они могут захотеть обсудить индивидуально с {{ unblock }} рецензентами на своей странице обсуждения, а не на открытом форуме.
  • В-третьих, это вопрос защиты заблокированных редакторов от благонамеренных, но некомпетентных или вредных запросов на разблокировку со стороны других. Если плохо продуманный или деструктивный запрос на разблокировку со стороны других отклоняется на публичном форуме, любой последующий запрос на разблокировку может быть отклонен безотлагательно, потому что существует предполагаемое согласие сообщества в пользу блокировки.
  • В-четвертых, это вопрос не тратить время сообщества на обсуждения разблокировки, которые, по-видимому, даже заблокированный редактор считает бесполезными (иначе они бы сами сделали запрос на разблокировку).
  • Но, в-пятых, и это, пожалуй, самое главное, серьезные обсуждения разблокировки невозможны без участия заблокированного редактора. Основным принципом наших механизмов санкций является то, что блоки носят превентивный, а не карательный характер. Запросы на разблокировку не о том, «соответствует ли наказание преступлению?», Они о том, «нужна ли блокировка для предотвращения сбоев в работе проекта?». А это, в свою очередь, означает, что нам необходимо знать , считает ли заблокированный редактор проблемой собственное поведение, о котором идет речь, и намерены ли они продолжать это после разблокировки. Не слыша от них их собственных слов, мы находимся в режиме чистого наказания, а не в режиме предотвращения ущерба, и я не думаю, что мы хотим быть там.

  Настаивание на том, что запросы на разблокировку делаются только заблокированным редактором, вообще не препятствует ответственности администратора, поскольку не исключает возможности подачи апелляции. Это просто гарантирует, что может быть проведено полезное и продуктивное обсуждение, которое также учитывает интересы заблокированного редактора. Sandstein 17:38, 22 марта 2021 г. (UTC)

• Вариант 3 . Два других варианта отражают текст, который был недавно добавлен к руководящим принципам, что противоречит уже довольно подробному разделу политики Википедии: Политика блокировки # Запросы на разблокировку. Я знаю, что некоторые администраторы не желают поддерживать отзывы о блокировках, исходящих от третьих лиц, но это нежелание оставляет впечатление избегания ответственности. (Это впечатление может быть неверным, но тот факт, что он уже существует, подрывает доверие к системе). Я полагаю, что эти админы предполагают, что все блокировки в порядке, и поэтому единственные условия, при которых они могут быть сняты, - это когда сам заблокированный редактор демонстрирует готовность изменить свой образ действий. Но не все блоки хороши. Например, может быть недоразумение, и иногда его легче уловить опытному наблюдателю, чем заинтересованной стороне. Мы должны знать, что есть и разные темпераменты - некоторые редакторы предпочли бы уйти навсегда, чем проглотить свою гордость и попросить, чтобы их впустили обратно, особенно если они этого не сделают.Я согласен с блоком. Сандштейн отмечает несколько хороших моментов выше, и они показывают, что важно всегда позволять заблокированным редакторам принимать участие в любом обсуждении их блокировки. Однако при этом упускается из виду тот факт, что в большинстве случаев, когда сторонние апелляции находятся на рассмотрении, в центре внимания находится не столько поведение заблокированного редактора, сколько блокирующего администратора. -Уанфала (разговорное) 17:57, 22 марта 2021 (UTC)
• Вариант 2, возможно, вариант 3 в качестве второго варианта. Основной принцип WP: ADMINACCTтребует, чтобы каждое действие администратора, включая блокировку, было подотчетным и проверяемым сообществом. Может быть много ситуаций, когда блокировка была оскорбительной или просто неправильной и противоречила политике, но заблокированный редактор по какой-то причине недоступен или не желает подавать апелляцию. В частности, новые редакторы могут не понять, как это сделать. Редакторы могут заболеть или столкнуться с семейными или другими жизненными обстоятельствами или обязательствами, которые сделают их недоступными. Или они могут просто захотеть избежать драмы. Если блокировка была плохой и противоречила политике, у сообщества все еще есть интерес и право привлекать к ответственности администратора, выпустившего эту блокировку. Вот почему обзор блока сообществом должен оставаться доступным в качестве опции, даже если заблокированный редактор не обжалует свой блок. Nsk92 ( обсуждение) 18:13, 22 марта 2021 г. (UTC)
• Вариант 3 для WP: CREEP , WP: IAR и замечания ОП. Кроме того, блокирующий администратор или заблокированный редактор могут быть недоступны по разным причинам. Эндрю 🐉 ( разговор ) 18:58, 22 марта 2021 (UTC)
• Я поддерживаю сохранение существующего текста, в котором заблокированные редакторы имеют право обжаловать свои блоки. Поскольку именно они сталкиваются с последствиями апелляции, они должны сохранять контроль над тем, когда и как подавать апелляцию. Как правило, из-за усталости сообщества есть один первоначальный шанс оптимально сформулировать апелляцию. Другим редакторам не должно быть позволено лишать заблокированных редакторов возможности составлять свои собственные апелляции своими словами и когда они доступны, или явно делегировать эту ответственность. Я действительно понимаю, что ответственность сообщества по обеспечению надзора за действиями администратора частично пересекается. Тем не менее я считаю важным дать возможность тем, кто больше всего пострадал от апелляции, управлять своей апелляцией. isaacl ( разговор ) 19:53, 22 марта 2021 (UTC)
• Политика Варианта 2 гласит, что может быть пересмотр, я согласен с этим, и я также согласен, что желательно, чтобы апелляция исходила от заблокированной стороны в первую очередь. Selfstudier ( разговор ) 20:01, 22 марта 2021 (UTC)
• Вариант 2 согласно пунктам, сделанным выше. Sea Ane ( разговорное ) 20:41, 22 марта 2021 (UTC)
• Вариант 2, поскольку полное обоснование блокировок часто не раскрывается в вики, беспрепятственное обращение к третьим лицам будет проблематичным. Частые призывы сторонних лиц сменить блок «на отработанный срок» не помогут заблокированному редактору. Для блоков, созданных по ошибке, такой проблемы нет.力(power ~ enwiki, π , ν ) 23:02, 22 марта 2021 г. (UTC)
• Вариант 3 с вариантом 2 в качестве второго варианта. Заблокированный пользователь - просто свидетель события; они не обязательно обладают знаниями, навыками или невозмутимостью, чтобы аргументировать политику в целях самозащиты. Я указываю на мой ненадлежащий блок с декабря, который был отменен, потому что мне посчастливилось получить поддержку от других в моем апелляции, когда я чувствовал себя беспомощным и потерянным (хотя я сделал первоначальное заявление об апелляции). Коля Баттернат ( разговор ) 23:08, 22 марта 2021 (UTC)
• Вариант 2 с вариантом 3 в качестве второго варианта. Администраторы должны нести ответственность перед сообществом, в том числе и за то, что блоки, которые они делают, проверяются сообществом. Это обычно предпочтительно, обзоры инициируются заблокированной партия, но есть и исключение - не в последнюю очередь потому , что Админы люди и люди делают ошибки. Единственные причины, по которым допустимо просматривать блок без предварительного обсуждения его с блокирующим администратором, заключаются в том, что этот администратор не может или не хочет его обсуждать (например, у них нет времени, их явно нет рядом или просто не отвечает) или указали, что предпочитают сразу же обсуждать это в более широкой среде. Вариант 2 лучше всего отражает это imo. Thryduulf ( разговор) 23:53, 22 марта 2021 г. (UTC)
• Комментарий - рассматривает возможность подачи апелляции другим членом сообщества, помимо блокируемого, но только с коротким сроком (например, неделя или месяц). Не следует обжаловать чужие блоки через 3 месяца, 6 месяцев или год (лет) после того, как факт (то есть после того, как член сообщества не был рядом в течение среднего или значительного периода времени), потому что это было бы проблематично по-разному. . Кроме того, время от времени разногласия по поводу блоков довольно быстро передаются заинтересованным сторонам в AN; предпочли бы просто slighly мягкую формулировку Вариант 1. -  Godsy  ^{( TALK} _{CONT )} 2:41, 23 марта 2021 (UTC)
• Вариант 1 - все остальное потенциально может открыть ящик Пандоры для легкомысленных апелляций. Помимо моего Кена ( выступление ) 03:04, 23 марта 2021 г. (UTC)

  Я рассматриваю вариант 2 как линию защиты от таких апелляций, которые, я согласен, нежелательны, но с радостью поддержали бы кое-что явное. Однако в настоящее время у меня нет хорошего предложения, как это сказать. Тридуульф ( разговор ) 03:39, 23 марта 2021 (UTC)

• Вариант 1 За исключением случаев, когда есть какой-либо другой скрытый способ информирования заблокированного пользователя и его явного согласия на то, чтобы его перетаскивали через высокопрофильную AN. Аланскоттуокер ( разговор ) 23:24, 23 марта 2021 (UTC)
• Вариант 2 До того, как у меня появился опыт работы с arb com, я бы сказал вариант 3, но мы столкнулись с несколькими случаями, когда заблокированная сторона не хотела, чтобы ее разблокировали, и даже не хотели, чтобы этот вопрос обсуждался снова. По крайней мере, один или два из них явно были связаны с попыткой кого-то другого преследовать заблокированного человека, что, конечно, совершенно несправедливо. Здесь должна быть некоторая осмотрительность, и №2 - хорошее компромиссное решение. DGG ( разговорное ) 01:58, 24 марта 2021 (UTC)

  @ DGG : а раньше это было проблемой для AN? (если да, какие-либо ссылки / примеры?) Я предполагаю, что кто-то, преследующий кого-либо под предлогом запросов на разблокировку, столкнется с суровым WP: BOOMERANG ? ProcrastinatingReader ( talk ) 17:19, 24 марта 2021 (UTC)

  вроде это нормально попадает под вилку ком. DGG ( разговор ) 17:59, 24 марта 2021 (UTC)

• Вариант 2 Действия администратора должны быть доступны другим пользователям. Если блок явно не соответствует политике, на него следует обратить внимание сообщества. Я надеюсь, что это не станет обычным явлением, но при необходимости это станет возможным. Тамвин ( разговор ) 06:08, 24 марта 2021 (UTC)
• Вариант 3 во многом на ProcrastinatingReader и Колю Баттернат. Заблокированный пользователь может не всегда обладать достаточными знаниями, чтобы подать эффективный запрос на разблокировку. Сторонний запрос на проверку, вероятно, будет более убедительным, поскольку его инициирование само по себе означает, что есть по крайней мере один человек, который считает, что блокировка неправильная, и достаточно заботится о ней, чтобы запросить проверку. - SD0001 ( разговор ) 11:05, 24 марта 2021 г. (UTC)
• Вариант 2 в основном для Power и DGG, хотя я симпатизирую аргументам сторонников варианта 3 относительно принудительного компромисса и, безусловно, предпочел бы его варианту 1. Ватицидальный пророк 13:53, 24 марта 2021 г. (UTC)
• Вариант 1 по Sandstein, вариант 2 также кажется вполне разумным. wikitigresito ( обсуждение ) 19:33, 24 марта 2021 (UTC)
• Вариант 1 по Sandstein. ~ ToBeFree ( обсуждение ) 22:53, 24 марта 2021 г. (UTC)
• Вариант 2 или 3- Я думаю, что те уважаемые члены нашего сообщества, которые прошли RfA и никогда прежде не были заблокированы, не совсем понимают, насколько раздражающим может быть то, что их заблокировали по ложной причине. Теперь в моем длинном журнале блокировки есть только один или два, о которых я так думал, и это определенно не те, для которых я собирался подавать запрос на разблокировку. Было почти унизительно просить разблокировать меня за то, за что, как мне казалось, меня никогда не должны были блокировать. И требование, чтобы кто-то это сделал, мне кажется, как человеку, который был на этой стороне вещей, еще одним оскорблением. Если блок неправильный, его следует поднять. Не имеет значения, кто делает официальный запрос, чтобы определить, является ли блокировка неправильной. Мы не должны требовать, чтобы люди раскаивались, когда с ними поступили несправедливо, и да, некоторые блоки ошибочны.nableezy - 00:33, 25 марта 2021 г. (UTC)
• Вариант 2.1. Если плохой блок уводит кого-то с сайта, то на самом деле нет способа привлечь к нему внимание сообщества. Новым редакторам также сложно полностью получить запросы на разблокировку, особенно если они делают это во время блокировки. Я лично не против сторонних обзоров. Однако , помимо предварительного контакта с администратором, я также потребовал бы: а) третья сторона спросит заблокированного редактора, хотят ли они подать апелляцию, и, если нет, возражают ли они против апелляции третьей стороны? б) Подождите 48 часов после a. Если ответа нет или заблокированный редактор пишет «нет или нет», то можно подать апелляцию. Если заблокированный редактор не хочет подавать апелляцию (или подает ее самостоятельно), то очевидно, что третья сторона все равно не сможет ее подать.Носовая сумка медведь (разговор ) 11:48, 25 марта 2021 (UTC)
• Вариант 3 с вариантом 2 в качестве второго варианта . Я стал жертвой плохого блока, и я могу полностью понять, почему тот, кто его получил, ушел. В соответствии с действующими правилами это оставляет сообщество без юрисдикции заниматься этим вопросом. Мы должны иметь право контролировать, анализировать и давать отзывы о блокировании использования сисопами или неправильного использования инструментов. Некоторые сисопы гораздо более склонны к блокированию, чем другие, что приводит к значительному уровню непоследовательности в наших решениях, связанных с блокировками. На данный момент любая попытка решить проблему с блокировщиками затруднена в каждом случае, когда сисоп успешно сбивает свою цель. Я считаю , что должен быть специальный форум, отдельно от доски объявлений Администратора, для блока reviews.- S Marshall  T /C 10:05, 26 марта 2021 г. (UTC)
• Вариант 2 кажется хорошим компромиссом между противоречивыми проблемами, - agr ( talk ) 12:32, 26 марта 2021 г. (UTC).
• Вариант 3 1-й выбор, Вариант 2 2-й выбор. # 3, потому что, более или менее, инструкции: нам не нужно, чтобы в этом разделе указывалось, кто может делать запрос и при каких обстоятельствах; нет проблемы с апелляциями на плохие блоки, которые нам нужно избегать с помощью инструкций на странице политики / рекомендаций. PAG должны быть как можно короче, и это меня не устраивает. Вариант 2 в качестве второго варианта, потому что, если у нас есть письменное правило об этом, вариант 2 - это то, что он должен сказать. Levivich  ^харасс / _гончая 03:38, 27 марта 2021 (UTC)
• Вариант 1 как первый выбор; сочетание варианта 2 в качестве второго, поэтому я думаю, что причина такого большого количества «Вариантов 2» выше в том, что у нас уже есть сочетание варианта 2 на практике. Мы уже разрешаем апелляции третьих лиц в чрезвычайных обстоятельствах, и меня беспокоит использование формулировки варианта 2, так это то, что он выйдет за рамки существующей практики, которая находится где-то между вариантом 1 и вариантом 2. Другими словами, заявить, что блокировка вашего друга нарушена, подать апелляцию от его имени будет намного проще, если мы неправильно сообщим об обновлении.
  Другими словами, я в целом согласен с приведенным выше Тридуульфом , но я бы предпочел, чтобы это было смягчено в существующей формулировке, а не рассматривалось как нечто новое. Я не считаю это чем-то новым (это может произойти как выходящее за рамки нормы, когда уже есть серьезная ошибка или что-то подобное). Я бы хотел убедиться, что он сохраняет ощущение нестандартности. видеть в любой редакции. Тони Баллиони ( разговор ) 20:56, 27 марта 2021 (UTC)
• Вариант 2 кажется лучшим вариантом. Это не ситуация «никогда» или «всегда». Некоторые блоки НЕ должны отменяться, если заблокированный пользователь этого не запрашивает. Некоторые блоки должны. Мы ни не хотим поощрять wikilawyering и чрезмерную травлю админ в случаях бесспорной блокировки, но и не хочу , чтобы помешать обзор сообщества плохих блоков, даже не-обжалованы них. Это индивидуальная проблема. Для блоков типа садовых и стандартных болот было бы необычно разрешить третьей стороне запросить переворот, но практика ЯВНО диктует, что мы обсуждаем спорные блоки на WP: AN, даже если заблокированный пользователь этого не запрашивает. Мы уже в основном делаем 2, и это представляет собой стандартную практику в течение многих лет. - Джейрон 32 16:42, 29 марта 2021 г. (UTC)
  • Не комментируя здесь достоинства, но я просто хочу отметить, что RfC должны быть в состоянии изменить практику. Администраторы должны следовать воле сообщества, особенно когда она официально выражена в хорошо разрекламированном и проводимом RFC. - Трубатор ( разговор ) 18:51, 29 марта 2021 (UTC)
    • Да, вы правы, но ваша точка зрения не имеет значения. Я говорю не о том, чтобы «никогда не менять практику». Я говорю: «Альтернативы, предлагаемые текущим RFC для текущей практики, плохие. Не делайте их. То, что у нас есть, работает и лучше всего». - Джейрон 32, 11:15, 30 марта 2021 г. (UTC)
• Вариант 2 , теперь, когда я имел возможность взглянуть на достоинства. Проблема с аргументом Сандштейна состоит в том, что он предполагает, что в поведении заблокированного редактора есть что-то, что действительно нужно изменить. Это не всегда так; иногда блок просто неправильный, и никогда не должен был быть сделан изначально. В этом случае редактору не обязательно приходить в руки и просить рецензию. - Троватор ( разговор ) 19:00, 29 марта 2021 (UTC)
• Вариант 2, за которым следует 3 , на Jayron32 и S Marshall. Такого пользователя нет ( обсуждение ) 08:13, 30 марта 2021 (UTC)
• Вариант 2 . Я думаю, что Вариант 2 лучше всего гармонирует с другими страницами политики, и это также самый разумный способ для нас это сделать. Это разумная середина. Вариант 1 слишком жесткий, недостаточен для исправления ошибок и несовместим с другими страницами политики. Вариант 3 без нужды открывает слишком много способов игры с системой. Но Вариант 2 устанавливает правильный баланс, при этом самооценка является нормой в сочетании с соответствующими способами, позволяющими уделять больше внимания проблеме. Я поддерживаю предложения Nosebagbear о включении какого-либо требования о том, чтобы третьи стороны пытались получить разрешение от заблокированного пользователя, прежде чем двигаться дальше. - Триптофиш ( разговор ) 18:51, 30 марта 2021 (UTC)
• Вариант 2 (второй вариант выбора 3), поскольку не должно быть запрета на обсуждение плохих блоков или их просмотр другими. Легкомысленные просьбы не поощряются и могут быть быстро завершены. Грэм Бартлетт ( разговор ) 22:38, 30 марта 2021 (UTC)
• Вариант 2 первый выбор; вариант 3 иначе. Хотя сторонние запросы на проверку блоков - или любые другие санкции - редки, нет центральной основы политики, запрещающей их, и на самом деле они иногда принимаются, в том числе ArbCom (я видел, как это происходило как минимум дважды на WP: AE, в том числе один раз в течение последнего года или около того). Наиболее очевидная причина, по которой они должны быть допустимыми, заключается в том, что ограничение в отношении одного редактора часто приводит к вторичному ограничению другого (например, прекращает продолжавшееся в то время сотрудничество или ограничивает другого редактора в том, что они могут обсуждать с редактором при условии явного Средства). Учитывая отсутствие чего-либо вроде деструктивного «шума», связанного с разблокировкой третьих лиц, у рассматриваемой страницы нет реальной причины пытаться излишне придирчиво относиться к этим вопросам, особенно как a) WP: ISNOTABUREAUCRACY и b ) наша политика существует для того, чтобы служить нам, а не наоборот, и не должна ограничивать любые добросовестные редакционные действия без уважительной причины (см. WP: EDITINGполитика). Какой бы вариант ни был выбран, убедитесь, что между этими страницами нет WP: POLICYFORK . PS: Я согласен с приведенной ниже критикой Сандштейна формулировки вопроса RfC, но я думаю, что большинство из нас без труда поняли смысл и цель. Но постарайтесь писать RfC более нейтрально, в соответствии с инструкциями в WP: RFC .  -  SMcCandlish ☏ ¢  😼  05:29, 31 марта 2021 г. (UTC)
• Вариант 1 для Sandstein Majavah ( обсуждение! ) 12:25, 31 марта 2021 г. (UTC)
• Вариант 2. Сообщество может и должно иметь возможность отвергать почти все остальное путем консенсуса, если это необходимо. Политика, утверждающая иное, была бы просто неправильной. Упоминание этой возможности в политике поможет действительно начать обзор, когда это необходимо, в то время как совет редакторам сначала попытаться обсудить это с блокирующим администратором, прежде чем запускать ветку ANI, поможет предотвратить несоразмерное раздутие вещей, когда, возможно, они могли бы быть решается намного проще. Я согласен с второстепенным предложением некоторых других о том, что сначала нужно спросить заблокированного пользователя - начинать обсуждение от чьего-то имени только для того, чтобы выяснилось, что он даже не хочет, чтобы его разблокировали, было бы неуважением к ним и пустой тратой времени. . Наконец, необоснованные запросы все равно случаются, и этот RFC не изменит этого, независимо от результата. - Руммскартоффель ( обсуждение  • вклад ) 21:42, 1 апреля 2021 г. (UTC)
• Вариант 2 : любые действия администратора должны быть открыты для рассмотрения сообществом, включая блокировку. Член сообщества может иметь законное беспокойство по поводу действия администратора, даже если он не был целью действия, и даже если цель действия не желает его обжаловать. Редактор, обеспокоенный действием администратора, должен сначала обсудить это действие с этим администратором и сообщить о своей проблеме более широкому сообществу только в том случае, если первоначальное обсуждение не помогло решить эту проблему. Mr248 ( разговор ) 05:00, 2 апреля 2021 (UTC)
• Вариант 3 первый выбор. Вариант 4 (просто позвольте нам сделать сторонние запросы} действительно первый выбор (если бы он был доступен). У нас уже есть ADMNACCT и очень четкая политика блокировки, и мы поверили, что мы можем подавать эти апелляции, если мы думаем, что является проблемой. Мы должны либо поддерживать эту политику в других местах, либо удалить ее из других мест, где она конфликтует. Huggums537 ( talk) 09:36, 2 апреля 2021 г. (UTC) Кроме того, большинство аргументов Сандштейна основаны на предположении, что заблокированный редактор каким-то образом не имеет возможности высказаться по этому поводу или иным образом не имеет возможности участвовать в процесс независимой проверки собственного блока. Доказательств этого нет, потому что у большинства заблокированных пользователей все еще есть страница обсуждения и доступ к электронной почте, и даже если они этого не делают, они все равно могут отправлять кому-то электронное письмо . Итак, я вынужден не согласиться с его утверждениями, основываясь только на этом. Huggums537 ( разговорное ) 03:46, 6 апреля 2021 (UTC)
• Вариант 2 просто приводит WP: AAB в соответствие со страницей политики, которую он призван дополнять, и поэтому не может иметь разумных возражений. Вариант 3 - мой второй выбор, очень близкий второй вариант. Iaritmioawp ( разговор ) 22:12, 2 апреля 2021 (UTC)
• Вариант 2 Если пользователь подает апелляцию на блокировку, обычно нет причин для предотвращения обсуждения на доске объявлений. Например, в Википедии есть поддержка разблокировки : Доска объявлений администраторов / IncidentArchive1008 # Meatpuppetry в Spygate от r / The Donald, но нет конкретного предложения по разблокировке; при запуске обзора Wikipedia: Доска объявлений администраторов / Archive308 # Блокировать просмотр KeithCu от Feezo, он почти сразу закрывается. Вариант 1 позволяет администраторам закрыть любую попытку обсуждения, решение, которое, вероятно, будет зависеть от мнения администратора о заблокированном редакторе, блокирующем администраторе или редакторе, запрашивающем проверку, или политикой, в той же степени, что и целью block, а также политики и рекомендации. Питер Джеймс (разговор ) 12:19, 7 апреля 2021 (UTC)
• Вариант 2 - Формулировка, наиболее подходящая для обсуждения разблокировки в каждом конкретном случае. Куртис (разговор) 13:04, 9 апреля 2021 (UTC)
• Вариант третий . Администраторы должны нести ответственность перед широким сообществом за свои действия, а санкции должны быть пересмотрены. Если заблокированный редактор не знаком с соответствующей политикой или общепринятой практикой, было бы несправедливо ожидать, что этот редактор сможет составить запрос на разблокировку с хорошими шансами на успех. Я считаю, что первый вариант несовместим с идеями подотчетности, а второй вариант - ненужный совет, который несправедливо ограничивает тех, кто желает, чтобы блокировка была пересмотрена. Sdrqaz ( разговорное ) 20:49, 9 апреля 2021 (UTC)
• Вариант 3 - Раздел был добавлен неправильно без формального консенсуса, и его вообще не следовало добавлять. Политика работает не так, мы просто не пишем новую политику, основанную на неопределенных «предыдущих обсуждениях», и говорим: «Не стесняйтесь возвращаться». Оговорка совершенно незаконна. ~ Swarm ~ ^{sting} 22:28, 9 апреля 2021 г. (UTC)
  • Я думаю, вы сделали здесь отличное замечание, Swarm . Доказательством того, что запись была недействительной, является тот факт, что с тех пор, как она была добавлена, здесь много раз возражали или оспаривали ее, и даже если бы она была так или иначе действительна с некоторой натяжкой воображения, я согласен с комментариями, сделанными Троваторе выше, что аргументы поскольку в нем Сандштейн и другие делают слишком много нереалистичных предположений об обстоятельствах, связанных с заблокированными пользователями, о чем также говорилось в моем голосовании выше. Huggums537 ( разговор ) 03:00, 10 апреля 2021 (UTC)

  @ Swarm : Я согласен с тем, что указанное положение могло быть «вкраплено» в политику без должного консенсуса, но ваше возражение, основанное на этом простом факте, не должно иметь здесь никакого значения, поскольку сам консенсус может быть достигнут независимо от того, каким образом он был инициирован. ( ответьте на обсуждение ниже ) - AXO NOV (обсуждение) ⚑ 11:14, 10 апреля 2021 г. (UTC)

  Извините, но это не так. Должны быть предложены новые политики, и для их реализации требуется высокий уровень консенсуса всего сообщества. Вы не можете просто добавить текст, не выполнив этого требования, которое само по себе является требованием политики сообщества для создания новых политик. Этот документ не создает существующее положение политики в качестве незаконнорожденных политиков нуждаются в проверке обратной силы сообщества, это создает как существующий статус - кво либо сохранить или изменен или удален, в то время как замазать тот факт , что это не на самом деле, даже настоящая политика для начала. ~ Swarm ~ ^{sting} 00:13, 12 апреля 2021 г. (UTC)

  Как я уже говорил в другом месте, я чувствую, что это изменение было примером этого . Другие редакторы добросовестно обсуждали это во время выступления в октябре, но по нему явно не удалось достичь консенсуса, и его все еще заставляли. Это не то, как мы должны редактировать политику. Вызывает беспокойство то, что идея несогласованного текста добавляется к подобным политикам, а затем (согласно Nsk92 ниже) используется в обсуждениях. В более общем плане: части PAG постоянно цитируются при разрешении споров и используются в качестве основы для санкций / разрешения споров RfC, но некоторые из этих текстов даже не имеют консенсуса, и большинство людей не используют WikiBlame все время, чтобы выяснить, когда был добавлен текст и после какого разговора. Это может привести к плохим результатам. ProcrastinatingReader ( говорить) 14:22, 10 апреля 2021 г. (UTC)

• Вариант 2 - Ненавижу бессрочные баны. Мы не должны лишать третьи стороны возможности выносить спорные запреты (или доказательства неправомерных действий) в свете более широких обзоров сообщества. Это должно стать первым шагом, предотвращающим всевозможные незаметные WP: группировки и охоты на ведьм, сделают процесс поведенческой проверки более прозрачным и сложнее полностью исказить информацию о жертвах или сложнее ввести запреты, не подлежащие обжалованию. Учитывая, что применение этого положения может привлечь более широкое внимание сообщества, злоупотреблять им нельзя. Отсутствие такового, безусловно, придаст смелости тем, у кого злые намерения . РГ: ARBCOM также регулярно рассматривает некоторые блоки , так что я не понимаю , почему сообщество должно быть запрещено делать это. Это хорошее предложение.AXO NOV (разговорное) ⚑ 11:14, 10 апреля 2021 (UTC)
• Вариант 2 - если блокировка находится в рамках разумной интерпретации политики, то действительно, собственное обращение заблокированного пользователя должно быть единственным основанием для разблокировки. Однако, если блокировка выходит за рамки разумного диапазона политики, ее следует отменить как можно скорее, даже без такой апелляции; любому пользователю, который замечает такую ​​проблему, следует разрешить запросить отзыв сообщества по этому поводу. 147.161.8.7 ( разговорное ) 23:05, 12 апреля 2021 (UTC)
• Вариант 2 . Администраторы должны нести максимальную ответственность перед сообществом. Бенджамин ( разговор ) 03:16, 14 апреля 2021 (UTC)
• Вариант 2 Только заблокированный редактор может гарантировать, что хороший блок не нужно будет повторять. Но любой должен иметь возможность оспорить то, что он считает плохим блоком. Ϣere Spiel Checkers 23:49, 14 апреля 2021 г. (UTC)

Обсуждение (просмотр блока)

Вопрос, поставленный в этом RFC («Могут ли редакторы запрашивать у сообщества проверку блоков, особенно проблемных и / или противоречащих политике?»), Не является нейтральным или разумным. Его следует перефразировать как «Могут ли редакторы запрашивать рассмотрение сообществом блоков других редакторов?». Вопрос упускает из виду, что этот RfC касается только блоков других, а не собственных блоков. И, по-видимому, каждый, кто подает апелляцию на блокировку, считает, что блокировка проблематична или нарушает политику, иначе зачем ее обжаловать? Следовательно, эта квалификация также не нужна. Sandstein 17:46, 22 марта 2021 г. (UTC)

Некоторые вопросы: (1) Если есть неправильная блокировка и после обсуждения с администратором она не решена, означает ли это, что необходимо обсудить, следует ли принимать меры против администратора? (2) Иногда удовлетворительный запрос на разблокировку отклоняется, потому что администратор не прочитал его должным образом. (3) Могут быть и другие исключения, такие как недопонимание [3] или блокировка не того пользователя. Процесс разблокировки идет слишком медленно, есть как минимум один непроверенный запрос с января. Питер Джеймс ( разговор ) 18:13, 22 марта 2021 (UTC)

Я понимаю вашу точку зрения по первому (должно быть ясно, что речь идет о других редакторах); Подправлю. По второму пункту: я считаю, что квалификация необходима. Существуют разные причины для апелляции / проверки, например, на основании того, что в блоке больше нет необходимости или что редактор узнал, и т. Д., Что не означает, что исходный блок был вне политики (хотя он мог все равно ошибаться). Подобные обсуждения тоже происходят с некоторой регулярностью. Мне кажется, что введение этих двух отдельных деталей непосредственно в вопрос RfC сделает это обсуждение небольшим WP: TRAINWRECK . У меня нет особого мнения относительно апелляций по другим причинам, и я доволен фактическим статус-кво, существующим в AN. ProcrastinatingReader ( разговор ) 18:23, 22 марта 2021 (UTC)

• Я всегда предполагал, что если администратор предпримет действие против другого редактора, и я увижу проблему с этим действием, я смогу связаться с этим администратором, чтобы обсудить это ... и (при необходимости) я мог бы опубликовать ветку на WP: AN обсудить этот вопрос с остальными админдом. Разве это не так? Blueboar ( разговор ) 18:50, 22 марта 2021 (UTC)

  Не когда дело касается блоков. Или, по крайней мере, ситуация с блоками непонятна. Я почти уверен, что каждый раз, когда я видел, как сообщество рассматривает запуск блока в AN / ANI без того, чтобы заблокированный редактор запрашивал разблокировку, Сандштейн поднимал это конкретное положение Википедии: Обжалование блокировки ( `` апелляции на блокировку сторонних лиц принимаются не допускается »), что обычно приводит к затяжным обсуждениям данного вопроса. Nsk92 ( разговор ) 23:19, 22 марта 2021 (UTC)

  • Что делать, если существует потенциальный образец плохих блоков? Конечно, мы должны иметь возможность обсуждать отдельные блоки, чтобы определить, существует ли модель неправильного суждения со стороны администратора. Здесь нужна НЕКОТОРАЯ гибкость. Blueboar ( разговор ) 00:44, 23 марта 2021 (UTC)
• Похоже, что потенциальный другой вариант - потребовать от заблокированного лица дать согласие на проверку третьей стороной (или предоставить временное окно для возражения). Я думаю, что некоторые возражения Сандштейна убедительны, но я также знаю, что блоки - это эмоциональные и запутанные времена, поэтому сторонняя проверка потенциально чрезвычайно полезна для некоторых пользователей, которые не чувствуют себя подготовленными или иным образом чувствуют себя подавленными / неуверенными в ситуации. -Рододендриты ^{говорят} \\ 19:45, 22 марта 2021 года (UTC)

  Я действительно понимаю, что быть заблокированным - это непростое время, и я сочувствую заблокированным сторонам, которые чувствуют себя подавленными. Тем не менее, я думаю, что важно постараться не допустить, чтобы это превратилось в ситуацию, когда они соглашаются, невзирая на беду, на апелляцию третьей стороны, не тратя времени на то, чтобы обдумать наилучший курс действий. В другом контексте Билби предложил, чтобы советники давали рекомендации потерпевшим сторонам относительно возможных будущих шагов. Это может быть полезно для этого сценария. isaacl ( разговор ) 20:01, 22 марта 2021 (UTC)

• Если я правильно понимаю цель Варианта 1, я думаю, что это разумное описание общей практики, которая не обязательно противоречит WP: ADMINACCT или политике блокировки, хотя ее определенно можно было бы сформулировать лучше. По сути, всякий раз, когда сторонний редактор публикует в AN или ANI сообщения с просьбой о проверке блокировки, сообществу обычно требуется заявление от заблокированного пользователя, в котором объясняется его взгляд на ситуацию. За исключением ситуаций, когда блокировка является явной ошибкой или явным неправильным применением политики, я не могу представить себе ситуацию, когда мы могли бы разблокировать кого-либо, не получив сначала известие от заблокированного пользователя. Цель не состоит в том, чтобы дать администраторам карт-бланш.безнаказанно создавать плохие блоки до тех пор, пока заблокированный редактор отказывается обжаловать свои блоки, а просто для того, чтобы сообщить, что в подавляющем большинстве случаев апелляции будут безуспешными, если у нас нет заявления от самого заблокированного пользователя. Mz7 ( разговорное ) 21:24, 22 марта 2021 (UTC)

  Блочные проверки обычно отличаются от апелляций (обычно делаются на основании того, что они не соответствуют политике; Сандштейн также отменил это изменение, поэтому я предполагаю, что он с этим не согласен). Сообщество, как правило, непоследовательно в отношении того, что делать с фактическими апелляциями третьих лиц, часто это зависит от редакторов, участвующих в обсуждении в конкретный день. ProcrastinatingReader ( разговор ) 21:51, 22 марта 2021 (UTC)

  Хм, разобравшись в этом чуть подробнее, думаю, я лучше понимаю контекст спора здесь. Я согласен с вами в том, что если сторонний пользователь приходит в ANI с просьбой пересмотреть чей-то блок, например, обвиняя администратора в том, что он участвует в WP: INVOLVED или в каком-либо другом явном нарушении политики, мы не должны отклонять их аргументы только потому, что это не так. исходят из самого заблокированного редактора. Обоснованием для этого может быть WP: NOTBURO : в юридических спорах в Соединенных Штатах нередко суд отклоняет незавершенное судебное разбирательство исключительно по процедурным основаниям до рассмотрения "существа дела", например, если истец не имеет права возбуждать дело. ; Однако Википедия не является судом, и NOTBURO заявляет, чтоПроцедурная ошибка, допущенная в предложении или запросе, не является основанием для отклонения этого предложения или запроса.

  С учетом всего вышесказанного, я думаю, что все же поддержу добавление формулировок, которые препятствуют большинству форм сторонних блокирующих апелляций / обзоров, если только блок не является явно ошибочным. Статус-кво, кажется, в порядке, но я обеспокоен тем, что с этим RFC мы непреднамеренно изменим статус-кво в сторону поощрения большего количества сторонних обзоров в ущерб нашему времени и энергии. Среди представленных здесь вариантов вариант 2, похоже, наиболее близок к моим взглядам, хотя я считаю, что немного больше внимания следует уделять части «как правило, только должно быть». Mz7 ( разговорное ) 22:31, 22 марта 2021 (UTC)

  Проблема в том, что плохая апелляция может испортить возможность для разумной апелляции в краткосрочной перспективе. Проблема не в игнорировании аргументов, а в том, чтобы позволить стороне, наиболее затронутой апелляцией, решать, когда и как приводятся эти аргументы. Несправедливо, когда заблокированные редакторы позволяют кому-либо подавать апелляцию без согласования ее формы, формулировки, акцента или других аспектов. isaacl ( разговор ) 22:42, 22 марта 2021 (UTC)

  Я думаю, что попытка вызвать WP: NOTBURO или WP: IAR в качестве причины для разрешения - не идеальный подход. Это склоняет чашу весов в пользу редакторов, которые понимают нормы сообщества, или редакторов с большим количеством TPW таких редакторов, которые могут согласовывать различные политики вместе и знают, как сообщество на практике реагирует на различные проблемы. Руководящие принципы должны отражать этостатус-кво, документируя его, чтобы люди, менее знакомые с операциями бэк-офиса, также могли запрашивать рассмотрение сообществом вопросов (и действительно, много раз такие редакторы улавливали актуальные проблемы). Вероятно, нежелательно не разъяснять это всем редакторам, и недопустимо предоставлять вводящее в заблуждение изображение этого (что и делается в текущем разделе). Я знаю, что люди слишком осторожны, когда «склоняют чашу весов» слишком далеко, поэтому я попытался пойти на компромисс с Sandstein в том, что, на мой взгляд, было осторожным изменением формулировок, открывающим дверь для блокирования обзоров по вопросам, не связанным с политикой. но не слишком широко. (мое фактическое мнение немного более широкий, хотя и признавая озабоченность isaccl на что - то слишкомшироко.) Ни один из вариантов не говорит прямо, что «любой редактор может подавать апелляцию по любой причине, по своему желанию». Таким образом, в лучшем случае вариант 2 по-прежнему тщательно сформулирован, а вариант 3 просто возвращается к тому, что, по мнению редакторов, есть статус-кво (без его документирования) (что в значительной степени соответствует WP: BP : вы можете, но руководствуйтесь здравым смыслом). ProcrastinatingReader ( разговор ) 22:44, 22 марта 2021 (UTC)

  Я бы добавил, что, по моему опыту, администратор, совершающий предположительно проблемное действие, редко отступает в локальных обсуждениях (возможно, потому, что он твердо верит в свое действие или аспект сохранения лица, или и то, и другое). Действительно, во всех действиях, которые я апеллировал к AN, которые были отменены, все администраторы отказывались отменить свои действия. На самом деле это не обвинение администраторов (люди, естественно, могут не согласиться с применением политики), просто тот факт, что я думаю, что «вы можете обсудить с администратором блокировки» (из текущего текста), беззубый / бесполезный на практике. ProcrastinatingReader ( разговор ) 22:54, 22 марта 2021 (UTC)

Что касается тех, кто поддерживает вариант 3, так как редакторы могут не знать, как подать апелляцию, или они будут подавлены: мне не нравится, когда сообщество подает апелляцию от их имени, не обсудив ее предварительно с ними. Коммуникация - это основополагающий принцип совместного проекта. Мы должны попытаться работать с заблокированным редактором, чтобы определить лучший путь вперед, а не предполагать, что нам лучше всего известно. isaacl ( разговор ) 23:29, 24 марта 2021 (UTC)

ИМО: непосредственная проблема с этой точкой зрения [4] . Есть несколько второстепенных проблем, начиная от конфронтации и резонанса (аналогично страхам перед запуском RfA) до роли сообщества в подотчетности администратора (если плохое действие настолько болезненно, что редактор уходит, а другие редакторы не могут. запросить пересмотр с сообществом, является ли ArbCom теперь единственным выбором?). Блокировка - самая острая палка в арсенале инструментов. Его также следует использовать наиболее осторожно и подвергать наибольшему количеству проверок, когда это не так. ProcrastinatingReader ( разговор ) 23:34, 24 марта 2021 (UTC)

Всегда есть особые обстоятельства, с которыми можно справиться по-разному. На мой взгляд, это не гарантирует отмены каких-либо ограничений (согласно варианту 3) в отношении того, кто может подавать апелляцию. Когда есть возможность общаться с заблокированным редактором, мы должны попытаться это сделать, и это не создает значительных препятствий для проверки действий администратора. isaacl ( разговор ) 00:16, 25 марта 2021 (UTC)

Полагаю, вы не возражаете против варианта 2? Как мне кажется, ваше заявление действительно приведет к серьезным препятствиям, если вы также выступите против варианта 2 (это будет означать, что ArbCom - единственный жизнеспособный вариант [хотя, согласно средству 5.x, эта жизнеспособность находится под вопросом]).

Для варианта 3: я видел продуманные апелляции от третьих лиц, таких как Ritchie333 , которые помогали в делах (в некоторых - нет, но обычно потому, что редакторы говорят, что сторонние апелляции плохи, что зацикливается на этом самом РФК). Я считаю, что WP: UBCHEAP может применяться во многих случаях, и, что более важно, я действительно не верю, что искусство создания убедительного блокирования / более широких отношений с сообществом имеет много общего с тем, научился ли кто-то и может ли он быть продуктивным редактором. ProcrastinatingReader ( разговор ) 00:46, 25 марта 2021 (UTC)

Я не люблю перечислять конкретные обстоятельства; Я считаю, что отдельные дела следует оценивать по существу. Мне не нравится, что нет никаких упоминаний о попытках работать с заблокированным редактором. Были прекрасные апелляции от третьих лиц; Я также видел жалкие сторонние апелляции. Дело не в том, что заблокированный редактор должен научиться делать кадриль с лобстером . Было бы неосмотрительно действовать от чьего-либо имени, даже не пытаясь согласовать действия с ними и не понимать, что они хотят делать дальше. isaacl ( разговор ) 01:00, 25 марта 2021 (UTC)

Во втором тайме это справедливый момент. Стоит отметить, что и вариант 1, и вариант 2 в основном были написаны одним редактором, не проходя через этапы написания политики (отсюда мой акцент на образце текста). Я не чувствовал особого значения, потому что в этом конкретном RFC я хотел бы увидеть решение более широкой идеологической проблемы. Я согласен добавить текст о передовых методах рассмотрения апелляций третьих лиц, если будет принят вариант 2. Хотя я действительно думаю, что обзоры блоков или критика блокирующего администратора отличаются от апелляции от имени человека (по общему признанию, тонкая грань). По первой части я до сих пор не слежу; конечно, с вариантом 1 случаи не могут быть оценены по существу, так как это 'как полный запрет на апелляции третьих лиц? ProcrastinatingReader ( говорить) 01:16, 25 марта 2021 г. (UTC)

По общему принципу, к любому руководству всегда могут применяться особые обстоятельства; начните перечислять некоторые исключения, и люди могут начать думать, что это единственные особые случаи. В данном конкретном случае термин «проблемный» настолько широк, что почти все можно отнести к этой категории. isaacl ( разговор ) 01:31, 25 марта 2021 (UTC)

• Подлинный вопрос, могу ли я спросить тех, кто голосует за вариант 3!, Почему они думают, что вариант 2 (или что-то еще, что кто-то может захотеть) не будет вашим предпочтительным выбором? Если это просто «предпочитаю не иметь больше правил», это имеет смысл, но, предположительно, любая блокировка, которую кто-то поставит под сомнение, по их мнению, является проблематичным? Nosebagbear ( разговор ) 13:58, 26 марта 2021 (UTC)

  Потому что сообществу нужна максимальная свобода для решения проблем, связанных с неправильным суждением сисопа. Если я увижу, что сисоп передает проблемный блок, я хотел бы быть полностью свободным, чтобы обсудить это с сообществом. И вполне может быть, что мое непредсказуемое, бескорыстное выражение озабоченности по поводу блокировки более убедительно для сообщества, чем озабоченность цели. - S Marshall  T / C 18:03, 27 марта 2021 г. (UTC)

  @ S Marshall : но вы говорите, что это проблемный блок, поэтому он, конечно же, подпадает под предложение 2? Nosebagbear ( разговор ) 16:28, 31 марта 2021 (UTC)

• Просто в качестве общего примечания; Я не видел четвертого варианта, который позволял бы просто разрешить сторонние запросы относительно проверки блоков. Похоже, это не предлагало каждому абсолютно беспристрастного количества вариантов с полностью нейтральной точки зрения . Huggums537 ( разговор ) 09:03, 2 апреля 2021 (UTC) Отметьте последнюю часть. Мне не нравится, как это звучит. Мне просто было любопытно, почему не придумали четвертый вариант, вот и все. Без обид на ОП. Huggums537 ( разговорное ) 10:27, 2 апреля 2021 (UTC)
• Кроме того, я на какое-то время ушел из проекта. Что это за чушь о первом и втором выборе? Как приближение должно это подсчитать? Huggums537 ( разговор ) 12:58, 3 апреля 2021 (UTC)
• Я видел, как много людей говорили о корректировке рекомендаций в соответствии с «обычной практикой» и «текущими нормами», но какое это имеет отношение к чему-либо? Это все равно, что сказать: «Уровень преступности у нас очень низкий, и в настоящее время нормой является низкий уровень преступности, поэтому мы должны писать наши уголовные законы, чтобы отметить, что преступность не является обычной практикой». В этом нет никакого смысла, и на самом деле он не служит явно действительной или полезной цели. Также напрашивается вопрос, зачем кому-то нужны такие обозначения в руководящих принципах. Huggums537 ( разговорное ) 01:19, 5 апреля 2021 (UTC)

Определите "недавно" для CSD R3

Википедия: Критерии для быстрого удаления # R3 : «Этот критерий не применяется к перенаправлениям, созданным в результате перемещения страницы, если только перемещенная страница не была также создана недавно».

Здесь "недавно" не определено, из-за чего на Fastily кричали за удаление R3 при перенаправлении , которому не хватило дня .

Предложение: определите «недавно» как «менее месяца назад». (т. е. если страница создается 2 февраля, последний день для получения права на получение CSD R3 - 1 марта) - Alexis Jazz ( поговорите или напишите мне) 15:32, 23 марта 2021 г. (UTC)

Думаю, месяц - это самое подходящее время. Большим препятствием для R3 на самом деле должна быть очевидная неправдоподобность, а не точная недавность - и то, что имело смысл в 2006 году, сейчас может показаться неправдоподобным, но должно быть обсуждено, но то, что сейчас кажется неправдоподобным, вероятно, все еще выглядело неправдоподобным в феврале 2021 года. раньше не думали, что это нужно кодифицировать, но если люди действительно поднимают шум на основе недавнего переадресации, когда это происходит с перенаправлением дневной давности, возможно, стоит сделать настоящую сплошную линию. Я также хотел бы упомянуть, что я просто не могу читать {{ db-redirtypo }} без того, чтобы мой мозг считал это как «re-dirty-po». ~ m a z c a ^talk 15:47, 23 марта 2021 г. (UTC)

• Как я указывал в WP: VPI # Define «недавно» для CSD R3 , я бы предпочел немного больше, но это приемлемо. Я бы также предпочел, чтобы нам не приходилось объяснять это, но ясно, что мы делаем - на практике не так часто, когда люди жалуются на быстрое удаление старых перенаправлений, как на людей, жалующихся на отклонение старых перенаправлений . - Cryptic 16:07, 23 марта 2021 г. (UTC)

Это неоднократно возникало в RfD на протяжении многих лет, и приблизительный консенсус всегда заключался в том, что твердого ограничения нет, но оно измеряется неделями, а не месяцами (или, косвенно, днями, но я не помню, чтобы это приближалось. ). Как правило, чем неправдоподобнее, тем снисходительнее люди относятся к новизне. Если действительно есть необходимость четко определить это, то 1 месяц, конечно, приемлем, но я не уверен, что такая необходимость есть. Мне могло бы показаться достаточным просто записать консенсус «недели, а не месяцы» в качестве руководства. Тридуульф ( разговор ) 16:54, 23 марта 2021 (UTC)

Здесь нет реальной проблемы, просто Быстро быть более консервативным, чем они должны быть. Рассматриваемое перенаправление, вероятно, могло быть быстро удалено по запросу единственного создателя страницы. Ничего страшного, давайте продолжим нашу жизнь. Ойярбепси ( разговор ) 17:24, 23 марта 2021 (UTC)

Я с Ойярбепси не вижу здесь никаких проблем, если только ее нельзя показать ссылкой на настоящий крик, а не отчетом из вторых рук. Как и большинство вещей, его лучше оставить довольно расплывчатым, потому что яркие линии, как правило, приводят к играм. Фил Бриджер ( разговор ) 19:39, 23 марта 2021 (UTC)

Что касается « ссылки на настоящий крик », Alexis Jazz уже просил об этом, и я отказался, потому что этому сайту действительно не нужна дополнительная драма. Давайте сосредоточимся на определении подходящего интервала, исходя из его собственных достоинств. - F ASTILY 22:41, 23 марта 2021 (UTC)

• Этот вопрос время от времени поднимается (например, в этих двух дискуссиях из 2019 года). Один месяц согласуется с мнением большинства людей, но у меня сложилось впечатление, что существует широкое согласие с тем, что гибкость - это хорошо, а наличие четко установленной точки отсечения нежелательно. - Уанфала (разговор) 11:57, 27 марта 2021 г. (UTC)

@ Uanfala : Проблема в том, что некоторые люди интерпретируют «недавно» как «24 часа», а другие как «несколько лет». (Википедии 20 лет, поэтому все, что было создано за последние 2 года, было создано недавно) Моя личная интерпретация длилась около недели, но теперь я буду использовать месяц в качестве ориентира, когда я увидел, что большинство людей интерпретируют это именно так. . Не могли бы мы, по крайней мере, изменить «недавно» на «недавно, обычно около месяца» или что-то еще, чтобы дать читателям приблизительную оценку? - Alexis Jazz ( поговори или позвони мне) 05:36, 28 марта 2021 г. (UTC)

Учитывая, что другие вызвали беспокойство, возможно, было бы неплохо внести предложение. - The SandDoctor ^Talk 05:46, 28 марта 2021 г. (UTC)

• Я бы поддержал упоминание в документации чего-то вроде «Ожидается, что пользователи и администраторы будут проявлять осмотрительность, но приблизительный ориентир для« недавних »должен составлять один месяц». Элли ( Обсуждение | вклад ) 01:48, 31 марта 2021 (UTC)
• хорошо, что предыдущая дискуссия приближалась к 30-дневному добавлению к тексту, но теперь дебаты начинаются снова. Я думаю, мы должны добавить эти 30 дней, чтобы дать гида и планку. Во многих случаях это означает, что удалитель должен проверить, когда было создано перенаправление, но я надеюсь, что они уже это делают! Грэм Бартлетт ( разговор ) 07:21, 31 марта 2021 (UTC)

Слово «недавний» необходимо определить для первого упоминания в R3; при использовании позже (например, в разделе, цитируемом OP), он должен означать то же самое. 147.161.8.151 ( разговорное ) 23:32, 12 апреля 2021 (UTC)

• 30 дней звучит достаточно долго, чтобы люди это заметили. Я отмечаю, что CSD A10 также не имеет определенного «недавнего» отсечения, и я бы рекомендовал тот же порог там. - Прачечная Пицца 03 ( d c̄ ) 21:17, 14 апреля 2021 г. (UTC)

RfC: Известность вымышленных персонажей

• Поздний комментарий - я согласен с приведенными выше комментариями с одним дополнением: существует достаточно высокая вероятность того, что если актер, изображающий персонажа, получил награду за изображение, персонаж также получил хотя бы некоторое освещение. Сделайте тщательный поиск этого покрытия WP: ПЕРЕД назначением. Blueboar ( разговор ) 21:32, 27 марта 2021 (UTC)

  Да, это хорошее замечание. Эмир Википедии ( разговор ) 22:41, 27 марта 2021 (UTC)

• @ Theleekycauldron : Не могли бы вы прояснить близкое заявление? Сейчас это технически заявляет , что кто - то выиграть Grammy не примечателен , ни кто - то получил Нобелевскую премию и т.д. Эти вещи могут сделать кого - то примечателен своими силами за то , что получил его за WP: NMUSICIAN / NBAND, Википедия: значительность (академиков) , (части) Википедия: Известность (спорт) и сам WP: ANYBIO / NBIO. Оператор закрытия должен выявлять особенности вопроса, чтобы указать его объем (например, что-то вроде«Был достигнут консенсус, что вымышленный персонаж в фильме или телесериале не считается выдающимся исключительно из-за того, что персонаж в реальной жизни получил главную награду за свое изображение». ) - The SandDoctor ^Talk 04:06, 28 марта 2021 г. (UTC)

  @ TheSandDoctor : ага… извини, иногда я тупица. Я изменю заключительное заявление. - Предыдущий неподписанный комментарий, добавленный Theleekycauldron ( обсуждение • вклад ) 08:18, 28 марта 2021 г. (UTC)

  @ Theleekycauldron : Все хорошо! Мы все делаем ошибки и т. Д. Спасибо за исправление объема заключительного заявления. - The SandDoctor ^Talk 08:56, 28 марта 2021 г. (UTC)

  @ TheSandDoctor : проблема, спасибо :) theleekycauldron ( обсуждение • вклад ) ( они / они ) 20:31, 28 марта 2021 (UTC)

• РЖУ НЕ МОГУ. Это было довольно очевидно. VP не обязательно увязать в RfC с предсказуемым исходом. Просто поищите сохранившиеся примеры, подтверждающие правоту. Например, Линда Хант (бесспорно примечателен актер) получила Оскар (бесспорно примечательна премия) среди других наград за ее кросс-пол и кросс-этнической роль в Годе опасной жизни (бесспорно примечателен фильм). Но персонаж не особо известен, и почти никто не помнит его имени. Точно так же Фишер Стивенс (известный актер) сыграл межэтническую роль в « Коротком замыкании» (известный фильм) и (с необъяснимым изменением фамилии персонажа в бессмысленном ретконе) его продолжении прямого видео « Короткое замыкание 2».(малозаметный фильм). Тем не менее, персонаж, чье запутанное имя никто не помнит, не является независимо заметным - несмотря на множество споров вокруг этих изображений, в результате которых Стивенс даже на неопределенный срок стал персоной нон-грата , которому запретили ездить в Индию. Такой славы и дурной славы придерживаются актеры, а не персонажи.  -  SMcCandlish ☏ ¢  😼  05:11, 31 марта 2021 г. (UTC)

Что является подлинным вторичным источником дат рождения?

MOS: BIRTHDATE говорит, что все биографии должны открываться абзацем, содержащим дату рождения субъекта, но WP: BLPPRIMARY запрещает использование первичных источников для такого рода информации и вместо этого требует, чтобы информация "обсуждалась надежным вторичным источником. " (Далее WP: BLPPRIVACY требует, чтобы этот источник был «широко опубликован», что бы это ни значило.) Вторичный источник, согласно WP: SECONDARY , «обеспечивает собственное мышление автора, основанное на первичных источниках» и «содержит авторский анализ, оценку, интерпретация и т. д. Но кроме, может быть, псевдоспоров, таких как свидетельство о рождении Обамы, дата рождения человека никогда не «обсуждается» опубликованными источниками в той мере, в какой она заслуживает ранга вторичного источника. Итак, мой вопрос: что на самом деле подразумевают WP: BLPPRIMARY и WP: BLPPRIVACY и какие источники допустимы?

Приведу несколько примеров:

• Является ли NBC Sports основным источником информации о рождении такого маргинального игрока НФЛ, как Тэ Краудер ? Здесь не указывается источник информации, сайт ничего не оценивает и не обсуждает.
• Являются ли официальные файлы Библиотеки Конгресса первичным источником информации о докторе профессии университетского профессора, такого как Каннан Соундарараджан ? Оргкомитет обычно указывает источник информации (например, «Информация из архивов Принстонского университета»), но обычно не рассматривает информацию в какой-либо форме. И, по-видимому, сами Принстонские архивы тоже не являются допустимыми источниками.
• И я полагаю, что опубликованное самостоятельно резюме не может считаться достоверным источником даты рождения Марка Даггана , поскольку оно очевидно является первичным.
• Как насчет кратких анкет в нишевом академическом журнале ? Он публикуется, но широко ли он публикуется? Кроме того, авторское размышление о DOB, кажется, снова отсутствует.
  Моя точка зрения: как на самом деле выглядит подлинный вторичный источник дат рождения? Если наша политика установит такую ​​высокую планку, мы сможем четко определить этот стандарт. Или может кто-нибудь хотя бы привести пример надежного источника, который передает как WP: BLPPRIMARY, так и WP: BLPPRIVACY? - bender235 ( разговор ) 16:33, 27 марта 2021 (UTC)

Я считаю, что только первый, NBCSports, определенно можно квалифицировать как вторичный источник, поскольку мы исходим из предположения, что они провели проверку фактов. LoC не занимается проверкой фактов и не имеет редакторов, поэтому они не могли бы удовлетворить вторичные запросы самостоятельно. Резюме определенно будет первичным. Последний, вероятно, устраивает вторичных, поскольку у них есть редакционная группа, хотя я не знаком с их спецификой. Slywriter ( разговор ) 16:48, 27 марта 2021 (UTC)

На каком именно основании мы можем сделать вывод, что NBC Sports проводит более тщательную проверку фактов, чем Библиотека Конгресса? - bender235 ( разговор ) 17:49, 27 марта 2021 (UTC)

MOS: BIRTHDATE не говорит, что все биографии должны открываться абзацем, содержащим дату рождения субъекта. Вы пропустили важнейшее слово «обычно». Возвращение к MOS: OPENPARABIO показывает, что это объяснение предложения «даты рождения и смерти, если они найдены во вторичных источниках». Если дата не найдена в таких источниках, ее следует опустить. Фил Бриджер ( разговор ) 17:06, 27 марта 2021 (UTC)

Но это как раз мой вопрос: как выглядит такой вторичный источник? - bender235 ( разговор ) 17:47, 27 марта 2021 (UTC)

Что касается узкого вопроса о разнице между вторичным источником и первичным источником, каждый из источников, которые вы указали выше, является вторичными. Первичный источник - это такой источник, как свидетельство о рождении, свидетельство о крещении, записи переписи населения и т. Д. Независимо от того, являются ли какие-либо из приведенных вами источников хорошими вторичными источниками этой информации, я не буду комментировать, но новостные организации, профили работодателей, и даже резюме являются вторичными источниками, потому что они сообщают о том, что будет в первичных источниках. - Джейрон, 32 16:26, 29 марта 2021 г. (UTC)

• Комментируя "широко", примером может быть Мик Джаггер . Примеры источников (без определенного порядка / как они показаны в моих результатах в Google): New Yorker , CNN , USA Today , The History Channel , Today , Boston.com , iHeart Radio и Vogue . Я мог продолжать, это было около 3 минут поиска, каждая из которых давала дату и возраст на тот момент; нет разногласий по дате / году / возрасту и т. д. Без перечисления примеров источников, Тейлор Свифт была бы другим примером. - The SandDoctor ^Talk 18:34, 27 марта 2021 г. (UTC)

  Да, эти люди супер-знатные, так что такие источники будут. Возможно, MOS: BIRTHDATE следует использовать более слабое слово, чем «обычно». Я не провел необходимых исследований, и я сомневаюсь, что это сделал тот, кто вложил это слово в MOS, но я почему-то сомневаюсь, что у подавляющего большинства известных субъектов есть надежные вторичные источники даты рождения. В другом месте я комментировал одержимость редакторов Википедии включением национальной идентичности субъекта в начальное предложение, даже если оно не получено из хорошего источника. То же самое и с датой рождения. В большинстве случаев важны место и временные рамки, в которых объект достиг значимости, а не такие детали. Фил Бриджер ( разговор ) 19:10, 27 марта 2021 (UTC)

  Если таковы стандарты, 99% биографий в Википедии должны быть без даты рождения. Я имею в виду, попытайтесь найти столько источников новостей о случайном легкоатлетическом спортсмене , актере или судье и так далее. Потому что, опять же, мы говорим не об одном надежном источнике (на WP: RS), а о нескольких широко опубликованных вторичных источниках. - bender235 ( разговор ) 19:40, 27 марта 2021 (UTC)

  Используйте WP: COMMONSENSE / IAR, когда правила приводят к странному выводу. - Зеленый C 19:44, 27 марта 2021 г. (UTC)

  @ GreenC : не вариант. Люди, как правило, очень рьяно используют свое приложение WP: BLPPRIVACY, стремясь к театру конфиденциальности для защиты якобы конфиденциальной информации, которая на самом деле уже является общедоступной. - bender235 ( разговор ) 15:00, 28 марта 2021 г. (UTC)

• ( править конфликт ) Это два самых опытных музыканта в современной истории, так что определенно. Я бы поддержал слово послабее, чем «обычно», по причинам, которые вы перечисляете, Фил Бриджер . - The SandDoctor ^Talk 19:50, 27 марта 2021 г. (UTC)

• DOB также можно указать в достойном источнике WP: BLPSELFPUB , если таковой существует. Отмечен Twitter и т. Д. Резюме OP: s Марка Даггана соответствует " опубликованным надежными источниками или источниками, связанными с предметом, так что можно сделать разумный вывод, что субъект не возражает против обнародования деталей ". Лично я не знаю Нет проблем с тем, что 99% BLP: s не имеют даты рождения. Gråbergs Gråa Sång ( разговорное ) 20:06, 27 марта 2021 (UTC)

  Я согласен со Slywriter. Все сводится к ожидаемой проверке фактов. Я ожидал, что NBCSports проверит факты. Я не ожидаю, что записи Библиотеки Конгресса будут проверены фактами, и я встречал статьи, в которых мы игнорировали LOC как надежный источник для dob. Краткие профили сомнительны, поскольку информация часто поступает из анкеты или формы, отправленной субъекту, который не проходит независимую проверку фактов. Если есть разногласия с разными источниками, следует отдавать предпочтение тем рефералам, в которых можно ожидать проверки фактов. - Hipal ( разговор ) 21:02, 27 марта 2021 г. (UTC)

• Единственный случай, когда в биографии было бы неправильно не указывать дату рождения, - это когда их дата рождения была / была предметом значительных комментариев ( Трейси Лордс - первый пример, который приходит на ум), но по определению это означает есть несколько надежных источников, в которых он представлен, поэтому проблем не возникает. Для людей, дата рождения которых не вызывает споров и нет доказательств того, что они возражают против ее публикации, можно использовать первичный источник , если нет надежных вторичных источников. Вопрос о том, следует ли использовать такой первоисточник , является предметом консенсуса в каждой статье.
  Если источники противоречат друг другу и противоречие не обсуждается, укажите варианты / диапазон (применяя такие квалификаторы, как «большинство источников указывают X», если это правда), либо просто опустите его. Тридуульф ( разговор ) 11:25, 28 марта 2021 (UTC)

Политика РГ: BLPPRIMARY запрещает публичные записи с использованием в качестве основного источника информации о дате рождения живого человека. Это ограничение не распространяется на умерших. Так что эту ветку действительно следует разделить на две разные темы: одну для мертвых, а другую - для живых. Jc3s5h ( разговорное ) 14:07, 28 марта 2021 (UTC)

Это хороший момент. Эмир Википедии ( разговор ) 14:37, 28 марта 2021 (UTC)

Я думаю, что вполне приемлемо использовать самоизданный источник для даты рождения человека, если этот человек в остальном примечателен и если они согласны с тем, что эта информация присутствует в Википедии. С другой стороны, только потому, что человек публикует дату своего рождения в своем резюме на своем веб-сайте, он не обязательно хочет, чтобы она была включена в его статью в Википедии. Если тема статьи появляется (будь то в качестве редактора, через OTRS или как-то иначе), следует уважать их предпочтения относительно того, должна ли статья включать дату их рождения или нет. Mr248 ( разговор ) 23:49, 31 марта 2021 (UTC)

Я имею в виду, конечно, что вы можете использовать свидетельство о рождении человека как источник его даты рождения. Фактически это самый надежный источник. Даже свидетельства о рождении не всегда верны, но они более надежны, чем любой другой источник, поэтому использование любого другого источника намеренно повышает вероятность ошибки. Не делай этого. Если есть какое-то правило против этого, ну, здесь много правил, и это глупо, так что игнорируйте его.

Если человек не хочет, чтобы его дата рождения была опубликована, это, конечно, было бы иначе - вы бы захотели уважать это, если можете. Я считаю, что предполагается, что дни рождения в верхней части статьи - это нормально, если человек специально не просит нас не делать этого. Это очень ключ к базовому пониманию предмета (ну, по крайней мере, год). Если вы ищете актера, спортсмена или кого-то еще, важно сразу знать, 20 или 45 лет и так далее. Вот почему мы всегда это делаем. Я никогда не видел, чтобы это было незавершенным, кроме случаев, когда информация не известна или никто еще не дошел до нее. Это то, что мы делаем. Предполагается, что правила кодифицируют передовой опыт. Игнорируйте глупые правила. Герострат ( разговор ) 07:30, 2 апреля 2021 (UTC)

Герострат, Есть правило против использования свидетельств о рождении. Это совсем не глупое правило. Если дата рождения человека еще не известна, Википедия не должна делать ее общедоступной. Если редактор каким-то образом обнаруживает свидетельство о рождении объекта статьи, ему не следует добавлять информацию из этого документа в статью, которая еще не является общедоступной. Во многих (но не во всех) юрисдикциях свидетельства о рождении будут выдаваться только человеку и его близким родственникам (их родителям, иногда другим родственникам, например детям), поэтому они являются своего рода частными документами, и вы не должны размещать их в частном порядке. информация о ком-то в Википедии. (Все могло бы быть иначе, если бы все в их свидетельстве о рождении было уже известно широкой публике из средств массовой информации,и т. д., но это, вероятно, будет верно только для очень известных людей.)Mr248 ( разговор ) 03:08, 5 апреля 2021 (UTC)

Пользователь: Mr248 , хорошо, я понимаю вашу точку зрения. Это проблема конфиденциальности, проблема WP: BLP . Это другое, и хорошо, да, в этом есть смысл. Я думал о (несколько глупом ИМО) призыве в WP: RS не использовать первоисточники в целом .... я полагаю, чтобы в основном не выбирать вишенки. Трудно выбрать даты рождения.

BLP в своей «Конфиденциальности личной информации и использовании первоисточников» двусмысленна. Он говорит , используя рождение года в порядке, и это своего рода неясно ли вы должны или не должны предполагать , что что субъекты не хотят , чтобы их жизненно информация опубликована , если они не сделали никаких признаков этого.

Но если предполагается, что мы не должны этого делать, нам, вероятно, также не следует использовать вторичные источники. Тот факт, что кто-то другой откопал чью-то жизненно важную статистику и опубликовал ее, не так уж сильно влияет на нас. Во-первых, наши статьи часто занимают высокие позиции в результатах Google для человека и, таким образом, составляют большую часть его публичного лица, а во-вторых, наши данные, вероятно, будут сохраняться и отслеживать человека в течение долгого времени. Есть большая разница между Terra Haute Times-Dispatch, публикующим дату рождения человека, и нами. В первом случае информацию можно найти, если действительно захочется и она будет копаться (по крайней мере, сейчас - но, может быть, не через 20 лет), во втором случае она навсегда останется на виду у всего мира. Большая разница.Герострат( разговор ) 04:52, 5 апреля 2021 (UTC)

Я предполагаю, что одна проблема с датой рождения - это кража личных данных. Вот почему BLP говорит, что давать только год лучше. Тем не менее, многие люди не хотят, чтобы мы знали их возраст или, во всяком случае, трубили во всем мире. Возможно, место рождения - Т.С. Элиот родился в Сент-Луисе, а Эзра Паунд родился в Хейли, территория Айдахо, и вполне возможно, что они предпочли бы, чтобы мир забыл об этом (если бы они были живы).

Тем не менее, я практически никогда не видел статьи, в которой намеренно опускалась бы какая-либо важная статистика ... Это обычная практика. Даже для Джеки ДеШаннон мы указываем год ее рождения, хотя я думаю, что она хотела бы, чтобы люди думали, что она моложе. Это не хорошо. Но обычная практика такова.

Я либерален и экспансивен в отношении прав субъектов BLP, поэтому, поразмыслив, я изменил свое мнение по сравнению с моим заявлением выше, и со своей стороны я буду избегать добавления важных характеристик, кроме национальности, в любые другие (живые) биографии, которые я пишу. Но BLP на самом деле этого не требует, по крайней мере, явно, и я ожидаю, что другие редакторы придут и добавят это. Я не могу это контролировать, но я все равно могу контролировать то, что делаю сам. Герострат ( разговор ) 04:33, 5 апреля 2021 (UTC)

Herostratus , в целом я согласен, но хотел бы отметить два момента. Во-первых, но если предполагается, что мы не должны этого делать, нам, вероятно, также не следует использовать вторичные источники.- это в некоторой степени зависит от источника. Например, для профессора университета, если в его официальной биографии, опубликованной на веб-сайте университета, указана дата его рождения, его, вероятно, можно использовать. А если это напечатала какая-то малоизвестная газета, может и нет. Во-вторых, я думаю, это также зависит от того, насколько кто-то общественный деятель. Я думаю, что кого-то, кто является очень публичной фигурой, например, высокопоставленным политиком, меньше опасений по поводу частной жизни, чем кого-то гораздо менее известного - например, художника, о котором многие люди никогда не слышали. (Приведенный вами пример - один из таких - я никогда раньше о ней не слышал и уверен, что я не единственный человек в этой категории.) Mr248 ( разговор ) 04:46, 5 апреля 2021 г. (UTC)

Применимы ли соображения конфиденциальности даже в том случае, если первичный исходный документ может быть легко найден любым человеком, использующим Интернет? Записи LOC, во-первых, легко доступны. BD2412 T 04:48, 5 апреля 2021 г. (UTC)

Пользователь: BD2412 , да. MOS: BIRTHDATE и MOS: BIRTHPLACE являются руководящими принципами, но презумпция конфиденциальности более важна. РГ: BLP - это политика, которая превосходит руководящие принципы. Это неоднозначно относительно того, когда можно публиковать важную информацию, но в нем говорится: «Википедия включает полные имена и даты рождения, которые были широко опубликованы из надежных источников ...» (курсив мой). Термин «широко» открыт для толкования, но BLP следует толковать свободно, исходя из презумпции конфиденциальности.

«Легко найти», я полагаю, означает «Если человек хочет копать» (я не знаю, что такое LOC-запись. Если это не высокий результат при поиске в Google по этому человеку, то его «не легко найти». ) Есть большая разница между «человек, который действительно хочет знать, что это может найти», и тем, как мы вечно кричим об этом миру. В противном случае BLP не имеет смысла. Герострат ( разговор ) 05:02, 5 апреля 2021 (UTC)

Пользователь: Mr248 , верно. Нам не нужно пропускать день рождения Эммануэля Макрона или что-то еще. Что касается официальной биографии колледжа ... я думаю ... это уже вид публичного лица, наверное. Если придется копать, чтобы найти, может и нет. Это возможно , что человек ума «Тьфу, я не могу остановить их публиковать свою жизненную статистику, но я предпочел бы мир не знал , что я 60 лет ». Полагаю, это на самом деле не демонстрирует разрешения.

Интересно, что интервью без проверки (где человек сообщает дату или год своего рождения) является хорошим показателем того, что она не возражает против того, чтобы мы его опубликовали, но само это не является хорошим источником. Люди - не лучший источник информации о дате своего рождения. Нам нужно будет найти другой источник (и он должен соответствовать тому, что сказал человек). Герострат ( разговор ) 05:12, 5 апреля 2021 (UTC)

Что касается Джеки ДеШаннона, если вы просто не укажете дату рождения ... кто-то придет и скажет: «О, жизненно важные характеристики отсутствуют, я добавлю их!» а затем введите либо ее реальный год рождения (нарушение BLP), либо тот, который она указала (предоставив читателю ложную информацию). Так что не знаю решения. Герострат ( разговор ) 05:19, 5 апреля 2021 (UTC)

Статьи могут содержать примечания для редакторов в html-комментариях, в которых говорится что-то вроде «не добавляйте дату рождения, см. Обсуждение» с объяснением на странице обсуждения того, почему в статье нет даты рождения. Если кто-то добавит его, его можно будет отменить. Я не знаю, можно ли их легко найти, но Анушай Аббаси содержит пометку в информационном поле «<! - Не добавляйте дату рождения без ссылки на надежный источник в тексте. ->». Тридуульф ( разговор ) 10:48, 5 апреля 2021 (UTC)

Поиск неясных технических тем

Многие темы не освещаются в мире программного обеспечения, а обсуждение ограничивается проблемами github, форумами и Reddit. Но есть множество знаний, которые не задокументированы в Википедии из-за того, что источники воспринимаются как ненадежные. Есть ли способ сделать их надежными, скажем, с помощью службы проверки вики, которая позволила бы цитировать эти ценные «киберфарменские» знания? Наблюдая за тем, как многие АФД идут по неверному пути на протяжении многих лет, я чувствую, что здесь необходимо наладить надлежащий процесс. Тот же процесс можно использовать для извлечения информации из тем, затронутых систематической предвзятостью, а также для преобразования источников ИСП в нейтральные. 94.175.6.205 ( разговорное ) 15:54, 28 марта 2021 (UTC)

Если техническая область не охвачена вторичными источниками, WP не подходит для ее освещения. Темы программного обеспечения неясны, потому что они интересны лишь небольшому количеству людей - M asem ( t ) 15:57, 28 марта 2021 г. (UTC)

По словам Масема, освещение из надежных источников - вот что делает эту тему достойной пищей для статьи в Википедии . Если что-то существенно не освещено надежными источниками, это не подходящая тема для статьи в Википедии. Недостаточно того, что много людей говорят об этом на Reddit. - Джейрон, 32 16:37, 29 марта 2021 г. (UTC)

Можно цитировать профильных экспертов даже из ненадежных источников. OwO ( что это? ) 09:09, 1 апреля 2021 г. (UTC)

Здесь есть еще один фактор: способность редакторов-добровольцев создавать точную энциклопедию. Мы не эксперты. Мы не репортеры. Но мы внимательные читатели. Википедия работает только в том случае, если мы используем надежные вторичные источники, которые консультируются с несколькими экспертами, готовят отчеты и проверяют их работу. Я мог легко обмануть людей за пределами моей области, указывая на набор не очень хороших источников, особенно если язык был достаточно техническим. И ты тоже можешь меня обмануть в своей сфере. Но если эта тема освещается в регулярной прессе, кто-нибудь с Google сможет отсеять второстепенные теории. Звучит экстремально, но раньше такое случалось часто. Возможно, вы были достаточно долго, чтобы это увидеть. До WP: MEDRS , WP: COI и аналогичные WP: PRIMARYреформ, малоизвестные компании помещали свои сомнительные товары для здоровья в Википедию, цитировали три спонсируемых ими исследования с участием 15 человек в каждом и высказывали свои сомнительные заявления голосом Википедии. Поскольку они были совершенно непонятными, противоречащих друг другу исследований не было. Единственное, что избавило Википедию от этого кинопламени, - это требование более качественного поиска. Все это говорит о том, что я согласен с вами в том, что в программном обеспечении есть много вещей, которые из-за этого недостаточно хорошо освещены. Но у программного обеспечения также есть одни из самых сильных сообществ свободного знания. Они более хаотичны, чем википедия. Но они могли бы стать еще более хаотичными, если бы им было поручено выбрать единственный «правильный ответ» на определенные темы, на которые нельзя было бы ссылаться. (Обсуждения языков программирования,кто-нибудь?) Крис vLS ( разговор) 16:20, 10 апреля 2021 г. (UTC)

Являются ли официальные спутники телешоу независимыми источниками?

Конкретный пример здесь - эта книга . - Предыдущий неподписанный комментарий, добавленный Theleekycauldron ( обсуждение • вклад ) 04:53, 30 марта 2021 г. (UTC)

В целях заметности я бы сказал определенно нет, если он был произведен непосредственно для сопровождения шоу продюсерской компанией / сетью или для нее. На мой взгляд, они обычно будут надежными (в основном) первоисточниками для целей проверки, но WP: RSN - лучшее место, чтобы задать этот вопрос. Подходящий ли это источник будет зависеть от того, как и почему вы хотите его использовать. Тридуульф ( разговор ) 11:53, 30 марта 2021 (UTC)

Они не подтверждают, что тема подходит для отдельной статьи, но, поскольку это было установлено другими источниками, они вполне приемлемы для информации о рассматриваемом телешоу (т.е. резюме эпизодов, биографии персонажей и т. Д.). Несамостоятельные источники могут быть (и часто бывают) очень надежными для информации, но поскольку информация не показывает, что другие люди обратили внимание на предмет, это не означает известность. - Jayron 32, 14:03, 30 марта 2021 г. (UTC)

В частности, учитывая их пример, я думаю, что OP запрашивает только для целей использования его для информации, которую нужно добавить в статью, а не для определения того, должна ли в шоу быть статья. postdlf ( обсуждение ) 16:44, 30 марта 2021 (UTC)

• Что касается вопроса об использовании его для информации в уже известной статье, да, это нормально, но его следует использовать в разумных пределах для заполнения высокоуровневых деталей, которые не могут быть легко доступны для вторичного материала; этот тип работы не должен доминировать при поиске источника статьи. Например, я вижу такую ​​работу, чтобы установить для уже известного персонажа, где они родились и какое у них высшее образование; детали, которые могут быть скрыты в нескольких эпизодах, но легче просто указать на это, прежде чем статья перейдет к деталям характеристики и тому подобному, которые мы извлекаем из вторичного освещения. - M asem ( t ) 17:25, 30 марта 2021 г. (UTC)

  Да, это был мой вопрос. Я искал больше глубины - мне придется искать другие источники, чем. theleekycauldron ( обсуждение • вклад ) ( они / они ) 18:39, 30 марта 2021 (UTC)

• Очевидно, не WP: INDY , не более чем веб-сайт продюсера или интервью с автором, режиссером фильма, ведущим разработчиком игровой компании или кем-то еще, что подходит для сценария. Это все материалы WP: PRIMARYSOURCE и WP: ABOUTSELF . Его можно использовать с осторожностью, но только для определенных видов претензий., В основном , «голые факты» дела, и только тогда , когда нет ничего спорного или превозносящего об этом. ( «Развитие началось 13 мая 2001 года в нашем Бостонскоге офиса», вероятно , не является спорным утверждением, к примеру) . Когда дело доходит до точек сюжета, объяснения особенностей игры или системных требований, производство / анекдоты развития игрового / шоу / film и т. д., официальные сайты-компаньоны и книги, вероятно, актуальны и достаточно надежны для тривиальных вопросов, но вторичные источники будут лучше. И они не могут противоречить твердым вторичным источникам, которые доказывают, что они в чем-то не правы. И даже лучше первичных, как опубликованная версия самого произведения, которая более «канонична». Пример, близкий моему сердцу: моей первой сопутствующей книгой была книга по « Звездным войнам».(оригинальный фильм), и я получил его до того, как фильм действительно вышел. Это было в формате сборника рассказов с кадрами из фильмов в качестве иллюстраций. Вначале он показывает, как Люк встречается с Биггсом и другими его друзьями на Татуине. Я бы не смог использовать это как источник, чтобы вписать эти события в сюжет фильма в Википедии, потому что они не сделали окончательный монтаж фильма. Тем не менее, сохранившаяся копия этой книги была бы хорошим источником (возможно, для примечания в производственном разделе) этого материала (также являющегося частью сюжета новой версии), поскольку он был частью сюжета фильма, находящегося в разработке. какой-то момент, хотя бы частично снятый, и как это выглядело. (Не то чтобы нам это нужно, поскольку удаленные кадры, конечно, сейчас повсюду в Интернете. Но это все еще хороший пример.)  - SMcCandlish ☏ ¢  😼 04:54, 31 марта 2021 г. (UTC)
• Именно так сказал Пользователь: SMcCandlish . Они не независимы, они WP: ABOUTSELF , что и означает «официальный». Как указывает SMcC, это подходит для голых фактов, но не для пустых слов, которые вы можете там найти, вроде «первое шоу, чтобы показать ...» или «высоко оцененные» и т. Д. В идеале вы можете искать самые интересные лакомые кусочки или историй и найдите вторичные источники, которые их опубликовали (и проверили факты). Крис vLS ( разговор ) 16:35, 10 апреля 2021 (UTC)

Перепишите Википедию: Гражданство и национальность

Это неудавшееся предложение основано на ложном предположении, что «гражданство» - это правовой статус, а «национальность» - нет. Фактически, оба статуса являются юридическими. Гражданство - это правовые отношения между физическим лицом и суверенным государством, при которых физическое лицо несет перед государством обязанность верности, а государство несет перед физическим лицом обязанность по защите. Гражданство - это правовой статус наличия политических прав в суверенном государстве, таких как право голоса на выборах. В большинстве случаев они идут вместе, но реже иметь законное гражданство возможно без законного гражданства. Например, в законодательстве США есть понятие «неграждане», которые имеют гражданство США, но не имеют гражданства США - это означает, что они имеют право на получение паспорта США, но не могут голосовать на выборах в США. Прямо сейчас,единственными людьми, которые являются «негражданами» США, являются жители Американского Самоа, хотя естьсудебное дело, оспаривающее конституционность этого. Точно так же в Великобритании есть класс граждан, известных как « британские подданные без гражданства.«которые имеют британское гражданство, но не имеют британского гражданства. Действующее законодательство Великобритании не позволяет получить этот статус, поэтому он в конечном итоге вымрет - большинство людей с ним имели какие-то связи с бывшими колониями, но по какой-либо причине не приобрели национальность / гражданство нового независимого государства после обретения независимости (многие из этих людей - люди южноазиатского происхождения, проживающие в Африке и Юго-Восточной Азии - их происхождение в Индии / Пакистане было слишком далеким для получения индийского или пакистанского гражданства, и этим новым независимым государствам иногда отказывали. гражданство / национальность для этих меньшинств, оставляя им статус негражданина Великобритании как не очень полезный запасной вариант.)

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

В любом случае, я думаю, что даже помеченное как неудавшееся предложение иметь что-то в пространстве имен Википедии, что фактически неверно, проблематично. Я думаю, что это предложение должно быть написано так, чтобы четко указать, что и национальность, и гражданство являются правовыми статусами, и что, за редкими исключениями, любой, кто имеет один статус, имеет и другой. Это, в свою очередь, означает, что наличие отдельных параметров «Национальность» и «Гражданство» в инфобоксах - плохая идея, поскольку они очень редко будут различаться, и я думаю, что если вы посмотрите на случаи, когда используются эти два параметра, они очень редко используются с разными значениями (или одно из них предпочтительнее другого) из-за фактической правовой ситуации наличия гражданства без гражданства. Редкий статус граждан-неграждан можно просто выразить в скобках в "Национальность »вместо отдельного параметра« Гражданство ».@ SMcCandlish : поскольку вы написали предложение, которое я предлагаю, мы его переписываем. Mr248 ( разговор ) 03:26, 31 марта 2021 (UTC)

Хм? 01011000  ( обсуждение  · вклад ) написал это; Я просто переместил его на более понятное имя страницы и убрал некоторые из наиболее очевидных проблем в тексте. Честно говоря, я думаю, что выбросы, о которых вы упомянули выше, можно было бы просто описать в сносках, не повлияв на общую суть. «Национальность» и «гражданство» обычно используются в повседневной письменной речи и как обычно понимается подавляющим большинством наших читателей.имеют значения, указанные в этом предложении. Необычные юридические детали - это просто исключения, которые следует отметить вскользь, в сноске. Еще одно примечание - это предполагаемое британское употребление на местном языке, чтобы различать Великобританию как страну «мета-нации» и Англию и т. Д. Как субнациональные «страны». То же самое и использование слова «нация» для обозначения «этнического наследия» или «политического движения», и, вероятно, есть и другие. «Национальность» (в обычном смысле и даже в большинстве других смыслов, за небольшими исключениями) обычно не является юридическим вопросом; это социокультурный, а иногда и социально-политический конструкт (например, гендерные роли и что-то вроде « расы »).

Типичное решение - переместить неудавшееся предложение на такое имя, как Википедия: Гражданство и национальность (неудавшееся предложение) . Тем не менее, возможно, что эту часть можно «массировать» в пояснительное эссе (которое в основном уже есть), не пытаясь также быть правилом (которое уже было отвергнуто). Проблема, которую я вижу, заключается в том, что дошедший до нас текст продвигает чрезмерно упрощенную точку зрения, в то время как вы продвигаете точку зрения «скучать по лесу за деревьями» с другой стороны. Решение состоит в том, чтобы сохранить общий подход к основному тексту, а затем покрыть технические детали в сносках, чтобы они были там, но не погрязли в обычно неприменимых деталях.

Но если эта работа не будет сделана для создания разумного эссе, я согласен, что было бы проблематично сохранить его под текущим именем, поскольку оно претендует на установление правил или, по крайней мере, совета, и люди могут ссылаться на разделы или якоря в середине. -страница, так что люди не могут видеть баннер неудавшегося предложения. Таким образом, он должен либо содержать «неудавшееся предложение» в названии страницы, либо перестать давать прежние советы / правила. PS: не требуется консенсусного обсуждения, чтобы просто сделать это и переработать страницу, чтобы она больше не была неудавшимся предложением, а вместо этого представляла собой информативное эссе. Просто постарайтесь, чтобы полученный текст действительно соответствовал соглашению и служил информативным целям в отношении большинства ситуаций редактирования, а не был просто кучей волос по поводу необычных исключений (сноски, сноски). Такжеошибка двусмысленности ; все мы знаем, что любое слово может иметь несколько значений, и мы должны разделять их; спорить о том, что такое «национальность» и что означает «национальность» в обычном смысле этого слова, а затем изменить определение в середине потока на то, что относится, например, только к жителям Американского Самоа, и аргументировать на этой основе («Национальность также юридический вопрос »и т. д.) не принесет ничего полезного.
 -  SMcCandlish ☏ ¢  😼  04:41, 31 марта 2021 г. (UTC)

SMcCandlish А ? 01011000  ( обсуждение · вклад ) написал это; Я просто переместил его на более понятное имя страницы. Извините за путаницу, я неправильно прочитал историю редактирования. Термины "национальность" и "гражданство", обычно используемые в повседневной письменной форме и обычно понимаемые подавляющим большинством наших читателей, имеют значения, изложенные в этом предложении, с которым я не согласен. Как обычно используется в повседневной письменной форме и как обычно понимается подавляющим большинством наших читателей, «национальность» и «гражданство» являются синонимами.  . Обычное использование не пытается провести какое-либо четкое различие между ними, ни техническое юридическое различие, о котором я говорю, ни предполагаемое различие, которое представляет собой предложение. Mr248 ( разговор ) 06:18, 31 марта 2021 (UTC)

Они не могут быть синонимами, если большая часть вашей, моей и 01011000 точки зрения состоит в том, что они различимы даже при повседневном использовании. Вы не можете одновременно утверждать, что нужно сохранить и улучшить страницу, посвященную этим различиям, а также аргументировать отсутствие различий. Мы должны верить, что наши читатели более или менее бегло говорят и знают, как пользоваться словарем. Наблюдение за использованием этих терминов ясно показывает, что люди действительно используют их по-разному. Так что я действительно не склонен спорить с вами по этому поводу. Тем более, что в вашем ответе игнорируется все, что я сказал по существу; больше придирок. Цель здесь - найти решение для этой страницы, а не перехитрить всех. Другие редакторы, если они хотят комментировать, могут либо поддержать идею написать эссе на этой странице, либокоторый, как мы надеемся, создаст эссе, с которым люди согласны и сочтут полезным, или они не будут этого делать, и в этом случае я или кто-то другой предложу его для переименования, которое заканчивается на «(неудавшееся предложение)». Или я полагаю, что кто-томожно было бы попытаться переформулировать его так, чтобы оно действительно имело смысл в качестве руководства, и повторно предложить его, хотя я даю этому шанс снежного кома в аду.  -  SMcCandlish ☏ ¢  😼  06:31, 31 марта 2021 г. (UTC)

Позвольте мне прояснить свою точку зрения - в технической юридической терминологии да, существует достаточно четкое различие между «национальностью» и «гражданством»; однако в повседневном языке нет четкого или стандартного различия между этими двумя терминами - многие носители трактуют их как синонимы; небольшое количество спикеров (знакомых с техническими юридическими определениями) будет использовать технические юридические определения даже на повседневном языке; в то же время другие проводят между ними какое-то иное различие, отличное от технического юридического различия. Вы (и 01011000), кажется, утверждаете, что различие между ними, которое отличается от юридического различия, являетсястандарт в повседневном использовании, с чем я не согласен. Я предполагаю, что вопрос в том, какие доказательства (даже из надежных источников) у нас есть о том, как эти два термина последовательно различаются в повседневном использовании, если на самом деле это так? Mr248 ( разговор ) 08:39, 31 марта 2021 (UTC)

Как я уже сказал, я не склонен приводить по этому поводу круговые аргументы. Никто, кроме вас, ничего не сказал о « последовательно выделяемых», и если бы мы использовали это в качестве критерия, половина страниц проекта в системе должна была бы исчезнуть, начиная, скажем, с WP: Consensus , WP: Harassment и WP: Вежливость . Тот факт, что термины могут иметь несколько значений, никогда не мешал нам писать о них или конкретизировать «значение WP», мы просто должны четко это понимать. И ничто из этого не приравнивается к « синонимам », как вы утверждали. Но давайте просто перейдем к более конструктивному подходу ниже.  -  SMcCandlish ☏ ¢  😼  12:47, 2 апреля 2021 г. (UTC)

@ SMcCandlish , не думаю, что страница правильная. Вот несколько строк из раздела == Definitions ==:

• Национальность, с другой стороны, означает место рождения человека ... - Нет, место вашего рождения - это ваше национальное происхождение [5], а не ваше гражданство .
• Гражданство передается по наследству от родителей ... - То же самое и с гражданством для большинства людей, но я думаю, вы имели в виду национальную принадлежность .
• Пример национальности - итальянец для человека с итальянскими корнями, родившегося в США ... - Нет, это пример этнической принадлежности . Человек, родившийся в США, является гражданином США и гражданином США.

Это правда, что многие люди используют эти термины неточно. WhatamIdoing ( разговор ) 18:56, 1 апреля 2021 (UTC)

WhatamIdoing , где вы родились, является вашим национальным происхождением. Я думаю, что определение, которое вы связали («место рождения человека или любого из его прямых предков»), применимо для некоторых юридических целей, но человек может не учитывать страну, в которой они были рождены своим «национальным происхождением». Хороший тому пример - сенатор США Тед Круз.- он родился в Канаде, у матери-американки и отца-беженца-кубинца, его родители познакомились в США и только позже переехали в Канаду, а его родители вернулись в США, когда ему было четыре года, и после этого он вырос. в США. Несмотря на то, что Канада - страна его рождения, он, вероятно, не стал бы считать ее своим «национальным происхождением». Фактически, когда он узнал (будучи взрослым), что является гражданином Канады, он отказался от своего канадского гражданства. Mr248 ( разговор ) 03:41, 2 апреля 2021 (UTC)

То, что человек думает о себе, - это его национальная принадлежность. В случае Теда Круза его национальное происхождение - Канада (место рождения), Америка (прямой предок по материнской линии) и Куба (предок по отцовской линии). Вам не обязательно предъявлять какие-либо требования о национальном происхождении. WhatamIdoing ( обсуждение ) 16:00, 2 апреля 2021 г. (UTC)

Я согласен с определениями, что «национальная идентичность» связана с субъективной идентичностью (что вы думаете о себе, как вас идентифицируют другие), тогда как «национальное происхождение» определяется в более объективных терминах. Тем не менее, я не ожидаю, что все сделают это различие - некоторые читатели, вероятно, будут использовать эти термины как синонимы и, следовательно, могут использовать «национальное происхождение» также в субъективном смысле. Mr248 ( разговор ) 22:06, 2 апреля 2021 (UTC)

Я согласен с тем, что эти определения в лучшем случае наполовину недооценены, и я не возражаю против их улучшения, пока редакторы могут понять и согласиться с результатами, полученными редакторами, а это значит, что они должны осознавать значение дисперсии, а не пытаться скрыть различия и предположить, что каждое из этих слов может иметь только одно конкретное значение. Мы знаем, что это просто неправда. Сам факт того, что они потенциально сбивают с толку, является одной из причин не полагаться на них в Википедии как на средство передачи информации, которую, как мы ожидаем, будут последовательно понимать разные читатели. Даже более простые понятия, такие как «страна», часто означают разные вещи для разных читателей.  -  SMcCandlish ☏ ¢  😼  12:47, 2 апреля 2021 г. (UTC)

Я согласен с вами, что полезно помогать редакторам помнить, что люди (особенно люди из разных частей мира) часто используют эти термины для обозначения разных вещей. WhatamIdoing ( обсуждение ) 16:02, 2 апреля 2021 г. (UTC)

Я попытался переписать это эссе, чтобы быть точным. Вот что я придумал - Пользователь: Mr248 / Гражданство и национальность . Что люди думают об относительных достоинствах текущего эссе по сравнению с моим черновиком? Mr248 ( разговор ) 13:53, 31 марта 2021 (UTC)

Мне кажется, что это значительное улучшение как структурно, так и концептуально, хотя я не вдавался в подробности каждого его слова. Меня больше всего беспокоит то, что многие из приведенных определений не будут знакомы или даже встречаться многим читателям или редакторам, поэтому первая часть эссе должна сосредоточиться на наиболее распространенных значениях. PS: Я предполагаю, что вы намерены заменить провалившееся предложение жизнеспособным эссе, а не создавать новое руководство.  -  SMcCandlish ☏ ¢  😼  12:47, 2 апреля 2021 г. (UTC)

Я не претендую на особый опыт в этой области, НО, национальность в Великобритании часто связана с тем, кто вы - англичанин, шотландец, валлийский или ирландец. Это разные нации, и хотя членство в какой-либо из них не имеет ни юридической основы, ни юридического определения и не дает никаких преимуществ или прав, нельзя отказываться от этого использования. Юридически это может быть просто «национальная принадлежность», но это употребление имеет очень глубокие корни, но в эссе такое использование национальности игнорируется. Во-вторых, не все страны автоматически предоставляют «гражданство» всем, кто родился в стране. Германия, например, предоставляет гражданство и, как следствие, гражданство только детям граждан Германии (дети «гастарбайтеров» или беженцев по закону не являются немцами, даже если они родились там от родителей, законно проживающих в Германии - они должны подать заявление о натурализации).В эссе подразумевается, что только дети нелегальных иммигрантов(плюс дипломаты и вооруженные силы) никогда не могут получить гражданство в силу места рождения, это не так. Я не претендую на то, чтобы знать, в чем проблема, которую пытается решить эссе, но должен сказать, что я нахожу эссе скорее сбивающим с толку, чем разъясняющим. Pincrete ( разговор ) 18:01, 4 апреля 2021 (UTC)

Пинкрет , но в эссе игнорируется это использование национальности. Оно не игнорируется. Об этом говорится в разделе User: Mr248 / Citizenship_and_nationality # UK_constituent_countries .

В эссе подразумевается, что только дети нелегальных иммигрантов (плюс дипломаты и вооруженные силы) когда-либо лишены возможности получить гражданство в силу места рождения, но это не так. В нем говорится: «Некоторые штаты отвергают jus soli, и, следовательно, лицо, родившееся на их территории от родителей-неграждан, не приобретает гражданства государства независимо от того, сколько поколений их предки могли жить в этом штате». Это именно тот случай с Германией, я просто не упомянул Германию как пример. Я добавлю это. (Edit: На самом деле, современный немецкий закон имеет грантовый ребенок , рожденные в Германии законных жителей гражданства, по крайней мере , в некоторых случаях - то , что вы говорите, исторически верно,но это уже не так, так как правовые реформы 1999 г..)

Я не претендую на то, чтобы знать, в чем проблема, которую пытается решить эссе, но я должен сказать, что нахожу эссе скорее сбивающим с толку, чем проясняющим . Проблема, которую оно пытается решить, заключается в том, что (1) многие редакторы Википедии плохо понимают о разнообразии значений слов «гражданство» и «национальность»; (2) существующее эссе « Википедия: гражданство и национальность» содержит фактические ошибки и в значительной степени просто отражает сомнительные личные мнения одного редактора, и я пытаюсь заменить его чем-то более точным и нейтральным. Но если у вас есть конкретные предложения по улучшению текста или вы думаете, что можете сделать лучше, пожалуйста, продолжайте. Mr248 ( разговор ) 02:53, 5 апреля 2021 (UTC)

Я сочувствую этой проблеме, но задаюсь вопросом, возможно ли вообще универсальное решение - помимо того, которое мы уже используем, а именно, что мы относимся к гражданству людей, как WR: RS. Я признаю, что совершенно ошибался насчет «немецкой» ситуации, хотя не знаю, насколько распространено такое ограничение прав. Я думаю, что я, по крайней мере, частично прав насчет ситуации в Великобритании, Англии, Ск, Валли, Ирландии (которая определенно непоследовательна и временами запутана, но, как я понимаю, часто очень важна для людей, о которых пишут) . Просто заявив, что у гражданства есть юридическое определение (и описывая его свойства), вы противоречите крупной стране, где национальность имеет разные определения, большинство из которых не имеют правовой основы и не предоставляют никаких прав, привилегий или защиты. Упоминание Великобритании позже не отменяет того, что уже было сказано. Pincrete ( разговор ) 07:50, 5 апреля 2021 (UTC)

Pincrete , то есть мы называем людей по национальности WR: RS из надежных источников очень часто называет людей «американцами», «французами», «британцами», «англичанами» или как-то еще. Но приписывает ли это им национальность ? Или национальная принадлежность ? Или национальное происхождение ? Редко есть надежные источники, конкретно указывающие, о каком из этих трех связанных понятий они говорят, и читать источник как о национальности конкретно, в отличие от одного из этих других связанных понятий, когда не уточняется, какой именно говоря, значит рискнуть прочитать в нем то, чего на самом деле нет.

Просто говоря , что национальность имеет юридическое определение (и описание его свойств), Вы противоречите большую стране , где национальность имеет различные определения, большинство из которых не имеют никакой правовой основы и не предоставляют никаких прав или привилегий или защиты каких Вы прочитали вступительную часть эссе? В нем говорится: Оба являются юридическими терминами, и в этом эссе будет предпринята попытка дать обзор юридического различия между «гражданством» и «национальностью»; оба они также используются в неправовом контексте способами, отличными от их легального использования, и в этом эссе также будет предпринята попытка предоставить обзор различных неправовых способов использования этих двух терминов.. Совершенно ясно, что термины имеют как юридические, так и неправовые определения, и что эти определения различны, и они рассматриваются отдельно - все эссе разделено на два основных раздела, один из которых посвящен юридическим определениям, а другой - неправовые определения. Я не понимаю твоей критики. Mr248 ( разговор ) 22:41, 5 апреля 2021 (UTC)

Я не собираюсь с вами спорить - удачи в этом. Pincrete ( разговор ) 06:48, 6 апреля 2021 (UTC)

@ Pincrete и Mr248 : Если позволите, я немного вмешаюсь :

Пинкрет: «Упоминание Великобритании позже не отменяет того, что уже было сказано». Это справедливый момент, поэтому использование подобного примера ранее, чтобы прояснить, что эти определения не универсальны для каждого контекста и стороны, было бы разумным. Итак, Mr248 прав в том, что он не «игнорируется», но место его размещения может быть, как указывает Пинкрет, слишком поздно. Мы не можем предположить, что все на этой странице прочитают все это. Важно, чтобы главный вопрос хорошо резюмировал общую суть.

Пинкрет: «В эссе подразумевается, что только [странные случаи] когда-либо исключаются из получения гражданства в силу места рождения»; Mr248 "Это не так. В нем говорится:" Некоторые штаты отвергают jus soli и, следовательно, [дополнительные объяснения] ". Опять же, я собираюсь согласиться с Mr248 технически, но с Pincrete по духу. Разве нет способа подтасовывать какой-то материал. Я не думаю, что Pincrete имеет dain bramage, поэтому, если один из наших редакторов обнаружит, что это сбивает с толку, есть большая вероятность, что другие это сделают, и что он может использовать некоторую словесную обработку, которая может быть связана с выбором слов, размещением в то есть, давайте попробуем массировать материал, чтобы разрешить спор, а не просто спорить, пока кто-то не рассердится и не уйдет.

Даже такая тривиальная вещь, как изменение «Оба являются юридическими терминами» на «Оба они иногда являются юридическими терминами» или, может быть, даже лучше «Оба имеют различные юридические определения», может очень помочь, поскольку с первых же слов проясняет, что никаких абсолютистских определений будут предлагаться. Из работы по юзабилити, которую я проделал в старые времена раннего Интернета, я знаю достаточно, что пользователи веб-сайтов имеют сильную тенденцию (на языках LtR) начинать с левого верхнего угла собственно контента, читать ровно столько, чтобы быть уверенным, что они в нужном месте, а затем начните быстро бегать по кругу в поисках того, для чего они здесь, и не успокаиваются на чтении всерьез (если вообще), пока не зацепятся за что-то интересное. Так что есть большая вероятность, что кто-то увидит «Оба являются юридическим термином» и заключит: «Ага! Именно то, что я сказал!»,прыгайте вниз по странице, чтобы найти что-то относящееся к этому, что поддерживает какую-то точку, о которой они спорят, найдите то, что они хотят, и прочитайте это (не читая мимо), затем скопируйте и вставьте какой-нибудь материал, цитируемый вне контекста, и вернитесь к их борьба. РЖУ НЕ МОГУ.

Я стараюсь писать эссе таким образом, чтобы не допустить этого, особенно избегая утверждений, которые кажутся абсолютными, а затем уточняются, поскольку люди склонны видеть и использовать только абсолютную часть. (Это также одна из причин того, что в руководящих материалах мы не приводим кучу исключений, а затем даем общее правило в конце. Мы хотим, чтобы люди цеплялись за общее правило и применяли его, если нет кодифицированного исключения. Если бы мы руководили за исключениями, люди цеплялись за одно из них и пытались сделать из них чрезмерные обобщения и никогда не достигли фактического правила или игнорировали его, если они это сделали, надеясь, что это действительно не относится к их ситуации.) Я знаю, что это много психики UE, но об этом стоит подумать на последнем этапе разработки.
 -  SMcCandlish ☏ ¢  😼  17:15, 10 апреля 2021 (UTC)

Я думаю, что это улучшение можно было бы сделать после того, как @ Mr248 вставит на страницу уже улучшенную версию. Может быть, просто добавьте большую рамку с надписью «Особенно остерегайтесь людей из Великобритании, которые говорят, что их« национальность »- англичане / ирландцы / шотландцы / валлийцы, хотя в их собственной переписной листе это называется« национальная принадлежность », а не« национальность »». ? WhatamIdoing ( разговор ) 01:33, 12 апреля 2021 (UTC)

Религия или раса в разделах "Ранняя жизнь" биографических статей

Я кое-что заметил. В любой биографической статье, если человек имеет еврейское происхождение или родословную, эта информация отображается на видном месте; но это не относится к другим религиям. Биография никогда не указывает на то, что такой-то и есть епископальный. Или этот кто-то еще индус.Это только в том случае, если они евреи, когда об этом говорят. Сначала я подумал, что это произошло из-за расы, а не религии, но вы не найдете подобных маркеров для Черной, Азиатской или любой другой упомянутой расы, поэтому это упоминание должно быть только из-за религии. Что затем возвращает меня к вопросу: кто ищет каждого еврея на WP, чтобы специально добавить информацию, которая на самом деле не является неотъемлемой частью статьи. Должны ли мы действительно заботиться о том, является ли человек определенной религией или нет? Имеет ли это отношение к жизни человека?

Мне это кажется немного вымученным и ненужным указывать на это. - Предыдущий неподписанный комментарий добавлен 198.70.2.200 ( обсуждение ) 13:45, 31 марта 2021 г. (UTC)

Руководство Википедии о том, как отмечать религию и расу человека, находится в Википедии: Руководство по стилю / биографии , где под сокращенным названием WP: ЭТНИЧНОСТЬ говорится : «Этническая принадлежность, религия или сексуальность, как правило, не должны быть в лидерах, если это не имеет отношения к известности субъекта. . Точно так же предыдущая национальность или место рождения не должны упоминаться в заголовке, если они не имеют отношения к известности субъекта ". Соблюдал или нет человек это руководство в какой-либо отдельной статье или нет, будет варьироваться от статьи к статье. Если вы обнаружите, что статья не соответствует этому руководству должным образом, WP: SOFIXIT, но в случаях активного спора (например, если кто-то возражает против ваших изменений), пожалуйста, обсудите свое обоснование изменений на странице обсуждения в WP: BRD , а если возникнет тупик, используйте систему разрешения споров Википедии, чтобы получить помощь извне. - Джейрон, 32 13:56, 31 марта 2021 г. (UTC)

Кто-то « ищет каждого еврея на WP специально для добавления информации »? свидетельство? вы также можете заметить, что американские BLP демонстрируют явную одержимость «предками», но это результат социокультурной озабоченности «наследием» в США, а не результат того, что один человек пытается найти эту не относящуюся к делу информацию. Акусмана ( разговор ) 14:13, 31 марта 2021 (UTC)

Что ж, это может быть предметом обсуждения в любой конкретной статье - не так давно, iirc, был спор, связанный с WP: BLP, в котором живой человек сделал исключение на основе релевантности, и это нужно было проработать. . Также кажется, что иногда люди путают «национальность», которая обычно должна быть в первом предложении, с «этнической принадлежностью», которая должна идти позже, если вообще. Я также хотел бы отметить, что ОП спрашивал о разделе «Ранняя жизнь», который обычно является первым разделом ниже ведущего, и ОП прав, что он не должен казаться «принудительным», поэтому, возможно, переформулируйте его, или если есть спор обсудим. - Alanscottwalker ( разговор ) 14:55, 31 марта 2021 (UTC)

@ Alanscottwalker : Термин «национальность» может сбивать с толку, потому что он имеет несколько значений. С одной стороны, это может относиться к юридическому гражданству, которое обычно (но не всегда) идет рука об руку с законным гражданством. С другой стороны, это слово может также относиться к « национальной идентичности », то есть к тому, идентифицирует ли человек субъективно с определенной «нацией» и идентифицируют ли их как таковые другие. Это не юридическая концепция, и то, что считается «нацией» для целей субъективной национальной идентичности, может не приниматься в качестве независимого суверенного государства в соответствии с международным правом. Например, курдский националистмогут рассматривать «курдов» как свою национальную идентичность, даже если в настоящее время нет курдского национального государства; Arab националист может рассматривать «Араб» в качестве своей национальной самобытности , даже если арабский мир в настоящее время разделен на 22 отдельных суверенных государств . А «национальная идентичность» имеет неясную связь с « этнической принадлежностью », поскольку то, что одни будут называть «нацией», другие ограничат статусом «этнической группы» - вопрос о том, считается ли что-то «этнической принадлежностью» или национальность »часто является политическим вопросом, за который будут бороться различные националисты. Как я уже упоминал в другом разделе выше, я работал над эссекоторый пытается беспристрастно раскрыть все эти сложности в надежде, что он может заменить текущую статью « Википедия: гражданство и национальность» (которая полна фактических неточностей и, на мой взгляд, пытается выдвинуть конкретную точку зрения). Mr248 ( разговор ) 23:34, 31 марта 2021 (UTC)

Точка национальности - это прежде всего контекст места в мире, чтобы быстро ответить читателю на вопрос «откуда». Так что лучше не усложнять, но обязательно будут крайние случаи. Alanscottwalker ( разговор ) 00:36, 1 апреля 2021 (UTC)

Я думаю, что отчасти проблема заключается в том, что многие люди думают, что ответом на вопрос «откуда» должно быть название признанного независимого суверенного государства (или, возможно, зависимой территории ) - человек может быть из Макминнвилля, штат Орегон., но никто бы не назвал это своей «национальностью». Однако это противоречит другим, которые думают, что их национальность - это нечто иное, чем суверенное государство или зависимая территория, например субнациональное деление («нация внутри нации», такая как «английский», «шотландский», «квебекский»). "и т. д.) или этнической принадлежности, такой как курд (" Я курд из Курдистана "). И тогда первая группа людей отвечает: «Это не национальность, это национальность!». Решение, что считать «национальностью», а что считать «этнической принадлежностью», часто является очень политическим вопросом. Mr248 ( разговор ) 01:23, 1 апреля 2021 (UTC)

Реже, чем общая, и общая практика - это просто общая практика, в то время как в крайних случаях часто есть несколько способов ее усовершенствовать. - Alanscottwalker ( разговор ) 03:07, 1 апреля 2021 (UTC)

• https://www.commentarymagazine.com/articles/edward-kosner/jew-tagging-wikipedia/ , вероятно, будет очень актуальным чтением. Следует сразу отметить, что, в то время как Espicopalian - это просто религиозное описание, еврей - это этнорелигиозное описание, и поэтому можно утверждать, что оно, по крайней мере, немного более актуально. {{u | Sdkb }}  ^talk 16:25, 31 марта 2021 г. (UTC)

ну это интересно, значит есть доказательства. Лично я не думаю, что такие вещи (религия / этническая принадлежность / происхождение и т. Д.) Должны быть перечислены в BLP, если только не может быть продемонстрировано - с помощью надежных источников - что: 1) люди идентифицируют себя с тем или иным ярлыком. ; 2) указанная этикетка является примечательным аспектом. Акусмана ( разговор ) 16:52, 31 марта 2021 (UTC)

Культура, в которой вырос человек, или церковь, в которую ходила его семья, или происхождение их родителей - важная биографическая информация для любого человека. Это не то же самое, что «навешивать на них ярлыки », потому что то, что они позже практикуют или не идентифицируют с или нет, будучи взрослыми, - это отдельный вопрос. «Смит вырос в епископальной семье» ≠ «Смит - член епископальной церкви». postdlf ( обсуждение ) 23:43, 31 марта 2021 (UTC)

актуально только постольку, поскольку источники WP: RS подтверждают важность упоминания, в противном случае « культура, в которой кто-то вырос, или церковь, в которую ходила их семья, или происхождение их родителей » - это чушь, люди одержимы этим, почему ? потому что им нравится ставить в известность людей, это чушь, если только сам субъект не придает важность этим аспектам их жизни, и если они это сделают, RS, вероятно, отразит это. Акусмана ( разговор ) 11:57, 1 апреля 2021 (UTC)

Конечно, мы говорим только о проверяемой информации. Но я совершенно не понимаю, что мы должны ограничиваться только тем, что субъект считает важным в нем, или что все, что не указано в резюме, является "ерундой". Мы пишем биографии людей, а не резюме. postdlf ( обсуждение ) 17:33, 1 апреля 2021 (UTC)

просто не думайте, что необходимо детализировать аспекты чьего-то прошлого, если это не имеет ничего общего с тем, почему этот человек примечателен. Я видел несколько особенно вопиющих примеров «предков», от которых я только что почесал в затылке. Акусмана ( разговор ) 18:00, 1 апреля 2021 (UTC)

Я думаю, что одна проблема, связанная с этой статьей, в частности - у нее долгая и ужасная история антисемитизма, и автор статьи обеспокоен тем, что описание тем статьи как "еврейское" может иметь антисемитские мотивы или может иметь следствием поощрение антисемитизма, даже если это не было намерением редактора Википедии. В отличие от этого, в современном мире нет значительного «анти-епископальства», которое хотело бы навредить или очернить епископалов или обвинить в бедах мира темный епископальный заговор. Возможно, тогда опасения автора больше связаны с еврейской идентичностью - и, возможно, с другими идентичностями, которые могут подвергаться такой же степени ненависти, - чем озабоченность по поводу идентичности в целом. Mr248 ( разговор ) 01:48, 1 апреля 2021 г. (UTC)

антисемитские мотивы, безусловно, будут проблематичными и, несомненно, заслуживают внимания. Акусмана ( разговор ) 16:09, 1 апреля 2021 (UTC)

Частично это является общей тенденцией, согласно которой кто-то из евреев (или представителей другого этнического меньшинства) (обычно) рассматривает «интересный факт» о человеке из надежных источников в большинстве белых англоязычных стран, поскольку быть белым англосаксонским протестантом по умолчанию. (Не многие люди заботятся о деноминации протестантского христианина, поскольку большинство людей ничего не знают о богословских различиях). например, Сэнди Куфакс известен отчасти как величайший еврейский бейсболист всех времен («Самолет!» пошутил о брошюрах известных еврейских спортивных легенд), Барри Голдуотер отчасти известен тем, что был первым кандидатом в президенты США от евреев. и т. д. и т. д. Примеры неевреев включают Дерека Джетера иТайгер Вудс - смешанная раса. Хотя это можно рассматривать как отражение систематической предвзятости в источниках, которые мы используем, именно так работает эта энциклопедия. Мы здесь не для того, чтобы исправлять великие ошибки.

Есть и другие случаи, такие как Берни Сандерс , религиозные взгляды которого объясняются тем, что это тема, обсуждаемая многими надежными источниками (есть предположения о том, атеист ли он; необходимо включить контекст, что он родился евреем и что он идентифицирует поскольку это была важная тема, обсуждаемая в надежных источниках). Также есть Ларри Дэвид или Джерри Сайнфелд, еврейство которых обеспечивает необходимый контекст для их работы. На самом деле это не случаи систематической предвзятости.

При этом есть много случаев, когда людей называли евреями в своих статьях, а эта тема вообще не обсуждалась в надежных источниках; или редакторы нашли неясные источники, которые утверждают, что кто-то является евреем, и не признают, что WP: DUEWEIGHT означает, что их нельзя идентифицировать как таковых. Хотя я не собираюсь упоминать кого-либо конкретно, поскольку здесь это будет противоречить духу BLP; В разделе «Ранняя жизнь» упоминается множество руководителей средств массовой информации или людей в банковской сфере с именами, звучащими по-еврейски (которые на самом деле могут быть или не быть евреями), несмотря на то, что нет достоверных источников, фактически комментирующих их предполагаемый иудаизм. Это действительно заставляет меня задуматься о том, существует ли какая-то (((tagging))) кампания, нацеленная на евреев в определенных отраслях.Шахматы( Обсуждение ) (используйте при ответе){{reply to|Chess}} 20:46, 1 апреля 2021 г. (UTC)

Могу подтвердить: я только что закончил отображать один такой случай на странице обсуждения и полностью удалить другой из Дэвида Соломона после случайного нажатия CTRL + F в цитируемых источниках. - Амбир Фантом ( разговор ) 23:16, 1 апреля 2021 года (UTC)

• Я думаю, что здесь происходит много разных явлений, и часто невозможно сказать, что отвечает за какой-либо один экземпляр контента. Есть антисемиты, в основном крайне правые, которые хотят нарисовать картину еврейского заговора и поэтому могут добавить ярлык к кому-то, кого они считают частью «основных средств массовой информации», «либеральной элиты» или другого политического врага - обратите внимание, это своего рода « правило одной капли », что кто-то считается евреем этими людьми, если один из их прадедов был евреем, а остальные семь прадедов были протестантами. Есть также, совершенно не связанные друг с другом , многие из нас, кто любит повторяющиеся действия на основе категоризации, поэтому AWBи другие полуавтоматические инструменты так популярны. Кто-то из этого круга может пойти на охоту за источниками / BLP, чтобы идентифицировать себя как еврея, даже если, как и в другом случае, во многих случаях это довольно натянуто. Так было с делом о статье « Комментарий» .
  С одной стороны, у нас есть неонацист, с другой - у нас есть редактор с благими намерениями, и если у вас есть третья рука, вы можете поместить некоторых евреев, которые гордятся своей культурой и наследием, которые также склонны к чрезмерной категоризации. Я видел несколько веб-сайтов / СМИ, написанных благонамеренными евреями, которые чрезмерно относят общественных деятелей к категории евреев - Дэйв Горман.однажды высказался по поводу такого источника, который классифицировал его как такового, хотя он не еврей. Таким образом, даже в тех случаях, когда кого-то необоснованно причисляют к евреям, но не по другим дескрипторам, которые в равной степени (н) актуальны, это может быть случай антисемитизма, редактор, который полностью нейтрально относится к этой теме, или даже чрезмерно нетерпеливый еврей. Ситуация очень сложная, но общий эффект часто проявляется в антисемитской предвзятости на наших страницах BLP (всякая чрезмерная категоризация усиливает этот менталитет "еврейского заговора" и придает ему ложное доверие), поэтому это явление, которое мы все нужно действительно осознавать. - Билорв ( разговор ) 00:29, 2 апреля 2021 (UTC)

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

Возьмем, к примеру, первый абзац раздела «Ранние годы жизни» Джо Байдена : самый старший ребенок в католической семье, у него есть сестра Валери и два брата, Фрэнсис и Джеймс. Джин имела ирландское происхождение, а у Джозефа-старшего - англичане, французы и ирландцы. Это не заставляет меня вообще дважды смотреть на эти категории: католик , ирландскийи т. д. являются действительно заслуживающей внимания информацией для BLP. Вам просто следует быть осторожным, чтобы не исправить предвзятость, которую, по вашему мнению, создают люди, которые особенно любят или особенно не любят евреев, для статьи достаточной длины в большинстве случаев факт того, что кто-то является евреем, является заслуживающей внимания информацией, достаточно актуальной, чтобы включить ее в Раздел ранней жизни, никто не должен моргнуть глазами еврейского эквивалента биографии Джо Байдена и думать «черт возьми, эти подлые про / антиеврейские крестоносцы» - в большинстве случаев это действительно нормально. ‑‑ Volteer1 ( разговор ) 17:00, 2 апреля 2021 г. (UTC)

Отойдя от контекста Соединенных Штатов, у нас есть несколько категорий для довольно хороших групп по происхождению, например Категория: ливанцы иранского происхождения . Классифицировать людей по таким категориям в целом проблематично или в целом нормально? В некоторых случаях вы не найдете прямого источника, в котором говорится, что «X - ливанец иранского происхождения», возможно, вам даже придется немного поработать WP: SYNTH.(«X - отец Y», «Источник Z говорит, что X имеет иранское происхождение», следовательно, «Y имеет иранское происхождение»). Я не знаю культурного контекста того, как иранское происхождение рассматривается в ливанском обществе - могут ли быть опасения по поводу подпитки антииранских настроений, так же как есть опасения по поводу того, чтобы навесить на людей еврейское происхождение в американском контексте? Или никого там не волнует? Я думаю, меня беспокоит то, что Википедия является глобальным ресурсом, и поэтому любые правила, которые мы придумываем, должны иметь глобальный смысл, а не только для американских (или даже англоязычных или, в более широком смысле, западных) интересов. Mr248 ( разговор ) 22:56, 2 апреля 2021 (UTC)

Я считаю, что такая сверхтонкая категоризация обычно проблематична. Возьмем, к примеру, этот аргумент о том, подходит ли Луи С.К. к категории : американцы мексикано-еврейского происхождения и как это соотносится с категорией: американцы венгерско-еврейского происхождения . Я действительно просто не могу представить, чтобы какой-либо читатель искренне интересовался прокруткой категории «Американцы мексикано-еврейского происхождения», и я не могу представить, чтобы кто-то вообще смотрел на страницу Луи С.К. и говорил: «О да, мне было бы интересно Увидев больше американцев мексикано-еврейского происхождения, покажите мне больше, пожалуйста, Википедия ". Они появляются довольно глупо, WP: SYNTH -y, WP: OR-у аргументы в пользу отсутствия какой-либо выгоды для проекта. ‑‑ Volteer1 ( разговор ) 05:03, 3 апреля 2021 г. (UTC)

Действительно. Категории должны быть определяющими, и хороший тест для этого - «нажмет ли читатель на эту категорию, потому что он хотел бы видеть больше статей, соответствующих этому критерию?» Точно так же я сомневаюсь, что многие из этих категорий проходят этот тест. К сожалению, на практике категории часто могут быть просто занятой работой, источниками конфликтов и набором внутренних страниц для редакторов, а не основным контентом для читателей. - Билорв ( разговор ) 18:37, 4 апреля 2021 (UTC)

Особенность политиков (обычно американских) заключается в том, что их религиозные взгляды часто обсуждаются в СМИ и часто составляют центральную часть их общественного характера. Байден часто упоминает в публичных заявлениях, что христианство - это забота о людях или что-то еще, и ему приходилось решать ситуацию, когда католическая церковь находилась между позицией католической церкви по абортам или контролю над рождаемостью и позицией его партии. Его ирландские корни также упоминаются в надежных источниках; но ирландцы уже не являются такой большой целью (больше) белых националистов, предполагающих, что оккупационное правительство Хибернии пытается проникнуть в американскую политическую одержимость. Шахматы ( обсуждение ) (используйте в ответе){{reply to|Chess}} 01:32, 3 апреля 2021 г. (UTC)

Просто массово переместите все BLP о евреях в тройные скобки. Шахматы ( обсуждение ) (используйте в ответе){{reply to|Chess}} 01:32, 3 апреля 2021 г. (UTC)

OP сказал: «Но вы не найдете подобных маркеров для Черной, Азиатской или любой другой упомянутой расы». Однако это неверно. Почти все канадские инуиты, живые или мертвые, в первой строке указывают, что это инуит. Я видел это для метисов, коренных народов и более общих коренных народов. Он используется в статьях о шерпах и коренных австралийцах. CambridgeBayWeather , Uqaqtuq (разговор) , Huliva 01:42, 4 апреля 2021 г. (UTC)

Мусульманин также почти всегда упоминается в британских / европейских статьях (и категоризирован) - я понимаю, что это не этнический термин, но в подавляющем большинстве случаев он является синонимом «неевропейского» и «небелого» происхождения и наследия. Иногда есть веские причины, по которым мы упоминаем религию или этническую принадлежность человека (особенно, возможно, избранного политика) - для нас было бы упущением не заявить, что Обама отличался от всех предыдущих президентов США по крайней мере в одном очень очевидном отношении - но религия и этническая принадлежность иногда включаются, когда они не имеют никакого отношения к делу и мало освещаются в источниках. Ученый, медицинский человек, академик или аналогичный сотрудник вполне может иметь право сохранить (и, возможно, преуспел в сохранении) их национальность или религия как их личное дело. Pincrete ( разговор ) 07:03, 6 апреля 2021 (UTC)

Разъединение прав сисопа

Перемещено в Википедию: Village pump (лаборатория идей) § Разблокирование прав администратора (Размещено здесь после указания от VP: policy)

Закрыт на открытие по просьбе Xaosflux . Тол | Обсуждение | Contribs (ранее Twassman) 19:54, 2 апреля 2021 г. (UTC)

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

---

Я хотел бы поработать над предложением об отмене всех прав, которые обычные пользователи могут запрашивать из административного инструментария. Я знаю, что автоматический патруль - это пример, но я не уверен, какие еще права включены в набор административных инструментов, на которые могут подать заявку обычные пользователи. Я хочу, чтобы это предложение сделало так, чтобы администраторы больше не имели автоматического доступа к дополнительным правам, и вместо этого они могли попросить обычного лица, предоставляющего эти права, предоставить их в любое время. (Так что, если бы у администратора был автопатрульщик + набор инструментов, вы могли бы убрать автопатрульщика индивидуально, позволив ему оставить остальное.) Тем не менее, мне определенно нужны другие люди, которые помогут воплотить эту идею в жизнь. Jackattack1597 ( разговорное ) 23:04, 31 марта 2021 (UTC)

• Примечание: чтобы добавить небольшую дополнительную деталь, я хотел бы предложить, чтобы все права пользователей, кроме трех основных прав администратора (удаление страниц, блокировка пользователей и защита страниц), больше не предоставлялись администраторам автоматически, и администраторы должны применять за права пользователей на обычном форуме. (Смысл этого состоит в том, чтобы позволить отобрать определенные права у администраторов без необходимости формального Desysop от Arbcom). Главный технический вопрос заключается в том, может ли администратор предоставлять себе недавно разделенные права пользователя, при этом сохраняя эту возможность для администраторов. чтобы предоставить эти права другим пользователям. Я предполагаю, что для этого, вероятно, потребуется формальный RFC, и я ищу соавтора, который поможет составить официальное предложение RFC. Jackattack1597 ( разговор) 23:47, 31 марта 2021 г. (UTC)

@ Jackattack1597 : Это частая тема. Пожалуйста, прочтите Википедию: Perennial_proposals и Википедию: Разделение полномочий администраторов для некоторых из предыдущих разногласий. Если у вас есть что-то новое по этой теме, я предлагаю начать с WP: VPI, а также обсудить и проработать детали с другими редакторами. RudolfRed ( разговор ) 00:08, 1 апреля 2021 (UTC)

На практике кое-что было сделано с течением времени, поэтому сейчас у нас так много видов прав пользователей. BD2412 T 02:32, 1 апреля 2021 г. (UTC)

@ Jackattack1597 : многое из этого уже произошло. Например, я редактор шаблонов и движок страниц , что позволяет мне редактировать часто используемые шаблоны и перемещать страницы по перенаправлениям - и я не администратор. Основные функции удаления и блокировки вряд ли когда-либо будут разделены - и если кому-то доверяют их, им лучше доверять все остальное (кроме того, есть администратор интерфейса , роль, которую имеют не все администраторы, для страниц интерфейса - которые использовали быть в комплекте с админкой). OwO ( что это? ) 09:08, 1 апреля 2021 г. (UTC)

• Строго говоря, это на самом деле имеет другой аспект, чем постоянный - это удаление определенных стандартных прав в комплекте. Только вот проблема ... почему? Для отдельных частей рабочих процессов требуется множество дополнительных прав - фоновые задачи администратора немного шире, чем традиционные три ядра. Есть определенные права, когда это было бы хорошо - я действительно хотел бы отключить автопатрол для статей, которые я перемещаю в основное пространство, вместо того, чтобы пытаться не забыть депатролировать (хотя я видел лучшую идею использования задачи бота, которую администраторы могут выбрать в). Nosebagbear ( разговор ) 11:13, 1 апреля 2021 (UTC)

  @ Nosebagbear : Задача бота была бы интересной. Я даже был бы заинтересован в этом. - The SandDoctor ^Talk 15:24, 1 апреля 2021 г. (UTC)

  TheSandDoctor : Чтобы вы не дублировали усилия, бот DannyS712 уже выполняет эту задачу ; просто нужно было бы задать новый набор правил, например, согласился ли пользователь и с какими настройками. - xeno talk 00:53, 2 апреля 2021 г. (UTC)

  @ Xeno : Спасибо за внимание. DannyS712 Я думаю, что это было бы хорошей задачей. --- SandDoctor ^{Обсуждение} 5:11, 2 апреля 2021 (UTC)

  @ TheSandDoctor : Заполнит BRFA, если / когда какие-либо админы попросят меня отменить патрулирование их творений. DannyS712 ( разговор ) 05:23, 2 апреля 2021 г. (UTC)

  @ Nosebagbear , почему вы хотите удалить из патруля статьи, которые вы перемещаете в основное пространство? Как вы думаете, мы не должны вам доверять, или вы специально пытаетесь сделать дополнительную работу для других? WhatamIdoing ( обсуждение ) 16:16, 2 апреля 2021 (UTC)

  @ WhatamIdoing : while I somewhat appreciate a second look at my articles, it's particularly there for my AfC reviews. AfC has long had a bit of an ideological split as to whether reviewers who are also patrollers should also patrol. A trade of work vs 2nd opinion. Both sides have a basis to them. Autopatrol effectively shifts me to the side I don't stand on. To answer your actual question, I'd proffer a third option: I wilfully make choices that are not fully trustworthy. As a reviewer I use a rough guide of "Is it 80% likely to be kept at AfD? If so, move to mainspace and let the Community decide", others do similar. It is these cases that (as well as general community viewing) that I think are most beneficial to have a second pair of eyes in the form of an NPP patroller. While manually depatrolling is an option, it's easy to miss them. Nosebagbear ( разговор ) 17:12, 2 апреля 2021 (UTC)

На мой взгляд, хорошее предложение. Эмир Википедии ( разговор ) 23:20, 1 апреля 2021 г. (UTC)

• Как я писал в параллельной ветке Idea Lab, я считаю, что было бы полезно создать новое пользовательское право «борца с вандалами», которое обычные редакторы могут запросить в Википедии: Запросы разрешений . Право пользователя будет включать возможность выпускать краткосрочные блокировки (до 72 часов) для IP-адресов и пользователей без автоподтверждения за вандализм и серьезное нарушение работы, а также частично защищать страницы на срок до недели. Доски объявлений, такие как RPP, AIV и 3RR, теперь регулярно откладываются, и часто требуются часы, чтобы принять меры по отчету на них, даже если активный вандализм продолжается. Нам нужно дать обычным редакторам новый инструмент для решения этой ситуации. Nsk92 ( разговор ) 01:19, 2 апреля 2021 (UTC)

Другой пример из сегодняшней беседы на User talk: Explicit # CfD Category: Aldrich family , показывает, что из-за больших и постоянных невыполненных работ в CfD фактическая практика заключается в игнорировании руководства WP: NACD и разрешении NAC "удалить" "закрытие в не спорных случаях. Для таких закрытий фактические удаления все еще выполняются администратором позже, но закрывающая инструкция NAC для соответствующего CfD остается. Я не знаю, возможно ли технически создать права пользователя, позволяющие пользователю удалять только категории, а не статьи или другие типы страниц и файлов, но если да, то, возможно, стоит это сделать. Nsk92 ( разговор ) 16:55, 2 апреля 2021 (UTC)

• @ Jackattack1597 : Я бы поддержал создание некоторых прав, в первую очередь автопатруля, но, возможно, других, таких как NPR и редактор шаблонов, необязательно в том смысле, что фильтр редактирования в настоящее время является необязательным. Насколько я понимаю, технически это можно сделать довольно легко. С уважением , Barkeep49 ( разговор ) 16:35, 2 апреля 2021 (UTC)
• Можем ли мы ОТКРЫТЬ эту дискуссию? Я вижу, что это также есть в Википедии: Village_pump_ (idea_lab) #Adminship_rights_debundling _ (_ Posted_here_after_pointed_away_from_VP: _policy) . Может быть, свернуть это и указать на другое? - ^{Обсуждение} xaosflux 16:39, 2 апреля 2021 г. (UTC)
• Если есть проблема, связанная с тем, что те, кто может предоставить доступ, делают это ненадлежащим образом, им вообще не следует разрешать это делать. Сказать, что «Xaosflux не может предоставлять + создателя учетной записи» для Xaosflux с помощью технических средств управления, не помешает предоставить его «Xaosflux2». Если политика говорит, что я не должен делать то же самое, но я - у меня не должно быть доступа к инструменты - xaosflux ^Talk 18:00, 2 апреля 2021 г. (UTC)

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

Новое руководство

Заметность указов президента

Считаются ли все указы президента знаменательными? Или они должны пройти WP: GNG ? - Предшествующий неподписанный комментарий, добавленный Theleekycauldron ( обсуждение • вклад )

Думаю, большой вопрос в том, обсуждают ли второстепенные источники указ? Если да, то очевидно, что это заметно. Если у вас есть какой-то весьма непонятный исполнительный приказ, который вторичные источники не обсуждают, возможно, нет. Если все, на чем вы должны основывать статью, - это первоисточники, значит, у вас нет известности для статьи. Это похоже на то, что Конгресс США иногда принимает законы о переименовании почтовых отделений. Я думаю, что в целом закон Конгресса США будет примечательным, но закон о переименовании почтового отделениявероятно, не особо примечательны по отдельности (хотя у вас есть все основания иметь коллективную статью о таком типе законодательства). И я думаю, что вы редко найдете вторичные источники, в которых индивидуально обсуждаются такие действия. Вы вполне можете обнаружить, что существуют такие же неясные / тривиальные исполнительные распоряжения. Также имейте в виду, что в мире более 200 стран, и во многих из них есть что-то эквивалентное указам исполнительной власти - если все указы президента США заслуживают внимания, применяем ли мы один и тот же стандарт ко всем указам исполнительной власти (или какому-либо другому). они называются) президента узбекистана? А как насчет указов губернаторов штатов США? Mr248 ( разговор ) 02:18, 1 апреля 2021 (UTC)

Я предполагаю, что это закрывает обсуждение - хотя исполнительные приказы, скорее всего, пройдут WP: GNG , презумпции известности нет. theleekycauldron ( обсуждение • вклад ) ( они / они ) 02:27, 1 апреля 2021 (UTC)

Я согласен. Я хотел добавить, вот пример Распоряжения, которое, вероятно, недостаточно примечательно для своей собственной статьи - EO 13970 . Каждый год, в обязательном порядке, президент США издает распоряжение о корректировке шкалы оплаты труда федеральных служащих США. В то время как эта последовательность исполнительных распоряжений может быть достаточно примечательной для статьи, отдельные ежегодные члены этой последовательности, вполне возможно, нет. Возможно, имеет смысл опубликовать статью об этом типе исполнительного распоряжения (я предполагаю, что надежные источники, освещающие тему оплаты труда правительства США, охватят ее, но я особо не изучал это), но я менее уверен, что мы на самом деле нужна статья о каждом таком годовом указе. Может быть, просто статью о типе / серии, а затем перенаправьте отдельных ее членов на этот тип / серию.Mr248 ( разговор ) 03:02, 1 апреля 2021 (UTC)

Либо перенаправление туда, либо перенаправление в список указов этого президента, либо мягкое перенаправление на Викисорт. OwO ( что это? ) 09:05, 1 апреля 2021 г. (UTC)

Хотя сами по себе они могут не стать достаточно заметными для отдельных статей, ссылки на заказы обычно уместны в списке. - ^{Обсуждение} xaosflux 10:27, 3 апреля 2021 г. (UTC)

Статьи, в которых (почти) каждый раздел отмечен как требующий ссылок

Я иногда сталкиваюсь со статьями, где кажется, что каждый раздел помечен как требующий добавления ссылок (кроме, может быть, одного или двух разделов). Разумно ли удалить отдельные шаблоны разделов и поместить один шаблон вверху, если для статьи нужно больше ссылок? RJFJR ( разговорное ) 18:41, 1 апреля 2021 (UTC)

@ RJFJR : Я так думаю. Я предполагаю, что он также попадет под WP: BOLD . - The SandDoctor ^Talk 05:35, 2 апреля 2021 г. (UTC)

• Да. {{u | Sdkb }}  ^talk 23:43, 2 апреля 2021 г. (UTC)

Свобода членов Arbcom обсуждать активные дела на внешних форумах

RFC о переносе словосочетания «виртуальная реальность» и других подобных фраз

Существует RFC на WT: Manual of Style о том, следует ли переносить фразы вроде «виртуальная реальность» в качестве атрибутивного прилагательного, например, в « гарнитуре виртуальной реальности », или нет. - M asem ( t ) 06:07, 3 апреля 2021 г. (UTC)

Несогласованные списки защищенных классов

К вашему сведению  - указатель на соответствующее обсуждение в другом месте.

См.: Обсуждение в Википедии: Притеснение # Непоследовательный список защищенных классов
Резюме: списки защищенных классов (раса, религия и т. Д.) В WP: Harassment # TYPE и WP: Никаких личных атак # WHATIS не согласен.  -  SMcCandlish ☏ ¢  😼  06:46, 3 апреля 2021 г. (UTC)

(Не) оплаченные голоса в Википедии: Статьи для удаления / Rt Rana

Перемещено в Википедию: Доска объявлений администраторов § (Не) платное голосование в Википедии: Статьи для удаления / Rt Rana  - FF-11 ( обсуждение ) 19:57, 8 апреля 2021 г. (UTC)

Согласно этому редактированию , пользователям было сказано, что им заплатят за голосование «удалить» (это тоже похоже на «соль»). Однако фактически им не заплатили. Однако я не хочу говорить о платном редактировании или мошенничестве, но хотел сказать, что обсуждение, похоже, манипулируется. Я не уверен, нужно ли что-то делать сейчас. FF-11 ( разговорное ) 13:26, 3 апреля 2021 (UTC)

Это кажется более подходящим для WP: AN , но я не постоянный участник VPP, поэтому я воздержусь от переноса этого. GeneralNotability ( обсуждение ) 18:54, 3 апреля 2021 (UTC)

RFC по проблемам со страницами аэропорта, которые нарушают правила

DefaultSort для переадресации на полное имя

Должен ли быть шаблон DefaultSort для перенаправления страниц с полного имени? Например, должна ли страница перенаправления с названием «Джон Фредерик Смит» (на «Джон Смит» - добавлено 22:24, 5 апреля 2021 (UTC)) иметь тип DefaultSort «Смит, Джон Фредерик»? Как это работает для переадресации от и / или не-людей? Недавно вернулся из укрытия , DePlume ( разговор ) 01:24, 5 апреля 2021 (UTC)

Я запросил комментарии на Обсуждение: Майкл Джон Грейдон Сорока , соответствующая страница. Прокомментируйте, пожалуйста , DePlume ( обсуждение ) 02:15, 5 апреля 2021 (UTC)

Соответствующая страница политики - это Википедия: категоризация перенаправлений , в которой говорится, что когда перенаправляемый заголовок является собственным именем человека, консенсус заключается в том, чтобы изменить ключ сортировки из действия по умолчанию (обычно отсортированного по {{PAGENAME}}, заголовку перенаправления в этом case), чтобы вместо этого отсортировать его по фамилии. Конечно, многие перенаправления вообще не классифицируются. Юзер: 力(power ~ enwiki, π , ν ) 22:32, 5 апреля 2021 г. (UTC)

Я уже выразил свое знание зеленого текста в обсуждении Сорока - тем не менее, спасибо. Что касается перенаправлений, отсортированных по именам (например, Майкл Джон Майерс ), следует ли их менять? - ДеПлюм ( разговор ) 22:34, 5 апреля 2021 г. (UTC)

В тексте на этой странице из {{ R от имени при рождении }} говорится, что обязательно включите {{DEFAULTSORT: (фамилия), (имя)}} для правильной сортировки по категориям имени этого человека , так что да. Юзер: 力(power ~ enwiki, π , ν ) 22:36, 5 апреля 2021 г. (UTC)

Важно : Могу ли я предложить категорию для переадресации, помеченной {{ R from имя при рождении }}, но не {{ DEFAULTSORT }}? - ДеПлюм ( разговор ) 22:43, 5 апреля 2021 г. (UTC)

Никто не может помешать вам сделать это. Я не думаю, что это технически возможно, но, если это возможно, это, вероятно, хорошая идея. Юзер: 力(power ~ enwiki, π , ν ) 22:47, 5 апреля 2021 г. (UTC)

Это пустая трата времени. RfC был запущен на Talk: Michael John Graydon Soroka без какого-либо упоминания этой существующей ветки, и он прошел несколько замысловатых изменений. Никакого RfC не потребовалось, простого вопроса на WP: HD или WP: Teahouse должно было хватить, где был бы дан простой ответ вроде « использовать {{DEFAULTSORT:Soroka, Michael John Graydon}}на WP: NAMESORT ». - Red rose64 🌹 ( обсуждение ) 22:56, 5 апреля 2021 (UTC)

Универсальный кодекс поведения - консультации 2021 г.

Универсальный кодекс поведения, этап 2

Универсальный кодекс поведения (UCoC) обеспечивает универсальный базовый приемлемого поведения для всего движения Wikimedia и всех его проектов. В настоящее время проект находится на Фазе 2, где намечены четкие пути правоприменения. Вы можете узнать больше обо всем проекте на его странице проекта .

Редакционный комитет: прием заявок

Фонд Викимедиа набирает добровольцев, чтобы они присоединились к комитету, который разработает, как сделать кодекс применимым. Волонтеры в комитете будут посвящать от 2 до 6 часов в неделю с конца апреля по июль и снова в октябре и ноябре. Важно, чтобы комитет был разнообразным и инклюзивным, а также обладал разнообразным опытом, включая как опытных пользователей, так и новичков, а также тех, кто получил ответы или ответил на них, а также тех, кто был ложно обвинен в домогательствах.

Чтобы подать заявку и узнать больше о процессе, см. Универсальный кодекс поведения / Редакционный комитет .

Консультации с общественностью 2021 года: уведомление и вызов волонтеров / переводчиков

С 5 апреля по 5 мая 2021 года по многим проектам Викимедиа будут проводиться разговоры о том, как обеспечить соблюдение UCoC. Мы ищем добровольцев для перевода ключевых материалов, а также для оказания помощи в проведении консультаций по их родным языкам или проектам, используя предлагаемые ключевые вопросы . Если вы заинтересованы в волонтерстве на любой из этих ролей, свяжитесь с нами на любом удобном для вас языке.

Чтобы узнать больше об этой работе и других происходящих обсуждениях, см. Универсальный кодекс поведения / Консультации до 2021 года .

- Ксено (WMF) ( разговор ) 20:45, 5 апреля 2021 г. (UTC)

Английский Википедия Запрос комментария: Приложение "Универсальный кодекс поведения"

В дополнение к вышесказанному, я открыл RfC в Википедии: Консультации по универсальному кодексу поведения / 2021 , и сообщества приглашаются к комментариям. Ксено (WMF) ( разговорное ) 22:40, 5 апреля 2021 (UTC)

Излишки шаблонов защиты на страницах статей

Повторяющееся использование {{pp-protected}} и {{pp-protected | small}} (которое добавляет изображение блокировки рядом с заголовком) является избыточным и НЕ является обязательным согласно Wikipedia: Rough_guide_to_semi-protection . Более того, страницы немного сложнее обрабатывать, а изображение замка может оттолкнуть пользователей от редактирования. Неявная защита (вы можете увидеть это, попытавшись изменить исходный код или информацию о странице) должна быть справедливой в бесплатной энциклопедии, объединенной с поощрением создания постоянных и надежных учетных записей пользователей. Хвастовство защищенных статей с помощью изображений замка - не путь к бесплатной энциклопедии. Brainfrogk4mon ( обсуждение ) 20:10, 7 апреля 2021 (UTC)

Мое общее мнение таково, что стоит предоставлять читателям некоторую информацию, если она влияет на восприятие чтения. В этом случае, я думаю, наличие значков висячих замков может помочь в некоторых случаях убедить читателей, что спорная статья, по крайней мере, в некоторой степени защищена от вандализма, поэтому есть некоторая выгода. {{u | Sdkb }}  ^talk 04:17, 8 апреля 2021 г. (UTC)

Сомневаюсь, что кто-то из них заметит. WhatamIdoing ( разговор ) 01:37, 12 апреля 2021 (UTC)

RfC на FA защиты

Предлагаемое дополнение MoS для дополнительной маркировки ударения на русском, украинском, японском, корейском языках и т. Д.

К вашему сведению  - указатель на соответствующее обсуждение в другом месте.

См .: Обсуждение в Википедии: Руководство по стилю # RfC? , для предложения, касающегося дополнительных символов / знаков для обозначения вокального ударения, используемых в некоторых иностранных языках, включают символы «рубин» для японского и корейского языков , а также знаки «знаки ударения» на украинском и русском языках. Краткая версия заключается в том, что, основываясь на правиле, уже давно найденном в MOS: JAPAN и согласующемся с политикой WP: NOTDICT , MoS будет инструктировать (в MOS: FOREIGN ) не использовать эти знаки (в основном предназначенные для педагогических целей), за исключением необычных обстоятельств. , например, прямая цитата или обсуждение самих знаков. Срок реализации - 21 апреля. PS: Это не относится к вьетнамским тональным знакам.  -  SMcCandlish ☏ ¢  😼  19:41, 8 апреля 2021 г. (UTC)

Политика создания заглушек

Это было перемещено из WP: ANI , см. Википедия: Доска объявлений для администраторов / Инциденты # Массовое создание статей на основе одного ненадежного источника контекста - Ymblanter ( обсуждение ) 14:35, 11 апреля 2021 г. (UTC)

Примечание администратора. Я оставил этот раздел открытым (отдельно от закрытия выше), поскольку считаю, что это обсуждение крайне необходимо. Однако это обсуждение не требует внимания администратора, и его, вероятно, следует перенести в другое место. Иванвектор ( ^{Обсуждение} / _{Редакции} ) 14:13, 11 апреля 2021 (UTC)

Есть ли какой-либо интерес в разработке политики, которая определяла бы, когда разрешены отдельные заглушки местоположений, а когда они должны быть объединены в списки? Кто-нибудь знает, предпринималась ли такая политика и является ли это вечнозеленым предложением? Pinging @ Iridescent : кто может это знать, - Имблантер ( разговор ) 07:40, 9 апреля 2021 года (UTC).

Чтобы прояснить, список или отдельные статьи - это вопросы очень широкого диапазона; Я сейчас говорю только о населенных пунктах (которые, я думаю, имеют хоть какие-то шансы, чтобы их можно было серьезно рассмотреть), - Имблантер ( выступление ) 07:42, 9 апреля 2021 г. (UTC)

• Мы обсуждали это здесь: Обсуждение в Википедии: Известность (географические особенности) # Массово созданные деревни / окрестности Геостабы . FOARP ( разговор ) 09:22, 9 апреля 2021 (UTC)
• В дополнение к руководящим принципам повышения значимости было бы полезно иметь политику, которая фактически требует от редакторов демонстрировать известность во время создания статьи. Многие из Cricketer окурков Lugnuts' были созданы в предположении , что должно быть значительное освещение вне там где - то для тех , кто играет в определенное количество матчей на определенном уровне, и несколько редакторов! Голосования Keep в AFD на основе этой посылки даже когда единственный найденный источник - это запись в базе данных. - dlthewave ☎ 15:18, 10 апреля 2021 г. (UTC)

Даже РГ: Geoland носит это неявное предположение (именно поэтому он использует язык «как правило , предполагаемый быть заметным» , а не « являются заметным»). Мы предполагаем, что даже для официально признанных населенных пунктов они могут создать WP: GNG.пройти, если кто-то проведет достаточно глубокое исследование. Возможно, такое поведение было нормальным, если просто делать это на основе Sports-Reference.com, например, для прыгунов с шестом (я не думаю, что это так, но консенсус исторически не был против этого), но как только вы попытаетесь делайте статьи на GEO так же, как вы в конечном итоге получаете что-то вроде иранской «деревни», потому что география намного сложнее, чем спортивная статистика. Количество горя, которое мы испытали из-за предположения, что X в персидском / азербайджанском / любом другом языке означает то же самое, что и "деревня" .... FOARP ( разговор ) 18:50, 10 апреля 2021 (UTC)

Что ж, не будем переусердствовать. Я создал, например, эту статью сегодня, и в настоящее время она размещена в двух базах данных (ну, в одном статистическом документе и одном сайте, похожем на правительственную базу данных). Я вернусь к нему позже (что может занять несколько лет), чтобы довести его до этой стадии.. Однако я не думаю, что какой-либо здравомыслящий человек может утверждать, что у него есть проблемы с известностью, или даже что было бы более выгодно иметь его как элемент списка. Мой аргумент заключается в том, что на каком-то этапе развития (который необходимо формализовать, но что-то вроде статьи о местности содержит только название, местное название, административное деление, в котором находится местность, население и координаты), это больше. выгодно иметь его как элемент списка, а не как отдельную статью. Такую статью нужно перенаправить в список, - Ymblanter ( разговор ) 19:17, 10 апреля 2021 г. (UTC).

«Предполагаемая значимость» в соответствии с рекомендациями по значимости не означает, что это обязательно должно указывать тип источников, соответствующих SIGCOV, только то, что статья может быть показана как отвечающая критериям, которые, вероятно, приведут к большему количеству SIGCOV для значимости. Большинство рекомендаций по известности основаны на заслугах (например, получение Нобелевской премии), и этот подход имеет смысл, но проблема заключается в случаях в GEOLAND и NSPORT, где простое доказательство того, что что-то / кто-то существовал на определенном уровне, является презумпцией известности (в случае NSPORT , игра на профессиональном уровне - это предположение, что человек должен был иметь предшествующую карьеру, чтобы перейти на профессиональный уровень, который может быть задокументирован). Я также отмечу, что любой подобный подход должен быть согласован с CSD, который намеренно отвергает любую «известность».факторов и использует гораздо более низкую полосу для хранения предметов. -М асем ( t ) 14:42, 11 апреля 2021 (UTC)

Я бы поддержал такую ​​политику, особенно если бы она касалась и спорта. Насколько сложно найти один источник SIGCOV? Если у вас нет доступа к ссылкам, но вы ожидаете, что они будут существовать, кажется гораздо более разумным поместить тему в соответствующие списки и сделать сообщение в соответствующих википроектах с вопросом, есть ли у кого-нибудь еще доступ. Джоэл Джей ( разговорное ) 20:28, 10 апреля 2021 (UTC)

Как указывалось выше, это обсуждение дублирует обсуждение в Википедии: Известность (географические особенности) # Массовое создание геостабов деревень / районов . Прокомментируйте, пожалуйста, вместо этого. - Уанфала (разговорное) 15:04, 11 апреля 2021 г. (UTC)

В то время как я намеревался ограничить обсуждение только статьями о местах, обсуждение шло более широко и не соответствовало разговору в Википедии: Известность (географические особенности) - Имблантер ( разговор ) 15:09, 11 апреля 2021 г. (UTC)

Считаете ли вы местность местом, подпадающим под WP: GEOLAND ? Я думаю, что отчасти отсутствие ясности здесь связано с определением WP: GEOLAND . SportingFlyer T · C 15:10, 11 апреля 2021 г. (UTC)

Да, населенные пункты подпадают под GEOLAND, но есть много других вещей, которые попадают туда и с которыми нельзя относиться так же, - Имблантер ( разговор ) 15:17, 11 апреля 2021 г. (UTC)

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

Для населенных пунктов следует изменить политику заглушек, чтобы явно запретить создание статьи, когда доступна единственная информация - это записи в базе данных. Требуется минимум раздел по истории, географии или другой информативный раздел. Slywriter ( разговор ) 16:19, 11 апреля 2021 (UTC)

Я поддерживаю то, что вы сказали выше. Стёрм (разговор) 21:46, 11 апреля 2021 (UTC)

@ Slywriter : Я не уверен в этом. Я обнаружил, что наши корешки о населенных пунктах в США довольно хороши, скажем, городок Лейк-Джордж, округ Хаббард, Миннесота (выбран наугад). Конечно, это не здорово, но это лучше, чем ничего. Я почти уверен, что все в указанной статье, кроме истории имен (которая на самом деле не имеет значения), взято из баз данных. Было бы ваше предложение против такой статьи? Элли ( Обсуждение | вклад ) 22:25, 11 апреля 2021 (UTC)

Элли , это лучше, чем Meryemköy, _Çıldır, но все, что читатель узнал, это данные переписи населения США и к тому же устаревшие данные переписи. Так что, если кто-то не потрудится обновить эту статью в следующем году, это будет две переписи с отставанием от текущего времени, и мало надежды на то, что кто-то обновит каждое обновление. Список населенных пунктов в Хаббарде или Миннесоте со ссылками на переписи населения США, викиданные или другие точки данных будет лучше служить читателям в долгосрочной перспективе, поскольку одна страница может быть обновлена, чтобы указывать на самые свежие данные и сохранять исторические данные. Slywriter ( разговор ) 23:26, 11 апреля 2021 (UTC)

Я третий комментарий к случайной кнопке. На данный момент это бесполезно, если вы не хотите обнаружить десятки окурков футболистов и сортов растений. Джоэл Джей ( разговор ) 03:25, 12 апреля 2021 (UTC)

Не ограничиваясь заглушками, не ограничиваясь локациями; в каждой новой статье должен быть указан хотя бы один надежный и исчерпывающий источник. Статьи, в которых этого не хватает, должны быть помечены для улучшения, а затем (примерно через неделю) либо перемещены в область черновиков, либо перенаправлены в список (если имеется соответствующий список). Фрам ( разговор ) 07:56, 12 апреля 2021 (UTC)

• Функцию random можно легко настроить или параметризовать для включения или исключения определенных типов контента в зависимости от требований пользователя. Например, я чаще всего вижу «случайную статью» в приложении Wikipedia для iPhone, которое просматриваю ежедневно. Кажется, это уже отфильтровано, поэтому отображаются только статьи с изображениями.

Пробуя рандомизатор приложения, я вскоре нахожу Доланы (Кладненский район) - чешскую деревню. Это заглушка, но обратите внимание, что у нее есть изображение и информационное окно, и поэтому он выглядит нормально. Также обратите внимание, что в нем нет цитат - только запись {{ авторитетный контроль }}. Он был создан из соответствующей статьи в чешской википедии . Обратите внимание, что эта тема также существует во многих других языковых Википедиях и поэтому считается действительной.

Если редакторы хотят дополнить эту заглушку, то они должны это сделать. Удаление было бы шагом назад и, следовательно, разрушительным. Создание еще большего количества правил противоречило бы политике для WP: CREEP .

Эндрю 🐉 ( разговор ) 19:02, 12 апреля 2021 (UTC)

Да, статья, в которой есть раздел истории на чешском языке, есть галереи изображений в общих чертах и ​​другие моменты, которые показывают, что кто-то приложил усилия хотя бы на одном языке, а не просто выкинул строчку из базы данных

Миссия также призывает к тому, чтобы Википедия просуществовала 100 лет, десятки тысяч однострочных статей, требующих обновления, чтобы быть актуальными, не помогут будущим редакторам и читателям. с этим можно было бы справиться на уровне рода, потому что ни о каком из этих видов ничего не известно. И нет особых требований к удалению данных, речь идет об изменении того, как они организованы, чтобы было меньше статей и больше соответствующих списков / диаграмм для захвата этих данных. лайнеры. Slywriter ( разговор ) 20:00, 12 апреля 2021 (UTC)

Nganzun , созданный в 2008 году, имеет две дополнительные статьи-заглушки, иерархически расположенные над ним, прежде чем вы перейдете к статье en-wiki с любой соответствующей информацией в Mandalay_Region . Бирманская Википедия немного лучше, хотя даже там Nganzun и Nganzun Township могут легко быть одной статьей, но еще лучше и то, и другое может сделать Myingyan District актуальной статьей, а редакторы должны обновлять только одну статью в будущем. Вместо этого 3 статьи будут томиться нетронутыми десятилетиями. Slywriter ( разговор ) 20:34, 12 апреля 2021 (UTC)

Бирма и Бангладеш были забиты множеством «деревенских» заглушек, созданных доктором Блофельдом (ныне Encyclopdius) с помощью бот / бот-подобного редактирования еще в 2008 году или около того. С тех пор почти никого из них не трогали. Статьи были созданы на основе данных GEOnet, но - что очень важно - то, что GEOnet называет "населенным местом", может быть буквально всем, в чем люди могут жить / работать, и многие из мест, которые он описывает как "населенные", возможно, никогда не были заселены (это не как будто они отправляют следователей для проверки или выполнения какой-либо работы по проверке данных, которые они представляют). У Нганзуна даже этого нет.

Создание заглушки "Распыляй и молись" на самом деле просто проклятие. FOARP ( разговор ) 07:28, 13 апреля 2021 (UTC)

• Lake George Городка, Хаббард Каунти, штат Миннесота упоминалось выше , был Ram-Man  ( ток  · вклад ) / Rambot  ( разговор  · вклад ) создание и какие новые редакторы, вероятно , не знают о том , что люди имели дискуссии , то о массовых созданных географических пней, тоже. Одна из вещей, которая была сделана, заключалась в том, чтобы эти статьи начинались с нескольких абзацев прозы. Свидетель Special: Permalink / 5057043 и прочтите Special: Permalink / 512950 # FAQ и Wikipedia talk: Bots / Archive 1. Также обратите внимание на то, что было сказано еще в 2002 году о том, что функция случайной страницы действительно заключается в обнаружении заглушек. Дядя Джи ( разговор ) 08:05, 13 апреля 2021 (UTC)

Создание статей, которые представляют собой просто статистические данные, представленные в формате прозы, - это просто плохое редактирование - все, что добавил Рамбот, могло быть (и, вероятно, было) одной строкой в ​​таблице, и было бы более кратким и легко сопоставимым с другими местами, представленными таким образом. . Я думаю, мы можем и должны добиться большего. Однако я скажу, что использование бота для этого все же лучше, чем операции вырезания / вставки, которые делали Карлос, Лагнатс и доктор Блофельд, поскольку количество человеческих ошибок уменьшается. FOARP ( разговор ) 08:18, 13 апреля 2021 (UTC)

Почему Википедия не требует, чтобы редакторы были старше 13 лет?

Для большинства веб-сайтов с взаимодействием с пользователем требуется, чтобы пользователи были старше 13 лет. Я думаю, что минимальный возраст несколько снизит количество вандализма на сайте. Почему в Википедии нет минимального возраста? Феликс Ан ( разговорное ) 14:39, 11 апреля 2021 (UTC)

Я полагаю, вы могли бы попросить людей указать, что им 13 лет или больше, хотя такие утверждения могут быть неверными. Selfstudier ( разговор ) 14:42, 11 апреля 2021 (UTC)

Это невозможно обеспечить. Можно добавить такой пункт в условия использования, но вандалов все равно не заботят условия использования, - Имблантер ( разговор ) 14:43, 11 апреля 2021 г. (UTC)

«Большинство веб-сайтов ...» ^{[ необходима цитата ]} Большинство вандалов все равно не входят в систему. Читатели могут использовать учетные записи не только для редактирования, но и для других целей. PrimeHunter ( разговорное ) 14:56, 11 апреля 2021 (UTC)

Веб-сайты делают это, потому что Закон о защите конфиденциальности детей в Интернете ограничивает сбор личных данных от лиц младше 13 лет. Википедия не имеет обыкновения собирать информацию, поэтому у нее нет особой озабоченности по поводу возраста. - Нат Гертлер ( разговор ) 15:02, 11 апреля 2021 г. (UTC)

WP не только не занимается активным сбором информации о пользователях, о которой говорят такие законы и постановления, но и советуем молодым википедистам не раскрывать свой возраст или другую личную информацию. Роджер (Dodger67) ( разговор ) 16:06, 11 апреля 2021 (UTC)

Википедия, онлайн-энциклопедия, которую может редактировать каждый , не требует никаких ограничений в отношении того, кто может редактировать, кроме принятия условий использования . Это один из наших основополагающих принципов . Иванвектор ( ^{Обсуждение} / _{Редакции} ) 15:05, 11 апреля 2021 (UTC)

Никто не может быть признан вандалом только по возрасту. И большая часть вандализма со стороны лиц младше 13 лет не будет очень тонкой, поэтому их будет легко обнаружить и обратить вспять. Это тонкий, более скрытый вандализм, о котором нам нужно беспокоиться больше всего, и по большей части он исходит от старых редакторов. Если мы хотим запретить людям редактировать, потому что они могут быть вандалами, нам придется запретить всем (даже мне, 63 года) редактировать. Фил Бриджер ( выступление ) 15:50, 11 апреля 2021 (UTC)

Как отмечалось выше, на самом деле у нас нет механизма для обеспечения соблюдения требования проверки возраста для редакторов WP в масштабе, предложенном OP. У нас есть руководство WP: CIR, которое на практике отсеивает большинство очень молодых редакторов. Лично я считаю, что было бы разумно установить минимальный возраст для администраторов, хотя бы по юридическим причинам. Nsk92 ( разговор ) 16:14, 11 апреля 2021 (UTC)

@ Nsk92 : такое требование есть для Checkusers, Oversighters и членов ArbCom. Элли ( Обсуждение | вклад ) 21:04, 11 апреля 2021 (UTC)

@ Феликс Ан : почему это должно быть? Минимальный возраст ни в малейшей степени не снизит уровень вандализма, насколько я могу судить (я уверен, что желающие быть 12-летними вандалами просто солгали бы). Элли ( Обсуждение | вклад ) 21:04, 11 апреля 2021 (UTC)

Причина, по которой на многих веб-сайтах есть требование о минимальном возрасте (13 лет), заключается в COPPA , который не распространяется на Википедию, поскольку мы не собираем, не используем и не раскрываем возраст пользователя. Изно ( разговорное ) 23:02, 11 апреля 2021 (UTC)

Чего бы это ни стоило (и это второстепенно), я считаю, что на заре существования Википедии были администраторы, которые были даже моложе 13 лет, и я могу вспомнить действующего президента, которому было 13 лет, когда они проходили RfA. Вопросы возраста, конечно же, возникают в RfA, поскольку многие избиратели не хотят голосовать за несовершеннолетних. Также есть случай, когда в Интернете никто не знает, что вы собака . Sdrqaz ( разговор ) 17:10, 11 апреля 2021 (UTC)

@ Sdrqaz : Да, смотри мои комментарии на User talk: Iridescent / Archive 41 # sidetrack-within-a-sidetrack on age . Graham 87, 10:10, 12 апреля 2021 г. (UTC)

Ах, это интересная история, Грэм (с добавлением небольшого комментария относительно Маллеуса). Известно ли вам о каких-либо успешных RfA для несовершеннолетних в «современную» эпоху? Мне вспоминается RfA 2015 года , на которое я наткнулся примерно неделю назад, где около половины оппонентов были примерно возраста (и кандидат был старше многих из наиболее крайних примеров). Sdrqaz ( разговор ) 12:41, 12 апреля 2021 (UTC)

@ Sdrqaz : Нет, я ничего не знаю. Graham 87 13:40, 12 апреля 2021 г. (UTC)

Я не могу вспомнить недавнюю успешную RFA кем-то, кого считают несовершеннолетним, меня не удивит, если наш самый молодой нынешний администратор будет старше подростка. Есть две вещи, которые сделали сообщество менее открытым для подростков в последнее десятилетие или около того: ожидание использования встроенного цитирования и мобильная платформа, которая делает Wikipedia apig для редактирования на смартфонах или планшетах. Это не только дает нам серьезный перекос в этнической принадлежности, но и не учитывает поколение смартфонов. Шере Шпиль Чекерс 08:34, 13 апреля 2021 г. (UTC)

@ WereSpielChequers : Специальных редакторов для смартфонов не существует. Хотя существуют исключения, смартфоны используют потребители средств массовой информации, а помимо фотографий и видео - не столько создатели. Википедию нужно редактировать на смартфонах или планшетах, потому что на этих устройствах нет физической клавиатуры. Никто не пишет книгу на смартфон. Они могут исправить опечатку здесь и там, добавить категорию или даже ссылку, но с меньшей вероятностью добавят целый раздел. - Alexis Jazz ( поговори со мной или позвони мне) 16:23, 13 апреля 2021 г. (UTC)

@ Alexis Jazz : Писать на мобильном телефоне не так уж и плохо: я обнаружил, что скользящий набор ускоряет его, а когда вы привыкли печатать на мобильном телефоне, слепой ввод действительно возможен. Однако вопрос о потребителях средств массовой информации кажется правильным. Sdrqaz ( обсуждение ) 16:31, 13 апреля 2021 (UTC)

@ Sdrqaz : Я полагаю, вы могли бы привыкнуть ко всему, но даже на клавиатуре нетбука я, вероятно, все равно побил бы вас как по скорости, так и по точности. Проблема не только в клавиатуре: экрана на планшете или большом телефоне было бы почти достаточно, и для потребления мультимедиа он, по сути, есть, но когда вы начинаете печатать, клавиатура занимает большую часть, если не все. экран. Возможно, будет невозможно написать текст на мобильном устройстве, если вы обучены этому, но любой, кто действительно хочет написать больше, чем короткий комментарий в социальных сетях или исправить опечатку в WP, скорее всего, бросит свое мобильное устройство на что-то с физическая клавиатура. Итак, возвращаясь назад, Википедия не является недопустимым представлением поколения смартфонов., пользователи смартфонов недостаточно представляют Википедию. В этом есть смысл. Fiat Pandas - прекрасные автомобили на каждый день, но они недостаточно представлены в гонках серийных автомобилей, и это вряд ли кого-то удивит. - Alexis Jazz ( поговори или позвони мне) 22:37, 14 апреля 2021 г. (UTC)

У меня есть Fiat Panda и смартфон. Я бы предпочел редактировать Википедию с помощью Панды, чем с помощью мобильного интерфейса Википедии. DuncanHill ( разговорное ) 23:11, 14 апреля 2021 (UTC)

WereSpielChequers , это интересно. Я думал об этом больше в смысле изменения стандартов RfA, чем в смысле отсутствия представительства. Лично я часто использую "чистый" мобильный редактор (использующий мобильный веб-сайт, а не настольный сайт на мобильном телефоне а-ля Каллен), и интерфейс адекватен ( возможно, слабая похвала ). Вы не можете использовать Twinkle или RefToolbar без метода Каллена, и трудно одновременно открыть два окна для лучшего письма, но это не так ужасно, как говорят другие (приложение, с другой стороны, - это другая история ). Встроенное цитирование можно сделать, открыв Template: Cite web на другой вкладке и скопировав скелет поверх или введя параметры вручную, как только вы их запомните.

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

Шашки, были успешными кандидатуры несовершеннолетних, потому что избиратели не заботились о их возрасте или не знали? Или, может быть, те, кто знал, не предали гласности это, поэтому остальные избиратели не знали? Sdrqaz ( разговор ) 16:27, 13 апреля 2021 (UTC)

Я вспомнил о двух RFA от женщин, которые, я уверен, были молодыми, когда проходили RFA. Один из них в 2010 году был близким к цифрам, ретроспективно мои собственные возражения были слишком резкими, и с тех пор я выступал только против ошибочного удаления тегов, где я обнаружил несколько ошибок. Одно из противодействий в том было явно потому, что она была школьницей, но ни в одном из последующих оппонентов не упоминалось это или слово зрелости, и довольно много возражений были типа «ты почти там, вернешься через несколько месяцев», что Я сомневаюсь, что был эйджистом. В 2007 году я нашел один, в котором было нейтральное голосование: «Я не могу заставить себя поддержать кого-то такого молодого», но RFA сдало 90 к 1. Что соответствует моей памяти, что сообщество не рассматривало как проблему иметь очень молодые админы.Я могу вспомнить пару крайне неудачных в 2009 году, в одном из которых несколько редакторов указали на «опасения по поводу зрелости», но в обоих случаях были недавние ошибки. Я бы сказал, что раньше сообщество сознательно назначало администраторов-подростков. У меня смутные воспоминания о более недавнем RFA, где все чаще ожидалось, что администраторы должны быть совершеннолетними по закону.Шере Шпиль Чекерс 20:50, 13 апреля 2021 г. (UTC)

Интересный материал, WereSpielChequers , спасибо. Думаю, я знаю, о каком RfA 2007 г. вы имеете в виду; Вскоре после этого она неожиданно получила повторное подтверждение. Глядя на 13-летнего кандидата в другом, они прошли с 98% поддержкой, и никто не упомянул о возрасте, поэтому я не уверен, знал ли кто-нибудь об их возрасте в то время. Может быть, тот, о котором вы думаете, был более свежим, 2015 года ? Кажется, около половины оппонентов были основаны на возрасте. Sdrqaz ( разговор ) 21:53, 13 апреля 2021 (UTC)

Почти наверняка так оно и было, в 15 лет он был старше, чем по крайней мере один из несогласных с несколькими годами ранее, и большинство оппонентов этого возраста исходили из принципа его возраста - также был огромный откат в колонне поддержки от люди, которые отвергли эйджизм в колонке противников. Я почти уверен, что что-то изменилось внутри или за пределами сообщества за прошедшие годы, чтобы сместить точку зрения Эрика Корбетта с выброса на достаточно большое меньшинство, чтобы, вероятно, сорвать RFA. Единственное, что я могу придумать, что могло бы объяснить сдвиг, - это скандал с католическим сексуальным насилием и роль администраторов в хранении определенных вещей в тайне и получении доступа к удаленным изменениям. Я предоставлю какому-нибудь будущему исследователю разобраться, изменила ли группа редакторов свои взгляды на молодых кандидатов или это было изменением электората РФА.Или, действительно, к 2015 году в сообществе уже не было много подростков или, по крайней мере, подростков-админов. Но очевидно, что все изменилось, и я сомневаюсь, что все изменилось обратно. Я думаю, что толпа RFA уже давно умеет замечать очень молодых кандидатов.Шере Шпиль Чекерс 07:25, 14 апреля 2021 г. (UTC)

• Думаю, я помню, как одному редактору, который вносил хорошие правки в статьи о динозаврах, было меньше 13 лет, когда они начинали, поэтому я не уверен, почему нам нужно исключать их на этом основании. FunkMonk ( разговор ) 14:00, 12 апреля 2021 (UTC)
• Мне девять лет, по собачьим. - Платан Рокси . wooF 14:03, 12 апреля 2021 (UTC)

  Итак, вы признаете, что сделали свое первое предварительное зачатие редактирования . Могу я одолжить вашу машину времени? - Red rose64 🌹 ( обсуждение ) 10:57, 13 апреля 2021 (UTC)

• Исключение тех подростков, которые подчиняются таким правилам, как не трогайте, пока вам не исполнится 13 лет, мы не потеряем для нас никаких вандалов. Это может лишить нас некоторых добросовестных редакторов и может даже привлечь некоторый вандализм со стороны подростков, которые хотят показать, что они могут нажимать кнопку редактирования, даже если они этого не должны. Так что я не вижу пользы от этого предложения, но есть небольшая польза. Шере Шпиль Чекерс 08:40, 13 апреля 2021 г. (UTC)

  Согласен . Если бы это было возможно осуществить, это стоило бы обсудить. Это не так, значит, это не так. {{u | Sdkb }}  ^talk 18:21, 13 апреля 2021 г. (UTC)

• В США COPPA применяется ко всем личным данным, даже если они опубликованы добровольно (например, контактная информация на странице пользователя), если оператору известно, что пользователю моложе 13 лет. Однако некоммерческие организации освобождены. Мы следуем лучшим практикам, контролируя такую ​​личную информацию, когда мы с ней сталкиваемся. - dlthewave ☎ 20:23, 13 апреля 2021 г. (UTC)

Предложение по поиску давних плохих статей

Томас Ranch находится около быть удалены , просуществовав в Википедии в течение более пятнадцати лет без единой ссылки инлайн, и никогда не имея внешнюю ссылку на независимый источник. Граб Смит , хоть и немного дольше, находится в подобном состоянии столь же долгое время. Я случайно натолкнулся на этих двоих не во время поиска подозрительных статей, а во время общей очистки от имени Томас и фамилии Смит. Сколько еще статей в этом состоянии? Я предполагаю, что лучший способ выяснить это, если это технически возможно, - это создать список статей, в которых никогда не было встроенного тега ref.в течение своего существования, отсортированные по возрасту, и проталкивать их, начиная с самых старых. Если у кого-то есть Вики-фу для создания такого списка, пожалуйста, имейте это в виду. BD2412 T 00:20, 5 апреля 2021 г. (UTC)

Никогда за все время их существования это, вероятно, непростая задача , но WP: RAQ , вероятно, лучшая первая остановка. Изно ( разговор ) 01:51, 5 апреля 2021 (UTC)

Да, трудная задача, но большие усилия приносят большие плоды. Спасибо за указатель. BD2412 T 02:41, 5 апреля 2021 г. (UTC)

• BD2412 , мне кажется, я помню, что реплики базы данных включают только метаданные, а не фактическое содержимое страницы. Чтобы получить содержимое, вам нужно пройти через API (что намного медленнее). Кто-то должен проверить меня в этом. В качестве доказательства концепции я написал тривиальный небольшой скрипт на Python, который выполняет итерацию по всем страницам в основном пространстве и ищет <ref> в любом месте текста. Он обрабатывает около 10 страниц в секунду. У нас около 6 миллионов статей (из WP: STATS, который, как я полагаю, имеет в виду mainspace, когда написано «6 281 819 статей»). Таким образом, мы могли сканировать каждую статью в mainspace примерно за неделю. Это можно было представить. Я предполагаю, что количество редакций на 2 порядка больше, поэтому поиск каждой редакции каждой статьи, вероятно, будет непозволительным. Первое предположение, пару лет. В любом случае я не уверен, какую ценность это добавит. - РойСмит (разговор) 02:49, 5 апреля 2021 г. (UTC)

  Мы могли бы значительно сократить это количество, сначала удалив из поиска каждую статью, имеющую тег ref прямо сейчас (а это должно быть существенное большинство), а из оставшихся - только поисковые статьи, созданные, скажем, до 2007 года. Значение будет просто убирать старый мусор. BD2412 T 03:00, 5 апреля 2021 г. (UTC)

Сканирование базы данных должно работать. Я попытался найти тег ref на гораздо меньшей вики, чем enwiki, и, похоже, это сработало. Запросы не будут работать, потому что они не регистрируются в таблице sql. - Снаевар ( разговор ) 08:00, 5 апреля 2021 г. (UTC)

Snaevar , какой запрос выполнял? Можете ли вы дать ссылку на страницу Quarry? - РойСмит (разговор) 14:02, 5 апреля 2021 г. (UTC)

Скорее всего, они говорят о дампах баз данных . Quarry не будет работать, как вы говорите - в нем нет текстов страниц. Pinging HaeB, который, я думаю, может прокомментировать возможность обработки дампов для этой задачи. - SD0001 ( разговор ) 16:55, 5 апреля 2021 г. (UTC)

Я провел сканирование базы данных с помощью AWB на небольшой вики, и я просто искал в основном пространстве имен страницы, у которых нет <ref>. Такой поиск выполняется в автономном режиме. Файл дампа содержал все страницы только с самой последней версией (страницы-мета-текущие в имени файла). Файл дампа был загружен с dumps.wikimedia.org. - Снаевар ( разговор ) 19:33, 5 апреля 2021 г. (UTC).

Как отмечалось в обсуждении WP: RAQ , запросы могут быть дополнительно сужены до статей, отнесенных к категории в дереве категорий Категория: Компании , или статей, отнесенных к категории Категория: Живые люди . Вот где чаще всего возникают подобные проблемы. BD2412 T 15:15, 5 апреля 2021 г. (UTC)

@ BD2412 : почему бы не начать с чего-нибудь вроде « Категория: Статьи без исходных текстов за декабрь 2006 года» ? Для компаний специально используйте что-то вроде списка очистки для WikiProject Business (в настоящее время не существует для компаний WikiProject, но вы можете запросить его). -  Finnusertop ( обсуждение ⋅ вклад ) 16:17, 5 апреля 2021 г. (UTC)

Ни одна из упомянутых выше статей не была помечена таким образом, возможно, потому, что на них есть внешние ссылки (даже если эти ссылки на сайты непригодны для использования в качестве источников). Я ищу вещи, которые действительно проскользнули сквозь трещины. BD2412 T 16:20, 5 апреля 2021 г. (UTC)

Конечно, BD2412 , но если необходимо предпринять какие-либо действия в отношении статей с этими конкретными проблемами, имеет смысл начать с тех, которые уже были выявлены. Но я понимаю вашу точку зрения. Я иногда натыкаюсь на статьи с низким трафиком с очевидными проблемами, которые тоже проскочили сквозь трещины, и отмечаю их. -  Finnusertop ( обсуждение ⋅ вклад ) 16:24, 5 апреля 2021 г. (UTC)

• Ну, я создал экземпляр VPS. Производительность намного лучше, чем у Toolforge; Мне удалось отсканировать 994949 страниц менее чем за 6 минут! Не уверен, что вы имели в виду именно это, но я нашел все страницы в категории: Живые люди , которых не было </ref>в тексте. Всего найдено 7 страниц:
  • Джанни Клеричи
  • Сибилла Говен
  • Стивен Холт (хоккей на траве)
  • Артур Касков
  • Майк Кингери
  • Арт Филлипс (композитор)
  • Кэрол Скелтон

Это кажется правдоподобным? - РойСмит (разговор) 02:27, 7 апреля 2021 г. (UTC)

Кстати, https://github.com/roysmith/bad-articles - РойСмит (разговор) 02:31, 7 апреля 2021 г. (UTC)

Спасибо. Что примечательно, до сих пор ни одна из этих статей не была помечена как нуждающиеся в источниках. Я подозреваю, что есть еще кое-что. BD2412 T 04:04, 8 апреля 2021 г. (UTC)

@ RoySmith отсканирует 994949 страниц менее чем за 6 минут, используя API или дампы? В любом случае, вау! Последнее звучит неправдоподобно, поскольку на User: SDZeroBot / Unreferenced_BLPs есть список BLP, на которые нет ссылок - это намного больше, чем 7. Или вы имели в виду страницы, у которых уже нет тега без источника? - SD0001 ( разговор ) 20:27, 8 апреля 2021 г. (UTC)

SD0001 , через API. Это работает внутри центра обработки данных WMF, поэтому я предполагаю, что у него намного больше пропускной способности для серверов API, чем у вас или у меня с удаленного компьютера. Да, это казалось потрясающим, поэтому я искал подтверждения того, что это имеет смысл. Ясно что то не то, покопаю еще. - РойСмит (разговор) 20:55, 8 апреля 2021 г. (UTC)

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

У меня сейчас новая версия. Он должен обрабатывать статьи со скоростью примерно 0,01% от скорости оригинала, но с компенсирующим преимуществом, заключающимся в том, чтобы делать что-то полезное. Он находит, например, Odalys Adams , который восполняет отсутствие ссылок, имея 22 категории. Он должен был закончиться примерно через 24 часа, но я убил его, чтобы не перегружать серверы. Я работаю над получением доступа к файлам дампа, и как только это будет сделано, я перейду на их использование. - Рой Смит (разговор) 21:26, 8 апреля 2021 г. (UTC)

😂. Получение миллиона страниц за считанные минуты звучало подозрительно! Что касается дампов, я вижу, что они есть в toolforge по адресу /mnt/nfs/dumps-labstore1006.wikimedia.org/enwiki/latest. - SD0001 ( разговор ) 13:24, 9 апреля 2021 г. (UTC)

-insource:"<ref"Упоминался ли поиск в enwiki с помощью ? Результаты включают XXX (страница значений) и Hitler Youth (есть куча ссылок с использованием {{ sfn }}, но без <ref>тегов). Чтобы ограничить поиск категорией, используйте incategory:"Living people" -insource:"<ref" Johnuniq ( talk ) 00:33, 9 апреля 2021 г. (UTC)

Таймаут составляет 200 КБ, но я просмотрел некоторые, и у большинства из них не было встроенной ссылки на рассматриваемой странице. Изно ( разговорное ) 00:47, 9 апреля 2021 (UTC)

Johnuniq , А можно ли искать "<ref" с ведущей пунктуацией? Я думал, что все знаки препинания игнорируются поисковым индексатором. - РойСмит (разговор) 02:17, 9 апреля 2021 г. (UTC)

Вы правы - из Help: Searching # insource:, «не буквенно-цифровые символы игнорируются». Я новичок в поиске и начал с insource:/regexp/(косые черты вместо кавычек) и (я считаю), что разрешает пунктуацию в соответствии с правилами регулярных выражений. Однако время ожидания регулярного выражения истекло, поэтому я без особых раздумий переключился на котировки. В любом случае, я хотел сказать, что dab-страницы нужно игнорировать (что происходит автоматически при использовании Category: Living people ) и что некоторые найденные страницы могут не иметь тегов ref, но все же быть хорошими, потому что они используют один из новомодных методов ссылок. . Джонуник ( разговор ) 03:06, 9 апреля 2021 (UTC)

• @ BD2412 : У меня только что появился доступ к файлам дампа, поэтому я получил еще один удар по этому поводу. Это не результат воображаемого производственного кода, но вот сценарий, который я запустил . Эвристика, которую он использует для определения того, что такое BLP, что такое перенаправление, что является ссылкой и т. Д., Довольно грубая. Я не проводил никаких измерений производительности, но мне кажется, что в большинстве случаев это был простой ввод-вывод, распаковка потока bzip и синтаксический анализ XML, поэтому добавление более сложных проверок не сильно замедлило бы работу. Это было сделано с помощью однопоточного процесса грубой силы. Если бы мы хотели превратить это в производственный инструмент, который запускался бы по регулярному графику, я мог бы легко увидеть ускорение на 1-2 порядка.

Это было выполнено с файлом дампа enwiki-20210320-pages-article.xml.bz2 (только текущие версии). Он просмотрел примерно 21 миллион страниц (все пространства имен), из которых около 1 миллиона оказались BLP, и обнаружил 43 399 страниц примерно за 5,8 часа. Он подготовил этот список . - РойСмит (разговор) 16:11, 14 апреля 2021 г. (UTC)

Защищенный от дурака WP: уведомление о песочнице

Есть ли способ защитить уведомление от ошибок, чтобы оно больше никогда не было удалено? Может, сделать меньше? Больше скрытых комментариев? Переместить его в уведомление об изменении страницы? - Привет, середина ( вклад ) 22:18, 5 апреля 2021 г. (UTC)

У Cyberbot I есть задача, которая периодически очищает песочницу, вот так . Я не углублялся в его BRFA или логику, чтобы понять, почему иногда между правками проходит несколько часов. cyberpower678 может пролить свет. - Jonesey95 ( разговорное ) 22:57, 5 апреля 2021 г. (UTC)

Я знаю это. Я не жил под камнем. Значит, нет никакого способа заставить шаблон быть там, кроме как поместить его в викитекст страницы вместе со всем остальным? Проблема в том, что некоторые пользователи добавляют шаблон nobots, который отключает редактирование страницы ботами. И не похоже, что бот сразу после удаления восстанавливает сообщение. - Привет, середина ( вклад ) 19:47, 6 апреля 2021 г. (UTC)

BRFA Cyberbot I для рассматриваемой задачи говорит, что она не соответствует требованиям исключения, поэтому {{nobots}} не должно быть проблемой. -  Руммскартоффель ( обсуждение  • вклад ) 15:50, 8 апреля 2021 г. (UTC)

@ Heymid : Я бы не возражал против добавления здесь editnotice, хотя, если мы сохраним заголовок на странице, он, вероятно, будет излишним ... Elli ( talk | contribs ) 21:00, 11 апреля 2021 (UTC)

Мобильные редакторы (как веб-редакторы, так и приложения) не могут видеть уведомления об изменении, поэтому удалять текстовое уведомление не рекомендуется. Suffusion of Yellow ( разговор ) 21:05, 11 апреля 2021 (UTC)

@ Suffusion of Yellow : возможно, удаление обходных путей для мобильных приложений побудит их быть в некоторой степени компетентными? (хорошо, это, вероятно, принятие желаемого за действительное) Элли ( Обсуждение | вклад ) 21:14, 11 апреля 2021 (UTC)

Уведомления о редактировании становятся все более и более неуместными. Они не видны в мобильном представлении, потому что, как и шаблоны навигационных ящиков, они предоставляют мало информации и обычно от одного редактора, желающего остановить редактирование страницы. Moxy - 22:38, 11 апреля 2021 г. (UTC)

@ Moxy : Я не совсем согласен с этим. Уведомления о редактировании должны быть редкими - может быть, 1/50 - 1/100 страницы, максимум - но они очень полезны, когда все сделано хорошо. Я считаю, что уведомления о редактировании на страницах обсуждения, вероятно, следует использовать больше, чем баннеры на странице обсуждения. Элли ( Обсуждение | вклад ) 22:58, 11 апреля 2021 (UTC)

... Я сформулировал это довольно неудачно, я имею в виду, что их следует часто использовать поверх баннеров на странице обсуждения - баннеры на странице обсуждения должны быть более распространенными. Но люди почти никогда не видели, например, {{ Warning RS and OR }}, поскольку вы не видите баннеры на странице обсуждения, когда делаете запросы на редактирование. В то время как перенос этого в editnotice намного эффективнее. Элли ( Обсуждение | вклад ) 22:59, 11 апреля 2021 (UTC)

Потребуется сделать его жизнеспособным в мобильных устройствах, в приложениях и т. Д. ... потому что на данный момент только 30% читателей ... которые могут нажимать кнопку редактирования, увидят их. Moxy - 00:00, 12 апреля 2021 г. (UTC)

Есть ли здесь актуальная проблема? Песочница предназначена только для тестирования, и иногда тестовые правки удаляют заголовок ... вот почему у нас есть бот, вставляющий его обратно. Legoktm ( обсуждение ) 07:26, 12 апреля 2021 г. (UTC)

Новый план развертывания RADAR

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

• Щелкните здесь, чтобы использовать инструмент. (ссылка заработает в ближайшее время)Извините за плохую ссылку. Фактическая ссылка будет доступна в следующий вторник.

• Щелкните здесь, чтобы просмотреть обучающие видео.

Обязательно сохраните ссылки, чтобы не потерять их. Сэм в Megaputer ( разговор ) 16:32, 6 апреля 2021 (UTC)

Так что же это за инструмент? EGGIDICAE🥚 18:50, 6 апреля 2021 г. (UTC)

Инструмент делает несколько вещей, но главная особенность, которой я горжусь, - это обнаружение рекламных статей. Или, по крайней мере, будет, когда наш айтишник получит связь (ха-ха). Итак, я провел индивидуальный анализ настроений.для всех статей о компаниях и школах, чтобы получить промо-балл, который мы можем использовать для ранжирования их от наиболее до наименее рекламных. Я также использовал все промо-теги и ежемесячные просмотры страниц. Идея состоит в том, что мы применяем различные виды и фильтры для обнаружения различных типов поврежденных артикулов. Чтобы привести несколько примеров, мы можем отфильтровать статьи без тегов и отсортировать их по промо-баллам. Статьи вверху списка - это рекламные статьи без тегов, поэтому мы помечаем их. Или мы можем отфильтровать статьи с тегами POV, а затем отсортировать по просмотрам за месяц. Если мы заботимся об уменьшении количества поврежденных попаданий, это дает нам приоритетную очередь для статей, нуждающихся в очистке. Сэм в Megaputer ( разговор ) 18:59, 6 апреля 2021 (UTC)

Я не понимаю, зачем нам нужен инструмент, размещенный на Wiki, который предположительно будет иметь доступ к личным данным для учетных записей пользователей, когда у нас есть совершенно хорошие фильтры, которые уже это делают. EGGIDICAE🥚 19:05, 6 апреля 2021 г. (UTC)

Ну, мы не можем сортировать по промо-баллу. И я не уверен, что вы имеете в виду под доступом к личным данным для учетных записей пользователей. Как только ссылка заработает, настройка учетной записи не потребуется. Сэм в Megaputer ( разговор ) 19:09, 6 апреля 2021 (UTC)

Да мы можем. Точно так же, как ORES и фильтры. EGGIDICAE🥚 19:12, 6 апреля 2021 г. (UTC)

I'm not sure that ORES does exactly that. Could you show me what you mean? For example, could you get me a link to all articles on companies that have a notability tag, sorted from most to least promotional? Sam at Megaputer (talk) 19:20, 6 April 2021 (UTC)

MW:ORES. Can you please explain how exactly your tool works, what type of information it would "see" from using it? EGGIDICAE🥚 19:28, 6 April 2021 (UTC)

I make this video series to explain how it works from a user's prospective. If this can be achieved with ORES, It's certainly not obvious how to do it from that documentation. I am planning on opening up the tool for inspection after it has been out for two weeks and we have collected some data on efficacy. Sam at Megaputer (talk) 19:40, 6 April 2021 (UTC)

You still haven't explained what if anything it sees from a data standpoint, which is more important since you're asking people to test it out and promoting it all over the site without any meaningful discussion with the actual community. EGGIDICAE🥚 19:42, 6 April 2021 (UTC)

Are you asking me to explain how it creates the ranking? Sam at Megaputer (talk) 19:47, 6 April 2021 (UTC)

To be honest, this sounds to me like straight-up spam promoting your company's tool, and I'm half-minded to remove the spam you posted - the optics of this are very concerning for me. If it's genuinely not intended to be promotion and is intended to purely for the interests of furthering the project, why not open-source it and host it on wikitech:Toolforge? That way, concerns about leaking the private data of users of this tool can be mitigated through the requirement to follow Toolforge's terms of use as well. While I'm definitely interested in the anti-spam fight, just the way this seems to have been pushed from your end definitely feels like (to me, at least) a bait-and-switch, though I do assume that's not your intention.

You also mention you're collecting usage data from this, but I fail to see where you've disclosed your privacy policy detailing exactly what data you will be collecting and storing, and for how long. ​stwalkerster (talk)

Oh, that data collection. The data I am collecting is just an analysis of how these Wikipedia articles change over time. We aren't collecting any user data. And this tool was built with a proprietary software framework, so it can't be open-sourced. But it might be possible to create an open-source knock off if it is popular, and I would even be willing to help with that. I'm not sure what you mean by "bait and switch". Sam at Megaputer (talk) 19:56, 6 April 2021 (UTC)

The fact that you do not understand what I am asking about with regard to data is a problem. How do we know what data it is collecting from someone using the tool? How do we know this isn't just scraping IPs? What privacy assurances are there? EGGIDICAE🥚 19:59, 6 April 2021 (UTC)

It's the same as when you visit any website. If I had built this tool to scrape IPs, I would be doing that in a very inefficient way. You are probably wanting to know what Megaputer is trying to get out of this. That is a perfectly reasonable question. My company let me work on this because they are hoping to make the news. As for myself, I am a Wikipedian who wants to help along the project. Sam at Megaputer (talk) 20:02, 6 April 2021 (UTC)

No, I honestly don't care. I want to know what user data this tool is gathering from USERS ACCESSING IT considering you've promoted it all over the place. This isn't a goodness of your heart creation, you even said as much. My company let me work on this because they are hoping to make the news. EGGIDICAE🥚 20:07, 6 April 2021 (UTC)

Why would any company do all this work just to steal data from a dozen or so Wikipedians? That makes absolutely no sense. And of course this isn't being done out of the goodness of Megaputer's heart. Megaputer is a company, and companies don't have hearts. I started building this thing during my unpaid internship. Megaputer let me do it because I was unpaid, and they really didn't care what I did as long as I learned the software. Now I am releasing it. Quite frankly, I'd like to see it do some good. Sam at Megaputer (talk) 20:14, 6 April 2021 (UTC)

Again, you're totally missing the point, aside from you spamming on behalf of your company who wants to "get in the news", what a tool used on Wikipedia does with user data does matter whether it's intentionally nefarious or not. That's why Stwalkerster asked about the privacy policy. You're really toeing a line here and you need to stop. Further, just because you've disclosed as a paid editor, doesn't give you free reign to use Wikimedia as a marketing stunt. EGGIDICAE🥚 20:16, 6 April 2021 (UTC)

Here is a link to Megaputer's privacy policy. Sam at Megaputer (talk) 20:20, 6 April 2021 (UTC)

Thank you for the privacy policy link. I've had a look, and I'm disappointed in a number of the vague statements regarding potentially indefinite data retention and the depth of user-identifying information that you appear collect. I will not be using this tool. stwalkerster (talk) 20:43, 6 April 2021 (UTC)

I respect your decision. But please bear in mind that there are many Wikipedians who use Facebook, Twitter, and even Google, all of which are known to violate your privacy in ways that Megaputer never could, even if we wanted to. These Wikipedians will likely not have such an objection to Megaputer's privacy policy. I very much hope that a few of them will give my tool a try. Sam at Megaputer (talk) 20:58, 6 April 2021 (UTC)

The difference is that those are individual choices that have nothing to do with Wikipedia. A tool for Wikipedia is a different matter, especially one that is promoted heavily by someone with a vested interest in that company. I would recommend dropping this given you literally said that it was an attempt to get media coverage. EGGIDICAE🥚 21:13, 6 April 2021 (UTC)

@Praxidicae When you navigate to an external site by clicking on a link from Wikipedia, they'll be able to know that you've come from Wikipedia, but they can't possibly know what your user account is or any other information related to your account. They'll also get your IP address and user agent string – but that's true of every website you visit on the internet. If you don't agree to that just don't visit their site. No need to make a fuss about it as it spurs technical innovation and discourages future technical contributors from even trying to improve WP. Hosting on Toolforge is good practise but it is certainly not a requirement since it's always up to users whether they want to use the tool or not. – SD0001 (talk) 04:25, 7 April 2021 (UTC)

SD0001 You've completely missed my point. There is a difference between viewing an article, clicking a source. No one is worried about that data scraping. This is someone who was literally paid/hired to write about the company hosting this tool and is creating the tool and promoting it in hopes of getting media attention per their own admission in this thread. Further, it would be very easy to scrape data from accounts using a tool like this - say it pulls up 5 spammy articles and I go and AFD/tag/CSD them, it's fairly obvious who was using the tool at that point. Further, ORES already does this. This is nothing more than a marketing ploy. EGGIDICAE🥚 15:17, 7 April 2021 (UTC)

This is nothing more than a marketing ploy So much for WP:AGF. I'm not missing your point – all the comments you've made here indicate you were worried about user data collection. You even started this discussion by creating FUD (... presumably will have access to private data for user accounts – which is technically impossible by the way). Even if the sole purpose of creating the tool was to get user data – it doesn't sound like the type of data that can be sold to DMPs for money. ORES is maintained by an understaffed team at WMF. I'm quite sure it is possible to create more sophisticated ML algorithms. I do not know whether this is one of those. But by the way you're treating this person, you're ensuring that no one makes another attempt. – SD0001 (talk) 17:38, 7 April 2021 (UTC)

SD0001 My company let me work on this because they are hoping to make the news. is a direct quote from the OP, who is literally paid to write content about the company hosting this "tool". It is quite literally a marketing ploy. So perhaps, I don't know, read through the thread next time. EGGIDICAE🥚 21:32, 7 April 2021 (UTC)

As much as I don't want to engage with you, I feel the need to say that I do not appreciate being told that the product of my hard work is a "marketing ploy". You have claimed that my tool is redundant to ORES (it is not), that it steals user data (which doesn't even make sense), and even that I lacked community approval to build it. You are clearly just throwing out allegations and seeing what sticks. All this started with allegations of "spam", and while I could have handled the rollout better, your response to this has been far more disruptive than anything I have done. Sam at Megaputer (talk) 22:02, 7 April 2021 (UTC)

I never once said that it steals data, I said that it's possible given your lackluster response about the privacy policy. And if I'm disruptive, please feel free to take it to the appropriate noticeboard. My marketing ploy comment is completely reasonable given your response to someone asking why you built it was that your company wanted to be in the news. The disruptive one here is you. EGGIDICAE🥚 23:18, 7 April 2021 (UTC)

I raised this on Sam's user page, but he took umbrage, which is undercutting my AGF. Is there any reason this user isn't yet blocked for all of the above as well as the non-answers & evasiveness re: his prior account? Courtesy @DGG, Praxidicae, Blablubbs, and RoySmith: StarM 18:23, 8 April 2021 (UTC)

• The bity-ness and general rudeness in this thread makes me sad. The OP wanted to do something to help the encyclopedia in an innovative way. Killiondude (talk) 18:26, 8 April 2021 (UTC)

Sorry but I don't agree with "helping the encyclopedia." He literally said it was because his company wanted to be in the news. Further, I'm super skeptical of an editor who is paid to write about their company reporting competitors for COI, afding articles and tagging other articles as paid/upe/coi. EGGIDICAE🥚 18:28, 8 April 2021 (UTC)

This is the seventh time you have claimed that I only built this thing as a marketing ploy, or to get in the news. [6][7][8][9][10][11][12] This is a totally unnecessary attack on my reputation. Sam at Megaputer (talk) 19:27, 8 April 2021 (UTC)

• I was going to stay out of this, but since I was pinged, I'll comment. I would be happier if Sam disclosed his other account, but I've read WP:ALTACCN carefully, and I think a reasonable case can be made that forcing him to disclose the other account would be effectively forcing him to disclose his real-world identity, which we never force people to do. His employer is a small company; anybody familiar with the company would probably be able to figure out who Sam is based on the information he's already disclosed about his work there. He's disclosed that he's paid, disclosed that he's got another account, and disclosed additional details to a CU. Unless a CU wants to go further, I think it's time to drop this.

As for "We don't need this tool because it does the same thing as ORES", that's just plain silly. There's a huge range of AI algorithms used in classification problems. Even if you're using the same basic algorithms, training a model on a different data set is a significant difference. I'd be happier if they open-sourced the code, but people are free to use the wikipedia data for commercial purposes, with no requirement to disclose their source code. There's also the argument that in a domain like spam detection, disclosing every detail of your model just makes it easier for the bad guys to alter their behavior to avoid detection. So, even in a purely altruistic, "all knowledge should be free" universe, I can understand not disclosing everything.

And, yeah, I wish Sam would not be quite so effusive about how wonderful his stuff is. If this was in mainspace, it might well be WP:G11 material.

And finally, on the topic of potential privacy violations by Megaputer, to be honest, I think we're in WP:FRINGE territory here. WMF has an exceptionally conservative privacy policy. It is unreasonable to require anybody who uses WMF data have an equally conservative policy. As long as they're not running on WMF systems, what they log is between them and their users. -- RoySmith (talk) 19:11, 8 April 2021 (UTC)

I have to disagree with the sock part, Roy – the "Sam at Megaputer" account is being used in ways that a "regular", unpaid account is and participating in discussions internal to the project (participating in AfD's and this thread, tagging an article by a firm that works in a similar industry to Megaputer etc.); per WP:SOCKLEGIT, Although a privacy-based alternative account is not publicly connected to your main account, it should not be used in ways outlined in the inappropriate uses section of this page. WP:ILLEGIT is clear about the fact that editing projectspace with an undisclosed alternative account is prohibited, and it makes clear that evasion of scrutiny is a violation of WP:SOCK. Using a privacy sock to participate in projectspace discussions arguably is evasion of scrutiny because it splits contribution histories and prevents people from evaluating your edits as a whole. Blablubbs|talk 12:56, 9 April 2021 (UTC)

• I can confirm that the alternate account has been disclosed to me as a checkuser. I have checked just now the editing history. It has not been used to overlap in any manner the editing or interests of the current account. Whatever the merits of the project being discussed here, there is in my opinion no violation of sock policy. DGG ( talk ) 14:09, 9 April 2021 (UTC)

  DGG, the assertion being that it's okay to participate in discussions internal to the project with two undisclosed accounts as long as there's no overlap? If so, I think that that would need to be clarified in WP:SOCK. Blablubbs|talk 13:00, 10 April 2021 (UTC)

If you continue to have concerns, please do not discuss them in an open forum, but take them to arb com, to avoid the possibility of outing. DGG ( talk ) 23:33, 10 April 2021 (UTC)

DGG, I'm not seeing the outing concerns here - nobody's tossing out possibilities for who the "other" account is, and Sam has been quite clear about their relationship with Megaputer. They are just discussing whether this situation appears to be in violation of PROJSOCK/SOCKLEGIT, which is entirely reasonable as long as nobody's speculating about their other identity. GeneralNotability (talk) 23:59, 10 April 2021 (UTC)

It seem obvious to me that further discussion on this line will lead to revealing the identity of the other account. I I do not consider this suitable for discussion on a page devoted to purely technical matters. have listed this on the checkuser list for my colleagues awareness and advice. DGG ( talk ) 04:38, 11 April 2021 (UTC)

DGG, that is not "obvious" to me at all - again, nobody is even speculating about the identity of the other account. Perhaps it's obvious to you since you've been officially notified of the user's other account. While the discussion is currently more "policy" than "technical", I believe it is still reasonably on-topic (and moving the policy discussion onto VPP would unnecessarily split the discussion). GeneralNotability (talk) 14:18, 11 April 2021 (UTC)

• This thread is mildly disappointing to me, but unfortunately not terribly surprising. I wholly agree with SD0001's comments above. I'd add that it's up to the (potential) users of this tool to decide for themselves if they want to use it; it isn't being embedded on Wikipedia and users aren't forced to use it. There is no policy requiring editors who develop a tool to 'seek consensus' before linking the tool onwiki. It's also not surprising to see a for-profit company looking to keep its source code private or gain publicity. None of this is even remotely a problem though, in the same way the popular CVDetector uses proprietary APIs to offer its service (Google's, I believe?). If it helps Wikipedians improve Wikipedia, and we're getting it for free, that's great. If the company profits from it too, how and why exactly is that a problem for us? ProcrastinatingReader (talk) 22:53, 12 April 2021 (UTC)
  • Just to add, I don't understand how someone can call for an editor to be blocked on their userpage whilst appearing to question their value to the project,[13] and then claim that having that comment very reasonably removed with a polite summary is undercutting my AGF. What AGF? I don't see any AGF in this section at all. ProcrastinatingReader (talk) 02:00, 13 April 2021 (UTC)
• Comment I'm glad that this "Megaputer tools for Wikipedia" effort had a stop put to it, effectively. Sam at Megaputer sums up the Megaputer position, which is wholly at odd with the open-source ethos Wikipedia is built upon, over at Mediawiki. In reply to a questions asking if the Megaputer code could be open eventually open–sourced, he said "I could ask about it, but I don't think it will be possible. I believe that this grammar check feature is written in our proprietary programing language, which in turn depends on our proprietary grammar parsing algorithms, so open-sourcing it would require giving away too much of what we do. The CEO has expressed a willingness to make our software freely available to editors and WMF staff for the building of bots, tools etc., but releasing that much source code without payment may not be a viable business model. As a company, we still have trade secrets to maintain in order to exist." The fact that the company is the driver behind the functionality, and not a regular user, is also at odds with the way things are usually done. No doubt the user was well-intentioned, but I don't think they understood how sketchy their proposal looks, for a number of reasons-- for example the fact they have engaged in paid editing, and would like to promote a commercial tool to detect promotional editing... --- Possibly (talk) 03:41, 14 April 2021 (UTC)

  And...? Which community or WMF policy is being violated here? What's unique here compared to Wikipedia:Turnitin or meta:CopyPatrol or various services using iThenticate or CVDetector? ProcrastinatingReader (talk) 04:01, 14 April 2021 (UTC)

Well, presumably those companies did not internally design a specific product for Wikipedia, and then send an actual Wikipedia editor over to Wikipedia to set up an improper alternate account to promote the product. And if they were involved in creating promotion-detection software for Wikipedia, they presumably did not have the previously named editor do some paid editing which caused him to appear at COIN, followed by the editor coming up with software to detect all the things they were accused of at COIN? For starters. --- Possibly (talk) 04:26, 14 April 2021 (UTC)

Again, Which community or WMF policy is being violated here? Also, are you saying that those creating something shouldn't communicate and work closely with the users of the product? Because conventional software development wisdom usually has it that developers should actively communicate with users in order to create better solutions that actually solve problems. ProcrastinatingReader (talk) 04:39, 14 April 2021 (UTC)

Aside from many issues articulated above, the WMF's stated mission is to "empower and engage people around the world to collect and develop educational content under a free license or in the public domain". Free, shared and transparent is at the core of the movement. Have a nice evening.--- Possibly (talk) 05:00, 14 April 2021 (UTC)

The alternate account seems fine to me. An arb A former arb, current CU, also said as much in this very thread. Have a great evening! Killiondude (talk) 05:29, 14 April 2021 (UTC)

@Killiondude: Which arb would that be? Prior to myself, I see that there have been twelve contributors to this thread (Blablubbs, DGG, GeneralNotability, Killiondude, Possibly, Praxidicae, ProcrastinatingReader, RoySmith, Sam at Megaputer, SD0001, Star Mississippi, and Stwalkerster); and I know of fourteen arbs (listed here) - but I can find no names in common. --Redrose64 🌹 (talk) 20:37, 14 April 2021 (UTC)

Hi RR! DGG was an arb until Dec 2020. I am a few months out of sync. I struck and corrected my comment. Thank you for your concern. Killiondude (talk) 21:44, 14 April 2021 (UTC)

Bot Partially Non-functioning

I think that I have a specific issue and a general issue to report. The specific issue is that a bot, User:MDanielsBot, has stopped doing one of its tasks. The task is Task 6, which is to clerk the Dispute Resolution Noticeboard by maintaining a table that summarizes the status of disputes. It has stopped maintaining that table. The bot seems to be doing Task 4 properly, which is to dispose of stale reports at the vandalism noticeboard. The instructions say that if the bot is malfunctioning, administrators can press a button to block it, or non-admins can report it at WP:ANI. Presumably a report at WP:ANI will result in the bot being blocked. Any bot should be blocked if it is doing something wrong. In this case the bot isn't doing anything wrong. It isn't doing something right that it should do. The general issue is what should be done if a bot stops doing one of its tasks, and the bot maintainer is on a long wikibreak. It appears that User:Mdaniels5757 has posted a notice saying that they will be back in a few months. In the meantime, their bot is doing its most important task, and isn't doing another task.

What should be done with this bot?

What should be done with bots that are partly non-functioning and do not have a current bot administrator? Robert McClenon (talk) 18:16, 6 April 2021 (UTC)

This is a typical problem with bots. There's nothing that can be done about it. Try emailing Mdaniels; if he sees it, and has time, he might fix it. If not, WP:BOTREQ to find someone else to create a similar bot (presumably this may help make it quicker for someone to do so). ProcrastinatingReader (talk) 18:20, 6 April 2021 (UTC)

User:ProcrastinatingReader - Is the link the Python code that performs the task? If so, that would mean that it would be minimal work for a Python coder to use the existing code, and that would be why User:Firefly is able to make such an offer. I will send the email and provide an update in between 24 and 72 hours. Robert McClenon (talk) 22:27, 6 April 2021 (UTC)

It certainly appears to be - I've not tested it, but at the very least it would cut down the work required as the basic algorithm is there to see. ƒirefly ( t · c ) 06:23, 7 April 2021 (UTC)

Just noting that I’d be happy to have FireflyBot take this on if it’s deemed necessary (BRFA would be required of course). Ping me if MDaniels doesn’t get back to you! ƒirefly ( t · c ) 20:55, 6 April 2021 (UTC)

User:Firefly - I have not received a response from User:Mdaniels5757, and it has been more than 72 hours since I sent it. They are either not answering email or not responding to Wikipedia email. That is all right, since we are all volunteers, and they said that they were on break. So it would be appreciated if your bot could take on this extra task. Thank you. Robert McClenon (talk) 03:52, 10 April 2021 (UTC)

@Robert McClenon: Not a problem, I'll have a look. ƒirefly ( t · c ) 11:11, 10 April 2021 (UTC)

Category for the Philippines

The universal template for sports events by month by country works fine for most countries (and is very useful!) but for the Philippines displays the category “2015 in Filipino sport” instead of “2015 in Philippine sport” (which has a temporary fix). Can this be fixed please? See Category:January 2015 sports events in the Philippines. Hugo999 (talk) 21:41, 7 April 2021 (UTC)

Hugo999 The problem is that the nationality isn't the same as the adjective for something pertaining to the country. Looks like a {{country2adjective}} template should be created to deal with these cases. I think Le Deluge may be intressted in dealing with this. --Trialpears (talk) 22:00, 7 April 2021 (UTC)

Well it should be possible; cf Dutch sport & Events in the Netherlands! Hugo999 (talk) 09:48, 9 April 2021 (UTC)

An adaptation of the (bicontinental) Russian (or Turkish) sports categories works fine for the Philippines (and does not require editing for specific months/years!); but other editors have to be aware that they cannot use the usual universal category for the Phillipines; see Category:January 2015 sports events in the Philippines. Hugo999 (talk) 11:12, 11 April 2021 (UTC)

Wikipedia app's SuggestEdit ruining short descriptions

Not sure if this is the right place to discuss this, but the SuggestEdit-add 1.0 feature on the android app is encouraging new users to change short descriptions in a way that always violates WP:SDFORMAT, and are half the time complete nonsense. Firstly, it suggests users uncapitalize short descriptions, which leads to new editors (very reasonably!) trusting the app and incorrectly uncapitalizing short descriptions en masse: [14] [15] [16] [17] [18].

When the program does decide to change the actual content in short descriptions, it very often adds complete nonsense. Here's a really lovely short description [19] it suggested (and successfully encouraged a new user to add!) to natural science: branch of science about the natural world and how it relates to statistics, prediction, low-entropy thinking, extra sensory perception (ESP), Prophecising, Apocalyptic Revelations, God, The Trinity, David, Kyle, Alpha, Omega, K, Cabal, cosmos, Wikis. Great stuff.

It's plausible that there's some team I could take this issue up with and some marginal improvement can be made to the program in a months time, but really, I can't see what benefit this possibly serves to the project, it is effectively always disruptive. ‑‑Volteer1 (talk) 17:34, 8 April 2021 (UTC)

@Volteer1: you may want to report this as a bug using this form - sounds like the problem is that this feature is making inappropriate suggestions. — xaosflux ^Talk 17:38, 8 April 2021 (UTC)

Bug report submitted, T279702. – Jonesey95 (talk) 18:00, 8 April 2021 (UTC)

Can we see somewhere if the short description being added is actually the one that was suggested? If the tool is really suggesting someone to use their own username (in lowercase) as short description, then it would be very weird[20]. It looks more as if it suggests to add a short description (with the error of using lowercase), but people are then adding whatever they like anyway, like here, here or here. Still, probably not the best way to get people to edit. Fram (talk) 09:28, 12 April 2021 (UTC)

• For the record, I asked about this here two weeks ago and did a small amount of reading. There is a system at Commons whereby these suggestions are tagged so they can be found easily (as I recall, they hated them). I also saw a discussion, perhaps at meta, where a non-English Wikipedia asked for the first letter to be lowercase so presumably that was implemented. Johnuniq (talk) 23:22, 12 April 2021 (UTC)

Problems accessing WMF sites

Hi - an editor I know and trust has contacted me by e-mail to tell me that she is unable to access WMF sites today - no commons, no EnWiki, no EsWiki. Not that she can't edit, but she can't connect at all, her browser is giving her "The server at en.wikipedia.org is taking too long to respond." She's checked with friends and family in the same locale with same ISP, they can get access, but despite multiple reboots, trying different browsers, even trying her husband's computer, she's not getting access. Other websites all work fine, just WMF sites won't load for some reason. Any thoughts about what to try? If it matters, she's in Mexico. Thanks in advance for any suggestions, which I will have to forward by e-mail (since she can't see this page!). GirthSummit (blether) 18:15, 8 April 2021 (UTC)

I wonder what en.wikipedia.org resolves to for her? SQLQuery me! 18:19, 8 April 2021 (UTC)

Tell her to try using Google Public DNS (8.8.8.8 and 8.8.4.4), this is almost certainly an issue on her end. ‑‑Volteer1 (talk) 18:22, 8 April 2021 (UTC)

Thanks both. I'll ask her... GirthSummit (blether) 18:31, 8 April 2021 (UTC)

Oh, she just told me that she's been able to get onto https://wikipedialibrary.wmflabs.org/users/my_library/, but that's the only WMF related site she's been able to get to load so far. In case that gives you a clue. GirthSummit (blether) 18:33, 8 April 2021 (UTC)

SQL - she sent me a screenshot of what happens when she types 'en.wikipedia.org' into her address bar. The address bar changes to https://en.wikipedia.org/wiki/Main_Page, but she's just seeing the failure screen: The connection has timed out. The server at en.wikipeida.org took too long to respond, etc. Any more thoughts?

Volteer1 - I'm afraid that might be excessively technical for her. She's retired, a first-rate writer, researcher and overall contributor, but her technical skills are not too slick, she's daunted at the thought of attempting that, having had one look at what comes up when she Googles 'Google Public DNS' (I confess, I would be too). GirthSummit (blether) 19:11, 8 April 2021 (UTC)

Girth Summit, Try https://wikitech.wikimedia.org/. That's another wiki that's in a WMF datacenter, but outside the WP:SUL domain, as is (I believe), https://wikipedialibrary.wmflabs.org. If you can get to both of those, but none of enwiki. eswiki, commons, wikidata, etc, then this smells like an auth-related issue.

Today is WP:THURSDAY. A new version of the software was rolled out to enwiki today. There were some recent changes that dropped support for some very old browsers. I don't think that was in today's release, but it's something to consider if she's running something very old.

I would suggest looking in the javascript console and/or network tabs of the developer's tools, but from what you say, I'm guessing that's beyond her technical reach. -- RoySmith (talk) 22:31, 8 April 2021 (UTC)

RoySmith, thanks very much - I'll forward that. GirthSummit (blether) 22:42, 8 April 2021 (UTC)

Girth Summit, Hmmm, interesting, it turns out https://wikipedialibrary.wmflabs.org isn't running WikiMedia at all. It's running something completely different. Which makes me suspect even more that this is a WP:THURSDAY issue. -- RoySmith (talk) 23:23, 8 April 2021 (UTC)

• I woke up to an email telling me she's back on - whatever the problem was, it seems to have gone away (for now at least) - thanks all for your suggestions. GirthSummit (blether) 05:43, 9 April 2021 (UTC)

  @Girth Summit and others, in the future please direct them to Reporting a connectivity issue (wikitech-static is hosted separately, outside the normal Wikimedia datacenter). Legoktm (talk) 07:17, 12 April 2021 (UTC)

  Legoktm, thanks for that link - appreciated. GirthSummit (blether) 08:28, 12 April 2021 (UTC)

Text size changes in references on mobile device?

This is one of those things that's been annoying me forever. On my Android phone viewing the desktop site with Chrome (Vector skin), references appear in either normal or reduced size text (see screenshot).

This seems to be related to whether I've visited a link or not, but it's not that simple. For example, if I tap on the first reference (Connor), the first thing that happens is the text shrinks to the small size. If I tap again, it takes me to the UPI page. If I go back to the wikipedia page and reload, it's back to being the normal size. -- RoySmith (talk) 17:20, 9 April 2021 (UTC)

@RoySmith: It sounds like Wikipedia:Village pump (technical)/Archive 188#What does it mean when a table column font has an unwanted enbiggenment not commanded by wikitext? No way to stop it was posted, apart from using the mobile site. PrimeHunter (talk) 17:37, 9 April 2021 (UTC)

PrimeHunter, Hmm, yeah, that does sound like exactly what I'm seeing, right down to "often result in clicking an unwanted link which has now squirmed to under your finger". Just for fun, I put my desktop Chrome into mobile emulation mode, and couldn't reproduce it, not that I really expected it would. -- RoySmith (talk) 21:20, 10 April 2021 (UTC)

@Sagittarian Milky Way: who started that thread. -- RoySmith (talk) 21:22, 10 April 2021 (UTC)

You can set long press threshold to 0.3 seconds or so. The whole holding down a link then letting go then re-aiming then clicking without risk procedure doesn't have to take that long. Sagittarian Milky Way (talk) 22:06, 10 April 2021 (UTC)

google books URLs need a bot

URLs q.v.:

https://books.google.com/books?id=sDeE9r_6HdsC&pg=PT234&lpg=PT234&dq=Jiyu+hiwar&source=bl&ots=uqCPAz1gx6&sig=2ZDD2RkxILyXnIqm0o42i5PfndU&hl=en&sa=X&ved=0CBwQ6AEwAGoVChMI3qqt6NvhyAIVxWQsCh07igs-#v=onepage&q=Jiyu%20hiwar&f=false

can be cleaned of contributor metadata:

https://books.google.com/books?id=sDeE9r_6HdsC&pg=PT234&lpg=PT234&dq=Jiyu+hiwar&hl=en

.... 0mtwb9gd5wx (talk) 02:45, 10 April 2021 (UTC)

From my experience (from some time ago), page numbers are useless. So the bare minimum is:

https://books.google.com/books?id=sDeE9r_6HdsC&dq=Jiyu+hiwar MarMi wiki (talk) 15:36, 10 April 2021 (UTC)

User:Citation bot does some GB URL cleanup. But I agree we need a dedicated bot for Google Books because there are many issues that can only be determined/fixed with header and page checks. There are millions of Google Books links on enwiki, and many of them no longer work as originally intended: hard and soft 404, link has a page # but redirects to "About this book", book ID usurped and points to a different book, etc.. more at Wikipedia:Google Books and Wikipedia. -- GreenC 03:04, 10 April 2021 (UTC)

IABot

This - https://iabot.toolforge.org/index.php?page=runbotqueue - used to be the link to IABot that I've used for years to archive links. For the past week or so there is an error message 503 Service Unavailable. Any idea what's going on? Firefox Browser, latest version. Thanks. Twofingered Typist (talk) 12:40, 10 April 2021 (UTC)

Tracked in Phabricator
Task T279341

It's down at the moment owing to a database issue. See phab:T279341. ƒirefly ( t · c ) 12:56, 10 April 2021 (UTC)

Thanks! Twofingered Typist (talk) 14:39, 10 April 2021 (UTC)

TOC font size in modern skin

Has there been a change made to the modern skin css to reduce the TOC font size? I might be imagining it but the font size seems a lot smaller than it was. Nthep (talk) 14:34, 10 April 2021 (UTC)

I have 100% certainty that this is the same TOC issue in Timeless as I added to phab:T279693. Izno (talk) 15:27, 10 April 2021 (UTC)

Glad it's not my eyesight or memory! Nthep (talk) 16:38, 10 April 2021 (UTC)

Picture title mis-spelled

There is a picture of the opening of the Stockton and Darlington Railway (File:Opening of the Stockton and Darlington Railway.jpg). There is also a cropped version (File:Opening of Stocking and Darlington Railway (crop).jpg) whose title is obviously mis-spelled (Stocking for Stockton). The latter is only linked once in en.wikipedia (from Stockton and Darlington Railway), but it is also linked from the es.-, ka.-, no.-, and zh.wikipedias.

Can I move this page to a correct spelling? Will this leave a redirect in place, and will that redirect work for the other wikipedias? I have never moved an article, and this is a file: rather than a mainspace article, so I don't want to make a mess through ignorance.

Also, how can I put a link to the file into this talk that shows the title (informative) rather than pulling in the picture (pretty, but not so germane)?--Verbarson (talk) 20:43, 10 April 2021 (UTC)

1. You don't have the requisite permissions to move the file, but you can request someone who does move to file by visiting the file's page on Commons (c:File:Opening of Stocking and Darlington Railway (crop).jpg) and clicking the "Move" link (which may be in a "More" menu). I've now done that for you. Once a Commons file mover processes my request, the move will leave a redirect, which will work on other Wikipedias. Nevertheless, it's customary for them to use a script to automatically replace all usages on all wikis, although I'm not sure why.

2. You prefix the link with a leading colon ([[:File:Example.png]] produces File:Example.png) * Pppery * it has begun... 20:55, 10 April 2021 (UTC)

Thank you. I'll keep an eye open for the rename to take effect.--Verbarson (talk) 21:38, 10 April 2021 (UTC)

As a Commons filemover, I've done the requested move. Graham87 03:15, 11 April 2021 (UTC)

Graham, thank you.--Verbarson (talk) 10:59, 12 April 2021 (UTC)

Table of contents limit doesn't appear to work on QAnon page

A couple of times over the last few months, I've tried to set a Table of Contents limit (Template:TOC limit) on the QAnon page. There are currently 54 sections listed in the articles' ToC. Limiting it top-level headers only would bring the number down to a much more reasonable 15, making the page more readable for all users. However, each time I try to put the limit in place, it breaks something and the ToC either disappears, or the lead does. Does anyone know what's going wrong? Thanks. Ganesha811 (talk) 21:50, 10 April 2021 (UTC)

It looks like you inserted {{TOC limit|1}}, which does nothing. TOC level 1 is the page title. Level 2 are the main headings on the page, so {{TOC limit|2}} limits the TOC to a single level. A bit confusing, I know. – Jonesey95 (talk) 22:29, 10 April 2021 (UTC)

Jonesey95, thanks for the help! Makes sense. Ganesha811 (talk) 23:59, 10 April 2021 (UTC)

Level 1 headings have a single "=" but we don't use that in articles and rarely in other places. It's used for date headings in some pages, e.g. Wikipedia:Help desk. PrimeHunter (talk) 11:05, 11 April 2021 (UTC)

Reflinks still down

I've just noticed that Reflinks are still down. Would we be able to get this fixed please because I find it so important for content creation. I've asked on Meta but they haven't been much help. The C of E God Save the Queen! (talk) 08:05, 11 April 2021 (UTC)

I don't see how. The user seems to have disappeared. —TheDJ (talk • contribs) 09:22, 11 April 2021 (UTC)

It's giving the code errors, would WikiMedia be able to copy it over and fix it? @TheDJ: I ask because it allows you to fix all the errors at once rather than Citer which does it only one at a time. The C of E God Save the Queen! (talk) 10:34, 11 April 2021 (UTC)

Alternatively you could try using reFill which, presently, is working and will do multiple cites. - Derek R Bullamore (talk) 14:30, 11 April 2021 (UTC)

FYI The C of E reflinks was down for more than a year - more or less. Then it started again a couple months ago which was a big help but now it has been gone for a couple weeks so I wouldn't expect it back anytime soon. Its formatting of PDFs and marking of dead links are big pluses over refill but we just have to soldier on with the tools that are working. Thanks for your work dealing with bare urls. MarnetteD|Talk 18:19, 11 April 2021 (UTC)

It's just so annoying ReFil doesn't put accessdates. If only we could combine the mass ref fixing of ReFill with the detail of Citer. The C of E God Save the Queen! (talk) 08:19, 12 April 2021 (UTC)

ReFill has a preference setting to add an access date; is it not meeting your needs? isaacl (talk) 14:34, 12 April 2021 (UTC)

Johnny Iguana

This article, which I recently created, has rendered the article's title in italics. I believe it is because I have included an album infobox within the article, as per the guidance given here. Is there a way of getting the article's title back to normal type, without the disruption of deleting the album infobox altogether ? Thank you. - Derek R Bullamore (talk) 13:02, 11 April 2021 (UTC)

Derek R Bullamore, you're completely right about the cause, the solution is adding italic_title=no to {{Infobox album}} --Trialpears (talk) 13:11, 11 April 2021 (UTC)

Thanks for that, and the correcting edit. Like a flash of lightning ! - Derek R Bullamore (talk) 13:13, 11 April 2021 (UTC)

Get a revid

Anyone know how to grab the latest revid for a given page from an API? Sam at Megaputer (talk) 18:15, 11 April 2021 (UTC)

Special:ApiSandbox#action=query&format=json&prop=revisions&titles=Wikipedia:Sandbox&rvprop=ids&rvlimit=1 works. * Pppery * it has begun... 18:17, 11 April 2021 (UTC)

Or Special:ApiSandbox#action=query&format=json&prop=info&titles=Wikipedia. Nardog (talk) 18:20, 11 April 2021 (UTC)

Thanks. Both of those work well. Sam at Megaputer (talk) 18:27, 11 April 2021 (UTC)

Microscopic barnstar

Hi, here are two screenshots of a barnstar as shown on my Samsung Galaxy J3 (2016) mobile by the app Samsung Internet v. 13.2.3.2:

• File:En wiki barnstar on Samsung mobile 2021-04-11-21-02-08.png - a 'normal' view
• File:En wiki barnstar on Samsung mobile 2021-04-11-21-02-30.png - zoomed-in

What can I do to see the star in some reasonable size, comparable to the text? --CiaPan (talk) 19:23, 11 April 2021 (UTC)

The screenshots are from User talk:Bluefist#A barnstar for you! The image is alone in a table cell. Samsung Internet probably chooses to display it tiny to get more space for text in other cells. I don't have a solution. PrimeHunter (talk) 19:45, 11 April 2021 (UTC)

May be I should've added I use the MonoBook skin. No idea if that matters. --CiaPan (talk) 20:02, 11 April 2021 (UTC)

This is an issue in some skins (Timeless also has it occur) for images and certain responsive views. I don't understand what it is about the responsive views that causes it. (Presumably some 'upstream' CSS somewhere).

I think technically it could also occur in Minerva/mobile if we didn't have a line in MediaWiki:Mobile.css that prevents the width of images from shrinking beyond recognizability. Izno (talk) 20:10, 11 April 2021 (UTC)

Just checked, it's only fixed onwiki for flagicons, see phab:T116318. --Izno (talk) 20:11, 11 April 2021 (UTC)

Yeah intentional. As there is no good way to know the intended minimum size of an image inside a table. The best way is to set a min image size on the image via a template or something (if u want to keep it). Or to simply hide the image altogether if it’s decorative (like the mbox mobile styles in my narrow/wide screen gadget do). Author styling that handles the responsiveness. It’s just flagicons in tables are so prevalent that we deployed a fix for that. —TheDJ (talk • contribs) 06:49, 12 April 2021 (UTC)

rd's not listed at "Pages that link to X"

Wondering why redirects don't show up at [Pages that link to "X"] where there are tags on the page, such as the rd being under discussion. Makes it difficult to see if there are other rd's for variations of the name being discussed that should all be redirected together. — kwami (talk) 05:32, 12 April 2021 (UTC)

Please post an example when you report an issue. If redirects are tagged for discussion like Paralvinella then they are not redirects during the discussion because we want users to find the discussion. They still link to the target and should show up at WhatLinksHere as normal links. Special:WhatLinksHere/Alvinellidae correctly shows Paralvinella. It disappears as it should if you click "Hide links". The search insource:"redirect Alvinellidae" finds Paralvinella. It doesn't find actual redirects because redirects are excluded from search results. "redirect" is rendered so you can also just search "redirect Alvinellidae". PrimeHunter (talk) 09:20, 12 April 2021 (UTC)

Thanks. Yes, it was hidden when I clicked "hide links". I didn't know about the "redirect Alvinellidae" thing. — kwami (talk) 19:11, 12 April 2021 (UTC)

Can't log in with Safari on iOS

As the subject line says. I can log in on my desktop, and I can log in on Chrome on my iPhone; but when I use Safari on the iPhone, with the same user name and password as I just used a minute ago in Chrome, I get the error "Incorrect user name or password entered." Any idea what could be causing this? --R'n'B (call me Russ) 12:09, 12 April 2021 (UTC)

@R'n'B: Some things to check: Are you using a current version of Safari? Are you using stored usernames/passwords? Are you using 2FA? Is the date-time on your device correct? — xaosflux ^Talk 16:25, 12 April 2021 (UTC)

@Xaosflux: 1) It's remarkably hard to find a version number for Safari on iPhone, because it is so tightly integrated into the operating system (which is iOS 14.4.2). 2) Although I usually use stored usernames/passwords, I tried entering both manually before posting this thread; it didn't make any difference. 3) Yes, I'm using 2FA, but this error message occurs before I am asked to enter an authentication code. 4) Hopefully, today is 12 April 2021 and it is 1:00 pm EDT. :-) In which case, yes. --R'n'B (call me Russ) 17:01, 12 April 2021 (UTC)

R'n'B, You could also try creating a second account. Name it something like User:R'n'B-testing, and add a note on the user page stating that it's an alternate account of yours, to prevent any accusations of socking. Then, see if you get the same behavior with that account. -- RoySmith (talk) 16:32, 12 April 2021 (UTC)

@RoySmith: Interesting suggestion; I'll try it later. --R'n'B (call me Russ) 17:01, 12 April 2021 (UTC)

@RoySmith: OK, I created User:RnB-test2, and that account is able to log in to Safari with no problem. But the original account still can't log in. --R'n'B (call me Russ) 23:53, 12 April 2021 (UTC)

R'n'B, OK, well at least that says it's nothing inherent with your software. I'm not familiar with Safari on iOS, but I'm assuming it's got some way to clear your cache. I'd certainly try that. There may also be a way to find what cookies you've got in the "wikipedia.org" domain and delete them all. That would be the next thing to try. -- RoySmith (talk) 00:02, 13 April 2021 (UTC)

RoySmith Thanks, I should have thought of cookies myself (but didn't). To be safe, I deleted all wikipedia.org and wikimedia.org and all the other WMF domains. And I still can't log in.... --R'n'B (call me Russ) 00:09, 13 April 2021 (UTC)

R'n'B, Just a hunch, maybe it's the quotes in your user name (but not in your alternate account username). Try another account, with the two quotes just like in your primary account name. -- RoySmith (talk) 00:23, 13 April 2021 (UTC)

So, this is interesting. I just created User:RoySmith-testing'with'quotes. I can log in on my desktop, when I tried it on an iPhone, I couldn't log in with either Chrome or Safari. I was able to log into my User:RoySmith-testing account. So, yeah, I'm guessing something on the phone doesn't like the quotes. -- RoySmith (talk) 00:44, 13 April 2021 (UTC)

Solved. The problem is caused by the virtual keyboard on the iPhone, which generates a right single quotation mark (U+2019) character by default when the ’ key is pressed, while my user name uses an ASCII apostrophe (U+0027) character. Bizarrely, when you long-press the ’ key, four alternatives pop up, with the straight apostrophe highlighted, which to me intuitively (but incorrectly) suggests it is the default value for that key. In fact, on the iPhone's US English keyboard, all the keys that have multiple possible values assigned to them highlight their default value when long-pressed, except the single and double quotation marks, which highlight a non-default value (that is, the straight quotation marks are highlighted on a long-press, but a normal keypress generates the curly varieties). This is an, ahem, questionable design choice by Apple. --R'n'B (call me Russ) 13:59, 13 April 2021 (UTC)

This is an option that can be turned off. Go to Settings → General → Keyboard and uncheck the box for "Smart Punctuation" -FASTILY 23:43, 13 April 2021 (UTC)

Line numbering coming soon to all wikis

-- Johanna Strodt (WMDE) 15:08, 12 April 2021 (UTC)

Add links in Wikidata banner

If there is only one Wikidata link connected to one item (ENWP article connected to Wikidata) there is "Add links" button which allow us to add article in other language directly on Wikipedia but if there is already one link conected then there is button "Edit links" instead of "Add links" which is redirecting us to Wikidata. Would it be possible to add "Add links" button in case when more than one language version is connected? Eurohunter (talk) 11:57, 13 April 2021 (UTC)

Robert Héliès

Hello, for some reason there are two pictures in the infobox of Robert Héliès. I don't know how to fix this and this appears to be a technical problem as the image is only inserted once but appears twice. (It's a double infobox). Paul Vaurie (talk) 18:41, 13 April 2021 (UTC)

Fixed with a work-around in the embedded template which was pulling the image from Wikidata. MB 20:20, 13 April 2021 (UTC)

Thank you. Paul Vaurie (talk) 16:01, 14 April 2021 (UTC)

"Powered by MediaWiki" box logo

I noticed that the "Powered by MediaWiki" box that appears in the extreme lower right hand corner of the desktop version of Wikipedia is still using the old MediaWiki logo. Has a request been made to change it, and if not, how can we do so? {{u|Sdkb}} ^talk 18:53, 13 April 2021 (UTC)

Sdkb, probably a caching issue. I have it show up on some devices and not others. --Trialpears (talk) 18:57, 13 April 2021 (UTC)

Ah, makes sense. I just checked on another browser and it's changed. Hopefully the cache will clear for most users at some point soon, as I think it's been changed for several weeks now. {{u|Sdkb}} ^talk 19:00, 13 April 2021 (UTC)

It's updated on my devices - it's not a major deal but hopefully it'll update everywhere soon. Remagoxer (talk) 19:20, 13 April 2021 (UTC)

Danny Rivera

This is something I have never seen before. When you first load this article, the title looks fine... but keep watching and within a second or two, the capital "R" at the start of the surname reverts to the lowercase styling. Most bizarre. Anyone know why ? Is it just me ? - Thanks. - Derek R Bullamore (talk) 21:07, 13 April 2021 (UTC)

I'm not seeing it. TAXIDICAE💰 21:17, 13 April 2021 (UTC)

I don't see it either. Try the usual: a different browser, viewing the article while logged out. – Jonesey95 (talk) 21:25, 13 April 2021 (UTC)

I can't see that, but every time I open the page, the browser—Edge Version 89.0.774.75 (Official build) (64-bit)—prompts me to translate it from Spanish back to English!?--Verbarson (talk) 09:01, 14 April 2021 (UTC)

Probably because of the extensive Spanish-language cites in the lead paragraph.--Verbarson (talk) 09:04, 14 April 2021 (UTC)

On Edge 89.0.774.57 32-bit this doesn't happen (or maybe it's just a matter of browser user settings).

It's probably because your browser tries to translate that page for some reason - google translate (es to en) lowercases the word "riviera". MarMi wiki (talk) 16:13, 14 April 2021 (UTC)

Right to left text confusion

At Hani al-Hassan, I'm trying to fix the date in the first line from l939 to 1939 (note that the first one has an "l" (el) instead of a "1" (one). I think the problem is a hidden character doing right to left text or something, but I can't figure it out. Suggestions?

Similar problems at:

• Gholam Mohammad Niazi with l932
• Ibrahim Nassar with l895
• Amin Abd al-Hadi with l897
• Hamdi al-Pachachi with l886

Thank you, SchreiberBike | ⌨  21:42, 13 April 2021 (UTC)

I edited Hani al-Hassan and inserted <bdi> tags, see HTML element#bdi. I learned that trick at Commons but don't know if there is some template that would be preferable here for clarity. Johnuniq (talk) 22:18, 13 April 2021 (UTC)

I inserted a left-to-right mark ‎ in the others. PrimeHunter (talk) 22:25, 13 April 2021 (UTC)

Shouldn't {{rtl-lang}} be able to deal with it while providing proper labeling for screen readers? For some reason I still experienced weirdness when testing it. --Trialpears (talk) 22:41, 13 April 2021 (UTC)

I don't know what is best for screen readers. None of the solutions are activated in the edit window. What works there is any text in a left-to-right script like English. For example, for &lrm; it is the string "lrm" (or just the initial "l") which works in the edit window. {{rtl-lang}} only places English letters before the text in the edit window so it doesn't work there. PrimeHunter (talk) 23:41, 13 April 2021 (UTC)

Thanks all. SchreiberBike | ⌨  00:31, 14 April 2021 (UTC)

Weird TOC at Chabad

The entire Activities section in the TOC of the Chabad article is highlighted with red. This might be just my screen—does anyone else see this?—what's the cause? It kind of looks like the same red highlight given to unreliable sources through User:Headbomb/unreliable.js; maybe that has something to do with it? Aza24 (talk) 02:23, 14 April 2021 (UTC)

I can confirm it is indeed caused by that script. (It doesn't show for me when I visit the page, and if I manually import the script in the browser console, the section does turn red). * Pppery * it has begun... 02:25, 14 April 2021 (UTC)

Then I suppose this may be the wrong place to discuss the matter, but I'll ping Headbomb regardless. @Headbomb: – Aza24 (talk) 05:11, 14 April 2021 (UTC)

Indeed. Caused by a match of chabad.org in a list (TOCs are lists). Since it's topical and not inappropriately mentioned, you can simply ignore what the script is doing to the TOC in that article. Headbomb {t · c · p · b} 09:07, 14 April 2021 (UTC)

Page titles showing up as section links in summaries

I'm seeing page titles in section links in summaries (e.g. "→Wikipedia:Village pump (technical)") lately more often than I remember. The links are redundant and lead to nowhere because H1 headings don't have IDs matching the captions like lower-level headings do. It looks like they are mostly Android app edits. Is this something that's being worked on? Nardog (talk) 04:12, 14 April 2021 (UTC)

Likely a bug that needs reporting and sorting. Izno (talk) 05:38, 14 April 2021 (UTC)

It looks like when you edit the introduction on the Android app, it includes the page title in the summary as the section name. – BrandonXLF (talk) 05:58, 14 April 2021 (UTC)

CATCSD down

Cross-posting from AN as this is a technical issue, about the lists of CSD by date not being available: Wikipedia:Administrators' noticeboard#CATCSD down. Please comment there. Fences&Windows 12:29, 14 April 2021 (UTC)

CS1 errors: extra text: volume

I noticed that an article I brought to FA, First Battle of Newtonia, is now flagging a CS1 error for long volume value. It's unclear what's wrong, because the red text of doom telling me where the error is isn't showing up. My guess is that it's the Foote 1986 [1958] source, but that's literally the title of the volume. Are the CS1 citation templates so inflexible that they flag errors for things with volumes that aren't just a numeral? I'm also now getting messy colorful error messages whenever the "discouraged parameter" |accessdate appears now. Makes me want to switch to <ref> </ref> referncing now, since it seems that the CS1 templates are so inflexible it's just perpetually giving me errors now. Hog Farm _Talk 14:21, 14 April 2021 (UTC)

Click on the "help" link. It will tell you that you need to remove the word "volume". Izno (talk) 14:48, 14 April 2021 (UTC)

Done, but no help link was appearing in the article page. Unsure why this is an error now, because "Volume 1, Fort Sumter to Perryville" is going to make more sense to the reader than "1, Fort Sumter to Perryville". Not a fan of a lot of the new citation template changes, as they just wind up making everything harder to use. Hog Farm _Talk 15:15, 14 April 2021 (UTC)

The error message is now hidden as a result of this edit.

Category:CS1: long volume value‎ is not a maintenance or error category; it is a properties category that was created as a research tool to understand how |volume= is used.

Category:CS1 maint: discouraged parameter collects articles that use cs1|2 templates with nonhyphenated multiword parameter names. This is not an error category. At some point in time you must have added the css listed at Help:CS1 errors § Controlling error message display to one or more of your personal css pages (these and all other maintenance messages are hidden by default). You can remove that css from your personal css page so that you will not see these messages.

The error message is at Foote 1986 because |volume=Volume 1, Fort Sumter to Perryville contains the word 'volume'. In most cases, the name of a parameter in that parameter's assigned value is inappropriate duplication. This is being discussed at Help talk:Citation Style 1 § Using volume= with cite book.

—Trappist the monk (talk) 15:21, 14 April 2021 (UTC)

Would this be a case where the ((...)) trick could be introduced to allow inclusion of Volume when it is appropriate, as here? —  Jts1882 | talk  15:39, 14 April 2021 (UTC)

The accept-this-as-written markup can be used for false-positive |volume= errors. Be sure that you report these false positives at Help talk:Citation Style 1 so that they can be fixed (if a fix is possible).

—Trappist the monk (talk) 16:06, 14 April 2021 (UTC)

How to upload a wiki file?

If I have a text file containing wikitext, is there some easy way to upload it to enwiki, short of copy-paste? Yeah, I know I could do something through the API, but surely somebody's already whipped up a wiki-version of scp? -- RoySmith (talk) 14:22, 14 April 2021 (UTC)

@RoySmith: not natively, the only pure "upload" option would be via Special:Import, which would need to be in XML format (c.f. mw:Manual:Importing XML dumps) , and access to which is highly restricted. Any other methods would be shims on top of the webui or api (barring special back-end shell access things which realistically are not going to get exposed to any sort of normal editing processes without a very very good reason). — xaosflux ^Talk 16:23, 14 April 2021 (UTC)

The closest path to this would likely using the REST API along with some sort of script, but once you start trying to invent that you could just use something like mw:Manual:Pywikibot/pagefromfile.py to do all the heavy lifting. — xaosflux ^Talk 16:31, 14 April 2021 (UTC)

Xaosflux, Hmmm, the pywikibot thing looks like it might be what I wanted, thanks. -- RoySmith (talk) 16:34, 14 April 2021 (UTC)

RoySmith, I basically have that set up here in my spihelper deployment script. ^{SubjectiveNotability} _{a GN franchise} (talk to the boss) 16:54, 14 April 2021 (UTC)

Technical possibilities of creating an edit filter that targets app users

Black Kite suggested the possibility of creating a filter on User talk:Jimbo Wales#The tragic case of User:CejeroC, even saying It would actually be very trivial to disable mobile app editing through the edit filter.

Having looked at various existing abuse filters and mw:Extension:AbuseFilter/Rules format I see that it's possible to filter by user group, text contents, account age, etc but I can't find any option to filter by tag which would be required for such a filter to even be a technical possibility.

Per T206490 Make it possible for the AbuseFilter to check change tags this is indeed not actually possible, but this task hasn't been active for a while so I don't know if this is still accurate.

Is there any way to target app edits with AbuseFilter? (we're not yet talking about whether we should, but is it even possible?) — Alexis Jazz (talk or ping me) 22:53, 14 April 2021 (UTC)

The user_app variable. It's documented on that rules page. ProcrastinatingReader (talk) 22:56, 14 April 2021 (UTC)

Alexis Jazz, the presence of a variable user_app suggests to me that it's likely possible to disallow or warn edits that way - but I don't know if warning would show up on the mobile app. FWIW I think that the apps are the problem and need fixed. -bɜ:ʳkənhɪmez (User/say hi!) 22:59, 14 April 2021 (UTC)

Thank you both, I had overlooked that. Berchanhimez, no, it wouldn't show up. The apps are the problem, but nobody is fixing them. — Alexis Jazz (talk or ping me) 23:05, 14 April 2021 (UTC)

The bigger problem, as mentioned at the original discussion, is not actually implementing an edit-filter block, but the fact that (unless the latest version fixes it, which I doubt) the apps are also broken in the respect that it is awkward (iOS) or impossible (Android) for an edit-filter to direct IP app users to a landing page that actually explained why they couldn't edit. IMO this would cause even more problems than actually blocking the edit function in the first place. Black Kite (talk) 23:08, 14 April 2021 (UTC)

@Black Kite: Is it possible to run a site-wide campaign for a month or so using a CSS class that only app users can see? (I'm hoping such a CSS class exists) — Alexis Jazz (talk or ping me) 23:24, 14 April 2021 (UTC)

If they can't see the warnings, I think it is beneficial to block all edits from the mobile app (via a filter) until such time that the app developers make the apps work. It's not our fault nor our problem that app editors are suffering - and maybe if we disable editing via the app they will actually take notice and fix it. So thus I support fully an edit filter that blocks all mobile app edits until such time as they fix the apps to work with Wikipedia standards of communication. -bɜ:ʳkənhɪmez (User/say hi!) 23:40, 14 April 2021 (UTC)

Here is an example of a user that used mobile app, abuse filter is able to determine that: Special:AbuseFilter/examine/1374567200. — xaosflux ^Talk 23:46, 14 April 2021 (UTC)

Special:Book background broken

Most of the contents at Special:Book overflow on top of the white background box. I'm guessing this is a CSS issue somewhere, but couldn't find the cause. --Trialpears (talk) 23:11, 14 April 2021 (UTC)

Something is missing a clear or a width. Izno (talk) 23:18, 14 April 2021 (UTC)

Convert all English variant notices to editnotices

This proposal arises from an ongoing discussion at the idea lab about how to reduce the clutter of excessive talk page banners, a phenomenon that leads to banner blindness, overwhelming and confusing new editors and reducing the visibility of the more important notices.

One idea I put out that seems to have gotten particular traction is that there is no need to have English variant notices (e.g. {{British English}}) appear on the talk page, rather than just as an editnotice that appears in the edit window while one is editing the article. The primary rationale is that no one is policing the English variety used on talk pages, so the only place this is needed is the editnotice. I'm therefore proposing here that we convert all existing English variant notices on talk pages to editnotices on the corresponding page. This would be done via a bot task, and once completed Module:English variant notice would be configured so that it produces an error notice if placed on an article talk page. {{u|Sdkb}} ^talk 14:34, 10 January 2021 (UTC)

Survey (English varieties)

• Support as nominator. To address two potential concerns: (1) In the rare instance that there's a talk page discussion about changing the variant, it's easy for the proposer to provide the context. I can't think of any other situation in which people on the talk page need to pay attention to the variant. (2) Modifying editnotices currently requires advanced permissions; my understanding is that this is for technical reasons rather than because of any editorial consensus. This is an issue that ought to be addressed on its own at some point, but I don't think it's an insurmountable impediment here, as most pages developed enough to be tagged with a variant notice are monitored by editors able to modify it, and if not, they will be prompted to create an edit request, which is quite straightforward. {{u|Sdkb}} ^talk 14:34, 10 January 2021 (UTC)
• Support This is a good idea and should be implemented, provided any technical issues are addressed eventually (new permission?). GenQuest ^"scribble" 15:34, 10 January 2021 (UTC)
• Support there's a dual benefit as it simultaneously improves both the talk page (by reducing clutter) and the edit screen (by displaying relevant info), a win-win. --Paul ❬talk❭ 16:55, 10 January 2021 (UTC)
• Oppose The proposal seems half-baked because it doesn't address the use of templates like {{Use British English}} which are what I see most often. For talk pages, we could use something like an infobox which would contain key pieces of information about the article such as its size and quality rating. The dialect would fit best in such a summary of the article's properties. Andrew🐉(talk) 17:26, 10 January 2021 (UTC)

  Regarding the "use" templates, this wouldn't affect them one way or another; they'll continue being available for when it's desirable to designate a variant but there's not enough erroneous editing for there to be a need for a notice. We could discuss down the line how often to have something visible vs. invisible, but for now I think getting all the visible notices into editnotice format is the best first step.

  Regarding your idea for a hypothetical talk page infobox, I'd suggest proposing that at the broader idea lab discussion. I could support it if it's implemented well, but it's beyond the scope of the more narrow change I'm trying to achieve here. {{u|Sdkb}} ^talk 19:12, 10 January 2021 (UTC)

• Excellent idea. I suspect if editnotices had existed when these templates started this problem would not have arisen. ϢereSpielChequers 18:50, 10 January 2021 (UTC)
• Strong support if implemented, this would be huge for reducing talk page clutter, and actually making the english variety notices effective. As I said at the idea lab, the people who are disregarding or ignoring an established English variety aren't going to be on the talk page and see it there. As such, I'm convinced that the current position on the talk page is basically worthless. Aza24 (talk) 21:03, 10 January 2021 (UTC)
• Support this seems like a way to make the information more effective and reduce talk-page clutter at the same time. Thryduulf (talk) 22:06, 10 January 2021 (UTC)
• Support we do this for a few Canadian articles already...like Template:Editnotices/Page/Canada....still not seen in mobile view :-( --Moxy 🍁 01:06, 11 January 2021 (UTC)
• Oppose Arguments below convince me this is not a great idea. I think that it's better to use the "silent" {{Use American English}} etc and at worst let gnomes fix the problems. — Wug·a·po·des​ 23:07, 16 March 2021 (UTC) Support great idea. One added benefit is that it reduces ownership of articles by preventing new users from posting useless engvar tags. Since only admins, template editors, and page movers can add these if we make them edit notices, it also gives template editors and page movers something to do. — Wug·a·po·des​ 02:54, 11 January 2021 (UTC)
  • I also like the idea of removing them altogether. — Wug·a·po·des​ 21:45, 13 January 2021 (UTC)
  • Template editors and page movers may not want something else to do. It seems simple enough to write a bot with the necessary permissions to do this. ChromaNebula (talk) 23:20, 26 January 2021 (UTC)
• Support for all of this genre of notices (engvar, date formats etc.), but -- perhaps heretically -- I would support all top-of-the-page cleanup notices going into editnotices as well, so people who just want to consult an article for information aren't bothered with them. Beyond My Ken (talk) 03:17, 11 January 2021 (UTC)

  Beyond My Ken, by top-of-the-page cleanup notices are you referring to things like {{NPOV}} or {{Original research}}? I think those notices are pretty necessary from a reader perspective, since readers deserve to know when an article has significant problems so that they can read it with due caution and skepticism (yes, people should always be doing that, but they trust us enough they de facto often don't). That's more true for some notices than others, though; I could see a case for many of the yellow style ones like {{Cleanup bare URLs}} to be converted to be shown to editors only. The question at that point becomes whether we're wasting an opportunity to convert readers to editors by offering them an easy task. All this is tangential to the current discussion, so maybe take it elsewhere if you want to develop it further, but I hope my comment is food for thought. {{u|Sdkb}} ^talk 11:05, 11 January 2021 (UTC)

  No, you are correct, I was referring to the "yellow style" ones which primarily concern editors only. Beyond My Ken (talk) 21:26, 11 January 2021 (UTC)

  I would argue that a fair number of the yellow banners are useful to readers (eg Template:Overcoloured letting colourblind users know that they may not interpret something on the page correctly, or Template:Essay-like). Further, as I've been editing even the ones which non-editor readers may not find useful now inform how I read. For example, seeing Template:Debate wouldn't have changed how I read something in the past, but now it suggests to me that people may have POV forked, there may not be great usage of reviews/meta-analyses (in the case of scientific articles), or its editing may have been a series of unconnected additions. They're also useful for the purpose of editing - I will detour from doing other tasks to correct an article if I notice some kinds of banners, including when I wasn't intending to edit it. --Xurizuri (talk) 10:55, 12 January 2021 (UTC)

• Support Great idea, this banner contributes to creep and I hope that this reduces needless conflict, as many well intentioned edits from new and IP editors are related to ENGVAR. --Tom (LT) (talk) 03:20, 11 January 2021 (UTC)
  • Having read through some comments below I have come to change my mind. As pointed out below this is likely to result in a large amount of editnotices that is likely to frustrate and deter editors. Tom (LT) (talk) 10:56, 6 April 2021 (UTC)
• Support not useful on talk pages, useful when editing which shows on editnotice. No need for new permission, nor should editing editnotices be available to all, PMR & TPE can do this. If the TPER queue becomes too long, we can get a bot with TPE to carry over additions from the talk page into the editnotice. ProcrastinatingReader (talk) 09:21, 11 January 2021 (UTC)

  Striking in favour of using hidden templates such as {{Use British English}} on the article prose, as said by Whatamidoing, and removing all the editnotices and talk page banners and converting them into hidden templates such as {{Use British English}}. Alternatively, a {{article standards}} template, as described in the thread by Levivich. Arguments by Levivich & L235 are compelling imo. ProcrastinatingReader (talk) 15:15, 5 February 2021 (UTC)

• Support per proposal ~ ToBeFree (talk) 11:09, 11 January 2021 (UTC)
• Support – reducing talk page template bloat and helping new editors understand Engvar at the same time sounds like a clear win-win to me. AngryHarpy‍^talk 12:47, 11 January 2021 (UTC)
• I think I oppose for sympathetic reasons. 2 reasons: 1) I do not think this is technically feasible. It asks to make an edit notice for essentially 6 million pages. That's an awful lot of infrastructure. (Someone tell me I'm wrong.) 2) I do think the correct remedy is removing these in their entirety from talk pages. We do not need them present in both their canonical place as article tags as well as talk pages. (Replace as needed on the article proper.) --Izno (talk) 14:41, 11 January 2021 (UTC)
  • @Izno: I think it would be at most creating 41,000 edit notices with current use of the eng var module. --Paul ❬talk❭ 18:36, 11 January 2021 (UTC)
    • Just a casual 41k. Eyeroll. --Izno (talk) 18:44, 11 January 2021 (UTC)
      • Trivial for a bot. Thryduulf (talk) 19:57, 11 January 2021 (UTC)
      • Trivial or not, a very different figure to 6 mil. --Paul ❬talk❭ 21:14, 11 January 2021 (UTC)
        • Creation is "trivial for a bot". Maintenance and filtering through the noise in the template namespace looking for anything but edit notices? Yeah, not so much. --Izno (talk) 01:39, 12 January 2021 (UTC)
• Support This seems like a good idea worth pursuing. --Jayron32 18:16, 11 January 2021 (UTC)
• Support Reducing talk page clutter is a good idea. Remagoxer (talk) 20:51, 11 January 2021 (UTC)
• Support. It'd be more useful as an edit notice - I know I never check first, and it's a pain to have to open the talk page in a new tab (especially as I have ADHD and sometimes forget the variant as soon as I close said tab). Ideally, similar notices about the style of writing in a given article would also be great to have as edit notices. However, a concern would be that by reducing talk page clutter, we need to not just relocate the clutter (sweeping it under the carpet, so to speak). --Xurizuri (talk) 10:55, 12 January 2021 (UTC)
• Support, but what about protected pages? There might be an increase of (incorrect) ENVAR edit request, I guess you would also add a en-varent message on the talk page too? (please ping) DarthFlappy 18:53, 12 January 2021 (UTC)

  @DarthFlappy: I would expect that the vast majority of edit requests come from people trying to edit a protected page (that they don't meet the requirements of), clicking the button to request an edit and filling in the form. You might have noticed many are blank—this is because people don't read what's on their screen and just click the big blue "Submit" (maybe thinking that they're requesting permission for them to be given edit access). But anyway, I wouldn't think the talk page banner would really make a difference on edit request content. — Bilorv (talk) 23:49, 14 January 2021 (UTC)

• Oppose Will only worsen banner blindness. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:41, 12 January 2021 (UTC)
• Support but not at scale, and only as a pilot. As I understand this could affect millions of articles, so please try it first as a pilot for 100s of articles. Big changes like this are best done with test cases, time passing, multiple requests for comment, and documentation. This already has my general support and also I anticipate supporting again in the future, but the proposal as it is has no limits. The scale and pace of the changes matters to me. I am only expecting volunteer-level documentation and not the best and most complete, and I encourage the pilot. I recognize the existence of the problem and feel that it will only grow. There are various possible solutions, and perhaps we have to use several solutions at once to address this issue. Please develop this one solution first. Blue Rasberry (talk) 20:51, 12 January 2021 (UTC)
• Oppose editnotice banners are far more annoying than talk page notices. They slow down editing. Graeme Bartlett (talk) 22:18, 12 January 2021 (UTC)
• Oppose — Enwiki has got to be the only publication in the world that writes a single work using multiple varieties of English. Engvar isn't important enough to have talk page banners for, I agree, but the solution is to remove them altogether. Moving them to the edit notice will create edit notice blindness instead of talk page banner blindness, and that's even worse, because in theory, edit notices have the really important stuff, even moreso than talk page headers. Creating thousands or millions of edit notices is a huge overhead and maintenance increase. Edit notices are annoying and largely ignored anyway. They don't show at all for mobile users. In all, I think this moves the problem to a worse place rather than alleviating it. Levivich ^harass/_hound 04:53, 13 January 2021 (UTC)

  This is a fair point. I was thinking the notice should be trimmed down, literally into a bullet point like: “* This article uses British English.”. Alternatively, we can have a single “Article conventions” talk page template which is highly trimmed down and signifies standards like the variety of English used — this assumes that there are other types of standards other than English and date variety that could possibly apply. A bit like {{article standards|lang=British|dates=dmy}}. ProcrastinatingReader (talk) 09:16, 13 January 2021 (UTC)

  An article conventions template sounds like a very good idea. There are probably others besides engvar and usedmy, but those two are good examples. I would find iconography to be the most efficient way of communicating these sorts of things, but I'm not sure if everyone would be on board for that. So like a little British flag somewhere if it was use BrEng, a US flag for AmEng, something like that. Levivich ^harass/_hound 17:27, 13 January 2021 (UTC)

  I agree that the notices should be kept unobtrusive and concise. Regarding the "just remove them entirely" point, we already have the e.g. {{Use British English}} family of templates, which set the standard without displaying anything, just as you describe. I'm undecided about whether/when we should use that compared to {{British English}}, but I think that, in circumstances where it is important enough to warrant a banner, that banner should be proximate to the place it actually applies, which means putting it in the edit notice next to the article rather than the talk banners next to the talk. {{u|Sdkb}} ^talk 00:06, 14 January 2021 (UTC)

• Oppose We should save banners for the truly important stuff like BLP, rather than spelling. (t · c) buidhe 18:35, 13 January 2021 (UTC)
• Oppose per Graeme Bartlett and CaptainEek. ~ HAL333 22:19, 13 January 2021 (UTC)
• Support: seems like a no-brainer. Banner blindness on a talk page is already a massive issue, and ENGVAR isn't relevant to reading the talk page, it's relevant to editing the page, so it should be where it's relevant. Sceptre (talk) 23:33, 14 January 2021 (UTC)
• Oppose: it's absolutely a reasonable proposal, but I'd prefer removal of these banners from the talk page instead. I just don't buy that language variant is important enough to warrant this kind of attention, and instead it will just cause reader blindness wherever it appears. I understand that it's very frustrating to be reverting the same good-faith spelling changes over and over again (I've lost count of the number of times I've had to revert "installment" back to "instalment" on the BritEng Black Mirror series of articles), but I've found that most unregistered editors will not see an editnotice, a wikicode template or a hidden comment in the middle of a word that keeps being changed (I don't know why the last doesn't work, but it doesn't), or possibly just willfully ignore them all. So I believe that this proposal, though it seems like the common sense logical position to move the template to, would just create blindness and have little-to-no effect on averting editing redundancies. — Bilorv (talk) 23:40, 14 January 2021 (UTC)

  @Bilorv: Your point about having to correct the same word over and over gives me a thought: what if we had an edit filter so that e.g. anyone trying to introduce "installment" to an article tagged with British English would get a big caution notice when they try to publish? {{u|Sdkb}} ^talk 01:58, 15 January 2021 (UTC)

  I think it is unreasonable for new/IP users to have no way of knowing this info before editing. Yes, they most likely won't read the notice, but "there's a notice that you ignored" is much better than "there's a policy hidden in our arcane (to new users) WP namespace that you don't even know about". And given that the varieties of English are largely identical, it's sometimes difficult to tell what variant the article is in; the notice is a nice reminder. - Novov T C 07:57, 15 January 2021 (UTC)

  To Sdkb, that's possibly something I could support, but I really don't like edit filters targeted at newbies because it's one more barrier to entry. If there was a way to say "literally the only changes in this edit are a bad spelling changes" then that would be ideal. I know that's asking a lot. To Mir Novov, many good faith edits I see by new/IP users that I have to revert are something I couldn't reasonably expect them to understand. There's been a discussion on the talk page? The lead doesn't mention this because of due weight? This source is unreliable even though it's a newspaper one million people read per day? It's wrong to call a section "Controversy" even though you've seen 1000 other articles with that bad heading? If anything it seems to me that "this article uses Australian English because it's about an Australian show" is so much easier to explain than most common mistakes made. — Bilorv (talk) 09:37, 15 January 2021 (UTC)

  Bilorv, in my idealized 2030 version of Wikipedia, the way that filter would work is that someone would go in and try to make a bad switch to another variant within an otherwise fine edit, and when they click publish, a notice would pop up saying "Hey, you switched 'instalment' to 'installment', which appears to go against the British English used for this article. Would you like to (a) publish, but keep British English? [works in one click], or (b) publish anyways?"

  Even with that, though, I agree with Novov that, for pages where switches are common (which is the group we're discussing here), it's better not to make someone do all the work before giving them the alert. And it's not just newcomers—I didn't know that "installment" was one of the words that differed until you mentioned it above, so I could easily see myself making that error. Whereas if there's an editnotice that (again, thinking futuristically) automatically detects that "instalment" is used a lot on that page and therefore includes it in the examples, that'll let me know not to touch anything. {{u|Sdkb}} ^talk 13:05, 15 January 2021 (UTC)

• Support - This information is most useful for actually editing pages, not discussions. Logically, it should belong there, and such a relocation would be useful to the IP editors that have "corrected" spelling . Yes, some other info is on the talk page that should be read, but a lot of people don't read that, and wishful thinking won't make that fact go away. - Novov T C 07:57, 15 January 2021 (UTC)
• Oppose. Instruction creep, overly intrusive and will just lead to more edit notice blindness. Neutrality^talk 19:43, 15 January 2021 (UTC)
• Oppose per Neutrality. Personally, I dislike edit notices and more edit notices that would intrude on the editing interface is something that I would not want. Perhaps something similar to the Template:Use mdy dates template would be better. A whole host of edit notices on the national varities of English (sometimes where editnotices are already in place) would be worse than talk page banner blindness for content creators hoow would have to scroll past the edit notice every time they edit. Plus, the national varities of English really isn't that important and as such, this is why we should keep them on talk pages. P,TO 19104 (talk) (contribs) 23:08, 15 January 2021 (UTC)
• Oppose per Graeme Bartlett and CaptainEek. Cavalryman (talk) 03:14, 16 January 2021 (UTC).
• Oppose. Varieties of English are not important enough to warrant placement as an editnotice. Just try and notice what variety the article is using and emulate that; if you get it wrong, someone will help you fix it. In my view, the talk page banner exists only to attempt to avert edit wars over this stuff, with one side being able to point to the banner. The rest of the time it's not useful, whether on the talk page or as an editnotice. KevinL (aka L235 · t · c) 20:07, 18 January 2021 (UTC)
  • Further to this, there are some truly important editnotices (e.g. DS notices that create blockable offenses), and the more editnotices we add the more banner blindness we get. Talk page notices are already ignored; let's not consign editnotices to the same fate. KevinL (aka L235 · t · c) 20:09, 18 January 2021 (UTC)

  Whilst I see your argument, to be fair, the editnotice format already exists right now and is placed arbitrarily; admins/TE/PMRs will place it themselves or on request for other editors, also in line with the current documentation for these templates. The pages that only have a talk notice are usually arbitrary. ProcrastinatingReader (talk) 20:12, 18 January 2021 (UTC)

  • There's an editnotice already? That's awful. Let's delete it. KevinL (aka L235 · t · c) 20:22, 18 January 2021 (UTC)
    • Yeah, see doc of {{British English}}. It’s done using a parameter, but the idea is (I think) to use both. To clarify, my point isn’t that we should enshrine a pattern that may not make sense, but if we don’t want language editnotices we should remove them entirely rather than the arbitrary system currently.
      Personally I think either trim it down to literally a bullet point not a hefty notice, or create a {{article standards}} for talk pages. Each option has a different purposes of course: the former is intended to alert editors writing to tailor their language, the latter to help copyeditors ‘fix’ errors. Personally, I don’t know other varieties of English so I make my ‘errors’ and let someone else copyedit their fixes if they care, so possibly the latter is smarter. ProcrastinatingReader (talk) 20:26, 18 January 2021 (UTC)
      • The current editnotice should be terminated with prejudice. KevinL (aka L235 · t · c) 20:52, 18 January 2021 (UTC)
        • I think I have used that edit notice. But the idea is to only insert the notice if it really needs to be noticed, ie there is a chronic problem with numerous edits on the page. So in general it should not be added in my opinion. Graeme Bartlett (talk) 23:59, 18 January 2021 (UTC)

• Oppose - editnotices should be reserved for important article- and page-specific instructions, and should be used as minimally as we can manage. Opening editnotices to general advisories about article styles will lead to clutter and significantly diminish the usefulness of editnotices for those article- and page-specific notices. See also this discussion from a couple years back about this exact thing which led to consensus that style notices shouldn't be used this way without evidence of disruption. In the same discussion, several users smarter than me also suggested that doing this would pollute the database with a few hundred thousand new pages and increase the loading time of articles, for no particularly important reason. Ivanvector's squirrel (^trees/_nuts) 01:04, 20 January 2021 (UTC)

  Furthermore, we still haven't solved the issue that editnotices aren't visible to mobile editors, so they're not well suited to editorial advisories anyway. Ivanvector's squirrel (^trees/_nuts) 01:06, 20 January 2021 (UTC)

• Oppose as this proposal appears to ignore the fact that editnotices don’t show on mobile. SK2242 (talk) 06:41, 20 January 2021 (UTC)

  Neither do talk notices. Or, well, they're well hidden. ProcrastinatingReader (talk) 23:00, 21 January 2021 (UTC)

• Weak oppose; how many times have you read on AN or ANI a reminder along the lines of, "Dear OP, did you miss the violently orange notice when you posted here?" If they miss that, do we really think that an editnotice will prevent page watchers from having to revert to the correct EngVar? Personally, i think that editnotices should be kept for the very most important things ~ things that if you cross or miss might end up with your privileges restricted. happy days, Lindsay^Hello 14:10, 22 January 2021 (UTC)
• Support but only if there's an option for logged-in editors to turn off the notifications. Lugnuts ^{Fire Walk with Me} 17:23, 22 January 2021 (UTC)
• Oppose having more edit notices. In the visual editor and the 2017 wikitext editor, you have to click to get past the edit notices every single time you open that page to edit. Also, just as Ivanvector's squirrel says, you stop reading them when they're common. WT:MED has an edit notice that I've clicked past most days for the last several years, and I no longer know what it says. When we need to have notes about the language variant to use, please make them all "invisible" templates that carry the necessary information in the title, such as {{Use British English}}. WhatamIdoing (talk) 19:58, 22 January 2021 (UTC)
• Support. As many others have said, very few editors will actually notice talk page banners, especially IPs and newbies. And failure to heed ENGVAR instructions has often led to disruptive, pointless edit wars. Of course, we need to be mindful of not accumulating so many edit notices that people will stop paying attention, but that's a separate discussion of how to condense the edit notices. ChromaNebula (talk) 23:20, 26 January 2021 (UTC)
• Support: Even if people ignore the notice, it won't be worse than it is now. This is a great way to stop people from changing between English varieties unnecessarily. And, also, since more people are seeing the fact that "you can tag articles for types of English?", there'll be more people tagging, which, in turn, leads to more standardisation and organization. Opal|zukor^(discuss) 22:10, 29 January 2021 (UTC)
• Support, ideally with the notice stripped down to its bare essentials. Perhaps just This article is written in American English, and this should not be changed without consensus. Learn more. I see using editnotices as an improvement in multiple ways. Talk pages become less cluttered. Newbies who don't know about our approach to English varieties are more likely to learn about it and avoid making unwanted changes. And more experienced users editing articles without strong national ties can quickly see how they should write without having to either check the talk page or scan the article for clues as to the preferred variety. the wub "?!" 23:35, 30 January 2021 (UTC)
• Support - this seems like a good idea. Rollo August (talk) 17:32, 3 February 2021 (UTC)
• Oppose per Levivich and L235. AVSmalnad77 ^talk 04:04, 5 February 2021 (UTC)
• Oppose. Edit notices make it harder to edit. They should be reserved for important matters. Espresso Addict (talk) 07:54, 11 February 2021 (UTC)
• Strongly oppose.: Instead, eliminate the editnotice versions. We do not need to browbeat editors, especially new ones, about style trivia every single time they edit the page. If someone gets it wrong, some gnome will fix it later, as with all other style quibbles. MoS is a guideline, not a policy, for a reason. No editor is required to follow it when adding new content; they're not permitted to disruptively and stubbornly change material to be noncompliant after they've been asked to stop doing it. Trying to effectively make following an MoS line-item mandatory to edit the page at all is an end-run around WP:EDITING policy, is WP:BITEy, is WP:CREEP of the highest order, and is also an end-run around nearly two decades of consensus that no style matters aside from some key points about article titling rise to policy level. While we're at it, also just get rid of the talk page banners for this. The "silent" templates like {{Use British English}} at the top of the actual article is entirely sufficient.  — SMcCandlish ☏ ¢ 😼  18:01, 13 February 2021 (UTC)
• Weak support, this is one option to reduce current clutter. These templates already exist as edit-notices, so whether or not they should be needs to be a different discussion. Either way, as a talkpage tag or edit notice, they should be sharply reduced in prominence/space in line with similar comments above, first of all by removing flags/other images per the spirit of WP:FLAGCRUFT. Frankly these notices could be reduced to two words (eg. "British English", "American English") left somewhere consistent on the talkpage/edit notice. CMD (talk) 17:46, 14 February 2021 (UTC)
• Oppose per SMcCandlish. Editnotices should be reserved for important instrctions/information only. --NSH001 (talk) 10:04, 20 February 2021 (UTC)
• Oppose clutters the editnotice space with hundreds of thousands of pointless editnotices, while making sure editnotices need to be even flashier for users to read them. Ideally, we'd have a standardized location in the editor displaying the English variety - and editnotices are a hacky - and bad - way to somewhat emulate this. Elliot321 (talk | contribs) 01:45, 28 February 2021 (UTC)

  Elliot321, a standardized location in the editor is an interesting thought. Where would you envision it going? Are there any phab tickets seeing if the WMF could look into adding something? {{u|Sdkb}} ^talk 07:08, 3 March 2021 (UTC)

  Sdkb sure, here's a mockup I made for source editor (what I use): File:English Variety mockup - source.png. I'm unsure of if there are any phab tickets. Elliot321 (talk | contribs) 07:21, 3 March 2021 (UTC)

  Elliot321, that looks pretty good to me! Hovering over the word "British" could perhaps provide a tooltip with word examples (ideally tailored to the actual words used on the page). If you go forward and turn the mockup into a more formal proposal, I'd support. My read of this discussion is that there's definitely desire to make the language tag less prominent but just disagreement about how to do it, so I think your solution might have strong support if it can be implemented. {{u|Sdkb}} ^talk 07:39, 3 March 2021 (UTC)

  Sdkb yeah, that would be my idea.

  Now, the question is how to set it? Though I suppose the {{Use blah English}} templates do that just fine, and that could probably be detected in the editor. Elliot321 (talk | contribs) 07:43, 3 March 2021 (UTC)

• Support Most users don't bother to look at the talk page unless they want to post a discussion there. A new user might not even know that talk pages are there! This is a very useful proposal. 🐔 Chicdat  ^{Bawk to me!} 11:22, 5 March 2021 (UTC)
• Opppose. I support aggressively cutting talk page clutter, but this notice to an even-more-visible edit notice does not accurately reflect its importance (it's a MoS issue, and I concur with SMcCandlish that we should not bludgeon editors about it, like an edit notice would do). — Goszei (talk) 16:37, 8 March 2021 (UTC)
• I have long thought that the Variant notice should go on the Article page, and not the Talk Page. Just a simple one line hat note saying something like “This article uses UK spelling and grammar” at the top of the page would be enough. Blueboar (talk) 16:50, 8 March 2021 (UTC)
• Oppose per above.  Spy-cicle💥  Talk? 18:52, 10 March 2021 (UTC)

Discussion (English varieties)

• If this is adopted, how would it be implemented relative to existing editnotices that already incorporate English variety? That is, see Wikipedia:Featured articles/Editnotice templates for a list of all medical featured article editnotices, that already include English variety, incorporating a custom list of words from the article. (Not a techie, please spell this out in Dummy 101 detail.) SandyGeorgia (Talk) 16:46, 10 January 2021 (UTC)
  • In the cases where it's already in the edit notice, I think we'd just leave it there and only remove it from the talk page. --Paul ❬talk❭ 17:07, 10 January 2021 (UTC)

    Yeah, for pages like Template:Editnotices/Page/Rotavirus, it already includes {{British English|form=editnotice}}, so the bot would just remove the talk page notice and not add a duplicate. For the rare page that has a custom language editnotice, like Template:Editnotices/Page/COVID-19 pandemic, that'd be a little trickier, but still doable; the bot could just skipping adding anything for editnotices that link to a page in Category:English dialects. {{u|Sdkb}} ^talk 19:55, 10 January 2021 (UTC)

• Shifting banners from talk to the edit notice helps talk but makes it even more unlikely that people will read the edit notice. I would want to see a draft of exactly how this proposal would be implemented (create a million new edit notices? create one central edit notice with magic code to show the language variety?), and exactly how it would appear. Try editing Donald Trump to see what an edit notice can look like. Johnuniq (talk) 22:59, 10 January 2021 (UTC)
  • You're emphasis of how big of a change this will be is certainly valid, though I don't know if I agree that moving to an edit notice makes it even more unlikely that people will read the edit notice – even just the flag of the UK or US in the edit notice would do more than right now. The only alternative I can see to the current situation or the proposed solution above is to completely remove the english variety, which is a more or less impossible scenario. Aza24 (talk) 00:10, 11 January 2021 (UTC)
  • We make the editnotice form smaller? ProcrastinatingReader (talk) 09:25, 11 January 2021 (UTC)
    • I'm not sure how feasible this is in a technical sense, but if an editnotice template is about the formatting (eg date order), language variant, etc, then could those be smaller and all placed together right above the editor? It'd make it less obtrusive, while still being easy to locate all the relevant little pieces of information re writing conventions. Those could alternatively be in an expandable bar, like some of the category lists at the end of articles are. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)

  @Johnuniq, I believe that this will involve creating tens of thousands of edit notices. WhatamIdoing (talk) 20:01, 22 January 2021 (UTC)

• Many old time editors, most newer editors, and virtually all IPs never make it a habit to look at the talk page before editing an article page. English version notices on the talk page are worthless. GenQuest ^"scribble" 23:30, 10 January 2021 (UTC)
  • Completely agreed, and this proposal should address that appropriately I believe. The current placement of English variety templates are virtually invisible to the intended audience. Aza24 (talk) 00:10, 11 January 2021 (UTC)
    • As a newer editor, I have never intentionally checked before editing so that's at least some anecdotal evidence for your point. However, I'm not sure if this is a function of the notice on the talk page, but on the visual editor on some articles there's a little prompt right under the title (eg Education in Australia). I'm a big fan of those little prompts. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)
• The need for an administrator to intervene will force an non-administrator-editor who notices a a change to the English variety is clearly warranted to spend two edit sessions on the page. The first session would be to place a protected edit request. The second would be to actually change the variety. Jc3s5h (talk) 01:02, 11 January 2021 (UTC)
  • Given how infrequently a page's variety of English should be changed this sounds like a benefit to this proposal - ensuring that it only happens when there is a good reason to do so. Thryduulf (talk) 11:12, 11 January 2021 (UTC)
    • I would agree with this. Requiring two edits isn't unreasonable for something that defines how the entire article is written. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)

• I expect that the opposers on the basis of "we shouldn't have them in the first place" will actually do something about that and propose that we remove them all together (were this proposal not to pass) . Otherwise, you're wasting everyone's time. Aza24 (talk) 06:08, 13 January 2021 (UTC)

  Opposing a change from the second-best solution (talk page banners) to the third-best solution (edit notices) is not a waste of time, even if one doesn't propose the best solution (no banners). Making a proposal that doesn't have a reasonable chance of success is a waste of time. Oftentimes, "second-best" is status quo because it's the compromise. Levivich ^harass/_hound 06:16, 13 January 2021 (UTC)

  You are mistaken if you believe this discussion cannot generate the consensus to remove these from talk pages without replacement. RFCs are not votes.

  Secondly, we are not wasting time regardless. We should prefer the best solution, however we get to it. It is a logical fallacy to argue that we also must do things consistent with our position, especially as this is a volunteer mission. (I have no problem being called a hypocrite if you like. :)

  Thirdly, this is maybe the least concerning thing on the wiki today. We don't need the polarism on your part. --Izno (talk) 22:09, 13 January 2021 (UTC)

  Izno, literally no where did I say anything like this discussion cannot generate the consensus to remove these from talk pages without replacement, and I certainly wasn't intentionally trying to generate "polarism"; the misrepresentations are not appreciated. I think I was pretty clear about what would be "wasting time" – a situation where people who oppose on the basis of "we shouldn't have them in the first place", the proposal fails, yet these opposers don't start some proposal to remove English variety banners. Because in a situation where a problem is brought up, consequently unresolved by the introduction of a bigger problem and neither end up being addressed is a waste of time. Aza24 (talk) 22:39, 13 January 2021 (UTC)

• Obviously, the best solution would be a bot that automatically (and quietly) corrected spelling and usage to whatever variant was designated (assuming that a variant has been designated)... with an edit summary explaining what was done and why. Then editors could simply write, and not worry about whether they were writing in the designated variant. Blueboar (talk) 14:00, 15 January 2021 (UTC)

  @Blueboar: editors that are writing any new content shouldn't be overly concerned with this already - it is really about avoiding refactoring the existing text over and over again. — xaosflux ^Talk 11:45, 16 January 2021 (UTC)

  @Xaosflux: Is there evidence that such refactoring has been a significant problem thus far? Because if not then I think that Blueboar's suggestion is correct. Nsk92 (talk) 00:31, 4 April 2021 (UTC)

• At the very least, the banners should be reduced and have the flags or other images removed. English varieties don't always neatly follow political boundaries, and at any rate we have WP:FLAGCRUFT for such situations in articles and yet flags are spammed across talk pages. Removing them also helps reduce space and prominence for a template that is probably mostly seen when explicitly being looked for. CMD (talk) 16:47, 17 January 2021 (UTC)

  I agree that the banners should be trimmed down, but I think the flags are actually quite helpful as a visual shorthand, so they're an element I think we should keep. {{u|Sdkb}} ^talk 21:15, 14 February 2021 (UTC)

• My main concern here is that editnotices only can be edited by page movers, template editors and admins. I get that a bot can do the initial move but how will we go about additions of these in the future? I don't mind if the consequence is that these notices become rarer, but in that case it should be a deliberate choice and not just an oversight. I also don't think it's a good use of time to significantly increase the number of trivial WP:TPERs with changes to engvar notices. --Trialpears (talk) 21:46, 11 February 2021 (UTC)

  Trialpears, as I mentioned a bit in my !vote, I see this as an underlying problem—there are lots of situations in which anyone autoconfirmed ought to be able to edit a page's editnotice but can't (not because of any editorial consensus, but just because of something about the back-end technical structure of editnotices). That's a problem that we should solve (and if this goes through, it might nudge us toward doing so), but I don't think we should handicap ourselves here and reject this because of it. To do that would both obscure the level of need to resolve the issue and give ourselves more work down the road once it is resolved. {{u|Sdkb}} ^talk 00:12, 13 February 2021 (UTC)

  I feel like that would in general be a good idea, but I still see some reasons for the protection. Vandalism at editnotices would likely not be detected most of the time and even if it was detected most editors would probably not be familiar how to solve it. Putting misinformation in them could be significantly worse. I would definitely support enabling it for extended confirmed users though. With regards to implementation the restriction is governed by MediaWiki:Titleblacklist which can easily switch it to requiring autoconfirmed. It should also be possible to use a editfilter instead which could implement an extended confirmed restriction instead. --Trialpears (talk) 21:26, 16 February 2021 (UTC)

  Sdkb I don't see an issue with keeping editnotices to people who can override the blacklist - needing to edit editnotices is quite niche and they should, in most cases, be using templates which are not on the blacklist and thus can be edited.

  As long as edit requests are fulfilled quickly, this is fine. Perhaps more people should apply for page mover? Elliot321 (talk | contribs) 07:29, 3 March 2021 (UTC)

Pending-changes protection of Today's featured article

RFC: Citation Style 1 parameter naming convention

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Close in progress: See Wikipedia:Administrators' noticeboard#New close for "Citation Style 1 parameter naming convention" RfC. – Joe (talk) 11:02, 14 April 2021 (UTC) is in the process of closing this discussion. Please do not contribute further to it; the result should be posted shortly. More information: The user who added this notice will be listed in the page history; the page was last edited by Amorymeltzer at 10:11, 5 May 2020. It is intended to help reduce edit conflicts, and to avoid closers duplicating each other's work. It also helps avoid a late comment being added to the discussion but not being taken into account in the close. If this page has not been edited for a few hours, it is usually safe to remove this template. However, if the debate is long, complex, or acrimonious, please allow more time.

Should non-hyphenated parameters be fully removed from the CS1/2 family of templates? Primefac (talk) 02:14, 10 February 2021 (UTC)

Background (CS1)

In 2014 an RFC determined that all parameter names in Citation Style 1 templates should have an alias which is in lowercase that has separations with hyphens between English words, between (not within) acronyms, or between English words and acronyms. The documentation is to show this lowercase, hyphenated version as the one for "normal use". This meant, for example, that |access-date= would be shown as the preferred parameter while |accessdate= was shown as acceptable but discouraged from use. In the following years there have been various trends and discussions formally deprecating many of the non-hyphenated parameters, from a small handful (2019 example) to the current list which contains over 70 entries. Many of these are the non-hyphenated variants of the preferred/hyphenated versions, which are being removed to decrease the maintenance burden and increase the uniformity between templates (i.e. "ease of use"). Other changes have included having RefToolbar give the hyphenated params and setting AWB's genfixes to replace some parameters.

In October 2020, all non-hyphenated parameters were added to the "current list" linked above. In November 2020, a bot request was submitted ("Monkbot 18") to remove or replace these deprecated parameters so that they could be removed from the base module and simplify the template code further. While acknowledging that this task was largely cosmetic in nature, BAG and other venues (primarily templates for discussion) have historically sided with the idea of a "maintenance burden" as a valid reason for edits such as these; see for example Monkbot 17, which replaced (cosmetically) one parameter for a better-named value for ease of use.

The issue for Monkbot 18 arises from the number of edits it is/was required to make; a conservative estimate would put the number of edits it has made for this task over a two month period (Nov 2020-Jan 2021) at around 1 million edits; as discussed on the task's talk page, this has essentially removed all but five of the non-hyphenated parameters, but another 2-3 million edits taking up to four additional months will still be required to fully "clear out" these parameters. Additionally, those opposed to the bot also expressed concern that the relatively small-scale discussions to deprecate these parameters had not reached a wide enough audience to merit what they felt were sweeping changes.

Proposal (CS1)

There are three main options with regard to the CS1/2 family of templates, and by extension Monkbot 18's task.

• Option A: Non-hyphenated parameters should be deprecated and removed; the bot is free to continue its work.
• Option B ("status quo"): Non-hyphenated parameters are formally deprecated, but should not be immediately removed. Deprecation can be bundled into genfixes or performed along with other non-cosmetic changes, but (ignoring a possible Cosmetic Bot Day) should not be done on its own by a bot.
• Option C: Non-hyphenated parameters should not be deprecated; deprecation should not be continued and bot approval should be revoked. This will also mean that the deprecated parameter list will need to be updated to remove the non-hyphenated parameters.

Please note that this discussion is primarily about the CS1/2 template parameters and whether two full sets of parameters should be kept/maintained. It is not the place to re-litigate the various discussions about Monkbot 18's task; Option B is provided for those who feel the task should not proceed.

Survey (CS1)

• First choice A, second choice B. I'd be happy to see AWB's genfixes take on some of this burden, and I'd be happy to see this happen a little more slowly, but it should happen, even though it's occasionally inconvenient for me. Also, when any individual parameter reaches a sufficiently small state (e.g., potentially still thousands of uses, but not hundreds of thousands of articles), the template should be updated to disallow that particular parameter (not merely advise against it in the documentation), so that they won't keep creeping back in, because, hey, it still works, so why should I bother? WhatamIdoing (talk) 19:12, 10 February 2021 (UTC)

  @WhatamIdoing: AWB's genfixes already handles this through WP:AWB/RTP, so manual edits and other bots can help whittle down the list while making other (non-cosmetic) edits. GoingBatty (talk) 04:12, 11 February 2021 (UTC)

  GoingBatty, are you sure that |accessdate= will be replaced by |access-date= by editors using the current version of WP:AWB/RTP? I think it was removed. – Jonesey95 (talk) 04:33, 11 February 2021 (UTC)

  @Jonesey95: You're right! While the functionality exists (and other parameters are still replaced), editors have removed some hyphenation replacement rules. GoingBatty (talk) 04:59, 11 February 2021 (UTC)

• Option A. I support completing the nearly finished move away from unhyphenated multi-word parameters. See below for more details about this process, which is being questioned now by a very few editors after seven years of work, and when it is more than 90% complete. With any other template, it would have been the work of a few days to standardize on one style of parameter name and convert all of the transclusions. The only reason that the process for CS1/CS2 templates is different is that there are millions of transclusions instead of hundreds. – Jonesey95 (talk) 04:33, 11 February 2021 (UTC)
• Option C. This is pointless make work; see extended comment in discussion section. Espresso Addict (talk) 07:08, 11 February 2021 (UTC)
• Option C If it was only confined to a few thousand pages, it wouldn't be a big deal. But when it's upwards of 3 million pages, maybe it should be the other way round - IE no hyphen. Lots of pointless bot cloggage in going through millions of pages for a trivial change. Lugnuts ^{Fire Walk with Me} 08:20, 11 February 2021 (UTC)
• B if not C As per comments above; many editors are clearly quite happy with the unhyphenated forms, so why not allow both? Changing is pointless. Lots of other templates allow aliases as parameter names. I fail to see the problem. But we are where we are, so I favour B rather than C. Peter coxhead (talk) 09:04, 11 February 2021 (UTC)
• Option A (second choice B), per Jonesey95. Let's just get everything simplified, as it should be. Get on and finish the job. --NSH001 (talk) 10:18, 11 February 2021 (UTC)

  Update Add a qualification: I still very much hope that the bot will be allowed to resume, but subject to this condition: only if Monkbot 18 drops its removal of entirely blank lines within citation templates. For the reasoning behind this, see my conversation with Floydian in the discussion section (this is quite an easy change to make to the bot). While I'm here, I'll add a second qualification, also arising from the discussion: the list of articles on which the bot runs should be filtered to remove articles that have already been visited by the bot. This is in order to reduce the alleged problem of "bot spam" objected to by some editors (who says I don't listen to objections?). --NSH001 (talk) 06:52, 12 March 2021 (UTC)

• Option C. It is a totally pointless exercise. The unhyphenated ones are better in my eyes as they do not wrap in the edit window and can be underlined as a typo so are clearly visible in the edit window. Keith D (talk) 13:01, 11 February 2021 (UTC)
• C (first choice) or B (second choice). I've read many of the discussions about this issue and I've never yet seen anything the convinces me that deprecation actually benefits the encyclopaedia in any way. Even if we assume for the same of argument that it somehow does, the real and evident disruption caused by the bot so far and the extent of the changes the bot operator notes will be required to complete the task, very clearly and very significantly outweigh that benefit. Thryduulf (talk) 15:20, 11 February 2021 (UTC)
• Option A this change is a bit painful, but better for editing in the long-run. It's better to make this change than to not make it. The best time would've been fifteen years ago - but the second-best is now. Allow the bot to continue its operation, get rid of all the parameters, and once all are removed, start generating cite errors. Elliot321 (talk | contribs) 17:09, 11 February 2021 (UTC)
• Option A. Unfortunately, the visual editor exists... but isn't useful for large editing projects and thus many people still use wikitext editing - condensing to one form (specifically the hyphenated one as it is easier to read for editors) will help ensure consistency between articles at least in the CS1 templates. Obviously this won't make every article easier to edit as there are articles with non CS1 style citations, but it'll help the millions that do use CS1 look the same to editors instead of having a hodge-podge of hyphenated names. I further agree with the bot continuing to run now, and then running maybe once per week or so after this initial run to fix any CS1 non-hyphenated parameter names. -bɜ:ʳkənhɪmez (User/say hi!) 17:13, 11 February 2021 (UTC)
• Option C. The point of templates and bots is that they should work to make editors' lives easier, not that editors should change the way they do things to make template and bot creators' lives easier. This bot has it completely topsy-turvy, and if the bot-approvals group has approved this then that is a problem with that group, not with a few unhyphenated parameters. I can't help feeling that that group is looking at the interests of a few bot operators rather than of the many more editors and still many more readers. There's no great complexity in having a few synonyms for template parameters, and there's no problem at all with exporting data - if the synonymic parameters point to the same place in code then they can be exported in the same format with no extra effort. I can't believe that forty years after I went into IT we still expect users to be slaves to the systems that are supposed to help them. Phil Bridger (talk) 18:21, 11 February 2021 (UTC)

  The point of templates and bots is that they should work to make editors' lives easier. Exactly so. That's what this bot is for. It makes the parameter names easier to read (taking them as a whole, not just access-date on its own), reduces the size of the template documentation, makes the parameter names all consistent. All these combine to make learning how to use the cite templates easier. It also makes maintaining the templates easier. a win-win situation. The only reason we're having this discussion is that Mediawiki's watchlist software is so bad at handling bot edits. Otherwise it would be a no-brainer. Some people here seem to be under the mistaken apprehension that this is just to advance the interests of "a few bot operators". Well, I'm quite sure Trappist (the operator of this bot) could do without the stress of planning, writing and running this bot. He does a bloody fantastic job, and deserves a huge amount of credit and appreciation for his work. I can't believe that forty years after I went into IT we still expect users to be slaves to the systems that are supposed to help them. The whole reason for this bot is to make users' life easier. FWIW, I also have experience of IT work more than 40 years ago (seconded for 2 years to work on a (very successful) project - mathematical programming on big data for a life insurance company) and frequently had to liaise with IT people since then. I'm well aware of the problems that can arise when you just allow systems to get more and more complex, so I appreciate Trappist's (and many other people's) efforts to simplify matters. --NSH001 (talk) 23:37, 11 February 2021 (UTC)

  Clarifying: Re-reading this again this morning, it might appear to readers who don't read carefully that I'm agreeing with Phil Bridger. Nothing could be further from the truth, I still support Option A. Option C makes no sense, for all the reasons set out by SMcCandlish. --NSH001 (talk) 08:35, 12 February 2021 (UTC)

  And Phil Bridger's hyperbole stance is fallacious. Option B imposes nothing on anyone. "I don't like option A" does not equate to "only option C can work". Option B is the status quo, and it has broken nothing. I'm rather shocked at how stark obvious this is, yet at least 10 editors don't seem to have noticed. I know that we have a lot of populism running around in the world – a lot of "I would feel very strongly about this, if it were true, and it feels good to pretend its true, so I'm going to pretend it's true" behavior. But that stuff needs to be left at the door.  — SMcCandlish ☏ ¢ 😼  04:21, 12 February 2021 (UTC)

  No, my stance is not hyperbole or due to populism. The reason I reject option B is the word "immediately". It still leaves current consensus that unhyphenated versions of parameters will be removed, just not immediately, and it is that consensus that should change, however many years it has been stable for. I am happy with simplifying the documentation, but not with removal of the option. Phil Bridger (talk) 09:19, 12 February 2021 (UTC)

  As noted above: Deprecation is not synonymous with disabling. You're confusing replacement of the parameters as written in a template transcluded in a page, with removal of the runtogether parameter variant's ability to function in the template. Only option A would do the latter. We have many, many templates that support variant-spelling parameters but do not "advertise" them in the documentation, and it breaks nothing whatsoever to bot-replace them with the canonical version, just as the same bot will replaces calls to a redirect name for the template with the actual page name of the template. I.e., you're having a strong negative reaction to an argument that option B is not actually making.  — SMcCandlish ☏ ¢ 😼  17:50, 13 February 2021 (UTC)

  Option B very clearly says "but should not be immediately removed". Either the word "immediately" has some meaning, and this option would lead to removal, but just not immediately, or it has no meaning and has no business being there. Phil Bridger (talk) 18:10, 13 February 2021 (UTC)

  SMcCandlish, this was explained in the previous discussion at CS1: ""Deprecation", by the definition used in the context of CS1/CS2, means that if the parameter is used, a red maintenance message will be shown and it will appear in a tracking category. It is a phase before removal of support for a parameter (in which case only an "unsupported parameter" message and optionally a hint on the new parameter will be shown). It is possible to stay in this state for extended periods of time, but the idea is that eventually the functionality will go". So the intention is to error and then remove the functionality of these parameters, not simply not advertise them in the documentation. If you want to propose a variant of option C that removes the parameters from the documentation but still allows them to function, go ahead, but option B is not that. Nikkimaria (talk) 20:09, 13 February 2021 (UTC)

  What I want to propose is a variant of Option B that removes the parameters from the documentation before letting some bot go around changing the articles on my watchlist as if the parameters are somehow bad. If the params are really bad, and if there's a consensus to that effect, then Step One is to take them out of the documentation (either by dragging them away in the dark of night, silently, like ninjas, or by transparently mentioning them as being deprecated, so everybody knows what's going on). The first phase of real deprecation is telling people to stop using something. Then you can start throwing up red messages and it's not so damned rude or surprising. — JohnFromPinckney (talk) 21:40, 13 February 2021 (UTC)

  Sure, I would support that variant, too. Or a variant that kept mention of those versions of the parameters but deprecated them. Whatever gets us closer to having consistency in the actual deployed templates being used in citations.  — SMcCandlish ☏ ¢ 😼  04:15, 14 February 2021 (UTC)

  This stuff should be in a tracking category, if that's what bots and other tools are going to work with. If we don't like the error messages, then we can disable them. This is just template and module code, it's not etched forver into a mountain face like Mt. Rushmore.  — SMcCandlish ☏ ¢ 😼  04:15, 14 February 2021 (UTC)

• Option C I agree strongly with Phil Bridger here. In other words, I fail to see what exactly is accomplished by making millions of cosmetic edits and then deliberately breaking things that would otherwise have worked. * Pppery * it has begun... 20:21, 11 February 2021 (UTC)

  Option B breaks nothing. You, et al., are providing an argument against option A, not an actual argument for C, and just ignoring B. Also, a !vote for C is an !vote for overturning a status quo that has been stable for years, in favor of chaos, yet without an actual rationale to do so. The closer should take that into account, per WP:NOTAVOTE. In the event of a "no consensus" result we still end up with the status quo. Things like this are why I keep telling people they need to write RfCs better. "Anything that can be misinterpreted will be."  — SMcCandlish ☏ ¢ 😼  04:21, 12 February 2021 (UTC)

  SMcCandlish, option B supports disabling of the non-hyphenated parameters - that is a breaking change. The difference between A and B is speed, not outcome. Your !vote below suggests you want the non-hyphenated variants to remain supported, but of the options provided only option C accomplishes that. Nikkimaria (talk) 16:18, 13 February 2021 (UTC)

  Nope. See my response to same claim by Phil Bridger, above.  — SMcCandlish ☏ ¢ 😼  17:50, 13 February 2021 (UTC)

  Yep - see above. You can also look at what has happened with previously deprecated CS1 parameters such as |authorfirst= - they don't work. Nikkimaria (talk) 20:09, 13 February 2021 (UTC)

  Which is perfectly fine, given enough time that people stop actually using them. Thus remove them from the template documentation and replace them in deployed template translcusions. Eventually the "monkey see, monkey do" effect of being exposed to deprecated parameter variants goes away, through decreased and eventually zero exposure. I'm mean, come on, that's what the point of deprecation is. It seems to me that you [plural] are coming from a "give me C or give me death" perspective, artificially conflating A and B because you just will not tolerate the idea of any parameter name variants ever going away for any reason. If I'm wrong about that perception, then please explain.  — SMcCandlish ☏ ¢ 😼  04:18, 14 February 2021 (UTC)

• Option C per Phil Bridger. Ealdgyth (talk) 21:28, 11 February 2021 (UTC)
• Option C - Commenting here probably falls under my doctors' lists of "things HF shouldn't do while he has a concussion", but I don't want to miss this discussion. While I understand that maintaining the citation templates is not a particularly easy job, in the end, rigidness in the citation template is not desirable. The citation templates should be easy to use, and having a couple aliases for the most common parameters makes it easier to use. And a trout to the bot guild for approving a bot task that was designed to deprecate template parameters with no consensus for that deprecation. Hog Farm _Talk 22:15, 11 February 2021 (UTC)
• First choice A, second choice B. Wikipedia source text is becoming increasingly complex and difficult to manage making it less accessible, except for the type of experienced editors participating here. Anything we can do to reduce complexity is a win, fewer options the better when plainly redundant. -- GreenC 22:41, 11 February 2021 (UTC)
• Option C per Phil Bridger, personally I prefer non-hyphenated parameters, and I find deprecating them to be an absolutely pointless exercise that breaks things for absolutely no reason other than to satisfy the cosmetic preferences of a few editors. Devonian Wombat (talk) 00:14, 12 February 2021 (UTC)
• Option C. Largely per Hog Farm. Keeping extremely commonly used aliases is helpful for editors using these templates. Nikkimaria (talk) 01:17, 12 February 2021 (UTC)
• Support option C, neutral on option B, strongly oppose option A. My fingers are used to typing many of these parameter names without hyphens. Deprecating them and the accompanying gnomework of replacing them with the un-deprecated versions is already causing me significant hassle, both in trying to remember that really now they should be hyphenated, and in trying to pick out the important changes on my watchlist among all the pointless gnomery. Removing the unhyphenated forms altogether would be worse. —David Eppstein (talk) 01:41, 12 February 2021 (UTC)
• Option C. I'm with Phil Bridger and Hog Farm. I don't know if this is bike shedding or yak shaving, but it's just not productive and a bad look. Alternatives exist because it's simpler than remembering which of two common possibilities are acceptable, rather than forcing one or the other (as the other options do). Discussing efficiency because of a off-row character on the other hand (oh, so we're making this choice based on everyone using QWERTY?) is the kind of ignore-practical-facts reasoning that yield platypus-shaped end results. -- Mikeblas (talk) 01:52, 12 February 2021 (UTC)
• A is better in the long run, but B for now, and have the conversion covered by AWB genfixes and similar. Headbomb {t · c · p · b} 02:29, 12 February 2021 (UTC)

  Comment Unfortunately, in this case, leaving it to AWB genfixes alone would be neither effective nor desirable. Because there are likely to be so many of these parms on any given page, the genfixes are likely to swamp the main, intended change, causing understandable annoyance. Much better to leave it to this excellent bot, which is clear and open about what it is doing – no nasty surprises. That's why I prefer option A to option B, but either of these is vastly preferable to option C. --NSH001 (talk) 08:31, 7 March 2021 (UTC)

• Option C per Phil Bridger. SarahSV ^(talk) 02:51, 12 February 2021 (UTC)
• Option C. This "everything must be hyphenated" approach doesn't work well with the text editor. For some common parameters like |accessdate=, it is simply better being unhyphenated because the source text is quicker and easier for a human to parse because the parameter doesn't word wrap in the editor's textbox. Jason Quinn (talk) 03:09, 12 February 2021 (UTC)
• Option B. We should stop listing the nonhyphenated ones in the documentation at very least, so that between editorial shift and AWB/bot genfixes cleanup, we get more consistent over time. It's too soon for option A, if ever, because the templates serve us, we don't serve the templates. It's perfectly fine for templates to quietly support non-hyphenated variants so they don't just break if people try them. But we should not continue listing those variants in the docs. It's antithetical to the purpose of templating, for us to perpetuate inconsistency (without good reason, like an ENGVAR color vs. colour distinction). And it pointlessly makes the documentation longer and more complex for no gain at all; no one looking for how to specify the Archive.org URL needs to know anything but |archive-date=, and telling them |archivedate= also works is just stuffing pointless trivia into their head. Yes, do continue converting to hyphenated versions in genfixes and other automated edits (when doing something more substantive at the same time). Finally, option C is rather pointless. We've regularly been (gradually) deprecating various old parameter names, and it has worked just fine. Option B will not break anything, and will have (already is having) positive results.  — SMcCandlish ☏ ¢ 😼  04:21, 12 February 2021 (UTC)
• Option B Option C. These are all valid aliases, as there is zero confusion between say |access-date= and |accessdate=. The status quo works fine: hyphenated is preferred because it's easier to read, but unhyphenated is acceptable because there is no ambiguity and evidently plenty of people type it that way. Cosmetic changes should adhere to policy. – Finnusertop (talk ⋅ contribs) 05:53, 12 February 2021 (UTC) Changed from B to C as I am opposed to the implications of the "formally deprecated" part of these valid aliases. – Finnusertop (talk ⋅ contribs) 09:26, 12 February 2021 (UTC)
• Option C first choice (B second). Editors should be allowed to use either hyphenated or non-hyphenated versions. Consistency is not better than flexibility here: the only people reading the parameter are editors, so let the editors decide whether or not they want to use a hyphen in their template parameters. I share the general concern about the disconnect between code writers and content writers, and the frustration with some template and bot maintainers imposing decisions on everyone without consensus. Fait accompli editing across millions of edits or transclusions is kind of a big deal. Levivich ^harass/_hound 07:20, 12 February 2021 (UTC)
• I Like C: I especially echo Levivich, Thryduulf|, and Phil Bridger's comments regarding these perennial, periodic, new surprises where editing articles is concerned. That is disruptive and we should just stop it. C, therefore, will bring the sanity back. GenQuest ^"scribble" 07:42, 12 February 2021 (UTC)
• Option C. These are templates for use by editors, they have no impact on readers, and it's a complete waste of time making rules and regulations about them and then writing bots to enforce those pointless rules. Not to mention that when AWB goes through "fixing" all these in an article, it can drown out the genuine edits and make it harder for people to track what's going on. Get rid of this ridiculous rule, delete it from AWB, and then maybe we can get on with actually building an encyclopedia.  — Amakuru (talk) 09:13, 12 February 2021 (UTC)
• Option C (which is the status quo ante). I just don't see what problem people are trying to fix, so follow WP:NBDF. The hyphenated parameters are useful and improve wikitext legibility, I personally prefer them, but allowing both forms makes things easier for editors. Deprecating them appears pointless, and removing them entirely seems actively harmful. It's created millions of pointless busywork edits clogging up watchlists for no good reason. We don't have a problem with template aliases, so why the concern about parameter aliases? None has been convincingly articulated. Modest Genius talk 12:10, 12 February 2021 (UTC)
• Since I have been pinged, neutral all round. I'm have nostalgia for the status quo for some reasons already presented (muscle memory, line breaks), but I recognize that once we pass through the valley of the shadow and emerge into the bright uplands yonder of a cleaner implementation, we'll have forgotten the pain. Mind you, I'll probably be 90 years old and beyond caring. But I have some implementation concerns in the Discussion. David Brooks (talk) 16:54, 12 February 2021 (UTC)
• Option C - Standardization of this sort may be useful to researchers or developers, but not to regular users. Adding citations should be as easy as possible. To that end, I want to minimize the chances that the interface will not know what I'm trying to do, or that I'll get an error because I entered an underscore instead of a hyphen. The rest of the internet is trying to increase flexibility to make user experience easy and intuitive. We do that too in many ways. But here we seem to be doing the opposite: removing flexibility and requiring users to know how we've worded/arranged things.
  I don't care if there's a bot that goes in an standardizes them afterwards or if someone runs AWB behind me. Again, I get the appeal of standardization. We should just be doing everything we can to make the experience intuitive for regular users. — Rhododendrites ^talk \\ 23:04, 12 February 2021 (UTC)
  • Alternative: Option D - let the bot and/or AWB standardize, but never disable the parameters. Standardization is good; degrading usability is bad. — Rhododendrites ^talk \\ 23:12, 12 February 2021 (UTC)

    I would certainly support your option D if it was on the table, but cannot support anything that says that this functionality should be removed, as option B (despite the illiterate claims above that it doesn't) clearly mandates. Phil Bridger (talk) 18:10, 13 February 2021 (UTC)

• Option A with B as my second choice. Maintaining our complex citation templates is not an easy task, and if the people who are putting in the work want to do this to make their jobs easier, I'm in favor of it. Legoktm (talk) 23:48, 12 February 2021 (UTC)
• Option C with Option B as second choice: Modest Genius makes an excellent comment, as do several others. The community needs to stop wasting its time on this citation formatting nonsense and do the hard labor of introducing citations in articles instead, the place we actually have a front-facing desperate crisis which damages our reputation. I use |accessdate= and I have no intention to stop. I remember very clearly the process I went through of learning citation templates in 2014—they were confusing at first but I never had a single confusion in parsing "accessdate" as the two word phrase "access date", very clearly meaning the date you last accessed a reference. I can see that in theory this would be marginally better for new users, and I can see that in practice some people who don't like the look of "accessdate" are escalating it ("my opinion" becomes "the correct view" becomes "a moral imperative to enforce"), but this just doesn't outweigh the actual genuine pain it will cause editors like me to retrain a years-long developed muscle memory; almost every mainspace edit I make for months will have a disrupted flow (interrupts my thought process, wastes my time re-typing) if this is to change.
  As for the bot that has been wasting several minutes of my time per day, I strongly opposed it in the first place and have had more than enough of it. (No, I can't ignore it, because if I turn bot edits off I will miss acts of vandalism, unconstructive changes or cleanup tagging that are hidden by a subsequent bot edit.) BRFAs need wider advertisement when their scope is so enormous and their violation of WP:COSMETICBOT so overt. I don't accept that option B reflects past consensus in practice in that I can't remember anyone ever approaching me about my use of |accessdate= or changing it to |access-date= manually. Past local consensus among technical groups who don't work in article space, sure. But enwiki community consensus? No. — Bilorv (talk) 01:07, 13 February 2021 (UTC)
  • @Bilorv: if I turn bot edits off I will miss acts of vandalism, unconstructive changes or cleanup tagging that are hidden by a subsequent bot edit -- this always takes me aback. Just curious, but why not enable the "Expand watchlist to show all changes, not just the most recent" + "Group changes by page in recent changes and watchlist" settings? I see no bot edits, and they don't cover anything up. — Rhododendrites ^talk \\ 02:50, 13 February 2021 (UTC)
    • @Rhododendrites: appreciate the suggestion! It's never occurred to me that combining those would produce that functionality (there are so many complex combinations of Watchlist filters and Preferences options), but I've enabled those two and kept "Latest revision" on and enabled "Human (not bot)" as the Preference option "Hide bot edits from the watchlist" didn't seem to do that and now I think (small sample size in my watchlist atm) I see the latest change only, including if it's a bot, but only if at least one non-bot edit has been made (which is exactly desirable). — Bilorv (talk) 11:34, 13 February 2021 (UTC)
• Option A with B as my second choice. Maintaining the complex citation templates is not an easy task. AManWithNoPlan (talk) 02:52, 13 February 2021 (UTC)
• Option A on the basis that standardization is good. I don't actually care whether the hyphens are there or not, but it's better one way or the other rather than having a mix. In general I'd rather see us migrate away from using wikitext for reference information, though, it's like doing your finances in a text document. Thanks. Mike Peel (talk) 18:26, 13 February 2021 (UTC)
• Option A I have always preferred the hyphenated form personally because it allowed the spell checker to verify that there was no typo, whereas the unhyphenated form is always flagged as a typo, although the preview now informs me of errors. I disagree with the contention that humans can parse |accessdate= more quickly than |access-date=; spaces were invented for this reason. I also know the overhead that permitting multiple parameters that mean the same thing in templates entails. I'm aware that this has been cluttering my watchlist with Monkbot edits, but my !vote is to continue. Hawkeye7 (discuss) 22:12, 13 February 2021 (UTC)

  Note that this is mostly an WP:ILIKEIT rationale and dismisses the views of those who indicate that they can parse "accessdate" without issue as wrong without any evidence. It also dismisses the very real disruption caused to others as necessary to reduce overheads, whereas this overhead, even if it is a significant as some claim (for which no convincing evidence has ever been presented) it's still trivial compared to the disruption caused by Monkbot's edits and by the unnecessary disruption to editors using the templates. Thryduulf (talk) 15:29, 14 February 2021 (UTC)

• B or C. I've no strong preference between accessdate or access-date, both seem useable, if one is formally preferred then fine. However, the massive ongoing bot spam for something that has literally no effect on readers, and barely any on editors, is unwarranted. In addition to being everywhere on the watchlist, Monkbot makes it much harder to disentangle various series of diffs in the edit history for little benefit. A user making an edit inserting "accessdate" isn't an egregious issue that should cause a bot to come running, and such a bot action then obscures the edit in question from watchlists. CMD (talk) 18:18, 14 February 2021 (UTC)
• Option C. Removing a common way to type parameters in templates reduces ease of use for the end users. Having a bot going around and "fixing" these has a negative impact on the readability of page history and watchlists . No one in this conversation has demonstrated that the maintenance burden on the template is so significant that it would justify all of these downsides. It also seems that the maintenance burden is not something that would be difficult to track like accidental blue links to primary topic articles when non-primary topic articles were intended, since the template code are on the template pages.---- Patar knight - ^chat/_{contributions} 18:53, 14 February 2021 (UTC)
• Option C. The previous discussions linked above (a six-year-old RFC with seven people participating in it, which specifically promised that nothing would be depreciated, followed by a handwavy argument about maintenance burden), are not remotely sufficient to justify such a sweeping change. Yes, maintenance burden is a pain, but it affects a relatively small handful of bot authors; removing the most widely-used version of a template parameter affects a huge swath of editors, who need to be given deference here on account of being a larger group. And obviously there is not a standing consensus that maintenance burden justifies such changes (at least not one on a scale necessary to justify this), or this discussion wouldn't be so clearly split. Therefore, the unhyphenated version should never have been depreciated, which makes the bot's edits pointless clutter at best and an attempt to push through a controversial change without sufficient consensus via fiat accompli at worst. Furthermore, if maintenance burden is the only concern, obviously the solution is to reverse the 2016 RFC (which, again, had only seven people participating it and agreed merely to create the hyphenated versions as alternatives) and remove the hyphenated version, which currently sees little use and would therefore be far easier and less disruptive to discard. --Aquillion (talk) 22:12, 15 February 2021 (UTC)
• Option B-ish. I think it's reasonable to have the hyphenated forms be the canonical version of the parameter, but I see no reason to make mass-edits to change from one form to another or to change the usual rules about cosmetic bots here. I see no harm in Option C, but implementing Option A will trade current problems for new ones. --AntiCompositeNumber (talk) 02:15, 16 February 2021 (UTC)
• Strong Support A: standardization for template parameters is important & useful.

Mild Support B: the # of |accessdate= per page is too damn high (much of the time), so much so as to interfere with checking regular WP:GenFixes (i.e. many single-screen diffs become many-screen diffs) — I would Strong Support B IIF Monkbot was allowed to continue & hyphenate at least this parameter.

Strong Oppose C: antithesis of A.

~ Tom.Reding (talk ⋅dgaf)  19:23, 16 February 2021 (UTC)

• To whom is standardization for template parameters important & useful? Phil Bridger (talk) 20:39, 16 February 2021 (UTC)
• How and why is standardisation more important and useful than editors being able to improve the encyclopaedia without needing to know the exact format of parameter names and deal with watchlists and page histories full of cosmetic edits? Thryduulf (talk) 20:45, 16 February 2021 (UTC)

• Are y'all suggesting we bring back all deprecated parameters, and adding more so that every user may choose to use the parameter names that are most comfortable/understandable/intuitive to them? I'm ok with soft-deprecation - allowing both but discouraging/converting one, in bulk once via bot, then gradually/passively via WP:GenFixes & other tools, but that is not one of the options.
  Re: "watchlists": may be configured to ignore bots until it's done.
  Re: "histories full of cosmetic edits": the bot only requires 1 edit; hardly "full of"; regardless, there is community consensus for WP:CBD.   ~ Tom.Reding (talk ⋅dgaf)  12:16, 17 February 2021 (UTC)

  Yes, I am suggesting that all the two-word parameters should accept hyphenated and non-hyphenated varieties. It's fine for one to be preferred over the other in documentation but both should work and continue to work as this is by far the least disruptive to editors and allows them to spend their time producing/maintaining content rather than worrying about finicky syntax. I don't have massively strong objections to general fixes substituting one for the other when making non-cosmetic changes to the page, but I wouldn't actively encourage it as it will clutter diffs for no benefit. I strongly oppose bulk bot runs and making one option non-functional in the future. Thryduulf (talk) 15:29, 17 February 2021 (UTC)

  Re "Are y'all suggesting we bring back all deprecated parameters" - yep, that's spot on. They should never have been deprecated in the first place. This is a template, which sits in the background, and exists for editor convenience, nothing more. Deprecating parameters reduces that convenience. And it's well-established that bots and editors shouldn't be running through making cosmetic changes to wikitext that do nothing to alter the page, so those need to stop as well.  — Amakuru (talk) 12:48, 18 February 2021 (UTC)

• Option C, I guess, as I've not been persuaded as to the marginal utility of the hyphenated versions. Without that clarity, we shouldn't be doing these kinds of changes. (And if we had consensus, then B, but with documentation changes as the first step.) — JohnFromPinckney (talk) 01:48, 17 February 2021 (UTC)
• Option C If it works don't fix it. Andrew🐉(talk) 13:01, 17 February 2021 (UTC)
• Option A, strongly oppose option C: anybody working regularly on templates or modules will appreciate the value of settling on a single style for issues like parameter names. I don't care what the agreed style is, as long as it's consistent, and the argument about whether it should be hyphenated, underscored, camel-case or run-on has been settled with hyphenated as the preferred style. It is then nonsensical to fail to implement that style, and I'd prefer it was done as soon as possible. This whole debate is reminiscent of the date-linking wars where strong objections were made to unlinking dates, yet within a few months of a binding decision being reached to delink dates, everyone had moved on, and nobody today would even consider linking dates. Once we have standardised on hyphenated parameters, future editors will look back and think how lame and time-wasting this sort of debate is. --RexxS (talk) 19:46, 19 February 2021 (UTC)
• A or B but not C per Scott, Hawkeye, and RexxS. Usingahyphenismoreuserfriendly, andwhilethereissomeupfrontworkonourparttomaketheswitch, itisbetterinthelongruntohavesomedelimiterbetweenwordsinsteadofrunningthemtogether. Just like we stopped linking dates and no longer SmashWordsTogether, this is worth the temporary inconvenience. — Wug·a·po·des​ 00:46, 20 February 2021 (UTC)

  Notwhen it'sjust twowords :-P Levivich ^harass/_hound 08:10, 20 February 2021 (UTC)

  ...is what your comment would look like if we allowed people to use whichever method worked for them and still made it work. If we turn off those parameters, your comment wouldn't have appeared. If we allow people to use whatever works and use a bot to clean it up afterwards, your comment would look just like everyone else's after some period of time (during which your comment would still be functional, even if pairs of words were sometimes combined). :) — Rhododendrites ^talk \\ 20:15, 22 February 2021 (UTC)

• Option A for all the arguments already made at length in the CS1/CS2 talk pages over the years and the good arguments brought forward above. Definitely not Option C. --Matthiaspaul (talk) 02:06, 20 February 2021 (UTC)
• Option C. Such an absurd waste of time and energy and an enormous source of watchlist spam, all to achieve something that will make editing more difficult. Toohool (talk) 02:26, 22 February 2021 (UTC)
• Option A as standardizing is better in the long term. Let the bot continue its work. If people have a problem with their watchlist getting spammed, they have the option to filter out bot edits. AVSmalnad77 ^talk 05:59, 23 February 2021 (UTC)
• Option C if not B While I love consistency, I'm struggling to see what the actual issue is here. I guess they can be gradually changed by the bot along with other more useful changes, but this is just cosmetic to the code and clutters edit histories. Reywas92^Talk 06:21, 24 February 2021 (UTC)
• Option C. Benefits for bot or template builders don't outweigh the inconvenience for other editors. Fram (talk) 08:13, 24 February 2021 (UTC)
• C. I don't see the argument for mandating hyphens. Just let people use both, consistency on this does not matter. Fences&Windows 17:00, 24 February 2021 (UTC)
• Comment - my default is Option D... I refuse to use citation templates, and format my citations by hand. It means that I can ignore all the silly debates about parameters and what not. Blueboar (talk) 17:49, 24 February 2021 (UTC)

  Yeah and we can instantly clear the WP:PHAB backlog by writing articles with paper and pen. We can solve many technological problems by abandoning technology. Levivich ^harass/_hound 00:52, 25 February 2021 (UTC)

• Option C. Bots do some useful work but their code can be changed as needed. Here I am much more concerned about regular editors who use citation templates when making manual edits. These are live human beings and there are many more of them than bots. Making the template syntax too rigid will make their life much more unpleasant. Extra flexibility is both useful and helpful for regular editors. Nsk92 (talk) 02:26, 25 February 2021 (UTC)
• Option C. I've been typing accessdate for the last 15 or so years, sometimes while reaching for my drink with my other hand (Qwerty keyboard). Why wreck my muscle memory and deprive me of a sip of tea?-gadfium 04:04, 25 February 2021 (UTC)
• Option Cper Phil BridgerSea Ane (talk) 21:53, 26 February 2021 (UTC)
• Option C, stop the craziness hitting watchlists (although most of that damage is already done). SandyGeorgia (Talk) 00:58, 2 March 2021 (UTC)
• C sounds best, followed by B. Removing parameters that were widely used in the past will break old revisions of articles for very little practical advantage. —Kusma (t·c) 11:44, 2 March 2021 (UTC)
• Option C. Others have already hit on why – watchlist spam, waste of time and energy for no genuine benefit, unnecessary imposition on editors, etc. I'm increasingly warming to the idea of writing out citations manually (as someone else here mentioned), just to avoid the constant tinkering around that seems to take place with these templates. JG66 (talk) 11:51, 2 March 2021 (UTC)
• Option C per Aquillion. Monkbot should never have been approved --In actu (Guerillero) ^{Parlez Moi} 20:22, 2 March 2021 (UTC)
• A or B This seems like a choice between having unnecessarily having several different ways to write a given parameter, and between standardizing after the fact with a lot of minor edits. Many of the arguments in favour of C appear to presuppose that editors will land in trouble for writing the unhyphenated parameters, but I don't see evidence of that. Jo-Jo Eumerus (talk) 10:30, 4 March 2021 (UTC)
• Option A. From real world experience, I understand how difficult it is to maintain code without occasional deprecation. Opponents' fears of unacceptable disruption and inconvenience don't match what I encountered when the bot was running, and typing the hyphen quickly became second nature. --Worldbruce (talk) 05:07, 7 March 2021 (UTC)

  You may not personally have encountered disruption and inconvenience, but I did and there are a great many other editors in this and other discussions that have reported unacceptable disruption and explained exactly why the inconvenience is not justified. Thryduulf (talk) 20:29, 7 March 2021 (UTC)

• Option A. Long term benefit is worth the short-term disruption. There is too much inconsistency in templates that causes me to waste far more time (e.g. is it "image=" or "Image=" or "photo=" in this particular template); we should move towards more consistency. I would support keeping the parameters functional for a few years (but undocumented and with a warning) for those who really are troubled by typing the hyphen, knowing the bot will come by and change them. MB 15:23, 7 March 2021 (UTC)

  The better solution to "is it "image=" or "Image=" or "photo=" " is simply to support all of them. That way there is no need for any disruption, short-term or otherwise. Thryduulf (talk) 20:31, 7 March 2021 (UTC)

• Option A—standardization helps simplify code maintenance, and that means more time can be devoted to future improvements. Imzadi 1979 → 17:34, 7 March 2021 (UTC)
• The question before us is: Should non-hyphenated parameters be fully removed from the CS1/2 family of templates? Yes, absolutely, for most if not all of the reasons enumerated above. Consistent parameter naming should have been implemented c. 2007 when the various, independently-developed, cs1|2 templates were converted to use {{citation/core}} as the common citation rendering engine. In early 2013, en.wiki migrated to the Module:Citation/CS1 suite. Since then, approximately 180 other-language MediaWiki wikis plus some number of non-MediaWiki wikis have also migrated to the module suite. In the time since en.wiki switched to the module suite, we have added new parameter names to support new functionality while at the same time, we have pared away quite a few parameter names because of redundancy, peculiar name-style, non-use, and other reasons. This reduction includes most of the nonhyphenated multiword parameter names so that today, the only remaining nonhyphenated parameter names are |accessdate=, |archivedate=, |archiveurl=, |authorlink= (and its two enumerated forms), and |origyear= (there are 263 basic parameter names and 77 enumerated parameter names). The worldwide adoption of the cs1|2 module suite has caused us to add support for internationalization. Non-English wikis employing the cs1|2 module suite should retain all of the English parameter names because, very often, articles developed at en.wiki are exported and translated to those other languages. That means that a fully implemented module suite at a non-English wiki must support the 340 English parameter names plus 340 local parameter names. It is best, I think, to have a single consistent style for multiword parameter names so that translating editors don't have to learn about or deal with redundant parameter names (this same applies to beginner editors at en.wiki). The cs1|2 templates are complex enough, we don't need to add to that complexity by maintaining lists of synonymous parameter names that don't have semantic meaning (for example, |chapter=, |article=, |entry=, |section=, etc, are treated by cs1|2 as synonyms but, to editors, convey different meanings – the inclusion or omission of a hyphen conveys no meaningful distinction). So yeah, non-hyphenated parameters [should] be fully removed from the CS1/2 family of templates and since we can't go back to 2007 to do what we should have done then, we should do it now, we should do it quickly, and we should get it done. A is my preferred option but, if needs must, then (sigh) B; never that other option. —Trappist the monk (talk) 00:50, 8 March 2021 (UTC)

  Thanks for weighing in, Trappist; I just wish you had done it a month ago. Your explanation is persuasive, but I still think Option A is silly if we don't at least simultaneously change the documentation to tell users, "don't use that parameter anymore". Having the bots fight against the human editors is silly and inefficient and possibly even dangerous. — JohnFromPinckney (talk) 02:03, 8 March 2021 (UTC)

  So to summarise Trappist's arguments: It's much easier for developers to only have a few names so we should disrupt editors and thus the wiki to make their lives easier, regardless of the costs (it's been explained at length previously how having two names do the same thing is not at all a problem for editors). Sorry, but that is not persuasive in the slightest: templates exist to support editors not the other way around. Thryduulf (talk) 03:06, 8 March 2021 (UTC)

  No. Trappist said no such thing. He helpfully explained why this change is necessary. With the possible exception of watchlists, this change does not seriously "disrupt editors" (there's no way having to type in one extra character can be said to be a problem of that magnitude); on the contrary, in the long run it makes life easier for editors, because there is only one simple, easy-to-remember rule: all muti-word parameters use a hyphen to separate the words. On watchlists, see #Worth noting below, which seems to be a promising solution. And if the worst comes to the worst and that solution doesn't work for you, then I sympathise, but at least the "disruption" is only temporary until the bot is finished. --NSH001 (talk) 10:05, 8 March 2021 (UTC)

  No, the disruption is not temporary. Not only are people likely to continue using the "old" parameters, but removing support for these parameters from the templates means that millions of old revisions will have errors in them instead of simply displaying the references like they used to. Creating errors in the references of old versions of countless pages, so that you only have to maintain 340 instead of 349 parameters (well, not even that, 340 parameters + 9 synonyms)? That seems like a lot of disruption for little gain. Fram (talk) 11:13, 8 March 2021 (UTC)

  Doesn't really matter, it's relatively uncommon to cite old versions of pages, and the error messsages can safely be ignored – only the latest page matters. They also suffer from deleted templates (which can be much more serious for the page as actually displayed to the user) and wikilinks which have gone red because the target page has been deleted. No doubt other things I haven't thought of yet. One just accepts these imperfections. Doesn't seriously "disrupt" anything. --NSH001 (talk) 14:05, 8 March 2021 (UTC)

  A redlink because the target doesn't exist isn't an issue (it is even an improvement). The others are problems, and knowingly adding much, much more of the same is a serious issue. A version of Salvador Dalí from 5 years ago now already has 10 or so errors: the lang text ones are the most annoying. But the planned defenestration of e.g. accessdate will suddenly add 24 extra errors here. Basically, every edit that MonkBot does for these, will mean one or more errors in every history revision, or millions upon millions of old versions which will become worse, and no current of future versions which will become better. Fram (talk) 14:33, 8 March 2021 (UTC)

  "Basically, every edit that MonkBot does for these, will mean one or more errors in every history revision, or millions upon millions of old versions which will become worse". That's false. Monkbot 18's edits make no difference whatsoever to the display of error messages; in fact it will reduce (drastically) the number of error messages that are eventually displayed when and if the remaining are formally deprecated, where "formally deprecated" means changing the CS1/1 module suite to actually generate the error messages. --NSH001 (talk) 09:37, 11 March 2021 (UTC)

  Not false, just shorthand. One can see the number of errors that will exist by looking at the number of edits that Monkbot does for this. No, Monkbot doesn't cause the errors directly, the deprecation does; but the two belong together. If option C is chosen, then there will be no "when and if", the remaining will not be formally deprecated, and no error messages will be generated, not in historic versions, not in live versions. None. Fram (talk) 10:56, 11 March 2021 (UTC)

  "One can see the number of errors that will exist by looking at the number of edits that Monkbot does for this." That's very misleading. The number of edits by the bot has nothing whatsoever to do with the errors displayed in the live version (except that, as I've already explained, it reduces them). You're trying to mislead readers here by implying that every single edit by the bot causes an error message, when in fact it only does so for historic versions. Error messages in historic versions don't matter. --NSH001 (talk) 12:00, 11 March 2021 (UTC)

  No, that's not misleading if one reads the actual conversation, which is about historic versions. "removing support for these parameters from the templates means that millions of old revisions will have errors in them instead of simply displaying the references like they used to." and "Basically, every edit that MonkBot does for these, will mean one or more errors in every history revision, or millions upon millions of old versions which will become worse, and no current of future versions which will become better." That's what you replied to, and which we are still discussing. We can disagree whether errors in old revisions are a problem or not, or whether the maintenance cost of keeping a few synonyms alive is negligible or significant; but please don't start accusing people of "trying to mislead readers" (a bit rich coming from someone claiming that "access-date" is easier to use and more meaningful than "accessdate"). Fram (talk) 12:12, 11 March 2021 (UTC)

• Option C And this issue is largely why I am of the current position BAG is not suitable for purpose and needs nuking from orbit. Only in death does duty end (talk) 15:31, 8 March 2021 (UTC)

  The BAG has a few functions. It does a good job of some of them - notably it's pretty good at ensuring bots do only what their authors intend them to do before they are unleashed. The main issue is with ensuring that only tasks with consensus to be done and consensus for a bot to do the job get approved - I can't recall an instance when it failed to approve something that should be approved, and it does stop the truly egregiously bad ideas from proceeding, but there are multiple instances (including this one) where bar for consensus has been set too low and a small local consensus has allowed a bot without wide community approval to operate. If we have bots then we do need some sort of approvals process, so don't nuke the one we have without coming up with something better first. Thryduulf (talk) 16:54, 8 March 2021 (UTC)

  "only what their authors intend them to do before they are unleashed." On a technical level this is correct - what BAG doesnt do is any sort of even half-decent job of confirming that bots *continue* to only do the tasks they were initially approved for, or that that approval in the first place has consensus amongst those editors who it will *affect* that the task is wanted or needed, or that there is a clear benefit to those effected by it. The problem with automated editing is rarely the technical aspect, its the business case for it. If we did a review of current active bot tasks (and editors using automated editing to perform mass edits) do you genuinely think they will all be able to point to a discussion that shows a level of consensus proportionate to their effect on the wider editing populace, rather than the walled garden (and the term I would actually prefer to use here as its more accurate is circle-jerk) of 5 or 6 data & machine readable obsessed editors who want it? Only in death does duty end (talk) 08:30, 11 March 2021 (UTC)

  On the technical vs business-case aspect, I agree, that was much of the point I was trying to make. I also agree that a regular review of bot and automated editing tasks should be undertaken. There are some that I'm sure still have community consensus (e.g. the anti-vandal bots) but I can't say that will hold true for every task. I also agree that there must be an active consensus of editors that will be affected before a task goes ahead - in the case of monkbot almost all affected editors were entirely unaware that it was even proposed. Thryduulf (talk) 14:20, 11 March 2021 (UTC)

• Option B - I can easily see both sides of this debate. As someone who works in IT, I fully agree that IT should serve the needs of users first wherever possible, rather than simply making life easier for the people who maintain the systems. I see far too many systems that make life harder than the non-digital alternative, which is just ridiculous. There are of course times when things need to be deprecated because they're either incompatible with other things, have security holes, or take up too much development time to maintain. This case is one of the latter, although I'm not sure what extra burden the deprecated (non-hyphenated) paramaters actually add. I would recommend that we formally deprecate the unhyphenated parameters and clean them up with AWB genfixes but I can't support continuing to run Monkbot 18 given the strength of feeling here against such a task. Personally I do not care about 'watchlist spam', but clearly many people do, and we cannot simply dismiss their opinion because "it'd make life easier for us techs". ƒirefly ( t · c ) 07:42, 10 March 2021 (UTC)

  As I understand it, there's a framework for supporting parameter aliases, which are configured in Module:Citation/CS1/Configuration. As there are many other aliases supported, the framework would remain in place. isaacl (talk) 15:23, 10 March 2021 (UTC)

• Option A / B per above.  Spy-cicle💥  Talk? 18:50, 10 March 2021 (UTC)
• Option A, strongly oppose Option C. Hyphens should be standard and we should discourage them. I do not mind continuing to support the non-hyphenated version per B, but B also implies the bot isn't free to do its job, so A it is. SportingFlyer T·C 12:57, 11 March 2021 (UTC)

  Why should one version over the other be discouraged? What benefit to the encyclopaedia does it bring that outweighs the disruption that removing support for a long-standing and well-used feature causes? Why should the bot be free to continue to do a job it didn't have consensus for? Thryduulf (talk) 14:22, 11 March 2021 (UTC)

  We're trying to gain consensus here, right? I support standardising the reference tags, and I don't think the opponents have good counter-arguments. I'd appreciate if you just let me (and others) have our opinions without the need for commenting - you're not "correct" and we're not "wrong." SportingFlyer T·C 15:01, 11 March 2021 (UTC)

  I'm not trying to stop people having opinions. I'm trying to get people to explain them and to actually counter arguments left explaining preferences different to their own. Why is standardising reference tags more important than the disruption standardisation causes? Why is a desire to avoid this disruption "not a good counter-argument"? I may or may not be "correct" but unless you can explain why forcing standardisation against the wishes of a very significant number of editors (who will not see any benefit from such standardisation but will experience significant ongoing disruption due to it) is somehow desirable then there is no hope of getting consensus for your views. Thryduulf (talk) 16:02, 11 March 2021 (UTC)

  You're chiding me for not countering your argument, even though your argument above is simply "I don't see the point." We've been working on this for awhile, it's been discussed on talk pages, it makes it easier to maintain the encyclopaedia, and it's a good idea to finish the project as opposed to having it held back by users who don't like it. I also thought I was just !voting here, I think this is obvious and I don't want to be drawn into a long argument about this, so not only did I not appreciate your response, I'd appreciate it if you left this conversation alone going forward. SportingFlyer T·C 16:49, 11 March 2021 (UTC)

  As with many of these types of questions, the conclusion each person draws depends a lot on the weighting they give on the relative priorities of different factors. We lay out our lines of reasoning with the tradeoffs, and others can use it as they wish to figure out what tradeoffs they would like to make. isaacl (talk) 17:13, 11 March 2021 (UTC)

• Option C Unless there is an issue with bots having to read accessdate and access-date as the same thing (and there doesn't appear to be a problem from what has been described, as bots can do this) then I'm not convinced that forcing users who already write accessdate to make an error when they continue to do so after its use is stopped that bots will then flag up for humans to solve is going to be a useful thing to do. Creating a situation which is going to frustrate and demotivate volunteers for no valid reason other than "conformity" doesn't sound like a good plan. Indeed, it was stressed in the original 2014 RfC that "Establishing this uniform parameter name convention does not preclude the existence of any other alias for a parameter, merely that a lowercase, hyphenated version will exist for each parameter." And some of those supporting did so because: "This will significantly reduce editor confusion. They don't have to think about: "Is this the parameter where the words are mushed together, or is it one where they are separated by an '_' ?" Hopefully this will make the templates easier to use." - User:Makyen. What we should be looking at is making bots read the varying ways that users may write a word or phrase in a template. I hate it when, for example, I use a capital letter by mistake, and the template doesn't work, and I have to work out what the problem is. I don't follow how frustrating, demotivating and alienating volunteers by changing how a template works and so creating problems for them will "decrease the maintenance burden" on those users. It is sometimes things like functionality being changed, that drives users away. SilkTork (talk) 01:09, 12 March 2021 (UTC)
• Option C. I haven't checked whether this move was done under a six-year old RFC with seven people, or under a seven-year old RFC with six people. But no one disputed that it was an at least six years old RFC involving at most seven people. Now, it seems that there are a large number of users who disagree. Perhaps telling them they "don't see the larger picture" will be enough to silence the dissenters. Maybe the "Visual Editor reception" will happen again. Who knows the future? Pldx1 (talk) 15:07, 12 March 2021 (UTC)
• Option A. I do not see any real argument for why citation templates should be a mish-mash of two different parameter names. It's an eyesore, it's a pain in the ass, and it brings zero utility. There are a couple ways of fixing it: for the new parameter names to be integrated into every tool, and every adjacent task, and every automated editing tool, and then maybe in ten years 90% of them will be gone (but the remaining 10% will be scattered willy-nilly across the entire project and impossible to hunt down). Or we could just have there be one short run and be done with it. I, for one, would be glad for the issue to be concluded. jp×g 05:33, 15 March 2021 (UTC)

  Have you actually ready any of the comments left by others? There are at least half a dozen different reasons given for the utility of multiple forms of parameteres. Even if option A is selected, disruption will not be short term but will continue for years for the reasons explained multiple times elsewhere on this page. Thryduulf (talk) 12:27, 15 March 2021 (UTC)

• Option A. Over time, we evolve different conventions. Once we have done so, we need to clean up the uses of the old conventions. Option B will be too slow and leave this issue dragging on for many more years. So, firstly ensure that all documentation is unambiguous about using only the new names. Secondly, make sure that all editing tools use only the correct parameter names and all genfix rules are up to date. Wait for the bot to complete a full pass and then treat the old parameter names as solid errors — GhostInTheMachine ^{talk to me} 15:36, 15 March 2021 (UTC)
• Option C. The encyclopedia should be run for the benefit of readers, and subject to that, for the benefit of editors. Creating busywork and random conventions for the sake of it is not useful. Stifle (talk) 10:19, 16 March 2021 (UTC)
• Comment: The argument made here and elsewhere about how much easier things would be for template- and module-writers under Option A, is a completely misguided and arrogant one. It seeks to benefit a small subgroup who are neither the consumers of the encyclopedia, nor its principal creators. Namely, it calls for optimizing ease of work and convenience for the very small number of template/module writers, rather than optimizing for (the much larger number of) article editors. The trade-off must benefit the largest number; if you make it harder for editors, then the article readers will suffer, and they are the largest group of all and the reason the encyclopedia exists. This should be axiomatic, but the encyclopedia isn't here for the convenience of template and module writers. Personally, I'm happy writing and improving templates and breaking my head against squirrely, confusing, and sometimes infuriating template problems, just to make things slightly easier for editors. If it's too inconvenient or too much work for template/module-writers, then they should abstain from "helping", and just improve article content, rather than seek to make their own lives easier. Mathglot (talk) 23:42, 20 March 2021 (UTC)

  Thryduulf said it better (and briefer) than I, here: "Those who do care about template mechanics should always be acting in ways that actively put readers first, editors second and programmers third." Precisely. Mathglot (talk) 00:04, 21 March 2021 (UTC)

• Option C (preferred) or Option B (seoncd choice) -Beyond My Ken (talk) 03:06, 23 March 2021 (UTC)
• Strongest possible option C Per WP:KISS and WP:IFITAINTBROKE. If it ain't broken, don't fix it, and don't waste our time with meaningless bot tasks. We should be making templates easy to use. Having different aliases for the same parameter is helpful. Insisting on one particular format because of some concept about what is correct and what is not is WP:CREEP, and generally to be discouraged. RandomCanadian (talk / contribs) 01:59, 24 March 2021 (UTC)
• Option C. If we were starting today, and writing brand new template to handle citations, I would strongly advocate using one consistent format for parameter names. But we aren't. Many thousands of editors are used to using the no-hyphen versions of those parameters, and I see no reason to disrupt their editing lives in order to (allegedly) make life easier for a handful of template editors. The system we have now works fine, I see no reason at all to waste anybody's time changing it. Chuntuk (talk) 20:41, 30 March 2021 (UTC)
  • This argument, and those like it, would be more persuasive if dozens of unhyphenated multi-word parameters had not already been deprecated and removed from the CS1 citation templates over the past seven years with a minimum of drama. We are talking here about removing the final six, which would make the whole parameter system consistent instead of the current situation, in which nearly all multi-word parameters are hyphen-only, and six have unhyphenated options. Option C proposes to halt seven years of work when it is about 90% complete. – Jonesey95 (talk) 01:59, 1 April 2021 (UTC)
    • Fait accompli actions, where actions are justified by virtue of being already carried out, and difficult to reverse, are inappropriate. If it's a concern that some parameters have unhyphenated aliases and others don't, let's allow unhyphenated options for all. Nikkimaria (talk) 02:20, 1 April 2021 (UTC)
      • There has been discussion at Help Talk:CS1 prior to the deprecation of each multiword parameter over the past seven years, and then further discussion at the same page prior to the removal of support for those parameters. Millions of page changes have been performed over those seven years to remove the deprecated parameters from pages in affected namespaces. Until this last round of edits by Monkbot, I have been unable to find significant objection to these edits. All of that is very different from a fait accompli: the actions are not justified by having been carried out, they are justified by being repeatedly discussed at the relevant talk page and documented accordingly. Again, the only difference between this parameter standardization work and that done for hundreds of other templates is the scale. – Jonesey95 (talk) 15:30, 1 April 2021 (UTC)
        • Funny you should mention scale. This is the first large-scale discussion I'm aware of on this topic; as already noted, there are far more participants supporting option C here than have supported deprecation in any previous discussion. This suggests that, to the extent that consensus for these deprecations could ever have been said to exist, it was an extremely limited one - certainly not one strong enough to support millions of changes. Nikkimaria (talk) 00:25, 2 April 2021 (UTC)
• Option A. Having done a fair bit of work with CS1 templates, I support the option that ensures the greatest consistency and ease of use among articles. While inter-article consistency is indeed not fully realized, with various articles having different ways to write dates or citations, I think, at the very least, disabling |accessdate= in favor of |access-date=, et al., would make it easier to search of instances of strings without the need to use regular expressions or two separate searches to get everything. In addition, the line breaks in the editing window make things easier to look at. It's nothing too major, but I think ultimately that moving everything to the hyphenated formats will do us much more good in the long run. -BRAINULATOR9 (TALK) 19:18, 1 April 2021 (UTC)
• Option A now that the tasks have got this far. Regardless of personal naming preferences, standardization is far preferable to the alternative of having to maintain and support multiple template options indefinitely, which is what it boils down to. MichaelMaggs (talk) 13:04, 2 April 2021 (UTC)
• Option C, though I don't think the proposal is completely accurate as MonkBot has been removing accessdate which is not officially deprecated, which is a problem on its own. Based on this discussion and the CBD proposal, there clearly is not unanimous consensus that a) non-hyphenated parameters should be deprecated and b) that millions of cosmetic edits are fine, but somehow both were approved with no opposition. I get the impression that the bot approvals group (or whomever makes these decisions) does not accurately represent the wider community. For now, these decisions which do not have consensus should be revoked. -M.Nelson (talk) 10:02, 3 April 2021 (UTC)
• Option A. Template and module maintainers do a lot of work behind the scenes to ensure the rest of us have a smooth experience as possible. This often requires vast amounts of code with many edge cases. This in turn, makes maintaining big modules harder and more difficult as times goes on. For the editor experience, having a consistent style on any article they edit is always a benefit. I've spent many times looking at templates, trying to figure out what the correct parameter should be because of the existence of parameter aliases. I'm sure newer editors that find it harder navigating template documentation find it even more frustrating. Removing this burden would benefit both groups of editors and maintainers. The downside of having a watchlist "spammed" is very minimal and has a page should only have one edit (by this bot), that means that a watcher will view it once. The amount of editors that watch many pages and will be annoyed by it is extremely minimal that it is frankly absured that it is even a consideration. --Gonnym (talk) 12:52, 3 April 2021 (UTC)

Discussion (CS1)

Some suggestions regarding the options:

• Pedantry: "Non-hyphenated parameters" should read "Non-hyphenated multi-word parameters" in all three options. Parameters that contain only a single word or acronym do not need a hyphen.
• In Option C, there is no point in suggesting that "the deprecated parameter list will need to be updated to remove the non-hyphenated parameters"; there are no instances of those deprecated parameters left in the affected namespaces, so support for them will be removed shortly, just as support has been removed for dozens of unhyphenated multi-word parameters already.

Some history and a status update, for those here on VPP unfamiliar with the long history of updates and changes to the Citation Style 1 templates ({{cite web}} and its siblings): As far as I can tell, there are only six unhyphenated multi-word parameters left – |accessdate=, |airdate=, |archivedate=, |archiveurl=, |authorlink=, and |origyear= – out of an original population of many dozens. So far, through the work of scores of editors and bots over the seven years since we standardized on hyphenation of multi-word parameters, we have deprecated, removed from pages in affected namespaces, and then removed from the CS1 templates themselves (as WhatamIdoing suggests above), many dozens of different unhyphenated multi-word parameters in CS1/CS2 templates. All new multi-word parameters during that time have been introduced using only a hyphenated form. This RFC is essentially asking: should we finish the job, or leave it at over 90% done, in a sort of limbo state, with six parameters as exceptions to the overall pattern, just because those parameters are used in a lot of articles? – Jonesey95 (talk) 04:38, 11 February 2021 (UTC)

• Problem with "Option B": Option B is not the status quo. If it were, I'd be much happier. Since it's not, I don't know whether to !vote for A or B. The documentation at Cite web, for example, makes no mention of accessdate being deprecated. This means that users will be quite justified in blissfully adding and readding templates with accessdate, even after the bot has come through already and changed accessdate to access-date in 20 places. Each iteration tends to address fewer instances, but each run is a separate entry in my watchlist. Watchlist entries seem to be part of the complaint against this kind of work, so the first step should be turning off the faucet at the source, before spending energy to, um, bail out the boat. — JohnFromPinckney (talk) 06:37, 11 February 2021 (UTC)
  • The first sentence is true; all but six of the unhyphenated multi-word parameters have been formally deprecated and removed. As for "turning off the faucet at the source", that would be Option A, but in the past, when we have made red error messages appear in large numbers of articles as a first step in standardizing the citation templates and noting errors in them, there has been significant pushback. In order to avoid that pushback, the bot was acting to fix 90+% of the non-standard parameters before turning on the error messages, but that work has been stopped as well. Option A will allow that work to be completed. – Jonesey95 (talk) 15:09, 11 February 2021 (UTC)
    • I feel we are not understanding each other. "Deprecation" involves communication as a first step; removal is a second, later step. If we are going to have a bot changing pages (e.g., accessdate to access-date), causing some distress to the populace (and this is the status quo), then we should at least change the documentation to say that accessdate is deprecated, and is not a usable alias. I am strongly against a bot going around to change parameters to the "good" names when we don't ever tell the humans they shouldn't use the "bad" ones. That's just an endless cycle of watchlist-cluttering edits causing great irritation. If you want to avoid pushback, tell the people not to use the unhyphenated versions, then run the bot, then remove support some time later. — JohnFromPinckney (talk) 15:41, 11 February 2021 (UTC)
      • Deprecate in terms of the CS1 templates means to emit a red error message indicating deprecation. When we emit any red error messages for parameters in CS1 that are used often (or lack thereof for parameters that should be used more often), a lot of people get very irate. We do not change the documentation to indicate deprecation until after the module begins telling people inline about deprecation. So yes, you are not understanding each other, but it's a question of terms of art. --Izno (talk) 16:44, 11 February 2021 (UTC)
        • Why do people get irate? Because suddenly millions of readers go from nothing being wrong to seeing a load of red error messages all over hundreds of thousands of articles (and you couldn't seriously expect someone to debug a CS1 error as their first contribution). These citation templates aren't for us. They're for the reader and they need to be functional with low rate of error messaging 24/7 with no exception, because even small amounts of downtime have significant reputational damage. — Bilorv (talk) 02:54, 15 February 2021 (UTC)
          • I would be more sympathetic to such an argument of "significant reputational damage" if there weren't over 100,000 pages with active errors on them (and that's ignoring the hidden Category:CS1 errors: missing periodical) and another 250k in its sister (also hidden). --Izno (talk) 20:22, 15 February 2021 (UTC)
    • That "we" (who is that, some class of super-techies whose opinions count for much more than those of us "normal" editors?) get significant pushback when creating error messages is simply a demonstration that the wider community does not agree with what "we" have decided. The answer is to stop doing what you are doing, not to do it more stealthily. Phil Bridger (talk) 18:37, 11 February 2021 (UTC)
      • You are welcome to participate at Help talk:CS1, the same as any other editor. Decisions are made by consensus there, inline with how consensus is practiced everywhere else on wiki. Don't like a decision "we" made? Get involved. --Izno (talk) 18:42, 11 February 2021 (UTC)
        • I saw absolutely no discussion of the removal of the freetext editors field on the talk page. Where did that happen? I don't think it's coincidence that all the editors whose names I know well from content creation/editing are voting B/C and all the editors voting A are those I don't recognise at all. Espresso Addict (talk) 20:08, 11 February 2021 (UTC)
          • The difference is between those people who think this is an encyclopedia and those who think that it's a playground for techies. Phil Bridger (talk) 20:43, 11 February 2021 (UTC)
            • Your ad hominem has no welcome here. Move along if that's the best you can offer to the discussion. --Izno (talk) 20:47, 11 February 2021 (UTC)
              • That is just the kind of reply that people who are here to create an encyclopedia tend to get from the techies. No response to genuine concerns but just an order to "move along". I have no wish to monitor whatever pages are used to ignore end users, but I have a right to expect that any decisions taken will respect the interests of everyone, not just a self-appointed clique of people who "know" what is right. Phil Bridger (talk) 19:53, 15 February 2021 (UTC)
                • It's the kind of reply to people who needlessly create category A and category B and then line themselves up in one or the other categories. If you (specific/personal) don't want to monitor whatever pages, that's your prerogative. Do know that it is your choice and you are responsible for that choice, and choices have consequences. Changes are always announced ahead of time and consensus is sought for non-obvious changes (and even obvious changes with non-obvious implementations), so you have no excuse not to tune in at least once every couple months when the regular "Shit is Changing" post gets made. Secondarily, the scare quotes are not indicated by this discussion, nor any prior discussion that I can see, whatsoever. I have not seen any such 'clique' nor any of the users who would prospectively be in such a 'clique' claim they "know" what is right. As I said, if you have nothing to contribute but smears and attacks and divisiveness, move on. --Izno (talk) 20:22, 15 February 2021 (UTC)
          • In reverse chronological order: the patch notes indicating removal, the removal discussion, the patch notes indicating deprecation, the deprecation discussion. 4 times mentioned over a period of half a year on that talk page, a pre-existing maintenance category indicating a soft deprecation, and my removal of over 4k instances of the parameter over the year and a half preceding that deprecation discussion. Basically by hand (my hand, as it happens). --Izno (talk) 20:45, 11 February 2021 (UTC)
          • As for I don't think it's coincidence that all the editors whose names I know well from content creation/editing are voting B/C and all the editors voting A are those I don't recognise at all., I invite you the same as I invited Phil Bridger. You may watch and edit Help talk:CS1 at any time, the same as me. "I don't recognize these people" is a trash association to make and is the same kind of ad hominem that I have asked Phil so kindly to stop employing. It is certainly not sufficient cause to say "I don't like this change". --Izno (talk) 20:49, 11 February 2021 (UTC)
            • I think there's a genuine problem here that there's a disconnect between the editors maintaining the citation templates and the editors employing them to write and maintain articles. I didn't make the decision to abandon years of using citation templates (CS2 actually, but the same parameter changes are happening there too, even less announced) lightly. Espresso Addict (talk) 21:35, 11 February 2021 (UTC)

              The disconnect is real and significant. Someone whose skills and interest lie in writing or maintaining article content shouldn't need to care about what happens at pages like Help talk:CS1 (and how on earth is a new editor even meant to know that page exists?), let alone have to pay attention to discussions there. Those who do care about template mechanics should always be acting in ways that actively put readers first, editors second and programmers third. The only time there should ever be breaking changes or a need for cosmetic edits is when after detailed examination there are literally no alternatives available. We've ended up here because that hasn't been happening and a local consensus has ignored the needs of end users. Thryduulf (talk) 01:38, 12 February 2021 (UTC)

              I almost commented last night, and then put that version into a text file and went to bed. Now I have been spurred by a comment above to reply here. The editors using these templates to write and maintain articles are the same as the editors maintaining the citation templates. Get that through your head. If we prioritize different qualities versus this other supposed separate group, it's because we have the experience to do so. If you don't, let me reiterate, get involved. Come and say "I don't like this" or "this is a painful interaction" or X, Y, and Z, and provide a suggested fix. That's how consensus starts forming, like every other page or process on this website. Others will say "I don't want this to work like that suggested fix because A, B, and C". Then you discuss the tradeoffs and make a decision. If you're unwilling to step up and discuss the paper cuts, then we end up having mass RFCs or AN drama or what have you over what would otherwise be small issues or ones that could have been discussed informally with the ordinary "let's figure it out" consensus view of the world. That's a disconnect too, and blaming editors interested in one page versus those apparently disinterested is not the right way to move forward. Want something to be better? Ask. Propose. Cajole. Make the effort to put forth the minorest of social interactions required to start a discussion in the one place where everything about that thing is discussed. We're all volunteers and our heart is in just a right a place as yours, but if we should have disagreements, then we talk to each other and find out how to fix the problem or agree to disagree on the points of interest. Not have constant complaints of "they didn't listen to me". Consensus is not unanimity.

              The only time there should ever be breaking changes or a need for cosmetic edits is when after detailed examination there are literally no alternatives available. This is quite frankly an opinion lacking any community consensus whatsoever. We've recently approved an RFC allowing cosmetic edits on a regular basis and from what I could see in that discussion (and murmurings elsewhere), cosmetic edits might be closer to having consensus than not, it's just inertia that leaves us not performing them regularly. Moreover, hundreds of templates, and certainly all those which go through WP:TFD, have a process applied which causes breaking changes or which results in more-or-less cosmetic edits. Are you claiming that TFD does not have consensus as a process? That templates which are being cleaned up because of a talk page discussion on that template's talk page should be stopped? You want your cake (to not care about how things work) and eat it too (have all of your opinions and claims listened to, when they aren't even articulated in the first place). Get real. --Izno (talk) 20:22, 15 February 2021 (UTC)

              I fear this just demonstrates the truth of what Thryduulf writes. "The editors using these templates to write and maintain articles are the same as the editors maintaining the citation templates. Get that through your head." is self-evidently false, as well as impolite. Speaking only for myself, what I actually want is to be able to get on with writing & improving articles, rather than having long side discussions on matters that aren't directly relevant. Espresso Addict (talk) 00:10, 16 February 2021 (UTC)

              get on with writing & improving articles Then do that. No-one is stopping you from not caring. I am just calling you hypocritical for raising a fuss when you don't and then changes happen elsewhere that affect you. Don't like it? Change your behavior. (I won't reply to you again.) --Izno (talk) 00:34, 16 February 2021 (UTC)

              The editors using these templates to write and maintain articles are the same as the editors maintaining the citation templates. Get that through your head. Both uncivil and not even close to correct. While it is possible that some, maybe even many, of the editors maintaining templates also write and maintain articles there are literally hundreds of editors writing and maintaining articles who have never been near a discussion about the template code, let alone written any code. Writing encyclopaedic prose and writing computer code are very different skills; nobody is or should be required to do both. However given that the purpose of this project is to write an encyclopaedia everything that is not writing an encyclopaedia should be done for the benefit of (first and foremost) readers of the encyclopaedia and (secondly) those who write and maintain the encyclopaedia. The convenience of those dealing with tools is least important. Thryduulf (talk) 00:23, 16 February 2021 (UTC)

              Writing encyclopaedic prose and writing computer code is a false dichotomy and a blatant misrepresentation of what the two paragraphs I had to say. I did not ask you to do both. Nor do I serve you (general) in your supposed role as an article writer. There are no (formal) hierarchies on this encyclopedia, and even considering yourself as supposedly above me or my efforts is the actual uncivil statement. Lastly, I place myself fully in both supposed groups given the thousands of articles where I have bettered their citations. (And as I said to Espresso, I will not reply in this section again.) --Izno (talk) 00:34, 16 February 2021 (UTC)

              My role here is not as an article writer (I do very little of that), I spend the majority of my time on the project trying to ensure that readers can find the content they are looking for and those that do write and improve articles without needing to worry about nonsense like this that will needlessly make their job harder. There might not be a formal hierarchy but their should be: (1) Readers are head-and-shoulders above anyone else. (2) Those who write and maintain the encyclopaedia a short way above (3) Those who support those write and maintain the encyclopaedia are a long way above (4) Those who hinder any of the above. I place myself in the third category alongside many of those who maintain templates. Thryduulf (talk) 21:02, 16 February 2021 (UTC)

• Comment. What is the merit of citation templates? Let alone the increasing creep to make them more and more rigid and harder and harder to use? The only reason I can see is to make it easier to export and sell data. No-one ever seems to give a thought to those who type citations manually; it is far harder to type "access-date" (which requires two hands and a hand movement) than "accessdate" (one hand, no move). I don't understand what the benefit of this change is at all. In fact, broadening this discussion, I don't understand why the freetext editors field was suddenly withdrawn this January. Personally I've decided to meet the latter change by reverting to writing out references by hand, which is easier, more flexible, and seems to have no downsides. Espresso Addict (talk) 07:04, 11 February 2021 (UTC)
  • Citation templates make standardizing citation style and look much easier. They can, for example, automatically standardize date display. Machine-readability is also a good thing, imo. I suppose access-date is slightly harder to type - but editors editing wikitext manually would probably not mind. Otherwise, tools for inserting these citations exist. Elliot321 (talk | contribs) 17:12, 11 February 2021 (UTC)
    • It's not slightly harder to type, it's a great deal harder to type for a touch typist. And here's an editor editing wikitext manually who does mind, enough to bother responding here. There's no tool I know of that creates citation template code in the form I prefer for ease of wikitext editing afterwards; they all make code soup that takes longer to fix than retype. Espresso Addict (talk) 20:08, 11 February 2021 (UTC)

      A bit slower, yes, but I personally don't find it a great deal harder—touch typists generally have practised it a lot while learning. Nonetheless, I don't think ease of typing by some metric is the primary issue. isaacl (talk) 20:40, 11 February 2021 (UTC)

      Speaking as one of those touch-typists, and as a person who learned to type on an actual typewriter, I don't find the hyphenated version any harder to type, and I do recall my typing teacher saying that it was faster and easier to type words that were split evenly between hands, instead of all in one hand. WhatamIdoing (talk) 22:49, 11 February 2021 (UTC)

      Yeah, personally I imagine it has a greater effect for a hunt-and-peck typist. When I said a bit slower, I was thinking compared with a word of equal length that consisted only of letters. Of course, in this case, the hyphenated name has one more character which would comprise most of the difference for me. isaacl (talk) 23:02, 11 February 2021 (UTC)

      For me, not an issue on a regular keyboard, but a bit of a pain on a tablet. Then again, so much is a bit of a pain on a tablet... · · · Peter Southwood (talk): 05:39, 2 March 2021 (UTC)

    • I use citation templates myself, but I respect the wishes of those who prefer not to use them. It is precisely the fact that I use them that leads me to the opinion that obvious synonyms for parameters should not be removed, as proposed here. What on Earth is the problem with allowing both hyphenated or unhyphenated forms? All it means is a few extra bytes of storage, and no extra code if it is done properly. And the work has already been done, but this proposal is to undo it. Do we still live in the days when I started in IT working for one of the world's leading business information companies whose UK operations were all run from a computer with 1MB of memory and where all online programs were limited to 12KB? I thought we had moved on from there. Phil Bridger (talk) 20:34, 11 February 2021 (UTC)

      I am reminded of a story about a lady, who (decades ago) bought a large supply of personalized stationery and then discovered that the post office was renaming her street. She convinced the local postmaster into letting her continue to use the old address until her stationery was used up. This saved her some money and effort, but it had external costs. For many years to come, every mail carrier had to learn that "123 Main Street" wasn't on Main Street and wasn't number 123, but instead had to be delivered to the other side of town.

      Aliases are often low-cost in storage and computational terms, but they are not actually free. "Not free" can add up to a quite significant cost when it is repeated a million times. WhatamIdoing (talk) 22:56, 11 February 2021 (UTC)

• Although I sympathize with the desire for all templates to align with one standard (from a user's perspective, I would personally find it easier), I just don't think it's feasible at this point in time. In which case, I sympathize with those who think computers should make our lives easier, and just accept both formats. On the third hand, from an implementer's perspective, I appreciate that it adds a lot of noise to template syntax, if not implemented with a Lua module. Since the CS1-based templates are implemented with Lua, the overhead can be minimized, and so I think both formats should continue to be supported. I don't feel there is much advantage to converting en masse, by any mechanism. isaacl (talk) 20:40, 11 February 2021 (UTC)
• Pinging some previous participants in related conversations who may not yet be aware of this discussion: @SandyGeorgia, Jason Quinn, Oknazevad, Tom.Reding, Brainulator, DavidBrooks, SMcCandlish, David Eppstein, Matthiaspaul, Headbomb, Gracefool, Ss112, JG66, Mikeblas, Gonzo fan2007, Sariel Xilo, Modest Genius, and SlimVirgin:. Nikkimaria (talk) 01:17, 12 February 2021 (UTC)

  Thanks for the ping, I was indeed unaware of this discussion. Modest Genius talk 12:16, 12 February 2021 (UTC)

• Does anyone have any evidence that having alias for parameters makes things harder for end users? In my experience as a trainer and long-time user, having multiple ways to achieve the same ends allows editors to spend their time and energy working on content rather than puzzling over making sure that the template parameters are named in exactly the right way. I've never met anybody who was comfortable enough to be dealing with templates in the first place who was not completely comfortable with the idea that "you can write it as either access-date or accessdate, it doesn't make a difference." (or similar). Speaking personally, I don't want to have to learn whether it is "accessdate", "access-date", "access_date" or "access date", I just want them all to be accepted so that whichever I input the template works and I can worry about more important things. Thryduulf (talk) 01:29, 12 February 2021 (UTC)

  The inconsistency across all templates does make things harder. Users have to either remember which templates only support one form and which one, or look it up each time. I appreciate though that there is extra complexity in trying to support lots of aliases, particularly for ones that aren't implemented with a Lua module (either each use is going to become more elaborate and verbose, or the template could delegate the detailed implementation to a helper template, with the top-level one only doing parameter normalization), so personally I wouldn't want to require that every template must support aliasing. Thus I think we're kind of stuck with inconsistency. isaacl (talk) 02:12, 12 February 2021 (UTC)

  This inconsistency should be tolerated. Some, particularly high-use, templates having aliases is important for the great number of people who use these templates. They don't have to remember was it |access-date= or |accessdate=. If it doesn't work on some other template, well fine. But eliminating aliases and simply making the computer say no on all templates makes things a lot harder for the vast majority of users. That inconvenience is far greater than the fact that a few lesser-used templates don't support aliases and you might need to take a look at the documentation sometimes. – Finnusertop (talk ⋅ contribs) 06:05, 12 February 2021 (UTC)

  Yes, as I said in another comment, I feel both forms should continue to be supported for the CS1-based templates. I'm pretty sure the vast majority of templates don't support both hyphenated and non-hyphenated parameters—for example, from what I can tell from the code and a quick test, {{Infobox}} doesn't. That's just the way it goes when trying to make as many aspects of Wikipedia markup accessible to as many editors as possible: standardization won't always happen, and often simpler markup will be preferred by more editors than more complex markup, even if it would add more functionality for users. isaacl (talk) 22:22, 12 February 2021 (UTC)

• In Option C, there is no point in suggesting that "the deprecated parameter list will need to be updated to remove the non-hyphenated parameters"; there are no instances of those deprecated parameters left in the affected namespaces, so support for them will be removed shortly, just as support has been removed for dozens of unhyphenated multi-word parameters already. This argument directly goes against WP:FAITACCOMPLI. Also, stop referring to them as "depreciated" - it is clear that there was insufficient consensus to declare them depreciated in the first place. I can understand that it's frustrating to have something you thought was decided fall apart like this, but it is extremely important that sweeping changes get more discussion before being implemented; the only way we can reasonably encourage that is by refusing to allow things like Monkbot's use here to determine policy, ie. it is necessary to make the work it did moot, or people will have a constant incentive to take the easy route and avoid bothering with time-consuming, often-frustrating, and unpredictable (but necessary) discussions before a change of this magnitude. That means, yes, allowing and even encouraging people to resume using non-hyphenated parameters even though you thought you were finally done with them; if you want to avoid that happening next time, seek larger-scale discussions first before making large-scale changes to avoid unexpected blowback if it turns out you don't have the consensus you thought you did. No matter how well-intentioned this was, we absolutely cannot risk rewarding the use of a tool to make a wide-spread change without sufficient consensus - which means, yes, as painful as it is, very deliberately taking the wrench to the kneecaps of the intended improvement this change was meant to establish, and intentionally ruining it even after the "cost' has been paid. It's not ideal, but it shows why it's so important to have broad discussions involving many users before making wide-spread changes; having policy effectively set by bots performing mass edits and establishing things as fait accompli is just not acceptable. I can sympathize with the amount of work that went into this that will be wasted as a result, but reaching a clear, unequivocal consensus involving a large number of editors should have been the first step for something of this magnitude, so you wouldn't suddenly run headlong into an RFC like this and find the consensus wasn't what you thought it was. --Aquillion (talk) 10:07, 4 March 2021 (UTC)

Arbitrary break 1

• Thanks to Nikkimaria for the ping based on my earlier involvement. I'm appallingly neutral (or torn) on the main topic but I earlier did some analysis that gives me concern about impacts on Template space in particular, if deprecation goes ahead fully. Here I'll use |authorlink= as a proxy for all six, because I personally type it more often. There are three areas that concern me: templates that indirectly invoke CS1, those that transclude CS1-invoking templates, and clones. I'm concerned about where and when red error messages appear, and documentation, in which I include both /doc and TemplateData.

1. There are many CS1-friendly templates that invoke one of the canonical templates; {{Cite encyclopedia}} is often used for example. Some use parameter rewriting, converting |authorlink= to |author-link= before passing it on.
   1. Does their documentation always give precedence to |author-link=? I think we caught them all during the earlier discussion, but I can't guarantee the quality of the search.
   2. Because the CS1 code never sees the deprecated parameter, should this template emit a red error itself during the substitution? Or maybe just forget about the mapping and have CS1 do it? And how hard is it to find templates with the parameter substitution code?
   3. If |authorlink= ever moves from deprecated to invalid, then all those mappings and documentation need to be trimmed in one fell swoop. Well, I guess the mappings can stay in place although they could trip up inattentive longtime users.
2. There are templates that simply transclude a pre-filled CS1-style template: for example embedding {{Cite book}} as a citation to a specific volume that is relevant to any use of this template. Have they all been fixed? If not, their user will see a red error message (correct?) that has nothing to do with their own usage.
3. There may be templates that are modeled on CS1 but roll their own expansion, although I don't know of any such. If they happen to use |authorlink=, should they also be brought in line?

Two final comments: there are more than six, if you consider variants like |author1link= and |authorlink1=. And in principle the arguments above apply to any page outside Template space that gets transcluded by someone, although I know that feature is rarely used. David Brooks (talk) 16:51, 12 February 2021 (UTC)

Shoulda said: the above applies to A and to some extent B but you can probably figure that out. David Brooks (talk) 16:57, 12 February 2021 (UTC)

DavidBrooks: There is a tiny army of editors at the ready to fix these templates. As far as I know, there are no transcludable templates that pass |authorlink=, your example, to any CS1 templates, so using those templates would not generate an error message. |accessdate= and the two or three remaining unhyphenated parameters being passed from template transclusions to CS1 templates were being processed by the bot before the bot was paused to hold this discussion. Once this discussion is closed, the bot will be able to resume that work, with human assistance, if the closure is a reasonable one. – Jonesey95 (talk) 17:13, 21 February 2021 (UTC)

@Jonesey95: I just addressed a related issue in Help talk:Citation Style 1, where by modifying the example given I found 3 templates that use |authorlink= in a CS1-style template that's used to reference a specific source: {{Barmakids family tree}}, {{Citeer web}}, {{Alox2}}. But this less restrictive query shows a few more (ignore the "DYK" archive, I think). Not sure if you meant this type of usage in your comment; I may be missing the context. David Brooks (talk) 05:05, 22 February 2021 (UTC)

@Jonesey95: OK, looks like you fixed {{Alox2}}. {{Barmakids family tree}} and {{Citeer web}} still need to be fixed (I'll do them later today). The documentation of "Cite book (short)" in {{Quicktemplates}} lists the not-incorrect |authorlink=, so that comes under the "prefer the hyphen forms in documentation" rule. I didn't look for |authorlink2= or |author2link= because they are unlikely to appear alone. David Brooks (talk) 19:17, 22 February 2021 (UTC) ... Y, also {{Bach's compositions (sources)}}, which indeed had |author2link =. David Brooks (talk) 21:42, 22 February 2021 (UTC)

• I would like to clarify what I meant when I originally wrote the options, since there is some confusion. My intention with "removal" was to refer only to removal of usage of nonhyphenated parameters by transclusions of the template, not removal from the implementation of the template itself (I will call this "disabling the parameter"). This is also distinct from deprecation, which is designating something in documentation and warning messages as discouraged. Remember that the original reason for this RfC is to clarify whether we should have a bot going through the article space removing the parameter usage as its sole action. A, B, and C are respectively continue removing now, remove only as part of other non-cosmetic edits or in a situation where cosmetic-only edits are allowed, or do not remove. In case of A or B, I did not intend for them to make a statement about whether we should disable the parameter when this is done. This is an important question, but orthogonal to whether the parameter usage is removed now or later. — The Earwig alt ⟨talk⟩ 22:11, 13 February 2021 (UTC)

  Thanks for clarifying (except the part where you formulated the options). Unfortunately, it now means I'm missing the option: Non-hyphenated parameters should be deprecated now and removed later. The actual status quo seems to be: Non-hyphenated parameters should be removed now and deprecated later, and the removal can occur by bot which does nothing else on the page (cosmetic only), but will revisit the page as often as necessary to re-remove the non-deprecated params that keep getting added. — JohnFromPinckney (talk) 23:01, 13 February 2021 (UTC)

  For context, this is how I originally phrased it; note B and C are swapped. Isn’t what you’re desiring exactly option B (in the current formulation)? It seems describing B as the "status quo" is confusing. Instead, view A as what the bot was doing before it was stopped, and B as what is currently happening with the bot stopped, but with clear, formal deprecation. — The Earwig alt ⟨talk⟩ 00:19, 14 February 2021 (UTC)

  Mmm, maybe, and in any case I'm very grateful for your link to the pre-RfC coordination at Primefac's Talk. And I can say that your original formulation was clearer than the formulation we're now using for the RfC proper. However:

  1. There appears to be no consensus for the removal of non-hyphenated multiword parameters. The 2014 RfC determined only that the hyphenated version must exist, and the close explicitly allowed for non-hyphenates.
  2. If this RfC is intended to determine whether non-hyphenates should be deprecated, it's poorly formulated to the extent that it mentions the current bot activities.
  3. I can't view Option A as what the bot was doing before it was stopped, because the parameter has not been deprecated. (The statement by Nikkimaria that deprecation "in the context of CS1/CS2" means a red maintenance message will be shown is not something I can accept, as any reasonable software provider knows that advance notice is the first part of deprecation. Unfortunately, I don't usually work "in the context of CS1/CS2", so haven't argued before against this unhappy definition.)
  4. Option B, as written on this page, is a garbled mess, not only because of the "status quo" mention, but also because of the "Deprecation can be bundled into genfixes..." bit. Deprecation, as above, is (first) a documentation task, followed by a (presumably small) step to cause red messages to be generated (I'm not sure what's involved here). I don't see what would need to be "bundled into genfixes". I had the feeling that many !voting here saw "removal" as meaning elimination of usages, but maybe that's due to my own confusion. Your Option C (and your original formulations in general) were much clearer.

  There should never have been any bot activities, because (a) there's no consensus, yet, to deprecate non-hyphenates, (b) the params are not yet deprecated, and (c) the bots' edits have been largely accessdate => access-date only, so violate WP:COSMETICBOT. So I guess I'll be !voting for B, although I'd much rather choose your original Option C. This RfC as written has been too unclear (at least for me). — JohnFromPinckney (talk) 11:20, 14 February 2021 (UTC)

  Re The 2014 RfC determined only that the hyphenated version must exist: As called out in the proposal, it also said The documentation is to show this lowercase, hyphenated version as the one for "normal use". Hence my comment above: some of us recently tweaked the documentation of a few high-use templates to make the hyphenated version the privileged one, but I can't guarantee we got both /doc and TemplateData for every template that indirectly uses CS1/2. If we end up with both hyphen and no-hyphen equally valid (is that C?), then tweaking the documentation will be the only change visible to current editors. SHould there be a more valiant effort to track them all down? David Brooks (talk) 19:45, 14 February 2021 (UTC)

  If the consensus is for Option C, then nobody has to track down anything; we can leave the documentation as it is. BTW, the claim written there, This will also mean that the deprecated parameter list will need to be updated to remove the non-hyphenated parameters is another red herring and would, it seems, not apply at all (as accessdate isn't even listed there yet).

  If we chose Options A or B, then yes, the documentation should be immediately changed. I can't believe it will take too much valor to find the Template:Cite web documentation, as it doesn't seem terrible exotic, but it should be included in the tweaking in those cases. — JohnFromPinckney (talk) 20:07, 14 February 2021 (UTC)

  • The 2014 RFC had a participation of only seven people and was six or seven years ago. It is patiently absurd to update documentation with such a sweeping change based on that alone, and any such changes ought to be reverted pending the outcome of a more clear RFC. Furthermore, the 2014 RFC specifically indicated that nothing would be depreciated, so if you are relying on it as a justification for any changes then obviously no non-hyphenated versions can be depreciated until / unless a new RFC overturns it. --Aquillion (talk) 22:19, 15 February 2021 (UTC)

  Please read the summary at the top of this Discussion section. Here's the summary of that summary: Dozens of unhyphenated multi-word parameters have been deprecated, removed from pages, and then removed from the Citation Style 1 templates over the last seven years. There are only six left. During those seven years, many new, hyphenated multi-word parameters have been introduced, without unhyphenated aliases. At present, the situation is that unhyphenated multi-word parameters are the standard, and there is just a bit more work to do to remove the final six outliers. Unfortunately, it appears that many editors have not enabled the useful settings "Expand watchlist to show all changes, not just the most recent" and "Group changes by page in recent changes and watchlist" so that bot edits can be hidden without losing visibility of bad human edits, so people are complaining about a bot "clogging" their watchlists. – Jonesey95 (talk) 23:59, 15 February 2021 (UTC)

  None of that is however relevant to Aquillion's comment in the slightest. That a flimsy consensus (at best) has been used to justify removing functionality in the past does not mean that that removal was a good thing or that the bot edits (which clog both watchlists and page histories with unnecessary edits, whether they hide other edits or not) should continue. Indeed, I strongly suspect there would be support for re-enabling the parameters already removed. Thryduulf (talk) 00:27, 16 February 2021 (UTC)

Please note, folks, that this bot is a one-off; it may be processing some 2 or 3 million pages, but it's still a one-off, that is (unless reverted) it will only ever appear ONCE in any article history. So the idea that it's "clogging up" page histories is a big red herring. If you're bothered about it "clogging up" your watchlist, then please set the options recommended by Jonesey95 and others. So that objection falls by the wayside too. Please also note that this bot finishes the job. Once it's done, that's it – no more bots making this sort of change. To the charge that this bot is "disruptive" or that it's somehow "removing functionality", I can't do better than copy Rexx's observation above: "Once we have standardised on hyphenated parameters, future editors will look back and think how lame and time-wasting this sort of debate is." --NSH001 (talk) 19:30, 21 February 2021 (UTC)

Except that, no, that's completely inaccurate. Consider List of University of Pennsylvania people. When I look at the last 500 edits just now, I see that Monkbot has been there SEVEN times: here (21:07, 19 October 2020) and here (01:02, 28 December 2020) and here (17:21, 14 January 2021) and here (21:21, 16 January 2021) and here (01:53, 18 January 2021) and here (15:30, 18 January 2021) and here (20:54, 30 January 2021). While that first edit (from October) did nothing with |accessdate=, the others all did, as often as it found new additions to the article. Note that the fifth and sixth edits both occurred on the same day.

I don't ordinarily block bot edits from my watchlist because I want to know what's going on with "my" articles, and the bots generally do useful and interesting work. It's just that the (to me) sudden and unforeseen flurry of multitudinous edits (doing, it appears, nothing which really interests me) was quite irritating. The repetition on List of University of Pennsylvania people really got my blood pressure up, and that's not far off from "disruptive" to me. — JohnFromPinckney (talk) 21:15, 21 February 2021 (UTC)

Hmm... The October edit is Monkbot 17 (not 18), so doesn't fall into the scope of this RfC. The edit on 28 December is the main application of this bot. That leaves 5 (mostly quite small) unexpected additional edits by the bot. They are all caused by editors adding parms that don't conform to the canonical standard. So yes, I should have qualified my statement by allowing for that possibility, sorry for that. Understandable that this should happen in the absence of a clear deprecation (so far) of the unhyphenated form. Perhaps the editors concerned are using some cite-generating tool that doesn't generate the canonical form, in which case the tool should be updated. Whatever, that strengthens the case for deprecating the non-canonical forms ASAP, and for moving forward as fast as possible with the main task. It's late now, and I will be going to bed shortly. Will comment on Phil Bidger's intemperate remark below in the morning. --NSH001 (talk) 00:06, 22 February 2021 (UTC)

Naw, the editor concerned is/was just copying/pasting whatever they found in whatever articles they were looking at. (The user also hasn't learned that refs go after punctuation, or that a named ref copied from another article might not be declared on the target page, or that Wikipedia has a Preview function to allow checking for errors. Not that I'm bitter.) Agreed, without actual deprecation, nobody knows what they're supposed to use or not use, so watchlists get plagued with unnecessary repetition. And I can't point such a user to the deprecation or consensus not to use the non-hyphenated forms, because there aren't any yet. — JohnFromPinckney (talk) 00:21, 22 February 2021 (UTC)

Thanks for that. If it is the case that editors on that page are simply copy-pasting cites from the original wiki bios, then that's good news – the problem will go away if the bot is simply allowed to continue and fix the problem in the source articles. I don't think it's true that there is no consensus for this change: the desired style was settled in an RfC several years ago, and has been 90% implemented in the years since, with no substantial objection. So there is an effective consensus, and it makes no sense not to carry the task through to its logical conclusion. The objections here amount to a dislike of large numbers of bot edits appearing on watchlists, not on the actual merits of the case. --NSH001 (talk) 07:34, 22 February 2021 (UTC)

The RfC in question only had seven supports, and only concerned making sure a hyphenated version existed and was presented first in the documentation. I don't know how that could be read as effective consensus for deprecating a parameter that, prior to the bot run, seems to have been more commonly used than the hyphenated variant - and even if it could, it would be a limited one. The objection to the bot is not just that it edits a lot, but that it "fixes" something that isn't a problem. Nikkimaria (talk) 14:01, 22 February 2021 (UTC)

Exactly this. — JohnFromPinckney (talk) 02:05, 23 February 2021 (UTC)

Nikkimaria, the first fallacy in your argument is that you are assuming the wider community, if it participated in the original RfC, would disagree with its conclusion. That isn't (quite) the case – I'm pretty sure that, out of the various choices available for multi-word parameters (runon, camelCase, under_score, hyphenation, etc), hyphenation would still be chosen, simply because it is the easiest to read in wikitext. Possibly underscore might be better (it won't line-wrap) but most people, apart perhaps from those with a programming background, will be much more comfortable with the hyphen, so that RfC came to a very sensible conclusion. The detail of its implementation is another matter, though. The second fallacy in your argument concerns the reason for the objection to the bot. Firstly, the observable fact is that some editors are now kicking up a huge time-wasting fuss about this bot, but said nothing about the many other bot runs for all the other CS1/2 parameters doing exactly the same thing. Secondly, and I see this repeatedly in other RfCs as well, that editors tend to focus solely on a perceived short-term problem, without taking account of the bigger picture and the wider context. That context has already been well described in the introduction to this RfC, and in the links given there. It's astonishing to me that people don't see that that the whole point of this work is to make the citation templates simpler and easier to use. Part of that process is to make the parameter names more meaningful and consistent. It's ridiculous to leave the mess inherited from the early days of citation templates, with these few remaining parameters sticking out like sore thumbs. --NSH001 (talk) 08:25, 25 February 2021 (UTC)

Please explain how allowing e.g. "accessdate" is less meaningful, is less simple, is harder to use for regular editors. That is the bigger picture, the wider coontext: the benefits are actually only for a small group of people, who have every right to present their case and ask if their life can be made easier, but should not be astonished when it turns out that in some cases, their preferred solution is not supported by the larger group of people who don't do (or not as regularly) the template and bot stuff. Putting error messages on thousands of pages for things which are not an error but something which a few people decided is no longer allowed at all is losing sight of the bigger picture as well. Fram (talk) 09:24, 25 February 2021 (UTC)

you are assuming the wider community, if it participated in the original RfC, would disagree with its conclusion. I don't know that, and neither do you, because the wider community was never consulted. We can be reasonably sure that the discussion would have been far less one-sided, based on subsequent commentary. As to the second half of your point, as Fram notes, it's not at all clear why deprecating widely-used aliases would make the templates easier to use for the average editor. Nikkimaria (talk) 13:33, 25 February 2021 (UTC)

(replying to both). Yes, that's easy. There's a very simple rule for all the CS1/2 citation templates: all multi-word parameters use a hyphen to separate the words. That's it. Dead easy to remember. Moreover, it's already implemented for the vast majority of the parameters (only 5 are left to do). I don't buy the argument that having to type ONE extra character is an insufferable burden. The only valid objection I can see is that the bot may flood watchlists, but that is temporary until the bot run is finished. So my sympathies to those who feel irritated (I don't – I have over 6,000 pages on my watchlist, and bot spam doesn't bother me), but the irritation will be temporary. If it really does bother you, others have mentioned a way to configure your watchlist to avoid the problem. --NSH001 (talk) 07:35, 8 March 2021 (UTC)

I'm glad you personally are not irritated by this change - but others are, and others have explained why hiding the problem is not solving it. No one is proposing removing the hyphenated variation, simply supporting the (often more widely used) aliases. It's not appropriate to justify a change on the basis of it being mostly carried out. Nikkimaria (talk) 02:49, 12 March 2021 (UTC)

On watchlists, see #Worth noting below for a possible way of reducing the "disruption". I forgot to reply to Fram's point about the wider context: I was thinking about the overall naming convention, and why the bot makes it easier, but Trappist's latest contribution to the survey section explains also the wider consideration that we need to consider all the non-English Wikipedias that have borrowed our CS1 templates/modules. --NSH001 (talk) 10:40, 8 March 2021 (UTC)

So the solution to a bot editing against consensus is for those who object to stop watching it? You couldn't make this stuff up. Once again, this is a fucking encyclopedia, not a place for techies to dictate to editors. Find a playground elsewhere, or get a real job and you will find out that people can only get paid to write programs if thay do what their users want them to. Phil Bridger (talk) 21:27, 21 February 2021 (UTC)

Phil, your first sentence is false. This bot was approved by consensus, following standard procedures. Indeed its operator went to extraordinary lengths to shout from the rooftops that it is a "cosmetic" bot. I'll ignore your intemperate and baseless personal attack. Finally, on the question of bot edits and watchlists, I refer you to Bilorv's conribution at 11:34, 13 February above, which looks like a good solution (I'll just add the caveat that I haven't tested it yet). --NSH001 (talk) 08:25, 25 February 2021 (UTC)

Reading some of the above comments, I'm sorely tempted to add a new proposal here: every editor who deliberately makes a change which adds an error message to at least 10,000 pages is stripped from their template editor right. Excluding hidden cats of course, these aren't a problem; but no depreciation of any parameter justifies such mainspace disruption for readers. Fram (talk) 08:30, 24 February 2021 (UTC)

Three responses: First of all, the error messages displayed by CS1 templates are displayed by consensus, not by a single editor. Second, the error messages, such as those displayed in articles within Category:CS1 errors: unsupported parameter, are shown not because a single editor changed a template, but because individual editors made errors when they used CS1 templates. Third, the objection to error messages being splashed across article space is why the bot was operating before the deprecation error messages were displayed. People hate the display of hundreds of thousands of minor error messages, so the bot was fixing the articles before the CS1 modules were changed to display deprecated-parameter errors.

Fram's feedback offer give something to think about, however; if the logical options A or B are chosen here so that the last 10% of the hyphenation of multi-word CS1 parameters can be completed, perhaps we should not display deprecated-parameter error messages (except maybe in preview mode) in articles until the vast majority of parameter name replacements are complete. – Jonesey95 (talk) 16:29, 24 February 2021 (UTC)

Thanks, but remember Wikipedia:Administrators' noticeboard/Archive313#Is there a semi-automated tool that could fix these annoying "Cite Web" errors? from 1 1/2 year ago? There also was "consensus" for that change, among a tiny group of editors, but disregarding the wider community. I hoped that that episode would have learned some of the people most active at these templates that, when they propose a change affecting many pages (and certainly when they propose a change adding error messages to many pages), they should get a much wider consensus first. Still, I see in the above discussion people arguing to activate the red error messages for this (most error messages we get now are either on very few pages or for actual errors, e.g. impossible dates), which isn't an error but something some bot operators and template builders don't like. Fram (talk) 17:06, 24 February 2021 (UTC)

Three responses: First of all, the error messages displayed by CS1 templates are displayed by consensus, not by a single editor. One thing that this discussion has made crystal-clear, I think, is that many of the "consensuses" used to make sweeping changes like this are not remotely sufficient in terms of scale per WP:LOCALCONSENSUS; again, if they were, we wouldn't be having this conversation. If you want to make a change that significantly affects hundreds of thousands of pages, you should need a consensus involving a very large number of users, and it should be properly broadcast on high-traffic boards - a seven-person "consensus" is patiently insufficient for a change at this scale, and turning around and using bots or template messages to then try to enforce it amounts to WP:FAITACCOMPLI. --Aquillion (talk) 10:03, 4 March 2021 (UTC)

I wish that people would stop repeating this "seven-person consensus" canard; it is a weak platform on which to base an argument. The consensus about hyphenated parameters has been in place for seven years, and has been reinforced by multiple discussions about deprecation of dozens of individual multi-word parameters during those seven years. The discussion page on which every single one of those discussions has occurred, Help talk:Citation Style 1, has 396 page watchers. – Jonesey95 (talk) 05:48, 11 March 2021 (UTC)

This page has ten times that, and I'm willing to bet there are more people opposing deprecation here than there are who supported it in the discussions you mention put together. Repeating a local consensus for less used parameters != an appropriate level of consensus to get rid of other parameters from literally millions of articles. Not to mention that the consensus that was supposedly established seven years ago wasn't even for deprecation, just prioritization. Nikkimaria (talk) 02:49, 12 March 2021 (UTC)

• I wish that people would stop repeating this "seven-person consensus" canard; it is a weak platform on which to base an argument. The consensus about hyphenated parameters has been in place for seven years To be clear, the consensus of that RFC was that non-hyphenated parameters are allowed, subject to the unambiguous restriction that no parameters can be depreciated. The RFC specifically did not favor non-hyphenated parameters over hyphenated ones, and the statement at its start specifically promised that no parameters would be depreciated as a result. There has never been any sort of consensus (not even a weak, highly-local one) to depreciate hyphenated parameters; nor, as a result, have any depreciations made on those grounds ever been valid. And it is clear from this discussion that such consensus would never have been reached if it had been sought (which it was not.) A discussion among a tiny number of people, without an RFC, which directly violated the very RFC they tried to use to justify their actions, with no further RFCs or any effort to get consensus from or even inform the wider community of what they were doing, is not a "consensus" in any way, shape, or form - longstanding consensuses get their weight from the large number of people who have seen and accepted them, and in this case the longstanding consensus is (and remains) to retain hyphenated parameters. --Aquillion (talk) 10:31, 16 March 2021 (UTC)

This is uh, not a good idea. In some cases many templates are used in error, though they previously did not detect such errors. Detecting and fixing such errors is a good thing. IAR is policy, and if someone is breaking tons of things, sure, remove their rights, but simply displaying error messages isn't a clear-cut issue.

As for non-silent parameter deprecation, yeah, replace first then deprecate. I don't think anyone disagrees with this. Elliot321 (talk | contribs) 20:30, 3 March 2021 (UTC)

Well, I certainly disagree (and have, several times, on this page already). If there's consensus to do away with certain parameters, then the very first thing to do is deprecate them, that is, tell everybody not to use them anymore, next, run the bots to replace the usage, then, eventually, show the red messages and, ultimately, completely remove support for the deprecated params. Any other path is crazy. — JohnFromPinckney (talk) 03:54, 4 March 2021 (UTC)

• One of the objections I raised with Monkbot18 which is not being addressed whatsoever in the "status quo" (option A) argument is that the bot also make other changes, including the removal of whitespace and line breaks from citation templates. This is unacceptable per MOS:STYLERET. In my mind, the time I have spent undoing these changes to the articles I focus on has been a far bigger burden than the lack or presence of a hyphen in a parameter. If this bot is tasked with swapping parameters, it should ONLY be changing "accessdate" to "access-date" (and vis a vis similar parameter hyphenations), and absolutely nothing outside of that. Option A should not be construed as approval of the bot code as currently written, but the task for which it was meant to be accomplishing. - Floydian ^τ _¢ 18:33, 7 March 2021 (UTC)

  Well, that's very odd, because Monkbot18 is very careful to preserve whitespace (with one very reasonable exception), so I don't see how it's going against STYLERET. It's true that it does remove empty/blank parameters, but that's a good thing, as it reduces clutter in the wikitext. It does a few other good things as well, see User:Monkbot/task_18: cosmetic cs1 template cleanup. Can you give specific examples of edits you think it's doing wrong, please? --NSH001 (talk) 19:13, 7 March 2021 (UTC)

  There's a nice list of reversions if you look at my edits for January 17, but here is an example. - Floydian ^τ _¢ 06:27, 8 March 2021 (UTC)

  Ah, that's the "one very reasonable exception" that I referred to. All the other changes that you felt you needed to make in your "cleanup and standardise first 150 refs. Revert stupid friggen MonkBot making stylistic changes to thousands of articles on a "consensus" of like 3 people, and block it from making further edits" edit are down to other editors/bots, not Monkbot18. I think a blank line within a cite template is always unnecessary, and uses up valuable space within the edit window, but if it bothers you that much, you can always ask Trappist nicely, and I'm sure he'll remove that tweak for you. --NSH001 (talk) 07:15, 8 March 2021 (UTC)

  In that case, Your Mileage May Vary, and STYLERET applies. The blank lines make it easier to pick out citations from text, and scroll bars overcome the "valuable space" argument. I tried to ask that behaviour to be removed. I was met with (*paraphrased) "bot code was approved, proceeding". So I just blocked the damn bot from the 300 articles I work on. Now if someone is that concerned about a hyphen in a parameter, they can go manually change it. Simple as that.

  Or, you know, the bot could stick to making the changes to parameters that it is supposed to. I shouldn't need to ask, it's not part of the bot's mandate, remove it. - Floydian ^τ _¢ 15:43, 8 March 2021 (UTC)

  First, you say I tried to ask that behaviour to be removed. I was met with (*paraphrased) "bot code was approved, proceeding". That is surprising, as I would expect Trappist to be amenable to such a request (it's important to get this job done, so a small change like this one to avoid pushback is worth making). Can you point me to the conversation where you made this request, and received that reply, please?

  (later) - ah, don't bother – found it myself User talk:Trappist the monk/Archive 17#Task 18 taking out reference spacing. Looks like you didn't explain yourself very well to Trappist. FWIW, I can see the rationale for the blank line for in-line cites within the article body, if it stops people from turning it into the (horrible) horizontal format. I touch on this again below, but I agree with you that Monkbot18 shouldn't be removing the blank line. (I hope Trappist is reading this). But the rest of the changes it's making are good, and should stay.(Actually, to be strictly correct, Monkbot should remove it within LDR or biblio listings, but not within the main body. For simplicity, I'd say simply don't bother trying to remove it.)

  Secondly, Or, you know, the bot could stick to making the changes to parameters that it is supposed to. That statement is false. The bot was approved to carry out the tasks listed at the link I've already given: User:Monkbot/task_18: cosmetic cs1 template cleanup, and that's exactly what the bot has been doing. Apart from the blank line issue, the other changes are good, and valuable, and will reduce the need for more bot runs in the future. One of the reasons I like this bot so much.

  The next bit is very interesting (to me) but is wandering mostly off-topic, so I'm putting it in small text. If you'd like to take it further, feel free to discuss it on my talk page. The problem of citation clutter in the main body of Wikipedia articles has been annoying me for years, and especially the huge problems caused by long, horizontally-formatted citation templates, which in my opinion make wikitext difficult or impossible to read and to edit. This is all set out on a very long "thread" (it isn't really a thread any longer): on my talk page. It is talking about a way of setting out citation templates that I call "ETVP" for "easy to visually parse", which is similar in many ways to the citations in your example, but also differs in some respects. The interesting point to mention here is that I had a difficult and bruising experience trying to introduce ETVP-formatted citations into article bodies. The excuse offered for reverting me was mostly "it takes up too many lines" in the edit box (hence "the one very reasoable exception" above), so in the end I gave up on that, and focused mainly on other solutions (ETVP within WP:LDR or ETVP within biblio listings using short-form referencing) which in most cases are actually a better solution anyway. It's a fascinating paradox that you seem to have gotten away with it by using more lines, not fewer, combined with a lavish use of white space – the exact opposite of what one would expect. So I am now thinking of adding a similar option to my ETVP script – and thank you for prompting that thought. Will need some thought, though.

  --NSH001 (talk) 10:02, 9 March 2021 (UTC)

  The blank lines is the only issue I'm having / pointing out here. I have no problem with updating deprecated parameters, I have no problem with my watchlist having a litany of bot edits. I do have a problem with going through 250 articles that have an average of 50 citations, to reinsert a blank line in each. This is not one of the 6 tasks listed at User:Monkbot/task_18: cosmetic cs1 template cleanup.
  There are also some automated tools that do similar nonsense that I revert on sight (e.g. Regex Citation Formatter). - Floydian ^τ _¢ 15:49, 10 March 2021 (UTC)

  We appear to be in agreement here, specifically that you support option A, but only if Monkbot 18 drops its removal of entirely blank lines within citation templates. If you could confirm that my understanding is correct, that would be very helpful. Thanks. --NSH001 (talk) 10:00, 11 March 2021 (UTC)

  You would be correct good sir! - Floydian ^τ _¢ 15:36, 11 March 2021 (UTC)

Worth noting

Trappist has kindly set out, very clearly, a suggestion on how to configure your watchlist to avoid the problems of large numbers of bot edits in watchlists. I copy it here, in case it is helpful to anybody:

• at Special:Preferences#mw-prefsection-watchlist:
  • check Advanced options → Expand watchlist to show all changes, not just the most recent
  • check Changes shown → Hide bot edits from the watchlist
• at Special:Preferences#mw-prefsection-rc:
  • check Advanced options → Group changes by page in recent changes and watchlist

Note that I haven't (yet) tried this myself, since I'm already satisfied with the way my watchlist is set up. --NSH001 (talk) 09:09, 8 March 2021 (UTC)

Note to RFC closer: the above instructions are a remedy for all of the people supporting Option C because of "watchlist clogging" and the alleged problems that the bot's edits cause for editors who watch for vandalism. As far as I can tell, no editor using the above settings is objecting to the bot's changes based on watchlist issues. Unless a valid objection is raised, I propose that all Option C support citing watchlist problems be discounted and guided to the above recommendation. – Jonesey95 (talk) 17:30, 8 March 2021 (UTC)

This is a workaround that (a) should not be necessary, (b) doesn't work for everybody, e.g. those who want to see bot edits (I do for example) and (c) doesn't fix the problem only a symptom. It is additionally highly inappropriate to suggest that large numbers of editor's valid and rationally expressed preferences are discounted. Thryduulf (talk) 17:41, 8 March 2021 (UTC)

I've been trialing this workaround for the last day or so. Back in December I cleared out my watchlist and took a two and half month wikibreak while the bot ran. I've just come back to Wiki and discovered that the bot has been stopped, but thought I'd try Trappist's suggestion. So far so good, it's a bit different but at least it makes the watchlist saner than during the bot attack! Martin of Sheffield (talk) 20:23, 8 March 2021 (UTC)

I've always been puzzled that (some) editors get so triggered by large numbers of bot edits. I have more than 6,000 pages on my watchlist (which I have set to show bot edits), and bot spam has never bothered me. I even welcome it, as they sometimes remind me of articles I did a lot of work on perhaps 7 or 10 years ago, and which I really ought to look at again. That said, I do understand the problems of editors who want to deal with vandalism, so this new setting looks to be very valuable, and should indeed remove many (but probably not all) of the "watchlist spam" objections. --NSH001 (talk) 10:40, 9 March 2021 (UTC)

And on the subject of editors like me who aren't bothered by bot spam, has anyone considered the silent majority who either aren't bothered by the "spam" or who, if they are, aren't concerned enough to come to this RfC to complain about it? Perhaps they ought to be weighed somehow in the balance when considering "consensus"? --NSH001 (talk) 10:51, 9 March 2021 (UTC)

Well given that most of them will not know that this discussion exists and will just be getting on with adding the parameters, with and without hyphens, as they always have done I don't think was can say one way or the other what their opinion is - especially given that the bot has not been spamming its unnecessary changes for quite a while now (the discussion has been open a month tomorrow, and I think it was stopped a day or so before then, and more than a few editors are of the opinion that arguing against bots/bot operators is pointless). Instead of grasping at straws to discredit or dismiss the opinions you disagree with, perhaps you could instead try listening to why they disagree with the changes, not just the manner of the changes. I also note that you have completely ignored my explanation of why this will not actually solve the problem for everybody and ignored that there is no reason why the problem should need to be solved in the first place. Thryduulf (talk) 11:49, 9 March 2021 (UTC)

None of this changes the fact that there is no consensus to depreciate non-hyphenated parameters, nor has any such consensus ever existed. Rather than trying to convince the RFC closer, you should be planning how you're going to get that consensus, if you intend to keep doubling down on that. --Aquillion (talk) 10:35, 16 March 2021 (UTC)

• Comment It's easier for authors if every possible format is accommodated, and recognized as a synonym. There's no reason to delete any unless they;re actually confusing. DGG ( talk ) 05:59, 21 March 2021 (UTC)
• Option A, then B, Strongly Oppose C. Citations should be standardized across the encyclopedia. Having a bot do these automated tasks does not spam watch lists, and if that was a concern then the solution is to ignore bots from watch lists, instead of stopping encyclopedia improving projects too many people are saying " watch list ".JackFromReedsburg (talk | contribs) 18:36, 5 April 2021 (UTC)

  Why should citation parameter names be standardised? How does it improve the encyclopaedia? Why is your opinion that the many bot edits are "not spam" more valid than the experiences of those who have explained why they experience them that way? What is your response to those who have explained that they do not support these changes for reasons other than watchlist spam and/or have reasons why they do not want to ignore all bot edits? Thryduulf (talk) 19:50, 5 April 2021 (UTC)

• There seem to be many people responding to the "spamming watchlists" aspect of this. That is certainly not my objection. The problem is that we have lots of editors who for over a decade have been using the non-hyphenated parameters but if this is deprecated will get an error message when doing so. Everyone would say on seeing that that they know what they meant, so why on Earth remove the functionality that deals with the situation automatically? People are proposing very complicated artificial intelligence techniques in other areas, but are resisting synonyms for parameters that were considered simple even in the early days of computing. Phil Bridger (talk) 19:26, 5 April 2021 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

MJL's close

Closure review

NOTE: the closure of this RfC is now under discussion at WP:AN#Closure review request for "Citation Style 1 parameter naming convention" RfC. Fram (talk) 09:44, 8 April 2021 (UTC)

• I undid MJL's close based on the discussion above. It is preserved for the record in the section above. – Joe (talk) 11:02, 14 April 2021 (UTC)
  • While MJL's RFC closure was fearless and difficult, it was unclear in its prose and left a number of implementation-related questions unanswered. I was involved with the RFC and with the implementation of its first closure, so I asked a number of those questions. I am willing to assist a potential closer with drafting a closure, not to put my spin on it, but to ensure that it answers questions that might arise from it and contains grammatical prose. Feel free to ping me. – Jonesey95 (talk) 20:34, 14 April 2021 (UTC)
    • It is a very bad idea to get someone who was seriously involved in the RfC to "assist a potential close", and I hope no one pings you over this. The closure has not been overturned because of unclear or ungrammatical prose, suggesting this already disqualifies you from having any involvement with a new close. If the closers have questions, they can post them here, for everyone, without pings to one party or another. Please don't try to unduly influence the outcome, and please stop replacing these parameters while the RfC is still open. Fram (talk) 07:32, 15 April 2021 (UTC)

What should the thanks confirmation be like?

What should the message and interface that pop up when you click "thank" on a diff or history be like? On the talk page of Help:Notifications/Thanks, it was suggested that rewording the message and adding a link to the help page would make it less confusing. So we have:

• Status quo: Publicly send thanks?  Thank Cancel
• Option A: Send thanks?  Thank Cancel Help
• Option B: Send thanks (help)?  Thank Cancel

See here for the preliminary discussion (whose participants I'll notify). Note this has no binding force and there's no guarantee the result will be acted upon; it's just an informal poll to see if a change is due. Nardog (talk) 07:53, 21 March 2021 (UTC)

• A or B, preferably A. While it is the case that the thanks are logged, the word "publicly" is highly misleading since only who thanked whom when, not even for which edit or on which page, is public, and only if one goes to Special:Log, which no casual user would even know the existence of. The following from the discussion illustrate the demand for the change. Diegodlh said:

  It wasn't clear to me whether my thanks had been sent already and if it was asking me if I wanted to publicly thank the editor on top of that, or if publicly thanking was the only way to go.

  Pdebee said:

  A few years ago, a new joiner wanted to thank me for my initial help with her first steps as an editor, but changed her mind because she thought that “publicly” meant that tens of millions of other registered editors were going to see what she’d hoped would be a simple, private signal of personal appreciation.

  Removing "publicly" will eradicate such confusion, and adding the help link will help newcomers know what the function does and hesitate less to use it, which will lead to increased editor retention if these studies are to be believed. Nardog (talk) 07:53, 21 March 2021 (UTC)
• Support change, preferably A - I’ve always thought the ‘publicly’ wording doesn’t really match up with reality. ƒirefly ( t · c ) 08:20, 21 March 2021 (UTC)
• Support change, preferably A - Thank you for considering this effort; if implemented, your solution should prove less confusing. Patrick. ツ Pdebee.^{(talk)(become old-fashioned!)} 10:45, 21 March 2021 (UTC)
• Comment: First off, I would have preferred the three given options to be given similar labels, i.e. Options A, B, and C instead of the cumbersome "Status Quo", making A and B more attractive simply to type. Secondly, the help page is considerably improved since the original discussion back in 2019 (if I may say so myself). The original discussion hones in on the word "publicly" and what that means. Go read the help page, I hope you will find it much more instructive than back in the day. Finally, here are the relevant issues I raised in the original discussion that never got addressed really: a) "Thank" and Cancel" should be buttons not links - they execute commands, they don't take you to new pages. This would make it easier to distinguish a help link. b) the help page is for the entire Thanks fuction, not merely to answer questions on "publicly" which suggests Option B as the more logical placement. c) As I understand PrimeHunter's argument (in the earlier discussion) option A requires developer intervention while option B can be done by only tweaking system messages. d) the degree of "publicness" of your given thanks is debatable - see the earlier discussion. Just so we make a change for the right reasons. CapnZapp (talk) 10:56, 21 March 2021 (UTC)

  To that end, here's an alternate poll:

  • Option A: Publicly send thanks?  Thank Cancel
  • Option B: Send thanks?  Thank Cancel Help
  • Option C: Send thanks (help)?  Thank Cancel
  • Option D: Send thanks (help)?  Thank Cancel

  CapnZapp (talk) 11:01, 21 March 2021 (UTC)

  You're throwing a monkey wrench in the middle of this discussion. Overriding the options when others have already participated will all but confuse people, and Option D isn't even comparable to the others! We can call the status quo "Option 0" if we want, and I don't mind you or anyone adding to the options (as long as it's a change on the equal level). Nardog (talk) 11:19, 21 March 2021 (UTC)

  I brought up the button/link issue in the 2019 discussion. Don't dismiss my reminder as if I had a chance to give my input any sooner, but blew it. (If you feel there is a better place where I should have brought up this directly-relevant-to-the-topic issue, you will have to tell me where) CapnZapp (talk) 14:49, 21 March 2021 (UTC)

  while option B can be done by only tweaking system messages That turned out not to be the case. See Xaosflux's comments. Both A and B require "developer intervention" (though B is easier).

  Okay, thanks. CapnZapp (talk) 14:50, 21 March 2021 (UTC)

  the help page is for the entire Thanks fuction, not merely to answer questions on "publicly" which suggests Option B as the more logical placement I don't follow this argument. What part of Option A suggests it's "merely to answer questions on 'publicly'" (when the word does not even appear in it)?

  buttons not links That would require even more of a drastic change than Option A. For now let's focus on what is within our reach (which both A and B are). You can request that change separately.

  the degree of "publicness" of your given thanks is debatable Um... so? Are you disputing my characterization ("only who thanked whom when, not even for which edit or on which page, is public")? Nardog (talk) 11:08, 21 March 2021 (UTC)

• See technical notes at phab:T229168 for software changes that would be required upstream. — xaosflux ^Talk 12:25, 21 March 2021 (UTC)
  • @Xaosflux: isn't option B already possible? Can't we just create MediaWiki:thanks-confirmation2 with the content "Publicly {{GENDER:$1|send}} thanks? ([[Help:Notifications/Thanks|help]]) " ProcrastinatingReader (talk) 12:41, 21 March 2021 (UTC)
    • @ProcrastinatingReader: no, as the interface message does not support links (see the example here on testwiki). Enabling this would require a software change, I think this discussion is to help gather support to lobby for such change to be enabled. — xaosflux ^Talk 12:54, 21 March 2021 (UTC)
      • Oh I see. Indeed, that’s a problem. Shouldn’t the function that renders messages parse wikitext? For example in the FlaggedRevs page the standard msg functions are used and that template has wikitext working. Looking at the source for thanks, the message is rendered using JS (using mw.msg) ([21]). Presumably this function doesn’t support wikitext? Is there an alternate JS function that does? ProcrastinatingReader (talk) 13:16, 21 March 2021 (UTC)
      • Did some digging. See here. If mw.message().parse is used instead, it should parse the wikitext, right? So should be a quick change? ProcrastinatingReader (talk) 13:20, 21 March 2021 (UTC)
        • No, this also needs to change. I'm realizing Option A might actually be easier. Either way it's going to involve a change to jquery.confirmable.js. .parse() could raise XSS concerns, so it can be tricky. Nardog (talk) 13:23, 21 March 2021 (UTC)
          • Still, a minor change there. What XSS concerns? ProcrastinatingReader (talk) 14:02, 21 March 2021 (UTC)
• Prefer Option B. The interface usually has (help) in brackets after the text, before the action, I think. For example the editnotice here about pending changes. ProcrastinatingReader (talk) 12:33, 21 March 2021 (UTC)
• Status quo. It's important to note that thanks are public, not private (anyone can look at the thanks log), and it's good to keep consistency with other wikis (Wikidata, Commons, etc.). Having the help link always visible isn't particularly helpful, it's one more link to mis-click on, and if you don't know what 'thanks' is then you can easily find out (just google 'wiki thanks'). Thanks. Mike Peel (talk) 14:26, 21 March 2021 (UTC)

  @Mike Peel: The proposal will require a software change, so it will be "consistent with other wikis", with the link by default pointing to mw:Special:MyLanguage/Help:Notifications/Thanks (cf. the " Help" links seen in many parts of MW). Nardog (talk) 14:31, 21 March 2021 (UTC)

  @Nardog: So this should be a cross-wiki proposal, perhaps on meta, or the output is a suggestion to the developers? Enwp can't decide on its own to change MediaWiki's default config. Thanks. Mike Peel (talk) 14:45, 21 March 2021 (UTC)

  Yeah, the latter. As I said at the beginning, this is just to get a grasp of how many people would think it's an improvement. phab:T229168 has already been marked as "patch welcome", but I fear they wouldn't accept my patch right off if there wasn't "any research saying this will be a positive improvement", as they put it. Nardog (talk) 14:52, 21 March 2021 (UTC)

• comment I think requiring a confirmation at all is unnecessary. "Thank" should be a one-and-done click. Schazjmd (talk) 16:10, 21 March 2021 (UTC)
• As I recall, several people expressed concerns about warning users that thanks were publicly logged. Thus at present I support keeping the current message, and adding a help link to explain the thank you notification mechanism. isaacl (talk) 16:27, 21 March 2021 (UTC)
• Support change, preferably B—the information about it being public is unnecessary and confusing, especially considering that almost everything is public on Wikipedia. When I was just starting on WP, I didn't thank people for a while, because I assumed the weirdly phrased/ambiguous "Publicly send thanks" would be an automated talk page post or something. Aza24 (talk) 17:58, 21 March 2021 (UTC)
• Status quo regarding the word 'publicly', per Isaacl et al. No comment on the rest. --Izno (talk) 18:11, 21 March 2021 (UTC)
• Status quo Really? This is even worth discussing? GenQuest ^"scribble" 18:53, 21 March 2021 (UTC)

  Quite. The "thanks" feature is simply a frippery to make us look like a social media site, not anything that should exercise our brain cells, which should be used to improve the encyclopedia. Phil Bridger (talk) 19:15, 21 March 2021 (UTC)

• Status quo Total non-issue. ~ HAL333 02:30, 22 March 2021 (UTC)
• Status quo I'd support option A or B but the help link is unnecessary imo. Just "Send thanks? Thank Cancel" would be fine. Elli (talk | contribs) 05:35, 22 March 2021 (UTC)
• Support change, preferably B I have always thought this was confusing. You get there by clicking on "thank", and then you are asked if you want to "Publicly send thanks" sort of implying there is a private alternative. I'd even be OK with no confirmation on this one at all. MB 18:54, 22 March 2021 (UTC)
• Status quo. The wording was changed for a reason. I sent an entire years worth of thanks into the bit bucket because the old query (which is closer to A/B above) made it sound like "you're sending thanks, do you want it to be public or private?" I of course just wanted the person I was thanking to be thanked, so clicked on the private option, which was really the "discard sending thanks at all" option. It's important to make clear that thanks are public, and there's no other option, so the status quo wording is fine. SnowFire (talk) 21:11, 25 March 2021 (UTC)
• Status quo, plus the "Help" link from option A. "Publicly" is there for a reason; people need to understand that they are not engaging in private communication. However, a link to the Help page about this function cannot possibly be a bad idea.  — SMcCandlish ☏ ¢ 😼  05:45, 3 April 2021 (UTC)
• Status quo. People should know that the thank actions are publicly recorded and the log can be viewed by anyone. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:34, 5 April 2021 (UTC)
• Option B. It is the most superior option.
  In all seriousness, the link would probably be helpful. Second choice is status quo. –MJL ‐Talk‐^☖ 04:57, 8 April 2021 (UTC)
• Status quo: the fact that it's not obviously public is more reason to highlight this fact. If you thank somebody then someone can often work out for what edit based on the context of the date. Not my favourite technical process but there are cases where you might feel uncomfortable publicly endorsing a statement, and you need to know that "thanks" is not the private thanks-for-writing-this you would otherwise assume it is. — Bilorv (talk) 22:32, 11 April 2021 (UTC)
• Status quo, plus the "Help" link from option B. The fact that this is not publicly recorded is more reason to remind people that they are not engaging in private communication. The "Help" link also can't hurt. EpicPupper 16:32, 12 April 2021 (UTC)

RfC on limiting minor edits

Question: Should the minor edit functionality be limited to a group of users (such as autoconfirmed or extended-confirmed users)?

• Option 0 (status quo): Limit minor edits to registered users.
• Option A: Limit minor edits to autoconfirmed (or confirmed) users.
• Option B: Limit minor edits to extended-confirmed users. (No change to bots or admins which currently have this access)

This is a follow-up to this RfC on effectively disabling minor edits. As there was no consensus then, this is to establish clearer consensus regarding an alternative proposal. (This is my first time requesting comment, please let me know if I'm doing anything wrong.) Tol | Talk | Contribs (formerly Twassman) 00:02, 1 April 2021 (UTC)

Survey (minor edits)

• Question What about the Gordian-knot solution, just get rid of the concept of "minor edit" entirely? Was that considered? --Trovatore (talk) 00:23, 1 April 2021 (UTC)

  The aforementioned RfC demonstrates fairly clear opposition to removing minor edits entirely. — ⊥ɥǝ Ǝɐɹʍıƃ (ʇɐlʞ) 00:30, 1 April 2021 (UTC)

  Well, that one says something like "limit by policy to anti-vandalism reverts", which is not really a simplification and adds another layer of things people can and can't do. What I'm talking about is, the whole concept of "minor edit" goes away entirely; it's not that some people can do it and some people can't; it's not that there are rules about when you can do it; it's that it just doesn't exist, period. Even historical edits would no longer distinguish minor vs non-minor. Like it never existed at all. I would support that. --Trovatore (talk) 00:37, 1 April 2021 (UTC)

  You are right that the RfC was specifically about restricting minor edits rather than removing entirely, but what I meant is many of the arguments in opposition would apply just as well for a proposal to remove them entirely, so I don't see that reaching consensus. — ⊥ɥǝ Ǝɐɹʍıƃ (ʇɐlʞ) 00:45, 1 April 2021 (UTC)

  The !voters may not have taken into consideration the advantage of a genuine simplification, for once, given that none was offered. --Trovatore (talk) 00:47, 1 April 2021 (UTC)

  Given that the title was to "Disable minor edits" I doubt this. Tol | Talk | Contribs (formerly Twassman) 01:03, 1 April 2021 (UTC)

• Support B, then A. As I said in the other RFC, currently it's about as useful as the evil bit. The point of the minor edit checkbox is to say "you can safely ignore this edit"; so long as vandals, spammers, and "what does this button do?" types can use it, "minor" edits still need to be reviewed. For new users, this will be one less thing to worry about, and one less thing to get yelled at for misusing. Suffusion of Yellow (talk) 00:34, 1 April 2021 (UTC)
  • Which strikes me as a good reason to remove the concept entirely, rather than to restrict who can use it. --Trovatore (talk) 00:42, 1 April 2021 (UTC)
    • Indeed, I would support that too. But in the other RFC there was significant opposition to this idea, so let's at least remove it for the users most likely to be spammers, vandals, or clueless. Suffusion of Yellow (talk) 00:49, 1 April 2021 (UTC)
      • Meh, can't get excited about that. If the concept is useless, remove it. If we're not going to remove it, then since I'm pretty much going to ignore it anyway, I don't really care who can use it. --Trovatore (talk) 00:52, 1 April 2021 (UTC)
• Support B, then A Johnbod (talk) 00:39, 1 April 2021 (UTC)
• Support A, Oppose B per my arguments in the previous RfC. I am not in favor of expanding the scope of EC if it means taking rights away from autoconfirmed users. The threshold for EC is too high for a feature as minor (no pun intended) as this one. — ⊥ɥǝ Ǝɐɹʍıƃ (ʇɐlʞ) 00:53, 1 April 2021 (UTC)
• Option A/B (as requester): minor edits are frequently abused or incorrectly used by new users, and this could limit this feature to users who can be better trusted not to misuse it. Tol | Talk | Contribs (formerly Twassman) 01:09, 1 April 2021 (UTC)
• Support 0, strong oppose B: I'm shocked to find out the VPR discussion, which I'd filed away mentally as "some weird discussion between people with outlier opinions that's probably fizzling out", made its way here, and I at first thought this was an April Fool's RfC that hadn't been tagged properly. I can grudgingly recognize an argument for autoconfirmed (selects away some-but-not-all of the people with actively negative amounts of clue) but overall think that an example of over-bureaucracy at the terror of Spammers And Vandals taking away a minor, useful, and mostly noncontentious function. Limiting it to extended confirmed is beyond parody -- do you know what 500 edits sounds like to someone who isn't Into Wikipedia? We use extended confirmed protection as a last resort for the most massively controversial and abused articles to make sure they're only edited by people who are in too deep to continue it. I do not see the point of restricting something to vested contributors (B) or the patient (A) that can very well be better explained with replacing "This is a [[subtle link|minor edit]]" with "This is a minor edit [[less subtle link|(when to check this box)]]". Vaticidalprophet 01:12, 1 April 2021 (UTC)

  Also, should this have a watchlist notification? Vaticidalprophet 01:15, 1 April 2021 (UTC)

  I'd see your point if it was a feature that had any direct benefit to the user. But (like autopatrolled) it can only benefit other people. How is the non-extendedconfirmed user harmed by the removal? Suffusion of Yellow (talk) 01:21, 1 April 2021 (UTC)

  Autopatrolled not benefitting the end user is something I've always found more said than true -- having pages indexed by Google (and by extension around the top of it for most subjects) is indeed a benefit for the page's writer, in that it means their work will be viewed. Similarly, I don't believe minor edits are useful only to other people in either the corest sense of "to the editor, directly, in a void" or the sense of "the editor as they actually are, interacting with other people" (e.g. it is quite meaningful well before the point someone hits extended-confirmed if they have 10% minor edits or 90%). Even in the one-man-is-an-island sense, being able to tag your own edits is helpful for personal categorization and tracking. I'd like to flip the position you're presenting here -- to limit minor edits, especially to limit them only to people with edit counts that sound absolutely insane to people who are not themselves prolific Wikipedia editors, would in my opinion require a far more serious abuse than I've seen either in practice or that you're proposing. "This should only be possible for 0.1375% of the people who have joined Wikipedia" is a proposal that shouldn't happen without major cause. Vaticidalprophet 01:30, 1 April 2021 (UTC)

• Support B/A Support B, but wouldn't mind A. There often are users(often newer) who use minor edit for things they think are minor changes but aren't Wikipedia minor edits. WikiVirusC(talk) 01:48, 1 April 2021 (UTC)
• Question: What if I don't want to limit minor edits at all? — JohnFromPinckney (talk) 01:50, 1 April 2021 (UTC)
  • Then you would say "Option 0" and set up your own proposal on such a topic, I would think. Aza24 (talk)
• Oppose B No real preference on A or 0. — UwU wug's this? 02:21, 1 April 2021 (UTC)
• Support B as first choice, A as second choice. Most uses of minor edits by new users are by newbies exploring Wikipedia for the first time, vandals, spammers and sockpuppets, making the concept useless with respect to non-autoconfirmed users. Since autoconfirmed is so easy to game and it is unlikely a new user will get the point by that point, we should restrict minor edits only to those who understand what they are, and what their purpose is. JavaHurricane 04:03, 1 April 2021 (UTC)

  Are "most" uses of minor edits malicious? Does it take a month and the 99.8625th percentile of edit count to learn something that can be learned by clicking the link piped from 'minor edit'? Are minor edits as massively contentious as articles about intense global political disputes, our primary use-case for limiting an action to the 99.8625th percentile of editors? Vaticidalprophet 06:47, 1 April 2021 (UTC)

  Having been doing RCP and counter-LTA activities for quite a while now, I daresay most uses of the minor mark are either malicious, or tests, or rollbacks of tests and vandalism. And yes, it took me that long to get fully the concept of minor edits. JavaHurricane 08:13, 1 April 2021 (UTC)

  If you work in the part of the project that deals with the worst edits, you'll pattern-match the worst edits to everything. This does not mean that the majority of minor edits are bad, it means the majority of minor edits you personally encounter are bad. I have not seen any argument in favour of making minor edits more restricted than actual rollback (any autoconfirmed user can install Twinkle), or indeed as restricted as it, that doesn't sound like either "then we should make the link to Help:Minor edits more obvious" or "then you shouldn't filter minor edits in your watchlist". (I personally pay attention to every diff for the watchlist articles I care most about, including Amantio running AWB over it, in case a poor edit is hidden behind them.) Vaticidalprophet 19:58, 1 April 2021 (UTC)

• Support B, then A per Suffusion of Yellow. ProcrastinatingReader (talk) 13:33, 1 April 2021 (UTC)
• Option 0. What problem is this even trying to solve? Thanks. Mike Peel (talk) 14:50, 1 April 2021 (UTC)
• Oppose B - Editors should become familiar with the edit summary system much before 500 edits. Anyone who is very concerned with missing something because it is marked minor can simply stop filtering those out of their watchlist. — Godsy ^(TALK_CONT) 15:08, 1 April 2021 (UTC)
• Procedural Oppose to B if that would remove this capability from admins or bots (@Tol: that isn't part of your intent here is it?). — xaosflux ^Talk 15:13, 1 April 2021 (UTC)

  @Xaosflux: No, I should have made this more clear. Option B would not remove this capability from admins or bots. I intended to mean removing minor edits from human users who have not been extended-confirmed (bots not being human and admins having been XC at some point). Tol | Talk | Contribs (formerly Twassman) 19:18, 1 April 2021 (UTC)

  Thanks, I noted it above and struck this !vote. — xaosflux ^Talk 23:09, 1 April 2021 (UTC)

• Support A or B I have also seen this feature misused by bad actors. The purpose of this feature is to allow minor edits by trusted editors to be less prominent on watchlists, not as a privilege to certain editors. As I see it, adding an activity requirement before it shows up would make this feature more useful to those who review changes. (t · c) buidhe 15:21, 1 April 2021 (UTC)
• Support something between B and A I was originally going to just support B but as stated above by Godsy, Wikipedia editors should become familiar with the edit summary before 500 edits.But becoming autoconfirmed (as far as I know, I'm not completely sure) is easy to do. However I completely oppose Option 0 because any user can register an account and then vandalize an article while marking it as minor. We need to take note that not all vandals are IP editors. So I think if we did something between A and B (maybe semi-autoconfirmed or possibly a separate thing entirely just for minor edits) then it would still make it harder for vandals to do what they do best while not making it too hard for good users to make minor edits. A Wild Wolf has appeared! | Gotta catch 'em all! (talk) 15:29, 1 April 2021 (UTC)
• Support B, then A I personally believe every user uses minor edits differently, but only with WP:ECP users, is there going to even be a discernible pattern. Non ECP users by definition will have fewer than 500 edits anyways Shushugah (talk) 15:41, 1 April 2021 (UTC)
• Support 0 - I vaguely recall participating in the previous RfC, but this is a case where what logically makes sense (either A or B) actually doesn't. One of the best RCP "tells" is mis-use of minor edits. It raises efficiency appreciably, and that alone makes me prefer to keep as-is. Nosebagbear (talk) 16:04, 1 April 2021 (UTC)
• Support 0 with A as a very distant second choice. Despite all the discussion here and in the previous discussion, I've never actually been convinced that there is a problem that needs fixing here or that the proposed changes would actually fix things. The issues people have are one of user behaviour and limiting use of the minor edit feature is not going to solve that. Thryduulf (talk) 16:25, 1 April 2021 (UTC)
• Support 0 As a sock and vandal detector, the minor edits checkbox is a fantastic honeypot. AdmiralEek (talk) 17:03, 1 April 2021 (UTC)
• Support A, second choice 0, weak oppose B. The designation is almost entirely uninformative for very new users. (Contrary to the "honeypot hypothesis", I think it's essentially uncorrelated with vandalism, not reliably anticorrelated to any degree to actually be useful.) Even for the more experienced, there are different standards of what constitutes a minor edit. But it's also basically harmless. Somewhere between 10 and 500 it starts to acquire a small amount of usefulness, but given the choice I'd rather it kick in sooner rather than later. As for the preference for 0 over B, if nothing else it gives IPs one more incentive to register. MarginalCost (talk) 17:21, 1 April 2021 (UTC)

  The correlation is likely not between "minor edit" and "vandalism" alone. The correlation is between "minor edit & large diff size" and "vandalism". ~ ToBeFree (talk) 17:32, 1 April 2021 (UTC)

• In all the years I have edited here, I do not recollect ever before having actually registered a comment in an RfC, only to say that I don't care. But I don't. If you don't want to take "you can safely ignore this edit" for granted, here's a very effective fix: don't. I can see requiring some additional experience before allowing it, but it won't really matter. --Tryptofish (talk) 19:19, 1 April 2021 (UTC)
• Option 0, if we're limited to the options above. I don't see the point in limiting who can use the minor edit checkbox, if the problem is how it's being used. I might consider supporting a proposal that would add a technical limit on how many characters/bytes could be changed and still have the edit marked minor, such that minor edits are effectively limited to spelling corrections in one or two words, or the addition/removal of 3-5 bits of punctuation, but that option is apparently not currently under consideration and I have no idea if it's technically feasible or not. ~ ONUnicorn^{(Talk|Contribs)}problem solving 19:29, 1 April 2021 (UTC)
• Support 0. The fact that almost anything can be abused by a small minority is not a good reason to ban this feature from the majority that use it responsively. Also, doing it would be counterproductive as Nosebagbear points out. – Finnusertop (talk ⋅ contribs) 19:59, 1 April 2021 (UTC)
• Support 0 - I edit in topics that are subject to frequent vandalism and POV editing... and often the vandals try to “hide” their edits by intentionally misusing the “minor edit” tag. Thus, when I see an edit flagged as a “minor edit” (in these topics), my reaction is the opposite of what is intended... I pay extra attention to the edit. I know this is not the purpose of the flag, but it actually HELPS me discover and correct vandal/POV edits... so I WANT the vandals and POV editors to keep misusing it. Blueboar (talk) 00:49, 2 April 2021 (UTC)
• Support 0 Anon editors are human as well. I don't see why they shouldn't get minor edits. If anything, removing them will almost certainlyy increase bad edits as they allow for small changes and removing that will have severe consequences on the editing process. Swordman97 talk to me 01:22, 2 April 2021 (UTC)

  First, anonymous (IP) editors already cannot use minor edits; this RfC is to discuss whether the bar should be moved up from registered accounts to autoconfirmed or extended-confirmed accounts. This does not remove their ability to make edits which are minor edits as defined in Help:Minor edit, it only removes their technical ability to mark the edits as such. It has absolutely no impact on what edits they can make. It may help other editors who ignore minor edits, as by preventing these new editors (who may not understand what a minor edit is) from making minor edits, all edits by these new editors will show up on watchlists. Tol | Talk | Contribs (formerly Twassman) 16:35, 2 April 2021 (UTC)

• Oppose B - While I support the idea of having to request a permission to make minor edits, extended-confirmed is not the right permission to bundle it with. Neutral between the status quo and auto-confirmed; certainly some minor edits by new users are vandalism or incorrectly tagged but it doesn't seem to be disproportionate. User:力 (power~enwiki, π, ν) 01:29, 2 April 2021 (UTC)
• Strong Support 0 Misusing makes it easier to detect vandals per Blueboar. It also makes it easier to detect sockpuppets, since their previous account(s) likely learned about minor edits. 🐔 Chicdat  ^{Bawk to me!} 10:32, 2 April 2021 (UTC)
• Comment I'm concerned that many editors appear to see the purpose of minor edits as a honeypot to trap editors. ProcrastinatingReader (talk) 12:35, 2 April 2021 (UTC)

  @ProcrastinatingReader:, would you care to elaborate? If you mean what I think you mean, nobody was talking about using minor edits to "trap" good-faith editors. For that matter, minor edits alone cannot trap anyone - they were saying as how minor edits assist them in spotting socks and vandals; but they aren't "busted" for using the minor edit feature, but for socking and vandalising. A good faith editor who is not socking or vandalling can't be wrongly accused of such just for using minor edits Firejuggler86 (talk) 22:02, 2 April 2021 (UTC)

• Option 0 with a strong oppose option B (or removal of minor edits altogether). Editors supporting restrictions don't seem to be balancing the odds right—at least, not if we take their comments at face value. The question at hand is: are sufficiently many minor edits made by non-autoconfirmed/non-EC (a) unconstructive and (b) not caught by standard anti-vandalism procedures (ClueBot, Huggle, watchlisting, RCP) that it is a net negative to the system? From my own experience, I don't see how this could possibly be the case. The vast majority of unconstructive edits are not marked as minor. The proportion of minor edits which are unconstructive is lower than the proportion of major edits. And I think it's clear that anything minor by a new user that says (+2,167) is still likely to be caught by our existing processes (I think users above are saying "m (+2,167)" makes them more likely to read the edit, and it does for me too). The only thing minor edits really do is help someone with a large watchlist find the most important changes first, and I don't think we're doing these people a favour.
  I am also concerned by the attitude people are showing behind the purpose of marking an edit as minor. I mark an edit as minor if and only if I think "I would be very surprised if an editor wanted to know that this edit had happened (because they might want to discuss it or have some improvement to make on what I've done)". If an editor is repeatedly marking contentious edits as minor then approach them in the first (and maybe second) instance and if they continue and do not reply constructively then report them, because such malicious actions are sanctionable.
  Literally my first registered edit was minor (marked as such and genuinely such). There's a button saying "This is a minor edit", with an uncontroversially clear meaning. It's not hard for a beginner to use it correctly. — Bilorv (talk) 13:18, 2 April 2021 (UTC)
• Support A Would ensure that editors understand its use. ~ HAL333 17:44, 2 April 2021 (UTC)
• Option 0 I don't get the point of this RfC; status quo is fine. TonyBallioni (talk) 20:32, 2 April 2021 (UTC)
• Minor edits are effectively worse than evil bits right now because they have an unclear meaning that's basically "hey you don't have to look at this edit"; this is a part of why I don't believe new editors don't use it (sort of vague meaning). At the same time though, restricting it to extended confirmed or autoconfirmed won't change that. Minor spelling and grammar corrections are often disputed as well as layout issues or whatever else; that's why the MOS pages/infoboxes are under discretionary sanctions and why there was endless discussions about the second Star Trek remake's capitalization. Minor edits should be replaced with a more robust tagging system to allow editors to self-tag edits as falling under different categories kind of like the common edit summaries tool. Right now minor edits are supposed to simply just mean "uncontroversial" but the subjects they're applied to can often be very controversial or need review. That or it's just used as a vandalism cover that doesn't work.

A system where editors could tag edits as being grammar/spelling correction, style/layout issues, rv vandalism, wikilinking things, or a few other topics would serve the dual purpose of being a more useful tag for filtering/sorting purposes (maybe you want to see corrections of factual errors but not grammar/spelling corrections on your watchlist) and assist new editors who don't really know how to use edit summaries or the existing system. Said system has a slim to none chance of actually being implemented though (too busy making margins bigger) so I have to go with Option 0 for now. Chess (talk) (please use {{reply to|Chess}} on reply) 01:56, 3 April 2021 (UTC)

• Option 0 per WP:BROKE. Strongly oppose Option B. There's virtually no evidence of disruption to demonstrate that limiting minor edits is actually necessary. This is a pointless proposal. OhKayeSierra (talk) 02:02, 3 April 2021 (UTC)
• Option A. Too often I see noobs misusing this (intentionally or not) to semi-hide edits which are quite substantive (and often unconstructive). And too many "brand new editors" are socks of banned users, or other unhelpful parties, so they should not be able to partially disguise what they are doing from the scrutiny of many longer-term editors. It does not hurt us in any way for a brand new legit editor, already unfamiliar with the existence of a "[ ] This is a minor edit" feature, which was not available to them as an anon, will still not have that option until after they've been around long enough that we don't think they're a sock or troll. There's just no down-side to this. However, I think option B is excessive. We don't need to wait that long to permit fairly basic functionality to be available.  — SMcCandlish ☏ ¢ 😼  05:39, 3 April 2021 (UTC)
• Option 0 or A From a new editor, it's a warning about half the time, based on the figures below. I and many of us actually use that waring. The change wouldn't remove disruption, but makes it harder to detect. I think it would be even more helpful to give unregistered editors the same ability; DGG ( talk ) 09:28, 3 April 2021 (UTC)
• Support 0, maybe A We're going to inevitably require registration for edits eventually, but I see no point of this current proposal. I can maybe see minor edits for confirmed, though, as that's not too onerous.  – John M Wolfson (talk • contribs) 14:15, 3 April 2021 (UTC)
• Support 0 Status quo: because, right now, the minor edit tick (when combined with a new account status), often acts like an indicator of vandalism and bears further scrutiny, especially when used on edits with the addition/removal of a whole paragraph, several sentences, or even several characters. GenQuest ^"scribble" 16:05, 3 April 2021 (UTC)
• O first choice, but if we're doing this A. Limiting it to autoconirmed users as we do with other abilities such as creating or moving pages isn't entirely unreasonable, limiting it to ECP users is a rather large overreaction. Slightly favor status quo per the comments about vandal detection. Beeblebrox (talk) 19:12, 3 April 2021 (UTC)
• Remove minor edits Honestly, what an editor considers a "minor" edit is based on perspective. A simple spelling change can meet opposition or what is deemed as a spelling correction could lead to a dispute. I've seen it happen before, disputes over trivial things such as spelling change marked as a minor edit. Just get rid of the whole "minor edit" system, even if it were used for a simple grammar correction. Filling out the edit summary will do just fine. If not that, at least have the "minor edit" system stop marking rollbacks and page moves as minor. Jerm (talk) 22:01, 3 April 2021 (UTC)
  • The problem there, as noted in the proposal, is that an RFC to basically do that failed less than two weeks ago with a strong consensus against it. Beeblebrox (talk) 22:05, 4 April 2021 (UTC)
• 0 It's confusing if the interface changes and we should avoid confusing new users. Andrew🐉(talk) 08:52, 4 April 2021 (UTC)
• B This make things simpler for new editors, the concept of minor edits can be introduced to them after they have made 500 edits. ϢereSpielChequers 09:09, 4 April 2021 (UTC)
• Option 0 This seems like pointless bureaucracy. Who cares about a quite literal minor flag on an edit? Leave it be and focus on the stuff that realistically matters. Remagoxer (talk) 12:31, 4 April 2021 (UTC)
• Option 0, plus new filters on the History panel of each page to filter out edits by extended-confirmed and/or autoconfirmed users. Those who want to only review edits by vandals, spammers, and "what does this button do?" types can do so. The current proposal of limiting minor edits does not help people who want to more effectively review problematic edits. feminist (talk) 05:24, 5 April 2021 (UTC)
• Option 0 per hardly-a-problem looking for a major solution; also per all the other Option 0ers, who each present cogent arguments. ——Serial 13:14, 5 April 2021 (UTC)
• Status Quo, Strongly oppose B. While it is true that there are lots of bad faith minor edits, lots of newer user also started up with minor edits. Not all people would be bold and change major things, some people started by minor edits such as fixing punctuation or capitalization, or adding minor facts, or doing minor rewording of sentences. If these new users are presented with "No you can't edit minor stuff because we don't trust you enough" it would be discouraging. Limiting minor edits to extended-autoconfirmed will be useless as vandals wouldn't care anyway. As someone who loves to revert vandalism (and made some bad calls too time to time) what stands out are the content of the vandalism, not whether it is minor edit or major edit. SunDawn (talk) 07:42, 6 April 2021 (UTC)

  How would making the "minor edit" checkbox vanish make users less likely to make edits such as fixing punctuation or capitalization? No one ever gets yelled at for failing to check that box when fixing a typo. Plus the newest users won't even know that it ever existed. The interface will just be a bit simpler. Suffusion of Yellow (talk) 16:56, 6 April 2021 (UTC)

• B 1st choice, A 2nd choice - This makes things simpler for new users (who will not have to worry about the minor flag), and simpler for experienced users (who will know the minor flag is only being used by experienced users). Levivich ^harass/_hound 03:20, 7 April 2021 (UTC)
• Option 0 Pointless. Why limit it to more experienced users if new users will probably not use it anyway? What is there to gain? There's no policy against making a minor edit not minor. ThePlatypusofDoom (talk) 13:49, 7 April 2021 (UTC)

  To me the answer to "why" is: so that I can filter out minor edits from my watchlist, and be confident that anyone using the minor flag is an experienced editor, and I'm not missing vandalism that is marked as minor by new vandalism-only accounts. Levivich ^harass/_hound 17:07, 7 April 2021 (UTC)

• Option 0, strong oppose B Minor edits, in my opinion, are an essential part of organizing edits. Also, there's no policy against making a minor edit not minor. EpicPupper 18:03, 7 April 2021 (UTC)
• Option 0. Recent change patrollers always look at every edit, minor or not, so it doesn't really help to hide anything. -- King of ♥ ♦ ♣ ♠ 03:15, 8 April 2021 (UTC)
• Option AB+ If this proposal actually passed, then I would filter out minor edits from my watchlist. The reason I don't already is because it feels like a lot of the time those edits are really some form of disruption or vandalism. –MJL ‐Talk‐^☖ 04:50, 8 April 2021 (UTC)
• Option 0. Solution looking for a problem. Stifle (talk) 10:06, 8 April 2021 (UTC)
• Support B, then A per numerous others. There needs to be a way to mark things that are truly inconsequential, such as fixing broken syntax in a call to a template or removing an extra period, etc. But there is no reason to allow it to be abused. Desertborn (talk) 17:42, 8 April 2021 (UTC)
• Support B first, then A. Should we be allowing brand new users a way to make an edit not appear on watchlists with one click? No... the "solution looking for a problem" group needs to get over themselves; obviously there is an apparent problem to some people, or B and A would have received no support at all. Aza24 (talk) 23:10, 11 April 2021 (UTC)
• 0 - I'm not clear what the problem is supposed to be. FOARP (talk) 20:22, 12 April 2021 (UTC)

Data on usage of minor edits

Quickly sorting through the past 100 minor edits to the mainspace by human editors of each of the following categories (specific revisions available here), I have some data. Note IP (unregistered) users cannot use minor edits. I am also erring on the side of assuming an edit to actually be minor.

• Registered but not autoconfirmed users: 42% actually minor (many were also vandalism)
• Autoconfirmed but not extended-confirmed users: 50% actually minor
• Extended-confirmed users: 82% actually minor

I had to remove ClueBot NG edits because apparently even the "Human (not bot)" checkbox doesn't exclude its edits. Tol | Talk | Contribs (formerly Twassman) 01:22, 2 April 2021 (UTC)

I think this is only half the story—where's the control sample? The information I think we need is how many minor edits in each of the categories are vandalism/bad faith/unconstructive and how many major edits in each of the categories are the same. For instance, based on what I see in my watchlist (obviously selectively biased) I would expect more than 58% of registered-and-non-autoconfirmed edits to need reverting wholesale, so that 58% of minor edits that need attention is not necessarily a flaw in the system. — Bilorv (talk) 13:18, 2 April 2021 (UTC)

Looking in each category on Recent Changes (new data), and highlighting edits tagged as reverted, 20% of minor edits by registered users were reverted, compared with 1% for autoconfirmed, and none for extended-confirmed. Tol | Talk | Contribs (formerly Twassman) 16:32, 2 April 2021 (UTC)

Option C

Pop-up notice

Part of the issue we have with minor edits is that our definition of minor is not intuitive, and this means that we have to assume that people misusing the box are doing so out of ignorance, which makes it very difficult to do enforcement. I propose that, should Option A or Option B be adopted, the first time an editor checks the minor edit box, a notice pop up with a brief definition of what we mean by "minor" (perhaps similar to the wording at {{uw-minor}}) that the editor would have to okay. This would ensure that everyone making a minor edit can be expected to understand what it means. {{u|Sdkb}} ^talk 16:00, 5 April 2021 (UTC)

• Support as proposer. {{u|Sdkb}} ^talk 16:00, 5 April 2021 (UTC)
• Sensible. Also works well with the options that don't make minor edit a possibility until you have been here a while. There is much to learn when you start to edit and a lot of sense in postponing some of that to make things simpler for new editors on their very first edits. ϢereSpielChequers 07:18, 8 April 2021 (UTC)
• Support. To be quite honest, it took me quite a while for me to figure out what constituted a minor edit back when I started, and I believe this would be useful. Sdrqaz (talk) 20:56, 9 April 2021 (UTC)

An extended comment/rebuttal to option 0

I, the proposer of this RFC, have seen rather many confusing option 0 responses; I will counter those here.

• Mike Peel, Thryduulf, TonyBallioni, OhKayeSierra, John M Wolfson, ThePlatypusofDoom, and Stifle say there is no obvious problem to be solved. The problem is that many edits marked as minor by new users are not actually minor. Therefore, the option to hide minor edits on watchlists is ineffective, as it may hide edits which are not actually minor. (I probably should have included this in the RFC itself.)
• Nosebagbear, CaptainEek, Blueboar, Chicdat, and GenQuest argue that a questionable edit marked as minor is an indicator to recent changes patrollers that the edit may be vandalism (a honeypot). That may be, but the whole point is that these edits are not actually minor. Recent changes patrollers will still check the edit, and this provides tangible benefits to people who use the watchlist and want to filter out minor edits. ProcrastinatingReader also noted this.
• Finnusertop and Bilorv believe that most new users use the feature correctly, so it would be unhelpful to remove it from all new users. A quick look at minor edits from new users shows otherwise, as I saw (see my #Data on usage of minor edits). This only removes the feature from new users, who are unlikely to use it correctly.
• Andrew Davidson says it would be confusing if the interface changes. I believe, if anything, it would be less confusing, as (for new users) there would no longer be a checkbox with a potentially unclear meaning.
• Swordman97 and SunDawn seem to think that this would ban new users from making edits which are minor. (Note the wording.) This does not propose that, rather, it proposes that new users cannot mark edits as minor. They can still make edits which fulfill the minor edit criteria, but they cannot tick the box which marks it as minor.
• EpicPupper says two things. First, he or she says that minor edits are an essential part of organizing edits. Sure, but they work poorly because they are frequently misused by new users. He or she also says that there's no policy against making a minor edit not minor. I assume this means making a minor edit, but not ticking the box. As far as I know, people do this all the time, and there is not much of an argument for making everyone tick the box when the edit is minor — all that will happen if one leaves it unticked is that it may show up on more watchlists.
• King of Hearts says that recent change patrollers always look at every edit, minor or not. That's not the point, the point is that people who use the watchlist may want to only look at edits which are not minor. This doesn't hurt recent changes patrollers, but it significantly helps those who wish to filter out minor edits from watchlists.

Tol | Talk | Contribs (formerly Twassman) 22:26, 11 April 2021 (UTC)

The problem is that many edits marked as minor by new users are not actually minor. I do not consider that a problem. TonyBallioni (talk) 22:28, 11 April 2021 (UTC)

@TonyBallioni: As I said, the watchlist function allows users to hide minor edits. With these edits, which are not minor but are marked as such, someone who hides minor edits on his or her watchlist will not see these edits even though he or she wants to. As most of these edits are by new users, I believe restricting the feature to more experienced users (who are more likely to use it correctly) is a good idea. Tol | Talk | Contribs (formerly Twassman) 22:33, 11 April 2021 (UTC)

And I disagree that what you are describing is actually problematic. Maybe it's because I've never hidden minor edits on my watchlist, but if someone makes the choice to hide them, that's on them. There's no reason to restrict it because of that. TonyBallioni (talk) 22:36, 11 April 2021 (UTC)

I agree completely with Tony. I don't know why people choose to hide minor edits on their watchlist (the only edits I hide are my own), but that's not the primary function of the flag. As has been said multiple times by multiple people, the solution to what you are seeing as a problem is to teach people how to correctly use the minor edit flag not to remove their ability to use it. Thryduulf (talk) 22:45, 11 April 2021 (UTC)

@Thryduulf: The reason to hide minor edits would be because one wants to see the substantive edits to the article but skip the minor ones. For teaching people: we do have {{Uw-minor}} for this purpose, and while I've tried to use it as much as possible, there isn't a "new users' minor edits patrol" akin to RCP to teach people about minor edits. I do agree that education on minor edits is definitely preferable to removing it from new users, but I'm not sure how to do that effectively. Now I have an idea for a bot, hmm... Tol | Talk | Contribs (formerly Twassman) 23:00, 11 April 2021 (UTC)

I agree with Tony and Thryduulf. Also, yes, you should have said this at the start of the RfC. Thanks. Mike Peel (talk) 07:22, 12 April 2021 (UTC)

• While it (to put it coarsely) sucks that many users abuse the "minor edit" functionality, and I wouldn't be opposed to removing it entirely (though nor would I entirely support it), I think it's hardly a reason to impose such an onerous restriction.  – John M Wolfson (talk • contribs) 22:30, 11 April 2021 (UTC)
• I didn't say that most new users use the feature correctly (name any step to editing and most new users do it wrong) and my argument doesn't rest on that fact. Your data remains lacking a control sample (what you replied to my comment with is not a control sample or the data that I said was missing). — Bilorv (talk) 22:37, 11 April 2021 (UTC)

  @Bilorv: Thanks for following up. The control sample would be made of a mixture of all three categories, and I didn't see much of a point in repeating the tedium of sorting edits a fourth time. From the data I already sampled:

  • Non-AC: 100 edits from 22:03 to 23:59 (1 hr 56 min), so ~0.864 minor edits per minute, weight 9%
  • AC non-XC: 100 edits from 23:26 to 00:27 (1 hr 1 min), so ~1.64 minor edits per minute, weight 17%
  • XC: 100 edits from 00:45 to 00:59 (14 min), so ~7.14 minor edits per minute, weight 74%

  From this, it is evident that extended-confirmed users make many more minor edits than other groups (around three quarters of minor edits). Weighting the samples with minor edits per minute, the reconstituted "control"-ish sample gets ~73% of total edits are actually minor. Tol | Talk | Contribs (formerly Twassman) 22:54, 11 April 2021 (UTC)

  Read what I wrote again. The control sample for the factor that is relevant to the argument I make is the proportion of non-minor edits which are reverted per group (which can be compared to the 20%/1%/0% data you give). This still assumes that "reverted" is synonymous to "unconstructive", but I presume you aren't willing to read through 600 edits and assess whether they're constructive or not manually. — Bilorv (talk) 23:02, 11 April 2021 (UTC)

  Ahh, thanks for the clarification. Based on new RC data, 11% non-AC, 3% AC non-XC, 0% XC (percent of non-minor edits reverted). This indicates that for non-AC, the minor edit may be a flag or honeypot, but for autoconfirmed users minor edits are more likely to be constructive. Tol | Talk | Contribs (formerly Twassman) 23:09, 11 April 2021 (UTC)

  Your rebuttal to both my and TB's group don't really seem to be convincing to me. Recent Changes Patrollers don't check every edit (if they did, we'd never find vandalism more than 10 minutes old!), prioritisation is key. Nosebagbear (talk) 23:19, 11 April 2021 (UTC)

  @Nosebagbear: Thanks for the reply. I do not think the removal of minor edits from new users will have much impact on recent changes patrol. I certainly take into account a minor edit flag in RCP, but only when it's combined with something else (such as a large byte change size or a questionable or missing edit summary). I believe that the amount of vandalism that would not be reviewed without a minor flag is inconsequential. Tol | Talk | Contribs (formerly Twassman) 23:27, 11 April 2021 (UTC)

  Well, here's the thing: A user can choose whether or not to hide minor edits on his or her watchlist. I myself never hid minor edits, not to detect vandalism, but because I wanted to see all the edits made to that article on my watchlist. 🐔 Chicdat  ^{Bawk to me!} 10:12, 12 April 2021 (UTC)

• The thing is, a lot of users just aren't getting the point. If we pop up a notice saying, "Are you sure you want to mark this edit as minor? A minor edit is..." then the maliciously intending editors will just skip the notice and mark their edit as minor. If we limit it to autoconfirmed or extended confirmed, then the maliciously intending editors will just make the necessary amount of edits and time, and then go on a disruptive "minor" spree. If we limit the character change of minor edits, then the maliciously intending editors will just change all the 4 letter words on the page to "****" and/or change the 5 letter words on the page to "penis". If, on the other hand, we block the maliciously intending editors before they can go on a disruptive "minor" spree, and keep the status quo, then the maliciously intending editors will never get to edit. Period. 🐔 Chicdat  ^{Bawk to me!} 10:12, 12 April 2021 (UTC)

Question to the community: Should Arbcom members be restricted from discussing active cases and participants on forums outside Wikipedia?

Redesigning the featured, good, and article assessment icons

• Current good article icon

• Current featured content icon

This proposal seeks to establish consensus for new icons that appear in the upper right corner of good articles (GAs) and featured content (FC) pages to mark their status, as well as the variant icons of these (candidate, former featured/good, former candidate). For the sake of consistency, it also proposes new assessment (A-B-C-Start-Stub-List-Disambig) icons.

Background: There was recently a Village Pump proposal (here) discussing whether or not to change the FA and GA icons. Main issues brought up were the overly detailed FC icon, which causes it to render poorly as small sizes, as well as the confusing GA icon, as it also is used as a "support vote" icon. In short, Support for the proposal outnumbered opposition, 2-to-1. As such, I have created new icons that I believe alleviate these issues. I've made quite a few variants of these icons, a large number of them that can be found here: File:FA-GA icon proposal.png, but for the sake of streamlining this process, I have chosen what I believe to be the most clear and intuitive ones in the proposal. As opinions come in, we can make new proposal sets of icons.

Proposal 1

• New icons, Proposal 1

• Side-by-side with old. Note that the default size of the image is such that the individual icons are 45px wide, which is around the size they would be rendered in talk pages.

Key points:

• FC icons simplified, with GA icons matching the format of FC.
• GA icons changed to silver, as it is a very natural was to color these.
• FC/GA former icons have dashed outline of a star, representing that they once held that distinction.
• FC/GA candidate and reassessment are represented by the same icon, as they both serve the same purpose – assessing whether or not they should be classified as FC/GA.
• FC/GA former candidates have an "x" representing that there were items not satisfied in the FC/GA criteria.
• Start and Stub class articles get new icons.

Support (article icons)

• Support – As proposer. These icons are simple enough that they will render well as small scales, the new color and matching format for GA makes it clear and obvious that they are related, while FC is clearly a higher distinction, and the new icons have intuition behind them as to what they mean. Pbrks (talk) 21:02, 2 April 2021 (UTC)
• Support with the following reservations I highly doubt that non-editors will know what any of this means, nor necessarily should they. In any event, the interwiki list has (I think) silver for a good article in another language (see James Thompson (surveyor)) and gold for a featured article in another language (see World War II for several examples of this). I think the colors should be brought to those respective standards if not already done so. The former article/former candidate, etc., stuff doesn't belong as a topicon and should instead go to the talkpage, IMO.  – John M Wolfson (talk • contribs) 21:16, 2 April 2021 (UTC)
  • I don't see anywhere suggesting that the former stuff would now be put on the article page (that would almost certainly require its own, separate proposal), I would assume their replacement is with their respective icons on the talk page. Aza24 (talk) 21:22, 2 April 2021 (UTC)
  • The former, candidate, etc. are only seen on on talk pages. You will only see the "Promoted" icons at the top right of the page. Pbrks (talk) 22:13, 2 April 2021 (UTC)
• Support in principle Repeating my earlier comment: The icons should be changed to something the average reader is familiar with. The current icons are nice, but they're nice to Wikipedians. The average reader probably has no idea what this means. We should aim to use images which readers will understand. For example: silver star, gold star. A tick / double tick. Or something along those lines. It should be obvious to a reader what it symbolises. I'm not so sure about this specific set, though. ProcrastinatingReader (talk) 14:04, 3 April 2021 (UTC)
• Support per Pbrks and Ivanvector (in the section below). The current icons are terrible at the size they're normally displayed. --Ahecht (TALKPAGE) 03:13, 12 April 2021 (UTC)
• Support per above. EpicPupper 21:38, 12 April 2021 (UTC)
• Support As per above and I prefer uniformity.  Saha ❯❯❯ Stay safe  08:41, 14 April 2021 (UTC)

Oppose (article icons)

• Where exactly is the need to replace the current icons with some hideous Web Whatever.0 design? How have I been running into so many "well, everyone in the tiny discussion on VPR supported it" lately? Why did we have a watchlist notice for the worst, most heat-over-light RfC I've seen in my life and yet no watchlist notices for "people want to restrict minor edits to the 99.8625th percentile of editors" or "people have decided the current quality icons are bad for some unclear reason" that have impact on actually writing an encyclopedia? How many of the thirteen people in the prior discussion are highly involved in the article quality process? Vaticidalprophet 22:27, 2 April 2021 (UTC)

  @Vaticidalprophet: The prior discussion was widely advertised everywhere of relevance short of CENT (including at the article quality forums). I sympathize with the feeling of coming across a discussion I would've wanted to participate in after it's closed, but the rationale behind changing the icons was thoroughly discussed and won clear support, and the process at this point has moved to the next stage. This thread is seeking to figure out how to change the icons, not if we should change them. Let's please not relitigate settled terrain; the whole point of the prior discussion was to resolve that part. {{u|Sdkb}} ^talk 23:04, 2 April 2021 (UTC)

  The reaction thus far to this proposal does not sound like "whether to change the icons or not was uncontroversially litigated and everyone who might possibly have been interested decided there was a problem". (There are quite a few prominently missing names in that conversation -- pinging @SandyGeorgia, Ealdgyth, Gog the Mild, Wehwalt, Ian Rose, Casliber, The Rambling Man, Epicgenius, Vami IV, Lee Vilenski, JPxG, Johnbod, and Serial Number 54129 as a small selection of people I might expect to have opinions, and I'm probably missing tons of names.) Vaticidalprophet 23:12, 2 April 2021 (UTC)

  Never saw the discussion, and don’t see it as having any kind of broad consensus now that I have seen it. People, if you want to keep messing with content review processes at least notify them. This is make work. So while I’m here, Oppose the notion that any change is needed or helpful. SandyGeorgia (Talk) 23:38, 2 April 2021 (UTC)

  Nor did I, and mildly alarmed to find myself on the "selection of people I might expect to have opinions"! I seem to have arrived here just in time to see the stern of the ship sinking below the waves, so I'll just say that on a quick look the proposal seemed uncompelling. As Martin Poulter says below, the main problem with our icons is that most readers don't know we have them, nor understand them. Can't see this changing that. Johnbod (talk) 03:05, 3 April 2021 (UTC)

• With respect, this seems like a solution in search of a problem. Insofar as, right now, readers see the gold star or the green icon in the top right of an article and know that means the article has been through some kind of peer review (which, anecdotally, I know is a benchmark many non-Wikipedia users use, for better or worse, to assess the veracity of an article), why we would want to change that for the sake of our own design preferences is beyond me. Minor cosmetic changes that keep the basic gold star and green icon for the FA/GA classes are fine, but I strongly oppose changing the green icon to something that is a completely different color. Go Phightins! 22:34, 2 April 2021 (UTC)
• As well as thinking these changes are unnecessary, I view the symbols as being no more clear than the current ones, and in the case of the good articles, significantly less clear, as well as visualy unappealing. Nosebagbear (talk) 22:48, 2 April 2021 (UTC)
• I don't think that the A–Disambig icons need to be changed. Just going to point out that with the change to flat, what about the other 10 icons that will be left with a shadow/3d, nothing quite like inconsistency. The stub/start will probably be harder to differentiate between since the icons are so small. I don't mind the FA/GA but I don't support replacing already acceptable icons. Terasail[✉] 22:51, 2 April 2021 (UTC)
  • The though process was, if we indeed do come to a consensus for the FC/GA icons, then the other icons (A - dab, the other 10 you are referring to) would/should be changed for consistency. No reason we couldn't keep the start/stub icons the way they look now just without the drop shadow stylization. Pbrks (talk) 23:19, 2 April 2021 (UTC)
• There was weak to no consensus for the idea the icons needed to change at all (I never saw that discussion), and this has all the same issues I mentioned back in the other discussion at Wikipedia:Village pump (proposals)/Archive 174 that was broadly attended. Pretty much, the changes aren’t needed, please go write and review some articles people; better yet, please initiate a badly needed GA sweeps. On the surface, it appears that the proposed icons are obscuring the fact that no other content review process except FAC is a community-wide process, rather one person’s opinion at one time, rarely re-reviwed, and seek to elevate GA to the same plane as FA by demoting the bronze star to a gold something the same as GA’s silver. Misleading. Others ahead of me, in this and both discussions, have explained the problems. Or, as Johnbod said once, Oppose per the Opposers. SandyGeorgia (Talk) 23:28, 2 April 2021 (UTC)
  • SandyGeorgia, "go write and review some articles" as a personal directive is absolutely inappropriate. People are allowed and should be encouraged to constructively edit Wikipedia however they like. If that's writing articles, great. If that's anti-vandal work, great. And if that's trying to improve the icons we use, great. Be kind and show some respect. Ed ^{[talk] [majestic titan]} 14:14, 13 April 2021 (UTC)
• I think the proposed logos are not only less clear (grey question mark in a circle means "Good Article Candidate" -- really?), but too childlike and less visually appealing. — Goszei (talk) 23:36, 2 April 2021 (UTC)
• Sorry. Respect the effort you've put into this; I understand design is difficult... but I don't like the new icons, particularly for FA. It's generic and fades into the background at small scales. I don't think there's enough padding between the star and the border. I might support a change to the GA icon, but not sure this is the right one. It's unclear what is being communicated to me by the stub and start icons. The changes to the others are fine, but minor. — The Earwig (talk) 23:37, 2 April 2021 (UTC)
• I don't know about these. I agree that, overall, the icons used on Wikipedia might benefit from some kind of comprehensive review. For example, the fact that "good article" and "support vote" use the exact same image is a profoundly dogshit situation. Who decided that was a good idea? The distinctions between "FA candidate", "former FA", and "former FA candidate" are also bizarre and non-intuitive (to someone who is not a hardcore Wikipedia editor, these all look like random injured starfish). Moreover, the scale of quality goes magenta, dark green, red, orange, yellow, green, blue, green, yellow. While I agree that some change ought to be made (and there should be an enormous watchlist-pinging WP:CENT about it with several suggestions for icon schemes), I don't think it needs an update, and this one in particular doesn't really spark joy for me. Notably, the "silver" being used to denote GAs is... that doesn't look silver, it looks gray. Also, it removes some good stuff: right now, the jagged former-GA icon very clearly shows that it was a GA and then was "broken", whereas a little dotted star shows nothing. jp×g 23:59, 2 April 2021 (UTC)
• I don't think the proposed icons improve over the current ones aesthetically, but there are also more serious problems. The use of a question mark is too firmly associated with DYK and should be kept out of FA/GA icons to avoid confusion. Moreover, the proposed FA and GA icons have exactly the same geometric design and are distingished only by colors. IMO that already renders the entire proposal unacceptable. A substantial portion of our readers are color blind. They will face a great difficulty in telling the GA and FA icons apart and some just won't be able to do so. The FA and GA icons need to be clearly geometrically different from each other, and one should not have to rely on the color scheme to tell them apart. Nsk92 (talk) 00:06, 3 April 2021 (UTC)
• I like the icons myself, but I must oppose the changing of the GA palette to gray. It does not and will not stand out against the default white background of Wikipedia. It must remain green. –♠Vami_IV†♠ 00:17, 3 April 2021 (UTC)
• Comment Here's an icon for "Rearranging deck chairs on the Titanic": . EEng 03:26, 3 April 2021 (UTC) P.S. Someone's calendar is off. This came a day late for April Fools.
• Oppose the need for a redesign in general, and especially the use of gray to indicate a GA. SounderBruce 05:02, 3 April 2021 (UTC)
• Oppose. "Ain't broke, don't 'fix' it." One obvious problem with the extreme anti-skeuomorphism that is the current trendy fashion in UI (but which is already seeing a lot of pushback and probably won't last long), is that it can't visually represent gold and silver, they just come out as yellow and grey, since adding white and dark highlights to simulate metallic shine is not possible in an anti-skeuomorphic approach. And grey in user-interface design means "disabled, unavailable, or inapplicable". So, FAIL.  — SMcCandlish ☏ ¢ 😼  05:30, 3 April 2021 (UTC)
• Oppose: I do not see a strong enough reason to change the icons. I think Nsk92 raises some very good points about this. Aoba47 (talk) 06:20, 3 April 2021 (UTC)
• oppose - some of the individual logos aren't fantastic, but the suggested ones are significantly worse. I'm not here to say that everything we have is perfect, but maybe we should update an image at a time? I agree that the difference between a former featured article, and a failed featured candidate is a bit odd, but then these are generally only used in templates next to where it rights what it means. I do think we would benefit from explaining to users what a good and featured article is (when I first used the site, I got what "stub" and "featured" was, but not much else), but changing the logo designed doesn't help. Best Wishes, Lee Vilenski ^{(talk • contribs)} 07:26, 3 April 2021 (UTC)
• Oppose. Whatever consensus was reached at the previous discussion, the number of opposing opinions here suggests that it is not very strong. The previous discussion should have been advertised better (i.e. at RFC or CENT). – Finnusertop (talk ⋅ contribs) 08:47, 3 April 2021 (UTC)
• Oppose. I actually like the old ones better (sorry). Cas Liber (talk · contribs) 09:37, 3 April 2021 (UTC)
• Oppose - this seems to be a solution in search of a problem. I'm not entirely sure what changing the icons will accomplish. ƒirefly ( t · c ) 09:41, 3 April 2021 (UTC)
• Oppose at least for now, I want to see the actual proposed image files (see discussion section below) - looks like we only have a picture of the pictures so far? Also, agree that greyscale icons aren't as useful. — xaosflux ^Talk 10:23, 3 April 2021 (UTC)
• Oppose. I am not against changing the icons in principle, although I would want to see much fuller discussion, but the suggested alternatives are hideous. And I agree with the comments that this all seems to be a solution in search of a problem; for example, "the overly detailed FC icon, which causes it to render poorly as small sizes" - I have it at 15px on my user page and it looks fine to me.Gog the Mild (talk) 12:26, 3 April 2021 (UTC)
• Oppose. I don't think that the consensus achieved at that October 2020 thread is very strong, judging by the response here. As for the actual proposed icons, gray does not mean "positive" or "good", that's universally green. Question mark is for help. The proposed stub and start-class symbols are too similar. As an aside, I can't wait for this current trend of over-simplifying symbols to go away soon. RetiredDuke (talk) 13:20, 3 April 2021 (UTC)
• Opposed (echoed). A consensus of eight is insufficient to change the mechanisms—however superficially—of multiple, highly active projects. Regardless of whether This thread is seeking to figure out how to change the icons, not if we should change them, it looks like you arenow enjoying a consensus to overturn a consensus. Land ahoy! ——Serial 13:30, 3 April 2021 (UTC)
• Oppose No need for this. Paul August ☎ 16:22, 3 April 2021 (UTC)
• Oppose. I didn't want to have to write here, but as it has been reopened I guess I will. I'm not set against the idea of changing the icons, although I equally don't really see a need to do so as I don't really find any of the reasons given particularly convincing (for much the same reasons as the others). However if you do still feel the need for change, work out what your design goals are, talk to the folks at Wikipedia:WikiProject Accessibility and follow their advice about how to make your ideals compatible with best practice. Only then will it be worth getting the pencils out. Thryduulf (talk) 17:46, 10 April 2021 (UTC)
• Weak opposeI agree with Thryduulf there is no real need to revise most of these. However, in my humble opinion, i think you made fair points that the FA article's icon goes to waste as you cannot see the full details. I'll mention my opinions in detail on what should be done.Blue Pumpkin Pie (talk) 18:07, 10 April 2021 (UTC)
• Oppose such a big change should come after a well advertised discussion involving a large number of editors. This is not the way to make such changes that affect everyone. Also the proposed new icons are ugly. --Ita140188 (talk) 05:38, 13 April 2021 (UTC)

Discussion (article icons)

@Pbrks: (or anyone) can you make a table of before/after for these - that has been quite helpful in similar discussion about icons. — xaosflux ^Talk 21:18, 2 April 2021 (UTC)

@Xaosflux: Yes, I will make them shortly. Pbrks (talk) 21:26, 2 April 2021 (UTC)

@Pbrks: do you have these as actual files that are already uploaded that can be in a normal table instead of a picture of a table? — xaosflux ^Talk 23:45, 2 April 2021 (UTC)

• I agree that the icons we use need to change and that they don't make much sense to casual users of the site, which is a loss because markers of quality are really important fo a critical engagement with Wikipedia. When I give training, it is almost always completely new information to people that Wikipedia even has a quality scale. I like the "promoted" and "former" icons, since "gold star" and "silver star" seem like a visual metaphor that people can understand from an early age, across a lot of contexts. The Featured buttons could be in a deeper hue to stand out more, but that's not much of a change. That said, the Candidate icons with a question mark in a circle, look like a "Help" or "Info" icon that a user would click on to get help with the user interface. The Former Candidate icons with a cross look a lot like the "Close tab" or "Close application" of some interfaces: buttons that a user would click to make something disappear. I can see what the List icon represents, but it looks an awful lot like the hamburger menu which is a very common navigational feature of web sites, and is the sort of thing that a user would click on to see a list of preferences or options. These potential confusions mean I can't support this iteration of the proposal, but I do think it is going in the right direction. MartinPoulter (talk) 21:26, 2 April 2021 (UTC)
• The star outlines for former featured/good status are very thin—at small sizes I'd guess these are essentially just empty circles, which is presumably not the intention, right? I'd make them thicker. Even a full border (but hollow interior) would be visually distinct enough from current featured/good. At some point it would be good to play around with the individual image files in a sandbox, which you can't easily do with the icons all as one image, though I understand mass uploading of all the icons could be a bit tedious. — Bilorv (talk) 21:31, 2 April 2021 (UTC)
• Meta point -- should the bullet points in support/oppose be converted to numbered lists for readability? Vaticidalprophet 00:12, 3 April 2021 (UTC)
• I don't oppose the concept of people designing new art work, allow editors to edit to their strengths. Just because something is new doesn't mean it's bad. I'm not a fan of the "Start" and "Stub" icons, may want to come up with something a bit different there. I don't see any ships sinking, deck chairs being rearranged, and I certainly wouldn't insult someone for proposing an idea as an April Fool's joke. Perhaps just in an effort to get some sort of "social capital" in the name of humor? But, as they say, YMMV. — Ched (talk) 07:16, 11 April 2021 (UTC)

Taking a step back

• I started this proposal after a closure request for the previous one decided that the outcome was fairly self evident with support ... editors interested in taking on this work have a mandate to do so. and the request moved forward at the Illustration workshop. It's fine that Prop 1 wasn't held in high regard, but it's just a proposition -- things can be changed, style can be changed. However, it's a bit disheartening and demoralizing to get comments of hideous Web Whatever.0 design and to go write and review some articles instead. I don't understand why people can't just give their opinion without being nasty about it. It's human nature to resist change, I get that, but the fact remains that this renders terribly at 20px and has literally confused people in the past, as it also is used for the "support vote" symbol. Moreover, the subicons for these (particularly the GA icon) don't make much of any sense. The former FC icon has a unsightly, stylistically different "X" through it. The reassessment icon is a broken GA icon? The former GA icon is the same as the former GA candidate icon ? All three of the aforementioned are the same except for color (in which Nsk92 makes a good point about color blindness)? To believe that nothing needs to be changed is beyond me. I don't see much of a reason to move forward with any different kind of proposition given the previous comments. Pbrks (talk) 05:31, 3 April 2021 (UTC)

  The only argument of the bunch that rings in any way true to me is 's ambiguity, and even that I'm skeptical about -- the only real context I ever see it used to denote support votes is...GAN, where it in fact makes perfect sense. Is hyper-anti-skeuomorphism and a redesign ten people asked for really a better solution than "rename " or just straight up "we have a million support vote symbols, some will overlap"? It's also honestly bizarre to me that the previous proposal was closed as a mandate when it had no participation from the people highly involved in the relevant process, many of who have since come out in strong opposition. Vaticidalprophet 06:17, 3 April 2021 (UTC)

  (Addendum: readers interested both in the 'million support vote symbols' comment and in why trying to redesign Wikipedia's house styles for icons is both a huge job and a thankless/anti-thanked one are pointed here.) Vaticidalprophet 06:25, 3 April 2021 (UTC)

  I just responded to the "go write and review some articles" comment. As a personal directive, it's absolutely inappropriate. People can (and should!) constructively edit Wikipedia however they'd like. Ed ^{[talk] [majestic titan]} 14:19, 13 April 2021 (UTC)

• Class icons B, C, Start, and Stub don't need to be revised as their icons aren't visible on the article or talk page. I do think Good Article and Featured Articles are great milestones that need to be highlighted in the article. I like the Gold-Star, Silver-star because they can illustrate to both readers and editors that they are the cream of the crop. Especially with a Silver Star instead of a Green Plus symbol can give editors an indicator that it's almost a Featured article (Gold Star). But the recreated icons don't stand out enough for new readers to notice or for editors to care about. If the icons are going to be revised, they have to be visually appealing and something that readers/editors can approve of.

I googled the words "Quality" and "Icon" and I found a lot of metals with ribbons attached to them. We can have a gold jigsaw puzzle to indicate the Featured article, and a silver jigsaw puzzle to indicate Good Article. I'm just being creative at the moment. So long as these icons shine and stand out positively, then maybe editors may support the proposal more. The dotted line forming a star isn't clear to me, and the Question mark resembles the DYK icon. I think it would be easier to use a magnifying glass over the current icons for representing re/assessment. The current Red X and Broken GA (in my humble opinion) are upsetting and can be discouraging. The red-painted cross over the featured article and the broken GA symbol is just not professional icons in my opinion and even look like there's anger involved.Blue Pumpkin Pie (talk) 20:11, 10 April 2021 (UTC)

Licensing

• Ideally, any new icons would be licensed as CC0 or PD so that the icons be used unlinked, without the need for the link for attribution. -- WOSlinker (talk) 09:01, 3 April 2021 (UTC)

Post-close

It's regrettable that a constructive idea was shot down so quickly (less than a day!) and for such poor reasons. Sometimes it's good to discuss new ideas even if they're not immediately going to fix an urgent problem, we might uncover issues that the early knee-jerk WP:AINTBROKE crowd hadn't thought of. And frankly our FA icon at topicon resolution (where readers normally see it) looks like it was drawn on the back of a napkin with a sharpie and digitized with one of those old hand-held roll scanners, or else shrunk from its original size down to 10px and then scaled up again. Putting this blighted icon on a featured article makes the article less good. I realize it's what readers and editors are used to, but that's not a good enough reason on its own to keep it, and certainly not to shut down a discussion about it after just over 18 hours. Just a plain bordered star in the same colour would be not so much of a departure from the current icon as to be confusing, and would be a fair improvement. But I guess nobody wants to talk about improving the encyclopedia. Ivanvector's squirrel (^trees/_nuts) 19:22, 8 April 2021 (UTC)

I agree. Since the close mentions SNOW, I also want to point out this section of the essay saying: "It can sometimes be better to allow a few extra days even if current discussion seems very clearly to hold one opinion, to be sure that it really will be a snowball and as a courtesy to be sure that no significant input will be excluded if closed very soon." In general, I like the proposed designs for FA and GA (though agree that the good-article-grey is a bad color choice). They read much better at small sizes, are symbolically more clear (an absent star and question mark are a lot more intuitive than the existing symbols), and the style matches the recently redesigned protection icons providing a more unified design. I hope we can give these ideas more serious consideration next time around. — Wug·a·po·des​ 23:29, 8 April 2021 (UTC)

Agreed, though the proposal in its fullest form might be seen a snow close, a lot of opposers offered sympathy for specific improvements. The latter is valuable information that could thoroughly inform future discussions, but has been halted unnaturally. Aza24 (talk) 23:34, 8 April 2021 (UTC)

I disagree - this specific proposal was correctly SNOW closed because it was very clearly never going to get a consensus. There is nothing stopping you or anyone else going back a step or two and initiating a discussion to generate a broad consensus for the need for change (which hasn't yet occurred). If there is a consensus for change, then the next step is to workshop multiple designs, implementing the results of feedback received, before presenting a small number of well developed proposals for adoption. Getting more of the same feedback on this proposal and more reminders about the lack of consensus that a need for changes exists is not going to help that. Thryduulf (talk) 17:12, 9 April 2021 (UTC)

Yes, how terrible for Wikipedia that someone with an idea wanted to talk about it, but didn't get permission from The Community first. What a sterile, needlessly bureaucratic place this is becoming. Ivanvector's squirrel (^trees/_nuts) 12:55, 10 April 2021 (UTC)

• @Ivanvector, Wugapodes, and Thryduulf: Re-opened per request. --TheSandDoctor ^Talk 17:31, 10 April 2021 (UTC)
• Is there any evidence that any more than a minuscule percentage of our readers understand the current icons, and that any more would understand redesigned icons? In the absence of that this seems like yet another make-work project that imposes change for change's sake on both readers and editors, taking people away from improving the encyclopedia. There seems to be a theme of following the advice of self-appointed experts in both programming and design, but ignoring the people who actually create this encyclopedia. Phil Bridger (talk) 18:01, 10 April 2021 (UTC)

  1. You're probably right that only a minuscule percentage of our readers understand the current icons. I mean, there's a reason why one of the files is called File:Symbol support vote.svg and is usually used for supporting/opposing permission requests/deletion discussions (eg on meta/commons). It's doubtful that this is a carefully thought out icon set that works well in cohesion with other icons, rather than just stuff formed independently over time. This is hence something we might be able to improve.
  2. I dislike the recent themes of trying to create a bit of a "us vs them" (ie "content creators" vs "admins/software developers/designers/whatever else"). Everyone is trying to achieve the same thing here - a decent free resource for information. Some people are better at different things. No doubt the people who have 90 FAs under their belt are great at writing content and valuable contributors. Also no doubt the people that write bots that save hundreds/thousands of hours of repetitive manual labour are also valuable contributors. Similarly, those who have experience with design and user interfaces are more likely to know what makes for a good, intuitive layout. There's no reason to think that those with one type of skill are better than any other type of editor, or are more apt at doing every task than others.
  3. I don't think anyone is ignoring anyone. Pbrks made a proposal based on a prior RfC, and above appears to be trying to work with people to figure out issues and improve. It is unlikely that this proposal is the best possible solution, but it can only be improved with feedback, and if people discuss their issues perhaps Pbrks (and/or others) can adapt the icons based on that. It's impossible to just guess what people want. But at least some of the ideas presented, such as using a question mark to represent a GAR/FAR(C), are broadly good ideas and more intuitive than the current representations.

  ProcrastinatingReader (talk) 19:00, 10 April 2021 (UTC)

  I dislike the recent themes of trying to create a bit of a "us vs them" I agree strongly with this. The proposal requires literally nothing from Phil (unless he manually draws the FA icon every time we promote an article), yet somehow he seems deeply concerned about the burden this will impose on editors. Seriously? Just say you don't like the design and move on, but don't pretend like you have veto power over how volunteers decide to spend their time. If you want to rail against "self-appointed experts" wait until you find out who writes our content. — Wug·a·po·des​ 22:25, 10 April 2021 (UTC)

• Does the foundation have a usability team that supports the software we use and can provide us with recommendations on issues like this? ElKevbo (talk) 21:38, 10 April 2021 (UTC)

  There is the Design team, and they seem to do nice work (see mockups at mw:Streamlined Infoboxes for example). No idea how you'd get in touch with them though. Phabricator task maybe, but the backlog on those looks long... Email or IRC perhaps? ProcrastinatingReader (talk) 23:51, 10 April 2021 (UTC)

• I'm not sure the reopening here will really help. Putting together the prior discussion and this one, my read is that there's substantial discontent with the current icons and weak consensus that they ought to be changed, but also fairly clear consensus that the specific proposal here isn't yet ready to be adopted. I think the best path forward is to take a step back and work on refining the design, and then come back to a prominent venue when that is ready.

The one thing I'd say while this is in the spotlight is that, for any editors graphically-inclined, it'd really be helpful to have additional help with that. Wikipedia:Graphics Lab/Illustration workshop#Good article and featured article topicon redesign has been sitting around for months and hasn't yet gotten the level of engagement that I'd hope for it to get. {{u|Sdkb}} ^talk 23:00, 12 April 2021 (UTC)

Idea for speedy deletion U6: user pages of users blocked or banned for bad-faith edits

We have many pages that list problem users and categories for Wikipedia sockpuppets and long-term abusers and sometimes one-off spammers who create user pages. I think users that vandalize or spam or anything of the like should have their user pages deleted as not to glorify them. See also Special:PrefixIndex/Wikipedia:Long-term abuse/ and Category:Wikipedia sockpuppets. We should not be glorifying these users acting in bad-faith. We should have secret administrative pages (probably on an admin mailing list or on Discord) to allow for admins and trusted users to identify socks. Aasim (talk) 05:48, 4 April 2021 (UTC)

Like usual, feel free to move this to the idea lab if too early for VPPR. Aasim (talk) 05:49, 4 April 2021 (UTC)

CSD proposals should be at WT:CSD but I don't think we need a real large-scale discussion here. This is a bad idea for multiple reasons. Stuff that is relevant to Wikipedia should stay on Wikipedia (barring privacy concerns). There is nothing "glorifying" about telling the whole world that this person violated the rules to the point that they were banned from editing and it helps users to identify problem editors, especially when they return as socks. Regards SoWhy 11:11, 4 April 2021 (UTC)

In addition to SoWhy's points, if their user page is spam it can already be speedily deleted (WP:CSD#G11), if it was created by a user in violation of a block or ban it can be speedily deleted under criterion G5, if they're misusing Wikipedia as a webhost then criterion U5 applies. However, most often user pages of sockpuppets and sockmasters are replaced by a notice that notes this status and (in the case of sockpuppets) who their master is; this does not require deletion so your proposal would fail WP:NEWCSD point 2. Thryduulf (talk) 11:35, 4 April 2021 (UTC)

Creating a new CSD to hide things is... not really a good idea. "Secret administrative pages" *shudders* Elli (talk | contribs) 11:59, 4 April 2021 (UTC)

Apart from pages that already qualify for deletion under U5 or G11, I don't see a need to delete userpages of banned or blocked users. User:力 (power~enwiki, π, ν) 22:20, 4 April 2021 (UTC)

I think to give better context in what I am thinking: Wikipedia:Deny recognition CSD. Aasim (talk) 19:19, 7 April 2021 (UTC)

This idea belongs at WP:PERENNIAL. In six years that I've been active at SPI and as a checkuser, I can count on one hand the number of long-term abuse cases I've encountered of a vandal doing it "for the lulz", and we do purposely deal with them as silently as possible to deny recognition. The vast majority, though, are people with a specific agenda, far from vandalism (ethnic nationalists, fringe theory proponents, people who would fit right in at Rightpedia, and such) who try very hard to not be recognized. WP:DENY works in their favour, not ours. In fact we do have "secret administrative pages" in the form of separate, private wikis, for non-public information that helps in detection, but having public LTA pages helps detection and enforcement be a collective task, rather than entirely handled by a handful of active functionaries. Ivanvector's squirrel (^trees/_nuts) 13:14, 10 April 2021 (UTC)

Email edit notice update

Given some of the, ...let's say discussions, at various places lately, I wondered if this idea was worth floating. (if this should be at a different VP section like technical, or something else, I have no objections to it being moved)

As it stands now there is the last line in the 'email this user' edit notice:

• Wikipedia makes no guarantee of confidentiality for messages sent by this system. Do not send information by email that you would not want published on the internet.

and I wondered if perhaps we should bold that to stand out a bit more...

• Wikipedia makes no guarantee of confidentiality for messages sent by this system. Do not send information by email that you would not want published on the internet.

thoughts? — Ched (talk) 21:55, 4 April 2021 (UTC)

Without trying to commenting on any particular situations... Sure, Wikipedia can't guarantee that an editor won't send a message to another editor. But this is true of any site, anywhere. Facebook can't guarantee that the receiver of a "private message (PM)" won't show the message to someone else, Signal (software) can't guarantee a message sent in its E2E encrypted "private chats" won't be republished by a participant, and for all Snapchat gives an alert when people screenshot an expiring snap/image, it can't actually stop anyone screenshotting it. All this is to say, I don't really see the point of this disclaimer. It doesn't really relate to what good etiquette is (and IMO, it's bad etiquette to repost messages sent via that system), and a move towards possibly implying that this is anything but bad etiquette is a bad idea imo. Not even sure I like the existing text that's there, maybe it should be worded in a more nuanced way (but I suspect I'm the minority on this opinion). ProcrastinatingReader (talk) 00:24, 5 April 2021 (UTC)

While I'm commenting here, what might be interesting is to see if there's now consensus for some sort of email guideline. Wikipedia:Harassment#Private correspondence indicates previous discussions were no consensus. Some other incidents makes me feel this can lead to bad situations (for example this situation). ProcrastinatingReader (talk) 00:36, 5 April 2021 (UTC)

Administrator note the entire message is stored in MediaWiki:emailpagetext. — xaosflux ^Talk 00:51, 5 April 2021 (UTC)

The line in question was added by AGK with this edit in 2014. I assume this change didn't come out of nowhere but I haven't immediately found any discussion about it. Two days later they added a similar message at User:Arbitration Committee. Thryduulf (talk) 02:20, 5 April 2021 (UTC)

Was that around the time that there were all those arbcom leaks posted on an external site perhaps? — Ched (talk) 02:26, 5 April 2021 (UTC)

A quick search suggests that the major leak was in mid 2011 Signpost story, with a smaller one in late 2012 Signpost story. That tallies with my memory of leaks not being mentioned significantly in the 2014 elections where I was a candidate. Thryduulf (talk) 02:47, 5 April 2021 (UTC)

• It's 2021, and people know what email is and how the internet works. It's not our job to educate them on those things in the editnotice Xaosflux linked. Worse, when the editnotice becomes 20 pages long with every other line bolded,^[hyperbole] the main actually-important point—that your email address will be disclosed—gets lost because no one reads the notice. This suffers from the same issue that has made so much of instruction on Wikipedia terrible: the way to improve it is to make it shorter so that people actually read it, not to make it longer and longer until it becomes a manual covering every possible eventuality. There are several lines from the current notice that should be removed, including the reiteration; that's where I would start. {{u|Sdkb}} ^talk 16:11, 5 April 2021 (UTC)
• If I want to e-mail a user, I go to their user page and use the Email this user option in the sidebar menu. The entire text that I am given in the form is then:
  You can use the form below to send an email message to this user. The email address you entered in your user preferences will appear as the "From" address of the email, so the recipient will be able to reply directly to you..
  Nothing more. For me, this seems to be enough. When would I see the text being discussed above? — GhostInTheMachine ^{talk to me} 19:27, 5 April 2021 (UTC)

@GhostInTheMachine: You probably have your interface language set to British English. I see the same thing at [25]. I'm guessing maybe MediaWiki:Emailpagetext/en-GB should be moved to MediaWiki:Emailpagetext/en-gb. Suffusion of Yellow (talk) 21:27, 5 April 2021 (UTC)

Being British and speaking only English -- that would make sense. My preferences do say that my interface language is en-GB, not en-gb — GhostInTheMachine ^{talk to me} 19:11, 6 April 2021 (UTC)

@GhostInTheMachine: this should be "fixed" for you now, but please note: there is almost no maintenance of English language variants (e.g. en-gb, en-ca, en-au, etc.) performed on any of the WMF projects and due to oddities with the language fall back chains (see phab:T229992 for more on that) users that pick one of those variants will likely miss out on localized messages often, I strongly suggest you change it to the base English. — xaosflux ^Talk 10:46, 7 April 2021 (UTC)

Xaosflux Thanks. Sort of – I have downgraded myself from being British to just being an English speaker — GhostInTheMachine ^{talk to me} 19:09, 7 April 2021 (UTC)

@GhostInTheMachine: feel free to speak however you like, hopefully this is just a bodge! — xaosflux ^Talk 19:13, 7 April 2021 (UTC)

• Sure, but I don't think it makes much difference. The message is more of a disclaimer than a purposeful educational message to users: we've had email for 30+ years, if you don't know how it works by now (in particular how insecure it is) then a bold message on an email form probably isn't going to help. Personally I have a message on my user talk that advises users of my own personal policy with respect to email privacy, which again is more for my own benefit, I really don't expect anyone who emails me to have read it (and generally assume that they have not) but act accordingly anyway. I don't expect the same courtesy from others, and why should I? To that end I'd like to be able to make my own editnotice for the mail form when a user tries to email me, but that's probably dev work and I won't hold my breath. Ivanvector's squirrel (^trees/_nuts) 13:24, 7 April 2021 (UTC)

  You can do that, see Wikipedia:Emailnotice for simple instructions. Thryduulf (talk) 18:45, 7 April 2021 (UTC)

  Thryduulf, Cool, or in wiki-speak: Thank you for this information, it is valuable to me and much appreciated. Thanks. — Ched (talk) 19:31, 7 April 2021 (UTC)

  About three and a half seconds after I hit save I thought, "someone's going to reply telling me how to do exactly that", and there you have it. Thanks Thryduulf! Ivanvector's squirrel (^trees/_nuts) 00:39, 8 April 2021 (UTC)

Promote Wikipedia:Video links from essay to guideline

Wikipedia:Video linksmight have some shortfalls, but it is ready for edits and review to become a guideline. Talk page notified. 2601:601:CE7F:E270:5456:2939:9AB9:38F1 (talk) 07:08, 6 April 2021 (UTC)

A bot should create two redirects for all new Articles for Deletion listings.

For example, if Wikipedia:Articles for deletion/Example is created, a bot should create all of the following:

• Wikipedia:Articles for Deletion/Example ("D" in "Deletion" capitalised)
• Wikipedia:AfD/Example ("Articles for Deletion" abbreviated)
• (add nomination number to end of name if necessary)

It would alleviate capitalisation problems (in case of first) and make many links to nominations shorter (in case of the second). What do you think? DePlume (talk) 04:09, 8 April 2021 (UTC)

• The first thing doesn't seem like much of a problem, but gosh that second thing would be so convenient when pulling up related AfDs.. –MJL ‐Talk‐^☖ 05:05, 8 April 2021 (UTC)

Nicer would be a mediawiki feature allowing a redirect to automatically redirect all subpages accordingly. Elli (talk | contribs) 05:54, 8 April 2021 (UTC)

Solving the issue of subpage redirects in the software would be a much cleaner solution, and would also benefit other venues where this is an issue (WP:MFD and WP:SPI come to mind), rather than creating an extra two pages for every AfD nomination. Yesterday there were 98 nominations, creating 98 additional pages. A bot creating the proposed redirects would have created an additional 196. That's not a lot of overhead but it's not zero. Ivanvector's squirrel (^trees/_nuts) 16:28, 8 April 2021 (UTC)

Agree with the above^. ~ HAL333 00:00, 9 April 2021 (UTC)

• Oppose, creating triple the number of pages for this task should only be with a very good reason, I'm not seeing what the overwhelming problem is here. — xaosflux ^Talk 16:58, 8 April 2021 (UTC)

User:Enterprisey/search-shortcuts exists that expands "WP:AFD/" in the search box to "WP:Articles for deletion/", which solves part of the problem in navigating to these pages easily. – SD0001 (talk) 15:59, 9 April 2021 (UTC)

Broken links to references

Many articles now have broken references to web based sources that no longer exist or have moved to some other link. Please suggest or require all users and editors to screenshot the info from a web based source and place the reference in caption. — Preceding unsigned comment added by 108.174.40.162 (talk) 19:16, 8 April 2021 (UTC)

a) That's a fair-use nightmare and probably wouldn't be acceptable under our fair-use policy (and wouldn't work at all on other wikis which don't permit fair-use). b) Sounds like a major accessibility issue. c) According to WP:PLRT (can't vouch for whether that's up-to-date), most links added to Wikipedia trigger an archiving of that page in the Internet Archive - and for bonus points, User:InternetArchiveBot can scan for dead links and replace them with archive links. ^{SubjectiveNotability} _{a GN franchise} (talk to the boss) 19:25, 8 April 2021 (UTC)

In addition to SubjectiveNotability's excellent points, where would you suggest that editors put the screenshots? Around half the editors seem to use mobile 'phones these days and the other half are probably behind firewalls. Martin of Sheffield (talk) 19:37, 8 April 2021 (UTC)

What they could do is submit the page to archive.is, which will take and save a snapshot. It would be better to have a Bot carry out this task though. Hawkeye7 (discuss) 22:57, 8 April 2021 (UTC)

the Internet Archive automatically scrapes links that are posted to Wikipedia and archives them, if I remember correctly. Elli (talk | contribs) 19:43, 9 April 2021 (UTC)

Our referencing policy doesn't require that sources be available at the time of viewing, only that the citation identifies the source of the information cited at the time of the edit. InternetArchiveBot flags dead links and I think can also replace them with links to [archive.org], and there's either another bot or a semiauto tool which automatically replaces weblinked references with an archive link regardless of their status. Recording screenshots of the source is a bad idea for the fair-use reasons mentioned, but also what's to stop someone from modifying a screenshot to include false information and then citing it as a reference? Ivanvector's squirrel (^trees/_nuts) 15:34, 9 April 2021 (UTC)

I would add to the excellent points made above that an ephemeral, unarchived, web-based source is very likely not to be a reliable source. I would add that I know of people who have manipulated screenshots in the way described by Ivanvector's squirrel - not for Wikipedia purposes, but it could be done here just as easily. Phil Bridger (talk) 15:52, 9 April 2021 (UTC)

WP:LINKROT has additional information about archiving on enwiki.. -- GreenC 20:09, 9 April 2021 (UTC)

Limiting the number of GA nominations per editor

Deletion of own user-pages

In my opinion non-sysops should have the right to delete their own user page. Dr Salvus 12:47, 11 April 2021 (UTC)

You can request the deletion of a page in your own userspace by CSD by WP:U1 Best Wishes, Lee Vilenski ^{(talk • contribs)} 12:51, 11 April 2021 (UTC)

Dr Salvus This is a perennial proposal, with good reasons as to why it hasn't been done. See this section. The main reason not to do it is that users could move articles to their user page and then delete it. 331dot (talk) 12:54, 11 April 2021 (UTC)

Should IP files an Arbitration cases

Hello, i read the Wikipedia:Arbitration/Requests/Case. In the article, all arbitration requests was done only by autoconfirmed users, which automatically bans IPs or unregistered users from filling the arbitration requests. In my opinion, this policy should be changed to allow IPs or unregistered users (unless their edits are bad faith) to filing arbitration requests, because there are many good faith IP edits, not assuming all IP edits as bad faith. For all users, should IPs be allowed to filling the request. 36.77.94.191 (talk) 04:21, 13 April 2021 (UTC)

That way madness lies... ~King Lear GenQuest ^"scribble" 05:26, 13 April 2021 (UTC)

Pinging a couple of arbcom clerks (@Liz and Guerillero:) ...will be quicker then reading the arbcom book... - are unregistered users actually barred from initiating arbitration policy wise? If there are technical hurdles can they be overcome by methods such as contacting the clerks to open a request perhaps with a transcluded section (as Wikipedia:Arbitration/Requests/Case is SPP)? — xaosflux ^Talk 10:10, 13 April 2021 (UTC)

I don't know of anywhere in policy where this is prohibited. -- Guerillero ^{Parlez Moi} 02:53, 14 April 2021 (UTC)

I don't know whether they can, but they generally should not. They should start an ANI thread first, and if arbitration is necessary someone else can file the request. User:力 (power~enwiki, π, ν) 02:56, 14 April 2021 (UTC)

The arbitration request pages have been semi-protected for over a decade. That doesn't mean unregistered users can't participate in arbitration (at least, I don't know of anything in either WP:ARBPOL or WP:ARBPROC that says so), it just recognises they're prime targets for vandals and sockpuppets, and that very few unregistered/unconfirmed accounts will have a legitimate reason to edit them. And the small number of long-term unregistered users who have been around long enough to get involved in a dispute requiring arbitration presumably have also been around long enough to know how to make an edit request if they need to. – Joe (talk) 10:34, 14 April 2021 (UTC)

Trigger warnings

Trigger warnings should be added at the beginnings of articles or at least somewhere on the page. Avoids people accidentally stumbling across triggering content. Perhaps in the form of one of those template notice thingies that go at the top of the page? -LocalPunk (talk) 11:14, 25 January 2021 (UTC)

It would be nigh-impossible for Wikipedians, who may not share each others' societal or cultural norms, to agree on a comprehensive standard for what constitutes "triggering content". If the principle of least astonishment is properly followed, readers should generally come across offensive material only when it is expected (e.g. readers should anticipate articles on anatomy will contain images of sexual organs) and enhances their understanding of the topic, which would negate the need for warnings. There is also a general content disclaimer which explicitly warns readers that Wikipedia hosts objectionable content. (See also WP:NOTCENSORED). – Teratix ₵ 14:01, 25 January 2021 (UTC)

True. Perhaps a card with a link to the content disclaimer could be an idea? -LocalPunk (talk) 15:40, 25 January 2021 (UTC)

The problem is still which articles should have it, which is a highly subjective choice. —  HELLKNOWZ   ▎TALK 16:24, 25 January 2021 (UTC)

There'd probably have to be some sort of free-to-update list or something. -LocalPunk (talk) 19:19, 25 January 2021 (UTC)

@LocalPunk, I think you will want to read Trauma trigger. There might be some practical value in having a NSFW warning, but there is probably no benefit to a trigger warning. WhatamIdoing (talk) 02:35, 26 January 2021 (UTC)

I strongly disagree with the first paragraph of "In higher education". LocalPunk (talk) 11:35, 26 January 2021 (UTC)

It might be useful to differentiate between trauma trigger and thing that makes some people uncomfortable. For example, if you saw a person stabbed to death, then you might (or might not) develop long-term PTSD as a result. Your trauma trigger, however, is statistically unlikely to be "seeing people stabbed" or "reading about people being murdered". It's likely to be something like the metallic smell of blood, or the odd motion of the murderer's head, or the food that you had eaten just beforehand. Reading about crimes or watching a violent movie might be uncomfortable (or not; some traumatized people seek out horror films[26]), but it is unlikely to be an actual, bona fide trauma trigger.

There has been talk in the past about certain kinds of content filters. Nobody should have to look at a photo of someone gouging out another person's eye or dead bodies just because Special:Random will sometimes take you to pages related to mixed martial arts or war crimes. But actual trauma triggers, rather than things that make people feel uncomfortable, are probably few and far between on wiki, and warnings for true trauma triggers are probably neither possible (how is anyone supposed to know what your personal trigger is?) nor necessarily helpful. WhatamIdoing (talk) 03:35, 30 January 2021 (UTC)

• Someone should have warned me there'd be a Trigger warning discussion on this page before I visited it, because every time I see someone proposing trigger warnings I just want to cry. EEng 21:34, 29 January 2021 (UTC)

  I think you're missing a ⸮ there, EEng. 4D4850 (talk) 19:43, 15 February 2021 (UTC)

  What, you think I wasn't serious? EEng 06:42, 2 March 2021 (UTC)

What if it's like one of the banners Wikimedia puts up on articles that need to be reviewed. Just a pale yellow warning "Common Trigger Warning" and editors and decide how specific that needs to be. — Preceding unsigned comment added by Totalart44 (talk • contribs) 06:05, 23 February 2021 (UTC)

• I agree that there should be trigger warnings on things that everyone can agree on is triggering, like the holocaust or KKK. Starman2377 (talk) 16:25, 25 February 2021 (UTC)

  The problem is that we can't actually agree that those subjects are triggering. We can agree that they are uncomfortable. We can agree that they involve evil things. We can agree that one might wish to be careful about how one describes those to children. That is not actually the same thing as those subjects being coupled to any individual's PTSD-producing experience.

  Trauma trigger is "the Vietnam vet flinches when he hears a helicopter fly by". Trauma trigger is "mother collapses every time she hears her dead child's favorite Christmas song". A trauma trigger is not "reading about evil makes me uncomfortable". You're actually supposed to feel uncomfortable when you read about the Holocaust and the violent racist groups. Feeling uncomfortable when you encounter the evils of racism and genocide means you still have a functional conscience. WhatamIdoing (talk) 23:37, 2 March 2021 (UTC) You're right. Starman2377 (talk) 14:46, 25 March 2021 (UTC)

• I don't think this should be dismissed out of hand - such warnings would not impact article content and would go a long way to making the website more accessible to some. As for what topics should be "warned" for, we could decide on that the same way we do anything else - through editor consensus. A standardized banner template with slot-in content warnings seems feasible and reasonable. BlackholeWA (talk) 23:51, 1 March 2021 (UTC)
• Seriously, how about if someone creates a browser extension that searches a page for key words and phrases, does some kind of image search automagic, etc., before presenting it. Then it would work on everything, not just Wikipedia. And we can get out of the nannying business. EEng 06:42, 2 March 2021 (UTC)
• I agree with WhatamIdoing's statement above. But, supposing that we could agree on a "trigger warning" banner and come up with a list of subject areas that the community agreed should display the banner, here's what I would expect to happen:

1. Most readers would not see it (banner blindness).
2. Word would get around that some articles have trigger warnings.
3. People would complain when an article that bothered them personally in some way didn't have the warning.
4. There would be demands for warnings on unmarked articles for a myriad of reasons (many patently ridiculous on purpose in the hopes of being denied so they can broadcast their fauxrage and get their 15 minutes), which, if we failed to comply, would result in accusations of bias or complicity or indifference to their suffering that would spread rapidly across social media to then be picked up by mainstream media who seem to welcome twitter mobs creating clickbait "news" for them.

I'm not convinced the lack of trigger warnings on articles is a problem, nor am I convinced there's a problem that would be solved by banners. Schazjmd (talk) 16:35, 2 March 2021 (UTC)

• Yes, i think we should make a banner for triggering content. I know not everyone thinks that something is triggering. But what we should do is have discussions on pages if they should have a trigger warning or not. Starman2377 (talk) 16:40, 2 March 2021 (UTC)

  So, what if someone is triggered by snakes. Or dogs. Or birds. Or spiders. Would we have to put trigger warnings on all of those pages too? Because some people are as frightened of those as other people are of violence. Where do we draw the line? We could easily end up with virtually every article having some sort of trigger warning. MeegsC (talk) 17:23, 2 March 2021 (UTC)

  Phobia object ≠ trauma trigger. NSFW warning ≠ trigger warning. WhatamIdoing (talk) 23:29, 2 March 2021 (UTC)

• Incredible, and sad, that we are even discussing such a silly, infantilizing, idea. Of course, this is assuming text. Photos might be another issue. Rollo (talk) 21:51, 2 March 2021 (UTC)
• Although a trigger warning is much more serious than a spoiler warning, I think Wikipedia's experience with spoiler warnings is instructive here. I don't think it's a good idea, and would be subject to similar problems. ~ ONUnicorn^{(Talk|Contribs)}problem solving 23:41, 2 March 2021 (UTC)
• Oppose for text. Wikipedia isn't in the business of censoring text on this type of basis. An effort independent of Wikipedia, probably a browser toolbar, may be what you want to support. power~enwiki (π, ν) 23:41, 2 March 2021 (UTC)

  Everyone keeps stealing my ideas -- see my earlier post. I feel triggered. EEng 23:44, 2 March 2021 (UTC)

• Oppose, regretfully. I am a person who generally benefits from content warnings; I have strong post-traumatic reactions to certain subjects, and so I find it useful to be prepared I am going to experience certain subjects before I experience them - especially in video content/etc, where it's much easier to be surprised by content. I am opposed to this proposal for two reasons: I do not generally have these problems on Wikipedia because this is an encyclopaedia, and article subjects are narrowly scoped enough that the lead generally already contains the information to allow me to nope out if I need to. Secondly, I don't think we are capable as a community of delivering effective content warnings with anywhere near enough consistency and empathy across the project for them to be anything more than a weak gesture. I would support more stringent policy on describing the content audiovisual media embedded in articles, because that has caught me out before. -- a ^{they/them | argue | contribs} 07:13, 3 March 2021 (UTC)

• Oppose I have no idea what would even constitute a trigger warning. I think the introduction of an article should be enough for each user to decide if they personally wish to read the article. If the introduction says, for example, "The Holocaust, also known as the Shoah, was the genocide of European Jews during World War II. Between 1941 and 1945, Nazi Germany and its collaborators systematically murdered some six million Jews across German-occupied Europe, around two-thirds of Europe's Jewish population.", you can decide based on that information if you wish to continue reading. I believe triggers would be highly subjective. I don't see a point in adding a banner to a bunch of articles. jort⁹³|talk 00:04, 8 March 2021 (UTC)
• Oppose - this is an encyclopedia. It covers the world in all its variety: good, bad, beautiful, ugly.... --Khajidha (talk) 11:40, 17 March 2021 (UTC)
• Doesn't No disclaimers in articles cover this? On a semi-related note, though, I wonder if there'd be any benefit to showing new readers the disclaimers Wikipedia does have which they have to take an action on – i.e. clicking "Okay, continue" or "Cancel" so that they're properly informed about what sorts of things exist on Wikipedia before they enter. Then again, if this were shown to anyone without a cookie set, or something, it could become an annoyance. Maybe a link to the disclaimers could be prominently shown on the main page? Another problem with this sort of thing is you then get a "don't stuff beans up your nose" violation – as in, if we warn readers about what sort of objectionable stuff exists on the site, they then might try to seek it out, if they're curious youngsters or something. Well, anyway, there's my inane rambling quota fulfilled for the day. DesertPipeline (talk) 13:32, 19 March 2021 (UTC)
• Oppose For some reason, the proposer believes that the average WP reader has only a few brain cells and cannot make inferences based on the names of articles that they will see graphic content. We can't pander this site to everyone. Putting trigger warnings on articles would only be obstructive to the 99% of readers who would not be triggered by the content of said article. Lettler^{hello • contribs} 22:07, 3 April 2021 (UTC)
• Oppose page-level content warnings, but support the concept in general. We ought to have a disclaimer to readers somewhere on the site that Wikipedia is not censored and so they may come across content or images they may find offensive or may be inappropriate to display in (for example) a workplace, but I agree that we could never decide on universal criteria for what is offensive. Ivanvector's squirrel (^trees/_nuts) 13:39, 10 April 2021 (UTC)

  Is something like Wikipedia:Content disclaimer what you have in mind? — Goszei (talk) 18:12, 13 April 2021 (UTC)

I have an idea

My idea is that when you hover you're cursor over an image, You should be able to see a larger version of the image. A lot of the time, It takes awhile to load an image when you click on it. If this would be added, It would be a switchable setting. Starman2377 (talk) 13:02, 25 March 2021 (UTC)

I like it. I already have Wikipedia:Tools/Navigation popups turned on. It's quite pleasant, and this feature would also make pictures more useful. Jim.henderson (talk) 11:43, 28 March 2021 (UTC)

There's a browser extension for Chrome and Firefox called ImagePreviewer that does this. Fences&Windows 23:46, 3 April 2021 (UTC)

Comma bot

I don't really know how bots work, but there is a grammar mistake (not too extreme) I see consistently. It's in a list of words, such as "One, two, three and four". It is supposed to be "One, two, three, and four". Again, I don't know how bots work/how to create one. Does anyone think this is a good idea? TheFirstVicar4 (talk) 15:21, 28 March 2021 (UTC)

Both forms are allowed by Wikipedia:Manual of Style#Serial commas. PrimeHunter (talk) 15:25, 28 March 2021 (UTC)

See also WP:CONTEXTBOT. This is not a task bots can do. —  HELLKNOWZ   ▎TALK 16:27, 28 March 2021 (UTC)

No!! Adding Oxford commas to existing articles would be a fine way to start a war — GhostInTheMachine ^{talk to me} 17:00, 28 March 2021 (UTC)

Alas, for the sake of peace, TheFirstVicar4, Wikipedia has to allow people to eat Grandma. Nosebagbear (talk) 10:29, 29 March 2021 (UTC)

Filter for special:random or the random article button

I feel like there should be some way to filter what pages you can be taken to by either using Special:Random or clicking on the Random Article button. I usually try and use it to find a random page and see if it needs any editing but often it takes me to a page on a topic I know nothing about or a page with very little information on a subject I don't know anything about. So maybe creating some kind of way for users to filter what kind of articles either of those will take them to or something else. I'd like to hear what you guys think about this idea. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 20:00, 29 March 2021 (UTC)

I'd also like it if there was a "random" for all namespaces, or at least the major ones. 🐔 Chicdat  ^{Bawk to me!} 20:05, 29 March 2021 (UTC)

There is. See Wikipedia:Random. PrimeHunter (talk) 20:48, 29 March 2021 (UTC)

• Special:RandomInCategory is probably what you need. Unfortunately for readers, it's much harder to get a random vital article, which is probably what they'd want to avoid super niche subjects. {{u|Sdkb}} ^talk 04:22, 30 March 2021 (UTC)

  I'm don't completely understand how Wikipedia works (I have a general enough idea to do what I need here) so could you please explain how it would be harder to do this? Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 18:03, 31 March 2021 (UTC)

  @Blaze The Wolf, click on Special:RandomInCategory/Main topic articles. That's the sort of thing that @Sdkb is talking about, although we don't have the perfect category. I'm doubtful that people want vital articles, however. They might be happier with Special:RandomInCategory/Featured articles or Special:RandomInCategory/Good articles, in which they could find well-written articles, including the chance of something fun. (Wikipedia:Did you know tags are unfortunately in the Talk: namespace, so looking for a random article in, e.g., Category:Dogs Did you know articles, will take you to the talk page rather than the article.) WhatamIdoing (talk) 01:32, 8 April 2021 (UTC)

"Year in review" articles

I've noticed that different topics have different lead sections and different ways to put events, so I would like to make a proposal to fix them. I think this would be added to Wikipedia:Manual of Style/Lists.

PROPOSAL: Year in review articles are articles that review and summarize all of the events in the year.

General

The article should be the name of the year, then in, and then the topic it is referring to. For example, an article talking about politics in 2005 would be called 2005 in politics. The lead section should be just "Events from the year Year in review.", with no links in the lead. Everything should have a bullet point.

Topics

Places

It should start with a section for the monarch and/or leader(s) of the place, titled Incumbents. Then it should have a section titled Events, with subsections for each month if and only if there is at least one event for each month. Only events with specific articles should be listed. For example,

• 1 July – Sony releases a new brand of headphones.

should not go in the article (unless there is a specific article about its release), but

• 20 April – The Deepwater Horizon starts to leak oil.

should go in the list.

Art

After the lead, there should be a section called Works. Every work listed must have a separate article. Do not link to files. It should then include a list of Births, then Deaths in the year, in that order.

— Preceding unsigned comment added by -noah- (talk • contribs) 22:43, 29 March 2021 (UTC)

"Year in review" discussion

@-noah-: That sounds too rigid for many articles. For example, should 2020 in Burkina Faso have four one-line subsections for events by month? Or maybe less if we remove items with no article, which would leave 2010 in Burkina Faso essentially blank. Or maybe make 12 sections whether there are events or not like the ugly 1997 in Burkina Faso? If you want to work on years then you can join Wikipedia:WikiProject Years. PrimeHunter (talk) 23:42, 29 March 2021 (UTC)

@PrimeHunter:. Thanks for the feedback. Do you have any suggestions about what I could change it to? Noah 💬 13:08, 30 March 2021 (UTC)

@-noah-: I'm not active in the area. Wikipedia talk:WikiProject Years seems a better place to discuss it. Note that Wikipedia:WikiProject Years#Scope links to Wikipedia:Timeline standards. Many year articles display Template:Year article header. PrimeHunter (talk) 14:41, 30 March 2021 (UTC)

I think a way to fix this issue would be to only make articles like this if that year was fairly significant for the specific topic. So 2021 in Burkina Faso would only be made if something significant happened that year for Burkina Faso. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 18:08, 31 March 2021 (UTC)

Burkina Faso has 22 million people. People would be screaming about systemic bias if we deleted a whole year of the country "because nothing significant happened". The problem is that we haven't added much to those articles yet, probably mainly due to a shortage of editors from the country. PrimeHunter (talk) 21:59, 1 April 2021 (UTC)

WikiProject Years, under whose purview this should fall under, doesn't seem to be very active currently. In any case, I think further development of such guidelines should probably be based on WP:Timeline standards, which already exists as a former guideline. More specifically, I would strongly oppose the proposed guidance that "The lead section should be just 'Events from the year YYYY.', with no links in the lead." This is in direct contravention of the manual of style. All lists, year lists included, should have a proper introduction as the lead section. That most of them don't is a current failure, not something to be advocated. --Paul_012 (talk) 15:28, 1 April 2021 (UTC)

Including ethnic or religious heritage

When did Wikipedia become the enforcer of the Nuremberg Laws? I notice that people are constantly inserting information to identify subjects as being of Jewish descent, irrespective of whether that is relevant to the person's occupation (say, as a Rabbi or activist on behalf of Jewish causes.) Far, far less frequently is anyone else's religion mentioned. Protestants are never identified as Protestants, unless they are official members of a Protestant Church. Catholics are rarely identified as Catholics. But Jews are almost always identified as Jews.

I would recommend a policy of not including someone's ethnic or religious heritage unless that is directly related to their profession. — Preceding unsigned comment added by Wixifixer (talk • contribs) 20:30, 30 March 2021 (UTC)

@Wixifixer: I think this has to do with reliable sources noting these things more prominently in the case of those who are Jewish. In the western world, anyway, you'd see a similar thing for those who are Muslims, or those who are gay, or any other minority - it's not the default, so it's more worthy of note. Elli (talk | contribs) 01:57, 31 March 2021 (UTC)

@Wixifixer: You hint at a significant reason yourself: Jews are both considered an ethnic and religious group, an ethnoreligious group. Wikipedia:Manual of Style/Biography#Context says: "Ethnicity, religion, or sexuality should generally not be in the lead unless it is relevant to the subject's notability." If reliable sources often mention it then we usually don't omit it from the whole article. PrimeHunter (talk) 12:37, 31 March 2021 (UTC)

I think you would find a very high proportion of the editors adding such information are themselves Jewish, so your implication is wrong. Johnbod (talk) 13:32, 31 March 2021 (UTC)

I don't know. In an earlier period, all those things would also have been true of Catholics--from the majority Protestant point of view. Catholics were not just regarded as a different religious group; most Protestants regarded them as at least an ethnic "other," if not a racial "other." In that world, too, "reliable sources" would have mentioned that one of their subjects was Italian/Irish/Catholic, because that fact would be "worthy of note." Now, tastes have changed. Catholics don't need to be noted as Catholics anymore. I haven't done the research to figure out why that changed. Maybe you guys know. But it's still the same phenomenon. And I just think it's time for us to be more sensitive to it. If many other Jews don't agree with me, that's fine. I think they're wrong. — Preceding unsigned comment added by Wixifixer (talk • contribs) 21:24, 31 March 2021 (UTC)

Getting a Wikipedia biography is usually a sign you are successful. I doubt Jews in general want it hidden that article subjects are Jews if they don't hide it themselves. PrimeHunter (talk) 21:52, 1 April 2021 (UTC)

well, by that logic, we would have to assume that Jews are the only ones who don't want their religious/ethnic identity hidden, while Episcopalians and Presbyterians DO want it hidden? Honestly, what are you talking about? 47.35.240.141 (talk) 16:34, 4 April 2021 (UTC)

What are YOU talking about? I have never in any way indicated that Episcopalians and Presbyterians want it hidden. The discussion is about Jews because that's what Wixifixer posted about. The reason we are more likely to mention whether somebody is Jewish is that it's also an ethnicity, and the reliable sources we use are more likely to mention it. PrimeHunter (talk) 19:43, 4 April 2021 (UTC)

This question has come up fairly often, so we might need to write an essay somewhere. What seems to throw people off is the combination of ethnicity and religion. If you feel like "Jewish" is primarily a religion, then it seems weird to say "He's Jewish" but not "She's Presbyterian". The difference, of course, is that the ethnic background of many Presbyterians is spelled "Scottish", not "Presbyterian". WhatamIdoing (talk) 01:47, 8 April 2021 (UTC)

Deserted WikiProjects around drinks – or anything? Merge, let be, or something else?

I have noticed that there are several WikiProjects and at least one task force revolving around some sort of beverage, WikiProject Spirits, WikiProject Wine and WikiProject Food and drink with task force Beverages that I know of, all of them inactive. It's a real pity as it looks like a lot of effort has been put into them. Perhaps they could be merged in some way. What happened to them? Is it this perhaps a general trend that WikiProjects fade away? How should Wikipedia handle that? --Mango från yttre rymden (talk) 23:59, 31 March 2021 (UTC)

@Mango från yttre rymden: some projects manage to provide context that helps editing – such as guidelines, coordinated reviews and a forum for discussion – and it's those projects that thrive. We've had even big projects fail, such as Wikipedia:WikiProject Culture, but it doesn't necessarily mean that editors will not be able to edit those topics effectively. If a project goes inactive, it's a good idea to link to a related project (see the Culture example). I suppose it would also be possible to revive Wikipedia:WikiProject Food and drink since it has a broad scope and thus many potentially interested editors. By the way, there is also a project on my favorite drink that is active: Wikipedia:WikiProject Beer. – Finnusertop (talk ⋅ contribs) 18:16, 1 April 2021 (UTC)

@Finnusertop: I wasn't implying that WikiProjects are indispensable. I'm just airing thoughts. I'm thinking that all those WikiProjects that revolve around the same wider subject, like food and drink, could be merged into WP Food and drink, that way is it more likely the projects(s) revive and the subject(s) get some more attention. The result could be worth more than the sum of it's parts, as more people are likely to join and engage if there are a few people in the same group, even though each person focus on different things, than if the same amount of people would be separated into one project each. Wine, beer and spirits could be task forces within WP Food and drink.

I have looked around a little, and I get the impression that WikiProjects sprung up like mushrooms at the early 2010s, presumably shortly after the concepts inception, but now have lost peoples interest and half of them are deserted. --Mango från yttre rymden (talk) 19:37, 4 April 2021 (UTC)

A Wikipedia:WikiProject is a group of people. Some groups form for time-limited tasks; others form indefinitely, but then sort of drift apart. That's okay. You are welcome to WP:REVIVE any WikiProject. You do that primarily by banding together with interested wiki-friends. Pages such as Wikipedia:WikiProject Directory/Description/WikiProject Food and drink will help you find interested editors.

Sometimes, two groups will voluntarily merge. This can be helpful, but it is never forced. WhatamIdoing (talk) 01:51, 8 April 2021 (UTC)

Adminship rights debundling

I would like to work on a proposal to debundle all rights that normal users can apply for from the administrative toolkit. I know auto patroller is an example, but I'm not sure what other rights are included in the administrative toolkit that normal users can also apply for. To add a little additional detail, I would like to propose that all user rights aside from the 3 core administrator rights ( Delete pages , block users, and protect pages), are no longer automatically given to administrators, and administrators have to apply for those user rights at the regular forum. ( The point of this is to enable taking away certain rights from administrators without requiring a formal Desysop by Arbcom) The main technical question is whether the ability for an administrator to grant themselves the newly unbundled user rights could be disabled while keeping the ability for admins to grant those rights to other users. I assume that this would probably take a formal RFC, and I am seeking a coauthor to help draft an official RFC proposal. Jackattack1597 (talk) 01:27, 1 April 2021 (UTC)

Can you see any situations where this would have been useful - eg rather than desysop, are there cases where taking away autopatrol from an admin would have been useful? Mostly when arbcom desysop I see it for admins offending some people, rather than creating problematic articles, or using rollback wrongly. Graeme Bartlett (talk) 03:48, 1 April 2021 (UTC)

I can't imagine a situation where an admin is trustworthy enough to block people, delete articles, view deleted material, and protect and unprotect pages, but could not be trusted with rights like rollback or autopatrolled. If they cannot be trusted with those, they certainly should not have the admin tools either. Seraphimblade ^{Talk to me} 05:02, 1 April 2021 (UTC)

If there are enough administrators that feel personally that their article creations should be independently patrolled, they could add themselves to a black list for a bot to unpatrol the articles (if DannyS712 is kind enough to repurpose it). The issue then becomes new page patrollers have to patrol pages admins create, when the vast majority are okay. You’ll unbundle it and find admins handing it back to each other because they are sick of patrolling fine pages. Yes, there is an application but hard cases make bad law.

Maybe there’s admins who never use rollback and could shed that right so as not to need a script to hide it. –xenotalk 05:17, 1 April 2021 (UTC)

Thanks for the ping. @Jackattack1597: "The main technical question is whether the ability for an administrator to grant themselves the newly unbundled user rights could be disabled while keeping the ability for admins to grant those rights to other users." as a matter of fact, it should be fairly easy to do - I wrote the code to do it in December 2019, see gerrit, but it hasn't merged yet because there wasn't a need for it - if enwiki decided to request this feature, it would likely be approved. The relevant phab task is phab:T44072. @Xeno: If any admin wants their articles to be unpatrolled automatically, I'd be happy to file a BRFA, should be fairly easy to code (ridiculously easy since the bot already unpatrols new pages by global rollbackers, so the logic is all there). DannyS712 (talk) 05:26, 1 April 2021 (UTC)

@Xeno: I requested a way for someone to have a session with less than all their access years ago in phab:T153454 - it hasn't taken off. This is currently available in the API, but not the WEBUI. — xaosflux ^Talk 13:23, 1 April 2021 (UTC)

Hmm, looks like I may have had an off-phab on that, since I'm not the author of that one (I think I was the wishlist author for it maybe?) - but same thing. — xaosflux ^Talk 13:25, 1 April 2021 (UTC)

• This is never going to happen as written. Special:ListGroupRights shows the 63 permissions that sysops have. Also the current permission system doesn't allow for direct assignment of a permission, only a group - so they would need a group for each permission and that would overkill - and there is no way we are going to put the community through a "Request for globalblock-whitelist access" process for example. The partial blocks system may grow to allowing someone to be blocked against arbitrary actions, phab:T242541 has some more information on that. — xaosflux ^Talk 11:01, 1 April 2021 (UTC)
  • OK, so I re-read this focusing on the "can apply for" part. Keep in mind that noone gets rights still, they get groups. Still see issues, for example "event coordinators" get "no rate limit" and "add +confirmed to users", but you are proposing removing these from sysops and making them also be event coordinators to get them back? Sysops get "import" , but so do "transwiki importers" and "importers", so sysops would also have to apply for those? Making admins also be a member of a dozen other groups is quite cumbersome, we have role-based access controls for good reason. — xaosflux ^Talk 17:48, 2 April 2021 (UTC)
• I firmly believe that unbundling admin rights is necessary but I also think that it has to be done in stages, rather than all at once. I would do this in the form of introducing new userright groups, for which regular users can apply, rather than taking any userrights away from admins. A good place to start seems to be creating a "vandalfighter" userright. I think it should include the ability to issue short blocks (up to 72 hours) to IP and non-autoconfirmed users engaged in vandalism and severe disruption and the ability to semi-protect pages for short periods (say up to a week). In my observations, the noticeboards such as RPP, AIV and 3RR are now frequently backlogged and it often takes hours to get action from an admin on a report there. But, unlike the admins, vandals don't take a break for hours. To give a specific example, several days ago I observed severe BLP disruption by a dynamic IP on an article on my watchlist, 2019 World Figure Skating Championships. I reported it to RPP,[28] but for several hours the report sat without action even though the article was getting clobbered. In the meantime, other users filed reports at 3RR Wikipedia:Administrators' noticeboard/3RRArchive430#User:117.111.0.0/19 reported by User:Jasper Deng (Result: Block, Semi) and ANI Wikipedia:Administrators' noticeboard/IncidentArchive1062#Urgent edit warring rangeblock needed, but again, nothing was happening. Eventually more than seven (!) hours after my initial RPP report, an admin was pinged directly and protected the page [29] and set a range-block for the dynamic IP. Yesterday, after the block and the semi protection expired, the disruption resumed. We were lucky this time that the same admin was online and responded to a ping quickly, since otherwise it would have again been several hours of chaos. This situation was ridiculous and I am certain that it is not an isolated case. Since we don't have enough admins to respond quickly to AIV and RPP reports, we need to give regular users the ability to do something. Nsk92 (talk) 12:13, 1 April 2021 (UTC)
  • We've looked at "mini-block" and "mini-protect" rights on multiple occasions just in the last 2 years. I think a case can be made, but we've failed to garner firm backing - there are issues that arise with either route. Nosebagbear (talk) 17:15, 2 April 2021 (UTC)

  A proposal for a "vandalfighter" user right was brought up in 2015 and failed to gain consensus. See Wikipedia:Village_pump_(proposals)/Archive_120#Proposed_user_right:_Vandal_fighter. --Ahecht (TALKPAGE) 03:35, 12 April 2021 (UTC)

• I'm lost as to why this makes any sense. Give admin the three most important tools requiring the most trust, but make them ask for a whole bunch of other user rights? And also everything Xaosflux has said. You mention deleting pages as a right they would keep, but would they keep the ability to view deleted pages and to delete only specific revisions? They would still be able to protect pages, but would they retain the ability to edit through protection? None of this seems to have been considered before this was proposed. It is my personal opinion that we already have too many user groups. WP:PERM already experiences backlogs, sometimes fairly substantial ones. This would make that problem worse, much worse actually in that assigning permissions is not one of the three "core" abilities identified in the proposal. So would we need another new forum for requesting that ability? There might be an unbundling proposal I would support, but this is for sure not it. Beeblebrox (talk) 20:04, 2 April 2021 (UTC)

Sorry, I really don't think my original proposal was clear enough at all. Really, what I am trying to propose is that any permission that can be requested at WP:PERM is no longer automatically given to administrators, but it wouldn't affect any other permissions. Instead, administrators would need to request them at WP:PERM. If we were concerned about a backlog, I could propose an RFC on doing this for a few permissions at a time instead of all at once, to avoid a logjam of most active administrators requesting every perm back at WP:PERM at once. Also, to me the point of this is so that if an admin minorly misuses WP:PERMpermissions, the permissions in question can be removed without requiring a Desysop. I'm glad I was pointed to idea lab, because I definitely need to iron this out some more. Jackattack1597 (talk) 23:20, 2 April 2021 (UTC)

• As far as the question of would we need a technical control to allow +sysop to give this to anyone except for themselves - why? If we don't want them to do that, just make a policy and block them if they violate. Such a technical control wouldn't prevent me from giving some flag to my own alt-account for example after all. — xaosflux ^Talk 21:02, 2 April 2021 (UTC)

Good point, on second thought I'll take the technical control out of the proposal, and just include a prohibition on self or alt perm granting in the RFC.Jackattack1597 (talk) 23:20, 2 April 2021 (UTC)

• Per Beeblebrox. based on what Xaosflux said. The user rights system on Wikipedia is already highly granular and confusing to many who don't necessarily work in governance areas or are not involved in them until their creation is tagged for deletion, or they become a target for sanctions for some infringement or another. It would be interesting to define what actually constitute the 'core' rights of adminship. Traditionally blocking, deleting, and protecting may be perceived as the most important but as many admins focus on specific areas of their choice, they might not be the tools that are most often used by all admins - someone with some time on their hands might wish to do some data mining, the results of which could/should have been in the preamble of such an RfC (and might cast a different light on the proposal). While it may be possible to come up with reasons why autopatrolled for admins might need to be reviewed, they are rare. More rights mean more opportunities for hat-collecting, hence the En Wikipedia has probably reached the point where suggestions for further ideas for unbundling only serve for academic discussion, and they possibly fall under WP:SLOP. Kudpung กุดผึ้ง (talk) 23:55, 2 April 2021 (UTC)
• I don't think we should be concentrating on taking away any userrights from admins, despite the currently pending arbitration request. However, I do believe that we should be thinking about creating new userrights that would allow regular users to perform parts of admin functions in areas where there is particularly urgent need and the shortage of admins is already acutely felt. In my observations, one area where the shortage of active admins is already acutely felt is vandal fighting. As I noted above, AIV and RPP are often backlogged for hours and even screaming for help at ANI doesn't necessarily produce a sufficiently fast response. That's why I suggested above creating a "vandal fighter" userright with the ability to issue short term blocks to non-autoconfirmed editors and to semi-protect pages for up to a week. Another such area is CfD. As it turns out, the persistent backlog there is so bad, that admins have a de-facto practice of allowing non-admins to perform NAC "delete" closures of CfD discussions, disregarding WP:NACD. So creating some kind of a userright (if technically possible) allowing regular editors to perform some low-level deletion functions, such as deleting expired PRODS and maybe deleting categories in non-controversial cases, plus possibly something else, would be useful. Nsk92 (talk) 00:34, 3 April 2021 (UTC)

  I would probably oppose any effort to unbundle the three "core admin rights" (delete, block, protect) per the rationale I wrote at WP:COREADMIN. It's true that AIV, RFPP, and other areas have been backlogged lately, but I see this as more of a short-term problem that can be solved by promoting two or three additional administrators who are specifically interested in those areas. A new user group would likely have unintended consequences and would be an ill-advised long-term solution to a short-term problem. Mz7 (talk) 01:58, 3 April 2021 (UTC)

  You are completely wrong. The arguments in WP:COREADMIN are abstract, but the problems I am talking about are concrete and practical that need addressing and are getting worse. And they are not "short-term", far from it. I have observed backlogs at RPP and AfD for a while and they have been quite chronic for at least over a year. As I said, things at CfD have gotten so bad that they now allow NAC "delete" closures in violation of WP:NACD. I haven't paid as close attention to AIV but I would bet good money that if one checks the data for the last year, we'd find that serious backlogs are persistent. All of these problems are only going to get worse if unadressed (just look at what's happening at Commons). The supply of new admins has slowed almost to nothing. At the same time we are losing quite a few admins due to retirements, inactivity, desysops, etc. At the same time WP as a project is getting more and more complicated. The number of admin tasks increases and the level of technical expertise required to perform them increases as well. Our current model of adminship is simply unsustainable and we are already seeing signs of things coming apart at the seams. Nsk92 (talk) 13:31, 3 April 2021 (UTC)

  I'm actually unopposed to the narrow proposal of allowing non-admins to close CfDs as "delete" if that would actually reduce a chronic backlog. In the past, I have supported such a strategy for WP:RFD, see [30]. Doing this would not require a technical change to the admin toolset, and any such close would eventually have to be reviewed by an administrator anyway when they go to press the "delete" button.

  On the issue of WP:AIV, I am an active admin there, and in my experience, whenever that page is filled with a backlog, it is not because there are a ton of urgent requests waiting for attention, but rather because editors have overfilled it with marginal reports that should really be declined as "not vandalism, take it to ANI", "user incorrectly or insufficiently warned", or "no edits since last warning". From a psychological perspective, it's harder to decline a report than to action the report because it requires taking a confrontational stand, which is why it might take longer for someone to actually say something (nowadays we even have a bot that clears stale AIV reports automatically). I'm not as much of a regular at WP:RFPP, but when I worked there a few weeks ago when there was a chronic backlog, it was the same thing: I declined the wide majority of the backlogged reports rather than taking action on them.

  What this tells me is that the truly urgent issues at AIV and RFPP—e.g. vandals who spam dozens of changes per minute on a variety of articles—already get dealt with quickly in the wide majority of cases, and it's the less urgent, more marginal reports that are the ones that form a backlog, the ones that wouldn't really benefit from non-administrator intervention anyway. Mz7 (talk) 16:11, 3 April 2021 (UTC)

  I think that admins' rights should stay as they are, unless anyone proposed automatically assigning edit filter manager to administrators, which I support. No unbundling, no debundling, our current number of administrators is too fragile. 🐔 Chicdat  ^{Bawk to me!} 10:08, 3 April 2021 (UTC)

• At the moment, I would probably look favorably upon a proposal that would unbundle only autopatrolled, but allowing any administrator to self-grant to themselves without restriction, similar to edit filter manager. This would allow administrators who are not as experienced as others in content creation to get WP:NPP feedback on their article creations if they wish to do so. Other rights like rollback and page mover probably don't need to be unbundled. Mz7 (talk) 01:58, 3 April 2021 (UTC)

  @Mz7: not sure this is really needed - if an admin can't create a page that would pass basic new page patrol - they really shouldn't be creating pages - but if they just want feedback don't they now have the option to "unreview" the page to throw it back in to the queue? — xaosflux ^Talk 15:38, 3 April 2021 (UTC)

  I suppose that's fair. I guess it goes back to that contentious question at WP:RFA, which is whether considerable experience in content creation is needed to be an administrator. Currently, the guideline for granting autopatrolled to non-admins is prior creation of 25 valid articles, not including redirects or disambiguation pages. I know I didn't have 25 articles created when I did RfA (although I did have two GAs, but I know some admins who were promoted with much less). Mz7 (talk) 16:11, 3 April 2021 (UTC)

  @Mz7: that is a good guideline, but the primary component of patrolled new pages is that they aren't a CSD - which admins are expected to be able to recognize (i.e. that it doesn't violate "Wikipedia's criteria for inclusion, copyright violations, biography of living persons violations, conflicts of interest, and advertising.") If we are electing admins that really can't tell if a page is a violation of these policies we have a much bigger problem; not to mention that admins are also patrollers/reviewers themselves. — xaosflux ^Talk 20:08, 3 April 2021 (UTC)

  @Nosebagbear mentioned this point at WP:VPP recently. The problem is, I don't think he's correct. When he accepts an article at Wikipedia:Articles for creation, he's making an informed judgement about whether it has at least an 80% chance of surviving Wikipedia:Articles for deletion. He'd like a second or third person to go through the same assessment process. However:

  • Editors' subject-matter expertise varies wildly, so a second opinion may be worth less (or worthless).
  • He says that he's aiming for an 80% chance of the article surviving AFD, but exactly 0% of the 90 AFC drafts he's accepted have been deleted at AFD. Only three out of the 90 have been deleted. Two of the 90 articles were moved back to the draft namespace by someone else and were deleted as abandoned drafts (one of those subjects was moved to the draft namespace for non-notability reasons) and the third was deleted at the author's request. All three of those are eligible for a WP:REFUND.

  So I'm doubtful that we'd be getting any value out of a second opinion. In fact, maybe what we really need is to tell AFC folks that if none of the articles they accept end up at AFD, then that's a sign that their standards are too high. At any rate, what I conclude from this review is that if Nosebagbear accepts a draft at AFC, there is no point in asking another editor try to find a reason to delete it. WhatamIdoing (talk) 05:06, 6 April 2021 (UTC)

  AFC is not new page patrol. AFC assesses notability and tends to be strict, while NPP lets more stuff through with clean-up tags (while catching obvious speedy deletions). Following this, anyone competent enough to be an admin should have their pages survive NPP. Elli (talk | contribs) 10:05, 7 April 2021 (UTC)

  @Elli, well, that's what I think, too, but Nosebagbear is an admin, has a much lower deletion rate for the articles he accepts at AFC than he say's he's hoping to achieve, and he still wants the NPP folks to double-check his work. It doesn't seem like a good use of NPP's time to have them re-check the articles that he's already approved. WhatamIdoing (talk) 01:26, 8 April 2021 (UTC)

  @WhatamIdoing: well tbh, for admin-created articles I'm likely to approve them if they aren't blatant vandalism or whatever, since I trust that an admin would have an understanding of the notability policy. So it's not that big of a problem, more just pointless. Elli (talk | contribs) 01:56, 8 April 2021 (UTC)

  I agree that it's pointless. WhatamIdoing (talk) 02:11, 8 April 2021 (UTC)

  And that's really why I think rights de-bundling is pointless. Anyone trusted with blocking or page deleting should be trusted with stuff like article creation and rollback. If they've screwed up enough to merit not having those rights, they should not be an admin. Elli (talk | contribs) 02:22, 8 April 2021 (UTC)

• Please see Wikipedia:Unbundling administrators' powers for some history. -- RoySmith (talk) 16:10, 3 April 2021 (UTC)
• Remember our problem is not enough candidates running for adminship. Each time we unbundle part of the toolkit we remove another route to adminship, and once people become admins they often go on into other useful areas of adminship. I'm not aware of a specific right that could be unbundled in the way that rollback, file move and template editor were. We are now left with things that go together - like you can't set autopatroller without looking at someone's deleted edits. ϢereSpielChequers 13:10, 4 April 2021 (UTC)
• I would strongly support this proposal, if it were a proposal. It does not come up often of course, but there have been instances of an administrator abusing a minor userright in a way which would normally be addressed by simply removing that one privilege, but because the user is an administrator the remedy is desysopping, which at present can only be done through a lengthy Arbcom case. If we kept the admin toolset to the userrights that are exclusive to admins, along with granting the usual non-admin userrights at the time of a successful RFA, then this is a lightweight change (other than for 'crats, who I'm sure can handle ticking a few extra boxes a few times a year, or it could be done by script) which also improves our processes. Ivanvector's squirrel (^trees/_nuts) 13:51, 10 April 2021 (UTC)

Thank summary

Currently we can thank users. We thank them for a specific edit, or several. But what if we wanted to say why we were thanking the user? What if we wanted to add an additional comment? Similar to edit summaries, I think it would be nice if there were thank summaries. I've thanked a lot of users, and a lot of users have thanked me, but sometimes I'm wondering, what about the edit was so great? I know that thanks should be shorter than, say, barnstars, but these thank summaries would just be optional. 🐔 Chicdat  ^{Bawk to me!} 10:15, 3 April 2021 (UTC)

• I have no comment on the merits of this issue, but I believe it would require developer time to implement. Dev time is a scarce resource, which I feel could be better spent elsewhere. ƒirefly ( t · c ) 10:59, 3 April 2021 (UTC)
• My take... automated thank you messages are rather impersonal. I appreciate it when someone composes a more personalized message, and posts it on my user talk page. Much more meaningful to receive than an automated message. Blueboar (talk) 11:39, 3 April 2021 (UTC)
• Some users would use it for other things, e.g. harassing or canvassing. Would the summary be public or private? If it's private then should some user groups like administrators be able to see it? We value transparency. As long as we don't have private messaging (I know we have email), I don't think we should introduce a similar feature for an unimportant official purpose. If it's public then you may as well post to them or ping them somewhere. PrimeHunter (talk) 11:42, 3 April 2021 (UTC)

  It would be public, viewable to other users (apart from the two, the performer and the receiver) through thanks logs. 🐔 Chicdat  ^{Bawk to me!} 12:41, 3 April 2021 (UTC)

• Personal messages are always appreciated—please feel free to put a note on the user's talk page and let them know exactly what is so great about the edit in question! The thank you function works well as a way to give a quick indication of appreciation. In terms of cost-benefit ratio, I wouldn't want more effort spent enhancing it to replicate the functionality of editing a talk page. isaacl (talk) 15:56, 3 April 2021 (UTC)

Creating Articles for Restoration

I have had this idea for a while now, and I have been considering that we could make Articles for Restoration to vote on whether an article that has been deleted should be restored, much like Articles for Deletion. There have also been some pages that I would support restoring such as List of people with autism spectrum disorders and New England Independence Campaign. I am not sure if this has been proposed before, though I feel like this should be implemented. Blubabluba9990 (talk) 21:20, 3 April 2021 (UTC)

• @Blubabluba9990: We already have this at Wikipedia:Deletion review. Lettler^{hello • contribs} 22:09, 3 April 2021 (UTC)
  • Ok. Blubabluba9990 (talk) 22:21, 3 April 2021 (UTC)
    • And I just noticed Requests for Undeletion.

Note that Wikipedia:Requests for undeletion is meant for articles that were deleted via WP:PROD or after AfDs closed as WP:SOFTDELETE. Something like Wikipedia:Articles for deletion/New England Independence Campaign definitely won't qualify. Nsk92 (talk) 22:40, 3 April 2021 (UTC)

• There might be a benefit to a page for discussion, but we certainly wouldn't want a new forum to !vote at. For a page like New England Independence Campaign, you can create a WP:DRAFT article that addresses the reason for deletion (the lack of reliable independent sourcing). For List of people with autism spectrum disorders, you should probably just not until you're more familiar with editing WP:BLP topics. User:力 (power~enwiki, π, ν) 22:24, 3 April 2021 (UTC)

Pronouns in Infoboxes

I believe that it could be useful to include a person's pronouns in the "infobox"/"biography" section that appears on the side specifically for people.

While this is a per-page thing, having this become standard across pages that refer to a person would be extremely helpful in having it implemented site-wide. — Preceding unsigned comment added by Itscrossboy (talk • contribs) 09:16, 5 April 2021 (UTC)

I don't believe so. The "they/them" crowd's pronouns are announced in their articles. If Wikipedia was like this: "John Doe was born in 2000. In 2010, he got a job. In 2020, she founded a pizza shop. In 2021, they expanded their menu." then that would be useful. But since it isn't, it isn't. 🐔 Chicdat  ^{Bawk to me!} 10:09, 5 April 2021 (UTC)

• Oppose - It is actually very rare for notable people to publicly state their preferred pronouns, and even rarer for sources to comment upon that preference. Thus, we often won’t know what to put in this parameter.

The problem is that many of our editors (especially newer editors) think that we must fill in every parameter in an infobox... and to do so the editor will either guess, or use the pronouns that the editor assumes the subject will prefer (or worse, an editor will add a pronoun that the editor prefers) - and that would violate WP:No original research. In cases where we do know a bio-subject’s preference, we can simply use it in the text of the article - as is appropriate. Blueboar (talk) 12:25, 5 April 2021 (UTC)

• I don't think this is a good idea, we are not wikidata - so putting every possible attribute about a person in a box isn't necessary. — xaosflux ^Talk 12:59, 5 April 2021 (UTC)
• Oppose as unnecessary and likely to be a magnet for disruptive editing. ƒirefly ( t · c ) 13:17, 5 April 2021 (UTC)
• Oppose due to it being an unnecessary addition, and a huge potential for edit-warring. JackFromReedsburg (talk | contribs) 19:42, 10 April 2021 (UTC)
• Oppose Simple situations can just be used in the text. More complex or unusual uses will require explanation in the text, and will not be adequately covered in the infobox. This will not be a common thing to do at all. Having the parameter in the box will be almost always unhelpful and at the same time pushing a political point of view. Graeme Bartlett (talk) 20:52, 10 April 2021 (UTC)

Image use proposal

I'd like to deprecate the use of nude or sexually explicit photographs uploaded by anonymous single-purpose accounts. (This would include both Wikimedia accounts and accounts on other image hosting websites such as Flickr.) I'd appreciate any thoughts or advice on formulating an RfC. Cheers, gnu57 15:06, 5 April 2021 (UTC)

@Genericusername57: do you have any statistics as to the prevalence of this condition? Keep in mind that it should only be about local uploads here on the English Wikipedia as any uploads to Commons are outside the scope of enwiki RfC's. — xaosflux ^Talk 15:26, 5 April 2021 (UTC)

...and I don't see how we can police an unrelated site like Flickr. I know that this is the village pump for discussing vague ideas, but I still think that you should think about this a bit more before starting a discussion. I'm pretty sure that our policies and guidelines already prevent Wikipedia editors from including gratuitous nudity or sexually explicit content, but there are some articles where such content should be expected. Phil Bridger (talk) 17:44, 5 April 2021 (UTC)

@Xaosflux: Commons has no rule against hosting mugshots, but the English Wikipedia places limits on their use in biographies of living persons (WP:MUG). I am proposing something similar: not that we somehow prevent Commons from hosting these photos, but rather that we stop using them to illustrate English Wikipedia articles. As far as statistics go, I'm not sure. Using Petscan to intersect the Commons categories "Human genitalia" and "Self-published work", then subtracting out various art and diagram categories and the "User categories" tree (most photographers with dedicated categories are non-anonymous) yields several thousand files, several hundred of which are in use on the English Wikipedia. Someone better at SQL than I am could probably use Quarry to figure out what percentage of the files in Commons category trees like "Nudity" and "Sex in humans" were uploaded by accounts with fewer than, say, 50 global edits.

@Phil Bridger: The problem is that we have no way of verifying that the subjects consented to their photos being published on the internet. Commons and Flickr both let anyone with an anonymous throwaway account upload sexually explicit content. For illustrating English Wikipedia articles about human anatomy, medical conditions, social and artistic nudity, etc, there are plenty of high-quality, freely licensed images from reputable photographers and institutions. There's really no need to keep using sketchy amateur snapshots from anonymous randos. gnu57 14:26, 6 April 2021 (UTC)

Disagree with doing this on enwiki - the proper place to make this decision is Commons (there, I do generally support deleting non-education nudity uploaded by new users). Elli (talk | contribs) 09:57, 7 April 2021 (UTC)

• This is pretty well covered by WP:GRATUITOUS. If you're proposing that we somehow filter uploads before they appear, I'm not sure we can do that. Ivanvector's squirrel (^trees/_nuts) 14:00, 10 April 2021 (UTC)
  • @Ivanvector: WP:GRATUITOUS addresses the content of images, not their provenance. It would be counterproductive to point out specific examples here (hey everyone, take a look at this potential privacy violation), but I can think of several images currently in use that aren't all that gratuitous in context (surely someone reading about human anatomy can expect to see images of the human body), but still might embarrass or distress the subject if they were posted on the internet without the subject's permission. Cheers, gnu57 16:13, 12 April 2021 (UTC)

Audio Summaries

It would be very helpful for many people who are illiterate (~14% of the world), blind, or can't understand the content of Wikipedia pages (simple English Wikipedia is, unfortunately, not heavily updated and contains few articles compared to Wikipedia) if there were short (~1-5 minute) audio summaries of pages at the top that can be listened to. The audio summaries would be created by any confirmed users and then "Audio Summary Reviewers" (new permission) would approve the summaries. I know there are audio recordings of some pages, but this is just a reading of the page as opposed to a summary; a summary would serve a separate, and arguably, more broad purpose. Thoughts? Ajshul 😃 02:01, 6 April 2021 (UTC)

What do you expect people to get from a short audio summary that they can't get from using text-to-speech tools on the first few paragraphs of an article? WhatamIdoing (talk) 05:12, 6 April 2021 (UTC)

Illiterate people are mostly in countries that dont have great access to the internet. Which you need to access Wikipedia. The priority wouldn't be high, but this could work if enough people would volunteer. Just... dont expect it to happen anytime soon. Arsonxists (talk) 14:05, 6 April 2021 (UTC)

I also think that for larger articles (for which I foresee this being the most useful), a 1-5 minute audio summary would be extremely helpful for those who can read but just want to gain some knowledge without having to pick through a large article. It can also be great for people who just want to learn something new for fun quickly while doing another task (similar to a short podcast). I also think that for some very long articles about very complex topics (mathematics, sciences, philosophical theories, etc.) if an audio recording with a summary can be provided, it would help a lot of people gain a deeper understanding. By no means do I think that if implemented, audio recordings will appear overnight on all articles, but by developing a framework for this to be possible, I think it would be incredibly helpful; further, with certain permissions needed for posting and reviewers needed to approve, I foresee few problems arising from this: only upsides. Ajshul 😃 17:04, 6 April 2021 (UTC)

That is, mostly better reasoning. Audio transcripts do exist already (solved the illiteracy problem), so I think a text based summary would work better. Also, I don't think that the permissions would be nessecary for a text based summary system and way too infuriating, as audio is way harder to make new versions of then text. Arsonxists (talk) 18:32, 6 April 2021 (UTC)

I think a text based summary would work better that is what the MOS:LEAD is supposed to be... Elli (talk | contribs) 22:44, 7 April 2021 (UTC)

Agreed, which is why I think audio would be best. An audio summary would allow people to learn about the subject without having to devote their entire attention to reading. As for the revisions, the audio would only cover a broad summary and not any extremely new or controversial information; similar to what is currently being done with Spoken Wikipedia. Ajshul 😃 22:41, 8 April 2021 (UTC)

Perhaps you can work with some people at Wikipedia:WikiProject Spoken Wikipedia on this idea. isaacl (talk) 19:27, 6 April 2021 (UTC)

I don't see why a new permission would be necessary here. Elli (talk | contribs) 09:56, 7 April 2021 (UTC)

This isn't even a problem (we have something called a "lead" that summarizes the content of the article, and readers can use TTS tools if they need help reading the lead. (Illiterate or blind people most likely aren't reading WP) Lettler^{hello • contribs} 14:48, 10 April 2021 (UTC)

Lettler, blind people most likely aren't reading WP Blind people read and edit Wikipedia. They even have their own usergroup: https://meta.wikimedia.org/wiki/WikiBlind_User_Group Vexations (talk) 16:02, 10 April 2021 (UTC)

I did not say that there were no blind people reading or editing WP. Either way, they are a minority of our readers and editors, so they most likely should just use an external TTS tool if they need help reading articles. Lettler^{hello • contribs} 01:29, 11 April 2021 (UTC)

Watchlist/Notifications for specific sections

Please let me know if this is already a feature, but I think it would be incredibly helpful if a user could add a specific section of a talk page or other discussion-based page (like this one) to their watchlist. This would make it so they don't see notifications pertaining to different sections that they may not care much about. Ajshul 😃 02:12, 6 April 2021 (UTC)

@Ajshul, please see Wikipedia:Talk pages project. WhatamIdoing (talk) 05:12, 6 April 2021 (UTC)

This is a long-term wish list item, see phab:T2738 for more on it. — xaosflux ^Talk 14:29, 6 April 2021 (UTC)

@Ajshul: This is being worked on as part of DiscussionTools, see phab:T263820. In the interim, User:Enterprisey/section-watchlist provides the same functionality as a user script. – SD0001 (talk) 16:29, 6 April 2021 (UTC)

@SD001 and @Xaosflux – my apologies. I was not aware of these projects.

Obtaining BLP photographs from their subjects

Wikipedia articles about living people tend to have portrait pictures in the infobox that are rather low-quality compared to what one would expect on the internet in 2021, or in many cases no picture at all. I suppose this is due to the difficulty of finding a freely-licensed image given that Wikipedia lacks professional photographers. (The exception is government officials, who tend to have official portraits.) I wonder if any thought has been given to creating a streamlined way for subjects of BLP articles, or their representatives, to contribute a freely-licensed image to Wikipedia for use on their article, and then advertising this in some way. While some subjects are doubtless too busy to entertain such a request, given the ubiquity of Wikipedia in today's world I would be surprised if no BLP subjects were willing to contribute an improved picture for use on their article. CapitalSasha ~ talk 22:55, 7 April 2021 (UTC)

@CapitalSasha: there is Wikipedia:A picture of you. I agree that the process should be improved. Elli (talk | contribs) 23:16, 7 April 2021 (UTC)

Thanks, I wasn't aware of that page! I wonder if a dedicated email address could be set up, connected to OTRS somehow, so that all was required was to send an image attached to an email. That would be a lower barrier to entry. CapitalSasha ~ talk 00:41, 8 April 2021 (UTC)

@CapitalSasha: that sounds like quite a good idea. Elli (talk | contribs) 01:23, 8 April 2021 (UTC)

@CapitalSasha and Elli: There actually is a dedicated email address set up and connected to OTRS: photosubmissionwikimedia.org. See Wikipedia:Contact us/Article subjects for the details. Given that it was so hard for people to find this, it's probably not being used to its full potential, but it is there. Vahurzpu (talk) 01:04, 12 April 2021 (UTC)

@Vahurzpu: thanks - I've added this to Wikipedia:A picture of you (see the section "By email"). Elli (talk | contribs) 01:20, 12 April 2021 (UTC)

I didn't know until now that the page Wikipedia:A picture of you exists but it surprises me that the page doesn't mention the simplest way someone can provide a free picture of themselves. Many people maintain personal webpages and have photos of themselves posted there. They almost always own copyrights to those photos. All they need to do is post a note at their webpage saying that the copyright for a particular photo is being released under a suitable free license (like CC-by-sa 4.0), with the necessary basic info (where and when the photo was taken). Then any other Wikipedia editor can upload the photo to Commons or to Wikipedia directly. I think that's easier than asking BLP subjects to upload their photos to Commons or to e-mail something somewhere. Nsk92 (talk) 01:40, 12 April 2021 (UTC)

@Nsk92: feel free to update said page. It could certainly use some help. Elli (talk | contribs) 02:03, 12 April 2021 (UTC)

How about making all requests for comments into subpages of the RfC page?

All AfD listings that are not jokes are as subpages of the main Wikipedia:Articles for deletion page. In that manner, I propose that all future Requests for Comments be mandatorily made subpages of Wikipedia:Requests for comment. I also propose that titling of future RfCs be standardised with the following format:

• Wikipedia:Requests for comment/In re [page name] for RfCs that concern one page. (feel free to replace "in re" with words like "regarding", but its replacement should be standardised across the board).
• Wikipedia:Requests for comment/[question] for RfCs on general matters that cannot be easily classified as only concerning a specific/specific pages.
• Wikipedia:Requests for comment/[proposal] for proposals.

Ideally there could be an RfC template (yes, I know about Wikipedia:Requests for comment/Example formatting) that a user would sub into when making an RfC (c.f. {{afd2}} where the only things you have to do is to type your reasoning, the page name, and its category). A side benefit of standardisation is that it could open the door for WP:Twinkle to also cover RfCs (though this is not the main reason for my proposal). Thank you, DePlume (talk) 04:17, 8 April 2021 (UTC)

I don't see a problem this solves. Elli (talk | contribs) 05:27, 8 April 2021 (UTC)

Right now the RFCs are all over the spot. Some are in Articles' talk pages, another bunch as subpages of WP:RfC, and yet another bunch as subpages of various Project (not Project talk) pages. Making all of them subpages of WP:RfC will greatly enhance unity by having one instead of 100+ locations for them. --DePlume (talk) 05:34, 8 April 2021 (UTC)

DePlume I guess it just seems unnecessary given the variability in "officialness" or whatever of RfCs. Is a subpage really needed instead of a post at WP:RSN or whatever? Feels excessive. Elli (talk | contribs) 05:50, 8 April 2021 (UTC)

I am not asking for the RfCs to be posted twice. It is just once, like the AfD nominations. NotReallySoroka (talk) 01:16, 11 April 2021 (UTC)

I think there are some benefits, like having RfCs being found and created slightly faster with Twinkle support and there not being 15 pages for the same reason. I can see why it could be unessecary, but it could have moderate benefits. Arsonxists (talk) 14:58, 8 April 2021 (UTC)

• There are benefits of holding RFCs about particular articles on article talk pages, such as having previous discussions and the article itself close at hand, but there are other RFCs that are not about particular articles, so they need to go elsewhere. As long as RFCs are registered and advertised at a central location I don't see any benefit to standardising where the discussion itself is held. I don't think we should be making decisions on the basis of what is easy to implement in Twinkle (does it go to the library to find good sources and add them to articles yet? If so I might consider using it) but anyway I don't see what would be too difficult about having it add the correct RFC headers wherever a discussion is held, if it is really too burdensome for people to do it themselves. Phil Bridger (talk) 15:25, 8 April 2021 (UTC)
  • Thank you, but Twinkle is merely a collateral benefit, not the main reason. DePlume (talk) 17:31, 8 April 2021 (UTC)
    • Then what is your main reason? I don't see one in your initial comment here, but merely an assertion that we should do this. Phil Bridger (talk) 17:54, 8 April 2021 (UTC)
      • Phil Bridger There are unity (prevents RfCs from being scattered all over Wikipedia), convenience (those who wish to reply to an RfC can easily find some to respond to), and standardised format, just to name a few. Sorry for replying this late, NotReallySoroka (talk) 01:15, 11 April 2021 (UTC)
        • We want AfD's to remain visible if the article and talk page is deleted, so they aren't held on the talk page. RfC's don't have that concern, and they aren't transcluded on pages like Wikipedia:Articles for deletion/Log/2021 April 11. I don't see sufficient reason to remove RfC's from the page they mostly concern. And whether to designate a discussion as an RfC is often an arbitrary decision. PrimeHunter (talk) 11:18, 12 April 2021 (UTC)
• I see the point made, RFCs are all over the shop. Unless you have every area in your watch list, or spot it on the centralised discussion board, it would make sense to make it to centralise to one location. Davidstewartharvey (talk) 13:52, 12 April 2021 (UTC)
  • Current RfCs are listed at Wikipedia:Requests for comment/All. PrimeHunter (talk) 14:13, 12 April 2021 (UTC)
  • Having RfCs exist as subpages of one page will make them easier to search (from that point on), but I don't think it'll affect how easy it is to notice new RfCs. Using the bot-maintained page that lists all current RfCs would still be the best way. And it's a bit late to try to improve searching, since there is already a long history of requests in other locations that people would still have to search through. (I don't think it's worth the effort to move them and fix all links to them.) isaacl (talk) 15:08, 12 April 2021 (UTC)
    • As I said, whether to designate a discussion as an RfC is often an arbitrary decision. I think it's of limited value to make it easier to search old RfCs. PrimeHunter (talk) 15:35, 12 April 2021 (UTC)

      Yes, I read your comment. I apologize for not discussing the desirability of searching discussions not arbitrarily marked as a request for comment, which I think is important as well and so limits the value of being able to search one set of tagged discussions. isaacl (talk) 20:01, 12 April 2021 (UTC)

      I'm just trying to weigh the use cases for searchers. How often do I specifically search for RfC's about something? Never. How often do I search archives of a page for discussions which would normally belong there? Often. I think an "RfC space" will make the discussions harder to find, not easier, for the typical searcher. Maybe they get lucky and hit a notification about the RfC in the archives they search, but the chance is much better if the actual discussion is there. PrimeHunter (talk) 23:18, 12 April 2021 (UTC)

      I don't favour this proposal, for the reasons I specified (don't see how it helps people notice new RfCs or helps with searching given the current situation), but I didn't want to ignore a potential way of interpreting the proposer's viewpoint on the proposal's advantages. isaacl (talk) 23:30, 12 April 2021 (UTC)

I believe it is preferable to keep most RfCs, particular article RfCs, at the corresponding talk pages. That's where one can view discussions leading to a particular RfC, the relevant talk page archives, etc. However, I also think there is some benefit in having old RfCs searchable. An RfC is a formal, consensus determining, step in the dispute resolution process. Although the initial decision to label a particular discussion as an RfC is often arbitrary, the decisions reached in RfCs carry greater weight afterwards and their conclusions are viewed as more authoritative, compared to ordinary talk page discussions. So I think it might be worthwhile to get the bots to somehow index old RfCs in a systematic fashion after they are closed or expire. Nsk92 (talk) 23:58, 12 April 2021 (UTC)

Dark mode

Just noticed that XTools has switched to an all-black background. I really dig it. Are there any current efforts/pushes to add a dark mode to Wikipedia? Shouldn't be too difficult, right? ~ HAL333 01:44, 10 April 2021 (UTC)

@HAL333: it is actually very difficult - see many many open tasks related to that idea though. — xaosflux ^Talk 09:14, 10 April 2021 (UTC)

This has been implemented on the mobile version. Sungodtemple a tcg fan!!1!11!! (talk) 00:22, 11 April 2021 (UTC)

HAL333, Ugh, I hope not. Just wait until your eyes are a couple decades older and you need all the contrast you can get. -- RoySmith (talk) 23:25, 12 April 2021 (UTC)

Identifying extra line breaks

One of the most common errors I see in stubs and similar pages is erroneous instances of double line breaks. Surely there's some way to automatically identify this and flag pages that might have the error for review? {{u|Sdkb}} ^talk 03:53, 10 April 2021 (UTC)

I think there's already a bot that does it. It might also be a built-in WP:AWB task. Ivanvector's squirrel (^trees/_nuts) 14:03, 10 April 2021 (UTC)

New user 'problem'

This might be in the wrong place; feel free to move the discussion: Recently I've been seeing many new users get bitten by more experienced users, such as in this diff. In it, User:David notMD thought the user's edit was vandalismunconstructive, so they reverted, and now the new user is saying 'And this is now my really last edit in any article' about a word choice. Wikipedia is supposed to be an open place, but all too often at talk pages, RfCs, AfDs, etc. there is just a lot of harshness, if not intentional, that drives away even experienced users. Is there a way to make the Wiki more open?

Ideas:

1. Whenever someone signs up, guide them through a mandatory tutorial. This is hitting two birds with one stone: Vandals will be discouraged from creating socks, and new editors won't try something like editing a featured article too soon.

2. Make Wikipedia's policies and guidelines more accessible to new users. For example, upon creating an account, new users would be directed to a page which summarizes policies and isn't too long, so that they understand what to do and what not to do.

I'm sure doing this will help problems with vandals and subtle vandalism. Anyone have any other ideas about this? Sungodtemple a tcg fan!!1!11!! (talk) 00:39, 11 April 2021 (UTC)

• I don't think anyone has a suggestion for a good "mandatory tutorial" or a short summary of all important policies. Requiring a "mandatory tutorial" certainly won't "make the Wiki more open". Many contributions from new users are not constructive and have to be reverted, no desire to be nice will change that. And your example is not as you describe; nobody said the initial edit was vandalism, and the editor who made it has been here over a year with over 500 edits. User:力 (power~enwiki, π, ν) 01:14, 11 April 2021 (UTC)
  • Well, looks like my principles and the Wiki's principles are conflicting here. I'd prefer improvement, but the Wiki prefers openness, likely because they don't want people complaining that Wiki editors are a vested community. Sungodtemple a tcg fan!!1!11!! (talk) 19:13, 11 April 2021 (UTC)

FYI - The editor was accusing me of vandalism for having reverted additions to "See also" at more than one article. I engaged the editor in discussions at the Talk pages of the articles in question and at Teahouse. Furthermore, V is not a new editor, having been actively editing since April 2019. David notMD (talk) 01:23, 11 April 2021 (UTC)

• This doesn't look like any sort of problem at all. The new editor was told that there was a disagreement about their edit and that the article talk page was the place to discuss it. If the user then calls the disagreement vandalism and refuses to take advice about the appropriate place for discussion then that user is unsuited to be editing Wikipedia, which involves civil disagreement and discussion. It is better to be told that sooner rather than later. Phil Bridger (talk) 19:35, 11 April 2021 (UTC)

WikiProjects that link to articles in their talkpage banners

This has been a minor annoyance to me, so I'm wondering if there's any opposition to this. Special:WantedPages is pretty much useless because talkpage banners, for example {{WikiProject Northern Ireland}}, link to articles such as Shauna Gunn (which is, for the record, salted). Not only does this make WhatLinksHere of those pages useless, it makes WantedPages useless, as it mainly tracks what happens to be linked in WikiProject banners.

Additionally, this slows down loading (though small, it can add up) of any pages tagged with the banner, since it pulls in information that hardly anyone on that talkpage cares about.

Therefore, I would suggest that WikiProject banners are not allowed to include lists of tasks in them, and must instead only link to such lists. Elli (talk | contribs) 20:57, 11 April 2021 (UTC)

@Elli: I suggested that at Wikipedia talk:WikiProject Council/Archive 21#Proposal: Disallow transcluded to-do lists in 2015. There was support but also a suggestion of wider notification about the discussion. That wasn't done and the discussion died without action. I don't want to spend time on this now but others are welcome to use content from my post if they revive the issue. PrimeHunter (talk) 22:21, 11 April 2021 (UTC)

@PrimeHunter: seems like it gained support so... would an RfC be necessary, or simply asking the relevant WikiProjects? Elli (talk | contribs) 22:23, 11 April 2021 (UTC)

@Elli: An RfC may be best. It affects many other users than the WikiProjects which use the system. PrimeHunter (talk) 22:36, 11 April 2021 (UTC)

@PrimeHunter: ugh, that means I have to do writing :( I'll probably start one later this week, then Elli (talk | contribs) 22:38, 11 April 2021 (UTC)

• I agree that WikiProject banners shouldn't be linking to to-do lists. It's not because of Elli's rationale, though, but rather that it's just not appropriate to be advertising tasks you'd like for your project to get done at talk pages that have no connection to those tasks. "Spam" would be the most blunt way to put it. It's part of the larger problem of talk page banner bloat. Regarding Elli's rationale, Special:WantedPages exists to serve the encyclopedia, not the other way around, so I don't buy that we should ban the lists to get it functioning better. Rather, I would suggest technical solutions, such as making Special:WantedPages only go by mainspace transclusions, or identify when a page is only showing up because it's part of a widely-transcluded template. {{u|Sdkb}} ^talk 22:41, 12 April 2021 (UTC)
• I agree with Sdkb on the argument that these lists should be removed on the grounds of banner bloat. I doubt the utility attained in recruiting editors justifies inserting non-relevant information on every talk page in a project's scope (it's precious space). These todo lists should be kept strictly in the realm of WikiProjects and their subpages. — Goszei (talk) 18:20, 13 April 2021 (UTC)

Category

Hi!, I wanted to ask something interesting, at least to me. I hope to be in the right place. I am enthusiast about both World Wars and the people who served in both (I don't say men just out of respect for Florence Green) xD. I wanted to know if it would be a good idea to create a category of the few flying aces during both World Wars, mostly German flying aces who later became Luftwaffe members. Wouldn't it be a suitable category or it's too specified? Thanks all. CoryGlee (talk) 22:46, 13 April 2021 (UTC)

Hello CoryGlee. I will let others comment on whether a category is feasible but I think the info might be better in a list article. For me categories can get lost in the shuffle especially if the person's article has ten or more cats. In a list article things like what company of each air force can be included. Other editors will have more and different input for you to consider. Regards. MarnetteD|Talk 23:29, 13 April 2021 (UTC)

Perfect friend! Thank you! CoryGlee (talk) 23:50, 13 April 2021 (UTC)

What we've got here is failure to communicate (some mobile editors you just can't reach)

Summary of overall issues: User:Suffusion of Yellow/Mobile communication bugs ProcrastinatingReader (talk) 03:08, 21 March 2021 (UTC)

Over a year ago, I reported two problems to the WMF:

(1) Logged-in mobile web editors are not given a very strong indication that they have new messages. There's just a little number in a red circle. It's similar to what many other sites use for "Exciting! New! Offers!" and other garbage. There's nothing to say "A human being wants to talk to you."

(2) Mobile web IP editors are given no indication at all that they have new messages. Nothing. Every template warning, every carefully thought out personal message, and everything else just disappears into a black hole, unless the user stumbles across their talk page by accident, or switches to the desktop interface.

But I get it. Bugs happen. They can be fixed. Instead both problems were marked as a "low" priority.

This is baffling. Problem 1 is a serious issue. Problem 2 is utterly unacceptable.

We are yelling at users (or even dragging them to WP:ANI) for "ignoring" our messages that they have no idea exist. We are expecting them learn without any communication all sorts of rules from WP:V to WP:3RR to WP:MOS that don't even apply to most other sites on the web.

Until they get blocked, of course. What a terrible experience. How are we supposed to gain new users when their very first interaction with a human is being told to f--- off, for "ignoring" a message they didn't even know about?

WMF, please explain to this community why this is a "low" priority. One year is long enough. Suffusion of Yellow (talk) 22:55, 16 February 2021 (UTC)

I'll just note that a majority of our users are accessing us on mobile so this isn't a niche problem either. Best, Barkeep49 (talk) 23:26, 16 February 2021 (UTC)

Wow. Neglected high-priority phabricator tickets are nothing new, but this is another level. Jimbo Wales, this deserves your attention. {{u|Sdkb}} ^talk 08:11, 18 February 2021 (UTC)

I would like to point out that the majority of messages left to IPs will never reach the user in question anyways, ESPECIALLY on mobile connections. Due to shared ips, the chance of someone else viewing the message before the person you are trying to reach is probably about 50/50. I realise that sometimes leaving a message is effective, but there are serious questions about all the cases where it is simply leaving a very confusing and often aggressively toned message to a completely different user just randomly reading an article at the busstop a month later. What we really need is a completely new way to leave messages to anonymous users. Possibly with some sort of very short lived session or something. But as ip users are more or less stateless (the software concept) right now, that is probably hard to implement. —TheDJ (talk • contribs) 09:26, 18 February 2021 (UTC)

@TheDJ: I would have no objection to expiring the OBOD if the talk page isn't clicked in a few days. Many messages come only a few minutes after the user makes the edit; most mobile carriers aren't that dynamic. Suffusion of Yellow (talk) 17:14, 23 February 2021 (UTC)

Equally baffling is that mobile app users do not see any notifications, including no talk page notifications, logged in or out. The link to talk is buried within the settings. Official mobile apps! They don't even see block messages! See T263943 and others. This block review and also this discussion where an editor also tested block messages. The editor was blocked multiple times for something that was not their fault but that of a poorly thought out app. They are not alone. Quote from phab task: Conclusion: Using the app is like being inside a bubble, without contacts with the exterior. It's no wonder there's so much people complaining here that using the app caused their Wikipedia account to be blocked, for reasons they don't understand. ProcrastinatingReader (talk) 09:33, 18 February 2021 (UTC)

I have filed T275117 and T275118. ProcrastinatingReader (talk) 10:22, 18 February 2021 (UTC)

I'm always surprised that anyone manages to edit with the mobile interface. As another example, if you're not logged in, there is no way to access the talk page of an article, or even any indication that it exists. If an unregistered user makes an edit and is reverted with a common summary like "see talk", I imagine many will have no idea what's going on. – Joe (talk) 09:39, 18 February 2021 (UTC)

The mobile web, and mobile apps, appear to be designed for readers and not writers. Having used mobile web occasionally, I think it's usable for logged in editing, but I do have to switch to desktop every now and then. I've used the iOS app only for a test - it is not usable for editing imo. ProcrastinatingReader (talk) 09:55, 18 February 2021 (UTC)

The number of edits I have made with the mobile web or app interface is most likely less than 50 (out of 13,000). Even for reading, the mobile interface is borderline unusable. I do frequently edit from my 4-inch cell phone screen (in fact, I'm doing that right now)... but I use the desktop version. —pythoncoder (talk | contribs) 14:04, 18 February 2021 (UTC)

I agree with Joe and have always found Cullen328 to be a bit of a superhero for being who he is on a mobile device. Best, Barkeep49 (talk) 18:19, 18 February 2021 (UTC)

Thanks for the kind words, Barkeep49, but I simply use the fully functional desktop site on my Android smartphone. It's easy. If I was the king of the Wikimedia Foundation, I would shut down the mobile site and apps, because they are an ongoing impediment to serious editing. RoySmith, there is no need to invest more effort (money) on a good editing interface for mobile, because that interface already exists - the desktop site. Just change its name from desktop to universal or something, and the problem will be solved.Cullen328 Let's discuss it 18:34, 18 February 2021 (UTC)

• In some parts of the world, laptops and desktops are common, and people's phones are their second screen. In an environment like that, yes, it makes sense for mobile devices to be thought of as a read-mostly interface. On the other hand, in other parts of the world (particularly India in the context of English language users), mobile is how people access the internet.[31] There's no doubt that building a good editing interface for mobile is a hard thing, but we should be investing more effort there. Poor mobile editing tools disenfranchises a large segment of the world's population. -- RoySmith (talk) 14:41, 18 February 2021 (UTC)

• @Suffusion of Yellow: Thank you for basically expressing exactly the same problem I wanted to. I have blocked a few editors who seem to be editing in good faith but just don't communicate, which eventually end up at ANI and after much agonising, get hit with as friendly a WP:ICANTHEARYOU block as we can muster. In the last instance, Mdd97 (talk · contribs), I specifically made a custom block template that said "CLICK HERE TO READ YOUR MESSAGES" in a way that they surely couldn't miss .... but again, following the block they've not edited again. We have to get to the bottom of this; if it's got to the stage where I've got to block people and the root cause is a software fault, it needs to be fixed. Surely the WMF can't be happy that I've needed to issue blocks on good-faith editors in this manner. Ritchie333 (talk) (cont) 16:10, 18 February 2021 (UTC)
• To address a reaction some might have, yes, the vast majority of users on mobile are readers, not editors, and no, I wouldn't want the community totally in charge of redesigning the mobile interface, since we'd end up with the phenomenon we have at desktop where e.g. the tools section of the sidebar is visible to every user on every page despite it being of zero use to 99.9% of them. But this request is not just editor-centrism; it applies to users who have already edited and who badly need a notification to help them not get lost. {{u|Sdkb}} ^talk 18:55, 18 February 2021 (UTC)
• I think the mw:Talk pages project, especially now that they are beginning to work on subscribing to notifications for talk page sections, could be interested in this discussion. Pinging User:PPelberg (WMF) and User:Whatamidoing (WMF). It also touches on UCoC Enforcement, highlighting that there needs to be funding for software dev. in addition to other measures. Pinging User:SPoore (WMF) and User:BChoo (WMF) for want of knowing who to contact regarding Phase 2. Pelagic ( messages ) – (09:51 Sat 20, AEDT) 22:51, 19 February 2021 (UTC) ... Adding User:Xeno (WMF) after seeing section above. Pelagic ( messages ) – (09:55 Sat 20, AEDT) 22:55, 19 February 2021 (UTC)

  Pelagic: Thank you for the ping and highlighting how this is a related need for my current project. I've been following this thread and will be including the comments (and phabricator links - thank you for those!) in my work categorized under important requests for additional human or technical resources to assist with on-wiki workflows. Xeno (WMF) (talk) 15:02, 14 March 2021 (UTC)

Question - Is this something that could be cured by bringing back the "Orange Bar of Death"? Mjroots (talk) 16:31, 22 February 2021 (UTC)

@Mjroots: the orange bar of death never went away. Last I check, it's still there for non mobile IP editors. That's why they get an indication of new messages. AFAIK, it was never there for the mobile web editor, that's probably part of the problem. Nil Einne (talk) 03:06, 23 February 2021 (UTC)

What no one has ever told me is why it was left out in the first place. Was it a simple oversight? Did someone have such a little understanding of how the sites work that they thought communication was unnecessary? Some other reason, that I'm not thinking of? This is the most confusing part. Suffusion of Yellow (talk) 17:14, 23 February 2021 (UTC)

I wish it could be brought back for all editors. Looks like bringing it in for IPs on mobiles could be the cure here. Mjroots (talk) 18:40, 23 February 2021 (UTC)

This is alarming but not surprising. Since I do a lot of question answering at the Teahouse, I'll point out a random IP's post from yesterday, in the same vein as some of the sentiments noted above: "Also, why don’t they get rid of the mobile view? So terrible!".--Fuhghettaboutit (talk) 00:29, 24 February 2021 (UTC)

• Does anyone with a (WMF) account plan on commenting in this thread? Suffusion of Yellow (talk) 17:21, 8 March 2021 (UTC)

  Don't hold your breath. For most W?F employees, commenting on Wikipedia using a W?F account is a quick way to get yourself fired. You might, if you make enough noise, get a department head to respond by saying that mobile users are very important to us and we will do everything we can to address this, up to but not including doing anything differently that we are doing them now. --Guy Macon (talk) 17:39, 8 March 2021 (UTC)

  @Guy Macon: When they did the same thing with desktop IPs, it was fixed within hours of being pointed out. Serious, not rhetorical question: what's changed about WMF culture since 2013? Suffusion of Yellow (talk) 17:58, 8 March 2021 (UTC)

When you spend three times as much money without the actual job you were hired to do changing, you start to focus more on spending all of that money instead of on doing your job. When you hire a boatload of new employees when the current bunch are more that enough to do the job, those new employees find something to do, whether that something needs doing or not. I'm just saying. --Guy Macon (talk) 18:31, 8 March 2021 (UTC)

• User:Suffusion of Yellow broadly you have two factors. Firstly there is little incentive for WMF people engage people here were they will get a bunch of people shouting that them (which is not fun). Secondly there has been a longstanding unwritten understanding that mobile is the WMF's turf while the community has more ownership of the desktop.©Geni (talk) 11:21, 11 March 2021 (UTC)

  Well, imagine this. Someone is standing on your foot. You politely ask them to move off of it. They don't. You repeat your request more loudly. They continue to ignore you. It still hurts. At some point, does shouting and shoving come into play?

  If WMF doesn't like being shouted at, well—certainly, no one does. But people do not like being ignored either, and doing so is an excellent way to get them started shouting just to be heard at all. Seraphimblade ^{Talk to me} 21:42, 14 March 2021 (UTC)

• Action from the WMF! One two three new mobile bugs I discovered while investigating this have been triaged as "low" priority, and a fourth was lowered to "medium", after a volunteer developer had raised it to "high". All without a word of explanation. The first (unparsed spam blacklist messages) isn't a huge deal I'll agree. But why is not telling users why they're blocked or falsely telling registered users that they're blocked personally not a major concern? That's how we lose people. Suffusion of Yellow (talk) 22:55, 22 March 2021 (UTC)
  • Can we locally block these apps from editing English Wikipedia? That would force the WMF to fix them. Fences&Windows 00:02, 26 March 2021 (UTC)

    @Fences and windows: Yes, this can be done with the edit filter. It could even be limited to users with no confirmed email address. But there's a catch. The apps don't properly display custom edit filter warnings, either! The iOS app just displays the title of the page where the message is stored. And the Android app doesn't display custom messages at all. The mobile web editor does display messages properly, however. Suffusion of Yellow (talk) 00:10, 26 March 2021 (UTC)

    If this were a lower-priority issue, I would say we should come back in a month and see if the WMF fixed it. But this is such a glaring oversight that I feel this may be the only option if we want to fix this. Question: would this apply to just the app, or to the mobile site as well? —pythoncoder (talk | contribs) 15:06, 29 March 2021 (UTC)

    It's app only (the user_app variable in the edit filter). ProcrastinatingReader (talk) 15:12, 29 March 2021 (UTC)

  Thanks, ProcrastinatingReader. If we prepare an RfC, where would it be held? It would need advertising on cent. Fences&Windows 23:47, 29 March 2021 (UTC)

  @Fences and windows: Any RFC will need some very careful drafting first. If it fails (for any reason) the WMF could interpret the failure as "see the community doesn't really care about this issue". Suffusion of Yellow (talk) 23:51, 29 March 2021 (UTC)

  We might want to move this thread to WP:VPT; this noticeboard is not widely watched. –xenotalk 23:54, 29 March 2021 (UTC)

  I really don't want to rush into an RFC, though. There are many questions. Should we also disallow mobile IP web editors? Should we disallow edits from users with a confirmed email address? Which bugs, exactly, do we want fixed? How long do we give the WMF to fix them? This is a nuclear option. It should not be taken lightly.

  But please don't move the whole thread to VPT. It's here so it doesn't get buried in the archives. Suffusion of Yellow (talk) 00:33, 30 March 2021 (UTC)

  (edit conflict) Two-question RfC maybe? Initial brainstorm - Question 1: consensus 'letter' to WMF requesting resources be allocated to promptly fix the issues. Question 2: if not done within 90 days, mobile apps blocked from editing enwiki by edit filter. Best to move this particular matter to VPI. ProcrastinatingReader (talk) 00:36, 30 March 2021 (UTC)

  It has to be noted though that disallowing edits, if it comes to it, is really not great and rather bitey, as the editors will hardly have any clue what's going on due to EF messages being iffy. Maybe bugging Jimbo and/or Doc James to contact someone in engineering is a viable option? ProcrastinatingReader (talk) 00:43, 30 March 2021 (UTC)

  As I said. Nuclear. Suffusion of Yellow (talk) 01:09, 30 March 2021 (UTC)

  Yes, IDEALAB is the best place (for a new thread). That will discourage any supporting and opposing until we figure just what we're asking for. Suffusion of Yellow (talk) 01:09, 30 March 2021 (UTC)

  This needs caution—an overly enthusiastic RfC or proposal at WP:VPI is bound to be voted down and that would cause a lot of people to automatically vote down any future proposals of a similar nature. I'm thinking of masked IPs—any proposal to impede or block such users could easily fail if it appeared to be similar to an earlier idea to block "good faith" users who were unaware that communication was even possible, let alone required. Johnuniq (talk) 08:34, 30 March 2021 (UTC)

• I wish I could say I was surprised by any of this but I've long assumed that something like this was the cause of numerous editors I've come across who display quite clearly that they have never seen their IP/user talk page, and simply have no idea why their edits "aren't going through" (because a human editor keeps undoing them). A thorough waste of thousands of hours of volunteer time, on both ends. There are some countries or regions in which accessing the internet is only financially possible for the everyday person via a mobile phone, so the WMF's inaction here is another built-in systemic bias which prevents some cultures from effectively contributing their knowledge and skills to Wikipedia. — Bilorv (talk) 06:51, 29 March 2021 (UTC)
• Tracked in Phabricator
  Task T278838
  
  
  User:Suffusion of Yellow/Mobile communication bugs seems to be an excellent overview but it would get more attention if it were on phab. I have tried to roughly copy it to https://phabricator.wikimedia.org/T278838 which can probably be used as a parent task for all these issues. – SD0001 (talk) 15:04, 30 March 2021 (UTC)

Hi everyone, thanks for raising these issues, and documenting the problems so thoroughly. We're going to get a group of people from the Product department together next week to talk about these problems, and see what we can do about it. I'll let you know what we figure out. I appreciate you all bringing it up. — DannyH (WMF) (talk) 22:17, 7 April 2021 (UTC)

Thank you, Danny! I look forward to seeing what you come up with. Suffusion of Yellow (talk) 19:55, 9 April 2021 (UTC)

Open Letter from Arbcoms to the Board of Trustees

I just stumbled onto m:Open Letter from Arbcoms to the Board of Trustees, expressing concerns about how the UCoC Enforcement policies are being developed. Thanks and support to our Arbs (won't ping you all) and those of the cs, de, fr, pl, ru, uk communities. You have expressed it better than I ever could. Pelagic ( messages ) – (23:39 Wed 31, AEDT) 12:39, 31 March 2021 (UTC)

Note: More discussion at WT:ACN —pythoncoder (talk | contribs) 13:10, 31 March 2021 (UTC)

Universal Code of Conduct – 2021 consultations

Universal Code of Conduct Phase 2

The Universal Code of Conduct (UCoC) provides a universal baseline of acceptable behavior for the entire Wikimedia movement and all its projects. The project is currently in Phase 2, outlining clear enforcement pathways. You can read more about the whole project on its project page.

Drafting Committee: Call for applications

The Wikimedia Foundation is recruiting volunteers to join a committee to draft how to make the code enforceable. Volunteers on the committee will commit between 2 and 6 hours per week from late April through July and again in October and November. It is important that the committee be diverse and inclusive, and have a range of experiences, including both experienced users and newcomers, and those who have received or responded to, as well as those who have been falsely accused of harassment.

To apply and learn more about the process, see Universal Code of Conduct/Drafting committee.

2021 community consultations: Notice and call for volunteers / translators

From 5 April – 5 May 2021 there will be conversations on many Wikimedia projects about how to enforce the UCoC. We are looking for volunteers to translate key material, as well as to help host consultations on their own languages or projects using suggested key questions. If you are interested in volunteering for either of these roles, please contact us in whatever language you are most comfortable.

To learn more about this work and other conversations taking place, see Universal Code of Conduct/2021 consultations.

-- Xeno (WMF) (talk) 20:45, 5 April 2021 (UTC)

English Wikipedia Request for comment: Universal Code of Conduct application

Further to the above, I've opened an RfC at Wikipedia:Universal Code of Conduct/2021 consultation, and community comments are invited. Xeno (WMF) (talk) 22:40, 5 April 2021 (UTC)

[Wiki For human rights] Invitation to participate discussion

Hello everyone,

This is Michel BAKNI from Wikimedia Foundation. I am writing this post on behalf of the Wiki for Human Rights Campaign which is an annual campaign. This year we are focusing on the right to a healthy environment.

We are currently looking for local communities to engage in the campaign. Thus I would like to invite you all to participate in the challenge or any event related to the human rights campaign.

Here are some usual links related to this year's campaign:

• The campaign page
• The challenge page
• List of articles to work on

Please feel free to get back to me if you have any questions or need more information, you can also add join the discussion here and I will be more than happy to answer all of your questions.--Michel Bakni (talk) 19:10, 6 April 2021 (UTC)

There's a proposal to run a Central Notice banner for a #WikiForHumanRights writing challenge on "Right to a healthy environment" which would run from 15 to 21-April. Please discuss at link. --Michel Bakni (talk) 19:17, 8 April 2021 (UTC)

new page Wikipedia:Wikimedia proposals

Hi. I have created the page below, simply to facilitate greater awareness and discussion of current and active proposals by WMF, in the most inclusive and positive way possible. any comments and input are welcome. thanks!!

• Wikipedia:Wikimedia proposals

thanks. --Sm8900 (talk) 14:39, 8 April 2021 (UTC)

I'm not the most familiar with existing venues for announcements from the WMF, but I have some concern this could become a fork of any such existing venues and end up inactive. {{u|Sdkb}} ^talk 22:45, 12 April 2021 (UTC)

I misread that as in the most inconclusive...way possible and thought "yup, that sounds like noticeboard business as usual" GeneralNotability (talk) 23:16, 12 April 2021 (UTC)

You may want to add meta:IP Editing: Privacy Enhancement and Abuse Mitigation and meta:Wikimedia Enterprise. Also, shortcuts usually have no spaces. So WP:WMPROPOSALS better than WP:WM PROPOSALS. MarioGom (talk) 23:32, 12 April 2021 (UTC)

Notification of discussion at Wikipedia talk:Oversight

Hello! I've been advised by Beeblebrox to notify this village pump about a discussion regarding the potential use of a remake of the Oversight logo using a 3D version of at the Wikipedia logo. The discussion can be found at Wikipedia talk:Oversight#Proposal to change the Oversight logo. Chlod (say hi!) 21:12, 13 April 2021 (UTC)

Community Resilience & Sustainability office hour April 17 15:00 UTC

Duplicated from VPMHi all! The Community Resilience & Sustainability team at the Wikimedia Foundation is hosting an office hour led by its Vice President Maggie Dennis. Topics within scope for this call include Movement Strategy coordination (recently transferred to CR&S), Trust and Safety (and the Universal Code of Conduct), Community Development, and Human Rights. Come with your questions or feedback, and let’s talk! You can also send us your questions in advance. 
 The meeting will be on April 17 at 15:00 UTC check your local time. 
 You can check all the details on Meta. Hope to see you there!

Best, JKoerner (WMF) (talk) 20:37, 8 April 2021 (UTC)

-- I've copied this across from VPM, as this seems more appropriate. If you follow the office hours it will also explain how to email questions in advance For Maggie to answer. Nosebagbear (talk) 20:24, 14 April 2021 (UTC)

Be careful about April Fool's Articles

As I type these words, it is April 1 2021, which is Maundy Thursday in 2021. It is also April Fool's Day. Can I therefore ask all Recent Changes Watchers to be especially vigilant of newly created articles today, as some of them might be hoaxes as April Fool's Day jokes. There was a very famous hoax in which Panorama declared that spaghetti grows on trees - it was an April Fool's Day joke. If it was not Panorama, it might have been Horizon. Rollo August (talk) 16:57, 1 April 2021 (UTC)

All right I shall confess that when I was editing Wikipedia under the name Vorbee (I have a new laptop now) I did create a joke article on a made-up pop group called "Heidegger Returns to Ontology" on April 1. This was deleted almost immediately as a mild celebration of April Fool's Day. Rollo August (talk) 21:30, 8 April 2021 (UTC)

Dennis F. Rasmussen

Dennis F. Rasmussen needs an advertisement-like hatnote (puffery)

.... 0mtwb9gd5wx (talk) 21:21, 6 April 2021 (UTC)

Like so, 0mtwb9gd5wx? The page was not protected so you could have done it yourself. – Finnusertop (talk ⋅ contribs) 13:50, 11 April 2021 (UTC)

I did not know how to find the template, who would have thought {{Puffery}} ...

.... 0mtwb9gd5wx (talk) 16:38, 11 April 2021 (UTC)

Best thing to do if you want to make a requested move but feel afraid there will be too many votes to oppose

Look at Talk:Emily Brooke. I just posted in that talk page a message and I want to know if anyone has opinions about it. (Please make only comments that would be valid with ANY requested move that one might want to propose but that they're too afraid there will be lots of oppose votes.) Georgia guy (talk) 21:41, 7 April 2021 (UTC)

@Georgia guy: we only disambiguate between topics covered on Wikipedia. I'd recommend seeing if you could write an article on the singer Emily Brooke first, then proposing the move (or doing it boldly and disambiguating). Elli (talk | contribs) 22:54, 7 April 2021 (UTC)

It is likewise true that I worry that if I do so the article will be put on Afd with many delete votes. Georgia guy (talk) 23:50, 7 April 2021 (UTC)

I would suggest that having such a worry may indicate that you have doubts that the subject meets Wikipedia standards for notability. Why not start a draft in userspace or draftspace and see what sources you can bring together? BD2412 T 00:35, 8 April 2021 (UTC)

Community Resilience & Sustainability office hour April 17 15:00 UTC

Hi all! The Community Resilience & Sustainability team at the Wikimedia Foundation is hosting an office hour led by its Vice President Maggie Dennis. Topics within scope for this call include Movement Strategy coordination (recently transferred to CR&S), Trust and Safety (and the Universal Code of Conduct), Community Development, and Human Rights. Come with your questions or feedback, and let’s talk! You can also send us your questions in advance. 
 The meeting will be on April 17 at 15:00 UTC check your local time. 
 You can check all the details on Meta. Hope to see you there!

Best, JKoerner (WMF) (talk) 20:37, 8 April 2021 (UTC)

Mass-deletion/cleanup discussion

Several thousand articles exist for purported places in Azerbaijan that were mass-created in a problematic way from GEOnet. We have had similar problems with Iran articles (see earlier on the same noticeboard) and California articles (see Wikipedia:Reliability of GNIS data and Wikipedia:WikiProject California/GNIS cleanup task force) and have quite a number of areas not even tackled yet (e.g. "Corner" articles in the U.S. state of Virginia that were probably once the sites of marker trees for land surveys, that Wikipedia is declaring to be human communities). A discussion of which articles we do not trust to be fundamentally accurate in the context that they give to readers/editors, and whether and what to mass-delete, is on-going on the Administrators' main noticeboard. Uncle G (talk) 02:15, 11 April 2021 (UTC)

I attempted to help a user to add citations, but existing Help for Citations is not a How To tutorial

See User_talk:Uni3993#Citations_needed. Perhaps the help pages need more material on the How to add the citation. The existing documentation for citations is a step up in skills needed, when compared to the Help tutorial. --Ancheta Wis   (talk | contribs) 00:02, 15 April 2021 (UTC)

I point new editors to User:Nick Moyes/Easier Referencing for Beginners. Schazjmd (talk) 00:14, 15 April 2021 (UTC)

Thank you, I will update my message to the user. --Ancheta Wis   (talk | contribs) 00:28, 15 April 2021 (UTC)