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

Предупреждения о срабатывании триггера [ править ]

Запятая бот [ править ]

Я действительно не знаю, как работают боты, но есть грамматическая ошибка (не слишком серьезная), которую я постоянно вижу. Это список слов, например «Один, два, три и четыре». Предполагается, что это «Один, два, три и четыре». Опять же, я не знаю, как работают боты / как их создать. Кто-нибудь думает, что это хорошая идея? TheFirstVicar4 ( обсуждение ) 15:21, 28 марта 2021 (UTC)

Обе формы разрешены Википедией: Руководство по стилю № Серийные запятые . PrimeHunter ( разговорное ) 15:25, 28 марта 2021 (UTC)

См. Также WP: CONTEXTBOT . Это не та задача, которую могут выполнять боты. -  HELL KNOWZ    ▎ TALK 16:27, 28 марта 2021 г. (UTC) 

Нет!! Добавление оксфордских запятых к существующим статьям было бы прекрасным способом начать войну - GhostInTheMachine ^{поговорит со мной} 17:00, 28 марта 2021 г. (UTC)

Увы, во имя мира TheFirstVicar4, Википедия должна позволить людям есть бабушку. Nosebagbear ( разговор ) 10:29, 29 марта 2021 (UTC)

Я вижу, к чему вы идете, но это слишком много работы и слишком мало общей пользы. Как частично указал Hellknowz, даже если вы работаете с запятой, то, как она используется, может повлиять на ясность статьи, и это во многом зависит от типа предложения, в котором она используется. Заставить бота понять это вероятно, потребует много времени волонтеров, и, в конце концов, почти всегда будут ложные срабатывания / отрицания. Как правило, я предпочитаю, чтобы большинство грамматических двусмысленностей было подобрано и исправлено редакторами-людьми (и я также считаю, что это статус-кво ) - Лэнкиливер ( выступление ) 00:55, 18 апреля 2021 г. (UTC)

Фильтр по специальным: случайным или случайным кнопкам статьи [ редактировать ]

Я считаю, что должен быть какой-то способ отфильтровать, на какие страницы вы можете попасть, используя Special: Random или нажав кнопку Random Article. Обычно я пытаюсь использовать его, чтобы найти случайную страницу и посмотреть, нуждается ли она в редактировании, но часто это приводит меня на страницу по теме, о которой я ничего не знаю, или на страницу с очень небольшим количеством информации по теме, о которой я ничего не знаю . Так что, возможно, создадим какой-то способ для пользователей фильтровать, к каким статьям они их приведут, или что-то еще. Я хотел бы услышать, что вы думаете об этой идее. Пылающий волк | Гордый Фурри и редактор Википедии ( обсуждение ) 20:00, 29 марта 2021 г. (UTC)

Я бы также хотел, чтобы был «случайный» для всех пространств имен или хотя бы для основных. 🐔  Chicdat   ^{Bawk мне!} 20:05, 29 марта 2021 г. (UTC)

Там есть. См. Wikipedia: Random . PrimeHunter ( разговорное ) 20:48, 29 марта 2021 (UTC)

• Special: RandomInCategory , вероятно, то, что вам нужно. К несчастью для читателей, гораздо сложнее получить случайную жизненно важную статью, и, вероятно, они хотели бы избежать супер-нишевых тем. {{u | Sdkb }}  ^talk 04:22, 30 марта 2021 г. (UTC)

  Я не совсем понимаю, как работает Википедия (у меня есть достаточно общее представление, чтобы делать то, что мне нужно здесь), поэтому не могли бы вы объяснить, как это было бы труднее? Пылающий волк | Гордый Фурри и редактор Википедии ( обсуждение ) 18:03, 31 марта 2021 г. (UTC)

  @ Blaze The Wolf , нажмите Special: RandomInCategory / Основные статьи по теме . Это то, о чем говорит @ Sdkb , хотя у нас нет идеальной категории. Однако я сомневаюсь, что людям нужны жизненно важные статьи. Они могут быть более довольны статьями Special: RandomInCategory / Featured или Special: RandomInCategory / Good , в которых они могут найти хорошо написанные статьи, включая возможность чего-то забавного. ( Википедия: знаете ли вы, что теги, к сожалению, находятся в пространстве имен Talk :, поэтому поиск случайной статьи, например, в категории: Собаки, знаете ли вы статьи , приведет вас к странице обсуждения, а не к статье.) WhatamIdoing( разговор ) 01:32, 8 апреля 2021 (UTC)

• Вы также можете взглянуть на https://randomincategory.toolforge.org/ и расширенные параметры на https://randomincategory.toolforge.org/README.html - Ahecht (РАЗГОВОРНАЯ СТРАНИЦА) 21:56, 21 апреля 2021 г. (UTC)

Включая этническое или религиозное наследие [ править ]

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

Я бы порекомендовал политику исключения чьего-либо этнического или религиозного наследия, если это не связано напрямую с их профессией. - Предшествующий комментарий без подписи, добавленный Wixifixer ( обсуждение • вклад ) 20:30, 30 марта 2021 г. (UTC)

@ Wixifixer : Я думаю, это связано с надежными источниками, в которых эти вещи более заметны в случае с евреями. В любом случае, в западном мире вы бы увидели то же самое для мусульман, геев или любого другого меньшинства - это не по умолчанию, поэтому стоит отметить. Элли ( Обсуждение | вклад ) 01:57, 31 марта 2021 (UTC)

@ Wixifixer : Вы сами намекаете на важную причину: евреи считаются этнической и религиозной группой, этнорелигиозной группой . Википедия: Руководство по стилю / биографии # Контекст гласит: «Этническая принадлежность, религия или сексуальность, как правило, не должны быть в лидерах, если это не имеет отношения к известности субъекта». Если о нем часто упоминают в надежных источниках, то обычно мы не исключаем его из всей статьи. PrimeHunter ( разговор ) 12:37, 31 марта 2021 (UTC)

Возможно, я слишком много читаю в вашем комментарии, но поскольку речь идет о еврейском происхождении , похоже, вы подразумеваете, что люди говорят о гомосексуальном предке как о части своей идентичности. 118.208.187.206 ( разговорное ) 06:21, 16 апреля 2021 (UTC)

Я думаю, вы обнаружите, что очень большая часть редакторов, добавляющих такую ​​информацию, сами являются евреями, поэтому ваше предположение неверно. Джонбод ( разговор ) 13:32, 31 марта 2021 (UTC)

Я не знаю. В более ранний период все это было бы справедливо и для католиков - с точки зрения большинства протестантов. Католики не просто рассматривались как отдельная религиозная группа; большинство протестантов считало их, по крайней мере, этническим «другим», если не расовым «другим». В том мире также «надежные источники» упомянули бы, что один из их подданных был итальянцем / ирландцем / католиком, потому что этот факт «заслуживает внимания». Теперь вкусы изменились. Католиков больше не нужно отмечать как католиков. Я не проводил исследования, чтобы понять, почему это изменилось. Может вы, ребята, знаете. Но это все тот же феномен. И я просто думаю, что нам пора быть более восприимчивыми к этому. Если многие другие евреи не согласны со мной, это нормально. Я думаю, они ошибаются. - предшествующее беззнаковоекомментарий добавлен Wixifixer ( обсуждение • вклад ) 21:24, 31 марта 2021 (UTC)

Получение биографии из Википедии обычно является признаком того, что вы добились успеха. Я сомневаюсь, что евреи в целом хотят скрыть, что объекты статей - евреи, если они сами этого не скрывают. PrimeHunter ( разговорное ) 21:52, 1 апреля 2021 (UTC)

ну, согласно этой логике, мы должны были бы предположить, что евреи - единственные, кто не хочет, чтобы их религиозная / этническая идентичность была скрыта, в то время как епископалы и пресвитериане ДЕЙСТВИТЕЛЬНО хотят скрыть ее? Честно, о чем ты говоришь? 47.35.240.141 ( разговорное ) 16:34, 4 апреля 2021 (UTC)

О чем ты говоришь? Я никоим образом не указывал, что епископалы и пресвитериане хотят это скрыть. Речь идет о евреях, потому что об этом писал Wixifixer. Причина, по которой мы чаще упоминаем, является ли кто-то евреем, заключается в том, что это также этническая принадлежность, и надежные источники, которые мы используем, с большей вероятностью упоминают об этом. PrimeHunter ( разговорное ) 19:43, 4 апреля 2021 (UTC)

Этот вопрос возникает довольно часто, поэтому нам, возможно, придется где-нибудь написать эссе. Что, кажется, отталкивает людей, так это сочетание этнической принадлежности и религии. Если вам кажется, что «еврей» - это в первую очередь религия, то кажется странным говорить «Он еврей», но не «Она пресвитерианка». Разница, конечно же, в том, что этническое происхождение многих пресвитериан пишется «шотландское», а не «пресвитерианское». WhatamIdoing ( разговор ) 01:47, 8 апреля 2021 (UTC)

Заброшенные википроекты вокруг напитков - или что-нибудь в этом роде? Слияние, пусть будет, или еще что? [ редактировать ]

Я заметил, что есть несколько WikiProjects и, по крайней мере, одна целевая группа, вращающаяся вокруг какого-то напитка, WikiProject Spirits , WikiProject Wine и WikiProject Food and drink с целевой группой Beverages, о которых я знаю, но все они неактивны. Очень жаль, так как похоже, что в них было вложено много усилий. Возможно, их можно было как-то объединить. Что с ними случилось? Возможно, это общая тенденция исчезновения WikiProjects? Как Википедия должна с этим справиться? - Mango från yttre rymden ( разговор ) 23:59, 31 марта 2021 (UTC)

@ Mango från yttre rymden : некоторым проектам удается предоставить контекст, который помогает редактировать - например, руководящие принципы, согласованные обзоры и форум для обсуждения - и именно эти проекты процветают. У нас были даже большие проекты, такие как Wikipedia: WikiProject Culture , но это не обязательно означает, что редакторы не смогут эффективно редактировать эти темы. Если проект становится неактивным, рекомендуется установить ссылку на связанный проект (см. Пример «Культура»). Я полагаю, что можно было бы возродить Википедию: WikiProject Еда и напитки, поскольку она имеет широкий охват и, следовательно, много потенциально заинтересованных редакторов. Кстати, есть также активный проект по моему любимому напитку: Википедия: WikiProject Beer .-  Finnusertop ( обсуждение ⋅ вклад ) 18:16, 1 апреля 2021 г. (UTC)

@ Finnusertop : Я не имел в виду, что WikiProjects незаменимы. Я просто высказываю мысли. Я думаю, что все те проекты Wiki, которые вращаются вокруг одной и той же более широкой темы, такой как еда и напитки, можно было бы объединить в WP Food and Drink, так было бы более вероятно, что проекты возродятся, а тема (ы) получит некоторые больше внимания. Результат может быть больше, чем сумма его частей, поскольку больше людей, вероятно, присоединятся и будут участвовать, если в одной группе будет несколько человек, даже если каждый человек сосредоточится на разных вещах, чем если бы такое же количество людей быть разделенными на один проект каждый. Вино, пиво и спиртные напитки могут стать целевыми группами в рамках WP Food and Drink.

