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

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

Предупреждения о срабатывании триггеров следует добавлять в начале статей или хотя бы где-нибудь на странице. Избегает того, чтобы люди случайно наткнулись на запускающий контент. Возможно, в виде одного из этих шаблонов заметите штучки, которые идут вверху страницы? - 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)

  Что, ты думаешь, я несерьезно? E Eng 06:42, 2 марта 2021 г. (UTC)

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

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

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

  Триггером травмы является «вьетнамский ветеринар вздрагивает, когда слышит, как пролетает вертолет». Триггер травмы - «мать падает каждый раз, когда слышит любимую рождественскую песню своего умершего ребенка». Триггер травмы - это не «чтение о зле доставляет мне дискомфорт». На самом деле предполагается, что вы чувствуете себя некомфортно, когда читаете о Холокосте и насильственных расистских группах. Чувство дискомфорта, когда вы сталкиваетесь со злом расизма и геноцида, означает, что у вас все еще есть функциональная совесть. WhatamIdoing ( разговор ) 23:37, 2 марта 2021 (UTC)

• Я не думаю, что это следует сразу же отвергать - такие предупреждения не повлияют на содержание статьи и во многом сделают сайт более доступным для некоторых. Что касается того, о каких темах следует «предупреждать», мы можем решить это так же, как и все остальное - через консенсус редактора. Стандартизированный шаблон баннера со вставленными в него предупреждениями о содержимом кажется выполнимым и разумным. BlackholeWA ( разговор ) 23:51, 1 марта 2021 (UTC)
• Серьезно, а как насчет того, чтобы кто-то создал расширение браузера, которое выполняет поиск на странице по ключевым словам и фразам, выполняет какой-то автоматический поиск изображений и т. Д. Перед его представлением. Тогда это будет работать со всем, а не только с Википедией. И мы можем уйти от няни. E Eng 06:42, 2 марта 2021 г. (UTC)
• Я согласен с утверждением WhatamIdoing выше. Но если предположить, что мы могли бы согласовать баннер с предупреждением о срабатывании триггера и составить список предметных областей, которые, по мнению сообщества, должны отображать баннер, то вот что я ожидал бы:

1. Большинство читателей этого не увидят ( баннерная слепота ).
2. Ходят слухи, что в некоторых статьях есть предупреждения о срабатывании триггеров.
3. Люди жаловались, когда статья, которая их лично беспокоила, не содержала предупреждения.
4. Потребуются предупреждения о немаркированных статьях по множеству причин (многие из них явно смехотворны в надежде получить отказ, чтобы они могли транслировать свою фальшивку и получить свои 15 минут), что, если мы не выполним этого, приведет к обвинения в предвзятости, соучастии или безразличии к их страданиям, которые быстро распространятся в социальных сетях, а затем будут подхвачены основными СМИ, которые, похоже, приветствуют твиттер-мобов, создающих для них «новости» кликбейта.

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

• Да, я думаю, нам нужно сделать баннер для запуска контента. Я знаю, что не все думают, что что-то срабатывает. Но что мы должны сделать, так это обсудить на страницах, должны ли они иметь триггерное предупреждение или нет. Starman2377 ( разговор ) 16:40, 2 марта 2021 (UTC)

  Итак, что, если кого-то спровоцируют змеи. Или собак. Или птицы. Или пауки. Должны ли мы также размещать триггерные предупреждения на всех этих страницах? Потому что некоторые люди боятся их так же, как другие - насилия. Где провести черту? Мы можем легко получить практически каждую статью с каким-либо предупреждением о триггере. MeegsC ( разговор ) 17:23, 2 марта 2021 (UTC)

  Объект фобии ≠ триггер травмы. Предупреждение NSFW ≠ вызывает предупреждение. WhatamIdoing ( обсуждение ) 23:29, 2 марта 2021 (UTC)

• Невероятно и печально, что мы даже обсуждаем такую ​​глупую, инфантильную идею. Конечно, это предполагает текст. Фотографии могут быть другой проблемой. Ролло ( разговор ) 21:51, 2 марта 2021 (UTC)
• Хотя предупреждение о триггере намного серьезнее, чем предупреждение о спойлере, я думаю, что опыт Википедии с предупреждениями о спойлерах здесь поучителен. Я не думаю, что это хорошая идея, и могут возникнуть аналогичные проблемы. ~ ONUnicorn ^{( Обсуждение | Вклад )} решение проблем 23:41, 2 марта 2021 (UTC)
• Против текста. Википедия не занимается цензурой текста на такой основе. Возможно, вы захотите поддержать усилия, не зависящие от Википедии, возможно, панель инструментов браузера. power ~ enwiki ( π , ν ) 23:41, 2 марта 2021 г. (UTC)

  Все продолжают красть мои идеи - см. Мой предыдущий пост. Я чувствую себя возбужденным. E Eng 23:44, 2 марта 2021 г. (UTC)

• ПротиводействоватьК сожалению. Я человек, которому обычно выгодны предупреждения о содержании; У меня сильные посттравматические реакции на определенные предметы, поэтому я считаю полезным быть готовым: я собираюсь испытать определенные предметы до того, как я их испытаю - особенно в видеоконтенте и т. Д., Где гораздо легче удивиться контенту. Я против этого предложения по двум причинам: у меня обычно нет этих проблем в Википедии, потому что это энциклопедия, а тематика статей достаточно узкая, так что ссылка, как правило, уже содержит информацию, позволяющую мне не отвечать, если мне нужно . Во-вторых, я не думаю, что мы способны как сообщество доставлять эффективные предупреждения о содержании с достаточно последовательностью и сочувствием по всему проекту, чтобы они были чем-то большим, чем слабый жест.Я бы поддержал более строгую политику в отношении описания аудиовизуального контента, встроенного в статьи, потому что это меня раньше привлекало. - а ^{они / они | спорить | вклад} 07:13, 3 марта 2021 г. (UTC)

• Предположим, я понятия не имею, что могло бы считаться предупреждением о срабатывании триггера. Я думаю, что введения статьи должно быть достаточно, чтобы каждый пользователь решил, хочет ли он лично прочитать статью. Если во введении сказано, например, «Холокост, также известный как Шоа, был геноцидом европейских евреев во время Второй мировой войны. В период с 1941 по 1945 год нацистская Германия и ее пособники систематически убивали около шести миллионов евреев в оккупированной немцами Европе. , около двух третей еврейского населения Европы », на основе этой информации вы можете решить, хотите ли вы продолжить чтение. Я считаю, что триггеры очень субъективны. Не вижу смысла добавлять баннер в кучу статей. джорт ⁹³ | разговор 00:04, 8 марта 2021 (UTC)

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

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

