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

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

Изменение дизайна значков избранных, хороших и оценок статей [ править ]

• Значок текущей хорошей статьи

• Значок текущего избранного контента

Это предложение направлено на достижение консенсуса в отношении новых значков, которые появляются в верхнем правом углу страниц с хорошими статьями (GA) и избранного контента (FC) для обозначения их статуса, а также для их вариантов значков (кандидат, ранее избранный / хороший, бывший кандидат). Для единообразия он также предлагает новые значки оценки (ABC-Start-Stub-List-Disambig).

Предыстория : недавно было предложение Village Pump ( здесь ), в котором обсуждали, стоит ли менять значки FA и GA. Основными поднятыми проблемами были слишком подробный значок FC, из-за которого он плохо отображался при малых размерах, а также сбивающий с толку значок GA, который также используется в качестве значка для голосования в поддержку. Короче говоря, поддержка предложения превысила число оппозиционеров - 2: 1. Таким образом, я создал новые значки, которые, как мне кажется, решают эти проблемы. Я сделал довольно много вариантов этих значков, большое количество из них можно найти здесь: File: FA-GA icon offer.png , но для упрощения этого процесса я выбрал то, что я считаю самые четкие и интуитивно понятные в предложении. По мере поступления мнений мы можем создавать новые наборы иконок для предложений.

Предложение 1 [ править ]

• Новые иконки, Предложение 1

• Рядом со старым. Обратите внимание, что размер изображения по умолчанию таков, что отдельные значки имеют ширину 45 пикселей, что примерно соответствует размеру, который они будут отображаться на страницах обсуждения.

Ключевые моменты :

• Значки FC упрощены, значки GA соответствуют формату FC.
• Иконки GA изменены на серебристые, так как их раскрашивать было очень естественно.
• Прежние значки FC / GA имеют пунктирный контур звезды, означающий, что когда-то они имели это различие.
• Кандидат в FC / GA и повторная оценка обозначаются одним и тем же значком, поскольку они служат одной и той же цели - оценивать, следует ли их классифицировать как FC / GA.
• Бывшие кандидаты FC / GA отмечены знаком «x», означающим, что некоторые пункты не удовлетворяли критериям FC / GA.
• В статьях классов Start и Stub появятся новые значки.

Поддержка (значки статей) [ править ]

• Поддержка - как предлагающий. Эти значки достаточно просты, чтобы они хорошо отображались в мелком масштабе, новый цвет и формат соответствия для GA делает ясным и очевидным, что они связаны, в то время как FC явно является более высоким различием, и новые значки имеют за собой интуицию в отношении что они имеют в виду. Pbrks ( обсуждение ) 21:02, 2 апреля 2021 (UTC)
• Поддержите со следующими оговорками. Я очень сомневаюсь, что не редакторы будут знать, что все это означает, и не обязательно должны. В любом случае, в списке интервики есть (я думаю) серебро за хорошую статью на другом языке (см. Джеймс Томпсон (инспектор) ) и золото за избранную статью на другом языке ( несколько примеров см. Вторую мировую войну ). Я думаю, что цвета следует привести в соответствие с этими стандартами, если это еще не сделано. Бывшая статья / бывший кандидат и т. Д., Материал не относится к теме и должен вместо этого перейти на страницу обсуждения, ИМО. -  Джон М. Вулфсон  ( обсуждение  •  вклад ) 21:16, 2 апреля 2021 г. (UTC)
  • Я не вижу нигде, предполагающей, что прежний материал теперь будет помещен на страницу статьи (что почти наверняка потребует отдельного предложения), я предполагаю, что их замена будет осуществляться соответствующими значками на странице обсуждения. Aza24 ( разговорное ) 21:22, 2 апреля 2021 (UTC)
  • Первый, кандидат и т. Д. Можно увидеть только на страницах обсуждения. Вы увидите только значки «Продвигаемые» в правом верхнем углу страницы. Pbrks ( обсуждение ) 22:13, 2 апреля 2021 (UTC)
• Принципиальная поддержка. Повторение моего предыдущего комментария: значки следует изменить на то, что знакомо среднему читателю. Текущие значки хороши, но они хороши для википедистов. Среднестатистический читатель, вероятно, не понимает, что это значит. Мы должны стремиться использовать изображения, которые будут понятны читателям. Например: серебряная звезда, золотая звезда. Галочка / двойная галочка. Или что-то вдоль этих линий. Читателю должно быть очевидно, что он символизирует. Однако я не уверен в этом конкретном наборе. ProcrastinatingReader ( обсуждение ) 14:04, 3 апреля 2021 г. (UTC)
  • Полностью согласен с этим комментарием. JBchrch ( разговор ) 19:45, 15 апреля 2021 (UTC)
• Поддержка Pbrks и Ivanvector (в разделе ниже). Текущие значки ужасны в том размере, в котором они обычно отображаются. - Ахехт (РАЗГОВОРНАЯ СТРАНИЦА) 03:13, 12 апреля 2021 (UTC)
• Поддержка согласно выше. EpicPupper 21:38, 12 апреля 2021 г. (UTC)
• Поддержка Как указано выше, я предпочитаю единообразие. Саха  ❯❯❯  Оставайтесь в безопасности 08:41, 14 апреля 2021 г. (UTC)  
• Поддерживает в принципе, но могут или даже должны быть некоторые улучшения. Сначала я собирался сбить это, потому что им не хватало «атмосферы», и у меня есть рефлекс позвоночника, который идет вразрез с чем-либо плоским без засечек и дизайном iOS-фиксации, который я абсолютно ненавижу. Такие вещи создаются только потому, что они выглядят современно, без какого-либо отношения к своему предназначению. Но если подумать, я думаю, что они действительно хороши и хорошо подходят для цели. Поскольку при реальном использовании они будут небольшими, хорошо, что они простые и имеют четкие цвета. Золото и серебро для высших классов - это блестящий дизайн графического интерфейса, а также упрощение линейки идизайн, который сам по себе намекает на то, что это означает, с вопросительным знаком для кандидата независимо от того, впервые он или нет, X для отклоненного, дырчатая звезда для бывшего и заполненная звезда для текущего. Однако вам нужно поработать с золотым и серебряным оттенком, он слишком мягкий и сливается. Для других он отлично подходит с более четким оттенком и большим контрастом. Наклон течения придает характер, но его труднее увидеть в миниатюре. Шрифты с засечками легче читать с маленькими кеглями, что является их особенностью, так что учтите это. Если вы сделаете новую партию шрифтов с засечками для букв, я уверен, вы получите больше поддержки. Однако именно по всем этим причинам я отвергаюпредлагаемые значки заглушки и запуска. Текущие отличные, как они есть, прекрасно символизируют эти классы. Новые загромождены и слишком похожи. Общая критика заключается в том, что края слишком мягкие, они должны быть подчеркнуты, возможно, даже иметь контурные линии, по крайней мере, значки FA и GA. Вопросительный знак слишком большой или слишком раздутый, он слишком близко расположен к верхнему кольцу. - Mango från yttre rymden ( разговор ) 23:57, 2 мая 2021 (UTC)
• Поддержка . Давай, люди. Меня критикуют по поводу того, что значок GA не является зеленым, а звезды на новых значках GA и FA не слишком прозрачны, но значки, которые мы сейчас используем, устарели и были сделаны в конце 2000-х годов, и они видны. Это определенно что-то сломанное, что нужно исправить. Мне действительно нравится трехмерное ощущение старого значка FA при ближайшем рассмотрении, но медаль выглядит более бронзовой, чем золотой, IMO, и вы не заметите, насколько трехмерным выглядит значок при чтении FA, потому что он такой маленький. Я чувствую, что новый значок стал более светлым. Кроме того, большинство новых значков в любом случае имеют тот же цвет, что и старые. Они также в большей степени связаны с текущим графическим дизайном большинства веб-сайтов и коммерческих продуктов сегодня, и вы знаете, что происходит с предприятиями, которые не модернизируются. 👨x🐱 ( говорить) 20:19, 4 мая 2021 г. (UTC)
• Поддержите с комментарием . Как (относительно новый?) Редактор, я могу сказать, что предлагаемая версия, безусловно, помогает новым редакторам быстро понять, что означают эти значки. Я просто не вижу большой разницы между полной звездой и сломанной звездой, когда они появляются в какой-то статье. Кроме того, новые значки единообразны по своей природе и дают гораздо более чистый и упрощенный вид, что во многом соответствует современному графическому дизайну, как HumanxAnthro.упомянул. Однако у меня есть некоторые сомнения в отношении двух значков с вопросительными знаками, которые выглядят так, как если бы это была статья на какую-то неопознанную тему. Более того, возможно, мы сможем получить некоторый переходный период, когда старая и новая версии могут отображаться бок о бок, например, внутри прямоугольного блока или чего-то подобного, чтобы старые и опытные редакторы могли привыкнуть к новым значкам. CX Zoom ( разговор ) 15:58, 13 мая 2021 (UTC)

Против (значки статей) [ править ]

• Где именно необходимость заменить текущие значки каким-то отвратительным дизайном Web Whatever.0? Как я столкнулся с таким количеством «ну, все в крошечной дискуссии о VPR поддержали это» в последнее время? Почему у нас есть уведомление в списке наблюдения для худших, наиболее перегретых над светом RfC, которые я видел в своей жизни, и при этом нет уведомлений в списке наблюдения для «люди хотят ограничить незначительные правки до 99,8625-го процентиля редакторов» или «люди имеют решили, что текущие качественные значки плохи по какой-то неясной причине, "которые влияют на написание энциклопедии?" Сколько из тринадцати человек, участвовавших в предыдущем обсуждении, активно участвуют в процессе обеспечения качества статьи? Ватицидальный пророк 22:27, 2 апреля 2021 г. (UTC)

  @ Vaticidalprophet : Предыдущее обсуждение широко рекламировалось везде, кроме CENT (в том числе на форумах по качеству статей). Я сочувствую, что натолкнулся на дискуссию, в которой я бы хотел участвовать после ее закрытия, но причина изменения значков была тщательно обсуждена и получила явную поддержку, и на этом этапе процесс перешел на следующий этап. Эта нить пытается выяснить , как изменить значки, не если мы должны изменить их. Пожалуйста, не пересматривайте заселенную местность; весь смысл предыдущего обсуждения состоял в том, чтобы разрешить эту часть. {{u | Sdkb }}  ^talk 23:04, 2 апреля 2021 г. (UTC)

  Пока что реакция на это предложение не звучит так, как «вопрос о том, менять значки или нет, был предметом споров, и все, кто мог быть заинтересован, решили, что существует проблема». (Есть немало заметно отсутствуют имена в этом разговоре - пинг @ SandyGeorgia , Элдджит , Гога мягкому , Wehwalt , Ian Rose , Casliber , бессвязные Люди , Epicgenius , Vami IV , Ли Виленский , JPxG , Johnbod и серийный номер 54129 какнебольшой набор людей, которых я мог бы ожидать, что они будут иметь мнение, и мне, вероятно, не хватает тонны имен.) Ватицидальный пророк 23:12, 2 апреля 2021 г. (UTC)

  Никогда не видел обсуждения, и теперь, когда я его увидел, не вижу в нем какого-либо широкого консенсуса. Люди, если вы хотите и дальше возиться с процессами проверки контента, по крайней мере, уведомите их. Это заставить работать. Итак, пока я здесь, возражайте против идеи, что любые изменения необходимы или полезны. Сэнди Джорджия ( Обсуждение ) 23:38, 2 апреля 2021 (UTC)

  И я тоже, и слегка встревожился, обнаружив себя на «выборе людей, которые, как я мог бы ожидать, иметь мнение»! Кажется, я прибыл сюда как раз вовремя, чтобы увидеть, как корма корабля тонет в волнах, поэтому я просто скажу, что на первый взгляд предложение показалось мне неубедительным. Как говорит ниже Мартин Поултер, основная проблема с нашими иконками заключается в том, что большинство читателей не знают, что они у нас есть, и не понимают их. Не вижу, как это меняет. Джонбод ( разговор ) 03:05, 3 апреля 2021 (UTC)

• При всем уважении, это похоже на решение в поисках проблемы. Поскольку прямо сейчас читатели видят золотую звезду или зеленый значок в правом верхнем углу статьи и знают, что это означает, что статья прошла какое-то рецензирование (которое, как я не знаю, является эталоном для многих, не относящихся к Википедии). пользователи используют, к лучшему или худшему, для оценки правдивости статьи), я не понимаю, почему мы хотели бы изменить это ради наших собственных дизайнерских предпочтений. Незначительные косметические изменения, которые сохраняют базовую золотую звезду и зеленый значок для классов FA / GA, - это нормально, но я категорически против изменения зеленого значка на что-то совершенно другого цвета. Вперед, Фиттинс ! 22:34, 2 апреля 2021 г. (UTC)
• Считая эти изменения ненужными, я считаю, что символы не более четкие, чем текущие, а в случае хороших статей - значительно менее четкие, а также визуально непривлекательные. Nosebagbear ( разговор ) 22:48, 2 апреля 2021 (UTC)
• Не думаю, что нужно менять значки A – Disambig. Просто хочу отметить, что с переходом на плоский, как насчет других 10 значков, которые останутся с тенью / 3d, ничего похожего на несогласованность. Вероятно, будет сложнее различить заглушку / начало, поскольку значки такие маленькие. Я не возражаю против FA / GA, но я не поддерживаю замену уже приемлемых значков. Terasail [ ✉ ] 22:51, 2 апреля 2021 г. (UTC)
  • Хотя процесс заключался в том, что если мы действительно придем к консенсусу в отношении значков FC / GA, то другие значки (A - dab, остальные 10, о которых вы говорите) будут / должны быть изменены для единообразия. Нет причин, по которым мы не могли сохранить значки запуска / заглушки в том виде, в каком они выглядят сейчас, только без стилизации тени. Pbrks ( обсуждение ) 23:19, 2 апреля 2021 (UTC)
• Идея, что иконки нужно изменить вообще, была слабой или отсутствовала (я никогда не видел этого обсуждения), и здесь есть все те же проблемы, о которых я упоминал в другом обсуждении в Википедии: Деревенский насос (предложения) / Архив 174, который былошироко присутствовали. В значительной степени, изменения не нужны, пожалуйста, напишите и просмотрите несколько статей, люди; еще лучше, пожалуйста, инициируйте крайне необходимую очистку GA. На первый взгляд кажется, что предлагаемые значки затемняют тот факт, что никакой другой процесс проверки контента, кроме FAC, не является процессом в масштабе всего сообщества, а скорее является мнением одного человека за один раз, редко пересматривается повторно и стремится поднять GA до того же уровня. самолет как FA, понизив бронзовую звезду до золотой чего-то такого же, как у GA. Вводящие в заблуждение. Другие, опередившие меня, в этом и обоих обсуждениях, объяснили проблемы. Или, как однажды сказал Джонбод, «Противостоять противникам». Сэнди Джорджия ( Обсуждение ) 23:28, 2 апреля 2021 (UTC)
  • SandyGeorgia , «иди, напиши и просмотри несколько статей» как личное распоряжение абсолютно неприемлемо. Людям разрешено и следует поощрять их к конструктивному редактированию Википедии, как им нравится. Если это писать статьи, отлично. Если это антивандальная работа, отлично. И если это попытка улучшить значки, которые мы используем, отлично. Будьте добры и проявите немного уважения. Эд  ^{[разговор]  [величественный титан]} 14:14, 13 апреля 2021 года (UTC)
• Я думаю, что предлагаемые логотипы не только менее четкие (серый вопросительный знак в кружке означает «Хороший кандидат на статью» - правда?), Но и слишком детские и менее привлекательные. - Гозей ( разговорное ) 23:36, 2 апреля 2021 г. (UTC)
• Простите. Уважайте приложенные вами усилия; Я понимаю, что с дизайном сложно ... но мне не нравятся новые иконки, особенно для FA. Он общий и при малых масштабах уходит на второй план. Я не думаю, что между звездой и границей достаточно отступов. Я мог бы поддержать изменение значка GA, но не уверен, что это правильный вариант. Непонятно, что мне сообщают значки заглушки и запуска. В остальных изменениях все в порядке, но незначительно. -  The  Earwig  ( разговор ) 23:37, 2 апреля 2021 г. (UTC)
• Я не знаю об этом. Я согласен с тем, что в целом значки, используемые в Википедии, могут выиграть от какого-то всестороннего обзора. Например, тот факт, что в словах «хорошая статья» и «голосование за поддержку» используется один и тот же имидж, - это в корне фигня. Кто решил, что это хорошая идея? Различия между «кандидатом в FA», «бывшим FA» и «бывшим кандидатом FA» также причудливы и не интуитивно понятны (для тех, кто не является хардкорным редактором Википедии, все они выглядят как случайно раненые морские звезды). Причем шкала качества идет пурпурный, темно-зеленый, красный, оранжевый, желтый, зеленый, синий, зеленый, желтый. Хотя я согласен с тем, что необходимо внести некоторые изменения (и должен быть огромный WP, проверяющий список наблюдения :CENT с несколькими предложениями по схемам значков), я не думаю, что это нужнообновление , и это, в частности, не вызывает у меня радости. Примечательно, что «серебро», используемое для обозначения GA ... оно не выглядит серебристым, оно выглядит серым. Кроме того, он удаляет некоторые хорошие вещи: прямо сейчас зазубренный значок бывшего GA очень четко показывает, что это был GA, а затем был «сломан», тогда как маленькая пунктирная звездочка ничего не показывает. jp × g 23:59, 2 апреля 2021 г. (UTC)
• Я не думаю, что предлагаемые иконки улучшают эстетику текущих, но есть и более серьезные проблемы. Использование вопросительного знака слишком тесно связано с DYK, и его следует избегать в значках FA / GA, чтобы избежать путаницы. Более того, предлагаемые иконки FA и GA имеют абсолютно одинаковый геометрический дизайн и отличаются только цветом. ИМО, которая уже делает все предложение неприемлемым. Значительная часть наших читателей страдают дальтонизмом . Они столкнутся с большими трудностями при различении значков GA и FA, а некоторые просто не смогут этого сделать. Значки FA и GA должны четко отличаться друг от друга геометрически, и не нужно полагаться на цветовую схему, чтобы отличить их друг от друга. Nsk92 ( разговор ) 00:06, 3 апреля 2021 (UTC)
• Иконки мне нравятся, но я должен противиться изменению палитры GA на серый. Он не выделяется и не будет выделяться на белом фоне Википедии по умолчанию. Он должен оставаться зеленым. - ♠ Vami _IV † ♠ 00:17, 3 апреля 2021 г. (UTC)
• Комментарий Вот значок «переставляя шезлонги на Титанике »: . E Eng 03:26, 3 апреля 2021 (UTC) PS У кого-то календарь отключен. Это было на день позже для Первоапрельского.
• Противодействовать необходимости редизайна в целом, и особенно использованию серого цвета для обозначения GA. Эхолот Брюс 05:02, 3 апреля 2021 г. (UTC)
• Против . «Не сломан, не чини». Одна очевидная проблема с экстремальным антискевоморфизмом, который является нынешней модной модой в пользовательском интерфейсе (но который уже видит много отката и, вероятно, не продлится долго), заключается в том, что он не может визуально представлять золото и серебро, они просто получаются желто-серыми, поскольку добавление белых и темных бликов для имитации металлического блеска невозможно при антискевоморфном подходе. Серый цвет в дизайне пользовательского интерфейса означает «отключен, недоступен или неприменим». Итак, НЕИСПРАВНОСТЬ.  -  SMcCandlish ☏ ¢  😼  05:30, 3 апреля 2021 г. (UTC)
• Против : не вижу достаточно веской причины менять значки. Я думаю, что Nsk92 поднимает несколько очень хороших моментов по этому поводу. Aoba47 ( разговорное ) 06:20, 3 апреля 2021 (UTC)
• против - некоторые из отдельных логотипов не фантастичны, но предлагаемые значительно хуже. Я здесь не для того, чтобы сказать, что все, что у нас есть, идеально, но, может быть, нам стоит обновлять изображение за раз? Я согласен с тем, что разница между предыдущей избранной статьей и провалившимся избранным кандидатом немного странная, но тогда они обычно используются только в шаблонах, рядом с тем, где она права, что это означает. Я действительно думаю, что нам было бы полезно объяснить пользователям, что такое хорошая и популярная статья (когда я впервые зашел на сайт, я понял, что такое «заглушка» и «избранные», но не более того), но изменение дизайна логотипа меня не т помочь. С наилучшими пожеланиями, Ли Виленски ^{( обсуждение • вклад )} 07:26, 3 апреля 2021 г. (UTC)
• Против . Какой бы консенсус ни был достигнут в ходе предыдущего обсуждения, количество противоположных мнений здесь говорит о том, что он не очень сильный. Предыдущее обсуждение следовало разрекламировать лучше (например, в RFC или CENT). -  Finnusertop ( обсуждение ⋅ вклад ) 08:47, 3 апреля 2021 г. (UTC)
• Против . На самом деле старые мне нравятся больше (извините). Кас Либер ( Обсуждение · вклад ) 09:37, 3 апреля 2021 (UTC)
• Противопоставить - это вроде решение в поисках проблемы. Я не совсем уверен, что даст изменение значков. ƒirefly ( t · c ) 09:41, 3 апреля 2021 г. (UTC)
• Допустим, по крайней мере, на данный момент, я хочу увидеть фактические предлагаемые файлы изображений (см. Раздел обсуждения ниже) - похоже, у нас пока есть только изображение изображений? Кроме того, согласитесь, что значки в градациях серого не так полезны. - ^{Обсуждение} xaosflux 10:23, 3 апреля 2021 г. (UTC)
• Против . В принципе, я не против изменения иконок, хотя хотелось бы более полного обсуждения, но предлагаемые альтернативы ужасны. И я согласен с комментариями, что все это кажется решением в поисках проблемы; например, «слишком подробный значок FC, из-за которого он плохо отображается при малых размерах» - у меня он на 15 пикселей на моей странице пользователя, и мне он кажется прекрасным. Гог Мягкий ( разговорное ) 12:26, ​​3 апреля 2021 (UTC)
• Против . Я не думаю, что консенсус, достигнутый в этой октябрьской ветке 2020 года, будет очень сильным, судя по ответу здесь. Что касается фактически предлагаемых значков, серый цвет не означает «положительный» или «хороший», это обычно зеленый цвет. Вопросительный знак для помощи. Предлагаемые символы заглушки и стартового класса слишком похожи. Кстати, я не могу дождаться, когда эта текущая тенденция чрезмерного упрощения символов скоро исчезнет. RetiredDuke ( разговорное ) 13:20, 3 апреля 2021 (UTC)
• Противник (повторяется). Консенсуса из восьми недостаточно, чтобы изменить механизмы - пусть даже поверхностно - множества очень активных проектов. Независимо от того , пытается ли этот поток выяснить, как изменить значки, а не следует ли нам их менять , похоже, что вы теперь наслаждаетесь консенсусом, чтобы отменить консенсус. Земля, привет! - S Перс 13:30, 3 апреля 2021 (UTC)
• Противодействовать Нет необходимости в этом. Пол Август ☎ 16:22, 3 апреля 2021 (UTC)
• Против . Я не хотел писать здесь, но, поскольку он был снова открыт, я думаю, что напишу. Я не настроен против изменения значков, хотя я в равной степени не вижу в этом необходимости, поскольку я не нахожу ни одну из приведенных причин особенно убедительной (во многом по тем же причинам, что и другие) . Однако, если вы все еще чувствуете потребность в изменениях, определите, каковы ваши цели дизайна, поговорите с людьми из Wikipedia: WikiProject Accessibility и следуйте их советам о том, как сделать ваши идеалы совместимыми с передовой практикой. Только тогда стоит достать карандаши. Тридуульф ( разговор ) 17:46, 10 апреля 2021 (UTC)
• Слабый противник Я согласен с Тридуульфом, нет реальной необходимости пересматривать большинство из них. Однако, по моему скромному мнению, я думаю, что вы справедливо отметили, что значок статьи FA тратится зря, поскольку вы не можете видеть полные детали. Выскажу подробно свое мнение о том, что надо делать. Голубой тыквенный пирог ( разговор ) 18:07, 10 апреля 2021 (UTC)
• Предположим, что такое большое изменение должно произойти после хорошо разрекламированной дискуссии с участием большого количества редакторов. Это не способ вносить такие изменения, которые затрагивают всех. Также предлагаемые новые значки некрасивы. - Ita140188 ( разговорное ) 05:38, 13 апреля 2021 г. (UTC)
• Допустим, я счастлив, что иконки улучшились. Но я предпочитаю текущий набор предлагаемым новым. Система золотых звезд для FA и серебра для GA имеет смысл. Но наиболее распространенная иерархия - это золото, серебро, бронза, поэтому бронза и серебро могут сбить с толку. Ϣere Spiel Checkers 12:03, 15 апреля 2021 г. (UTC)
• Предположим, у меня нет проблем с текущими значками, но было бы хорошо, если бы они были изменены. Однако не только редакторы, которые тратили свое время на создание иконок, чтобы заменить их звездочками logomakr.com. Lettler ^{hello • вклад} 01:28, 22 апреля 2021 (UTC)
• Альтернативное предложение
  Я также склоняюсь к сохранению текущих значков. Однако я подготовил альтернативное предложение с помощью Microsoft Paint, так что это тоже можно принять во внимание. 𝟙𝟤𝟯𝟺𝐪𝑤𝒆𝓇𝟷𝟮𝟥𝟜𝓺𝔴𝕖𝖗𝟰 ( 𝗍𝗮𝘭𝙠 ) 21:54, 24 апреля 2021 (UTC)
  • Несомненно, графический дизайн - это ваша страсть . 👨x🐱 ( разговорное ) 20:12, 4 мая 2021 (UTC)
• Против. Извините, но предлагаемые значки не подходят. И спасибо за нужный смешок 1234qwer1234qwer4 . ;) ~ HAL 333 20:38, 28 апреля 2021 (UTC)
• Противодействуя всем предлагаемым проектам в WP: AINT , мы должны сосредоточиться на более серьезных проблемах. - Knowledgekid87 ( обсуждение ) 17:49, 29 апреля 2021 г. (UTC)
• Противодействовать предложенному набору значков по сравнению с текущим набором, но, возможно, поддержит другой улучшенный набор по сравнению с текущим набором. Если мой отзыв помогает, то это была моя неприязнь к серому цвету и то, как символы заглушки, начального класса и вопросительного знака заставили меня задуматься о том, что они должны были представлять, повлияли на мое решение. Huggums537 ( обсуждение ) 05:42, 1 мая 2021 (UTC) Из положительных моментов, мне нравятся все остальные из предложенного набора значков. Измените серый цвет на какой-нибудь другой цвет, подходящий для дальтоников, выберите другие символы, чтобы заменить вопросительный знак, и обозначить классы запуска / заглушки, и я на борту ... Huggums537 ( разговор ) 05:57, 1 мая 2021 (UTC) )

Обсуждение (значки статей) [ править ]

@ Pbrks : (или кто угодно) вы можете составить для них таблицу до и после - это было весьма полезно в аналогичном обсуждении значков. - xaosflux ^Talk 21:18, 2 апреля 2021 г. (UTC)

@ Xaosflux : Да, я скоро их сделаю. Pbrks ( разговор ) 21:26, 2 апреля 2021 (UTC)

@ Pbrks : есть ли у вас уже загруженные файлы, которые могут находиться в обычной таблице вместо изображения таблицы? - ^{Обсуждение} xaosflux, 23:45, 2 апреля 2021 г. (UTC)

• Я согласен с тем, что значки, которые мы используем, необходимо изменить и что они не имеют особого смысла для случайных пользователей сайта, что является потерей, потому что маркеры качества действительно важны для критического взаимодействия с Википедией. Когда я провожу обучение, это почти всегда совершенно новая информация для людей, в Википедии даже есть шкала качества. Мне нравятся «продвинутые» и «бывшие» иконы, поскольку «золотая звезда» и «серебряная звезда» кажутся визуальной метафорой, которую люди могут понять с раннего возраста во многих контекстах. Кнопки Featured могут иметь более глубокий оттенок, чтобы выделяться больше, но это не так уж и важно. При этом значки кандидатов с вопросительным знаком в кружке выглядят как значок «Справка» или «Информация».что пользователь щелкнет, чтобы получить справку по пользовательскому интерфейсу. Иконки бывшего кандидата с крестиком очень похожи на «Закрыть вкладку» или «Закрыть приложение» некоторых интерфейсов: кнопки, которые пользователь нажимает, чтобы что-то исчезло. Я могу видеть, что представляет собой значок списка, но он очень похож на гамбургер-меню, которое является очень распространенной функцией навигации на веб-сайтах, и это то, что пользователь щелкает, чтобы увидеть список предпочтений или опций. . Эти потенциальные недоразумения означают, что я не могу поддержать эту версию предложения, но я действительно думаю, что она идет в правильном направлении. Мартин Поултер ( разговор ) 21:26, 2 апреля 2021 (UTC)
• Звездные очертания для бывшего избранного / хорошего статуса очень тонкие - при небольших размерах я предполагаю, что это, по сути, просто пустые круги, что, по-видимому, не является намерением, верно? Я бы сделал их толще. Даже полная граница (но полая внутренняя часть) будет достаточно визуально отличаться от текущего / хорошего. В какой-то момент было бы неплохо поиграться с отдельными файлами изображений в песочнице, что нелегко сделать со всеми значками как одним изображением, хотя я понимаю, что массовая загрузка всех значков может быть немного утомительной. - Билорв ( разговор ) 21:31, 2 апреля 2021 г. (UTC)
• Мета-точка - следует ли преобразовать маркированные пункты в поддержку / противодействие в нумерованные списки для удобства чтения? Ватицидальный пророк 00:12, 3 апреля 2021 г. (UTC)
• Я не против того, чтобы люди создавали новые произведения искусства, позволяя редакторам редактировать в соответствии с их сильными сторонами. То, что что-то новое, не значит, что это плохо. Я не поклонник иконок «Пуск» и «Заглушка», может, захочется придумать там что-то другое. Я не вижу тонущих кораблей, переставляемых шезлонгов, и я, конечно , не стал бы оскорблять кого-то за то, что он предложил идею в качестве первоапрельской шутки. Возможно, просто для того, чтобы получить своего рода «социальный капитал» во имя юмора? Но, как говорится, ЫММВ. - Чед ( разговор ) 07:16, 11 апреля 2021 (UTC)

Сделать шаг назад [ править ]

• Я начал это предложение после того, как запрос о закрытии предыдущего предложения решил, что результат был достаточно очевиден при поддержке ... редакторы, заинтересованные в том, чтобы взяться за эту работу, имеют на это полномочия. и запрос был перенесен в мастерскую иллюстраций . Хорошо, что Предложение 1 не пользовалось большим уважением, но это всего лишь предложение - все можно изменить, стиль можно изменить. Тем не менее, получать комментарии об ужасном дизайне Web Whatever.0 и писать и рецензировать некоторые статьи немного разочаровывает и деморализует . Я не понимаю, почему люди не могут просто высказывать свое мнение, не злясь на это. Я понимаю, что человеческая природа - сопротивляться переменам, но факт остается фактом:ужасно отображается при 20px и в прошлом буквально сбивал с толку людей , так как он также использовался для символа «голоса поддержки». Более того, субиконы для них (особенно значок GA) не имеют особого смысла. Бывший значок FC имеет неприглядный, стилистически отличающийся от него символ «X». Значок переоценки - сломанный значок GA? Бывший значок GA совпадает с бывшим значком кандидата в GA ? Все три из вышеперечисленных одинаковы, за исключением цвета (в котором Nsk92 хорошо замечает дальтонизм)? Поверить в то, что ничего не нужно менять, мне не по силам. Я не вижу особых причин, чтобы продвигаться вперед с каким-либо другим предложением, учитывая предыдущие комментарии. Пбркс( разговор ) 05:31, 3 апреля 2021 (UTC)

  Единственный аргумент группы, который хоть как-то правдоподобен для меня, - это двусмысленность России, и даже к которой я отношусь скептически - единственный реальный контекст, который я когда-либо видел, чтобы обозначить голоса поддержки, это ... GAN, где это на самом деле имеет смысл. Действительно ли гипер-антискевоморфизм и редизайн, которые десять человек просили о лучшем решении, чем «переименование », или просто «у нас есть миллион символов голосов поддержки, некоторые будут пересекаться»? Мне также честно странно, что предыдущее предложение было закрыто как мандат, когда в нем не участвовали люди, активно участвующие в соответствующем процессе, многие из которых с тех пор выступили с сильной оппозицией. Ватицидальный пророк 06:17, 3 апреля 2021 г. (UTC)

  (Приложение: читатели, заинтересованные как комментарием «миллиона символов голосов поддержки», так и тем, почему попытка изменить стили дома в Википедии для значков - это огромная работа, и здесь указывается на неблагодарный / антиблагодарный .) Ватицидальный пророк 06:25, 3 апреля 2021 г. (UTC)

  Я участвовал в первом обсуждении и думаю, что принимаю активное участие в процессе GA / FA / FL. - Билорв ( разговор ) 22:08, 19 апреля 2021 (UTC)

  Я просто ответил на комментарий «иди, напиши и просмотри несколько статей». Как личное распоряжение это абсолютно неуместно. Люди могут (и должны!) Конструктивно редактировать Википедию, как им хочется. Эд  ^{[разговор]  [величественный титан]} 14:19, 13 апреля 2021 г. (UTC)

  Я ценю ваши усилия в дизайне, Pbrks , хотя я не поддерживаю это изменение. Грубость в этом разговоре по отношению к вам была особенно вопиющей и неприемлемой. - Билорв ( разговор ) 22:08, 19 апреля 2021 (UTC)

• Значки классов B, C, Start и Stub не нужно изменять, поскольку их значки не видны на странице статьи или обсуждения. Я действительно думаю, что хорошие статьи и избранные статьи - отличные вехи, которые необходимо выделить в статье. Мне нравятся Золотая звезда, Серебряная звезда, потому что они могут проиллюстрировать как читателям, так и редакторам, что они лучшие из лучших. Особенно с серебряной звездой вместо символа зеленого плюса может дать редакторам индикатор того, что это почти избранная статья (золотая звезда). Но воссозданные значки недостаточно выделяются, чтобы их заметили новые читатели или чтобы о них позаботились редакторы. Если значки будут изменены, они должны быть визуально привлекательными и что-то, что читатели / редакторы могут одобрить.

Я погуглил слова «Качество» и «Икона» и нашел много металлов с прикрепленными к ним лентами. У нас может быть золотой пазл для обозначения избранной статьи и серебряный пазл для обозначения хорошей статьи. В данный момент я просто проявляю творческий подход. Пока эти значки светятся и выделяются положительно, редакторы, возможно, еще больше поддержат это предложение. Пунктирная линия, образующая звезду, мне непонятна, а знак вопроса похож на значок DYK. Я думаю, что было бы проще использовать увеличительное стекло над текущими значками для представления пере / оценки. Текущие Red X и Broken GA (по моему скромному мнению) расстраивают и могут обескураживать. Красный крестик над указанной статьей и сломанный символ GA, на мой взгляд, не являются профессиональными значками и даже выглядят так, будто в них замешан гнев.Blue Pumpkin Pie ( разговорное ) 20:11, 10 апреля 2021 (UTC)

• Лично у меня есть несколько причин, чтобы поддержать это, и главная из них состоит в том, что это больше привлекает читателей . Конечно, многим википедистам наплевать на «минималистичный дизайн Web 3.0», но многие случайные читатели ожидают этого, особенно на таких часто посещаемых сайтах, как WP. EpicPupper ( разговор ) 04:41, 9 мая 2021 (UTC)

Лицензирование [ править ]

• В идеале любые новые значки должны быть лицензированы как CC0 или PD, чтобы значки использовались без ссылки, без необходимости ссылки для атрибуции. - WOSlinker ( разговор ) 09:01, 3 апреля 2021 г. (UTC)

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