Я немного огляделся, и у меня сложилось впечатление, что WikiProjects возникли как грибы в начале 2010-х, предположительно вскоре после появления концепций, но теперь потеряли интерес людей, и половина из них заброшена. - Mango från yttre rymden ( разговор ) 19:37, 4 апреля 2021 года (UTC)

Википедия: WikiProject это группа людей. Некоторые группы формируются для выполнения ограниченных по времени задач; другие образуются бесконечно, но затем как бы расходятся. Это нормально. Добро пожаловать в WP: REVIVE любой WikiProject. Вы делаете это в первую очередь, объединяясь с заинтересованными вики-друзьями. Такие страницы, как Википедия: Каталог WikiProject / Описание / WikiProject Еда и напитки , помогут вам найти заинтересованных редакторов.

Иногда две группы объединяются добровольно. Это может быть полезно, но никогда не бывает принудительным. WhatamIdoing ( разговор ) 01:51, 8 апреля 2021 (UTC)

Есть некоторые википроекты, такие как MilHist, которые всегда активны, но я думаю, что у большинства из них будут периоды активности между более длительными периодами бездействия. Но они по-прежнему играют определенную роль и являются подходящим местом для отчетов и обсуждения источников по своей предметной области. Ere Spiel Checkers 12:58, 16 апреля 2021 (UTC)

Разблокирование прав администратора [ править ]

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

Можете ли вы увидеть какие-либо ситуации, в которых это было бы полезно - например, вместо дезисопа, есть ли случаи, когда было бы полезно отнять автопатрол у администратора? В основном, когда arbcom desysop, я вижу, что администраторы оскорбляют некоторых людей, а не создают проблемные статьи или неправильно используют откат. Грэм Бартлетт ( разговор ) 03:48, 1 апреля 2021 (UTC)

Я не могу представить себе ситуацию, когда администратор будет достаточно надежным, чтобы блокировать людей, удалять статьи, просматривать удаленные материалы, а также защищать и снимать защиту страниц, но нельзя было бы доверять такие права, как откат или автоматическое патрулирование. Если им нельзя доверять, у них определенно не должно быть инструментов администратора. Клинок Серафима ^{Поговори со мной} 05:02, 1 апреля 2021 г. (UTC)

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

Может быть, есть админы, которые никогда не используют откат и могут отказаться от этого права, чтобы не нуждаться в скрипте, чтобы его скрыть. - xeno talk 05:17, 1 апреля 2021 г. (UTC)

Спасибо за пинг. @ Jackattack1597 : «Главный технический вопрос заключается в том, можно ли отключить возможность администратора предоставлять себе недавно разделенные права пользователей, сохраняя при этом возможность администраторам предоставлять эти права другим пользователям». на самом деле это должно быть довольно легко сделать - я написал код для этого в декабре 2019 года, см. gerrit , но он еще не слился, потому что в нем не было необходимости - если enwiki решила запросить эта функция, скорее всего, будет одобрена. Соответствующая задача phab - phab: T44072 . @ Ксено :Если какой-либо администратор хочет, чтобы его статьи не отслеживались автоматически, я был бы рад подать BRFA, который должен быть довольно простым для кодирования (смехотворно просто, поскольку бот уже отменяет патрулирование новых страниц глобальными средствами отката, поэтому логика вся здесь). DannyS712 ( разговор ) 05:26, 1 апреля 2021 (UTC)

@ Xeno : Я попросил кого-нибудь провести сеанс с меньшим, чем у всех их доступом, много лет назад в phab: T153454 - он не стал популярным . В настоящее время это доступно в API, но не в WEBUI. - ^{Обсуждение} xaosflux 13:23, 1 апреля 2021 г. (UTC)

Хм, похоже, у меня мог быть офф-фаб по этому поводу, так как я не являюсь автором этого (я думаю, что я был автором списка желаний для него, может быть?) - но то же самое. - ^{Обсуждение} xaosflux 13:25, 1 апреля 2021 г. (UTC)

• Этого никогда не произойдет, как написано. Special: ListGroupRights показывает 63 разрешения, которые есть у сисопов. Кроме того, текущая система разрешений не позволяет напрямую назначать разрешение, только группу - поэтому им потребуется группа для каждого разрешения, и это будет излишним - и мы ни в коем случае не собираемся проводить сообщество через «Запрос» для процесса доступа к глобальному блоку-белому списку, например. Система частичных блокировок может расшириться и позволить кому-то быть заблокированным от произвольных действий, phab: T242541 дает дополнительную информацию по этому поводу . - ^{Обсуждение} xaosflux, 11:01, 1 апреля 2021 г. (UTC)
  • Хорошо, поэтому я перечитал это, сосредоточив внимание на части «могу подать заявку». Имейте в виду, что никто по-прежнему не получает прав, они получают группы. По-прежнему возникают проблемы, например «координаторы событий» получают «без ограничения скорости» и «добавление + подтверждение для пользователей», но вы предлагаете удалить их у сисопов и сделать их также координаторами событий, чтобы вернуть их? Сисопы получают «импорт», но также и «импортеры transwiki» и «импортеры», так что сисопам также придется подавать заявки на них? Сделать администраторов также членами дюжины других групп довольно обременительно, у нас есть ролевые элементы управления доступом по уважительной причине. - ^{Обсуждение} xaosflux 17:48, 2 апреля 2021 г. (UTC)
• Я твердо верю, что разделение прав администратора необходимо, но я также считаю, что это нужно делать поэтапно, а не все сразу. Я бы сделал это в форме введения новых групп прав пользователей, в которые могут подавать заявки обычные пользователи, вместо того, чтобы лишать администраторов каких-либо прав. Хорошим местом для начала, похоже, является создание пользовательских прав "вандалфайтер". Я думаю, что это должно включать в себя возможность отправлять короткие блоки (до 72 часов) IP и пользователям без автоподтверждения, вовлеченным в вандализм и серьезным нарушениям, а также возможность частично защищать страницы на короткие периоды (скажем, до недели). По моим наблюдениям, доски объявлений, такие как RPP, AIV и 3RR, теперь часто остаются в резерве, и часто требуется несколько часов, чтобы получить от администратора действие над отчетом. Но, в отличие от админов, вандалы часами не отдыхают. Чтобы привести конкретный пример,несколько дней назад я заметил серьезное нарушение BLP из-за динамического IP-адреса в статье в моем списке наблюдения,Чемпионат мира по фигурному катанию 2019 . Я сообщил об этом в RPP [3], но в течение нескольких часов отчет оставался бездействующим, хотя статья затиралась. Тем временем другие пользователи отправляли отчеты в 3RR Википедия: Доска объявлений администраторов / 3RRArchive430 # Пользователь: 117.111.0.0/19, о котором сообщил пользователь: Джаспер Денг (Результат: Блок, Полупериод) и ANI Википедия: Доска объявлений администраторов / IncidentArchive1062 # Срочное редактирование требовался warring rangeblock , но опять же, ничего не происходило. В конце концов, спустя более семи (!) Часов после моего первоначального отчета RPP, администратор получил пинг напрямую и защитил страницу [4]и установите диапазон для динамического IP. Вчера по истечении срока блокировки и полузащиты сбой возобновился. На этот раз нам повезло, что тот же администратор был в сети и быстро ответил на пинг, иначе это снова было бы несколько часов хаоса. Эта ситуация была нелепой, и я уверен, что это не единичный случай. Поскольку у нас недостаточно администраторов, чтобы быстро реагировать на отчеты AIV и RPP, нам нужно дать обычным пользователям возможность что-то делать. Nsk92 ( разговор ) 12:13, 1 апреля 2021 (UTC)
  • Мы неоднократно рассматривали права на «мини-блок» и «мини-защиту» только за последние 2 года. Я думаю, что дело можно сделать, но нам не удалось заручиться твердой поддержкой - есть проблемы, которые возникают с любым путем. Nosebagbear ( разговор ) 17:15, 2 апреля 2021 (UTC)

  Предложение о праве пользователя «вандалфайтер» было внесено в 2015 году и не получило консенсуса. См. Википедию: Village_pump_ (предложения) / Archive_120 # Proposed_user_right: _Vandal_fighter . - Ахехт (РАЗГОВОРНАЯ СТРАНИЦА) 03:35, 12 апреля 2021 г. (UTC)

• Я не понимаю, почему это имеет смысл. Предоставить администратору три наиболее важных инструмента, требующих наибольшего доверия, но заставить его требовать целую кучу других прав пользователя? А также все, что сказал Xaosflux. Вы упоминаете удаление страниц как право, которое они сохранят, но сохранят ли они возможность просматривать удаленные страницы и удалять только определенные версии? Они по-прежнему смогут защищать страницы, но сохранят ли они возможность редактировать с помощью защиты? Похоже, что все это не рассматривалось до того, как это было предложено. Лично я считаю, что у нас уже слишком много групп пользователей. РГ: ПЕРМЬуже есть задержки, иногда довольно существенные. Это усугубило бы эту проблему, на самом деле намного хуже, поскольку назначение разрешений не является одной из трех «основных» возможностей, указанных в предложении. Так нужен ли нам еще один новый форум для запроса этой способности? Возможно, я поддержу предложение о разделении, но это точно не так. Библброкс ( разговор ) 20:04, 2 апреля 2021 (UTC)

Извините, я действительно не думаю, что мое первоначальное предложение было достаточно ясным. На самом деле, я пытаюсь предложить, чтобы любое разрешение, которое может быть запрошено в WP: PERM , больше не предоставляется администраторам автоматически, но это не повлияет на другие разрешения. Вместо этого администраторам нужно будет запросить их на WP: PERM . Если бы нас беспокоило отставание, я мог бы предложить RFC делать это для нескольких разрешений одновременно, а не для всех сразу, чтобы избежать застревания у большинства активных администраторов, запрашивающих все разрешения сразу на WP: PERM . Кроме того, для меня смысл в том, что если администратор незначительно злоупотребляет разрешениями WP: PERM, соответствующие разрешения могут быть удалены без использования Desysop. Я рад, что меня указали на лабораторию идей, потому что мне определенно нужно еще немного сгладить это. Jackattack1597 ( разговорное ) 23:20, 2 апреля 2021 (UTC)

• Что касается вопроса о том, нужен ли нам технический контроль, чтобы позволить + сисопу передать это кому-либо, кроме себя - почему? Если мы не хотим, чтобы они этого делали, просто разработайте политику и заблокируйте их, если они нарушат. Такой технический контроль все-таки не помешал бы мне поставить какой-нибудь флаг, например, на мой собственный альт-аккаунт. - ^{Обсуждение} xaosflux 21:02, 2 апреля 2021 г. (UTC)

Хороший момент, если подумать, я исключу технический контроль из предложения и просто включу запрет на выдачу разрешений на себя или альтернативные разрешения в RFC. Jackattack1597 ( разговорное ) 23:20, 2 апреля 2021 (UTC)