TheFirstVicar4 - извините, вы предлагаете, чтобы это было принято для статей в основном пространстве? Или просто его следует использовать более широко в эссе, руководствах и т. Д.? - Пол ❬ talk ❭ 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)
  • Краткие описания Chicdat предназначены не для этого - они предназначены для устранения неоднозначности. Их можно неправильно использовать для энциклопедического содержания, но цель вовсе не в этом. Элли ( Обсуждение | вклад ) 11:00, 5 марта 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 для отправки запросов на редактирование . В настоящее время, когда редактор добавляет этот шаблон к запросу, размещенному на странице обсуждения статьи, запрос добавляется в очередь и отображается для редакторов в виде категории и сводной таблицы . Рецензирующие добровольцы, которые начинают работу из этой очереди, могут щелкать определенные ссылки, чтобы просмотреть отдельные запросы и ответить на странице обсуждения статьи.

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

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

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

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

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

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

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

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

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

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

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

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

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

Этот тест был проведен вовремя, потому что User: 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», что невероятно полезно. Большинство из них этого не делают, и половина моего времени уходит на расшифровку того, что именно они хотят делать. Исправление этого много сделало бы для этого процесса. Когда правки отформатированы таким образом, я могу легко их просмотреть. Я бы даже согласился на Х в месяц. Я еще не проверял мастер, но если он отформатирован как:

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

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

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

@ WWB , смотрели ли вы в Википедии: систему предупреждений о статьях , например, Википедию: предупреждения о лекарствах / статьях WikiProject ? Я не против обработки случайных запросов на редактирование (они тоже не просто платные редакторы), но я действительно не хочу видеть запросы, связанные с темами, о которых я ничего не знаю. Я быстро просмотрел текущий список из 183 правок и нашел только одноэто относится к области, с которой я знаком, и пролистал, чтобы обнаружить, что один из самых информированных редакторов уже был там. (Затем я нашел еще два похожих запроса и отправил ей эхо-запрос.) Если бы было легко найти только (пять?), Которые могли бы иметь отношение к редакторам WPMED, то я подозреваю, что эти запросы могли бы обрабатываться быстрее. Я думаю, что редакторы Wikipedia: Статьи для создания и Wikipedia: WikiProject Disambiguation обнаружили, что WPMED очень быстро реагирует на небольшие запросы, и я полагаю, что другие крупные проекты WikiProject будут реагировать аналогичным образом. 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 только сегодня из-за связанного инцидента). Конечно, можно только приветствовать улучшение процесса, и враждебное отношение к редакторам ИСП, добросовестно использующим запросы на редактирование, бесполезно. 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 к мастеру Edit Request Wizard ( ERW ) - со страниц руководств и советов и, возможно, из других источников.

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

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

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

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

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

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

Организовать в рамках проекта Wiki - сначала предложено 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 (используя этот поиск [3] ) и нашел смешанные результаты. С одной стороны, у нас, кажется, есть некоторые редакторы, успешно использующие предложенные поля. С другой стороны, у нас есть некоторые редакторы, игнорирующие предложенные поля и пишущие очень бесполезный запрос на редактирование. Есть и другие проблемы, хотя и не такие большие, например, неиспользование инструмента по назначению (например, для запроса перемещения страниц). Я думаю, что приведенное выше предложение сделать инструмент на 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)

Я недавно посмотрел несколько из них, так что поделюсь своим опытом:

• Обсуждение: UCLPartners # Некоторые предлагаемые изменения требуют изменений, которые, вероятно, точны, но удаляют все цифры (например, более миллиона пролеченных пациентов, более 2 000 000 000 фунтов стерлингов годового дохода). Я спросил, почему предполагается удалить эту информацию. Может быть, он сильно различается, поэтому возникнут проблемы с обслуживанием? Может, они хотят выглядеть бедными, если на это посмотрят спонсоры? Может они думают, что это неактуально? Я не знаю.
• Обсуждение: Джорджина Лонг - это набор текста, взятый из резюме BLP, и поэтому должен пройти процесс WP: DONATETEXT . Текст немного расплывчатый, но я отклонил запрос из-за проблем с копированием / лицензированием.
• Обсуждение: Стивен М. Пол # RfC об обновлении биографической информации во вводном разделе не является RFC, и его, вероятно, будет относительно легко реализовать.
• Обсуждение: Frontiers Media # Sources - сложная, противоречивая тема. Для всей статьи нужны более качественные источники, чем у нас.
• Обсуждение: Minuetta Kessler # Запрос на редактирование IMO не должен был нуждаться в запросе на редактирование в первую очередь, так как запрошенное редактирование не должно было когда-либо производиться. Это было легко решено.
• Обсуждение: Josefina Echánove # Год рождения был простым изменением, и это уже сделано.

Только второй запрос был очень длинным. WhatamIdoing ( разговор ) 01:44, 3 марта 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)

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

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

На форумах 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)
• Замечательный Aasim Я не думаю, что вовлечение в обсуждения большего количества шаблонов - хорошая идея. А у администраторов не больше полномочий в обсуждениях, чем у любых других пользователей. Elliot321 ( Обсуждение | вклад ) 01:13, 18 февраля 2021 (UTC)
  • Не думаю, что админам это тоже очень понравится. Я думаю, что может образоваться отставание от «Вещей, на которые администраторы должны делать запросы». У нас уже достаточно незавершенных дел. 🐔  Chicdat   ^{Bawk мне!} 11:30, 27 февраля 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)

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

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

Как бы вы отличили невинных редакторов от лжецов? WhatamIdoing ( разговор ) 01:51, 3 марта 2021 (UTC)

WhatamIdoing , принимая добросовестность и позволяя им попробовать . ^Talk IPEditor ^{· Вклад} 17:06, 9 марта 2021 г. (UTC)

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

В чем именно заключалась выгода для сообщества от вашего предложения? WhatamIdoing ( разговор ) 17:13, 9 марта 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)

