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

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

Предупреждения о срабатывании триггеров следует добавлять в начале статей или хотя бы где-нибудь на странице. Избегает людей, случайно наткнувшихся на запускающий контент. Возможно, в виде одного из тех шаблонов заметок, которые идут вверху страницы? - LocalPunk ( разговор ) 11:14, 25 января 2021 г. (UTC)

Для википедистов, которые могут не разделять общественные или культурные нормы друг друга, было бы практически невозможно договориться о всеобъемлющем стандарте того, что составляет «запускающий контент». При правильном соблюдении принципа наименьшего удивления читатели, как правило, должны сталкиваться с оскорбительными материалами только тогда, когда они ожидаются (например, читатели должны ожидать, что статьи по анатомии будут содержать изображения половых органов) и улучшить их понимание темы, что свело бы на нет необходимость для предупреждений. Существует также общий отказ от ответственности, который прямо предупреждает читателей о том, что в Википедии размещен нежелательный контент. (См. Также WP: без цензуры ). - Tera tix ₵ 14:01, 25 января 2021 г. (UTC)

Истинный. Возможно, вам подойдет карточка со ссылкой на отказ от ответственности? - LocalPunk ( разговор ) 15:40, 25 января 2021 г. (UTC)

Проблема по-прежнему в том, в каких статьях он должен быть, что является весьма субъективным выбором. -  HELL KNOWZ    ▎ TALK 16:24, 25 января 2021 г. (UTC) 

Вероятно, должен быть какой-то список бесплатных обновлений или что-то в этом роде. - LocalPunk ( разговор ) 19:19, 25 января 2021 г. (UTC)

@ LocalPunk , я думаю, вы захотите прочитать « Триггер травмы» . Предупреждение NSFW может иметь некоторую практическую ценность , но, вероятно, нет никакой пользы от предупреждения о триггере. WhatamIdoing ( разговор ) 02:35, 26 января 2021 (UTC)

Я категорически не согласен с первым абзацем «В высшем образовании». LocalPunk ( разговор ) 11:35, 26 января 2021 (UTC)

Было бы полезно различать триггер травмы и то, что доставляет некоторым людям дискомфорт . Например, если вы видели, как человека зарезали насмерть, то в результате у вас может (а может и не развиться) развиться длительный посттравматический стресс. Однако статистически маловероятно, что ваш триггер травмы будет «видеть людей с нанесенными ножом» или «читать об убитых людях». Скорее всего, это будет что-то вроде металлического запаха крови, странного движения головы убийцы или еды, которую вы съели только что. Читать о преступлениях или смотреть фильмы с насилием может быть неудобно (или нет; некоторые травмированные люди ищут фильмы ужасов [1] ), но вряд ли это будет реальным, добросовестным спусковым крючком для травмы.

В прошлом были разговоры об определенных типах фильтров содержимого. Никто не должен смотреть на фотографию, на которой кому-то выколачивают глаз или трупы, только потому, что Special: Random иногда переносит вас на страницы, связанные с смешанными боевыми искусствами или военными преступлениями . Но фактические триггеры травмы , а не вещи, которые заставляют людей чувствовать себя некомфортно, вероятно, немногочисленны в вики, а предупреждения об истинных триггерах травмы, вероятно, невозможны (как кто-то должен знать, что является вашим личным триггером?), Ни обязательно полезными . WhatamIdoing ( разговор ) 03:35, 30 января 2021 (UTC)

• Кто-то должен был предупредить меня, что на этой странице будет обсуждение предупреждения о триггере, прежде чем я его посетил, потому что каждый раз, когда я вижу, что кто-то предлагает предупреждения о триггере, я просто хочу плакать. E Eng 21:34, 29 января 2021 г. (UTC)

• Я думаю, тебе не хватает, EEng. 4D4850 ( разговорное ) 19:43, 15 февраля 2021 (UTC)

Что, если это похоже на один из баннеров, которые Викимедиа размещает на статьях, которые необходимо рецензировать. Просто бледно-желтое предупреждение «Common Trigger Warning» и редакторы и решают, насколько конкретным оно должно быть. - Предыдущий неподписанный комментарий, добавленный Totalart44 ( обсуждение • вклад ), 06:05, 23 февраля 2021 г. (UTC)

Я согласен с тем, что должны быть триггерные предупреждения о вещах, которые, по общему мнению, вызывают, таких как холокост или KKK . Starman2377 ( разговор ) 16:25, 25 февраля 2021 (UTC)

В верхней части страницы должно быть больше "кратких" маркированных списков [ править ]

Мне нравится, когда в верхней части некоторых статей есть резюме, они действительно полезны, особенно когда я просто хочу получить самую важную информацию. Может быть круто - Предыдущий неподписанный комментарий добавлен TheFirstVicar4 ( обсуждение • вклад ) 01:40, 27 января 2021 г. (UTC)

TheFirstVicar4 - извините, вы предлагаете принять это для статей в основном пространстве? Или просто его следует использовать более широко в эссе, руководствах и т. Д.? - Пол ❬ обсуждение ❭ 12:48, 27 января 2021 г. (UTC)

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

Выполняет ли WP: Infobox эту функцию? - A D Monroe III ^{( разговор )} 17:09, 27 января 2021 г. (UTC)

• Звучит как хорошая идея. В Британской энциклопедии раньше были разделы «Микропедии» и «Макропедии», первая из которых в основном состояла из резюме статей последней. Если вы посмотрите одну из многих статей об известных людях в Macropedia, а затем прочтете запись этого человека в Micropedia, вы увидите, что статья Micropedia будет гласить «Отрывок из текстовой биографии». Википедия не нуждается в отдельных версиях Micro-Wikipedia и Macro-Wikipedia, но если бы аннотации статей появлялись в верхней части статей, это могло бы служить этой функции. Ролло Август ( обсуждение ) 14:28, 16 февраля 2021 (UTC)
• Против. У нас уже есть краткие описания для этого. 🐔  Chicdat   ^{Bawk мне!} 12:26, ​​25 февраля 2021 г. (UTC)

Каникулы [ править ]

Некоторые компании проводят обязательные отпуска для сотрудников, чтобы убедиться, что никто не нужен . Интересно, можно ли применить здесь ту же концепцию. Или, может быть, это общие сведения, каковы будут результаты. Enterprisey  ( разговор! ) 09:56, 30 января 2021 (UTC)

все, что мы здесь делаем, записывается, потому что записывать все равно что, единственное, что мы можем сделать - поэтому я не уверен, как может применяться коэффициент шины. - Paul ❬ talk ❭ 21:38, 30 января 2021 г. (UTC)

Существуют различные области вики, которые перестанут функционировать должным образом или значительно снизятся в качестве, если останется один редактор. Конечно, вики в любом случае будет работать. ProcrastinatingReader ( разговор ) 21:50, 30 января 2021 г. (UTC)

Записанные действия не раскрывают всей истории, в частности, почему что-то было сделано. Enterprisey  ( разговор! ) 23:55, 30 января 2021 (UTC)

Однако стоит отметить, что я не уверен, что этот тест помогает. Единственное решение в этих областях - набрать больше людей, которые займут это место, что является функцией как наших общих усилий по набору редакторов (из числа не редакторов), так и нашей способности предоставить существующим редакторам разрешения, необходимые для повышения их ролей. Например, в прошлом году был момент, когда Primefac взяла небольшой перерыв, и BRFA остановилась (и TFDH). Для этого нет решения, кроме как большего количества BAG (которые, в настоящее время, я думаю, я и Earwig довольно активны), и более компетентных редакторов шаблонов с общими полномочиями TfD. Патрулирование запросов на разблокировку обычно выполняется Ямлой и другим, чье имя пользователя ускользает от меня. Запросы на редактирование фильтров в значительной степени зависят от SoY, поскольку большинство менеджеров фильтров редактирования не взаимодействуют с этим местом, и даже SoY может делать только некоторые,так что это место наполовину бесполезно. L235 отвечал за большую часть клерков ArbCom, я думаю, и до сих пор в некоторой степени даже после выборов (обновление шаблонов и тому подобное). Бесконечный список подобных примеров, некоторые из них (и другие) более эффективны, чем другие. Для них нет реального решения, кроме обучения новых редакторов, но это проблема сама по себе из-за общего скептицизма. Большинство областей задокументированы, так что кто-то может со временем уловить их, но некоторые более неясные области полагаются на неписаные соглашения (например, работа с TFDH, а некоторые с TFD в целом).но это проблема сама по себе из-за общего скептицизма. Большинство областей задокументированы, так что кто-то может со временем уловить их, но некоторые более неясные области полагаются на неписаные соглашения (например, работа с TFDH, а некоторые с TFD в целом).но это проблема сама по себе из-за общего скептицизма. Большинство областей задокументированы, так что кто-то может со временем уловить их, но некоторые более неясные области полагаются на неписаные соглашения (например, работа с TFDH, а некоторые с TFD в целом).ProcrastinatingReader ( разговор ) 00:51, 31 января 2021 (UTC)

Энтерпрайз , это интересная мысль! Я не думаю, что люди пойдут на это, но я действительно думаю, что есть вещи, которые мы могли бы сделать лучше, чтобы Википедия не стала чрезмерно полагаться на какого-то одного редактора.

Это применимо в нескольких сферах. Что касается поддержки статей / шаблонов / других страниц, я написал эссе Википедия: Создавайте контент, чтобы выдержать (WP: ENDURE) своими мыслями.

А еще есть боты, которые, как мне кажется, являются нашим самым слабым звеном в этой области. Есть много случаев, когда оператор бота выходит на пенсию, а его бот впоследствии перестает работать, что часто приводит к значительному ущербу, прежде чем кто-либо это заметит. Я уже поднимал этот вопрос раньше и предлагал несколько идей, но либо они не работают, либо никто не позаботился полностью их реализовать. {{u | Sdkb }}  ^talk 17:19, 1 февраля 2021 г. (UTC)

Тогда почему бы не иметь резервного оператора, который станет оператором после его выхода на пенсию? Тогда все боты будут в хорошем качестве. 🐔  Chicdat   ^{Bawk мне!} 12:29, 25 февраля 2021 г. (UTC)

• И все же мы как-то неуклюже продвигаемся вперед. Когда-то решение будет заключаться в том, что, как только данный редактор проявляет себя как высокопроизводительный и знающий, мы его блокируем. Тогда мы не становимся зависимыми и избегаем будущих сюрпризов. (Не уверен , что сам себе это слово , но мне кажется , он должен идти с «сингулярными они».) E Eng 15:32, 2 февраля 2021 (UTC)

  Или мы должны просто упреждающе блокировать всех, кто пытается редактировать. Если бы мы также удалили все наши статьи, у нас была бы хорошая аккуратная энциклопедия. Фил Бриджер ( разговор ) 17:18, 26 февраля 2021 (UTC)