• Пер Библброкс . на основании того, что сказал Xaosflux . Система прав пользователей в Википедии уже очень детализирована и сбивает с толку многих, кто не обязательно работает в областях управления или не участвует в них, пока их создание не будет помечено для удаления или они не станут объектом санкций за то или иное нарушение. Было бы интересно определить, что на самом деле составляет «основные» права администратора. Традиционно блокировка, удаление и защита могут считаться наиболее важнымино поскольку многие администраторы сосредотачиваются на определенных областях по своему выбору, они могут быть не теми инструментами, которые чаще всего используются всеми администраторами - кто-то, у кого есть время, может пожелать провести анализ данных, результаты которого могут / должны были иметь был в преамбуле такого RFC (и может пролить другой свет на это предложение). Хотя можно указать причины, по которым автоматическое патрулирование для администраторов может потребоваться пересмотреть, они редки. Больше прав означает больше возможностей для сбора шляп , поэтому En Wikipedia, вероятно, достигла точки, когда предложения по дальнейшим идеям разделения служат только для академического обсуждения и, возможно, подпадают под WP: SLOP . Кудпунг กุด ผึ้ง ( разговор) 23:55, 2 апреля 2021 г. (UTC)
• Я не думаю, что нам следует сосредоточиться на лишении каких-либо прав пользователей у администраторов, несмотря на ожидающий в настоящее время арбитражный запрос. Тем не менее, я считаю, что нам следует подумать о создании новых прав пользователей, которые позволили бы обычным пользователям выполнять часть административных функций в областях, где есть особенно острая необходимость, и нехватка администраторов уже остро ощущается. По моим наблюдениям, одна из сфер, где уже остро ощущается нехватка активных админов, - это борьба с вандалами. Как я отмечал выше, AIV и RPP часто задерживаются в работе на несколько часов, и даже крики о помощи в ANI не обязательно приводят к достаточно быстрому ответу. Вот почему я предложил выше создать пользовательское право «борца с вандалами» с возможностью выпускать краткосрочные блокировки для редакторов без автоподтверждения и частично защищать страницы на срок до недели.Еще одно такое направление - CfD. Как выясняется, постоянное отставание настолько велико, что у администраторов есть де-факто практика разрешать неадминистраторам выполнять закрытие NAC "удаления" обсуждений CfD, игнорируяРГ: NACD . Поэтому было бы полезно создать какое-то право пользователя (если это технически возможно), позволяющее обычным редакторам выполнять некоторые низкоуровневые функции удаления, такие как удаление просроченных PRODS и, возможно, удаление категорий в не спорных случаях, а также, возможно, что-то еще, было бы полезно. Nsk92 ( разговор ) 00:34, 3 апреля 2021 (UTC)

  Я бы, вероятно, воспротивился любым усилиям по разделению трех «основных прав администратора» (удаление, блокировка, защита) в соответствии с обоснованием, которое я написал в WP: COREADMIN . Верно, что AIV, RFPP и другие области в последнее время задерживаются, но я считаю это скорее краткосрочной проблемой, которую можно решить, назначив двух или трех дополнительных администраторов, которые особенно заинтересованы в этих областях. Новая группа пользователей, вероятно, будет иметь непредвиденные последствия и будет опрометчивым долгосрочным решением краткосрочной проблемы. Mz7 ( разговорное ) 01:58, 3 апреля 2021 (UTC)

  Вы совершенно не правы. Аргументы в WP: COREADMIN абстрактны, но проблемы, о которых я говорю, являются конкретными и практическими, которые требуют решения и становятся все хуже. И они далеко не «краткосрочные». Некоторое время я наблюдал за задержками в RPP и AfD, и они были хроническими уже как минимум больше года. Как я уже сказал, дела в CfD стали настолько плохи, что теперь они позволяют NAC "удалять" закрытия в нарушение WP: NACD.. Я не уделял так пристального внимания AIV, но готов поспорить, что если проверить данные за последний год, мы обнаружим, что серьезные отставания сохраняются. Все эти проблемы только усугубятся, если их не решить (просто посмотрите, что происходит в Commons). Приток новых админов практически не снизился. В то же время мы теряем довольно много администраторов из-за выхода на пенсию, бездействия, недоразумений и т. Д. В то же время WP как проект становится все более сложным. Количество административных задач увеличивается, а также повышается уровень технических знаний, необходимых для их выполнения. Наша нынешняя модель администрирования просто неустойчива, и мы уже видим признаки того, что вещи расходятся по швам. Nsk92 ( разговор ) 13:31, 3 апреля 2021 (UTC)

  На самом деле я не возражаю против узкого предложения разрешить неадминистраторам закрывать CfD как «удалить», если это действительно уменьшит хроническое отставание. В прошлом я поддерживал такую ​​стратегию для WP: RFD , см. [5] . Это не потребует технических изменений в наборе инструментов администратора, и любое такое закрытие в конечном итоге должно быть проверено администратором, когда они пойдут нажимать кнопку «удалить».

  Что касается WP: AIV , я являюсь там активным администратором, и, по моему опыту, всякий раз, когда эта страница заполняется невыполненным журналом, это происходит не потому, что есть масса срочных запросов, ожидающих внимания, а скорее потому, что редакторы переполнили это с маргинальными сообщениями, которые действительно следует отклонить как «не вандализм, отнесите это в ANI», «пользователь неправильно или недостаточно предупрежден» или «без правок с момента последнего предупреждения». С психологической точки зрения, отклонить отчет сложнее, чем действовать с ним, потому что это требует конфронтационной позиции, поэтому кому-то может потребоваться больше времени, чтобы что-то сказать (в настоящее время у нас даже есть бот, который автоматически очищает устаревшие отчеты AIV. ). Я не такой уж и постоянный посетитель WP: RFPP, но когда я работал там несколько недель назад, когда было хроническое отставание, было то же самое: я отклонил подавляющее большинство отчетов, которые не были обработаны, вместо того, чтобы принимать меры.

  Это говорит мне о том, что действительно неотложные проблемы в AIV и RFPP - например, вандалы, которые спамят десятки изменений в минуту в различных статьях - уже решаются быстро в подавляющем большинстве случаев, и это менее срочные, более незначительные отчеты, которые образуют бэклог, те, которые в любом случае не выиграют от вмешательства неадминистратора. Mz7 ( разговорное ) 16:11, 3 апреля 2021 (UTC)

  Я думаю, что права администраторов должны оставаться такими, какие они есть, если только кто-нибудь не предложит автоматически назначать администраторам диспетчер фильтров редактирования, что я поддерживаю. Нет разделения, нет разделения, наше текущее количество администраторов слишком хрупкое. 🐔  Chicdat   ^{Bawk мне!} 10:08, 3 апреля 2021 г. (UTC)

• На данный момент я бы, вероятно, положительно отнесся к предложению, которое будет отделять только автоматическое патрулирование , но позволяет любому администратору самостоятельно предоставлять себе без ограничений, аналогично редактированию диспетчера фильтров . Это позволит администраторам, которые не так опытны в создании контента, как другие, получать обратную связь WP: NPP о своих статьях, если они того пожелают. Другие права, такие как откат и перемещение страницы, вероятно, не нужно разделять. Mz7 ( разговорное ) 01:58, 3 апреля 2021 (UTC)

  @ Mz7 : не уверен, что это действительно необходимо - если администратор не может создать страницу, которая прошла бы базовое патрулирование новой страницы - им действительно не следует создавать страницы - но если они просто хотят обратной связи, разве теперь у них нет такой возможности «отменить просмотр» страницы и вернуть ее в очередь? - ^{Обсуждение} xaosflux 15:38, 3 апреля 2021 г. (UTC)

  Полагаю, это справедливо. Я предполагаю, что это восходит к тому спорному вопросу в WP: RFA , который заключается в том, нужен ли значительный опыт в создании контента для того, чтобы быть администратором. В настоящее время руководящим принципом для предоставления автоматического патрулирования лицам, не являющимся администраторами, является предварительное создание 25 действительных статей, не считая страниц с перенаправлениями или устранением неоднозначности . Я знаю, что у меня не было 25 статей, когда я делал RfA (хотя у меня было два GA, но я знаю некоторых админов, которые продвигались с гораздо меньшими затратами). Mz7 ( разговорное ) 16:11, 3 апреля 2021 (UTC)

  @ Mz7 : это хороший ориентир, но основным компонентом новых страниц, которые патрулируют, является то, что они не являются CSD, что, как ожидается, администраторы смогут распознать (т.е. что это не нарушает "критерии Википедии для включения, авторское право нарушения, биография живых людей нарушения, конфликты интересов и реклама »). Если мы выбираем администраторов, которые действительно не могут сказать, является ли страница нарушением этих политик, у нас возникает гораздо большая проблема; не говоря уже о том, что администраторы сами также являются патрулями / обозревателями. - ^{Обсуждение} xaosflux, 20:08, 3 апреля 2021 г. (UTC)

  @ Nosebagbear недавно упомянул об этом на WP: VPP. Проблема в том, что я не думаю, что он прав. Когда он принимает статью в « Википедия: статьи для создания» , он делает осознанное суждение о том, есть ли у нее хотя бы 80% шансов на то, что « Википедия: статьи» подлежит удалению . Он хотел бы, чтобы второй или третий человек прошел такую ​​же оценку. Тем не мение:

  • Знания редакторов в предметной области сильно различаются, поэтому второе мнение может иметь меньшую ценность (или бесполезно).
  • Он говорит, что стремится к 80% -ной вероятности того, что статья уцелела в AFD, но ровно 0% из 90 черновиков AFC, которые он принял, были удалены в AFD. Только три из 90 были удалены. Две из 90 статей были перемещены обратно в пространство имен черновика кем-то другим и были удалены как заброшенные черновики (одна из этих тем была перемещена в пространство имен черновика по причинам, не связанным с известностью), а третья была удалена по просьбе автора. Все трое имеют право на получение WP: REFUND .

  Так что я сомневаюсь, что мы сможем извлечь какую-либо пользу из второго мнения. На самом деле, возможно, нам действительно нужно сказать сотрудникам AFC, что если ни одна из статей, которые они принимают, не попадает в AFD, то это признак того, что их стандарты слишком высоки. В любом случае, из этого обзора я пришел к выводу, что если Nosebagbear принимает черновик в AFC, нет смысла просить другого редактора попытаться найти причину для его удаления. WhatamIdoing ( разговор ) 05:06, 6 апреля 2021 (UTC)

  AFC - это не патруль новой страницы. AFC оценивает значимость и имеет тенденцию быть строгим, в то время как NPP пропускает больше вещей с помощью тегов очистки (при этом обнаруживая очевидные быстрые удаления). После этого любой достаточно компетентный, чтобы быть администратором, должен сохранить свои страницы на АЭС. Элли ( Обсуждение | вклад ) 10:05, 7 апреля 2021 (UTC)

  @ Элли , ну, я тоже так думаю, но Nosebagbear - администратор, у него гораздо меньшая скорость удаления статей, которые он принимает в AFC, чем, по его словам, он надеется достичь, и он все еще хочет, чтобы ребята из NPP перепроверили его работа. Не похоже, чтобы время NPP перепроверивало статьи, которые он уже одобрил. WhatamIdoing ( разговор ) 01:26, 8 апреля 2021 (UTC)

  @ WhatamIdoing : ну, черт возьми , для статей, созданных администратором, я, скорее всего, одобряю их, если они не являются явным вандализмом или чем-то еще, поскольку я верю, что администратор будет иметь представление о политике заметности. Так что это не что большая проблема, более просто бессмысленно. Элли ( Обсуждение | вклад ) 01:56, 8 апреля 2021 (UTC)

  Я согласен, что это бессмысленно. WhatamIdoing ( разговор ) 02:11, 8 апреля 2021 г. (UTC)

  Вот почему я считаю, что разукрупнение прав бессмысленно. Всем, кому доверена блокировка или удаление страниц, следует доверять такие вещи, как создание и откат статей. Если они достаточно облажались, чтобы заслужить отсутствие этих прав, им не следует быть администратором. Элли ( Обсуждение | вклад ) 02:22, 8 апреля 2021 (UTC)

• Пожалуйста, см. Википедию: разделение полномочий администраторов для получения некоторой истории. - Рой Смит (разговор) 16:10, 3 апреля 2021 г. (UTC)

  Хм, кажется, меня несколько раз упоминали на этой странице :) - jc37 00:29, 18 апреля 2021 г. (UTC)