@ Ник Мойес , насколько это большая проблема? Мы могли бы заблокировать URL-адрес, если бы это помогло ... WhatamIdoing ( разговор ) 01:53, 3 марта 2021 г. (UTC)

@ WhatamIdoing : не большая проблема. Просто молодой ребенок, возможно, в спектре аутизма, который неправильно понял цель Википедии. Другой администратор с тех пор заблокировал их различные добросовестные учетные записи sockpuppet (если это не оксюморонический термин), поэтому никаких дальнейших действий не требуется. Спасибо, Ник Мойес ( разговор ) 07:47, 3 марта 2021 г. (UTC)

Спасибо за объяснение. WhatamIdoing ( разговор ) 19:44, 3 марта 2021 (UTC)

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

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

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

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

И я все такой: «Ну, это мой вклад. Почему я этого не вижу?» И я знаю все их аргументы: страницы удаляются, чтобы люди не могли их просматривать, а некоторые на самом деле вредны и т. Д. Но я предлагаю, чтобы, скажем, если бы был неадмин по имени Пример , то по моему предложению , единственными людьми, которые смогут увидеть 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)

WMF на самом деле уже делает это общедоступным, но не предоставляет для него вики-интерфейс. Запрос выглядит это . - Cryptic 07:33, 5 марта 2021 г. (UTC)

Что ж, спасибо тебе. 🐔  Chicdat   ^{Bawk мне!} 11:05, 5 марта 2021 г. (UTC)

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

Вы по-прежнему можете запросить на WP: REFUND различную информацию, подобную этой. Журнал изменений, даже с резюме редактирования без текста, должен быть доступен в большинстве случаев. Иногда люди будут просить ссылки или просто задавать вопрос - была ли страница удаления о x? Что касается пользователя: удаленные материалы Chicdat , многие из них связаны с быстрой пометкой удаления пользователем. Довольно много правок было внесено в песочницы или страницы в пользовательском пространстве Chicdat. Некоторые из них - работы AFC, которые позже были удалены; в одном случае черновик, который вы улучшили, был удален, поскольку оригинал нарушал авторские права. Наибольшее количество удаленных правок было в Списке названных тропических циклонов . Грэм Бартлетт ( разговор ) 12:16, 3 марта 2021 (UTC)

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

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

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

В прошлом году, я полагаю, Nosebagbear ( выступление ) 13:31, 3 марта 2021 года (UTC), было крупное мероприятие GA-backlog, которое дало многие из тех же результатов, не будучи в реальной форме кубка.

Nosebagbear , Как человек с заявкой , которая стояла в очереди 3 месяца, и, похоже, еще 4 месяца на рассмотрение, да, это было бы круто. Не то чтобы я жалуюсь, заметьте. Я провел всего несколько анализов, но я был полностью впечатлен усилиями, которые рецензенты вложили в это, и конечный результат был намного лучше, чем тот, который был на момент начала проверки. - Рой Смит (разговор) 21:49, 4 марта 2021 г. (UTC)

РойСмит - Я должен уточнить, я не возражаю, если будет использован GA Cup, просто это было не потому, что GA просто сидела и не боролась с отставанием с 2016 года - они просто использовали неконкурентный метод. Либо мне хорошо. Моя первая подача в GA была на пике отставания - ушло ок. За 10 месяцев до этого я прогнулся и попросил TRM взглянуть напрямую, так что я чувствую боль. Nosebagbear ( разговор ) 22:01, 4 марта 2021 года (UTC)

В прошлом высказывались опасения по поводу плохого качества обзоров, связанных с Кубком GA (аналогичные опасения высказывались по поводу Кубка Вики), с беспокойством по поводу того, что некоторые редакторы больше озабочены пропуском статей, чтобы получить баллы, а не качеством статьи. Любое возобновление Кубка GA должно решить эти проблемы. Найджел Иш ( разговорное ) 22:52, 7 марта 2021 (UTC)

• Мне нужно увидеть предлагаемый набор правил и временных рамок, прежде чем я смогу предложить какую-либо поддержку. Приводы GA отлично справляются с устранением отставания, но в баках GA не так уж много топлива. И как он будет сочетаться с WikiCup, если бы обзоры GA и рекламные акции GA больше не учитывались в этом соревновании? Бродячий человек ( Будьте начеку! Контролируйте вирус! Спасайте жизни !!!! ) 16:42, 8 марта 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)

Поощряйте и переключайте необработанные данные Infobox на Викиданные [ править ]

Первоначально это было предложено в Wikipedia_talk: WikiProject_Wikidata # Encourage_and_switch_raw_Infobox_data_to_to_Wikidata, но никто не ответил, поэтому я публикую его здесь, прежде чем я официально предложу его.

Я заметил, что популярные шаблоны, такие как документация компании Template: Infobox, указывают на то, что Викиданные должны использоваться в качестве запасного варианта, и что данные, которые вы знаете, все равно должны вводиться в качестве аргументов.

Это кажется немного противоречащим цели Викиданных. Это также заставляет меня, редактора Викиданных и преобразователя Wikipedia Infobox Wikidata, чувствовать, что то, что я делаю, бессмысленно.

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

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

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

Что я предлагаю

• Поощряйте редакторов добавлять инструкции для соответствующих параметров Infobox в Викиданные, чтобы они могли просто использовать шаблон Infobox и не заполнять какие-либо параметры.
• Создайте Википроект / процесс удаления необработанных текстовых аргументов, поддерживаемых Викиданными, которые в настоящее время находятся в информационных ящиках, чтобы они использовали Викиданные. Это сделано для того, чтобы продемонстрировать, какие параметры задокументированы Викиданными, показать, что на них есть ссылки, и побудить редакторов, которые видят Викиданные, продолжать их использовать.
  Я понимаю, что это довольно радикально, но я бы очень хотел, чтобы Викиданные использовались и «связывались», а не просто заменялись дублированием работы.
  Другое решение может заключаться в том, чтобы просто переопределить значения необработанного текста Викиданными или, возможно, просто сделать так, чтобы значения необработанного текста больше не могли даже использоваться (параметр шаблона даже не будет использоваться). См. (Дополнительное) решение ниже, как редакторы Википедии могут легко добавить эти Викиданные.