Прискорбно, что конструктивная идея была сбита так быстро (меньше суток!) И по таким плохим причинам . Иногда полезно обсуждать новые идеи, даже если они не собираются немедленно решить неотложную проблему, мы можем обнаружить проблемы, которые ранний рефлекс WP: AINTBROKEтолпа не подумала. И, честно говоря, наш значок FA в разрешении (где читатели обычно его видят) выглядит так, как будто он был нарисован на обратной стороне салфетки с помощью маркера и оцифрован одним из тех старых ручных рулонных сканеров или уменьшился по сравнению с исходным размером. до 10 пикселей, а затем снова увеличил масштаб. Помещение этого испорченного значка в избранную статью делает статью менее хорошей. Я понимаю, что это то, к чему привыкли читатели и редакторы, но это не само по себе достаточно веская причина, чтобы сохранить это, и уж тем более не прекращать обсуждение этого по прошествии 18 часов. Просто звезда с простой рамкой того же цвета будет не столько отклонением от текущего значка, сколько запутывающим, и будет справедливым улучшением. Но я думаю, никто не хочет говорить об улучшении энциклопедии. Иванвекторs белка (^{деревья} / _орехи ) 19:22, 8 апреля 2021 г. (UTC)

Я согласен. Поскольку в конце упоминается СНЕГ, я также хочу указать на этот раздел эссе, в котором говорится: «Иногда может быть лучше выделить несколько дополнительных дней, даже если текущая дискуссия явно придерживается одного мнения, чтобы быть уверенным, что это действительно так. быть снежным комом и в качестве вежливости, чтобы быть уверенным, что не будет исключен значительный вклад, если он будет закрыт в ближайшее время ". В целом, мне нравятся предложенные дизайны для FA и GA (хотя согласен, что серый для хороших товаров - плохой выбор цвета). Они намного лучше читаются при небольшом размере, символически более четкие (отсутствие звездочки и вопросительного знака намного более интуитивно понятны, чем существующие символы), а стиль соответствует недавно переработанным значкам защиты, обеспечивая более унифицированный дизайн. Я надеюсь, что в следующий раз мы сможем более серьезно рассмотреть эти идеи. -ГВП · · ро · дез 23:29, 8 апреля 2021 (UTC)

Согласны, хотя предложение в его наиболее полной форме можно было бы рассматривать совсем близко, многие противники выразили сочувствие по поводу конкретных улучшений. Последняя представляет собой ценную информацию, которая могла бы дать исчерпывающую информацию для будущих обсуждений, но была остановлена ​​неестественным образом. Aza24 ( разговорное ) 23:34, 8 апреля 2021 (UTC)

Я не согласен - это конкретное предложение было правильно закрыто SNOW, потому что совершенно очевидно, что по нему никогда не будет достигнуто консенсус. Ничто не мешает вам или кому-либо еще вернуться на один-два шага и начать обсуждение для достижения широкого консенсуса в отношении необходимости изменений (чего еще не произошло). Если есть консенсус в отношении изменений, то следующим шагом будет отработка нескольких проектов, реализация результатов полученных отзывов, прежде чем представить небольшое количество хорошо разработанных предложений для принятия. Получение большего количества отзывов об этом предложении и напоминаний об отсутствии консенсуса в отношении необходимости изменений не поможет. Тридуульф ( разговор ) 17:12, 9 апреля 2021 (UTC)

Да, как ужасно для Википедии, что кто-то с идеей хотел поговорить об этом, но не получил сначала разрешения от Сообщества. Каким бесплодным, излишне бюрократическим местом это становится. Иванвекторская белка ( ^{деревья} / _орехи ) 12:55, 10 апреля 2021 (UTC)

• @ Ivanvector , Wugapodes и Thryduulf : повторно открывается по запросу . - The SandDoctor ^Talk 17:31, 10 апреля 2021 г. (UTC)
• Есть ли какие-либо доказательства того, что более чем незначительный процент наших читателей понимает текущие значки, и что кто-то еще поймет переработанные значки? В отсутствие этого это похоже на еще один надстраиваемый проект, который навязывает изменения ради изменений как читателям, так и редакторам, отвлекая людей от улучшения энциклопедии. Кажется, есть тема следовать советам самозваных экспертов как в программировании, так и в дизайне, но игнорировать людей, которые на самом деле создают эту энциклопедию. Фил Бриджер ( выступление ) 18:01, 10 апреля 2021 г. (UTC)

  1. Вы, наверное, правы, что только незначительный процент наших читателей понимает текущие значки. Я имею в виду, что есть причина, по которой один из файлов называется File: Symbol support vote.svg и обычно используется для поддержки / противодействия запросам разрешений / обсуждениям удаления (например, в мета / сообществе). Сомнительно, что это тщательно продуманный набор значков, который хорошо работает в связке с другими значками, а не просто вещи, сформированные независимо с течением времени. Следовательно, это то, что мы могли бы улучшить.
  2. Мне не нравятся недавние темы попыток создать что-то вроде «мы против них» (например, «создатели контента» против «администраторов / разработчиков программного обеспечения / дизайнеров / кого-то еще»). Здесь все пытаются добиться одного и того же - достойного бесплатного информационного ресурса. Некоторые люди лучше разбираются в разных вещах. Несомненно, люди, у которых за плечами 90 FA, отлично умеют писать контент и являются ценными участниками. Кроме того, без сомнения, люди, которые пишут ботов, которые экономят сотни / тысячи часов повторяющегося ручного труда, также являются ценными участниками. Точно так же те, у кого есть опыт в дизайне и пользовательских интерфейсах, с большей вероятностью знают, что делает хороший, интуитивно понятный макет. Нет причин думать, что те, кто обладает одним типом навыков, лучше, чем любой другой тип редактора, или что они более склонны к выполнению каждой задачи, чем другие.
  3. Я не думаю, что кто-то кого-то игнорирует. Pbrks сделал предложение, основанное на предыдущем RfC, и выше, похоже, пытается работать с людьми, чтобы выяснить проблемы и улучшить. Маловероятно, что это предложение - лучшее возможное решение, но его можно улучшить только с обратной связью, и если люди обсуждают свои проблемы, возможно, Pbrks (и / или другие) могут адаптировать значки на основе этого. Невозможно просто угадать, чего хотят люди. Но по крайней мере некоторые из представленных идей, такие как использование вопросительного знака для представления GAR / FAR (C), в целом являются хорошими идеями и более интуитивно понятными, чем текущие представления.

  ProcrastinatingReader ( разговор ) 19:00, 10 апреля 2021 (UTC)

  Мне не нравятся недавние темы попыток создать что-то вроде «мы против них». Я полностью с этим согласен. Предложение буквально ничего не требует от Фила (если только он не рисует вручную значок FA каждый раз, когда мы продвигаем статью), но почему-то он, кажется, глубоко обеспокоен бременем, которое это возложит на редакторов. Шутки в сторону? Просто скажите, что вам не нравится дизайн, и двигайтесь дальше, но не делайте вид, будто у вас есть право вето на то, как волонтеры решают проводить свое время. Если вы хотите выступить против «самозваных экспертов», подождите, пока вы не узнаете, кто пишет наш контент. - ГВП · · ро · дез 22:25, 10 апреля 2021 (UTC)

• Есть ли у фонда команда по удобству использования, которая поддерживает используемое нами программное обеспечение и может дать нам рекомендации по таким вопросам? ЭльКевбо ( разговор ) 21:38, 10 апреля 2021 (UTC)

  Есть команда дизайнеров , и они, кажется, неплохо работают (например, см. Макеты на mw: Оптимизированные информационные боксы ). Не знаю, как бы вы с ними связались. Может быть, задача Phabricator, но отставание по этим вопросам выглядит длинным ... Возможно, электронная почта или IRC? ProcrastinatingReader ( разговор ) 23:51, 10 апреля 2021 (UTC)

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

Одна вещь, которую я бы сказал, пока это находится в центре внимания, - это то, что для любого редактора, склонного к графике, было бы действительно полезно получить дополнительную помощь с этим. Википедия: Лаборатория графики / Мастерская иллюстраций # Хорошая статья и избранная статья, посвященная редизайну, лежала без дела в течение нескольких месяцев и еще не достигла того уровня заинтересованности, на который я бы надеялся. {{u | Sdkb }}  ^talk 23:00, 12 апреля 2021 г. (UTC)

Это должно быть повторно закрыто согласно WP: DEADHORSE , прошло уже месяц. - Knowledgekid87 ( разговор ) 01:53, 4 мая 2021 г. (UTC)

Объединение мест помощи [ править ]

Перемещено из Википедии: Village pump (policy)

AFAICS, у нас есть несколько пунктов первичной помощи по вопросам общего характера:

• РГ: Чайхана
• РГ: Служба поддержки
• Википедия: помощь редактора (неактивно)
• Википедия: Помощь редактора / Запросы

Я не знаю точно, в чем разница между Teahouse и Help Desk (в этом обсуждении MP другие редакторы подняли этот вопрос), возможно, первое считается полезным для новичков, а второе - для опытных редакторов? Хотя бегло просматривая Teahouse и HD, у меня не сложилось впечатления, что они действительно различаются с точки зрения задаваемых вопросов. Что еще более важно, я считаю, что Wikipedia: помощь редактора, вероятно, должна быть перенаправлена ​​куда-то, поскольку это место полностью неактивно и в основном восходит к периоду до 2011 года, а WP: EAR, вероятно, следует перенаправить либо в Чайный домик, либо в службу поддержки, поскольку это не так. Похоже, что у них нет никаких отличительных черт. ProcrastinatingReader ( говорить) 16:10, 20 апреля 2021 (UTC)

• Последние два в основном или полностью исторические AFAIK. Чайный домик для новейшего из нового. Служба поддержки, как правило, отвечает на более сложные вопросы, но не является нежелательной для людей, которые попадают туда, в отличие от THQ. G M G talk 16:13, 20 апреля 2021 г. (UTC)
• Вообще говоря, Чайхана предназначена для новых пользователей, незнакомых с Википедией, ее культурой и жаргоном, в то время как служба поддержки предназначена для людей, более знакомых с Википедией в целом. Нельзя сказать, что это срабатывает в 100% случаев, но в целом так оно и должно работать. В результате человек, отвечающий на вопрос в службе поддержки, будет чувствовать себя свободно, используя ярлыки, отсылая людей к техническим документам и используя wikijargon, чтобы отвечать на вопросы там; однако Чайхана должна исходить из того, что OP ничего об этом не знает, и стремится относиться к пользователям так, как если бы им нужно было держать их за руки в процессе, а респонденты должны принять тон в своем ответе, что они имеют дело с новичками в Википедии. кто бы не знал, как читать документ пространства имен Википедии, что такое diff,или что-нибудь изтермины «искусство», которые мы используем в повседневной беседе в Википедии, вообще означают. Нам нужны обе эти две службы поддержки, чтобы это различие оставалось доступным. EAR давно умирает, и я действительно шокирован, увидев, что с тех пор он не был отмечен как исторический. - Джейрон, 32 16:16, 20 апреля 2021 г. (UTC)
• Страница помощи редакторам сама по себе не является местом встречи, а местом, где можно найти конкретного желающего помощника. Я согласен с тем, что службы поддержки - хорошее место, где можно найти полезного редактора и наладить личную связь. isaacl ( разговор ) 16:54, 20 апреля 2021 (UTC)
• Я согласен, что последние два кажутся историческими. Что касается разницы между первыми двумя, я тоже задавался вопросом, когда работал с пользователем: Levivich / Help , который является моей прототипной попыткой объединить новые страницы справки для пользователей. Levivich  ^харасс / _гончая 17:25, 20 апреля 2021 (UTC)

• Есть ли у нас хорошее отображение входов в каждый из этих процессов, которые могут нуждаться в корректировке? - ^{Обсуждение} xaosflux, 19:08, 20 апреля 2021 г. (UTC)
• Я думаю, что наши помощники более чем способны определить, какой уровень помощи предоставить пользователям. Я думаю, что объединение службы поддержки и Чайхана могло бы стать полезным поворотом событий. Опытные пользователи не должны возражать, и новые пользователи будут меньше запутываться. У нас так много возможных страниц для новых пользователей, консолидация - ключ к доступности. Нам действительно нужно хорошенько подумать о том, как упростить привлечение новых пользователей. Кстати, называть это Чайным домом меня сбивает с толку. Хотелось бы, чтобы это называлось просто «службой поддержки», что говорит само за себя, но при этом в нем должны соблюдаться культурные нормы чайного домика. AdmiralEek ( разговор ) 23:29, 20 апреля 2021 (UTC)

  Кроме того, это рекламировалось на страницах обсуждения TH и HD. AdmiralEek ( разговор ) 23:33, 20 апреля 2021 (UTC)

• Планируется добавить еще несколько существенных комментариев позже, но люди могут захотеть взглянуть на Morgan, Jonathan T .; Халфакер, Аарон (22 августа 2018 г.). «Оценка влияния чайханы Википедии на социализацию и удержание новичков» . Материалы 14-го Международного симпозиума по открытому сотрудничеству : 1–7. DOI : 10.1145 / 3233391.3233544 .. В нем есть некоторые полезные эмпирические данные о том, чем занимается чайный домик, а также объяснение его целей в отличие от чайного домика. Вахурзпу ( разговорное ) 05:54, 21 апреля 2021 (UTC)
• Я поддерживаю разделение чайного домика и службы поддержки, поскольку у меня есть список поддержки и время от времени она вносит свой вклад, но мне было бы сложно следовать указаниям чайханы и объяснять каждый процесс Википедии своими словами, вместо того, чтобы ссылаться на процесс и отвечать на любые последующие вверх вопросы. В службе поддержки есть заметная ссылка на Чайный домик, а на странице чайного домика, вероятно, должна быть похожая ссылка на службу поддержки. Обе ссылки, вероятно, должны сопровождаться запросом на размещение запросов в одном месте, а не в обоих. Цвентон ( разговор ) 12:19, 21 апреля 2021 (UTC)
• Согласно Цвентону , чайный домик и службу поддержки обязательно должны быть разделены, и они предназначены для удовлетворения потребностей разных типов редакторов, даже если они часто частично совпадают. В WP: TH мы стремимся общаться на простом английском и дружелюбным тоном, предполагая, что у спрашивающего мало или совсем нет предварительных знаний. Как уже было сказано, WP: HD короче, лаконичнее и часто более технический по тону, как с точки зрения задаваемых вопросов, так и особенно с точки зрения предоставленных ответов. Приветствие новых редакторов и ответ на их вопросы в простой и дружелюбной манере в Чайном домике значительно усложняют взаимодействие с новичками, но, как было указано выше Вахурзпу , исследование Jmorgan (WMF)и коллега показал, что Чайхана вносит значительный вклад в удержание новых редакторов - и этого мы все хотим, не так ли? Он также продолжает обеспечивать испытательный стенд для исследования удержания редактора (см этого поста по Maximilianklein на WT: TH в январе 2020).
  Я отмечаю, что вопрос ProcrastinatingReader связан с частично согласованным обсуждением, которое они закрыли, согласившись добавить ссылку на Чайный домик на главной странице , и именно там действительно следует проводить различие между целевыми аудиториями, хотя точная формулировка требуется дополнительное внимание. Я, безусловно, был бы за добавление этой ссылки и за прояснение различных действующих мест. Конечно, если вопрос в WP: TH является слишком техническим для бедных чайхана Хосты , чтобы ответить также, мы иногда называем людей на, хотя это было бы наиболее часто быть WP: ВПТ - или WP: REFDESK для внедорожных темы из них . (Однако я бы хотел, чтобы WP: THу меня была лучшая система именования архивов, больше похожая на WP: HD, так как новичку было бы намного проще найти свою старую, заархивированную публикацию, когда они находятся в устаревшем формате.) Что касается любого предложения по объединению WP : TH / WP: HD , этот комментарий от Maineartists резюмирует это: «если он не сломан , зачем его ремонтировать?». Но что касается WP: Editor Assistance - да, это, вероятно, нужно отмечать как историческое, и я отмечаю, что Кудпунг предложил именно это еще в 2018 году. Но поскольку я никогда там не был (кто был?), Я не могу комментировать дальше от любого личного опыта о том, где было бы лучше всего перенаправить. Я предполагаю WP: THможет иметь наибольший смысл. Ник Мойес ( разговор ) 22:39, 21 апреля 2021 г. (UTC)
• Я согласен с откладывающим на потом читателем в том, что места оказания помощи должны быть объединены, и я согласен с тем, чтобы пометить форум помощи редакторам как исторический. Одна из вещей, которые новички чаще всего говорят о Википедии, - это то, что количество внутренних страниц слишком велико, поэтому плохо, что редакторы сталкиваются с потенциальной путаницей в том, где в первую очередь задать свой вопрос.
  Что касается обозначенной разницы между TH и HD, все в порядке, но ключевое слово предназначено . В настоящее время в HD попадает много новичков, и полагаться на них, чтобы они прочитали сноску и переключились в Чайный домик, если они хотят дружеского ответа, не работает. Нам нужно лучше указывать на TH, а не на HD во всех областях, с которыми сталкиваются новички, и сделать последнее гораздо более тихим местом, которое получает только неочевидные вопросы от авторитетных редакторов. {{u | Sdkb }}  ^talk 01:41, 23 апреля 2021 г. (UTC)
• Я был основным пользователем, отвечающим на WP: EAR в течение нескольких лет. Это было одно из основных мест оказания помощи до открытия Чайного домика. Мой первоначальный комментарий о закрытии EAR был на самом деле в 2013 году. Я удивлен, что никто не выступил с инициативой отказаться от него и закрыть все ссылки на него. Кудпунг กุด ผึ้ง ( разговор ) 05:12, 23 апреля 2021 (UTC)
• В волонтерской среде, я думаю, группы, заинтересованные в инициативе, должны иметь право решать, как ее организовать, при условии, что это не налагает чрезмерного бремени на других. В этом контексте я считаю, что следует изучить следующие вопросы относительно любого потенциального бремени:
  1. Насколько эффективно задают вопросы и отвечают ли они на них?
  2. Могут ли респонденты эффективно отвечать на вопросы?
• Что касается первого вопроса, разные типы заведений нравятся разным редакторам, поэтому может быть полезно использовать метафорическую обстановку чайханы, а также более сжатый формат вопросов и ответов. Что касается второго вопроса, как отмечали другие, разные респонденты могут быть заинтересованы в ответах на разных уровнях детализации. Эффективно ли наличие нескольких мест для поддержки этого, по сравнению с тем, что некоторым респондентам приходится контролировать несколько мест? В связи с обоими вопросами, если кто-то задает вопрос в одном месте, которое, исходя из уровня детализации, необходимого спрашивающему, лучше подходит для другого места, будет ли этот вопрос решен эффективно (по-прежнему отвечая на желаемом уровне, плавно переместить его в другое место или другими способами)?
• Короче говоря, я хотел бы услышать от людей на местах: мешает ли наличие двух площадок вашей способности получать адекватные ответы или адекватно отвечать на вопросы? Нужно ли нам иметь более широкий состав людей, наблюдающих за службой поддержки или чайным, чтобы иметь дело с разными ожиданиями по уровню детализации? Действительно ли устранение одного привлечет больше наблюдателей к другому? Я без особого энтузиазма говорю волонтерам, чтобы они перестали вносить свой вклад в продуктивную инициативу, даже если я думаю, что они также могут помочь другой продуктивной инициативе. isaacl ( разговор ) 19:46, 24 апреля 2021 (UTC)
• Иногда я захожу и в чайный дом, и в службу поддержки, и даже отвечаю на вопросы. Я бы тоже не назвал себя очень опытным. Я действительно вижу много совпадений (но также и большую разницу). Если кто-то задает вопрос новичку в HD, лучше ответить ему на месте, чем попросить его пойти и снова спросить в Чайхане. И наоборот, более содержательные вопросы в Teahouse помогают нарушить монотонность. Если бы мы действительно хотели сохранить четкое разделение, а не намерение, то мы могли бы перенести обсуждения с одного форума на другой, точно так же, как это обсуждение было перемещено с VPP на VPR. Но перемещение потоков на MediaWiki немного сложнее, чем на некоторых других дискуссионных платформах. Я действительно думаю, что мы немного резковаты с людьми, которые задают вопрос в обоих местах:наличие двух форумов потенциально сбивает с толку, а просьба о помощи более чем в одном месте - это не то же самое, что поиск на форумах в DR – AN – ANI.
  И HD, и TH ограничены большим объемом и быстрым архивированием, особенно Teahouse. Я вспоминаю одного нового редактора, который был очень рассержен тем, что Чайный домик представлен как место для дружеской беседы, но на практике это в основном оперативная лента вопросов и ответов. Если бы мы были меньшим сообществом, мы могли бы все болтать в Le Bistro или Beerhall, а не разделять его на несколько бункеров (VP * - хороший пример). Это подводит нас к практическому ограничению. Их объединение обострит ситуацию большим количеством вопросов. И еще есть природа вопросов: объединенная площадка справки может быть перегружена повторяющимися словами «как я делаю новую статью для незначительной вещи?», «Моя вещь не отображается в Google» и «почему AFC так длинный?".
  Говоря о практических, а не предполагаемых различиях, большая разница между Teahouse и Help Desk - это точки входа. Новые пользователи часто получают большое приветственное сообщение, направляющее их в TH.

IIRC, даже некоторые из наших шаблонов предупреждений первого уровня направляют их туда.
-  Pelagic (  сообщения  ) - (12:45 вс 25, AEDT) 01:45, 25 апреля 2021 (UTC)

• Для тех, кому интересно, в чем разница между EA / EAR и Teahouse / Help Desk; Если вы внимательно посмотрите, то заметите, что многие запросы EAR связаны со спорами / контентом, и я думаю, что Чайхана / Служба поддержки либо не занимается, либо не способствует тому, что они в основном продвигаются как форумы вопросов и ответов. Другие вещи, которые активно продвигаются в EA / EAR, но не в Teahouse, - это возможность напрямую связаться со списком полезных редакторов и сделать запросы на редактирование. Хотя эти функции могут быть технически возможны в Чайном доме, они не продвигаются каким-либо образом, который делает их функционально полезными, как в EA / EAR. Huggums537 ( разговорное ) 16:03, 1 мая 2021 (UTC)
• Комментарий . В последнее время я активно отвечаю на запросы в WP: EAR. Мне он нравится, потому что там мало трафика, но не совсем бездействующий. Я могу держать его в своем списке наблюдения, не увеличивая его количество до 100+ редакций в день, и у меня есть неплохие шансы ответить (до того, как кто-то другой даст хороший ответ, и мне не нужно будет отвечать). - Novem Linguae ( разговорное ) 23:19, 1 мая 2021 г. (UTC)

Предложение: исключить WP: EA / WP: EAR и закрыть все активные шаблоны или справочные страницы, ссылающиеся на него [ изменить ]

• Поддержка Нет смысла направлять новичков на неактивное место. Страницы также нужно пометить как «исторические». Pinging ProcrastinatingReader как OP. Ник Мойес ( разговор ) 23:10, 23 апреля 2021 (UTC)
  • Ник Мойес , откуда вы взяли, что это неактивное место? Самый старый запрос был 16-го, а самый новый - 30-го. Huggums537 ( разговор ) 14:32, 1 мая 2021 (UTC)

    @ Huggums537 : Вот цифры:

    • Редактирование Teahouse 2020: 31,653
    • Чайхана 2021 редакций: 18,347
    • Help Desk 2020 изменений: 25016
    • Справочная служба 2021, редакции: 9039
    • Ухо / Просьбы 2020: 1,121
    • Ухо / Просьбы 2021: 434

    Надеюсь, это поможет, Ник Мойес ( разговор ) 23:39, 1 мая 2021 г. (UTC)

    Да, это действительно помогает, потому что я вижу, что тег «неактивный» был неправильно отнесен к форуму, который на самом деле просто «менее активен», искажение, на которое я бы не был так обижен, если бы он был правильно представлен как «почти» или «почти» неактивен. Huggums537 ( разговорное ) 10:57, 2 мая 2021 (UTC)

    Хорошо, Ник Мойес , приношу извинения за то, что вы твердили о «неактивном» бите тега. После дальнейшего расследования кажется, что идея возникла из исходного сообщения ProcrastinatingReader, который сказал, что место проведения было « полностью неактивным », что привело других, таких как GreenMeansGo , Levivich и Sdkb, к выводу, что это место имело «исторический» характер. ОткладываниеЧитательне могли бы вы объяснить, почему вы назвали это место «полностью бездействующим»? Я добросовестно предполагаю, что вы ссылались на страницу регистрации EA, а не на страницу проекта EAR, и не собирались никого вводить в заблуждение. Я также согласен, что страница не очень активна. Тем не менее, я думаю, что она очень похожа на страницу регистрации многих других проектов и не предназначена для того, чтобы быть настолько активной, поскольку единственная реальная цель состоит в том, чтобы люди подписались на проект. Многие из этих страниц регистрации проектов на самом деле не так активны. Вряд ли это повод ставить какой-либо проект в «историческое» состояние или называть его полностью неактивным, когда редактор подписался на проект всего полтора месяца назад . Huggums537 ( разговор ) 12:31, 2 мая 2021 (UTC)

    Утверждение довольно ясное: что еще более важно, я считаю, что помощь редактора Wikipedia: вероятно, должна быть перенаправлена ​​куда-то, поскольку это место полностью неактивно и в основном восходит к периоду до 2011 года, а WP: EAR, вероятно, следует перенаправить либо в Чайный домик, либо в справочная служба, поскольку она, похоже, не имеет никаких отличительных черт. Он не говорит то, что вы думаете, он говорит. Последние 5 регистраций относятся к 2018 году, а последние 10 относятся к 2012 году, почти десять лет назад. Это «совершенно неактивно». ProcrastinatingReader ( разговор ) 13:16, 2 мая 2021 (UTC)

    @ Huggums537 : Хотя они, возможно, и не совсем мертвы, все же, вероятно, нужно провести некоторые расчеты, чтобы понять, не вводим ли мы в заблуждение новых редакторов из-за ненужного дублирования форумов, которые имеют очень мало изменений по объему. Как уже говорилось, для TH и HD существует неперекрывающаяся область. Во многом это связано с такими усилиями, как HostBot, которые специально нацелены на новых пользователей.

    Но мы не делаем себе одолжений, если у нас столько избыточности, что «где мне задать свой вопрос» становится чьим-то первым вопросом. В качестве альтернативы, если у вас есть ссылки на форумы помощи повсюду, и новый пользователь, который не знает, как использовать свою историю вкладов, и не может найти вопрос после того, как он его задает. G M G talk 16:05, 2 мая 2021 г. (UTC)

    Я согласен, что потребуется больше вычислений, потому что я очень серьезно сомневаюсь, что мы столкнемся с какими-либо проблемами «где мне задать свой вопрос». Это иррациональный аргумент , основанный на страхе, который не имеет реальной основы, поскольку статус-кво еще не породил сколько-нибудь значительного количества таких проблем, о которых я знаю. Нет никаких оснований ожидать, что оставление без изменений EA / EAR и TH / HD приведет к таким изменениям. Однако удаление EAR удаляет параметры, доступные пользователю, которые недоступны на других справочных форумах, такие как возможность делать определенные запросы на обсуждение / содержание / редактирование. Это очень полезно для тех, кого не интересует столь мерзкое место, как арахисовая галерея . Я недавно открыл для себя радостьВикипедия: запросы на разрешение споров, и я счел чрезвычайно полезным иметь доступные варианты разрешения споров, чтобы я мог найти более удобный и подходящий способ разрешения спора. Больше вариантов лучше. См. Мой аргумент о ванной ниже. Huggums537 ( разговорное ) 16:47, 2 мая 2021 (UTC)

    У нас есть много досок объявлений по конкретным проблемам и мест для общих вопросов. Излишнее разделение беседы снижает хорошие результаты как с точки зрения ответов на заданный вопрос, так и с точки зрения замешательства собеседника. Есть законный аргумент, что слияние HD + TH приведет к тому, что громкость будет настолько высокой, что слияние будет контрпродуктивным (следовательно, это не было предложено). То же самое не относится к EAR. У нас есть площадки {{ edit request }} и WP: DR, такие как WP: DRN и WP: 3O . Если EAR дублирует работу 4 разных систем и делает это не лучшим образом, то это абсолютно непродуктивное мероприятие. ProcrastinatingReader ( talk ) 17:11, 2 мая 2021 (UTC)

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

    И не только потому, что они будут продуктивны где-то еще, а потому, что слишком сложная система отпугивает новых добровольцев. Существует предубеждение в отношении выживания в том, кто действительно успевает опубликовать вопрос, и многие редакторы пугаются, просто сталкиваясь с множеством мест, где можно задать вопрос. Хотя мы хотели бы, чтобы они проявили смелость и выбрали что-то одно, многие люди боятся сделать неправильный выбор и на них орут, поэтому они просто не публикуют сообщения. Дублирование работы может быть вредным, и если рабочие процессы волонтеров вредит усилиям по привлечению большего количества добровольцев, тогда да, я думаю, мы должны попросить их изучить новый рабочий процесс. - ГВП · · ро · дез 6:54, 3 мая 2021 (UTC)

    Вугаподес , где ваши данные или какие-либо доказательства, позволяющие предположить, что в текущих процессах был нанесен какой-либо такой вред? Я устаю от этих основанных на страхе аргументов, распространяющихся в Википедии без каких-либо рациональных доказательств, подтверждающих их. Это предложение, по сути, требует, чтобы мы вторглись в группу, счастливо ведущую бизнес, и заставили их собирать вещи, чтобы вести дела в местах, которые они, возможно, не хотят, и способами, которые не совсем те, к которым они привыкли, потому что мы думаем, что знаем лучше или нам не нравится то, что они делают, и все во имя меньшей активности. Это имеет такой же смысл, как и размещение в комнате для гостей, чтобы никто не мог ею пользоваться, потому что она в любом случае не используется. Huggums537 ( обсуждение) 11:27, 3 мая 2021 г. (UTC) Кроме того, ваш аргумент предполагает, что мы должны повесить над дверью комнаты для гостей табличку с надписью: «Вредно! Не входить!» На самом деле это довольно комично. Все эти разговоры о «дублировании» работы, как будто мы каким-то образом собираемся приумножать вещи, просто оставляя их такими, какими они были, к счастью, действительно абсурдны. Логический менталитет, изложенный в Википедии, вводит меня в заблуждение. Huggums537 ( разговорное ) 11:48, 3 мая 2021 (UTC)

    Если есть проблема с производительностью одной или нескольких справочных систем с точки зрения спрашивающих или отвечающих, то, безусловно, нам следует изучить средства для улучшения ситуации. Однако я видел здесь только теоретические примеры, поэтому я думаю, что мы должны поговорить с участниками о различных инициативах, узнать, что они думают, и дать им широкую свободу действий, чтобы решить, какие режимы работы им подходят. Что касается криков, я думаю, что идеальное решение - не кричать на кого-либо и заранее заверить вас в том, что независимо от того, где кто-то просит о помощи, запрос будет адресован тем, кто может помочь. Этот несовершенный мир может означать перемещение запроса в более специализированное место (например, в техническую деревенскую помпу для вопросов, связанных с реализацией MediaWiki,доска объявлений о надежных источниках для вопросов о соответствующих источниках и т. д.), что, на мой взгляд, выполнимо.isaacl ( разговор ) 20:13, 3 мая 2021 (UTC)

    Я согласен. Ссылаясь на приведенную выше аналогию с гостевой комнатой, мы должны учитывать, что в этом случае гостевая комната в настоящее время фактически занята. Я думаю, что было бы гораздо правильнее узнать мнение самих гостей о том, насколько вредна, по их мнению, комната для гостей, чем внезапно выбросить их всех под тем предлогом, что мы * думаем *, что это может быть вредно, а затем пытаться оправдайте это, сказав, что он все равно мало использовался, так что вставьте его, и мы поставим на него знак «Опасно», чтобы почувствовать себя лучше. Huggums537 ( разговор ) 07:08, 4 мая 2021 (UTC)

    Если на запросы о помощи все еще поступают надлежащие ответы, место проведения по-прежнему активно. isaacl ( разговор ) 17:18, 2 мая 2021 (UTC)

    Согласитесь с утверждениями Исаакла . Huggums537 ( разговорное ) 17:41, 2 мая 2021 (UTC)

    Наверное, это было бы невозможно узнать. Я предполагаю, что мы могли бы посмотреть на страницы обсуждения пользователей перечисленных там редакторов, чтобы задать любые вопросы, но было бы невозможно узнать WP: EA , откуда они пришли. Учитывая ~ 150 просмотров страниц в месяц, я не оптимистичен. В любом случае формат IMO архаичен и уступает более новым системам. ProcrastinatingReader ( разговор ) 17:43, 2 мая 2021 (UTC)

    Что ж, на странице запроса есть запросы, для которых вы можете увидеть ответы и время отклика. Если вы думаете о прямом контакте с помощниками, лично я бы не назвал это второстепенным механизмом: индивидуальная помощь может быть эффективной. В любом случае, я не думаю, что нужно навязывать отключение. Не стесняйтесь побеседовать с вовлеченными редакторами и прийти к единому мнению, что ответы на вопросы в службе поддержки будут по сути эквивалентны. isaacl ( разговор ) 18:45, 2 мая 2021 (UTC)