• Помните, что наша проблема в том, что на должность администратора баллотируется недостаточно кандидатов. Каждый раз, когда мы разделяем часть набора инструментов, мы удаляем другой путь к администрированию, и когда люди становятся администраторами, они часто переходят в другие полезные области администрирования. Мне не известно о конкретном праве, которое можно было бы разделить таким же образом, как откат, перемещение файлов и редактор шаблонов. Теперь у нас остались вещи, которые идут вместе - например, вы не можете установить автопатроллер, не просматривая чьи-то удаленные правки. Шере Шпиль Чекерс 13:10, 4 апреля 2021 г. (UTC)
• Я бы решительно поддержал это предложение, если бы это было предложение. Конечно, это случается нечасто, но были случаи, когда администратор злоупотреблял второстепенным правом пользователя таким образом, который обычно решался бы простым удалением этой одной привилегии, но поскольку пользователь является администратором, средство защиты - это дезактивация, которая на подарок можно сделать только через длинное дело Arbcom. Если мы сохранили набор инструментов администратора для прав пользователей, которые являются исключительными для администраторов, наряду с предоставлением обычных прав пользователей, не являющихся администраторами, во время успешного RFA, то это легкое изменение (кроме `` кратов '', которые, я уверен, может обрабатывать несколько дополнительных флажков несколько раз в год или это может быть сделано с помощью сценария), что также улучшает наши процессы. Иванвекторская белка ( ^{деревья} / _орехи) 13:51, 10 апреля 2021 г. (UTC)
• Я разделяю озабоченность WSC по поводу разделения. Я поддерживаю утверждение Mz7 о том, что мы должны сделать автопатрол как фильтр редактирования. У администратора нет возможности отменить просмотр своей собственной страницы, поэтому нет простого способа, например, чтобы администратор мог принять маргинальную статью в AfC и попросить второго редактора просмотреть ее как часть NPP (и с тех пор, как это 80 % стандарт для этого?). Только по этой причине я поддерживаю превращение автопатруля в удобный переключатель для администраторов. Barkeep49 ( разговорное ) 22:49, 17 апреля 2021 (UTC)

  @ Barkeep49 : Я открыл phab: T280890 - не вижу причин, по которым им следует запретить отменять просмотр страницы. - ^{Обсуждение} xaosflux, 23:19, 21 апреля 2021 г. (UTC)

• Позвольте мне повторить то, что я сказал ранее: вместо того, чтобы отбирать права пользователей у администраторов, мы должны создавать новые права пользователей, позволяя выполнять определенные административные задачи низкого уровня и делая их доступными для обычных пользователей. Нам по-прежнему нужны «полные администраторы», но поскольку Википедия становится все более сложной, а поступление обычных редакторов стагнирует, мы не собираемся получить резкий наплыв кандидатов RfA. Мы должны принять это как данность, начать относиться к «полноправным администраторам» больше как к негодяям и начать привлекать обычных пользователей к выполнению большего количества реальных административных задач. Nsk92 ( разговор ) 00:11, 22 апреля 2021 (UTC)

  У нас есть обычные пользователи, выполняющие фактические административные задачи, именно так у нас есть редактор шаблонов и движок страниц (не говоря уже об откате, который раньше был основной причиной, по которой кто-то использовал RfA). Исторически разделение только затрудняло прохождение RfA, и я думаю, что это уже достаточно сложно. С уважением , Barkeep49 ( разговор ) 01:54, 22 апреля 2021 (UTC)

Местоимения в информационных ящиках [ править ]

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

Несмотря на то, что это постраничная вещь, внедрение этого стандарта для страниц, относящихся к конкретному человеку, было бы чрезвычайно полезным при внедрении этой функции на уровне всего сайта. - Предыдущий неподписанный комментарий, добавленный Itscrossboy ( обсуждение • вклад ) 09:16, 5 апреля 2021 г. (UTC)

Я так не верю. Местоимения толпы «они / они» объявляются в их статьях. Если бы Википедия была такой: «Джон Доу родился в 2000 году. В 2010 году он устроился на работу. В 2020 году она основала пиццерию. В 2021 году они расширили свое меню». тогда это было бы полезно. Но так как это не так, это не так. 🐔  Chicdat   ^{Bawk мне!} 10:09, 5 апреля 2021 г. (UTC)

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

Проблема заключается в том, что многие из наших редакторов (особенно новые редакторов) считают , что мы должны заполнить каждый параметр в Infobox ... и сделать так , редактор будет либо гадать, либо использовать местоимение , что редактор берет на себя субъект предпочтет ( или, что еще хуже, редактор добавит местоимение, которое предпочитает редактор) - и это нарушит WP: нет оригинального исследования . В тех случаях, когда нам известно предпочтение биосубъекта, мы можем просто использовать его в тексте статьи - при необходимости. Blueboar ( разговор ) 12:25, 5 апреля 2021 (UTC)

• Я не думаю, что это хорошая идея, мы не викиданные, поэтому помещать все возможные атрибуты человека в рамку не обязательно. - ^{Обсуждение} xaosflux 12:59, 5 апреля 2021 г. (UTC)
• Противодействовать как ненужное и, вероятно, стать магнитом для разрушительного редактирования. ƒirefly ( t · c ) 13:17, 5 апреля 2021 г. (UTC)
• Выступайте против из-за того, что это ненужное дополнение и огромный потенциал для противодействия редактированию. JackFromReedsburg ( Обсуждение | вклад ) 19:42, 10 апреля 2021 (UTC)
• Противопоставить простые ситуации можно просто использовать в тексте. Более сложные или необычные варианты использования потребуют объяснения в тексте и не будут адекватно отражены в информационном окне. Это вообще не будет обычным делом. Наличие параметра в поле почти всегда бесполезно и в то же время продвигает политическую точку зрения. Грэм Бартлетт ( разговорное ) 20:52, 10 апреля 2021 (UTC)
• Комментарий . Возможно, время для реализации этой идеи придет (и, возможно, раньше, чем может показаться), но пока это предложение, вероятно, преждевременно. Как отмечалось выше, относительно немногие люди заявили о своих предпочтениях в отношении местоимений, и еще в меньшем количестве случаев у нас есть WP: RS, которые указывают, что это за варианты. Если такая информация доступна, ее можно обсудить в основной части статьи, и я считаю, что это уже наша стандартная практика. Создание нового поля информационного окна, скорее всего, потребует большого количества WP: ИЛИ и догадок, а также потенциальной войны при редактировании. Nsk92 ( разговор ) 01:04, 24 апреля 2021 (UTC)
• Против. - Указание местоимений - это скорее вопрос «от первого лица»: «Привет, я Тейлор. Мои местоимения - она ​​/ она / она». Это помогает, потому что у человека редко есть причина использовать гендерные местоимения самореференциальным способом, и это сигнализирует другим, какие такие местоимения использовать при обращении к этому человеку. Но мы пишем о человеке и будем использовать местоимения довольно часто. Нам не нужно «рассказывать» читателю, когда мы можем «показать» его. Конечно, может быть полезна сноска или заметка на странице обсуждения, объясняющая любые случаи, которые могут быть неожиданными для читателя, но нет причин бить читателя по голове этим в каждой биографии. - Хаджида ( разговор ) 23:57, 24 апреля 2021 (UTC) PS - приведенный выше пример является лишь гипотетическим,не заявление о себе.
• Противопоставить - указание местоимений где-то поддающееся проверке не является нормой, и энциклопедия полностью покрывает эту тему, выбирая местоимения для использования в самих статьях. Если гендерная идентичность человека важна для биографии, мы помещаем это в текст статьи, обычно в разделе «Личная жизнь». ›  Mortee talk 00:02, 25 апреля 2021 г. (UTC)

Как насчет того, чтобы делать все запросы на комментарии на подстраницах страницы RFC? [ редактировать ]

Все объявления AfD, не являющиеся шутками, находятся на подстраницах главной страницы Википедии: Статьи для удаления . Таким образом, я предлагаю, чтобы все будущие Запросы на комментарии в обязательном порядке делались подстраницами Википедии: Запросы на комментарии . Я также предлагаю стандартизировать названия будущих RFC в следующем формате:

• Wikipedia:Requests for comment/In re [page name]для RFC, относящихся к одной странице. (не стесняйтесь заменять «in re» такими словами, как «относительно», но его замена должна быть стандартизирована по всем направлениям).
• Wikipedia:Requests for comment/[question] для RFC по общим вопросам, которые нельзя легко классифицировать как относящиеся только к конкретным / конкретным страницам.
• Wikipedia:Requests for comment/[proposal] для предложений.

В идеале может быть шаблон RfC (да, я знаю о Википедии: Запросы на комментарии / Пример форматирования ), который пользователь мог бы использовать при создании RfC (cf {{ afd2 }}, где единственное, что вам нужно сделать, это ввести ваше рассуждение, название страницы и ее категория). Дополнительным преимуществом стандартизации является то, что она может открыть дверь для WP: Twinkle, чтобы охватить также RfC (хотя это не основная причина моего предложения). Спасибо, ДеПлюм ( разговор ) 04:17, 8 апреля 2021 (UTC)

Я не вижу проблемы, которую это решает. Элли ( Обсуждение | вклад ) 05:27, 8 апреля 2021 (UTC)

Прямо сейчас RFC повсюду. Некоторые из них находятся на страницах обсуждения Статей, другие - как подстраницы WP: RfC , а третьи - как подстраницы различных страниц проекта (не обсуждения проекта). Создание всех подстраниц WP: RfC значительно повысит единство, поскольку для них будет использоваться одно место вместо 100+. - ДеПлюм ( разговор ) 05:34, 8 апреля 2021 г. (UTC)