• (Дополнительно) Может быть, разработать индикатор информационных ящиков или какой-нибудь процесс или программу, которые упрощают добавление операторов для параметров инфобокса для редакторов Википедии. Например, значок редактирования для параметра, не имеющего Викиданных, но чей оператор можно добавить, щелкнув значок.
  Если этот параметр имеет необработанное текстовое значение, возможно, его можно выделить красным, чтобы указать, что его нет в Викиданных. Рядом с ним также может быть значок редактирования, который ведет к Викиданным и, возможно, даже копирует данные в Викиданные.

- Lectrician1 ( разговор ) 21:06, 28 февраля 2021 г. (UTC)

• Категорически против. Есть много причин, по которым это плохая идея. Некоторые:
  1. Викиданные не настаивают на поиске источников так, как мы, поэтому получение информации из Викиданных означает отказ от наших стандартов требования надежных источников.
  2. В Викиданных гораздо меньше активных редакторов, чем здесь, поэтому вандализм гораздо труднее обнаружить и устранить.
  3. Простые данные, такие как даты рождения и смерти, могут оказаться уместными для извлечения из Викиданных (при условии, что проблемы WP: BLP были исправлены). Другие, казалось бы, прямые данные спорны и оспариваются. Национальность народа - хороший пример. Википедии на разных языках могут законно иметь разную политику по таким вопросам (является ли «тибетец» приемлемой национальностью? Вы используете текущие или исторические границы?). Таксобоксы - это частный случай инфобоксов, где многочисленные обсуждения показали, почему использование Викиданных было бы плохой идеей, поскольку классификации субъективны, а разные вики делают разный выбор.

Более общая проблема заключается в том, что для того, чтобы это работало, анализ данных и дизайн элемента Викиданных должны точно соответствовать используемому здесь. В качестве примера просмотрите обсуждения на Template talk: Cite Q, чтобы увидеть некоторые проблемы в случае цитирования. Если элемент Викиданных не обрабатывает поля так же, как наши шаблоны цитирования, информация не может быть получена должным образом. Я думаю, что большинство проблем проектирования данных можно преодолеть, но для этого требуется открытый диалог между редакторами языковых вики и редакторами Викиданных, а также признание того, что Викиданные должны соответствовать языковым вики, а не наоборот. На сегодняшний день добиться этого, мягко говоря, было непросто. Питер Коксхед ( разговор ) 09:38, 1 марта 2021 (UTC)

Поскольку эти же вопросы неизбежно возникают в каждом обсуждении, связанном с Викиданными, я чувствую себя обязанным прокомментировать. Хотя суть критики верна, некоторые детали устарели.

1. Хотя на практике источники Викиданных не так хороши, как Википедия, теоретически стандарт проверяемости очень близок к нашему, хотя на данный момент политика d: Wikidata: проверяемость официально не утверждена. В любом случае, какие бы шаблоны мы здесь ни использовали, можно настроить выборку только тех данных, на которые есть ссылки и которые относятся к определенному стандарту (например, не к Википедии).
2. Вероятно, правда, что вандализм обычно не устраняется в Викиданных так быстро, как здесь (хотя я бы хотел увидеть некоторые цифры), их также гораздо, гораздо меньше.
3. Викиданные поддерживают несколько значений одного факта. Это зависит от шаблонов в Википедии, которые используют его, чтобы определить, какое значение выбрать или что делать со значением (например, объединить их с родительским классом или категорией). Что касается BLP, то в Wikidata теперь есть политика d: Wikidata: Living people .

Приветствия -  Finnusertop ( Обсуждение ⋅ вклад ) 11:09, 1 марта 2021 (UTC)

@ Finnusertop : Я согласен с тем, что в Викиданных происходят изменения, хотя и медленно. Проблема с вандализмом (или действительно хорошо продуманными, но некорректными изменениями) при использовании Викиданных аналогична проблеме с автоматизированной системой taxobox., который извлекает таксономические данные из хранящихся здесь шаблонов таксономии. Я чаще всего слежу за категориями отслеживания ошибок таксобокса, и, да, вандализм с шаблонами таксономии вызывает меньше проблем, чем непосредственно в статьях, потому что они менее очевидны. Но вандализм действительно случается, и когда он случается, он обычно затрагивает несколько статей и может быть исправлен только редактором, который понимает, как работает система. Если мы действительно извлекаем данные из Викиданных, нам потребуется какой-то способ получать здесь уведомления об изменении соответствующих элементов Викиданных, а также некоторые хорошие категории отслеживания ошибок или другую систему. Питер Коксхед ( разговор ) 12:50, 1 марта 2021 (UTC)

Таким образом, похоже, что перед переходом к этой системе необходимо решить еще несколько технических проблем. - Lectrician1 ( разговор ) 18:58, 1 марта 2021 г. (UTC)

@ Питер Коксхед : О, я согласен. Между прочим, список наблюдения английской Википедии уже показывает, была ли отредактирована соответствующая запись Викиданных. -  Finnusertop ( обсуждение ⋅ вклад ) 03:22, 2 марта 2021 г. (UTC)

@ Finnusertop : отображение изменений в единственном связанном элементе Викиданных не очень полезно - что, как я понимаю, происходит в настоящее время, - учитывая, что во многих случаях потребуется извлекать данные из нескольких элементов. Это уже проблема с таксонбарами, когда у таксона есть несколько синонимов, каждый из которых имеет элемент Викиданных, из которого таксонбар извлекает данные. Например, чтобы полностью посмотреть Acmispon haydonii , мне нужно будет получать уведомления о четырех элементах Викиданных, которые использует таксонбар. Проблема еще более очевидна с . Должна быть возможность каким-то образом автоматически связывать языковую вики-статью со всеми без исключения элементами Викиданных, которые она использует. Питер Коксхед ( разговор{{Cite Q}}) 07:16, 2 марта 2021 г. (UTC)