• Перерывы в работе некоторых «больших ботов» (через их операторов) будут наиболее эффективными; у нас есть много рабочих процессов, которые зависят от этой клиентской работы, которая является одной глубиной (например, посмотрите этот журнал: Special: Log / pagetriage-copyvio ). - ^{Обсуждение} xaosflux 15:38, 2 февраля 2021 г. (UTC)

Проблема в том, что если у редактора есть обычная область редактирования, он может потерять доверие, если внезапно прекратит редактирование на длительный период времени. - Sm8900 ( разговор ) 19:22, 15 февраля 2021 (UTC)

• Мне нравится эта идея. Все хорошие организации делают что-то подобное, хотя это чаще нацелено на системы, чем на людей. См., Например, Хаос-инжиниринг . - РойСмит (разговор) 16:03, 26 февраля 2021 г. (UTC)
• Я думал, что более частой причиной обязательных отпусков была защита от мошенничества. Более вероятно, что сотрудник делает что-то неподходящее, если он не может получить доступ к системам работодателя в течение пары недель, а кто-то другой выполняет их (я пытался избежать использования единственного числа «они», но здесь больше нельзя использовать) functions. В любом случае, это хорошая идея, которая будет совершенно непрактичной в среде, где большинство рабочих анонимны. Фил Бриджер ( разговорное ) 17:14, 26 февраля 2021 (UTC)

Должна ли очередь запросов на редактирование COI функционировать больше как RfC? [ редактировать ]

Редактирование конфликта интересов (ИСП) долгое время было проблемой для Википедии. Хотя большая часть разногласий была связана с нераскрытым платным редактированием (UPE), при поддержке Джимми Уэйлса был выработан рабочий консенсус в отношении поощрения процесса «запроса на редактирование» в соответствии с руководящими принципами о конфликте интересов . Короче говоря, ответственные платные редакторы должны предлагать изменения, а волонтеры - внедрять их, если они сделают энциклопедию лучше. Более подробно это описано в WP: PSCOI, и с течением времени он работал достаточно хорошо, хотя, как и многие очереди запросов в Википедии, он часто имеет длительное отставание.

На момент написания этой статьи существует более 180 открытых запросов, самый старый из которых датируется октябрем. Если не рекорд за все время, то он, безусловно, близок , особенно после периода с 2018 по 2020 год, когда усилия в основном одного редактора поддерживали управляемость очереди. За прошедшие годы в Village pump были внесены различные предложения по улучшению этого процесса, включая добавление новых параметров в шаблон запроса на редактирование и продвижение недавно созданного мастера запросов на редактирование . Я подумал о другом способе потенциально улучшить эту систему, который я изложил ниже. Моя цель - обрисовать проблемы так, как я вижу их здесь, получить отзывы и, надеюсь, даже некоторую поддержку, прежде чем принимать более конкретное предложение.Деревенский насос (предложения) . Вот мой анализ и первоначальное предложение:

Обзор текущего процесса

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

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

Проблемы с текущим процессом

Однако у процесса есть свои недостатки:

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

Эти недостатки могут негативно повлиять на Википедию в целом:

• Читателям не выгодно, что проект цепляется за неверную информацию только потому, что у человека, указавшего на ошибку, есть COI.
• Плохо оформленные запросы тратят время волонтеров; если очередь была расположена на странице со ссылкой на WP: PSCOI или Мастер запросов на редактирование, было бы проще отсортировать эти запросы для проверки
• Некоторые запросы отклоняются без рассмотрения по существу, поскольку очередь иногда привлекает редакторов, которые, похоже, не любят редактировать ИСП. Я понимаю и понимаю, почему редакторы Википедии скептически относятся к редактированию ИСП. Они должны быть! Но в то же время этот процесс существует не просто так, и запросы должны решаться по существу. Большая прозрачность сделает эти увольнения менее распространенными
• Обременительный процесс отправки и очень долгое время ожидания стимулируют скрытое платное редактирование

Предлагаемые решения для улучшения процесса

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

Какие бы недостатки ни можно было выявить в процессе RfC, легче рассматривать вопросы одним взглядом, с большей вероятностью привлечет большее участие и тем самым снизит нагрузку на любого добровольца. RFC также включают установленные временные ограничения на обсуждение и включают приглашения, рассылаемые ботами для рекламы обсуждений для не вовлеченных редакторов. Более того, заявления RfC должны быть краткими и нейтральными, а пересмотренный процесс запроса на редактирование может побудить редакторов COI принять аналогичный подход.

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

Моя цель - дать возможность разумным запросам получить адекватное рассмотрение и реализацию нейтральными редакторами, не влиять на то, какие типы запросов принимаются или отклоняются, а также не диктовать, кому разрешать участвовать в обсуждениях. Я понимаю, что рассмотрение запросов на редактирование сказывается на сообществе Википедии, то есть на анализе WP: BOGO . Но именно поэтому я думаю, что, сделав процесс запроса COI более удобным для пользователя и уменьшив трение, присущее текущему дизайну, можно было бы снизить нагрузку на отдельных добровольцев.

Приглашения для обратной связи

В дополнение к редакторам, просматривающим эту страницу лабораторной работы, я хотел бы пригласить к этому обсуждению редакторов, которые могут быть хотя бы немного знакомы с текущим процессом, поскольку они ответили на отправленные запросы. Еще 4 января я просмотрел 100 последних отвеченных запросов на редактирование COI, начиная с 7 декабря. Ниже я составил список редакторов, которые ответили на эти запросы, и я отправляю им пинг в надежде получить отзывы о изменения, которые я предложил.

Этот тест был проведен вовремя, потому что Пользователь: Spintendo вообще прекратил редактирование 26 октября. До недавнего времени он внимательно следил за очередью и часто отвечал на запросы. Я, конечно, тоже приветствовал бы его мысли, но, завершив эту оценку, мы сможем увидеть, как выглядит процесс без него (гораздо медленнее!).

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

В заключение, я надеюсь получить здесь конструктивную обратную связь, прежде чем выдвигать более подробное предложение на другой странице деревенского насоса. Я с нетерпением жду всех ответов и приму их к сведению, когда буду обдумывать следующие шаги. Заранее спасибо, WWB ( обсуждение ) 22:55, 8 февраля 2021 г. (UTC)

Быстрая мысль: основная проблема, с которой мы сейчас сталкиваемся, - это отсутствие Spintendo. Весь процесс работал в основном потому, что одному редактору удавалось справиться с большим количеством трудоемких запросов, и он сломался в тот момент, когда они перестали тратить время волонтеров на помощь платным редакторам. За кулисами Википедии есть несколько областей, где слишком много полагается на одного человека; приходиться годами ждать обновления бота на WT: RFPP - еще одна проблема . Я не могу предложить правильного решения, могу только пожаловаться. ~ ToBeFree ( разговор ) 22:59, 8 февраля 2021 (UTC)

(ec) Я не был так активен в ответах на запросы редактирования COI, и я не обязательно поддерживаю переполнение того, что будет функционировать как RfC (и я не уверен, как этот процесс будет отличаться от текущего процесса - RfC классифицируются так же, как Запрошенные правки, и такие кошачьи страницы просматриваются редакторами), но я думаю, что решение для решения проблемы количества запросов на редактирование COI, безусловно, необходимо. Очередь запросов на редактирование COI нуждается в редакторах для обращения к ER, не обязательно в более крупном процессе. Поэтому я думаю, что организация редакторов или собрание редакторов были бы более полезными. Я был бы в пользу WikiProject или, возможно, диска с запросами на редактирование, но не за эту идею - я не уверен, что это что-то исправит. P, TO 19104 ( обсуждение ) ( вклад) 23:05, 8 февраля 2021 г. (UTC)

Я не являюсь обычным редактором COI-запросов (я отвечаю на запросы на редактирование статей, которые смотрю), поэтому я не знал о Категории: Запрошенные правки . На первый взгляд, это довольно ... неприятно. Мне больше нравится формат RFC , но я не уверен, насколько просто было бы отображать запросы COI в этом формате. У них нет краткого резюме или описания, которое можно было бы включить, как это делают RFC. А если включить весь запрос на редактирование, получится полный беспорядок. Я согласен с тем, что процесс можно улучшить, но я не знаю, что могло бы улучшить его. Вероятно, это не очень помогает, извините! Schazjmd  (разговорное) 23:12, 8 февраля 2021 (UTC)

Я не смотрю список Категория: Требуемые правки . Не люблю платный монтаж. Я подозреваю, что одна из причин отставания в том, что я не единственный, кто так считает. Запросы часто очень плохо структурированы и часто совершенно необоснованны. Может быть, если бы запрашивающие научились делать это правильно, перестали просить о включении чего-либо, что не поддается независимой проверке, и отказались бы от попыток использовать Википедию в качестве платформы для продвижения. Последняя запись в Talk: Wellendorff - довольно хороший пример того, как этого не делать. Решение? Ускорьте отклонение таких запросов и заблокируйте автора запроса за трату времени волонтера. Vexations ( разговор ) 23:15, 8 февраля 2021 (UTC)

• Я тоже не много запросов выполнил. Большинство запросов, которые я видел, обычно не имеют прямого действия и требуют значительного количества времени для правильного выполнения. Я ожидаю, что хороший запрос будет оформлен в виде абзацев, которые можно будет скопировать в статью после просмотра. - MarioGom ( разговор ) 23:37, 8 февраля 2021 г. (UTC)

Я смотрю Категория: Запрошенные правки, и мне нравится помогать вносить эти правки, но, честно говоря, я всегда выбираю из недавних запросов, ищу интересные или простые. Мне нравится обучать запрашивающих, и мне нравится встречаться с редакторами через это. Я понятия не имел, Википедия: Edit_Request_Wizardсуществовал, поэтому я полагаю, что большинство других людей не существует. На мой взгляд, самая большая проблема этого процесса в том, что его нет. Некоторые редакторы перечисляют своих редакторов по модели «изменить X на Y», что невероятно полезно. Большинство этого не делает, и половина моего времени уходит на расшифровку того, что именно они хотят делать. Исправление этого много помогло бы в этом процессе. Когда правки так отформатированы, я могу легко их просмотреть. Я бы даже был готов платить X в месяц. Я еще не проверял мастер, но если он отформатирован как:

• Где сдача?
• Что вы хотите изменить?
• Что за источник?

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

Только мои 0,02 доллара. Надеюсь, это поможет. - FeldBum ( разговор ) 23:58, 8 февраля 2021 г. (UTC)

@ WWB , смотрели ли вы в Википедии: систему предупреждений о статьях , например, Википедию: предупреждения о лекарствах / статьях WikiProject ? Я не против обработки случайных запросов на редактирование (они тоже не просто платные редакторы), но я действительно не хочу видеть запросы, связанные с темами, о которых я ничего не знаю. Я быстро просмотрел текущий список из 183 правок и нашел только одноэто относится к области, с которой я знаком, и пролистал, чтобы обнаружить, что один из наиболее информированных редакторов уже был там. (Затем я нашел еще два похожих запроса и отправил ей пинг на них.) Если бы было легко найти только (пять?), Которые могли бы иметь отношение к редакторам WPMED, то я подозреваю, что эти запросы могли бы обрабатываться быстрее. Я думаю, что редакторы Wikipedia: Статьи для создания и Wikipedia: WikiProject Disambiguation обнаружили, что WPMED очень быстро реагирует на небольшие запросы, и я полагаю, что другие крупные WikiProjects будут реагировать аналогичным образом. WhatamIdoing ( разговор ) 00:46, 9 февраля 2021 (UTC)

Кроме того, переключая шляпы: @ PPelberg (WMF) , эта проблема, вероятно, связана с проектом mw: Talk pages / Уведомления и целью получения своевременных ответов на комментарии, оставленные на страницах обсуждения. Whatamidoing (WMF) ( обсуждение ) 00:48, 9 февраля 2021 (UTC)

Самая большая проблема с очередью - это количество больших запросов, которые остаются там месяцами. Эти запросы включают изменение огромного количества информации, добавление абзацев или полное переписывание статьи. Я пытаюсь выполнить запросы в начале очереди, но это отнимает очень много времени. Мой процесс следующий: я обычно переписываю текст, удаляя рекламные формулировки, не относящиеся к теме факты и незначительную информацию. Затем я проверяю текст, потому что я не указываю свое имя в плохой редакции. Если я не могу получить доступ к источникам, я прошу запрашивающих по электронной почте pdf-файлы. Если информация не проверена или источник не является надежным, я обсуждаю проблему на странице обсуждения. Иногда это приводит к постоянному разговору в течение нескольких дней. Это изнурительный и трудоемкий процесс. Я просил взятьболее месяца на выполнение . Я не могу быстро отклонить эти большие запросы, потому что большая часть информации хороша, добавление текста - чистая выгода для проекта, и я хочу поощрить COI использовать этот процесс. Иногда мне кажется, что очередь становится меньше (я был взволнован, когда отставание стало меньше 100), но через пару дней она быстро увеличивается. Если это будет продолжаться как есть, я сгорю и буду уделять больше времени статьям, которые мне действительно нравятся, вместо того, чтобы помогать компаниям продвигать себя в Википедии. Вот несколько предложений:

1. Более четкие инструкции для рецензентов: Шаблон: Запрос на редактирование / Инструкции # Для рецензентов требуется переписывание. Когда я начал рецензирование, мне пришлось несколько раз прочитать инструкции, прежде чем я был уверен, что приступлю к рецензированию. Однажды я провел одного из редакторов Discord в Википедии по последним шагам, потому что они были сбиты с толку этими инструкциями. Он должен быть простым для понимания, приветствовать новых рецензентов и чувствовать, что это займет немного времени.
2. WikiProject для поддержки этого процесса, подобный AfC или NPP: мне нравится эта идея, предложенная выше PTO. Нам нужно место, где новые рецензенты могут задавать вопросы и получать отзывы.
3. Процесс, при котором инициатор запроса должен исправить проблемы, а не возлагать бремя на рецензентов. Это может работать аналогично AfC, где статья отклоняется и указываются причины, но номинант должен уйти и исправить проблемы.
4. Спин-аут запросы на удаление тегов: некоторые запросы предназначены для удаления тегов в верхней части статьи. Если мы вынесем это из очереди, это может привести к появлению редакторов, которые сосредоточатся на этом конкретном разделе и уменьшат отставание.
5. Ограничение того, сколько вы можете изменить или добавить в статью: каждое предложение должно быть ограничено четырьмя новыми абзацами нового текста или текстом для одного раздела. Например, редактор может запросить добавление четырех абзацев в раздел «История» компании или обновление в раздел «Операции», но не оба сразу. Я выбрал четыре, потому что статьи Википедии редко содержат разделы, превышающие четыре абзаца.
6. Мастер запроса на редактирование должен включать страницу со списком типичных ошибок. Они включают в себя: добавление без заметных наград статей, вне темы информация, анонсы будущих событий, пресс-релизы, используемые в качестве источников, чтобы показать что-то примечателен, пресс-релизы проверить спорный факт, пытаясь удалить негативную информацию, различные промо и павлин слова. Это должно быть показано до того, как редактор сможет отправить свой запрос.

Обидно, что эту очередь так долго поддерживал один редактор. Нам нужен этот процесс, чтобы не позволить компаниям продвигать нашу платформу. Прошу прощения за свой длинный комментарий, и я приветствую мысли, идеи, вопросы и предложения. Z1720 ( разговорное ) 01:46, 9 февраля 2021 (UTC)

EPW не запускается по этим запросам на редактирование. Это может быть хорошим началом. Последующее разумное использование стандартных ответов, вероятно, поможет сократить очередь. (Может быть, еще одна фраза: «Перепишите это, чтобы не пахло рекламой».) - Изно ( выступление ) 04:05, 9 февраля 2021 г. (UTC)

Я считаю, что концепция запроса COI чрезвычайно важна для этого проекта. Этот сильный комментарий может быть несколько удивительным, учитывая, как мало я внес. Я использую это обсуждение как предлог, чтобы изучить этот конфликт - почему я подписываю, вы слишком слабо думаете, что это очень важно, но я почти не участвую. На ум приходят четыре основные мысли:

1. Принятие запроса может быть тяжелой работой, если все сделано правильно. ( @ Z1720 : угадайте некоторые причины.)
2. Недостаточно вознаграждений за выполнение запроса.
3. Недостаточно ресурсов для сотрудничества с редакторами, имеющими опыт в этой области (с небольшой вероятностью, что эти ресурсы существуют, а я просто не знаю, где они).
4. Наш совет редакции, готовящей запрос, неадекватен

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

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

Я также согласен с замечаниями о том, что существующий список не предоставляет много информации о типе запрошенного редактирования или намного больше, чем намек на предмет, и улучшения в этой области могут помочь '', - сказал С. Филбрик. (Обсуждение) 21:26, 9 февраля 2021 (UTC)

WWB , спасибо за время, которое вы вложили в это дело. Задержки - серьезная проблема, потому что редакторы COI (по понятным причинам) будут разочарованы временем, которое им придется ждать, и было бы очень заманчиво редактировать страницы напрямую. Пара моментов:

• Идея WikiProject, предложенная P, TO 19104, кажется мне хорошей, и, честно говоря, я ругаю себя за то, что не подумал об этом раньше.
• Мастер запросов на редактирование нуждается в более активном продвижении на страницах справки COI и т. Д. Как и многие другие редакторы здесь, я не слышал о нем до того, как он появился.
• Хотя сравнение RfC интересно, я не сторонник включения всей информации на выделенную страницу. Это работает только для RfC, потому что должен быть задан короткий вопрос. Запросы на редактирование часто бывают очень длинными. Однако централизованная доска объявлений, безусловно, интересна и ее следует рассматривать наряду с идеей WikiProject; разделение запросов на редактирование по разным категориям упростило бы ответы на них.
• Я против , чтобы беспокойства идеи «s блокировки редакторов ИСПА , которые пишут плохие запросы редактирования. Это кажется чрезмерным и бесполезным.
• Рекомендации FeldBum по созданию модели «от X к Y» великолепны, и это следует сделать более понятными для редакторов COI.
• Идея предупреждений о статьях в WhatamIdoing кажется хорошей, хотя, признаюсь, я не очень хорошо знаком с предупреждениями по статьям в целом.
• Рекомендации Z1720 для более четких инструкций очень необходимы, и я полностью согласен с предложениями №1, №2 и №6.
• Я согласен практически со всеми предложениями Sphilbrick . Таблица лидеров и поощрения кажутся естественным продолжением WikiProject, и я думаю, что сотрудничество между ответчиками на запросы определенно хорошо.

В общем, оптимизация и повышение согласованности процесса - определенно хорошая вещь, поскольку отвечать на запросы COI - не модное занятие (меня перетащили в COIN только сегодня из-за связанного инцидента). Безусловно, улучшение процесса приветствуется, и враждебное отношение к редакторам COI, добросовестно использующим запросы на редактирование, нецелесообразно. Sdrqaz ( разговорное ) 23:50, 9 февраля 2021 (UTC)

Меня интересует предложение №5 от @ Z1720 . Следует ли разбивать большие запросы на более мелкие части? У вас может быть 10 запросов на странице обсуждения, но, возможно, некоторые из них могут быть легко приняты или отклонены, и общая рабочая нагрузка станет более управляемой. WhatamIdoing ( обсуждение ) 04:36, 10 февраля 2021 (UTC)

Еще одно изменение может заключаться в ограничении одного открытого запроса на статью. Это можно комбинировать с ограничением длины запросов и, надеюсь, обеспечить более высокую скорость выполнения. Z1720 ( обсуждение ) 14:54, 10 февраля 2021 (UTC)

Ответ OP: сводный список идей [ править ]

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

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

Более четкое руководство для редакторов ИСП

• Перечислите типичные ошибки и исправления - некоторые аспекты WP: PSCOI делают это, но недостаточно четко
• Направляйте редакторов COI к мастеру запросов на редактирование ( ERW ) - со страниц рекомендаций и советов и, возможно, из других источников.

Предложите улучшения для ВПВ

• Интеграция с шаблоном: запрос на редактирование - очевидная недоработка, которую должно быть достаточно легко исправить, хорошая уловка от Izno
• Создайте ERW вокруг общих сценариев запросов - основываясь на замечании, сделанном FeldBum , текущий шаблон запрашивает предложение, обоснование и ссылки, что хорошо, но может быть расширено, например, адаптировано для ситуаций, когда участник COI хочет предложить дополнения, удаления или модификации
• Обновите, чтобы поля использовались чаще, чем страницы обсуждения - в настоящее время ERW отправляет пользователей на несколько страниц обсуждения; если бы поля можно было использовать как мастер загрузки Commons, было бы проще использовать