DePlume: Думаю, это просто кажется ненужным, учитывая различную «официальность» или что-то еще из RFC. Действительно ли нужна подстраница вместо поста в WP: RSN или где-то еще? Чувствует себя чрезмерно. Элли ( Обсуждение | вклад ) 05:50, 8 апреля 2021 (UTC)

Я не прошу дважды размещать RFC. Это всего один раз, как и в номинациях от АдГ. NotReallySoroka ( разговор ) 01:16, 11 апреля 2021 (UTC)

Я думаю, что есть некоторые преимущества, такие как поиск и создание RfC немного быстрее с поддержкой Twinkle, а также отсутствие 15 страниц по той же причине. Я понимаю, почему это может быть необязательно, но может иметь умеренные преимущества. Поджоги ( разговор ) 14:58, 8 апреля 2021 (UTC)

• Есть преимущества наличия RFC для конкретных статей на страницах обсуждения статей, например, наличие предыдущих обсуждений и самой статьи под рукой, но есть и другие RFC, которые не относятся к конкретным статьям, поэтому их нужно искать в другом месте. Пока RFC регистрируются и рекламируются в центральном месте, я не вижу никакой пользы в стандартизации того, где проводится само обсуждение. Я не думаю, что мы должны принимать решения на основе того, что легко реализовать в Twinkle (идет ли он в библиотеку, чтобы найти хорошие источники и добавить их в статьи? Если да, я мог бы рассмотреть возможность его использования), но в любом случае я не понимайте, что было бы слишком сложно в том, чтобы добавить правильные заголовки RFC везде, где проводится обсуждение, если для людей действительно слишком обременительно делать это самим. Фил Бриджер (разговор ) 15:25, 8 апреля 2021 (UTC)
  • Спасибо, но Twinkle - это лишь побочная выгода, а не главная причина. Деплюм ( разговор ) 17:31, 8 апреля 2021 (UTC)
    • Тогда что это ваша главная причина? Я не вижу ни одного в вашем первоначальном комментарии, это просто утверждение, что мы должны это сделать. Фил Бриджер ( разговорное ) 17:54, 8 апреля 2021 (UTC)
      • Фил Бриджер. Есть единство (предотвращает разброс RfC по всей Википедии), удобство (те, кто хочет ответить на RfC, могут легко найти ответ) и стандартизованный формат, и это лишь некоторые из них. Извините за поздний ответ, NotReallySoroka ( разговор ) 01:15, 11 апреля 2021 г. (UTC)
        • Мы хотим, чтобы АдГ оставались видимыми при удалении статьи и страницы обсуждения, чтобы они не удерживались на странице обсуждения. У RfC нет такого беспокойства, и они не включены на такие страницы, как Википедия: статьи для удаления / Журнал / 11 апреля 2021 года . Я не вижу достаточных причин для удаления RfC со страницы, которая их больше всего волнует. А назначать ли обсуждение RFC часто является произвольным решением. PrimeHunter ( разговорное ) 11:18, 12 апреля 2021 (UTC)
          • Есть еще одна причина, по которой имеет смысл разместить АдГ для всех статей в одном месте, даже если имеет смысл разместить другие RFC по статье на странице обсуждения этой статьи: у официальных статей есть подписчики, которые будут заинтересованы в RFC по статье. У новой статьи таких подписчиков нет; Люди, заинтересованные в том, следует ли удалять статью, - это люди, которых интересует объем Википедии. Эти люди подписаны на страницу АдГ. Брайан Хендерсон (giraffedata) ( разговор ) 21:46, 24 апреля 2021 года (UTC)
• Я понимаю, что RFC повсюду. Если у вас нет каждой области в вашем списке наблюдения или вы не заметили ее на централизованной доске обсуждений, имеет смысл сделать ее централизованной в одном месте. Дэвидстюартхарви ( разговор ) 13:52, 12 апреля 2021 (UTC)
  • Текущие RFC перечислены в Wikipedia: Requests for comment / All . PrimeHunter ( разговорное ) 14:13, 12 апреля 2021 (UTC)
  • Наличие RfC в виде подстраниц на одной странице упростит их поиск (с этого момента), но я не думаю, что это повлияет на то, насколько легко заметить новые RfC. Использование поддерживаемой ботами страницы, на которой перечислены все текущие RfC, по-прежнему будет лучшим способом. И уже немного поздно пытаться улучшить поиск, поскольку уже существует длинная история запросов в других местах, которые людям все равно придется искать. (Не думаю, что стоит тратить силы на их перемещение и исправление всех ссылок на них.) Isaacl ( обсуждение ) 15:08, 12 апреля 2021 г. (UTC)
    • Как я уже сказал, решение о том, обозначать ли обсуждение как RfC, часто является произвольным. Я думаю, что упрощение поиска старых RFC имеет ограниченную ценность. PrimeHunter ( разговорное ) 15:35, 12 апреля 2021 (UTC)

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

      Я просто пытаюсь взвесить варианты использования для поисковиков. Как часто я специально ищу RFC о чем-то? Никогда. Как часто я ищу в архивах страницы обсуждения, которые обычно там бывают? Часто. Я думаю, что "пространство RfC" затруднит поиск дискуссий, а не облегчит обычному поисковику. Может быть, им повезет и они попадут в уведомление о RfC в архивах, которые они ищут, но шанс намного выше, если там будет фактическое обсуждение. PrimeHunter ( разговорное ) 23:18, 12 апреля 2021 (UTC)

      Я не поддерживаю это предложение по указанным мною причинам (не понимаю, как оно помогает людям замечать новые RfC или помогает в поиске в текущей ситуации), но я не хотел игнорировать потенциальный способ интерпретации предложения автора. точка зрения на преимущества предложения. isaacl ( разговор ) 23:30, 12 апреля 2021 (UTC)

Я считаю, что предпочтительно оставлять большинство RFC, в частности, RFC по статьям, на соответствующих страницах обсуждения. Здесь можно просмотреть обсуждения, ведущие к конкретному RfC, соответствующие архивы страниц обсуждения и т. Д. Тем не менее, я также думаю, что есть некоторые преимущества в том, что старые RfC доступны для поиска. RfC - это формальный, определяющий консенсус шаг в процессе разрешения спора . Хотя первоначальное решение обозначить конкретное обсуждение как RFC часто бывает произвольным, решения, принятые в RFC, впоследствии имеют больший вес, а их выводы считаются более авторитетными по сравнению с обычными обсуждениями на страницах обсуждения. Поэтому я думаю, что, возможно, стоит заставить ботов каким-то образом систематически индексировать старые RfC после их закрытия или истечения срока их действия. Nsk92 ( обсуждение) 23:58, 12 апреля 2021 г. (UTC)

Я согласен с @ Nsk92 о сохранении RFC о содержании отдельной статьи на странице обсуждения этой статьи.

Тем не менее, я хотел бы, чтобы большой объем Википедии: Надежные источники / Многолетние источники был перемещен из Википедии: Надежные источники / Доска объявлений , чтобы RSN снова стала функциональной доской с разумными размерами. WhatamIdoing ( разговор ) 02:21, 23 апреля 2021 (UTC)

Темный режим [ править ]

Сразу заметил, что XTools перешел на полностью черный фон. Я действительно копаюсь в этом. Есть ли какие-нибудь усилия / попытки добавить темный режим в Википедию? Не должно быть слишком сложно, правда? ~ HAL 333 01:44, 10 апреля 2021 г. (UTC)

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

Это реализовано в мобильной версии. Sungodtemple с TCG вентилятор !! 1 ! 11 !! ( разговор ) 00:22, 11 апреля 2021 (UTC)

HAL333 , тьфу , надеюсь, что нет. Просто подождите, пока ваши глаза не станут на пару десятилетий старше и вам понадобится весь возможный контраст. - РойСмит (разговор) 23:25, 12 апреля 2021 г. (UTC)

@ HAL333 : В ваших настройках (гаджетах) есть что-то похожее, что меняет текст на зеленый, а фон на черный, но я подозреваю, что к этому нужно привыкнуть. Sdrqaz ( разговор ) 00:51, 20 апреля 2021 (UTC)

Ух ты. Просто попробовал, и хотя он приятен для глаз, я бы хотел, чтобы он не был таким ярким. ~ HAL 333 01:37, 20 апреля 2021 г. (UTC)

Похоже, они только что выпустили темный режим в разделе «Тестирование и разработка», xaosflux и HAL333 (или, может быть, я просто пропустил его целую вечность). Выглядит неплохо. Sdrqaz ( разговорное ) 23:08, 22 апреля 2021 (UTC)

Sdrqaz , в настройках тоже есть Тестирование и Разработка? ~ HAL 333 19:36, 23 апреля 2021 г. (UTC)

@ HAL333 : Да, он находится в нижней части раздела "гаджеты" (должен быть предпоследним) предпочтений. Sdrqaz ( разговор ) 19:46, 23 апреля 2021 (UTC)

Я только что включил его, и О, БОГ, ЭТО СЛЕДАЕТ МЕНЯ, фон буквально черный, а текст белый, что делает его явно нелегким для глаз. Можно ли вместо этого сделать фон темно-серым? (Это вообще подходящее место для публикации?) ♔ MEisSCAMMER ^{(обсуждение) (вклад)} 22:04, 23 апреля 2021 г. (UTC)

@ MEisSCAMMER и @ Sdrqaz , это обсуждается в Википедии: Village_pump_ (технический) # Proposal_for_a_dark-mode_gadget_addition_ (before_Earth_Day_22_April?) . Я тоже считаю, что чернота ослепляет, но только на некоторых устройствах. Комментарии будут приветствоваться. - SD0001 ( разговор ) 08:43, 24 апреля 2021 г. (UTC)

Проблема нового пользователя [ править ]

Это могло быть не в том месте; не стесняйтесь перемещать обсуждение: в последнее время я видел, как много новых пользователей укусили более опытные пользователи, например, в этом различии. В нем User: David notMD посчитал, что редактирование пользователя было неконструктивным вандализмом , поэтому они вернулись, и теперь новый пользователь говорит: «И это теперь моя последняя правка в любой статье» о выборе слова. Предполагается, что Википедия будет открытым пространством, но слишком часто на страницах обсуждений, RFC, AfDs и т. Д. Присутствует очень много резкости, если не преднамеренной, которая отпугивает даже опытных пользователей. Есть ли способ сделать Wiki более открытой?

Идеи:

1. Каждый раз, когда кто-то регистрируется, проведите его через обязательное руководство. Это ударит двух зайцев одним выстрелом: вандалы не будут поощрять создание носков , а новые редакторы не станут слишком быстро пытаться редактировать избранные статьи .

2. Сделать политики и руководства Википедии более доступными для новых пользователей. Например, при создании учетной записи новые пользователи будут перенаправлены на страницу с кратким описанием политик и не слишком длинную, чтобы они понимали, что делать, а что не делать.