• Викиданные также по своей сути не подходят для тех, кто умеет редактировать Википедию, и тем сложнее, чем больше вам нужно с ними делать. Это означает, что любое переключение будет особенно трудным. В идеале мне нужен кросс-проектный инструмент, который упростил бы работу по исправлению ошибок. Что касается источников, то когда en-wiki несколько лет назад повысила свои правила поиска источников, фактическая реализация заняла много времени. Я полагаю, что викиданным потребуется немало времени, чтобы полностью опубликовать и усвоить любые изменения, которые они вносят. Nosebagbear ( разговор ) 13:30, 3 марта 2021 г. (UTC)
• @ Lectrician1 :Мы не должны проводить здесь жирное голосование, но, несмотря на то, что лично я в целом согласен с предложением, я твердо уверен, что здесь не будет консенсуса. Проблемы с источниками и вандализмом являются основополагающими препятствиями для более широкого внедрения Викиданных в en-WP, поэтому, если вы хотите увидеть принятие того типа, который вы предлагаете, сосредоточьтесь на их решении, а затем возвращайтесь. Из вышесказанного также ясно, что преобразование должно быть ограничено неконкретными параметрами. Как я уверен, вы знаете, централизация Викиданных была бы чрезвычайно полезна для всех неанглийских языков, но большинство английских редакторов заботятся только об английском и поэтому не считают это большим плюсом. Я предсказываю, что ему придется дойти до того момента, когда это будет так же удобно, как добавление данных локально, без существенных недостатков до этого »Достигну консенсуса. {{u |Sdkb }} ^talk16:41, 3 марта 2021 г. (UTC)
• НЕТ - это теперь постоянный вопрос, и ответы на него не изменились: консенсус на Wikipedia.en заключается в том, что мы НЕ хотим, чтобы информация экспортировалась из Викиданных (за исключением нескольких очень ограниченных ситуаций). Возможно, нам нужна новая страница политики, которая закрепит этот консенсус понятным языком (что-то, на что мы можем указывать всякий раз, когда он появляется ... но, что более важно, что-то, что объясняет, почему экспорт информации из Викиданных не считается приемлемым, и излагает то, что немногие исключения есть). Blueboar ( разговор ) 15:13, 4 марта 2021 (UTC)

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

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

Автор предложения упоминает, что то, как работает Википедия, «противоречит цели викиданных». Моя реакция на это: «Ну и что? ... это проблема WD, а не наша». Чтобы пойти еще дальше, я бы сказал, что «цель» WD на самом деле может противоречить «цели» WP ... и из-за этого может случиться так, что два проекта никогда не будут объединяться так, как вам хотелось бы. Blueboar ( разговор ) 16:57, 4 марта 2021 (UTC)

Это уже обсуждалось в RFC и даже в постановлении ARBCOm несколько лет назад, хотя это не так просто, как «да» или «нет». - Зеленый C 17:27, 4 марта 2021 г. (UTC)

Blueboar, Я согласен с тем, что интерфейс Викиданных неудобен для пользователя, что является большой проблемой. Частично проблема заключается в том, что ему необходимо отформатировать информацию так, чтобы она была доступна как для компьютеров, так и для людей, а не Википедия, которая должна быть ориентирована только на людей. Тем не менее, помимо этого, я думаю, что есть много возможностей для улучшения, и когда это произойдет, я не согласен с тем, что цели несовместимы. Существует много информации, которую мы в настоящее время тратим впустую, обновляя вручную (например, годовой доход компаний каждый год), тогда как ее можно было бы просто импортировать оптом в Викиданные и обновлять автоматически. Это помогло бы обновлять множество страниц с низким трафиком (и страниц на языках с низким трафиком; Викимедиа - это глобальное движение, поэтому давайте не будем англоцентричными) и сэкономить колоссальные усилия редактора.Все это нам напрямую помогает.{{u | Sdkb }}  ^talk 07:25, 5 марта 2021 г. (UTC)

RFC: Более информативный журнал изменений редактирования [ править ]

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

Моя мотивация для этого изменения заключается в том, что текущая система, показывающая изменение в байтах, не сообщает мне, сколько текста было добавлено, и, следовательно, тот, кто добавляет пару ссылок и цитат, может иметь такое же изменение в байтах, как и тот, кто написал абзац. без цитат. Philipp.governale ( разговор ) 23:25, 4 марта 2021 (UTC)

Philipp.governale , включите всплывающие окна навигации в настройках в разделе «Гаджеты». Одной из функций является предварительный просмотр различий и доступ к обеим ревизиям в списке наблюдения, истории и связанных с ними изменениях, просто наведя указатель мыши на «предыдущий» или «diff». StarryGrandma ( разговор ) 02:19, 5 марта 2021 (UTC)

StarryGrandma , Большое спасибо, я обнаружил много дополнительных настроек, которые стоит попробовать! Очень полезный! Philipp.governale ( разговор ) 02:31, 5 марта 2021 (UTC)

Требовать правки в основном пространстве для AfC / NPR / PCR / отката [ править ]

Я решил, что у нас здесь недостаточно ужасных идей, и я просто швыряю эту в стену, чтобы посмотреть, приживется ли она. Идея: потребовать добавления некоторого количества исходных заявлений к статьям (или копий, или любого вида существенного редактирования в основном пространстве), прежде чем запрашивать разрешения, когда вы просматриваете работу других (изначально я думаю о AfC / NPR / PCR / откате). Помимо CREEP, я считаю, что самая большая проблема с этим - отсутствие хорошего числа. Если нам потребуется достаточно правок, чтобы они действительно имели желаемое влияние (чтобы люди получали разумное количество опыта создания контента), два недостатка - чрезмерные накладные расходы для администраторов PERM и чрезмерный барьер для входа перевешивают любые положительные эффекты. И если нам потребуется крошечное число (однозначное), люди будут просто копаться и вносить дерьмовые правки, и никто ничего не узнает (и вотs по-прежнему PERM накладные расходы и барьер для входа). Во всяком случае, интересно слышать, что думают люди.Enterprisey  ( разговор! ) 06:23, 5 марта 2021 (UTC)

Enterprisey , как лица, предоставляющие разрешения, сообщают, сколько утверждений из источников кто-то добавил? {{u | Sdkb }}  ^talk 07:15, 5 марта 2021 г. (UTC)

Попросите их связать различия или, может быть, проверить их историю изменений?

Сказав «вам нужно связать две разницы, в которые вы добавляете источники», довольно легко отфильтровать запросы людей, которые не читают правила. Элли ( Обсуждение | вклад ) 07:19, 5 марта 2021 (UTC)

Является ли проблема для новичков или других явно неквалифицированных редакторов, запрашивающих эту химическую завивку? (Я не тратил время на эти доски объявлений, поэтому не знаю, но просто дважды проверял, решает ли это проблему .) {{U | Sdkb }}  ^{обсуждение} 07:30, 5 марта 2021 г. (UTC)

Не знаю, спросите у Энтерпрайза. Я просто не вижу в реализации большого препятствия. Элли ( Обсуждение | вклад ) 07:38, 5 марта 2021 (UTC)