• Поддержка в комментариях в разделе выше. {{u | Sdkb }}  ^talk 23:29, 23 апреля 2021 г. (UTC)
• Поддержка - Ditto Levivich  ^харасс / _гончая 00:46, 24 апреля 2021 (UTC)
• Поддержка - очень разумное и надежное предложение, которое, надеюсь, поможет решить наши проблемы. Aza24 ( разговор ) 01:37, 24 апреля 2021 (UTC)
• Поддержка по Aza24. ProcrastinatingReader ( разговор ) 07:46, 24 апреля 2021 (UTC)
• Поддержка за Ника Мойеса. EpicPupper 23:21, 24 апреля 2021 г. (UTC)
• Поддержка Если мы ничего не пропустили, это кажется очевидным. ЭльКевбо ( разговор ) 02:56, 25 апреля 2021 (UTC)
• Имеет смысл. ~ HAL 333 20:36, 28 апреля 2021 г. (UTC)
• Против, потому что это кажется мне полезным местом встречи, и я не понимаю, почему кто-то думает, что это место неактивно, поскольку в настоящее время существует 15 открытых запросов. Я также не понимаю, почему было сделано уведомление об этом обсуждении на страницах обсуждения в чайном домике и службе поддержки, но не на двух других, поэтому я сделаю это сейчас. Huggums537 ( разговор ) 14:32, 1 мая 2021 (UTC)
• Поддержка могла быть полезной исторически, но теперь кажется ненужным дублированием службы поддержки. - Tera tix ₵ 14:38, 1 мая 2021 г. (UTC)
  • За исключением того, что служба поддержки не предлагает разрешение споров и не принимает запросы на редактирование, как это делает EAR, хотя они могут сделать это по запросу, но это не предлагается в качестве стандартной функции, поэтому на самом деле это не дубликат. Huggums537 ( разговорное ) 10:57, 2 мая 2021 (UTC)
    • Есть много других форумов, которые предлагают разрешение споров (как по содержанию, так и по вопросам поведения ). Я не совсем понимаю, что вы имеете в виду, говоря «принимать запросы на редактирование », поскольку они публикуются на страницах обсуждения статей. Если вы намереваетесь передать общий смысл выражения «помощь в реализации предлагаемого редактирования» - с этим уже легко справится служба поддержки ( пример из сегодняшнего дня ). - Tera tix ₵ 01:23, 4 мая 2021 г. (UTC)
      • Teratix , дело не в этом. Вы сказали, что EAR является «дублированием» службы поддержки, и это не потому, что EAR занимается спорами, а служба поддержки - нет. Чайхана тоже. Поэтому представление о том, что EAR является «дублированием», является неверной оценкой. Huggums537 ( разговорное ) 05:58, 4 мая 2021 (UTC)
        • EAR, похоже, не «спорит»; одна из первых инструкций потенциальным отправителям запросов заключается в том, что дискуссии, связанные со спорами по содержанию, лучше рассматривать на доске объявлений о разрешении споров . Но даже если EAR действительно разрешать споры, я бы просто обновить свою оценку от «EAR дублирует функцию Help Desk» на что - то вроде «EAR дублирует функцию Help Desk и DRN». На мой основной аргумент это не повлияет. - Tera tix ₵ 09:38, 4 мая 2021 г. (UTC)
          • За исключением того, что мы не обсуждаем слияние DRN, мы обсуждаем слияние справочных форумов. Итак, я думаю, что это неуместная часть вашего основного аргумента. Кроме того, просто посмотрите на некоторые истории запросов, и вы легко увидите, что они ДЕЙСТВИТЕЛЬНО обрабатывают споры. Huggums537 ( разговорное ) 14:56, 4 мая 2021 (UTC)
            • Я не возражаю против обсуждения, но если вы неточно представляете мои взгляды, вы не добьетесь никакого прогресса в том, чтобы изменить мое мнение. Мы не обсуждаем слияние DRN . Я никогда не говорил, что DRN следует объединить. Вы можете легко увидеть, что они ДЕЙСТВИТЕЛЬНО разбирают споры . Я ясно объяснил, что вопрос о том, разрешает ли EAR споры, не имеет отношения к моему основному аргументу - EAR дублирует функции других форумов Википедии. Ни один из ваших трех ответов не касался этого вопроса. - Tera tix ₵ 02:13, 5 мая 2021 г. (UTC)
              • Я пытался ответить на этот вопрос, но вы не принимаете его, или я недостаточно хорошо его объясняю. EAR предлагает услуги , что чайхана и Help Desk не делают , например, также нашли в DRN и другие форумы. Поскольку мы сравниваем и обсуждаем слияние справочных форумовсравнивать услуги EAR с другими справочными форумами неверно и ложно, поэтому также неверно говорить, что EAR является «дубликатом» других справочных форумов. Нет. Это уникально. Он заимствован из нескольких форумов. Точно так же вы никогда не станете утверждать, что EAR является «дубликатом» DRN, поскольку он предлагает другие услуги, отличные от DRN, например запросы помощи. DRN - это строго разрешение споров, поэтому это было бы несправедливое сравнение, а не «дубликат». То, что что-то имеет похожие качества, не делает его «дублирующим». Я не думаю, что люди понимают, что такое «дубликат», или они слишком вольно используют этот термин. Любой из этих вариантов будет в равной степени неоптимальным. Вкратце, я думаю, что "дублирование"аргумент (справки или любого другого форума Википедии) о EAR неверен. Хаггумс537( разговор ) 03:46, 5 мая 2021 (UTC)

                Еще раз, вы не совсем точно представляете мои взгляды. Я не утверждаю, что EAR является точной копией определенного альтернативного форума, я утверждаю, что он дублирует функции других форумов . Также неверно говорить, что EAR является «дубликатом» других справочных форумов. Нет. Это уникально. Он заимствован из нескольких форумов. Да, это моя точка зрения; у него нет функций, которые нигде не выполнялись бы! На данный момент вы аргументировали свою точку зрения примерно в 20 комментариях и ответах другим редакторам, но не продвинулись вперед. На мой взгляд, это почти что затрудняет процесс . Возможно, пора отказаться от обсуждения. - Tera tix ₵ 09:15, 5 мая 2021 г. (UTC)

                Я рад, что мы наконец смогли докопаться до сути вашей точки зрения. Если бы вы сказали это только в начале, вместо того, чтобы утверждать, что это дубликат службы поддержки, это избавило бы нас от многих дискуссий, чтобы перейти к вашей точке зрения. Однако есть большая разница между длительным обсуждением, чтобы добраться до вашей точки зрения, и «забиванием процесса». Это очень плохая форма - обвинять других редакторов в разрушительном редактировании из-за того, что вы сами не в состоянии должным образом объяснить свою точку зрения. Любые другие комментарии, которые я делал где-то еще, касались только тех конкретных мест, где я чувствовал, что необходим ответ, чтобы обосновать необходимость сохранения EAR. Во всяком случае, я все равно считаю, что ваша точка зрения неверна, потому что[игнорируя это] EAR на самом деле выполняет функцию, которая не выполняется где-либо еще, в силу того факта, что это единственный справочный форум, который также разрешает споры и другие запросы. Сам факт, что он «дублирует функции других форумов», свидетельствует о том, что это форум, который выполняет функцию так, как никакой другой форум. На этом я перестану здесь комментировать, прежде чем кто-либо решит выдвинуть какие-либо дикие недобросовестные обвинения. Huggums537 ( обсуждение ) 13:30, 5 мая 2021 г. (UTC) Другими словами, EAR - единственный известный мне форум, который выполняет функцию объединения этих других сервисов. Huggums537 ( разговорное ) 15:41, 5 мая 2021 (UTC)

                Я предлагаю не зацикливаться на семантике и придерживаться целостного взгляда. Необязательно обозначать инициативу помощи редакторам как справочный форум, и не обязательно рассматривать только другие места, помеченные как справочные форумы, как потенциальную замену. (Если бы все, участвующие в проекте помощи редакторам, были счастливы перенести свою деятельность, например, в другие области, я не думаю, что это имеет значение, если все эти области являются справочными форумами.) Isaacl ( обсуждение ) 04:46, 5 мая 2021 г. ( УНИВЕРСАЛЬНОЕ ГЛОБАЛЬНОЕ ВРЕМЯ)

                Исаакл , ну да, если бы они были счастливы перейти на другие форумы, они бы просто выбрали то, что они предпочитают, либо DRN или Teahouse, но если им нравятся оба, тогда мы бы разделили их интересы на несколько площадок и создали очень проблема, которую пользователь IP 192.76.8.91 сказал, что мы будем решать. Huggums537 ( разговор ) 05:22, 5 мая 2021 (UTC)

                Что ж, вы уже аргументировали преимущества наличия нескольких площадок, в которых редакторы могут получить помощь. Обратите внимание, что мне не нужно пинговать меня в это обсуждение. isaacl ( разговор ) 05:31, 5 мая 2021 (UTC)

                Да, я настаиваю на том, чтобы было больше вариантов и возможностей. Я думаю, что EAR предлагает это уникальным способом, которого нет у других. Он может сделать больше, чем справочные форумы, и он не так ужасен, как ANI. Однако вы, кажется, имеете в виду, что, поскольку я выступал за больший выбор, мне не следует спорить о принуждении участников посещать больше мест. Что ж, это действительно два разных аргумента, не так ли? Я чувствую себя прекрасно, снимая их обоих. Извините за пинг. Скрипт его вставляет, а я иногда забываю его удалить. Huggums537 ( обсуждение ) 06:13, 5 мая 2021 (UTC) Кстати, спасибо за попытку указать на очевидный парадокс моих аргументов, поскольку более серьезный парадокс создания самой проблемы, которую мы пытаемся решить путем реализации решения, был раскрытый...Huggums537 ( разговор ) 07:58, 5 мая 2021 (UTC)

                Нет, я просто сказал, что мне не нужно обсуждать преимущества возможности отвечать на вопросы в одном или нескольких местах, как обе стороны считают нужным, поскольку вы уже это сделали. Это нормально, что процессы меняются с годами, что может означать создание новых или устранение старых. Если для эффективной работы одного процесса не хватает добровольцев, нам, возможно, придется объединить усилия; по мере роста сообщества английской Википедии может оказаться более эффективным иметь более специализированные инициативы. isaacl ( разговор ) 16:02, 5 мая 2021 (UTC)

• Возражать против утверждения OP ложно. Статистика страниц показывает, что активность в последние годы была довольно постоянной и стабильной и далека от нуля. Эндрю 🐉 ( разговор ) 15:00, 1 мая 2021 (UTC)

  См. Статистику сравнения выше. Ник Мойес ( разговор ) 07:15, 2 мая 2021 (UTC)

  Это тоже только половина дела, другая - то, что это вызывает ненужную избыточность и непродуктивную децентрализацию. Aza24 ( разговор ) 07:22, 2 мая 2021 (UTC)

  Основное, что я заметил из статистики выше, это то, что больше всего текста в Чайхане добавляет Ник Мойес. Итак, мы имеем дело с заявкой на поглощение, в которой более мелкие конкуренты раздавлены и уничтожены. Проблема в том, что в Википедии нет эффекта масштаба. Больше - не лучше, потому что вики-страницы становятся непригодными для использования, когда становятся слишком большими и становятся нечитаемыми.и возникла техническая проблема с перегрузкой шаблона. И если вы заставляете людей делать что-то единственно верным способом, то добровольцы, которым это не нравится, будут отказываться от своей работы. Таким образом, меньшее количество добровольцев получает большую рабочую нагрузку. Это может работать какое-то время, но затем вы выгораете из единственной точки отказа. Обратите внимание, как «Указатель» снова переживает кризис, потому что его централизованная структура снова сжигает главного редактора. Мой! Голос остается в силе. Эндрю 🐉 ( разговор ) 08:56, 2 мая 2021 (UTC)

  Я вроде как согласен с Эндрю Дэвидсоном. Эта логика, что у нас уже есть место, используемое для оказания помощи, поэтому нам не нужно другое, сродни той семье, которая улучшила свой дом с 1 кровати / 1 ванны до дома с пятью спальнями и сказала себе: «нам не нужна еще одна ванная, нам нужно централизованное место, чтобы все могли пописать, чтобы упростить жизнь». Это совершенно бессмысленно. Кроме того, нет избыточности в хранении EAR, когда вы сравниваете два форума, которые предлагают разные виды услуг, а EAR предлагает услуги, которых нет в других. Однако, даже если бы itGood была «избыточной» услугой, я думаю, что мой аргумент «чем больше ванных комнат, тем лучше» все же применим. Huggums537 ( разговорное ) 10:57, 2 мая 2021 (UTC)

  Этот аргумент о ванной не подходит - я не могу поверить, что говорю это, но, конечно, полезно больше ванных комнат, потому что только один человек может использовать их одновременно, но это не так.Бывает с этими справочными заведениями. Наличие нескольких местоположений для целей без существенной разницы просто бесполезно, это сбивает с толку, разделяет ресурсы и повторяется. И почему мы ведем себя так, как будто здесь есть какой-то заговор? "меньшие соперники раздавлены и уничтожены" Я имею в виду, что ????? Данные о просмотрах страниц показали, что активность в EAR, безусловно, ниже, и, учитывая скорость ее снижения, я не вижу причин полагать, что перенаправленный трафик может перегрузить чайный домик или службу поддержки, которые чрезвычайно эффективны. На самом деле, если уж на то пошло, то это вряд ли вообще повлияет на среднюю «загруженность» в этих местах. Централизация не является отрицательной по своей сути, это основная практика WP - Sign Post совершенно несравнима и имеет множество собственных проблем.Aza24 ( обсуждение) 17:05, 3 мая 2021 г. (UTC)

  По моему опыту, разделение досок объявлений хорошо работает только тогда, когда каждая из дополнительных досок объявлений имеет определенную цель и занимает определенный участок трафика. Посмотрите на некоторые из успешных разделений, например, деревенский насос имеет отдельные разделы, в которых есть отдельные разделы для политики, отношений WMF, технических вещей и т. Д. Можете представить себе беспорядок, если бы вместо этого мы разделили его, создав «Деревенский насос 1». , «Деревенский насос 2», «Деревенский насос 3» и т. Д., А правила были такими: «Размещайте на любой доске, которая вам нравится»? Если мы хотим разделить справочные доски на более мелкие разделы, это следует сделать, разделив справочную службу на темы, например, «помощь с шаблонами», «помощь с поиском источников», «помощь с политиками и рекомендациями». Я тоже не думаю, что аналогия с ванной действительно подходит,Я думаю, что ситуация больше похожа на покупку дома с пятью спальнями, а затем на покупку идентичного дома по соседству, попытки жить в обоих одновременно и удивляться, почему в итоге все собираются в одном доме.192.76.8.91 ( разговорное ) 17:29, 3 мая 2021 (UTC)

  По своему опыту я вижу в Википедии множество процессов, которые хорошо работают без централизации. Один из примеров, который я могу сразу придумать, - это обсуждаемые те самые справочные форумы. Какие доказательства предлагали кто-либо, что какой-либо из этих форумов не работал хорошо, кроме низкого статуса трафика? Это ни в коем случае не указывает на то, работают ли форумы для людей, которые их используют. Во всяком случае, это всего лишь показатель того, что форумы с большим трафиком рекламировались больше, а те, у которых меньше, не получали такого большого внимания. Huggums537 ( разговорное ) 06:19, 4 мая 2021 (UTC)

  Низкий трафик по своей сути плохо для справочной доски - чтобы давать людям хорошие и своевременные советы, вам понадобится большая база добровольцев с различным опытом ответов на вопросы. Вчера кто-то на доске попросил помощи в споре по статье, касающемся изменения размера изображения в информационном окне - им потребовалось 8 часов, чтобы получить ответ, который в основном сводился к «Обычно мы оставляем размер изображения по умолчанию». Они задали дополнительный вопрос о том, как предотвратить будущие войны редактирования, который на момент написания этого комментария оставался без ответа в течение 14 часов. Просматривая архивы страниц обсуждения, это не редкость. Люди изложили другие проблемы, связанные с наличием нескольких досок помощи вверху и внизу, не в последнюю очередь из-за того, что это:Это чрезвычайно сбивает с толку новичков, которые хотят задать вопрос, поскольку они сталкиваются с несколькими страницами с совершенно разными именами, которые делают одно и то же.192.76.8.91 ( разговорное ) 09:41, 4 мая 2021 (UTC)

  Итак, вы думаете, что массовое объединение всех трех форумов в один огромный конгломерат на самом деле сократит время отклика, а не сделает их дольше? На вашем месте я бы серьезно переосмыслил эту позицию. Huggums537 ( обсуждение ) 14:56, 4 мая 2021 г. (UTC) Кроме того, ваше недовольство по поводу времени ответа довольно смехотворно. Я приглашаю вас взглянуть на некоторые другие консолидированные и унифицированные площадки, которые доказывают, что они не работают, например, на статьи для творчества, где отставание превышает 5000, а время ответа измеряется месяцами, а не часами, или вы можете посмотреть что-то вроде разблокировки система запросови посмотрите, как вам нравится это время отклика. Администраторы должны иметь возможность просматривать блокировку так же легко, как спор рассматривается в EAR, но они этого не делают, и это то, что вы получаете за свою объединенную консолидацию. Huggums537 ( разговорное ) 15:55, 4 мая 2021 (UTC)

  Сравнение с AfC кажется разумным. Я только что внимательно посмотрел на Чайный домик и обнаружил, что это просто несфокусированная доска вопросов и ответов - похоже, что здесь нет нееврейского общения, о котором говорит его название. Там Ник Мойес объясняет: « К сожалению, большая часть нашей работы здесь говорит обнадеживающим редакторам, что у них нет шансов на то, что их любимая статья станет реальностью ..."и поэтому мы видим, что это в основном враждебное препятствие, как и AfC. Как координатор мероприятий, который регулярно имеет дело с новыми редакторами на editathons, я стараюсь отвести новых редакторов от AfC, и теперь я буду относиться к чайному домику таким же образом . И это также показывает, насколько осторожно вы должны быть со статистикой. Если Чайный домик на самом деле оказывает неблагоприятное воздействие, отпугивая новичков и отталкивая их, а не помогая им, то увеличение занятости может усугубить ситуацию. Нам нужна статистика по эффект этих различных справочных служб. Какие из них на самом деле повышения производительности и сохранения и задевающие его? Эндрю 🐉 ( разговор ) 8:38, 5 мая 2021 (UTC)

• Поддержка имеет для меня смысл. Afernand74 ( разговорное ) 13:59, 2 мая 2021 (UTC)
• Комментарий - LOL, «заявка на поглощение». Что за чушь. Рейк _ЙО! 14:10, 2 мая 2021 г. (UTC)
• Поддержите данные Per NickMoyes выше. Мы не должны разделять наши усилия, потому что слишком много мест сбивает с толку новичков. Лучше всего направлять новых редакторов в одно место, чтобы задавать вопросы или делать запросы, а в 2020 году у Чайхана было в 30 раз больше трафика, чем у WP: EAR, поэтому я думаю, что нам следует пойти с этим. Редакторы, работающие в EARS, по-прежнему могут продолжать выполнять запросы, вместо этого просто следите за ними в Чайхане. - ГВП · · ро · дез 6:47, 3 мая 2021 (UTC)
• Поддержка . Я не вижу смысла в наличии нескольких площадок с перекрывающимся фокусом и думаю, что это создает больше проблем, чем решает:
  • Это сбивает с толку новичков, которые уже сталкиваются с огромным количеством досок объявлений , справочных страниц и дискуссионных форумов. Например, если вы хотите узнать, можно ли использовать источник в черновике, который вы пишете, вы можете быть перенаправлены на WP: TEA , WP: RSN , WP: HD , WP: AFCHELP или WP: EAR , все которые могут быть подходящими местами для того, чтобы задать свой вопрос.
  • Он разделяет добровольцев на несколько страниц, что означает, что помощники, которые являются экспертами в одном из аспектов редактирования, могут пропускать вопросы, размещенные на справочном форуме, которые они не часто проверяют, что приводит к более низкому качеству ответов.
  • Люди, просящие о помощи на досках с меньшим трафиком, будут ждать ответа неоправданно дольше. На некоторые вопросы WP: EAR на получение ответа потребовалось не менее 3 часов, что не идеально для новичка, который пишет свою первую страницу. 192.76.8.91 ( разговорное ) 16:45, 3 мая 2021 (UTC)

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

• Поддержка EAR - это умирающая страница, и наличие слишком большого количества опций вредит эффективной работе любой из них. Нам бы не пришлось, если бы это была широко используемая часть Википедии. Хотя это могло быть в прошлом, это не сейчас, и нам лучше закрыть его. - Jayron 32, 16:06, 4 мая 2021 г. (UTC)

  Никто не представил никаких доказательств того, что эта так называемая "умирающая" страница каким-либо образом нанесла какой-либо ущерб работе других пользователей. Huggums537 ( разговор ) 05:00, 5 мая 2021 (UTC)