Я уверен, что это поможет решить проблемы с вандалами и тонким вандализмом. У кого-нибудь есть другие идеи по этому поводу? Sungodtemple с TCG вентилятор !! 1 ! 11 !! ( разговор ) 00:39, 11 апреля 2021 (UTC)

• Я не думаю, что у кого-то есть предложения по поводу хорошего «обязательного руководства» или краткого обзора всех важных политик. Требование «обязательного обучения», конечно же, не «сделает Wiki более открытой». Многие вклады новых пользователей неконструктивны и должны быть отменены, никакое желание быть хорошим не изменит этого. И ваш пример не такой, как вы описываете; Никто не сказал, что первоначальная правка была вандализмом, а редактор, который ее сделал, находится здесь более года, и внес более 500 правок. Юзер: 力(power ~ enwiki, π , ν ) 01:14, 11 апреля 2021 г. (UTC)
  • Что ж, похоже, что мои принципы и принципы Wiki здесь противоречат друг другу. Я бы предпочел улучшения , но Wiki предпочитает открытость , вероятно, потому, что они не хотят, чтобы люди жаловались на то, что редакторы Wiki являются закрытым сообществом. Sungodtemple с TCG вентилятор !! 1 ! 11 !! ( разговор ) 19:13, 11 апреля 2021 (UTC)
• К вашему сведению . Редактор обвинял меня в вандализме за то, что я отменил дополнения к «См. Также» более чем в одной статье. Я вовлек редактора в обсуждения на страницах обсуждения рассматриваемых статей и в Teahouse. Кроме того, Ви не новый редактор, он активно редактировал с апреля 2019 года. Дэвид notMD ( обсуждение ) 01:23, 11 апреля 2021 года (UTC)
• Это вообще не похоже на проблему. Новому редактору сказали, что есть разногласия по поводу их редактирования и что страница обсуждения статьи является местом для обсуждения этого. Если пользователь затем называет несогласие вандализмом и отказывается принимать советы о подходящем месте для обсуждения, тогда этот пользователь не подходит для редактирования Википедии, что включает гражданские разногласия и обсуждения. Лучше узнать об этом раньше, чем позже. Фил Бриджер ( разговор ) 19:35, 11 апреля 2021 (UTC)
• @ Sungodtemple : Для этого есть WP: HI . В защиту Дэвида notMD я могу с уверенностью сказать, что он не подвел WP: COMMUNICATE полностью, он кратко объяснил себя здесь . С другой стороны, его вклад не был таким дружественным. В целом я не думаю, что идея стоит того, чтобы ее развивать, поэтому предлагаю закрыть это обсуждение. (Я также сделал здесь предложение , чтобы всех успокоить) - AXO NOV (разговор) ⚑ 15:37, 15 апреля 2021 г. (UTC)
• У меня есть несколько идей. Во-первых, «учебник» уже существует или что-то подобное. Когда новые пользователи создают учетную запись, появляется интерфейс с рекомендациями для редактирования статей, хотя и без упоминания политики. WP: TFA - хорошее, поддерживаемое в настоящее время, подробное и простое в использовании более длинное «введение». Кроме того, уже существуют упрощенные версии многих политик WP, включая WP: SMOS , HELP: PG , WP: SR , WP: 8 , WP: 10SR , WP: SRI и т. Д.

Возможные варианты реализации, относящиеся к вышеизложенному:

• Сделайте упрощенные наборы правил более доступными и публичными, например, сделайте ссылки на главной странице.
• Ссылка на TFA в уже существующем «введении».
• Добавьте краткое изложение политики к уже существующему «введению».

Требуются материалы для моего эссе WP [ править ]

Здравствуйте, может ли кто-нибудь дать отзыв о моем эссе, Пользователь: NotReallySoroka / Нет такого перенаправления, как "Dorian Fried" , которое выступает против создания перенаправления на отчество и фамилию без имени? Спасибо, NotReallySoroka ( обсуждение ) (ранее DePlume) 05:06, 17 апреля 2021 г. (UTC)

Уважаемый пользователь: NotReallySoroka , вы можете создать эту статью, и если она окажется в стадии зарождения в Википедии, она будет перемещена в черновик. Вы можете следить за этим и видеть, привлекает ли он достаточно внимания со стороны других пользователей, чтобы довести его до качества статьи в Википедии. С уважением, Ролло Август ( разговор ) 21:38, 25 апреля 2021 года (UTC)

Изменение интерфейса списка наблюдения [ править ]

В настоящее время, когда редакторы заканчивают редактирование и прокручивают вниз до полосы кнопок, в раскрывающемся списке рядом с «Посмотреть эту страницу» отображается: «Постоянно». Я считаю, что это не идеальная формулировка, поскольку она подразумевает, что вы не можете удалить статью из своего списка наблюдения. Вместо этого я думаю, что его следует изменить на « Пока я не удалю» или « Пока не удалю» . Есть мысли по этому поводу? EpicPupper 21:03, 17 апреля 2021 г. (UTC)

Другие варианты 1 неделя, 1 месяц, 3 месяца, 6 месяцев также могут быть удалены или изменены пользователем раньше. Я думаю, что лучше просто продолжить краткое изложение того, что происходит, без дальнейших действий. Большинство пользователей, вероятно, знают или догадываются, что за страницами можно не следить. «Пока я не удалю / не удалю» может создаться впечатление, что пользователь должен когда-нибудь удалить его. Думаю, большинство просматриваемых страниц никогда не будут удалены. PrimeHunter ( разговорное ) 00:41, 18 апреля 2021 (UTC)

Идея решить проблему перенаселенности и спагеттизации статей по контекстным спецификациям [ править ]

Одна вещь, которую я отмечаю в Википедии, - это полное отсутствие заметок, как и в любой печатной энциклопедии в моем детстве.

Это приводит к чрезмерному увеличению количества сложных статей, которые зигзагообразно перемещаются по теме только для того, чтобы прояснить конкретный контекст по теме с помощью очень длинных абзацев, когда. ^[1]

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

Наиболее распространенными примерами, но не только, являются бесконечные списки культурных вариантов, в которых «некоторые страны» ^[2] помогли бы перемежать статью. ^[3] Не говоря уже о ^[4]

Википедия должна применять политику заметок с ног до статей и добавить в свой стиль раздел с заметками.

Кажется, я знаю, что в стиле Википедии уже есть очень непопулярный раздел заметок, но я думаю, что он используется для других целей (в основном для добавления цитат и цитат?).

Я только сожалею, если моя идея будет принята, что возможность машинной читаемости из внешних сценариев будет потеряна, и grep дампа lynx википедии будет выводить только сноску предиката (например, в Аргентине, Бразилии и Уругвае) ​​без темы (e , g. asado), но, в свою очередь, мои человеческие глаза это очень предвидят. - Предыдущий неподписанный комментарий, добавленный Neurorebel ( обсуждение • вклад )

Neurorebel , я не понимаю, в чем ваша идея. Не могли бы вы уточнить? Кроме того, уже стало обычной практикой добавлять примечания в длинные списки, как в Bill Nye the Science Guy # Format . Sungodtemple с TCG вентилятор !! 1 ! 11 !! ( разговор ) 01:55, 18 апреля 2021 (UTC)

@ Neurorebel : Вам нужны {{ efn }} и {{ notelist }}. Но я предполагаю, что здесь задается вопрос: достаточно ли чего-то актуального, чтобы упоминать о нем в прозе статьи? Если нет, то это можно упомянуть в сноске , например: Новый год отмечают во многих странах. ^[a] -  Finnusertop ( обсуждение ⋅ вклад ) 06:21, 18 апреля 2021 г. (UTC)

Neurorebel , я чувствую, что ваше предложение по сноске будет больше похоже на функцию, которая упрощает "забавные / тривиальные факты", что не является чем-то распространенным в Википедии: информация либо достаточно значима, чтобы ее можно было упомянуть, либо нет. Кроме того, основной контекст должен принадлежать основной статье, и если он слишком длинный, ненужные детали следует опускать. Что касается терминологии, требующей пояснения, то, если она не понятна носителю или хорошо владеющему английским языком, то, вероятно, это жаргон, и его следует избегать (см. 2-й абзац руководства по стилю ). В противном случае читатели могут просто выполнить поиск в словаре или определить значение слова из контекста. Однако это многообещающая идея,и может быть способ изменить его, чтобы его можно было успешно ввести в действие.Лэнкиливер ( разговорное ) 11:59, 18 апреля 2021 (UTC)

Neurorebel , у нас уже есть этот функционал, но нет причин делать его обязательным; все зависит от темы. Раздел макета Руководства по стилю Википедии определяет пояснительные сноски как те, которые дают информацию, которая слишком подробна или неудобна для содержания статьи . Схема того, как это сделать, дана там: раздел «Примечания» идет впереди раздела «Ссылки». См. Статью Абу аль-Фарадж аль-Исфахани, в которой широко используются пояснительные примечания. Шаблон: у Efn есть инструкции по их созданию. При необходимости в заметках могут быть указаны сами ссылки, как описано в Википедии: Вложенные сноски . Звездная бабушка ( разговор) 22:44, 18 апреля 2021 г. (UTC)

• Нет ни Википедии: Гипертекст, ни Википедии: Как написать гипертекстовую страницу, и они должны быть. Пользователь: 力(power ~ enwiki, π , ν ) 00:38, 20 апреля 2021 г. (UTC)

@力: вы имеете в виду Help: HTML в wikitext ? -  Finnusertop ( обсуждение ⋅ вклад ) 20:51, 20 апреля 2021 г. (UTC)

Что-то вроде. Справка: Wikitext объясняет, «как использовать гипертекст», но не является руководством по стилю о том, «чем написание гипертекста отличается от записи в физическом дневнике». Пользователь: 力(power ~ enwiki, π , ν ) 16:41, 22 апреля 2021 г. (UTC)

Думаю, стоит сделать сноски более очевидными. По этой причине я всегда использую стиль {{ NoteTag }}. Другие сноски выглядят просто как цитаты, то есть вещи, которые читатель игнорирует. Ватицидальный пророк 09:51, 20 апреля 2021 г. (UTC)

• Согласно с пользователем: Vaticidalprophet - Википедия делает много сносок, но это в значительной степени ссылки citatiions. Лично я не был бы против наличия большего количества сносок, если они добавляют полезную информацию к статье, но нам нужно быть осторожными, чтобы они ссылались на другой список со списком ссылок. Ролло Август ( разговор ) 21:47, 25 апреля 2021 (UTC)

Повторное подтверждение предложения об администрировании (ROA) [ править ]

Я рассматриваю RFC для добавления следующего текста в новый раздел WP: ADMIN :