Проблема, которую пытается решить это предложение (которое, я должен еще раз подчеркнуть, является крайне недоработанным): расстреливать или даже вообще пересматривать свои вещи - это немного больно. Таким образом, люди, получившие привилегию проверять работы других, должны были выполнить часть этой работы самостоятельно, прежде чем они получат эту привилегию. Требуемого количества редактирования в основном пространстве недостаточно, потому что, конечно, не все изменения в основном пространстве требуют одинакового объема работы. Подводя итоги, в настоящее время существует дисбаланс между работой, необходимой для написания чего-либо, и работой, необходимой для ее устранения, и было бы неплохо немного восполнить этот пробел или, по крайней мере, обеспечить, чтобы последнее было выполнено с некоторым сочувствием. И да, я подумал о том, чтобы попросить кандидатов перечислить различия как наиболее вероятную реализацию. У нас даже может быть автоматическая проверка с помощью формы withJS.(форма, показанная сценарием, загруженным withJS), поэтому отклонения «неверно сформированного / неполного запроса» уходят в прошлое.Enterprisey  ( разговор! ) 08:52, 5 марта 2021 (UTC)

И, конечно же , что проблема - то есть более новые редакторы фактически получить укусил рецензентов , которые не имеют достаточного опыта содержания? Совсем не знаю, но не удивлюсь, если так. Я не уверен, как собрать точные цифры по этому поводу, но я подумаю над этим еще немного. Enterprisey  ( разговор! ) 09:04, 5 марта 2021 (UTC)

Проблема в том, что новички, которые чувствуют себя укушенными, обычно не сообщают об этом, по крайней мере, конструктивно. Элли ( Обсуждение | вклад ) 10:03, 5 марта 2021 (UTC)

Хорошо это или плохо, но многие RCP / Hugglers (=> откатчики) не создают контент. Я не думаю, что это приводит к проблемам с NPR / AfC. Мне кажется, что многие рецензенты AfC придерживаются высоких стандартов, потому что они добавляли контент раньше, но стоит спросить @ Barkeep49 и Primefac (соответственно) об этих двух областях. ProcrastinatingReader ( talk ) 16:48, 5 марта 2021 (UTC)

У AfC уже есть это требование. Primefac ( разговор ) 17:11, 5 марта 2021 (UTC)

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

Когда я смотрю запрос, я ищу причину для предоставления разрешения (поскольку первое разрешение для меня всегда будет своего рода испытанием, которое по своей сути устраняет некоторый уровень риска). Я задаю себе два вопроса: есть ли у этого пользователя очевидный опыт понимания / применения соответствующих политик / руководящих принципов и есть ли у него расположение, чтобы поддерживать стандарты поведения, которых я ожидаю от New Page Patroller. Проверки размещения просты - я смотрю их журнал блоков, изучаю их историю разговоров пользователей и проверяю, есть ли у них какие-либо уведомления DS (так как это может быть способом изучить расположение в более «горячей» среде). Пользовательский разговор также дает мне идеи о вещах, которые мне нужно исследовать при проверке понимания. Я всегда буду проверять журнал CSD (или, если это не удается, их историю редактирования / удаления) как это 'Это так или иначе важно для меня - никакой послужной список CSD (или плохой) не заставит меня искать более высокие стандарты во всем остальном, чем я занимаюсь. Я посмотрю, сделали ли они AfC. Поскольку у AfC и NPP есть много совпадающих потребностей, если они выполнили AfC и имеют хорошую репутацию, этого будет достаточно для меня, чтобы предоставить PERM. После этого я перейду к созданию контента. Если они создали контент, будь то новые статьи или прошли проверку FA / GA, это будет отличным знаком. Я также собираюсь проверить участие AfD как способ применения этой информации, если у них нет послужного списка AfC. Как я уже сказал, если я скажу «да» (т.е. они хорошо справятся с AfC), я, вероятно, перестану искать и назначу испытание.

В целом, я хочу отметить, что NPR требует редактирования в основном пространстве (500), а не какого-либо вида редактирования. Бест, Barkeep49 ( разговор ) 17:32, 5 марта 2021 (UTC)

Мой процесс рассмотрения кандидатов достаточно похож на процесс Barkeep49 , поэтому я не думаю, что необходимо подробно перечислять шаги. Я также согласен с тем, что, по крайней мере, в том, что касается NPR, существующая планка достаточно высока, поэтому я не думаю, что нам нужны какие-либо дополнительные явные требования (хотя мы, возможно, захотим пересмотреть переписывание довольно редких руководящих принципов для предоставления более согласованных с тем, что мы действительно ожидаем от кандидатов). _{подписали,} Rosguill ^{разговор} 19:12, 5 марта 2021 (UTC)

Если честно, требование «хотя бы одна не-заглушка создана» может быть лучше, чем 500 правок. Либо-либо, либо в качестве замены, я не знаю, но я думаю, что создание контента может быть хорошим требованием, когда вся роль заключается в создании контента. Элли ( Обсуждение | вклад ) 20:05, 5 марта 2021 (UTC)

Предприятие, Я признаю, что у меня нет достаточно времени, чтобы прочитать здесь всю дискуссию, но чтение вашего сообщения оставило меня с мыслями, которые я думал, что просто уйду отсюда - они не будут отполированы. Похоже, есть две общие цели, которые вы могли бы попытаться решить с помощью этого предложения: (1) со стороны кандидата, сигнализируя о необходимом правильном опыте, и (2) со стороны администратора, уменьшая дискреционные полномочия для предоставления (для уменьшения несогласованности, поднять стандарты и т. д.). Лучший способ добиться этого - использовать рекомендательные, а не обязательные инструкции. По первому пункту вы будете правы, если скажете, что есть веская причина для сокращения количества не отвечающих требованиям кандидатов, отговаривая некоторых повышением стандартов: когда мы отказываем кандидатам, это, вероятно, первый раз, когда им формально отказывают. что-то в Википедии,и это может быть воспринято как серьезный упрек, а не то, что мы хотим делать, если можем помочь; Кроме того, хорошее руководство может предоставить информацию, помимо «демонстрации компетентности», о том, как именно создать послужной список. На стороне администратора обязательный стандарт просто не сработает; ваш лучший вариант, вероятно, будет (1) проработать PERM в течение нескольких месяцев, затем (2) написать то, что вы считаете хорошими общими рекомендациями, затем (3) убедить дюжину или меньше администраторов, которые работают PERM, что эти рекомендации (возможно, с правками от них) правильные. Лучший,ваш лучший вариант, вероятно, будет (1) проработать PERM в течение нескольких месяцев, затем (2) написать то, что вы считаете хорошими общими рекомендациями, затем (3) убедить дюжину или меньше администраторов, которые работают PERM, что эти рекомендации (возможно, с правками от них) правильные. Лучший,ваш лучший вариант, вероятно, будет (1) проработать PERM в течение нескольких месяцев, затем (2) написать то, что вы считаете хорошими общими рекомендациями, затем (3) убедить дюжину или меньше администраторов, которые работают PERM, что эти рекомендации (возможно, с правками от них) правильные. Лучший,KevinL ( он же L235 · t · c ) 20:35, 5 марта 2021 г. (UTC)