• Поддержка Медленное распространение закулисных форумов Википедии неизбежно, но ухоженный сад необходимо время от времени подрезать. Это кажется разумным. Ganesha811 ( разговорное ) 01:08, 5 мая 2021 (UTC)
• Поддержка - сделать страницы редиректами. - Чед ( разговор ) 03:58, 5 мая 2021 (UTC)
• Поддержка Скорее несколько крупных площадок, чем много маленьких. CaptainEek ^{редактирует Ho Cap'n!} ⚓ 21:23, 8 мая 2021 г. (UTC)

Предложение: закрыть службу поддержки и заменить ее на чайный домик [ править ]

Прежде чем я начну, я знаю, что это определенно будет очень противоречивым, и я просто хочу опубликовать его, чтобы получить отзывы по этому поводу. Чайный домик выглядит как отличная замена справочной службе, система хостов работает хорошо, есть хороший процесс адаптации для новых вопросов, и в целом он выглядит довольно гостеприимно. Я думаю, что объединение службы поддержки и чайного домика также поможет решить некоторые проблемы с тем, где задавать вопросы. Мысли? EpicPupper ( разговор ) 04:44, 9 мая 2021 (UTC)

• Я категорически против этого. Время от времени я помогаю в обоих местах, и они предназначены для разных ситуаций (новые и опытные пользователи). Нет необходимости объединять их, и это только добавит разочарования. Элли ( Обсуждение | вклад ) 21:16, 12 мая 2021 (UTC)
• Против и нет. Huggums537 ( разговор ) 21:58, 12 мая 2021 (UTC)
• Возражать , если я хочу помочь Я иду в службу поддержки . Если я хочу чаю, я иду в чайный домик. DuncanHill ( разговорное ) 22:03, 12 мая 2021 (UTC)
• Допустим, даже сейчас, если мне нужна помощь в теме, где я вообще ничего не знаю о поле (например, трехмерные изображения), я иду в чайный домик, потому что там помощники знают, что нужно начинать с первых принципов. Но для большинства моих вопросов мне нужно только знать, как справиться с конкретным пограничным случаем - изучение всех авторских прав в качестве учебника было бы нежелательным, поэтому я прошу это в справочной службе и т. Д. Nosebagbear ( разговор ) 12:31, 13 Май 2021 г. (UTC)
• Против . Культуры этих двух центров помощи различны. Help Desk обслуживает опытных редакторов и новичков в Teahouse. Отвечая в этих местах, мне не нужно проверять учетные данные запрашивающих редакторов и соответствующим образом корректировать свой ответ, потому что это предполагается. -  Finnusertop ( обсуждение ⋅ вклад ) 12:48, 13 мая 2021 г. (UTC)
• Оппост за носового мешка медведя и финнусертопа. МБ 13:24, 13 мая 2021 г. (UTC)
• Против. Служба поддержки изначально спроектирована и функционирует как место для всех редакторов, включая опытных. Чайный домик создан специально для новых редакторов, которым нужна базовая помощь. --- Sm8900 ( разговорное ) 🌍 14:31, 13 мая 2021 (UTC)
• Напротив, согласно вышеизложенному, у них есть четко определенные и отличные домены, и они оба очень активны. Не нужно выключаться. - Jayron 32 14:32, 13 мая 2021 года (UTC)

Предложение: заменить ссылку службы поддержки на главной странице ссылкой на чайный домик [ править ]

• Поддержка Пока мы здесь: чтобы продолжить это обсуждение, которое завершилось консенсусом, чтобы добавить ссылку на Чайный домик, но не был уверен, какую форму она должна принять. Похоже, что, вероятно, есть консенсус в отношении разделения TH и HD на данный момент. Поэтому я думаю, что было бы лучше заменить ссылку службы поддержки на главной странице ссылкой на чайный домик. Редакторы, приходящие оттуда, вероятно, являются новичками, и слишком запутанно / раздуто, чтобы они оба перечислялись, пытаясь объяснить различия IMO. ProcrastinatingReader ( разговор ) 07:46, 24 апреля 2021 (UTC)
• Комментарий Хотя я рад поддержать это, я немного обеспокоен полным удалением ссылки службы поддержки. Разве следующее не сработает ?:

  • Портал сообщества - Доска объявлений, проекты, ресурсы и мероприятия, охватывающие широкий спектр областей Википедии.
  • Служба поддержки - задавайте вопросы об использовании Википедии.
  • Чайный домик - справочная служба для начинающих редакторов. Удобное место, где можно задать вопрос о редактировании Википедии.
  • Местное посольство - для общения по Википедии на языках, отличных от английского.
  • Справочная служба - Выступая в роли виртуальных библиотекарей, волонтеры Википедии ответят на ваши вопросы по широкому кругу тем.
  • Новости сайта - объявления, обновления, статьи и пресс-релизы в Википедии и Фонде Викимедиа.
  • Village pump - для обсуждения самой Википедии, включая области технических проблем и политик.

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

  Это работает для меня, хотя я бы сказал, что чайный домик выше HD, а описание службы поддержки заменено чем-то вроде «Для более опытных редакторов, которые задают вопросы о редактировании Википедии». Я все еще думаю, что предпочитаю полностью заменить ссылку, так как я думаю, что Чайный дом лучше справляется с помощью новичков, и что предоставление ненужных вариантов является плохим UX и добавляет небольшое трение. ProcrastinatingReader ( разговор ) 09:44, 24 апреля 2021 (UTC)

• Поддержите одну ссылку. Против двух ссылок. Нам не нужно и не должно быть двух форумов для того, чтобы задавать вопросы (так что службу поддержки и чайхан нужно объединить). Если у нас есть два форума, на главной странице должна быть ссылка на TH (поддержите это предложение). Ни при каких обстоятельствах не следует связывать оба элемента; это просто запутает людей. Levivich  ^харасс / _гончая 13:24, 24 апреля 2021 (UTC)
• Ссылка «Поддержите чайный домик» на главной странице и , если у нас есть обе ссылки, поместите ее над службой поддержки. Если мы сохраним и то, и другое, рекламная строка службы поддержки должна включать что-то, что предназначено для редакторов, не являющихся новичками. Я нейтрально отношусь к тому, чтобы убрать службу поддержки с главной страницы и просто разместить там чайный домик. Nosebagbear ( разговор ) 14:02, 24 апреля 2021 года (UTC)
• Я не поддерживаю это добросовестное предложение из лучших побуждений. Я поддерживаю добавление дополнительной ссылки на чайный домик и не возражаю против размещения этой ссылки над ссылкой службы поддержки. Но пока служба поддержки открыта, и мы хотим, чтобы редакторы использовали ее, нам нужно на нее ссылаться. Я настоятельно рекомендую провести отдельное обсуждение, сфокусированное исключительно на том, можем ли мы и должны ли мы объединить эти два усилия; Я решительно поддержал бы такое предложение, но это, кажется, гораздо более масштабное предложение, чем то, что было выдвинуто здесь, которое требует отдельного, специального обсуждения с четким заголовком, чтобы другие редакторы могли видеть то, что предлагается. ЭльКевбо ( разговор ) 02:59, 25 апреля 2021 (UTC)

  У нас есть ссылки на службу поддержки с внутренних страниц, таких как WP: вопросы , Шаблон: страницы справки Википедии , Шаблон: ссылки на доску объявлений и т. Д. Мы не предлагаем отказаться от всех этих ссылок. Просто заменить его специально на главной странице, откуда, скорее всего, мы будем получать клики новичков, а не что-либо еще. ProcrastinatingReader ( разговор ) 15:32, 25 апреля 2021 (UTC)

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

  • Чайный домик - справочная служба для начинающих редакторов. Удобное место, где можно задать вопрос о редактировании Википедии.
  • Служба поддержки - задавайте вопросы об использовании Википедии. Направлено в основном на тех, у кого уже есть некоторый опыт редактирования.

  (или, возможно ... * Служба поддержки - задавайте вопросы об использовании Википедии. Менее дружелюбно, более кратко и с большим количеством сокращений!) Ник Мойес ( выступление ) 00:19, 26 апреля 2021 г. (UTC)

  Может ли формулировка «Чайный домик» быть просто «дружественным пространством для новых редакторов, где они могут спросить о редактировании Википедии»? - Наддруф ( обсуждение ~ вклад ) 16:21, 28 апреля 2021 г. (UTC)

• Поддержите удаление ссылки службы поддержки и замену ее ссылкой на Чайный домик. Скорее всего, на главную страницу новые редакторы пойдут за информацией. Опытные редакторы могут по-прежнему обращаться в службу поддержки вручную. EpicPupper 20:26, 27 апреля 2021 г. (UTC)
• Поддержка Per Epicpupper. Две ссылки просто сбивают с толку, и лучшая из двух ссылок на главную страницу - это чайный домик. Каллиопеджен1 ( разговор ) 04:21, 30 апреля 2021 (UTC)
• Ссылка для поддержки обоих, предложенная Ником Мойесом здесь . Моя логика заключается в том, что нам нужны два разных места, чтобы получить ответы либо для продвинутых, либо для новичков. Как новый пользователь, я рад, что теперь справочная служба существует. Я ходил в Чайхана за ответами, и, хотя я ценю дружелюбие и полезность, это отстой, когда меня рассматривают, как одного дня, когда пользователь IP получает ответы с ложечки. Теперь я знаю, что у меня есть место, куда я могу пойти, чтобы получить ответы, с которыми я могу справиться. Думаю, это тоже понравится другим пользователям. Huggums537 ( разговорное ) 14:48, 1 мая 2021 (UTC)
  • Но вы не узнали эту информацию по ссылке на главной странице, и другие авторитетные редакторы тоже не узнают. - Билорв ( разговорное ) 23:18, 1 мая 2021 г. (UTC)
    • Но, тем не менее, я узнал о чайном домике на своей странице обсуждения, и если бы на главной странице была описательная ссылка на чайный домик с контрастной описательной ссылкой службы поддержки прямо под ним, я бы, скорее всего, заметил это гораздо раньше. Huggums537 ( разговор ) 12:31, 2 мая 2021 (UTC)
• Поддержка : предпочтительнее просто ссылка на чайный домик (не вводите людей в заблуждение, пока они даже не нажали на справочный форум, потому что они не знают, какой из них им подходит), но ссылку как на чайный домик, так и на службу поддержки. будет улучшением, так как Чайхана более дружелюбна. - Билорв ( разговорное ) 23:18, 1 мая 2021 г. (UTC)
• Я бы поддержал замену чем-то вроде {{tq | Нужна помощь? Попробуйте наш справочный форум для новых пользователей или наш справочный форум для более опытных пользователей . G M G talk 22:39, 2 мая 2021 г. (UTC)

  Я думаю, что GreenMeansGo предлагает интересное решение. Huggums537 ( разговорное ) 00:01, 3 мая 2021 (UTC)

Поддержка замены ссылки .... нужна только одна, и чайхана лучше подойдет для набора новых редакторов. В прошлом году количество индивидуальных правок значительно увеличилось, но количество регистраций снизилось ... возможно, Чайный домик может помочь нам решить эту проблему. Moxy - 23:08, 2 мая 2021 г. (UTC)

• Поддержка . Чайхана сейчас в значительной степени является расчетной палатой. Парень ( помогите! - опечатка? ) 20:18, 3 мая 2021 г. (UTC)
• Поддержка , я был бы удивлен, если бы опытные редакторы не знали о службе поддержки, и тем более, если бы они обращались к ней с первой страницы. Доступ к местам помощи с главной страницы кажется чем-то более ориентированным на новых пользователей, отсюда и использование ссылки в чайхане. Aza24 ( разговорное ) 22:21, 3 мая 2021 (UTC)
• Поддержите две ссылки: ссылка на Чайный домик выше и ссылка службы поддержки, где написано что-то вроде «для более сложных вопросов». Ganesha811 ( разговорное ) 01:09, 5 мая 2021 (UTC)
• Предположим, что название «Чайный домик» вводит в заблуждение, так как здесь, кажется, нет никакого общения или групповой деятельности, и уж точно нет чая. Когда я хожу на физические монтажные конференции, лучше всего подходят перерывы на чай / кофе, так как обмен напитками - это хороший способ сблизить и пообщаться с другими редакторами. Чайный домик на самом деле кажется просто несфокусированной доской для вопросов и ответов. У нас уже есть много таких, с более точными названиями, как Help Desk и Reference Desk. Эндрю 🐉 ( разговор ) 08:54, 5 мая 2021 (UTC)

  Отсутствие чая действительно огорчает. Может быть, его следует переименовать в Coffeehouse, чтобы вместо этого мы могли расстроиться из-за отсутствия кофе? - GhostInTheMachine ^{поговорит со мной} 18:01, 5 мая 2021 года (UTC)

• Противодействовать. Добавьте ссылку на Чайный домик к 6 ссылкам, уже имеющимся ^в разделе «Другие разделы Википедии» на главной странице - как было предложено Ником Мойесом в самом начале - GhostInTheMachine ^{поговорит со мной} 18:07, 5 мая 2021 г. (UTC)
• Против удаления ссылки службы поддержки. Поддержите добавление дополнительной ссылки на Чайный домик. - Джейрон, 32 14:33, 13 мая 2021 г. (UTC)

Архив отчетов RfPP [ править ]

Я создаю постоянный архив отчетов в Википедии: Запросы на защиту страниц . Я уже сделал кое-что, что можно увидеть в User talk: Chicdat / RfPP archives . Я хотел бы узнать, что об этом думает более широкое сообщество Википедии. 🐔  Chicdat   ^{Bawk мне!} 10:54, 21 апреля 2021 (UTC)

какой в ​​этом смысл? Я имею в виду, что архивирующие боты могут быть настроены для создания постоянных датированных архивов, если это будет сочтено полезным (по сравнению с текущими скользящими архивами). Но было сделано так много отчетов, что я просто не понимаю, чем это может быть полезно. ProcrastinatingReader ( разговор ) 11:17, 21 апреля 2021 (UTC)

Защищая страницу, администратор может просмотреть другие запросы защиты страницы, чтобы определить, следует ли защищать ее. 🐔  Chicdat   ^{Bawk мне!} 12:23, 21 апреля 2021 г. (UTC)

Я предполагаю, что администраторы RfPP сочтут это полезным, но если они думают, что да, то, вероятно, было бы лучше, чтобы бот WP: BOTREQ отвечал на RfPP со ссылками на постоянные ссылки предыдущих запросов защиты. Даже если вам удастся скомпилировать все архивы RfPP на вашей странице (очень трудоемкая задача, которую нужно выполнить вручную), загрузка этой страницы займет так много времени, а затем нажатие ctrl-f заголовка страницы просто не позволит быть особенно эффективным. ProcrastinatingReader ( обсуждение ) 12:51, 21 апреля 2021 (UTC)

Я не планирую делать шестнадцать лет RfPP на одной этой странице. Когда он достигнет 500 КБ, я разделю его. Чикдат ( разговор ) 12:42, 26 апреля 2021 (UTC)

• Наверное, ненужно, но, вероятно, и безвредно. Администраторы (фактически любой) уже могут просмотреть журнал защиты страницы, чтобы узнать, как давно и как часто страница была защищена. Просмотр журнала отклонений запроса на защиту (ИМО) не очень полезен при принятии решения о защите. Иванвекторская белка ( ^{деревья} / _орехи ) 12:54, 21 апреля 2021 (UTC)
• Как администратор, который раньше часто патрулировал RFPP (и все еще время от времени заходит), я нашел бы эту функциональность бесполезной; Я имею в виду, если вы хотите сделать это, потому что кто-то другой может счесть это полезным, продолжайте, я просто говорю, что это не повлияет на мою работу по RFPP; Я основываю свои решения о защите почти полностью на странице истории статей и журнале защиты, где предыдущие меры защиты легко видны и могут быть легко отслежены. В общем, я не возражаю против этого, если кто-то другой сочтет это полезным, я бы просто не стал. - Джейрон, 32 12:55, 21 апреля 2021 г. (UTC)
• На лекции в Википедии был достигнут консенсус по этому поводу: Запросы на защиту страницы / Архив 9 # Архивирование запросов RfPP , но он так и не был реализован, потому что текущая система архивирования обрабатывается ботом, оператор которого не отвечает на запросы на обновление бота. * Ппперы * началось ... 13:20, 21 апреля 2021 г. (UTC)
• Если это необходимо, это должен сделать бот. - ^{Обсуждение} xaosflux 15:36, 21 апреля 2021 г. (UTC)

  Я написал код для такого бота некоторое время назад, см. Обсуждение в Википедии: Запросы на защиту страниц # Исторические архивы . У меня все еще есть код, и я был бы готов запустить его, если есть консенсус, но более серьезная проблема (как я сказал в своем предыдущем комментарии) заключается в том, что бот в настоящее время архивирует запросы RFPP в скользящий архив, чтобы быть совместимым с новая система. * Pppery * началось ... 16:03, 21 апреля 2021 г. (UTC)

  Или мы могли бы просто выключить этого бота. Нам конечно не нужны скользящий архив и постоянный архив. Иванвекторская белка ( ^{деревья} / _орехи ) 13:22, 22 апреля 2021 г. (UTC)

  Согласен, но тот же бот отвечает за множество других неотделимых клерков отчетов ботов, поэтому «просто выключите его» не так просто, как кажется. Я дам оператору бота пинг, но я не ожидаю действий, учитывая, что его впервые попросили сделать это в 2019 году, но он так и не сделал. * Pppery * началось ... 21:25, 22 апреля 2021 (UTC)

  Пппери , мне действительно нужно ответить на этот запрос. Я постараюсь посвятить время обновлению этой информации в эти выходные. - CYBERPOWER ( чат ) 15:26, 23 апреля 2021 г. (UTC)

  @ Cyberpower678 : Есть новости по этому поводу ? * Pppery * началось ... 14:51, 27 апреля 2021 (UTC)

  Согласитесь, это не так просто, как нажать большую красную кнопку. Но, если есть запрос к боту изменить или прекратить делать что-то, что он делает в настоящее время, а оператор не отвечает, я без колебаний заблокирую его. Иванвекторская белка ( ^{деревья} / _орехи ) 15:03, 27 апреля 2021 г. (UTC)

  Пппери , я кое-что поработал, но он не готов. Я буду работать еще немного в течение недели. - CYBERPOWER ( чат ) 15:32, 28 апреля 2021 г. (UTC)

• Здесь, в Википедии, много необходимой работы. Это не то. G en Q uest ^"scribble" 17:43, 21 апреля 2021 г. (UTC)
• Вы можете объяснить, зачем это нужно, Чикдат? Какую проблему это решит? - Малькольмxl5 ( разговор ) 13:26, 22 апреля 2021 г. (UTC)
  • См. Обсуждение в Википедии: Запросы на защиту страниц # Архив ?? для дополнительной информации. 🐔  Chicdat   ^{Bawk мне!} 13:30, 22 апреля 2021 г. (UTC)
• Журнал защиты страницы уже обеспечивает это в удобном, простом для использования формате. CaptainEek ^{редактирует Ho Cap'n!} ⚓ 20:10, 22 апреля 2021 (UTC)
• Я также просто не понимаю, как это помогает. Для меня это похоже на архивирование WP: UAA или WP: AIV . Это доски, которые получают новые отчеты весь день, каждый день. Архивация всех этих запросов создаст горы новых страниц, которые почти наверняка останутся без поддержки и будут игнорироваться как старый бизнес. Я не вижу пользы. Библброкс ( разговорное ) 20:19, 22 апреля 2021 (UTC)
• Хотя полезность немного сомнительна, опять же, она не вредит. И в отсутствие этого вреда, если редактор считает, что это либо полезно, либо повышает прозрачность, я поддерживаю их в этом. Nosebagbear ( разговор ) 20:29, 22 апреля 2021 (UTC)
• Согласен с Jayron32. Похоже на решение в поисках проблемы. - F ASTILY 23:41, 22 апреля 2021 (UTC)
• Я добавлю, что поддерживаю это (хотя мои комментарии выше подразумевают это в некоторой степени), в первую очередь из-за аргумента согласованности: почти все остальные доски объявлений полностью заархивированы (включая ANI, который получает примерно такое же количество правок в день, что и RFPP), поэтому мне кажется странным не сделать этого в одном случае. * Pppery * началось ... 21:53, 25 апреля 2021 г. (UTC)
  • Я согласен. На самом деле ANI имеет примерно на 500 000 ревизий больше, чем RfPP. Чикдат ( разговор ) 12:40, 26 апреля 2021 (UTC)
    • Хотя не совсем. АНИ - это место для обсуждения сложных вопросов. AIV, UAA и RFPP предназначены для быстрых действий в более очевидных случаях. Вот почему они не архивируются, а также почему их архивирование бесполезно. Библброкс ( разговор ) 01:22, 1 мая 2021 (UTC)
      • Есть несколько различных типов досок для объявлений. Есть те, у которых есть веские причины не архивировать (например, AIV и UAA). Есть те, которые заархивированы (AN, ANI, AN3, BN, IAN, EFN, RSN, COIN, BLPN). Есть те, что заархивированы, но странным образом (PERM, XfD, SPI). А еще есть RFPP. Некоторые пользователи хотят, чтобы он работал с AIV и UAA. Другие хотят, чтобы он пошел вместе с Ns. 🐔  Chicdat   ^{Bawk мне!} 11:02, 2 мая 2021 г. (UTC)
• Cyberbot I скоро должен быть обновлен, чтобы отразить это предложение. Чикдат ( разговор ) 12:40, 26 апреля 2021 (UTC)
• Прошло много времени. Рад видеть, что в настоящее время над этим работают. Большое спасибо Chicdat и Pppery за повторное озвучивание проблемы и Cyberpower678 за реализацию предложения. В ответ на PEIsquirrel , ну, хотя я не уверен, как еще описать ситуацию с застопорившимся RfC на WT: RFPP , принимать такие меры не срочно и не выгодно, иначе я бы давно просил об этом, годами. В настоящее время единственная альтернатива работающему боту с устаревшими настройками - это неучтенная доска объявлений и расстроенный оператор бота. ~ ToBeFree ( обсуждение ) 21:15, 3 мая 2021 г. (UTC)
  • Благодарю вас . Это одно из самых приятных сообщений, которые я получил за долгое время. 🐔  Chicdat   ^{Bawk мне!} 10:06, 4 мая 2021 г. (UTC)

Можем ли мы прийти к единому мнению о том, когда уместно «спасти» живые ссылки в статье с IABot? [ редактировать ]

Если вы посетите страницу истории любой статьи, вверху вы увидите «Исправить мертвые ссылки». Это приведет вас на страницу https://iabot.toolforge.org, где вы можете использовать базу данных IABot для добавления ссылок на архивы на страницу. Есть поле для «Добавить архивы ко всем не мертвым ссылкам (необязательно)», и это тот маленький прямоугольник, о котором я хотел бы здесь поговорить.

Насколько я понимаю, щелчок по этому окну не архивирует страницу. Это уже было сделано ботом и сохранено в базе данных вне вики. Все, что он делает, - это копирует уже существующие архивные ссылки в статью. Многие люди стали просто переходить к различным статьям, не имеющим мертвых ссылок, и «спасать» все живые источники.

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

Причины, по которым это нехорошо: это значительно увеличивает размер страницы без добавления каких-либо значимых функций. См., Например, эту разницу, которая была последней в моем списке наблюдения, а не самой большой, которую я видел. Он добавляет 12k на страницу без спасенных мертвых ссылок. Это, конечно, означает, что страница больше, но также означает, что любой, кто использует редактор исходного кода, должен прокручивать еще более крупные шаблоны цитирования. Это также избавляет нас от различных инструментов, необходимых для понимания авторства страницы. Я знаю, спорная тема, но иногда полезно взглянуть на статистику страницы xtoolsчтобы увидеть, кто работал над статьей, что не всегда очевидно, просто взглянув на самую последнюю историю. В этом случае тот, кто просто спас ссылки, которые не нужно было восстанавливать, теперь указан как основной автор этой страницы. ( Приносим извинения YoungForever , который просто пытался здесь помочь. Я не хочу выделять вас - многие люди используют этот инструмент таким образом.) Мы также знаем, что некоторые википедисты заинтересованы в том, чтобы делать большие числа вкладов, и я бы предположил, что возможность быстро вносить эти большие полуавтоматические правки в любую статью также может быть мотивирующим фактором для некоторых (я видел, как люди после длинной череды правок переходили к десяткам статей просто чтобы спасти живые ссылки).

TL; DR - Если желательно, чтобы в статье были все архивные ссылки, бот должен это сделать, а не оставлять это на произвол судьбы, спасая вещи, которые не нуждаются в спасении. Если это нежелательно, эта опция либо не должна быть доступна пользователям, либо мы должны быть более ясными в отображаемом тексте для этой опции и разрешить возврат при неправильном использовании. Если иногда желательно восстановить живые ссылки, каковы эти случаи? -Рододендриты ^{говорят} \\ 14:27, 23 апреля 2021 (UTC)

Я согласен, что это не должно происходить произвольно. Это должен быть шаг к практике, такой как заключительная подготовка к GA / FA и последующее обслуживание, как только это будет достигнуто. (например, как только 90% ссылок имеют URL-адреса архива, архивирование остальных ботов не проблема). Я также вижу, что это делается для темы, где основная часть источников существует только с веб-страниц, таких как многие статьи о текущих событиях, но это должно произойти через некоторое время после создания статьи, где может быть возникают - по крайней мере, если не более чем через год после создания, но не в этот первый год наверняка. - M asem ( t ) 14:43, 23 апреля 2021 г. (UTC)

@ Masem : Просто чтобы уточнить, когда вы говорите, что я также вижу, что это делается там, где основная часть источников существует только с веб-страниц , вы говорите, что архивирование этих ссылок - это то, что должно быть сделано, чтобы в случае смерти одного из архивов можно было добавляться полуавтоматически? Или все эти ссылки должны быть добавлены прямо в статью в порядке упреждения в дополнение к архивированию IABot вне вики? IABot архивирует / хранит их независимо от того, используем мы этот интерфейс или нет. Вопрос в том, когда переносить архивные ссылки в текст статьи. -Рододендриты ^{говорят} \\ 14:51, 23 апреля 2021 (UTC)

Действительно ли архивный бот создает архивы во время работы, даже если вы не поставили этот флажок? У меня создалось впечатление, что это не AManWithNoPlan ( разговор ) 15:02, 23 апреля 2021 г. (UTC)

Я про то, когда их добавят в википейдж. Я считаю, что мы действительно хотим, чтобы фоновые ссылки для архивных ссылок происходили независимо, но проблема заключается в добавлении их в Wikipages, и его следует делать только в целях полировки (GA / FA) или если статья сильно зависит от онлайн-поиска. - M asem ( t ) 15:04, 23 апреля 2021 г. (UTC)

Если желательно иметь все архивные ссылки в статье, бот должен сделать это, а не оставлять это на произвол судьбы путем спасения вещей, которые не нуждаются в спасении. Рододендриты , я согласен с этим. И есть еще одна причина для добавления ссылок на архив: WP: EVADEGDPR . Кстати, когда дело доходит до более длинного вики-текста (меня никогда особо не беспокоило), его можно значительно уменьшить, изменив шаблоны. Шаблон цитирования на голландском Wiktionary , например , не требует архивных дат и позволяет опуская живой URL. - Alexis Jazz ( поговори или позвони мне) 15:05, 23 апреля 2021 г. (UTC)

Несколько лет назад мое предложение автоматизировать дату архивации (основанное на разборе URL-адресов архива общих архивных сайтов) было отклонено. На данный момент не могу найти его в архивах. Я обычно поддерживаю сокращение избыточности между полями. Однако я не поддерживаю удаление URL-адреса, если есть URL-адрес архива, потому что это затрудняет сканирование конкретных ссылок или обновление ("где, черт возьми, сам URL? О, верно, он закодирован как часть другой URL в другом поле. "). DMacks ( разговор ) 15:57, 23 апреля 2021 (UTC)

DMacks , в голландском Викисловаре также не принято опускать действующий URL, и если он указан, будет использоваться введенный URL. Шаблон просто не беспокоит пропуск URL-адреса. Я не совсем уверен, будет ли хорошей идеей структурное исключение действующего URL, но я хотел упомянуть, что технически это возможно. - Alexis Jazz ( поговори со мной или позвони мне) 17:36, 23 апреля 2021 года (UTC)

Спасибо за объяснение происхождения этих правок. Термин «спасение» в моем списке наблюдения продолжал сбивать меня с толку, когда все ссылки были активными (неясно, исправляется ли какая-то плохая ситуация). DMacks ( разговорное ) 15:29, 23 апреля 2021 (UTC)

100% согласен с ОП. Когда я впервые сюда попал, я совершал эту ошибку: я просматривал статьи, отмечал необязательный флажок и добавлял все ссылки на архивы. Я думал, что это архивирование ссылок. Кто-то в какой-то момент меня поправил, и теперь я понимаю, что это добавляет к статьям много ненужного раздувания. Это также портит статистику авторства. Я указан как главный автор движения « Александрия Окасио-Кортес» и « Желтые жилеты», но это только потому, что я одним щелчком добавил около 40 тысяч архивных ссылок. Этот необязательный флажок должен иметь как минимум предупреждение, если он не был удален или перемещен в другое место. Levivich  ^харасс / _гончая 16:57, 23 апреля 2021 (UTC)

Я не особо много пользуюсь IAB. Я использовал его только тогда, когда я сталкивался с отмененным сериалом, который уже закончился, мини-сериалом (только 1 сезон) уже закончился, мертвым человеком или фильмом, который отсутствовал какое-то время, поскольку URL-адреса статей могут не работать или обновляться с информация, которая может больше не иметь отношения к статьям. Я не думал, что добавление архивных URL-адресов к действующим ссылкам - это большая проблема, так как я видел много старых редакторов, использующих IABot для этого. - Young Forever (разговор) 19:43, 23 апреля 2021 (UTC)

Предполагая, что информация на WP: EVADEGDPR верна, я поддерживаю редакторов (или ботов), добавляющих архивные ссылки на все, что уже заархивировано на веб-сайте Internet Archive (WayBack Machine), при условии, что боты не делают этого без запроса редактора на конкретная статья, или потому что бот спасает другие мертвые ссылки в статьях. На самом деле у меня нет того или иного мнения о том, что бот делает это для всех страниц без запроса, но я бы не стал возражать против этого. -bɜ: ʳkənhɪmez ( Пользователь / привет! ) 01:58, 24 апреля 2021 г. (UTC)

• Так что, возможно, это связано с RfC. Я думаю, что в конечном итоге все сводится к:
  • Вариант 1. Отключите параметр «спасать» ссылки, которые не мертвы в интерфейсе IABot, потому что все ссылки должны сопровождаться ссылкой на архив, и мы должны сделать так, чтобы бот добавлял их автоматически.
  • Вариант 2. Отключите параметр «спасать» ссылки, которые не мертвы в интерфейсе IABot, потому что IABot уже архивирует все ссылки, и они нам не нужны в статье до тех пор, пока ссылка действительно не станет мертвой.
  • Вариант 3. Разрешить пользователям «спасать» ссылки, которые не мертвы, но устанавливать правила, когда это разрешено. (например, определенные типы тем или восстановление мертвой ссылки) и добавить предупреждение в интерфейс .
  • Вариант 4 - Разрешить пользователям «спасать» ссылки, которые не умерли по прихоти, по их собственному усмотрению (статус-кво).
• Более или менее? Чтобы быть ясным, я не прошу людей выбирать здесь один из этих вариантов - я удостоверяюсь, что это более или менее правильные варианты для представления, признавая, что № 3, конечно, потребует дополнительных действий. -Рододендриты ^{говорят} \\ 02:19, 24 апреля 2021 года (UTC)
  • Я думаю, добавить опцию «добавить предупреждение / совет к флажку» (в отличие от «правил» №3) и явно указать №4 как статус-кво (с более нейтральной формулировкой). В остальном выглядит хорошо и спасибо. Levivich  ^харасс / _гончая 02:51, 24 апреля 2021 (UTC)
    • Что касается «правил», разве это не то, что нам действительно нужно? Условия, когда это приемлемо? Иначе что бы говорилось в сообщении? И да, я на самом деле не собирался «по прихоти» превращать его в RfC. :) -Рододендриты ^{говорят} \\ 13:31, 24 апреля 2021 года (UTC)
  • Также проверьте Cyberpower678 , чтобы убедиться, что это звучит работоспособно и на его стороне ? -Рододендриты ^{говорят} \\ 03:04, 24 апреля 2021 года (UTC)

    Верен ли вариант 2? Кажется, это не побуждает ИА архивировать ссылки; Я всегда ищу их вручную. Hawkeye7 (обсуждение) 03:07, 24 апреля 2021 (UTC)

    Рододендриты , я хотел бы удалить вариант 2. Этот инструмент также используется за пределами enwiki, и у них разные практики. Внесение поправок в номер 1, отключение этой опции было бы спорным, если бы IAB не добавлял архив автоматически. В конечном счете, это инструмент, которым любой может пользоваться бесплатно, но его никто не заставляет. Если дело доходит до того, что разрешено использовать, а что нет, это должно быть ориентировано на политику, а не на реализацию индивидуальных ограничений для внешнего инструмента. - CYBERPOWER ( около ) 14:01, 24 апреля 2021 г. (UTC)

    @ Cyberpower678 : Facepalm благодарит за напоминание о том, что английская Википедия - не единственный проект, который использует эти инструменты (и что я подвержен энвикицентризму). Проблема, связанная с политикой, заключается в том, что наши политики не решают ее. Таким образом, похоже, что это нужно будет переосмыслить не с точки зрения удаления этой опции, а, возможно, просто (а) определения, хотим ли мы, чтобы бот добавил все архивы; если нет, то (б) разработка наших собственных правил для этого и, если применимо, (в) добавление рекомендаций при выборе варианта, говорящего (используя общую формулировку о том, что это не разрешено во всех проектах, или указывая где-то на какую-то документацию). Как это звучит? -Рододендриты ^{говорят} \\ 14:28, 24 апреля 2021 (UTC)

    Рододендриты , конечно. Добавление подсказки в ящик не проблема. - CYBERPOWER ( около ) 15:47, 24 апреля 2021 г. (UTC)

• Что касается минусов архивирования живых ссылок, замедляет ли это загрузку для читателей? И будут ли более длинные ссылки чем-то раздражающим для читателей, или это будет потенциально полезно, если ссылка умирает, но еще не идентифицирована как таковая? Мне эти вопросы кажутся более важными, ориентированными на читателя , чем проценты авторства (что в основном является ошибкой из-за чрезмерной простоты инструмента; инструменты должны служить для редактирования, а не наоборот) или засорения исходного кода (что по сути является проблемой пользовательского интерфейса, WMF нужно решить ). Если мы решим, что они больше раздражают, чем полезны, одним из вариантов было бы хранить архивные ссылки в викитексте, но не показывать их читателям до тех пор, пока |url-status=live. {{u | Sdkb }}  ^{обсуждение} 04:12, 24 апреля 2021 (UTC)
  • Я полагаю, что дополнительные 5, 10, 15 или, в некоторых случаях, 40-50 КБ данных на страницу будут иметь какое-то влияние. Руководство по размеру статьи WP: определяет размер страницы в WP: CHOKING , где объясняется, что загрузка 32k занимает около 5 секунд при коммутируемом соединении, а длинные страницы вызывают проблемы с некоторыми мобильными устройствами. Я думаю, что, как и во многих других вещах, стоит поговорить о том, насколько это полезно по сравнению с любыми затратами. И я бы не стал полностью сбрасывать со счетов расходы редакторов. Некоторые вещи могут быть "просто" проблемой дизайна, которую WMF или кто-то долженисправить, но это не значит, что это действительно произойдет. Однако это довольно касательный вопрос, и да, читатели по сути являются приоритетом. Я действительно считаю, что хранить архивную информацию в вики-тексте, но не отображать ее - худший из возможных вариантов. Я не слышал, чтобы кого-то раздражало появление ссылок на архивы. Я имею в виду, что в долгосрочной перспективе это то, что следует экспортировать в Wikidata / WikiCite, но мы еще не достигли этого. -Рододендриты ^{говорят} \\ 13:18, 24 апреля 2021 года (UTC)

Некоторые комментарии:

• Не беспокойтесь о производительности .
• Ссылка гниль - это категорически плохо . Чем раньше мы это остановим, тем лучше.
• Не основывайте свои решения на том, заболевают ли люди editcountitis . Мы здесь не для того, чтобы указывать им, как внести свой вклад, если вклад положительный.
• У шаблонов определенного размера в викитексте есть решение. Просто некоторым редакторам такое решение не нравится. ;)
• Раньше у нас было как минимум одно обсуждение «раннего» архивирования. Пожалуйста, просмотрите архивы здесь или где-нибудь еще.

Между набором, добавление архивных ссылок категорически в лучшую сторону. - Изно ( разговор ) 00:15, 25 апреля 2021 г. (UTC)

Мы не должны беспокоиться о производительности сервера. Мы все еще можем беспокоиться о добавлении времени загрузки и анализа на стороне клиента («синтаксический анализ» относится к любому времени, добавленному дополнительными параметрами к настройке структур данных, которые вызывают действие при наведении курсора мыши). Борьба с гниением ссылок путем бездумного добавления огромного количества архивных ссылок не улучшает проверяемость, когда полезно проверить исходные ссылки (особенно, если они потеряны просто из-за реорганизации веб-сайта), на наличие более свежих источников, и совпадают ли источники и текст. Я бы зарезервировал IABot для использования, скажем, по одной статье за ​​раз, для тех редакторов, которые не заботятся о дополнительной справочной разметке (например, url-адрес архива, дата архива, статус URL-адреса). Дхтвики ( разговор ) 14:53,25 апреля 2021 г. (UTC)

Все здесь говорят, что плохо включать архивные ссылки, когда вы вставляете (живую) ссылку? - Наддруф ( обсуждение ~ вклад ) 17:12, 25 апреля 2021 г. (UTC)

Нет. Мы пытаемся выяснить, есть ли согласие на массовое добавление архивных ссылок к действующим ссылкам. Я не думаю, что это повлияет на индивидуальное решение включить ссылку на архив для конкретной цитаты. -Рододендриты ^{говорят} \\ 18:21, 25 апреля 2021 года (UTC)

Можно рассмотреть возможность дополнения возможности «Добавить архивы ко всем не мертвым ссылкам (необязательно)» другой опцией, которая позволяет пользователю пробовать и выборочно добавлять архивы к определенным ссылкам. Я не уверен, как часто это происходит, но я видел некоторые «живые» ссылки, которые фактически умерли и были заменены спамом. Ссылка технически «живая», поэтому IABot пропускает ее и говорит что-то вроде «изменений не было», потому что нет мертвых ссылок. Что ж, я знаю, что мне действительно нужно добавить ссылку на архив, чтобы иметь правильный контент, поэтому я могу поискать на нескольких сайтах архива свой URL-адрес или попытаться добавить все ссылки на архив и надеюсь, что получу правильный . Конечно, все остальное тоже получит ссылку на архив, но это нормально, верно? Давай, сделай это.Иногда я буду искать в Wayback и Archive.today, но стараюсь на этом останавливаться. Это зависит от того, насколько я ленив.
В любом случае, это не обязательно решает предложение, но может немного снизить частоту использования «добавить все архивы». - 2pou ( разговорное ) 17:05, 26 апреля 2021 г. (UTC)

• Комментарий. Йо, я не могу поверить, что установка этого флажка не архивирует ссылки. Могу поклясться, что это именно то, что он сделал.
  @ Cyberpower678 : вы можете здесь взвесить. - MJL  - Обсуждение - ^☖ 04:10, 28 апреля 2021 (UTC)

  Ой ... Он уже пингуется. Извини за это. Мне просто нужно лечь спать .. - MJL  - Talk - ^☖ 04:11, 28 апреля 2021 (UTC)

  MJL , конечно, есть. Если цель состоит в том, чтобы добавить архивные URL-адреса ко ВСЕМ ссылкам, а некоторые из них еще не существуют в Wayback Machine, то IABot попросит Wayback Machine сохранить их, а затем URL-адрес снимка будет добавлен в Википедию. - CYBERPOWER ( чат ) 15:34, 28 апреля 2021 г. (UTC)

  @ Cyberpower678 : Но нет необходимости активировать IABot для архивирования ссылок, потому что IA уже автоматически сканирует Википедию и архивирует все ссылки, это правильно? Например, вчера я создал статью, основанную на недавних статьях в прессе. Мне не нужно «ставить галочку» и добавлять архивные ссылки на статью Википедии через IABot, потому что эти ссылки в статье уже заархивированы, просто в силу того, что они находятся на проиндексированной странице Википедии. Это правильно? Кроме того, если одна из этих ссылок станет мертвой, есть бот, который автоматически заменит мертвую ссылку ссылкой на архив в это время, верно? Просто пытаюсь понять, понимаю ли я, как все это работает. Спасибо, что нашли время объяснить это нам, новичкам. Levivich  ^харасс /_гончая 16:15, 28 апреля 2021 (UTC)

  По моему опыту, новые ссылки обычно, но не всегда, архивируются в течение нескольких дней после добавления. Около недели назад я проверил ссылки в Fagradalsfjall и вручную заархивировал несколько, что не было сделано автоматически. Тридуульф ( разговор ) 10:42, 29 апреля 2021 (UTC)

  Левивич , да. Так должна работать система. Но иногда что-то может пойти не так, и некоторые ссылки пропускаются или не удается заархивировать. Это не обычное явление, но такое бывает. В конце концов, у Internet Archive есть огромная инфраструктура, которую нужно поддерживать. - CYBERPOWER ( около ) 16:30, 29 апреля 2021 г. (UTC)

• Когда уместно спасать живые ссылки? Всегда и вчера. Эти 12 КБ гнили анти-ссылок - один из самых ценных материалов, которые может добавить редактор. Я думаю, что есть еще два важных подпункта, которые нужно рассмотреть в OP. (1) Иногда статья слишком велика, чтобы поддерживать архивные URL-адреса для всех цитирований, так как лучше всего передать эту социальную практику? Самым простым решением был бы какой-то пустой шаблон, который велит IABot архивировать свои ссылки, но не писать в статью, уважая социальный консенсус редакторов этой страницы. (2) Вопросы авторства в XTools должны решаться в алгоритме авторства, а не в общих ограничениях на использование IABot. Тот факт, что байты цитирования учитывают «авторство», означает, что правки цитирования, не относящиеся к IABot, будут по-прежнему неточно отражать авторство прозы.(нетсмотрите , пожалуйста ) {{ping}} czar 07:12, 4 мая 2021 (UTC)

Пробная версия на вики-сайте Growth Team [ править ]

Всем привет,

Команда Growth Team предложила план тестирования новых функций Growth Team для 2% новых учетных записей на вики-странице после различных успешных испытаний / развертываний в других проектах.

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

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

Чтобы протестировать функции , перейдите к своим пользовательским настройкам, а затем:

• включите панель Help на вкладке Editing .
• включите домашнюю страницу для новичков на вкладке профиля пользователя .

Это даст вам доступ к домашней странице ( Special: Homepage ), и оттуда вы сможете:

• свяжитесь со своим наставником
• выберите свои любимые темы и задачи, чтобы внести некоторые предлагаемые изменения
• просматривать справочные страницы
• увидеть свое влияние

Вы также увидите, что панель справки будет видна при редактировании или просмотре страниц справки.

- MMiller (WMF) ( разговор ) 01:41, 9 мая 2021 г. (UTC)

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

1. Наставники выбираются случайным образом из всех редакторов или только из тех, кто намеревается быть наставниками? Если это случайный выбор из всех редакторов, каковы критерии выбора, чтобы гарантировать, что только редакторы, которые могут отвечать новым пользователям, случайным образом назначаются в качестве наставников?
2. Будет ли способ выбрать наставников на основе тематических областей, которые новый редактор выбирает на домашней странице, или на основе их наиболее распространенных тем, которые они уже редактировали?
3. «Создать новую статью» в настоящее время неактивно для меня - будет ли это расширено, чтобы позволить людям начать работу над черновиком, как только они захотят, независимо от того, завершены ли «другие шаги»? Я думаю, что это, вероятно, оттолкнет людей, если им нужно будет сделать «больше шагов», пока они не получат вариант «нового черновика».
4. Будет ли способ «настроить» домашнюю страницу для включения ссылок, относящихся к тематическим областям? Например, большинству новых редакторов, вероятно, не нужно видеть WP: MEDRS и WT: MED, но для тех, кто интересуется статьями по биологии / медицине, эти две ссылки, вероятно, было бы хорошо разместить на главной странице. В идеале, я думаю, это была бы подстраница WikiProjects, которая могла бы быть включена с инструкциями для WikiProjects о том, как создать краткое введение в их тематическую область.

В целом я считаю, что это отличная идея - и это всего лишь мой первый отзыв. С уважением -bɜ: ʳkənhɪmez ( Пользователь / привет! ) 01:53, 9 мая 2021 г. (UTC)

Спасибо за ознакомление с функциями, @ Berchanhimez ! Я рад, что ты думаешь, что мы на правильном пути. Вот мои ответы на ваши хорошие вопросы:

1. Наставники выбираются случайным образом из списка пользователей, которые подписываются на роль наставников. Для небольших вики (например, чешской Википедии) им, как правило, требуется всего около пяти наставников, чтобы наставники не получали слишком много вопросов. Для больших вики, таких как французская Википедия, обычно требуется около 40 наставников. По мере того, как мы тестируем функции здесь на английском языке, мы получим представление о том, сколько наставников будет подходящим для гораздо большего потока новичков в этой вики. Это страница регистрации на английском языке , где нам нужно всего 5-10 наставников для 2% -ного теста (и мы не хотим, чтобы их было слишком много, потому что тогда каждый наставник будет редко получать вопросы).
2. Идея подбора наставников по тематическим направлениям возникла очень часто! Я определенно считаю, что это хорошее улучшение, и рад, что вы упомянули об этом.
3. Идея «создать новую статью» неактивна: многие новички пытаются создать новую статью сразу после создания своей учетной записи. Это одна из самых распространенных причин, по которой люди создают учетную запись. Но из нашего исследования мы знаем, что подавляющее большинство из них не могут создать статью и в конечном итоге не получат первого опыта работы с Википедией. В нашей функции мы хотим побудить новичков попробовать более легкие изменения, прежде чем погрузиться в создание новой статьи, и мы поместили в это поле серое поле, потому что мы знаем, что многие из них из новичков ищут, где создать статью. Мы хотим указать, что мы знаем, что они хотят создать новую статью, но мы не рекомендуем этого. Имеет ли это смысл? Как вы думаете?
4. Раньше не слышал об этой идее, но она мне нравится! Мы знаем, что новичкам может помочь добиться успеха, если они смогут найти других, разделяющих их интересы. Я могу представить себе это примерно так: после того, как новичок выберет интересующие его темы, в модуле появятся ссылки на вики-сообщества, которые сосредоточены на этих темах, и они смогут приступить к изучению. Сюда я подал задание , чтобы наша команда запомнила идею.

MMiller (WMF) ( разговорное ) 03:42, 9 мая 2021 (UTC)

MMiller (WMF) , благодарю за ответы! Что касается плохого опыта создания новой статьи, я думаю, важно понимать, что у многих новых редакторов единственная цель регистрации - создать какую-то статью - и на самом деле некоторые из наших новых медицинских статей были написаны новыми редакторы, которых мы, возможно, сможем сохранить. Я не думаю, что ограничение - лучшая идея - на мой взгляд, было бы лучше иметь наставника через создание новой статьи. Я понимаю вашу позицию, и я не полностью против нее, потому что я в основном согласен с вами - у большинства людей плохой опыт работы с новыми статьями, - но решение, я думаю, не в том, чтобы усложнять им это но чтобы иметь возможность направлять их больше. Я думаю, что руководство может помочь им осознать самостоятельночто создавать статью для начала - не лучшая идея - и это поможет им остаться. В целом я очень ценю и согласен с ответами здесь - и я думаю, что это, вероятно, будет хорошо :) Спасибо за ответ :) -bɜ: ʳkənhɪmez ( Пользователь / привет! ) 04:14, 9 мая 2021 (UTC )

@ Berchanhimez - понял; Благодарю. Возможно, нам следует подумать о создании руководства по новым статьям раньше, чем мы планировали. MMiller (WMF) ( разговорное ) 04:22, 9 мая 2021 (UTC)

MMiller (WMF) , да, я думаю, что это может быть лучше всего - потому что, к сожалению, некоторые люди просто собираются полностью оставить инструменты и вернуться к старому способу, если они не могут найти ясный (не обязательно простой, но понятный) путь к своей цели в новой статье. На мой взгляд, даже всплывающая подсказка или подсказка, в которой говорится, что «создание новой статьи будет доступно через этот инструмент после x», независимо от того, подтверждено ли это автоматически или что-то еще, были бы полезны. В качестве альтернативы, если подталкивание их к «более легкому редактированию» в области темы работает хорошо, может быть полезно просто выделить его серым, а во всплывающей подсказке будет сказано: «Пожалуйста, попросите своего наставника помочь в создании новой статьи, поскольку этот процесс нелегок автоматизировать в этом инструменте »или подобном - в основном это снимает вину с инструмента и поощряет наставничество на протяжении всего процесса. Адаптация наставничества к конкретным тематическим областям, будь то автоматическая рандомизация на основе участия в WikiProjectили что-то подобное, безусловно, сделает его более жизнеспособным, т. е. поседение не просто вернет их к нормальному мышлению «Я все равно сделаю это», но даст им четкий путь. Рассматривается ли это - автоматическая рандомизация на основе выбора тематической области и связанных списков участников / активных пользователей WikiProjects? Я знаю, что некоторые WP лучше обновляют эти списки, чем другие, но это была бы хорошая интеграция WP в новые редакторы. Таким образом, первый вопрос, который им задают, когда они открывают его, это «Какая тематическая область вас больше всего интересует» - с, возможно, еще несколько подвопросов для областей с большим количеством проектов (например, WikiProject для конкретного региона, фокусирующийся на теме площадь и т. д.). -bɜ: ʳkənhɪmez ( Пользователь / передай привет!) 21:44, 11 мая 2021 г. (UTC)