Обсуждения повторного подтверждения административных полномочий (ROA) - это процесс добровольного повторного подтверждения того, есть ли у администраторов согласие сообщества на то, чтобы оставаться администратором. Обсуждения РОА должны быть включены в Википедию: Запросы на администрированиеиспользуя шаблон {{tls | Повторное подтверждение шаблона администрирования}}. Любой администратор может инициировать обсуждение ROA самостоятельно в любое время. Подобно запросам на администрирование, обсуждение подтверждения длится 7 дней, в течение которого редакторы могут задать по два вопроса каждый, а обсуждение закрывает бюрократ. В отличие от запросов на администрирование, порог для сохранения инструментов администратора составляет 60% участников, не считая нейтральных, а разница между 50% и 60% должна быть оценена бюрократами, чтобы определить, существует ли консенсус для продолжения доступа к набору административных инструментов. Администраторы, которые отказываются от открытого ROA или не получают достаточной поддержки, теряют административные привилегии.

(текст основан на этом различии ; я считаю, что Вугаподес и я были единственными редакторами, но проверьте эту страницу на предмет атрибуции)

Черновик шаблона можно найти в Википедии: Запросы на комментарий / Изменение требований к действиям сисопа / Повторное подтверждение шаблона администрирования .

Обсуждение в Википедии: Запросы на администрирование / Harrias 2 (и несколько лет назад в Википедии: Запросы на администрирование / HJ Mitchell 3 ) должно продемонстрировать, почему предлагается эта политика. Юзер: 力(power ~ enwiki, π , ν ) 00:02, 20 апреля 2021 г. (UTC)

Другие комментарии к ROA [ править ]

• Что касается форума, я ожидаю начать обсуждение в виде RFC на Википедии: «Администраторы» со ссылкой со страницы «Village Pump (политика)». Юзер: 力(power ~ enwiki, π , ν ) 00:02, 20 апреля 2021 г. (UTC)
• Что касается аббревиатуры, я предпочитаю «ROA», но «RoA» могут предпочесть другие редакторы. Юзер: 力(power ~ enwiki, π , ν ) 00:02, 20 апреля 2021 г. (UTC)
• Там нет на самом деле определения , что такое РОА есть . Например, может ли любой администратор в любое время инициировать обсуждение ROA о другом администраторе ? - xaosflux ^Talk 00:18, 20 апреля 2021 г. (UTC)
  • Я думал, что было очевидно, что ROA будет о том, что администратор начнет обсуждение, но вы правы, это действительно нужно заявить. Так же забыл ссылку на черновик шаблона, исправляю сейчас. Пользователь: 力(power ~ enwiki, π , ν ) 00:20, 20 апреля 2021 г. (UTC)
• Не нужен. Если конкретный администратор действительно захочет снова пройти RfA, он может избавиться от излишнего надзора и просто снова запустить его. Для этого нам не нужен отдельный процесс (если только это не предоставит сообществу возможность удалить администраторов, а это не так). Это предложение требует дополнительной информации о том, почему оно лучше, чем повторный RfA. JackFromReedsburg ( Обсуждение | вклад ) 01:03, 20 апреля 2021 (UTC)
  • В Википедии возникли серьезные разногласия : запросы на администрирование / Харриас 2 относительно того, должно ли оно быть в Категории: Успешные запросы на администрирование , среди прочего; обратите внимание на историю редактирования. В разговоре с Википедией: Администраторы / Архив 18 # RFC_about_reconfirmation_procedures предложения с намерением, противоположным этому, не нашли консенсуса. Юзер: 力(power ~ enwiki, π , ν ) 01:12, 20 апреля 2021 г. (UTC)
• Я не вижу особой причины поощрять повторные RfA текущих админов. Этот процесс кажется мне довольно самолюбивым - не столько я принципиально возражал бы, как несколько человек из Harrias 2, но достаточно, чтобы быть немного сомнительной практикой. Если вы делаете это, чтобы следовать критериям отзыва, я не вижу веских причин давать ему особое имя, чтобы ... отделить себя от болвана? Честно говоря, я не убежден, что это не «о, черт, у нас уже два месяца пусто поле Текущих RfA, давайте увеличим эти цифры, поощряя повторные RfA». Ватицидальный пророк 01:07, 20 апреля 2021 г. (UTC)
  • Я также считаю, что Harrias 2 - это вовсе не обсуждение необходимости такого процесса, а обсуждение того, насколько он не нужен сообществу . Эта нейтральная колонка была не просто парочкой отбросов, как в среднем RfA - это было сильное заявление от имени примерно трети участников о том, что они были настолько обеспокоены идеей создания прецедента в их пользу, что отказались. чтобы поддержать кого-то, кого они считали достойным швабры. Ватицидальный пророк 01:11, 20 апреля 2021 г. (UTC)
• На данный момент я изо всех сил пытаюсь понять, почему кто-то решил сделать это. Помогите мне понять? Stifle ( разговор ) 09:52, 20 апреля 2021 (UTC)
  • Администратор, желающий проверить, остается ли доверие сообщества к продолжающемуся администрированию. Это также шаг к предложению дезисопа. Результат таких RfA будет свидетельствовать о том, насколько обоснованны утверждения о том, что RfA существующих администраторов будут заполнены редакторами с жалобами и недовольствами и, таким образом, потерпят неудачу (что приводит к тому, что предложения Desysop терпят неудачу в силу `` необходимости защищать администраторов, которые принимают жесткие меры ''). действия '). Однако для этого потребуются очень самоотверженные администраторы, поэтому как минимум должно быть доказательство того, что есть несколько администраторов, которые даже подумывают о том, чтобы пройти через это. ProcrastinatingReader ( разговор ) 14:02, 20 апреля 2021 (UTC)
    • В той степени, в которой нам нужны доказательства, я бы предложил два: один - это все наши администраторы, у которых есть критерии отзыва, а другой - 3-4 администратора, которые добровольно вызвались действовать в качестве пробной версии предложения об обязательном повторном подтверждении, которое не удалось. совсем недавно. Nosebagbear ( разговор ) 14:04, 24 апреля 2021 (UTC)
  • Однажды я сделал это в русской Википедии (и стал первым админом, прошедшим всю процедуру), потому что группа пользователей стала громко критиковать меня, и я не был уверен, есть ли у меня до сих пор поддержка сообщества. Я решил выдержать повторное подтверждение и получил более 90%, против 3 пользователей, - Ymblanter ( разговор ) 18:58, 21 апреля 2021 г. (UTC)
• Похоже, что это добавляет ненужной сложности, создавая так называемый «ROA» со специальными инструкциями. Упростите предложение; просто добавьте предложение, в котором говорится (более элегантными словами): Пользователи с инструментами администратора (или те, кто имеет право восстановить инструменты администратора в BN) также могут открыть RfA. Такой RfA будет иметь скорректированные пороговые значения для консенсуса <insert>. В случае сбоя этого RfA права администратора будут аннулированы. ProcrastinatingReader ( разговор ) 14:06, 20 апреля 2021 (UTC)
  • Лично я предпочел бы иметь отдельное название, чем длинное объяснение того, чем отличается RfA для нынешних администраторов. Пользователь: 力(power ~ enwiki, π , ν ) 16:46, 22 апреля 2021 г. (UTC)
• Это довольно похоже на @ Thryduulf : «s предложение здесь , и поэтому я был бы склонен к поддержке. Я действительно думаю, что следует отметить, что кандидаты не могут инициировать один из них, пока есть неурегулированный запрос дела ARBCOM или дело, в котором их называют партией. Я твердо поддерживаю четкую демонстрацию того, что отзыв RfA разрешен, и что отказ от подтверждения согласия на то, чтобы быть администратором, подлежит принудительному исполнению путем удаления прав пользователя «крэтами». Nosebagbear ( разговор ) 20:35, 22 апреля 2021 (UTC)
• Отличная идея. Я бы поддержал более амбициозное предложение, но это разумное начало. Помимо того, что PR написал выше, повторное подтверждение RfA (даже если в подавляющем большинстве случаев было успешным) также позволило бы администратору получить существенную систематическую обратную связь о своей административной работе от сообщества в целом. Что-то вроде обзора производительности. Nsk92 ( разговор ) 22:24, 23 апреля 2021 (UTC)
• Хорошая идея, хотя я думаю, что ее следует проработать вместе с User: Nosebagbear / Draft RfC on Confirmation RfAs # Simpler предложение (т.е. объединить два предложения в одно), чтобы отсортировать недостающие детали. Тридуульф ( разговор ) 21:35, 24 апреля 2021 (UTC)

Мое эссе "не для поисковых систем" [ править ]

Пытаясь внести свой вклад в RfD, я решил написать еще одно эссе, чтобы сказать, что мы не поисковая машина. Как Сообщество думает об этом? Я считаю, что это было бы хорошим дополнением к WP: NOT . Эссе находится на WP: NOTSEARCHENGINE , NotReallySoroka ( обсуждение ) (ранее DePlume), 03:05, 21 апреля 2021 г. (UTC)

Я не думаю , что эта статья является точной - в конце концов, Википедия делает есть поисковик . Конечно, это не универсальная поисковая система, как Google или Bing, но, тем не менее, это поисковая система. Основная цель Википедии может состоять в том, чтобы быть онлайн-энциклопедией, но для достижения этой цели нам необходимо предоставить читателям эффективный способ поиска нужной информации. - Tera tix ₵ 04:38 , 21 апреля 2021 г. (UTC)

Автоматическое патрулирование для расширенных подтвержденных пользователей за пределами статьи [ править ]

Хотя статьи во всех пространствах имен отображаются не так заметно, они подлежат патрулированию. В то время как патрулирование в основном пространстве включает в себя проверку на заметность, проблемы с очисткой и т. Д., Патрулирование в другом месте в основном просто проверяет очевидные проблемы, такие как копирование и атаки страниц. Учитывая огромное количество страниц, созданных опытными пользователями за пределами основного пространства, патрулирование этих других пространств имен выполняется нечасто. Чтобы сделать эту функцию более полезной, я бы предложил автоматическое патрулирование, в идеале с помощью программного обеспечения, страниц, созданных расширенными подтвержденными пользователями за пределами основного пространства. Мысли? Элли ( Обсуждение | вклад ) 01:55, 22 апреля 2021 (UTC)

Эм ... что? Вы когда-нибудь слышали о том, чтобы пользователь, Carlossuarez46 , администратор , злоупотреблял правом автоматического патрулирования, создавая тысячи незаметных подзаголовков? Во всяком случае, после этого недавнего случая нам следует быть более осторожными при выдаче автоматических патрулей. Так что нет. 🐔  Chicdat   ^{Bawk мне!} 11:38, 22 апреля 2021 г. (UTC)

• @ Chicdat :, это скорее провал процесса RfA, чем что-либо еще. Тем не менее, это не имеет значения, поскольку это предложение направлено только на обеспечение автоматического патрулирования для всех пространств имен, не предназначенных для чтения . JackFromWisconsin ( Обсуждение | вклад ) 14:34, 22 апреля 2021 (UTC)