Цветные фотографии [ править ]

Я не думаю, что в Википедии следует использовать цветные версии фотографий, которые изначально были черно-белыми. Раскрашенная фотография - это, по сути, чье-то произведение искусства, и ее использование можно рассматривать как форму оригинального исследования. Этот вопрос дважды поднимался в шахматном проекте википедии в связи со статьями Бобби Фишера и Александра Алехина, и я уверен, что он поднимался и в других местах. 10:07, 5 марта 2021 г. (UTC)

РГ: Нет оригинальных исследований политика не имеет подзаголовка , что работа обсуждает пользователя и изображения (см WP: OI ) ... в общем таких работ в порядке, но есть исключения. Blueboar ( разговор ) 13:17, 5 марта 2021 (UTC)

В обоих случаях исходная публикация фотографии уже была раскрашена. Википедисты не раскрашивали. Это ключевое различие. Википедисты не проводят никаких оригинальных исследований по этим фотографиям, потому что они не раскрашивают их. Журнал Chess Life сделал. - Джейрон, 32 13:22, 5 марта 2021 г. (UTC)

• Я имею в виду, можно утверждать, что фотографирование и загрузка его в Commons - это сама по себе форма оригинального исследования. Меня больше всего беспокоит окраска не из-за того, что это операционная или художественная работа (мы все время используем картины людей), а скорее в том, что она может ввести в заблуждение. При использовании раскрашенных фотографий важно отметить, что они были раскрашены в подписи. Если цвета важны для фотографии и неизвестно, соответствуют ли они цветам из реальной жизни, это тем более важно. {{u | Sdkb }}  ^talk 20:37, 5 марта 2021 (UTC)

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

Если мы будем более точными, 99% Википедии - это ИЛИ, но ИМО это не ИЛИ в общепринятом значении wp: OR. Но раскрашенные фотографии IMO представляют собой повреждение / потерю данных, содержащихся в исходной черно-белой фотографии. И если это не обозначено как таковое, это тоже вводит в заблуждение. Но нам не нужно еще одно правило, запрещающее их. North8000 ( разговор ) 21:07, 5 марта 2021 (UTC)

Что нам тогда нужно? Оригинал от Александра Алехина - отличное фото и, на мой взгляд, лучше смотрится в оригинальном черно-белом. Может быть, заметка какая-то в WP: OI ? MaxBrowne2 ( разговор ) 00:07, 6 марта 2021 (UTC)

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

См. Также эту печальную последовательность событий ; Короче говоря, все пришли к единому мнению, что окрашенное изображение было интересным произведением искусства, но исходное черно-белое изображение более важно для изображения его темы. Ура, RandomCanadian ( обсуждение / вклад ) 03:06, 7 марта 2021 (UTC)

Мои 2 цента: ненавижу цветные фотографии. Обычно они выглядят так, как будто к ним подошел ребенок с коробкой цветных карандашей, поэтому они редко бывают реалистичными. Это стало модно для газет и журналов , чтобы использовать colourised фотографии, чтобы они выглядели современно, но Википедия не следует делать это .-- ♦ Ян Ма гр М ♦ ^{(Поговори со мной)} 10:31, 7 марта 2021 (UTC)

Более легкое предложение новых статей для тех, кто не участвует [ править ]

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

Я вижу несколько преимуществ, если будет разработано что-то вроде этого:

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

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

Приношу свои извинения, если что-то подобное уже было предложено. Philipp.governale ( разговор ) 01:23, 6 марта 2021 (UTC)

Philipp.governale это похвальная цель, но система запрошенных статей уже перегружена тысячами незаметных записей, которые никогда не будут созданы. Вероятно, есть лучший способ сделать это, но небольшой барьер для входа, чтобы сократить огромный приток заявок, - не самое худшее - недостатка в запросах нет. Элли ( Обсуждение | вклад ) 01:57, 6 марта 2021 (UTC)

Элли в отношении вашей озабоченности по поводу превышения количества запрашиваемых статей:

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

и что касается вашего комментария о том, что некоторый барьер для входа - это хорошо, я не согласен.

• Барьер для входа в первую очередь только отпугнет тех, кто, возможно, не очень доволен технологией, но, тем не менее, может предложить совершенно хорошую статью. Таким образом, мы можем усиливать предвзятость содержания Википедии, усложняя участие определенных сообществ. Эти сообщества могут, например, включать пожилых людей и людей с ограниченным или только недавним доступом к Интернету.
• Если запросы в основном касаются известных или значимых тем, я лично не возражал бы иметь много записей. Чем больше разнообразия, тем больше людей могут найти статьи, которые им интересны или в которых они разбираются - Philipp.governale ( обсуждение ) 04:25, 6 марта 2021 г. (UTC)

  Philipp.governale достаточно честный. Я определенно думаю, что в этом процессе можно было бы изменить дизайн - например, для запрошенных статей потребуется RS. Как это происходит ... ну, все идеи должны быть на столе. Элли ( Обсуждение | вклад ) 04:30, 6 марта 2021 (UTC)