Хорошо, эта страница выглядит довольно круто. Первоначальные комментарии к виджету «Помощь с редактированием» в правом нижнем углу, я думаю, что некоторые цели ссылки можно изменить. «Как создать новую статью» идет в Википедию: Мастер статей / версия 1, который заменяется, «Как написать хорошую статью» идет в WP: MOS, что, хотя и является руководством по стилю, для новичка немного сложно. в чтение, и я думаю, что у нас есть лучшие руководства о том, как написать хорошую статью (у меня есть пара в User: ProcrastinatingReader / sandbox # Writing , и я думаю, есть также Википедия: Написание лучших статей ). ProcrastinatingReader ( разговор ) 02:22, 9 мая 2021 (UTC)

Отлично работает и хорошо выглядит. Единственное беспокойство, которое у меня есть, перекликается с ProcrastinatingReader .... нашими целевыми страницами для получения дополнительной помощи должна быть родительская страница справки Википедии, которая редактируется и контролируется сообществом. Страницы учебников вызывают много проблем ... доступность в мобильном представлении ... многослойный текст в представлении destop ... необходимость щелкать и загружать кнопки действий на нескольких страницах для получения полезной информации. В руководстве есть серьезные проблемы с удержанием редактора . Moxy - 02:36, 9 мая 2021 г. (UTC)

Спасибо за проверку, @ ProcrastinatingReader и @ Moxy . Я рад слышать, что тебе все хорошо. Для этих страниц справки мы автоматически заполняем их на основе Викиданных, но они полностью настраиваются для этой вики. Несколько других людей тоже заметили, и мы обсуждаем, как их изменить. Не стесняйтесь взвесить, чтобы мы могли сделать их подходящими страницами для английской Википедии! MMiller (WMF) ( разговорное ) 03:50, 9 мая 2021 (UTC)

Отлично смотрится, приятный и интуитивно понятный интерфейс для новых редакторов. EpicPupper ( разговор ) 04:37, 9 мая 2021 (UTC)

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

Я наконец поплелся к VPR после того, как столкнулся с этим вдвое за большее количество дней, и с тем фактом, что такие RM / TR часто остаются открытыми в течение длительного времени, поскольку область патрулируется большим количеством PMR, чем администраторов. Я не могу считать веской причиной, чтобы этого не произошло; переносчиков страниц не так много, это достаточно охраняемая пермь, и любой PMR с хроническим движением может быстро вырвать бит. Удивительное количество страниц находится под защитой от перемещения сисопа indef, которая, кажется, почти никогда не пересматривается (я столкнулся с одной, где она была размещена во время небольшой войны с перемещениями с 2008 года), и это довольно мешает PMR не иметь возможности выполнять значительную часть перемещений страниц, на которые нам вообще было дано право. Ватицидальный пророк 08:52, 26 апреля 2021 г. (UTC)

• Поддержка Я столкнулся с этим в Википедии: Доска объявлений для администраторов / Archive324 # Запрошенный ход (защищенная статья) . В 2011 году статья была защищена от перемещения Mjroots, поэтому нам потребовался администратор в 2020 году, чтобы переместить ее на правильное имя. - Alexis Jazz ( поговори со мной или позвони мне) 11:12, 26 апреля 2021 года (UTC)

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

• Если мы так поступаем, то да, я тоже это поддерживаю. Естественно, поскольку несколько недель назад я тоже наткнулся на завал. Как и все. Вопрос, я думаю, в том, насколько актуальна эта проблема на самом деле; как долго в среднем нужно ждать, чтобы администратор отменил защиту от перемещения? - S Перс 11:37, 26 апреля 2021 (UTC)

  Серийный номер 54129 , в случае выше его не было. Администратор выполнил перемещение, но страница остается защищенной от перемещения. Если организация будет переименована в будущем, нам снова понадобится админ. - Alexis Jazz ( поговори со мной или позвони мне) 11:41, 26 апреля 2021 г. (UTC)

• Поддержка , хотя я бы сказал, что страницы, защищенные от перемещения, не проверяются, потому что никто не запрашивает такие проверки. Мджрутс ( разговор ) 11:39, 26 апреля 2021 (UTC)
• Я бы поддержал это. Мы должны ожидать, что любой, кому было предоставлено средство перемещения страниц, не является вандалом, перемещающим страницы, и что они знают, что нельзя перемещать спорные страницы без согласия. Элли ( Обсуждение | вклад ) 12:02, 26 апреля 2021 (UTC)
• Комментарий Если я правильно помню, это невозможно без предоставления перемещателям страниц также возможности редактировать защищенные страницы. Anomie ⚔ 12:37, 26 апреля 2021 г. (UTC)
  • Это кажется легко разрешимым с ситуацией, подобной редакторам шаблонов, где подавляющее большинство страниц, защищенных от перемещения, реклассифицируются как защищенные PMR, а очень немногие, которые не могут быть отредактированы не администраторами, когда-либо (материал типа Main Page) сохраняется. в полном объеме. Ватицидальный пророк 12:45, 26 апреля 2021 г. (UTC)
• Предыдущее обсуждение: Обсуждение в Википедии: Перемещение страниц / Архив 1 # Обсуждение: Разрешить перемещение страниц, защищенных от перемещения ~ Aseleste ( t , e | c , l ) 13:01, 26 апреля 2021 г. (UTC)
• Поддержка Проблема с уровнями защиты в том, что у вас слишком много чрезмерно защищенных страниц. В частности, есть чрезмерно защищенные перенаправления, чрезмерно защищенные соленые заголовки и чрезмерно защищенная защита от перемещения. Многие из них, похоже, соответствуют современным стандартам политики защиты и до-ECP. Эти чрезмерные защиты неразрешимы - слишком много страниц подвержены этому, так что это может решить только бот, и обсуждения в AN, чтобы сделать что-то массово (например, на основе соображений защиты), как правило, заканчиваются отсутствием консенсуса из-за нечеткости ' обеспокоенность'. Типичный аргумент состоит в том, что можно запросить снижение в WP: RFPP . Да, это правда, можно запросить снижение защиты конкретной страницы в постоянно задерживающемся WP: RFPP.. Но если вы собираетесь бросить задачу в чью-то корзину, вы можете просто подать WP: RM / TR (что я и делаю). Это в лучшем случае искусственное отставание и просто пустая трата времени множества людей. Мы надлежащим образом проверяем переносчиков страниц, и стандарты для PMR в настоящее время, вероятно, выше, чем для администраторов в 2004 году. Если это предложение будет принято, PMR, перемещающие защищенные от перемещения страницы, должны быть ограничены политикой, чтобы делать это только в тех же обстоятельствах, что и администраторы. . Таким образом, здесь нет никакого реального риска. ProcrastinatingReader ( разговор ) 14:24, 26 апреля 2021 (UTC)
• Поддержка . Я тоже столкнулся с этим. Майкл Мэггс ( разговор ) 14:29, 26 апреля 2021 (UTC)
• Сильно возражайте против предположения, что это предложение фактически «разрешить перемещателям страниц перемещать страницы с защитой от перемещения только для администратора» (поскольку они уже могут перемещать страницы с защитой от перемещения, находящейся в пределах их уровней редактирования). Мало того, что этой технической возможности не существует (препятствуя тому, чтобы это могло быть выполнено без работы разработчика - что они могут быть не заинтересованы в этом), но я не хотел бы, чтобы "движок страницы" возился со страницами, такими как как эти или эти . Мы даже не позволяем делать это гораздо более тщательно изученным редакторам шаблонов, а полоса входа для движка страниц намного ниже. - xaosflux ^Talk 14:53, 26 апреля 2021 г. (UTC)
  • Если на самом деле речь идет о чем-то другом, например о создании нового уровня защиты, у меня действительно нет возражений, но я действительно не думаю, что это необходимо - так что нейтрально в этом случае. - xaosflux ^Talk 14:56, 26 апреля 2021 г. (UTC)

  @ Xaosflux : ИМО, вы оцениваете предложение и факторы риска по неправильным критериям. Техническая возможность перемещения страницы не означает, что она будет перемещена, и я не могу представить, как движок страницы пытается переместить Module: Math только потому, что он технически может это сделать. На мой взгляд, этот аргумент эквивалентен тому, что предоставление администраторам DYK / ITN технического доступа к Special: MergeHistory приведет к повреждению историй страниц.

  Правильными критериями для оценки этого могут быть: a) имеет ли это существенное преимущество для незавершенных работ и / или наших процессов, связанных с перемещением (то есть: улучшает ли энциклопедию); б) является ли предложение слишком рискованным. Я не думаю, что кто-то может обоснованно не согласиться с первым пунктом, так что остается только второй (риск). Страницы должны (в широком смысле) быть защищены от перемещения из-за вандализма, разногласий при редактировании или превентивной защиты (например, часто используемых шаблонов / модулей), где может быть повышенный риск вандализма или добросовестных действий, которые неправильно понимают уровень консенсуса, необходимый для перемещения . (если я не упускаю другие случаи?)

  • Вандализм: Те, у кого есть PMR, не будут вандалами.
  • Плохие ходы с благими намерениями: движущиеся страницы должным образом проверяются на предмет запросов об успешных перемещениях в WP: PERM / PM , а в ИМО стандарты примерно правильные (за исключением случаев запросов на основе удалений WP: R2 для составления черновиков). Pages, задача, которую должен выполнять бот IMO), поэтому вы ожидаете, что они будут хорошо разбираться в том, когда они могут или не могут быть подходящим редактором для перемещения страницы или закрытия RM. Вероятно, среднестатистический исполнитель страниц с большей вероятностью будет компетентен в этой задаче, чем средний администратор (поскольку большинство из них не работают в области перемещения страниц).
  • Неправильное использование в спорах о контенте: есть много страстных администраторов, которые тоже участвуют в спорах, и они не редактируют свои спорные мнения по поводу полностью защищенной страницы, заблокированной для противодействия редактированию, хотя технически они могут это сделать. Я не думаю, что это будет по-другому, и если есть злоупотребления, вытащить разделенную химическую завивку несложно. ProcrastinatingReader ( разговор ) 15:30, 26 апреля 2021 г. (UTC)

  • Что касается вопросов о страницах типа «контент», которые защищены от перемещения администратора; как и в случае с другими средствами защиты, они должны быть защищены только до уровня и продолжительности, необходимых для предотвращения сбоев; если есть плохие защиты, они должны быть проверены и скорректированы. Случайный щелчок по списку статей с полной защитой от перемещения вызвал, например, Trevor Lock , и я не вижу никаких веских причин для использования защиты от перемещения только для администратора (которую я только что удалил). - ^{Обсуждение} xaosflux 16:10, 26 апреля 2021 г. (UTC)

• @ Xaosflux : как переносчики страниц смогут перемещать защищенные шаблонами или полностью защищенные страницы? Им по-прежнему нужно иметь возможность редактировать их, чтобы переместить, что они не смогли бы сделать. Я думаю, вы могли неправильно понять объем предложения здесь. Элли ( Обсуждение | вклад ) 23:49, 26 апреля 2021 (UTC)

  @ Элли : отчасти проблема в том, что предложение представлено довольно плохо. Нет определения, позволяющего перемещать страницы, имеющие право перемещать защищенные от перемещения страницы - например, они уже МОГУТ это делать, при условии, что защита от перемещения - это уровень, на котором они могут перемещаться; это похоже на то, что была изобретена некая новая технология, позволяющая этой группе иметь новое разрешение, которое позволяет перемещать страницу независимо от уровня ее защиты. - ^{Обсуждение} xaosflux, 00:00, 27 апреля 2021 г. (UTC)

  @ Xaosflux : Я почти уверен, что предложение состоит в том, чтобы просто не применять защиту от перемещения к переносчикам страниц - любая другая защита от редактирования все равно применима. Я не понимаю , как это на самом деле , что трудно осуществить технологически. Элли ( Обсуждение | вклад ) 00:24, 27 апреля 2021 (UTC)

• С сожалением возражаю против разрешения перемещать полностью защищенные страницы при перемещении страниц, поскольку вероятность (вероятного непреднамеренного) сбоя слишком высока и потребует от разработчика времени, потраченного в другом месте. Слабые противники также создают новый уровень защиты «PMR-protected», так как это также потребует времени на разработку, и я сомневаюсь, что действительно решит исходную проблему Vaticidalprophet. ƒirefly ( t · c ) 15:03, 26 апреля 2021 г. (UTC)

  Я могу абсолютно подтвердить, что изменение страниц, защищенных сисопом, которые не требовали этого по соображениям безопасности, на PMR предотвратило бы / решило мою исходную проблему. Ватицидальный пророк 16:09, 26 апреля 2021 г. (UTC)

• Против . Конечно, это имеет смысл для упомянутых случаев, но xeno xaosflux хорошо замечает, что есть страницы, которые мы определенно хотим, чтобы как можно меньше людей могли удалить. Более жизнеспособным решением проблемы может быть создание нового page mover move protectionуровня защиты и поощрение его использования вместо полной защиты. Это также зависит от желания разработчиков реализовать это, и это звучит немного жутко . -  Джо  ( разговор ) 15:10, 26 апреля 2021 г. (UTC)

  @ Джо Роу : ты имел в виду меня, а не ксено? - ^{Обсуждение} xaosflux 15:56, 26 апреля 2021 г. (UTC)

  @ Xaosflux : Да, извините. Я всегда путаю ваши имена пользователей! -  Джо  ( разговор ) 10:35, 27 апреля 2021 г. (UTC)

• Правильная проблема, неправильное решение - решение состоит в том, чтобы снизить уровень защиты чрезмерно защищенных страниц. Есть подходящее место для защиты от перемещения только для администратора; К сожалению, слишком много страниц полностью защищены (не только защита от перемещения администратора, но и защита от редактирования). Ответ - снизить уровень защиты этих страниц. Вообще говоря, мне кажется, что в административном корпусе есть или был какой-то этос, согласно которому защита страницы лучше, чем блокировка редактора, но я думаю, например, если редакторы ECP движутся враждебно, их следует блокировать, а не перемещать страницу. защищен. Я предполагаю, что, возможно, частичные блоки изменят это. Levivich  ^харасс / _гончая 15:20, 26 апреля 2021 (UTC)
• Противостаньте за Xaosflux; это уводит технические возможности перетяжек страниц слишком далеко от их социальных способностей, и подобный раскол имеет тенденцию стираться со временем. Нейтрально при создании отдельного уровня защиты для переносчиков страниц. * Pppery * началось ... 15:35, 26 апреля 2021 (UTC)
• Тогда могут ли оппоненты проголосовать так, как если бы они выступали за защиту ПМР? Это является частой проблемой, и было особенно страшные последствия для меня сегодня offwiki. Я не был бы счастлив, если бы потерпел неудачу, потому что люди соглашались с фактами, но не соглашались с реализацией. Мы еще не дошли до стадии «формального RfC»; нормально потратить некоторое время на выяснение нюансов, как это реализовать. Ватицидальный пророк 15:51, 26 апреля 2021 г. (UTC)

  Создание отдельного уровня защиты PMR, вероятно, было бы беспорядком. Непосредственные проблемы, о которых я могу думать:

  1. Вам нужно как-то снизить все «подходящие» полные защиты и получить консенсус по критериям для этого, вероятно, через бота, поскольку (в отличие от шаблонов с высоким риском) существует слишком много защищенных страниц, которые нужно делать вручную.
  2. В отличие от шаблонов с высокой степенью риска, в которых вы не получаете новый каждый день, средства защиты от перемещения применяются нечасто. Как вы проинформируете 1100 администраторов об изменении политики, чтобы они теперь должны использовать «защиту PMR» почти во всех случаях?
  3. Нужны ли вам администраторы, постоянно контролирующие полностью защищенные страницы, снижающие полную защиту до защиты PMR, когда администраторы, незнакомые с новой политикой, делают то, что в таком случае будет считаться чрезмерной защитой? Насколько это отнимет у вас время (рассмотрите WP: RAAA и текущие трудности с получением даже древних чрезмерных защит, сниженных в WP: RFPP ).
  4. Общий WP: Проблемы CREEP , и это действительно так.

  Шанс того, что это предложение будет принято, невелик, и на самом деле не имеет значения, есть ли у оппонентов логическая, доказательная основа (если мы хотим обсудить доказательства, мы бы проверили WP: RM / TR на предмет запросов от переносчиков страниц или посмотрите количество отмененных ходов / закрытие RM по PMR). Похоже, что предложения о разделении вызывают возражения противников, хотя кажется, что опасения никогда не материализуются, когда то же самое (или почти эквивалентное) предложение в конечном итоге принимается. Предположим, что TfD NAC удаляет (тогда то же предложение было передано под названием «закрыть как сирота», и бедствия не произошло), [1] переносчик страниц с имеющимися у него разрешениями (изначально сбой в WP: PMRRFC ), новая группа для редактирования защищенные шаблоны (теперь шаблон-редактор) и т. д. ProcrastinatingReader (разговор ) 16:21, 26 апреля 2021 (UTC)

  • Без защиты PMR, я не уверен, так как не считаю, что у меня достаточно информации, чтобы составить мнение. Одна проблема - это проблема времени разработки. Мне жаль, что у вас сегодня был дрянной день, НДС, и я могу понять, почему вы расстроены, но при всем уважении, и, возможно, я неправильно понимаю это предложение, но предложение о защите PMR кажется мне следующим: " у одного редактора сегодня был плохой день из-за страницы, которую они не могли переместить, поэтому мы хотим, чтобы разработчики создали новый уровень защиты ». В этом нет необходимости. Как спрашивали здесь другие, насколько широко распространена эта проблема? Будет ли создание PMR-защиты стимулом для администраторов к защите до этого уровня, что в конечном итоге увеличит количество страниц, которые не могут быть перемещены редакторами ECP? Если так, я не думаю, что это хорошо.Будут ли перемещатели страниц реагировать быстрее / лучше на запросы о снятии защиты или перемещении, чем администраторы в настоящее время? Я не знаю, у нас гораздо больше администраторов, чем перемещателей страниц. Я согласен с вами, что существует проблема со слишком большим количеством защищенных страниц, включая защиту от перемещения, в основном, но не только в основном пространстве, и я поддерживаю любые ваши усилия по исследованию и достижению консенсуса по решению этой проблемы. Прямо сейчас я не уверен, что PMR-protect - правильное решение, но я буду непредвзято и внимательно следить за будущими предложениями.и я поддерживаю любые ваши усилия по исследованию и достижению консенсуса по решению этой проблемы. Прямо сейчас я не уверен, что PMR-protect - правильное решение, но я буду непредвзято и внимательно следить за будущими предложениями.и я поддерживаю любые ваши усилия по исследованию и достижению консенсуса по решению этой проблемы. Прямо сейчас я не уверен, что PMR-protect - правильное решение, но я буду непредвзято и внимательно следить за будущими предложениями.Levivich  ^харасс / _гончая 17:39, 26 апреля 2021 (UTC)
    • Спасибо за сочувствие (искренне - мне кажется, эта фраза звучит немного легкомысленно). Как я уже отмечал, я сделал это предложение до того, как дела пошли грушевидной формы. Это второй раз за последнее время, когда я сталкиваюсь с действиями, защищенными сисопом, как в недавних спорах, так и в долгосрочных спорах, и пару недель назад у меня был еще один, который оставался на RM / TR более 24 часов. Я смотрю список RM / TR, как я думаю, большинство наших активных PMR, и я регулярно вижу, что запросы «закрытые PMR, защищенные сисопом» остаются, пока запросы, которые PMR могут обрабатывать, решаются. Ватицидальный пророк 17:47, 26 апреля 2021 г. (UTC)
• Возражать на Xaosflux. Просто сделайте половину переносчиков страниц администраторами, тогда никакого дополнительного уровня защиты не потребуется. - Кусма ( t · c ) 16:25, 26 апреля 2021 г. (UTC)
• Это такая большая проблема? Я закрыл несколько RM, которым требовались права администратора, и я видел, как Буиде писал несколько сообщений в RM / TR. Как наблюдатель за страницей RM / TR, я знаю, что Энтони Эпплеярд часто посещает страницу и очищает невыполненный журнал практически ежедневно (если не чаще в других случаях), и я знаю, что есть другие администраторы, которые тоже заходят туда. . Если RM закрыт, но переезд все еще не завершен, люди должны набраться терпения. Если кто-то поднимет шум ... ну, весь этот проект - WP: WIP, и, честно говоря, WP: NORUSHдо завершения, на мой взгляд, если это действительно стоит в очереди. RM ожидал 7-дневного ожидания, и еще один или два, чтобы завершить закрытие, не должно быть большой проблемой. Всегда можно дополнить заключительное примечание или добавить примечание под закрытым обсуждением о том, что ход еще не завершен. Я думаю, что Aseleste регулярно делала это для NAC страниц, которые только что заблокировали перенаправления, прежде чем получить привилегии перемещения.
  Все это звучит негативно, но все, что было сказано, я приветствовал бы эту привилегию, а не возражал бы против нее; Я просто не думаю, что это слишком высокий приоритет. Что касается противодействия этому из-за высокотехнологичных случаев, таких как модули и шаблоны, похоже , что ребенок выбрасывает ребенка вместе с водой из ванны.. Перенос страницы должен знать, что ему удобно перемещать, а если это слишком сложно, он должен позволить кому-то другому справиться с этим. Я знаю, что несколько ходов шаблонов опубликованы на RM / TR, но они задерживаются там дольше, чем другие запросы, и я должен предположить, что это потому, что некоторые движущиеся думают, что другому движущемуся было бы лучше обработать его, опасаясь что-то сломать. Если кто-то переусердствовал с обоснованным запросом: « Совершать ошибки - это нормально. Попытайтесь исправить их и тоже извлеките уроки из них ». Если кто-то просто злоупотребил своей привилегией или совершил глупость, отмените право. К сожалению, это потребует очистки от кого-то другого, но это все еще можно исправить. Тем не менее ... кажется, что "приятно иметь" больше, чем необходимость, но если какому-то разработчику нужно что-то делать, конечно.- 2поу( разговорное ) 16:39, 26 апреля 2021 (UTC)
• Есть несколько тысяч основных статей, которые защищены от перемещения администратора. Я не знаю, будет ли решение уменьшить чрезмерную защиту страниц или разрешить перемещателям страниц полностью перемещать защищенные страницы в основном пространстве. Я согласен с тем, что те, что находятся в пространстве шаблона, - это отдельная проблема. ( t · c ) buidhe 16:45, 26 апреля 2021 (UTC)

  @ Buidhe : Я бы поддержал обзор и вероятное массовое сокращение ns: 0 страниц, которые защищены только indef admin-move, где защита очень старая. - ^{Обсуждение} xaosflux 16:50, 26 апреля 2021 г. (UTC)

  Однако PMR могут также закрывать RM для более поздних ситуаций - многие RM создаются после войн перемещений. У меня был худший день в этом году из-за того, что я пытался найти администратора, чтобы остановить постоянный поток сообщений на странице обсуждения о незавершенном перемещении, и простое понижение уровня защиты не предотвратило бы эту ситуацию, тогда как "простой ход воюющий, ПМР защищать" имел бы. (Для ясности, я сделал эту ветку VPR до того, как все стало грушевидным.) Ватицидальный пророк 17:23, 26 апреля 2021 г. (UTC)

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

  Я бы поддержал запуск такого проекта. Нам нужно проверить все полностью защищенные страницы (как редактируемые, так и перемещаемые) во всех пространствах имен. Я трачу много времени на очистку Special: LintErrors и регулярно сталкиваюсь с чрезмерно защищенными страницами. Месяц назад мне пришлось удалить полную защиту только с 1400 страниц в пространстве имен Википедии. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ ( разговорное ) 08:51, 27 апреля 2021 (UTC)

• Возражать - даже если позволить pagemovers двигаться SysOp передвигающихся защищенных страниц, есть еще требование , чтобы проверить с защитным администратором перед редактированием через защиту, поэтому изменение функционально бессмысленно. Да, на этом уровне, вероятно, есть много страниц, которые не нуждаются в защите (я считаю, что возможность EC-move-protect стала доступной только в течение последних двух лет), но решение такое, как предлагает Уанфала: систематическая просмотр всех защищенных от перемещения страниц. Или, на самом деле, это далеко не так важно, как кажется: если защищенную страницу нужно переместить, в любой момент есть несколько сотен активных администраторов, которые могут это сделать, поэтому эту проблему можно легко решить. в индивидуальном порядке. Иванвекторская белка ( ^{деревья} /_орехи ) 21:25, 26 апреля 2021 (UTC)

  Я бы поддержал замену расширенной-подтвержденной-защиты-перемещения защитой-перемещением-перемещением страницы, но возражал бы против создания еще одного нового уровня защиты. Если страница должна быть защищена ниже уровня администратора, то для редакторов, уже проверенных и доверенных за свой опыт перемещения страниц, будет гораздо больше смысла иметь возможность (и ту, которая может быть отозвана за злоупотребления), а не (как сейчас) все пользователи, прошедшие чрезвычайно низкую планку для самого простого участия. Я не вижу веских причин, по которым защита от перемещения должна быть более детальной, чем эти два уровня. Иванвекторская белка ( ^{деревья} / _орехи ) 21:47, 26 апреля 2021 г. (UTC)

  по-прежнему существует требование проконсультироваться с администратором защиты перед редактированием через защиту, поэтому изменение функционально бессмысленно, конечно, это неправда? Если бы это было так, все администраторы WP: RM / TR должны были бы проверить связь с защищающим администратором перед выполнением запроса (или только защищающий администратор мог бы обработать запрос). ProcrastinatingReader ( разговор ) 22:07, 26 апреля 2021 (UTC)

  Не письменное правило AFAIK, это было бы правилом мудака Джона , но, вообще говоря, любой администратор, собирающийся изменить действие другого администратора (например, редактирование / перемещение через защиту), должен сначала проконсультироваться с защищающим администратором или в WP: IAR ситуаций, уведомить другого администратора о действии сразу после факта. Изменение действий другого администратора, не утруждая себя советом, - хороший способ быть придурком , и это можно рассматривать как войну колес.. Если мы собираемся предоставить неадминистраторам техническую возможность изменять действия администратора таким образом, то эта привилегия должна сопровождаться теми же ожиданиями в отношении подотчетности. Я бы подумал, что если страница защищена, она не должна претендовать на технический ход, но опять же, IAR. Иванвекторская белка ( ^{деревья} / _орехи ) 14:41, 27 апреля 2021 (UTC)

• Комментарий . Я хотел бы видеть подтвержденную защиту от перемещения страниц и расширенную защиту SALT по умолчанию и выбирать сисопа только при необходимости. Например, если расширенные подтвержденные пользователи борются за переезд. Я думаю, что некоторые люди в своем уме обычно устанавливают это как сисоп, не особо задумываясь об этом. Я также хотел бы увидеть даты истечения срока, возможно, через год после войны за переезд. - Novem Linguae ( разговор ) 21:58, 26 апреля 2021 г. (UTC)

  Xaosflux , насколько возможно то, что предлагает Novem Linguae ? Я только что проверил в другом месте, и я даже не мог ограничить перемещение файловой страницы для файловых движков. Я мог выбрать всех пользователей (без защиты), автоматически подтвержденных, редакторов шаблонов + админов или админов. Ничего больше. Я также задаюсь вопросом, возможно ли (если защита от перемещения сисопа все еще применяется сегодня) создать фильтр редактирования, который предупреждает администратора при попытке защитить страницу от перемещения сисопа. - Alexis Jazz ( поговорите или позвоните мне) 22:27, 26 апреля 2021 г. (UTC)

  • @ Alexis Jazz : Защита от перемещения по умолчанию установлена ​​на «унаследовать от защиты от редактирования»; когда защита от редактирования не установлена, у сисопов есть дополнительный щелчок, чтобы включить ее вообще, тогда по умолчанию устанавливается «разрешить все» с раскрывающимся списком, сисоп уже является последним из 5 вариантов. Параметр защиты по умолчанию является неопределенным, и ожидается, что администраторы будут следовать политике защиты при принятии решения о том, что подходит. Это ответ на ваш вопрос? - ^{Обсуждение} xaosflux 23:11, 26 апреля 2021 г. (UTC)

    Если вы спрашиваете только «можем ли мы применить расширенную защиту с подтвержденным перемещением» - тогда да, можем. - ^{Обсуждение} xaosflux, 23:17, 26 апреля 2021 г. (UTC)

    Xaosflux , на самом деле вопрос был в том, "можно ли применить защиту от перемещения страницы?" Вы сказали, что у вас есть 5 вариантов. Кто они такие? - Alexis Jazz ( поговори со мной или позвони мне) 07:34, 27 апреля 2021 года (UTC)

    @ Алексис Джаз : текущие уровни защиты являются: '(all users)', 'autoconfirmed', 'extendedconfirmed', 'templateeditor', 'sysop'. - ^{Обсуждение} xaosflux 09:56, 27 апреля 2021 г. (UTC)

  Если я правильно понимаю, перемещение файлов всегда разрешено только файловым операторам и администраторам. isaacl ( разговор ) 22:44, 26 апреля 2021 (UTC)

  Исаакл , ну, я тоже не мог ограничить его ботами, откатами или любой другой произвольной группой. Но я говорю о другой вики с отличиями в конфигурации. Я просто интересно , если это даже возможно , чтобы ограничить перемещение на страницу движителей прямо сейчас. - Alexis Jazz ( поговори со мной или позвони мне) 22:49, 26 апреля 2021 года (UTC)

  @ Alexis Jazz : в основном, мы могли бы убрать возможность перемещения страниц у сисопов и у всех других групп, кроме этой группы - но мы ни в коем случае не собираемся это делать; кроме того, все сисопы просто разрешили бы себе перетаскивание страниц, чтобы восстановить его, если мы не заблокируем его. Почему вы все равно хотите, чтобы сисопы не могли перемещать страницу? - ^{Обсуждение} xaosflux, 23:14, 26 апреля 2021 г. (UTC)

  Xaosflux , если вы снова прочитать первоначальное предложение, он на самом деле не очень указать техническое исполнение. (возможно, нечеткие намеки, но я не думаю, что это конкретно). Один из способов реализовать это предложение - это изменить каждую страницу, которая в настоящее время находится под защитой от перемещения сисопа indef, на защиту перемещения перемещения страницы indef (?). Если в настоящее время это невозможно, нам нужно сначала подать заявку на Phabricator. Я бы не отказался от Template :, Module: и страниц с высокой видимостью (например, Main Page ). Как я прочитал это предложение, оно применимо только к страницам, защищенным от перемещения, а не к страницам, которые также защищены от редактирования сисопом. - Alexis Jazz ( поговори со мной или позвони мне) 07:41, 27 апреля 2021 года (UTC)

  @ Alexis Jazz : Это возможно и потребует нескольких изменений: (1) создать еще один новый уровень защиты, (2) создать разрешение, позволяющее редактировать этот новый уровень защиты, (3) назначить это разрешение группам (вероятно, сисопам, ботам , переносчики страниц, персонал, стюарды, редакторы глобального интерфейса); (4) обновить политику защиты, чтобы указать правила относительно того, когда можно использовать новый уровень защиты (5) попросить администратора (возможно, с помощью бота) проверить и настроить все существующие страницы, защищенные только сисопом, и снизить их уровень защиты до нового уровня. при необходимости. Подумайте об этом - в частности, №5 отнимет много времени - и его можно сделать прямо сейчас, чтобы уменьшить ненужную защиту от перемещений только для сисопа. - ^{Обсуждение} xaosflux, 10:05, 27 апреля 2021 г. (UTC)

• Решительно возражать, это, по сути, еще одно предложение о разделении и бессмысленно. Если что-то защищено администратором, для этого есть причина, и совсем не потребуется времени, чтобы запросить снижение защиты. Разделение этого также сделало бы защиту от админки бесполезной, так что вам лучше предложить полностью удалить эту защиту (что я также против) TAXIDICAE💰 22:41, 26 апреля 2021 г. (UTC)
• Противостоять правильной проблеме, неправильному решению. Радикальное предложение: все страницы автоматически блокируются от перемещений, не связанных с перемещением страниц, а затем все страницы не защищены от перемещения. Вы просто не можете перемещать страницы, если только вы не перемещаете страницы. Юзер: 力(power ~ enwiki, π , ν ) 01:22, 27 апреля 2021 г. (UTC)

  Перемещение страниц (скажем, вы допустили опечатку или поняли, что использовали неправильное средство устранения неоднозначности или хотите использовать черновики пользовательского пространства) - это такая основная часть редактирования, что мы должны предоставить право почти каждому. (Вот что мы делаем сейчас: автоподтвержденные редакторы - единственные, кому разрешено перемещать страницы, в то время как IP-адреса и новые редакторы не разрешены). - Кусма ( t · c ) 09:09, 27 апреля 2021 г. (UTC)

  Очевидно, потребуется много мелкого шрифта; перемещение в пределах или за пределы собственного пользовательского пространства, очевидно, нормально, и вам, вероятно, понадобится что-то для опечаток при создании статьи. Но я вижу большой риск в вандализме, связанном с перемещением страниц, и очень мало вреда в том, что новые редакторы используют шаблон «перемещения» (с Twinkle) вместо того, чтобы перемещать сами страницы. Пользователь: 力(power ~ enwiki, π , ν ) 17:57, 27 апреля 2021 г. (UTC)

  Идея удаления неограниченного доступа новых пользователей к созданию страниц была поддержана более чем двумя третями из более чем 500 редакторов, прокомментировавших в 2011 году, и WMF все же потребовалось более семи лет, чтобы действовать по предложению, и то только в качестве ограниченное по времени испытание. Затем они произвольно отключили его и отказались включить снова без дополнительного обсуждения (что было численно 207-26 в пользу), и даже после этого несколько разработчиков пытались незаметно изменить билет, чтобы этого не произошло, или просто открыто отказались. работать над этим. Потребовалось, чтобы один из наших функционеров действовал в качестве менеджера проекта, несколько добровольцев enwiki держали разработчиков за ноги, а также вмешательство менеджеров WMF и члена правления, чтобы заставить его вообще двигаться вперед. Идея убрать еще одну базовую функцию редактирования у новых редакторов и так сильно ограничить ее:мягко говоря, вряд ли никуда поеду.Белка иванавектор ( ^{деревья} / _орехи ) 18:41, 27 апреля 2021 (UTC)

  Надо было просто использовать фильтр редактирования, например ptwiki;) ProcrastinatingReader ( обсуждение ) 03:35, 28 апреля 2021 г. (UTC)

  Нужно ли мне проверять, не было ли за последнюю неделю вандализма, связанного со скрытым перемещением страниц? Или кто-то еще (надеюсь) уже проверил это? В более широком смысле: я помню, когда у нас не было энциклопедии. Теперь он у нас есть. Инструменты, необходимые для создания энциклопедии с нуля, отличаются от инструментов, необходимых для ее редактирования. Юзер: 力(power ~ enwiki, π , ν ) 03:40, 28 апреля 2021 г. (UTC)

• Поддержка , переносчики страниц - это доверенные пользователи, которые должны продемонстрировать достаточную компетентность для перемещения защищенных страниц. EpicPupper 20:30, 27 апреля 2021 г. (UTC)
• Допустим, я согласен, что это неправильное решение. Большинству страниц не требуется полная защита от перемещения, доступная только администратору, но тем, кому она действительно нужна, она нужна. Фактическое решение представляет собой обзор полного перемещение защищенных страниц , чтобы отсеять страницы , которые не нуждаются в абсолютной высочайший уровень защиты для предотвращения движения. Библброкс ( разговор ) 21:02, 27 апреля 2021 (UTC)

  Некоторые предварительные результаты здесь: wikipedia: Запросите запрос # Неопределенные средства защиты от перемещений, размещенные давным-давно в статьях . - xeno talk 22:08, 27 апреля 2021 г. (UTC)

  Опубликовано для проверки: Википедия: Доска объявлений для администраторов # Обзор статей с неограниченной защитой от перемещения . - xeno talk 23:34, 27 апреля 2021 г. (UTC)

• Против согласно вышеизложенному. ~ HAL 333 20:34, 28 апреля 2021 г. (UTC)
• Противостоять, но моральная поддержка. Я согласен с Кусмой: сделайте больше админов, перемещающих страницы. Если серьезно, у меня есть проблемы с безопасностью и технические проблемы. При перемещении защищенной страницы защита дублируется. Если мы разрешим неадминистраторам перемещать полностью защищенные страницы, то внезапно перемещатели страниц смогут полностью защищать перенаправления, что создает множество потенциальных проблем, некоторые из которых похожи на то, почему protectтребуется право пользователя для редактирования с помощью защиты WP: CASCADE . - ГВП · · ро · дез 6:47, 29 апреля 2021 (UTC)
• Допустим, я согласен, что это тоже не очень хорошее решение. Здесь уже была замечена альтернатива - проверка текущих мер защиты от перемещений. Разделение того, что обычно является административными привилегиями, не должно происходить легкомысленно. - pandakekok9 ( разговор ) 07:51, 29 апреля 2021 (UTC)
• Как правило, выступайте против любого предложения о передаче требующих доверия разрешений только для сисопов существующим группам, не относящимся к сисопам, поскольку это либо снизит уровень доверия, практически необходимый для выполнения конфиденциального действия, либо увеличит уровень доверия, необходимый для получения ранее полезного разрешение с низким уровнем доверия. Это либо приводит к более высокому риску повреждения в областях, ограниченных сисопом, либо к меньшему количеству членов группы, которые будут использовать группу для выполнения исходных задач. ~ ToBeFree ( разговор ) 19:01, 4 мая 2021 г. (UTC)

Добавление местоимений к выдающимся фигурам [ править ]

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

Мы уже обсуждали это раньше. Для обычных местоимений (он или она) просто используйте их в тексте. Если испытуемый выразил свои пожелания по поводу использования местоимений в надежном источнике, то мы должны осветить это в тексте. Но не используйте шаблоны и не придумывайте ничего. Если писатели используют «они», непонятно, плохое ли это письмо или предметный запрос. Так что это должно быть четко указано в тексте статьи. Грэм Бартлетт ( разговор ) 07:59, 3 мая 2021 (UTC)

Википедия не предназначена для защиты интересов общества . Как бы некоторые люди этого не хотели и, возможно, преуспели в других отношениях, мы здесь не для того, чтобы выступать за социальные изменения, такие как «нормализация» местоимений. Мы здесь, чтобы описать мир таким, какой он есть, как можно более нейтрально. Наша наиболее подходящая социальная защита заключается в том, чтобы делать именно это: писать о мире таким, какой он есть, не игнорируя примечательные энциклопедические темы, которые исторически игнорировались. Но такие мелочи, как местоимения или группы крови, обычно не примечательны и не актуальны с энциклопедической точки зрения. Anomie ⚔ 11:53, 3 мая 2021 г. (UTC)

Вообще говоря, мы знаем пол и / или пол человека, поэтому можем использовать «он» или «она». Если это неизвестно - это было бы очень редко, я полагаю, но я имею в виду, что если мы описываем человека, который, я не знаю, вырезал Венеру Виллондорфскую или является анонимным блоггером, мы могли бы использовать "он или она" "возможно, и попробуйте использовать более конкретные местоимения в этих случаях (" резчик "," блоггер "). «Они» означают, что мы говорим о группе человека в целом. «Он был найден в районе, где жило Племя Багбоев, и они, вероятно, создали его около 2000 года до нашей эры. Резчик, кажется, был опытным для того времени, и он или она явно находились под влиянием культуры Woowoo». Замена «они были» во втором предложении на «он или она»меняет смысл. (Это также все еще заставляет некоторых людей цепляться за драпировки и при прочих равных условиях, что не очень удобно.)

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

Во всех спорных случаях предпочтения субъектов - это точка данных, и их, безусловно, стоит учитывать, особенно если человек жив. Но в конце концов мы решаем. У меня был предмет по имени "ML Something" (она называлась только своими инициалами), который хотел, чтобы ее имя было везде написано как "ML Something" - я думаю, спортивно. Некоторые источники сделали это, а некоторые нет, поэтому наш нормальный MoS превзошел ее желания. Если кто - то хочет быть известным как «х» или «heshe» или что там у вас, хорошо, но в основном мы хотим знать , что местоимения в Таймс оф Индия и Tribune Чикаго и т.д. использование.