Улучшенный процесс для рецензентов

• Более четкие инструкции для процесса проверки - как отмечает Z1720
• Таблица лидеров для распознавания активных редакторов - предложено Sphilbrick

Улучшение шаблона запроса на редактирование несколькими способами

• Добавьте сводный параметр TLDR для возможного включения - как отметили Schazjmd и Sdrqaz , запросы на редактирование слишком длинные для включения; это может быть одно решение
• Сделайте больше похожим на AfC с обратной связью и периодом лечения - предложено более чем одним респондентом, и мне интересно, могут ли некоторые шаблонные ответы быть полезными для экономии времени рецензентов

Организовать проект в рамках WikiProject - сначала предложено P, TO 19104 и поддержано другими

• Сводное руководство для обеих сторон - улучшенные инструкции для редакторов и рецензентов COI доступны здесь
• Централизованная доска объявлений: список всех запросов для рецензентов, возможно, с включенным резюме TLDR.
• Выдающаяся точка доступа к ВПВ - объясните ВПВ и сделайте доступ заметным здесь для ИСП

Включить оповещения о статьях - увлекательное предложение WhatamIdoing, о котором я недостаточно знаю, которое потребовало бы связать запрос на редактирование с темами, вероятно, от WikiProject.

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

1. Если я упустил идею, которую вы считаете важной, не стесняйтесь аргументировать ее в своем ответе. :)
2. Есть ли какие-либо уточняющие моменты или дополнительная информация о конкретных идеях, упомянутых выше?
3. Есть ли в вышеизложенном конкретные идеи, которые редакторы, взвешивающие здесь, имеют опыт или чувствуют себя достаточно квалифицированными, чтобы активно работать над ними?
4. Есть какие-нибудь предложения о том, как некоторые или все это можно было бы эффективно предложить на самом Village Pump?

Заранее спасибо, WWB ( обсуждение ) 17:45, 12 февраля 2021 (UTC)

WWB , отличное резюме. Может быть, одним из шагов к «более четкому руководству» могло бы быть добавление ссылки Wikipedia: Edit Request Wizard / COI на Template: Connected Contributor и Wikipedia: Edit Request Wizard / Paid на Template: Connected Contributor (платно) ? Это дало бы волшебнику немного больше видимости. (Я не знал, что он существует.) Schazjmd  (разговор) 18:10, 12 февраля 2021 (UTC)

Связать запросы на редактирование с темами обычно несложно, потому что большинство статей помечены как минимум одним WikiProject. WhatamIdoing ( разговор ) 19:01, 12 февраля 2021 (UTC)

Это хорошие идеи. Я только что сообразил, что мне следовало пинговать Сэма-2727 , который является создателем инструмента ERW, так что теперь я это сделал! WWB ( разговор ) 20:59, 12 февраля 2021 (UTC)

@ Certes предоставил мне URL-адрес, который позволяет мне находить запросы на редактирование на страницах, помеченных WP: MED . Вот:

https://petscan.wmflabs.org/?&sortby=ns_title&ns%5B1%5D=1&edits%5Banons%5D=both&ns%5B0%5D=1&search_max_results=500&cb_labels_yes_l=1&depth=bot_labels_yes_l=1&depth=3&ipediaanguage5&depth=3&prodage5_s_l=1&depth=3&prodage5 = Запрошено% 20 редакций% 7C0% 0AWikiProject% 20Medicine% 20articles & edits% 5Bflagged% 5D = both & cb_labels_any_l = 1 & cb_labels_no_l = 1 & before =

Если вы нажмете кнопку «Сделай это!» кнопку, а затем подождите, вы должны увидеть, что на данный момент перечислены три статьи. Вы можете сделать то же самое для биографий WikiProject с помощью этой ссылки , и, как правило, вы можете поменять местами в аналогичной категории любой WikiProject в поле в середине страницы. WhatamIdoing ( разговор ) 02:59, 14 февраля 2021 (UTC)

WWB , спасибо за пинг. Я не знал, что это обсуждение продолжается. Я просто проверял производительность инструмента ERW (используя этот поиск [2] ) и нашел смешанные результаты. С одной стороны, у нас есть некоторые редакторы, успешно использующие предложенные поля. С другой стороны, у нас есть некоторые редакторы, игнорирующие предлагаемые поля и составляющие очень бесполезный запрос на редактирование. Есть и другие проблемы, хотя и не такие большие, например, неиспользование инструмента по назначению (например, для запроса перемещения страниц). Я думаю, что приведенное выше предложение сделать инструмент на javascript, похожим на WP: FUW, отличная идея. Хотя мы старались максимально ограничить технические знания, необходимые для запросов на редактирование, проблемы все же остаются. Фактически, я достаточно уверен, что это изменение должно быть сделано, и я хотел бы поработать над ним. К сожалению, поскольку у меня ограниченные знания о javascript (и особенно о его использовании на Викимедиа), мне потребуется некоторое время, чтобы сделать это, поэтому, если кто-то захочет вмешаться и помочь мне / взять на себя ответственность, это будет очень признательно.

В целом, я вижу очень большую неорганизованность в отношении запросов на редактирование. Несогласованность в том, как пользователи должны запрашивать изменения, как мы реагируем на изменения, а также плохая документация, связанная с процессом запроса редактирования. Надеюсь, WP: запросы на редактирование Wikiproject могут облегчить это. Может ли кто-нибудь создать википроект (поскольку похоже, что большинство людей поддерживает эту идею)? Sam-2727 ( разговор ) 03:22, 13 февраля 2021 (UTC)

Реагирование редакторов Запрос пользователя Учитывая , что у меня не было предыдущая настройка вверх WikiProject опыта, я сделал этот официальное предложение в Википедии: WikiProject Совет / Предложения / Редактирование запросы . Если интересно, просьба оставлять предложения / отзывы. Sdrqaz ( разговор ) 02:22, 14 февраля 2021 (UTC)

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

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

Откровенно говоря, я думаю, что жалобы на то, что проверка правок запросов требует много времени, в основном вызваны самими собой. Редакторы рассматривают запрошенные правки, как если бы они были RfC, и часто зацикливаются на таких тривиальных деталях, как вики-ссылки, даты доступа и так далее. Я могу просмотреть большинство изменений запроса менее чем за минуту. На то, чтобы запрошенное редактирование было безупречным, могут потребоваться часы, но менее минуты, чтобы увидеть, является ли оно улучшением. CorporateM ( Обсуждение ) 19:23, 14 февраля 2021 (UTC)

Согласен с CorporateM- Я прошел через множество GAN, которые менее подробны, чем запросы COI. Текущий процесс явно не работает. Например, в октябре у меня был запрос на редактирование. Когда в феврале я подошел к началу очереди, мне показалось, что кто-то может ответить на него, но они этого не сделали, вернув меня в конец очереди с 200 запросами передо мной (возможно, еще шесть месяцев ожидания в текущий темп). Я вижу, как предложения по ограничению размера запроса на редактирование могут быть заманчивыми с точки зрения проверяющего, но со стороны COI, если для получения ответа на один запрос требуется 6-10 месяцев, вы хотите внести все запрошенные вами изменения по адресу однажды. Я хотел бы получить информацию от более чем одного рецензента для запросов на редактирование, и больше внимания уделять тому, "является ли это чистым положительным результатом?" а не "соответствует ли это стандартам FA?"Энвебб ( разговор ) 15:32, 26 февраля 2021 (UTC)

Добавление «Предлагаемых правок» из приложений Викимедиа в обычную Википедию [ править ]

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

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

Для настольных пользователей User: SuggestBot / Requests - это круто. Или, для более мелких задач , попробуйте Википедию: Центр задач . ProcrastinatingReader ( разговор ) 08:50, 10 февраля 2021 (UTC)

Тайрон Мадера и ProcrastinatingReader , WMF активно работает над этим; это просто сначала развертывается на мобильных устройствах и на некоторых других языках. См. Mw: Рост / Персонализированный первый день / Структурированные задачи и некоторые другие работы группы роста. {{u | Sdkb }}  ^talk 21:25, 10 февраля 2021 г. (UTC)

Sdkb , я не вижу намерения со стороны WMF делать это в присланной вами статье. Я видел только упоминания о мобильных и неанглоязычных языках и ни разу о мейнстримной Википедии. Тайрон Мадера ( разговор ) 21:42, 10 февраля 2021 (UTC)

Тайрон Мадера , очень типично, что новые функции сначала выкладываются на небольшие вики, а сначала проходят бета-тестирование. Затем их привозят сюда, когда они более полно развиты. Люди из WMF сообщили, что это их план на страницах обсуждений, которые вы найдете, если немного покопаетесь в MediaWiki. {{u | Sdkb }}  ^talk 21:45, 10 февраля 2021 г. (UTC)

Тайрон Мадера -

Функция новичков в чешской Википедии