• Служба поддержки. Обоснование того, что страницы пространства проектов подлежат патрулированию в первую очередь, всегда было довольно слабым. Теоретическая причина, по которой нужно следить за копировальным видео и атаковать там страницы, абстрактно звучит разумно, но на практике подавляющее количество страниц пространства проектов либо вообще не патрулируется, либо патрулируется случайно, намного позже, чем они были созданы. Нам следует искать более эффективные способы выявления очень проблематичного материала в пространстве проектов (например, попытки автоматизировать определенные задачи и творческое использование ботов), а не подвергать все страницы пространства проектов патрулированию. Случай с Carlossuarez46 был чрезвычайно изолированным исключением даже для mainspace, и, AFAIK, у нас никогда не было ничего подобного в пространстве проектов ни с одним пользователем, администратором или кем-либо еще.Я бы поддержал, чтобы все страницы за пределами mainspace не подвергались патрулированию; но в остальном предложение Элли разумно.Nsk92 ( разговор ) 12:02, 22 апреля 2021 (UTC)
• Выступите против этой конкретной реализации, но теоретически поддержите идею отказа от патрулирования для опытных пользователей за пределами читаемых пространств имен. EC - это автоматическое право пользователя, и его легко использовать в игре, и я боюсь, что у нас будет LTA socks gaming EC и получить это модифицированное право автопатрулирования, создавать и автоматически патрулировать страницы, которые мы в противном случае отклонили бы в каком-то непонятном пространстве имен, а затем перемещать их в пространство статей, где они остаются незамеченными. Право на автопатрулирование должно оставаться в силе, выдаваемой только на основании человеческой оценки пригодности заявителя. С другой стороны, я бы поддержал отключение патрулирования для пространств имен NOINDEX с низким риском злоупотреблений, возможно, вместе с добавлением баннера «это не статья Википедии» в программное обеспечение для этих пространств имен. Не воспринимайте мои комментарии как предложение,это требует доработки.Иванвекторская белка ( ^{деревья} / _орехи ) 13:12, 22 апреля 2021 г. (UTC)

  Я думаю, что индексирование - хороший потенциальный критерий того, какие страницы требуют патрулирования. {{u | Sdkb }}  ^talk 05:36, 24 апреля 2021 г. (UTC)

• Поддержите идею этого, но все еще не уверены в правильности реализации. Пользователь: PEIsquirrel выражает обеспокоенность по поводу злоупотребления ДСС. Самое простое решение состоит в том, чтобы все страницы, перемещенные в основное пространство, требовали проверки (если у пользователя нет истинного права на автоматическое патрулирование). Я равнодушен к баннерам с надписью «это не статья из Википедии». JackFromWisconsin ( Обсуждение | вклад ) 14:34, 22 апреля 2021 (UTC)
• Мы не должны голосовать в соответствии с правилами лаборатории идей, и я не уверен в конкретной предлагаемой реализации, но в целом я поддерживаю попытку найти способ сделать патрулирование страниц, не относящихся к статьям, более целенаправленным. В частности, что касается копировальных видео, мне интересно, может ли это быть полуавтоматическим - может быть, только те страницы патрулирования, которые, по словам Уервиг, имеют высокую вероятность нарушения? {{u | Sdkb }}  ^talk 05:38, 24 апреля 2021 г. (UTC)
• Поддержите идею, не уверены в возможном смягчении последствий злоупотреблений. EpicPupper 21:58, 27 апреля 2021 г. (UTC)

Делаем Википедию более графической [ править ]

Можно ли добавить в статьи больше изображений или видео для лучшего восприятия и понимания предоставляемого контента? - Предыдущий неподписанный комментарий добавлен Souvick100Saha ( обсуждение • вклад ) 09:11, 24 апреля 2021 г. (UTC)

Кабайи ( разговор ) 10:10, 24 апреля 2021 (UTC)

Souvick100Saha , это лаборатория идей Village Pump, используемая для инкубации предложений по всей Википедии. Если вы видите определенные статьи, в которых нужно больше изображений, выделите их и добавьте их. Спасибо, EpicPupper 20:08, 24 апреля 2021 г. (UTC)

Графики (гистограммы / гистограммы / ......) добавлены в статьи [ править ]

На странице типа «Канада»; Я думаю о 1 диаграмме, показывающей сушу Канады относительно суши других стран (страны больше, чем Канада, и меньше, чем Канада; по обе стороны от Канады.), Другую диаграмму, показывающую длину береговой линии Канады по отношению к длинам береговых линий других стран и т. д. для всех номеров на странице "Канада".

Это всего лишь 1 пример; но, в конце концов, это была «Иллюстрированная Педия».

Я не могу решить, правда ли; ссылка на главной странице должна открывать отдельную страницу с диаграммами, или каждая отдельная диаграмма должна "всплывать" при нажатии значка рядом с соответствующим номером?

Если ссылка на главной странице для «Канада», открывается на графическую страницу; должна ли карта Канады быть фоном с диаграммами, расположенными наверху?

Может быть; это выходит за рамки / вне сферы Википедии?

Может быть; кто-то другой реализовал эту идею, а я этого не видел.

Я такая новенькая; для навигации по чудовищу, как Википедия.

А также; Мне нужно будет много "держаться за руку", если я все-таки выдержу это. - Предыдущий беззнаковый комментарий добавлен пользователем Мне нравятся данные ( обсуждение • вклад ) 02:24, 26 апреля 2021 г. (UTC)

Энциклопедические статьи предназначены для ознакомления читателей с предметами, а не для отображения всех возможных кусочков информации (см. WP: Википедия - это не беспорядочный сбор информации ). Sungodtemple с TCG вентилятор !! 1 ! 11 !! ( разговорное ) 15:23, 26 апреля 2021 (UTC)

• Обратите внимание, что у нас уже есть статья для информации / сравнения массивов суши ... см .: Список стран и зависимостей по площади . Вместо того, чтобы дублировать информацию из статьи о Канаде , я бы предложил просто дать ссылку на эту статью со списком. Я не проверял, есть ли у нас уже аналогичный список для информации о береговой линии, но меня это не удивит. Blueboar ( разговор ) 15:42, 26 апреля 2021 (UTC)

Только что проверил ... делаем. См .: Список стран по длине береговой линии . Итак, еще раз ... вместо того, чтобы дублировать, просто дайте ссылку. Blueboar ( разговор ) 15:49, 26 апреля 2021 (UTC)

Порталы? [ редактировать ]

Кто-нибудь действительно пользуется порталами? До того как перейти Рубикон и стать редактором, я никогда их не замечал, не говоря уже о том, чтобы пользоваться ими. Пример их неиспользования, портал: Автомобили в просмотрены менее чем 100 ежедневно в среднем ... Есть ли способ , чтобы сделать их более доступными и удобной , или они должны быть просто списаны? ~ HAL 333 21:34, 26 апреля 2021 г. (UTC)

• Исключены, за исключением тех, которые связаны на главной странице верхнего уровня, потому что их практически никто не использует (на основе просмотров страниц). С другой стороны, их существование не вредит. У нас несколько миллионов страниц, которые никто не читает, и порталы составляют менее одной десятой процента из них. Levivich  ^харасс / _гончая 21:59, 26 апреля 2021 (UTC)
• Я прошел путь от специалиста по обслуживанию портала до скептика портала. Идея о том, что это либо альтернативные тематические главные страницы, либо читательские аспекты WikiProjects, провалилась. Читатели просто не используют их так, как мы хотели. Читатели ими почти не пользуются. Несколько лет назад был большой RFC, который объявил порталы устаревшими, но это не удалось. С тех пор у сотрудников портала было время, чтобы придумать стоящие идеи, но порталы по-прежнему являются печальным напоминанием о том, как все веб-сайты выглядели 20 лет назад и почему они больше не такие. Если бы еще один RFC был проведен, скажем, через несколько лет, это, вероятно, прошло бы. -  Finnusertop ( обсуждение ⋅ вклад ) 22:08, 26 апреля 2021 г. (UTC)
• Порталы должны быть удалены, за исключением тех, которые находятся на самом верхнем уровне, на которые есть ссылки на главной странице. Практически никто ими не пользуется. Более крупные категории полезны, но небольшие порталы часто остаются неиспользованными после значительных усилий по их созданию. EpicPupper 21:46, 27 апреля 2021 г. (UTC)

Иметь возможность искать страницы без страниц обсуждения или страницы обсуждения без WikiProjects [ править ]

Я не знаю, возможно ли это или уже было сделано, но это кажется отличной новой функцией. Это может позволить WikiProjects более легко находить страницы, которые не были помечены тегами, которые охватываются WikiProject. Это был бы отличный инструмент для обслуживания. (Oinkers42) ( разговорное ) 15:51, 27 апреля 2021 (UTC)

Я бы тоже очень хотел знать об этом и был бы более чем счастлив помочь с добавлением WikiProjects. Я часто натыкаюсь на статьи, даже те, которые существуют в течение многих лет, которые либо не имеют страницы обсуждения, либо имеют страницу обсуждения без баннеров WikiProject. -  Finnusertop ( обсуждение ⋅ вклад ) 16:22, 27 апреля 2021 г. (UTC)

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

Обратите внимание, что для восстановления результатов вам необходимо выполнить ответвление запроса. Вахурзпу ( разговорное ) 17:08, 27 апреля 2021 (UTC)

Этот поиск ищет страницы обсуждения без баннеров WikiProject. Многие из них являются страницами обсуждения редиректов. PrimeHunter ( разговор ) 17:18, 27 апреля 2021 (UTC)

PetScan можно использовать для поиска страниц с определенным шаблоном (например, информационным блоком) или в дереве категорий, на которых нет определенного (-ых) баннера (-ов) WikiProject. Этот поиск находит статьи с {{ Infobox mountain }}, у которых нет баннеров для WikiProjects: Горы, Вулканы или Британские и Ирландские холмы. И этот поиск находит статьи в Категории: Полифенолы и ее подкатегории, у которых нет баннера для WikiProject Chemicals. Плантдрю ( разговор ) 20:12, 27 апреля 2021 (UTC)

• Учитывая, сколько из наших Wiki-проектов неактивны / умирают, действительно ли это продуктивная вещь, о которой стоит беспокоиться? Blueboar ( разговор ) 20:35, 27 апреля 2021 (UTC)
  • @ Blueboar : На мой взгляд, да. То, что «WikiProjects неактивны / умирают» обычно означает, что мало обсуждения или координации на уровне проекта, и это правда. Но многие инструменты редактора, не требующие согласования с WikiProject, используют баннеры проекта. Я могу найти статьи, связанные с масонством категории B, если меня интересует эта тема и я хочу представить достаточно полную статью в номинациях на Хорошие статьи. Я могу найти Категория: Важнейшие статьи, связанные с масонством, чтобы обратить внимание на самые важные статьи . Я могу найти список уборок, связанных с Германией, если я хочу потратить некоторое время на устранение проблем, связанных с этой темой. Я могу смотреть егоВикипедия: WikiProject Germany / Статья предупреждает, если я хочу поделиться своим опытом с АдГ по обсуждению и т. Д. Предмета, о котором я что-то знаю. Наконец, я считаю важным, чтобы все статьи оценивались по крайней мере для какого-то проекта, чтобы мы могли получить полную картину состояния статей в Википедии. -  Finnusertop ( обсуждение ⋅ вклад ) 21:37, 27 апреля 2021 г. (UTC)