И тогда система может сойти с рельсов. Кейинан Лонсдейл хочет, чтобы его местоимение было "дерево" ("Лондсдейл должен был появиться в" Рад видеть тебя , но дерево заболело ", я думаю). Нам определенно не нужна система, в которой мы должны использовать «дерево» в статье мистера Лондсдейла и так далее. Так что, может быть, на данный момент лучше не будет никаких правил. Герострат ( разговор ) 23:33, 3 мая 2021 (UTC)

Я не думаю, что предложение и замена, которые вы предлагаете, действительно меняют значение, хотя они создают некоторую двусмысленность: я ловлю себя на том, что спрашиваю: «Это единственное число, они или кто-то пишет на уровне средней школы ?» В большинстве случаев я нахожу их однозначными. Anomie ⚔ 12:22, 4 мая 2021 г. (UTC)

В Википедии было очень неблагоприятное решение по этому поводу: Village pump (idea lab) #Pronouns in Infoboxes . 🐔  Chicdat   ^{Bawk мне!} 12:33, 4 мая 2021 г. (UTC)

Как я говорю каждый раз, когда кто-то поднимает этот вопрос - если есть надежный источник информации, мы можем абсолютно точно указать предпочтение темы в статье, и мы делаем это последовательно. Если нет надежного источника, излагающего эту информацию (и нет, использование определенного набора местоимений при передаче в другом надежном источнике на самом деле не считается ИМО - источником, который явноотносится к субъекту, который сам определяет, что их местоимение будет необходимо), то мы не можем явно сказать «<x> заявила, что она использует« она / она »» или что-то подобное. В противном случае я не хочу привлекать особое внимание, потому что он постоянно является мишенью для вандализма в отношении статей о трансфолках и заставляет работать все сокращающееся меньшинство редакторов контента, которые вносят хорошие, проверенные правки в этой области. - а ^{они / они | спорить | вклад} 12:41, 4 мая 2021 г. (UTC)

• Мне это кажется разумным. Очевидно, что если кто-то не выразил предпочтения, его не следует использовать, но я не согласен с тем, что, если кто-то выразил предпочтение, всегда имеет смысл включить его в прозу статьи. Кроме того, поскольку мы так или иначе используем местоимения , простое использование местоимений не означает выраженного предпочтения. Я бы полностью отверг идею о том, что указание местоимений в любом случае является «социальной защитой». Это то, что делают некоторые люди и что Википедия старается уважать. Альтернативой информационному окну может быть шаблон типа {{ use dmy date }} (назовем его {{ использует местоимения они / их}}), для которого потребуется параметр цитирования, и он не повлияет на текст статьи, кроме добавления страниц в категорию, которые будущие редакторы должны принять во внимание. -Рододендриты ^{говорят} \\ 16:46, 13 мая 2021 года (UTC)

Контроль полномочий [ править ]

{{ Authority control }} - это шаблон с 1,86 миллиона включений. Обычно он добавляется к статьям масштабно и без разбора ( например, ) и визуально выглядит как набор странных слов, сброшенных вместе, часто не имеющих отношения к статье ( например , со ссылками, подобными этой ). Был недавно RfC здесь о визуальных улучшений, с подразделом обсуждали значение шаблона на всех, и грубой поддержки слом его. Закрытие предложило продолжить обсуждение этого. Я не думаю, что этот шаблон соответствует политике WP: NOTLINK или руководству Wikipedia: External Links :Целью Википедии не является включение длинного или исчерпывающего списка внешних ссылок, относящихся к каждой теме. Ни одна страница не должна содержать ссылки из статьи Википедии, если ее включение не оправдано в соответствии с этим правилом и здравым смыслом. Бремя предоставления этого обоснования лежит на человеке, который хочет включить внешнюю ссылку. Я не понимаю, почему этот шаблон вообще существует, не говоря уже о том, почему он массово добавляется в статьи? Для наших читателей это просто беспорядок, и, конечно же, нельзя сказать, что добавление десятков разрозненных, обычно бесполезных внешних ссылок соответствует политике. ProcrastinatingReader ( разговор ) 11:49, 4 мая 2021 (UTC)

Вы утверждаете, что предоставленные ссылки {{Authority control}}"бесполезны". Они - и, что более важно, информация, представленная шаблоном в его текущей форме - не являются. Таким образом, вся остальная часть вашей обличительной речи бесполезна. Энди Маббетт ( Свиноядное крыло ); Поговорите с Энди ; Редакции Энди 12:36, 4 мая 2021 г. (UTC)

Я полагаю, это субъективно, являются ли они «бесполезными». Да, по - моему такие вещи , как это бесполезно 99,9% читателей и 99,9% статей. Но объективно добавление ~ 10-30 внешних ссылок на статью, обычно к случайным ссылкам с машинными значениями данных, не может соответствовать требованиям WP: NOTLINK или WP: EL . Я также не понимаю, как редакторы могут проявлять «суждение и здравый смысл» относительно уместности каждой ссылки в данной статье, когда этот шаблон добавляется со скоростью несколько десятков в минуту (без одобрения бота; вероятно, нарушение WP: БОТПОЛ ). Видимо раньше был настоящий ботодобрено для этой цели на основе довольно сомнительного BRFA, в котором связанные обсуждения не показали надлежащего уровня (или любого) рекламы или широкого консенсуса. Я думаю, что уместно поднять этот вопрос перед сообществом в соответствии с завершением предыдущего RFC. ProcrastinatingReader ( разговор ) 13:09, 4 мая 2021 г. (UTC)

Полезность для вас может быть субъективной, но сама по себе полезность - нет. Энди Маббетт ( Свиноядное крыло ); Поговорите с Энди ; Редакции Энди 14:52, 4 мая 2021 г. (UTC)

Это новое определение цели (или полезности). Полезность зависит от контекста и человека, и обычно это не вопрос типа «да» или «нет», а вопрос более или менее (более или менее полезный для вас, полезный для большего или меньшего числа людей, для большего или меньшего использования) . Фрам ( разговорное ) 15:31, 4 мая 2021 (UTC)

Я никогда не пользовался парашютом и не планирую. Я бы не стал спорить «Парашюты бесполезны». YMMV Энди Маббетт ( Pigsonthewing ); Поговорите с Энди ; Редакции Энди 16:27, 4 мая 2021 г. (UTC)

Да, для блинов они бесполезны. Они пригодятся, чтобы выжить, выпрыгивая из самолета на высоте. Точно так же люди могут утверждать, что ссылки AC в наших статьях бесполезны. Такие утверждения сделаны в контексте, а не в пустоте. В этом случае они могут ошибаться, а могут быть и правы, но это не делает внезапной объективной меры полезной или бесполезной. «Бесполезно иметь их на enwiki, потому что они все у нас есть, и обычно гораздо больше (а иногда и лучше) в Викиданных в любом случае» является допустимой позицией, точно так же, как «полезно иметь их здесь, это экономит мне один клик» это действительная позиция. Просто отвергая чьи-то утверждения о том, что они бесполезны, потому что они объективнополезно ни в малейшей степени не способствовать дискуссии, не прислушиваться к тому, что говорит другая сторона, это просто занимает доктринальную, абсолютистскую позицию, которая имеет тенденцию либо раздражать людей, либо просто игнорироваться. Фрам ( разговорное ) 16:41, 4 мая 2021 (UTC)

Если провести аналогию, парашют очень пригодится в ВВС. Это не означает, что мы должны раздавать парашюты каждому человеку в ВВС, поскольку большую часть времени они бесполезны для большинства персонала ВВС. Можно утверждать, что парашют полезен для пилотов, поэтому мы также не должны отнимать парашюты у всех в ВВС. У нас должны быть парашюты там, где они полезны, и не иметь парашютов, где они бесполезны. Точно так же мы должны иметь авторитетный контроль там, где это полезно, и не иметь авторитетного контроля там, где он бесполезен. Прямо сейчас мы (или, скорее, несколько редакторов) повсюду устанавливаем авторитетный контроль. Это бесполезно. Возникает вопрос: где и где может быть полезен этот шаблон? Levivich  ^харасс / _гончая 19:03, 4 мая 2021 г. (UTC)

Одна из проблем заключается в том, что ссылки добавляются к статьям автоматически, независимо от того, актуальны они для наших читателей или нет. В то время как текущая переработка шаблона делает более понятным, что представляет собой каждая ссылка (что позволяет избежать большого недоумения), это не помогает решить проблему, с которой вы столкнулись, например, с Алехандро Родригесом (психиатром) , педиатром и психиатром из Венесолы. , ссылка на Чешскую национальную библиотеку [2], которая никогда не будет принята как простая внешняя ссылка. Я попытался (первый, маленький шаг) уменьшить этот беспорядок с помощью Template: Authority control (arts), который для статей, связанных с искусством, показывает только ссылки на авторитетный контроль, которые либо на английском языке, либо посвящены искусству (или, с добавленным параметром страны, имеют ссылку на страну темы статьи). Такие шаблоны также могут быть созданы для других предметов (например, по стране или языку, что нравится людям больше всего). Этот шаблон автоматически получит новый макет основного шаблона авторитетного контроля. Есть и другие варианты: удалить наименее полезные ссылки из шаблона авторитетного контроля или просто отказаться от него: но добиться такого результата будет нелегко, и перед тем, как делать такое предложение, вы должны убедиться, что у вас много представителей. примеры того, почему нам лучше без него. Одно лишь утверждение, что это бесполезно, вызовет встречные претензии, что это необходимо для объединенных библиотекарей мира и для некоторого программного обеспечения,где-нибудь, которые могут глупо использовать этот шаблон вместо ссылок в Викиданных.Фрам ( разговорное ) 12:53, 4 мая 2021 (UTC)

« {{Authority control (arts)}}» И, как и тех , кто балуется в чем - то они не правильно понимают, вы сделали правильный хэш его. Если, конечно, вы не хотите утверждать, что ни один художник, работающий как художник, не опубликовал ничего в академическом контексте? Или оформили обложку альбома? Энди Маббетт ( Свиноядное крыло ); Поговорите с Энди ; Редакции Энди 15:39, 5 мая 2021 г. (UTC)

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

"общий шаблон все еще можно использовать, если необходимо" Разве вы не использовали инструменты для массового удаления {{ Authority control }} и замены его своей вилкой - сейчас существует 14K экземпляров последнего, в основном, если не в основном ваши дела. Совершено без предварительного согласия сообщества. На скольких статьях вы оставили исходный шаблон по причинам, о которых я упоминал? Вы можете привести нам несколько примеров? Заметьте, я был бы впечатлен, если бы вам удалось изучить 14К статей на предмет таких нюансов. Или вы просто слепо поменяли шаблоны, не задумываясь о проверке, как человек, который балуется тем, чего не понимает должным образом ? Вы хоть знаете, из скольких из этих статей вы удалили идентификаторы, относящиеся к академическим публикациям или деятельности артистов по оформлению альбомов?Энди Маббетт ( Свиноядное крыло ); Поговорите с Энди ; Редакции Энди 19:02, 5 мая 2021 г. (UTC)

Вы выдвинули шаблон для удаления в феврале (полное недопонимание или искажение шаблона в вашей номинации), и он был сохранен. Из этого обсуждения, а также из комментариев в этом же обсуждении становится ясно, что многие люди видят в этом шаг в правильном направлении. И да, когда я заменяю шаблон, я проверяю статьи, в которых я это делаю. Это не значит, что я не делаю ошибок, но, например, из короткой « Категория: исландские художники» я пропустил Элинборга Халлдорсдоттира , Сёльви Хельгасона и Эдду Хейдрун Бакман . Фрам ( разговор ) 08:01, 6 мая 2021 (UTC)

Я никогда не понимал неправильно цель вашей вилки шаблона, которая явно состоит в том, чтобы обойти решения сообщества отклонить ваши попытки удаления и удалить из него популярные идентификаторы. Шаблон едва избежал удаления, несмотря на то, что большинство высказалось за его удаление, благодаря суперволу. Я попросил привести примеры замены шаблонов, пропущенных из-за академической публикации или оформления обложек альбомов ; ни один из перечисленных вами не соответствует этим критериям. Энди Маббетт ( Свиноядное крыло ); Поговорите с Энди ; Редакции Энди 13:05, 6 мая 2021 г. (UTC)

К сожалению, у меня нет списка статей, которые я не редактировал, с указанием причины, по которой я их не редактировал. И я больше не заинтересован в ваших недобросовестных публикациях. Я показал, что пропускаю статьи во время замены шаблонов по разным причинам. Не знаете, откуда вы взяли понятие «популярные» идентификаторы, есть ли у вас статистика, показывающая, какие идентификаторы более популярны, чем другие? Фрам ( разговорное ) 13:18, 6 мая 2021 (UTC)

• Я полностью согласен с ProcrastinatingReader здесь, во многих статьях, что это было добавлено в этот шаблон, служит не более чем беспорядком внешних ссылок. для какой части наших читателей GND ID чизкейка настолько важен, что его необходимо включить в статью? Как насчет Microsoft Academic ID жирафа или ID винта из библиотеки Национальной диеты ? На мой взгляд, этот тип структурированной информации идентификатора должен по большей части храниться в викиданных, поскольку он просто не так полезен для большинства читателей.
  Я хотел бы предложить провести здесь небольшой эксперимент - найти пару хорошо просматриваемых статей с шаблонами контроля полномочий с большим количеством идентификаторов на них, и для каждой статьи заменить шаблон контроля полномочий на фиктивный, где каждая ссылка фактически перенаправление по конвейеру на страницу, содержащую фактический шаблон авторитетного контроля и объяснение того, что происходит. Сравнивая просмотры страниц статьи и перенаправления, мы сможем получить приблизительное представление о том, какая часть наших читателей на самом деле использует ссылки в шаблоне. 192.76.8.91 ( разговорное ) 13:03, 4 мая 2021 года (UTC)
  • Мы склонны блокировать людей за вандализм. Кроме того, ваша точка зрения о жирафах и винтах не соответствует сути; ли {{Authority control}}следует использовать в таких статьях, другой вопрос , должен ли он быть использован на статьи о людях, или творческих работах, или - как здесь - на всех. Энди Маббетт ( Свиноядное крыло ); Поговорите с Энди ; Редакции Энди 14:52, 4 мая 2021 г. (UTC)
    • Угроза людям с помощью вандализма блокирует мысленные эксперименты, которые вовсе не вандализм, - не лучший способ вести дискуссию. Фрам ( разговорное ) 15:31, 4 мая 2021 (UTC)
      • Не стесняйтесь указать, где я угрожал кому-либо «блокировкой вандализма для мысленного эксперимента». Энди Маббетт ( Свиноядное крыло ); Поговорите с Энди ; Редакции Энди 16:27, 4 мая 2021 г. (UTC)
        • Да, это важный момент, будь то «мысленный эксперимент» или «предложение о реальном эксперименте». Вы угрожали кому-то блокировкой вандализма за добросовестное, конструктивное предложение. Опять же, это очень хороший способ заставить людей избегать обсуждений с вами, поскольку гораздо полезнее просто игнорировать вас. Фрам ( разговорное ) 16:41, 4 мая 2021 (UTC)
          • Не стесняйтесь указать, где я угрожал кому-либо "блокировкой вандализма". Энди Маббетт ( Свиноядное крыло ); Поговорите с Энди ; Редакции Энди 15:41, 5 мая 2021 г. (UTC)
            • «Мы склонны блокировать людей за вандализм». никому не грозит вандализм блоком? Это просто ваш способ поздороваться с IP, делающим конструктивное предложение? Дурак я. Фрам ( разговорное ) 15:51, 5 мая 2021 (UTC)
    • Я не знаю, почему вы угрожаете мне блоком, это совершенно ненужно и чрезмерно. Использование переадресации для отслеживания того, действительно ли читатели используют функции, - это то, что мы делали в прошлом, например, когда мы хотели узнать, действительно ли читатели использовали баннер ITN COVID-19, мы перенаправили весь их трафик через Coronavirus болезнь 2019 *, чтобы узнать, где трафик исходил из. Кто-то начал классифицировать эти типы переадресации с помощью {{ R from statistics redirect }} в начале этого года, и есть (очень неполный) проект политики их использования в Википедии: Статистические переадресации .
      Причина, по которой я специально привожу эту статью, заключается в том, что они иллюстрируют, почему я думаю, что этот шаблон получил такое огромное количество откликов и неоднократно упоминался здесь - шаблон без разбора добавлялся в статьи, по-видимому, без каких-либо размышлений о том, будут ли в результате ссылки актуальны для наших читателей. Я бы сказал, что ссылка на ORCID ID академика полезна (на самом деле, вероятно, достаточно важна, чтобы быть импортированной непосредственно в академическое информационное окно), есть очень хороший аргумент в пользу того, что есть смысл связывать художников с их записями в художественных базах данных и что такие вещи, как номера ISBN, должны быть включены в статьи о книгах. Делайте такие статьи, как Lego , Varnish и Electric light.действительно ли полезно иметь ссылки на базы данных «Классифицируйте все в известной вселенной», которые, в свою очередь, ссылаются на практически все публикации, связанные с этой концепцией? На мой взгляд, не совсем. 192.76.8.91 ( разговорное ) 15:49, 4 мая 2021 (UTC)

  Похоже, хороший способ измерить трафик ботов. ~ ToBeFree ( обсуждение ) 18:49, 4 мая 2021 г. (UTC)

• Я нахожу это очень полезным, когда смотрю (и редактирую) статьи. Это все равно, что предлагать избавиться от ссылок в ссылках, потому что они не соответствуют требованиям внешних ссылок - смешно. Майк Пил ( разговорное ) 13:28, 4 мая 2021 (UTC)

  Я уверен, что сказал это в предыдущих обсуждениях, но ссылки подтверждают текст в статье, а Википедия: внешние ссылки - нет, так что на самом деле это сравнение яблок с апельсинами. И WP: EL также прямо говорит: эти правила использования внешних ссылок не применяются к цитированию надежных источников в тексте статьи. ProcrastinatingReader ( разговор ) 14:12, 4 мая 2021 (UTC)

  Затем подумайте об этих ссылках для авторитетного контроля как о ссылках, если это помогает, предоставляя цитаты для заметности статьи. Майк Пил ( разговорное ) 14:16, 4 мая 2021 (UTC)

  За исключением того, что они этого не делают. Наличие записи, например, на Musicbrainz дает нулевую известность. Сочетание «цитирования» и «известности» в качестве оправдания шаблона, не предусматривающего ни цитирования, ни значимости, не является самым сильным аргументом. Фрам ( разговорное ) 14:18, 4 мая 2021 (UTC)

  За исключением того, что они делают, поэтому «авторитет» заключен в названии. Майк Пил ( разговорное ) 14:22, 4 мая 2021 (UTC)

  О, мальчик ... «Слово« авторитет в авторитетном контроле »происходит от идеи, что имена людей, мест, вещей и понятий авторизованы, то есть они установлены в одной конкретной форме». Ссылки, предоставленные в качестве контроля доступа, могут быть совершенно ненадежными, вики-сайты (например, Викиданные), что угодно. Авторитетный контроль - ужасное название, так как оно часто приводит к путанице и придает ссылкам привлекательность и надежность, которой они не заслуживают: но я надеялся, что люди, которые с ним много работают, по крайней мере знаю это. Фрам ( разговорное ) 14:34, 4 мая 2021 (UTC)

  Пожалуйста, скажите это, ммм, Британской библиотеке или Библиотеке Конгресса и т. Д. Майк Пил ( выступление ) 14:47, 4 мая 2021 г. (UTC)

  Что, этот Musicbrainz или Викиданные (не говоря уже о некоторых AC, используемых в Викиданных, таких как Quora, FindAGrave, ...), ненадежны, и наличие там записи не дает никакой известности? Что просто быть «авторитетным контролем» бессмысленно в этом контексте или для этих целей? Что LoC или BL получают свою важность и надежность не от того, что они являются авторитетным контролем, а от того, что они являются заслуживающим доверия учреждением, известным своей проверкой фактов, своими усилиями по получению правильной и нейтральной информации? Я сомневаюсь, что им вообще будет интересен этот разговор, но я без колебаний говорю им это, нет. В чем ваша риторическая мысль? Фрам ( разговорное ) 15:31, 4 мая 2021 (UTC)

  Если вы собираетесь упорствовать в намеренном недопонимании и пытаетесь вложить слова в мои уста, тогда просто уходите. Майк Пил ( разговорное ) 16:52, 4 мая 2021 (UTC)

Что ж, вы утверждали, что я должен был сказать что-то довольно неопределенное для BL и LoC, двух учреждений, которые я не обсуждал и не упоминал. Если вы не проясните, что я должен им сказать, я могу только строить предположения. У вас есть достаточно места, чтобы исправить меня и прояснить смысл, но это, конечно, зависит от вас. А до тех пор, похоже, вы пытались набрать какой-то риторический аргумент, и это имело неприятные последствия. Фрам ( разговор ) 08:16, 5 мая 2021 (UTC)

Хорошо, приятно осознавать, что, по вашему мнению, Британская библиотека и Musicbrainz одинаково надежны. Но я собираюсь пересмотреть свою политику - не отвечать на все, что вы говорите, это лучше для моего кровяного давления. Майк Пил ( разговор ) 09:09, 5 мая 2021 (UTC)

Для кого-то, кого беспокоит то, что люди вкладывают слова в ваш рот, когда они задают вам вопросы о том, что вы имели в виду, у вас наверняка нет проблем с тем, чтобы вставить неправильные слова мне в рот, не так ли? Я обсуждал MusicBrainz среди ненадежных AC, вики, проблемных: я обсуждал BL как один из важных и надежных (который мы все равно не используем в шаблоне AC, но что ж, вы подняли его, так что ... .): Я никогда не говорил и не думаю, что они даже отдаленно «одинаково надежны». Возможно, действительно будет лучше, если вы перестанете отвечать, так как вы не имеете особого смысла. Фрам ( разговорное ) 12:15, 5 мая 2021 (UTC)

• Но ... это не ссылки; они не проверяют никакой текст. Это внешние ссылки. Несомненно, этот аргумент равносилен отказу от WP: EL в целом. ProcrastinatingReader ( разговор ) 14:24, 4 мая 2021 (UTC)

  Они проверяют тему статьи. Довольно часто их также можно использовать для ссылок, особенно если вы расширили AC для памятников и т. Д. Я категорически против наличия внешних ссылок в статьях в целом, поскольку я согласен с тем, что внешние ссылки редко добавляют ценность, но для меня это не так. подпадают под эту категорию. Майк Пил ( разговор ) 14:28, 4 мая 2021 (UTC)

Но нет необходимости «проверять тему статьи» ... нам нужно только проверить информацию по теме, которую мы обсуждаем в статье. Blueboar ( разговор ) 11:27, 5 мая 2021 (UTC)

Но как вы это сделаете без такого авторитетного контроля [3] ? Или как иначе вы узнаете, что индийский футболист Мохаммед Салим (футболист) (1904-1980) (полное имя «Мохаммед Абдул-Салим Бачи Хан») - это то же самое, что и автор Мухаммад аль-Табиб Ибн Салим (1903-1980) кто опубликовал одну книгу в Тунисе в 1973 году? Без «авторитетного контроля» и Викиданных мы никогда бы этого не узнали, мы никогда не смогли бы проверить важность, значимость и достоверность этого удивительного факта! Они надежны и незаменимы! Фрам ( разговорное ) 12:38, 5 мая 2021 (UTC)

• Избавьтесь от него, если только кто-то не убедится в его полезности. Levivich  ^харасс / _гончая 14:20, 4 мая 2021 (UTC)
  • Чтобы расширить свой комментарий, я считаю, что такие утверждения, как «Я считаю полезным», бесполезны. Мне наплевать, что горстка редакторов считает полезным, и мы не должны принимать решения в рамках всего проекта на основе этого. Что никто не объяснил (пока) является то , что использование этого шаблона является: для чего используется шаблон? (Очевидно, это не для какой-либо цели WP: V или N, что, кажется, является единственным конкретным использованием, упомянутым до сих пор в этом обсуждении.) Глядя на приведенные выше примеры, такие как Giraffe, я с трудом представляю, для чего нужно иметь эти ссылки внизу этой статьи. Я понимаю, как можно связать статью автора с его записью в Worldcat или статью в книге с его списком LOC, но эти конкретные ссылки, кажется, лучше включать в информационное окно или какой-то конкретный шаблон для определенных тем, а не в этот одноразовый - универсальный шаблон авторитетного контроля, который у нас есть сейчас. Levivich  ^харасс / _гончая 18:53, 4 мая 2021 (UTC)
• Конечно, против избавления от него. Я использовал это. Я знаю людей, которые этим пользуются. Людям, работающим с данными и библиотеками, они нравятся, как только они понимают, что они есть. Противодействовать любой оценке, основанной на том, «какой процент читателей считает ее полезной» (как будто у нас есть какой-либо хороший способ узнать это помимо анекдотов). Большинство читателей не используют слишком много материалов, которые мы решили включить в Википедию, потому что мы не только пытаемся максимально заинтересовать наибольшее количество людей, но и предоставляем справочную работу, которая может стать первой. остановитесь для исследования и более глубокого изучения темы. -Рододендриты ^{говорят} \\ 14:42, 4 мая 2021 года (UTC)
• Также против избавления от него. Это очень полезно иметь в статьях, неразумно ожидать, что читатели обратятся к Викиданным. Здесь предпочтительнее включать информацию дискретным образом, что и происходит. Элли ( Обсуждение | вклад ) 15:30, 4 мая 2021 г. (UTC)
• Не возражайте против того, чтобы сразу избавиться от этого - информация явно полезна для некоторых читателей, и я не понимаю, как можно утверждать, что одна небольшая строка ссылок на данные в самом низу страницы каким-то образом мешает читателям. . Если да, то предлагал ли кто-нибудь перенести {{ авторитетный контроль }} на страницы обсуждения? Создайте авторитетный элемент управления Wikipedia: WikiProject и добавьте ссылки на баннер обсуждения этого проекта, который в определенных ситуациях будет автоматически сворачиваться, как и все остальные. Иванвекторская белка ( ^{деревья} / _орехи ) 15:52, 4 мая 2021 г. (UTC)

  Да, и об этом кричала обычная толпа викиданных. Шаблон Authority Control существует для того, чтобы прикреплять Викиданные к статьям, а не предоставлять полезную информацию человеку, читающему статью. Его ограниченная полезность для подавляющего большинства читателей в лучшие дни. Некоторые идентификаторы полезны для очень небольшой группы людей, просматривающих статью. Но затем, как указывал Фрам при создании своего шаблона искусства, из общего числа идентификаторов, доступных по данной теме, некоторые из них полезны, некоторые - бесполезны, а некоторых активно следует избегать (ненадежные сайты, созданные пользователями, такие как найти могилу). Шаблон Fram, который на самом деле стремился конструктивно применить AC к статье таким образом, чтобы сделать ее полезной, был номинирован на удаление.в еще одном подрывном действии Энди в отношении всего, что связано с викиданными. Как только вы поймете, что цель шаблона - интегрировать викиданные в статью, действия различных редакторов викиданных, пытающиеся предотвратить их полезное изменение, приобретают больше смысла. Меньше ссылок в шаблоне - меньше викиданных. Учитывая, что Wikidata соответствует стандартам Daily Mail, когда дело доходит до источников информации, вы можете понять, почему это раздражает. Только смерть заканчивает долг ( разговор ) 17:28, 4 мая 2021 (UTC)

  «Шаблон Authority Control существует для встраивания Викиданных в статьи» Этот шаблон появился на несколько лет раньше Викиданных. Есть ли какие-нибудь другие изобретения по борьбе с AGF, которые вы бы хотели обсудить? Энди Маббетт ( Свиноядное крыло ); Поговорите с Энди ; Редакции Энди 19:59, 4 мая 2021 г. (UTC)

  А как насчет левой боковой панели со всеми межъязыковыми ссылками и ссылками «на другие проекты»? А как насчет интеграции этого с новыми полями в Викиданных для хранения информации о ссылках? Мы можем ограничить доступные поля ссылок только теми, которые считаются полезными. Иванвекторская белка ( ^{деревья} / _орехи ) 13:35, 5 мая 2021 г. (UTC)

  Похоже, это может быть интересная идея, но у нас уже есть ссылка «Элемент Викиданных». Какую ссылку вы имеете в виду? ProcrastinatingReader ( обсуждение ) 13:40, 5 мая 2021 (UTC)

  Я имею в виду буквально ссылки, которые сейчас находятся в полях AC, просто поместите их вместо этого на боковой панели, в их собственный раздел, скажем, под языками. «Элемент Викиданных» - это просто ссылка на тему в Викиданных, не так ли? Я полагаю, что объединение AC с Викиданными также может быть хорошим подходом, хотя я бы предпочел, чтобы ссылки оставались видимыми из Википедии, а эта боковая панель - это много потраченного впустую места в любой статье, большей, чем заглушка. Иванвекторская белка ( ^{деревья} / _орехи ) 15:56, 5 мая 2021 г. (UTC)

• Я полностью за «Меньше Викиданных» ... вот что я хочу знать: как мы доберемся до «БЕЗ Викиданных»? Хотел бы это. Blueboar ( разговор ) 18:17, 4 мая 2021 (UTC)
• Это менее бесполезно, чем беспорядок внизу статей. Конечно, полезнее, чем ссылки на порталы. Я бы против избавления от этого. Геттарда ( разговор ) 19:12, 4 мая 2021 (UTC)
• Против того, чтобы избавиться от него. WP - это энциклопедия, которая может быть полезна исследователям и т. Д. Они появляются в самом низу статей и вообще не отображаются в мобильной версии. Не понимаю, чем это беспокоит читателей. Я также не думаю, что это нарушает WP: EL . В частности, применимы № 3 WP: ELYES , № 4 и № 6 WP: ELMAYBE, которые соответствуют ссылкам на авторитетное управление. - SD0001 ( разговорное ) 20:41, 4 мая 2021 г. (UTC)
• Oppose Authority control явно полезен для тем об авторах, исследователях, переводчиках и т. П., Предоставляя авторитетный список фондов в крупных библиотеках, таких как Библиотека Конгресса . Поскольку большинство наших читателей пользуются мобильным интерфейсом и не читают последние статьи, это идеальное место для серьезных исследователей и ученых, которые поймут и воспользуются им. Эндрю 🐉 ( разговорное ) 20:54, 4 мая 2021 (UTC)
• Поддержите либо избавление от него, либо серьезное снижение его визуальной подписи, в настоящее время он добавляет ненужный беспорядок в нижнюю часть страницы. Кажется, наиболее убедительным аргументом в пользу его сохранения является то, что некоторые опытные редакторы считают его полезным при исследовании темы статьи, заявив, что редакторы, скорее всего, могли бы перейти к Викиданным. Если требуется еще одна ссылка на Викиданные, возможно, измените шаблон на что-то похожее на {{ Commons }}, которое могло бы скрытно ссылаться на Викиданные внизу страницы, в отличие от текущего беспорядка, подобного навигационному ящику, который только отвлекает от фактического средства навигации. Кавалерист ( разговор ) 23:33, 4 мая 2021 года (UTC).
• Мы снова вернулись к этому крестовому походу? Думаю, на самом деле ничего не меняется. - Th е DJ ( разговор • вклад ) 13:21, 5 мая 2021 (UTC)
• Против того, чтобы избавиться от него. Это полезно для некоторых, в том числе и для меня, но не мешает другим. - Герда Арендт ( разговорное ) 15:46, 5 мая 2021 г. (UTC)
• Слабые противники - в общем, я не думаю, что их существование отрицательно. Я считаю, что большинство читателей в любом случае читают только наводку, и кажется вероятным, что чем дальше читатели заходят в статью, тем больше они интересуются (чистое предположение, но, возможно, не слишком много размышлений). Если они каким-то образом оказываются внизу страницы, предоставление ссылок на другие базы данных на самом деле не кажется негативным, но, надеюсь, это может полностью удовлетворить интерес читателя. Честно говоря, это, кажется, стало (некоторыми) аргументом в пользу «мне это нравится» и «мне это не нравится» - но у меня возникли проблемы с объяснением того, насколько аккуратно сохраненный список ссылок на базы данных находится в таком ужасном состоянии. необходимость удаления. Я понимаю, что некоторым людям не нравится иметь такое количество ссылок; Думаю, ограничение этого - отдельный разговор,но тот, который определенно имеет свои достоинства.Aza24 ( разговорное ) 15:59, 5 мая 2021 (UTC)
  • Я думаю, что это комбинация (для популярных страниц, конечно) слишком большого количества ссылок, часто имеющих ограниченную ценность (что я пытаюсь решить с помощью чего-то вроде Template: Authority control (Arts) ); море непонятных аббревиатур, за которыми следуют бессмысленные числа (которые мы сейчас решаем в основном шаблоне); и нежелание иметь много ссылок, которые на самом деле не проверяются и которые могут быть подвергнуты удаленному вандализму (см., например, мой пример выше Мохаммеда Салима (футболиста), у которого есть AC-ссылки для другого человека с таким же именем и почти с тем же годом рождения и смерти: это объявление с добавлением бота в Викиданные и добавление полубота здесь, и в течение 2,5 лет никто не замечал этой проблемы, вероятно, потому, что никто не использовал их в первую очередь). Замена локального редактирования и обслуживания, выполняемого человеком, удаленным редактированием, поддерживаемым ботами, часто приветствуется сторонниками как гораздо более безопасное, лучшее и надежное: но слишком распространенные контрпримеры сомнительной, бесполезной или просто неправильной информации добавляются и ускользают от проверки в этот способ вызвал сопротивление и привел к группе людей, которые предпочли бы иметь как можно меньше материалов на основе Викиданных в enwiki. Фрам ( разговорное ) 16:12, 5 мая 2021 (UTC)
    • Я не знаю, Фрам, похоже, что обе основные проблемы, которые вы представляете, имеют хорошие шансы на то, чтобы их разрешить. Из того, что я мог сказать при обсуждении аббревиатуры (которая была прекрасно представлена), за такой вещью стоит явный консенсус; TFD для Ac Art мог привести к удалению, но если бы вы внесли сюда предложение о наличии такой вещи для различных тем, у него также были бы большие шансы на успех. Я просто думаю, что люди придают слишком большое значение тому, насколько "грязно" это выглядит; как я уже сказал ранее, большинство читателей вообще не ищут туда, и те, кто, вероятно, все равно ищут дополнительную информацию. Я впечатлен тем, что вы нашли Мохаммеда Салима (футболиста)пример - довольно случайный ...! - но я не знаю, есть ли у нас какие-либо надежные данные, чтобы доказать, что такого рода вещи случаются особенно часто или чаще, чем наши собственные беспорядки в EnWiki, такие как Абу-Али Урбути . Aza24 ( разговорное ) 16:27, 5 мая 2021 (UTC)

  Особенно в таких заглушках, как Special: Permalink / 1019401732, он массово вторгается в пурпурную рамку без необходимости прокрутки вниз. Нижняя часть статьи - это WikiSpeak, где можно сбрасывать много случайных вещей, и это одновременно отвлекает и выглядит непрофессионально. Хотя, действительно, аргументы keep - «Мне нравится», аргументы удаления - нет; WP: NOTLINK - это политика, и WP: EL также говорит, что длинные списки ссылок в статьях неприемлемы.Политика не содержит «списка ссылок на базы данных» в статьях, особенно когда они массово добавляются к 1,8 миллионам статей без четкого предварительного согласия на это. Меня не волнует весь аргумент Викиданных (и я думаю, что WD - хорошая идея), я был бы также недоволен этими полями, если бы данные хранились в enwiki. ProcrastinatingReader ( разговор ) 16:31, 5 мая 2021 (UTC)

  Я действительно не понимаю, почему в центре моих аргументов вообще стоит «нравится» или «не нравится» - это кажется чистым обобщением. Очевидно, что есть что сказать о статус-кво, поэтому утверждение, что консенсуса никогда не было, кажется немного сомнительным. Прошу прощения, но я просто не считаю коробку навязчивой, и, во всяком случае, я считаю их полезными в моем вышеупомянутом примере. Но причина, по которой мой противник "слабый", заключается в том, что я не вижу смысла в удалении шаблона, когда многие проблемы можно было бы исправить художественным способом AC и / или способом акронима, последнее из которых, вероятно, произойдет в любом случае. . Aza24 ( разговорное ) 16:56, 5 мая 2021 (UTC)

Фрам хорошо обобщает мою негативную реакцию на Викиданные. Для протокола, я ДЕЙСТВИТЕЛЬНО думаю, что Викиданные - полезный проект ... Я просто не думаю, что он должен быть переплетен с Википедией. Я бы не стал возражать против относительно ненавязчивого сообщения, в котором говорится: «В нашем родственном проекте, Wikidata, есть материалы, связанные с этой темой» со ссылкой на соответствующую страницу WD. Я возражаю против импорта этого «материала» в статьи WP. Мой антагонизм, вероятно, проистекает из того факта, что я считаю, что WP должен быть ориентирован на текст , а не на данные . Я рассматриваю эти «данные» AC как нежелательный беспорядок ... что-то, что принадлежит WD, но не то, что следует импортировать в WP.

Итак, мой вывод: ссылка на WD ... не импортировать из WD. Blueboar ( разговор ) 16:49, 5 мая 2021 (UTC)

@ Blueboar : «Я думаю, WP должен быть ориентирован на текст, а не на данные» - текст - это то, что WP делает лучше всего, данные - это то, что WD делает лучше всего. Я бы хотел видеть приличное слияние этих двух: вместо того, чтобы пытаться обрабатывать данные в тексте, как мы делаем с множеством шаблонов / информационных ящиков, используйте для этого WD. К сожалению, есть люди, которые думают о ядерной угрозе и хотят полностью избавиться от использования WD, что является позором, вызывает множество ненужных аргументов и, как правило, относится к 1980-м годам (подумайте о том, сколько веб-сайтов используют базы данных на своей внутренней стороне). Спасибо. Майк Пил ( разговорное ) 17:08, 5 мая 2021 (UTC)

Если вы предлагаете перенести все информационные окна и большинство наших шаблонов на Викиданные ... Я поддержу. Инфобоксы и шаблоны вызывают здесь половину споров, так что WD приветствует их! Что касается 1980-х годов ... если вы имеете в виду золотой век, когда люди понимали разницу между энциклопедией и альманахом, то да ... Все для этого! А еще лучше ... мы могли бы попробовать в 1960-х годах - когда все работало аналогично, но работало хорошо. Blueboar ( разговор ) 17:35, 5 мая 2021 (UTC)

• Уменьшение или удаление поддержки. Согласно OP, WP: внешние ссылки четко указывают, что EL должны иметь отношение к статье. Тот факт, что объект просто существует в какой-то другой базе данных, не означает, что мы должны включить эту ссылку на его страницу в Википедии. EL следует курировать по каждой статье или, возможно, по теме / группе / категории, но нынешний подход «один размер для всех» не подходит. Если необходимо сохранить статус-кво, WP: внешние ссылки должны быть обновлены, чтобы обеспечить (почти) универсальное включение ссылок AC. - М. Нельсон ( выступление ) 20:25, 5 мая 2021 г. (UTC)
• В большинстве случаев я не возражаю, чтобы это было внизу (и хотя мне не нравится это имя, похоже, это правильный технический термин в библиотечном деле). Он находится внизу статьи вместе с навигационными блоками, которые мой мозг приучен полностью игнорировать. Тем не менее, для статей с большим количеством записей AC это становится немного шумным, и я думаю, что свертывание шаблона или использование более целевых ссылок, таких как шаблон ACarts, являются разумными способами продвижения в таких случаях. Мы должны хорошо интегрироваться с базами данных и викиданными, но нам не нужно прибегать к подходу «все или ничего». - Кусма ( t · c ) 13:30, 6 мая 2021 г. (UTC)
• Поддержка удаления или исправления Я выступаю против включения машинной информации в области, предназначенные для человеческого глаза. Этот шаблон представляет списки идентификаторов машин, которые могут прочитать только компьютеры, и предоставляет эту информацию человеческому глазу. Я вообще против использования опубликованных идентификаторов в Википедии, так что это также относится и к информационным ящикам, которые иногда собирают этот контент. Нет причин управлять информацией о машинах в Википедии, и основная коллекция этого в любом случае должна быть в Викиданных. Насколько он есть в Википедии, он должен быть представлен как читаемый человеком текст. Blue Rasberry (разговорное) 15:45, 6 мая 2021 (UTC)

  Голубая малина, это удивительно луддитская точка зрения, исходящая от человека, который так много вкладывает в онлайн-энциклопедию. Больше беспокоит ваша характеристика информации; это не кажется (мне) «машинной информацией» больше, чем URL-адрес или телефонный код города. Это не машинные идентификаторы, которые могут читать только компьютеры , они просто не делают ничего полезного для большинства людей. Они, конечно, ничего для меня не делают. Когда вы говорите, он должен быть представлен в виде читаемого текста человека , я думаю, «это есть , но это не человек (легко) использовать текст». Лично мне это не нужно. Но я могиспользуйте его (хотя я человек), если у меня возникла потребность / интерес. -  Джон Фром Пинкни ( разговор ) 18:51, 6 мая 2021 года (UTC)

@ JohnFromPinckney : Я утверждаю, что ни один человек не должен читать или вводить идентификатор, за исключением редких случаев сбоя в повседневных технологиях. В настоящее время в шаблоне написано что-то вроде « SNAC : w6zm66qw ». Я не возражаю против ссылки, но машинный код - это произвольный заполнитель, не предназначенный для рассмотрения людьми. Если нам нужны произвольные заполнители, мы могли бы использовать любую альтернативу, например ссылку на информацию с эмодзи для информации о вики-статье в базе данных. " 📃 SNAC«Мы могли бы, вероятно, перечислить несколько вариантов дизайна. Я признаю, что, как вы говорите, человек мог бы предположить это, но если бы я сделал предположение, я бы сказал, что частота ввода идентификатора человеком составляет менее 1 из 5 миллионов использований. Ибо эти миллионы других читателей, это кажется плохим дизайном, чтобы подвергнуть их компьютерному коду. Blue Rasberry (разговор) 15:39, 7 мая 2021 (UTC)

• Вопрос к тем, кто считает ссылки AC полезными: не могли бы вы рассмотреть примерный сценарий, в котором вы бы использовали эти ссылки? например, «Я перехожу к статье X в поисках информации Y. Я перехожу по ссылке Z авторитетного контроля, а затем ...». Я один из тех, кто считает эти ссылки совершенно непостижимыми, но я хочу лучше понять другую сторону. Колин М. ( разговор ) 17:08, 7 мая 2021 (UTC)
• Противостоять так много , как это голосование, я противостоящие изменения. Существует 1,8 миллиона таких шаблонов, и я уверен, что по крайней мере 200 тысяч из них явно приносят чистую прибыль. Некоторые люди могут сказать: «это всего лишь 10%», но это еще много улучшений. Были бы полезны некоторые улучшенные рекомендации относительно того, где используется авторитетный контроль; Я не уверен, что сейчас есть какие-то рекомендации. Улучшения пользовательского интерфейса (например, переход на боковую панель) также могут помочь. Юзер: 力(power ~ enwiki, π , ν ) 17:18, 7 мая 2021 г. (UTC)

Резюме идей [ править ]

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

• Избавьтесь от этого полностью
• Проведите A / B-тест для измерения использования (подробно описано в предложении IP) и действуйте соответственно.
• Ограничьте использование этого шаблона «соответствующими статьями» (необходимо определить критерии)
• Другой способ позволить пользователям, которые хотят увидеть шаблон, увидеть его. Например, можно использовать гаджет с подпиской, чтобы сделать поля видимыми.
• Переместите его на боковую панель. Возможно, в форме, подобной странице Цитировать эту страницу
• Измените политику, чтобы сделать этот шаблон допустимым. Сделаем ли мы исключение только для этого шаблона или какого-то «общего принципа» этого шаблона, или, возможно, рассмотрим полное удаление политики, если по ней нет консенсуса.

Как нам изменить эти идеи, чтобы перейти к RFC? Какие идеи наиболее жизнеспособны? ProcrastinatingReader ( обсуждение ) 13:23, 6 мая 2021 (UTC)

Выше также предлагалось поместить его или что-то подобное на боковой панели. Майкл Мэггс ( разговор ) 13:47, 6 мая 2021 (UTC)

Спасибо, добавил. ProcSock ( разговор ) 13:59, 6 мая 2021 (UTC)

Или сделать его автосвертывающимся? Фрам ( разговорное ) 13:52, 6 мая 2021 (UTC)

• Против. С самого начала было сказано, что «{{ Authority control }} - это шаблон с 1,86 миллионами включений». Это говорит нам о том, что шаблон уже разрешен и широко используется. Кажется, что это не проблема, которую нужно исправлять, поэтому дальнейшее обсуждение не требуется. См. WP: CREEP . Эндрю 🐉 ( разговорное ) 15:54, 6 мая 2021 (UTC)

  @Andrew Davidson: Two issues with this argument. First, WP:CREEP is about policy creep. Here we already have a policy that isn't being followed. Second, WP:FAIT is not an excuse. In the CS1 parameters RfC the community seemed to show great concern with bots or WP:MEATBOTs altering articles at scale without wider community input. There is no evidence presented that its installation to 1.8 million articles had consensus, or that the wider community actually thinks this template at this scale adds value for readers. In any case, if this is deemed acceptable then WP:NOTLINK needs to be amended, because then that would not be accurately reflecting consensus. ProcrastinatingReader (talk) 16:44, 6 May 2021 (UTC)

  Consensus can change. It used to be a widely followed convention to wikilink dates and years whenever they appeared. Fortunately, the community changed its mind, and dates were de-linked en masse. Colin M (talk) 17:01, 7 May 2021 (UTC)

• "Amend policy to make this template permissible. " It is mischievous at best to imply that this massively-used template is against current policy. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:28, 7 May 2021 (UTC)
• One point no one has seem to made yet: in the old days, {{Authority control}} was de facto limited to biographies, and this made sense. People tend to have written books or created works of art etc. and that's what most of these authorities catalogue. It makes sense to want to access a library record of a writer's corpus and that's what {{Authority control}} makes possible. It also eliminates the need to fight over which library search links are relevant enough for a particular biography to be included in an EL section as this varies by the nationality, influence and languages of authors. Many people above are questioning the utility of seeing identifiers for a topic like cheesecake. But for biographies, they are essential and I'm convinced that {{Authority control}} is the best way to handle the issue. – Finnusertop (talk ⋅ contribs) 10:30, 7 May 2021 (UTC)

  We only have 1 million BLPs. Even if every BLP had AC, at least another million are not BLPs. Further, many of these "Authority controls" are just blank pages. They aren't lists of the published works of an individual. ProcrastinatingReader (talk) 11:19, 7 May 2021 (UTC)

Authority Control - asking a slightly different question[edit]

Reading all the discussion above, I would like to ask a slightly different question than was originally asked. Let’s assume that Authority Control data is useful to at least some of our readers, and that we DO want to help them to find it. The next question then becomes:

• Should Authority Control data be placed DIRECTLY into Wikipedia articles, or should we instead LINK to an exterior site (such as Wikidata) where the data is located?

In both methods, a reader looking for AC data will find the data... it is more an issue of HOW and WHERE they find it. Please share your thoughts. Blueboar (talk) 21:00, 6 May 2021 (UTC)

• Link to Wikidata would be useful. It could tell the reader what the link leads to (like "other database entries"), and would take up less room. That comes at the cost of an extra click, but I think that's a good trade off, because most readers won't use this, so the reduced clutter benefits all and the extra click only inconveniences some. Levivich ^harass/_hound 21:15, 6 May 2021 (UTC)

  Articles do already have a link to Wikidata. To pick a random article – this has a AC template which gives 6 links: GND, LCCN, NKC, SUDOC, VIAF, WorldCat Identities. The sidebar also has a link under Tools called Wikidata item which, unsurprisingly, links directly to the Wikidata item. The Wikidata page then has a section at the end called Identifiers which lists a massive 39 links. Not sure why the AC template selects those 6 links out of the 39 possible ones. It might be better to have a sidebar link (like the Page information link?) that is to a local page that acts like an expanded AC template and then includes a link to Wikidata. The Wikidata layout is not at all friendly, so an intermediate local page would be a chance to explain things more fully and provide links to other information about the identifiers — GhostInTheMachine ^{talk to me} 21:43, 6 May 2021 (UTC)

• Support – link to WikiData suffices. As it happens I've been experimenting with this some time ago, see e.g. Minuets in G major and G minor#External links (first right-aligned box of this section). --Francis Schonken (talk) 08:56, 7 May 2021 (UTC)
• Great idea, strong support. As Francis Schonken's example shows (convenient edit conflict), we treat Commons the same way. We don't show a gallery of images curated by Commons on every Wikipedia page; WP editors individually select the media that are relevant to the encyclopedia article and include them where helpful to the article, and provide a link to the full selection at Commons at the bottom of the page. For AC, if editors decide specific links are particularly relevant to a given article, the link should already be included as a reference or external link (e.g. WP:ELLIST); if a reader would like the full selection of connected resources, they should navigate to the project which specializes in connecting things. -M.Nelson (talk) 09:21, 7 May 2021 (UTC)
• I'd support this, but only in the form of an external link template like {{commons}}. The buried sidebar link is not visible enough, and I understand sidebar links are not visible at all on mobile. Ivanvector's squirrel (^trees/_nuts) 12:39, 9 May 2021 (UTC)
• oppose This is deletion in disguise. Mike Peel (talk) 12:46, 9 May 2021 (UTC)

Yes and no... yes, shifting AC from being DIRECTLY listed in WP articles to being INDIRECTLY linked would make the current template obsolete (and thus likely to be deleted)... but we would be replacing that template with an INDIRECT link (similar to our link to commons for images). This would NOT delete AC, just change WHERE the information is hosted (at WD instead of at WP), and HOW it is accessed (via an indirect link instead of a template). Blueboar (talk) 13:36, 9 May 2021 (UTC)

No, it's deletion, plain and simple. Compare with the current situation of the template + the sidebar link. The information is already hosted at Wikidata, it's different ways of displaying it. Mike Peel (talk) 13:51, 9 May 2021 (UTC)

How is it deletion when the information can still be easily accessed? Blueboar (talk) 14:00, 9 May 2021 (UTC)

The template is still deleted from the articles and the content no longer shown in the articles, no? Wikidata's user interface is designed more for editing than viewing, it's normal that templates like this one reformat the data so it displays better. Mike Peel (talk) 14:40, 9 May 2021 (UTC)

Ah, Ok... you are focused on the visual aspects while I am focused on the functional aspects. Fair enough. I still don’t see the suggestion as a “deletion”, but I do understand how you might. Blueboar (talk) 15:35, 9 May 2021 (UTC)

• I think the idea of linking to Wikidata has merit, but also think that Mike makes a good point: Wikidata entries aren't really designed to be casually browsed; they're to be queried. Maybe a possible solution would be to develop a template on Wikidata which presents identifiers in a neat way like our authority control template tries to do, and we link to that. Or I guess just use this template on Wikidata? I'm not sure I'm entirely sold on replacing it with a link, but if the original goal here was to make it more user-friendly, just linking to a Wikidata item doesn't achieve that. — Rhododendrites ^talk \\ 16:45, 9 May 2021 (UTC)
  • Ghost mentioned above the idea of linking to an intermediate page that queries WD and presents the information in a readable format (kind of like our Page Information link). Whether that intermediate page should be hosted on enwiki or WD I'm not sure, but I think this idea has promise. Levivich ^harass/_hound 16:51, 9 May 2021 (UTC)
    • What if an {{authority file}}-like box could link to a subpage which would import the links from Wikidata and present them in a standardized reader-friendly format? I'm sure someone who knows what they're doing (i.e. not me) could whip up a template for this purpose pretty easily. Ivanvector's squirrel (^trees/_nuts) 13:20, 11 May 2021 (UTC)
• Oppose I have dabbled with Wikidata but don't find its interface and content to be easy. The current {{authority control}} template is comparatively straightforward and simple and so we should continue to use it. Andrew🐉(talk) 16:35, 10 May 2021 (UTC)

Unique identification and/or useful links?[edit]

the {{Authority control}} box currently serves the double goal of:

• unique identification of an article topic
• adding a set of links to the bottom of an article

There may be other objectives for the template (feel free to mention those), but I suppose the above two are the main ones. These two goals are not mutually exclusive, and accomplishing both in a single pass seems commendable. In practice, however, they may be less compatible than anticipated: e.g., cleaning up excessive external links WP:EL-wise may hamper the unique identification goal. Trimming excessive identification (e.g. according to systems that hardly ever use an English-language word) may lead to removal of more useful external links. So it might be a good step to see whether we can find consensus on any of these:

1. Both main goals have equal (high) importance: inclusion/exclusion of linked identifiers should seek a middle way of what optimizes both goals with as little as possible drawback for either goal.
2. External links in the box are subject to the WP:EL guidance: only those external links that are most useful to a general readership should be retained, discarding those that would not normally otherwise be included in an external links section.
3. Unique identification, as in authority control, is paramount, and should show as many connections as useful for the precise identification of the article's topic.
4. Neither goal is very suitable for an {{Authority control}}-like box: external links should be included elsewhere in the article (e.g., in references grouped at the bottom of an article, and/or in a usual format adopted for lists of external links), not in a type of box that was designed after models for grouping internal links (navbox format), and unique identification is rather something for Wikidata (no need to echo that in English Wikipedia: a link to the Wikidata "authority file" for the article suffices).

Rather than exclusively mentioning which of the above options is or are closest to what you think best, it would be interesting to know how you would accomplish the goal(s) you'd like to see pursued first. And additional ideas are welcome too, that is, inasmuch as they help to distinguish which should be the main goals of the template. --Francis Schonken (talk) 12:32, 7 May 2021 (UTC)

Comments:

• Option 4 – an {{Authority control}}-like box is neither very suitable for external links, nor for unique identification. Re. how to accomplish that: see my proposal in #Authority Control - asking a slightly different question above. If forced to say which of both goals mentioned in the OP of this subsection should be most prominent for the box, then I'd think the "unique identification" goal: external links already have designated places elsewhere in the article – "authority control" is the template's USP. --Francis Schonken (talk) 12:32, 7 May 2021 (UTC)

• On the subject of WP:EL - External links in the box are subject to the WP:EL guidance: only those external links that are most useful to a general readership should be retained - the guidance about keeping them to a minimum is about the external links section, not all external links on a page. The page doesn't account for authority control, but does explain that there are parts of the page where this guidance doesn't apply (citations, not to mention other namespaces). I suppose we should really have some information about it there, because we otherwise don't include multiple ELs like that and don't have another template which operates similarly. In other words, when that guidance was written, the EL section would just be a long list and not a separate, standardized template with a particular purpose. The relevant bit is really just ELNEVER. As such, either #2 should be rewritten or another option, I guess: The links are a major goal, and should not include any links along the lines of ELNEVER, but should be subject to a different kind of inclusion evaluation than links presented as normal in the external links section. — Rhododendrites ^talk \\ 13:02, 7 May 2021 (UTC)
• I won't pretend to know the answer, but this is the question that needs answering before we get on to technical details of implementation, i.e. what is authority control for? I had always assumed that the answer is the first of Francis's points, which is a very difficult question for libraries, but the way that this template is used seems to lean more towards the second. If it is to provide a single unique identifier than we should only include organisations that actually do some serious fact-checking into the issue. I have the feeling that some of the organisations linked don't do that but only use what others have done or vague feelings that namesakes, or alternative names possibly for the same person/thing, are or are not the same. If the purpose is to provide external links to organisations with information about a topic then I don't see why those links should be treated any differently from links in an "external links" section. Phil Bridger (talk) 16:07, 9 May 2021 (UTC)

Different color for featured articles?[edit]

What if we had different colored links for featured articles. For non-existent articles, we have red, but I think having different colored links to highlight colored articles would make it quicker to find a featured article related to another topic. Terminator21738 (talk) 20:36, 4 May 2021 (UTC)

You might be interested in User:Anomie/linkclassifier.js and User:Anomie/linkclassifier.css, which change the default colour of wikilinks depending on the target page, and can be customized to some extent although I've never bothered to change the default settings. Also, in your preferences under Gadgets -> Appearance, you can enable "Display an assessment of an article's quality in its page header" which changes the colour of the page's title depending on its assessment. Ivanvector's squirrel (^trees/_nuts) 23:12, 4 May 2021 (UTC)

• Is there a color you have in mind? Per the (routinely ignored) instructions at the top of this page, it is supposed to be for concrete proposals. {{u|Sdkb}} ^talk 23:35, 4 May 2021 (UTC)

New user landing page should link to search results[edit]

I think the new user landing page should have a link to search results for whatever page name they typed, just like the regular landing page. A new user is less likely to be qualified to create a page than a regular user, yet the current system makes them less likely to see the other alternative (that a page exists for what they're looking for under a different name). —Lights and freedom (talk ~ contribs) 01:03, 5 May 2021 (UTC)

I'm sorry I have to ask this, but: what is "the regular landing page"? Can you link an example of it? — JohnFromPinckney (talk) 02:44, 5 May 2021 (UTC)

@JohnFromPinckney: The page which you get when you go to any article that does not exist. —Lights and freedom (talk ~ contribs) 04:46, 5 May 2021 (UTC)

That page is actually Template:No article text. Feel free to make edit requests for it. It's indeed possible for the template to distinguish new users using the CSS classes for user groups. – SD0001 (talk) 08:16, 5 May 2021 (UTC)

@SD0001: There is also this page Wikipedia:New user landing page, where new users with an account get directed. —Lights and freedom (talk ~ contribs) 17:33, 5 May 2021 (UTC)

Okay, Lights, thanks. I just went to https://en.wikipedia.org/wiki/Farfle in this browser (signed in) and in another, anonymously. The only difference I detect is the "Start the Farfle article..." vs "You cannot create this article", owing to the fact that I am autoconfirmed here. But they both have "Search for "Farfle" in existing articles", and I don't agree (or don't see) that they are less likely to see that a page exists for what they're looking for under a different name. I mean, I guess, that I don't see what you're proposing. Both "landing pages" already have a link to search results for whatever page name they typed, which is what you seemed to be asking for. — JohnFromPinckney (talk) 12:32, 5 May 2021 (UTC)

@JohnFromPinckney: New users with an account get directed to this page: Wikipedia:New user landing page. I'm not sure if it lasts until they're autoconfirmed, or something else. —Lights and freedom (talk ~ contribs) 17:32, 5 May 2021 (UTC)

Ah, didn't know. I was only new just the one time, and that was long ago, before that page was created. — JohnFromPinckney (talk) 19:45, 5 May 2021 (UTC)

This sounds easy enough to incorporate, but I don't feel like unwinding the workflow right now - can someone make clear the workflow steps that actually lead an editor to seeing Wikipedia:New_user_landing_page? That is, exactly what do they have to type/click on, in what order. (Might be good to document that at Wikipedia talk:New_user_landing_page). — xaosflux ^Talk 13:16, 6 May 2021 (UTC)

Think this was somehow routed through the ACWorkflow - just don't remember the mechanics. — xaosflux ^Talk 13:58, 6 May 2021 (UTC)

Had a min - still falling down the rabbit hole ... mw:Extension:ArticleCreationWorkflow references $wgArticleCreationLandingPage. (What we need to dig for is how/if the original search page is preserved - because if it isn't something being passed in to manipulate we can't just add a search text link for it and this may need to go to the extension developers). — xaosflux ^Talk 14:34, 6 May 2021 (UTC)

This uses the default Project:New user landing page as the "landing page". — xaosflux ^Talk 14:36, 6 May 2021 (UTC)

• OK SO......looks like phab:T204234 is all about this already, and has been stalled for years. — xaosflux ^Talk 14:37, 6 May 2021 (UTC)
  • Pinging extension authors: @MaxSem and Niharika: to see if this is on a known roadmap. — xaosflux ^Talk 14:37, 6 May 2021 (UTC)
• @Lights and freedom: from the task I linked to above, this does not appear to be technically possible today, unless we remove the new user landing page all together. So where to go from here? (1) Follow up on the technical improvements in phab:T204234; (2) Remove the new user article workflow extension; (3) make some improvements to Wikipedia:New_user_landing_page that don't have this functionality. For 3, you can suggest edits at Wikipedia talk:New_user_landing_page. Based on this information, can you refine what you are proposing at this time (or we can revisit this if/after (1) ever gets completed). — xaosflux ^Talk 11:36, 7 May 2021 (UTC)
  • I can't do any of this stuff. From what I've seen, everytime something in "Phabricator" is mentioned, it's been waiting for years. So somebody will have to deal with it. —Lights and freedom (talk ~ contribs) 17:40, 7 May 2021 (UTC)
    • OK, well if anyone else wants anything done on this before this archives, those are the routes available. — xaosflux ^Talk 10:26, 8 May 2021 (UTC)

Making Ds/alert notices less scary for newbies[edit]

A proposal regarding template {{Ds/alert}} which may help support editor retention is under discussion at Template talk:Ds#Add optional param to support editor retention. Your feedback would be welcome. Thanks, Mathglot (talk) 20:06, 6 May 2021 (UTC)

RfC: look of Authority Control[edit]

Can the new style of the Template:Authority control, as demonstrated in the articles in this list, be used instead of the current style (used in these)? This is a follow-up of this RfC, which had consensus for the general principles behind the redesign, but didn't have a definitive layout to agree upon yet. Fram (talk) 07:36, 7 May 2021 (UTC)

• A: the new style as proposed
• B: the new style, but autocollapsed
• C: something else

Discussion (look of Authority Control)[edit]

• Support A, second choice B, as RfC initiator. After the RfC, there has been discussion and proposals on the template talk page, with the version as now (temporary) implemented in the "Arts" subtemplate as a compromise between the RfC results and some extras that were wanted (like accommodating multiple IDs from one institution, or keeping the explanatory link for some of the more obscure acronyms). Articles like Pablo Picasso give an idea of how the new look would be: on many articles, it will be smaller of course. There is still disagreement about whether the new version may be implemented now or needs an RfC first, so here we are. If you don't support the new layout, then please indicate how to improve it while respecting the result of the previous RfC. Please don't relitigate the previous RfC though, if possible. Fram (talk) 07:42, 7 May 2021 (UTC)
• Oppose – gives, in mainspace, way too much prominence to a rather technical aspect: the new design gives even more bandwith to this than the old design. Suggestions:
  1. In #Authority control above the question was raised whether we should have this template at all. That was already one of the points following from the previous RfC: I'd suggest to ask that question in a formal RfC (which may go in another direction than the current informal discussion), before this second RfC on the design goes forward.
  2. At Andy Warhol#External links (just taking the first example of the list proposed in the OP), the new design is shown *uncollapsed* under two collapsed navboxes: for Wikipedia these (internal) navboxes are far more important than the (external) unique identification (which can be handled by WikiData): *as a bare minimum* the new design should be shown collapsed, *at the very least* always autocollapsing when the article contains an internal navbox of whatever kind.
  3. The color scheme of the authority control box (new as well as old design) follows the standard color scheme of internal navboxes: the color scheme should be *different* (as in: a color scheme not normally used by internal navboxes) and *less conspicuous* (colors that draw not attention whatsoever), thus proposing to use only grey-scale background colours in the template (instead of the purplish background colors now). Authority control is a rather technical aspect (not really encyclopedia content as such), and such less colorful background colors would be a better indication for that.

--Francis Schonken (talk) 08:49, 7 May 2021 (UTC)

• Oppose – even leaving aside that the point of authority control is not the links to AC sites, but the unique identifier values, which this proposed design hides, the new design takes up too much space in too many cases, making multiple table rows where one is currently used, often with a single identifier on each - the proponents of this unnecessary change have acknowledged that they have done no research into how many such cases exist. It also removes links to Wikipedia articles which explain the origins and use of those identifiers (example on template talk page). The close of the previous RfC explicitly stated that there was "not any consensus on the exact form that an improved version might take." Insistence that anyone not approving the new design must provide alternatives is false; unless a better proposal is made and meets community approval, the status quo pertains. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:24, 7 May 2021 (UTC)
  • I don't think you will find many people who agree that the point of AC is the values, not the links. The links without the values (i.e. this proposal, and the one accepted at the RfC) is or can be useful to get extra information; the values without the links would just lead to this template being deleted(or at the very best hidden from view, like persondata in the old days) in the blink of an eye as utterly useless clutter. Nothing was "acknowledged" in the way you claim, and you fail to mention that "one is currently used" is a rather one-sided manner of presenting the current template, where you often have one "row" which is displayed over multiple "lines" anyway (depending on the number of entries obviously, and on your screen width and font size).
  • There is consensus, community approval, for a new layout much like the one proposed now, and there is community approval to get rid of the current version. Opposing the new layout without providing alternatives which respect the result of the previous RfC is just stalling to get the result you want, the already rejected status-quo. Fram (talk) 10:40, 7 May 2021 (UTC)
    • "I don't think you will find many people who agree that the point of AC is the values" Perhaps; perhaps not. But anyone who has taken the time to understand what AC is will know that that is so, and that's what's important.
    • There was consensus for a vague proposal for an unspecified new layout, but as we all know, consensus can change, and now you need to demonstrate consensus for a specific proposal. People can choose that, or an alternative if one emerges, or the status quo if that is deemed to be the best option. So far, it is. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:53, 7 May 2021 (UTC)
• Oppose The issues discussed on the talk page need to be resolved first: in particular, the new template has a lot more whitespace than the previous one, and it doesn't include wikilinks to the relevant articles (and discussion on that talk page has been needlessly dramatic, which isn't a surprise given the people involved in this rewrite). My preference would be to go back to the previous version, which also showed the ID values (which is useful), and just change the acronyms to the words used by the new template, which meets the consensus from the previous RfC. Thanks. Mike Peel (talk) 10:34, 7 May 2021 (UTC)
  • Auto-collapsing would be even worse, since that would hide the content. Making it smaller, like the old version, is a far better solution. Thanks. Mike Peel (talk) 10:55, 7 May 2021 (UTC)
• Note: I have added options above, as "it's too big" seems to be the common theme here. @Pigsonthewing, Mike Peel, and Francis Schonken:. Fram (talk) 10:51, 7 May 2021 (UTC)
  • You appear to have neglected to add "D: no change". Your RfC is no longer neutral, as is required. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:55, 7 May 2021 (UTC)
• And why has this new design been implemented, without consensus on the 14K articles using {{Authority control (arts)}}? That change described as a "Test" should be reverted immediately. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:06, 7 May 2021 (UTC)
  • I've reverted this since sandboxes should *never* be used in mainspace, particularly on so many articles. Mike Peel (talk) 11:26, 7 May 2021 (UTC)
    • Note that this now uses a fork of {{Authority control}}, at {{Authority control (arts) Master}}. If that isn't temporary, then probably Wikipedia:Templates_for_discussion/Log/2021_February_26#Template:ACArt should be revisited. Mike Peel (talk) 12:34, 7 May 2021 (UTC)
      • Of course that's temporary. Fram (talk) 12:42, 7 May 2021 (UTC)
        • Just to note that this is at Wikipedia:Templates_for_discussion/Log/2021_May_7#Template:Authority_control_(arts)_Master. Mike Peel (talk) 13:14, 7 May 2021 (UTC)
• Note that, having learned from many previous experiences, I will not respond to comments from Pigsonthewing and Mike Peel, as they seem incapable or unwilling to post about the template without adding snide remarks or outright attacks on the people they don't agree with (just read their replies above, or other related discussions). Please take whatever they write here with a big grain of salt. Fram (talk) 11:10, 7 May 2021 (UTC)
  • Note that this is untrue, however Fram has a long history of doing *exactly what they are claiming of Andy and me* in any discussion about Wikidata. This harassment has been going on for years now. It's generally better to focus on the facts than the drama, but unfortunately they can't help it. Mike Peel (talk) 11:21, 7 May 2021 (UTC)
  • And just 92 minutes later, Fram responds to Mike Peel. I mention this as it needs to be noted that Fram will respond when they choose to; which means that lack of response to other posts (such as my pointing out that their RfC is therefore no longer neutral; or that consensus specifically for what they are now proposing needs to be demonstrated)) is selective, and is not for the (bogus) reason stated immediately above. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:01, 7 May 2021 (UTC)