Я Маршалл Миллер; Я менеджер по продукту в команде WMF Growth. Как сказал Sdkb , мы думаем в том же духе, что и вы: чтобы википедисты в Интернете могли извлечь выгоду из потока простых задач, которые нужно выполнить. Полезно слышать, что у других есть эта идея, потому что это подтверждает, что мы, возможно, на правильном пути в своей работе. На данный момент мы создали « задачи для новичков »: поток статей с шаблонами обслуживания, в которых говорится, что им нужны такие вещи, как копирование, вики-ссылки или ссылки. Один из способов подумать об этом состоит в том, что он берет статьи, о которых говорит ProcrastinatingReader , и помещает их в канал, который можно фильтровать по интересующей теме (см. Изображение. Мы проводили эксперименты в небольших вики, показывающих, что наличие этого канала увеличивает вовлеченность новичков, и поэтому мы быстро распространяем его на большее количество вики, чтобы они могли получить пользу.

В дальнейшем мы добавляем новый вид задач. Вместо того, чтобы полагаться на шаблоны обслуживания, мы вводим алгоритмы, которые могут определять статьи, которые могут потребовать внимания, и вносить предложения по изменениям. Первый - для добавления вики-ссылок , которые мы сейчас создаем (см. Изображение). Мы также делаем начальное планирование для добавления изображений .

Планы по структурированной задаче "добавить ссылку"

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

В любом случае, я надеюсь, что любой, кто смотрит эту страницу, сможет присоединиться к обсуждению здесь, в английской Википедии, или на Mediawiki.org. ProcrastinatingReader , мне определенно было бы интересно услышать, что вы думаете о структурированных задачах. - MMiller (WMF) ( обсуждение ) 23:57, 10 февраля 2021 г. (UTC)

Sdkb , прошу прощения за резкость в своем ответе. Спасибо за терпение и спасибо MMiller (WMF) за добавление пояснений, ответы на все мои вопросы и такие вежливые ответы. Я не могу дождаться этой новой функции! Тайрон Мадера ( разговорное ) 02:14, 11 февраля 2021 (UTC)

@ MMiller (WMF) : извиняюсь за задержку с ответом. Я считаю, что структурированные задачи как концепция - отличная идея. Я думаю, что начинать с пустой страницы пугает. Я также думаю, что добавление исходного контента, когда никто не знает о MOS или обо всех других сложных политиках, которые у нас есть, иногда может быть трудным. Некоторые редакторы просто вернут то, что выглядит некрасиво (т. Е. Нарушает MOS) из нового редактора, вместо того, чтобы очистить его и сделать достойным. Это всего лишь один пример. Я подозреваю, что у многих людей есть знания, которые нужно добавить, но у них нет времени или интереса, чтобы углубиться в Википедию, чтобы получить ее в правильном формате, так что вообще не беспокойтесь о добавлении. В любом случае, если вы, ребята, можете как-то снизить барьер для редактирования с помощью структурированных задач, я думаю, что это может быть большим плюсом для набора редактора.

Однако на скриншотах справа не все. Такие задачи, как добавление ссылок и т. Д., Плохо выполняются без контекста более широкой картины. См. WP: LINKRELEVANT / MOS: OVERLINK и т. Д. Люди могут просто добавлять ссылки, которые, да, указывают на правильную статью, но не должны быть связаны. И некоторый стиль MOS предлагает только первую ссылку, а остальные нет. Проблема здесь в том, что «более крупные задачи» (добавление исходного контента, копирование и т. Д.), Кажется, трудно превратить в структурированные задачи. Но я признаю, что не тратил много времени на размышления о том, какими они могут быть. Если бы вы могли это понять, это было бы отличной возможностью. По сравнению со мной, вероятно, есть несколько более ориентированных на контент редакторов, которые могут иметь лучшие идеи о том, как этого можно достичь. ОткладываниеЧитатель( разговор ) 12:11, 23 февраля 2021 (UTC)

Привет, откладывающий читатель- спасибо за критическое отношение к этим идеям. Я рад, что вы считаете, что структурированные задачи в целом находятся на правильном пути - это первый шаг! Я согласен с тем, что существует множество потенциальных ловушек вокруг пользователей, имеющих достаточный контекст и понимание политик. Многие члены сообщества указали на эти проблемы по мере продвижения, и мы делаем все возможное, чтобы установить соответствующие ограждения, чтобы обеспечить безопасность и продуктивность для новичков. Например, вы упомянули, что алгоритм может предлагать ссылки, которые не следует делать. Алгоритм построен с учетом этой проблемы, поскольку он обучается на существующих вики-ссылках, чтобы иметь представление о том, какие слова и фразы обычно связаны между собой. И когда это неправильно,Полный рабочий процесс включает руководство и адаптацию для новичков, чтобы они могли оценить предложения с некоторыми рекомендациями. В примере со ссылкой только на первое вхождение слова в статье, это также встроено в алгоритм. Я знаю, что мы не решим все проблемы, но мы хотим сделать хороший первый удар, понять, как новички справляются с этой задачей, и начать учиться совершенствоваться. Сначала мы опробуем это только на нескольких вики (арабский, вьетнамский, чешский и бенгальский), так что это снизит риск. В то же время, однако, я хотел бы начать дискуссию о том, чтобы в конечном итоге внести такого рода функции в английскую Википедию.Я знаю, что мы не решим все проблемы, но мы хотим сделать хороший первый удар, понять, как новички справляются с этой задачей, и начать учиться совершенствоваться. Сначала мы опробуем это только на нескольких вики (арабский, вьетнамский, чешский и бенгальский), так что это снизит риск. В то же время, однако, я хотел бы начать дискуссию о том, чтобы в конечном итоге внести такого рода функции в английскую Википедию.Я знаю, что мы не решим все проблемы, но мы хотим сделать хороший первый удар, понять, как новички справляются с этой задачей, и начать учиться совершенствоваться. Сначала мы опробуем это только на нескольких вики (арабский, вьетнамский, чешский и бенгальский), так что это снизит риск. В то же время, однако, я хотел бы начать дискуссию о том, чтобы в конечном итоге внести такого рода функции в английскую Википедию.Я хотел бы начать дискуссию о том, чтобы в конечном итоге добавить такого рода функции в английскую Википедию.Я хотел бы начать дискуссию о том, чтобы в конечном итоге добавить такого рода функции в английскую Википедию. Я начинаю это здесь и надеюсь, что вы сможете посмотреть или присоединиться к нам! - MMiller (WMF) ( обсуждение ) 21:13, 26 февраля 2021 г. (UTC)

Повторяющиеся ссылки [ править ]

Для многих больших статей я часто быстро добавляю ссылку, только чтобы обнаружить, что после этого она уже использовалась где-то на странице, только с другой датой получения или другим незначительным изменением, поэтому она не была автоматически объединена. Я также часто сталкиваюсь со случаями, когда другие поступали так, а потом не замечали. Из WP: DUPCITES , похоже, нет хороших инструментов для объединения повторяющихся ссылок. Должны ли мы работать над созданием таких инструментов или добавить какое-то мягкое предупреждение, когда кто-то пытается добавить ссылку, обнаруженную как вероятную дубликат? {{u | Sdkb }}  ^talk 21:35, 10 февраля 2021 г. (UTC)

Sdkb , ReFill 2 этого не делает? Sdrqaz ( разговорное ) 22:37, 10 февраля 2021 (UTC)

Sdrqaz , я не очень хорошо знаком с ReFill 2. Он так делает? Насколько хорошо он определяет, какие ссылки являются дубликатами? (Должны ли они быть точно такими же, или он заметит такие вещи, как work=New York Timesvs. work=[[The New York Times]]?) {{U | Sdkb }}  ^talk 22:41, 10 февраля 2021 г. (UTC)

@ Sdkb : Я так и думал, но, видимо, нет. Я только что заставил ReFill прогнать мою песочницу со сценарием, о котором, я думаю, вы говорите, но они не были объединены. Я бы сказал, однако, что объединение ссылок с разными датами доступа может иметь непредвиденные последствия: часть информации могла присутствовать в более ранней версии. Однако этот момент относительно косметической разницы в названии работы невелик и должен быть покрыт инструментом. Sdrqaz ( обсуждение ) 23:31, 10 февраля 2021 (UTC)

Sdrqaz , я просто добавил еще несколько тестов. Простое изменение URL-адреса с https на http сбивает бота, так что это не супер умно. {{u | Sdkb }}  ^talk 23:44, 10 февраля 2021 г. (UTC)

Ах, какой позор, Sdkb . Честно говоря, я думаю, что он в основном предназначен для разрешения голых URL-адресов, и я обычно для этого тоже его использую. Sdrqaz ( разговорное ) 23:47, 10 февраля 2021 (UTC)

@ Sdkb и Sdrqaz : Да, ReFill объединяет только абсолютно идентичные ссылки. Вы пробовали User: Kaniivel / Reference Organizer ? -  Finnusertop ( обсуждение ⋅ вклад ) 05:29, 12 февраля 2021 г. (UTC)

@ Finnusertop : Я не слышал об этом раньше, спасибо. Однако, похоже, это не работает в моей тестовой среде в песочнице; это должно случиться? Sdrqaz ( разговор ) 00:27, 13 февраля 2021 (UTC)

@ Sdrqaz : попробуйте в mainspace в статье с множеством, казалось бы, повторяющихся ссылок. Я редко использую его, поэтому не знаю, должен ли он работать вне основного пространства. -  Finnusertop ( обсуждение ⋅ вклад ) 07:48, 13 февраля 2021 г. (UTC)

@ Finnusertop : Похоже, это не сработает: посмотрите это , там, где была дубликат ссылки Liptak. Sdrqaz ( разговор ) 17:22, 15 февраля 2021 (UTC)

Запросы на исправление опечаток [ править ]

Служба поддержки и волонтер чайханы, а также десятилетний редактор. Я только что разместил массовый запрос на исправление опечаток для "Insititute" в Википедии: Typo Team, но заметил, что запрос от июля прошлого года о распространенности его (с завершающим апострофом), похоже, остался без ответа. Википедия: Typo Team имеет страницу с обещаниями , но разве не должна быть страница с запросами ? Это может также поднять авторитет Typo Team - до сегодняшнего дня я никогда не слышал о команде. ТимТемплтон (разговор) (продолжение) 02:25, 12 февраля 2021 (UTC)

@ Timtempleton : «его» уже есть в Википедии: Lists_of_common_misspellings / I , ссылка на которую находится на странице проекта Typo Team. Если вы считаете, что «его» тоже должно быть в этом списке, добавьте его. RudolfRed ( разговорное ) 03:23, 12 февраля 2021 (UTC)

Связывание цитируемых статей с графиками Connected Papers [ править ]

Я подумал, что для Википедии было бы полезно добавить ссылку в разделе «Процитированные работы» на график « Связанные документы» каждой журнальной статьи. Connected Papers находит и визуализирует документы, похожие на рассматриваемую. Я думаю, что это упростит использование Википедии в качестве ресурса в академических исследованиях. Они недавно интегрировались с arXiv и, похоже, будут поддерживать проекты FOSS, такие как wikipedia, или, по крайней мере, поддерживать связь с ними. TripleShortOfACycle ( обсуждение - вклад ) - (она / ее / ее) 05:49, 12 февраля 2021 (UTC)

@ TripleShortOfACycle : вы предлагаете сделать это для каждой цитируемой статьи, верно? Это интересная идея, хотя я не уверен, насколько она соответствует общим стилям цитирования. Elliot321 ( Обсуждение | вклад ) 01:14, 18 февраля 2021 (UTC)

@ Elliot321 : Да, идея состояла бы в том, чтобы связать с графиком любую статью, в цитировании которой есть DOI. Я не совсем уверен, как это сделать. TripleShortOfACycle ( обсуждение - вклад ) - (она / ее / ее) 07:44, 18 февраля 2021 (UTC)

@ TripleShortOfACycle : это довольно интересная идея, но я думаю , что было бы весьма спорным - люди могут быть обидчивым о цитатах, к сожалению. Elliot321 ( Обсуждение | вклад ) 07:59, 18 февраля 2021 (UTC)

Идея: шаблоны выноски для обсуждения [ править ]

В основном это шаблоны, которые могут быть встроены для вызова комментария или определенных групп комментариев.

На форумах Discourse есть что-то, где администратор может опубликовать сообщение о комментарии для всех.

Предположим, Алиса открывает заявку на удаление статьи «Foo», а Боб пишет что-то вроде «Мне нравится foo». Выноска может стать легким напоминанием о том, что нужно не отвлекаться от темы и оставаться вежливым. Конечно, если это происходит несколько раз, мы можем просто использовать серию uw.

Итак, обсуждение будет выглядеть так:

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

• Спасибо, не надо. Эти шаблоны будут холодными, покровительственными и безличными - редакторы должны составлять эти сообщения своими словами. В этом эссе дается дальнейший обзор проблем с такого рода шаблонными сообщениями. - Tera tix ₵ 02:00, 13 февраля 2021 г. (UTC)
  • Цель состоит в том, чтобы мягко напоминать, что трудно сделать, если обсуждение становится жарким. Цель шаблонов выноски - не укусить или предположить недобросовестность, а напомнить всем редакторам об общем этикете вики и форумов, особенно если обсуждение, ну, ну, жаркое и сорванное. Эти выноски были бы полезны даже для напоминания большой группе новых редакторов о нашей цели.

Яснее? Аасим ( разговор ) 07:01, 13 февраля 2021 (UTC)

• • • Я понимаю, что эти шаблоны предназначены для мягкого напоминания, но они не будут восприниматься как таковые. - Tera tix ₵ 23:11, 14 февраля 2021 г. (UTC)
    • Если положить их в рамку, они будут звучать намного сильнее и агрессивнее. Было бы лучше просто написать собственный комментарий, если он действительно стоит того. В большинстве приведенных выше случаев создание выноски было неуместным, и сначала следовало дождаться большего количества не по теме / области - предшествующий неподписанный комментарий, добавленный Грэмом Бартлеттом ( обсуждение • вклад ) 00:24, 15 февраля 2021 г. (UTC)
• Замечательный Аасим. Я не думаю, что вовлечение в обсуждения большего количества шаблонов - хорошая идея. А у администраторов не больше полномочий в обсуждениях, чем у других пользователей. Elliot321 ( Обсуждение | вклад ) 01:13, 18 февраля 2021 (UTC)
  • Я не думаю, что администраторам это тоже очень понравится. Я думаю, что может образоваться отставание от «Вещей, на которые администраторы должны делать запросы». У нас уже достаточно незавершенных дел. 🐔  Chicdat   ^{Bawk мне!} 11:30, 27 февраля 2021 г. (UTC)

Общественный транспорт СНГ [ править ]

Здравствуй. В последнее время я видел довольно много объявлений для небольших поставщиков общественного транспорта в Великобритании и задавался вопросом, должны ли мы иметь SNG специально для общественного транспорта. Я основываю эту идею на том, что, если общественный транспорт не является национальной заботой, они редко получают уровень покрытия, соответствующий требованиям gng, даже если они являются важным игроком в обществе и являются тем, что люди на улице назвали бы примечательными. Я посмотрел и не увидел ни одного текущего википроекта, смотрящего на это. Дэвидстюартхарви ( разговор ) 15:26, 15 февраля 2021 (UTC)

Можете ли вы привести пример того, что вы имеете в виду? Мне сложно представить оператора пассажирских железнодорожных или автобусных перевозок, который не стал бы предметом значительного освещения в специализированной прессе и, как правило, в более широкой прессе, особенно в Великобритании, где даже самые незначительные местные службы, соединяющие пару деревень неизменно является предметом как конкурентных торгов на эксплуатацию маршрута, так и регулярных комментариев местных политиков относительно уровней обслуживания и любых предполагаемых проблем. По моему опыту, во всяком случае, нам следовало бы ужесточить правила выдачи информации об общественном транспорте Великобритании, поскольку на данный момент у нас есть множество статей, не представляющих ни для кого ни малейшего интереса, но технически значимых, так что не подлежащих удалению статей, таких как Лондон. Автобусы 453 . - Радужный 15:47, 15 февраля 2021 г. (UTC)

Текущая проблема состоит в том, что специализированная пресса считается неприемлемой. Туры Stotts были недавно удалены в AFD, в то время как в настоящее время есть Green Bus , Stansted Transit , Imperial Buses и Regal Busways номинированы в AFD. Я согласен с автобусными маршрутами, так как они бессмысленны, если у них нет какой-либо значимости, но компании, которые их поставляют, заметны? Дэвидстюартхарви ( разговор ) 18:28, 15 февраля 2021 (UTC)

У меня есть несправедливое преимущество в том, что я могу видеть удаленный контент и, таким образом, вижу, что проблема со Stotts Tours (Oldham) не в том, что на него цитировали специализированную прессу (в специализированной прессе не было вообще никаких ссылок); дело в том, что кроме трех предложений он ни к чему не приводился . (Если бы я восстановил статью Stotts Tours, но удалил все утверждения, которые не цитировались или цитировались только из неподходящего источника, она читалась бы полностьюВ 2018 году комиссар по дорожному движению на северо-западе Англии Саймон Эванс сократил лицензию Стоттса на перевозку с 40 до 31 автомобиля после того, как не смог автоматически зарегистрировать сотрудников в пенсионной программе. В ноябре 2017 года магистратский суд Брайтона признал Stotts Tours и его управляющего директора виновными в неспособности автоматически зачислить сотрудников на трудовую пенсию. Компания была оштрафована на 60 000 фунтов стерлингов и стала первой британской компанией, признанной виновной в соответствии с пенсионным законодательством 2015 года. ) Предполагая, что он был подробно освещен журналом Buses Magazineв какой-то момент - и я был бы удивлен, если бы какой-либо оператор регулярных автобусных перевозок не был, - тогда его можно будет воссоздать с приличными источниками, но участники дискуссий АдГ могут работать только с тем, что у них есть впереди их. При отсутствии такого источника ни один администратор не мог ничего сделать, кроме как удалить его.

Я думаю, что вы неправильно понимаете, что такое особые руководящие принципы примечательности; они не декларация того, что некоторые темы автоматически становятся заметными, а краткое изложение ситуации, касающейся существования источников для определенных классов тем. Обычно они указывают на наличие определенных тем (например, олимпийские спортсмены, поселки и городки, члены национальных законодательных собраний), по которым всегда разумно предположить, что существует достаточное количество источников, даже если их нельзя найти в Google; в некоторых редких случаях , когда есть много освещения малоценного (например , порнографические актеры) они работают по - другому , и указать , что даже если существуют источники тема не примечательна , если критерии конкретных не будут выполнены, чтобы предотвратить Wikipedia быть заблокированным. Хотя я бы поддержал ( и поддержал) формальное постановление о том, что железнодорожные станции по своей сути примечательны, поскольку мы всегда можем предположить, что они получили значительный охват при открытии, вероятно, было бы нецелесообразно распространять это на автобусных операторов; не потому, что они не всегда будут теоретически заметными, а потому, что без адекватного поиска их невозможно написать. (TL; сводка DR; недостаточно, чтобы что-то было заметным, должно быть достаточно источников, чтобы что-то сказать об этом.) -  Радужный 20:14, 15 февраля 2021 г. (UTC)

Я не о том, чтобы не было никаких ссылок для демонстрации Notability, но sng показывает то, что считается примечательным, и нуждается в ссылке для подтверждения. В текущем AFD номинант заявил: «Отсутствие значительного освещения этой несуществующей компании в нескольких надежных источниках (которые не являются местными или представляют ограниченный интерес) - не соответствует требованиям WP: NCORP». . Если бы у нас была система общественного транспорта, мы могли бы охватить все аспекты, от операторов автобусов до железнодорожных станций, вместо того, чтобы полагаться на ncorp или nbuild. Почему у нас есть спорт, а не то, что важно в повседневной жизни? Дэвидстюартхарви ( разговор ) 20:50, 15 февраля 2021 (UTC)

Ежемесячные статьи за все годы с 1990 г. [ править ]

(Это могло быть предложено раньше. Кроме того, если эта идея находится не в том месте, скажите, пожалуйста, куда мне ее поместить.)

В каждой годовой статье с 1900 по 1989 * раздел событий содержит ссылки на подробные ежемесячные статьи для каждого месяца, каждая из которых, в свою очередь, перечисляет несколько событий для каждого дня в нем (а также соответствующего дня недели). Между тем, для всех статей за год с 1990 по 2021 * раздел событий представляет собой лишь скудный список различных событий, без каких-либо ежемесячных статей (каждое ежемесячное заголовок является перенаправлением на соответствующий подраздел раздела событий). Однако период с 1990 года практически не был лишен исторически значимых событий. Чтобы исправить это несоответствие, я предлагаю создавать ежемесячные статьи для каждого месяца с 1990 г. по настоящее время с содержанием для каждого дня. Это значительно улучшило бы наше историческое понимание недавних и важных событий.

* По крайней мере, мне так кажется. Я не утруждал себя проверкой каждой статьи, но, похоже, это касается каждой, которую я посетил.

Дакматер ( разговор ) 18:08, 15 февраля 2021 (UTC)

Вам не нужно спрашивать разрешения на создание статей. Если вы думаете, что у вас достаточно материала, чтобы написать отдельную статью в сентябре 1997 года (или что-то еще), вы можете просто сделать это. -  Радужный 20:18, 15 февраля 2021 г. (UTC)

Такой статьи нет ни за один месяц с 1986 по 1989 год. Апрель 1985 года - последний. Портал: Текущие события / События по месяцам имеет ссылки на страницы портала примерно каждый месяц с июля 1994 года. Месяцы включают только ежедневные страницы, такие как Портал: Текущие события / 2 июля 1994 года . На Wikipedia talk: WikiProject Years / Archive 11 # Используя архивы Portal: Current events для статей за месяц, было решено не показывать их в mainspace. PrimeHunter ( разговорное ) 08:25, 16 февраля 2021 (UTC)

Спасибо за ответ! Я собираюсь отложить эту идею, потому что она уже обсуждалась до смерти, и, похоже, консенсус указывает на то, что ежегодных статей достаточно. (Мой папа говорит мне, что эти ежемесячные статьи в любом случае имеют сомнительное историческое значение.) Дакматер ( разговор ) 20:36, 19 февраля 2021 г. (UTC)

Демократия википедии [ править ]

Мне было интересно, будут ли, даже если это возможно, происходящие обсуждения, такие как изменения в Notability, уведомлять редакторов, чтобы сделать Википедию более демократичной? На данный момент кажется, что, когда изменения в политике обсуждаются и вносятся, кажется, что это та же небольшая группа редакторов, и в большинстве случаев большинство редакторов не знают, что это действительно происходит.

Я считаю, что, когда политика обсуждается, все редакторы получают уведомление об обсуждении, а в конце обсуждения все редакторы получают уведомление о голосовании. После завершения голосования всем редакторам отправляется уведомление, чтобы они знали об изменениях, если таковые имеются, в политике. Дэвидстюартхарви ( разговор ) 06:59, 16 февраля 2021 (UTC)

Любые предлагаемые серьезные изменения уже перечислены в {{ Централизованное обсуждение }}, которое, в свою очередь, появляется в верхней части более 5000 досок объявлений и страниц политик (включая эту); это не значит, что мы скрываем дискуссии, чтобы сохранить их прерогативой клики инсайдеров. В любой момент времени у нас есть много текущих запросов на комментарии ( это только открытые в настоящее время, а публикация уведомлений обо всех из них на всех 41 046 787 страницах обсуждения редакторов полностью затопила бы Википедию; не существует практического способа уведомить только об основных из них, поскольку никакие два редактора не согласятся, что считать «основными». Если вы хотите повысить вероятность получения уведомлений о предложениях в определенных областях, добавьте свое имя в соответствующие разделы в Википедии: Служба запросов обратной связи . (Как бы то ни было, определение «известности» в Википедии - значительное освещение в надежных источниках, не зависящих от предмета - не менялось с мая 2007 года и является одним из немногих моментов в Википедии, которые никогда не подвергались серьезным возражениям; изменение его на даже незначительная степень будет иметь такое огромное влияние на Википедию » существующий контент как неработающий.) -Радужный 07:45, 16 февраля 2021 г. (UTC)

Мы могли бы рекламировать обсуждения T: CENT в списках наблюдения, например RfA? В упрощенном виде столбцов (например, 3 элемента в строке), чтобы не было слишком тесно. Обычно одновременно работает не более 5 обсуждений enwiki CENT. Не говорю, что это хорошая идея, а просто мысль. Кстати, у нас ведь не 5000 досок объявлений и страниц политики? ProcrastinatingReader ( обсуждение ) 14:13, 16 февраля 2021 (UTC)

Многие из этих 5000, в которые включен T: CENT, являются архивами, а не активными досками объявлений, но, во всяком случае, у нас, вероятно, больше около 10 000 активных досок объявлений. Существуют тысячи де-факто «любой, кто интересуется этой темой, будет занесен в этот список», таких как страницы обсуждения WikiProject и страницы обсуждения статей с высокой посещаемостью, такие как Talk: Joe Biden . Если бы существовал способ ограничить круг лиц, которым это показывали, я бы добавил T: CENTбыло бы хорошо, если бы мы могли ограничить его так, чтобы он не показывался всем (может быть, 500 правок и 30-дневный порог, который мы уже используем где-то еще?). Один из уроков, извлеченных из списка наблюдения для RFA, заключается в том, что приглашать новеньких редакторов для участия в обсуждениях сложных вопросов может быть контрпродуктивным, поскольку они делают добросовестные комментарии, получают пощечины за непонимание проблем и, в свою очередь, получают деморализованы и ушли, и многие проблемы, которые возникают в T: CENT, относятся к сфере внутреннего бейсбола. -  Радужный 15:43, 16 февраля 2021 г. (UTC)

С технической точки зрения, по крайней мере, я думаю, что можно было бы ограничить его показом только для ECP. Обычно вы можете добавить класс «sysop-show» или «autoconfirmed-show» к вещам, чтобы скрыть их от всего, кроме этой группы. Вероятно, есть и для ECP. ProcrastinatingReader ( разговор ) 16:31, 16 февраля 2021 (UTC)

А, да, «extendedconfirmed-show» существует в mediawiki: Group-extendedconfirmed.css , так что это, вероятно, сработает. ProcrastinatingReader ( разговор ) 16:35, 16 февраля 2021 (UTC)

Я бы поддержал показ его только пользователям ECP. Мы, вероятно, не хотим, чтобы в эти обсуждения вовлекалось слишком много новичков, но лучше, чтобы о них узнало больше людей. Elliot321 ( Обсуждение | вклад ) 01:09, 18 февраля 2021 (UTC)

В этом определенно есть возможности для улучшения. Да, очень серьезные изменения могут привести к централизованному обсуждению, но давайте не будем делать вид, что все обсуждения получают то количество обсуждений, которого они заслуживают. Определенно есть некоторые RFC и изменения, которые создают прецеденты, которые делаются в захолустных местах с элементом "игры в систему" в процессе игры. Одна вещь, которую нам нужно улучшить, - это упрекать редакторов, которые, кажется, делают это. Джейсон Куинн ( разговор ) 12:55, 16 февраля 2021 (UTC)

Я не уверен, как вы планируете определять, какие редакторы играют в систему, а какие просто поднимают ее на наиболее подходящих (но менее просматриваемых) страницах. Нет четкого маркера того, какие обсуждения относятся к центральному узлу, а какие - на соответствующих страницах обсуждения политики / руководящих принципов. Nosebagbear ( разговор ) 00:50, 18 февраля 2021 (UTC)

В список наблюдения также добавляются очень важные RFC, обычно связанные с серьезными изменениями, затрагивающими большое количество редакторов. Критерии включения субъективны, но в целом WLN в отношении RFC более строгие, чем для T: CENT. (например, Special: PermaLink / 975679275 от нескольких месяцев назад. - xaosflux ^Talk 20:19, 18 февраля 2021 г. (UTC)

Концепция символа второго мнения [ править ]

В WP: GA есть символы поддержки ( ), символы противостояния ( ) и символы удержания ( ), которые представляют различные результаты хорошего обзора статьи. Однако один игнорируемый результат - это запрос второго мнения, которое в настоящее время представлено нейтральным голосом ( ), что, как я считаю, не имеет большого смысла и мало что передает. Я предлагаю значок, похожий на этот ; простите ужасное искусство, я сделал это на Chrome Canvass с помощью коврика для мыши. P Anini 🥪 14:17, 16 февраля 2021 (UTC)

Чтобы прояснить для людей, если я правильно понимаю, это повлияет только на очередь Wikipedia: Good_article_nominations . Вы можете увидеть, как это выглядит в настоящее время, перейдя на эту страницу и выполнив поиск по словам «Второе мнение» (сейчас оно находится наверху очереди мировой истории , но кто знает, будет ли он решен к тому времени, когда вы это прочтете) . Думаю, это хорошая идея. Айполино ( разговорное ) 20:34, 16 февраля 2021 (UTC)

Панини! Мне тоже нравится идея вопросительного знака, хотя, очевидно, он должен быть нарисован с большей точностью, чем то, что вы сделали. Elliot321 ( Обсуждение | вклад ) 01:07, 18 февраля 2021

Ну нет, это была всего лишь идея. P Anini 🥪 02:00, 18 февраля 2021 (UTC)

Отличная идея! Как найти людей, чтобы сделать из него правильный символ? FemkeMilene ( разговорное ) 20:56, 18 февраля 2021 (UTC)

• DYK использует {{ DYK? Again }}, чтобы запросить еще одну проверку (эр). Символ есть .

На Викискладе есть также множество символов, таких как File: SegundaOpinión-Artículo bueno.svg, которые были предназначены для этой цели. Это не так хорошо работает при размере других иконок - 16px:

Вот как это выглядит на 128 пикселей:

Эндрю 🐉 ( разговор ) 21:43, 18 февраля 2021 (UTC)

Я не уверен, насколько полезен такой символ на самом деле, но использование значка DYK, на которое указал Эндрю, кажется хорошим решением. Проблема, с которой я столкнулся с предложенным изображением Панини, заключается в том, что при использовании того же размера пикселей, что и символы поддержки и противостояния, 2 и? было бы, наверное, слишком трудно увидеть. Aza24 ( разговорное ) 02:46, 22 февраля 2021 (UTC)

Ну как насчет этого? 🐔  Chicdat   ^{Bawk мне!} 11:20, 27 февраля 2021 г. (UTC)

Мобильное приложение Wikivoyage [ править ]

Wikivoyage - один из лучших проектов Викимедиа. В последние дни я так сконцентрирован на разработке новой открытой турецкой страницы Wikivoyage. И я думаю, что официальное мобильное приложение для Wikivoyage - хорошая идея. Он может быть идеальным для путешественников по всему миру. Люди в основном используют свои смартфоны во время путешествий. Этот проект не будет иметь особого смысла, если не будет приложения WV. UcuncuUlus ( обсуждение ) 13:27, 20 февраля 2021 (UTC)

Это отдельный проект от Википедии, поэтому его следует обсудить там. Согласно порталу сообщества Wikivoyage [3] , запросы функций попадают в phabricator [4] . Также есть "Traveler's Pub", который выглядит как справочная служба Википедии, так что, может быть, сначала попробуйте там [5] RudolfRed ( talk ) 21:11, 20 февраля 2021 (UTC)

Относительно ложных блоков в Sockblock [ править ]

Я недавно наткнулся на страницу обсуждения User: IHateAccounts , и я думаю, что мы должны разрешать апелляции через socks только в том случае, если они утверждают, что они на самом деле не носки sockmaster. Например, предположим, что человек A не является sockpuppet человека B (sockmaster), тогда в WP: SOCKBLOCK человек A не может подавать апелляцию, так как все апелляции sockblock должны подаваться через sockmaster, к которому они не могут получить доступ. ThatIPEditor ( обсуждение ) 08:13, 23 февраля 2021 (UTC)

Идея для нового возможного скина [ править ]

С тех пор, как я начал использовать Ubuntu, мне показалось интересной идея создать в Википедии скин, который делает Википедию похожей на командную строку или терминал. Я знаю, что он, вероятно, не будет реализован, и даже если он будет реализован, очень немногие люди будут его использовать, но это кажется интересной идеей. 4D4850 ( разговорное ) 01:27, 24 февраля 2021 (UTC)

Что вы имеете в виду под «похожим на терминал»? Если вам нужны шрифты фиксированной ширины, а не графика, просто установите Lynx ; вам не нужно возиться с перескином веб-сайтов. -  Радужный 05:33, 24 февраля 2021 г. (UTC)

Хорошо, это в основном то, что я представлял. Спасибо. 4D4850 ( разговорное ) 16:26, 24 февраля 2021 (UTC)

4D4850 , Также Википедия: Wikipedia-mode.el для действительно хардкорных . - Рой Смит (разговор) 13:29, 25 февраля 2021 г. (UTC)

мне нужна статья об усиленной рогатке Тима [ править ]

это усиленная рогатка https://cults3d.com/en/3d-model/various/tim-postma-s-reinformed-slingshot, хотя она также доступна на MyMiniFactory - предшествующий неподписанный комментарий, добавленный Tim3dPostma ( обсуждение • вклад ) 17: 24, 24 февраля 2021 г. (UTC)

@ Tim3dPostma , TimPatAlPostma1996 , TimPostma3DPrints , Timpatalpostma и 3DPrintingTimPostma : вам нужно немедленно прекратить попытки продвигать свою катапульту. Это не заслуживает и никогда не заслуживает статьи здесь . Википедия не предназначена для рекламы ваших изобретений или модификаций дизайна. Ваше редактирование стало разрушительным, и я собираюсь оставить вам официальное предупреждение на ваших нескольких страницах использования, а не только о создании и использовании нескольких учетных записей одновременно (см. WP: SOCK), но также чтобы предупредить вас, чтобы вы перестали использовать Википедию как форум, чтобы пытаться обсуждать глупые вопросы, не относящиеся к теме, не относящиеся к рассматриваемой статье. По сути: прекратите редактировать статьи, связанные с резинкой. Ник Мойес ( разговор ) 23:59, 24 февраля 2021 (UTC)

Adminbot для WP: U1 [ править ]

Любопытно, думал ли кто-нибудь о написании бота для автоматической обработки множества быстрых удалений WP: U1 ? Чтобы предотвратить злоупотребления, он должен убедиться, что страница либо была создана в пользовательском пространстве пользователя, либо никогда не редактировалась кем-либо, кроме пользователя (чтобы кто-то не мог переместить страницу в свое пользовательское пространство, чтобы удалить ее, или U1 статью, которую они созданы, но построены другие). Это могло бы значительно ускорить U1 и позволить администраторам заниматься более полезными делами. Elliot321 ( Обсуждение | вклад ) 02:31, 25 февраля 2021 (UTC)

Возможно, вам стоит попробовать 7SeriesBOT . Если вы человек наполовину пустой , посмотрите на это . - zzuuzz ^{(разговор)} 03:16, 25 февраля 2021 (UTC)

Ах, интересно, не знал, что такой бот существует. Elliot321 ( Обсуждение | вклад ) 06:46, 25 февраля 2021 (UTC)

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

Сегодня я смотрел на количество моих правок. Там было сказано, что у меня «306 удаленных правок», и мне было интересно, на каких страницах они были. Я посмотрел и получил следующее сообщение:

У вас нет разрешения на просмотр истории удаленных страниц по следующей причине:

Запрошенное действие ограничено пользователями одной из групп: администраторы, надзиратели, исследователи, проверяющие.

И я все такой: «Ну, это мой вклад. Почему я этого не вижу?» И я знаю все их аргументы: страницы удаляются, чтобы люди не могли их просматривать, а некоторые на самом деле вредны и т. Д. Но я предлагаю, чтобы, скажем, если бы был неадмин с именем Example , то по моему предложению , единственными людьми, которые смогут увидеть Special: DeletedContributions / Example , будут администраторы и сам Example. Я должен это уточнить. Это похоже на редактирование страниц / js и / css (могут только администраторы пользователей и интерфейсов), за исключением того, что все администраторы смогут их просматривать. Есть мысли по этому поводу? Изменения в предложении приветствуются. 🐔  Chicdat   ^{Bawk мне!} 12:25, 25 февраля 2021 г. (UTC)

Этого не произойдет. Мы могли бы гипотетически изменить MediaWiki, чтобы вы могли просматривать удаленные страницы, на которых вы были единственным соавтором , но то, что вы предлагаете, будет означать, что если кто-то написал страницу, наполненную клеветой, и вы случайно исправили одну опечатку до этого. был удален, мы дадим вам бессрочное право прочитать эту клевету. Я не могу представить себе обстоятельства, при которых Legal когда-либо допустил бы это. -  Радужный 13:10, 25 февраля 2021 г. (UTC)

На практике, если вы хотите / хотите увидеть что-то из ваших удаленных, вы можете спросить на WP: REFUND . В зависимости от того, что это было, администратор может захотеть восстановить его в вашей песочнице или, возможно, даже отправить его вам по электронной почте (не все администраторы готовы это сделать). Кроме того, существует ряд зеркал Википедии, где вы все еще можете найти копию. Я думаю, что большинство из них довольно слизистые, поэтому я не буду называть их по имени, но уверен, что вы сможете найти их, если погуглите по запросу «зеркало википедии». - Рой Смит (разговор) 13:27, 25 февраля 2021 г. (UTC)

Это не то, что я ищу. Я сам сохранил для пользователя копию моей единственной настоящей статьи, которая была удалена. Я говорил об идее Аазима. 🐔  Chicdat   ^{Bawk мне!} 11:19, 27 февраля 2021 г. (UTC)

Я думаю, что удаленные правки должны отображаться так же, как удаленные редакции. Таким образом, если страница удаляется, она удаляет сводку редактирования и версию, но не пользователя со страницы вкладов. Аасим ( разговор ) 18:37, 25 февраля 2021 (UTC)

Но подобное было отмечено выше; есть причины, не относящиеся к примечательности, по которым статья может быть удалена (копирование, клевета, грубая вульгарность и т. д.), и программа не имеет возможности отличить одну правку от другой. Допустим, вы были новым патрулем страницы, который пометил статью для быстрого удаления как страницу оскорбительной атаки. Теперь вы редактор этой статьи . Нет никакой пользы от того, чтобы позволить вам в качестве тегировщика статьи просматривать контент. Не то чтобы вы внесли значительный вклад. К этому типу подходит большая часть удаленных статей; Я понимаю импульс со стороны OP, они представляют себе статью, которую они создали, которая не прошла проверку на известность и была удалена через AFD или что-то еще, и теперь они хотят посмотреть на нее и посмотреть, смогут ли они исправить это и сделать это приемлемо. Это определенно часть того, что мы удаляем, но это не все, что мы удаляем, и большая часть того, что удалено, действительно никогда не должна быть доступна для просмотра снова. В программном обеспечении нет средств для проведения различия между этим типом контента, ТАКЖЕ, есть ли в нем средства отличия среди группы из нескольких редакторов, которые создали контент и отметили его для удаления. Все это просто «правки». - Джейрон, 32 18:57, 25 февраля 2021 г. (UTC)

Я не думаю, что Аазим говорит о содержании или сводках редактирования, а скорее просто говорит об истории изменений удаленных правок. Если я правильно помню из прошлого обсуждения, эти данные уже доступны через API. См. Wikipedia_talk: Sockpuppet_investigations / Archives / Archive23 # Useful_user-right ProcrastinatingReader ( обсуждение ) 19:32, 25 февраля 2021 г. (UTC)

Вы имеете в виду необработанный список удаленных правок, а не различия или что-то в этом роде? Это кажется менее нежелательным. - Джейрон, 32 19:55, 25 февраля 2021 г. (UTC)

В основном: 1 января 1970 г. (diff | hist). . ( Сводка редактирования удалена ) на странице вкладов. Аасим ( разговорное ) 20:51, 25 февраля 2021 (UTC)

Да! Это то, что я имею в виду. Я не вижу редакцию, сводку редактирования или историю - я просто вижу имя редактируемой страницы. 🐔  Chicdat   ^{Bawk мне!} 10:54, 26 февраля 2021 г. (UTC)

Этот запрос в основном требует, чтобы сначала было разрешено phab: T20493 , у которого есть некоторые проблемы как есть. - Изно ( разговор ) 20:58, 25 февраля 2021 (UTC)

Возвращение Кубка GA [ править ]

Кубок GA был соревнованием, которое напрямую поощряло редакторов повышать статус статей в GA. Но последний Кубок GA был в 2016 году, и с тех пор соревнований не было. Чтобы справиться с отставанием в номинациях в GA, а также чтобы улучшить статус статей в GA в целом, я предлагаю вернуть этот конкурс. Мысли? X-Editor ( разговор ) 06:20, 27 февраля 2021 (UTC)

Да. На шаблоне всегда написано: «Пожалуйста, подождите терпеливо», но многие редакторы нетерпеливы. Кубок GA действительно сократит отставание. 🐔  Chicdat   ^{Bawk мне!} 11:16, 27 февраля 2021 г. (UTC)

Редизайн страниц обсуждения [ править ]

Я пробовал полистать архивы и не нашел ничего подобного, поэтому размещаю здесь.

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

Я вижу четыре большие проблемы:

1. Нет простого способа ввести комментарий и добавить его. На большинстве других платформ вы можете ввести что-нибудь, нажать «Отправить» и вуаля - вы прокомментировали. В Википедии нужно пробираться по тексту и находить, где что-то написать, как сделать отступ и т. Д.
2. Нет вложенности комментариев. Невозможно легко найти, кто что сказал в обсуждении на странице обсуждения, и это особенно проблематично для длинных комментариев, комментариев с неправильным отступом и т. Д. Это также затрудняет чтение длинной страницы.
3. Никаких автоматических подписей или уведомлений. Если я сделаю комментарий, я ожидаю, что он скажет, что это я написал, а также уведомит кого-либо еще. Сейчас обе эти функции требуют, чтобы кто-то знал, как это сделать, и нашел время, чтобы добавить пинг, подпись и т. Д.
4. Редактирование исходного кода. Как уже говорилось выше, это высокий барьер во времени и знаниях.

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

Знаю, что не могу быть единственным, кто заметил недостатки формата страницы обсуждения. Что вы думаете о страницах обсуждения и как их можно улучшить?

Fredlesaltique ( разговорное ) 14:04, 27 февраля 2021 (UTC)

@ Fredlesaltique : Есть проект mw: Talk pages / Replying , над которым вы можете отвечать в визуальном редакторе и (я думаю) автоматически добавлять подписи, которые должны адресовать # 1, # 4 и часть # 3, с визуальным редактором, имеющим кнопку для добавления пинга пользователю. Terasail [ ✉ ] 14:56, 27 февраля 2021 г. (UTC)

См. Также пример Flow здесь: mw: Talk: MediaWiki - хотя он решает некоторые из ваших проблем, он порождает совершенно новый набор проблем. - ^{Обсуждение} xaosflux 15:59, 27 февраля 2021 г. (UTC)