Элли хорошо замечает, что требует RS. Я не уверен, что мы должны требовать RS при подаче, но, возможно, сделать это необязательным, а затем разрешить другим добавлять RS, если они их найдут? Не совсем уверен в том, как это лучше всего сделать, поскольку для меня следует найти тщательный баланс между снижением входного барьера и обеспечением того, чтобы система не была переполнена неприемлемыми записями, как вы упомянули. Читатель, который сделал это предложение, может не чувствовать себя комфортно при проведении исследования, и ему не обязательно делать это, чтобы предлагать статью. С другой стороны, это значительно увеличивает нагрузку на сообщество, которое и так уже растянуто. Если нам действительно потребуется RS, нам все равно потребуется, чтобы сообщество как-то проверяло источники. Это все равно будет проще, чем требовать от сообщества самого поиска источников. -Philipp.governale ( разговор ) 05:00, 6 марта 2021 (UTC)

Philipp.governale, если мы не требуем RS, система получит тысячи незаметных страниц, которые никто не потрудится удалить. Элли ( Обсуждение | вклад ) 05:14, 6 марта 2021 (UTC)

Элли Ладно согласилась. Должен ли редактор, который рассматривает возможность написания статьи, нести ответственность за проверку достоверности предоставленных источников? - Philipp.governale ( разговор ) 05:24, 6 марта 2021 г. (UTC)

Philipp.governale да. Я считаю, что редакторы, которые следят за списками, должны иметь возможность удалять записи без перечисления надежного источника. Я думаю, что это уже в некотором роде так, но до сих пор тысячи запросов без них. Элли ( Обсуждение | вклад ) 05:37, 6 марта 2021 (UTC)

У меня есть предложение: как насчет того, чтобы разрешить пользователям публиковать материалы в Запрошенных статьях, только если они предоставят хотя бы один надежный источник, указывающий на известность? 🐔  Chicdat   ^{Bawk мне!} 11:11, 6 марта 2021 г. (UTC)

Chicdat На мой взгляд, поиск RS, который явно указывает на известность, может быть слишком трудным и просто невозможным для некоторых субъектов. Еще один вопрос, который у меня был бы: что считается выдающейся известностью? Обычно наличие нескольких RS должно быть достаточным для определения известности объекта. - Philipp.governale ( разговор ) 11:51, 6 марта 2021 (UTC)

@ Philipp.governale и Chicdat : Если мы не можем доказать известность чего-либо, в нем не должно быть статьи, и статья никогда не будет сделана. Требование некоторого количества значительного покрытия или другая причина, по которой человек является заметным (соответствует SNG), является разумным. Элли ( Обсуждение | вклад ) 02:55, 7 марта 2021 (UTC)

• Я имею в виду кнопку в верхней части каждого, которая открывала бы шаблонную страницу с указанием вверху, чтобы показать источники информации, которые были: надежными, независимыми и вторичными (и с примерами вторичных), а также подробными, а затем наличие маркеров для источников 1, 2 и 3. Если люди не могут найти хотя бы 2 источника, их не следует добавлять. Очевидно, что любой, кто в конечном итоге рассмотрит это предложение, должен будет предоставить свой собственный обзор, но для любого включения в RA должно потребоваться прохождение доверенности prima facie о признании предложения. Мы могли бы даже прикрепить фильтр редактирования, который запрещал бы его, если бы в нем не было хотя бы двух URL-адресов. Nosebagbear ( разговор ) 11:18, 7 марта 2021 (UTC)

Nosebagbear Мне нравится включать примеры того, как выглядят и не выглядят вторичные и надежные источники. Что вы имеете в виду, говоря об источниках 1, 2 и 3? С точки зрения фильтра редактирования, определяющего URL-адреса, мы должны задать вопрос: есть ли известные субъекты, у которых RS может не быть онлайн? Philipp.governale ( разговор ) 03:47, 8 марта 2021 (UTC)

Как и при использовании WP: ERW, он загружает шаблон с несколькими пунктами маркированного списка и комментарием рядом с ними, в котором говорится, что следует туда поместить (причина изменения, источник и т. Д.), Этот метод можно использовать здесь. Онлайн-источник неплох, но любые мысли о том, как использовать какой-либо процесс для фильтрации - в противном случае, если он станет более заметным / легким, он будет пропущен большими числами и потребует ручного просмотра для фильтрации. Nosebagbear ( разговор ) 09:03, 8 марта 2021 (UTC)

Nosebagbear Я полностью согласен с тем, что было бы действительно неплохо не проверять источники вручную, но, тем не менее, я думаю, что все источники (в том числе онлайн) необходимо будет проверить, чтобы убедиться, что они соответствуют критериям RS. Возможно, для автономных источников мы могли бы потребовать дополнительные поля для автора, издателя, года и т. Д., Чтобы людям было труднее обойти систему? Таким образом, мы могли бы также включить фильтр редактирования, который обнаруживает URL-адрес, а пользователь просто выбирает тип используемого источника. Philipp.governale ( разговор ) 00:39, 9 марта 2021 (UTC)

@ MMiller (WMF) и @ Trizek (WMF) , вы на это смотрите? Я знаю, что в прошлом координаторы edit-a-thon обсуждали сложность составления списков важных тем. Некоторые мероприятия по редактированию хотят начинать с предварительно проверенного списка предлагаемых тем, поэтому они поговорят с профильными экспертами, чтобы составить список заранее. Если у вас есть профессор местного искусства, который желает идентифицировать дюжину важных местных художников, отсутствующих в Википедии, вы действительно не хотите, чтобы это было остановлено проблемой UX. Whatamidoing (WMF) ( обсуждение ) 00:50, 9 марта 2021 (UTC)

Команда Growth работает над облегчением первых шагов новичков, но мы не рассматриваем создание статей (пока).

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

Здесь, в английской Википедии, есть страница проекта об этих функциях . Тризек (WMF) ( разговор ) 13:32, 9 марта 2021 (UTC)

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

Перенесли из WP: VPR

Привет. Я считаю, что создание версии этой боковой панели в нижнем колонтитуле будет большим подспорьем, поскольку она иногда занимает слишком много места в тексте статьи. Что вы думаете? Кроме того, я не разбираюсь в кодировании, поэтому, если вы согласны, не стесняйтесь создавать указанный нижний колонтитул. Более того, я не уверен, что этот форум - подходящее место для вопросов. Веверве ( разговорное ) 13:04, 9 марта 2021 (UTC)

@ Veverve : вот и все: {{ Translation navbox }}. Я добавил его во все статьи, на которые есть ссылки на WP: BIDIRECTIONAL . -  Finnusertop ( обсуждение ⋅ вклад ) 22:56, 10 марта 2021 г. (UTC)