• Fram, I think it would've been better to do the AC RfC at the top first. If AC is to be scrapped, or changed to a different form altogether, then spending time trying to redesign it is wasted. I think that this RfC is required (or such is felt) is somewhat IDHT - the will of the previous RfC on design was quite clear, so I don't really see why this is necessary. ProcrastinatingReader (talk) 11:16, 7 May 2021 (UTC)
• Oppose. Consensus has not yet been reached, as requested, @ Template talk:Authority control, so why are we having a premature RfC?
  • Oppose any change that entices auto-collapsing a 1-QID AC (see enticing comments already received).
  • Oppose incomplete wikilinks - on Claus Sluter#External links, why is VIAF wikilinked, but Integrated Authority File, WorldCat, etc., not? Integrated Authority File doesn't mention "Integrated Authority File", so what is it?
  • Oppose dramatic size increase & gratuitous whitespace - on Claus Sluter#External links, {{Authority control (arts)/sandbox}} is THREE TIMES (~3.25x) the size of {{Authority control (arts)}}:

  ~ Tom.Reding (talk ⋅dgaf)  11:52, 7 May 2021 (UTC)

• Why should there be consensus at the template talk page before starting an RfC here? It was obvious that no such consensus was possible there, with the same few people arguing against each other. The previous RfC (also started without consensus, and boy has that been complained about by you three) clearly showed that the opinion of you three is out-of-sync with that of many other editors. The time has come to gather wider input instead of clashing again and again about the same issues. Fram (talk) 12:15, 7 May 2021 (UTC)

• "The time has come to gather wider input instead of clashing again and again about the same issues." - AKA WP:FORUMSHOPPING.   ~ Tom.Reding (talk ⋅dgaf)  12:52, 7 May 2021 (UTC)

• So that's one OPPOSE and three SUB-OPPOSES? Would you like fries with that? — JohnFromPinckney (talk) 12:23, 7 May 2021 (UTC)

• COMMENT - I think this RFC needs to be put on “hold”... it is counter-productive, given that we currently have an open RFC (above) about whether to have any AC templates in our articles. It won’t matter what the template looks like if the consensus in the above RFC is to not have it at all. Blueboar (talk) 12:49, 7 May 2021 (UTC)
  • I don't see an RfC, but obviously if there's a proposal to remove this from 1-point-however-million pages, there would need to be (plus CENT, yada yada). — Rhododendrites ^talk \\ 13:07, 7 May 2021 (UTC)

    It's not an RfC yet per se. I wanted to 'test the waters', because I knew it would devolve into what it has, but wanted some time for some less involved people to opine, particularly on viable options. I guess by definition it'd be more suitable in the idea lab, but I don't know that place to be successful at achieving much, so wanted to try this. I don't think a normal RfC (i.e. a survey/discussion-style) would be conclusive, in part due to the persistent personalisations, so I'm still thinking on what form it should take. There's also some brainstorming going on by less involved parties and maybe that might help bridge some gaps between different views on this template. In any case, I obviously wanted to take some aspect of the proposal to an RfC... ProcrastinatingReader (talk) 13:21, 7 May 2021 (UTC)

    • Sorry, my bad... There is an ongoing discussion (above) about whether to have (or not have) the template at all, and I assumed it was an RFC. Thanks for pointing out that it isn’t.

So, I will change my comment to: “C” - something else (my preference would be to provide a simple link to Wikidata - similar to how we link to commons for images - instead of hosting the AC stuff directly in our articles) Blueboar (talk) 14:20, 7 May 2021 (UTC)

• A somewhat reluctant A, I guess. Not collapsed by default, but with whether it should be collapsed left to an article-by-article basis. Definitely open to C, too, if someone has other ideas. I don't fully agree with the closing statement of the last RfC. There was clear support for the RfC statement about making this template user friendly, but most people didn't actually speak specifically to the example provided (and many who did were highlighting issues with it). But that RfC is what we have, and nobody has challenged the close AFAIK. So we have the idea that we must make it more user friendly, and an example to use as a rough starting point for discussion of what that should look like. At the same, I think there are a lot of people who like the idea of user-friendliness but didn't really think about just how big that would make some of these templates. If the design of the old version of the template had one virtue it was being compact, of course. So I suspect the user-friendliness may make ultimately it easier for those who want to remove it from the page to convince others, ironically. We'll see, I suppose. — Rhododendrites ^talk \\ 13:07, 7 May 2021 (UTC)
• Support A This RfC constitutes forum shopping (by the opposers of the original RfC, not by Fram) in an attempt to overturn the clear consensus of the first RfC. As I wrote on the template talk page, the [original] RfC shows clear consensus that the sandbox is preferable to the status quo. That consensus should not be overturned by a few vociferous objectors on the talk page. Also weakly support B, on the grounds that, again quoting myself from the template talk page, I [see] no reason to deviate from the standard navbox behavior (of autocollapsing when there are two or more navboxes and not collapsing when there is only one navbox). * Pppery * it has begun... 13:55, 7 May 2021 (UTC)
  • Fram starting an RfC (nor indeed later changing it to be non-neutral) is not me or anyone else forum shopping. When you wrote that on the talk page, I replied [emphasis in original]: The burden is on you to show consensus for the change you propose to make (and not just for a change). Note also that the RfC did not speak at all about the version currently in the sandbox, which was not presented there; indeed, it explicitly stated that there was "not any consensus on the exact form that an improved version might take.". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 7 May 2021 (UTC)
• A, looking at the examples below. It is much more human-readable, and I'd call it an incremental improvement over the old template. I think the default auto collapsing behavior is fine (collapse when it's not the only footer template). I also think though that we should pursue an RFC based out of the earlier discussion here above, as there are some alternatives (like link to wikidata or an intermediate enwiki page) that could make AC redesign moot. Levivich ^harass/_hound 16:28, 7 May 2021 (UTC)
  • B is fine with me too per others below. Personally I don't think whether it's always collapsed or has the default behavior is a big deal for me. Levivich ^harass/_hound 21:13, 9 May 2021 (UTC)
• A - while I like authority control templates, I don't like the fact that they're so cryptic. This would be a big increase in usability at a relatively small cost of more "junk" at the bottom of a page. Guettarda (talk) 16:44, 7 May 2021 (UTC)
• B I don't think our readers actually use this template much, heck I can't remember the last time I actually used an authority control template. This template should stay out of sight and out of mind; if folks really want it they can uncollapse it. Frankly, the whole idea of Authority Control seems like something mostly for internal use, perhaps it would be best to put such templates on talk pages instead. CaptainEek ^{Edits Ho Cap'n!}⚓ 21:30, 8 May 2021 (UTC)
• B to the extent that we're doing this RfC, per CaptainEek. Second choice option A, because something slightly longer and... English... is better than something shorter and machine. ProcrastinatingReader (talk) 12:24, 9 May 2021 (UTC)
• B As per the comments above. Sea Ane (talk) 19:56, 9 May 2021 (UTC)
• B seems to the ideal compromise for providing extra and immediately available information to readers, without shoving it in their face. Of course, the more accessible layout is certainly desirable for our readers, who will be surely confused otherwise. Aza24 (talk) 20:12, 9 May 2021 (UTC)

Examples[edit]

From the template testcases page:

Old:

new:

old:

new:

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:21, 7 May 2021 (UTC)

Note: the above examples are fictitious, these ones don't appear on a real article. The RfC made sure that next to the 1 million examples of the old template, there were 14000 examples of the new template to be checked out on actual articles (as the previous RfC example was said to be "cherry-picked"), but the 3 main opposers of all these changes have reverted all efforts to do this, claiming "disruption" (the new version worked just as well as the version they reverted to, and showed the same number of ACs). Basically, the 3 defenders of the status quo are doing everything in their power to disrupt this (and the previous RfC, and the discussions at the template talk page). A very tiring situation, about which I started Wikipedia:Administrators' noticeboard/Incidents#Pigsonthewing et al.. Perhaps this RfC should be simply stopped and restarted then under the supervision of some neutral admins, to avoid further disruption. As it stands, the chances of getting anyone interested in participating in these shambles are slim, which was probably the intention.

The above examples are also, to use the terminology used against the previous RfC, cherrypicked. The testpages also contain some equally fictituous examples:

vs.

And

vs.

Fram (talk) 16:35, 7 May 2021 (UTC)

Note that the large example you mention isn't fictitious, it's the actual authority control template used on Douglas Adams. * Pppery * it has begun... 16:43, 7 May 2021 (UTC)

Mass deletion of redirects of non-diacritic articles[edit]

Requesting outside feedback on wikiproject mergers[edit]

I believe this is likely the one and only place I can bring up wikiproject mergers for outside feedback. It is being proposed that WP:METEOROLOGY, WP:WPTC, and WP:SEVERE be merged into WP:WEATHER. I would like to give a rundown of what has been done thus far and what is being proposed exactly. In the case of Meterology, the project is quite inactive and the articles need to be sorted out into different topics/taskforces so we can see where everything stands. Some articles were already moved over to taskforces in Weather before the WPTC and WP severe mergers were disputed. Weather is supposed to supersede the meteorology project directly. WP:CLIMATE was entirely defunct, not even having a talkpage template to sort normal climate articles underneath it. This project was moved over to Wikipedia:WikiProject Weather/Climate task force and had nearly 200 articles sorted into it. The flood, droughts & wildfires, and met instruments were moved out of WP Met and over to WP Weather, becoming official taskforces. All have since had articles added to them. WP:NTROP was a project that was defunct for quite a while and was barely on life support. I migrated it over to a taskforce given the support from its members, moving all of its subpages over to allow it to function as a subproject/task force underneath WP:WEATHER.

That being said, the coverage of floods, droughts & wildfires, non-tropical systems, and weather outside the United States is in bad shape. It is being proposed that we have one, united weather project. While WPTC and WP:SEVERE are active and doing pretty well, the rest of the weather has unfortunately suffered from years of neglect. It is being proposed that WPTC and WP:SEVERE be merged over into WP:WEATHER (with all subpages moved over) and operate as subprojects/task forces of WP:WEATHER. The goal here is not to drastically change how these projects currently operate. The biggest changes would be talkpage templates would switch over to WP:WEATHER and the titles of project pages would become task force pages. Having one project would allow for shared resources, such as more reviewers, as well as a standardized assessment of articles across the topic of weather. Hopefully, this would also make cooperation easier as everything would be under one roof. There is a lot of overlap between weather topics, such as tropical cyclones spawning tornadoes (severe weather), becoming extratropical cyclones (non-tropical), ending droughts, causing floods, and starting wildfires via lightning or winds. Topics that have been neglected may see more help with them as there would be increased awareness since everything is no longer partitioned off into separate projects. Tornado and tropical cyclone articles seem to be the main focus for weather on WP at this point, but we need to address the problem of lacking coverage outside these areas. Smaller projects are difficult to maintain and I believe it to be in the best interest of everything else that WPTC and WP:SEVERE be merged into WP:WEATHER. Please feel free to participate in the merge discussion here. Noah^Talk 23:51, 9 May 2021 (UTC)

User:SlimVirgin userspace pages[edit]

As many will know, User:SlimVirgin has passed away. There are a little over 120 subpages in her userspaces, some of which are drafts for articles or collections of notes. Many are currently blank but have substantial edit history of past draft work. Someone should curate these pages. If she had drafts in progress, her intent may have been to eventually work these into articles. BD2412 T 02:19, 10 May 2021 (UTC)

Fortunately there is no deadline for userspace pages. If she had anything in progress in draftspace though it would be best to work on them before they get G13ed - I don't know what happens regarding notifications for users who've opted out of bot messages? Thryduulf (talk) 02:39, 10 May 2021 (UTC)

There is no deadline, but they could be forgotten and left to sit undeveloped forever. BD2412 T 02:49, 10 May 2021 (UTC)

True, but my point was that before worrying about what to do with pages that have no deadline, ascertain whether there are any that do and, if so, work out what you want to do with those first. Thryduulf (talk) 23:08, 10 May 2021 (UTC)

I appreciate your note to let us know. by the way, some of those pages are actually empty, with no content. is it okay to delete those? it would be a bit convoluted to sift through the edit history of each page, wouldn't it? ---Sm8900 (talk) 🌍 23:14, 10 May 2021 (UTC)

Yes, in retrospect I would think those pages, having been blanked by SV, would be ripe for deletion. If SV had wanted their edit history to be noted somewhere, she knew how to do that. BD2412 T 23:23, 10 May 2021 (UTC)

BD2412, I'll take a look. — Alexis Jazz (talk or ping me) 23:37, 10 May 2021 (UTC)

Allow related Wikinews original reporting in articles[edit]

I am a Wikinews and Wikipedia editor. I was not aware of a change that was made in 2018 that mainly restricted Wikinews links using Template:Wikinews to the bottom of the article/external link area. Previously, I had put my Wikinews articles within Wikipedia articles — for example, I put an article I wrote on the 2021 Kernadec Island earthquakes in 2021 Kermadec Islands earthquakes#Earthquakes. I understand why articles like this, which contain no new original reporting, and are based off existing articles that should, ideally, already be cited, have no need to be cited inline.

But, I don't understand why original reporting would not be relevant to the reader. The process of verifying, for example, interviews on Wikinews, is that the content is reviewed by a community reviewer before being published. In my experience, though mine is not universal, I conduct interviews via email, post the text of the email on the talk page, and forward the email onto a scoop email which I believe reviewers have access to. It's not a perfect process by any means, but I think it's a reasonable process to verify the validity of the content.

It also does provide additional helpful information to the reader. In the context of, again using my own example, an article on the 2020 Groom by-election, interviews with the candidates do help the readers, and it's useful to have it listed in the relevant section. Again, obviously there are limits to this. An article about the history of Australia, for example, doesn't need an inline link to an interview with an Australian historian. Common sense can be used. But I think that it can be helpful to the reader to have relevant Wikinews original reporting inline in an article. --LivelyRatification (talk) 02:46, 10 May 2021 (UTC)

• I agree with this. ---Sm8900 (talk) 🌍 14:18, 10 May 2021 (UTC)

  Why? How do you square it with WP:NOR, one of our core content policies? Phil Bridger (talk) 17:56, 10 May 2021 (UTC)

• @LivelyRatification: Could you elaborate on how this proposal reconciles with WP:NOR? Is the idea that WikiNews is separate from Wikipedia and thus NOR doesn't apply? — Rhododendrites ^talk \\ 14:23, 10 May 2021 (UTC)

That's my thoughts, yeah, that Wikinews is separate. Obviously if we added to the article "[x] candidate said [y]" using Wikinews as a source it'd be different, but we wouldn't be adding any material to the article prose, just pointing readers to original research done by one of our sister projects. To use another example, if information from a Wikivoyage article was put into a Wikipedia article verbatim, it'd be unreliable because it didn't cite any sources, but it's acceptable to link to articles in that project, even if Wikivoyage doesn't have the same standards of verification and sourcing as Wikipedia. --LivelyRatification (talk) 20:53, 10 May 2021 (UTC)

• From my perspective wikinews seems to be an appropriate external link following WP:ELYES #3 since we can't incorporate the information because of our NOR policy but it is still relevant to an encyclopedic understanding of the proposal. On the other hand I quite agree with the 2018 RfC in that there really isn't a good reason for special highlightning of WikiNews links. They should imo be treated like external links like any other and go in the external link section, preferably without a large box. --Trialpears (talk) 21:06, 10 May 2021 (UTC)
• Wikinews aims to be a news outlet, and we should treat it exactly the same as we treat every other news outlet, without any sort of favoritism just because it falls under the WMF umbrella. The 2018 discussion did that pretty well. What other news outlet gets its own template, or even placement in the external links section? The proper way to include Wikinews would be the same as the proper way to include any other news outlet—as a reference. That'd require establishing consensus that Wikinews is a reliable source, though, and I see at RSP that editors do not currently feel that it is. So sorry, but I do not see a path for Wikinews to be used on Wikipedia unless that consensus changes. {{u|Sdkb}} ^talk 05:27, 11 May 2021 (UTC)

• The article on Wikinews says that, unlike other Wikimedia projects, Wikinews allows original research. Since any reader of Wikinews can edit the site, would Wikinews be counted as a reliable source? Rollo August (talk) 21:38, 11 May 2021 (UTC)

  The documentation at Template:Wikinews says clearly (though below the fold):

  N Do not place this template in the main body of the article.

  Higher up it says that the template "is not intended to represent sources for Wikipedia articles." And above that, in the ambox, is a link to a discussion from 2018 where Wikinews was rejected as a source. — JohnFromPinckney (talk) 23:29, 11 May 2021 (UTC)

• My personal opinion is that we should never direct people to Wikinews in any way. It's coverage is arbitrary original research, not professional journalism. I don't know why it still exists at all but we shouldn't direct people to it as if it is a reliable source or a real news organization. Beeblebrox (talk) 19:55, 12 May 2021 (UTC)

Restricting GFDL-licensed uploads[edit]

This is a proposal to make some restrictions on uploading new files licensed {{GFDL}}-only.

GFDL was originally designed for software manuals and it is not good for media because it makes it difficult to re-use the material (see comic to the right). Motivated by the the wish of making it easier to re-use files in compliance with the world-wide wiki-vision the Wikimedia Foundation Board decided in 2009 to stop using GFDL as a sole license while allowing importation of text without the GFDL license. The Wikimedia Foundation Board did not forbid GFDL for media files but encourages people to use licenses other than GFDL, for example CC licenses.

The Wikimedia Foundation Board explicitly mentioned that each wiki could restrict the use of GFDL. The English Wikipedia has removed GFDL from MediaWiki:Licenses and MediaWiki:Licenses/en-ownwork but it is still possible for users to add it manually.

In September 2018 is was suggested to deprecate the GFDL license but at the time no consensus could be formed to limit GFDL on the English Wikipedia.

Some of the arguments against the restrictions were:

1. We have a lot of non-free files so why should we not allow GFDL?
2. If we find media that is licensed GFDL we won't be able to copy it to Wikipedia.

Re 1) The idea of a wiki is to share knowledge freely. That is the reason we have Wikipedia! Non-free content is an exception per the licensing policy. It is something a community may decide to have (not must) but the use must be minimal. So while we have non-free files that is not a reason to allow anyone to license their uploads with a license that isn't quite in the spirit of sharing free knowledge. We also don't allow CC BY-NC or CC BY-ND.

Re 2) Technically true, but the use of GFDL for media files is virtually (if not completely) nonexistent outside Wikimedia. When files are uploaded as GFDL in 2021 it is either because it is a copy or a derivative of another file from another wiki-project or because the uploader has specifically chosen to use GFDL.

Several projects already have restricted the use of GFDL, for example Japanese Wikipedia, Commons and Wikivoyage. Other projects are likely waiting to see what English Wikipedia does.

The suggestion is this:

GFDL is not permitted as the only acceptable license where all of the following are true:

• The content was licensed on or after 1 July 2021. The licensing date is considered, not the creation or upload date.
• The content is primarily a photograph, painting, drawing, audio or video.
• The content is not a software logo, diagram or screenshot that is extracted from GFDL software or^[4] a GFDL software manual.

The above does not restrict non-free usage of content. If a work that is not a derivative work with a GFDL license is used under a non-free rationale, it doesn't have to be scaled down but other non-free limitations will still apply.

The theoretical possibility of future GFDL-licensed content that would be eligible for non-free inclusion has been brought up as an argument in the past and this is a compromise that will hopefully mitigate that.

I'm not a native English speaker so if there are typos or bad wording you are welcome to fix. Thank you! --MGA73 (talk) 16:37, 10 May 2021 (UTC)

^ The term "GFDL software" was based on a misunderstanding. GFDL was created two decades ago to accompany free software licenses because using free software licenses for manuals was considered odd. GFDL was adopted by some software projects for their manuals, but never for the software itself. Since GFDL-licensed software doesn't exist, it is not possible to extract anything from it. Software logos, diagrams or screenshots can only be extracted from GFDL-licensed software manuals, which do exist. This note was added by Alexis Jazz, coauthor of this proposal. Apologies for any confusion that may have arisen from this error. — Alexis Jazz (talk or ping me) 15:17, 12 May 2021 (UTC)

• Oppose. We are the free encyclopedia. That means, as far as files are concerned, that any license that is free enough will do. What constitutes a free enough license is defined by the foundation:Resolution:Licensing policy, referring to the Definition of Free Cultural Works (1.0), and GFDL fully meets these these requirements. That Commons no longer allows GFDL-only files is an excellent reason to allow them to be uploaded locally here. The "free" in the free culture movement includes the freedom to choose between equally free licenses. – Finnusertop (talk ⋅ contribs) 17:03, 10 May 2021 (UTC)

  Thank you for your comment. I would like to point out that it was the Wikimedia Foundation Board that decided in 2009, that GFDL should not be used on wiki projects. If anyone know what "we" are it must be the Wikimedia Foundation Board? Commons continued to allow GFDL for 9 years before they fully implemented the resolution. Do not blame Commons for the resolution if you disagree with it. --MGA73 (talk) 17:59, 10 May 2021 (UTC)

  It decided it would stop allowing it on uploads as the sole license. At no point did it decide that it 'should not be used on wiki projects'. You would make your point better if you did not state outright falsehoods. Only in death does duty end (talk) 18:15, 10 May 2021 (UTC)

  Sorry it is was not clear. I'm only talking about future uploads. Files allready uploaded can of course stay. Thank you for letting me know. --MGA73 (talk) 19:29, 10 May 2021 (UTC)

• Support. The link Finnusertop provides links to [5] from where you end up at [6] which also notes the problem with GFDL. Finnusertop speaks of allowing "GFDL-only files" to be uploaded here so they won't be homeless. The reality is that without Wikimedia, GFDL-only licensed photos wouldn't exist to begin with. Not all free licenses are equal. One could even make up a completely ridiculous but technically free homebrew license, and I can only hope we'd reject it if that happened. GFDL is a relic of the past. It served a purpose, once. It no longer does, it has been superseded by better licenses. GFDL is not a practical license for visual media (like photos) and there is literally no reason for a photographer to license their photos as GFDL other than to pester re-users. We shouldn't allow photographers to pester re-users. — Alexis Jazz (talk or ping me) 18:01, 10 May 2021 (UTC)
• Support. The GFDL is free, and I don't think anyone here is questioning that. The GNU FDL is perfect for free software documentation, as well as any other text where the list of contributors is not as large as Wikipedia's. But this is not the case for media (especially photographs), where it's very impractical to use. We are supposed to make knowledge easier to disseminate. The GFDL doesn't allow that for media. Even the FSF has acknowledged the impracticality of the FDL on those media, which is why they released FDL 1.3 in the first place.

  I'm okay with the compromise that has been put here. I don't see any reason to restrict the resolution of a solely GFDL-licensed medium. But we certainly should discourage solely using the GFDL for non-text, non-software media. pandakekok9 (talk) 05:24, 11 May 2021 (UTC)

• I'm somewhat meh on this. On the one hand, we shouldn't be afraid of trying to clean up relics of the past to simplify the maintenance burden, and GFDL is clearly a relic of the past. However, because of past media uploaded with it, we'll never be able to get rid of it completely. It appears that we've already done what we can to discourage its use by making it super far from the default. Given that, the number of files being uploaded via GFDL is likely tiny. If someone really wants to use it for some reason and won't contribute their work otherwise, then sure, I hope we'll decide to take the work. But hopefully pretty much everyone will just go and put it on Commons under CC. {{u|Sdkb}} ^talk 05:41, 11 May 2021 (UTC)
• Support. I see no drawbacks and even WMF itself is saying it's not ideal for image media. SpartaN (talk) 05:52, 11 May 2021 (UTC)
• Too early to just prohibit GFDL, instead deprecated and discourage it for a year, especially with an edit filter warning. After a year we can evaluate whether it is still needed at all and prohibit if it really is useless. Graeme Bartlett (talk) 10:14, 11 May 2021 (UTC)

  @Graeme Bartlett: Thank you. The license was removed as a suggested license in 2009: Special:Diff/294994426. So it has been discouraged for almost 12 years now. --MGA73 (talk) 13:40, 11 May 2021 (UTC)

• Support This is years overdue, how are GFDL-only licenses still allowed here? GFDL really isn't suitable for images, and GFDL-only uploads haven't been allowed on Commons since 2018! Thanks. Mike Peel (talk) 10:50, 11 May 2021 (UTC)
• Meh leaning support, how many GFDL only uploads have we had in the past 12 years? —Kusma (t·c) 14:23, 11 May 2021 (UTC)

  @Kusma: Thank you. My guess is around 1380 files. --MGA73 (talk) 19:34, 11 May 2021 (UTC)

  MGA73, thanks. The vast majority of these seem rather old, with very few exceptions such as File:RitwikSanyal1.JPG (which is a new upload overwriting an older one GFDL licensed in 2010). Incidentally, the "Upload a new version of this file" dialog doesn't do a good job at checking that the license of the new and old files are identical. —Kusma (t·c) 20:44, 11 May 2021 (UTC)

  MGA73, actually far less. Kusma asked about the last 12 years. (so since 2009) Files older than that which weren't eligible for relicensing would also be included in your query. Who hopper.png was actually PD-self (maybe the uploader was confused?), File:Poktori-2.jpg is PD-self, File:Chuck Close 1.jpg is nonfree, File:Paullusmagnus-logo.JPG comes from m:File:Paullusmagnus-logo (small) reloaded.png and is GFDL-presumed and would be eligible for relicensing as CC BY-SA 3.0 if we accept the GFDL-presumed, this isn't own work?, File:Shared interest lending diagram.PNG was incorrectly tagged as not being eligible for relicensing, File:Tenka Qing.png is identical to w:ja:ファイル:Tenka Qing.png so also incorrectly tagged as not being eligible for relicensing, File:Pb0.9.2 (r86)Win7.PNG is GPL I guess, File:Fence Lake Monument.jpg is also PD-self. And so on. Excluding false positives, overwrites where the original upload is eligible for relicensing but the overwrite isn't and uploads from 2009 and 2010 when some uploaders just weren't aware yet of the license migration, only a small fraction would be left. — Alexis Jazz (talk or ping me) 21:54, 11 May 2021 (UTC)

  @Kusma and Alexis Jazz: I know the number can be discussed. There are also files that are moved to Commons, deleted or where the uploader have later agreed to relicense. I hope everyone will accept if GFDL is no longer accepted for new uploads and therefore use a cc-license. --MGA73 (talk) 07:30, 12 May 2021 (UTC)

• So, I'm supportive of not allowing new original works in GFDL only; but not so supportive of relegating uploads of existing GFDL works found elsewhere to non-free/fair-use only status. — xaosflux ^Talk 14:41, 11 May 2021 (UTC)

  @Xaosflux: Thank you. If existing works are licensed GFDL today they can still be uploaded as GFDL. Also in 2 months or 2 years from now. --MGA73 (talk) 19:21, 11 May 2021 (UTC)

  Xaosflux, if it was licensed before 1 July 2021 you could still upload it, even after 1 July 2021. If it was licensed after 1 July 2021.. Just try to find something that was recently licensed as GFDL outside Wikimedia. I'll be surprised if you find anything. IIRC, some years ago a Wikipedian convinced an organization that didn't want to release their work with a free license to release some work under the GFDL because the terms would complicate/inhibit re-use anyway, so they wouldn't have to worry much about those pesky re-users. Errr, yeah. notafish advocated for this all the way back in 2005: Why the Wikimedia projects should not use GFDL as a stand alone license for images. — Alexis Jazz (talk or ping me) 19:40, 11 May 2021 (UTC)

  @Alexis Jazz: so if we are not going to purge the ones we have or consider them non-free, and they would be a rarity -- why would we need to prohibit them? What problem is that solving? I'm fully supportive that any editor-created images should be CCBYA (and really, they should be uploaded to commons not enwiki unless there is some esoteric non-article related reason). — xaosflux ^Talk 19:57, 11 May 2021 (UTC)

  Xaosflux, we don't want to name and shame, but there are photographers who either multi-license their work with GFDL+CC BY-NC knowing full well the GFDL is largely useless for commercial use of a single image in a printed publication or who will hang on to GFDL until it is no longer allowed to either make a point about GFDL being a bad license (some will know who I'm talking about) or out of some sort of misplaced nostalgia. Not being able to completely dry the room doesn't mean we shouldn't stop people from using the faucet above the broken sink. Use of GFDL-only images in articles can only decline after we've sealed the faucet. — Alexis Jazz (talk or ping me) 20:34, 11 May 2021 (UTC)

  I'm not convinced this is a problem in need of solving, if that photog is an editor - then sure, lets say they can only upload their own work under CCBYSA; If you find one of their pics and think it is useful to include then I don't think we should stop you from uploading it though. — xaosflux ^Talk 20:57, 11 May 2021 (UTC)

  Xaosflux, I guess I was unclear. All the photographers I'm talking about are Wikimedians. One does not find GFDL-licensed photos outside Wikimedia. — Alexis Jazz (talk or ping me) 21:59, 11 May 2021 (UTC)

  @Alexis Jazz: well - you could, but in any case I'd be fine with the next step being that we disallow anyone to upload their own work here with only a GFDL license. — xaosflux ^Talk 23:10, 11 May 2021 (UTC)

• Support GFDL was always a poor fit for images. It is designed for manuals, textbooks, other reference and instructional materials, and documentation which often accompanies GNU software... it can be used for any text-based work, regardless of subject matter. (bold mine). It was used for images in Wikipedia's early days because the Creative Commons licenses didn't exist yet. Once CC became fully developed and it was clear that CC was a better license for use on images, the WMF wisely began the process of migrating image licensing policy to favor CC licensing. Basically, the GFDL was a poor tool to fit the purpose, but was all that we had in 2001 when Wikipedia was founded. When better tools came along, it was no longer needed as a tool. Other than legacy images which have been licensed with only GFDL before we change the policy, we should deprecate any future uses of the license. --Jayron32 14:47, 11 May 2021 (UTC)
• Support. Flickr does not offer GFDL licensing on uploaded images. Google does not show GFDL licensed images in their "free images only" tools on Google Images. GFDL itself is intended for "manual, textbook or other document"s. For these reasons, we shouldn't allow images solely licensed under GFDL - because not only are they limiting the reuse on Wikipedia, it prevents other image hosting sites from reusing our images as part of their repositories. However, I do not think it should be deprecated as a whole - as long as someone chooses to license their image under another acceptable free license (or to the public domain/CC0), they should be permitted to also select GFDL and license it that way. Furthermore, images licensed only under GFDL should continue to be uploadable, and I do not believe that they should be considered fully "non-free content". If a GFDL image is the only one that is able to be found for a purpose, even if a freer image could be created, I think that the non-free content criteria should accommodate using a GFDL licensed image as opposed to relegating it to the strictness of those criteria - but not a full relaxation thereof. Part of the Wikimedia movement is to encourage free access to information - and we are not accomplishing that by considering the GFDL, with its onerous and strict terms for abiding with attribution, the same as a CC license. The GFDL is great for its purpose - especially when considering digital documentation/media that can easily contain a plethora of required attribution/copying elements without it becoming unusable - but that is not what we consider "free". -bɜ:ʳkənhɪmez (User/say hi!) 22:06, 11 May 2021 (UTC)
• Support, mainly per Alexis Jazz. GFDL-only is a bad license for images, and it's now obsolete. No reason to continue to allow it, especially since the only people who use GFDL-only for images are Wikimedia editors. In effect we continue to perpetuate a bad copyright practice that doesn't exist anywhere else. Regarding fair use concerns, I think they are mostly theoretical, again since the only people who might ever want (and ever do) upload a GFDL-only image to Wikipedia are Wikipedia users themselves and they upload their own work. The likelihood that we are going to find an image somewhere on the web licensed as GFDL-only that we may want to upload here (as fair use or as a free image) is quite small. But for formal purposes I'd be perfectly fine explicitly specifying that if someone wants to upload a GFDL-only licensed image as a fair use image, that's allowed and that in this situation GFDL-only will be treated the same as a non-free license. Nsk92 (talk) 23:57, 11 May 2021 (UTC)
• Oppose per Finnusertop, and concerns raised by Xaosflux even though I actually agree Creative Commons is a better license for photos, I have to stick to my beliefs in the freedom to choose. I might otherwise need that far less practical option some day, so I'm against anyone removing it. Also, the idea of adding this WP:CREEPy instruction set about if you uploaded before or after this date is just adding adding more needless confusion to the process that we say we want to remove by getting rid of "3 pages" of licensing. Except, the 3 pages have already been determined to be "free enough" so there is no confusion, but the new policy would bring plenty of confusion while people attempt to make "determinations" about already existing media. I can see all the disputes happening already... Huggums537 (talk) 01:47, 12 May 2021 (UTC)

  @Huggums537: Thank you for your comment. I agree that we should make things as simple as possible. But I think that the only way to make it more simple is to reduce it to "GFDL is not allowed!". I know you oppose but if you had to chose between those 2 alternatives which one do you think is the best (or the least crappy)? --MGA73 (talk) 07:43, 12 May 2021 (UTC)

  Forgive me, but exactly which 2 crappy alternatives are you asking me to choose from? Huggums537 (talk) 10:10, 12 May 2021 (UTC)

  @Huggums537: First alternative is my original (the one you call CREEPy) and the second alternative is "GFDL is not allowed.". --MGA73 (talk) 10:22, 12 May 2021 (UTC)

  Ok. Got it. I vote for a third alternative, just leave things as they are because you can't very easily add free software with a Creative Commons, but you can with a GFDL. This proposal overlooks that fact. Huggums537 (talk) 10:28, 12 May 2021 (UTC)

  @Huggums537: Thank you. But the proposal is that software licensed GFDL can still be uploaded to Wikipedia as GFDL. --MGA73 (talk) 12:02, 12 May 2021 (UTC)

  Yes, I understand your point, but I read your proposal differently because educational and/or instructional software as well can oftentimes also be primarily categorized as video or audio, so the proposal as it is written could cause those softwares to be excluded. These are the kinds of softwares I was thinking of that might get overlooked, but there very well may be other factors that have not been taken into consideration. Huggums537 (talk) 14:29, 12 May 2021 (UTC)

  Huggums537, I might otherwise need that far less practical option some day Actually, you won't. If somehow in the future you find a problem with Creative Commons, you might switch to the basic {{Attribution}} or {{PD-self}} templates, perhaps {{FAL}} or another free license or write a better license from scratch. But not GFDL. instruction set about if you uploaded before or after this date That's actually not in there. There is a standard grandfather clause based in the licensing date. So if you find a GFDL-only licensed file on, say, dewiki or itwiki, you may upload it here if it was tagged GFDL before 1 July 2021. make "determinations" about already existing media Already existing media is simply not affected by this proposal, so there is no need to worry about dispute over that. Except, the 3 pages have already been determined to be "free enough" The real-world example from notafish and the comic explain why GFDL just isn't a practical license for visual media. There appears to be some confusion about "GFDL software", but this appears to be an error in the proposal that I overlooked (I coauthored the proposal): GFDL was created two decades ago to accompany existing free software licenses like the GPL. Before that, the manual that came with free software was typically licensed under the free software license, which was odd because reasons. Software itself does not get licensed as GFDL. — Alexis Jazz (talk or ping me) 14:56, 12 May 2021 (UTC)

  Okay, that addresses a lot of my concerns, and I still do think the Creative Commons is a better license for photos. I'm just not convinced it's better for audio or video or even drawings since they can be comprised of illustration such as flow charts and blueprints etc. You can find a good example of the confusion I'm talking about if you do a Google search for Harry Potter wizarding world DVD game, then try to make a determination whether it should be classified as a DVD video, a software video game or perhaps either or both. Huggums537 (talk) 15:38, 12 May 2021 (UTC) An even better general example that I can think of is a document called an electrical schematic which could be interpreted as both a drawing and/or a manual. Huggums537 (talk) 16:30, 12 May 2021 (UTC)

  The distinctive aspects of the GFDL is the requirement to maintain some of the identity of the original—the specified cover text, any specified invariant sections, and the acknowledgment or dedication sections—while also requiring the modified version to distinguish itself from the original with a different title. For audio or video recordings, frankly I think it would be preferable for someone to craft a new free licence that appropriately takes into account the attributes of those media. For a schematic, sure, issue it within a document that already complies with the GFDL. isaacl (talk) 19:58, 12 May 2021 (UTC)

  I guess that makes sense. Another good example is blueprints because they are architectural drawings, but also construction manuals. Huggums537 (talk) 20:14, 12 May 2021 (UTC)

• GFDL only makes sense for printed works that can contain within themselves the sections required to be preserved by modified versions, as the licence assumes this context. At a minimum, this means a title page, copyright and licensing page, and history section. I think it is reasonable to restrict its use to files that already contain within themselves a title page, a copyright and licensing page, and if the file is a modification of an earlier one, a history section. Thus even for an image extracted from a GFDL book, I think the uploaded work should contain within itself a title, copyright and licensing, and history pages, either within the image or with everything bundled together in a document file format. This would make it easier for re-users to comply with the licensing terms. isaacl (talk) 02:17, 12 May 2021 (UTC)

  That is a very reasonable argument. However, the argument could also be made that the title of a photo technically constitutes a "title page", and the revision history of the photo a "history page" while licensing does not need to be within the photo itself, unlike other media such as film or software. On the flip side of this argument, we could allow media such as film and free software under a GFDL license because they have titles, revision histories (maybe not so much in film), and licensing within them. Huggums537 (talk) 10:05, 12 May 2021 (UTC)

  @Huggums537: yes we could. But the question is why should we? WMF conluded in 2009 that GFDl is not good for Wikipedia so they decided not to use it as the sole license. There are better alternatives so why not use them? --MGA73 (talk) 10:32, 12 May 2021 (UTC)

  Because in the case of drawings, audio, and video this could be instructional or educational in nature such as a type of course work that is more suitable to a GFDL license than Creative Commons for the authors. While we are a "free knowledge" site even CC acknowledges authorship [through attribution]. Huggums537 (talk) 10:49, 12 May 2021 (UTC)

  If you squint just right, and turn your head just so, you can sort of invent ways for other forms of media to have equivalents to the sections described by the GFDL. (For a photo distributed as its own individual work, separate web pages is not one of them, as the license refers to sections and pages of the document itself. Also reproducing the license in full within the document is mandatory.) But the fact remains that the licence was written assuming the context of a printed work with specific sections contained within the document, and thus it makes most sense to limit the use of the license to works within this context. isaacl (talk) 14:42, 12 May 2021 (UTC)

• Support GFDL is impractical for new content, and if people practically can't reuse our content, then it's not really free (as in freedom). It is important that we have an exception for legacy content though like Commons has, as there is a lot of legacy early 2000s content out there that was licensed as GFDL just because it was the popular license at the time (I uploaded some to Commons a few months ago). Legoktm (talk) 15:29, 12 May 2021 (UTC)
• Support. Ruslik_Zero 20:47, 12 May 2021 (UTC)
• Oppose. "Is it helpful? Is it necessary? Is it kind?" Does this solve an actual problem Wikipedia has? Or only an imagined one, that will make uploading (and RE-uploading) relevant media more difficult? Does this improve the encyclopedia or its usability or its RE-usability? If not, vote NO. 71.62.227.79 (talk) 02:52, 13 May 2021 (UTC)

  Does this solve an actual problem Wikipedia has? Didn't want to name and shame, but I guess there's no avoiding it eventually. Here's an example. that will make uploading (and RE-uploading) relevant media more difficult? GFDL hasn't been a default option for years. Licensing date counts, not the upload date. Is it necessary? Is it kind? If you simply don't care, why require a license at all? Even easier. Yes, it's necessary. or its RE-usability? Yes, that one. See this real-world example from notafish and the comic above. — Alexis Jazz (talk or ping me) 04:27, 13 May 2021 (UTC)

• Strongly oppose. I use the GFDL because I have frequently seen images I uploaded under Creative Commons used outside Wikipedia without attribution because it is widely assumed to be equivalent to public domain. I no longer upload my photos to Commons because they adopted a proposal like this. Jonathunder (talk) 16:41, 13 May 2021 (UTC)

  Lots of people erroneously assume that Wikipedia's text is PD and violate the license. Doesn't mean we should go back to GFDL only for the text. —Kusma (t·c) 16:51, 13 May 2021 (UTC)

  Thank you for your comment. Sadly there are always someone that do not care about copyright. I do not think that it makes much difference to them if you add CC or GFDL. May I ask if there is always attribution for the files you have licensed GFDL? --MGA73 (talk) 17:20, 13 May 2021 (UTC)